Windows for Workgrounds 3.11 crashes

[jschwartzenberg]

My installation of Windows for Workgroups with MS DOS 6.22 used to work without issues, but now it crashes on startup or it crashes DOSEMU. I'm using current GIT devel.

With $_cpu_emu = "vm86" the splash screen shows for a short moment, but then I get the DOS prompt back with the resolution of the splash screen.

With $_cpu_emu = "full" I get the attached crash. And in my terminal: ERROR: CPU-EMU: addr not found for 14008 boot.log-wfw311crash.txt

[runderwo]

Which version did it work with? Does it still work if you use that version?

[jschwartzenberg]

With current GIT master, it starts up much further but DOSEMU crashes after clicking the button in a general protection fault in progman.exe, this is with $_cpu_emu = "vm86".

With master and $_cpu_emu = "full" it shows the splash screen but crashes with a DOSEMU message: "DPMI: Unhandled Exception 0e - Terminating Client It is likely that dosemu in unstable now and should be rebooted

I'm not sure what was the last build which had no issues.

[runderwo]

Well, when was the last time you used it with no issues? Was it with 1.4.x or with 2.x?

[jschwartzenberg]

I just tested it with the DOSEMU2 fork point 1.5.0 tar ball and with that version my Windows for Worksgroups 3.11 installation works fine.

[stsp]

Could you please re-test also this?

[jschwartzenberg]

It seems this is fixed as well. With current GIT, Windows for Workgroups 3.11 starts without problems.

Btw. did you ever consider emulating pen/tablet hardware in DOSEMU to get exact coordinates for the mouse cursor? This is a popular feature in QEMU/VirtualBox these days to avoid a need for VM specific mouse drivers. https://en.wikipedia.org/wiki/Windows_for_Pen_Computing

[stsp]

OK, so lets close this.

97 is still actual, right?

Not sure about the pen computing. Did it include the *.386 drivers for stylus? If so - this would be a quite difficult task for dosemu, unless such code can be stolen from wine.

[jschwartzenberg]

I'll have to take another look at #97 and maybe the other installers I have.

I have no idea what kind of pen/tablet drivers exist in general for Windows 3.x. QEMU/VirtualBox can get away with just emulating a standard USB tablet of course, but that probably won't work here. Is there a specific kind of driver which would make it easier?

[stsp]

Yes, the one from wine.

[stsp]

Or if there is purely a user-space driver (.drv) and some int15 interface, then the things are much better.

[jschwartzenberg]

I don't think Wine provides any code which could work with Win3x itself to work with mouse cursor movement. The relevant win16 api events are generated directly by Wine.

A quick search gives me this driver for a serial tablet: ftp://ftp.brain.it/public/Old_Driver/Driver%20Vari/Tavoletta%20Wacom/Disk1/ In combination with X.org/XFree86/Linux driver sources to understand what kind of serial port data the devices generate, I can imagine this might be possible.

[stsp]

The relevant win16 api events are generated directly by Wine.

Wine can work in 2 modes: native dlls or wine dlls. If you use native dlls then wine emulates things on a vxd level. This is exactly what we need. dosemu already has some vxd code from wine, see vxd.c.

Anyway, we need to study this subject further. For example the serial port driver can probably be tested right now: all you need is to disable the linux driver and give that serial port to dosemu. But I wonder if there is a driver that just uses int15. The native windows mouse driver does exactly that. So when you use your stylus, does it need a special mouse driver or what?

[stsp]

RBIL also lists the INT 7f touchscreen interface. All we need is to find out what the windows driver expects, or what kind of drivers do exist.

[jschwartzenberg]

I wasn't really clear it seems. I was thinking of emulation of such hardware so that dosemu can use absolute positioning with the mouse cursor. I don't actually have such hardware.

[stsp]

To emulate the hardware, we need to know 2 things: how it is connected to PC physically (I guess serial port is not an only option; can it use ps/2 ports?), and what driver stack is there in windows. Its not qemu here, where you would only care about a physical interface.

[stsp]

absolute positioning with the mouse cursor. I don't actually have such hardware.

Oh, please just use the winos2 mouse driver then. If you don't have such hw, you won't get anything from that task.

[jschwartzenberg]

Yes, my bad. I had forgotten about that driver. It will probably be superior in any case. I should write a script to fetch that driver though, as I was just lazy to install it manually.

[jschwartzenberg]

I just installed the winos2 mouse driver (and changed win.ini according to the README). It seems to work more predictably, but it is still not right. I'm unable to reach the left part of the window. In general dosemu still does not seem to know where the Windows mouse pointer is located exactly in its window. Maybe there's a calculation issue? I'm using the Trident 800x600 driver.

[stsp]

You need to execute before starting windows: emumouse x 8 y 8

[jschwartzenberg]

Then I can access the left part, but not the bottom and right parts.

[stsp]

Then enable mouse grab (Ctrl-Alt-Home)

[jschwartzenberg]

That works, but that completely misses the point of using the winos2 driver I would say.

[stsp]

OK, you won. Your prize is the driver that does exactly what you say. Please get your prize now: http://www.pocketdos.com/Misc/PocketDOS_Win3xMousePM.zip

[jschwartzenberg]

This driver is indeed interesting :) ... But I can't access the right+lower sides of the screen with it, even in grab mouse mode. Other than this it seems much more accurate!

[jschwartzenberg]

I set the resolution with its setup program btw.

[stsp]

I can't reproduce any slightest problem with this driver. Please check the standard VGA driver, maybe the problem is with the trident driver or whatever.

[jschwartzenberg]

I tried whole bunch of drivers, including the standard VGA one and I have this exact issue with all of them. Did you change the resolution with either the included setup utility or with emumouse? Could it be due to different Windows versions?

[stsp]

I didn't do anything at all. All I did is copied the pdmouse.drv over the existing mouse.drv. What's your problem? Could you record it in video?

[jschwartzenberg]

Here's a video which shows the problem. I never recorded a video of my desktop before, so I hope this is usable. Bascially it's impossible to reach the right or lower parts of the screen with the Windows mouse cursor. video.zip

[stsp]

Yes, adding a gstreamer support for video recording is in my todo list, but of course i don't have time to work on everything.

Yes, there is something very wrong with the driver, and for me that doesn't happen. Are you sure it is not a winos2 driver? I have that with winos2 driver but not with pd.

[jschwartzenberg]

In system.ini I see mouse.drv=PDMOUSE.DRV. I would say that should let Windows use the Pocket Mouse driver.

I still wanted to try this driver as well btw, I don't know if you've seen it before: http://turkeys4me.byethost4.com/

[jschwartzenberg]

Crazy, with that driver I have almost the same problem, except that now I can't reach the left and top parts of the window!

[stsp]

How to install it? I see only sources and some DLL in archive, but no .drv files.

[stsp]

Does your problem happen with both X and SDL?

[stsp]

Does different emumouse resolution settings affect this anyhow?

[jschwartzenberg]

I tried using both the setup program and emumouse to change the resolution, but it didn't seem to have any effect. Are there particular settings you would recommend? X and SDL doesn't make a difference.

There's a readme included with the package which is quite clear. You need to set that DLL as the driver, the included oemsetup.inf will also do that. Then you need to start the included executable to be able to move the mouse pointer.

[stsp]

Are there particular settings you would recommend?

No, as they should have no effect on this driver (but do on winos2 one, so after all its not that).

You need to run dosemu with -D9+m and see for "MOUSE: move: " strings when moving the pointer outside of the window. For example when I cross the bottom edge, I can see: MOUSE: move: x=600,y=479

y=479 means the bottom edge at the 640x480 resolution. If you have some smaller y value - a problem.

[jschwartzenberg]

It seems my values are comparable to yours: mouse_move_absolute(639, 474, 640, 480) -> 639 474

The cursor is just not catching up. You also have MouseThreshold[1,2] and MouseSpeed in win.ini set to 0 right?

[stsp]

Yes, all 0.

[stsp]

OK, so my pdmouse.drv: 33b5e2857a0c2a2b5ea9021632b128fa pdmouse.drv

And yours: 5e9c40798057ed8ee063f62e67d6cbad pdmouse.drv

Please don't break files before testing. :)

[stsp]

Hmm, and if we copy from the end of your hash sum, we can see: bad pdmouse.drv which is quite correct.

[stsp]

Please read the manual. It says that setup.exe can patch the resolution values in the driver, which is what you have done. You need setup.exe 0 0 to return the autodetection.

[jschwartzenberg]

Yes sorry I had been experimenting with it as it had the exact same issue with the autodetection. Or you mean that you got it to work correctly with the autodetection?

[stsp]

It works correctly on my install, where I simply copied pdmouse.drv over mouse.drv. And if I take your pdmouse.drv then I reproduce the same problem as you do. However, putting my pdmouse.drv to your install for some reason doesn't work for me at all. :( I suspect pdmouse.drv has some bug. Are there the source codes anywhere?

Also could you please describe exactly how have you got it patched? Was it patched just by installing it via setup.exe? We need to ask its author to please use win.ini instead of patching the driver.

[jschwartzenberg]

I indeed used the included setup program. I tried a lot of different options and resolutions, but couldn't get it to work properly at all. Maybe this Windows version is just less suitable for dosemu.

The other driver I mentioned above does have source code btw.

[stsp]

I indeed used the included setup program.

How exactly? Does it patch the driver no matter what you do? In this case we can try to bug-report it.

The other driver I mentioned above does have source code btw.

OK, if pdmouse appeared problematic, we need to re-evaluate this one.

[stsp]

pdmouse has some very nasty license statements. I wouldn't be recommending it.

dosmous5, according to its readme, requires you to run /kbdmouse/d2wmouse.exe??

[stsp]

OK, so pdmouse's auto-resolution works fine only with vga.drv, and you have instead svga256.drv for which it fails to detect the resolution.

To get it working with svga256, you need to do setup.exe 640 480 That works, I checked that on your setup. So I really doubt you experimented with resolution. Your driver is set to 1024x768, which is obviously wrong.

So, what we need from this driver:

1. remove the restriction to decode and modify it
2. use win.ini instead of patching the binary
3. fix autodetection to work with svga256.drv, or at least make it to fall back to 640x480 rather than to fail completely.

I wonder if it worth a try to contact its author about so many things...

[stsp]

Hmm, in fact the auto-detection relies on dosemu autodetection, and that chokes. I need to revisit the mouse coords calculation, which is already too complex.

[jschwartzenberg]

Yep I could get 640x480 to work correctly now. I think I wrongly assumed that the setup updates the file in cwd, while it probably always updates the file in its own directory. Setting Windows to 1024x768 and doing the same to pdmouse.drv doesn't work here though.