On the topic of Open32 – does anyone know what development tools exist for it?

I know about Odin, which seems widely available. Open32’s headers/libs/docs seem to have only been published through the Warp 4 toolkit, given to Developer Connection subscribers. But I don’t see any indication that these toolkits were ever downloadable or freely redistributable, and by 1996 there weren’t third parties investing in the area either (eg. no Borland or Watcom support.)

Since the DLL is part of the OS and has to contain at least function names, and the Win32 function signatures are well known, it’d be easy enough to approximate; but since it’s only trying to be source compatible it could easily diverge in ways that aren’t obvious.

I’m sure MSC6 has better support; it just wasn’t the version I ended up with. 5.1 works but is quite rough; the binaries aren’t marked as windowcompat, for example, so it’s not much fun to use.

The reason I was asking about 16 bit as a viable app target is because the divorce left OS/2 without a good 32 bit toolchain in 1992. By the time things like Open32 came along, that problem was solved – or perhaps, solving it was a prerequisite for Open32 to make any sense.

Fwiw, I have a copy of SmartSuite 1.1 which is before the IBM/Lotus acquisition, and I’ve never opened it or inspected what it does. But for something of that era, it sounds like we’re agreeing that it would have been practical to have a 16 bit port of a 16 bit Windows program, and Open32 was really about evolving as that changed.

…re: OS/2 1.2 improvements, I wonder if Microsoft C 6.0 supports most or all of them. MSC6 definitely still supports building for 16-bit OS/2.

Also, one example that just occurred to me of a set of applications that absolutely won’t run on anything older than Warp 3 due to taking advantage of PM APIs that didn’t exist before would be those that use Open32, which was kind of a layer atop PM that IBM released which mimicked Win32. These were definitely utilized by Lotus (by that point “an IBM company”) to get SmartSuite 96 onto OS/2. The Open32 stuff wasn’t just a DLL shim or portable runtime that could be shipped alongside your code…it was part of the OS. You had to actually install a FixPak to Warp 3 or 4 that included the Open32 frameworks in order to be able to run SmartSuite/2 on your system.

Good find with that article, though I’ll point out that being published in June 1990 means it was well before the IBM/MS split. So not only was this early on in the development cycle of 32-bit OS/2, but there was more than enough time in the following 1.5 years for IBM to decide to change things (even things that may not have been on the table to be changed while MS was still involved…I’m honestly not even convinced that WPS would have shipped with 2.0 if it had remained a joint project!). Just like with the LE to LX executable format change, if they were going to make any changes to APIs, this was THE time to do it, since nobody had yet shipped any production 32-bit OS/2 software!

It’s very possible that any analogs to 16-bit PM APIs in 32-bit PM largely remained unchanged, but I’m also thinking of later additions. I find it hard to believe that Warp 3.0 and 4.0 did nothing to expand the scope and feature set of PM, especially as even basic 2D graphics capabilities of PCs themselves continued to advance (32-bit color, etc.; when 2.0 was released in 1992, you were lucky to have 8-bit color at a decent resolution! and OS/2 — to my great shock — ended up attracting a surprising number of photo editing titles in the 32-bit era, all of which I’m sure turned out to be much easier to implement as
“32-bit clean” top to bottom than they would have been: Compart ImpOS/2, SPG ColorWorks, TrueSpectra Photo>Graphics).

So it probably depends on when in time you’re asking. Right around the time that 2.0 shipped, maybe the cost-benefit of building a 32-bit version of your existing 16-bit app wouldn’t have made much sense, but (maybe depending on your app and what it does) that calculus surely changed as the years went on. If you wanted to take advantage of conveniences afforded by new APIs in newer versions of the OS but these new APIs were only offered in 32-bit versions, well… (also, if you wanted to write classes for WPS, WPS itself was a 32-bit PM app, and so your class code running in the same process space as WPS also needs to be 32-bit)

I want to say even OpenWatcom can do 16-bit PM, but don’t quote me. It can certainly do 16-bit command-line OS/2 though.

I found something called “IBM OS2 1.2 SDK (3.5”)” which does have a pm.h so I think that is the tool kit. The box I got that had no disks is the OS/2 Presentation Manager Softset, which I think might just be a subset of the SDK?

Also Watcom 10 should have 16bit PM stuff? I think the toolkit is there on the 10.00 for 2.1 for sure!

Agree about the segment size limit, although with decent data structures and/or a good compiler, that never seemed like a big problem. (Do you really need a flat buffer bigger than 64Kb?)

For the 16/32 bit API differences, I know nothing so tried to find things out. Superficially it seems very different to Windows where the 16 bit OS had very limited capabilities, so moving to NT meant a pile of important OS enhancements, and moving to 95 meant a pile of important UI enhancements. OS/2 already had a better OS, and I didn’t see a whole lot of visible UI changes for applications in 2.0.

This is the best resource I’ve found (sorry for the huge link):
https://books.google.com/books?id=u7WbsmbttwYC&lpg=PT368&ots=vSZr9H-R1Q&dq=power%20programming&pg=PT368#v=onepage&q&f=false

It emphasizes things like the calling convention change, changing the names of kernel exports, etc, but is remarkably short on examples of things that are inexpressible in 16 bit. It includes “The 32 bit Presentation Manager API is essentially identical to the 16 bit PM API” and goes on to talk about the rest of the system.

The most interesting detail I hadn’t considered is that a lot of capabilities were added in 1.2 along with HPFS to support long file names. Those won’t be used by C 5.1, and creating a “good” OS/2 application still wants to target at least 1.2.

“Need” is an interesting term. Somewhat philosophically, in the digital realm, I don’t think we need anything in that it can be recreated – the only question is how difficult that recreation will be.

In Win32 import libraries can be recreated from DLLs, since those need to indicate their exports in order to perform run-time linking. The headers need to be created, but API documentation online is easy to come by.

16-bit protected mode still enforced a maximum segment size of 64KiB I believe, so even if the amount of addressable memory is greater than 16-bit real mode, it’d still be more of a pain to utilize.

I’m not a PM guru, but I’m pretty sure that though they are related, there are separate 16-bit PM APIs and 32-bit PM APIs. I’m not sure if you could necessarily take a 16-bit PM app and merely recompile…there might be API call tweaks you’d have to make even irrespective of any memory model changes. And so it also wouldn’t surprise me if there were more features available to be taken advantage of in 32-bit PM vs. 16-bit (don’t ask me what though)…I’m sure any new APIs introduced to 32-bit PM were never backported (if 16-bit OS/2 was no longer being marketed, sold, or developed further, what would be the point!)

The bind command will make it family mode at the end. There should be some papers with what is allowed in common space somewhere.

For presentation manager you need the “toolkit”. I have a legit box it’s so tiny, sadly diskettes we’re not in the box though.