Idling under MS-DOS 4.01 & Windows 3.0

Well I was playing some more with my MS-DOS setup, and the annoying thing is that it doesn’t idle worth anything.

And of course running old DOS doesn’t help that most everything needs MS-DOS 5.0 or higher.

But then I found WQGHLT, which is a VXD to support idling under Windows 3.1.  And happily it works on Windows 3.0 …

The only pain is that running MS-DOS applications kills the CPU (again).  Which means that the DOS programs themselves need to idle.  And yes I did check the ‘detect idle’ but it seems that it doesn’t do what I’d hope.

Maybe it’s just the software, I should try some more and see what I get.

Windows 3.0 …

Bill Gates with Windows 3.0 / credit:Carol Halebian

There is no denying it, when it comes to revolutionary products you simply cannot ignore the powerhouse that was, Windows 3.0 .  Simply put this is what made the Microsoft empire, broke the alliance with IBM, and changed the future of OS/2 3.0.

Not only that, but Windows 3.0 changed the way businesses operate world wide, and finally delivered on the ‘dream’ of what could be done with the 286/386 microprocessor where OS/2 had failed.

To really appreciate Windows 3.0 you have to see the world as it was before it was under development.  Back in 1989 the pc market was in turmoil.  While OS/2 had the promise of breaking all the old barriers of the real-mode only OS MS-DOS, it simply cost too much, and hardware compatibility was just too poor.  The other striking thing was that the only 386 specific feature that OS/2 1.2 (current version in 1989) could exploit was that the 386 could quickly move in & out of 286 protected mode.  The LAN server product also had a 386 specific HPFS driver, but that was it.  OS/2 1.2 was still limited to a SINGLE MS-DOS box.

OS/2 1.2’s DOS session

And there wasn’t a heck of a lot you could do memory wise.  Not to mention there was no ability for the DOS session to use EMS/XMS memory.  It’s no wonder it became to be known as the ‘penalty box’.

Meanwhile, Windows/386 circa 1987 could run multiple MS-DOS VDM’s on the 386 processor.  You were only limited by how much extended memory was in your system.  Windows/386 exploited the v86 mode of the 386 processor which allowed for hardware virtualization.  However Windows itself was a ‘real mode’ program, meaning that it had to fit in 640kb of ram, just as the VDM’s it spawned had to.

Windows/386 2.11

So unless your goal was to run a bunch of MS-DOS sessions all your extra memory was for nothing.  That also included Windows programs since they all ran in real mode.  For people with enough disk space you *could* actually install one copy of Windows/386 in say VGA, then another with a lower video resolution (CGA or EGA), then actually run Windows in Windows… in a Window.  But it really wasn’t that useful, it ran better full screen.  And all this had the effect of doing was partitioning your windows programs from each other, if you dedicated a VM per application.  Needless to say with OS/2 2.0’s seamless windows this was far more easier to setup, and frankly far more practical.

In 1989 building large applications meant that you either forced people to use Unix (SCO Xenix!) or OS/2.  For those that could afford it, Xenix would have been the way to go, as they not only ran in 386 protected mode, offered a far larger address space, but it was also multiuser!  But Xenix was expensive, needed specialized knowledge.  And as mentioned the cost of OS/2 development was HIGH, and it required your end users to have OS/2 (naturally).  And the users would have to fight that a lot of PC/AT compatible PC’s on the market were not compatible enough to run OS/2.  Despite this a lot of banks latched onto OS/2, and some still use it today (look at why parallax came into existence!).  Then out of nowhere, PharLap had developed a piece of software that changed everything, the DOS Extender.

Originally for 386 computers, the first DOS extenders required people to use special 386 compilers, runtimes, and of course linkers & extenders.  The tools were expensive, the right to redistribute wasn’t free, but end users could run your multi-megabyte (lol) applications on regular MS-DOS.  Which is what 99% of PC’s were running, and it didn’t require users to change their OS, abandon their applications, it would simply just work.

Links 386 pro

One of the earliest and most popular DOS Extended game/application was Access Software’s Links 386 pro.  That’s right this game ran in protected mode! .. And it would *NOT* run under, or near Windows/386.

It was out of this wildly great but incompatible world that the first DOS Extender vendors, tried to standardize their products with the original and short lived VCPI specification, from Phar Lap.  However in 1989 Microsoft was busy working on Windows 3.0 as the next great thing.  Using a protected mode debugger, they were converting Windows/386 from a real mode ‘hypervisor’ into a protected mode application.  And if Windows couldn’t run these new extended applications, then people would naturally have to exit Windows to run them.  And that was the major problem with Windows is that people may have an application for windows but they spent most of their time in DOS. So Microsoft’s Ralph Lipe came up with the DPMI specification, managed to get all of the major vendors to support and take over it, in exchange for leaving Windows as a 0.9 level client/server.  After all why would you need their products if Windows were to incorporate the entire 1.0 spec?  At the time it was a big deal, but the success of Windows would eventually kill the extender market save for video games until Windows 95.  There is a great article about the rise of DPMI here.

So with a firm dos extended foundation Windows 3.0 could do something the 2.x products could never do, which was to actually utilize all the memory in peoples computers.  And because it hinged on a dos extender (ever wonder what dosx.exe was?) it meant that there was no special disk, mouse, network driver/software needed as it could jump out of protected mode, and call real mode software like the BIOS, or even mouse drivers if need be.  However older protected mode programs would only error like this:

No Lotus 1-2-3 r3 for you!

Another popular application for MS-DOS just happened to be Lotus 1-2-3, and it was *NOT* DPMI compliant.  Oh sure they had DOS & OS/2 support, but would you believe that the OS/2 version wouldn’t run in a Window?  Oh sure the install program may have, but some how someone didn’t think there would be any value in being able to SEE more then one application at a time.  Not to mention the dark horse, Excel was starting to sell in 1987 like crazy, in 1988 Excel actually started to out sell 1-2-3, and by 1989 it was already over.

Lotus 1-2-3 r3 for OS/2

Microsoft Excel 2.2 for OS/2

There is no doubt about it, GUI applications were taking over.  The old ‘DOS’ interface was dead.  And Lotus had basically killed their product line by providing an identical interface and experience to their customers by providing an OS/2 application that looked and felt just like the MS-DOS application.  While you may hear that Lotus got distracted with OS/2 and missed releasing a Windows version of 1-2-3 to counter the rise of Excel, the truth is that they straight up missed windowing UI’s. Their hubris is that the users simply didn’t like the 1-2-3 interface, they wanted a windowed application.

What they did want was graphical Windows, and of course more memory!  And there is nothing more annoying than having say 16MB of VERY expensive memory in a computer like a 286, but being restricted to 640kb or less is just … insane.

So let’s see Excel in action.  Excel 2.1c shipped with a ‘runtime’ version of Windows 2.1.  Mostly because nobody was buying Windows in 1987 Microsoft had to do something to get people running the thing.  So the best way was to allow you to run an application with it.  By late 1989 and early 1990 application vendors were making updates to their products so that they could run under Windows 3.0.  And here is the first version of Excel to do so.

Excel 2.1c and the Windows 2.1 runtime

So here we have Excel running under Windows 2.1 ala the runtime environment.  All you have here is excel.  Also worth noting is that the setup program is 100% DOS text based.

Moving forward we can now upgrade to Windows 3.0.

Excel 2.1c running on Windows 3.0’s real mode

So as you can see Windows 3.0 takes up 30kb more memory then Windows 2.1!  For someone with an XT this could mean bad news!  Now it’s time to see what all the babling was about, running the same application in protected mode to access more memory!

Excel 2.1c running in Windows 3.0’s standard mode (286 and above)

Now we are running in 286 ‘standard’ mode.  Notice that Excel thinks it’s conventional memory, but we now have 14MB of the computers installed 16MB accessible to the application!  Now this is pretty amazing stuff! Now it’s no secret that the 286’s memory management left a lot to be desired, and Microsoft really didn’t want to write for it, as the 386 was where they wanted to be.  So unlike OS/2 the 286 cannot swap.  You are only limited to what extended memory you have in your computer.  But this is different for the 386..

Excel 2.1c running under 386 enhanced mode

And here we are, 386 enhanced mode! So finally  our Windows applications are clearly running in protected mode, with demand paging!  With 36MB of available memory in a computer with 16MB of ram.  The colors are distorted on Virtual PC under 386 enhanced mode… But as you can see the environment runs!  And even graphical programs that for example used CGA could happily run on an EGA system in a window.  Even better you could copy the screen, and paste it into any Windows application you want.  Yes you could buy games and use them for clipart!

Another feature of Windows 3.0 that people didn’t realize is that it could pre-preemptively multitask DOS based VDM’s

As you can see, there it is, the timeslice, and scheduling options..  Great ways to confuse users for decades… 🙂

Who could resist?

As always, there is a great InfoWorld article here.

So why was Windows 3.0 successful? A lot of it is timing, as there was no other environment that could offer people access to their whole machine without upgrading their operating system.  And of course there was the whole thing with bundling Windows, Word & Excel with new computers.  I mean who would resist something like a graphical application like Excel when compared to the klunky and significantly more expensive 1-2-3?  Sure the bundling practices were found to be illegal, but looking back, Lotus & Word perfect basically GAVE Microsoft the market.  And of course, talk about aggressive upgrades!  I’m not sure they even do such things anymore.  Although I’ve heard of big companies, and governments pushing for discounts for running things like Linux.

And there is the other things that Windows 3.0 supported that OS/2 simply did not.  For starters backgrounds (wallpapers), and of course the desk accessories.  Sure they sucked but in a panic at lest you *could* do something… where OS/2 basically left you in the lurch.  Not to mention how much more expensive OS/2 was when compared to Windows.

So with all that out of the way, what fun is a write up without a demo?

 

And thankfully I’ve found all the bits in prior posts, and I can put them together right here.

Windows 3.0 working demo, click to launch!

 

MS-DOS Player

Since the last time I reviewed it, the MS-DOS Player, by Takeda Toshiya has come a long way!. He’s fleshed out more of the MS-DOS emulation, and updated the CPU core.

I’ve now been able to run the Microsoft C 5.1 compiler under Windows 7:

MS-DOS Player running Microsoft C 5.1

MS-DOS Player running Microsoft C 5.1

Check it out!

The MS-DOS Player is similar in nature to DOSBox, except that it’s not interactive, but rather built for CLI batch based operation. The MS-DOS Player seems to have some 80286 capabilities, but it’s BIOS/DOS emulation doesn’t seem to have the protected mode interface to allow dos extenders to work.

It’s certainly great for people that still have ANCIENT cli based programs that you’d want to call & capture their output. This is a life saver for some of us that still rely on dbaseIII & some ancient i8085 micro controller.

*EDIT updates from the future

Well Looking back at this post, it really is a snapshot of life back in 2011. Since those many years later DPMI support was added, along with the ability to ‘bind’ old programs allowing you to have a ‘Win32/Win64’ native exe that’ll run the old program inside. This is incredibly valuable for ancient toolchains where the source was either lost, or never provided, but now you can run them! This saves things like the Nintendo toolchain, although you can cross build the compiler, and assembler as they are GNU standard, the linker is a special one that will output cartridge images. And now you can run the MS-DOS DPMI version under Win64. Awesome!

Concurrent DOS/386

Concurrent DOS/386

Concurrent DOS/386

Concurrent DOS/386 was a successor to MP/M, from Digital Research.

I’ve been able to track down a few versions:

  • version 2, released November 17, 1987
  • version 3, released February 23, 1988

What is interesting is that these versions include a CP/M 8086 emulator. I would imagine that would be a ‘big deal’ for users of the older MP/M to migrate into a newer 80386 environment. From what I’ve seen in other places these were compatible with MS-DOS 3.0 . It can also read extended dos partitions! Since they predate VCPI/DPMI there is no way to run protected mode applications. Concurrent DOS/386 is later followed up with Digital Research Multiuser DOS. It is interesting, well to me that DR-DOS was basically a single user, single tasking version of the Multiuser DOS.

Multiuser DR-DOS

I was able to install this on Qemu 0.13.0. Although this includes some IPX/SPX stuff from the later purchase of Digital Research by Novell, it still remains a largely MS-DOS 3.3 compatible OS. Because it uses protected mode, and the v86 mode, it is still incapable of running VCPI/DPMI programs. Also absent is the CP/M emulator. I think there was a DR-DOS 6 equivalence sold as a multiuser, but by the time of DR-DOS 7, the product had been forked and several VARS started to sell their own versions based on Multiuser DR-DOS. These included (but probably not a complete list)

  • REAL/32
  • System Manager
  • DR-Multiuser-DOS

Of these, REAL/32 seems to be the only one that is still alive, and being sold by Intelligent Micro Software. I’ve located a demo version of REAL/32 here.

REAL/32 logo

REAL/32 certainly feels a lot like DR-DOS (which it is derived from) and what is cool is that it supports DPMI applications. I’ve tested some Borland Pascal stuff, along with DJGPP. Like the others it supports serial terminals to be hooked up.

real32 serial connection

 

Qemu makes it super easy to simple to switch to the serial port, and bring up the ‘second user’. I’m pretty sure you could use qemu to redirect it’s serial port over TCP…

And speaking of networking, the install program also seems to have some kind of networking config built in, so I would imagine each VM can have it’s own IPX/SPX setup? I’ll have to mess some more with it.

If you’ve ever liked DR-DOS, you may want to give real/32 a whirl, it’s certainly more… interesting.

Multiuser DOS

This has been a fun thing to go through, but at one point it was a popular trend to convert big expensive 386 computers from the late 1980’s into multi-user, multi-tasking beasts much like a mainframe. But instead of CICS, and PROFS people ran Dbase III, WordPerfect, and all kinds of email solutions from ccmail, to MS mail, and even some dbase programs, compiled by clipper into being email clients.

In a way things were more ‘simple’ back then, and the 80386 CPU had a card up it’s sleeve v86 mode. v86 mode provides hardware emulation of a 8086, allowing the base OS to spawn dozens of these virtual machines. All that was up to the ‘supervisor’ was to create virtual peripherals, much like how Windows/386 of the day ran multiple MS-DOS VM’s on a single machine that you could see at once, these solutions provide the output to multiple terminals.

While Windows/386 sat on top of MS-DOS, these multitasking DOS’s had the v86 mode multitasking as part of it’s core, and some of the later ones were themselves protected mode operating systems.

But juggling multiple MS-DOS applications at one could be quite a challenge. And of course there was the whole dos extender thing, leading up to VCPI, and DPMI.

While MP/M-86 is a grand daddy to a bunch of Digital Research derived OS’s, it’s not 386 specific so I’m going to omit it for now. I’m sure it’ll be worth doing it’s own write up.

I’m sure I’m going to miss a bunch of these, but let’s have a quick rundown.

  • Concurrent DOS/386
  • DR-Multiuser-DOS 5.0
  • Real/32
  • TSX-32
  • PC-MOS/386
  • VM/386
  • VMOS/3

If anyone knows of any others feel free to give me a shout. It does seem that multiuser DOS was a good market at one point.

QuakeWorld client for MS-DOS

So as leileilol pointed on on VOGONS, QuakeWorld’s networking was a rapid departure from Quake 1, and formed the basis of a lot of modern multiplayer games… Like teamfortress and half-life.

So with a little bit of work, I was able to compile a QuakeWorld client for MS-DOS. Or here for the standalone exe, and don’t forget CWSDPMI. Oh and be sure to get a packet driver, for your NIC. Many vendors have these on their site for newer stuff.

Now I managed to get a new computer between posts, and it’s not working on virtual pc… I may be 500 updates behind though so maybe it’s something else. So in the meantime I’m testing with Qemu.

The other oddity is that compiling QuakeWorld with GCC 2.95.3 with either -O1 or -O2 builds a client that will time out after 2 minutes… -O0 ran for over an hour with me playing and dying a lot on quake.xs4all.nl:27500 …

Oh and what good would this be without pictures?

Yes, I’m really that bad.

You can find quakeworld servers on the site quakeservers.net. And I can verify that you can indeed download levels!

Enjoy!

Quake1 with WATTCP built with DJGPP on DOSBox

Phew.

As far as I know this was never done, as the world at large moved away from MS-DOS, and of course when Quake 1 on MS-DOS was popular they weren’t exactly giving out the source… Such a shame the DLM thing was lost in the shuffle as DLL’s on DJGPP/MS-DOS could have made quake more modular..

So what I’ve done, is I’ve used an ancient version of cygwin that I was playing around with line, and built a cross compiler for DJGPP. Then using that I’ve built the latest version of Watt-32 tcp/ip with it, then I took my build of Quake 1 on DJGPP, and built quake to use the net_bsd, net_udp, net_dgrm services, and added in the needed hooks for Watt-32 TCP/IP. And to their credit, I just added a single function call to both protocols init functions, and a single function to the general network poll function. All and all I think it’s 3 lines I changed.

Then to test, I used an older copy of DOSBox that included a virtual NE2000 that binds onto a physical interface via libpcap, loaded up the packet ne2000 driver, and ran the client!

For a server, I used the much older, quake dedicated server I had built to run on Windows NT 3.1. Although I never did automatically turn on the ‘-dedicated’ flag for some reason…

On the Windows XP virtual machine, I installed a loopback adapter, then set it up with internet connection sharing so that XP would act as a DHCP server to the Watt-32 TCP/IP stack.

Anyways, as you can see in the picture I connected a simple sniffer, WinDump to watch the packets, and it worked.

I’m still blown away that it worked on the first shot.

It’s really a testament to all the people that make all the moving parts here, when I can just string stuff along and get it to work.

For anyone daring enough, this zip contains all the source, and binaries of all the parts, except for the cygwin install. (I did have to poach a ‘modern’ cygwin1.dll from a modern install).

Enjoy!

Cross compiling for MS-DOS (DJGPP) from OS X

So building on DOOM, I thought I’d try to build a djgpp cross compiler from my main OS X box, as compiling under DOSBox is… just too slow. Luckily Delorie has a page on building a cross compiler.

I started out with binutils-2.9.1, just as he does, with a few things thrown in…

First I had to run configure like this, as OS X didn’t exist back then, let alone x64 cpu’s..
./configure --target=i586-pc-msdosdjgpp --host=i386-netbsd --prefix=/usr/local/djgpp
Next the following error is thrown…

strerror.c:463: error: conflicting type qualifiers for ‘sys_nerr’

So I just edited libiberty/strerror.c, and commented out the following line.

Next up was a strange error in gas/targ-cpu.h

targ-cpu.h:374: error: array type has incomplete element type
targ-cpu.h:378: error: previous declaration of ‘flag_16bit_code’ was here

I simply commented out the lines.

Then later while compiling gas/write.c it bombs out because of an undefined type.. One of which was commented out in targ-cpu.h . The easiest fix is to go to the start of the relax_align procedure and just add in the definition:

extern const struct relax_type md_relax_table[];

Next up was gcc. I couldn’t get 2.8.1 to build, instead I built gcc-2.95.3.

I had to configure gcc like this:
./configure --target=i586-pc-msdosdjgpp --host=i386-netbsd --prefix=/usr/local/djgpp
And it threw the same error as binutils… with the same fix (commenting out the line in libiberty/strerror.c).

strerror.c:465: error: conflicting type qualifiers for ‘sys_nerr’

I also had an error pop up like this:

./config/i386/i386.c:142:22: error: macro “strcat” requires 2 arguments

And again I just commented it out.

Under OSX the makeinfo parts crashed, so I simply removed them from the makefile. With a little more tweaking the cross compiler was ready!

REMEMBER TO FOLLOW DJ’s steps too!

The cool thing is that now I can run make with the -j4 flags allowing gcc to run on each of the cpu cores letting me build doom in under 3 seconds!

i586-pc-msdosdjgpp-gcc -O2 -DNORMALUNIX dos/doomdef.o dos/doomstat.o dos/dstrings.o dos/i_system.o dos/i_sound.o dos/i_video.o dos/i_net.o dos/tables.o dos/f_finale.o dos/f_wipe.o dos/d_main.o dos/d_net.o dos/d_items.o dos/g_game.o dos/m_menu.o dos/m_misc.o dos/m_argv.o dos/m_bbox.o dos/m_fixed.o dos/m_swap.o dos/m_cheat.o dos/m_random.o dos/am_map.o dos/p_ceilng.o dos/p_doors.o dos/p_enemy.o dos/p_floor.o dos/p_inter.o dos/p_lights.o dos/p_map.o dos/p_maputl.o dos/p_plats.o dos/p_pspr.o dos/p_setup.o dos/p_sight.o dos/p_spec.o dos/p_switch.o dos/p_mobj.o dos/p_telept.o dos/p_tick.o dos/p_saveg.o dos/p_user.o dos/r_bsp.o dos/r_data.o dos/r_draw.o dos/r_main.o dos/r_plane.o dos/r_segs.o dos/r_sky.o dos/r_things.o dos/w_wad.o dos/wi_stuff.o dos/v_video.o dos/st_lib.o dos/st_stuff.o dos/hu_stuff.o dos/hu_lib.o dos/s_sound.o dos/z_zone.o dos/info.o dos/sounds.o dos/i_main.o \
-o dos/dosdoom

real 0m1.174s
user 0m2.626s
sys 0m0.679s

How’s that for fast?

For any curious OS X 64bit users out there you can download my binary toolchain here.

I would imagine that if you stuck with versions of binutils & gcc that build on your platform you too should be able to build a MS-DOS DJGPP cross compiler. And there is nothing like native 64bit tools for building for DOSBox… Oh and DOOM runs just fine, although I guess screen shots of the cross compiled exe is… redundant.

Doom for MS-DOS

Today while checking out eets on steam ( yeah I know… ) I came across this sale… It’s Doom, Doom II, and Doom III all together, with all the expansion sets for $8.74 USD!

Well needless to say I couldn’t resist the offer, so I bought it. While playing around with Doom, I was wondering what was the first port of the Linux X11 doom back to MS-DOS. A bit of googling brought me to the doom wiki, and from there it seems that “DOSDoom” version is the first source port returning DOOM back to MS-DOS.

As mentioned in Chi Hoang’s notes, it took him 4-5 hours to do the initial port. So I figured it’d be worth re-creating the 0.1 version of his work, under DOSBOX with DJGPP.

I did find out the hard way that there is a single assembly clause that breaks under newer versions of DJGPP, and there is a small issue with the HOME environment variable that if it’s not set it’ll crash DOOM. So I ‘fixed’ that to use the current directory.

To install this legacy version of DJGPP, I found the needed files..

*bnu27b.zip
*csdpmi7b.zip
*djdev201.zip
*gcc2721b.zip
*gdb418b.zip
*mak3791b.zip
*pat253b.zip

Simply unzip all of this into a directory that your DOSBox mounts, and alter your dosbox.conf something like this:

[autoexec]
# Lines in this section will be run at startup.

mount c c:\dos
c:
set PATH=C:\DJGPP\BIN;z:\
set DJGPP=C:\DJGPP\DJGPP.ENV

Then you should be able to extract the doom source that I’ve patched up, and run make to re-build the exe. I’ve included a shareware wad file that won’t explode on missing demos…

So the end result is the following:

DOSDoom 0.1

DOSDoom 0.1

Which… has no networking support, no audio, but it does work! This port is overall minimally invasive to the code, and I’d suspect it’d make it a very easy starting point for yet even more ports of doom… I think there is over 40 out there.

That’s the one great thing about making the source available, is that the product lives on and on!

Aeon

I came across this 386 emulator, Aeon(updated to use archive.org, as it’s dead now). What is interesting is that it’s written in C#!

That’s right it’s all managed code…!

If you can run .net 4.0 you may want to check it out, it’s quite capable….

Doom on AeonYes it can run doom!

The DPMI is good enough to run doom, and quake! While slower then DosBOX, I’d still say it’s a contender, you can never have too many possibilities…