Hope you dont mind, I was bored and its a small download (DK1).
The disassembly of the failure shows we have written to eax, and info regs shows eax of 0x00. dis 0x4e4a20 shows the routine where the return value is set up in eax, and some debugging shows the initial problem is a path problem. The routine parses the input path which inder windows is c:\path\to\KEEPER95.exe and under wine is KEEPER95. It searches backwards for the last backslash and returns a pointer to the backslash or 0x00. If 0x00, the trap occurs...
Now the question is where does the full path come from.
Jason
The disassembly of the failure shows we have written to eax, and info regs shows eax of 0x00. dis 0x4e4a20 shows the routine where the return value is set up in eax, and some debugging shows the initial problem is a path problem. The routine parses the input path which inder windows is c:\path\to\KEEPER95.exe and under wine is KEEPER95. It searches backwards for the last backslash and returns a pointer to the backslash or 0x00. If 0x00, the trap occurs...
Now the question is where does the full path come from.
Hmmm.
Following the path we are playing with back a bit, it is built up and looks extremely like the command line (Since if I add command line options, they are added as an array to where this comes from).. In fact, I can get back to an address where at the very first breakpoint the full path is in the place it will be eventually copied from.
Now a simple test pgm: void main(int count, char *argv[]) { printf("Argv[0] = %s\n", argv[0]); }
Shows that you only get the program name when run, so it leaves the question how the full path is supplied.
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
Bug#2 (which will fix bug #1) - Wines PEB stores the short path not the full path Playing with windbg (then ctrl+E to load executable), the peb on windows shows the peb->CommandLine is the full path. I suspect this must be the bug then, but I cant see the app is accessing this, unless it goes to the PEB directly. eg: 0:000> !peb PEB at 7ffdf000 WindowTitle: 'C:\temp\wine\dk\test.exe' ImageFile: 'C:\temp\wine\dk\test.exe' CommandLine: 'C:\temp\wine\dk\test.exe '
However, changing anything to do with paths on wine is an art form to itself, so I will leave the fix to someone else!
Note: wine C:\DK\KEEPER95 gets things significantely further (flash screen) before the next crash.
Thats it for me on this problem, Sorry! Jason
PS Anyone know if MSDEV has the ability to debug pgms under wine yet? PPS I really wish the winedbg had a memory dump routine (bytes + ascii)... is it possible with the cmd set available?
Note: wine C:\DK\KEEPER95 gets things significantely further (flash screen) before the next crash.
Thats it for me on this problem, Sorry! Jason
Bed? Whats that... I just couldnt resist.
The next problem is ddraw surface fails swhen the main surface is destroyed and it has an attached palette. This is Lionels area and I really dont understand the code, but commenting out dlls\ddraw\dsurface\main.c, line 106 ie: if (This->palette) { /* Bug here: IDirectDrawPalette_Release(ICOM_INTERFACE(This->palette, IDirectDrawPalette));*/ This->palette = NULL; } Gets things working (There's probably a memory leak here too though). Then you have a weird mouse problem whereby the mouse will only go down and right BUT the game is up and running as far as the menu and you can go to eg the options panel etc.
So to summarize Run DK1 with wine <fullpath>\KEEPER95 With the line above commented out
Thats really it, Jason
Hy Jason
Really cool man! I was following your posts here in real time and you almost found solutions faster than I could try them out, LOL!
I can confirm that the screen switches and a picture shows up when using full win-path and the mouse acts weird. Haven't tried commenting out anything yet. I'm trying to investigate that GetCommandLine thing. So far I grep'd through the wine code but only found extern GetCommandLineA decls.
Le ven 16/01/2004 à 19:40, Frank Schruefer a écrit :
Hy Jason
Really cool man! I was following your posts here in real time and you almost found solutions faster than I could try them out, LOL!
I can confirm that the screen switches and a picture shows up when using full win-path and the mouse acts weird. Haven't tried commenting out anything yet. I'm trying to investigate that GetCommandLine thing. So far I grep'd through the wine code but only found extern GetCommandLineA decls.
Use tools/findfunc rather than grep to find Win32 functions in the Wine tree.
Vincent
Use tools/findfunc rather than grep to find Win32 functions in the Wine tree.
Cool, that saves me from creating crazy grep constructs. Thanks for the tip. Think I'll investigate the contents of the tools dir a bit further now ...
On Fri, 16 Jan 2004 20:02:08 -0500, Vincent Béron wrote:
Use tools/findfunc rather than grep to find Win32 functions in the Wine tree.
Or better, make tags/make etags - I find this works very well.
Mike Hearn wrote:
On Fri, 16 Jan 2004 20:02:08 -0500, Vincent Béron wrote:
Use tools/findfunc rather than grep to find Win32 functions in the Wine tree.
Or better, make tags/make etags - I find this works very well.
Frank Schruefer wrote:
Hy Jason
Really cool man! I was following your posts here in real time and you almost found solutions faster than I could try them out, LOL!
I can confirm that the screen switches and a picture shows up when using full win-path and the mouse acts weird. Haven't tried commenting out anything yet. I'm trying to investigate that GetCommandLine thing. So far I grep'd through the wine code but only found extern GetCommandLineA decls.
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. * * 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. * * Perhaps we should take care of Win3.1 programs here (Win32s "feature"). * * References: MS KB article q102762.txt (special Win32s handling) */ LPSTR WINAPI GetCommandLineA(void) ...
But now what to do? Low and behold I remembered that I once saw a wine config option ... and here is the part of the wine config that should influence the behaviour of the above func:
[Version] ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win20,win30,win31) ; "Windows" = "win98" ; DOS version to imitate ;"DOS" = "6.22"
I tried to set 'Windows' to 'win98' and 'win2k', but that didn't make a difference, as expected when looking at the 'GetCommandLineA' source.
I think the right thing would be to make 'GetCommandLineA' looking at the config how it should behave and decide in which style the value should be returned.
But that there's no default setting in this version block makes me think maybe wine has a possibility to guess for which OS the executed prog was written and sets this config option automatically if not set in the config?
Suggestions?
(REPOST, somehow this message yesterday didn't go through until now, strange! Sorry if you may get it twice.)
Frank Schruefer wrote:
Hy Jason
Really cool man! I was following your posts here in real time and you almost found solutions faster than I could try them out, LOL!
I can confirm that the screen switches and a picture shows up when using full win-path and the mouse acts weird. Haven't tried commenting out anything yet. I'm trying to investigate that GetCommandLine thing. So far I grep'd through the wine code but only found extern GetCommandLineA decls.
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. * * 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. * * Perhaps we should take care of Win3.1 programs here (Win32s "feature"). * * References: MS KB article q102762.txt (special Win32s handling) */ LPSTR WINAPI GetCommandLineA(void) ...
But now what to do? Low and behold I remembered that I once saw a wine config option ... and here is the part of the wine config that should influence the behaviour of the above func:
[Version] ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win20,win30,win31) ; "Windows" = "win98" ; DOS version to imitate ;"DOS" = "6.22"
I tried to set 'Windows' to 'win98' and 'win2k', but that didn't make a difference, as expected when looking at the 'GetCommandLineA' source.
I think the right thing would be to make 'GetCommandLineA' looking at the config how it should behave and decide in which style the value should be returned.
But that there's no default setting in this version block makes me think maybe wine has a possibility to guess for which OS the executed prog was written and sets this config option automatically if not set in the config?
Suggestions?
Frank Schruefer wrote:
(REPOST, somehow this message yesterday didn't go through until now, strange! Sorry if you may get it twice.)
You are not subscribed to the list as Frank.Schruefer@t-online.de, so your postings go through moderation.
Frank Schruefer wrote:
But now what to do?
Suggestions?
Shouldn't the WINE exe loader imitate the behavior of an application being started by the Explorer in Windows? I don't know if this is a possible solution, but this seems to be the most "compatible" one. I think the NT behavior is that a child process should get the command line, like it was provided by the parent process.
To me it look's not correct to fix GetCommandLineA, but what's being passed to CreateProcess. This also the point, where you can decide if you are starting a Win32(s) or a Win16 application (and you can manipulate the commandline accordingly). If you add a config option that only changes the behavior of GetCommandLineA you would have a difference what you get as parameter for lpCmdLine via WinMain and what you get via GetCommandLineA!
- WARNING: there's a Windows incompatibility lurking here !
- Win32s always includes the full path of the program file,
Did anybody check if this is true if the process has been created with "CreateProcess" without a complete path. Does the Win32s layer in Win3.1 manipulate the commandline?
Andy
Frank Schruefer wrote:
Hy Jason
Really cool man! I was following your posts here in real time and you almost found solutions faster than I could try them out, LOL!
I can confirm that the screen switches and a picture shows up when using full win-path and the mouse acts weird. Haven't tried commenting out anything yet. I'm trying to investigate that GetCommandLine thing. So far I grep'd through the wine code but only found extern GetCommandLineA decls.
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. * * 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. * * Perhaps we should take care of Win3.1 programs here (Win32s "feature"). * * References: MS KB article q102762.txt (special Win32s handling) */ LPSTR WINAPI GetCommandLineA(void) ...
But now what to do? Low and behold I remembered that I once saw a wine config option ... and here is the part of the wine config that should influence the behaviour of the above func:
[Version] ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win20,win30,win31) ; "Windows" = "win98" ; DOS version to imitate ;"DOS" = "6.22"
I tried to set 'Windows' to 'win98' and 'win2k', but that didn't make a difference, as expected when looking at the 'GetCommandLineA' source.
I think the right thing would be to make 'GetCommandLineA' looking at the config how it should behave and decide in which style the value should be returned.
But that there's no default setting in this version block makes me think maybe wine has a possibility to guess for which OS the executed prog was written and sets this config option automatically if not set in the config?
Suggestions?
On Sat, 17 Jan 2004 15:00:55 +0100, Frank Schruefer wrote:
- 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.
Awwww crud.
So basically the reason Keeper crashes is because it expects to be run from explorer? I wonder if it crashes on Windows if you run it from command.com in that directory, ie without a full path.
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).
thanks -mike
Could you see if it runs ok when launched with winecfg ?
--- Mike Hearn mike@theoretic.com a écrit :
Awwww crud.
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).
thanks -mike
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels
"You believe it's the year 1984, when in fact, its closer to 2184"1984 / Matrix
_________________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
PS Anyone know if MSDEV has the ability to debug pgms under wine yet?
windbg used to run (it was a long time ago, and I didn't check recently). At least, the debugging API was ok. YMMV.
PPS I really wish the winedbg had a memory dump routine (bytes + ascii)... is it possible with the cmd set available?
check the 'x' command (x for examine, same syntax as gdb's)
A+
On Fri, 16 Jan 2004 23:19:33 +0000, Jason Edmeades wrote:
The disassembly of the failure shows we have written to eax, and info regs shows eax of 0x00. dis 0x4e4a20 shows the routine where the return value is set up in eax, and some debugging shows the initial problem is a path problem.
You're significantly better at this than I am! "Some debugging" is a bit vague but I'll let you off that ;) I guess I just need to get better at reading disassemblies.
Hmmm.
Following the path we are playing with back a bit, it is built up and looks extremely like the command line (Since if I add command line options, they are added as an array to where this comes from).. In fact, I can get back to an address where at the very first breakpoint the full path is in the place it will be eventually copied from.
Now a simple test pgm: void main(int count, char *argv[]) { printf("Argv[0] = %s\n", argv[0]); }
Shows that you only get the program name when run, so it leaves the question how the full path is supplied.
Are you sure that's the prototype of the entry point? I suspect it's actually a WinMain as Andreas suggested... that would make sense, you don't need to make an API call to get the path then.
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.
thankyou very much! I learnt something today -mike
-
Andreas Rosenberg -
Duane Clark -
Eric Pouech -
Frank.Schruefer＠t-online.de -
Jason Edmeades -
Mike Hearn -
Sylvain Petreolle -
Vincent Béron