Language:
switch to room list switch to menu My folders
Go to page: First ... 62 63 64 65 [66] 67 68 69 70 ... Last
[#] Tue Jun 28 2011 12:42:44 EDT from skpacman @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

http://bit.ly/iN1bmZ

[Microsoft Office 365 Goes Live]

Sorry M$..... Google beat you to it.

I've never been a fan of Exchange (I use Citadel) and SharePoint is PointLess (at least for my uses)... so I think I'll just stick with Google Docs and Citadel... thanks...



[#] Tue Jun 28 2011 16:36:04 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I don't get how gmail will retry to connect when it has problems calling home, but google docs (which strikes me as an equally if not more important application) will hang "trying to contact google." and never come back.

[#] Tue Jun 28 2011 23:22:26 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Sorry M$..... Google beat you to it.

Not only that, but they're playing Google's game on Google's home turf. Microsoft *can* win market share here, but it will require going against a lot of their long-held habits. Their strategy seems to be to gain an edge by leveraging the Windows version of Office as part of the same package. I don't know whether that's actually an advantage.

Either way, moving office applications behind the glass is a good thing.
Ultimately it will accelerate the demise of the WindowsOfficePC as the be-all and end-all of end user computing. I don't see even Microsoft's version of a cloud-based office suite being as effective a lock-in tool as the desktop version has been.

Eventually someone will come up with a way to run it on your own server, which won't take much away from Microsoft or Google, but with a portion of the world running it that way, it'll keep things reasonably open. Heck, any decent hacker could probably build a front end to OpenOffice that renders through an HTML5 canvas in a week or so. (Yeah, I've thought about it, and it's out of scope for now.)

[#] Wed Jun 29 2011 09:40:35 EDT from dothebart @ Uncensored

Subject: Re:

[Reply] [ReplyQuoted] [Headers] [Print]

Di Jun 28 2011 23:22:26 EDT von IGnatius T Foobar @ Uncensored
Eventually someone will come up with a way to run it on your own server, which won't take much away from Microsoft or Google, but with a portion of the world running it that way, it'll keep things reasonably open. Heck, any decent hacker could probably build a front end to OpenOffice that renders through an HTML5 canvas in a week or so. (Yeah, I've thought about it, and it's out of scope for now.)

thats what oracle tried before letting them go into the apache software foundation; so I guess its a little more work.



[#] Wed Jun 29 2011 11:24:27 EDT from IGnatius T Foobar @ Uncensored

Subject: Re:

[Reply] [ReplyQuoted] [Headers] [Print]

From what I have read, Oracle's web office product was/is *not* based on OpenOffice.

[#] Sat Jul 02 2011 08:19:23 EDT from dothebart @ Uncensored

Subject: Re:

[Reply] [ReplyQuoted] [Headers] [Print]

there is the __vsnprintf, whith the tiny difference that it won't terminate your string if you exceed the limit. suckers.



[#] Fri Jul 01 2011 11:04:10 EDT from wizard of aahz @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Am I the only one who thinks server based software no matter how much

client side javascript it contains yields a shittier end user
experience than a native local client application?

Ford - true. But the other question is.. Do you want to support an application running on a million desktops or just one that runs in a browser?

[#] Fri Jul 01 2011 22:42:47 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

In Win32, the closest thing I can think of is a kind of 'format message' api, but it doesn't require that '...' style argument passing, so it doesn't need to be a __cdecl.

I don't know enough about Windows 3.11 to know what their analogous function might have been.



[#] Thu Jun 30 2011 17:10:25 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

The obvious question comes up: why do we need different calling convetions in the first place?
fastcall makes sense, so does inlining functions however, so you COULD do without fastcall.
stdcall and cdecl are pascal and c. I think the only reason stdcall exists is because pascal didn't think of cdecl, which is too bad.
I don't see how stdcall would be faster though. I can see cdecl generating more code as now each caller has to pop the right number off the stack pointer whereas stdcall could do it at the end of the function with RET 6 or however they do that stuff nowadays in assembly, but I don't see where there's much of a speed tradeoff.
I mean RET 6 will probably be a few cycles quicker than RET and SUB sp, 6 but really, we're talking a handful of cycles here.

[#] Sun Jul 03 2011 10:45:27 EDT from the_mgt @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Ford, I think in-browser js stuff stucks if overdone, I already wrote about my hatred for googledocs in Google Overlords.

But concerning Win7, I really do like the gui. I am all for eyecandy, if it is the right amount. In WinXP, it just looked odd and they didnt improve much of the usability from Win2k. Win7 is far better usable for the not-so-geeky users (your average Joe at work or the usual Mom) than XP was, at least it is doing some basic things right.  The new networking stuff is annoying me and they are still miles away from a real easy to understand and useable interface. Microsoft Bob was probably out on the market too early, but I think it is kind of the right direction for people who never ever used a computer before.

Btw, does anybody remember those fancy iconsets and windows themeing stuff, with the farming-style theme, the mansion background (with occasional thunder, iirc) and that swirly hippie screensafer? Was that still 3.1 or 95 already?



[#] Fri Jul 01 2011 18:13:06 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

All the Win32 function calls are __stdcall. That is, every function


the windows api (3.1, sorry that's the only I know real well, maybe they changed it in win32) had the equivalent of vsprintf. I forget what it was called, but that must have been cdecl.

[#] Fri Jul 01 2011 22:47:03 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Here it is for Win32:

http://msdn.microsoft.com/en-us/library/ms679351(v=vs.85).aspx

From the example they give, you can sorta see how they get around the calling convention such that they do not require __cdecl.



[#] Mon Jul 04 2011 17:49:08 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

there's some real value for you.
When you want to actually do things (even if it's only getting your mail and browsing and the occasional rooting of an android phone) all that shit just gets in the way.

[#] Wed Jun 29 2011 23:11:11 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Am I the only one who thinks server based software no matter how much client side javascript it contains yields a shittier end user experience than a native local client application?

Wait for it... here's the next full circle. Your PC will become a server in the cloud from which you can point your browser to to run these web applications, thus creating an even shittier environment than anybody's managed to come up with yet.

[#] Fri Jul 01 2011 18:12:15 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Ford - true. But the other question is.. Do you want to support an
application running on a million desktops or just one that runs in a
browser?

one well written piece of software running on a million desktops.
If people wrote software well there wouldn't be nearly this much trouble maintaining a lot of desktops.
And you STILL have browser versions and vendors to deal with so it's the same thing.

[#] Thu Jun 30 2011 17:36:57 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Well, it's bit-twiddling once you get around to calling conventions in teh first place, so naturally the only reason you'd care is because you want to squeeze some more performance or something.

Although there's another nasty reason that you may not know about.

All the Win32 function calls are __stdcall. That is, every function call you make to KERNEL32.dll is __stdcall (there may be exceptions, of course, but I don't know of them).

I guess they did it that way for the old Windows95 crap, and had to maintain it that way or everything would fall apart.

I'm not sure if they continue to do that for 64 bit, though. I suspect they're trying to use __cdecl instead.

[#] Fri Jul 01 2011 20:45:54 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


If it was vsprintf, it was probably part of the C runtime library, not part of the WIN16 API proper (i.e., it probably wasn't in KERNEL or USER.) Everything in crt.lib or whatever they called it would have been a cdecl.

[#] Thu Jun 30 2011 16:10:20 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I'm venting. You can safely ignore this message. It's just an example
of the kind of nonsense you get sometimes at this level of programming.
Totally fucking stupid.

http://connect.microsoft.com/VisualStudio/feedback/details/584418/different-intrinsic-functions-are-declared-with-different-calling-conventions

This problem, linked above, wasted my time. Mostly because it's a
low-level bug... the kind that takes a while to research and understand.
I just want to write code, dammit. I've got things to do, real problems
to resolve, grey hair, a swollen lip where I bit it...

In the grand scheme of things, it's stupid. This creates a problem
working with the networking library I like best only because Microsoft
and boost can't seem to agree on the calling conventions of these low
level functions. COM objects require a certain calling convention, and
trying to create a DirectDraw
filter without Microsoft's 'baseclasses'
library would lead to illegible code, so I don't really want to change
those, either. So, I had to research this problem.

At the risk of boring you, here's the bit-twiddling bullshit, where you
see how the compiler writes the code in a mild way. If you lack a life,
and really want to impress (that is, bore) your friends with obscure C++
details, read on.

Calling conventions describe how arguments are passed to functions at
the machine-code level. __fastcall means the functions get their
arguments from the CPU's registers (which should be really, really fast,
but you're limited in how many of these registers you may use). With
__cdecl, the standard calling convention used in most C/C++ projects on
VC++, the arguments are put in a stack (last argument is first) and
passed to the function, forcing the caller to clean these up ... it's

somewhat costly, but it lets you do weird things in C++ like create
variable-argument functions (like our printf() statement, if you know
about that), because the function can tell how many arguments were
given. __stdcall passes the arguments in order, and the function cleans
itself up, which tends to be faster than __cdecl, but the function can't
see how many arguments are being passed to it. Ideally, you'd probably
use __stdcall for nearly everything, and __cdecl whenever you have one
of those weird printf-like functions that take variable arguments (note:
I almost never write printf-like functions... I prefer to manage things
differently, as I think that whole method of passing in variable
arguments reads like voodo, and I prefer to write legible code). In
practice, you just nod your head and do whatever the hell the compiler
wants to do, and it usually works out.

As
you might imagine, if you tried to call a __cdecl function as if it
were a __stdcall function (or vice-versa), the arguments would get
fouled up, and you'd be really lucky if the thing didn't crash (maybe
you didn't have any arguments or something). Well, I'm creating a
DirectDraw object, which requires the __stdcall calling convention for
all of its functions. Microsoft's baseclasses (which make programming
for DirectDraw so much clearer and easier) was compiled for __stdcall,
since that's what DirectDraw objects need (and, as mentioned, it's
faster).

Well, Microsoft made a change in their SDK where certain functions have
different calling conventions than when the boost folks originally wrote
their code. Now, certain boost libraries fail to compile properly when
you use the __stdcall convention for your code (which people relatively
rarely do). The boost folks asked Microsoft
for clarification (they
don't want to make a change to their library if Microsoft is going to
make a change to theirs... no point in compounding the problem by
introducing a fix that Microsoft breaks later)... but Microsoft hasn't
clearly indicated what it's doing (either that, or they have, and boost
just hasn't released an update yet).

In the end, I will probably work around this problem by modifying
boost's code, once I grasp the best way to do this such that it doesn't
fuck up anything else that currently works.

[#] Fri Jul 01 2011 19:33:07 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Yeah, all of those happy functions that took an argument signature that look slike this:

result_type fn( argtype arg, ... );

would require the __cdecl argument passing to work properly.

[#] Wed Jul 06 2011 15:55:16 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Wait for it... here's the next full circle. Your PC will become a
server in the cloud from which you can point your browser to to run

Evidently you haven't yet heard the good news about "desktop virtualization"

And yes, there are organizations deploying this. It's a good problem to solve but it's totally the wrong solution. The pushers of virtual cloudiness are taking entire standalone fat client desktop operating systems, and aggregating them onto virtualization hosts.

Instead of deploying a proper multiuser operating system, they're taking all of the problems that come with the conventional desktop, and pushing them behind the glass.

Go to page: First ... 62 63 64 65 [66] 67 68 69 70 ... Last