Example: The last free ShellEx with Execute option in 98 SE with KernelEx (for bypass GetVersionExA)
https://www.softspecialists.com/utilities/smallutilities
The problem is only with dos prompt window ( 16 bit subsystem problem in a 32 bits windows may be ) if the focus is on dos prompt window, not if the mouse is elsewhere in windows 98 desktop or above other window 32 bits.

mbsystem wrote on 2022-12-25, 22:36:

Example: The last free ShellEx with Execute option in 98 SE with KernelEx (for bypass GetVersionExA)
https://www.softspecialists.com/utilities/smallutilities
The problem is only with dos prompt window ( 16 bit subsystem problem in a 32 bits windows may be ) if the focus is on dos prompt window, not if the mouse is elsewhere in windows 98 desktop or above other window 32 bits.

I am still not sure what to do in order to reproduce the problem you mention.
However, I have reproduced another problem when i used the display driver from https://www.os2museum.com/wp/windows-9x-video-minidriver-hd/ under win95 . In this case, when I open a fullscreen DOS box and then exit it (returning to Windows), the mouse is "stuck" inside a very small box in the top-left corner of the screen .
It seems that with this driver the BIOS video mode is not preserved when returning to Windows, which causes VBMOUSE to reinitialize itself as if the video mode had changed.
I have added a workaround in the latest 0.66 release that restores the full range when returning from a fullscreen DOS box.
Hopefully this also fixes that issue.

Problem perfectly solved under Windows. Thanks! (I use the VBEMP.DRV of 02.14.2014 in 1024x768 x24 bits only.)

Cool project, thank you.

I am mostly interested in VBSF, but the problem below should be the same for the other utils.

In default mode, you try to move up into UMB memory, which absolutely super.

Unfortunately worlds best debugger, SoftICE provides UMB memory (which is good), but doesn't provide
VDS (virtual DMA services). now - by default - your driver and it's communication block are moved to
UMB, but the virtual address is NOT a linear address.

my solution to this problem is: don't move to UMB if SoftICE is detected, as in

nt SoftICE_present(void)
{
union REGS ir;

ir.h.ah = 0x09; // S-ICE

ir.x.si = ('F'<< 😎 | 'G'; // that's eight, not funny
ir.x.di = ('J'<< 😎 | 'M'; // that's eight, not funny

ir.h.al = 0x12; // get breakpoint information

ir.x.dx = 0xffff;
ir.x.bx = 0xffff;
int86(0x03,&ir,&ir);

return ir.x.dx != 0xffff && ir.x.bx != 0xffff;
}


int main(int argc, const char *argv[])
{
LPTSRDATA data = get_tsr_data(true);
...

printf(_(1, 9, "\nVBSharedFolders %x.%x\n"), VERSION_MAJOR, VERSION_MINOR);

if (high && SoftICE_present()) {
printf("SoftICE detected, loading low\n");
high = false;
}
...

After trying out vbados in a new installation of Windows for Workgroups, found a problem.

On exit of Windows back to DOS, touching the mouse causes the message "Divide Overflow" to appear, followed by the computer freezing.
Therefore I was forced to remove vbados.

Normally you don't need to remove vbados. Any little, non-resident tool such "nomouse.com" running right back should prevent the problem.

Robbbert wrote on 2023-12-15, 08:11:

After trying out vbados in a new installation of Windows for Workgroups, found a problem.

On exit of Windows back to DOS, touching the mouse causes the message "Divide Overflow" to appear, followed by the computer freezing.
Therefore I was forced to remove vbados.

Note that I designed & use VBADOS almost exclusively with WFW 3.11 , and I have not seen that, so I need some help to reproduce this issue.

Does this happen when you load VBSF? Or VBMOUSE? Or both?
Which version of Windows? Is it running in 386 enhanced mode, or standard mode? (See Help -> About box)
VirtualBox? VMware? DOSBox? Real hardware? Do you have set up mouse integration in VirtualBox? And did it work while running ?
Do you use also use the 3.x mouse driver, VBMOUSE.DRV? Do you use some other mouse driver? Or a patched VKD.386 ?
Do you have to do something special in Windows to reproduce the issue?
Is some DOS mouse-related TSR running at the same time?
How does the "Divide Overflow" message look like ? Is it EMM386 printing it ? The normal DOS ISR ?

EDIT: assuming this is real hardware (after having seen the mouse wheel thread), then I recommend this: https://jeffpar.github.io/kbarchive/kb/082/Q82763/

Note however that to use the mouse wheel in real hardware you need to extract and patch VKD.386. This is because the original VKD.386 prevents all mouse drivers from accessing the PS/2 hardware directly.
One way is to build the sample VKD from the Windows 3.1 DDK . I have a patch for for the for VKD.ASM from the DDK at https://depot.javispedro.com/vbox/vbados/wheelvkd_v1.patch .
I was trying to find a way to avoid having to do that (since it's not trivial to build, and it's not clear if I can redistribute DDK samples) , but I lost interest as the wheel works in DOSBox, etc. without this patch .

I'm looking for a windows mouse driver that supports the mouse wheel on WFW 3.11, via the PS/2 port . If vbados can't do this then we can stop here.

I don't want a DOS driver, just a windows one, so I tried a whole bunch of drivers that I found both on the net and in my own collection of floppies. Some even installed. Some even worked. But none of them supported the wheel, even the ones that said they did. VBADOS was the last choice because it required a DOS component.

In answer to your questions, it is real hardware. The same hardware supports pure DOS and all Windows versions up to and including W2K. The scroll wheel works on Win95/NT4 (with an extra driver), and Win98, win98se and W2K.

I'm using the standard *vkd (whatever file that is), I don't know anything about modifying it nor I am going to do so. I'm happy to try a pre-modified one though.

So when I came to test vbados I used the oemsetup.inf to get the driver into windows (I assume it used vbmouse.drv), however upon restarting windows it crashed at start and that's when I found that it required the dos component. So I loaded VBMOUSE.EXE in dos and tried Windows again, which started up this time. But still no scrolling. On exit of Windows I happened to bump the mouse and the Divide Overflow happened and the computer froze. I had to power it off/on. I tried a couple more times and it's 100% reproducible. At this point I gave up with it and switched back to the standard mouse driver, and removed vbados files from the system.

No other mouse driver gave this problem so I can be sure it's exclusive to vbados.

I don't know what VBSF does, never tried it. The only mouse-related TSR is VBMOUSE.EXE because it's required. Not sure how to answer what the message looks like, no idea where it comes from. It just says Divide Overflow.

Not sure if I should do that Q82763 thing, as no other mouse driver causes the problem - only vbados.

The last point is perhaps one of the other drivers actually did support the wheel, but it never showed in the control panel mouse applet as an option, or in any of the apps that are installed in windows.

So, not sure if you can help me or not.

Robbbert wrote on 2023-12-16, 04:04:

I'm looking for a windows mouse driver that supports the mouse wheel on WFW 3.11, via the PS/2 port . If vbados can't do this th […]
Show full quote

I'm looking for a windows mouse driver that supports the mouse wheel on WFW 3.11, via the PS/2 port . If vbados can't do this then we can stop here.

I don't want a DOS driver, just a windows one, so I tried a whole bunch of drivers that I found both on the net and in my own collection of floppies. Some even installed. Some even worked. But none of them supported the wheel, even the ones that said they did. VBADOS was the last choice because it required a DOS component.

In answer to your questions, it is real hardware. The same hardware supports pure DOS and all Windows versions up to and including W2K. The scroll wheel works on Win95/NT4 (with an extra driver), and Win98, win98se and W2K.

I'm using the standard *vkd (whatever file that is), I don't know anything about modifying it nor I am going to do so. I'm happy to try a pre-modified one though.

So when I came to test vbados I used the oemsetup.inf to get the driver into windows (I assume it used vbmouse.drv), however upon restarting windows it crashed at start and that's when I found that it required the dos component. So I loaded VBMOUSE.EXE in dos and tried Windows again, which started up this time. But still no scrolling. On exit of Windows I happened to bump the mouse and the Divide Overflow happened and the computer froze. I had to power it off/on. I tried a couple more times and it's 100% reproducible. At this point I gave up with it and switched back to the standard mouse driver, and removed vbados files from the system.

No other mouse driver gave this problem so I can be sure it's exclusive to vbados.

I don't know what VBSF does, never tried it. The only mouse-related TSR is VBMOUSE.EXE because it's required. Not sure how to answer what the message looks like, no idea where it comes from. It just says Divide Overflow.

Not sure if I should do that Q82763 thing, as no other mouse driver causes the problem - only vbados.

The last point is perhaps one of the other drivers actually did support the wheel, but it never showed in the control panel mouse applet as an option, or in any of the apps that are installed in windows.

So, not sure if you can help me or not.

Have you tried this ? https://archive.org/details/a4tmousedriver

edit: kinda offtopic though. Your question "mousewheel in windows 3.x" should've been its own thread and a quick google on my part found that A4tech driver.
but meh, hope it works.

I did try that driver already, doesn't work.

And the original question already does have its own thread.

Robbbert wrote on 2023-12-16, 04:04:

I'm looking for a windows mouse driver that supports the mouse wheel on WFW 3.11, via the PS/2 port . If vbados can't do this then we can stop here.

To the best of my knowledge, VBADOS is the only one capable for PS/2 , as it implements a bunch of hacks required to do that. You can see a bit of the discussion here -- https://github.com/NattyNarwhal/vmwmouse/issues/5 .

There was also the A4 tech "4D mouse" driver but it seems to work only with its own hardware which I believe is https://store.cwc-group.com/wop35.html

The "standard" wheel messages in Windows date from 96-98ish. Any software older than that will not understand the wheel messages (including ALL 3.x era software) and therefore requires hacks and posting fake scroll messages to support the mouse wheel. VBADOS (specifically vbmouse.drv) is doing these hacks (I use it frequently with CAD/office software on 3.x). Older Intellimouse drivers have similar hacks (mswheel.exe) but they are only for 95 up.

On DOSBox (-X or -staging) you can use the vbmouse.drv file by itself (no need for vbmouse.exe or patched VKD as dosbox itself will act as a magic int33 driver with wheel support) and I suggest you try first DOSBox (-X or -staging) to evaluate if the hacky scroll messages will work with whatever 3.x program it is you want to use. Follow e.g. these instructions https://dosbox-x.com/wiki/Guide%3AInstalling- … driver_option_2

Robbbert wrote on 2023-12-16, 04:04:

I'm using the standard *vkd (whatever file that is), I don't know anything about modifying it nor I am going to do so. I'm happy to try a pre-modified one though.

Well I can't redistribute patched windows binaries, and I'm not sure if I can legally distribute samples from the 3.x DDK either .
So the only way for you right now is to obtain the DDK "somehow" and build the sample VKD. Once you do that, here 's a patch to its source code: https://depot.javispedro.com/vbox/vbados/wheelvkd_v1.patch

You do need the patched VKD if you want to use the scroll wheel under 386 enhanced Windows. Note that Intellimouse drivers for 3.x do a similar patch (to support ball mouse and the like) but I have not seen a way to use the patched VKD from Intellimouse; I need to use my own patch.

Another alternative is to run windows in real mode. Most Windows for Workgroups versions will refuse to do so, albeit 3.0 works and so does VBADOS there.

I'm looking for ideas to simplify that. I was trying a hacky "overlay" driver but it get tiresome as you keep having to fight the builtin VKD for control of the PS/2 device.

Windows' VKD normally tries to do its own parsing of the PS/2 mouse packets so that each VM receives a "correct" stream of packets (i.e. reliable and ordered, even if you switch VMs in the middle of a mouse packet). However it just cannot understand anything wheel related and will destroy Ps/2 mouse packets that are not of standard length. My patch above simply prevents Windows' VKD from doing any framing of the PS/2 mouse packets, so that VKD forwards them "as they come", byte by byte, to the VM. My DOS driver (which will be running even in the system VM) does not care if we receive munged or partial PS/2 packets, so it works just as fine even if Windows does not do any framing. And since Windows is no longer doing the framing, longer PS/2 wheel mouse packets can now be handled as well.

Robbbert wrote on 2023-12-16, 04:04:

Not sure if I should do that Q82763 thing, as no other mouse driver causes the problem - only vbados.

It is also the only driver who will try to negotiate wheel support, even under 386 windows. Please try this option; at worst we'll learn something. If you didn't even launch any mouse-using DOS program between the TSR and Windows, then the TSR wouldn't even have registered the PS/2 callback; meaning the TSR code is not even running when you move the mouse, leaving the PS/2 BIOS as the only potential culprit.

(In fact, maybe you can try running e.g. EDIT after launching the TSR but before starting Windows, so that it actually initializes the PS/2 callback. This may result in different behavior once Windows exits.)

It's not that rare, I have a 99 Thinkpad which needs this option, albeit I have never seen it printing an arithmetic error before.

Robbbert wrote on 2023-12-16, 04:04:

The last point is perhaps one of the other drivers actually did support the wheel, but it never showed in the control panel mouse applet as an option, or in any of the apps that are installed in windows.

"wheel" will never appear in the control panel applet; it was written years before the first wheel mice.

Robbbert wrote on 2023-12-16, 04:04:

So, not sure if you can help me or not.

Erm... I'm not looking to provide free support here. You have to contribute something back (even if it's just testing things which worked/didn't work -- but with some detail to understand why).

Thanks for the feedback.

javispedro1 wrote on 2023-12-16, 13:50:

Well I can't redistribute patched windows binaries, and I'm not sure if I can legally distribute samples from the 3.x DDK either .
So the only way for you right now is to obtain the DDK "somehow" and build the sample VKD. Once you do that, here 's a patch to its source code: https://depot.javispedro.com/vbox/vbados/wheelvkd_v1.patch

You do need the patched VKD if you want to use the scroll wheel under 386 enhanced Windows. Note that Intellimouse drivers for 3.x do a similar patch (to support ball mouse and the like) but I have not seen a way to use the patched VKD from Intellimouse; I need to use my own patch.

Assuming you have the DDK, and have the vad.asm file patched... how do you actually compile the driver from the DDK? There seems to be very little information available on this topic.

arablizzard2413 wrote on 2024-01-06, 23:10:

Assuming you have the DDK, and have the vad.asm file patched... how do you actually compile the driver from the DDK? There seems to be very little information available on this topic.

You have to put the DDK's TOOLS directories in your path, e.g.

1SET PATH=C:\WINDDK\386\TOOLS;C:\WINDDK\286\TOOLS

Then go into the VKD directory (where VAD.ASM) resides, and run NMAKE.

To install, just copy the resulting VKD.386 file into, say, C:\WINDOWS\SYSTEM\wheelvkd.386 .
Then edit system.ini, replacing keyboard=*vkd line with keyboard=wheelvkd.386 .

Hello. I'm a stranger to this site, but I'd been getting an interest in emulating DOS (and particularly Win 3.11 recently) and have gotten a problem kind of relevant to this topic.

To start with, I have a very specific inclination on attempting to use very old Photo Manipulation software/Drawing software. Been trying to get Photoshop 3/4 specifically to work in VMWare before this, but I gave up on that due to having extreme issues with avoiding running out of memory. Before that I had issues using VirtualBox, period, but I'm gonna test again.
But previous to that VMWare issue, I had one big issue with my mouse which I fixed with this VMWare driver, letting me use a tablet semi-decently on Win 3.1. I couldn't even draw straight lines in Paintbrush with the old one.
Now, my VMWare machine stopped working for some reason that I can't describe, so I decided to try and move to PCem instead.

And surprisingly, PCem does not have these memory issues... but! It can't make use of this VMware driver on it, and I also can't figure out how to get the VBADOS driver someone made for VirtualBox to work either. The installation simply does not finish as it should, complaining that I don't have the vbados.exe in order or something.

Anyone know of any tricks I could try?

How about you try DOSBox? It runs Windows 3.x quite well and might be a better choice for what you are aiming at. Windows 3.1x DOSBox Guide
One problem is the missing share. Most programs that don't really need it but query it are fine with fakeshare but if that fails a fork of DOSBox with real share implemented should do the trick.

Dominus wrote on 2024-02-28, 21:33:

How about you try DOSBox? It runs Windows 3.x quite well and might be a better choice for what you are aiming at. Windows 3.1x DOSBox Guide
One problem is the missing share. Most programs that don't really need it but query it are fine with fakeshare but if that fails a fork of DOSBox with real share implemented should do the trick.

I was considering it as an eventuality, but I wanted to challenge myself with running a whole machine first so I would need to go DOS install > Windows and so forth. PCem complicates it with the whole part selection+BIOS setup, but aside from a mouse driver it was pretty on point.

But I'm gonna give an update. I went back to VirtualBox after ditching it too quickly when I first started this some weeks ago. Banging my head against the wall trying to get the other software for running DOS->Win3.x made me good enough to set this up properly from the start apparently.

And to my surprise, Photoshop 3.x and onward (the ones that have layers, 2.5.1 doesn't, which was my main issue) now seem to boot and not crash within 5 seconds of touching the display with my pen. I still need to try Photoshop 4, but this is promising since VMWare shat itself quickly every time I tried.
I'm also in luck with the driver from this thread: It works fine with Photoshop 3! So that means my main issue here is actually mostly solved.

@javispedro1

I was wondering, do you happen to know the driver level differences between Windows 98/ME on how scroll wheel input is processed on a usb mouse? One thing I noticed in VirtualBox is, scroll wheel is not working in the "seamless mode" under Windows 98, but it is working under Windows ME. I thought that it's related to the improvements in support for usb devices in ME, but you probably know more. Scrolling on a PS/2 mouse works, but do you think it's possible to enable scrolling on a usb mouse in Win98?

No, I don't know. I suspect the HID driver just ignores the mouse wheel reports when you use the USB tablet mouse in VirtualBox. It is definitely different between 98 and ME because of the well-known CoordShift "workaround" in 98.

One thing to try may be one of those "USB 2 stacks" floating around that bring ME/XP drivers to 9x, but I don't remember finding one which upgraded HID class drivers (i.e. hid*.sys).

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