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.
Well something interesting and slightly different popped up, it’;s OS/2 2.00.. but in a different box, packaged for the UK market.
14G0495 – Generic Package
You have to hand it to IBM for making something amazing for 1992 so.. Bland and Generic. You really have to think there was some truth to that deal with Commodore licensing their bland grey style from the Amiga DOS 2.0 betas in exchange for a REXX.
One thing I did like about this package is the included quick reference card. I don’t recall this in the US version.
Front side
Sorry I don’t have access to a scanner here, so this is about all I can do.
Installing this was a bit of a bear, as the only thing I could boot this up in was VMware.
XR02000
From a glance it pretty much looks the same as the US release, as an end user the only thing I saw different was that during the install it defaults to a UK keyboard, and Locale.
UK in the UK
I guess that is to be expected? The xr06100 fixpack installed without any fighting, so that was nice.
Sadly no stickers in the box, so it’s very underwhelming in that regard.
Ill have to look into the bootloops and crashes under qemu/bochs later. I had planned on installing it on an old machine I literally pulled out of the garbage, but it doesn’t emulate a PS/2 mouse with USB, so I have kind of put that on hold.
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’semxomf. 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.
well rounding out the experiment is of course the hidden OS/2 2ine. And how does it respond to the various linkers?
Operating System/2 LX (Linear Executable) Linker
Version 2.00.000 Mar 20 1992
Copyright (C) IBM Corporation 1988-1991.
Copyright (C) Microsoft Corp. 1988-1991.
All rights reserved.
If you remember this is from the Limited Edition or Citrix Multiuser 2.0 version:
[<ohestwo>-C:\TEMP]\os2\link386 mt.obj
Operating System/2 Linear Executable Linker
Version 2.01.005 Mar 16 1993
Copyright (C) IBM Corporation 1988-1993.
Copyright (C) Microsoft Corp. 1988-1993.
All rights reserved.
Run File [mt.exe]:
List File [nul.map]:
Libraries [.lib]:
Definitions File [nul.def]:
LINK386 : warning L4071: application type not specified; assuming WINDOWCOMPAT
[<ohestwo>-C:\TEMP]mt
hi
[<ohestwo>-C:\TEMP]
and on 2ine?
$ ./lx_loader /mnt/c/msos2/test/mt.exe
not an OS/2 module
$
Well this all sucks. But how about a 3rd party linker? Watcom?!
C:\msos2\test>cl386 /c mt.c
Microsoft (R) Microsoft 386 C Compiler. Version 1.00.075
Copyright (c) Microsoft Corp 1984-1989. All rights reserved.
mt.c
C:\msos2\test>wlink d all SYS os2v2 op m op maxe=25 op q op symf @mt.lnk
C:\msos2\test>dir mt.exe
Volume in drive C has no label.
Volume Serial Number is 3C41-1D63
Directory of C:\msos2\test
13/05/2021 01:48 am 5,160 mt.exe
1 File(s) 5,160 bytes
0 Dir(s) 646,855,708,672 bytes free
C:\msos2\test>
Obviously this needs more testing on later versions of OS/2. I tried wlink from Watcom C/C++ 10.0 and it won’t run. Once more again the devil is in the linker, and just as last time, it turns out that the ‘portable’ tools are 16bit!
Microsoft OS/2 Software Development Kit Pre-Release 2
I don’t know why, but Microsoft OS/2 2.00 beta’s are beyond rare. At one point I had a documentation set but not disks. However disk images circulated around, so at one point I did have printed documents (that basically didn’t show much interesting other than True Type fonts for OS/2), and the SDK/ToolKit. However there to date has been no operating system images surfacing.
Since yesterday’s look at the 1991 Windows NT Pre-release which turned out to be using the OS/2 compiler, I went back and checked the Microsoft OS/2 SDK, and it turns out that the compiler is a ‘bound’ executable, meaning that it’ll run under MS-DOS!… And for us that means the MS-DOS Player can make native Win32/Win64 executables out of the compiler/assembler.
Microsoft (R) Microsoft 386 C Compiler. Version 1.00.075 Copyright (c) Microsoft Corp 1984-1989. All rights reserved.
As always the devil is in the details, and this time it’s the linker. I now have OS/2 2.00 v123 (February of 1991), Citrix Multiuser 2.0 (March 1992), and OS/2 2.00 GA (July 1993). And not surprisingly despite them all either including a system link386.exe or the SDK link386 they have massive final incompatibilities.
For fun, I’m using a super simple C program, and compiling it with the Microsoft Pre-Release 2 SDK. After that I’m just using various Linkers & OS’s and the same Pre-Release libraries to see the same object relinked and running.
void main(void){
write(0,"hi\n",3);
}
It’s a very simple program that really doesn’t assume or need much other than write.
So looking at OS/2 build 123
Version 1.01.015
This is the SDK Linker 1.01.015. Dated November 28th, 1990. Which sounds a bit late in the year, but don’t worry as the OS includes Version 1.01.018, dated August 15th 1990!
Version 1.01.018
I don’t understand it either.
Citrix Multiuser 2.0
Version 2.00.000
Citrix Multiuser is using the 177H base also known as the OS/2 2.00 LE. It includes a version 2.00.000 linker, which works fine for it. However the SDK and 123 linked files do not run. While the SDK runs fine, I don’t know how did they link the tools as they work fine**.
OS/2 2.00 GA
Version 2.01.005
And finally we have OS/2 2.00 GA using it’s linker, and yeah it runs fine. Also the GA can run the LA linked files. Naturally 123 can’t run either LA or GA EXE’s.
Obviously the tool group was separate from the OS teams, and there was that brief window when everything 32bit was OMF, and LX was going to be the grand behind the doors unification thing providing 32bit exe’s for Windows 3.x VXD’s, OS/2 2.x and Windows NT. But as was obvious in the 1991 Pre-Release the tool to convert OMF to COFF wasn’t going to be a tool much longer and it was going to be integrated directly.
I’ve tried using the link386 from the Windows 3.1 DDK but I can’t get it to link properly. Just as I haven’t tried other MASM386’s or even 16bit MASM 5+ which apparently support 32bit OMF?
Again it’s interesting to me, but is it useful? Not really. Also the last interesting bit is that the Microsoft C from the 73g build of the Windows 95 SDK can produce assembly that the Pre-Release more or less understands:
D:\OneDrive\proj\link386>4.00.73g\BIN\cl /c /Famt.asm mt.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 8.00.3200
Copyright (c) Microsoft Corp 1984-1993. All rights reserved.
mt.c
D:\OneDrive\proj\link386>
And then assembling and linking on OS/2
Useful? Not very. I don’t think anything complicated will run, although I have only tried one thing and it had a tonne of 16bit/32bit collisions. I don’t know if Microsoft C/C++ 8.0 for OS/2 is all that desirable but I’d imagine if it were, smarter people than I would have made it a thing.
**Edit from the future
Well it turns out the SDK tools are 16bit Family mode apps. It’s obvious once Nathan pointed it out that there is no 32bit ‘bound’ for MS-DOS, however there was Family Mode*** for realmode/protected mode 16bit code.
PharLap famously made their early 286 extender based around OS/2, however for the 32bit stuff it was apparently home grown for the early stuff (I have version 4) but there is DLL’s to emulate MS-DOS like the 286 extender. Interestingly enough DOS/4G supports DLL’s but again there is no DOSCALLS.DLL I can find, but the loader loads it.
***Family Mode/Family API
From the book INSIDE OS/2 (ISBN 1-55615-117-9):
2.2.4.1 Family API To provide downward compatibility for applications, OS/2 designers integrated a Family Applications Program Interface (Family API) into the OS/2 project. The Family API provides a standard execution environment under MS-DOS version 3.x and OS/2. Using the Family API, a programmer can create an application that uses a subset of OS/2 functions (but a superset of MS-DOS version 3.x functions) and that runs in a binary compatible fashion under MS-DOS version 3.x and OS/2. In effect, some OS/2 functions can be retrofitted into an MS-DOS version 3.x environment by means of the Family API.
The linker is from an older MS SDK, the compiler from October 1991 preview of NT
So back in the day I wrote something vague about the October 1991 preview version of Windows NT, and after messing with the tools and building f2c & dungeon (among some other stuff) one that that stuck out to me is that the object files had to be converted for NT.
cvtomf!
The interesting thing is of course that it doesn’t support the cl386 direct compile and link (hence CL). Instead you have to compile, convert and then link. A fun thing about the October 1991 version is that there is a cl386 cross compiler for OS/2. So while looking around for OMF linkers (and assemblers that either understand GAS but output OMF, or some translator) I ran across this, and well yeah, it turns out that the OS/2 tool chain is the toolchain. I guess it makes sense in that the NT team was using OS/2 to build NT, but objects and exe’s were not solidified.
I think 6.00.080 was the last version of Microsoft C 386 for OS/2. I need to start collecting more of the SDK/DDK’s of the mixed era, I think the LX/OMF stuff was a bit more widespread hiding in plain sight.
Anyways, interesting?! sure. useful? Maybe 30 years ago. Although I’d probably say just use Watcom C/C++ instead of Microsoft C 6.00
This is nothing short of amazing. In the last update, 2ine was running simple 32bit programs on Linux, and providing a portable API set to allow strict OS/2 API based programs to run on Linux.
And now Ryan has turned his focus onto 16bit support for 2ine, which you can read about here:
As you can read right now It’s running a simple OpenWatcom 16bit hello world based program. The 16bit OS/2 and 32bit OS/2 API’s ended up having different calling sizes, among other issues which had complicated the bridge program. However Ryan’s newer use of scripts to generate the required glue for the API’s at least mean that adding the 16bit/32bit calling conventions & required bridges/glue is at least now automated.
This is super cool, as this will eventually open the door to Watcom C/Fortran, Zortec C, Microsoft Basic/C/Cobol/Fortran and of course many other languages that burst out into the initial OS/2 scene before the eventual weight of the SDK & associated costs doomed OS/2 to failure.
Seriously, for those among us who love OS/2 and have like $5 to spare, send some encouragement to Ryan… 🙂
So this is really super cool! Ryan C. Gordon has written a Wine like program to run OS/2 programs!
Using 32bit Linux, and some native libraries, 2ine can load up an LX (32bit) executable and try to run it under Linux, much in the same way that Wine can run Windows programs. And yes it’ll run EMX built stuff. Although keep in mind the original Microsoft based languages, programs and tools is all 16bit. After the whole Windows 3.0 thing and the split of Microsoft from the OS/2 project all their tools are either 16 bit, or 32bit LE format, which IBM had dumped for the LX format once OS/2 2.0 had shipped.
You can read about his incredible progress, and all the trials and tribulations of running OS/2 programs, along with the craziness that is thunking back and forth to the 16bit space for the old VIO calls that had never were updated to 32bit in that transition phase where a good chunk of OS/2 never was updated from 16bit, over on his patreon page here.
Attempting to run anything 16bit or LE will give you:
At End Of Road Score: 36/0
Welcome to Adventure! Do you need instructions? (y/n) >n
ADVENTURE
A Modern Classic
Based on Adventure by Willie Crowther and Don Woods (1977)
And prior adaptations by David M. Baggett (1993), Graham Nelson (1994), and
others
Adapted once more by Jesse McGrew (2015)
Release 1 / Serial number 151001 / ZILF 0.7 lib J3
At End Of Road
You are standing at the end of a road before a small brick building. Around you
is a forest. A small stream flows out of the building and down a gully.
At End Of Road Score: 36/0
>
Again it’s works so well it’s amazing!
You can find the 2ine source over on icculus.org here. I had to tweek the heck out of the CmakeList.txt to get it to build, and since I was interested in the command line, I ended up disabling all the SDL / PM stuff, and make sure I had the ‘wide/unicode’ version of ncurses installed.
I don’t think there really was any killer 32 bit OS/2 applications, but with clean room versions of:
doscalls.dll
kbdcalls.dll
msg.dll
nls.dll
quecalls.dll
sesmgr.dll
tcpip32.dll
viocalls.dll
Not to mention being able to call into Linux DLL’s and using ‘clean’ OS/2 DLL’s would let you embrace and extend OS/2.. Or maybe even let you build the proverbial fantasy of both RISC & 64 bit OS/2. …..
I don’t know why I did it, as honestly I didn’t like it on CGA back when it was a thing. Also, thankfully the hard disk speed on PCem is way faster than the real thing. And I’m not complaining.
Installing
Text mode is all the same setup wise, but on reboot the installer goes forward in glorious CGA ‘high res’ mode. Which is pretty terrible.
Welcome to OS/2!
Yuck. I guess at the time I just felt lucky that I could at least run it. Although once I got lucky enough to score an EGA card + monitor. Anyways let’s continue the horror!
Command prompt
Yep, there is the desktop! .. barely. The desktop constantly want’s to jump around which is annoying, just as command prompt’s cant decide if they should be black or white. And the font’s get truncated. It’s almost as if nobody cared about actually supporting CGA. Which honestly I’m more surprised that it even made the cut.
Word and the fox
Sure, I could have changed the default font, but why should I? I know Word 1.1 is very primitive but wow.
To be fair, Windows in CGA is pretty terrible as well.
Could they make the title bar any larger?
Not to mention solitaire on both is nearly impossible between the lack of colour, and the lack of any high resolution. I suppose the Wyse 700 display ought to be much nicer, if only they had gone through the hell of making OS/2 device drivers.
