11.20.09
Why Windows Seems Like a Dead End
Summary: Yesterday’s USENET post from Richard Rasker quoted verbatim
Subject: Windows 7’s dirty secrets revealed
From: Richard Rasker <spamtrap@linetec.nl> (Linetec)
Date: Thursday 19 Nov 2009 18:07:34
Groups: comp.os.linux.advocacyAn interesting look under the hood of Windows -- and in particular Vista 7: http://www.theregister.co.uk/2009/11/18/windows_7_heart/ It would appear that quite a bit of criticism on the technical implementation of Windows and the knowledge of Microsoft's programmers actually isn't all that far off the mark: - Criticism: Windows is such a convoluted mess that even Microsoft doesn't understand it any more: "the operating system is full of internal dependencies, and as Russinovich admitted: "We don't really understand those dependencies". Engineers have added features to low-level APIs that assume the presence of dynamic link libraries (DLLs) that belong with higher level APIs, and when you try to extract just those low-level components, they break." The upside here is of course that they're actually working on improving things in this respect, even though I think that the *nix way of dealing with libraries is far superior. - Criticism: Windows depends heavily on dirty hacks to offer at least the illusion of speed: "Microsoft has been in the habit of combining unrelated APIs into the same DLL for performance reasons." and "Microsoft also picked out 300 common user actions, such as clicking the Start menu or opening Control Panel, and gave them intensive optimisation to improve perceived performance." - Criticism: Windows encourages sloppy, messy programming: "How about reliability? This was fascinating. Microsoft observed that 15 per cent of all user-mode crashes and 30 per cent of shutdown crashes were caused by heap corruption: applications that try to access freed memory, or memory beyond what is allocated. Its solution was a feature called the Fault Tolerant Heap (FTH). ... "The user gets better reliability at the expense of performance, which suffers by up to 15 per cent or so, while buggy applications work better than you would expect." I really don't think that this is a good idea. If there's one way to make a computer behave less predictable and perhaps make programmers lazy and sloppy, it's to implement fault tolerance for software bugs. Richard Rasker
David Gerard said,
November 20, 2009 at 3:32 pm
This sort of thing is why I’m amazed Wine works so well. And why I’m not surprised Alexandre Julliard is *incredibly* fussy about what gets into Wine.
Natasiel Reply:
November 20th, 2009 at 5:07 pm
This remember me a post on Slashdot, and I have read it somewhere else too. As a sample example:
Civilisation II has been released on Windows 3.11 then somewhere in the code, the application freed some memory. Due to a bug in Windows 3.11, the memory was not properly freed and Civilisation had to access this “not properly freed memory” to read some data. This bug has been fixed in Windows 95, but the proper fix broke Civilisation II. So, binary speaking, to keep backward compatibility, Windows 95 had a hack to verify if the calling application was civ2.exe before freeing memory.
This is but one known of the many “features” inside the hidden Windows code. Wine has a better win32 API implementation than any Windows. Otherwordly, to be 100% compatible, Wine has to implement bugs.
-Dominic
David Gerard Reply:
November 20th, 2009 at 5:19 pm
Yeah, that example was from Raymond Chen’s blog. Which everyone should read, because it’s a shining example of what ensuring backward compatibility means in the real world: http://blogs.msdn.com/oldnewthing/ Fantastic stuff.
The problem is that if you buy Windows 95 and your old programs don’t work, you’re not going to blame the old program – you’re going to blame the new OS. So they have to do stuff like that. That’s the pain of selling an OS for proprietary software. With free software, people are used to recompiling – GNU/Linux has extremely bad backwards binary compatibility, because it doesn’t need it.
Wine is so far resisting app-specific hacks (Crossover has a few, but the winehq tree doesn’t), but yeah, eventually it’ll have to implement them. At the moment it confines itself to accurately reproducing more general Windows bugs
Test-driven development, no new features without a conformance test, etc.
Roy Schestowitz Reply:
November 20th, 2009 at 6:43 pm
That’s also why Microsoft can’t quite depart from x86.
David Gerard Reply:
November 20th, 2009 at 7:02 pm
Well, yeah. Backwards compatibility is the only reason to keep buying this stuff. Let’s duplicate Win32 on ARM! Uh, what? HORRIBLE programming interface.
Yuhong Bao Reply:
November 21st, 2009 at 12:49 am
Get The Old New Thing book too. Among other things, it has an example where a journalist wrote a bad review on Win95. MS ended up calling in the journalist to investigate the bad review, and it turned that the journalist installed it via XCOPY, and not only that was unsupported, it caused a third-party control panel to hit an untested error path and crash due to a double-free. Also look at the comments on the Louderback review of Windows 7. It was obvious from the review itself that the problem that caused the bad review was the lack of drivers.
Yuhong Bao Reply:
November 21st, 2009 at 12:52 am
Yea, in the Alpha NT days DEC had FX!32 and MS was going to create it’s own solution to run x86 Win32 apps too. BTW, guess why a solution to run x86 DOS and Win16 apps came with non-x86 NT but not x86 Win32 apps?
Roy Schestowitz Reply:
November 21st, 2009 at 5:08 am
Vista architecture. See? That’s why it’s called Vista 7.
Yuhong Bao Reply:
November 21st, 2009 at 4:18 pm
“Vista architecture. See? That’s why it’s called Vista 7. ”
Yes I know, but not the problem. MS do try to ensure driver backward compatiblity, XP and Vista drivers often do work in 7. It was mentioned in the comments, and by DaemonFC on IRC too when I was discussing why my old Palm device did not work on Vista.
Roy Schestowitz Reply:
November 21st, 2009 at 4:23 pm
So that’s the “post-Vista” era of Windows; still, leaving a trail of almost-obsolete binaries.
Yuhong Bao Reply:
November 21st, 2009 at 4:34 pm
What helped, I think, was the five-year gap between XP and Vista.
Roy Schestowitz Reply:
November 21st, 2009 at 5:02 pm
It’s not about duration.