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. Continue reading →
For the adventurous, it is possible to install Windows 95 in a VM configured with SCSI storage (hard disk, CD-ROM) attached to an emulated BusLogic HBA. This works in VirtualBox, but there’s a catch—the emulated PCI BusLogic HBA must have ISA compatibility disabled. If it does not, the installation will hang:
After several minutes, there may be a blue screen complaining about inability to write to the hard disk.
Let’s start with the solution. In VirtualBox, the following needs to be run prior to starting the VM (split into two lines here for readability):
The problem is most likely caused by a bug in the BusLogic drivers shipped with Windows 95, although it might be more accurate to say that the drivers are not just clever enough. But what’s really going on? Continue reading →
Several years ago, after attempting to get a very old 286 version of Xenix running in a VM, I concluded that it was probably incompatible with any 386 and later processor. Recently I revisited this issue and examined the problem in detail.
The operating system in question is IBM Personal Computer XENIX 1.0. It’s historically significant, not so much because it was the second OS licensed by IBM from Microsoft, but rather because it was the first protected-mode OS available for a PC (the IBM PC/AT to be exact). IBM PC XENIX 1.0 was finalized around October 1984, just a few moths after the IBM PC/AT (“Salmon”) was introduced (August 1984). The PC/AT and PC XENIX 1.0 were in fact announced on the same day.
This flavor of Xenix is quite picky about the hardware it runs on. It was designed to run on the first-generation PC/AT with 20 MB fixed disk, and has trouble even on later IBM PC/AT models (different hard disks, EGA).
But the reason why IBM PC XENIX 1.0 can’t run on a 386 is different. It’s related to the way the OS manages the segment descriptor tables and it shows a lot about how it took Intel years to properly manage the x86 architecture in a forward-compatible manner. Continue reading →
A while ago I ran into an odd problem: A virtual machine running QEMM 9.0 (aka QEMM 97) would crash more or less every time it tried to read something from a floppy. No such problem was observable in any other environment. But what does QEMM have to do with reading from a floppy, anyway? Quite a lot.
It is well known that EMM386, QEMM, and their cousins provide upper memory (UMBs) and optionally emulate expanded memory (EMS) through the 386 paging unit. Memory above 1MB, normally not accessible from real-mode applications, is allocated and mapped below the 1MB boundary using paging. In the case of UMBs, memory pages are more or less statically “moved” (remapped) to addresses between 640KB and 1MB in order to fill gaps or even overlay unused ROMs. In the case of expanded memory, pages are swapped in an out of the page frame as requested through the EMS services.
In either case, 16:16 segmented memory addresses used by DOS and BIOS do not necessarily correspond to physical addresses, and that poses a problem for software which needs to operate with physical addresses, such as those used for DMA (direct memory access). Continue reading →
Recently I had a need to test the behavior of floating-point exceptions (FPEs) in environments where traditional FPE reporting is used.
To briefly recap, in the original PC equipped with an 8088/8087 pair, floating-point exceptions, which are generally asynchronous events, were reported through an NMI. In the PC/AT (80286/80287), IRQ 13 was used instead, but the BIOS interrupt handler executed INT 02 for compatibility with the PC. This method stuck around in AT compatibles.
Using Open Watcom C/C++, I verified that FPE delivery works as expected in a 32-bit extended DOS executable using the default DOS/4GW extender. The run-time library installs a default handler on interrupt vector 2 and unless overridden by the user, a floating-point exception terminates the program.
The exact same executable behaved differently with the CauseWay and DOS/32A extenders—it was as if the exception never happened. The CauseWay and DOS/32A extenders are supposed to be compatible with DOS/4GW, but clearly there are differences… but where exactly? Continue reading →
While working on an unrelated problem, I noticed a strange behavior of one of my OS/2 VMs running OS/2 Warp 4.52. To cut a long story short, if an unhandled floating-point exception occurred in a DOS window (VDM, or Virtual DOS Machine) while executing real-mode code, the DOS box would crash because it would try to execute an invalid instruction. The IRQ13 (INT 75h) handler provided by the BIOS would run, and then execute an INT 02h instruction (for compatibility with old PCs). But interrupt vector 2 pointed to a place in the middle of the VDM’s conventional memory that wasn’t even allocated. It should be pointing to the BIOS and execute harmless code.
I quickly realized that only one of several very similarly configured VMs did this. At first I suspected a problem with the way the DOS box in the troublesome VM was set up, but that wasn’t the case. The OS version wasn’t it either. What’s more, the VDM was simply reflecting the contents of physical memory (the former real mode IVT at physical address zero)… and the IVT was modified very early in the boot, before even showing the OS/2 boot logo or boot menu.
Finally realization dawned: The OS/2 kernel debugger was doing this, and that’s why most of my VMs didn’t have the problem. But why would this happen at all? Continue reading →
One of the OS/2 Museum’s vintage boards is a genuine Made in U.S.A. Alaris Cougar. These boards were produced by IBM for Alaris and are a bit unusual: There’s a small IBM DLC3 processor in plastic package soldered on board, and there’s also a Socket 2 which accepts regular 5-Volt 486DX/SX processors or a Pentium OverDrive. If a standard ceramic-packaged 486 or OverDrive processor is installed, the on-board DLC3 is disabled.
The IBM DLC3, sometimes designated as BL3 and better known as Blue Lightning, has an aluminum heatsink glued on but requires no fan. After 20 years, the information whether it’s the 75MHz or 100 MHz variant has been lost, but the board is stable when the processor runs at 100 MHz (3 x 33 MHz). And incidentally, the OPTi chipset and notably the Adaptec VL-bus IDE controller are quite good performers, often doing better than newer PCI-based 486 systems.
The Blue Lightning CPU is an interesting beast. There is not a whole lot of information about what the processor really is, but it can be pieced together from various scraps of information. Around 1990, IBM needed low-power 32-bit processors with good performance for its portable systems, but no one offered such CPUs yet. IBM licensed the 386SX core from Intel and turned it into the IBM 386SLC processor (SLC reportedly stood for “Super Little Chip”). Continue reading →
While comparing the behavior of various versions of old Microsoft C compilers, I tried building a trivial hello-world type program with CL.EXE from Microsoft C/C++ 7.0 (March 1992) running on top of a 32-bit Windows Server 2003. This seemingly trivial task failed:
Command line error D2018 : cannot create linker response file
A quick search revealed that rather predictably, I wasn’t the first person hittingthisproblem. And as usual, there were only questions, not answers.
MS C/C++ 7.0 was Microsoft’s first compiler with C++ support included, but that’s not what made it special. It was Microsoft’s first DOS/Windows 3.x compiler which required a 386 host and used a 32-bit DOS extender.
Looking at the C/C++ 7.0 executables a bit closer, it’s apparent that these are in fact 32-bit PE modules, with a DOS extender in their respective DOS stub. The catch is that due to their age (released more than a year before NT 3.1), the PE modules are different enough that no NT release can use them. Hence the compiler must be run through NTVDM as if it were a normal DOS executable.
Now, given that when NT 3.1 was released (1993), Microsoft C/C++ 7.0 was still a current product, one would expect that the compiler would run under NT 3.1… and indeed it did! MS C/C++ 7.0 also works under NT 3.50 (1994), but it no longer functions under NT 3.51 (1995). The compiler fails with the above D2018 error message in NT 3.51 and all subsequent releases. At that point, Visual C++ 1.0/1.5 had taken over and C/C++ 7.0 was more or less obsolete, so perhaps the problem slipped under the radar, but why did the compiler stop working at all? What changed? Continue reading →
Upon reader request, the OS/2 Museum is publishing the source code to the NT video miniportdriver for VirtualBox. To recap, this is a NT video miniport which allows 32-bit NT versions to use high-resolution graphics modes in a VirtualBox VM. The miniport is unique(?) in that a single binary supports every released version from NT 3.1 through Windows 7 (Windows 8 no longer supports the same video miniport model).
The source code now lives in a private Mercurial repository. The credentials are ‘guest’/’guest’. The complete source code can be downloaded as a zip/gzip/bz2 archive from the above page. A floppy image with a driver binary produced from this source is also available for download.
The source code is published under the very liberal MIT license. Anyone can more or less use it as they see fit. However, if you fork it, please do not ask for help—you’re on your own. Continue reading →
The OS/2 Museum just posted a three-volume set of draft Windows Presentation Manager reference documentation. This refers to the OS/2 Presentation Manager GUI but highlights the story Microsoft pushed in 1987: Windows and OS/2 both used the same graphical user interface called “Windows Presentation Manager”.
By the time OS/2 1.1 was released, the “Windows” part was dropped and the GUI was called simply Presentation Manager. And conversely Windows dropped the “Presentation Manager” moniker again and went back to being simply Windows. Continue reading →