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