Where do I look, if a graphic mouse isn't moving?

[ghost]

Code of Conduct & Contributing Guidelines

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

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

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

Question

Hi,

I'm running two graphics applications in DosBox-x. In one of them, the graphics mouse is stuck in the Upper Left corner. In the other, it remains in the middle.

In text applications that use the mouse, the mouse works fine.

If I run them within DosBox, the mouse works fine, both graphics mode apps and text mode.

Where should I look first?

[joncampbell123]

Is the mouse captured in both cases? DOSBox-X does not send relative motion unless you capture the mouse. If the DOS application polls INT 33h for mouse cursor position or reads cursor position from the INT 33h interrupt function, DOSBox-X can provide absolute mouse coordinates without capturing the mouse. If the DOS application is reading only relative motion, then you will need to capture the mouse to work with the program through the mouse.

PS/2, serial, and PC-98 bus mouse interfaces only support relative motion. If using a different mouse driver than DOSBox-X INT 33h or running a guest OS, you will need to capture the mouse.

Despite all other mapper changes, DOSBox-X retains CTRL+ALT+F10 as the mouse capture/release shortcut in order not to annoy users used to DOSBox SVN or any other fork.

[ghost]

Was able to do it, with Ctrl-F10.

How do we make this a default, in the configuration tool? Or directly in the Autoexec or config, whatever controls the mouse?

[joncampbell123]

When the mouse is not captured, DOSBox-X sends only absolute position, and relative motion is suppressed.

When the mouse is captured, DOSBox-X sends only relative motion, and absolute position is no longer needed.

There's no way to transmit absolute position to hardware interfaces and INT 33h calls that only report relative motion, and I'd rather not add hacks to support it that can easily go wrong.

There is a mouse driver for Windows 3.1 that talks to the DOSBox-X Integration Device to allow interacting with Windows without having to capture the mouse cursor.

I'd rather DOSBox-X not capture the mouse until the user wants it to, so the default (and only option) is not to capture the mouse at startup.

[ghost]

Ok, thanks Jon. So I'll just remember to Ctrl F10 or Ctrl Alt F10, which is working fine.

[emendelson]

"There is a mouse driver for Windows 3.1 that talks to the DOSBox-X Integration Device to allow interacting with Windows without having to capture the mouse cursor."

Where can we find that driver? That might make it much easier to work with Windows 3.11. (I've searched for it but haven't found it, probably because I'm not looking in the right place.)

[rderooy]

You can also set autolock=true in your config file. That way when you press the mouse button over the window, it will lock the mouse to it.

[joncampbell123]

The driver is in the DOSLIB git repo: https://github.com/joncampbell123/doslib

Source code is here: https://github.com/joncampbell123/doslib/tree/master/windrv/dosboxpi Build packaging code is here: https://github.com/joncampbell123/doslib/tree/master/windrv/dosboxpi/bin

Binary builds are under Releases, under windrv/dosboxpi.

Use the INF file provided to install the mouse driver in your choice of Windows. Some versions (like Windows 1.0) will need extra steps to install.

The driver cannot use absolute cursor position from the host window unless the "dosbox integration device" is enabled in dosbox.conf, which it is NOT enabled by default.

[cpu] integration device=true

Note that there is also a Windows 3.1 driver for Windows 3.1 in PC-98 mode. I could not get Windows 1.0/2.0 for PC-98 to work with the code, for whatever reason.

[rebb]

You can also set autolock=true in your config file. That way when you press the mouse button over the window, it will lock the mouse to it.

And if the autolock "beep" annoys you ( like it does in my case ), add autolock_feedback=none as well ;)

[emendelson]

Thanks for all these details, which I should have known but didn't. I'll try to figure out the best way to add these things for the DOSBox-X-based setup I provide for running Win311:

http://www.columbia.edu/~em36/win31dosbox.html

[emendelson]

The driver is in the DOSLIB git repo: https://github.com/joncampbell123/doslib Binary builds are under Releases, under windrv/dosboxpi.

Use the INF file provided to install the mouse driver in your choice of Windows. Some versions (like Windows 1.0) will need extra steps to install.

Thank you again! I'm probably missing something obvious, but I can't find an INF file in /doslib/windrv/dosboxpi. In the win3x/win3001 folder, which seems to be the right one, but I've got things like this all wrong before...

EDIT: Wait, I see: it's in the \bin\win31 folder! Sorry to waste bandwidth, but I hope this helps someone else.

And one question: does integration device = true cause any problems if the DOSBox-X mouse driver is NOT loaded?

[evbo]

@joncampbell123 I'm hoping this isn't too off topic, but running windows 95 in dosbox-x works excellently, but why then does the mouse freeze in position (like O.P. describes) when run using your dosbox-svn release (other repo you have)?

In fact, I'm noticing when I run setup.exe for windows 95 with dosbox-svn the mouse is just frozen and only keyboard input works. Why is that and how did dosbox-x overcome this limitation?

[joncampbell123]

Windows 95 uses it's own drivers when installed, or it uses the BIOS PS/2 interface during setup. In both situations the PS/2 mouse can only provide relative motion.

DOSBox-X does not send relative motion when you move the mouse unless you use the mapper shortcut to "capture the cursor" to the emulator window.

If the cursor is captured, relative mouse motion is sent to PS/2, PC-98 bus mouse, and serial emulation. If a DOS program is polling INT 33h for relative mouse motion (such as DOOM with mouse support enabled), it will see it as well.

If the cursor is not captured, DOSBox-X only sends absolute mouse position, which is only received by the guest if running Windows with a special open source mouse driver written to run within DOSBox-X, or if a DOS program is polling cursor position via INT 33h. Anything that reads in a manner that can only read relative motion will see no motion unless the cursor is captured to the emulator window.

I believe this approach makes more sense than what DOSBox staging does which attempts to turn mouse motion inside the window into some sort of relative motion that does not and cannot match the mouse movement in the guest.

In the sister DOSLIB project here on GitHub, there is an open source Windows mouse driver that is designed to talk to the "DOSBox integration device" which allows the Windows guest to match it's mouse cursor exactly to mouse movement in the emulator window so that you can use Windows with the mouse without capturing the mouse cursor. There are INF files or installation instructions for every version of Windows from Windows 1.0 up to Windows Millenium Edition. There are no drivers for Windows NT (which currently does not run in DOSBox-X anyway). You will also need to add "dosbox integration device=true" to your dosbox.conf. There are also drivers for the PC-98 versions of Windows 3.0 and Windows 3.1.

[evbo]

thank you @joncampbell123! So it sounds like because I am using a fork of dosbox-svn I do not have the convenience of a built-in driver. I am running this fork, which has greater graphics support so I am hopeful it can handle 32 bit color: https://github.com/realnc/dosbox-core

Is there a way to get mouse input or would that require building dosbox from source to include the drivers you wrote in doslib? You mention a simple dos program polling for INT 33h would work? Could I run that as a background process before starting windows perhaps?

The reason I am using dosbox-core so is to run windows 95 games from Retroarch on Linux, but so far not a single version of dosbox has been able to run win9x (though the dosbox-svn core runs win3.1 for me great, it struggles to identify SVGA display so only 16 bit color games can be played on win95)

[evbo]

@joncampbell123 nevermind! I realize now your explanation had the solution staring right at me: when windows first boots it is not yet using the mouse driver you describe. You just have to use a keyboard for the initial setup process and then the second time you boot the mouse driver is installed and it works.

Took me by surprise. Excellent project thank you for keeping windows alive in the modern era! dosbox-svn is the secret weapon to convenient Retroarch-based gaming in 2022!