A Few Decades Late Book Reviews
Unauthorized Windows 95 Developer’s Resource Kit, by Andrew Schulman
IDG Books, November 1994; 593 pages, ISBN 1-56884-305-4; $39.99
A testimony to the incredible level of hype surrounding Microsoft’s “Chicago”, Unauthorized Windows 95 was published nearly a year before Windows 95 was available for purchase (October 1994 vs. August 1995). The book was written based on preview builds of Chicago including the official Windows 95 Beta-1 (May 1994). Although Microsoft made minor changes after that point, everything Mr. Schulman wrote about the architecture of Windows 95 applies to the released product.
The author appears to have had two major sources of motivation: taking an in-depth look at the inner workings of the OS that was likely to rule the world for years, and debunking various claims Microsoft made about the architecture and technology of Chicago.
The book starts with a look at the PC software industry and the dominant role of Microsoft, underscoring the importance of Windows 95 and the need to analyze it. Mr. Schulman dismisses both NT and OS/2 as unworthy of study due to their limited market reach.
The bulk of the book examines the question of what the real architecture of Windows 95 is, and exactly what role DOS and 16-bit code plays or doesn’t play. In the first few chapters, Mr. Schulman shows that yes, there’s still good old DOS in Windows 95, and it is used even for Win32 applications.
Chapter 6 demonstrates that Windows consists of two architecturally quite separate components: The actual Windows GUI and the underlying OS (VMM) with a built-in DPMI DOS extender. The DOS extender can be used to start arbitrary programs, and conversely, the GUI can be run under DOS extenders other than the one built into Windows.
Throughout the book, but especially in Chapter 8, the author shows how the Windows 95 OS is very far from being revolutionary but rather an incremental step in the Windows 3.0 Enhanced mode/Windows 3.1 Enhanced mode/Windows for Workgroups 3.11 line. This is presented as a good thing, using proven technology rather than inventing something new from scratch.
Because of the continuous evolution, a good deal of the book also applies to Windows 3.x, with a special emphasis on Windows for Workgroups 3.11. The author shows how the overall architecture did not change much since Windows 3.0 Enhanced mode, but over time Windows implemented more and more functionality in protected mode—notably 32-bit disk access (32BDA) in Windows 3.1 and then 32-bit file access (32BFA) in Windows for Workgroups 3.11. Examples demonstrate that even though Windows (and DOS) applications generate DOS INT 21h calls, a vast majority of those calls never reaches 16-bit real-mode DOS code and is handled by 32-bit protected-mode VxDs instead.
In Chapter 9 (page 298), Mr. Schulman draws important parallels between the Windows VMM and the original IBM VM/370, showing both the conceptual similarities and differences (such as the fact that the Windows VMM cannot be nested). This chapter is devoted to the virtual 8086 mode of 386 and later CPUs, and demonstrates how Windows is in control even when executing DOS code.
Chapter 11 is a key part of the book and examines the highly complex relationship between Windows and DOS. Some DOS calls are entirely emulated by VxDs, some calls are passed down but real-mode code calls back into Windows (possibly several times), and only a relatively small number of calls is processed by pure real-mode code. This goes for both DOS and BIOS services.
The final chapters explore the use of 16-bit code in the Windows GUI itself, including numerous 16-bit calls made on behalf of Win32 applications. Thunking is described in detail, as is the infamous Win16Mutex (formerly known as Win16Lock). The claim that Windows 95 is a 32-bit operating system is shown to be very much an exaggeration.
Occasionally, there are minor errors in the book. For example, Mr. Schulman often quite appropriately refers to Windows/386 as the ultimate progenitor of Chicago, but seems to be unaware that the product was first released in the Fall of 1987 and not in 1988. That said, he is hardly alone in making that mistake.
Sometimes Mr. Schulman’s insatiable curiosity unexpectedly takes a break. For example in a sidebar on page 221, it is mentioned that in Windows for Workgroups 3.11 with 32-bit file access, the performance improvement is reported to differ significantly between IDE and SCSI systems. The author only examines Windows running on an IDE system and makes no attempt to explain the difference in behavior.
In one instance (page 295) the author oddly claims that Windows 95’s DOS support is just like Windows NT VDM or OS/2 MVDM, even though elsewhere he spends considerable amount of ink showing the significant differences.
On the whole, Unauthorized Windows 95 consistently takes a scientific approach to analyzing Windows 95, first empirically establishing facts and then drawing conclusions. It openly shows disdain for slick marketing talk which glosses over facts, and instead relies upon proof by experiment. It is an excellent complement to more high-level books such as Inside Windows 95, which was published even earlier and which is in fact mentioned several times (usually in order to correct some gross oversimplification). Mr. Schulman clearly enjoys refuting various sweeping claims about the Windows 95 architecture made by or on behalf of Microsoft and published in e.g the above-mentioned Inside Windows 95 or the Microsoft Systems Journal.
After Unauthorized Windows 95 was published, Microsoft made numerous minor changed to Windows 95, which affected several utilities that came with the book. In almost all cases, updated versions of the utilities are available. However, the changes did not invalidate any of the key points that Mr. Schulman had made.
Finally, it should be noted that there were two editions of Unauthorized Windows 95. There was Unauthorized Windows 95: A Developer’s Guide to Exploring the Foundations of Windows “Chicago” and Unauthorized Windows 95: Developer’s Resource Kit (reviewed here). The book content was the same, but the latter additionally included The Programmer’s Shop Smash Hits for Programmers CD-ROM, a disc with a number of trial versions of developer tools.
Ah, I still remember how MS added XOR obfuscation to PIDs etc in Win9x thanks to the book.
Is the CD worth getting? I wanted to buy this book, but only copies without the CD were available at BetterWorldBooks. Can you recommend any other site to buy used books, which won’t charge me an arm and a leg for shipping oversees?
I got the book on amazon.de. I may have been lucky that both the CD and the floppy were in there, more often than not the media is missing from used books.
As to whether the CD is worth getting, I’d say probably not. There are a few article reprints from DDJ and CUJ, some demos and trial version of programming and productivity tools. But the trial versions are locked and require calling a phone number that probably went out of service 20 years ago. Not sure if anyone feels like cracking their encryption scheme 🙂
The companion to this book is Matt Pietrek’s Windows 95 System Programming Secrets which covers how Win95 works in better detail.
Inside Windows 95 seems to have been written so early in the process that some sections seem to expect that the early MS plan to create a 32-bit protected mode DOS as the underlayment would have been followed through. The modified 16-bit DOS included permitted usage of existing DOS games and drivers. Anyone will to toss those aside was a prime candidate for switching to Windows NT. Other plans got changed too like the OLE focused shell. Schulman spends too much time calling out lies even as MS was noting the scaling back of Win95 ambitions.
OT: can a category list be put in the sidebar? it’d make browsing (and binging) easier
I had the other book, and thought it was really cool at the time how you could take a compact memory model program and run it in protected mode with dosx.exe ..
It was such a shame that people held onto their DPMI stuff so tight, but the funniest thing is that Windows ended up being the cheapest DPMI extender of them all as it was bundled with so much hardware, or only $99 a seat! A steal compared to other offerings.
It’s so interesting that Windows came with a very decent DPMI server but it was buried so deep that it couldn’t be used standalone (even if technically it would have been easy). I take it to mean that Microsoft didn’t want to make turn it into an actual market.
Anyway, a DPMI server is not the same thing as a DOS extender… which is why Rational/PharLap/etc. still had something to sell.
BTW I think QDPMI bundled with QEMM was actually cheaper 🙂 Same goes for 386MAX.
@Michal Necasek: I think MS created MSDPMI for C/C++ 7.0 beta, before it got replaced by 386MAX in the final version.
Is this better?
Inside Windows 95 is only slightly older than Unauthorized Windows 95. Yes, it had clearly been written early, but all it does is mention that plans weren’t finalized and DOS 7.0 might or might not be released standalone. Similarly it mentions that networking may or may not be included. Not too different from the older Inside Windows NT which was also published about a year before the product. What’s funny about Inside Windows 95 is that it makes grand pronouncements (all-new, pure 32-bit, blah blah) but when one reads the actual text, it talks quite a bit about what’s 16-bit and what’s 32-bit, and what’s new and what’s old.
Anyway, there was 32-bit protected-mode “DOS” underneath (aka VMM), and Schulman clearly showed that. He also greatly appreciated the backwards compatibility provided by Windows 95 (but not NT).
The talk of OLE shell in Inside Windows 95 had me all confused, since it seemed to describe more or less the shell that was released with Windows 95. I’m wondering if “COM” really should have been used instead of “OLE”.
Pietrek’s book is great as a general-purpose backgrounder for Win32 programmers, but Inside Windows 95 has its place as a less technical book with interesting insider insights. It definitely has a historical value. I’ll probably write a review in a few weeks, then we can discuss it more 🙂
MSDPMI is described in detail in Unauthorized Windows 95, pages 173-176. So yeah.
Also Microsoft didn’t so much create MSDPMI for C/C++ 7.0 as ripped it out of Windows 3.x and packaged it as a stand-alone component.
The lack of full OLE in the Win95 shell is best described in Ray Valdes’s article in Dr. Dobbs Developer Update of July 1994. See http://www.drdobbs.com/a-milestone-on-the-road-to-chicago/184409449 in the section “The Ole Illusion.”
A full OLE2 Win95 shell would have resembled the later versions of shell with Internet Explorer integration except every OLE application could have been used instead of just IE. Viewers could have been just a pane in Windows Explorer instead of separate applications. Going the other way, the desktop could have been embedded into an application meaning that it would be possible to do everything related to the system without ever leaving WordPerfect. Some of the ideas suggested for usage of an OLE shell were perhaps impractical.
@Michal Necasek There’s an easy reason it was OLE and not COM, it wasn’t called COM yet. COM really is a subset of OLE2, using the object model without any of the linking and embedding. It was used like in the shell for a while before the object model was pulled out as COM.
Thanks for this explanation, it would not have occurred to me. Now it makes a lot more sense. Inside Windows 95 actually has an entry for COM in the glossary, but the term is almost never used in the text.
The strange part is that shell32.dll kept checking for the LoadWithoutCOM registry value for years and years (maybe it still does?) even though only 95 would actually use fake COM (without loading ole32.dll).
SHAlloc still works to this day but any 3rd-party shell extension written to the undocumented(?) 95 fake COM spec broke at some point because the drag&drop functions moved to shunimpl.dll.
See also: https://devblogs.microsoft.com/oldnewthing/20040705-00/?p=102299
I did some more useless digging. I don’t have the 95 SDK but a Chicago beta SDK (and one for NT4) and there is surprisingly little information about shell extensions vs fake-COM.
The only documented function that hints to this even being a thing is SHGetMalloc in shlobj.h. In that same header you will find this surprising comment: “// Caller should call SHFree to free the returned pidl”. SHAlloc and SHFree did not get documented until after the DOJ trial so this is clearly a slip up. The CabView sample in the NT4 SDK also slips up and gives a declaration for SHFree in CABOBJ.H.
Post DOJ; SHAlloc, SHFree, SHDoDragDrop and SHCoCreateInstance were documented and still work today. SHRegisterDragDrop, SHFlushClipboard, SHFreeUnusedLibraries and +++ were never documented and stopped working in Vista (why they broke old apps instead of forwarding to ole32, I will never know).
The lack of documentation for these functions means no 3rd-party Explorer shells could play the same COM game and would be forced to load ole32.
2000 applies the LoadWithoutCOM registry value to some of its interfaces for unknown reasons (ole32 is always loaded so it is pointless) and Windows 10 still does so today.