E
Erik Funkenbusch
Guest
Re: Why Windows sucks
On Fri, 11 Apr 2008 11:19:41 +0100, White Spirit wrote:
> There are profound technical reasons why Windows is crap. This is just
> one of them:
>
> Let's look at the WinMain function called by every Windows program. It
> has the following prototype:
> int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
> lpCmdLine, int nCmdShow);
>
> hPrevInstance is a legacy from 16-bit days. If there was an existing
> instance of the program running, the new instance needed to know about
> it because programs running under 16-bit Windows shared the same address
> space. Consequently, the programmer had to take measures to ensure that
> the two instances didn't conflict. Most programmers simply limited the
> application to one instance.
So are you seriously suggesting that Unix doesn't have it's own legacy
cruft?
ACL's have been "it" for a long time, and because of the vast majority of
Linux users and apps that don't know how to deal with them, people still
use UGO.
Or how about tar, a system designed for legacy tape drives that has been
hacked to make it filesystem friendly over the years?
Why not search your kernel config file for the word "legacy" while you're
at it, there's plenty of hits.
> Microsoft fixed this with Windows 95
Actually, it fixed it with Windows NT.
> - at which time it was over twenty-five years behind Unix in this
> regard(*)! Windows NT was also over twenty-five years behind Unix by
> being multiuser for the first time and finally allowing multiple
> permissions for the file system. Of course, the filesystem still became
> severely fragmented after a short amount of normal use - something that
> still happens with Windows XP, over thirty years behind Unix
> filesystems.
Oh, I get it, you're one of those people that really has no clue as to the
history of Unix. You think Unix sprung fully featured from the head of
Zeus in 1973, ignoring the fact that it too evolved over time.
Here's a hint:
http://en.wikipedia.org/wiki/Unix_File_System
It really wasn't until the mid-80's when the filesystems we think of as
"unix" filesystems were created. And, given that Windows NT was released
in 1993, that makes your exagerated timeframe more like "less than 10
years".
None of that excuses NTFS for fragmenting, although there is some research
which suggests that multi-user server filesystems benefit from filesystem
fragmentation because disk access is typically fragemented by multiple
users accessing file simultaneously anyways, but that's a different
argument.
> * Perhaps claiming twenty-five years is unfair given that x86
> architecture was originally unable to offer multitasking, which was only
> truly available with 32-bit x86. The i368 was first released in 1985,
> so it's certainly fair to say that Windows 95 was ten years behind the
> techonology.
Again, NT was released in 1993, and was in development since 87. Further,
remember that Microsoft developed most of OS/2 up until the 1.3 version.
The fact of the matter is, Windows 3.x (and 95) were more successful than
than OS/2 primarily because of legacy support that you pan.
> At least it didn't take MS that long to release 64-bit
> versions of Windows. It's a shame that they're buggy, slow, have poor
> driver support and come at an exorbitant price.
64 bit versions have no price different from their 32 bit versions. What
are you talking about? And I use 64 bit vista every day, it's not buggy,
and it's faster (marginally, anyways) than the 32 bit version.
On Fri, 11 Apr 2008 11:19:41 +0100, White Spirit wrote:
> There are profound technical reasons why Windows is crap. This is just
> one of them:
>
> Let's look at the WinMain function called by every Windows program. It
> has the following prototype:
> int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
> lpCmdLine, int nCmdShow);
>
> hPrevInstance is a legacy from 16-bit days. If there was an existing
> instance of the program running, the new instance needed to know about
> it because programs running under 16-bit Windows shared the same address
> space. Consequently, the programmer had to take measures to ensure that
> the two instances didn't conflict. Most programmers simply limited the
> application to one instance.
So are you seriously suggesting that Unix doesn't have it's own legacy
cruft?
ACL's have been "it" for a long time, and because of the vast majority of
Linux users and apps that don't know how to deal with them, people still
use UGO.
Or how about tar, a system designed for legacy tape drives that has been
hacked to make it filesystem friendly over the years?
Why not search your kernel config file for the word "legacy" while you're
at it, there's plenty of hits.
> Microsoft fixed this with Windows 95
Actually, it fixed it with Windows NT.
> - at which time it was over twenty-five years behind Unix in this
> regard(*)! Windows NT was also over twenty-five years behind Unix by
> being multiuser for the first time and finally allowing multiple
> permissions for the file system. Of course, the filesystem still became
> severely fragmented after a short amount of normal use - something that
> still happens with Windows XP, over thirty years behind Unix
> filesystems.
Oh, I get it, you're one of those people that really has no clue as to the
history of Unix. You think Unix sprung fully featured from the head of
Zeus in 1973, ignoring the fact that it too evolved over time.
Here's a hint:
http://en.wikipedia.org/wiki/Unix_File_System
It really wasn't until the mid-80's when the filesystems we think of as
"unix" filesystems were created. And, given that Windows NT was released
in 1993, that makes your exagerated timeframe more like "less than 10
years".
None of that excuses NTFS for fragmenting, although there is some research
which suggests that multi-user server filesystems benefit from filesystem
fragmentation because disk access is typically fragemented by multiple
users accessing file simultaneously anyways, but that's a different
argument.
> * Perhaps claiming twenty-five years is unfair given that x86
> architecture was originally unable to offer multitasking, which was only
> truly available with 32-bit x86. The i368 was first released in 1985,
> so it's certainly fair to say that Windows 95 was ten years behind the
> techonology.
Again, NT was released in 1993, and was in development since 87. Further,
remember that Microsoft developed most of OS/2 up until the 1.3 version.
The fact of the matter is, Windows 3.x (and 95) were more successful than
than OS/2 primarily because of legacy support that you pan.
> At least it didn't take MS that long to release 64-bit
> versions of Windows. It's a shame that they're buggy, slow, have poor
> driver support and come at an exorbitant price.
64 bit versions have no price different from their 32 bit versions. What
are you talking about? And I use 64 bit vista every day, it's not buggy,
and it's faster (marginally, anyways) than the 32 bit version.