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
On Sat, 17 Jan 2004 20:29:00 +0000, Jason Edmeades wrote:
I'd be worried this may cause more problems than it solves.
Perhaps. I'd be willing to bet that virtually all (gui) win32 apps are tested by running it from explorer or the shell, which seems to use full paths though. So the fact that we usually run without a full path seems to be problematic. I guess there's a slight chance it could break apps designed to be run from the command line in Windows which might make similarly bad assumptions. Perhaps a config option, override-able in appdefaults, which controls passing the full path to the app - on by default.
This leaves the question of where it gets the command line from, of course. If not argv[0], not WinMain, then where? I find it hard to believe the game does a TEB->PEB to get this, given that those structures are undocumented.
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.
I'm sure this would cause mighty flamewars but a compatability db we ship with Wine for obscure/broken/impossible-to-generalise apps might be an idea. Even Microsoft does this with their shims database. I'm not sure how else we're supposed to solve problems like IE setup trying to use a (broken/old) native advapi32, or issues like this where the app is broken but because of the fundamentally different nature of Windows it's never seen.
The appdb isn't really suitable for this IMHO as it mixes up lots of different things - user talking, app rating: advice for running it could easily get buried and there is no way to remove old stuff. If there was a compatability db (perhaps a set of registry entries) it could be held in CVS and updated using patches. Feels messy, but if Windows does it we may have to anyway one day.
thanks -mike
Perhaps. I'd be willing to bet that virtually all (gui) win32 apps are tested by running it from explorer or the shell, which seems to use full paths though.
I'd also bet 5 EUROs ;-)
So the fact that we usually run without a full path seems to be problematic. I guess there's a slight chance it could break apps designed to be run from the command line in Windows which might make similarly bad assumptions. Perhaps a config option, override-able in appdefaults, which controls passing the full path to the app - on by default.
Sounds good.
This leaves the question of where it gets the command line from, of course. If not argv[0], not WinMain, then where? I find it hard to believe the game does a TEB->PEB to get this, given that those structures are undocumented.
Jason wrote:
The one thing I couldnt answer is how the game 'gets' the command line. It doesnt (didnt!) appear to use any API to do it, although I didnt spend long looking into this.
Could it be that the string containing the name of path and exe was not retrieved from the command line, but using GetModuleFileName or GetModuleFileNameEx?
At least I would use this function if would like to get path where my exe is running.
Another idea would be that the crash happens in the startup code or in the (C?) library part. There it could easily be that the PEB is being accessed, because they prepare the arguments for main / WinMain.
If somebody could provide me the problematic exe of DK and the address where the crash occurs I will put it through IDA pro. This might help lifting the mystery. If IDA pro detects which compiler suite has been used to link the EXE, it should be "easy" to detect where the string came from...
-Andy
-
Andreas Rosenberg -
Jason Edmeades -
Mike Hearn