The OS/2 museum recently obtained a boxed copy of the original Microsoft Windows/386. That is, version 2.01 of Windows/386 from September 1987.
Windows/386 was Microsoft’s first product utilizing the 386 hardware in the DOS world. Microsoft was involved in the port of XENIX to the 386, but that was an entirely different product with a tiny market share.
Windows/386, on the other hand, was the direct predecessor of Enhanced mode Windows 3.0 and Windows 95. Windows/386 was an odd duck; it was essentially regular Windows 2.0 with a few optional “extra bits”. When started through WIN86.COM, Windows/386 was reduced to plain Windows 2.0 running in real mode and needing nothing more than an 8088-based PC.
When started through WIN386.EXE however, Windows/386 was transformed into a DOS multi-tasker with a built-in EMS emulator, rather similar in concept to Quarterdeck’s Desqview 2.0 (with QEMM) and other products. A virtual machine (VM) manager allowed the user to run multiple DOS sessions. One VM was always reserved for Windows and other VMs could be created on demand. The same basic architecture was used in Windows 9x.
The crucial difference between Windows/386 (all versions up to 2.11) and Windows 3.0 in Enhanced mode was that the latter ran Windows applications in protected mode, while in Windows/386, the Windows VM was just another real-mode DOS box. With a bit of exaggeration, it could be said that Windows/386 + DPMI = Enhanced mode Windows 3.0.
Windows/386 from 1987 was a historically very important product. Not necessarily because it was particularly innovative or better than the contemporary competition (particularly Desqview), but rather because it was the first in a line of highly successful DOS-based Windows products for the 386 and later CPUs.
Now the remaining question is… what happened to Windows 2.02, and was there Windows 2.00? Perhaps not. If InfoWorld is to be believed, Windows/386 was indeed released before regular Windows 2.0—on a deadline so that Compaq could bundle Windows/386 with its 386 machines. Since Windows 2.0 was released a few weeks later, it would make sense that the version number went from 2.01 to 2.03, and the interim versions were not necessarily publicly released.
I could be wrong, but I think there was a Windows 2.0, then Windows/286 2.x then finally Windows/386 2.x … I know it sure sounds confusing, and if you upgraded to a 386 you’d feel kinda left out with the 286 or ‘regular’ version of Windows 2.0 …
I have Windows/386 2.11 in the box (the last version from what I understand) and it even comes with a working model of excel!
It’s hard to piece the exact timeline together, but Windows/386 appears to have been released before Windows 2.0. The Windows/386 release is labeled 2.01 and is dated September 1987. The only version of Windows 2.0 I know of that didn’t have a /286 or /386 suffix is labeled 2.03 and the files are dated November 1987.
Well that would go to show just how much Microsoft was trying to push for 386 specific software, and how they wanted nothing to do with 286 versions of OS/2.. Although at the same time getting OS/2 2.0 and Windows NT 3.1 out of the door was a far bigger task than either IBM/Microsoft seemed to have anticipated… I wonder how much of the delays and issues were because of the runaway success of Windows 3.0 ..?
Microsoft definitely wanted a 386 version of OS/2 while IBM was pushing for 286 support. The question is when they would have managed to get an actual release done, and how successful it would have been given that in 1992, OS/2 was considered too bloated for requiring 4MB+ memory. There just weren’t that many 386s in 1988.
I don’t think the success of Windows 3.0 ultimately delayed the NT 3.1 release, although the API change can’t have sped things up. However, Microsoft’s withdrawal from OS/2 development certainly delayed the release of OS/2 2.0 significantly. One ex-IBMer I spoke to estimated the delay to about one year. That sounds realistic–OS/2 2.0 was released in 1992 but a 1990 release was initially planned, so an actual release in 1991 should have been possible with Microsoft still on board.
Oh and I re-remembered this fantastic post from Gordon Letwin…
http://groups.google.com/group/comp.os.ms-windows.misc/msg/d710490b745d5e5e?pli=1
More of the missteppings, the 386 and of course OS/2.
I do have a soft spot for Windows 2.xx, as it is the earliest version of Windows I have used. Most of our school computers ran Windows 3.0, but we had one computer lab with older computers, and they ran some flavour of Windows 2.xx. I’m not sure exactly which version it was.
Your last paragraph has me curious. I was under the impression that the “/286” and “/386” versions were introduced with Windows 2.10, but clearly this is not the case looking at your screenshots.
The naming was weird… first there was Windows/386 and Windows, both version 2.0. With version 2.1, the plain Windows version was renamed to Windows/286. The justification was the addition of HIMEM.SYS, which (optionally) added almost 64KB of base memory on 286+ systems.
Is curious that this version of windows was the first one that includes the VXD driver model, the first attempt of Microsoft to abstract the physical hardware of the applications, and make a true protected mode drivers that could use all 386 features…
Great article.
Just to clarify, Windows/386 did not support user-loadable VxDs (to my knowledge), there was only a big blob of 32-bit code, no doubt written 100% in assembler. The virtual devices were clearly there already though. A DDK or OAK would tell more, but those seem to be lost.
Microsoft later refined the virtual device model in OS/2 (around 1989-1990) and even later, in NT (around 1991-1992).
That´s true, Windows/386 didn´t support third party VxD loading, and Microsoft didn´t provided support to writing VxD in their DDKs until the release of Windows 3.1.
But i´m sure that Windows/386 Win386.exe 32bit blob is in reality a compound of VxD files, just like Windows 3.x Win386.exe and Windows 4.x (9x) vmm32.vxd were, but apparently Windows/386 blob only contains the DOSMGR (VM Manager) and V86MMGR (Memory Manager) modules, i need search more about respect.
As side note, OS/2 VDDs have more in common with Windows VxDs that Windows NT VDM Drivers, at least in concept. VDDs are in fact true drivers that run in x86 Ring 0 to work as OS/2 MVDM drivers and driver helpers, whereas NT VDM “Drivers” are Win32 usermode DLLs, and they act more like application plugins that drivers for NTVDM.
The Windows 3.0 DDK did support VxD development. I don’t have the DDK itself (though I would love to!), but I do have the complete documentation. VxDs are all in there.
Yes, it’s extremely likely that the blob in Windows/386 contains something like VxDs, although it’s questionable to what extend the code was really modularized. There is nothing that looks obviously like module headers, but then Windows/386 predates LINK386 and probably most other 386-capable development tools from Microsoft.
The VDD model in OS/2 is something of a VxD 2.0 model, developed from scratch yet based on what Microsoft had learned from Windows/386. But it is, in fact, more like the NT model. Yes, OS/2 VDDs run in kernel mode directly, because a x86 host is assumed, unlike the NT case. But the more important characteristic is that OS/2 VDDs are tied to VDMs and can’t do much for native OS/2 applications, and may not be loaded at all. That’s very different from Windows 3.x/9x where the VxDs apply to the system VM just as much as to any other VM. In Windows 3.x/9x, VxD is the driver model, whereas that’s not the case for OS/2 and NT VDDs.
Hehehe… yeah 🙂
If you want Win3x DDK, you can download a copy of it from Alter´s website:
hxxp://alter.org.ua/en/downloads/
It says Win31, but a lot of the DDK applies for Win30 as well, and some parts apply for Win86 Real Mode as well… it comes with online documentation
For more information about Windows/386, VxDs and NT/OS2 VDDs, i recommend read first this document:
http://www.essaycoursework.com/coursework/making-utilities-for-msdos.php
And the book Undocumented DOS from Andrew Schulman, unfortunately google books only have the Spanish version released for free (I´m Mexican).
Sorry, I wasn’t clear. I don’t (but would like to) have the Windows 3.0 DDK, or any earlier DDKs (I only have the SDKs for Windows 1.x and 2.x). I have the Windows 3.1 DDK of course, it wasn’t hard to get from MSDN a few years back and it may even still be available there.
I also have a printed copy of Undocumented DOS, as well as Undocumented Windows and Windows Internals, together with a few books on DOS extenders. All of them pretty interesting reading.
Interesting read from Michael Sokolov of 4.3 BSD Quasijarus fame… Although I just largely remember his incompatible compression.
It would be cool to score a 3.0 DDK and maybe fix the VGA driver….. Although I don’t think there would be much of a market for it anyways.
I guess the Windows 3.0 DDK is in the same place as the OS/2 2.0 DDK, and I almost wonder if it were the same tools and the same reason why they are all but gone… Like they just don’t want anyone writing anything for either.
The Windows 3.0 DDK was a normal released product, although not entirely cheap. The OS/2 2.0 SDK on the other hand was a limited release, very expensive ($2,600) deal.
I’m sure the relative rarity of the Windows 3.0 DDK is caused by the fact that not that many developers ever needed it, and it was relatively quickly superseded by Windows 3.1. Compare with the Windows 2.0 SDK, which is also rather hard to find these days.
Some of the tools were indeed the same, especially LINK386… but then LINK386 was still around for Windows 3.1/9x. I don’t believe Microsoft’s CL386 was ever part of the Windows DDKs, apparently they didn’t believe in writing VxDs in C (third parties supported that, e.g. VtoolsD).
Pingback: Operating System/2 announced 25 years ago | OS/2 Museum
Great article. (I’m just now reading it – nearly 3 years after it was published.)
In this article, I think you are indicating that Desqview was better? (Or at least equal to Windows/386 multitasking.) “Windows/386 from 1987 was a historically very important product. Not necessarily because it was particularly innovative or better than the contemporary competition (particularly Desqview)…”
I certainly don’t know much about either of them, but I remember getting a copy of Desqview and running it on a 386sx 16MHz computer, and I think I tried it again on a 486dx 33MHz a year or so later. (Early 1990’s when I was 14 years old.)
All I remember about Desqview is that I HATED it. Even back then when I was just getting started with computers in my early teenage years, it didn’t “feel” right to me. It felt like a total hack.
When I experienced *real* multitasking with Linux in 1995, the switching between virtual consoles was so smooth and fast that I wrote Desqview off as a complete joke.
My uneducated opinion was that since Desqview at “on top” of DOS, that it simply couldn’t do what it was trying to do. (At least, it couldn’t to it well.)
So I just assume (even now – with 2 decades of computing experience in the rear view mirror) that Multitasking MS-DOS 4.0 (and multitasking OS/2 1.0/1.1) must be somehow inherently better for the simple fact that it’s the Operating System itself that is doing the multitasking. Like it’s integrated at the lowest possible level and not just a hack job running on top of a non-multitasking OS.
Am I way off base? Is/Was Multitasking DOS no better than Desqview from a technical perspective?
And to that end, what about the earliest versions of Windows? Weren’t they more or less multitasking hack jobs that just sat on top of DOS? I was under the impression that even Windows 95 and Windows 98 weren’t true multitaskers … at least not like Windows NT 3.1 and Win2K/XP and so on. But even so, Windows/386 and the other early versions of Windows would, I would assume, be better than a 3rd party tool since the operating system developers have total knowledge and access to the lowest levels of code.
If my questions and assumptions seem very stupid, forgive me for being so ignorant on these things.
I never used either Desqview or Windows/386 back in the day, so I have to consider contemporary press reports. Desqview was typically highly rated, often better than Windows/386. For example see “Multitaskers” on page 51 of February 13, 1989 issue of InfoWorld. One of the major advantages of Desqview mentioned there is that it didn’t prevent 386-specific software from running (like Windows/386 did) and was faster than Windows/386.
Multitasking MS-DOS 4.0 is architecturally certainly different/better, at the cost of requiring applications specifically written for it. It’s conceptually closer to OS/2 1.0 than to DOS, and it may be useful to think of multitasking DOS 4 as OS/2 version 0.3 or so. Compared to Desqview/386, multitasking DOS 4 would fare very poorly in the memory management area because it’s simply too old.
The early versions of Windows were strange beasts. If you consider Windows/386 and Windows 3.x in Enhanced mode, it’s important to realize that Windows could pre-emptively multitask DOS tasks, but only used failure-prone cooperative multitasking for all Windows applications. But even early Windows apps had some advantages over DOS apps in that they were written for Windows memory management, and it was easier for Windows to swap/discard/reload chunks of memory (segments), something that a multitasked can’t really do for DOS apps. The major shortcoming of Windows was that a single ill-behaved application easily brought down the entire system.
Windows 9x still retained the basic architecture of Windows/386, but every new version relied on DOS less than the previous one. It certainly was nothing like Windows NT. Summarizing the architecture of Windows 9x is very difficult, but I’ll say it was a rather odd hybrid, and that there’s a fairly smooth progression that can be traced from Windows 1.0 to Windows Me.
Oh, and it wasn’t until Windows was widespread that Microsoft truly realized the advantage of writing both the OS and the applications. In the DOS days, Microsoft apps were rarely the best in any category. DOS was so simple that having the source code for it just didn’t help them all that much.
Thanks for the fantastic reply.
I’ve been reading a bit more about Windows 2.x and all its variations. I’m pretty confused on how many versions there are. According to Microsof’t’s version history (http://support.microsoft.com/kb/32905), there was no Windows 2.01. But clearly there was because you have a boxed copy. Was that a special box or something? Only intended for internal use and developers? Or was it actually a retail release that anyone could buy in the store? (If so, why the heck isn’t it listed in their official history?)
I know that 2.10 and 2.11 came in the 286 and 386 flavors. I’ve located install disks for all 4 variations, and the installer presents itself as Windows/286 2.10, or Windows/386 2.10, and Windows/286 2.11, or Windows/386 2.11
Was 2.03 just plain Windows? Or was it 386 only? The installer I have presents itself as just “Microsoft Windows Version 2”. But once you get installed, the About screen confirms that it’s 2.03. But there’s no mention of /286 or /386
So, in summary. There’s this 2.01 version that Microsoft says doesn’t exist. There’s 2.03 which doesn’t say /286 or /386, and then there’s 2.10 and 2.11 that are both /286 and /386.
Am I missing any?
It’s roughly like this. Windows/386 2.01 was a real Windows release in a regular box and with standard documentation, but it was probably only available with Compaq 386 PCs (Compaq collaborated with Microsoft on Windows/386 development). I’d call it a “limited retail release” or something like that. Windows 2.03 was then the “normal” Windows 2.0 release, and as the version number suggests, came a little later. From what I’ve seen, when Microsoft talked about “Windows 2.0”, that meant 2.03.
With the Windows 2.1 release, Microsoft added high memory support (including HIMEM.SYS) and called the basic version Windows/286. It didn’t require a 286, but could take advantage of it. That’s why 2.03 was just plain Windows and 2.10 was Windows/286. Windows/386 was a separate version but updated in sync.
So we have Windows/386 2.01, 2.10, 2.11. And we have the non-386 product version 2.03, 2.10, 2.11 — with the caveat that it was called ‘286’ starting with 2.10. Clear as mud 🙂
Wow, yeah – that is kind of a mess of version numbers, but if your account is correct, I can actually follow along.
I do have one other question with regards to the Windows/386 variants. When it came to setting up CONFIG.SYS, were you supposed to include any lines for HIMEM.SYS and/or EMM386.EXE in the CONFIG.SYS?
I read a comment from someone on Jason Stevens’ blog (a frequenter of this site) who said: It seems you’re not supposed to use HIMEM.SYS with Windows/386: “In Windows/286 version 2.10 or later, Windows has the capability of putting part of itself in extended memory with the help of a driver called HIMEM.SYS. In Windows/386, the HIMEM capability is built-in and HIMEM.SYS should NOT be placed in the config.sys.”
But if it’s built-in, then why do they have a C:\WIN386\HIMEM.SYS file?
Yes, the versioning is one of those “it made sense at a time” things.
The first version of Windows/386 predates both HIMEM.SYS and EMM386.SYS (it wasn’t EMM386.EXE back then). It essentially includes a built-in superset of EMM386 functionality.
The later versions of Windows/386 do ship with HIMEM.SYS and install it by default. I don’t think Windows/386 clashes with HIMEM.SYS, but it’s probably true that HIMEM.SYS isn’t required. Then again, HIMEM.SYS is a general XMS memory manager and useful for things like disk caches and ram disks. And Windows did ship with RAMDRIVE.SYS and SMARTDRV.SYS, so that may have been reason enough to also ship HIMEM.SYS.
Hmm… there’s some kind of conflict there somewhere. If I have DEVICE=C:\WIN386\HIMEM.SYS in my CONFIG.SYS, the system comes back with:
WARNING: The A20 Line was already enabled. XMS Driver not installed.
This also means the line DOS=HIGH fails. It says:
HMA not available: Loading DOS low
On the other hand, if I use DEVICE=C:\DOS\HIMEM.SYS (which would be PC DOS 2000’s HIMESYS), then I get this when I run the win386 command:
Error: High memory area in use.
The only thing that works is NOT having any HIMEM.SYS line in the CONFIG.SYS. (Which also means taking out DOS=HIGH and any other DEVICEHIGH statements such as loading a CDROM driver. Have to load them in low memory instead.)
It’s also interesting to note (perhaps) that if I don’t have DEVICE=C:\DOS\SETVER.EXE in the CONFIG.SYS, Windows/386 2.11 won’t load. That one is harder to explain in words, so check out this 60 second video clip I made:
http://www.youtube.com/watch?v=eZt999RYtLQ
I guess I still have access to all the virtual RAM though because I’m still able to start Turbo Pascal 7.01 within Windows/386 2.11. In fact, I can start 8 instances before I run out of memory.
So I’m not really sure what’s up with the HIMEM.SYS. Why include it if it’s built-in and can’t even be used?
DOS=HIGH? What’s that? 🙂 Windows/386 predates DOS 5 by quite a bit. You’d have to use DOS 3 or 4. I’m quite willing to believe that HIMEM.SYS shipped with Windows/386 doesn’t work with DOS 5/6/7, but that’s not saying much.
As for the A20 enabled error, what exactly is the HIMEM.SYS version and what hardware/virtual platform exactly?
Ha – didn’t know that DOS=HIGH was a DOS 5 thing. MS-DOS 5.x (I don’t remember the exact version) was the first version of DOS I ever experienced. Well, actually, I do remember that in high school, they had some pretty ancient computers (they were outdated even then) that used some earlier version of DOS. But as students, we were only allowed to use 2 or 3 programs that were installed, so I never got into the CONFIG.SYS on those. I digress slightly.
It’s probably easier to show you my screen (again) rather than type everything out.
http://www.youtube.com/watch?v=vnUoB5MmlT0
DOS 5 was the first version I really used, but I’ve done enough digging into DOS history to know that high memory support was THE major new feature of DOS 5 🙂
Anyway… The HIMEM.SYS shipped with Windows/386 2.11 (that’s HIMEM.SYS 2.04) is incompatible with DOS 5+. For some reason that’s not entirely obvious to me, DOS 5+ enables the A20 gate even with no DOS=HIGH statement in CONFIG.SYS. This is of course different from the older DOS versions which left the A20 gate alone. The old HIMEM.SYS effectively expects to find the old (A20 disabled) state and as a consequence, its detection of A20 line control fails. As far as I can tell, it’s really a bug in the old HIMEM.SYS version (it’s clear from reading the HIMEM source code that this case should work, but doesn’t because the internal logic is broken).
As for the other error (“High memory area in use”), again that’s an incompatibility with DOS 5 and later. Earlier DOS versions did not use the HMA and Windows/386 clearly wasn’t written to share the HMA with anyone.
What works for me is using HIMEM.SYS shipped with DOS and not using DOS=HIGH. Tested with PC DOS 5.01 and Windows/386 2.11. Windows/386 takes over extended memory and creates EMS instead.
Ok, thanks for the great info. I’ll dial back my DOS version a few years and try again. I was checking out Compaq DOS 3.31 quite a bit last night. It’s of particular interest because it’s the only DOS 3.x that allows partitions greater than 32MB.
My quick & dirty understanding of the history of Compaq DOS 3.31: Apparently Compaq borrowed FAT-16 from DOS 4.x and brought it DOS 3.30 and released it as DOS 3.31.
I thought this would be a particularly good version of DOS to try Windows/386 2.11 on, but at first I couldn’t get it to work. When I ran win386, it reported: Unsupported DOS version.
Then I tried IBM PC-DOS 3.30. But it too was giving me trouble. It didn’t report that my DOS version was unsupported, rather, when I ran win386, the screen cleared and immediately went back to a command prompt.
So then I quickly tried MS-DOS 4.01 and got the same thing.
When installing Windows/386 2.11, it puts this line in the CONFIG.SYS:
DEVICE=C:\SMARTDRV.SYS 7680
That device driver, or the 7680 argument, causes some kind of conflict in Virtual Box session, preventing Windows/386 2.11 from running. Removing the line fixes the problem.
I’ve also found with Windows 1.x and 2.x, I have to go to the Session Settings for the VM and go to System and uncheck Enable VT-x/AMD-V. If I don’t do that, I have no control over the mouse. (And the only reason I enabled it was so OS/2 VM’s would work.)
But finally, getting back to HIMEM.SYS. With these older versions, I’m able to have DEVICE=C:\WIN386\HIMEM.SYS in the CONFIG.SYS and Windows still boots.
Now I just have to digest what all of this means. PC DOS 2000 comes with its own HIMEM.SYS, but you can’t use it if you’re wanting to run Windows/386 2.11. You also can’t use the HIMEM.SYS that comes with Windows/386 2.11 if running under PC DOS 2000.
Older DOS’s like IBM PC DOS 3.30 and MS DOS 4.01 do not include a HIMEM.SYS, but you can use the one that comes with Windows/386 2.11
But … is it even necessary? Does including that line in the CONFIG.SYS actually accomplish anything? Or does Windows/386 2.11 load it, itself, internally, even if it’s not included in the CONFIG.SYS?
Hmm….
P.S. Is there any way to have notifications emailed to me for when I get a reply? I include my email address in every reply I post, but I never get a notification. I have to remember which article I commented on, and remember to come back and check for replies. That leaves a lot of room for human error. 🙂
I’m honestly not certain how the notifications work. The only thing I know for sure is that notification e-mails can sometimes get significantly delayed.
It’s actually unclear where Compaq got the FAT16 code from, or if they wrote it themselves. There’s just no real information on that topic.
By the time DOS 5 came out, no one gave a damn about Windows/386, especially not Microsoft. Windows/386 had been utterly obsoleted by Windows 3.0 at that point. That’s probably why the two don’t work very well together.
As a general rule, I’d always start with more or less common hardware/software of the era, which includes disk size, memory size, and OS version. FWIW, I didn’t run into any problems with Windows/386 2.11 and PC DOS 3.30 (VM with 16MB RAM). I let the Windows/386 installer do what it wanted and SMARTDRV.SYS didn’t cause any trouble.
You were the one having weird problems with the mouse in OS/2 VMs in VirtualBox, right? I honestly don’t know what’s so special about your system. I’ve never seen that on any of my machines (Mac, Windows, Linux, various Intel and AMD processors). Needless to say, the mouse works fine for me with Windows 1.04 and 2.x when using VT-x… I’m sorry I can’t help you with that.
As for the real question, does using HIMEM.SYS with Windows/386 even do anything… I’m not sure. It does make a difference if you run WIN86.COM (more available memory). I have not yet noticed any difference with actual Windows/386, but it’s possible that it also increases the maximum available conventional memory.
Part of my interest in that Compaq DOS 3.31 is that I read somewhere that DOS 3.3 is often referred to as the last good DOS. Or at the very least, the following version 4.x, was so terrible that many people stayed with 3.30.
It’s hard to imagine that people would prefer to stay with 3.30 with such a small hard-drive limit, but I guess in 1988, a 32MB fixed disk was still adequate? I remember when my family got our first IBM PC clone, it was a 386sx and only had 1MB of RAM and a 40MB HDD. It came with MS-DOS 5.0 (or possibly 5.00a – I’m not sure which). This was like 1990. So it’s not hard to imagine that 32MB was still a big deal in 1988. (Though, I’m pretty sure my parents bought the bargain bin PC at the time. 🙂 Never-the-less, I grew up on that 386 and learned all the basics of BIOS and DOS on it. My parents lost interest in the computer very fast, so I picked it up and just started “hacking” away – completely fearless. My dad was always scared to mess it up, so he wouldn’t use it. But I had the kind of boldness that only a 14 year old can have. I figured if I broke it, I could figure out how to fix it some way or another. So it wasn’t long before I was fdisk’ing, sys’ing, formatting and re-installing. Over and over again. 🙂
Yes, that was me that had the weird problems with the mouse under OS/2, and posted a video to show what was going on: http://www.os2museum.com/wp/?p=437&cpage=1#comment-55866
I had the same problem on 2 different Windows 7 computers, but interestingly enough, did not have the problem under Windows XP. Turning OFF VT-x/AMD-V is what ended up fixing it for me. Which is very odd because when you start OS/2, Virtual Box warns you that it won’t work unless you have VT-x/AMD-V enabled. But in my case, it’s exactly the opposite.
For your interest, here are the relevant parts of my computer specs:
Intel Core i7-4770K Haswell 3.5GHz CPU
ASUS B85-Plus Motherboard
Corsair Vengeance 16GB RAM DDR3 1600MHz 240 pin
MSI Radeon R7870-2GD5T
Samsung 1TB 840 EVO SSD
Seagate Barracuda 3TB SATA6 HDD
Corsair PSU 750TX
Regarding getting notifications, I never get notifications from here. I even check my spam folder once or twice a day to make sure nothing I want was misplaced there, and then I empty it. I’ve never received a notification about a topic reply whether it was hours, days, weeks, or even months later.
3.3 was maybe the last good DOS for PCs and XTs. For 286s not so much, and for a 386+ that’s just laughable. Try setting up networking etc. on DOS 3.3… it’s either not possible or requires 3rd party utilities that cost as much as DOS itself. The built-in memory management in DOS 5/6 was a huge advantage.
Anyway, it’s certainly true that the partition limit was not a big deal for many people even in the early 1990s. Even a huge (by 1990 standards) 100MB disk could be split into 3 partitions, which was not necessarily a bad thing for organizing data.
DOS 3.31 basically took the proven base of DOS 3.3 and added the most attractive feature of DOS 4 (large partition support). That made it quite popular until DOS 5 and 6 finally took over. I too had a PC to play with in the early 1990s as a teenager, but in my case it originally came with DR DOS 6.0 (instead of MS-DOS 5.0). Over time it was upgraded to Novell DOS 7 and various versions of MS-DOS 6.x and PC DOS 6.x.
The problem with the mouse could be software, but I don’t know what/how. At least one of my systems is similar enough and has no such trouble. The only bits of hardware that might make a difference are the CPU and the mouse. Turning hardware virtualization significantly affects the relative speed of various operations (certain things get much faster and others much slower) so that’s probably why it does anything. When you say it works for you under XP, that’s probably a different system?
The hardware virtualization warning about OS/2 really only applies to 32-bit OS/2… the 16-bit versions are different enough.
I honestly don’t know how the notifications work. I get them, but that’s because I’m an admin 🙂
“Earlier DOS versions did not use the HMA and Windows/386 clearly wasn’t written to share the HMA with anyone.”
This reminds me of WINA20.386. http://www.windowswiki.info/wp-content/uploads/codenames/PX03473.pdf shows that the DOS 5.0 project started in December 1989 with plans to move DOS to the HMA already, and with the original code complete date being the end of March 1990, before Win3.0 was released.
Here is some information about WIN386.386 file format used by Windows/386 2.x and which predates LE/VXD format: https://www.geoffchappell.com/notes/windows/retro/win386.htm
That looks an awful lot like the x.out format used by 386 XENIX. Which of course would be the least surprising thing ever, because what 32-bit OS did Microsoft have in 1987? I’m surprised Geoff Chappell hasn’t made that connection.
See here for an outline of the x.out format.
Yes indeed.
#define X_MAGIC 0x0206 /* indicates x.out header */One guess what the first two bytes in the .386 files in Windows/386 2.01 are.
This is interesting, Linux file already recognizes those Windows/386 2.01 .386 files as:
$ file EGA.386
EGA.386: Microsoft a.out segmented word-swapped not-stripped V2.3 V3.0 386 small model executable not stripped
Yep, that makes sense. I am almost certain that “Microsoft a.out” is a misnomer, since Microsoft called the format x.out. It was significantly more complex than your typical UNIX a.out format as it was designed to handle 8086 segmentation. But yes, the old 32-bit Windows/386 executables are definitely using the 386 XENIX format.
It’s possible that the 32-bit Win/386 code was developed on XENIX (the 386 development tools happily ran on 286 XENIX, too), and it’s also possible or even likely that Microsoft had a custom build of their linker that could produce XENIX modules on DOS. A DDK (“adaptation kit”) for Windows/386 2.x would tell, but I have never seen one.
Microsoft released Windows/386 2.01 in 1987 but 386 XENIX was released in 1988 by SCO. And previous XENIX versions were not 32-bit yet. Had Microsoft access to internal 386 SCO development tools? Or Microsoft wrote development tools for 386 XENIX before SCO?
And I doubt that there were some some public tools for WIN386.386 file. Microsoft just distributed few versions of this file on installation media and these files were not prepared for modifications.
No. 386 XENIX was released in 1987, and Microsoft did a lot of work on it. Microsoft also provided the tooling including compiler and linker. So yes, Microsoft in fact wrote the 386 XENIX development tools. I don’t think SCO ever had non-Microsoft development tools for XENIX (286 or 386).
See this press release (from April 1987) to understand more about 386 XENIX: https://www.tech-insider.org/unix/research/1987/0402.html
Microsoft had a common linker, but the DOS and OS/2 versions could not target XENIX. However, the ld shipped with XENIX could produce DOS executables in addition to XENIX support.
There was supposed to be an adaptation kit (really a DDK) for OEMs to support Windows/386. Anyone with a custom graphics adapter would have needed to modify Windows/386. How many OEMs actually did that I have no idea — possibly very few. But I believe a development kit did exist, although I don’t know what was in it.
The Windows 3.0 DDK included VxD development bits but of course at that point Microsoft had already switched to the LE format used by MS OS/2 2.0. In the Windows 2.x days the Windows/386 dev kit was separate from the “regular” Windows DDK.
@Michal Necasek
“For some reason that’s not entirely obvious to me, DOS 5+ enables the A20 gate even with no DOS=HIGH statement in CONFIG.SYS.”
Sorry for resurrecting the A20 zombie, but this text had me baffled. It’s easy to check that in DOS 5 and higher the A20 line is disabled by default, without HIMEM.SYS and “DOS=HIGH”, and address 0x100000 wraps to zero. So, what exactly does your statement mean?
Or did you mean that DOS 5 had the A20 line enabled only for the duration of CONFIG.SYS processing, and then disabled it again?
Actually I think it happens even before processing CONFIG.SYS. DOS enables and then again disables the A20 line. So no, the A20 line is not enabled permanently, but the A20 gate is toggled on and off early during DOS 5+ startup.
In printed document “The Microsoft Windows Device Driver Writer’s Release Notes” from September 1988 which is part of the Windows/286 2.11 OEM Binary Adaptation Kit is written:
“You cannot develop the virtual device drivers for Windows/386 by using this kit. However, it is absolutely necesary for you to first write a Windows/286 driver in order to even start writing a Windows/386 driver. Therefore, in order to achieve your ultimate goal of adapting Windows/386 to your device, you must use this kit to adapt Windows/286 first, and then contact Microsoft to obtain the Windows/386 Binary Adaptation Kit.”
So Microsoft was preparing some Windows/386 tools for OEM to develop own WIN386.386 file.
@Michal Necasek:
From all this it seems likely (without actually reverse-engineering DOS), that DOS 5 just enables A20 before starting to load CONFIG.SYS drivers. That’s why early versions of HIMEM.SYS don’t work under DOS 5. And perhaps this is the reason for enabling A20 in the first place – to make sure that only new versions of HIMEM.SYS are allowed to run (and that the installation of Windows 2.1x doesn’t leave DOS with HMA managed by a buggy driver). The collateral damage is that DOS 5 might be incompatible with any device drivers depending on the 1 Mb address wrap-around during initialization (provided that such drivers even exist).
Is there any evidence that “Windows/386 Binary Adaptation Kit” was ever released?
On https://betawiki.net/wiki/Windows_2.x#Windows/386 is written:
“Microsoft did release a DDK for Windows/386, which is currently lost, though it is known to have included WDEB386 (the 386 debugger later used for Windows 3.0 and above) and a linker for the custom object format used by WIN386.386. Unlike the enhanced mode in Windows 3.0 and later, Windows/386 does not support loading VxDs from files. Instead, they are all linked with the virtual machine manager into the WIN386.386 file. In practice, this was meant so OEMs could customize the WIN386 image with the hardware for the machine, though it is not known how widely this was used.”
And this discussion https://www.betaarchive.com/forum/viewtopic.php?t=20324 is interesting as users claims that Windows/386 NEC OEM contains different/custom version of WIN386.386 file.
So perhaps the OEM kit for WIN386.386 really existed?
It must have existed because OEMs needed it to support their hardware. Whether it was “released” is another question. It may have been something that a tiny handful of OEMs got directly from Microsoft on request.