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.
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.
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.
A bit late but I finally picked up where I left off and found the cause for this: the data segment was not fixed!
The Watcom runtime was calling LocalInit on it which I guess ends up locking it, so nothing crashed, but W3.0 didn't like this situation anyway and thus the error messages.
I have fixed it in git d27caefd , will be part of the 0.7x series.
I have some WIP changes going on, such as support for the horizontal scroll wheel as well as trivial serial mouse support (mostly for the fun and so that I can test the driver on more real hw), that I would like to polish a bit more before any release.
First of all, thanks Javis Pedro, for vbados/vbmouse, great job!
Wanted to report an observation regarding VBSF that might be worth documenting for other users.
My Setup
Guest: Windows 98
VBSF loaded via AUTOEXEC.BAT
Host: Linux, VirtualBox 7.2
VBSF 0.70 alpha
Symptom When a VirtualBox shared folder contains an underscore or accented characters — e.g. /home/user/Pasta_compartilhada — running DIR on the mounted drive would:
Show the volume label and . / .. entries correctly
Then fail with a "General failure" error (INT 24h) partway through the listing
This happened consistently, in both a real MS-DOS mode boot (Restart in MS-DOS mode) and inside Windows 98's DOS box — so it's not a Windows 32-bit caching issue, it reproduces in plain DOS too.
New files/folders added on the host afterward never appeared — the listing seemed "stuck", though the real cause turned out to be this failure rather than caching.
Isolation I initially suspected it was about filenames inside the share containing accents (I'm in a Portuguese/Brazilian locale, so I tested ç, ã in file/folder names). That was NOT the issue — files/folders with non-ASCII names, on a Linux host, inside the share work fine.
The actual trigger is the share directory name itself. Renaming the shared folder definition in Linux from /home/user/Pasta_compartilhada to /home/user/Pasta (plain ASCII, no underscore, no accents) immediately fixed it — DIR started updating correctly and reflecting host-side changes in real time.
I also tested _ alone (no accented characters) and it was enough to trigger the failure — so it's not limited to accents/Unicode, ASCII underscore in the share name also breaks it.
Also: Loading VBSF via AUTOEXEC.BAT (LH C:\Vba\Vbsf.exe, before Windows 98 loads) causes the shared drive to also show up correctly in Windows Explorer, not just in DOS boxes. If I run the VBSF after Windows 98 loads, I can only see the folder in the DOS window.
Might be worth adding a note on your website warning all of this.
Thanks again for the great work on this project!
PS: Apologies if this isn't the ideal thread — I couldn't find a dedicated one for VBSF specifically, and since it ships together with vbmouse as part of the same vbados package, I hope it's alright to post here. Please point me to a better thread if one exists, and feel free to move this post if needed.
(VBSF is, for the record, a VirtualBox shared folders client for DOS that I'm putting in the same package as vbmouse, so I suppose using this thread is fine, but I am happy to create a separate one if it pains anyone).
Reizend wrote on Yesterday, 18:35:The actual trigger is the share directory name itself. Renaming the shared folder definition in Linux from /home/user/Pasta_compartilhada to /home/user/Pasta (plain ASCII, no underscore, no accents) immediately fixed it — DIR started updating correctly and reflecting host-side changes in real time.
I am Spanish so most of directories in my host have accents, even the directory where I store VBSF itself has accents ! 😀
I do not think the directory in the host could influence in any way the behavior of the guest DOS, it should not even be visible to DOS at all.
So I'm not sure what is going on .
I tried to create directory on the host named "Pasta_compartilhada" and could not reproduce the issue, also not in Windows 98's DOS version.
Does it have to be in the host folder path ?
Can you check if the issue happens for a short folder name when you put the special name in the Folder name / "Nombre de la carpeta" / "Nome da pasta" field ? Or is it when you put in the Mount Point / "Ponto de montar" field ?
The "Folder name" goes into the disk label I show to DOS, so maybe that causes the issue. But -- as you can see from the screenshot, I could not reproduce that . Do I need to put more files in folder ?
Or is it possible that the issue is caused by VBox itself? Have you tried using a different guest with the official drivers and see what happens ?
Reizend wrote on Yesterday, 18:35:Also: Loading VBSF via AUTOEXEC.BAT (LH C:\Vba\Vbsf.exe, before Windows 98 loads) causes the shared drive to also show up correctly in Windows Explorer, not just in DOS boxes. If I run the VBSF after Windows 98 loads, I can only see the folder in the DOS window.
This is normal Windows behavior, there was an interesting article by Raymond Chen very recently: The little-known winstart.bat batch file. The table at the end mentions that if you load a TSR from a DOS box ("VM" in Win3.x/9x lingo) , it only works in that DOS box; if you load it from Winstart.bat, it works only in Windows but not DOS boxes, and if you load it from Autoexec.bat, it works on both Windows and DOS boxes.