It looks like you're new here. If you want to get involved, click one of these buttons!
Read the full story here
1.04 is picky on PS/2 especially in virtual machines. So real hardware it can work. VMs it will not work at all.
Incorrect, 1.04 is not "picky". Windows 1.x simply does not support PS/2 mice at all. Why? Because it was release before the IBM PS/2. And we don't know of any standalone driver supplied by IBM. (Wouldn't they have included a mouse driver disk with the PS/2 machines?)
You may add PS/2 support by copying the mouse driver from Windows 2.03 (or the one we have listed under premiere edition) over the driver on the 1.x setup disk and then re-install. (just copying a file in to the Windows folder will not work).
As mentioned on the product page, IBM allegedly released an OEM version of Windows 1.04 that included a PS/2 mouse driver, but that has not been archived yet.
SomeGuy's comment is correct if you are using MS-DOS 3.3 or later. Before that e.g. with MS-DOS 2.2, I can confirm that even this trick won't help you. I've tried (and posted about the attempt somewhere else on this forum).
The PS/2-aware drivers from any version of Windows just don't work in MS-DOS 2.2.
Specifically, these are the MOUSE.DRV drivers from Window 2.03, and from the IBM PS/2-release of Windows 1.04. Those from 1.01, 1.02, 1.03 and other releases of 1.04 are not PS/2-aware unless you replace them. Just replace the MOUSE.DRV, MSMOUSE1.DRV and MSMOUSE2.DRV on the first floppy disk image using a tool like WinImage before attempting the Windows installation. You won't see PS/2 mentioned, mind. You have to select the MS Mouse that you have "faked" and the driver will detect the PS/2 at runtime. And like I said, it should be at least MS-DOS 3.3 that you install to, else that driver still can't detect the PS/2. It isn't as clever as CTMOUSE (aka CuteMouse).
Unlike MS PBRUSH and MS Word 1.15 - both of which can be made to use the PS/2-aware CTMOUSE driver when this is combined together with the MS-MOUSE 6.2 driver, and after you configure the MS MOUSE.INI file to pass-through the existing CTMOUSE PS/2 driver. In this configuration I could get MS PBRUSH and MS Word to work with the VMWare PS/2 mouse in MS-DOS 2.2. Most other software will then also use the CTMOUSE directly or indirectly as needed. But MS Windows won't.
The Microsoft Windows 1.0X and 2.X mouse drivers appear to require and rely upon something in the DOS itself. So even if you use the driver in the IBM-PS/2 Windows 1.04 or any copy of Windows 2.03, they won't work with MS-DOS 2.2, as that version of DOS itself significantly predates the PS/2 architecture. Unfortunately whatever trick CTMOUSE uses to detect the PS/2 without relying on DOS can't be replicated by any of the MS code, and Windows ignores any DOS-based MS-Mouse, thus missing the pass-through trick. Other software is somewhat less particular.
My guess is the Windows PS/2 drivers probably won't work with MS-DOS 3.0, 3.1 and 3.2 either, though I haven't confirmed this. It was MS-DOS 3.3 that came out during the IBM PS/2 era, and I can confirm that the trick works then - without requiring the presence of CTMOUSE or a pass-through MS-MOUSE INI setting. The Windows ones work on their own, clearly doing their thing directly with DOS but only if it's the right version.
As an after-thought, if you really like a challenge, there may be a way of fooling Windows into thinking the CTMOUSE (do a search for CuteMouse and download), is actually its own driver, by renaming and injecting one of the CTMOUSE files to replace the Windows one. But first you'd have to work out which Windows file is the correct one and then hope that the DOS API that CTMOUSE presents is the same as the Windows API presented by the original Windows Mouse driver. However, my guess is that they aren't the same API - which is why Windows appears to ignore any DOS driver already present - it simply doesn't have the right API. This would explain why other MS Products designed for DOS can be fooled into using CTMOUSE directly or indirectly, but Windows can't. But this is all just observational theory and conjecture of course.
Incidentally, the MOUSE.INI pass-through trick I mentioned earlier arose as an attempt at belt-and-braces during my experiments. It appears that it might not be needed for DOS programs and CTMOUSE on its own is sufficient for anything but Windows.
Windows drivers are vastly different from DOS drivers. Even the kind of executable container is different.
Normal DOS programs don't need to be "fooled" to use a non-Microsoft mouse driver. A DOS mouse driver directly controls the hardware and exposes a set of standardized software interrupts as an API. This permits mouse drivers from Mouse Systems, Logitech, and zillions of others to operate with DOS programs that were written to accept Microsoft's original DOS driver. As a bonus, that puts all hardware support in the driver. There are drivers that simulate a mouse with the keyboard or joystick, and drivers that support bus, serial, PS/2 and various oddball proprietary interfaces. I don't know if anyone has written a DOS driver for USB mice, but it is not impossible (USB stacks are insanely complicated).
I just check Windows 1.01 under MS-DOS 2.11 and you are right, the PS/2 mouse driver did not load. That seems a tad odd as it should not depend much on DOS.
Yep, SomeGuy, you are right - in fact, had the "Edit-timeout" not occurred, I would have corrected myself (One hour of editing is way too short for me! I spend too much of it verifying things) So, yep - there's no need or benefit in layering an MS-Mouse on top of CT-Mouse.
It turns out I'd confused myself by working on several DOS versions in parallel over a month of experimentation (2.11 through 3.3). Some of those were incomplete, and hence confusing.
MS-DOS versions that predate the release of the physical IBM PS/2 machine are simply unable to detect the PS/2 mouse presented by VMware. All Microsoft code, whether that be DOS Mouse or Windows Mouse drivers will consequently fail, whatever version of those drivers you use. And VMware won't present any alternative to a PS/2 mouse. So you are screwed if you rely purely upon Microsoft stuff to build your (say) MS-DOS2.11 VM, if a mouse is required.
So you not only have to have a PS/2-aware MS mouse driver, but you also have to have a compatible DOS - which for Microsoft drivers is most probably at least MS-DOS 3.3. This implies that there is some feature within later versions of DOS that Microsoft depended upon in order to detect (or predict) a "physical" PS/2 mouse. And this is absent in (say) MS-DOS 2.11.
However, if you use CuteMouse (CTMOUSE), this will bypass the DOS version problem because (according to its documentation) it actually tests exhaustively for PS/2 mouse protocoled behaviour. It just does a whole lot more than Microsoft used to do. But it only supports DOS programs, not Windows 1.X or Windows 2.X. This is because Windows ignores whatever DOS-based driver you installed, including CTMOUSE.
It turns out that is not essential, when using CTMOUSE, to additionally add an MS Mouse driver for DOS programs. (I have now fully tested this). And since any PS/2-aware MS Mouse driver can work on its own in MS-DOS 3.3, the CTMOUSE is no-longer essential when using MS-DOS 3.3.
However, the bottom line is that there simply is no way to make any version of Windows work in pre-PS/2 versions of MS-DOS (such as MS-DOS 2.X) when running as a VMware VM.
And as said before, Windows ignores the DOS driver, so you have to nick a later PS/2-aware Windows driver, and you have to use MS-DOS 3.3.
But you can make DOS programs use the VMware PS/2 mouse in MS-DOS 2.11, by using CTMOUSE instead of any MS MOUSE.
Hopefully, this summary is somewhat more accurate and clearer.
And here's a new challenge- I believe there may be source code available for Cute Mouse. There might be a source for the Windows MSMOUSE driver, or at least an API definition. If someone could marry these up and compile a new driver, they could create a VMware-PS/2 emulation of MS-DOS 2.X that does support Windows. Anyone feel like coding? ...Not me, I'm getting too old for it. I've long forgotten most of my 8088 assembler skills from 35 years ago.
Thinking about it... you can bet your bottom dollar that the Microsoft PS/2 Mouse drivers are all looking for the most obvious DOS feature first (which is the DOS version number) and hence not testing for PS/2 mouse presence at all because it is "unlikely" to be present. So poking a few NOP instructions might cure the problem if you know where to put them.
Wasn't there a collegiate version of Win1X that had PS/2 Mouse support?
The IBM PS/2 version has been added to WinWorld. It has drivers for VGA and PS/2 Mice.