Windows 7's dirty secrets revealed
Hidden work arounds and complex dependencies
PDC While chief technology officer Ray Ozzie was away in the clouds at Microsoft's Professional Developer Conference, technical fellow Mark Russinovich got down and dirty with the true heart of Windows - the kernel.
He presented a two-hour session on changes made to the kernel used by both Windows 7 and Server 2008 R2, shedding light on some confusing issues - like the Windows version number, which he said "means nothing at all". Windows 7 is version 6.1, not because it is a minor release, but for compatibility with applications that check the major number and would not run if it said 7.
Another of his themes was MinWin, a lightweight version of Windows whose purpose has sparked speculation. MinWin exists, he said, and contains the minimum necessary to boot and access the network: kernel, file system driver, device drivers, services and TCP/IP stack. It amounts to around 150 binaries, and requires 25MB disk space and 40MB RAM.
MinWin is handy for setup and system recovery, but its real purpose is to introduce what he calls "architectural layering" to Windows. Microsoft needs small footprint versions of Windows, both for embedded use and for the GUI-free Server Core edition. The problem is that 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. MinWin is a first step in making Windows layered, maintainable and understandable.
A fresh DLL hell
In order to make MinWin, Microsoft had to split existing DLLs that had these unwanted dependencies, such as Kernel32.dll. The team created KernelBase.dll, which has only the base functions MinWin requires. Applications expect to find these functions in Kernel32, but they are simply forwarded to KernelBase. Kernel32 itself is outside MinWin.
A related problem is that Microsoft has been in the habit of combining unrelated APIs into the same DLL for performance reasons. Its solution is to create virtual DLLs, which are the API sets programmers call, but which are implemented in logical DLLs that might combine several virtual ones. A schema file that is mapped into every process tells Windows where the real API resides.
Russinovich went on to explain why Windows 7 is faster. Memory footprint was reduced by up to 30 per cent by reviewing excessive memory allocations, and by refactoring the Desktop Window Manager (DWM) to avoid a second copy of every Window being held in memory. The registry is no longer accessed as a memory-mapped file, reverting a change made for Windows XP. Processes that consume large amounts of memory are more aggressively pruned. 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.
Next page: Reliability?
"the worst software I've come across tends to be in-house applications that were thrown together by some office junior while on work placement five years ago, that inexplicably become vital to the operation of the company (although not critical enough to employ anyone to code it properly)."
Very good point, sir. It's true that MS have probably cocked up by trying so hard to maintain backward compatibility over the years, but a chunk of the blame must be laid at the corporate IT world, who allow bag o'shite apps to slowly become mission critical, when originally they were coded to be stop-gap measures. With all of the Freeform DYnamics stuff on the reg in the last couple of weeks about IT Governance fresh in my mind, you've highlighted a problem there that doesn't get talked about often enough: IT departments should have the balls to tell the business to take a running jump when the business comes knocking to demand a technical fix to a failure of management.
What's that? Your MS Access-based app runs poorly, and you absolutely cannot do without it? Stop using it, and go find a proper app that runs on a modern OS and migrate now. Don't postpone another six months, or to the start of the next financial year, 'cos the situation will just be worse then.
"If this application breaks because of a new operating system, guess who gets the blame? The office junior? No, Microsoft." It should be the director of the department responsible.
<As you deserve one.
Interdependencies not well understood.
Well let's have all of it in 1 single big fat DLL ... problemo solved.
>>Like NT4 that much? Do you? Had to work on it much? Stable huh? When's the last time you booted an NT4 server that wasn't a fresh build and it didn't say "At least one service failed to run at startup"?
Its been about a month. And before that it was about 15 months. Why? Because my NT servers are booted less than once per year. They are stable, why would a DLL go missing? Why would I want to use a USB Drive? Ever consider that allowing USB drives is WHY your machines are unstable? Convenience is NOT the number one priority.