the3dfxdude wrote on 2023-03-08, 15:45:

Interesting! And a bit confusing! […]
Show full quote

Jo22 wrote on 2023-03-08, 11:21:

Thanks for the link! ^^ These two are an interesting read, I think. My First Experience with MS Windows (archived version, also […]
Show full quote

Thanks for the link! ^^
These two are an interesting read, I think.
My First Experience with MS Windows (archived version, also still online)
AutoCAD for Windows

Interesting! And a bit confusing!

By late 1990, we realized that there was a lot of conflict between Microsoft and IBM about the future directions of OS/2. At one […]
Show full quote

By late 1990, we realized that there was a lot of conflict between Microsoft and IBM about the future directions of OS/2.
At one point, our Microsoft contacts, urged us to consider AutoCAD for Windows 3.1, which was about to be released.
I was, however, very skeptical since Windows 3.1 was a 16 bit operating system, and on a Window system,
AutoCAD really required a flat address space only available on 32 bit operating systems.

On July 5th, 1991 two months before the announced Microsoft/IBM divorce, Cameron was in the room when Bill Gates trumped Kern Si […]
Show full quote

On July 5th, 1991 two months before the announced Microsoft/IBM divorce,
Cameron was in the room when Bill Gates trumped Kern Sibbald's soliloquy
on how to promote OS/2 by leaning forward and saying very simply: "We don't want to sell OS/2".

It was a stunning revelation. The room was filled with the MS OS/2 lead programmers.
They were there to celebrate the first 32-bit application running on OS/2.
When Bill spoke those simple words, you could see the blood drain from their faces as their heads filled with random white noise.

OS/2 2.0 was the first 32bit version of OS/2, right, and came out in '92? And they were there in '91 to celebrate the first 32bit application,
which could not have been AutoCAD, because it involved MS programmers. I mean that part that it was coming from MS programmers makes sense,
because no one else would have had prior access to the proper 32bit flat address space compilers and apis to do it.
It was a very sly thing for Gates to pull this and tell the Autodesk team that they were pulling out of OS/2!

AutoCAD could not have been a 32bit application already, by this statement.
I think he *hoped* that they'd finally move to that based on the announced meeting,
and Gates's move in the meeting held them back if OS/2 was DOA and Windows was it.
Somehow they knew, even if Gates could not publicly admit it.

Another thing said was this in '92 on the Windows version of AutoCAD:

Shoehorning a huge program like AutoCAD into the 16-bit architecture of Windows 3.0 was a Herculean task,
made easier by our initial investment in the OS/2 version of AutoCAD.

This means AutoCAD was and still was 16bit application, but being 16bit was not as bad as they made it sound to be.
It's just Windows was a different API It just meant they couldn't land the 32bit version as fast as they initially planned. I guess OS/2 was a bit over promised, wasn't it?
It just was too late into action. I'm sure AutoCAD wanted to be on the inside to have an edge over their competition when 32bit apps finally arrived.
Was there actually a 32bit version of AutoCAD before 1992? I don't think the Xenix version would have been based on our earlier conversation.

Looking at AutoCAD version history, it looked like while version 13 was for Windows 3.1, a 16bit platform at the time, they also had a port for Windows NT Alpha?
So they were still moving forward with a 32bit version I guess... whenever NT was ready. And this was the only 16bit windows version. The next versions were very likely 32bit only.
https://en.wikipedia.org/wiki/AutoCAD_version_history

Yes, that's really a bit confusing I think. 🤷
It didn't really help that different versions of software were apparently internally called "OS/2 2.0" during development, also.
- That's at least the way I did understand the story, not sure if it's true actually.

My guess is that porting AutoCAD to Presentation Manager mainly eased the transition to MS Windows afterwards.
The APIs are different, but kind of similar. The Windows GDI and the OS/2 PM API most (in)famously use a different coordinate system, but the principle is the same.
That didn't save the developers from lots of work, but it avoided the need for a complete rewrite, at least.

I'm afraid can't provide a definite answer to the 32-Bit nature of AutoCAD, since I don't have the versions at hand right now. ^^;
My guesses for the Windows 3.1 version(s) are that
a) 32-Bit inline assembly could have been used
b) a 32-Bit Extender was used (Phar Lap etc)
c) the Win32s runtime was used to run a Win32 version on Windows 3.1
d) the strange and obscure WinMem32 API was used (supports flat mode on Windows 3.1 Enhanced Mode)

Hm. The early Windows 3.0/3.1 days were genereally really weird, I think. At least by today's standards, I mean.
Special Win16 executables could also being created by early Borland products like Turbo C++ to for Windows, I believe.
In project settings, there's an option to compile as Windows EXE, QuickWin EXE, Windows DLL and DOS EXE.

The QuickWin type essentially simulates a DOS command prompt in which former DOS programs run (Win3.1 hasn't its own command line output yet).
That way, they can run on Windows an use Windows' resources and do cooperative multitasking (I think).
Turbo Pascal for Windows had a similar feature (WinCRT unit), I vaguely remember.
https://en.wikipedia.org/wiki/QuickWin

The WinMem32 API (WINMEM32.DLL) was apparently part of the Window SDK since Windows 3.0, thus making it available since ~1990.

"WINMEM32 is a dynamic-link library (DLL) that supports 32-bit flat memory under
the Microsoft Windows graphical environment. WINMEM32 provides a flat model
computing environment for applications ported from another operating system to
Windows. New applications should not be designed using WINMEM32."

Source: https://jeffpar.github.io/kbarchive/kb/073/Q73679/

Quick update. This is interesting.. It seems to me that MS Windows 3.10 (on DOS 6.2) is running slower on the PC/AT Model 5170 emulation than OS/2 v1.10!
- With 8 MHz and the same amount of memory (~16 MB, to remove all bottlenecks and avoid memory fragmentation)!

Whereas Presentation Manager of OS/2 v1.10 is very responsive all the time, including the File Manager and mouse movement, it's not the case with Windows 3.10.
File Manager on Windows 3.10 is very sluggish and needs lots of time displaying the few base directories, PM file manager needs just about a second.

It happens with both the Standard VGA and proprietary Super VGA drivers.

This is interesting to me, because back in the 90s I didn't have an AT compatible PC that slow!
I started with 12 MHz and 70/80ns memory SIMMs, not those ancient 150ns (?) DIP/DIL chips with lots of waitstates.
Heck, even my 10/10 MHz Schneider Tower AT 286 from circa. 1988 is quicker and runs circles around the 8 MHz IBM AT Model 5170!

Quick update. I managed to get hold of the Presentation Manager add-on for Windows NT..
From what I can tell, it works fine on Windows NT 4, still.
But it's very barebone, limited to Standard VGA, comes only with a few applications and no file manager etc.

Luckily, I've got a working OS/2 v1.3 installation which I can, err, "borrow" a few files from. ;)
Time for some vandalism! :D Please enjoy!

Okay, so Win File -I mean PM File- is running just fine. It can even execute applications, which all appear on same PM shell!
I think that's neat. Other programs, old Presentation Manager games, also run nicely.
- If you watch closely, you will see that all PM applications are handled separately by NT or OS/2 subsystem! :)

Unlike PM GIF, a picture viewer for GIF87 picture files from 1989.
- It crashes with an exception fault once I select a GIF file - a valid one, by the way.
It was created using WinGIF (old, but awesome!) and works with PM GIF on real OS/2 v1.x and higher.

Speaking of games, Pegs and Hole is similar to an old board game I used to play here in my place when I was little (I played the physical thing).
However, it's known under a different name here: Solitär (Solitaire, like the card game) or Halma (Steckhalma).
https://de.wikipedia.org/wiki/Solit%C3%A4r_(Brettspiel)

This is one of these weird situations in which you see something familiar, but under a completely different name..
What comes the closest is Black Jack, the card game. It's been commonly known here as "Siebzehn und Vier" (17 and 4), though Black jack isn't beeing unheard of..
Edit: Just double checked. There a some differences in the rule set of both card games. They're otherwise quite similar.

I know, it seems like nothing special, but it always causes me a moment of surprise ("ooooohhh!") when I see something traditional suddenly appearing in a foreign product/film.
A similar reaction cause me films of Japanese origin, by the way. You watch an Anime, expect nothing bad in that scene, and then suddenly you hear an "Gesundheit!" (bless you) or something. Just unreal.

Quick update. I was trying to provide EMS to the OS/2 v1.10 "DOS penalty box" by using chip set EMS.
To do so, I had chosen the Trigem 286M motherboard in PCem v17..

From what I can tell, it would technically work, maybe, if there wasn't a big problem. Two, actually.

a) the i/o window used by the EMS chipset/driver is above 640KB - good on real hardware, bad on a pseudo-DOS session (OS/2's DOS box).
- Because it won't allow access past 640KB except for video related stuff or other special "hardware" located in the UMA.

b) the Trigem board has no option in CMOS Setup to reserve EMS memory. Instead, the MM.SYS driver will take care of this detail.
- Which is very bad, since OS/2 during boot sequence will detect and claim all available Extended Memory for itself. If now MM.SYS comes along and steals memory, OS/2 gets very upset.

So what we need to get EMS working (maybe) is something like an Lo-Tech 2MB card or an AST RAMpage.
Something which has no relationship to XMS/XMA or Extended Memory, at all. Some memory that's completely independent from the rest.
Ideally, the EMS page frame would be located in conventional memory (first 640KB), too.

Edit: I *do* have an EMS memory board here, an AST RAMPage 286. But.. It's one of my rarest items (older than me, still working!). And my few 286es have weak power supplies (I had to fix them).
I'm honestly a bit worried right now to accidentally kill any of the vintage parts by installing the board right now for testing purposes. 😓
Maybe I do that in the future if I have time and patience to build a solid 286 PC with a good PSU and a quality mainboard. 😀 👍

Quick update. Found some OS/2 "demos" (demo scene)..: Re: Ultimate OS/2 Warp 4 machine?
They seemingly run on DOS, but are interesting, too! The way they were made.. That's pure 90s aesthetics!
Just look at these effects and the ray-tracing/rendering - and image seeing those animations running on a 486 PC in a computer shop while going window shopping! ❤️

Jo22 : I think your posts are fantastic, it is like reading about findings and hackings of leaks of different games and software codes and what not, there has been during the last few years. Except this is legal (and not anything leaked, but instead your findings) , and it is so interesting, even though I understand Jack and S , when it comes to the programming side of things. And Jack has left town, but seriously keep up the good work, and I look forward to some more awesome posts 😀

Thanks a lot! I'll try to keep it up. I've got some more ideas for this thread, both 286/386 and OS/2 related. ^^

Quick update. Just noticed something while reading one of the old OS/2 articles. On one of the pages, an interesting 'foot note' can be found.

"I have read allegations that Microsoft's WLO is a blatant ripoff of Micrografx Mirrors, a similar product developed earlier by Micrografx.
Supposedly Microsoft's application division was offered to evaluate Mirrors for potential use in Microsoft products, on the condition that Microsoft systems division doesn't learn the details.
Looks like they did - not very surprising given Microsoft's track record. "

Source: https://www.landley.net/history/mirror/os2/hi … s213/index.html

That kind of reminds me of Apple's visit at Xerox Park when seeing the Xerox Alto's graphical and mouse drive interface.
Or rather, Microsoft's visit at Apple HQ when the Macintosh was in the making ? 😉

Here's a screenshot of PM Chart, which apparently uses Micrografx Mirrors:
http://www.os2museum.com/wp/os2-2-0-limited-a … y/20la_mirrors/

And here's Mirrors in the news:
https://techmonitor.ai/technology/ibms_new_pa … s_out_its_stall

I think that's interesting, what a twist! You (we) simply think that things are obvious and the way they are,
but the more you (we) dig, the more you (we) realize how everything is somehow connected with each other ! 😁

Edit: Screenshot attached (tiny).

Quick Update. Did a little bit of experimenting here.

Running PM Chart on Windows 3.1 results in an error message.
- What's interesting though: Both PM Chart and Soft Term have outstanding icons and both cause an error message.

The other OS/2 applications in C:\OS2\APPS rather cause Windows 3.1 to open a DOS window which immediately closes soon after.
That makes me think that both PM Chart and Soft Term have a different header. The rest is likely just displaying a DOS message ("needs OS/2") and quits.

Edit: On Windows XP, both programs do display a DOS message, but cause no dialog box.
Perhaps because Windows XP does try to run the application and not XP's built-in Windows 3.1 (Windows on Windows, WoW)..

Hi there. I'm currently trying to figure out how to compile Willow compatible applications..
In case you're curious, these two webpages are a great help in understanding how to make things work.

https://www.betaarchive.com/forum/viewtopic.php?t=14196
https://www.transmissionzero.co.uk/computing/ … in16-apps-in-c/

Gratefully, my father had an old copy of Quick C, along with a matching programming book! 😁

Edit: No, seriously. See photo. 😀

Quick update. Got it work! Here's an WLO enhanced sample application running on OS/2 v1.3. 😁
- It's 'Generic', one of the oldest sample programs. It's so ancient it was floating around on BBSes in the Windows 1.x/2.x days, even. 😁

Essentially, all I had to do was to provide my own version of winstub.exe; which I got by using WinHex on the clock.exe sample program.
I copied it into the project directory and added "STUB 'WINSTUB.EXE'" to generic.def by opening it in notepad, then did re-build the project from the Quick C IDE.

The STUB statement is optional and meant to refer to an DOS application that will be added prior to the Windows 3.0 executable that's going to be build.
The original idea was to add a tiny DOS programm that says "This program requires MS Windows". But it can be anything, really. Even a real full-fledged DOS program.

If you want to do the same, have some fun! ^^

PS: Just please keep in mind that the Windows application in question must be able to run via Windows 3.0's Real-Mode kernal.
I don't think it's a problem if the compiler uses 80286 instructions, though. Though maybe it's better to limit it to 8086 or 80186 ones, anyway.
Because, part of the fun is to have an application that can run on both an humble Windows 3.0 PC and and a high-end OS/2 PC, isn't it ? 😉

The memory model used by the compiler might be more important, maybe.
There are small / medium / compact / large.

Our old C programming book suggests to avoid using compact and large, if possible and use small and medium instead.
It says, they use far as a type and are slower thus. The fixed data segments may cause headaches, too.

Quick update. Compiled the Generic application for Windows 2.03 and added winstub.exe (WLO) to it.. Even ran Mark30 utility to make it look Win 3.0 friendly.
Well, the application runs as usual on Windows. The DOS-based part of the stub shows the "quotes.txt" error message, too.
But the Willow runtime on OS/2 doesn't like it. OS/2 reports an error message.

Edit: I did the compiling/linking in DOS, with the MS C compiler package. The winstub was integrated in DOS, too.

Quick update. I had been playing with the Windows SDK a bit.
I tried to compile Generic with the old Windows 2 SDK (Windows 2.11 header+library files, Generic sample application from Windows 1, 2) and MS Quick C for Windows.
- That's possible because MS Quick C for Windows 1.0 is directly based on Microsoft C Compiler 5.1, the compiler used for Windows 2 SDK.

So all I had to do was to borrow the existing "make" script from modern Generic (meant for Windows 3.0) and copy it over in the GENERIC.211 folder.
In which I had previously placed the old Windows 2.11 header+library files (in short, a big mess; everything in one folder/directory).

And it really worked, MS Quick C was compiling the project with the files it found in the same folder (I had told it to search in application directory first)! 😁
- Because, as I saw from the old window decorations (I *think*), it was using the older API calls from before Windows 3.0.

However, WLO didn't like the application. It still "crashed" on OS/2 as it did before. Hm.

After this, I checked the freshly made Generic application on Windows 2.11 - and it didn't run.
Windows complained about the Windows application being too new (rightfully, I admit).

So I ran Borland Resource Workshop 4.5 and tried to change the minimum version number for the Generic application.
Unfortunately, BRW didn't show it. It didn't provide any information about the EXE header, merely the resources.
Neither did BCC Workshop 5.02, another utility with a never version of the tool built-in. What a bummer!

So I ran Resource Hacker 3, another classic EXE utility I used in the past. Unfortunately, the author disliked Win16 platform and made its creation Win32 exclusively.
I then searched the web and found Exescope, an older utility from Japan (?) - and voila! It provided me with the information I looked for! 😀
Yeah, it provided me with the information. It showed me. It didn't allow me to change things, of course. *sigh* 🙄

So what did I do ? I used XVI32, my favorite hex editor, and went to the absolute address that Exescope told me - 0703F (hex).
And from there on, I could finally modify the values of the Win16 headers. Phew! 😌
I changed the values to 03 02 , which meant 2.03 - for Windows 2.03!

Did it work ? Yes, the editing was done correctly. Windows 2.03 and 2.11 started Generic and.. blacked out to DOS prompt. But hey, it technically worked! 😁

The moral of the story.. The Windows API before Windows 3.0 was still very different from what we know today.
And Willow *apparently* has no backwards-compatibility built-in, unlike the real thing (Windows 3.0, 3.1x)
All the old resource formats and API calls that Windows 3.0 still remembers are not included in WLO.
So in order to work under Willow/WLO, I guess, Windows applications are required to use the official Windows 3.0 API and the file formats it uses.

PS: This site has information about the Win16 EXE header: https://www.fileformat.info/format/exe/corion-ne.htm
It helped me to find the right entries mentioned in Exescope. 😀

The problem with the chart is, that the addresses seen on the left don't take the WINSTUB into account.
The stub above the Win16 code does shift all the addresses shown in that chart/table. That's why we need an utility like Exescope.

Alternatively, we would either need to remove the stub or use standard stub (and hoping that the chart was made with that in mind).
And then remember the spot we need to modify, after applying our own WINSTUB (doable, since Win16 EXEs start with "NE" at the very beginning).

Hi there!

I'm currently working on "porting" the Windows 3.x version of GNU Chess to OS/2 using WLO.
Essentially, I'm trying to accomplish the same as user yksoft1 previously did before. Please wish me luck! 😀

While looking for that copy of GNU Chess 3.21 for Windows (w/ source),
I had noticed that the author of the port, Daryl K. Baker, already had made an OS/2 port back in the day, too.
- And a real one, by the way, not just using WLO. Impressive, I didn't know that! Cool! 😁

I've found out by reading this site:
https://stason.org/TULARC/games/gnu-chess/B-3 … dows-or-OS.html

Unfortuntely, the URLs with the the old OS/2 files are gone.
The "Internet Chess Library" had them, but it's gone:
https://web.archive.org/web/19990302100444/ht … enet.net/chess/

That's when I realized the whole dimension of the loss, by the way.
Apparently, the chess society had lost a lot of things in past.
http://www.anders.thulin.name/posts/pgn/

By contrast, the "German Internet Chess Server" of the university of Kaiserslautern is still online.
And it looks as if it was 1997 all again. 😁 The downloads for the chess clients are intact, too.
If you're looking for new software for your IRIX or HPUX system, you're in luck!
https://www.unix-ag.uni-kl.de/~chess/soft/clients/index.html

Anyway, I've found a copy of PM Chess here, at least:

https://www.os2site.com/sw/games/board/index.html

Also, there's still hope. All those countless shareware CDs for OS/2 from the 90s do have the files, for sure.
I'm just lazy checking them right now. The internet archive has them, too.

Quick update. I got GNU Chess for Windows compiled. But not using Quick C for Windows, sadly.
That's because the supplied make file "chess.mak" was made for MS C compiler on DOS.
But not MS C Compiler 5, but version 6. The latter has "nmake", which replaced "make" as the make utility.

What I noticed during compiling, was that "nmake" constantly complained about "version.c" being wrong.
Which was true, it was empty. Totally empty (o bytes). But why ?
No matter how often I copied the good version.c over from the host drive, it always ended up that way.
- If you're curious, the good one was 44 bytes in size and contained: char Version[]="Sun Jun 16 19:41:00 1991";

That's when I used attrib command to write protect the file ("attrib +r version.c") on DOS prompt and tried again.
Funnily, this worked (?) and nmake compiled the program on the second run no problem. Ran on Windows, too. Nice! 😁
(During compile, I saw that makever was piping into version.c "makever >version.c" - maybe that's the issue.)

Next, I copied my WLO-enhanced winstub.exe into the CHESS directory.
I also looked for chess.res, because I wanted to include the WINSTUB.EXE.
Astonishingly, this wasn't even necessary. The line was already there.

So I did another compile. Worked, no errors. Chess.exe grew from 70KB to about 100KB.
Next, I ran the game on Windows (WIN /R CHESS) and it showed up as seen in the screen shot.
Motivated by all this success, I tried running it on OS/2 v1.3 on PCem (IBM AT 5170 emulation) and.. it crashed.
I also changed to WinBIOS machine type, just in case a +386 instruction was to be blame. But no, that wasn't it.

That's when I double-checked what yksoft1 did before. There was a mentioning of Quick C 1.0 linker/runtime..
So I got the idea of just combining the DOS utilities of both MS C 6.0 and Quick C for Windows (based on MS C 5.1).
Could it work ? A mashup of two products? Using MS C 6 compiler, both the WLO friendly, DOS-based linker from Quick C for Windows ?
Yup.

The nmake utility didn't complain. Not more that usual, I mean. I removed all *.OBJ files before (del *.obj) and ran nmake twice (version.c issue).
So I now got a binary that's assembled with the same stuff that successfully made Generic run on OS/2.
File size was about 85KB now, if I remember correctly.

Running WIN /R CHESS caused the "can't open quotefile quotes.txt" to appear. Okay, so WLO stub is alive, at least.
Windows .0 started, but there was no GNU Chess to be seen. Just an empty desktop with program manager sitting lonely in its corner.

Quick update. I'm currently trying to find out what other modification our chess.exe file needs, as well.
Didn't say user yksoft1 something about changing "a byte" ? Which one could it be ? Provied, that the EXE is otherwise okay, I mean?

Ok, let's try playing with "Program flags" and "Application flags".. How about changing the former from 02 to 03 ?
- Let's see how it affects our chess application. Make the change, save it to another name (chess_fixed.exe).
And try it ou.. -ch! What a mess! 😳

Edit: As you can see in the left window, the resources are missing (the chess characters).
There's definitely something wrong, not just because of the WLO stub.

Update. After a lot of trial and error, I got a WLO friendly version of GNU Chess for Windows compiled (ca. 100KB).
No idea how I managed to do that. I'll have to find out in the near future.

As you can see in the screen shots, it runs on OS/2 v1.3, the latest 16-Bit OS/2.
OS/2 also displays a compatibility warning. Maybe that was changing the byte for?

That being said, the binary is still not perfect.
The chess engine itself isn't running yet, the clock stands still.

Edit: Attached the original (?) GNU Chess for Windows archive and the WLO binary.

Enter some competition for OS/2... Linux. In September 1992, DOSEMU, was started to emulate DOS on Linux. In Linux Journal Sept '94 reports, James MacLean, one of the developers, prior to switching to Linux he was using OS/2 for DOS, he thought Linux should be able to do it as well. Well, he found out it did, and joined the project. DOSEMU by then already had developed to the point of being able to run Windows 3.0 inside of it.
https://ia601807.us.archive.org/view_archive. … ue5%2F2802.html

On the sourceforge page, you can see some screenshots, one of which it is running Netscape in Windows 3.x.
https://sourceforge.net/projects/dosemu/

It would be interesting to compare how capable it was then.

Nice to see that in OS/2 1.x protection mechanisms are already working - bad Windows app doesn't crash the entire system.
No protection in contemporary Windows versions...

Grzyb wrote on 2023-04-06, 05:33:

Nice to see that in OS/2 1.x protection mechanisms are already working - bad Windows app doesn't crash the entire system.
No protection in contemporary Windows versions...

Well, yes and no..
Yes, 16-Bit OS/2 is quite stable and its protection mechanisms work fine,
also thanks to the 286 Protected Mode using x86 ring scheme and the MMU's segmentation unit.

It's much more rugged than flat mode, I think.
Segmentation prevents malicious code to execute code in the data segments and vice versa.

On the other, Windows 3.x doesn't make full use of the ring scheme,
though it also uses segmentation at its core (386 Enhanced-Mode mode is special here; 4KB pages, WinMem32 etc).
Windows 3.1x merely uses two rings, at best. In Standard Mode, I vaguely remember..

What's interesting though, the foundation of both 16-Bit Presentation Manager and Windows 3.x is quite similar. 🙂
Willow is like a very simple form of WINE, though more like a very lightweight shim.
It doesn't change the executable format, it just maps API calls to their corresponding twin.
There's no real Windows doing its mischievous thing in 16-Bit OS/2 ("no").

The GNU Chess executable I've cobbled together seems to be close to that of user yksoft1..
Both have the same issue of the non-working chess fields and the stuck clock:

The problem is: Prior doing a move on the chess field, the count-down for player "black" (computer) is missing.
That's normal and also happening with the official binary.

But unfortunately, that prevents us seeing if the game engine works,
because the chess figures/the chess fields aren't click-able under Willow yet.
- So maybe there's just a bug in WLO, the game code or a missing API function.

The only true difference between my build and yksoft1's build is the warning dialog that it triggers.
That's why yksoft1 found it worth mentioning, I think: Without the warning message fixed, 32-Bit OS/2 refuses to run the binary!

It seems that OS/2 2.x + acts like Windows 95 here: Windows 95 also refuses to run old Windows 1.x/2.x applications
that would normally trigger a compatibility warning message on Windows 3.x!

To make them run on Windows 95, the header must be fixed (Windows 3.x offers a continue button, like OS/2 1.x).
The header must imply Windows 3.0 compatibility (programs must be marked "clean" with Mark or Mark30 utility).

16-Bit OS/2 / Presentation Manager is more forgiving, like real Windows 3.x is. And like its siblings in Windows NT and 32-Bit OS/2 are.

Edit: Edited.
Edit: Formatting fixed for better readability (at home on PC).