I have a small game written in MASM32 and one of my betatesters reported a problem: It says that it can not run the game on WinXP unless he sets "win95 compatibility" mode on for the program. Do you have any ideas what might cause this problem?
I must say that i developed the game on Win98 SE but it works fine on many WinXPs.

Posted on 2003-12-22 16:39:56 by Eugen
post the game if it is small enough.
Posted on 2003-12-22 16:48:25 by evil__donkey
unfortunately i cant post it, i have a contract with a game publisher.

Posted on 2003-12-22 17:14:47 by Eugen
Hi eugen,

It is hard to be specific obviously but I have found that XP reacts very differently to buffers than the other OS versions, be sure that you do not have a buffer over-run and check the return values of memory allocations to be sure that all of the memory requested was allocated. The other thing that I found was that occasionally I would get bizarre problems with mis-aligned data, probably due to XP using some newer processor features. In general if you followed MS spoecifications you will not have a problem, the tried and true shortcuts in Win9x sometimes fail when you run the app in XP.
Posted on 2003-12-22 17:29:08 by donkey
Thanks donkey

I will check for buffer overruns and mis-aligned data (btw, aligned at 4 or 16?) and no, i dont do any win 9x specific tricks (i play by the rules :) ).

Posted on 2003-12-22 17:36:48 by Eugen
Align 4 seems to work for me. By shortcuts I mean not checking the return values, not preserving the three registers (ebx,esi,edi) etc..
Posted on 2003-12-22 17:54:24 by donkey
I haven't run into any structs that requied more than 4byte align (which isn't too strange, as just about every win32 C/C++ has 4byte alignment as default). Of course SSE requires stricter alignment, but that's a different matter :)

Be certain stack isn't misaligned - always work with 32bit multiples when dealing with the stack.
Make sure wndproc/dlgprocs behave... calling the default window proc, or dlgproc returning proper values.

It would also help if you could narrow down the problem a bit... "doesn't work" is pretty damn vague. Does it crash? Refuse to load? Something else? Which subsystem causes (or is likely to cause) the error?
Posted on 2003-12-22 19:31:51 by f0dder
Unfortunately it is even more frustating for me as i dont have yet direct contact with the betatesters and what i told you is as much as i know... of course i will try to find more precise info.
I was hoping that this problem (working only with "win95 compatibility" ) would ring a bell, one of you could recognize a specific problem, and not a general XP programming issues. (silly me.. :) )


Posted on 2003-12-22 21:26:10 by Eugen
Also the funny part is that it works on many XPs in exactly the same conditions (DX version,video card,etc) but on one of them this problem appears. Also i have a similar problem on a win2k machine with a dual PIII ... still this is a singular situation i believe. Is multithreading behaving diferently on dual processors from the programmers point of view?

Posted on 2003-12-22 21:33:04 by Eugen
From a programmers point of view multiprocessors is not *supposed* to make a difference. The OS will run the threads in different processors if they are available or in time slices if not. Could be a thread synchronization problem that only appears in multiple processors because of independant execution of the threads. Maybe the XP box that is having the problem has a P4HT and it is the same problem as the dual processor one.

Mmmm, thinking about this, I believe that Win95 compatibility will limit the execution to a single processor even on a dual system. I think that you might be getting close to the root of the problem. The actual cause is another story. I would start hunting down synchronisation problems. You might want to try to run QFixApp on the executable to find out which of the changes made in compat mode are the ones that are necessary, it will help you narrow the search.

Posted on 2003-12-22 23:45:29 by donkey
buna ziua

another possibility - do you use .const in your data declarations?
i think that Win 9* lets us write to .const while xp prevents it
this is very easy to see if you're debugging your own code but could be mystifying to a tester

of course, MASM sends a warning for a direct write:


ShouldNotWriteToThis dd 0


mov [ShouldNotWriteToThis],value

but not for an indirect:

mov edi,offset ShouldNotWriteToThis

mov [edi],value
Posted on 2003-12-23 05:04:52 by eGo
thanks i will check QFixApp

buna ziua :)
and no i dont use ".const" in my app.

Posted on 2003-12-23 17:06:25 by Eugen