Recently a minor mystery resurfaced. When IBM’s OS/2 1.2 SE is installed on any “normal” system (either physical or virtual) and the PS/2 mouse driver is installed (the typical choice), the mouse won’t work:
The MSPS201.SYS driver is intended for Microsoft (‘MS’) PS/2 (‘PS2′) mice for so-called Type 1 (’01’) aka AT-compatible systems. It should work, and it indeed does work in IBM’s as well as Microsoft’s OS/2 1.3.
The reason why two error messages are displayed is caused by the mouse driver design in OS/2 1.x (as well as initial 2.x releases): There wa a generic mouse driver, MOUSE.SYS, which was responsible for providing mouse services to the rest of the system. This driver cooperated with a device-specific driver, such as MSPS201.SYS. Other device-specific drivers supported serial mice, MS bus mice, etc. The device-specific driver was relatively simple and used a straightforward interface to communicate with the generic driver.
But back to the original problem. Why won’t the IBM OS/2 1.2 MSPS201.SYS load? The answer turns out to be slightly unexpected. The driver doesn’t even get as far as trying to communicate with a mouse. During initialization, it calls the DosDevConfig API (twice) to query the system’s model and submodel ID bytes.
The driver only continues to load when the model is FCh (AT and compatibles) and submodel is 9. This would be true on IBM PS/2 Model 25 and 30 machines, the ISA bus based not-really-PS/2 systems. It’s not the case on any AT clone systems.
The obvious question is, would the driver load if the submodel ID were changed to 9 on a clone? The answer is as follows:
For PS/2 Model 25/30 machines, OS/2 1.2 and 1.3 loads a separate set of drivers that is neither ‘AT style’ (BASEDD01.SYS) nor ‘PS/2 style’ (BASEDD02.SYS). Not too surprisingly, the BASEDD03.SYS driver does not work on AT compatibles. Presumably if it did, there would be no need for separate drivers.
Is there any other way to convince the MSPS201.SYS driver to work? If changing the environment does not bring the desired results, perhaps patching the driver will. This method indeed works. For the driver distributed as MSPS201.SY@ (1796 bytes, dated 08/31/1989), all it takes is changing the byte at offset 6B0h from 74h (JE instruction) to 75h (JNE). Note that this modification must be applied to the unpacked driver!
With this tweak, the driver no longer fails the model/submodel check and happily loads and works on an AT clone equipped with a PS/2 mouse.
The MSPS201.SYS driver distributed with OS/2 1.3 does not include this overly strict model check. Because the internal mouse driver interface was not changed, the OS/2 1.3 PS/2 mouse driver for AT compatibles can also be used with OS/2 1.2.