VMware mouse support for Win9x/ME

[rderooy]

Code of Conduct & Contributing Guidelines

• I agree to follow the code of conduct and the contributing guidelines.

Have you checked that no other similar feature request(s) already exists?

• I have searched and didn't find any similar issues.

Is your feature request related to a problem? Please describe.

Extension of closed issue #3313

There is now VMware mouse support for Windows 3.1x, but it does not work with Win95, Win98 or WinME.
It seems the vmmouse.vxd driver for these windows versions assume a PnP device, which the current vmware mouse support does not implement.

What you want

Support for the vmmouse.inf and vmmouse.vxd VMware mouse driver package.

Describe alternatives you've considered

No response

Additional context

To get the vmware driver mouse, it seems the easiest way is to install VMware Workstation Player (free, but registration required), install it to get your hands on "winPre2k.iso", which contains the pre-Windows2000 drivers and includes the "vmmouse" driver for Windows 9x/ME.

Alternatively, it seems the latest version of the regular VMware Tools that included Win9x/ME support was version 5.5.6. Newer versions of the separate VMware Tools don't seem to include it any longer.

The only pointer I could find was a ESX download for the ISO which contains the driver.
https://msfn.org/board/topic/182085-vmware-tools-manual-download/?do=findComment&comment=1190715

Here are the PS/2 Mouse PnP device ID's from the vmmouse.inf file:

; Manufacturer Sections
; ----------------------------------------
[VMware]
%VMMouse.Desc%=VMMouse,*PNP0F0E
%VMMouse.Desc%=VMMouse,*PNP0F13

[javispedro]

DOSBox-X already shows the *PNP0F0E device:

dosbox-x/src/ints/bios.cpp

Line 1780 in 1b5d7f3

ISAPNP_ID('P','N','P',0x0,0xF,0x0,0xE), /* PNP0F0E Microsoft compatible PS/2 */

Anyway this is just an indication that there is a standard PS/2 mouse controller. Nothing fancier.
So I'm not sure if this is the issue. Were you able to install the driver via .inf file ?

I remember the vmmouse driver will not install on Win95, it seems to require 98.
Also it may be coupled to the vmware svga driver, not sure.

Also I noticed that dosbox-x's current implementation of vmmouse is not enough e.g. to load the Linux vmmouse driver.
https://github.com/torvalds/linux/blob/3e732ebf7316ac83e8562db7e64cc68aec390a18/drivers/input/mouse/vmmouse.c#L292
Here the Linux driver seems to be expecting a "version" packet of size 1 with yet another magic number, right after enabling vmmouse. The osdev tutorial seems to completely ignore this magic number, though, and I don't know whether the oficial vmmouse.vxd expects it or not.

[rderooy]

Thanks for the pointer for the PNP ID, I had missed that.

I indeed tested it with Win98SE only, where I was able to install the driver, but it gave an error after a reboot in device manager. And while the mouse worked, it behaved as before.

[javispedro]

From a quick look it seems that vmmouse.vxd is not speaking the same protocol described in osdev at all (nor the Linux driver, nor vmwmouse). It is writing/reading magic stuff from the ps2 controller io port:

LOG: 212882462 ERROR KEYBOARD:Port 64 write with val 82

It tried to write 0x45414552 to port 64(,65,66,67). 0x45414552 is indeed one of the correct magic numbers ( see https://wiki.osdev.org/VMware_tools#Absolute_Mouse_Coordinates ) so it seems that it is speaking a similar protocol but through 32-bit writes/reads to io port 0x64.

[javispedro]

Note also that you can use 3.x vmwmouse.drv in win9x, you just have to edit win9x's system.ini mouse.drv=mouse.drv line to point to it (e.g. mouse.drv=vmwmouse.drv if vmwmouse.drv is on C:\windows\system), then reboot. It will reboot a couple more times after you do that.

[Torinde]

VBMOUSE works in the shell of DOSbox-X MinGW64 SDL2 build from 2023-10-27, but only with "VMware integration"

This means no host cursor and maybe some other missing features. Is it possible to fully support what VirtualBox provides to VBMOUSE? Related dosbox-staging/dosbox-staging#2742

[javispedro]

The builtin int33 driver inside dosbox already implements these features; there shouldn't be any reason to use vbmouse.exe inside dosbox.

You can use vmwmouse.drv in win95 as mentioned above. Is there any problem with it?

vbmouse.drv could in theory be used as alternative, but you'd have to convince dosbox-x to enable int33 driver even when booting a guest os, and I don't remember off hand if you can do that from the config file.

[Torinde]

In Staging (and VirtualBox, I think) vbmouse.exe can provide "host cursor", which looks kind of out-of-place in DOS, but good in Win3x:

In X - I agree the native driver is already quite good - more seamless than vbmouse.exe in Staging where you have to get the Staging window in focus first (e.g. by clicking onto it) and only the clicks afterwards propagate to the DOS program (?), but it shows a "DOS block" cursor:

That's actually good, but I thought maybe a symptom that some other features are missing. Now that you explained nothing else is missing - I agree it's not a big deal.

I haven't tried vmwmouse.drv in win95 yet.

Totally unrelated question: can you please advise how to load in Virtualbox the guest additions mouse driver in NT3.51? I try from Setup - mouse - ...select other driver... and point to the folder on the guest additions CD, but it complains about missing "OEMSETUP.INF" and even if I rename the .INF file to that it still gives the same error... I'm sure it's something obvious I miss, because most questions on the internet are about video, sound, network, etc. and only one is similar to mine (but there's no answer).

[FeralChild64]

@javispedro I know one way to make the int33 mouse driver stop working, at least in DOSBox Staging: using the PIF Editor change the MS-DOS prompt settings to run in a window. Once it runs, the driver stops working. But I don't know yet whether this is a Staging problem, or the int33 driver problem.

If anyone is interested, Staging v0.81rc1 already supports the VirtualBox mouse driver by @javispedro (the case described above does not break it) - feel free to port it to DOSBox X if you wish.
But I haven't tested the support with Windows 9x yet, and there are some problems with VirtualBox DOS mouse driver (VBMOUSE.EXE) which I still didn't investigate. In VMware mode the VBMOUSE.EXE works correctly on Staging.

For me the biggest drawback of the Windows 3.1 VirtualBox mouse driver is that it does not support the wheel like the int33 driver does.

[javispedro]

@javispedro I know one way to make the int33 mouse driver stop working, at least in DOSBox Staging: using the PIF Editor change the MS-DOS prompt settings to run in a window. Once it runs, the driver stops working. But I don't know yet whether this is a Staging problem, or the int33 driver problem

Yes this is a problem with the way the builtin int33 driver is implemented in all DOSBox variants I know of: they store their status in memory "outside" of guest memory, so Windows is unable to save/restore the int33 driver status when switching between DOS VMs. E.g. if you have two DOS boxes A and B and in this order both start using the mouse (through the int33 driver) , even after you move the focus back to A the int33 driver will still call B's callback, so A's mouse will appear to freeze (or even crash).
Using vbmouse.drv exacerbates this problem since the main VM will also be using the int33 driver.

The proper solution would be to at least store the current int33 callback address in guest memory so that Windows could page it. Maybe there could be some Windows-specific workaround where DOSBox remembers a different callback address for each Windows VM, hooking some interrupt to detect focus change. Or alternatively use a native DOS mouse driver, like msmouse or vbmouse.exe (both have the hooks for this, and in addition they also allow mouse use in windowed DOS boxes).

For me the biggest drawback of the Windows 3.1 VirtualBox mouse driver is that it does not support the wheel like the int33 driver does.

It does work in real mode. It won't work in standard/enhanced mode.
Just had a discussion about this topic at https://www.vogons.org/viewtopic.php?p=1218924#p1218924

The problem is that "native" wheel usage through the PS/2 protocol requires a patch to VKD.386. The builtin int33 driver is not subject to this issue since it doesn't use the PS/2 protocol but communicates "directly" with the host mouse. The VirtualBox protocol is subject to the same issue since wheel information is transmitted through PS/2. The VMware protocol should not have this issue, though, since wheel information is transmitted through the magic backdoor.

[FeralChild64]

@javispedro OK, thanks for the info. I'll try to move all the data to guest memory, we'll see if the situation improves.

[FeralChild64]

The proper solution would be to at least store the current int33 callback address in guest memory so that Windows could page it

From my first test - we need to store the whole driver state in guest memory. Otherwise the DOSBox INT33 code (the "instance" your Windows driver talks to) thinks we have switched to text mode and the guest code didn't ask for mouse support (since INT33 function 0x00 is called when opening the command prompt).

[FeralChild64]

I have moved all the driver variables to the guest RAM (in DOSBox Staging), using DOS_GetMemory to allocate memory block, but it seems this is not enough. Windows 3.1x probably does not page everything - I guess I'll have to simulate the existence of a TSR, with a normal MCB block.

[javispedro]

Windows 3.1x probably does not page everything - I guess I'll have to simulate the existence of a TSR, with a normal MCB block.

Looking a bit more into it, it may be a bit more involved indeed. Windows specifically targets the mouse TSR. It does so by looking at the segment of the current int33h ISR, and checking to see if that segment starts with an MCB. If so, it will register that segment as requiring "paging" (instancing).
You can see this logic in vad/int33.asm in the DDK, Get_Mouse_Instance .

I am not sure how easy that is simulated from DOSBox. Alternatively, you can skip the heuristic and directly register the corresponding memory region with Windows, by hooking int2f during win startup. See the Win386_Startup_Info_Struc help in the Windows DDK. I was doing that in vbmouse, right here: https://git.javispedro.com/cgit/vbados.git/tree/mousetsr.c?id=4091173cceea8f2c3b0cdbc19a1adb6bd87c0a94#n1413 (since it is required to hook the interrupt anyway to get the callouts for the windowed mouse API).

[FeralChild64]

Interrupt 0x2f indeed seems to be a better, less hacky option. Thanks!

[FeralChild64]

Either I did something wrongly, or Windows does some sanity check of addresses passed via the win386_startup / win386_instance structures. The solution probably won't be available quickly - currently I have very little time for such development.

[joncampbell123]

Perhaps the int33 option in dosbox.conf needs a corresponding "int33 fake mcb" option for this reason.

It would be like the fake MCB blocks that DOSBox SVN allocates in lower memory below 64KB to help avoid some game crashes.

It's not the first Windows-specific hack. The IDE "fake v86 io" stuff was added because of the way that Windows 95 auto detects which INT 13h drive corresponds to which IDE controller.

[FeralChild64]

This, unfortunately, will have to wait. I can think of two ways to simulate the TSR in Staging, but both would require changes to the mechanisms for which we already have PRs waiting to be reviewed and merged - I don't want to create hard to resolve conflicts. And these PRs won't be reviewed and merged until Staging 0.81 is released. Not to mention I currently spend most of my time on testing the upcoming release...