Back in the olden days of when Microsoft had pivoted out of OS/2 in a hurry, I’ve always felt that the common ‘OMF’ objects ought to link for OS/2. But for some reason I never tried. But for some reason I thought I’d try it today.
I first installed Microsoft C 6.0, and set it up for a native OS/2 to OS/2 1.2 setup. This way I get a pure OS/2 include/library directory set. In retrospect, I don’t know why I didn’t just use 2 include / library directory sets to far easier target stuff, without dealing with changing the default names, and making linking an all around living hell.
So the first thing to do is to tell QuickC for Windows to default to the OS/2 include directory (turns out it wont link anyways). Compiling is nothing special. When setting up the project you’ll need a DEF file, I use this simple one:
NAME QCO2 WINDOWAPI
PROTMODE
CODE PRELOADNothing to it!
I tried to fight the Windows linker, but it figures out what you are doing and won’t do it. But can you manually link? Well QuickC for Windows does include a DOS linker, and it’s oddly enough newer than the one for Microsoft C 6.0!
C:\proj\o2>msdos \WIN16APP\QCWIN\bin\link hi.obj
Microsoft (R) Segmented-Executable Linker Version 5.15
Copyright (C) Microsoft Corp 1984-1991. All rights reserved.
Run File [hi.exe]:
List File [NUL.MAP]:
Libraries [.LIB]: doscalls SLIBCE
Definitions File [NUL.DEF]: qco2.def
C:\proj\o2>msdos hi.exe
This program cannot be run in DOS mode.
Manually invoking the linker wasn’t all too hard, just answer the 30 questions. I did set the LIB environment variable so it picked up the libraries just fine. And yes, it created my OS/2 binary no problem!
And as you saw from above, yes it does run!
I do suppose the graphical editors would have been nice some 30 years ago, but in today’s era, sadly it doesn’t matter. QuickC for Windows won’t run under WLO, so this prevents it being a backdoor GUI/Protected mode compiler for OS/2. It’s a shame too as at least running under Windows 3.0, QuickC for Windows is WAY faster than using Microsoft C 6.00 in either read mode, protected mode with smartdrive.. I’m not sure what the deal is. Even with the advanced caching SCSI controller.
Not sure if anyone cares, but I think it’s cool.
Somewhat related, but for QuickC 2.0 for DOS:
https://jeffpar.github.io/kbarchive/kb/040/Q40503/
I think I figured this out the hard way back in the day, since we didn’t have Internet connections when it was written. Note that this article is from 1989 so references to “Windows” should be read as “Windows 2.x”.
There’s also this which is for QuickC 2.5:
https://jeffpar.github.io/kbarchive/kb/065/Q65490/
I’ve never seen the disk it refers to. Looking now link.exe was not included at all with QuickC 2.5, which seems like a big functional regression. I’m very skeptical of the implication that Link 5.02 in QuickC 2.0 can’t target Windows 3.0.
Googling for the disk turned up https://books.google.com/books?id=FDwEAAAAMBAJ&pg=PP8&lpg=PP8#v=onepage&q&f=false which might be interesting. Note the “SMK” it refers to is what we’d call “WLO” today. Interesting that it’s explicitly one-third the cost of the Windows SDK.
AFAICT all of the 5.x linkers can generate either Windows or OS/2 binaries. Even if they couldn’t, OS/2 includes a version of link.exe and doscalls.lib, so all you need for OS/2 development is a 16 bit OMF compiler.
Looking back at the screenshot, I think it linked, it’s the resource compiler being called for no apparent reason that is bombing out. I should look at the makefile again, but that means getting out of the electric blanket…