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.
To summarize:
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 atall because it is "unlikely" to be present. So poking a few NOP instructions might cure the problem if you know where to put them.
I had heard of a PS/2 specific version of WIndows 1.04 before, but didn't know if it actually existed or not. I guess it does!!!! Just too cool to me since I'm a HUGE PS/2 fan.
I installed this on my Model 25 (technically identical to the Model 30), and it works great! I love playing around with these early versions of Windows.
Going to try and get it running on my Model 80 next!! Also need to get it on my Model 60 and two Model 30s...............
Because this is an OEM version, you only have three choices:
1:IBM Personal System/2 Model 30
2:IBM Personal System/2 Model 50, 60, 80
3:IBM Personal System/2 Model Display Adapter Card or Display Adapter 8514/A
I think normally you would select 3, although the second looks like it does the same thing.
The Model 30 uses "MCGA" instead of full VGA video, which selects a monochrome 640*480 mode.
@HorseBatteryStaple said:
Wasn't there a collegiate version of Win1X that had PS/2 Mouse support?
Microsoft Windows 1.04 is the first version of Windows 1.x that can support officially PS/2 mice.
Also, versions like Windows 1.01, Windows 1.02 or 1.03 does support also PS/2 mice, but you'll need to copy the driver from Windows 2.03 into, it's setup disk which is the disk 1.
in dosbox-x for some reason, windows 1.01, my previous installation stopped acting normal and stopped running applications entirely (normal apps that came with windows) and was unstable (it wasn't like this before) and so i came here and installed the IBM windows 1.04, and now i can switch directories but it's still very unstable and prone to hanging, opening any windows app doesn't do anything (wait cursor for like half a second) and DOS apps just bring up the 'cannot run' dialog box, albeit with a black box which then just turned into a thick black line...help me? that sounds like an error with dosbox-x somehow, but it all worked fine before, and windows 2.0, 3.0 and 3.1 all work normally
i reinstalled now, but the issue persist, except the icon is now there, and running windows with /r results in a dialog box that says 'Cannot run ' before the dos executive launches Edit: when i do C:\windows1\win.com /r now, it just says 'Cannot find Windows startup files' (i didn't delete anything in the windows1 directory), but when i CD into windows1 and then do win.com /r it does the previously described issue? i'll try with regular dosbox Edit 2: dosbox just freezes on the boot screen Edit 3: dosbox doesn't work with any copy of windows i have installed, 1.0, 2.0 or 3.0 and 3.1... although, 3.1 is the only one that returns an error message, 1.04 just hangs, 2.0 crashes back to the shell, 3.0 hangs on a blinking DOS prompt
Comments
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.
To summarize:
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.
One year(even more) and you answer now? hehehe
I had heard of a PS/2 specific version of WIndows 1.04 before, but didn't know if it actually existed or not. I guess it does!!!! Just too cool to me since I'm a HUGE PS/2 fan.
I installed this on my Model 25 (technically identical to the Model 30), and it works great! I love playing around with these early versions of Windows.
Going to try and get it running on my Model 80 next!! Also need to get it on my Model 60 and two Model 30s...............
how the mouse working? because I installed IBM version on vmware and it doesn't work
Maybe you chose the wrong mouse driver? I think there's a good Windows 1.04 IBM OEM tutorial with all the drivers listed, but it's in Russian.
You have to choose the "IBM Personal System/2 Mouse".
Here's a fact. Microsoft's Windows 8 Metro was inspired by Windows 1.04's MS-DOS Executive.
It works like a charm. Thank you! At least this version works for VirtualBox.
Which display driver do I pick?
Because this is an OEM version, you only have three choices:
1:IBM Personal System/2 Model 30
2:IBM Personal System/2 Model 50, 60, 80
3:IBM Personal System/2 Model Display Adapter Card or Display Adapter 8514/A
I think normally you would select 3, although the second looks like it does the same thing.
The Model 30 uses "MCGA" instead of full VGA video, which selects a monochrome 640*480 mode.
If you are running it on VirtualBox, I recommend to use the ''IBM Personal System/2 Model Display Adapter Card or Display Adapter 8514/A''.
Microsoft Windows 1.04 is the first version of Windows 1.x that can support officially PS/2 mice.
Also, versions like Windows 1.01, Windows 1.02 or 1.03 does support also PS/2 mice, but you'll need to copy the driver from Windows 2.03 into, it's setup disk which is the disk 1.
Well, you probably messed up with it. Use the PS/2 option, since it's from IBM and should work when you want to emulate.
Edit: when i do C:\windows1\win.com /r now, it just says 'Cannot find Windows startup files' (i didn't delete anything in the windows1 directory), but when i CD into windows1 and then do win.com /r it does the previously described issue? i'll try with regular dosbox
Edit 2: dosbox just freezes on the boot screen
Edit 3: dosbox doesn't work with any copy of windows i have installed, 1.0, 2.0 or 3.0 and 3.1... although, 3.1 is the only one that returns an error message, 1.04 just hangs, 2.0 crashes back to the shell, 3.0 hangs on a blinking DOS prompt
edit: it worked! thanks so much