Need help debugging ... Ddraw issue

[Jason Edmeades]

Wow, lots of updates, and rather than reply to each let me try to summarize.

 >> The one thing I couldnt answer is how the game 'gets' the command line.
 >int WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR 
lpCmdLine, int nCmdShow ); Perhaps this way?
No, I noticed the difference between the exe hdrs, (console vs gui) and 
I ran some tests on this, and the value in lpCmdLine seemed to be just 
the parms and not the "command line" / executable name. Thats why I then 
went on to try GetCommandLine and spotted that issue. Nice idea though, 
thanks

 >Ok, that here is exactly the problem (dlls/kernel/environ.c), it's 
explained in the remark of the func:
 >GetCommandLineA (KERNEL32.@)
 >* * WARNING: there's a Windows incompatibility lurking here !
 >* Win32s always includes the full path of the program file,
 >* whereas Windows NT only returns the full file path plus arguments
 >* in case the program has been started with a full path.
 >* Win9x seems to have inherited NT behaviour.

I read that as saying Win32s just provides the path and probably exe 
name and Winnt provides the full path, exe and parms. You may be 
correct, I didnt investigate this further.

 >> With some experimentation with a GUI pgm I think I stumbled upon the /
 >> an answer: > Bug#1 - GetCommandLine() returns a full path on Windows 
but no path on Wine Doh.
 >Well this should definately be fixed anyway (with a regression test), 
and it does sound a lot like the problem doesn't it?
 >I expect we use this API (or similar) to set the parameters to WinMain

Yes, but I didnt see any evidence it was being called. I may have missed 
it.. However I think this is also a red herring...

 > * Note that both Start Menu Execute and Explorer start programs with
 > * fully specified quoted app file paths, which is why probably the 
only case
 > * where you'll see single file names is in case of direct launch
 > * via CreateProcess or WinExec.

This may be the real issue - I was running it from within msdev.exe 
which works, but launching it from the command line does trap the same 
way.  "Windbg keeper95.exe" traps on run, but windbg, ctrl+e (open exe) 
doesnt, and I think thats because the file dialog returns fully 
qualified paths (at a guess).

 >I wonder if when a program is invoked directly from the wine loader 
app we should pretend
 >it's been run from Explorer and pass it the full path. Alexandre, 
would that be an acceptable
 >solution (subject to more thorough testing of course).

I'd be worried this may cause more problems than it solves. This is an 
interesting one in that wine *does* correctly emulate windows behaviour, 
but the app is broken to only expect a full path. Aside from an app 
specific option (perhaps we could add in app specific config options 
into a central compatibility ini file), I think the only way to capture 
this is to document in eg. the appDB.

 >"Some debugging" is a bit vague but I'll let you off that ;) I guess I 
just need to get better at reading disassemblies.
It certainly helps as I frequently drop down to assembler when things 
get confusing (my 'real' job involves lots of debugging!). I wish I was 
better with eg. gdb syntax as I really am mostly a Windows person so far 
(Boo Hiss...)!

Jason