The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I am working on a legacy DOS app that I hope to modernize into a Windows app, but it will be in a series of stages. In this stage, I need to write a TSR (Terminate and Stay Resident) COM application to monitor some of the activity going on in the app.
I wrote similar TSR DOS apps in the mid-80's, but it has been a very long time. It took some special effort to get a DOS .COM app to compile at all with VS 2019 - no MASM (done under C++), and the Linker doesn't get some of the options that used to be available...
If your friend is interested, I might be able to provide some guidance or assistance on this...
Thanks for the offer, but my friend is not responsible for the situation nor directly involved. The responsible folks are utilizing the time-old method "lots of praying" in lieu of replacing the hardware. When it eventually fails they will be forced to buy a new solution.
I suspect they are ignoring that corollary to Murphy's Law that states, "hardware failure will occur at exactly the worst possible moment".
Tern still makes embedded controllers running 186 to 486 compatible chips. so there's still manufactures building with those chips. I worked with one of their 286 boards a couple years back, it was a lot of fun writing SPI and 2-wire code to communicate with the various other chips on the board.
Haven't touched assembly in years, for now c, is good enough in what i'm doing.
The virtual DOS support in the 386 was, inadvertently, one of the worst things to ever happen. Because of that, Microsoft bailed out of OS/2, and went back to making money on DOS and started Windows 1.0 on top of DOS, and the rest is history.
Without that, OS/2 would have likely stuck and we'd have a vastly more sane environment to work in today. OS/2 threw out the Win32 API and created a completely new one that was consistent, and actually designed, not excrementally grown.
That's not exactly what happened. Windows 1.0 was quite a while before OS/2. A dispute over Windows 3.1 was what led to discontinuing joint development on OS/2. Microsoft took that API and developed NT with it and the end result was still very, very similar to OS/2 . In fact, the older documentation of the Win32 API would note compatibility with OS/2 for the various functions.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
They were about 2 years apart, but that's initial release, not when planning and work started on them. Anyhoo, the bottom line is that once it became possible to 'multi-task' DOS applications, OS/2 was pretty much doomed because Microsoft could continue to milk that cow instead of forcing the adoption of a new standard. Obviously forcing a new standard is hard, but we'd have all been far better off for it.
As to the compatibility there isn't much that I can see. The OS/2 API was extremely consistent in terms of naming and parameters and such. The Win32 API was basically a hacked up version of the previous Windows APIs. Win32 is a mess in comparison to the OS/2 interfaces.
IBM took OS/2 on to the 32 bit form and it was nice, though of course back then it took like 25 floppy disks to install or some such.