Windows 3.x VDDVGA

While working on my Windows 3.x display driver, I ran into a vexing problem. In Windows 3.1 running in Enhanced 386 mode, I could start a DOS session and switch it to a window. But an attempt to set a mode in the DOS window (e.g. MODE CO80) would destroy the Windows desktop, preventing further drawing from happening properly. It was possible to recover by using Alt+Enter to switch the DOS window to full screen again and then returning to the desktop, but obviously that wasn’t going to cut it.

Oddly enough, this problem did not exist in Windows 3.0. And in fact it also didn’t exist in Windows 3.1 if I used the Windows 3.0 compatible VDDVGA30.386 VxD shipped with Windows 3.1 (plus the corresponding VGA30.3GR grabber).

There was clearly some difference between the VGA VDD (Virtual Display Driver) in Windows 3.0 and 3.1. The downside of the VDD is that its operation is not particularly well explained in the Windows DDK documentation. The upside is that the source code of VDDVGA.386 (plus several other VDD variants) was shipped with the Windows 3.1 DDK.

First I tried to find out what was even happening. Comparing bad/good VGA register state, I soon enough discovered that the sequencer registers contents changed, switching from chained to planar mode. This would not matter if the driver used the linear framebuffer to access video memory, but for good reasons it uses banking and accesses video memory through the A0000h aperture.

But how could that even happen? The VDD is meant to virtualize VGA registers and not let DOS applications touch the real hardware. Something had to be very wrong.

I also suspected that the problem was likely caused by my driver doing something wrong, or perhaps not doing something necessary to correctly set up the VDD. The Video 7 sample driver that I based my code on was intended to work with its own custom VDD, not with VDDVGA; judging from the source code in the Windows 3.1 DDK, I suspect that V7VDD.386 was effectively forked from the Windows 3.0 VGAVDD and at most slightly updated for Windows 3.1. That might also explain why my driver worked with VDDVGA30.386 but not with the newer VDDVGA for Windows 3.1 (VDDVGA.386 is normally built into WIN386.EXE and does not exist as a separate file, although a standalone VDDVGA.386 can be used).

After poking through the VDDVGA source code for a while, I realized that it almost certainly wasn’t register access from a DOS session leaking through. It was the VDD itself!

And I also found that the missing link was a small section of code that was explained as “Call VDD to specify latch address” in the Windows 3.1 VGA driver. It is protected-mode service entry point 0Ch in VGAVDD, and it’s called VDDsetaddresses in the VGA display driver (VGA.ASM) but DspDrvr_Addresses in the VDD (VMDAVGA.INC).

The Windows 3.1 DDK does not appear to document the DspDrvr_Addresses function. Although due to the inconsistent naming, it’s difficult to be entirely certain.

At the same time, I tried to approach the problem from a different angle. The Windows 3.1 DDK does document a set of INT 2Fh calls, some of them with promising descriptions, such as “Save Video Register State (Interrupt 2Fh Function 4005h)” and the corresponding “Restore Video Register State (Interrupt 2Fh Function 4006h)”.

But there I hit the opposite problem. Even though the DDK documents those functions, and the VGA display driver implements 4005h/4006h callbacks, I could not find any code in the VDD calling those functions! And the debugger showed no sign that anyone else is calling them, either.

Note: It is possible that the save/restore registers INT 2Fh callbacks were specified for OS/2. Indeed the OS/2 2.1 DDK defines INT2F_SYSSAVEREGS (0x4005) and INT2F_SYSRESTOREREGS (0x4006) in the virtual video device driver source code… but again there is no sign of those being used in the code.

There is also “Enable VM-Assisted Save/Restore (Interrupt 2Fh Function 4000h)” and “Disable VM-Assisted Save/Restore (Interrupt 2Fh Function 4007h)”. The VGA and Video 7 call these functions and name them STOP_IO_TRAP and START_IO_TRAP. And VGAVDD.386 really implements these in VDD_Int_2F (the INT 2Fh intercept in VGAVDD.386). Interestingly, STOP_IO_TRAP corresponds to “VM knows how to restore the screen” logic, and START_IO_TRAP naturally corresponds to “VM doesn’t know how to restore the screen”.

But how does that make any sense? Why would the hardware access from the Windows display driver ever be trapped?

Why Oh Why?

Although I could not find any explanation in the DDK documentation, eventually I realized what the reason had to be: Windows/386 (aka Win386).

Windows/386 was essentially an add-on for Windows 2.x, adding the ability to pre-emptively multitask DOS sessions. Only, in the Windows 2.x days, Windows itself was effectively one of those DOS sessions.

That is, Windows 2.x display drivers had (almost) no clue about Win386. That only came with Windows 3.0. Therefore the Win386 VDD had to manage Windows itself as just another DOS session, save and restore all EGA/VGA registers, and also manage video memory contents. In fact in the “normal” Windows 2.x Adaptation Guide, there is almost no mention of Win386 (there was a separate development kit for Win386 which covered virtual device drivers).

I/O trapping was especially important on EGA adapters which did not have readable registers. As a consequence, it was impossible to read the current EGA hardware state; the only way was to shadow the state of EGA registers as they were written.

Windows 2.x display drivers did implement one interesting piece of functionality, switching Windows to/from the background. This was not at all intended for Win386 but rather for OS/2 (that is, OS/2 1.x, at least initially). The switching was implemented in the display driver by hooking INT 2Fh and watching for focus switch notifications.

In Windows 3.0, Enhanced 386 mode implemented the previously OS/2-only INT 2Fh callbacks that indicated switching out of and back to the Windows desktop. On the way out, the display driver could restore some kind of sane VGA state, and on the way back to the desktop it could re-establish the necessary hardware register state. In addition, the display driver could force a redraw of the entire screen, which avoided the need to save any video memory (which was good, because the video memory could be relatively big).

Unfortunately I don’t have the Windows 3.0 DDK (and no one else seems to, either) so I can’t look at the 3.0 VDDVGA source code. But it’s clear that whereas Windows 2.x display drivers knew very little about Win386, Windows 3.0 drivers typically have some level of cooperation with the VDD through the INT 2Fh interface.

Windows 3.1 VDDs

In Windows 3.1, Microsoft added a whole new level of complexity to VDDs. Namely, video memory can be paged. Microsoft article KB80901 states the following:

In Windows version 3.1, the standard virtual display device (VDD) for VGA is modified to demand page video memory. Thus, you can run graphical MS-DOS-based applications in a window or in the background on VGA systems. This VDD must track video memory usage, so it is not compatible with any of the super VGA display drivers that must access more than 256 kilobytes (K) of video memory. To run these display drivers, a user must use either the VDD provided by the display adapter manufacturer or the VDDVGA30.386, which is included with Windows version 3.1. Demand paging of video memory may break TSRs that worked with Windows version 3.0. The difference is that the VDD virtualizes access to video memory; in Windows version 3.0, the display driver had full reign over memory.

I am not entirely certain why Microsoft did that. It seems to add a lot of complexity in return for not a lot.

The Windows 3.1 VDDVGA.386 introduced a new concept of ‘CRTC VM’ and ‘MemC VM’, that is, the VM that owns the graphics card’s CRT controller (what is displayed on the screen) and the VM that owns the graphics card’s memory controller, i.e. what is read from and written to video memory.

In the typical case, the CRTC VM is also the MemC VM; that can be the Windows desktop (aka System VM) or a full-screen DOS box. Things get interesting for windowed DOS boxes. The desktop remains the CRTC owner because the desktop is what needs to be displayed. But a DOS box can temporarily become a MemC VM, directly accessing video memory.

Needless to say, this gets quite complicated. VDDVGA.386 needs to save the old MemC VM state, merge the new MemC VM state with it and update the hardware registers, let the DOS box execute, and then restore the original MemC VM state before the System VM can do any drawing to the Windows desktop.

As far as I can tell, of the drivers shipped with Windows 3.1 only VDDVGA.386 has this complexity. None of the other VDDs, including the Video 7 specific V7VDD.386, implement this logic. As mentioned above, I strongly suspect that the Video 7 VDD in the Windows 3.1 DDK (source code in VDDV7VGA directory) is actually very close to the Windows 3.0 VDDVGA.386, and thus to the Windows 3.1 VDDVGA30.386.

It’s a Tie

Needless to say, the register saving/restoring logic in VDDVGA.386 is quite fiddly and difficult to debug. In the end I have not been able to find out why register changes “leak through” to the System VM (i.e. Windows desktop). I found out where in the code that happens, but not why, or how to prevent it.

What I did find is that the DspDrvr_Addresses function does not at all do what the comments suggest. The function is supposedly used “to specify latch address” in video memory. Closer examination of the Windows 3.1 VGA display driver showed that while it does define a byte for the latches, and sends its address to the VDD, the display driver does nothing with that byte.

But even more interesting is that VDDVGA.386 does not use the latch byte either. Instead, VDDVGA.386 assumes that the latch byte lives somewhere very close to the end of the video memory used by the display driver, and expects that any following pages can be used by the VDD. (That logic likely comes from the Windows 2.x EGA/VGA drivers.)

A corollary is that passing 0FFFFh as the latch byte address to the VDD (something that SVGA256.DRV does) tells VDDVGA.386 that there is no video memory to share. In that situation, VDDVGA.386 does not try any hair-raising schemes to modify the VGA register state behind the display driver’s back.

It’s not perfect either. The system does survive MODE CO80 in a windowed DOS box without trouble, but starting (in a window) a DOS application which uses multiple pages of video memory triggers an interesting warning:

A disturbing but seemingly harmless warning

The warning appears to be harmless. Once it’s dismissed, the application works fine. The warning also only pops up the first time the application is started (in the same windowed DOS box). It’s not ideal, but it’s something I can live with.

I consider this fighting VDDVGA.386 to a draw. I am not impressed with the Windows 3.1 DDK documentation—it omits certain things while documenting other things that appear to be fictional. That said, the actual DDK source code saves the day, at least in the video area, because it is possible to see more or less all of the code involved.

And the Windows 3.0 DDK would be really nice to have.

This entry was posted in 386, Development, Documentation, Graphics, PC history, Windows. Bookmark the permalink.

21 Responses to Windows 3.x VDDVGA

  1. Joshua Rodd says:

    The architecture of Enhanced Mode Windows 3.x (and Windows/386) was interesting, but also infuriating. Essentially, Microsoft made an 80386 virtual machine hypervisor which then hosted 8086 virtual machines. Any device which might be accessed by more than one VM needed to have a VxD which would intercept these accesses and virtualise the device.

    In Windows 3.x, Microsoft extended the concept to both hosted 8086 virtual machines and then a 16-bit protected mode “VM” (aka the System VM) which, nonetheless, had to have access to the hardware controlled by a VxD if there was any chance another VM (aka a DOS window) would access the same hardware.

    Worse still, the concept of a “device” extended to things like network components and DOS itself, so you end up with an 80386 hypervisor which essentially virtualises DOS. Windows 9x didn’t depart from this architecture and indeed took it to its logical conclusion, but at least on Windows 9x, writing drivers was significantly easier; pre-9x VxDs are a confusing mess of assembler and hooked interrupts.

  2. Michal Necasek says:

    “Infuriating” is a good way to put it 🙂 Windows/386 was a real mode multitasker, and Windows 3.0 added protected mode support to it (for both the Windows “system VM” and DOS VMs). The huge complication was DOS sitting underneath all of it, both running the system VM and also running in multiple DOS VMs. And in the Windows 3.0/3.1 days this was extra complicated because Enhanced 386 mode wasn’t the only way to run Windows. So you needed VxDs to support Enhanced mode, but also not-VxDs for Standard mode. Which led some software vendors to say “sorry, we do Enhanced 386 mode only”, and Windows 3.11 for Workgroups made that official.

    My experience is that Standard and Real mode are quite close, and writing Windows code that runs as either real or 16-bit protected is not that hard. But VxDs are a whole different world. And Microsoft definitely didn’t make it easier with giant wads of heavily macro-ized assembler code.

    Windows 9x was, as you say, architecturally the same, but because the basic assumption was that the machine lived in the VxD world, many things were much easier. Microsoft could for example support NT style minidrivers, and over time the driver architecture got a lot better because there was no funny non-32-bit case to worry about. Even though, especially for storage, it was still possible to have to fall back on real-mode DOS drivers. Pretty it was not.

  3. SweetLow says:

    >It was possible to recover by using Alt+Enter to switch the DOS window to full screen again and then returning to the desktop, but obviously that wasn’t going to cut it.

    Hmm, I smell something interesting. The same problem and workaround as with VBEMP display driver under Windows 9x…

  4. Michal Necasek says:

    It is quite possibly the same underlying problem, the video BIOS forcing the graphics card out of high-res mode by writing to some registers that aren’t trapped/virtualized.

  5. Richard Wells says:

    Alt+Enter should correct for video gremlins. When the program switches into a window from full screen, the 386 grabber collects information about the current video mode (including what becomes SetPaintFnt, rather critical for text mode applications in a window) and then displays. In theory, it would be possible to catch these problems with a utility that sends the correct message to the grabber and forces an UpdateScreen instead of switching to full screen and back. I think some Win 3.1 drivers did trap a lot more and force more frequent updates. The modern solution is to virtualize everything but that is not very practical when the target machine is a 386/16 with 4MB of RAM.

    The underlying DOS with additional virtual machines containing their own copy of DOS was the only way to keep within the very tight memory constraints. Desqview-386 used a very similar for the same reasons.

    I did work on a VXD back in 1991. The level of frustration to successful code was extremely unfavorable. One depressing aspect was how little memory could be used by a VXD before the system transformed into a sluggish swapping nightmare.

  6. Yuhong Bao says:

    I wonder if part of the reason why they decided to demand page video memory is to make Windows 3.1 run better on 2MB to 4MB systems.

  7. MT says:

    I am curious about the virtual driver model and VM used in the early versions of Windows. Why did Windows run in a VM-style setup with “virtual” drivers? Would this not have negatively impacted performance on less powerful computers? If we ignore the use of DOS boxes, it seems to me that Windows would simply work as any other protected-mode operating system. Switch to pmode, run the programs as a process and use drivers to abstract the hardware. A driver is simply a piece of software that implements a standard interface specified by the operating system, such as a GDI-like interface. It works with the corresponding hardware using proprietary mechanisms to shield the operating system from hardware-specific details. However, the job of the driver is not to virtualize.

    So to clarify, I am confused about the role of drivers when running Windows 3.1. If a program calls a GDI function, isn’t it just processed in Windows, parsed down to a driver which then programs the hardware? So, nothing “virtual” about it at least at the hardware level. Windows itself will do a type of virtualization for instance by implementing the “windows” concept where every program runs in a window and can thus share one monitor and one graphics card. But this obviously isn’t due to the driver offering any virtualization of the hardware – it’s just how the o/s and applications tend to use it.
    When it comes to DOS boxes, it would make sense that the Windows VM monitor would need modules for virtualizing hardware that DOS programs tend to program directly. For example, a VGA module so a DOS program can think it’s programming a VGA card. But, this isn’t really a driver – this job can be done once by the o/s. The module will in turn invoke Windows calls to carry out the virtualization, and such calls may well end up in a vendor-specific driver (to get the things on the screen), but the vendor driver doesn’t know it’s related to virtualization.

    So my question maybe boils down to: When running plain Windows applications, were there any hardware virtualization at all going on or did things work in a classic driver setup as I described above (program calls become call to the driver which programs the hardware).
    Did each hardware vendors really have to write a driver that in addition to the above fully virtualized their hardware? And if that’s the case, was this solely for the purpose of DOS boxes or did it also play a role for normal Windows programs?
    It would make sense that the vendor could also write what I called virtualization modules above so that their specific hardware (with a proprietary interface Windows knew nothing about) could be available in a DOS box, if it happened that DOS programs tended to program such hardware directly. But this is a separate job from a driver and isn’t really a driver at all. It’s a plugin into the Windows virtualizer. But in Windows all drivers are called VxD or virtual drivers, and people talk about a “System VM” for Windows programs, so that is where my confusion is.

  8. Michal Necasek says:

    Early versions of Windows did not use any virtualization whatsoever. Microsoft did an excellent job of confusing things by talking about the Windows “virtual machine”, but that was really what we’d call a hardware abstraction layer and device drivers these days.

    True virtualization came with Windows/386 (1987), which was effectively an add-on to Windows 2.0. As the name suggests, it was 386 only, so it didn’t negatively affect performance on PCs and ATs because it didn’t run on them at all. Windows/386 added the ability to multitask DOS applications. It did nothing for Windows applications, the thing that changed was that Windows itself ran in a VM and could be time-sliced with DOS sessions. Note that in the Windows 2.x days, Windows/386 was available as one product, and plain Windows (later Windows/286) was another product. Windows/386 was Windows/286 plus DOS multitasker.

    Windows 3.1 can still run in Standard mode. When it does, there’s no virtualization. There are Windows drivers for display, keyboard, mouse, etc. and those directly control the hardware.

    Windows 3.1 in Enhanced 386 mode (aka Win386) adds a virtualization layer underneath. Hardware devices are virtualized to support multiple VMs, but you have to keep in mind that those aren’t only DOS boxes, Windows itself is a VM too. So the Windows drivers (for display, keyboard, mouse, etc.) are also subject to virtualization.

    So in Windows 3.1, there are not only VxDs. There are also still all the “regular” Windows drivers (usually with .drv extension). To a lesser or greater extent those drivers work with VxDs, but they are largely independent and do not need VxDs to operate.

    Once the Enhanced 386 mode was the only thing left, VxDs were attractive for many software vendors because they were 32-bit code, unlike 16-bit Windows drivers. It was possible to shove a lot of the driver functionality into a VxD, and there were things like network stacks in VxDs. It was confusing, because a VxD could do more or less anything, and with Standard mode gone there was no clear delineation what should be in a VxD and what shouldn’t.

    Over time, Microsoft moved more functionality into VxDs, like the DOS file system in Windows 3.11 for Workgroups and disk drivers in Windows 9x. But even in Windows 9x not everything was a VxD, notably Windows 9x display drives were quite close to Windows 3.x display drivers. There was a very clear evolution from DOS + Windows 1.0 to Windows Me, slowly moving more and more functionality into the 32-bit VxD world, but the basic Win386 architecture remained.

  9. MT says:

    Hi thanks but what I’m unsure about is probably this part “Windows 3.1 in Enhanced 386 mode (aka Win386) adds a virtualization layer underneath. Hardware devices are virtualized to support multiple VMs, but you have to keep in mind that those aren’t only DOS boxes, Windows itself is a VM too. So the Windows drivers (for display, keyboard, mouse, etc.) are also subject to virtualization.”. What does it mean that hardware devices are virtualized and not just for DOS boxes but for Windows itself? Does this mean that when running in Win 31. Enhanced 386 mode with no DOS boxes and a Windows program wants to draw something on the screen, virtualization is involved at some level (i.e. some code will behave as if writing to hardware but it’s actually picked up by a driver/VxD somewhere that intercepts and them presumably does the real drawing)?

  10. Michal Necasek says:

    You understood that correctly, except display drivers are not the best example. Because they usually tell the VDD to not virtualize anything in the system VM (and instead the display driver is responsible for saving/restoring any state). But in general that is how it works, for example the Windows keyboard driver (keyboard.drv) goes through the virtual keyboard driver (vkd.386). The VxD does whatever is required to let Windows itself and DOS sessions think they own the keyboard/mouse/display/whatever.

  11. MT says:

    Ok I think this is hard of the matter. Ok so display drivers are a bad example… but what if we take sound cards? Let’s say I am a vendor of a sound cards with some hardware interface. I want to make this available to windows programs. Do I both need to write a VxD driver for completely virtualizing my own hardware. And then a .drv driver for actually making windows able to know how to use the (now virtually exposed) hardware, which will then be manipulating the virtual hardware exposed by the VxD/.386

  12. Richard Wells says:

    Note that under Windows for Workgroups 3.11, running in standard mode was still an available option for troubleshooting. Win /d:t Having drivers that work in standard mode was still a requirement.

    The following excerpt of Writing Windows Drivers by Dan Norton applies to performance concerns with drivers under expanded mode. Please note that the book was written before Win 3.1 so all the future changes to the VXD model can not be mentioned.

    “… you should know that virtual access to the hardware can slow things down substantially. Instead of having your standard driver poke at virtual I/O ports, you may wish to give your driver direct access to the ports in enhanced mode. Alternatively, you may wish to have a virtual device driver control direct access to the hardware, handling device interrupts and buffering directly. This way your standard driver is not bogged down with virtual I/O access.”

    Disclaimer: I was an employee of Mr. Norton prior to the book’s publication.

  13. Yuhong Bao says:

    Which is why the amount of work done (and memory used) in a VxD should be kept to a minimum.

  14. MT says:

    @Richard: If a vendor were to do this (“you may wish to give your driver direct access to the ports in enhanced mode”) – what would one do? Make a VxD that actually didn’t virtualize anything and thereby let the .drv driver through)?

    To summarize in general – it seems virtualization really was generally in play in this model. And it’s all due to the need to support DOS boxes, because if it wasn’t for those there would be only one VM, thus no need for VM’s or .386/VxD’s *, only the ordinary drivers knowing their hardware (“.drv” files). This could potentially have given Windows a performance benefit? It’s strange to me that Microsoft selected this way of supporting DOS boxes, incurring an overhead for general Windows operation (and requiring vendors to supply two drivers, at least in some cases) – as opposed to optimizing for Windows apps, and give .drv drivers direct access. DOS boxes would be handled by a v86 based virtualizer that would itself contain the “drivers”/modules necessary to emulate the PC hardware – and would rely on the normal Windows API’s for drawing on screen, make sounds, keyboard etc. which would eventually go down to the .drv driver. I guess it shows how important DOS boxes must have been or maybe it just happened to be a good model initially.

    *) Though based on Michael’s response it’s clear that VxDs were later used to implement just any normal driver, not necessarily related to virtualization.

  15. Richard Wells says:

    @MT: Direct access requires the VXD to lock the device and then hands off control to the only driver permitted.

    Windows 3.x had standard mode for those that wanted the maximum speed of Windows drivers without the overhead of trying to keep DOS applications running in the background. 386 mode was a rapidly implemented method of improving old app support without trying to create a whole new protected mode OS. Almost OS/2 2.0 would have taken almost as much work to develop as the OS/2 kernel itself did. There were other DOS multitaskers with a complete protected mode kernel which were unsuccessful since the memory demands were higher and more software wouldn’t work.

    VxDs did change as memory capacity increased so buffering access to devices was possible. Some VxD and driver pairs look similar to the design concepts used in miniport drivers. Undocumented Windows also pushed the idea of using VxD for flat memory access. Natural thought for a DOS extender developer but consideration of the risks of ring 0 access and the needs of multitasking got short shrift.

  16. MT says:

    @Richard: Thanks a lot for the info. For low-bandwidth stuff (keyboard, mouse) I doubt virtualization would make much of a difference. For video it would, but apparently that was treated as a special case. I don’t know about sound cards, it seems performance could be hampered by virtualization there as well… maybe they were treated especially too. I true virtualization would require the VxD to do mixing of the incoming sound I guess, and this is also what happens in a modern o/s (in the o/s itself, not driver) for “application-level” virtualization of the sound resource.

    For what it’s worth I always found Windows 95 performance to be excellent. I was anxious when upgrading my aging 486/25 with 8MB RAM and feared it would be slow as a dog, but everything seemed faster and more snappy than with Win 3.1. Even booting was quite fast. I suppose the 32-bit drivers have played a big role there.
    On the other hand, OS/2 was at the time hailed as the “true” 32-bit o/s with preemptive multitasking etc. I for one wasn’t that impressed with the performance (sorry to say on this forum) – it seemed less responsive and more sluggish in many tasks. Booting was slow too, and with periods of no activity. Maybe the drivers for o/s weren’t as good (though my machine was an IBM PS/1 2133 tower). I think perhaps the RAM was a problem and also OS/2 was likely faster at things I didn’t use (server-stuff, network, true multitasking etc.)

  17. Michal Necasek says:

    Yes, DOS boxes were very important. Think about it like this — imagine it’s 1988 and you’re trying to do office or engineering work with Windows. There just weren’t that many Windows apps, and users required DOS applications. Windows/386 was, if anything, a way to get users to spend more time running Windows by letting them run DOS programs concurrently.

  18. r34jinkai says:

    @MT Please check VxD technology wasn’t only exclusively for DOS box support. It was also used to leverage on BIOS and DOS code to drive hardware which had no specific Windows driver but was supported by BIOS or DOS drivers. Think about cheap IDE/ATA stuff supported directly by INT13H on BIOS, or network hardware which at time had only Novell ODI compatible DOS only drivers.

    Later in the game was used to port NT code over Win95 and 98 architecture. First as source code compatibility with NT storage miniports… Then was DirectX… And very late in game, with a very minimal set of the NT Kernel running as VxD and offering a set of the WDM driver architecture (USB, ACPI, BDA, Firewire and multimedia Kernel Streaming support in Win98 use this for example). This broad compatibility between DOS, Windows and NT is the reason why Win9x architecture lasted that long.

  19. Richard Wells says:

    For those wondering about the costs of virtualizing the display, InfoWorld Feb 13, 1989 has a comparison review of several 386 multitaskers. Page 55 has some performance numbers; one that deserves highlighting is the Windows 386 Drafix/123 benchmark which takes twice as long if the apps are run in a window as opposed to full screen. Desqview performed much better in that task but running in a window was still slower than full screen.

    The multitasking market wasn’t all that big but Quarterdeck had about 100 million dollars in sales (roughly 1/10th of what MS had across all product lines) in the early 90s.

  20. SweetLow says:

    >disk drivers in Windows 9x
    In Windows 3.1x too (BLOCKDEV). Windows 9x is the second version (IOS). And you have good article about that “How to please WDCTRL” http://www.os2museum.com/wp/how-to-please-wdctrl/

  21. Michal Necasek says:

    Yes, I wrote about the Win95 IOS too.

    It’s just that in Windows 3.x, the VxD disk driver was entirely optional and probably not present on many machines (given that WDCTRL was quite picky, and not every OEM shipped a custom driver, though many did). In Windows 95, on a freshly installed system, the 32-bit “native” disk driver was almost certainly used.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.