Now that we’ve moved beyond the initial shockwave of the MS-DOS 4.00 source code dump, I thought it was time to try to pull off the ultimate trick of the time, building under OS/2 and using the exciting feature of the time “DOS from Drive A:” Long before VMware / Virtual PC for the PC OS/2 took Intel’s 80386’s hardware virtualization mode, “v86 mode” to the logical conclusion allowing you to boot native MS-DOS under OS/2. Sadly, the old 1989-1991 OS/2 betas do not include this feature. Although I have to wonder if it did exist and just wasn’t publicly available.

Many of the programs used to build MS-DOS are off the shelf, the MASM assembler, Microsoft C 5.1, and its associated tools are just retail versions. To change things up, I did use the 386MASM assembler just to see if it maintained MASM 5.1 compatibility. And it does. The only gotcha is that all the tools are *NOT* marked Presentation Manager compatible, so launching them from a window opens a full screen session. Very annoying!

I’m guessing the fix is in a toolkit? Either way, in Microsoft C 6.0, the utility exehdr lets us modify an OS/2 executable so it’ll now be WINDOWCOMPAT. So at least it ‘feels’ better now.

One thing is for sure, building DOS under OS/2 is a lot more enjoyable than doing a native build as you can minimize the build task, although the MS-DOS only programs do pop up when it generates text indexes & tables. But you do retain some control of your machine during the build, which is great! Although E is a terrible editor for source code, and the one in 6.78 has a nasty bug where it’ll truncate large files. Were people really using text mode editors for everything back then? I guess i like the fonts of the GUI, despite having used machines of the era.

Otherwise, the end result is the same, you get a build of DOS 4.

I went ahead and tried to build using 6.78 and no doubt compiling DOS is an absolute torture test. So far, the DOS Box has locked OS/2 once, and PM Shell has crashed once as well.

I altered the Makefiles to use ‘rm’ instead of the built in ‘del’ command, because if you try to delete a file that doesn’t exist, del returns an error, which then triggers an end to the NMAKE process. Very annoying! However, the ‘rm’ included in Microsoft C 5.1 doesn’t suffer the same defect. Using 86Box with an 83Mhz Pentium OverDrive it took about 18 minutes to build DOS-4.

I did capture the video and converted it to a GIF so you can quickly see the reboot & the UI crashing. FUN!

And it even boots!

For anyone interested I’ve put zips on archive.org that can be extracted under OS/2. I also made a pkzip disk set incase loading a 6MB zip file is an issue.

Building MS-DOS 4.00 under OS/2 2.x : neozeede : Free Download, Borrow, and Streaming : Internet Archive

have patience. It does work. Even booting from the SPOCK SCSI CARD which all the other DOS4 images all failed.

The best way for a native build is the zip in the releases.

Release Now can boot from hard disk! · neozeed/dos400 (github.com)

With a 16Mhz 80386 it took 70 minutes. I just formatted a blank image on the gotek, copied IO.SYS, MSDOS.SYS and COMMAND.COM, then rebooted. went back to the compiled DOS 4, and re-formatted the floppy as a system disk so the attributes are set. (DOS 5 lets you change system files), and yeah. It can be done!

Let me spell out the steps, in this case I’m going to use Windows 10. I use the git from the WSL (Windows subsystem for Linux) I have DOSBox mount c:\dos as my c: drive . ZIP/UNZIP are Info-ZIP versions, you MUST have the Win32 native version!

- md \dos
- md \dos\temp
- wsl git clone https://github.com/microsoft/MS-DOS
- cd MS-DOS\v4.0
- zip -r \dos\temp\src.zip src\*.*
- cd \dos
- unzip -a -LL temp\src.zip
- start dosbox
- cd \src
- edit setenv.bat to reflect the paths:
  set BAKROOT=c:
  set LIB=%BAKROOT%\src\tools\bld\lib
  set INCLUDE=%BAKROOT%\src\tools\bld\inc
  set PATH=%PATH%;%BAKROOT%\src\tools
- setenv
- nmake
it will then fail in mapper on getmsg.asm change the 3 chars to a '-'
- nmake
- cd ..
- nmake

It will then fail building select

- edit select2.asm
- edit usa.inf
- nmake
- cd ..
- nmake

and now it’ll be done compiling.

continuing from dosbox, you need a 1.44mb fat formatted disk image somedos144.img . I used a dos 6.22 diskette, it needs the bootsector already in place to load io.sys/msdos.sys

- cd \src
- md bin
- cpy bin
- imgmount a somedos144.img -t floppy
- a:
- del *.*
- copy c:\src\bin\io.sys
- copy c:\src\bin\msdos.sys
- copy c:\src\bin\http://command.com
- boot -l a:

And now I’ve booted MS-DOS 4.00 from within DOBOX!

Also as interest to most people there is a bug in msload.asm, where DOS 4.0 won’t boot on a lot of machines, from VMware, Qemu and even my PS/2. It’s a small fix to the IO.SYS initial stack being too small. Props to Michal Necasek for the fix!

For further guidance here is a video spelling it all out:

I’ts MS-DOS 4.0 Internal Work #2.06 – May 23, 1984, with copyrights from both IBM & Microsoft.

I don’t have time to make any comment much further other than having had been listing to people in on making this happen, and it’s been a long struggle to make this all happen, and it’s so amazing to see their hard work make it out into the wild!

DOS 4 is the basis of what would eventually become OS/2, just as I’m sure that it’s use of NE executables will reveal a far tighter integration with Windows, giving hints of the future that should have been!

Hopefully, like the LINK4 support I had stumbled onto a while back, we can build more robust applications!

** EDIT So it’s just DOS 4.00, with a lot of information on EU/MT DOS4. There is now a blog post over on Scott Hanselman – Scott Hanselman’s Blog‘s talking about the details of this release!

Credit goes to starfrost, this was nearly a year in the works!

*** EDIT it’s now live over on cloudblogs.microsoft.com, Open sourcing MS-DOS 4.0

Ive been able to bulid it from source, and I put up the changes on github (really minor changes)

neozeed/dos400: Microsoft DOS 4.00 (github.com)

And unfortunately, nobody has been able to get ahold of Paul Radek to see if he’d be okay with any kind of open-source license. So, sadly DMX has been a long-standing stumbling block for that ‘authentic’ super vanilla DOS DooM.

Enter the Raptor

Fast forward to a few days ago, and I come across dosraptor on github. I had a copy of this back in the day, it was bundled on CD-ROM or something. I am absolutely terrible at games like this, but I did remember this one being incredibly fluid, and fun despite me having no skill. Raptor was written by Scott Host, and it’s still on sale over on steam! The source had been cleaned up with help from skynettx, nukeykt and NY00123.

I went ahead and built it from source, and in no time I was up and running. I found Watcom 9.5 was the best path to go with. I even made a ‘release‘ for those who don’t want the joy of building from source, and of course picked up a copy on both steam and his site. While building the source code, and looking at the directory tree that’s when I noticed apodmx:

This is a DMX sound library wrapper, which is powered by the
Apogee Sound System, the latter being written by Jim Dose for
3D Realms. When used together, they form a replacement for DMX.

The DMX wrapper was written by Nuke.YKT for PCDoom, a DOS port
of id Software's Doom title from the 90s.

It also includes the mus2mid converter, contributed by Ben Ryves for
Simon Howard's Chocolate Doom port, as well as the PC Speaker frequency table, dumped by Gez from a DOOM2.EXE file and later also added to Chocolate Doom.

A few years later, this wrapper was modified by NY00123; Mostly to be built as a standalone library, while removing dependencies on game code.

So it turns out that Raptor used DMX, just like DooM!

Well, isn’t that incredible!

Now the first question I had, was apodmx a direct drop-in replacement for DMX? Well basically, yes! Let’s check out the Adlib driver!

The Apogee Sound System is softer, and not quite the same as DMX, but compared to nothing I’m more than happy with it. The AdLib is kind of a weird card to drive, and I guess it’s not to surprising that there is such a variance.

How about a Roland Sound Canvas?

Sadly, mine is inaccessible, but thanks to nukeykt there is the Nuked-SC55: Roland SC-55 series emulation. I had to setup the MidiLoop as expected, and configure DosBox for the Loop and now I have a virtual Sound Canvas. So let’s see how the two engines deal with a common instrument!

Pretty cool, if I do say so myself.

I’ve uploaded my modifications to github, along with a copy of that old ZeeDooM I had slapped together ages ago. I’d taken the map source code from Romero, and the graphical/audio resources from Freedoom and slapped them together.

From cracyc and roytam’s fork, I have incorporated a correction.
These include file access using FCB and fixing exceptions around the FPU of the MAME version of the i386 core.
In addition, the DAA/DAS/AAA/AAS/AAM/AAD instructions of the MAME version of the i386 core have been modified based on the DOSBox implementation.
With the Pentium 4 version, the testi386.exe is the same as the real thing.

The I386 core of NP21/W has been updated to equivalent to ver0.86 rev92 beta2.
Also, fixed the build time warning so that it does not appear.

Improved checking when accessing environment variables, referencing incorrect environment tables.
Recent builds have resolved an issue that prevented testi386.exe from working.
Improved the efficiency of memory access handling.
Basic memory, extended memory, and reserved areas (such as VRAM) can be accessed in that order with a small number of conditional branches.
The processing speed may be slightly increased.

MS-DOS Player for Win32-x64 Mystery WIP Page (coocan.jp)

Takeda has been very busy indeed!

I don’t want to complain or anything, I’m very thankful for the tool. It’s just so amazing.

but on my Windows 10 install I have so many issues relating to the font/screen changes, that I just made an incredibly lame fork, and commented out those changes, msdos-player_. I stumbled onto the issue by accident by redirecting stdout/stderr, and compiling stuff ran fine, but as soon as it started to mess with the console it’d just crash.

OK so you can run some basic stuff like compilers, but what about ORACLE?!

I did have to subst a drive, as I didn’t feel like dealing with paths and stuff, I had extracted it from oracle-51c-qemu, and modified the autoexec & config.ora and yeah, using the 386 or better emulation it just worked! Sadly there is no network part of the install, although there is a SDK so I guess there ought to be a way to proxy queries.

OK, but how about something even more complicated?! NETWARE!

Obviously there is no ISA MFM/IDE disks in MS-DOS Player, but the server loaded!

Needless to say this update is just GREAT!

I’d say try the one hosted on Takeda’s site! It’ll almost certainly work fine for you. Otherwise I guess try mine. Or not.

Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.

Ever since I got my first 286 board way back in the early 90’s (1990? 1991?) I have been intrigued by the whole protected mode of operation. Unfortunately, in the era the required tools were way out of my reach, and of course were not available at retail. But now I live in the future where I have all the parts! Let’s look at the needed parts

• IBM PS/2 model 60
• Microsoft C 6.00a
• Phar Lap 286|DOS-Extender
• Space Quest II

I have to once more again thank my patrons, and people tolerating the google ads as it made all the difference in being able to buy all this stuff. And now is as good a time as any other to put it all together.

I stumbled upon this repo on sourceforge, Sarien. It included a Turbo C++ port, which is pretty exciting! So, this became my goal, get Sarien running on Phar Lap 286.

Installing Microsoft C requires you to pick and choose both hosting, targeting environments, along with what the preferred libraries are. In the business we call this foreshadowing as this can be such a giant PITA. At least virtual machines are fast, plentiful, and cheap. In addition I had been using MS-DOS player to host the tools on Windows 11. This of course proved weird later.

The first step was getting it running on MS-DOS using Microsoft C 6.0a. This was actually pretty easy, the hard part was working out the makefile, as some files don’t compile with optimisations. And overall, the project doesn’t seem to work with /Ox at all. I haven’t spent enough time mixing and matching settings to find what actually doesn’t work, but I’m in a hurry, and /Os seems to work just fine.

In no time I had both the CGA & VGA drivers up and running and verified working on my PS/2. Great!

Now comes the fun, getting it ready to run on Pharlap.

Phar Lap’s 286|DOS-Extender is pure magic. A DOS extender is a special program that can load a protected mode program into memory on a 286 or better computer and run it. At it’s heart, it can proxy MS-DOS functionality from protected mode to real mode, allowing you to use a lot of methodology and code from traditional real mode code. Phar Lap, goes beyond that by providing a pseudo OS/2 1.2 environment on MS-DOS, including advanced features like DLL’s, and being able to use ALL the RAM in your computer. Of course on the 286 there is a massive caveat:

The 286 has no built-in function for switching from protected mode to real mode. This makes programs that rely a LOT on MS-DOS potentially very slow. You can absolutely feel the difference between the real mode and the protected mode version of Sarien.

Phar Lap does include a test program, swtest which can benchmark the switching methods, so let’s run it and get some scores.

Switch code version = 1.14
BIOS signature: BA66CC86
BIOS date: 02/13/87

Machine ID = 0, A20 method = PS2, Reset method = Standard
Starting test for Switch Mode 3 (SLOW) ... Test complete.
Avg switch time (usecs): To prot = 34, To real = 101, Total = 135
Min switch time (usecs): To prot = 32, To real = 98, Total = 130
Max switch time (usecs): To prot = 35, To real = 103, Total = 138

Machine ID = 0, A20 method = PS2, Reset method = Standard
Starting test for Switch Mode 2 (AT) ... Test complete.
Avg switch time (usecs): To prot = 34, To real = 86, Total = 120
Min switch time (usecs): To prot = 33, To real = 83, Total = 116
Max switch time (usecs): To prot = 36, To real = 88, Total = 124

Machine ID = 0, A20 method = PS2, Reset method = Standard
Starting test for Switch Mode 1 (SURE) ... Test complete.
Avg switch time (usecs): To prot = 34, To real = 70, Total = 104
Min switch time (usecs): To prot = 32, To real = 68, Total = 100
Max switch time (usecs): To prot = 35, To real = 72, Total = 107

For those of you wondering what the timing is like on a 386, here is my 16Mhz PS/2 Model 80 board (now with fully 32bit memory)

Switch code version = 1.14
BIOS signature: 039D2DB4
BIOS date: 03/30/87

Machine ID = 0, A20 method = PS2, Reset method = Standard
Starting test for Switch Mode 5 (386) ... Test complete.
Avg switch time (usecs): To prot = 31, To real = 22, Total = 53
Min switch time (usecs): To prot = 30, To real = 20, Total = 50
Max switch time (usecs): To prot = 32, To real = 23, Total = 55

I’m honestly surprised the 286 switches from protected back to real so quickly! Although as you can see from the 386 timings it’s significantly faster than the 286.

Here is a quick video, real mode on the left, protected mode on the right. Yes I need to get a VGA capture card. Sorry.

Being a DOS extender it does have built in functions for things like hooking interrupts like this:

    /* install our new timer tick routine */
    DosSetPassToProtVec(IRQ0, (PIHANDLER)new_prot_timer_tick,
        &old_prot_timer_tick, &old_real_timer_tick);

Unlike some kind of OS/2 method which would involve creating a thread and or timers.

Setting video modes via the video BIOS is also supported, using the built in int86 style calls:

    memset(&r,0x0,sizeof(r));
    r.h.ah = 0;
    r.h.al = 3;
    int86(0x10, &r, &r);

Using pointers into things like video ram do require ‘asking for permission’ but it’s not too involved:

    int rseg;
  /* Get PM pointer to text screen */
    DosMapRealSeg(0xb800,4000,&rseg);
    textptr=MAKEP(rseg,0);

with the segment mapped, and a pointer to the segment, and now I can read/write directly into video RAM!

  /* save text screen */
    memcpy(textbuf,textptr,4000);

Just like that!

I’m not sure what I screwed up on the VGA graphics, as it doesn’t work correctly, but oddly enough CGA does work.

And now this is where everything goes off the rails.

It ran fine on emulation. So all excited I fired up the PS/2 and….

This lead me to more fun in how on earth to debug this. Of course Phar Lap 286 version 2.5 requires me to have Microsoft C/C++ 7.0. I shamelessly downloaded a disk set from pcjs.org. You actually need to install it, to copy out the files required:

• 28/05/1991 05:37 pm 47,216 CFIG286.EXE
• 26/11/1991 11:19 am 13,531 GORUN286.EXE
• 19/03/1992 04:00 am 42,720 shw0.dll
• 19/03/1992 04:00 am 105,039 eew0cxx.dll
• 19/03/1992 04:00 am 410,112 cvw4.exe
• 19/03/1992 04:00 am 91,118 eew0can.dll
• 19/03/1992 04:00 am 74,400 emw0w0.dll
• 03/08/1992 09:34 pm 2,649 INT33.DLL
• 03/08/1992 09:40 pm 2,718 MSG.DLL
• 03/08/1992 09:40 pm 1,702 NAMPIPES.DLL
• 03/08/1992 09:42 pm 2,073 NLS.DLL
• 03/08/1992 09:43 pm 5,184 PTRACE.DLL
• 03/08/1992 09:45 pm 2,320 SESMGR.DLL
• 03/08/1992 09:50 pm 1,508 WIN87EM.DLL
• 05/08/1992 12:04 am 3,100 KEYBOARD.DLL
• 05/08/1992 06:33 pm 270 TOOLHELP.DLL
• 14/08/1992 07:38 pm 7,891 KERNEL.DLL
• 14/08/1992 09:40 pm 14,545 USER.DLL
• 09/09/1992 10:59 pm 209,922 RUN286.EXE
• 09/09/1992 10:59 pm 229,046 RUN286D.EXE
• 14/09/1992 11:01 pm 14,024 TLW0LOC.DLL
• 17/09/1992 07:26 pm 34,152 CVP7.EXE

While CVP7 does come with Phar Lap, you have to run it via run286. As you may have noticed there is a mixture of OS/2 and Windows DLL’s in here, as at this point CodeView was a Windows protected mode debugger. The divorce was in full swing, and Microsoft C/C++ 7.0 had amputated the majority of OS/2 support. I’m sure all this is in the manuals, however all I have is disk images. There was no C 6.0a supported hosted debugger. Maybe it’s in the v1/v2 of Phar Lap 286, but I only have 2.5. There is version 3 files on the internet but I wanted to stick to 2.5.

And this is all I got. Yes, I did recompile with ‘/Od /Zi’ along with using cvpack on the executable. Yes, after copying the source to the PS/2 I was able to see the source line mapping, but it immediately jumps to assembly and GP Faults. All this is fine, but IT RUNS UNDER EMULATION.

What is going on?!

I asked around on discord, and found someone willing to test on their 286. It also crashed. I tried VMware and .. it crashed too! So did 86box! Ok now we’re going somewhere!

Since I had been using MS-DOS player to run the tools, I had an issue with the linker in C 6.0a crashing, so I tried the one from C/C++ 7. It also didn’t work. I tried the one from Visual C++ 1.5. It also failed. Almost giving up on the entire thing, since I had copied the source code to the PS/2, I tried something really silly, I compiled it using the /qc or QuickC flag. I wasn’t too worried about sizes as again I’m going to run in protected mode. It took some 20-30 minutes to compile, as 10Mhz machines are not the best for building software in this modern age. Much to my surprise it actually ran.

This was kind of shocking as I’m not sure what I screwed up to not get this to work, but it worked! I went ahead and changed the build to not use QuickC, but rebuild with /Os (Optimize for space). It took about an hour. And it too worked.

Shockingly it runs! I’m not sure what on earth is up with the linking. I did find it easier to just rebuild on Qemu since it can easily map into my source directory and copy everything over and re-build very quickly.

Later I did try copying over compiled objects built using the MS-DOS Player, and linked them natively, and they ran fine.

What is it with the LINK?!

One weird thing on 86box is my pre-built machine I was using has a 5 1/4″ 1.2Mb floppy for the A: drive. It’s too small to fit MS-DOS, the game data and Phar Lap 286 all on there. Although Stacker to the rescue and it fits!

I removed a lot of Unix quality of life, to make it more MS-DOS dumping everything in the same directory so you can save & load games.

Assuming anyone is interested in this at all, I have the source up on github. I’ll follow up with some performance videos showing how much slower real vs protected mode is, along with some binaries/demos. A 5 1/4″ floppy disk image can be downloaded here for any suitable emulator.

I’d never seen this one before, but attempting to boot up PC-DOS 4.00 or 4.01 on my PS/2 model 60, with 7 virtual disks attached, all I get is a single smiley/happy face, ASCII 1 ‘’ on boot.

MS-DOS 5.00 doesn’t care.

While trying the Apricot MS-DOS 4 set I got on eBay, it boots from floppy disks, crashes trying to boot from the hard disk, and trying to run fdisk just causes a divide by zero error.

run-time error R6003
- integer divide by 0

I’m a bit reluctant to rip the whole machine apart as SD card extension cables don’t work for me which is even more annoying. Didn’t people buy big machines and put in a LOT of disks to just run MS-DOS? Even a Netware server still requires MS-DOS to boot.

Is my 286 just too weird?!

I’m not sure if it’s worth following up, but it is perplexing. Maybe I need to rename all my disks, and stick with whatever was actually selling in 1987. And sadly that means not fully loading it out.

As of this moment, this is the oldest version of 86-DOS surviving in the wild. The prior version was 0.34. You can download a disk image over on archive.org. Thanks to F15sim for providing the uploads!

Getting this running was a little involved as I first had to build open-simh, I just used the Windows Subsystem for Linux (WSL) to build the altairz80 emulator. With the emulator built, you’ll need the BIOS 86mon.bin from schorn.ch as 86dos.zip. In the archive you’ll find 86-DOS 1.0 in the zip file. Simply editing the file 86dos and specifying the 0.11 download (I renamed it as it’s too long and too many spaces!) and you’ll be able to run 86-DOS.

There isn’t much on the diskette:

• COMMAND COM
• RDCPM COM
• HEX2BIN COM
• ASM COM
• TRANS COM
• SYS COM
• EDLIN COM
• CHESS COM
• CHESS DOC

There is a simple chess game, although I’m not much of a player..

A:chess

Choose your color (W/B): W
Ply depth (1-6): 1
E2-E4
e7 e5

There is no source code in this disk image, but there is some stuff on the 0.34 image.

Just a quick post in that middle of the night.

I thought I’d slap together some github thing with MS-DOS 2.11 that’s been made buildable thanks to a whole host of other smart people. The default stuff out there expects you to build it under MS-DOS using the long obsoleted ‘append’ utility which can add directories to a search path. Instead I created a bunch of makefiles that take advantage of MS-DOS Player, and let you build from Windows.

dos211: just the MS-DOS 2.11 sources, I re-aranged stuff and made it (slightly) easier to rebuild on Windows. (github.com)

building should be somewhat straightforward, assuming you have the ms-dos player in your path. JUST MAKE SURE YOU UNZIP as TEXT mode. If you are getting a million errors you probably have them in github’s favourite unix mode.

D:\temp\dos211-main\bios>..\tools\make
msdos ..\tools\masm ibmbio.asm ibmbio.obj NUL NUL
The Microsoft MACRO Assembler , Version 1.25
 Copyright (C) Microsoft Corp 1981,82,83


Warning Severe
Errors  Errors
0       0
msdos ..\tools\masm sysimes.asm sysimes.obj NUL NUL
The Microsoft MACRO Assembler , Version 1.25
 Copyright (C) Microsoft Corp 1981,82,83


Warning Severe
Errors  Errors
0       0
msdos ..\tools\masm sysinit.asm sysinit.obj NUL NUL
The Microsoft MACRO Assembler , Version 1.25
 Copyright (C) Microsoft Corp 1981,82,83

DOSSYM in Pass 2

Warning Severe
Errors  Errors
0       0
msdos ..\tools\LINK IBMBIO+SYSINIT+SYSIMES;

   Microsoft Object Linker V2.00
(C) Copyright 1982 by Microsoft Inc.

Warning: No STACK segment

There was 1 error detected.
msdos ..\tools\exe2bin.exe IBMBIO IBMBIO.COM < 70.TXT
Fix-ups needed - base segment (hex): 70
del -f ibmbio.obj    sysimes.obj   sysinit.obj ibmbio.exe

D:\temp\dos211-main\bios>

As an example building the bios by running make. For the impatiend you can download dos211.zip, which includes a bootable 360kb disk image, and a 32Mb vmdk!

So, a while back I had found this up on eBay. As much as I’m trying not to buy old stuff I just couldn’t resist. And the price was just too good, I’d just have to forego going out to dinner for a week.

While looking around for something on Microsoft C, I stumbled upon this promo video for Microsoft C 6. Naturally I had to share it!

I had been using it to mess around with a poorly ported Hack 1.03, although I haven’t done much with that in a while.

One thing is for sure, that the old MS-DOS memory limits were becoming more and more of an issue. Sadly, they didn’t include the QuickC for Windows product which had the benefit of building in protected mode for access to far more memory, nor did they include any DOS Extender to even allow larger runtime access. Obviously you were expected to run this under MSOS/2 1.2 in this era. Although targeting OS/2 protected mode allowed easier integration with PharLap’s 286 based DOS Extender.

Since this was the OS/2 era, the Windows 3.0 SDK was a separate product.

There was another release, the 6.00ax version which included a DOS Extender, allowing the compiler to access 16MB of ram, as reported in this leaflet in a combined Microsoft C & Windows 3.0 SDK package.

The followup Microsoft C/C++ 7.0 addressed many of these shortcomings, but of course famously removed targeting OS/2. There was a later update that at least provided OS/2 compiled version of the binaries allowing you to run it under OS/2. I never tried to see if it could be paired with the OS/2 SDK, and manually made to generate OS/2 executables. I suspect not.

The larger thing is that Microsoft C 386 remained a ‘hidden’ product on Xenix, and the 32bit OS/2 and NTOS/2 betas.