Thank you very much! 😀👍

Hey, cool program! Out of curiosity: Is there anyway to add polling rate to this ala PS2RATE for Win9X? Makes the mouse feel smoother at the cost of some CPU (i presume?). Great for games 😀

FioGermi wrote on 2022-04-16, 22:58:

Hey, cool program! Out of curiosity: Is there anyway to add polling rate to this ala PS2RATE for Win9X? Makes the mouse feel smoother at the cost of some CPU (i presume?). Great for games 😀

Yeah it's trivial . I'm currently using 80Hz as default ( right here https://git.javispedro.com/cgit/vbados.git/tr … mousetsr.c#n989 ) but technically it can go as far as 200Hz
I'm attaching a build with default set to 6 aka 200Hz (only change).

Personally I found a significant difference between 40-60hz (windows 3.x seems to use 40Hz as default, and it feels sluggish after trying 60Hz), but no difference for anything >= 60Hz.
That's why I just left it at 80Hz.
No idea about the CPU usage, but I guess my mouse drawing routines are kinda slow -- I'm sure cutemouse is miles better in performance.
Should mention that it requires a 386 as a bare minimum due to use of 32-bit registers, but I am not sure what performance to expect on a 386 😀

Btw just looked : cutemouse uses 100hz as far as I can see. A comparison might be in order 😀
Also note: on a VM the sampling rate is basically the same as the host, I can't change that . was thinking real hardware 😀

I actually got the PS/2 scroll wheel to work on real hw (my T5710) under Windows 3.11 in protected mode 😀
Would have made a video, but it would be boring...

I needed to patch VKD.386 , and I'm not sure if I can redistribute it (even though it actually comes as sample code in the Windows 3.1 DDK).
So I'm attaching a patch to the VKD sources:

It also increases the sampling rate to 60Hz from 40Hz 😀

You'd also need the latest vbmouse.exe version which I just uploaded.

It is really a very stupid patch that will break any non-wheel aware mouse driver.
It simply makes VKD set the mouse to "Intellimouse"/4-byte packet mode unconditionally at startup, returns the wheel mouse device ID whenever asked, and removes all the packet segmentation code . Meaning overflow conditions may not be handled gracefully, dropping bytes randomly, so the DOS driver may need some synchronization code itself. However the code was not that functional to begin with, so not much of value is lost.
The 4-byte packets is what breaks most drivers, but if you use vbmouse as both DOS & Win driver, this shouldn't be a problem either.

Hello Javispedro1,

I just installed MSDOS on VirtualBox with so that I can run my old TangoPCB Series II+ on my Win10 machine. I installed your VBMOUSE and got it working (I only had to turn the integration off). However since the
highest resolution driver I can use is VESA1024 I find that the Mouse resolution is way too "speedy" and a small movement of the Mouse moves the cursor way too much. Is there any way to adjust this? When I am running Win7 in VirtualBox or Win10 natively the same mouse is perfectly fine.

Thank you so very much for creating this!

Sam
W3OHM

sam.reaves@gmail.com wrote on 2022-10-08, 00:52:

I just installed MSDOS on VirtualBox with so that I can run my old TangoPCB Series II+ on my Win10 machine. I installed your VBMOUSE and got it working (I only had to turn the integration off). However since the
highest resolution driver I can use is VESA1024 I find that the Mouse resolution is way too "speedy" and a small movement of the Mouse moves the cursor way too much. Is there any way to adjust this?

Hum, if you have to turn the integration off, that kind of defeats the purpose of using vbmouse in the first place, since there will be little advantage over any other DOS mouse driver.

So... why did you have to turn it off? was it at least working inside MS edit? and then what is the behavior inside TangoPCB ?
For example it the mouse inside TangoPCB just "wiggles" a few pixels to the right but nowhere else whenever vbmouse+integration is enabled, then it means TangoPCB is reading the PS/2 port directly, ignoring the DOS mouse driver.
Or if it just moves at a different speed than the "host" mouse pointer then it likely means TangoPCB is reading the relative positions of the mouse and doing its own acceleration/sensitivity calculation from it.
And if it the mouse cursor just moves inside a smaller subrectangle of the screen and you cannot move outside of it, then it means the calculations for the current screen mode coordinates are wrong 😀 , which is likely in svga/vesa modes. Does it work in vga modes ?

If you are OK to go with integration disabled (i.e. you will be forced to capture/release the mouse from VirtualBox), then you could also try some other mouse driver like CuteMouse or MS Mouse. There should be no difference other than you lose the integration, for the programs that support it that is. So it would be nice to compare if they also have a speed issue "out of the box". MS Mouse at least also allows you to set the sensitivity (but I think the program may still override, IIRC).

It would be interesting to support integration in programs like this in vbmouse (assuming it doesn't work 😀 ), but since these programs are difficult to find...
If necessary I could put a user-controllable speed multiplier in vbmouse, but I would prefer to minimize the number of compatibility-related toggles.

This is great! I have been looking for something like this for a while. Only issue I have come across in my use case , when I am in Borland C++ 3.1 IDE, if I compile and run my program the machine will crash if vbmouse.exe is loaded.... even just a printf hello world will crash. Exiting the IDE and running the executable is fine, just using the RUN from inside the IDE in conjunction with the mouse driver. Strange.

Glad to hear!

yyzkevin wrote on 2022-12-10, 07:38:

Only issue I have come across in my use case , when I am in Borland C++ 3.1 IDE, if I compile and run my program the machine will crash if vbmouse.exe is loaded.... even just a printf hello world will crash. Exiting the IDE and running the executable is fine, just using the RUN from inside the IDE in conjunction with the mouse driver. Strange.

I found this issue and think I have fixed it in the new 0.64.
The issue was that Borland is trying to save/restore the mouse state when you run a program from the IDE, and my driver was asking for too much memory. Borland seems to only allocate a 1K buffer for this no matter what, but I was using 1.5K, so I guess I was overwriting some of Borland's data.
With the fixed version I'm no longer preserving some of the VirtualBox data that didn't really need to be preserved, so that I only need 0.5K of the buffer provided by the IDE. This seems to fix the issue.

Great project! I would never have taken on "guest tools for DOS" but I'm happy you are 😀 I'm curious about your TSR for shared folders, where can I read more about that and how it works? Does it use the DOS redirection interfaces?

What a fast update! So it does not crash now which is amazing. What I do notice is, any time there is a dialog in the ide/turbovision, if the new dialog covers the current positon of the mouse cursor, if you move the mouse while the dialog is still open, it restores the character to the display from before the dialog opened.

javispedro1 wrote on 2022-12-10, 14:58:

Glad to hear! […]
Show full quote

Glad to hear!

yyzkevin wrote on 2022-12-10, 07:38:

Only issue I have come across in my use case , when I am in Borland C++ 3.1 IDE, if I compile and run my program the machine will crash if vbmouse.exe is loaded.... even just a printf hello world will crash. Exiting the IDE and running the executable is fine, just using the RUN from inside the IDE in conjunction with the mouse driver. Strange.

I found this issue and think I have fixed it in the new 0.64.
The issue was that Borland is trying to save/restore the mouse state when you run a program from the IDE, and my driver was asking for too much memory. Borland seems to only allocate a 1K buffer for this no matter what, but I was using 1.5K, so I guess I was overwriting some of Borland's data.
With the fixed version I'm no longer preserving some of the VirtualBox data that didn't really need to be preserved, so that I only need 0.5K of the buffer provided by the IDE. This seems to fix the issue.

MobyGamer wrote on 2022-12-10, 18:40:

Great project! I would never have taken on "guest tools for DOS" but I'm happy you are 😀 I'm curious about your TSR for shared folders, where can I read more about that and how it works? Does it use the DOS redirection interfaces?

There is an about page for the entire project with instructions -- https://git.javispedro.com/cgit/vbados.git/about/ -- I have written some details about the complicated parts, about not much details about the redirector part.
Yes, it is using the DOS redirection interfaces. When I started, I couldn't find any examples of either a mouse driver or redirector written in C, but it turns out there were some, like https://github.com/eduardocasino/vmsmount for VMware mounts (my TSR only does VirtualBox shared folders).

yyzkevin wrote on 2022-12-10, 22:05:

What a fast update! So it does not crash now which is amazing. What I do notice is, any time there is a dialog in the ide/turbovision, if the new dialog covers the current positon of the mouse cursor, if you move the mouse while the dialog is still open, it restores the character to the display from before the dialog opened.

You are not using VirtualBox then? In VirtualBox the cursor is drawn by the host so this shouldn't happen. The fallback code which renders the mouse cursor in DOS itself is not that good. I'll take a look.
I found the issue, some incompatibility with the hide/show cursor API. It should be much better with 0.65.

duplicate - delete please (sorry)

duplicate - delete please (sorry)

Okay looks perfect so far in Borland C++ !

I am playing with this on a small web interface I have been working on to a legacy system. Previously I would capture the mouse to the canvas area so only the relative movements were sent to the vm in the cloud, but this had a lot of issues and of course pressing esc was not an option.

If you wanted to check it out, the login name is guest. It is not stable it is a work in progress, but this is using your vbmouse driver. In windows 3.1 (enhanced mode) I am using a different mouse driver I cannot remember the name this second.

https://ipx.network/terminal

yyzkevin wrote on 2022-12-11, 22:17:

If you wanted to check it out, the login name is guest. It is not stable it is a work in progress, but this is using your vbmouse driver.
https://ipx.network/terminal

Cool! Do you have a page/thread for this?
I was envisioning browser-based qemu.js emulators as yet another usecase, since they really benefit from mouse integration. I am guessing this is rather using vmware or qemu (with vmware integration), and remoting into it, right? Maybe there's a way to force capture/release the mouse for these games that still need to capture it, like Descent or Doom. Running "vbmouse integ off" temporarily disables the integration, and on VirtualBox/VMware this means the cursor goes back to being captured, but I don't know how to propagate this back to the browser so that it also captures the mouse...

Just learned about this today (thank you, yyzkevin for the tip!). I see several other familiar faces in the thread here too 😀

Now I am wondering how difficult it would be to nominally do mouse integration for Win9X.. that would be awesome to have! I might have to look into it if someone isn't already working on it!

RetroTechChris wrote on 2022-12-20, 06:10:

Now I am wondering how difficult it would be to nominally do mouse integration for Win9X.. that would be awesome to have! I might have to look into it if someone isn't already working on it!

This already works as-is for 9x, you just have to install it manually , i.e. by loading VBMOUSE in autoexec.bat and then editing system.ini 's mouse.drv= line to point to vbmouse.drv.
Right now the only limitation is that there's no wheel support (like in all Windows 386 Enhanced Mode variants, albeit I have a working patch for 3.x).

Would that be for VirtualBox too?

I'm not sure of the benefits of a "native" 32-bit 9x driver. I have some unpublished work that I stopped because using the 16-bit driver seems to work as well.
Note that starting win98 you can already have mouse integration with VirtualBox via "standard" USB tablet and it works rather well, so this would be for non-USB win95 only...
And win95's 32-bit side has some bugs regarding absolute mouse integration, e.g. https://www.betaarchive.com/wiki/index.php?ti … _Archive/139292 , which kind of force you to override the 16-bit mouse.drv anyway .

From my side, I'm currently trying to fix the wheel situation with win3.x enhanced mode, which does require a 32-bit driver (same applies to win9x).
The problem with the wheel is that Windows helpfully "virtualizes" the PS/2 controller and mouse , so that multiple DOS VMs and Windows' mouse.drv itself can share control of the PS/2 mouse even if they are using different drivers. However, this virtualization has bugs ( http://www.os2museum.com/wp/jumpy-ps2-mouse-i … de-windows-3-x/ ) , and also prevents VMs from configuring the mouse so that it sends wheel information.
Result: no wheel, even if the underlying DOS/Windows drivers are capable of supporting it.

A couple messages ago, I posted a simple patch for VKD.386 that removes this behavior but this is far from ideal since I am not sure I can redistribute a patched VKD binary (and it breaks other DOS mouse drivers).

So what I'm trying to do instead is to write a new VXD that just hooks/overrides the broken parts of VKD, which I'm already finding a bit messy since I need to talk with the PS/2 hardware without VKD noticing at all, and either reinitialize the mouse on every VM switch or further virtualize it somehow so that each VM finds the mouse in the state it left it (wheel or not).
Also finding issues with Watcom's VxD support in the meanwhile ... https://github.com/open-watcom/open-watcom-v2/pull/1015

Anyway. I'm hoping the above experiences clear the way for more more VxDs, I specially look forward to implementing shared folders in win9x , but I'll probably also resurrect the 9x mouse integration then (so as to have only one driver calling into VirtualBox rather than two). I'll take me a lot of time though -- weekends development only.

There remains a slight problem with vbmouse in VirtualBox, it is when calling some windows programs from a dos command prompt. At this point the cursor is positioned again at the top left of VirtualBox.

mbsystem wrote on 2022-12-22, 04:10:

There remains a slight problem with vbmouse in VirtualBox, it is when calling some windows programs from a dos command prompt. At this point the cursor is positioned again at the top left of VirtualBox.

Do you have some examples? and which windows 3.x or 95.