PCem 0.7 and beyond

Checking out that javascript PCe made me want to check out PCem.  And good reason too, as its latest version 0.7 can run OS/2!

At first I tried version 2.0 and it just reboots once it is going to start the installer, (I haven’t tried a pre-installed disk image yet) but for the heck of it I shoved in an OS/2 1.1 boot diskette, and it came up!  So all excited I tried 1.21 and it worked as well!  The caveat is that OS/2 cannot partition or format the disk.  I didn’t try giving it a HPFS volume, but rather setup for a DualBoot with MS-DOS, and that worked fine.

OS/2 1.21 on PCem 0.7

OS/2 1.21 on PCem 0.7

Some of the cool things about PCem is that it runs REAL firmware, so you get the real XT/286/386/486 experience.  Also it is cycle accurate so things are SLOW like they were back in the day.  I’ve noticed that disk IO is really slow.  Again just like it was back then.  Things like DOOM take forever to load on a 386.  Just like the real thing!

If you have the ROMs the CGA/EGA & SVGA emulation is pretty good.   Again this is largely from running the actual firmware.

Work has slowed on PCem, but there is a source repo here.  I haven’t tried to build it yet.

The only thing I’d say is missing is some kind of ethernet adapter.  It would be cool to get this onto the internet.  But at the same time I’ve got to say this is pretty cool, especially if you want to enjoy the PC experience from 20 years ago, this is the way to go!  Although after a few minutes of running a 286 at 6Mhz, you’ll want to push for the fastest 486 it can emulate!

Microsoft OS/2 2.0 SDK Beta

Something interesting crossed my desk today.  The much-fabled Microsoft OS/2 2.0 SDK beta.

OS/2 2.0 SDK in action

OS/2 2.0 SDK in action

Sadly, this does *NOT* include the operating system, just the C compiler and the SDK bits. As you can see, the C compiler is version 1.00.075, a full year+ before the WindowsNT 3.1 1991 pre-release which had 6.00.080. An interesting thing is that the C compiler can be run from 16bit OS/2.  Unfortunately, the EXE’s produced by the SDK will not run on a production OS/2 system.  The fault lies with the linker & resource compiler.  However swapping those two components out for production versions seems to remedy this and produce working executables.  The only SDK examples that don’t work correctly involve the creation of DLL’s.  I’m sure it is again related to either the linker again, or from some gem I saw in the SDK saying you should always link by ordinal, and never by name.  Apparently a bunch of function calls were going to change name from OS/2 1.2 to 2.0.  It is interesting to me that going from the old Windows 3.1 to NT days we always had so much issues with people calling by ordinal vs the function name.  It broke all the time, but it is funny to see possibly where this bad habit started.

Import and link by Ordinal? What were they thinking!?

Import and link by Ordinal? What were they thinking!?

For those who don’t know DLL’s contain a table of functions sorted by NAME, and NUMBER.  The names have to be unique but the number depends on the order in which the DLL is linked together.  And it is very easy for someone to accidentally change the link order, and next thing you know the ordinal are all wrong.

Otherwise, yeah the tools from the MS OS/2 2.0 beta working in 2013.  I do believe that the object files can also be strung together with some DOS Extenders from the era to produce DPMI exe’s.

But I’ll save that exercise for later, like here! targeting OS/2 with Visual Studio 2003!

OS/2 1.21 under Qemu 1.6.0

Microsoft OS/2 1.21

Microsoft OS/2 1.21

 

So close, and yet so far away.  I’m using a ‘restore’ image to do this.. Basically I have an existing OS/2 1.21 machine that I made a backup of, using MS-DOS & OS/2.  I restore the MS-DOS backup with an altered config.sys that dumps me to a cmd.exe prompt with no Presentation Manager.  Then I restore the OS/2 image onto itself and then reboot into OS/2.  I know it works since I’ve used this to setup OS/2 onto VirtualBOX & a physical PC before.  Qemu boots half way through but the letter ‘o’ is corrupted for some reason, and the keyboard doesn’t respond once it’s booted.  But the cursor blinks away like it is waiting for you to type anything.  It is worth noting that OS/2 1.x doesn’t know what IDE CD-ROM’s are, and you have to remove the physical drive to boot this up.

Oh well it is a shame.

European MS-DOS 4.00 aka multitasking DOS

DOS 4.00M

DOS 4.00M

 

So this gem popped into my mailbox as everyone over at os2museum was whipped into a frenzy over the apparence of the predecessor to OS/2 making a showing!

So what is this, where did it come from?

To quote the excellent book, Inside OS/2 here is what this version is all about:

Microsoft started work on a multitasking version of MS-DOS in January 1983. At the time, it was internally called MS-DOS version 3.0. When a new version of the single-tasking MS-DOS was shipped under the name MS-DOS version 3.0, the multitasking version was renamed, internally, to MS-DOS version 4.0. A version of this product–a multitasking, real-mode only MS- DOS–was shipped as MS-DOS version 4.0. Because MS-DOS version 4.0 runs only in real mode, it can run on 8088 and 8086 machines as well as on 80286 machines. The limitations of the real mode environment make MS-DOS version 4.0 a specialized product. Although MS-DOS version 4.0 supports full preemptive multitasking, system memory is limited to the 640 KB available in real mode, with no swapping.

It is not feasible to support general purpose swapping without memory management hardware that is unavailable in 8086 real mode. This means that all processes have to fit into the single 640 KB memory area. Only one MS-DOS version 3.x compatible real mode application can be run; the other processes must be special MS-DOS version 4.0 processes that understand their environment and cooperate with the operating system to coexist peacefully with the single MS-DOS version 3.x real mode application.

Because of these restrictions, MS-DOS version 4.0 was not intended for general release, but as a platform for specific OEMs to support extended PC architectures. For example, a powerful telephone management system could be built into a PC by using special MS-DOS version 4.0 background processes to control the telephone equipment. The resulting machine could then be marketed as a “compatible MS-DOS 3 PC with a built-in superphone.”

Although MS-DOS version 4.0 was released as a special OEM product, the project–now called MS-DOS version 5.0–continued. The goal was to take advantage of the protected mode of the 80286 to provide full general purpose multitasking without the limitations–as seen in MS-DOS version 4.0–of a real-mode only environment. Soon, Microsoft and IBM signed a Joint Development Agreement that provided for the design and development of MS-DOS version 5.0 (now called CP/DOS). The agreement is complex, but it basically provides for joint development and then subsequent joint ownership, with both companies holding full rights to the resulting product.

As the project neared completion, the marketing staffs looked at CP/DOS, nee DOS 5, nee DOS 4, nee DOS 3, and decided that it needed…you guessed it…a name change. As a result, the remainder of this book will discuss the design and function of an operating system called OS/2.

So there you have it, OS/2 started out as a multitasking version of MS-DOS, one can even tell from some of the information on LINK4, that its architecture was also contributed to Windows, and much of how the original Windows 1.x and 2.x ‘wanted to be run from 286 protected mode, well I’d venture a guess that as OS/2 was being ‘born’ there were a lot of plans for this common architecture.  Of course I have no proof but it would seem to fit.. From Saving Windows from the OS/2 Bulldozer:

Thanks to Steve Wood’s original memory-allocation design, many of the changes involved bypassing real-mode code that served only to emulate the protected mode of the 286.

It would make sense at the time both multitasking DOS, being used for parts of early Windows, as both would be fighting the same problems regarding trying to live in the 640kb dos memory area.  While going with a protected mode in OS/2 there would be no need to maintain this, and they could start with a new memory model, Windows 3.0 went with an in house DOS Extender, and fleshed out more of its memory handling to be more 286 native.

Its a shame they didn’t go straight to 32bit stuff on the 386, bypassing the 286 but IBM was the proverbial elephant demanding 286 support.

For anyone wanting to try out this ancient OS, I was able to find out that it does run on DOSBox! So that means if you have a java capable machine you can quickly boot it up! The left alt key brings up the task switcher, and you can use the arrow keys to navigate.

DOOM runs.  I’m really still amazed at this, but it does crash on exit.  I think it was more so geared to small text mode stuff, much like what Windows 1.x or 2.x is capable of on a 286.

 

I got mentioned on Toasty Tech!

Right here!  Toasty Tech for those who don’t know has been collecting various screen shots of GUIs like since forever!

So it is kind of cool that I got mentioned over there, and for OS/2 of all things..!

Anyways, I thought it was worth mentioning.

Other than that, it is the prophesied end of some ancient calendar. If only it had any significance other than ‘happy cycle’.. I guess it is appropriate this being the ‘holiday’ season… Which for many may feel like the end of the world, but as they say, life goes on.