Touchscreen and Windows 3.1`

[IoIxD]

One of the main reasons I switched from DOSBox to DOSBox-X is because I wanted to use touchscreen with Windows 3.1. In DOSBox, when I click on the screen, the cursor immediately zooms to the bottom right corner of the screen. This same thing happens with DOSBox-X, though; additionally i see nothing in the configuration even relating to touchscreen. Is touchscreen supposed to be auto enabled? If so, how do I get it working with Windows 3.1?

[joncampbell123]

DOSBox-X has mouse pointer integration support for DOS programs and Windows 3.1.

The Windows 3.1 installation by default uses the PS/2 mouse interface which only supports relative motion.

DOSBox-X by default, requires mouse capture to send relative motion. One known problem is if you capture the mouse, then use a touchscreen. Touchscreen input doesn't work well with the relative mouse input and problems like that happen.

SDL2 builds have better and more explicit touchscreen support and the touchscreen input is more direct to DOSBox-X than the fake touchscreen to mouse input that is offered to non-touch-aware applications.

The best solution is to locate DOSLIB and install the "DOSBox mouse pointer integration" driver for Windows 3.1. This driver reads absolute coordinates from DOSBox-X and allows guest pointer integration (mouse and touch).

[IoIxD]

The best solution is to locate DOSLIB and install the "DOSBox mouse pointer integration" driver for Windows 3.1

Kinda new to linux, you mind just giving me a direct link or listing what commands I need to execute.

[joncampbell123]

Download the latest binary of DOSLIB, here, and unpack the contents into a directory.

https://github.com/joncampbell123/doslib/releases

Copy the files from windrv/dosboxpi/bin/win31 into a folder that is visible to the DOSBox VM you're making.

There should be an INF file and a DRV file.

Start up DOSBox-X, start Windows 3.1, and then in the Program Manager go to Main, double-click "Windows Setup".

In Windows Setup, select from the Options menu "Change system settings".

Locate the Mouse dropdown, scroll all the way down to "Other mouse".

When it asks you for the location, type in the DOS path where you copied the files and hit enter.

It should install the drivers and restart Windows.

If you used the shortcut to capture the mouse, use it again to un-capture the mouse now.

When Windows comes up, moving the cursor over the window (without capturing) should cause the cursor in Windows to match it.

It should also work with the touchscreen especially if you are using SDL2 builds of DOSBox-X.

[IoIxD]

Thanks, but there's no .drv file in the zip you provided, so the setup is stuck at the "guest additions" part.

[IoIxD]

So I think I found the driver:

https://github.com/joncampbell123/dosbox-x/blob/master/docs/Windows%203.1/dosbox%20drivers%20for%20Windows%203.1.zip

but when i installed it the mouse just disappeared, i can't do anything. I realised that I probably needed to extract the .drv file to a separate location along with it's oemsetup file, so i did that and reinstalled it (since i couldn't uninstall it fully for some reason) but it still doesn't work.

[joncampbell123]

The binary should be in the latest release.

Download https://github.com/joncampbell123/doslib/releases/tag/doslib-20190130 and unpack it.

Copy the INF and DRV file from windrv/dosboxpi/bin/win31.

Also, make sure that under the [cpu] section of your dosbox.conf, that you have "integration device=true"

[IoIxD]

That actually is the version I installed, guess I didn't install the source code? Anyways, it works! Thanks!

[IoIxD]

Actually one more problem. I've turned autolock off which works best since I'm planning on running 3.1 in full screen. Problem is, the cursor auto locks anyways as soon as the Windows logo disappears. Anyway to fix/circumvent this?

[joncampbell123]

DOSBox-X isn't supposed to auto-lock when the driver starts.

It is supposed to hide the cursor as long as the mouse driver in the guest is running and the cursor is within the boundaries of the emulator screen.

The way you can tell is if the cursor disappears while over the Windows 3.1 screen, and then reappears when you move the cursor beyond the Windows 3.1 screen boundaries and/or outside the emulator window.

[IoIxD]

Yes but I can tell it locks because after it disappears that I start experiencing all the problems I have with the cursor when it IS locked, until I press Ctrl+F10 in which case the cursor shows up, in full screen, and I can use it again.

[joncampbell123]

Is this on Windows, Linux, or...?

Given default settings in dosbox.conf DOSBox-X is supposed to treat DOS programs using INT 33h and Windows 3.1 using the driver as a case where, when the mouse is not captured, relative motion is never sent while absolute position is provided when you move the host cursor over the emulator window.

It's not supposed to auto-capture like that. It doesn't on my test collection, what does your dosbox.conf do to change that?

[joncampbell123]

Furthermore, if Windows 3.1 is using the standard PS/2 driver, moving the host cursor over the emulator window while NOT captured should not cause any cursor motion in the guest at all, while clicking the mouse buttons should still cause input.

[joncampbell123]

Here is the dosbox.conf I am using for Windows 3.1.

[log] logfile=log.txt

[dosbox] machine=svga_s3 captures=capture capture format=mpegts-h264 enable pci bus=true memsize=8

[cpu] core=normal cputype=pentium cycles=30000 isapnpbios=true realbig16=true integration device=true

[midi] mpu401=intelligent mididevice=mt32

[sblaster] enable asp=true sbtype=sb16 sbbase=220 irq=5 dma=1 hdma=5

[gus] gus=true gus panning table=default gusrate=44100 gus fixed render rate=false gusbase=240 gusirq=5 gusdma=3 gustype=classic

[dos] umb=true ems=true

[serial] serial1=nullmodem transparent:1

serial1=serialmouse

serial2=dummy serial3=disabled serial4=disabled

[speaker] disney=true

[autoexec] mount c: . mount d: /usr/src/doslib mount e: /usr/src/16 mount f: /usr/src/doslib2 c: SET PATH=%PATH%;C:\WINDOWS;C:\DOS;C:\QB45

[IoIxD]

This is on a Raspberry Pi, so Linux.

Here's the dosbox.conf file since you mentioned it: https://pastebin.com/raw/pH6jVW1L

[joncampbell123]

E: as /usr/src/16 is a leftover from helping "Project 16" with some testing and development. :)

[joncampbell123]

Why is aux=false?

In my dosbox.conf the aux= setting is never specified, and therefore defaults to true.

[IoIxD]

Aux is false because when it wasn't set, the keyboard wasn't working.

https://github.com/joncampbell123/dosbox-x/issues/845

[joncampbell123]

Ah. I'll dig up a copy of WfW 3.11 and see what works.

I knew I forgot something. I have test setups for Windows 1.0 through Windows 95 but I forgot to make one for Windows for Workgroups :)

[IoIxD]

Here's the one I used, it's actually straight from Microsoft's MSDN so I'm pretty sure it is somewhat legal, just don't actually register the computer, I guess. https://the-eye.eu/public/MSDN/Windows%203.11%20for%20Workgroups%20%2816-bit%29/

[joncampbell123]

No problems with Windows 3.1 WfW.

Windows 3.11 WfW however is masking IRQ1 (the keyboard interrupt) for no apparent reason.

A quick workaround at this time is to bring up the debugger and type "PIC UNMASKIRQ 1", hit enter, then resume emulation.

[joncampbell123]

The latest commit unmasks IRQ1 every time specific INT 16h calls are made, which seems to fix the issue with Windows 3.11 WfW.

Oddly enough issuing I/O reads/writes does NOT fix the issue. WfW's PIC virtualization seems to have a problem with DOSBox-X.

[IoIxD]

Issue still occurs after I reinstalled the latest commit. Version is 0.82.16

[joncampbell123]

in your dosbox.conf, in the [dosbox] section, make sure you have:

unmask keyboard on int 16 read=true

[IoIxD]

Thank you. Sorry but I don't think I described the problem I have in fullscreen. It works, but when I try and use touchfscreen the cursor slides all over the place and seems to appear on the opposite side of where I'm placing my finger.

[jschwartzenberg]

Are there any special features advantages of the Windows 3.1 pointer integration in DOSBox-X over regular int 33h?

[joncampbell123]

It lets you interact with Windows without having to capture the mouse. A side effect is that it also makes Windows 3.1 easier to use with a touchscreen. A special driver is needed for Windows 3.1 to work this way. Windows 3.1 does not use INT 33h but talks directly to the PS/2 through the BIOS, which reports relative motion only.

There is work with INT 33h to provide pointer integration for DOS games as well, if the DOS game makes calls to read cursor position. It will not work if the DOS game reads and handles relative motion only.

[joncampbell123]

If the cursor is sliding around uncontrollably when given touchscreen input, you have mouse capture enabled and you need to release capture for it to work.

When the mouse is captured, relative motion is reported to the guest in the same way DOSBox SVN does. That does not work properly with touchscreen input.

[jschwartzenberg]

For DOSEMU, this driver is now recommended: https://github.com/stsp/win31-mouse-driver/ It's based on the Win 3.1 DDK though.

I am mainly curious if your driver also has more features beyond what could be offered with a generic int 33h driver.

[joncampbell123]

My driver is also an adaptation of the Windows 3.1 DDK driver, though modified to compile with Open Watcom C. It connects to the PS/2 interface as does the original driver, but it also uses the DOSBox-X integration device to know if the user has captured the mouse or not, and decide whether to send the PS/2 relative motion or send the absolute cursor position returned through the integration device.

There are two versions.

Version for IBM PC/XT/AT emulation mode (for Windows 1.x/2.x/3.x/95/98/ME): https://github.com/joncampbell123/doslib/tree/master/windrv/dosboxpi/win3x

Version for NEC PC-98 emulation mode (for Windows 3.x ONLY, does not work with earlier versions): https://github.com/joncampbell123/doslib/tree/master/windrv/dosboxpi/win3x98

[jschwartzenberg]

I guess compared to DOSEMU it shouldn't matter feature wise then, but I could imagine your driver would be more stable. There are drivers out there that support scrolling in Windows 3.1, but they are for serial mice. It would be nice if there would be a driver that supports this in combination with absolute positioning.

[stsp]

Since I was pinged by this discussion, let me point out that the below are misunderstandings:

It lets you interact with Windows without having to capture the mouse. Windows 3.1 does not use INT 33h but talks directly to the PS/2 through the BIOS,

My int33 driver does exactly what you say it doesn't do. :) (yes, w/o any need to grab mouse, with tracking the host pointer by absolute coords and all that, and at the end - with just a couple of lines of an asm code). Not trying to advertise it, just was a bit surprised by this discussion.

[joncampbell123]

I am testing the int33 driver with DOSBox-X now. If it works as I expect, the INT 33h pointer integration should naturally carry through to Windows.

[joncampbell123]

Hm, doesn't seem to work yet.

[stsp]

Because of poor int33 support in dosbox-x or because of the problems in a driver? Easy to check up, just use winos2 driver as a test. It will not use absolute coords unless you support the undocumented int66 call, but it will work nevertheless (just make sure int66 vector in not NULL, or it will crash). If winos2 driver doesnt work too, there is also a pocketdos int33 driver to try. That way you'll be able to find out what is broken.

[nl255]

@joncampbell123

Is there a solution to fix this for DOS programs other than to run them in a Windows 3.x dos shell? Because I am having the same issue only with pure DOS games such as Ultima Underworld when trying to play them via remote display software like Teamviewer or Splashtop. Windows 3.x works fine with the DOSLIB driver you posted but that doesn't do anything unless you are running Windows.

[rmmh]

I got joncampbell123/doslib's mouse driver working with touchscreen in windowed mode, but it doesn't work in fullscreen-- presumably because of mouse locking? I tried setting [sdl] autolock=false but it didn't appear to change anything.

DOSBox-X 0.83.8, with config file:

``` [log] logfile=log.txt [dosbox] machine=svga_s3 captures=capture capture format=mpegts-h264 enable pci bus=true memsize=32 unmask keyboard on int 16 read=true [cpu] core=auto cputype=auto cycles=auto cycleup=10 cycledown=20 cputype=pentium isapnpbios=true realbig16=true integration device=true [render] aspect=true [mixer] nosound=false rate=44100 blocksize=1024 prebuffer=20 [midi] mpu401=intelligent mididevice=default midiconfig= [sblaster] sbtype=sb16 sbbase=220 irq=7 dma=1 hdma=5 sbmixer=true oplmode=auto oplemu=default oplrate=44100 [gus] gus=false gusrate=44100 gusbase=240 gusirq=5 gusdma=3 ultradir=C:\ULTRASND [speaker] pcspeaker=true pcrate=44100 tandy=auto tandyrate=44100 disney=true [joystick] joysticktype=auto timed=true autofire=false swap34=false buttonwrap=false [serial] serial1=nullmodem transparent:1 #serial1=serialmouse serial2=dummy serial3=disabled serial4=disabled [autoexec] mount c .\eXoWin3x\Mixed-Up imgmount d .\eXoWin3x\Mixed-Up\cd\MUMGDX.img -t cdrom d: path=C:\;z:\;c:\windows\;d:\ @cd sierra\mgdx @cls @win ```

[abrasive]

@rmmh I have the same problem. Pressing Ctrl-Alt-F10 after going fullscreen plays the uncapture sound and touchscreen starts working, same as for @IoIxDButStronger -- but I can't find a config option that makes this the default.