It's been nearly two years since this issue was reported

Oh no! Seems there is, yes, no interest.

So if you're going to make dosbox compatible with sdl 1.3 yourself, be prepared for
a lot of ripped-out multimedia features (SimpleDirectMedia is now SimpleDirectNotSoMuchMedia)
with a screwed-up keyboard layer, and hopes for anything usable working if/when they release
it officially are quite low.

So good luck, and please keep the amount of threads about this "issue" at a minumum.

Excuse you for being extremely rude, sir.

Did you even read the whole post? That was one of three options I presented, the most difficult one. The second option is far less complex, and the third should be almost effortless for a programmer familiar with the code.

Judging by your brash response, it seems you read the first few sentences and then dismissed me as some ignorant and belligerent fool - kindly do not, for I have put much thought and consideration into my above post.

I have no intention of making DOSBox compatible with SDL 1.3 myself - that would be a fool's errand. I was suggesting that it perhaps was time for the development community of this program to investigate migrating to it at some point in the near future, as SDL 1.2 is bound to stop functioning with modern systems in the next few years as the transition to 1.3 begins, as I understand it, and it would be much easier to slowly do this in a branch of the source than to suddenly find yourself with hundreds of thousands of upset users who can't run DOSBox at all because their new Linux distro or (Windows variant) and SDL 1.2 are fundamentally incompatible.

I intend to investigate a workaround via method 2 in my above post, compensating for the improperly returned values of the relative mouse coordinates when a touchscreen enters the mix. If I find that beyond my capabilities I will try to bypass SDL by getting the mouse coordinates through the Windows API directly, as a fix *specifically* for my own problem, and investigate doing the same for *nix as a gesture of kindness toward those in a similar situation on other platforms, even though it won't benefit myself.

Did you even read the whole post?

Yes.

That was one of three options I presented

The rest requires somebody with a non-functional touch screen.

to investigate migrating to it at some point in the near future

Thanks for pointing out that somebody may want to investigate migrating to sdl 1.3

to suddenly find yourself with hundreds of thousands of upset users who can't run DOSBox at all

Yeah, can handle that, promised. Guess the fundamentally sdl1.2-incompatible windows/linux is quite far far away.

I intend to investigate a workaround via method 2 in my above post, compensating for the improperly returned values

Nice. This is unrelated to dosbox, so compile a nice little sdl application (or use the examples they distribute)
and check how it behaves, assure you're using the same input functions as dosbox queries so you can move
to actual dosbox testing easily later on.
If there are any questions about the second part, feel free to ask here.

I've identified all of the bits of code in DOSBox related to mouse movement.

I tried removing the xrel and yrel components of the input to Mouse_CursorMoved by zeroing them out to 0.0f in sdlmain.cpp's HandleMouseMotion - the mouse no longer moved, both on the UMPC and an ordinary PC. This puzzled me, as it means SDL is not feeding the absolute X and Y coordinates to DOSBox, which can't be true... unless the normal operation relies solely on tracking relative movement...?

If someone more knowledgeable about the code could confirm this (or explain actual operations if I'm more lost than I think), then the problem isn't even fixable while still relying on SDL for the mouse coordinates - either a custom SDL build with a fix, or sourcing the mouse coordinates from another location will be required.

Operating on that assumption, I'll need to attempt one of those two options. Since SDL is difficult to get compiling, and likely complex to modify, I'll be trying the latter fix, and in my case the source would be the Windows API.. Unfortunately a MinGW compilation environment does not come with support for win32 functionality, if I'm not mistaken.

I've never been able to get Visual C++ working properly with any external dependencies, so I'm SOL there too. My only option is to either try to get win32 support in MinGW, which I hope isn't too difficult.. I imagine it involves installing gigantic SDKs and then figuring out the relevant paths to add to MinGW, but I could be less fortunate.

Edit: It seems it does come with it's own version of the Windows API headers, in the form of windows.h - hopefully this covers the necessary functionality.

I am open to suggestions and explanations, as always. Please try to be constructive, however.

Edit 2:

I've found a method to get the coordinates from Windows, and made a test program that functions perfectly. I then applied the same logic to DOSBox, adding the required headers to sdlmain.cpp (windows.h and winuser.h - not entirely sure if the second is necessary but not worried about that atm).

I then modified the relevant code section as such:

1static void HandleMouseMotion(SDL_MouseMotionEvent * motion) {
2	if (sdl.mouse.locked || !sdl.mouse.autoenable)
3		POINT p;
4		GetCursorPos(&p);
5		Mouse_CursorMoved((float)motion->xrel*sdl.mouse.sensitivity/100.0f,
6						  (float)motion->yrel*sdl.mouse.sensitivity/100.0f,
7						  (float)(p.x-sdl.clip.x)/(sdl.clip.w-1)*sdl.mouse.sensitivity/100.0f,
8						  (float)(p.y-sdl.clip.y)/(sdl.clip.h-1)*sdl.mouse.sensitivity/100.0f,
9						  sdl.mouse.locked);
10}

However, the compiler errors because "p was not declared in this scope", and my limited knowledge of C++ prevents me from understanding what scope it SHOULD be in, and why it isn't working - I require assistance.

After that is done, DOSBox should begin receiving coordinates on Windows, unlike before, and touchscreen input may just "magically" work - otherwise I will continue from there.

Edit 3: For reference, this is the test program that compiles/runs successfully and provides mouse coordinates:

1#include <iostream> 
2#include <windows.h>
3#include <winuser.h>
4int main() 
5{ 
6  POINT p;
7  GetCursorPos(&p);
8  std::cout<<p.x<<","<<p.y;
9  return 0;
10}

Edit 4:
Turns out I needed some curly brackets that weren't in the function otherwise the scope did not exist that I tried to call the variable from. That has been fixed, and now it works. I found no improvement in behavior, but after also adding the 0.0f changes mentioned above, the cursor moves properly, but is offset below and to the right of the cursor's actual position - I imagine an issue with the coordinates not being relative to the window - and it crashes when you move a stylus away from the device, meaning left click release - i.e., the button handling code.

I have thus identified core problem here - relative movement does not work with a touchscreen, as it feeds a stream of current coordinates instead of movement information. SDL does not send the current coordinates as it should - only the relative movement data, so a workaround is required unless somebody wants to fix SDL (which I can't compile with the necessary SDKs and other garbage, so I can't do at this time).

I really hope somebody who knows C++ better can take it from here, but if not, I shall persevere..

Next, I'll need to inspect the button click functions and see if I can decipher why they cause a crash with the new changes. After that, I'll need to see about converting the absolute coordinates to coordinates that are relative to the window (I'll try the SDL_MOUSE_RELATIVE=0 first, in case that's what that means).

Edit 5:
Confirmed the window position's relevance to the mouse offset by putting the window in the top left corner (as close as possible) before testing. The cursor then aligned just fine.

When this is done, I'll need assistance making a patch which I will then submit, because none of the devs have touchscreens and thus they couldn't care less about those who do (at least wd.. don't argue this, because you could have helped by writing patches for ME to test), so it's up to me. At that point the code will be toggled on and off by a configuration file variable "touchscreen", and there will be a Windows and Linux version to source the coordinates depending on the OS, and it will defer to the original code when the variable is zero (so don't worry about how I've currently made the changes).

Edit 6:
SDL_MOUSE_RELATIVE=0 causes no change. This variable never did anything for me before, so I imagine that varies from system to system, since others claimed it helped them in the old thread.

Edit 7:
Seems the click crash was just a faulty assumption - somehow I must have been exiting the program I was using to test by clicking the quit button with the offset in place.. Just need to solve that offset...

One problem found, this only functions in windowed mode. In fullscreen, the mouse coordinates must not get sent - perhaps DOSBox's mouse "emulate" toggle comes into play here - I'll try forcing it off and see if that's the case.

Edit 8:
Hah, I'm a genius. That worked brilliantly and now fullscreen mode is 100% operational with the touchscreen. The only remaining issue is the offset of the coordinates in windowed mode, and I imagine I'll need to look up the WinAPI functions necessary to determine window content area origin and recalculate the coordinates ONLY if it's in windowed mode. Also will have to only toggle the mouse emulation for fullscreen only (not that I see why the mouse is emulated in fullscreen, tbqh, but there must be a reason?).

Edit 9:
After a moment of thought while moving the mouse about in windowed mode, I came to the realization that the offset IS being calculated, and that's the problem. Since I'm using absolute coordinates and applying them to the cursor, the offset needs to be removed. Will try toying with the removal of SDL clip values, etc.

Edits 10 through 16 were all conjecture and didn't get me anywhere but to a more broken movement system, and have been removed. I clearly got too tired. Saved them in a text file for reference. Will continue working on this tomorrow.

Since I'm feeding it absolute coordinates, perhaps I need to replace the SDL w/h variables with screen w/h variables (did this as last test of the night, may have improved accuracy slightly (but not a fix by far), and when sensitivity stuff removed it created a circular offset.. undid in test code..).

I edited the same post 18 times last night, and I feel it's too long so I'd like to start a new entry in the thread. If this is against the rules I'm sorry, I could not find a rule list, only the faq, and searching for "double post" and "rules" both returned nothing, so I presume there is no rule against this. If I'm wrong, forgive me.

Today I will continue where I left off. Fullscreen works perfectly, and windowed mode works (including relative movement, mind you! 😁), but the cursor is offset depending on the position of the window. I've been unable to identify the source of this offset, unfortunately, and will be re-examining the code again shortly.

I would still appreciate it if any of the devs, patchers, etc., could take a quick look and see if they can identify where the offset values come from.

My best guess is sdl.clip.x and sdl.clip.y, but if I log these variables to the status window, they are zero and inconsequential, so I'm rather confused. I've tried taking them away, in case the logging was wrong, and it does not solve the problem.

I tried logging the SDL source of coordinates, and found that it DID send me some, but they are from the top left of the window to the middle of the window only, and are relative. Perhaps they wouldn't be relative if I turn off SDL_MOUSE_RELATIVE, but I'm rather skeptical that that variable does a damn thing, since in my experience it produces no change. However, the values are still only a strange subset of the window, so are useless!

Well this looks more like an irc self-chat now 😉

Anyways, post the current set of modifications (udiff or what you like) and post short information
about what failed movement you get with that (cursor offset in what game/application?)

Also try to post information about what ranges of input you get from the touchpad.

Here's the "stable" changes that work in fullscreen, and in windowed mode but with an offset due to window position:

sdlmain.cpp

1#ifdef WIN32
2#include <signal.h>
3#include <process.h>
4#include <windows.h>
5#include <winuser.h>
6#include "SDL_syswm.h"
7#endif
8(Snip..)
9static void HandleMouseMotion(SDL_MouseMotionEvent * motion) {
10	if (sdl.mouse.locked || !sdl.mouse.autoenable) {
11      POINT p; 
12      GetCursorPos(&p); 
13		Mouse_CursorMoved(0.0f,
14						  0.0f,
15						  (float)(p.x-sdl.clip.x)/(sdl.clip.w-1)*sdl.mouse.sensitivity/100.0f,
16						  (float)(p.y-sdl.clip.y)/(sdl.clip.h-1)*sdl.mouse.sensitivity/100.0f,
17						  sdl.mouse.locked);
18}
19}

mouse.cpp

1emulate = 0;

That's at line 459, just above "if (emulate)" to force it off (until the patch is further in development.

Afraid I don't have experience in making diff patches of any sort, so manual records of changes like this are all I can give ya.

In fullscreen it works 100% perfectly, because there is no window position to affect things. In windowed mode, the coordinate difference between the top left of the window and the top left of the screen seems to be applied to the mouse cursor coordinates, i.e., if the window is 50x50px away from the top left, the mouse cursor will appear 50x50px away from where you click in the DOSBox window.

I've run hundreds of test builds since then (every three to five minutes aside from the 6 hours of sleep I had), modifying mouse.cpp code and sdlmain.cpp code, and could produce no improvement in the results on my own so far, no matter how logical the changes, either the cursor disappears (out of the virtual screen, I imagine, as some builds caused corruption of the image when moving the cursor about.. i.e., shifting color palette.. I think I was toying about in VRAM or RAM - overflows are amusing sometimes) or won't move, sometimes stuck in the top left. Point is, I'm stuck.. Thanks for looking at this.

you might also take a look at the iOS port of Dosbox http://code.google.com/p/dospad/
There might be some hints at how he does the touch screen thing.

And the Android port Re: Dosbox for Android OS

Not sure if that could help, as the iPad, iPod, and iPhone use capacitive touchscreens that may provide a totally different type of coordinates and not need any special changes. I will look, however. Thank you.

Edit: Yeah, they made no changes to the cursor handling code - they fixed it by modifying SDL directly, if they even had anything to fix. I'm not very good at C++, I just started last night brute force, so I'm not confident about jumping into SDL's code as I imagine it's far more complicated and I've already made so much progress here.

Edit 2:
Nothing relevant in the android port either.

I think I'll take the rest of the day off from this, barring wd's return with a response or any others' advice/code to test (this takes priority over relaxation for me). 7 hours or so of solid on it is enough for the moment.

Edit 3:
This was the last attempt I did before answering wd's post - the goal was to compensate for the offset using the difference between the screen content area topleft and the origin point, which would of course result as just the content area topleft coordinates, and subtract them from the mouse coordinates to re-offset the offset since I can't locate it's origin.

1static void HandleMouseMotion(SDL_MouseMotionEvent * motion) { 
2
3   if (sdl.mouse.locked || !sdl.mouse.autoenable) {
4      POINT p; 
5      GetCursorPos(&p); 
6	SDL_SysWMinfo wmi;
7	HWND hwnd = wmi.window;
8	LPRECT rect;
9	GetClientRect(hwnd,rect);
10	int WinX = (int)rect->left;
11	int WinY = (int)rect->top;
12	LOG_MSG("x %d, y %d",WinX,WinY);
13	Mouse_CursorMoved(0.0f, 
14                     0.0f, 
15                    (float)(p.x-WinX),//*sdl.mouse.sensitivity/100.0f, 
16                    (float)(p.y-WinY),//*sdl.mouse.sensitivity/100.0f, 
17                    sdl.mouse.locked); 
18   }
19} 

I just inserted that log line, but it crashes as soon as I click on the window, so I'm unable to garner any data and can't tell why this doesn't work.

Move over to emulate==1, the relative mode (mouse locked) should be the prevalent mode.

I have autolock disabled in the conf file. I'll disable that too I suppose? The reason for emulate=0 is in fullscreen, the emulation code takes over and the cursor data stops it's flow. If what you say works, though, perhaps swapping emulate based on fullscreen vs windowed would be a solution, but needing autolock concerns me. *tests things*

Oh and is your advice targeted at my current testing code or the "stable" code?

Edit: I tested it with the current code and it still crashes, so I'll work on the assumption that you are ignoring those changes, and revert to the older function.

Edit 2: Yes I'm afraid I made that change for many reasons, it makes the cursor immediately stop moving in windowed mode. I honestly don't fully understand why, but it works..

Edit 3: Not sure if you realized this, but I've zeroed out all relative motion input. As I've seen it's always just a tiny number and I'm not sure what exactly it represents, but the relative motion causes psychotic jumping of the cursor and it can't be used. I'm feeding a stream of absolute coordinates (whole screen, not just client area) through the function in sdlmain.cpp, and by disabling the emulation mode, it's taking in the absolute coordinates and applying them to the software cursor. The only problem is that the absolute coordinates seem to be modified somewhere along the line, in windowed mode only (for obvious reasons), with offset data equal to the difference in coordinates between the top left of the dosbox window and the top left of the screen. I think this is because the function(s) were designed to take in relative coordinates, perhaps, but I can't find where it does the work to add that offset.. Since I'm not sure where this is introduced, I've been trying to calculate this offset myself and un-apply it to the coordinate data prior to passing it into the function. This way when it's applied, it has no effect, and the absolute coordinates are still used.

That was the purpose of the experimental code, but it caused crashes for some unknown reason. I've tried dozens of ways of doing this to no avail.

According to the SDL channel there's no way to get the necessary coordinates through SDL.. does DOSBox keep the coordinates of it's window on the screen anywhere?

If you could kindly provide the necessary code to achieve this theoretical solution I'm sure it would work fine, but I can't seem to do it, I'm not competent enough at C++. Alternatively, if you know where, or can find where the offset is added so that I could disable it, that would be an even better solution.

To the best of my ability, analyzing the code in sdlmain.cpp seems to reveal that by feeding absolute coordinates, it translates them into minute relative movements, i.e., in the <1.0 float range.

These are fed into the code in mouse.cpp, where this ends up picking up the trail:

1		} else if ((mouse.max_x < 2048) || (mouse.max_y < 2048) || (mouse.max_x != mouse.max_y)) {
2			if ((mouse.max_x > 0) && (mouse.max_y > 0)) {
3				mouse.x = x*mouse.max_x;
4				mouse.y = y*mouse.max_y;

From what I understand, it's "if there are boundries that aren't square", multiply the now-fractional X and Y values by the maximum boundries and apply them.

In the past I've tried removing the *mouse.max_x portion, and removing the fractionalization, but never both, this may be the key.

*tries*

Not sure if you realized this, but I've zeroed out all relative motion input.

That's exactly what i'm talking about. Instead of using emulate==0 force-enable that to one
and feed relative movement only to that function. You may need some scaling depending
on what absolute values you get from that windows position function.

What do you mean by "crashes"? Don't see anything that should cause hard crashes.

When I tap the stylus on the screen, i.e., begin mouse input value feeding into DOSBox, it was failing. I think I may have just solved the whole thing though, stand by..

The reason I didn't feed things into the relative values is I have no relative values, or didn't think I did. I see where you're going with that but it's a different path than I was trying to take. If this doesn't work I'll re-examine it.

Some sort of strange data manipulation is still going on, but without a logical basis that I can identify. Here's the current code:

mouse.cpp

1void Mouse_CursorMoved(float xrel,float yrel,float x,float y,bool emulate) {
2	float dx = xrel * mouse.pixelPerMickey_x;
3	float dy = yrel * mouse.pixelPerMickey_y;
4
5	if((fabs(xrel) > 1.0) || (mouse.senv_x < 1.0)) dx *= mouse.senv_x;
6	if((fabs(yrel) > 1.0) || (mouse.senv_y < 1.0)) dy *= mouse.senv_y;
7	if (useps2callback) dy *= 2;	
8
9	mouse.mickey_x += dx;
10	mouse.mickey_y += dy;
11	emulate = 0;
12	if (emulate) {
13		mouse.x += dx;
14		mouse.y += dy;
15	} else {
16		if (CurMode->type == M_TEXT) {
17			mouse.x = x*CurMode->swidth;
18			mouse.y = y*CurMode->sheight * 8 / CurMode->cheight;
19		} else if ((mouse.max_x < 2048) || (mouse.max_y < 2048) || (mouse.max_x != mouse.max_y)) {
20			if ((mouse.max_x > 0) && (mouse.max_y > 0)) {
21				mouse.x = x;//*mouse.max_x;
22				mouse.y = y;//*mouse.max_y;
23			} else {
24				mouse.x += xrel;
25				mouse.y += yrel;
26			}
27		} else { // Games faking relative movement through absolute coordinates. Quite surprising that this actually works..
28			mouse.x += xrel;
29			mouse.y += yrel;
30		}
31	}

sdlmain.cpp

1static void HandleMouseMotion(SDL_MouseMotionEvent * motion) { 
2   if (sdl.mouse.locked || !sdl.mouse.autoenable) { 
3      POINT p; 
4      GetCursorPos(&p); 
5      Mouse_CursorMoved(0.0f, 
6                    0.0f, 
7                    (float)p.x,//-sdl.clip.x)/(sdl.clip.w-1)*sdl.mouse.sensitivity/100.0f, 
8                    (float)p.y,//-sdl.clip.y)/(sdl.clip.h-1)*sdl.mouse.sensitivity/100.0f, 
9                    sdl.mouse.locked); 
10} 
11} 

I'd be glad to try your idea of using relative movement, but unless I can get it to not crash when attempting to calculate said movement, it's not possible unless the SDL coordinates are of some use. However, they seem to only provide coordinates from the top left to the exact middle of the window, no further, for some reason.

Is the fractionalized value that the default code creates considered relative movement? Since the SDL input is so radically different from the absolute coordinates, I don't really see how that would produce valid movement, so it must not be.

Here's a video of the current odd behavior. Sorry for the quality, I have no better video recording mechanism (again, if I modify the code to an earlier revision, I can get fullscreen working fine, but windowed either does the relative offset or this):
http://www.youtube.com/watch?v=s2-DxYQ0Z7U

I'm about to do a test, feeding the fractionalized values into the relative movement function..

Edit: Those values are clearly not relative movement, it just slowly moved the cursor down-right no matter what I did with the stylus. I will try to calculate my own relative movements.

Edit 2: No offense, but I really feel I'd have a better shot using absolute coordinates, I've already got it working for fullscreen and just need to solve a window offset. I can't even get the cursor to function with relative coordinates thus far, correctly or no.

If the "only" problem you have is the seemingly scaled movement that can be seen
in your video, then you're already finished: you cannot get rid of that in all circumstances.
Easiest example are games that hide the regular mouse cursor, place the mouse
in the center of the screen, and if the mouse moves they grab the relative movement
and re-place the mouse in the center. They can do anything with the relative
movement they read (even do inverse movement) and that'll never give any sort
of correlation to where your pen on the touchpad is.

Some ideas how you *may* achieve what you're trying: the autolock==false mode
in windowed mode (check how it works in for example xp/win7, uses emulate==0
and tries to use absolute coordinates). It's limited in that it doesn't work for some
games, so be sure to try different games to check effects.

But it works in fullscreen mode, with slightly different code (less modified, actually), with perfect accuracy - no scaled movement, no offset, no problems whatsoever. With that same code, if I move to windowed mode, the offset appears. The code that produces the strange movement in the video was an attempt to remove the offset. Ignoring that, I've got a locked offset equal to the relationship between the window and the 0,0 coordinate of the screen. This relationship is between the window and the cursor. It would seem that there is some niggling bit of code somewhere, that is beginning to infuriate me beyond belief, applying this offset.

I'd not say I'm "done", as the movement in the video is not present in the fullscreen mode with the older code. If it's possible to achieve perfect cursor movement there, it's possible to achieve perfect cursor movement in windowed mode. It's just a matter of finding that offset's source, or counteracting it by reverse-applying it before feeding the values through.

You seemed to get my meaning more easily from the video, so I'll make another illustrating the fullscreen vs. windowed issues with the slightly older "stable" revision of my changes - perhaps you'll realize what is causing it, as I cannot for the life of me figure it out.

Edit:
http://www.youtube.com/watch?v=NjMGoz_0rj4

I realized my camera is on 120p, terrifyingly bad quality - I thought it was at 240p. If I make any further videos on the subject they will be far less blurry.

Edit 2:
To be completely clear, that is this code:
sdlmain.cpp

1#ifdef WIN32
2#include <signal.h>
3#include <process.h>
4#include <windows.h>
5#include <winuser.h>
6#include "SDL_syswm.h"
7#endif
8(Snip..)
9static void HandleMouseMotion(SDL_MouseMotionEvent * motion) {
10	if (sdl.mouse.locked || !sdl.mouse.autoenable) {
11      POINT p; 
12      GetCursorPos(&p); 
13		Mouse_CursorMoved(0.0f,
14						  0.0f,
15						  (float)(p.x-sdl.clip.x)/(sdl.clip.w-1)*sdl.mouse.sensitivity/100.0f,
16						  (float)(p.y-sdl.clip.y)/(sdl.clip.h-1)*sdl.mouse.sensitivity/100.0f,
17						  sdl.mouse.locked);
18}
19}

mouse.cpp

1emulate = 0;

That's at line 459, just above "if (emulate)" to force it off (until the patch is further in development.

I'm not sure if you'd get this synchronized for all games, but the problem in the video
is as you say that the position returned by GetCursorPos is in the desktop coordinate
space rather than the dosbox client window space.

I don't know if there's a function to transfer desktop coordinates to client space
(other than getting the window position and translating the position), or if there is
a different get position function that works for your tablet (SDL functionality???)

SDL's coordinates are broken with touchscreens, hence the use of Windows API features in the first place.

I've had a conversion set up for GetCursorPos's results to transform into relative client area coordinates, the impact was not a positive one, but I don't recall the exact issue.. It was a function called ScreenToClient that I fed an SDL-derived HWND for the program and the original point coordinates to. It transforms them accordingly and places them back into the same variable(s). The problem here, really, was that there's still the anomalous "feature" of DOSBox that translates the coordinates based on window position, which I cannot locate. Thus even when my code is perfect, there is something outside of my code that is sabotaging my efforts.

What I need to solve this (to work around it, to be specific), is the coordinates of the window's content area as compared to the screen. With that data, I could subtract it from the coordinates before putting them in (when in windowed mode), and thus it would be perfect, or close to it. The trouble is the only way I could find to do that was the GetClientRect code in an earlier post, which caused an immediate crash of DOSBox upon moving the mouse within the window.

Put some logging around something like

POINT coord;
GetCursorPos(&coord);
ScreenToClient(hwnd, &coord);

and see if you get (0;0) for the coordinates when you point to the top left of the
dosbox window client area.

Did so and it seems to just be returning the same absolute coordinates (i.e., ~300x~50, not 0,0). *puzzled*

Relevant Code Snippet (sdlmain)

1	SDL_SysWMinfo wmi;
2	SDL_GetWMInfo( &wmi );
3	hwnd = wmi.window;
4	ScreenToClient(hwnd,&p);
5	   LOG_MSG("%d,%d",p.x,p.y);

Edit: I suppose I could try MapWindowPoints (msdn.microsoft.com/en-us/library/dd145046(v=vs.85).aspx) but I don't see why it would work if the other function didn't.