The other day I had a “pressing” need to obtain the list of modules loaded in an OS/2 VM by examining the VM’s memory and CPU state. I was able to use existing code that worked on OS/2 V3.0 (Warp) and later. But the logic failed on OS/2 V2.11 and earlier.
I pulled out the trusty old OS/2 Debugging Handbook, Volume IV, which provides an excellent reference of internal OS/2 structures. I quickly established that although the overall architecture is the same, OS/2 V2.11 used a slightly different format of the MTE (Module Table Entry) structure in memory. Adjusting for the difference made the module discovery code work in OS/2 V2.1 and V2.11.
But not in OS/2 V2.0. I could tell that the layout of the SAS (System Anchor Segment) must be different between OS/2 V2.0 and V2.1. Only the OS/2 Debugging Handbook has nothing to say about OS/2 V2.0 at all—it talks only about V2.1 and later.
I tried to find the SAS definition in header files, since SAS.H/SAS.INC was shipped with the OS/2 DDK. But I have no OS/2 V2.0 DDK, and the oldest DDK (1993) I could find clearly defines the SAS layout used in OS/2 V2.1 and later.
Then I noticed that the OS/2 Dump Formatter (but not the Kernel Debugger!) has a promising-sounding .A command described as “Format the System Anchor Segment (SAS)”. Except… there’s no Dump Formatter for OS/2 V2.0! Only for V2.1 and later. That was a surprise to me, because I assumed that it had always “been there”. Clearly that’s not the case and it was introduced with OS/2 V2.1.
In desperation, I started searching the OS/2 2.0 Technical Library for information on kernel debugging. What I found was… nothing. Even though the Technical Library contains complete DDK documentation, the Kernel Debugger is not documented there.
After some more digging, I found an archive called KDEBUG.ZIP. This contains KDEBUG.DOC, or IBM OS/2 Kernel Debugger Preliminary Draft, dated September 14, 1992. Now that explains why the Kernel Debugger documentation wasn’t included in the OS/2 2.0 Technical Library: The Technical Library was published in March or April 1992, and the Kernel Debugger documentation simply wasn’t ready at the time.
Publishing mysteries aside, I soon established that KDEBUG.DOC holds no answers either. While it shows a couple of neat tricks for debugging module loading on OS/2 V2.0, it does not show the MTE layout and says nothing whatsoever about the SAS.
Here’s the relevant information from the Debugging Handbook that applies to OS/2 V2.1 and later, as shown by the Dump Formatter .A command:
--- SAS Virtual Memory Mgt. Section ---
Flat offset of arena records: FFF13304
Flat offset of object records: FFF1331C
Flat offset of context records: FFF1330C
Flat offset of kernel mte records: FFF0A891
Flat offset of linked mte list: FFF07934
Flat offset of page frame table: FFF11A70
Flat offset of page range table: FFF111EC
Flat offset of swap frame array: FFF03BAC
Flat offset of Idle Head: FFF10090
Flat offset of Free Head: FFF10080
Flat offset of Heap Array: FFF11B78
Flat offset of all mte records: FFF12E04
The last item, also known as SAS_vm_all_mte, is how one can find all modules loaded in an OS/2 V2.1 and later system. As far as I can tell, that item simply doesn’t exist in OS/2 V2.0 (the SAS VM section is shorter). Worse yet, SAS_vm_krnl_mte (the kernel MTE, aka DOSCALLS.DLL) and SAS_vm_glbl_mte (offset of linked MTE list) aren’t there either, or use a significantly different format that I’ve been unable to figure out.
This remains an open research topic. There’s still a chance that the OS/2 V2.0 SAS was documented somewhere. If not, it should still be doable the hard way, disassembling the relevant OS/2 V2.0 code.
Update: As a reader pointed out, there was a Dump Formatter for OS/2 2.0. Its existence is noted in the July 1992 issue of the IBM Personal Systems Journal (page 65). The publication offers no hint as to where the Dump Formatter might be obtained, only notes that “This utility is not included with OS/2 2.0; it is for experienced OS/2 support personnel only.”
For whatever reason, IBM distributed the OS/2 2.1 and later Dump Formatter through normal public support channels, together with debug kernels and service packs. The V2.0 Dump Formatter never made it there.
A package called DF20 with the OS/2 2.0 Dump Formatter could be obtained internally within IBM. I failed to find any obvious copy, either online or in my own OS/2 archives. Until I stumbled upon it on an IBM Technical Connection CD-ROM from 1995. The CD-ROM contains the newer OS2PDP archive (PDP = Problem Determination Package) which supports OS/2 2.1 and later, but there is also an archive called DUMPTOOL.ZIP which is in fact the DF20 package.
The DF20 package includes PMDF (Presentation Manager Dump Formatter) and Dump Formatters for OS/2 2.0 GA, OS/2 2.1 GA, plus several other interim versions from 1992-1993.
My attempts to use the Dump Formatter with OS/2 2.0 GA ended up in abject failure. Dumping the memory to floppies and unpacking the memory dump file went fine, but no matter what I tried, the Dump Formatter for the 6.307 kernel just crashed at startup every time. The exact same procedure performed on OS/2 2.1 worked without a hitch… but didn’t tell me anything I didn’t already know.
Eventually I realized that the DF20 package also supports OS/2 2.0 “preload” aka version 2.00.1. This version uses a newer kernel (revision 6.427) but the core data structures are unchanged relative to 2.0 GA.
The 6.427 Dump Formatter answered a few questions… and opened up several others. It’s still work in progress.
The MTE structure exists as early as Multitasking DOS 4, which is pretty funny (although there it’s just 16 bytes_
I guess it just underscores the fact that there is a more or less straight line from Multitasking DOS 4 to OS/2 1.x to OS/2 2.x. Especially in the area of executable formats and loading.
Yeah, the PTDA already exists too, and as early as May 1984, iirc.
Many other areas are similar – the two that come to mind immediately are the scheduler also seems to be remarkably similar and the shell is absolutely the same codebase between MDOS 4 and OS/2, which by the way still exists in NT (as it was ported…) as CMD.
The main change was in drivers, which needed to be rewritten to work in protected mode. They already made design considerations for protected mode in Multitasking DOS 4 development (per the documents that are now available) and designed the kernel in such a way as to not use too many 8086 specific features so a hypothetical “5.0” could use DOS.
Overall, I believe I was able to match around 35 percent of kernel functions with OS/2 1.0 7.68 and the November 1985 MDOS 4 build (a similar amount to the percent that matched with DOS 3.2, the closest comparison – May 1984 was based on 2.11, though) and another 5 percent with Windows 1.0 (the global memory manager stuff is a copy and paste). Shell was closer to 80 percent, and 65 percent even with final OS/2 1.0 CMD.EXE.
I’ll finish my blogpost eventually, but the May 1985 build that turned up destroyed my flow for it.
Actually, after some further reflection it could be based on 2.00 or 2.10, since development started in January 1983 as “DOS 3.0” (there is an overwritten March 1984 syscall list on IBMBIO source disk 1, that has functions starting right where DOS 2.0 left off at 59h or whatever as “3.0 Multitasking Calls”). I haven’t looked at that build in detail yet, but the multitasking functions implemented start at 80h (and only go to 8Fh), like all later builds.
I’ll figure it all out later. They mentioned they were going to “reimplement the multitasking improvements on top of MS-DOS 3 soon” in the Readme for the May 1984 build (dated June 5, 1984) – by which I assume they mean they merged the 3.0 changes, some of which started as MDOS 4 changes, into 4.0
On the other hand, I think MS was once threatening to support Hercules in multitasking DOS 4.0. I wonder why that got pulled.
(keep in mind at the time there were very few EGA clones)
Who was threatened by Hercules support in MT DOS?
And by the way, are you sure MT DOS doesn’t support Hercules? it runs quite well on a PC/XT with a MDA, and Hercules emulates MDA perfectly.
Supporting Hercules requires for example saving additional registers.
Only if graphic mode is used, and I’m not sure MT DOS supported graphic programs.
In text mode, HGC can be used as a MDA, and saving/restoring the MDA registers and video memory is enough to make things work.
IBM might had seen a non-IBM video adapter/mode as “threatening”?
Btw, in theory MT DOS could probably be run on a computer with both MDA and CGA, set to MDA mode default, and run one graphic application on CGA.
As a side track, it’s a bit weird that none of OS/2, NT or 16-bit Windows seems to have supported running text mode applications both using the graphics screen and also MDA, like how Xenix (and maybe later Linux?) supports MDA+color cards for dual text mode screens. (IIRC Xenix maps ALT+F1..F6 virtual consoles to one of the screens/cards, and ALT+F7..F12 to the other).
“IBM might had seen a non-IBM video adapter/mode as “threatening”?”
HGC support in an obscure, limited release OS was threatening? But HGC (and other non-IBM adapters) support in Windows and GWBASIC wasn’t threatening? IBM might have had issues with the PC clones that ran MT-DOS, and with Microsoft that supported them, but hardly with the HGC.
IBM had no problems with third party adapters, especially when they could work with IBM computers. Video cards weren’t part of the core PC business of IBM, and were not considered a competitive threat.
(Note that I am talking about when “CP DOS” was created and they went to 286 protected mode)
Also note that they were very quick to add VGA support into “CP-DOS” as well.
The protected mode “CP-DOS” was for all intents and purposes an alpha/beta or OS/2. IBM PS/2 was meant to be the flagship platform for OS/2. The VGA was the primary video adapter for the 286- and 386-based PS/2 computers. In fact, the VGA was originally called “PS/2 display adapter”.
It’s little wonder that the VGA got preferential driver treatment.
The title seems a bit misleading to me. The Kernel Debugger and the Debug Kernels were shipped with IBM’s Developer’s Kit for OS/2 2.0. Otherwise, SNAPDF can be utilised for dumps from SnapDump/2 or FFST/2. Another option would be to use ASDT32. Both tools can be found here: http://public.dhe.ibm.com/rs6000/developer/os2/SDPtools/ – The manuals mentioned cover later problem determination packages.
Sure debug kernels were available, but they can’t print the SAS layout, or I don’t know how. And there’s no Dump Formatter for OS/2 2.0 as far as I can tell.
As for the title, the goal is interpreting OS/2 state without the kernel debugger or any debugging tools loaded. That is, when things fail in an unplanned fashion.
I can’t get to the IBM site either. Temporary outage or something else?
Try changing the start of the URL from http into https – that worked for me
Indeed. Thanks for the hint!
A dump formatter for all levels of OS/2 2.0 and 2.1 can be found in the DF20 package from IBM’s RAS support.
OK, but… where is it?
I have found some evidence that yes, there was a dump formatter for OS/2 2.0. But did it ever make it outside of IBM? All my searches turned up nothing. For OS/2 2.1 and later, yes, finding the dump formatters is not that hard. But 2.0?
ETA: Actually… I found DUMPTOOL.ZIP on an IBM Technical Connection CD-ROM. That seems to be the right thing. Exceedingly well hidden. Off to play with it…
So I did find it… and it didn’t work. That is, the 2.0 GA dump formatter (both df_ret and df_deb) just crashes on startup, even though it’s the exact same revision as the kernel. I repeated the same procedure with OS/2 2.1 GA and it worked fine. Who knows.