I haven’t looked at 2ine yet, but agree that’s another thing to look into. It’s a bit strange to be looking into OS/2-on-DOS instead of OS/2-on-Win32, which seems more applicable. Note though since it’s 16 bit code it’d need CPU emulation like winevdm – does 2ine do that?

Without CPU emulation, it’s an interesting question whether the same source code can target DOS, OS/2, and Win32 – obviously it _can_ but the logic needs to limit itself to 64Kb segments which is going to look ugly on Win32. There’s also another route of using the 32-bit OS/2 API to get a single piece of source code to support Win32, OS/2 and a DOS extender.

I don’t follow the comment about the msft post though – what msft post? That link should be to my personal blog…

Looks pretty cool!

I had messed with the MSC from the October 1991 NT, and the leaked MASM386 can assemble it, to an OMF that NT LINK386 can use, much like the Xenix 386 GAS.

The other ‘target’ I guess for family api, is 2ine? the OS/2 libraries for Linux, which give us the 64bit OS/2 we all know we need.

Also what is the msft post on creating family apps on masm6?

If you’re interested, first blog post: http://www.malsmith.net/blog/visual-c-os2-family/

Source code: https://github.com/malxau/os2api

I found my hello world one:

NAME HELLO WINDOWCOMPAT
DESCRIPTION 'Hello world'
PROTMODE


So yeah, so confusing!

I think it’s just “NAME FOO WINDOWCOMPAT” in a .def file, and point the linker to it. That sets a single bit in the executable which also modifies a second checksum bit. It should be possible to just mark executables after linking.

(Also, I know about the two bits because it’s possible to just recompile and diff. Unlike what happened later, the results really seem reproducible by default.)

Agree about the unified console. The Win95 one (which has no scrollback since it’s just an emulated VGA device) is unusably annoying now. That said, I started Yori so I could have tab completion on NT 3.51, and using OS/2 without tab completion is driving me nuts. OS/2 really tried to have a modern console (at least for OS/2 applications) but the shell needs work.

oh I have to find the linker def’s to make it window compatible. I have it somewhere when I was messing with Fortran 5.1. Otherwise it’ll launch a full screen session, say hi, and close in the blink of an eye.

We really take the ‘unified’ console of Windows NT for granted, as it was so fragmented back in the day.

Ive been getting an incredible amount of errors from invalid binaries, malformed binaries, missing symbols t duplicate symbols (__acrtused) and other stuff.

I just re-installed under OS/2 and got it to seemingly work though. I had it as a strictly OS/2 only setup?

doing steps 1/2/3 and it finally runs!

Thanks so much for that hint of just targeting OS/2. I manually extracted back the compiler only for realmode, and it’s acting way better now. I guess Microsoft C 6.00 is way more forging in this aspect.

I’ve had this working successfully although there are plenty of quirks. If you’re using the DOS toolchain, note there’s two versions of link.exe: a real mode one, and a bound (family mode) one. Linking an OS/2 application really wants the bound one, or the one provided with the OS (which is marginally newer.) The real mode one will complain about unresolved externals despite being given doscalls.lib (it doesn’t seem to handle it correctly.) The function prototypes for things like DosWrite are included in C 5.1 headers though.

Also, by default C 5.1 generates non-windowcompat binaries, so a module definition file is needed to make a useful result. On OS/2 2.0 and above, using the whole thing from DOS boxen might be easier, because everything works in a window by default.

This is a good resource:
http://www.edm2.com/index.php/Hints_for_writing_simple_programs_for_both_OS/2_and_DOS

Note the part at the bottom – it’s possible to dynamically check which system a binary is executing from with DosGetMachineMode, and it’s possible to add extra OS/2 functions so long as you supply a DOS equivalent. Bind -n can map a list of extra functions to a generic handler function, which is useful if you use DosGetMachineMode to ensure that the OS/2 function is only invoked on OS/2.

Also, digging around showed a PC Mag article complaining that building a family mode app is often larger than just building a native DOS version and using it as a stub for the OS/2 version – ie., rather than have a single OS/2 binary with a DOS translation layer, just glue two complete binaries together. For hello world, that seems like the right thing to do.

It’s a real shame that the same e_lfanew field is used to indicate _any_ “new” header. We could have had MZ applications that contain a DOS version, an NE OS/2 version (or possibly WLO), and a PE version. Although, it’d also be great to have a single PE version for multiple architectures. Sigh…