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.
Bummer about DeScribe. I ran the OS/2 version under everything from MS-OS/2 1.3 through to 4.52 and it ran fine on all of them (& the Win16 version runs fine also under real Windows 3.0, 3.1, and WIN-OS/2…I somehow did not realize that DeScribe for Windows existed that early).
The About… box is pretty darn spartan, so it makes one wonder if the problem isn’t actually with the PM layer (especially since that seems lifted from 1.3 virtually untouched!), but rather some lower-level OS/2 subsystem call that it’s making & that the NT OS/2 layer is choking on?
it could be trying to interface to a printer for all I know. I didn’t setup any printers for NT, and I’m not all that sure how the printing from OS/2 to NT would work but the print manager automatically starts once you launch the desktop..
WinWorld has the NT4.0 PM Subsystem under the System category in the library.
It behaves the same as the 3.51 version as far as I tested it.
Yeah it’s the one I uploaded in the wild . I was kind of impatient this morning and took the 3.51 path
Thank you for sharing.
So much software and documentation has been lost for older programs, especially non games.
I think I don’t have much software that isn’t at the net and the last time I tried to read some of my diskettes, some of them had bad sectors, but I will try again. Unfortunately I don’t live in a first world country and because my situation I don’t have a Kryoflux, but will try again to read the diskettes and see what I have stored all this years.
Again, thank you for sharing 🙂
Very cool!
I always used to wonder about this.. along the lines of:
Going forward in Windows:
Is it possible to take the OS2 subsystem and run it in later versions of Windows?
Going forward in Presentation Manager:
Can bits of PM from newer versions of OS2 be taken and run in this.
Of course, the boring answer to both of these is probably no, but you never know.
These are just educated guesses, but…
1) Going forward in OS/2 for Windows: maaaaaaybe? I believe the underpinnings for discrete subsystems like this still exists in modern Windows; in fact, I believe that WSL 1.0 used those same hooks (WSL 2.0 switched to using a VM layer, which I’m sure is based on HyperV or is at least reusing components of it). Besides the fact that I’m sure there have been implementation changes of that layer over time that would have to be compensated for when bringing the OS/2 subsystem forward, the big problem here would likely be the x64 version of Windows, which didn’t exist back when OS/2 subsystem was still a shipping component of WinNT. I don’t know for sure, but I’d bet money against being able to bring up the original implementation within WoW64.
(also, keep in mind the OS/2 subsystem itself is limited to 16-bit OS/2 API compatibility, which plays into the answer to your second question below…)
2) Going forward in PM for Windows: this is MUCH less likely (fast approaching zero). First, MS has access to all OS/2 1.x sources since they were sharing development responsibility with IBM for OS/2 at the time & also had that related cross-licensing agreement with IBM (which is what in turn allowed IBM access to Windows 3.x sources that they could base Win-OS/2 on…it cut both ways!). It’s pretty clear that for the PM layer that’s being demonstrated here, MS just took OS/2 1.3 PM source code, tweaked it a bit, and recompiled. Since they didn’t have to spend time clean-room reverse-engineering anything, that gives it a high degree of compatibility for fairly little effort on their part. That cross-licensing agreement ended shortly after OS/2 development partnership between the two companies ended. It’s *possible* I suppose that MS could technically/legally be due access to some of the IBM-only code that shipped in OS/2 2.x, but certainly nothing beyond that (Warp, etc.). And even if they *could* get the 2.x PM code from IBM, they’re not going to ask for it because they don’t care at this point, and even if they did have access, they aren’t going to spend time spinning a new release of PM for Windows based on it. Nobody other than MS can really produce a new release, either…if we wanted to undertake this as a hobbyist community, as third-parties without access to any source on either the IBM or MS side, our only option would be reverse-engineering both halves and then kludging up a bunch of very ugly hacks (assuming it’s even possible). And finally, anything OS/2 2.0 and beyond is 32-bit. So we are talking a completely new implementation of the PM layer that would have to sit atop a new *32-bit* version of an OS/2 for WinNT subsystem that flat-out doesn’t exist in any form, and never will.
as far as I’m aware nobody has managed to get the OS/2 subsystem running on 2003/LongHorn onwards. That said it’d be i386 (32bit) dependant so all those fancy x64 systems are out of the question.
Newer Presentation manager will most certainly NOT work as they are 32bit, and even if CRUISER bits were finished it’d be the older format from the previous posts about old linkers and hidden OS/2 toolchains.
Now if there was a time/effort thing, then yes for sure.
If I had $ to blow on it, I’d take 2ine and port it to something like OTVDM aka use the MAME i386 emulation and get it off of hardware i386 emulation and get the OS/2 DLL’s running in other places. But it’d be an incredible amount of work for basically at best EMX based stuff which is just trying to emulate Unix.
There is no OS/2 killer app, there are killer apps that are either MS-DOS/Win16 that run on OS/2 or the few and far between that were ported to OS/2.
Im not even going to touch the source leaks that of course open the door to adding at least API compatibility like the old POSIX subsystem, that doesn’t even try to achieve any binary compatibility. But that would be the only way, but good luck on x64 where everything needs to be signed.
Thanks for the thoughtful replies, Nathan and neozeed.
The lack of a killer app is a big issue … that keeps mainly on the curiosity side.
osfree.org is also an interesting project.. it seems to slowly chug along, though .. (very slowly it seems) – maybe it would make sense for them to use 2ine for the graphical side.
If I had enough time I’d untangled 2ine to tie the DLLS to Linux and redo the loader to the mame 80386 core like otvdmw.
The problem is that there is no large awesome other than 64bit SMP RISC OS/2 for salaryman
“Download link… gimme gimme!”
Win world pc
I don’t mean to imply that we condone anything illegal here by saying this: but as many times as various iterations of the Windows NT source code have leaked over the years, it really is a shame that nobody’s ever leaked the source to OS/2. It’d be absolutely worthless, but fascinating to read for those of us old enough to have used it as our daily drivers way back when.
Yep, pretty much. and it’s guaranteed to be useless in this day & age as it’s no doubt 100% hand tuned 80286 assembly. If anything the ‘useful’ bit would be fixing all the timing issues, and maybe making the errors more useful other than the infamous ‘error in country.sys’ nonsense.
I remember a few years ago, I don’t remember how many… There was a movement to make IBM release the OS/2 source code, (probably Warp or other version from IBM). A spokesperson from IBM said that IBM was in favor of releasing the code, but… that part of the code was licensed from other companies and would be complicated to get the permission from these companies to release the code and I think that was the end of it.
from what I remember the JFS code that made it’s way to Linux came from OS/2 PowerPC.
HPFS is a Microsoft thing, and well if you look at ‘European DOS’ aka the ‘link4’ Windows 1/2 magic it’s all Microsoft.
Some code that I would really want to see would be SOM (System Object Model) and Workplace Shell. I believe we don’t have nothing today like SOM, we could load libraries and call method/functions, but no Object Orientation at the Operating System Level.
I read that RPC have security problems hard to fix and that was why it was not used anymore, but I don’t remember if SOM or DSOM (Distributed System Object Model) used RPC.
There is some ‘free’ portable SOM, somFree.
The OS/2 subsystem in NT was needed for more than just SQL. I mean, the whole reason Workgroup Applications (hi!) released client and server software for OS/2 was because Australia Telecom was the biggest Microsoft Mail install in the world at 50,000 seats, ran _mostly_ OS/2 1.31, and bought premium-tier support, so when they said “jump” we said “how high?”
I don’t know if that was as important as SQL but it was pretty important.
I guess I should add, ‘cruiser’ was nowhere near to the point of running anything on NT/OS2 was it?
(sorry, used the wrong username first time, my bad, i’ve set it to save this time)
The OS/2 subsystem in NT was needed for more than just SQL. I mean, the whole reason Workgroup Applications (hi!) released client and server software for OS/2 was because Australia Telecom was the biggest Microsoft Mail install in the world at 50,000 seats, ran _mostly_ OS/2 1.31, and bought premium-tier support, so when they said “jump” we said “how high?”
I don’t know if that was as important as SQL but it was pretty important. They stood pat for a _long_ time on OS/2 1/31 and Microsoft Mail 3.0-3.5 and being there for them in 16-bit OS/2 was a big deal to keeping them from defecting to… who even knows what, right?