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

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!

Leisure Suit Larry 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

Very AmigaDOS 2.0

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.

If you are interested you can download the ISO on archive.org here: OS2J21_Beta

Ultra rare IBM OS/2 ad featuring OS/2!

I honestly didn’t think anything like this existed

Stay 2'ned. Can't help but think of 2ine.

Presentation Manager for Windows NT

This is something that honestly deserves so much more. Back in the original scope of NT OS/2 it was going to be a C parallel of OS/2 2.00 Cruiser that had the promise of running on one of those new fangled microkernels, and those trendy RISC workstations. The 486 / Pentium were considered like the 68040/68060 to be the peak of CISC processors and from there on it was going to be a RISC world, the only question was to be which one?

Many of the Motorola customers who couldn’t afford to make their own (SUN with the SPARC), or license a school project (SGi with MIPS) were expected to use the 88000 processors that were expected to eclipse the 68040. There was an Apple initiative, and even a NeXT RISC Workstation built among many others. Only with the launch of the 88010 it was discovered performance was nowhere near expected and it’d take significant work to fix.

Back on the i386 side, Microsoft had been working with Intel on their upcoming RISC, the NTen aka i860. And just like the 88000 it too had performance issues, which resulted in Microsoft retargeting the MIPS.

Things changed along the way, and not only was the primary CPU platform dumped, but Windows 3.0 became such an incredible seller that OS/2 Cruiser was dumped from NT OS/2, and it became Windows NT. NT had been promised with the ability to run OS/2, MS-DOS, and POSIX applications, with an emphasis on Win16 and the new extended Win32 applications. However MS-DOS was super limited, POSIX was just enough to run vi & tar, Win16 was incredibly slow as it ran through WOW (Windows on Windows), and OS/2 had been kneecapped to the 16bit 1.x support as it was primarily a vehicle for running Microsoft SQL Server 1.0/4.0 . Another consequence of this is that OS/2 was command line only. In the back of deployment guides, and resource kits there was always an inference to a Presentation Manager subsystem for NT, although I’d never seen one in the wild.

Until I got a hold of a bunch of Microsoft Select CD-ROM’s that mostly were multilingual service packs of Office and Windows 98 / NT 3.51 & NT 4.0 But burred in there was a copy of Presentation Manager for NT 3.51!

First off it’s a text based install. It feels like October 1991 all over again. It installs a parallel OS/2 directory with presentation manager support.

Once it is installed it’ll setup program icons from the Windows NT side. Presentation manager runs in a separate window from the GDI. This is akin to how OS/2 would run Windows in a ‘full screen’ session. So oddly enough both support each other’s 16bit applications full screen, while reserving the desktop for 32bit applications. IBM would later introduce dual mode video drivers capable of rending Windows and OS/2 applications at the same time. Clearly Microsoft would never do this.

Launching the control panel reveals that it’s OS/2 version 1.3. No big surprise there. You can return to the Windows NT desktop either via the Windows NT icon in the bottom right, or via a Control+Alt+Delete.

The DeScribe 3 beta installs pretty smoothly into the subsystem. However running Describe is a different story:

It hangs trying to open or do anything. Even the ‘help about’ is too much. Such a pitty.

The readme warns against trying to copy the file manager from OS/2 although it does tell you what files to copy in manually. Naturally there is no ‘console’ for Presentation Manager, rather that is handled on the Windows desktop.

No doubt there had to be some big customer that demanded a way out for their investment in Presentation Manager on Windows NT. Otherwise this would have been built in. And it’s only 5 diskettes so it’s not a space issue. I suspect since it was on a Select CD, it really was not meant for wide scale distribution.

Last time I tried, Excel 3, and Word 1 had issues running on Windows NT, as the loader tried to intercept them as Win16. Things didn’t go so well. Or maybe it’s my memory. I went ahead and installed Excel 2.2 for OS/2

Despite it being text mode, it has Presentation Manager hooks, and needs PM Shell to be running. It’s a simple setup program, but yes, it’s text mode.

One nice thing about Describe & Excel is that they can see the program groups on the NT side, and create icons over there. However NT has no ability to read OS/2 resources so the icons are all incorrect.

And yes, Excel for OS/2 runs on Windows NT! Back then Excel was super expensive, this is before the big Office OEM bundles that took over the industry. So I could totally see preserving this massive investment in Excel.

Despite having 80286 emulation in the earlier versions of NT, and 80486 emulation in Windows NT 4.0 (Yes DooM runs on the MIPS!) the OS/2 subsystem was never available on the RISC platforms. I suspect had Windows 3.0 not been a big seller it may have. Then again without the big ‘rabbit out of a hat’ like DOS Extenders, Windows would have died on the vine. Who knows, maybe NT OS/2 is a thing in a parallel universe.

All in the Family

One of the more interesting things about OS/2 1.x is how it had this interesting idea of how to strattle the bridge between old and new, and it was a very common bridge tactic where you can have a shipping program that can simply run in both the older operating system, and the new one. Naturally there is trade offs, you can’t fully take advantage of all kinds of features on the new side, you will be largely held back on the old side, but all is not lost, there is space for things that fit in the ‘same but bigger’ world where you have an overlap between old and new.

For OS X, this was the Carbon era, for Windows this was the famous Win32s extensions, and for OS/2 it’s the Family API.

As a quick example, allocating memory under MS-DOS may be limited to 640kb, but under OS/2 you have access to so much more memory, the entire capacity of an IBM AT class machine. And this also got OS/2 tools into a lot of MS-DOS developer’s hands as the early compilers and tools were built around the Family API and were able to run on so called legacy environments. Although it was far better to run on OS/2, the advantage 30+ years later is that MS-DOS emulation is more common and prevalent than OS/2, especially on non x86 processors.

Ages ago I had done a very simple video memory dump of the Microsoft Programmer’s Library giving me electronic access to the old documents, and a few queries give these as the Family API building blocks:

DOS

  • DosAllocHuge
  • DosAllocSeg
  • DosBeep
  • DosBufReset
  • DosCaseMap
  • DosChDir
  • DosChgFilePtr
  • DosCLIAccess
  • DosClose
  • DosCreateCSAlias
  • DosDelete
  • DosDevConfig
  • DosDevIOCtl
  • DosDupHandle
  • DosEnumAttribute
  • DosErrClass
  • DosError
  • DosExecPgm
  • DosExit
  • DosFileLocks
  • DosFindClose
  • DosFindFirst
  • DosFindFirst2
  • DosFindNext
  • DosFreeSeg
  • DosGetCollate
  • DosGetCtryInfo
  • DosGetDateTime
  • DosGetDBCSEv
  • DosGetEnv
  • DosGetHugeShift
  • DosGetMachineMode
  • DosGetMessage
  • DosGetVersion
  • DosHoldSignal
  • DosInsMessage
  • DosMkDir
  • DosMove
  • DosNewSize
  • DosOpen
  • DosPutMessage
  • DosQCurDir
  • DosQCurDisk
  • DosQFHandState
  • DosQFileInfo
  • DosQFileMode
  • DosQFSInfo
  • DosQPathInfo
  • DosQVerify
  • DosRead
  • DosReallocHuge
  • DosReallocSeg
  • DosRmDir
  • DosSelectDisk
  • DosSetDateTime
  • DosSetFHandState
  • DosSetFileInfo
  • DosSetFileMode
  • DosSetFSInfo
  • DosSetPathInfo
  • DosSetSigHandler
  • DosSetVec
  • DosSetVerify
  • DosSizeSeg
  • DosSleep
  • DosSubAlloc
  • DosSubFree
  • DosSubSet
  • DosWrite

Keyboard

  • KbdCharIn
  • KbdFlushBuffer
  • KbdGetStatus
  • KbdPeek
  • KbdSetStatus
  • KbdStringIn

Video

  • VioGetBuf
  • VioGetConfig
  • VioGetCurPos
  • VioGetMode
  • VioGetPhysBuf
  • VioGetState
  • VioReadCellStr
  • VioReadCharStr
  • VioScrLock
  • VioScrollDn
  • VioScrollLf
  • VioScrollRt
  • VioScrollUp
  • VioScrUnLock
  • VioSetCurPos
  • VioSetCurType
  • VioSetMode
  • VioSetState
  • VioShowBuf
  • VioWrtCellStr
  • VioWrtCharStr
  • VioWrtCharStrAtt
  • VioWrtNAttr
  • VioWrtNCell
  • VioWrtNChar
  • VioWrtTTY

I’m sure this is not exhaustive by any stretch. I got the list from a simple query like this:

grep -i 'family api' os2dev.txt | awk '{print $2}' > fam.txt
grep -i 'family api' prgmr[34].txt| awk '{print $3}' >> fam.txt
sort fam.txt | uniq > family.txt

As an added bonus you really don’t have to mess with the API at all, as the LIBC will use it no doubt.

At any rate, using Microsoft C 6.00 (I can’t get the syntax right for 5.1 to save my life, I suspect I need to run it UNDER OS/2 to build for OS/2 properly), you can compile a typical stdio compliant program, and get an OS/2 executable.

The real fun is from the bind program which will convert that OS/2 program to a full Family mode app with the bind program.

And now on MS-DOS (Under OS/2) you can see very quickly that the OS/2 app won’t run, however the family mode one does!

So this is what let’s me run the older SDK tools as I’d simply forgotten about this great mode, letting you run programs in either environment.

Of course the added fun is the 3rd party product Phar Lap’s 286|Dos-Extender that provides some OS/2 services under MS-DOS in addition to greater memory but DLL’s! But that’s for another story.

**EDIT Oh and another edit, here is how to make the OS/2 program ‘window’ compatible with a link time definition file:

OS/2 2.00 via telnet

and then on the console:

Window mode

And there we go with some magical flags & def file it’s now marked as being compatible with window mode. So no full screen VIO tricks for you!

Wlink-ing for fun & … profit?

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:

$ ./lx_loader /mnt/c/msos2/test/mt.exe
mmap((nil), 8192, RW-, ANON|PRIVATE|FIXED, -1, 0) failed (1): Operation not permitted
$

What about the OS/2 2.0 GA linker?

[<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>

and on 2ine?

$ ./lx_loader /mnt/c/msos2/test/mt.exe
hi
$

Wow! How about OS/2 2.00 GA?

Sadly a no go.

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!

$ ./lx_dump /mnt/c/msos2/bin/orig/CL386.EXE
/mnt/c/msos2/bin/orig/CL386.EXE
NE (16-bit) executable.
Linker version: 5
Linker revision: 2
Entry table offset: 117
Entry table size: 2
CRC32: 0x30E8EA59
Module flags: MULTIPLEDATA
Application type: WINPMCOMPAT

I meant to post earlier but if you want to follow along, project dump is msos2-wlink.7z.

Continuing with Ancient Microsoft C/Linkers

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.

DOS/4G error (2300): can’t find DOSCALLS.282 – referenced from MT
DOS/4G fatal error (1313): can’t resolve external references

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.

Interesting? Maybe. October 1991 NT SDK uses the OS/2 toolchain

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

Early MSDN CD’s on archive.org

I ran across this, and thought it was cool. These CD’s are getting harder and harder to find, and unless you want the old physical disks, getting ISO images is, of course the next best thing.

Granted these disks replaced the much older Microsoft Programmer’s Library. The new CD’s use a Windows based search & interface program removing the clunky old MS-DOS program that made it feel like trying to view the world through a straw. (Although the up side of the MS-DOS version is that you could easily dump the video RAM and save the contents to plain text).

And in this brave new post Windows 3.0 centric world of Microsoft just about everything regarding OS/2 was dumped, and the seeding of Win32 via Windows NT had started.

Naturally after winning this war, Microsoft withdrew many low end products and just couldn’t compete with the tidalwave that was GNU/Linux.

At any rate for the curious kids down the road that want to see what all the fuss was with Win16, and how Windows 3.0 had changed the landscape removing the force of IBM it’s worth a look.

So close, and yet so far away

OS/2 Presentation Manager Softset

I know it said it had no media, but I wanted it anyways as Microsoft tools of the OS/2 era are so damned hard to come by it’s almost as crazy as a religious artifact.

Anyways I kind of like the Microsoft early 90’s arty vibe to the OS/2 logo.

Anyone have any old MS OS/2 tools hiding in plain sight?

2ine updated to have preliminary 16-bit .exe support!

From icculus’s patreon

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:

https://www.patreon.com/posts/2ine-16-bit-exe-19337541

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… 🙂