Category Archives: OS/2

Presentation Manager for Windows NT

Posted on by
21

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

Posted on by
9

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?

Posted on by
4

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

Posted on by
23
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

Posted on by
Reply
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

Posted on by
6

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

Posted on by
2

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!

Posted on by
14

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

2ine the OS/2 emulator

Posted on by
9

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:

./lx_loader CL.EXE
not an OS/2 LX module

But let’s try my crazy Win32 hosted EMX 0.8h cross compiler!

C:\emx\demo\dhry>gcc -v dhyrstone.c -o dhyrstone.exe
gcc version 2.5.8
cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=5 -D__32BIT__ -D__EMX__ -Di386 -D__32BIT__ -D__EMX__ -D__i386__ -D__32BIT__ -D__EMX__ -D__i386 -Asystem(unix) -Asystem(emx) -Acpu(i386) -Amachine(i386) dhyrstone.c C:\Temp/cca13032
GNU CPP version 2.5.8 (80386, BSD syntax)
#include “…” search starts here:
#include <…> search starts here:
/usr/local/include
D:/pcem/building/MinGW/msys/1.0/local/emx/include
/emx/include
/usr/include
End of search list.
cc1 C:\Temp/cca13032 -quiet -dumpbase dhyrstone.c -version -o C:\Temp/ccb13032
GNU C version 2.5.8 (80386, BSD syntax) compiled by GNU C version 5.1.0.
as -o C:\Temp/ccc13032 C:\Temp/ccb13032
ld -o dhyrstone.exe /emx/lib/crt0.o -L/emx/lib C:\Temp/ccc13032 -lgcc -lc -lgcc -lemxst -los2 -lemx2

And now running that on Linux…

root@alpharacks:/usr/src/2ine-4a8318f4056f# file dhyrstone.exe
dhyrstone.exe: MS-DOS executable, LX for OS/2 (console) i80386, emx 0.8c
root@alpharacks:/usr/src/2ine-4a8318f4056f# ./lx_loader dhyrstone.exe
Dhrystone(1.1) time for 5000000 passes = 3
This machine benchmarks at 1666666 dhrystones/second

You’d never know that this was an OS/2 program, if I didn’t tell you.

I tried the old 87 Infocom interpreter, and it’ll run great too!

root@alpharacks:/usr/src/2ine-4a8318f4056f# file infocom.exe
infocom.exe: MS-DOS executable, LX for OS/2 (console) i80386, emx 0.8c

root@alpharacks:/usr/src/2ine-4a8318f4056f# ./lx_loader infocom.exe advent.z3

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

OS/2 2.00 CGA on PCem v13

Posted on by
1

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.

One neat ‘feature’ of PCem is that it’s CGA emulates the single ported memory, so that the card & host cannot properly share the video memory so for programs not watching the retrace line you get the snow effect. (here is a demo, GP-01 by Genesis Project with snow, and here without snow).

but of course in this day & age all of this really is moot.