Need help debugging ... Ddraw issue
us at the-edmeades.demon.co.uk
Sat Jan 17 14:29:00 CST 2004
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,
>Ok, that here is exactly the problem (dlls/kernel/environ.c), it's
explained in the remark of the func:
>* * 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
> * 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
More information about the wine-devel