DOSBox 0.70 Drops pervious auto Mouse Detect/Support in PCPAINT 3.0 \ VOGONS

DOSBox 0.70 Drops pervious auto Mouse Detect/Support in PCPAINT 3.0

Topic actions

Post a reply

First post, by cmdrmic

Posted on 2007-05-02, 17:27

cmdrmic Offline

Rank Newbie

Rank: Newbie
Posts: 2
Joined: 2007-05-02, 14:58

Hi Guys,

I thought I would report this issue, since it hits me a bit odd...

I have used DOSBox 0.65 with PCPAINT 3.0 and it has worked very well. PCPAINT 3.0 is a relatively tame DOS application and when you mount the directory and start the program, the mouse has always been detected. Thus, simply click in the window, and go to work.

However, not so with DosBox 0.70. For some odd reason, this new version of DOSBox refuses to understand a mouse is required. Even with a manual capture command via CTRL+F10, no support is offered.

As a work around, I have found that if I load a old MOUSE DRIVER into DOSBox (MSCMOUSE.COM), then start PCPAINT 3.0, the mouse is working.
So, in essense this is a step back in support from previous versions as mouse support was automatic.

I have duplicated this problem on three machines running different OSs (Win XP, & Win98). How do I forward this report to the developers, or is this post sufficient?

Is it possible there is just something that needs to be configured a little differently? I am running DOSBox with all default settings.

WELL FYI

Kind Regards,

Mic

Reply 1 of 7, by MiniMax

Posted on 2007-05-02, 21:16

MiniMax Offline

Rank Moderator

Rank: Moderator
Posts: 5128
Joined: 2004-01-18, 04:15
Location: Stockholm, Sweden, Europe, Earth Interests: Old games & young women

A post here is usually enough to get the attention of the developers. But feel free to create a real bug report at sourceforge.com.

*** Moved to DOSBox Development ***

Reply 2 of 7, by Kippesoep

Posted on 2007-05-03, 19:53

Kippesoep Offline

Rank Oldbie

Rank: Oldbie
Posts: 1024
Joined: 2005-05-04, 22:36
Location: Netherlands

This is caused by some odd checks against the address of the INT33 handler. Could be fixed by relocating DOSBox' mouse interrupt, but that would reduce available memory to the program. I've created a patch for the program and a TSR so it could work for other versions (or other programs) as well.

Reply 3 of 7, by wd

Posted on 2007-05-03, 19:56

wd Offline

Rank DOSBox Author

Rank: DOSBox Author
Posts: 10813
Joined: 2003-12-03, 21:23

What check exactly?

Reply 4 of 7, by Kippesoep

Posted on 2007-05-03, 20:08

Kippesoep Offline

Rank Oldbie

Rank: Oldbie
Posts: 1024
Joined: 2005-05-04, 22:36
Location: Netherlands

It has the following checks:
- segment < 0x0040 (no problem)
- points to iret (no problem)
- segment >= 0xF000 (problem)

My site: Ramblings on mostly tech stuff.

Reply 5 of 7, by wd

Posted on 2007-05-03, 20:13

wd Offline

Rank DOSBox Author

Rank: DOSBox Author
Posts: 10813
Joined: 2003-12-03, 21:23

Hm yes, maybe moving it into the private dos segment or so.
Thanks for digging it up 😀

Reply 6 of 7, by cmdrmic

Posted on 2007-05-04, 01:58

cmdrmic Offline

Rank Newbie

Rank: Newbie
Posts: 2
Joined: 2007-05-02, 14:58

So, will the patch go into the next official release of DOSBox or must I apply the patch from somewhere...

~Mic

Reply 7 of 7, by Kippesoep

Posted on 2007-05-04, 10:53

Kippesoep Offline

Rank Oldbie

Rank: Oldbie
Posts: 1024
Joined: 2005-05-04, 22:36
Location: Netherlands

I saw from your PM that you already understood this. For other people: From the looks of it, WD might decide to adjust DOSBox to render the patch unnecessary. It may be quite a while until an updated version is released, though. Until that time, you can use the patch or the TSR from my site. (They won't break when DOSBox is adjusted).

My site: Ramblings on mostly tech stuff.

Go to top of page Go to top of page

Back to DOSBox Development

Main menu

Common searches