640K ought to be enough for anyone. Well I’ve been poking around with an old beta that I had a long long time ago, lost, found, lost again, recovered, lost and found while looking for something entirely different again. I’ll spoil it later but anyways while messing around I needed a MS-DOS client, and it needs the MSNET TCP/IP stack, not to be confused with the LANMAN TCP/IP stack, and it doesn’t work with the Windows for Workgroups stack either. So yes I setup all 3, and of course found out that it really was the worst of the 3, the MSNET one.
Anyways convential memory is below 1MB. Back when the PC was new, it seemed that going from an Intel 8080 processor that could addresses a mere 64kb of RAM to the IBM PC that could address a whopping 1MB it seemed unlimited. A decision was made to segment the machine into 640kb for user programs reserving 384kb of RAM for hardware.
And then something happened where drivers became user programs, and suddenly loading a mouse driver, CD-ROM driver, audio driver, networking stack and you have not enough memory available. Welcome to the living hell that was 1988-1995. In this virtual machine although it has 64MB of RAM in MS-DOS the largest free space with everything loaded is 366KB.
Microsoft Windows and DOS (among other products) started to include this fun tool MSD, Microsoft Diagnostics that would let you explore your memory, to see what was actually in use.
Imagine the absolute frustration here. 64MB of RAM, and yet there isn’t enough free to run a simple program. HOW ANNOYING!!!
Looking back at the MSD memory map, you may noticed from the map there is memory available, and possibly available. What does that mean? It means that there is no ROMS, or device RAM in use currently using that hardware reserved memory. Sadly for the 8088/80286 users they either don’t have a MMU, or one that only really works for protected mode segmentation. The 80386 however had a MMU sophisticated enough to let you map whatever you wanted where by booting MS-DOS into a protected mode environment and using v86 mode to map whatever you wanted where, by using the included program emm386.exe I’m sure plenty of others have touched on this program, and I’m going to just make a quick glance at it.
If you look at a typical PC memory map you’ll find that location A000-AFFF is actually reserved for graphics memory. Since we are using VGA that also means B000-B7FF is also available. that means for text mode programs we can open up all this RAM for smaller program & driver use, along with the memory after the VGA BIOS, until the ROM BIOS of the computer that’s CC00-CFFF in my case, with D000-DFFF and E000-EFFF also being open. Obviously the fun comes in that not every PC has the same peripherals ROMS installed so this isn’t guaranteed to work in every instance.
In my case I don’t need EMS emulation at all I want to map it all to UMB or upper memory blocks for drivers and TSR’s. So I load emm386.exe into the config.sys like this:
DEVICE=C:\DOS\EMM386.EXE NOEMS I=B000-B7FF I=D000-DFFF I=CC00-CFFF I=D000-DFFF I=E000-EFFF
I didn’t put in any exclusionary ranges as EMM386 figured it out all on it’s own in MSD, but you may need to specify ranges to leave alone.
This gives me 519KB of free conventional RAM. Oddly enough a lot of the networking stack moved itself into UMB without me having to do anything. It’s probably more so a function of the MSNET I used from a Windows NT 3.5 Server CD-ROM being dated 1994, so I didn’t have to play with the load high command.
Back when the PCem forum was up I had this config, although keeping in mind that although it was far more aggressive!
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE 4096 frame=d000 x=a000-afff i=b000-b7ff x=b800-bbff x=c000-c7ff i=c800-cfff i=e000-efff ram
DEVICEHIGH=C:\DOS\CD1.SYS /D:CDROM01
DEVICEHIGH=C:\DOS\SETVER.EXE
DEVICEHIGH=C:\DOS\ANSI.SYS
DOS=HIGH,UMB
FILES=40@ECHO OFF
PROMPT $p$g
PATH C:\DOS;c:\windows
SET TEMP=C:\TEMP
LH MSCDEX /D:CDROM01
LH SMARTDRV
LH IDLE
LH DOSKEY
LH SHAREThis got me a whopping 619Kb free in MS-DOS, along with 4MB of EMS, and 12MB XMS (on a 16MB config).
In the spirit of the old ‘Linking the linker‘ (I’m not certain that this is the actual article but it does certainly read the same way, didn’t Tim have 2 blogs?), I went ahead and claimed the video memory for the heck of it.
Obviously you cannot run graphical programs, but 605kb of conventional RAM, wish some 206Kb worth of network drivers! Not bad. I could probably squeeze a 32kb EMS frame in there, and get what would be an incredible 1-2-3 machine for the era. But I’m not such a big Lotus 1-2-3 fan anymore.
As always it’s 2021, and normal people will glance and WTF, you have 64MB of ram how can you be fighting for kilobytes. Anyone that used MS-DOS based networking will cringe and look the other way. These were not happy times.
In other news the client ran, sadly it’s too new for the server.
In another forum about this recently, somebody mentioned that it’s possible to completely remove the graphics card, add a TSR to redirect output to COM1 or similar, and operate DOS with ~900Kb of conventional memory. I haven’t done it yet, and obviously it’s not much use for an ICA client, but for doing things like building Word for Windows it makes a lot of sense. Apparently people did this with two physical computers once, although with VMs it shouldn’t even be that unnatural.
I’ve heard of people using a custom BIOS that’d have int 10 baked in for support over serial ports. But for sure even with a TSR you could then open up all the video memory for sure.
There was that infamous “Linking the linker” article I can’t find that used a tarbell machine that didn’t have ISA or video cards so it had something crazy like 900kb of conventional RAM.
Then you had DPMS and QEMM with even more crazy tricks like stubbing the BIOS to a protected mode image, and allowing you to use the 64kb of ROM space. I think it was stealth mode?
And of course Helix’s Multimedia Cloaking.
It’s no small wonder that DOS Extender took over the entire market.
I remember the “Linking the linker” article, too, and I’ve been trying to find it again, but it seems to have fallen off the Internet somehow…
it must be this one!?
That claim seems curious. For one, addressing more memory doesn’t need a 386 with 32 bit tools, it needs a 286 with protected mode tools, and in 1988 either OS/2 or Xenix/286 would have worked fine.
The other curious thing is that software grows over time, and this machine would only be useful at a particular point (requires >640Kb but <1Mb.) If the linker in 1987 or so needed this much space, did it still need that much space in 1982? This claim only makes sense to address a very short point in time. It makes one wonder what the S-100 was doing from 1981-1985.
I can’t imagine as the tools for Xenix are just ports of the MS-DOS stuff, so Xenix-286 should happily link the linker so to speak. But before 1984/85 it’d be the way to go?
I don’t think it was this one – IIRC, the article I read was a bit more in-depth why the S-100 machine had to be used.
The “linking the linker” story is still available online at Tim Paterson’s website under the title “The First DOS machine.”
I know that Sirius and the S-100 mocked IBM for the limited maximum memory limit but anyone considering spending $10,000+ just on memory was going to be looking for a well stocked mini with software that took advantage of the memory space not some multi-user CP/M box.
I could have sworn the title was “Linking the linker” but instead it’s the punchline at the end.
Supposedly, it was relatively simple to extend the Conventional Memory for as long that it was contiguous, which means that you could do so until you reached the first thing than was mapped to the UMA. That was always the video framebuffer. With CGA, Conventional Memory could go up to 736 KiB, with MDA, up to 704 KiB. OS/2 even has official support for this: https://www.vogons.org/viewtopic.php?p=796928#p796928
This became impossible with EGA/VGA since they are mapped right at the end of the 640 KiB. Also, I recall reading than it was possible to move the video framebuffer with specialized Hardware (A CGA/EGA/whatever card that allowed you to map the RAM to another UMA location instead of the default as per the IBM defined Memory Map), but you also require to hack the Software because anything that wrote to the framebuffer directly wouldn’t find it at the expected location.