mbsystem wrote on 2024-05-20, 14:33:

Could you do an update for the safe mode in case it is not possible to load the DOS driver ?

Can you elaborate? In safe mode it won't load the drv either, as it will ignore your system.ini .

In safe mode windows load system.cb if present (not system.ini) .
Example:
...
[boot]
mouse.drv=mouse.drv
*DisplayFallback=0
386grabber=vgadib.3gr
display.drv=vbemp.drv

[386Enh]
display=vbe.vxd
...

Are you saying you have edited system.cb to force-load vbmouse.drv in safe mode ? .... why ?
The .drv can't spawn the .exe , by the time the .drv is loaded it's too late for a global TSR to load.

Yes, vbmouse.drv not work in safe mode, but mouse.drv seems to work a bit.
The only solution I found in safe mode is to use NumpadMouse06c.

Another alternative for your case is to use the older vbmouse, which was "standalone" and doesn't require the DOS driver .
I kept it separately archived as now I remember someone was using it for win9x : https://git.javispedro.com/cgit/vbmouse.git/about/ .
Here is a floppy image https://depot.javispedro.com/vbox/vbmouse1.flp .

mbsystem wrote on 2024-05-20, 17:10:

The only solution I found in safe mode is to use NumpadMouse06c.

I still don't understand what is that you want to do. Can you elaborate? Why are you changing system.cb _at all_? Why do you want a custom driver in safe mode ?

I like things to work, even safe mode. For me, your old driver no longer works on the latest version of VirtualBox (even blocks safe mode from loading)

Your vbados_0_70 alpha work normaly in normal mode. I see no difference with 0.67.

Thanks again for your work.

mbsystem wrote on 2024-05-20, 18:28:

I like things to work, even safe mode.

Are you saying that the normal Win9x mouse driver doesn't "work" ? That would be a much more important problem to diagnose. What hardware do you have ? What does "not work" mean ?
I believe it completely defeats the purpose of safe mode if you just copy your regular setup & drivers to it.
Not to mention there may be some hardcoded behavior in safe mode that you can't disable.
Maybe you want hardware profiles?

I can't recommending messing with safe mode. vbmouse.drv always requires the old-style mouse drivers (with vkd, vmd and without vmouse) and I'm not sure if safe mode will allow that. EDIT: As seen below, it apparently does, though.

mbsystem wrote on 2024-05-20, 18:28:

For me, your old driver no longer works on the latest version of VirtualBox (even blocks safe mode from loading)

For the sake of avoiding roundtrips, can you provide details every time you say something works or doesn't work ? At this point I'm not even sure which OS are you using.
What did you do? How do you see it doesn't work? Instructions to reproduce, etc.
I just tested right now on VirtualBox 7.0.18 and a fresh Win95 osr2 using 9xsetup.inf -> right click -> install method and it works for me.
I also tried safe mode: all I had to is copy system.ini system.cb.
Don't understand why you'd want to do that, but it works.

mbsystem wrote on 2024-05-20, 18:28:

Your vbados_0_70 alpha work normaly in normal mode. I see no difference with 0.67.

This is in progress work for 5 button mouse and horizontal wheel support. I only tested it in win3.11 so far.
There was some interest in extending the DOS int33 API to support 2nd wheel, so I'm proposing a spec -- see https://github.com/joncampbell123/dosbox-x/is … ment-2119335773
0.70alpha implements this spec.

it's windows 98 se afterwards I don't really know. You can send me a VirtualBox hardware profile (.vbox) if you want. Thanks.

Dunno if it will be useful, but I have implemented a extension to the int33 mouse API to support 4th and 5th mouse buttons and a 2nd wheel, and implemented a alpha version of VBMOUSE that exposes this API (working for PS/2 mouse and VirtualBox):
https://gist.github.com/javispedro/cef7fd7e49 … 78433b263f36c21
https://depot.javispedro.com/vbox/vbados/rele … _0_70_alpha.zip

Obviously no programs support it other than my toy test program.
If anyone is developing DOS software and wants to use extra mouse buttons or wheels, be sure to check it out , and give me a ping 😀

Hello, very cool project.
I know that it's not main aim of this driver, but I tried running your windows driver on real PC under real mode Windows 3.00a and encountered some problems with it. Recently I found that real mode windows can be easily run under Windows 9x DOS box. So I started experiments with some Windows versions inside Windows 98SE. There is only one problem that every "Windows in Windows" have - mouse don't work. This is caused by Windows 9x driver which takes full control over hardware not allowing any other similar driver to work. In DOS Window there is only posibility to use int 33h interface with mouse driver provided by Windows 9x VxD. So I found some drivers that use DOS int 33h passthrough to Windows. Your driver was the best candidate, because it was the only one to work in real mode Win 3.0. I found that only versions shipped with vbados package works. The standalone vbmouse version starts, but mouse don't move. In vbados I just load VBMOUSE.DRV to SYSTEM.INI and don't use VBMOUSE.EXE, because it can't be loaded on 9x (Windows just ignores it, still using it's own int 33h implementation), but vbmouse.drv seems to accept that fact. The only problem is that it causes "insufficient memory error" on some programs, despite having still about 400k free.

Not all programs are affected. The ones I found that display this error are for example windows setup program, calendar, PIF editor, Word 1.0 for Windows. They are always the same. Rest work normally, even games like soltaire and reversi work stable without any slowdowns. I tried to compile this driver on my own with disabled all unnecerssary functions like scrolling, VBox integration features, even 386 enhancements, leaving only bare driver, but it still causes the same error. I also checked it with disabled initialization in code (I set flags.enabled to true without initialization) and with driver not functioning only loaded in memory it still causes errors. Removing driver from system.ini solves problem, so it's definitely something with it. I also checked it in pure DOS without loading Windows (with all VBMOUSE.EXE, CTMOUSE.EXE and standard MS MOUSE.EXE) and still the same. Maybe it's problem with driver memory management?
On the other hand I checked this driver in WfW 3.11 standard mode loaded in Windows 98 DOS box with some beta Windows 95 files. Normally it uses special Microsoft driver dualmous.drv but I checked your driver and it worked even better, not causing any GPF's (like dualmous.drv) or slowdowns (like i33mouse.drv which I also tried). So from my experience the problem exist only in real mode Windows 3.0. I know that this driver wasn't aimed at real hardware, but it has very big potential, being close to perfect running in such unstable and crazy environment. Have you any ideas what could be wrong?

ks4 wrote on 2024-07-21, 20:48:

This is caused by Windows 9x driver which takes full control over hardware not allowing any other similar driver to work. In DOS Window there is only posibility to use int 33h interface with mouse driver provided by Windows 9x VxD.

Interesting, I didn't know that. Win3.x virtualizes the PS/2 hardware so inside DOS boxes programs can read the PS/2 mouse as normal, it's interesting they dropped that in 9x.
You can make w9x fall back to the w3.x keyboard stack (vkd, vmd) if you install a w3x mouse driver in 9x. (e.g. just put vbmouse.drv in 9x's system.ini 😀 ).
I have verified that this makes 9x go back to 3x-like behavior: it will stop providing its own int33 driver in DOS boxes and will allow (virtualized) PS/2 access, so classic DOS mouse drivers will work....... and perhaps including win3 in real mode with its standard PS/2 driver ? Maybe worth a try...

To clarify, the win3x behavior (as well as the behavior in win9x with the 3x mouse stack) is:
a) if the DOS VM is fullscreen, then it gets unfiltered access to the PS/2 mouse data
b) if the DOS VM is windowed, then it doesn't get any PS/2 mouse data. There's a series of hooks that a int33 driver (in the DOS VM) can implement to get mouse events from windows itself, and ms's mouse.com (as well as vbmouse.exe) implements them, so DOS programs using such int33 driver can continue to receive mouse events.

ks4 wrote on 2024-07-21, 20:48:

The only problem is that it causes "insufficient memory error" on some programs, despite having still about 400k free.

The issue seems to be that vbmouse.drv calls LocalInit (as part of watcom's DllMain; not my code), and this makes Win3.0 unhappy for some reason.
You can manually hack the NE header to set the "Local Heap Size" to 0 and this will prevent the Watcom runtime from calling LocalInit. This will avoid the "out of memory" messages, but it also seems to cause the driver to crash, and I have not figured out why yet. Maybe the runtime does use the heap. That would explain why it is built with a non-zero local heap size even though the documentation says the default should be 0.... this requires some long look at the watcom runtime and I haven't had the time.