http://www.os2museum.com/wp/retro-porting-to-os-2-1-0/ OS/2 Museum OS/2, vintage PC computing, and random musings [os2floppy] Skip to content * Home * About + Wanted List * OS/2 History + OS/2 Beginnings + OS/2 1.0 + OS/2 1.1 + OS/2 1.2 and 1.3 + OS/2 16-bit Server + OS/2 2.0 + OS/2 2.1 and 2.11 + OS/2 Warp + OS/2 Warp, PowerPC Edition + OS/2 Warp 4 + OS/2 Timeline + OS/2 Library o OS/2 1.x SDK o OS/2 1.x Programming o OS/2 2.0 Technical Library + OS/2 Videos, 1987 * DOS History + DOS Beginnings + DOS 1.0 and 1.1 + DOS 2.0 and 2.1 + DOS 3.0, 3.1, and 3.2 + DOS 3.3 + DOS 4.0 + DOS Library * NetWare History + NetWare Timeline + NetWare Library * Windows History + Windows Library * PC UNIX History + Solaris 2.1 for x86 - Failing to Fail Retro-Porting to OS/2 1.0 Posted on July 20, 2023 by Michal Necasek A few weeks ago I embarked on a somewhat crazy side project: Make the Open Watcom debugger work on OS/2 1.0. This project was not entirely successful, but I learned a couple of things along the way. The Open Watcom debugger components for OS/2 are 32-bit modules, but didn't use to be. At least up to and including Watcom C/C++ 11.0, the OS/2 debugger components were almost entirely 16-bit. That allowed them to work on 32-bit OS/2 but also on 16-bit OS/2 version 1.x. Needless to say, debugging 32-bit programs with a 16-bit debugger required a bit of extra work and there was an additional interface module (os2v2hlp.exe) which called the 32-bit DosDebug API on 32-bit OS/2 and interfaced with the 16-bit debugger 'trap file' std32.dll. Building the 16-bit components again was not particularly difficult. And they even mostly worked on OS/2 1.2 and 1.1. But I wanted to get the code working on OS/2 1.0 as well. Because why not. [wd16-os2-1]Running the Open Watcom debugger on OS/2 1.1 The OS/2 debug trap file has code in it that's supposed to refuse running unless the host is at least OS/2 1.2. It looks like this: DosGetVersion( &os2ver ); if( os2ver < 0x114 ) { strcpy( err, TRP_OS2_not_1p2 ); return( ver ); } The OS/2 major version is in the high byte and minor version in the low byte. This was clearly meant to check for versions below 1.20. But... the major version returned by OS/2 1.x is actually 10, not 1 -- this was done so that the OS/2 major version would be higher than the DOS versions of the time (3.x, 4.0). So the version check actually never worked because the reported OS/2 version can't be lower than 0x114! As a result, the debug trap file didn't refuse to load on OS/2 1.0 when it should have. But it certainly did not work. How does one debug a debugger? Either using a different, functioning debugger, or the old-fashioned way--debug print statements and such. I went the second route and after some difficulties I ran into, I'm not at all sure the first option is really workable at all on OS/2 1.0. Before going into details, I will say that this kind of project may now be easier than ever before. Certainly much easier than it would have been 20 or so years ago. The reason is that antique programming documentation from IBM and Microsoft is now much easier to find than it used to be. And for reasons that no one ever really understood, Microsoft's and IBM's programming documentation for OS/2 1.x was completely different, and there was always some information that could only be found only in one documentation set but not the other. The first problem I ran into was that the trap file was crashing OS/2 1.0 hard. The cause turned out to be calls to the DosPTrace API executed before a program was loaded. OS/2 1.0 does not appear to detect this situation and dies. Newer OS/2 versions just return an error and don't do anything harmful. Easy to fix. The second problem that I identified is that the program to be debugged could not be started. This was because the DosStartSession API (which a debugger must use) takes a parameter structure, but said structure must be smaller on OS/2 1.0 and the API failed when attempting to use it with a newer, larger version of the structure. Again, easy enough to fix. Another problem had to do with rather interesting logic that the Watcom debugger uses. It injects a small piece of code into the debugged process and runs it. The code does not do much, only invokes the DosLoadModule API to load a copy of the trap file. The debugger can later use this to perform various magic tricks like writing to the debugged program's console or redirecting files within the debugged process. The code, quite sensibly, queried the full path of the trap DLL and used that to load a copy of itself in the debugged process. This failed on OS/2 1.0. After briefly wondering why, I reviewed the documentation and found that in OS/2 1.0, DosLoadModule does not accept a full path. The only thing that DosLoadModule can do on OS/2 1.0 is take an up to 8-character name as input. This name has the .DLL extension tacked onto it and the operating system searches for the file along LIBPATH. This is obviously quite restrictive, but it's all OS/2 1.0 can do. The next problem caused me quite a bit of grief. I used remote debugging (over an emulated serial port) to debug the GUI (really text UI) version of the OS/2 debugger. The debugger stubbornly kept failing to load a support file (cpp.prs). But if I ran the debugger directly (not trying to debug it), there was no problem loading the file! [wd16-rem-os2-1]Remote debugging to OS/2 1.0 works. Mostly. I thought the problem was perhaps due to case sensitivity, or because OS/2 1.0 didn't accept some specific combination of DosOpen flags. To narrow down the problem, I used the remote debugger to modify the DosOpen flags and re-run DosOpen repeatedly. Well, I tried. Whenever I tried modifying the flags in the debugged process, the memory contents changed... to junk. After some head scratching, I found that the std16.dll trap file functionality to write memory had a not very obvious bug in it, taking the size of the wrong structure when calculating internal offsets. This bug was likely present for a very, very long time. With the remote debugger improved, I could attack DosOpen again. I could not find any combination of flags that would work. Eventually I had a flash of inspiration and realized that the problem was something completely different: When the debugged program started, it was running in the wrong directory! And that's why it couldn't find a file that was expected to be in the current directory. I believe the problem is that in OS/2 1.0, a new session always inherits open files etc. from the shell; in newer versions, the debugger can (and does) request that the new session inherits from the debugger instead. This is another area where OS/2 1.0 is different and more limited than the later versions. In the end, I managed to get the remote debugging somewhat working on OS/2 1.0... but not particularly well. I can load a simple hello world program, run it, set breakpoints, step through it, inspect and modify its memory. I also verified that the debugger can properly catch #GP faults in a simple program. As an aside, the debug interface in OS/2 1.0 has odd limitations. For example, a debugger can intercept general protection faults, but it can not intercept divide overflow faults. An integer divide by zero always terminates the program and the debugger can't do anything about it. But my attempts to debug a more complex program (the GUI debugger) miserably failed. The debugger, when executed directly (not in a debugger), always crashed--no doubt because of yet another subtle difference between OS/2 1.0 and later versions. But when trying to run the debugger through remote debugging, all I could achieve was to crash OS/2. I could still load the program and set breakpoints, and step through it, but when it crashed, it took the whole OS with it. All in all, it's apparent that OS/2 1.0 was a work in progress. OS/2 1.1 was notably improved, clearly building on users' experience with version 1.0. It was only OS/2 1.2 that finally included all major features that OS/2 1.x was supposed to have, including installable file systems (IFSs) and improved Presentation Manager. It's no surprise that OS/2 1.0 was rough around the edges. This entry was posted in Development, IBM, Microsoft, OS/2, Watcom. Bookmark the permalink. - Failing to Fail 4 Responses to Retro-Porting to OS/2 1.0 1. [6db4] random lurker says: July 21, 2023 at 7:25 am "It injects a small piece of code into the debugger process and runs it." Did you mean to say it injects code into the *debugged* process? (I don't understand why the debugger would need to inject code into itself) thx 2. [8f7d] Michal Necasek says: July 21, 2023 at 11:06 am Yes, that was a typo, fixed now. Thanks. 3. [49aa] Bill Olson says: July 21, 2023 at 6:41 pm "And for reasons that no one ever really understood, Microsoft's and IBM's programming documentation for OS/2 1.x was completely different, and there was always some information that could only be found only in one documentation set but not the other." They had very different ideas of what they wanted OS/2 to be therefore the very different documentation. Also, from what I understand, they each set about creating documentation separately in the beginning and then realized all of the problems they would run into if the documentation wasn't the same. Microsoft gets WAY too much credit for their work on OS/2. If they had been the star programmers for the OS, Windows 95 and versions of Windows after that would have been far better and absolutely weren't. OS/2 was one of only two OSs that I ever LOVED using. There was OS/2 and there was BeOS. The version that I loved was OS/2 2.0 beta that I saw at a presentation of the new OS/2 at IBM's building in downtown Seattle. I was blown away at what it could do. It was literally a much better DOS than DOS and much better Windows than Windows. But it also was its own OS and I was able to go from using two DOS and two Windows computers to using just one OS/2 computer and was probably 400% more productive than I had been before with DOS and Windows. While DOS and Windows were not dependable, OS/2 2.0, even the beta version was leagues better than either of those with up times in months when DOS and Windows could barely make it a couple of weeks ... if that. I use Mac OS now. It's >> significantly <> could << have gone and been... 4. [5791] Radoslaw Sokol says: July 22, 2023 at 4:18 pm This is the kind of content I come here for regularly. I really admire your persistence in debugging such issues and reviving old software in a way no one previously imagined! Leave a Reply Your email address will not be published. Required fields are marked * [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment * [ ] Name * [ ] Email * [ ] Website [ ] [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] This site uses Akismet to reduce spam. Learn how your comment data is processed. * Archives + July 2023 + June 2023 + May 2023 + April 2023 + March 2023 + January 2023 + December 2022 + November 2022 + October 2022 + September 2022 + July 2022 + June 2022 + May 2022 + April 2022 + March 2022 + February 2022 + January 2022 + December 2021 + November 2021 + October 2021 + September 2021 + August 2021 + July 2021 + June 2021 + May 2021 + April 2021 + March 2021 + February 2021 + January 2021 + December 2020 + November 2020 + October 2020 + September 2020 + August 2020 + July 2020 + June 2020 + May 2020 + April 2020 + March 2020 + February 2020 + January 2020 + December 2019 + November 2019 + October 2019 + September 2019 + August 2019 + July 2019 + June 2019 + May 2019 + April 2019 + March 2019 + February 2019 + January 2019 + December 2018 + November 2018 + October 2018 + August 2018 + July 2018 + June 2018 + May 2018 + April 2018 + March 2018 + February 2018 + January 2018 + December 2017 + November 2017 + October 2017 + August 2017 + July 2017 + June 2017 + May 2017 + April 2017 + March 2017 + February 2017 + January 2017 + December 2016 + November 2016 + October 2016 + September 2016 + August 2016 + July 2016 + June 2016 + May 2016 + April 2016 + March 2016 + February 2016 + January 2016 + December 2015 + November 2015 + October 2015 + September 2015 + August 2015 + July 2015 + June 2015 + May 2015 + April 2015 + March 2015 + February 2015 + January 2015 + December 2014 + November 2014 + October 2014 + September 2014 + August 2014 + July 2014 + June 2014 + May 2014 + April 2014 + March 2014 + February 2014 + January 2014 + December 2013 + November 2013 + October 2013 + September 2013 + August 2013 + July 2013 + June 2013 + May 2013 + April 2013 + March 2013 + February 2013 + January 2013 + December 2012 + November 2012 + October 2012 + September 2012 + August 2012 + July 2012 + June 2012 + May 2012 + April 2012 + March 2012 + February 2012 + January 2012 + December 2011 + November 2011 + October 2011 + September 2011 + August 2011 + July 2011 + June 2011 + May 2011 + April 2011 + March 2011 + January 2011 + November 2010 + October 2010 + August 2010 + July 2010 * Categories + 286 + 386 + 3Com + 3Dfx + 486 + 8086/8088 + Adaptec + AGP + AMD + AMD64 + Apple + Archiving + Assembler + ATi + BIOS + Books + Borland + BSD + Bugs + BusLogic + C + C&T + CD-ROM + Cirrus Logic + CompactFlash + Compaq + Compression + Computing History + Conner + Corrections + CP/M + Creative Labs + Crystal Semi + Cyrix + DDR RAM + Debugging + DEC + Development + Digital Research + Documentation + DOS + DOS Extenders + Dream + E-mu + Editors + EISA + Ensoniq + ESDI + Ethernet + Fakes + Fixes + Floppies + Graphics + Hardware Hacks + I18N + IBM + IDE + Intel + Internet + Keyboard + Kryoflux + Kurzweil + LAN Manager + Legal + Linux + MCA + Microsoft + MIDI + NetWare + Networking + NeXTSTEP + NFS + Novell + NT + OS X + OS/2 + PC architecture + PC hardware + PC history + PC press + PCI + PCMCIA + Pentium + Pentium 4 + Pentium II + Pentium III + Pentium Pro + Plug and Play + PowerPC + Pre-release + PS/2 + QNX + Quantum + Random Thoughts + RDRAM + Roland + Ryzen + S3 + SCO + SCSI + Seagate + Security + Site Management + SMP + Software Hacks + Solaris + Sound + Sound Blaster + Source code + Standards + Storage + Supermicro + TCP/IP + ThinkPad + Trident + UltraSound + Uncategorized + Undocumented + UNIX + UnixWare + USB + VGA + VirtualBox + Virtualization + VLB + Watcom + Wave Blaster + Western Digital + Windows + Windows 95 + Windows XP + Wireless + WordStar + x86 + x87 + Xenix + Xeon + Yamaha OS/2 Museum Proudly powered by WordPress.