Don’t waste money on a math coprocessor they said;

Posted on November 12, 2023 by neozeed

You don’t need it they said!

Well it’s been no secret, but OS/2 6.123 on my PS/2 model 80, is insanely unstable running simple MS-DOS based games (large EXE’s)

And almost always I’d get this fun error:

SYS0037: The system cannot write to the write-protected c: drive.

Followed by a crash trying to execute code at the top of the memory MAP (ABIOS?)

Then ending the program will just crash OS/2. Very annoying!

My goto test of v86 mode environments is an old game that I enjoyed as a kid, 1988’s BattleTech the Crescent Hawks inception.

It’s a great game, that runs on many 8-bit/16-bit systems of the era, and is surprisingly a very well behaved MS-DOS game. I mean if Windows/386 VGA machines can run it in a window using the CGA version, surely a super early OS/2 2.0 beta (6.123) can run it, right? However I found 6.123 to be incredibly unstable, and sadly not up to the task.

I tried to launch BattleTech over and over and had zero success. I couldn’t figure out why it was struggling on my model 80 board, where it runs just great on 86Box. What is going on?

One thing I had stumbled upon was that if I launched an ancient Infocom game in a DOS box, and then launched BattleTech it had a much higher chance of running. But this did not always equate to it working. How is launching an old COM file from the early 80’s excise the ‘devil’ of some 1988 EXE from running?

I wasn’t sure but I had this weird suspicion that it was that my system was lacking a math coprocessor. When I had the model 60 286 board in the PS/2 case I did spring for an 80287, and one thing I found is that OS/2 1.0 & 1.21 ran great. As a matter of fact I think it ran better than when I used to have a 386sx-16 and then later a 486SX-20. Now it’s been closer to 30 years, so I could have an absolutely false memory of all this, but I wasn’t sure I was onto something. So while shopping around a subscriber offered me a math coprocessor as they seem to be insanely expensive in the UK. I have no idea why the 80287 was so cheap, and no idea how to make any kind of adapter, but pJok was able to score one for super cheap in his homeland and send it to the barren wastelands of Scotland. As I was wrapping up the SSD G5 fun, the coprocessor arrived, and it was time to install it!

Note the purple 80386! It’s what we might call foreshadowing

The PS/2 8580 motherboard is really oddly designed with chip orientation going in every which other direction, and the 80387 socket isn’t keyed by pin, so it’s vital to see the notches on the silkscreen. Otherwise I just used compressed air to blow out the socket, and run the reference disk to add the processor.

The processor was instantly picked up, although I had the crashing issue with the BocaRAM/2 memory card again, which meant I had to remove the RAM card, re-configure with the math coprocessor, then add the RAM card, reconfigure, then run the util to patch the CMOS so it’d boot up. I really dislike this RAM card, but 32bit cards cost far more than this entire endeavor cost so I’m pretty much stuck with it.

Now let’s compare the Landmark scores between the 286/287 and the 386/ITT387

Landmark System Speed Test with the PS/2 model 60 80286/80287

And now the 386:

Landmark System Speed Test with the PS/2 model 80 80386/ITT 80387

The ITT processor is significantly faster than the old 80287, which is pretty amazing. The system bus is running at 16Mhz, although being 32bit vs 16bit yielding a nearly 2x in performance, although the ITT co-processor is so much more efficient.

Booting back into OS/2 6.123, and yeah now it just works! No fussing around, everything is just great.

I’m kind of lost too, as none of this should require the maths coprocessor, but the results speak for themselves. I used to wonder once I got some disk images for this ancient version of OS/2, why didn’t they ship it? Sure that insane fight with Microsoft on refusing something like Windows on OS/2, or even WLO like Windows IN OS/2 from being part of the product killed any hope of running apps, but this version of OS/2 is already caught in the trap that it can run MS-DOS so well, despite DPMI not being a thing right now.

As I’d mentioned it does run just fine in 86Box, so what is the deal? Well that lead me to look back at when it did crash I noticed an odd string 038600b1

So what does this mean? Well looking back at the CPU let’s try to decode some of it

First, it’s an A80386-16, which really isn’t that hard to figure out it’s a 16Mhz rated 80386. Next is the revision level, S40344. Searching around we can find this table:

S40276 - A1 (but probably 12 MHz as S40277 is 12 MHz)
S40334 - A2
S40336 - B0
S40337 is B0 stepping
S40343 - B1
S40344 is B1 stepping
S40362 - B1 (20 MHz)

So this places it at at the tail end of the introductory line of 386 processors. Checking over at pcjs, we find that there were quite a few more revisions to the 386.

And further that the B1 Errata is actually quite substantial. Maybe this is why the 386 had such a poor reputation for Unix ports in the day, and why it was shunned by CSRG?

As mentioned in the infamous 32bit multiply bug, this processor had been tested and was given the ΣΣ mark of approval. There are numerous issues listed with the presence of a math coprocessor, I have to wonder if beyond issues for using the full 32bit datapath, if there were some electrical issues with utilizing the full datapath as well? Much like an improperly terminated SCSI bus, did the simple presence of the ITT 387 help with signaling and improve system stability? Or am I hitting some weird bug in 32bit math that is simulated due to the lack of a coprocessor, that once one is in the system, the operation is performed on hardware, sidestepping the entire issue? I’m neither an EE or any good at reversing code, so I really don’t know.

The date code 751 does mean that this processor was manufactured in the 51st week of 1987.

Looking at how ancient this CPU is, I have opted to order one that was made in 1990, an SX218 or D1 stepping.

Although it hasn’t arrived yet, I have to wonder if it would make a really big difference in 32bit system stability? I have to wonder if there was such a massive delay in OS/2 2.0 because of the early 386 processors having so many defects that it just added an undue burden to the development, along with the fighting between IBM & Microsoft. While it would be interesting to see the difference between any of the Microsoft versions of OS/2 2.0, none have surfaced as of yet. Which is a shame.

Although it is nice to have this ‘mid’ IBM beta of OS/2, it does suffer from the ever so common issue of not being able to run any shipping 32bit executable, so unless you have source/object files to link, you are pretty much out of luck. The Microsoft Beta 2 tools are 16bit, so thankfully they run on pretty much any version of OS/2, and they ought to be able to run under Phar Lap 286 as well.

One thing that did recently surface on eBay, is a Microsoft tee shirt from their OS/2 2.0 group. With a minor bit of sleuthing, the Enterprise is from the 1989 ‘hit’ Star Trek V. Maybe I’m too much of a nerd to have recognized the GIF.

Back some 20+ years ago when I lived in Miami, I did have a loaded out PS/2 model 80 back then, and I ran AIX on it, as I thought it was really cool. But it was also incredibly unstable. I have to wonder now if it was a fault of the processor, or the system? Then again back then I had 6 registered IP’s and of course my PS/2 was on the internet! Although it was also the right height to double as a standing mouse pad.

So I guess this potentially leaves us with some painful lesson that you ought to get the math coprocessor for older systems if you plan on running anything other than DOS/Windows with a DOS extender. While I do have a PS/2 version of Xenix, I haven’t been able to dump them yet as my Power Mac doesn’t like NON FAT disks. One thing is for sure, it made a massive difference in OS/2. I don’t think 16Mhz/6MB of RAM is anywhere near enough to run OS/2 2.00 at any decent speed so I’ll stick with the much lighter 6.123.

32bits of disappointment, upgrading the IBM PS/2 model 60

Posted on October 27, 2023 by neozeed

While I had enjoyed this fully loaded 286, it was getting a bit annoying with all the 32bit limitations I was running into. Frontier Elite was a 32bit program, Obviously no WIndows/386 nor any DooM. It seems that most of the MS-DOS fun I had really was 32bit only. So with this PS/2 model 60, I did the only real thing I could do:

I swapped the motherboard with a PS/2 model 80 board. I had seen this on eBay for a bit of an excessive price, offered 40% of said price, and woke up to having shockingly won the bid. Of course it also means that I need special 32bit RAM to boot the board, because “IBM”.

I picked up 2 of these 1MB modules, they are 3 chip much like the SIMMS I had used on the PS/2 model 60 motherboard. So these are no doubt parity 256k in each row, and 2 cards giving it 2MB of RAM right off the bat. I got lucky to find these 2 cards in country and at a really reasonable rate, when compared to all the others. They did make 4MB & 8MB cards, but naturally they are incredibly expensive.

Luckily for me the board & RAM worked (the board was listed as working), and running setup from the gotek was painless. However for the heck of it, I put in the Boca RAM/2 board to see if it works. It does. It also does the same thing where once the Boca RAM/2 board is configured the setup program only crashes on running it, meaning I need to disconnect the battery backed RAM.

I thought I could avoid setting up the RAM card, but oddly enough until I did so it would not initialize the SCSI card. Oh, sure it showed up in the setup program, saw all my disks and everything, but it would not boot or show up from a boot disk.

So now let’s re-visit the painful world of SCSI disks. I had bought one SCSI controller, and tore some pads off for being impatient, bought another and had it working fine with the approved cable, crashed the PS/2 MCA SCSI market, and then bought the caching faster controller card, to only reveal that it is in fact slower than the stupid card.

But it’s a 32bit card!

And now I have 32bit slots and a 32bit processor! Surely it’s going to ROCK!!!!….?

It’s 0.3% faster.

What the actual FUCK. I mean ok BlueSCSI is great, and we’ve seen it perform faster with the ‘stupid’ card. I can’t imagine paying the $999 MSRP of this faster caching card to find out its slower. Nor the massive upgrade cost of going 32bit to find out its only slightly faster.

Wow.

Just Wow.

LANDMARK 6.00

That said, v86 mode is really cool!

My goto test for v86 is BattleTech the crescent hawk’s inception. I mean if Windows/386 can run this, everything else should be able to. And yeah, 16Mhz is almost enough to run this in a window. It screen tears like crazy and is just slow. But at least it runs!

Warning beeper music!

Although football was capable of doing this full screen in 1987, and Windows/386 could run it in a window in 1987 as well, it wasn’t until 1989/90 that OS/2 could with the much delayed 32bit version. Of course, the divorce happened after Windows 3.0 became such a massive seller, and OS/2 was delayed. again. While I had no issues under 86Box, I had plenty of weird issues on real hardware that seem to magically sort themselves out by running Infocom’s Planetfall first. I don’t know why either.

16Mhz Wing Commander

And luckily there is some difference in running at 16Mhz. Although I haven’t tried EMM386 on/off yet. The 286 had it’s excuse of copying pages in & out of protected mode, and the switch time being so horrific. But the 386 should be instant, only limited by it’s slow bus and I guess 4MB of slow RAM.

But what about DooM?

DooM v1.1 low resolution not quite postage stamp sized

Yes DooM v1.1 runs! I’ll have to try some Fast DooM later to see how much faster it can be! I’d like to think itll be faster but I am not holding out much hope.

Many of the bench stuff I had setup on the 286 to compare to the 386 sadly depend on a math processor. The problem of course is that 80287’s are very cheap for some reason. 80387’s however are not.

And the majority of them look like this. I don’t know how on earth people have hundreds of 80287’s to sell at super cheap prices, but 80387’s all seem to have been trampled, or had their inner core’s turned into slag. I will keep a lookout, although knowing my luck it may be cheaper to find another motherboard with a 386/387 paring.

Speaking of OS/2 and weird crashes, I got this fun one from OS/2 trying to run sysinfo:

While I’d seen plenty of trapcodes in my time, but I know less than nothing about reading them. Maybe it’s burred in there somewhere. The one odd thing was the 038600b1 part… Since the 386 is a 16Mhz part, maybe it’s a crazy old version? While it does have the ΣΣ mark, maybe there is other troublesome 386’s? I really don’t know. Or maybe OS/2 is just really more sensitive to having 2MB 32bit RAM + 4MB 16bit RAM.

Way back in the old times, I had upgraded from a 12Mhz 286 to a 16Mhz 286, and life was great, although I left out of all the 32bit personal computer revolution. After a lot of hard work, I managed to secure a 386sx 16Mhz board with 4MB of RAM. It was awesome although yeah SLOW. Clock for clock, task for task the 386sx was at best the same speed. Sometimes I’d swear the 286 was faster. A few months later though I made the insane trade of some complete in box Infocom games, along with cash and was able to score a 386DX 16Mhz, along with 4MB of 32bit RAM on some massive board. Surely this was going to be great right? I found pretty much the same thing there was no perceivable difference at all. At least back then it was 1992? and the capacitor plague was still decades away, and you could just call the BBS of the motherboard vendor and download the disks if needed (I didn’t need to). It was, frankly, a big letdown after so much ’32/32 is far superior to 32/16′ and here we are again in the future and the SCSI card bears it out, that id basically didn’t matter.

I guess it really comes as no surprise that the 386 does everything the 286 can just better.

So, what have we learned? The PS/2 model 60/80 chassis is the exact same thing. The low clocked 386 chips are super unimpressive, no doubt the magic in the intel family really didn’t hit until the DX2/66 and beyond. Beta versions of software act weird, oh, and that the backup program from MS-DOS 5.00 can actually backup a dual booted OS/2 install & restore it just fine. That was a bigger surprise for me, as the great thing about the BlueSCSI i that I can have so many drives, so I made a backup of the C: OS drive and trashed it quite a bit. Not expecting anything, but yes, a restore actually worked.

Building OS/2 apps from QuickC for Windows

Posted on October 23, 2023 by neozeed

Back in the olden days of when Microsoft had pivoted out of OS/2 in a hurry, I’ve always felt that the common ‘OMF’ objects ought to link for OS/2. But for some reason I never tried. But for some reason I thought I’d try it today.

I first installed Microsoft C 6.0, and set it up for a native OS/2 to OS/2 1.2 setup. This way I get a pure OS/2 include/library directory set. In retrospect, I don’t know why I didn’t just use 2 include / library directory sets to far easier target stuff, without dealing with changing the default names, and making linking an all around living hell.

So the first thing to do is to tell QuickC for Windows to default to the OS/2 include directory (turns out it wont link anyways). Compiling is nothing special. When setting up the project you’ll need a DEF file, I use this simple one:

NAME        QCO2 WINDOWAPI
PROTMODE
CODE        PRELOAD

Nothing to it!

I tried to fight the Windows linker, but it figures out what you are doing and won’t do it. But can you manually link? Well QuickC for Windows does include a DOS linker, and it’s oddly enough newer than the one for Microsoft C 6.0!

C:\proj\o2>msdos \WIN16APP\QCWIN\bin\link hi.obj

Microsoft (R) Segmented-Executable Linker  Version 5.15
Copyright (C) Microsoft Corp 1984-1991.  All rights reserved.

Run File [hi.exe]:
List File [NUL.MAP]:
Libraries [.LIB]: doscalls SLIBCE
Definitions File [NUL.DEF]: qco2.def

C:\proj\o2>msdos hi.exe
This program cannot be run in DOS mode.

Manually invoking the linker wasn’t all too hard, just answer the 30 questions. I did set the LIB environment variable so it picked up the libraries just fine. And yes, it created my OS/2 binary no problem!

And as you saw from above, yes it does run!

I do suppose the graphical editors would have been nice some 30 years ago, but in today’s era, sadly it doesn’t matter. QuickC for Windows won’t run under WLO, so this prevents it being a backdoor GUI/Protected mode compiler for OS/2. It’s a shame too as at least running under Windows 3.0, QuickC for Windows is WAY faster than using Microsoft C 6.00 in either read mode, protected mode with smartdrive.. I’m not sure what the deal is. Even with the advanced caching SCSI controller.

Not sure if anyone cares, but I think it’s cool.

OS/2 2.0 Technical Library on archive.org

Posted on August 5, 2023 by neozeed

It’s certainly one of those things that I’m surprised I didn’t buy when it was current, but glad binipafruc scanned the set.

PDF’s look nice on an iPad, but maybe that’s me being old.

It’s crazy that once uppon a time, corporations thought developer documentation was a revenue stream to their upstart Operating System. It went as well as you can imagine it would.

Bill Nye, the Microsoft C 6 guy

Posted on July 5, 2023 by neozeed

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.

Looking back at MS-DOS 4.00M, or in the beginning before there was OS/2

Posted on January 17, 2023 by neozeed

With the pre-christmas release of the Microsoft OS/2 betas 1.00, 1.01, 1.02, 1.03 & 1.05 on archive.org, and helping Ncommander with an upcoming video, it seemed like a good place to start, not with OS/2 but rather with MS-DOS 4.0.

From the book INSIDE OS/2 ( ISBN 1-55615-117-9 )

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.2 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.
– Inside OS/2.

Although MS-DOS 4.00M disk images have been floating around for quite some time, either a 2 360k disk set, or a single 720k disk image, I don’t think anyone (including me) really tore into it that much. It does have the ability to freeze DOS 3 programs, giving the illusion of running more than one. The session manager is pretty sparse but hitting left alt twice will pop it up giving you the ability to toggle through programs with ease.

There is a FDISK, FORMAT & SYS command making it straight forward to setup a hard disk, and copy the files over, I didn’t see any installer.

there is a PS command to show running processes. Also there is a DOSSIZE to show the memory partitioning and how much is available. Although there is a SWAPPER program I’ve been unable to get it to actually fun.

Another interesting thing if you run the unix ‘strings’ command against all the EXE’s you’ll find the string:

C Library - (C)Copyright Microsoft Corp 1985

Implying that not only was DOS 4.00M a ‘new’ DOS, but it was also written in C. No doubt this contributed to a larger file size than DOS 3, however it would also give that holy grail of portability, at least to new CPU modes. Also many files have the name of the source files baked in such as:

@(#)append.c    1.1 85/10/09
@(#)assign.c    6.1 85/10/23
@(#)attrib.c    6.1 85/10/24
@(#)fdisk.c     1.1 85/10/09
@(#)fddata.c    1.1 85/10/09
@(#)fdlow.c     1.1 85/10/09
@(#)fdsub.c     1.1 85/10/09
@(#)joinsbst.c  6.3 85/11/08
@(#)sysvar.c    6.2 85/11/08
@(#)cds.c       6.2 85/11/08
@(#)dpb.c       6.1 85/11/08
@(#)label.c     6.1 85/10/24
@(#)newdef.y    6.2 85/10/14
@(#)ms4bnr.c    1.1 85/10/15
@(#)mode.c      6.2 85/10/24
@(#)getkey.c    6.1 85/10/25
@(#)pifmes.c    6.1 85/10/25
@(#)advpscrn.c  6.1 85/10/25
@(#)advescrn.c  6.1 85/10/25
@(#)usrscrn.c   6.1 85/10/25
@(#)rangers.c   6.1 85/10/25

Okay so far, so good. But we’ve all seen this before, and scratched this OS about this far, because what else can you do? It’s not like there is any dev tools to do anything fun!

Well the tool hidden in plain sight is LINK4, which in retrospect is specific for MS-DOS 4.00M.

Microsoft (R) 8086 Object Linker  Version 4.01
Copyright (C) Microsoft Corp 1984, 1985.  All rights reserved.

Object Modules [.OBJ]:

There is no SDK for MS-DOS 4.00M, but they were kind enough to leave the linker in place. A quick check of the Windows 1.01 SDK shows that it also includes LINK4:

Microsoft 8086 Object Linker
Version 4.00  (C) Copyright Microsoft Corp 1984, 1985

Object Modules [.OBJ]:

It appears that if the dates and versions are to be trusted they are of the same vintage, but the Windows linker is older, and that they both output to a NE or New Executable. So to start the experiment I created a simple hello world exe from a simple:

void main(){
  printf("Hello from MSC 3\n");
}

To compile this I used Microsoft C 3.0 (more on why later), and used LINK4 to create an EXE:

C:\dos\msc3>cl /c hello.c
Microsoft C Compiler  Version 3.00
(C)Copyright Microsoft Corp 1984 1985
hello.c

C:\dos\msc3>msdos dos4m\link4 hello.OBJ

Microsoft (R) 8086 Object Linker  Version 4.01
Copyright (C) Microsoft Corp 1984, 1985.  All rights reserved.

Run File [HELLO.EXE]:
List File [NUL.MAP]:
Libraries [.LIB]:
Definitions File [NUL.DEF]

Okay, everything looks fine so far. Attempting to run this under MS-DOS just results in the error:

Program too big to fit into memory

Well now that’s odd. Checking the EXE with the Linux ‘file’ command reveals:

file HELLO.EXE
HELLO.EXE: MS-DOS executable, NE (unknown OS 0) (EXE)

So obviously it’s a NE, but it is an older/unknown version to the file map database. There is no stub so I suppose that is why MS-DOS is getting confused.

Now let’s try MS-DOS 4.00M

Well now isn’t that interesting?!

Excited with the ability to create special MS-DOS 4.00M programs, I get my favorite vintage ’87 Infocom interpreter, InfoTaskForce 87, and get it building on MSC 3.0. However instead of using the MS-DOS 4.00M linker, I thought I should try to use the Windows 1.01 linker and libraries for the exe:

C:\dos\msc3\infocom>msdos ..\win101sdk\bin\LINK4.EXE @infocom.win.lnk

Microsoft 8086 Object Linker
Version 4.00  (C) Copyright Microsoft Corp 1984, 1985

Object Modules [.OBJ]: FILE.OBJ FUNCS.OBJ INFOCOM.OBJ INIT.OBJ INPUT.OBJ +
Object Modules [.OBJ]: INTERP.OBJ IO.OBJ JUMP.OBJ OBJECT.OBJ OPTIONS.OBJ PAGE.OBJ +
Object Modules [.OBJ]: PRINT.OBJ PROPERTY.OBJ SUPPORT.OBJ VARIABLE.OBJ TERM.OBJ
Run File [FILE.EXE]: INFOCOM.EXE/ALIGN:16
List File [NUL.MAP]: INFOCOM.MAP
Libraries [.LIB]: MWLIBFP MWLIBC/NOD
Definitions File [NUL.DEF] INFOW.DEF;

And for those interested this is my .DEF file:

NAME    Infocom

DESCRIPTION 'Infocom 87 interpreter for Planetfall(83)'

DATA    MULTIPLE


HEAPSIZE    1024        ; Must be non-zero to use Local memory manager
STACKSIZE   4096        ; Must be non-zero for SS == DS
                        ; suggest 4k as minimum stacksize

SEGMENTS
    _INIT   PRELOAD MOVEABLE DISCARDABLE

One thing to save you the horror is that between MS-DOS 2 & 3 the way command line arguments changed. I forget the details but no matter what I tried I was unable to parse the CLI or the environment in this setup. I suppose if I had documentation of the product there would be some hint as to what tools or setup to use. Instead, I took the easy way and hard coded to load Planetfall.

InfoTaskForce compiled with MSC 3.0, using Windows 1.01 libc / LINK4

Unfortunately, this success would prove to be the exception to the rule. I took trek, converted it to K&R C, as Microsoft C 3.00 from 1985 is well. old, and sadly it just won’t run. Likewise, I took Hack 1.03 and although it runs on MS-DOS it will not run on MS-DOS 4.00M. I am sure there is some fundamental reason why it’s not working, and probably tied to creating a proper DEF file. I’m sure it was all written down somewhere but I don’t know. And yes I tried specifying either floating point emulation via library or inline, and it made no difference.

Looking at OS/2 1.00

Loading up the infamous $3,000 OS/2 1.00 beta, and hitting ctrl+escape you are greeted with session manager!

Notice the R for real-mode. With the obvious implication that everything else is protected mode. Going one step further on the excellent site pcjs.org there is OS/2 betas SIZZLE and although there is no OS/2 development bits on there, the directory DOS3TOOL reveals that the C compiler for this era for at least MS-DOS is MSC 3.0. Also included is our friend LINK4.

I create a simple def file that contains the single word ‘PROTMODE’ which should give me my OS/2 binary.

So let’s run that through hello world:

msdos sizzle\DOS3TOOL\link4  hello.OBJ,hello,,,hello.def;

Microsoft (R) Segmented-Executable Linker  Version 5.00.21
Copyright (C) Microsoft Corp 1984, 1985, 1986.  All rights reserved.


C:\dos\msc3>

However attempting to run this just crashes amazingly.

No doubt it’s because the real-mode libc is using interrupt 21 calls, which OS/2 sure wouldn’t like. I’m pretty sure it requires an OS/2 libc that uses DOSCALLS.DLL to function, which I just don’t have any pre-release versions, nor any libc source code to really make it possible. And attempting to port one to OS/2 pre-releases just doesn’t seem so worth the time.

So for the heck of it I point the LIB variable to the OS/2 1.00 SDK’s libs and re-run the link:

C:\dos\msc3>msdos sizzle\DOS3TOOL\link4  hello.OBJ,hello.exe,hello.map,C:\86box\100\x\MSC\LIB\slibc5.lib \86box\100\x\LIB\DOSCALLS.LIB,hello.def;

Microsoft (R) Segmented-Executable Linker  Version 5.00.21
Copyright (C) Microsoft Corp 1984, 1985, 1986.  All rights reserved.

By default it’s trying to link in EM.LIB, SLIBFP.LIB, SLIBC.LIB. Trying to add them all in the command line link just hangs LINK4 maybe a response file is better suited. Anyways:

It does run on OS/2 1.00, which I guess isn’t surprising as the LINK4 & libraries are from/for this version.

As an interesting note, OS/2 links against doscalls library/DLL to interface to the OS. While MS-DOS 4.00M doesn’t have a seperate DLL, rather it’s baked into IBMDOS.COM

DOSCALLS
ALLOCSEG
REALLOCSEG
FREESEG
LOCKSEG
UNLOCKSEG
GETSEGSIZE
GETDSHANDLE
CRITENTER
CRITLEAVE
FCRITENTER
FCRITLEAVE
PBLOCK
PRUN
SUBSCREEN
GETPIDS
DOSDISCARDCODE
DOSGETHANDLE
DOSHANDLEJUMP

Noticeably absent is file I/O, No doubt allowing programs to use the standard int21 interface to the kernel for file I/O. No doubt this is in its primordial state, as the OS was going to evolve a bit more until it became OS/2. Unfortunately I have no idea how to link or call into this. Without any SDK it’s impossible to say. And even then is developing for a real mode OS worth the effort?

So what have we learned? LINK4, aka the MS-DOS 4.00M Linker, probably should have been called LINKNE for the NE format. Also there is references to it having it’s own virtual memory paging system, and being able to link larger EXE’s than the traditional link command. Sadly I was unable to get any non trivial programs running. I don’t think it was a memory model thing, although the C compiler has issues with InfoTaskForce and the large memory model for some reason, but small & medium work fine. I’d like to think that DOS 4.00M could support massive EXE’s much like Windows 1.01, however despite being from the same company and using the same tools, the memory manager for DOS 4.00M & Windows is fundamentally different.

With all these exiting OS/2 betas now available I’ll have to take some more time to explore them in more detail.

But until then I thought this genesis of DOS 4.00M was worth the look.

Chasing more 386 OMF

Posted on October 22, 2021 by neozeed

Microsoft’s first 32bit OS, Xenix

Well back before, I had been looking into old linkers for 386 OMF, I knew I’d found some fun with some old GNU tools going back to the heyday of Xenix 386. As kind of expected the tools used to build Xenix, along with it’s SDK were in fact Microsoft C/MASM. So yes way back in 1987 Microsoft not only has MASM386, but they also had a 32bit Microsoft C 5.00. Let that sink in for a moment as OS/2 had been forced into 16-bit land despite FOOTBALL, and Windows/386 being a 386 VM86 multitasker. So in a weird way all the parts were in existence.

Back in the old days of GCC 1.x there was a bit of excitement about the file masm386.c in the old GCC source directory, sadly despite it being updated, there was no real public push on modifying GCC to support non AT&T assemblers. Instead something unexpected (well to me!) happened is that GAS had been modified to output OMF.

I tested this on MinGW with some simple stuff, and sure enough it links just fine. Considering its what is on the GCC on Xenix port I’m sure it’s pretty solid.

Enter OS/2

Now this is more fun, and again kind of sad that GCC didn’t take on the ability to target other assemblers (just look at the x68000!), Maybe they didn’t see GAS for OMF, or just didn’t know. Instead a more aggressive choice was made, to alter the binary output. Linking on OS/2 with EMX involved 2 very different and incompatible paths, the first one is the ancient Unix i386 a.out format, which then a utility called emxbind will convert into a loader & stub that OS/2 can run. Think of it as an OS/2 extender to take simple Unix programs (which is what they are) to run on OS/2. Neat!

The second more ‘native’ approach is to convert the binary a.out files into what is known as OMF files, which non GNU linkers like Wlink from Watcom or Link386 from Microsoft can then link into direct native EXE’s or DLL’s.

There had been an experimental ELF build of the EMX toolchain on OS/2 but I think it may have died? So as crazy as it seems bigger and crazier programs need to be built on systems like Windows or Linux and linked outside of OS/2 to get around the old memory limits. It’s really hard to say as I’ve never used it, although being able to do the link outside of OS/2 would be an advantage.

I’ve found 2 programs to convert the a.out objects into OMF, the first and oldest being o2obj. The one drawback I’ve had is that this doesn’t play so well with the Watcom 386 OMF linker. Instead the much later RSXNT/LIBC0.6 project’s emxomf. I’ve done some painful hacking but it appears to do what it should do. A simple omfdump seems to be spilling stuff out.

Of course the alternative is to use a 64bit linker, and since a.out has been pulled from binutils the only real hope is the Watcom linker which is now running in a 64bit address space. And the Watcom chain won’t understand ancient i386 a.out, however Microsoft 386 OMF it certainly will, although it appears to be based around something later than the aforementioned o2obj, which is why I ahd to do the emxomf.

I know as this stands it’s not very satisfying but I kind of wanted to push this out the door as I’d been hacking from time to time on it, and didn’t want to leave it to rot completely. The EMX tools remind me of the NeXT stuff where everyone goes native platform wild never imagining a day when remaining portable would mean it’d be easier to target more software.

The one thing I wonder about sometimes if there was some kind of secret Microsoft extended DOS/Windows that relied on OMF & Link386 that predated the NT team and their switch to COFF? Obviously it’d be super obsolete and would have been something like the first PharLap 386 stuff. But I’ve only owned a disk dump of v4, and a legit copy of TNT v6. Old 386/DPMI/Extender tools are hard to find.

Linkers & loaders, along with binary formats are too hard for me, but I thought I’d share at least what I’d been able to conjure with MinGW. I’ll have to touch on EMX to native OMF linking later.

Citrix South Beach: aka the missing link from text to graphics

Posted on August 5, 2021 by neozeed

A long long time ago, in a distant continent I once interviewed at this small company called Citrix. It was some QA position, they didn’t need programmers. I’d passed the interviews easily as I’d been programming serial TSR’s so I was hip to the 8250/16450. Citrix was an interesting but troubled company. They had incredible contacts and more importantly a deal from Microsoft that gave them access to OS/2. Sadly OS/2 1.0 had been a dud, and by the time OS/2 2.00 saw even a limited release, Microsoft had pulled out of OS/2. Citrix was a company that had lost twice in what should be a big market. -Multi user commodity systems.

Citrix Multiuser 1.0 was based on OS/2 1.21, and was limited to 16bit protected mode apps. Citrix Multiuser 2.0 was based on the Limited Availability version which means that it cannot run “GA” or General Availability programs. So no 32bit programs here. Instead it can run the same 16bit protected mode applications, however it can also run MS-DOS based programs. DOS4/GW programs run so oddly enough the only real commercial stuff that can be run is MS-DOS.

So here we were 1994. Citrix had struck out twice, but this time it was going to be different, but the deal had to be re-struck again. I have no idea how they managed to secure this lucrative deal again, but Citrix was able to get access to the source access Windows NT, after the 3.1 release to 3rd parties (when they got DEC involved). By now the world had gone Windows, Office 4.2 was a thing, and on the high end side, NT had SQL & SNA, and there was most defiantly a market for multiuser systems as there had been from the old days of Unix, with the old mix of ASCII and network graphical terminals.

The CD looks like a normal-ish NT 3.5 Server CD although there is no MIPS or Alpha builds, as expected everyone at Citrix would be working and targeting the larger established i386 market.

As you can see this is Beta build 101.

In the text mode setup it looks like a normal setup program. No doubt they had better things to do than skins, wallpapers and themes. HOWEVER there is a silent IDE bug that many people will no doubt run into:

Although it works okay in short bursts, the IDE driver will send a command 28 zero byte and then shut down the controller. From this point it hangs. So that means we either need to generate all the floppy disk images (not going to happen!) or do the MS-DOS cross install. Yeah I’m doing that instead.

When setting up under Qemu, use the AMD PCNET card. It’s much easier. I set it to Twisted Pair, and PCI bus. I’m not sure if those matter all that much, but it works for me!

If you are going to use Hyper-V, you’ll need the GF100 NIC driver, but use the Windows NT 3.1 driver, as this is technically a beta of NT 3.5 and the production 3.5 driver will blue screen.

I set the driver to autosense.

I also had both Qemu and Hyper-V bluescreen when doing DHCP. I don’t know what the issue is, and I’m too old to care as I don’t have source code to South Beach, and even if I did I’d probably regret posting fixes. So static IP address it is!

Ready to login

Honestly again the air in the office when I was there is that everyone was running around like crazy to QA the product, and get ready to expand client support. While I was too much of an OS/2 fan boy, they certainly knew that from now on everything was going to be about Windows NT.

Logging into the Citrix the first fun thing to do is to define some remote terminals, using the WinStation app.

The first interesting thing is that async terminals are supported. Along with using either NetBIOS or Winsock protocols for connecting clients. Isn’t that great! TCP/IP built in!

Now for the crazy part. The only client that works is MS-DOS based. Yes there is no Win16, no Win32, no Java, no protected mode DOS, no Linux, SunOS, Solaris, DG/UX, AIX, HPUX, Xenix, UnixWare or SYSV i386ABI. ONLY Real Mode MS-DOS. Despite the connections being able to be ICA version 2 or 3, they are incompatible with newer Windows based clients from Win Frame.

This it the following list of supported protocols. Although I had Novell Lan WorkPlace and used it before for Desqview X, I can’t find it at the moment. good luck finding FTP TCP/IP, in retrospect it’s a terrible name, and for all intents and purposes it’s disappeared from the earth. So that leaves Microsoft TCP/IP. Now all the LANMAN clients have it, although this isn’t what it wants. It wants the MSCLIENT found in the “\CLIENTS\MSCLIENT\NETSETUP” path from a retail version of NT Server 3.5

The DOS client is.. very touchy. Deleting profiles can lead to a corrupted profile. Altering existing profiles well yeah can lead to a corrupted profile. I thought it was EMM386 causing issues but it locks up on it’s own.

Revenge of text mode UI

One interesting thing I found is that the text mode UI didn’t die. It’s still very much alive. As mentioned above you can connect async terminals, or even connect over the network!

Text mode does bring up a Program Manage analogue, but all my programs are graphical so it’s kind of moot. But rest assured text mode stuff works great.

So 32bit Fortran stuff works great, what about MS-DOS?

Here is MS-DOS / Qbasic editor. Running on Citrix South Beach! Great, what about OS/2?

And here we go running the f2c translator through Dungeon to get an OS/2 text mode app. As you can see forcedos reveals that this isn’t a bound executable, instead it only runs on the OS/2 subsystem.

As you can see the os2.exe/os2srv components of the OS/2 subsystem

And of course it looks better on the graphical client to mix and match them all.

Indeed Word & Excel for NT work great alongside everything else.

Obviously somewhere post South Beach the text mode stuff dropped off. I’ll have have to dig for more, but it’s kind of neat the idea of a real text mode NT. Sadly South Beach doesn’t seem to like VMware. I haven’t dug too far, as I like WSLv2 so I’m stuck with Hyper-V. It may work fine on ESX I haven’t tested. Obviously you need the appropriate drivers, ill try to update links later, if anyone cares.

No doubt that finally Citrix was no positioned to realize the dream of multiuser commodity based hardware along with commodity applications. Of course it wouldn’t be all sunshine and rainbows, and no doubt there was a toll needing to be paid between Windows NT 4.0 and on the way to Windows 2000. But back in 1994, things were looking good!

IBM OS/2 J2.1 Beta Release (aka 90’s CD-ROM done right)

Posted on June 27, 2021 by neozeed

Frustration of the early 1990s

Something that used to annoy me to no end back in the early 90’s was nearly empty CD-ROM’s from big companies. Back then dialup was the norm and I was ‘lucky’ enough to have a 2400 baud modem back in 93. I wanted a 32bit processor and at least 4MB of ram to join that elite home based 32bit computing to finally feel like I’d upgraded well beyond the Commdore 64, but money was tight and that 2400 baud modem I got on sale from BrandsMart USA was ‘good enough’. I’ve had a 300 baud modem on the c64 so I knew the feeling of absolute painful downloads.

Heck internet access wasn’t so prevalent, and dialing up to BBS’s was super common. It’s a BBS where I stumbled across Linux on CCUG, which was both great for being local but also letting me download at night at 2400 baud as many BBS’s kicked me for being too slow. Thanks Doug!

But here we had this awesome era of CD-ROMs, I managed to snag a NEC Intersect single speed external from TigerDirect, who would have these annual sales to clearance all kinds of RMA’s. It was a great time to get stuff for pennies on the dollar as they say. It was amazing to have access to nearly 700MB of data per disc. But it was amazing how empty so many were.

One such opportunity to ship as much as possible to the users was absolutely missed in OS/2 2.1/3.0 Looking at the EN-US release you find the OS/2 2.1 for Windows CD-ROM contains just the OS, both extracted and disk images:

Volume in drive E is OS2_CD_ROM
  Volume Serial Number is 4384-1BD8
 Directory of E:\
 [DISKIMGS]    [MMPM2]       OS2SE20.SRC   [OS2SE21]
                1 File(s)             10 bytes
                3 Dir(s)               0 bytes free

 Total Files Listed:
          645 File(s)    292,279,546 bytes
          135 Dir(s)               0 bytes free

with 300MB on the disc that left space for another 300MB. What could they have put on there? Obviously the best answer is 3rd party drivers, any and all SDK (Although we are talking about IBM who famously priced the OS/2 1.0 SDK for $3,000), demos, utilities, free software?!

Enter OS/2 2.1J Beta of Japan

While on the Discord some cheap OS/2 CD-ROMS popped up and @plaman was nice to image them for me. I was more interested in Borland C++ 2 for OS/2 but there was also this Japanese beta of 2.1. Normally I wouldn’t be all that interested as I was thinking it was for PC-98 but but’s the ‘DOS/V’ variant which is mostly like a normal PC. But mounting the CD-ROM showed it was far more interesting:

Volume in drive F is V_MAG9310
  Volume Serial Number is DD59-9766
 Directory of F:\
 [DOS_WIN]     [OS2BETA]     [OS2DEMO]     [OS2FREE]     OS2SE20.SRC   [OS2SUPP]     [PCGAMES]     README.1ST
 [VMAG]
                2 File(s)          2,187 bytes
                7 Dir(s)               0 bytes free

 Total Files Listed:         2867 File(s)    501,115,944 bytes
          637 Dir(s)               0 bytes free

PC Games?! Demos?! What is this! And sure enough it has a tonne of game demos including a bunch of Sierra, LucasFilm and even an Electronic Arts Syndicate demo!

Indiana Jones and the Fate of Atlantis Demo

In the freeware directory its a selection from Hobbes, including EMX 0.8F, and the GCC/2 port. Also hidden in there is ‘S_O2OBJ.ZIP’ which is the source to a program to convert GAS i386 a.out object files to OMF for use by LINK386 (yes that adventure is ongoing), and all kinds of other fun things. What is nice is that the source code archives are included as well. Thanks IBM of Japan!

In addition there is of course one of those ‘OS/2 demo’ slide show apps

It’s just a simple slide show thing to go over how to use the new desktop

Transform your ‘old’ desktop to the new metaphors of the past:

Into the OS/2 future! Of course you have to understand it’s 1993 by now, and the vast majority of the world is using either Windows 3.0 or 3.1. The new OS/2 2.00 UI is so radically different that even Windows 10 doesn’t attempt the same level of object integration. Although leaving it like the above would be more of a ‘Bob’ type of move, the real world result was this:

Of course in the demos the backdrop per folder thing in OS/2 always looks great, but in real life it was never the same. Perhaps it was the limitation of editing tools of the time, or how OS/2 had a different bitmap format from Windows, which really limited the ability to interchange images.

Compare this to the clutter of the Windows 3.0/3.1 desktop:

Obviously the ‘winning move’ was the Windows 95 desktop which reduced icons to mere shortcuts to give the illusion of something like the OS/2 desktop, but without anywhere the level of complexity and integration made for something far more lightweight. Of course I don’t even want to talk about the binary ini files, their ability to corrupt and booting off diskette to rebuild the desktop by hand. When things failed on OS/2 they failed in the most amazing ways.

At the end of the day;

I still haven’t tracked down a release version of OS/2 2.1 for the Japanese market to see if the CD-ROM version shipped with anything beyond the OS. Perhaps it was simply a beta thing. But these shovelware discs always have a great accidental archives of the era. And it’s nice to see that some OS/2 stuff got preserved for once.

Virtually Fun

Fun with Virtualization

Category Archives: OS/2