Another rather interesting software artifact surfaced just recently, after more than 25 years since its release: Windows 3.0 Debug Release 1.14 (further referred to as DR 1.14) from February 1989.
This was an alpha version only provided to select ISVs under a non-disclosure agreement as a preview of the future Windows 3.0 product—which turned into a runaway success and made Microsoft king of the software industry. It was first demonstrated at the annual Microsoft Systems Software Forum in February 1989.
The final Windows 3.0 was released in May 1990, more than a year after the DR 1.14 alpha release. Not surprisingly, the released product barely resembles the alpha release; nevertheless, the DR 1.14 release was a quantum leap which convinced Microsoft to split with IBM, go it alone, and take over the multi-billion retail software industry.
What was so special about the DR 1.14 alpha? It ran Windows applications in protected mode, with direct access to many megabytes of memory. Here it may be necessary to go back to the architecture of earlier Windows versions.
Windows 2.x and Windows/386
In 1987, Microsoft released Windows/386 for the Compaq Deskpro 386, followed by the real-mode Windows 2.03. This was a successor to the original Windows 1.x, first released in 1985 after two years of delays.
Normal Windows 2.x, whether called just Windows 2.03 or Windows/286 (2.1, 2.11) was a 16-bit real-mode product, a direct successor to Windows 1.x. Windows applications were restricted by the 640 KB memory barrier, although they could use EMS to gain access to further memory—but only a small window of EMS could be mapped into the CPU’s address space at any one time. That made memory management highly complex and error-prone. Windows 2.03 and Windows/286 could run on any IBM PC, PC/XT, or compatible system. The only minor advantage Windows/286 took of PC/AT compatibles was the addition of 64 KB of high memory.
Windows/386 was Windows 2.x plus a VMM, or a Virtual Machine Monitor. Windows/386 could run several DOS sessions with pre-emptive multitasking, plus one Windows session. While Windows/386 did quite a lot for DOS applications, it did very little for Windows programs. Windows/386 could emulate EMS memory, but Windows applications were still executed as real-mode code, with the same 640 KB memory limitation and EMS complexity. And of course Windows/386 required a 386 machine, which severely limited its potential market in the late 1980s. It also had to fight stiff competition like Quarterdeck DESQview.
Windows 3.0 DR 1.14 Alpha
The beginning of Windows 3.0 was a little skunkworks project of David Weise and Murray Sargent started in June 1988 and presented to Steve Ballmer sometime in late summer 1988. It began as a hack, and DR 1.14 clearly reflects that.
What the February 1989 alpha release did was seemingly not much. It was essentially Windows/386, except it ran the Windows core (KERNEL/USER/GDI) and Windows applications in protected mode.
But that was in fact a big deal, because it removed the highly constraining 640 KB memory barrier. On a (very high-end) system with 4 MB RAM, Windows applications could directly access several megabytes of memory. Windows applications were still segmented 16-bit code, but now ran in protected mode with no need for complex EMS memory paging, and with lots more of them fitting into the system’s memory than before.
The beauty of the solution was that many existing Windows 2.x applications could run in protected mode without any changes whatsoever.
A Closer Look
The DR 1.14 release was obviously hastily thrown together as a technical demonstration, a proof of concept, but not a product. It came on two high-density 5¼” floppies. The setup utility was a simple batch file which copied the floppy contents to a hard disk directory.
There was no device selection—Windows was pre-configured to use an EGA color display and no other drivers were included. There was just enough to get a bare system running, but there were no applets on the disks (Control Panel, Paint, Clock, Reversi, etc.).
However—and this was the strength of this build—most of the applets shipped with Windows 2.x ran unmodified. The segmented memory model of Windows 1.x/2.x was such that it was easy to move to protected mode, although that wasn’t what it had been designed for. Simple, cleanly written Windows 2.x code ran in protected mode unchanged. More complex or dirty code required modifications, often not extensive.
Overall the DR 1.14 release looked very much like Windows 2.1 and did not really resemble Windows 3.0 at all. Microsoft didn’t even bother to consistently change the version numbering: While the debug build marker read “Windows v3.0 Debug Release 1.14”, the About box said “Version 2.1”:
Whereas Windows 3.0, shown below, was known for its attractive looks (at least by 1990 standards), the same could not be said of DR 1.14.
The components of DR 1.14 very much resembled Windows/386 2.1 (1988). There was WIN386.EXE, USER.EXE, GDI.EXE, DISPLAY.DRV, KEYBOARD.DRV, and other familiar modules. But instead of KERNEL.EXE there was PKERNEL.EXE—clearly an allusion to the kernel running in protected mode.
Once again let’s demonstrate the difference between Windows 2.x and 3.0. First, Windows 2.03 with several applets loaded:
And now DR 1.14 with exactly the same applets:
The amount of available memory (1,905K, on a 4 MB system) is still much bigger than what the older version started out with (356K)! That’s exactly why this alpha release was a big deal.
But… and here’s the very big but… all that may not help the user:
Even with megabytes of free memory, DR 1.14 might not be able to start new applications. This may be the same problem that plagued Windows 3.x—numerous internal structures limited by the 16-bit architecture could prevent new applications from being started (or running correctly) even when there was a lot of free memory.
What Was in DR 1.14 and What Wasn’t
It’s useful to go over a list of features that were or weren’t included in DR 1.14.
There was no way to run Windows in real mode. Although WIN86.COM was included, it exited immediately. PKERNEL.EXE was not prepared to run in real mode at any rate (more about that below).
There was no standard mode either, because there was no DOSX. There was only the equivalent of the future Enhanced 386 mode of Windows 3.0 (and a 386 system was naturally required).
The user interface was obviously that of Windows 2.1 and looked nothing like Windows 3.0 (see screenshots above).
The ability to run DOS sessions was missing (no WINOLDAP.MOD).
On the other hand, there was WDEB386.EXE, Microsoft’s system-level debugger for Windows/386. WDEB386 was later used for Windows 3.x as well as Windows 95 and 98, although most developers probably used Soft-ICE at that point (a far superior solution).
Microsoft also helpfully included symbols for the core components—WIN386, PKERNEL, USER, GDI, and the SYSTEM/DISPLAY/KEYBOARD/MOUSE/SOUND drivers.
There was no documentation included on the disks and no headers or libraries. Those may have been shipped separately, but it’s quite likely that DR 1.14 was simply meant as a showcase and as an aid to help ISVs make their existing Windows 2.x code compatible with protected mode. It should be kept in mind that Windows 3.0 continued to support real mode operation, and a well-written Windows 3.0 application should run in either real or protected mode.
The KERNEL exports resembled Windows 2.x, but there were a few crucial additions such as AllocSelector and FreeSelector, AllocDSToCSAlias and AllocCSToDSAlias, __LDTSELECTOR (which promoted all sorts of dirty programming practices), or the famous PrestoChangoSelector.
Running DR 1.14 in a VM
Not surprisingly, running such an unfinished product in a VM or on remotely modern hardware is fraught with difficulties.
The first hurdle is that Windows 3.0 DR 1.14 either refuses to load (“not enough memory”) or crashes miserably on a system with 16 MB RAM or more. That’s easy to fix in a VM, though may be harder in a physical system.
The second hurdle is the DOS version. DR 1.14 refuses outright to run on DOS 5.0 or later and complains of unsupported DOS version. With MS-DOS 3.30, DR 1.14 does start up but never brings up the MS-DOS Executive.
Windows 3.0 DR 1.14 does work on Compaq DOS 3.31 (likely in widespread use at Microsoft at the time), and it also works on MS-DOS 4.01 (the then-current MS-DOS release).
One additional caveat is that DR 1.14 misbehaves very badly when the FILES statement in CONFIG.SYS doesn’t provide enough file handles. FILES=30 appears to be a good amount, but with fewer file handles DR 1.14 may not start at all or applications may randomly crash. Yet another sign of a very unfinished product.
With a suitable amount of memory (perhaps 4, 8, or 12 MB) and the right DOS version and configuration in place, DR 1.14 should come up (assuming one followed the HIMEM.SYS instructions) when started via WIN386.EXE:
Being a debug release, this Windows 3.0 alpha was of course primarily meant for debugging. The supplied D.BAT will just hang on most systems. This one is Intel’s fault and the problem is documented for WDEB386.EXE shipped with the Windows 3.1 DDK. The same instructions accessing TR registers need to be patched out for the WDEB386 executable shipped with DR 1.14.
The issue is that Intel entirely removed those instructions (which existed in 386 and 486 CPUs) from the Pentium and later CPUs, so the debugger triggers invalid opcode exceptions. Fortunately patching out the instructions is harmless.
Once WDEB386.EXE is patched, D.BAT brings up Windows. The serial console (COM1) starts spewing all sorts of interesting stuff:
Map linked (KERNEL) Map linker (USER) Map linked (DISPLAY) Map linked (GDI) WDeb386 - Windows/386 Kernel Debugger v1.62 27.Jan.89 [80386] Win386!DATA(0001)=0028 Win386!DATA(0002)=0030 stop tracing VM break point located at 000F00BC in the system ROM VHIRQD=ON Ctrl+Alt+M is the focus hot key INITIAL REQUEST FOR IRQ 04 (60021FFC) VAD INFO: PS/2 type mouse detected Alt+~ is the focus hot key VDD control block offset of 00000600 VINT33 INFO: No global mouse installed WARNING: Device failed to initialize (DDB = 60022FF4) VMD installed Ctrl+Alt+Del reboot handler VND INFO: Network not installed WARNING: Device failed to initialize (DDB = 60021C60) VNETBIOS VCD INFO: COM 0001 exists VCD INFO: COM 0002 does not exist installed Ctrl+Alt+SysReq break handler Base count = 00002EDB 75% of this is 00002324 Desired moved down to 00000066 KERNEL!IGROUP=017D KERNEL!_NRESTEXT=0185 SYSTEM!DATA(0001)=01C5 KEYBOARD!DATA(0001)=01E5 KEYBOARD!DATA(0003)=01F5
If applications crash (and they will), WDEB386 can be used for diagnosing the problems.
On normal “unbound” development versions of Windows, running KERNEL.EXE directly should start Windows. But PKERNEL.EXE just hangs instead, for a somewhat obscure reason. It invokes INT 41h which is of course a pointer to the disk parameter table and not executable code… except that INT 41h used as a debugger interface (outputting debug strings etc.) in protected mode. If INT 41h is invoked in real mode, nothing good will happen.
As evidenced in the screenshots, DR 1.14 can run most applets shipped with Windows 2.x and the Windows 2.x SDK. One notable exception is Write. Larger applications, such as Excel 2.0, are highly unlikely to work, although only minor modifications might be needed.
Thoughts
The jump from the Windows 3.0 Debug Release 1.14 to the final Windows 3.0 is fascinating to consider. This is a great example of the huge difference between a technology demonstration and a polished product.
It is interesting (and heartening) how old, long lost and unavailable software packages keep turning up. Just as a quick reminder: Multitasking MS-DOS 4.0 from 1986, the original Compaq EMM aka CEMM from 1986, the original Windows/386 2.01 from 1987, and now this.
What else is lurking out there? Probably quite a lot…maybe the original WordStar that caused all the A20 gate hell? Microsoft OS/2 2.0 SDKs? Beta versions of Windows 2.x?
Let’s hope the surviving software is found, and the disks are imaged and documentation scanned before they turn to dust or end up in a landfill.
References
OS/2 for 386 will not be out this year, ComputerWorld, Feb 27, 1989, page 10
“the DR 1.14 release was a quantum leap which convinced Microsoft to split with IBM, go it alone, and take over the multi-billion retail software industry.”
Not in 1989. You may have seen me talk about PX00307 before.
I wonder how the “DPMI” interfaces used in this beta compares to the ones used in final Win3.0.
“only a small window of EMS could be mapped into the CPU’s address space at any one time.”
Do you mean small-frame EMS? What was the difference / requirement between / for small and large-frame EMS?
Small or large frame EMS, the point is that only a (probably small) subset of the EMS memory is accessible to the CPU at any one time.
The difference was that small-frame EMS had a 64K window (with 4 16K pages mapped into that window) while large-frame EMS could support a much larger window, several hundred KB in size. The problem was that the large-frame EMS window was below the 640K line, so it “stole” conventional memory. For that reason, large-frame EMS was never used all that much.
They don’t. As far as I can tell, there’s no DPMI whatsoever in this version. A DOS extender yes, DPMI no.
You can’t think that Ballmer and Gates would have given the green light for this project if they weren’t at least seriously thinking about a plan B… they knew very well IBM wasn’t going to be happy about Windows 3.0. Microsoft’s actions show that they were thinking about going it alone at least as far back as 1988. In June 1990, Windows was a huge success and OS/2 still wasn’t, so the situation came to a head. But that happened as a direct consequence of the decisions made in 1988/89.
But this was based on Windows/386, which means they couldn’t just switch directly to protected mode.
I must point out that EMS 4.0 usage under Windows/286 is more complex than depicted. Any 16KB chunk could be reallocated through EMS except if hardware is using the address including conventional memory above (I think) 256K. This means that a system using monochrome CGA and loading nothing else high could have about 700KB of EMS swappable real mode addresses. 16kB segments could be transferred through any window; larger segments need windows with multiple 16kB pages. Loading high uses up that EMS space and data EMS would take the 64kB (4 contiguous 16kB windows) out of Windows system management.
Large page frame reassigns a complete address space (frequently between 265kB and 640kB). That makes it easy to swap between DOS applications which use up the whole of conventional memory. Windows applications would also swapped in the same way. Great if using Excel or Actor but very wasteful for Clock. Note if using Large Page Frames that address space is also unavailable to the more efficient small page frame remapping.
From a programmer standpoint, EMS handles work very similarly to protected mode selectors. Lots of strange stuff happens behind the scenes but Windows hid most of it. Optimum segment size did change depending on which memory implementation was available.
To state the obvious, Windows/386 always ran entirely in protected mode.
Yea, but I am talking about how PKERNEL.EXE initially ran in virtual 8086 mode inside the system VM.
Yes, there’s a lot that could be written about large-frame EMS. It was a fairly clever scheme and Windows 2.x could take good advantage of it.
The major problem was that it needed either special hardware or a 386. And on a 386, as you say, it was a lot like protected mode–only worse. On a 286, I don’t know of any good way to convert extended memory to EMS. EMS could be used on a PC/XT, but that wasn’t really powerful enough for Windows anyway.
To be honest, this was true about plain old small frame EMS too. What was special about large frame EMS was that it required that conventional memory be removed from the motherboard. Typically this is pretty easy on XTs since the 8088s used a 8-bit bus, but the 80286s used in ATs used a 16-bit bus which often made it more difficult.
It didn’t. PKERNEL.EXE started out in protected mode in a DOS-extended environment.
But I have to correct myself — PKERNEL.EXE does call some kind of INT 31h interface which looks a lot like DPMI. It must have been provided by WIN386.EXE. Only selector management services are used by PKERNEL.EXE.
For VirtualBox:
The following configuration, enables small-frame ems in Windows 3.0:
DEVICE=C:\DOS\UMBPCI.SYS /I=CC00-DFFF
DEVICE=C:\DOS\UMBM.EXE /I=CC00-DFFF
DEVICE=C:\DOS\JEMMEX.EXE I=E200-E2C0 FRAME=E000
The following configuration, enables large-frame ems Windows 3.0, but opening a program causes an JemmEx Exception:
DEVICE=C:\DOS\UMBPCI.SYS /I=CC00-DFFF
DEVICE=C:\DOS\JEMMEX.EXE S=CC00-DFFF I=E200-E2C0 FRAME=E000
In general it’s often advisable to use the matching software releases… such as EMM386 that came with Windows 3.0. Have you tried that?
Since I can’t get at the DR, is it far enough along in the development cycle for the private profiles (system.ini, control.ini, etc.) or still with the monolithic win.ini?
@Yuhong: Motherboard memory does not need to be removed for large page frames. Some EEMS cards would backfill in a way that rendered some motherboard memory inaccessible but the EMS 4 card I had would use the motherboard memory to store an additional large page.
I tried multiple version:
EMM386 4.10.0419 from Windows 3.00a (EMM386.SYS FRAME=E000 ON)
-> Virtualbox hangs.
EMM386 4.33.06x from MS-DOS 5.0a (EMM386.EXE I=E200-E2C0 FRAME=E000 RAM)
-> Only conventional memory in windows.
EMM386 4.95 from Windows 95 / 98 (EMM386.EXE I=E200-E2C0 FRAME=E000)
-> Same behavior as with JemmEx. Large-frame ems, but hangs on program launch.
Whoa! Indeed this is one of the more rare things to have surfaced, and one of the more interesting! It’s really interesting to see these tentative steps for Windows/386 into becoming the unstoppable juggernaut of the industry.
Thanks for the really in-depth look at this ‘missing link’ from Windows/386 to Windows 3.0!
It’s interesting that this then predates the DPMI spec, in that brief window where Windows was going to go it alone in protected mode space, until Ralph Lipe did his DPMI talks.. I suspect if the early 286/dosx.exe driven stuff were to surface it’d be equally difficult to get running on emulation. Although Im still holding out for MS OS/2 2.0 ..
No, just win.ini… apart from PKERNEL.EXE it looks very much like Windows/386 2.1. That actually makes it all the more interesting because in about a year the product got a massive overhaul.
Now I’m really curious about the EEMS backfilling of conventional memory. How did that work? Did it work with all systems? As far as I know, chipsets normally decoded conventional memory as system RAM, so any adapter card trying to claim the same memory range would be out of luck. Anything I could find docs/datasheets for?
The story I heard was that Intel got wind of Microsoft’s plans and basically forced them to play nice with the DOS extender guys. Because Intel understood that the way to selling more 386s/486s wasn’t two or more totally incompatible solutions.
It’s now a really good question when the 286 DOSX showed up. It could have been a spin-off of something that MS already had internally in some form.
My first try, Windows 3.0 with 386MAX 6.02. No prob, large-frame EMS works when running ‘win /r’. With EMM386 from MS-DOS 5.0 (4.33.06X) it works too (EMM386.EXE 4096 I=C800-EFFF). With EMM386 from Windows 3.0 (4.10.0419) it works too (EMM386.SYS 4096 FRAME=E000). This is on DOS 5.0, files dated 11-11-91, with DOS’s HIMEM.SYS (except in the 386MAX case).
Don’t know what I’m doing differently but in each case ‘win /r’ shows large frame EMS and appears to work normally.
I don’t know if this is relevant but I remember back in that era Chips & Technologies had the NEAT, SCAT and LEAP chipsets which could map memory for EMS and shadowing and even map memory into video area if unused (A0000h-AFFFFh if no EGA/VGA, B0000h-B7FFFh if no MDA) so you could actually have up to 736KB conventional memory in DOS.
Which makes me wonder why EGA was not designed to switch the B0000h-BFFFFFh region. On reset, the use of this region would be same as on MDA and CGA, but on running a EGA program the EGA would be told to switch.
Kind of funny when you think about Intel dictating anything to Microsoft, and yet MS was planning this as their ‘plan b’ against IBM… I guess only make one big enemy at a time.
Wasn’t Microsoft a big financier of AMD around the time of the AMD64 stuff?
I fixed it! What a strange bug:
Changing back the Language in Windows Setup to English (American) and it works.
That is odd. The system isn’t crashed either, it’s just stuck and doesn’t seem to react to keyboard input (but mouse works). Now I really wonder what it is that the Language setting does exactly!
So I had a closer look… it turns out that the “language.dll” stuff is extremely poorly documented, but it seems to implement language-specific collation. It’s used by routines such as lstricmp().
The crash/hang is reproducible not just with German but even the “International English” language setting. I had a look with SYMDEB and established that the language DLL somehow gets trashed, which usually results in executing invalid instructions. The problem only happens with EMS; no such thing in plain real mode, standard mode, or enhanced 386 mode. The bug seems to occur regardless of the DOS version used or the memory manager (seen with various EMM386 versions as well as QEMM).
I was easily able to reproduce the same problem with Virtual PC (with a different DOS install and freshly set up Windows 3.0a), which leads me to believe that it’s a bug in Windows 3.0a. I suspect that the large frame EMS setup is something that wasn’t used too often with Windows 3.0.
Windows Premiere edition (a real one) also reared its head up.
Yes, although I haven’t had time to look at it yet. I’m also not sure what the deal was with the previous fake Premiere Edition. I’m also not sure how certain anyone is about what Microsoft did or didn’t release back then. Windows was most famous for being vaporware back then.
I seem to recall that released Windows 3.0 would inspect DOS’s internal file table structures and, if FILES<20, alter them to 30 or 40.
Alternative DOSes like DR-DOS would, in turn, patch WIN.COM's startup code to avoid this.
Windows did this from the beginning, and Larry Osterman mentioned how they had to deal with this when they did multitasking MS-DOS 4.0.
@Yuhong Bao,
Wasn’t this work for the non-multitasking MS-DOS 4.0?
I’ve never been able to get Windows to start in multitasking MS-DOS 4.0; in theory, real mode Windows and multitasking MS-DOS are providing too many of the same things, and probably in incompatible ways.
The original dilemma is a tough one: you don’t want to require end users to change to FILES=40, since that chews up memory, and isn’t needed when Windows isn’t running. But DOS (during the 2.0/3.0 era) provided no consistent way to add more file descriptors.
In my opinion, adding a new INT 2Fh call to resize the descriptor table would make the most sense, and if the call wasn’t resident, WIN.COM could stub it out.
But generally speaking Windows wasn’t written with an eye towards compatibility with future DOSes.
Larry Osterman specifically says that it was the multitasking one and ICL in fact bundled it with Windows.
hey guy tried windows 3.00.14 on dosbox or virtual box, i want to know
I don’t understand the question. All I can say is that the screenshots in this post were taken with VirtualBox.
yes
Hey Michael how you Windows 3.00.1.14 alpha worked on VirtualBox
because i try Windows 3.00.1.14 alpha on VirtualBox it don’t work, please show me
@Joshua
Multitasking MS-DOS 4.0 is too different from regular DOS for Windows to work. Some info about it is here – https://sites.google.com/site/pcdosretro/multitaskingdos4
There was no call to increase the number of system file tables (the FILES= structures) because you normally wouldn’t do this and if you did the memory would have to be guaranteed not to ever be released. The DOS data area has 5 SFTs builtin since it needs a few for processing CONFIG.SYS, the rest are added in a block after the DOS data area along with the FCB system file tables (FCBS), buffers, current directory structures (the LASTDRIVE tables) and the system stacks if STACKS=0,0 wasn’t specified. Of course Microsoft never followed their own standards so Windows did all sorts of stuff.
Windows wasn’t written with an eye towards compatibility with future Windows.
windows compatibility date back to first windows 1.0 in 1983
windows 1.0 was flop because real mode dos and took windows long time become successful in marketplace
it harder to get window 3.00.1.14 alpha working on modern emulator like dosbox, virtualbox or qemu without a patch files
@dosfan @Yuhong Bao
Has anyone seen multitasking MS-DOS 4.00 working with Windows (or some subset of Windows)? It seems obviously possible; basically multitasking MS-DOS would take over pretty much everything that WIN.COM and the KERNEL.EXE part of WIN200.BIN do.
When WIN.COM adds more entries to the SFT when FILES=20, what happens when WIN.COM exits? I thought it put the old file table back.
@Joshua
WIN.COM removes the additional SFTs it added from the SFT linked list. The additional tables are only present while WIN.COM is running. Theoretically any program can extend the SFTs but imagine if a program erroneously exited without removing the additional tables and it got overwritten by another program. Once DOS needed to open enough files the system would likely crash. FILES=20 was usually enough for DOS, Windows needed to open more files which is why it increased the number of SFTs. Also don’t forget the SFTs were not documented so most programmers of the time had no idea how to do this.
I can’t imagine Windows 3.x running under Multitasking MS-DOS 4.0, the internals are just too different from standard DOS and Windows definitely pokes around in DOS data structures.
windows 3.00.14 alpha based on windows386 code
i think it something do with win386.exe
because i try type windows 3.00.14 alpha win386.exe on VirtualBox but it crash
i’am using ms-dos 4.01 from 1989
@dosfan: If the various materials I have read are correct, there was a modified early Windows that ran on multi-tasking DOS. Nothing precluded doing the same for Windows 3 except it wouldn’t make much sense; applications could either be multitasked by MT-DOS real mode multitasking or in V86 form by Windows. Either way, a lot of excess code would be included in the system for the multitasker that is not used. Rewriting both MT-DOS and Windows 3 to move the V86 code from Windows into MT-DOS would have been needed.
the only Multitasking MS-DOS 4.0 with windows 1.03 is Multitasking MS-DOS Version 4.10 Fujitsu ICL OEM from 1987
It’s working for me here, with or without hardware virtualization… after making all the tweaks described in the article.
@Richard Wells
Windows 3.0 was still missing a lot of things that Multitasking DOS 4.0 provided, like named pipes, semaphores, and (I believe) preemptive multithreading.
that is true
As a side note, I think IBM DOS 4.0 and later also had a different SFT entry size. I wonder how they dealt with it.