Hi all,
There are just two (unrelated) points that I would like to discuss:
= the possibility to add a 'wine' launcher. Basically what happens is that some (maybe only one :-) ) application takes as an assumption that it is started via 'double clicking' on the .EXE file or via the installed link. From what I know, both these actions will start the game from its .EXE directory and with the full qualified path as the exe name.
So the application crashes if you start it with 'wine foo.exe', you need to type 'wine D:\Foo\foo.exe' to get it running.
One could then imagine having either 'wine' be a launcher that qualifies the name, changes to the good directory and just start the 'real' wine or do the reverse: publicize to new users that they should use 'winelaunch' to start applications and keep 'wine' how it is now.
= in the current Wine tree, if Wine crashes, some persistant X settings are changed (for example desktop resolution for people using XRandR)... And as most people do not know the 'xrandr' command line tool, they tend to kill X to restore their resolution (which tends to annoy them :-) ).
In the same vein, I would like to disable mouse acceleration when DInput mode is entered but actually fear to do so for the above-mentionned reasons (I fear gettint these kind of lines in the IRC channels: 'Wine is crap, when it exits, I need to restart X to get my mouse acceleration back'). Well, there is 'xset' but most 'normal' users have no idea that it even exists...
For that one, the most robust way would be at the X level (basically having 'connection-linked' configurations - i.e. the settings has changed up until the point in time that the client quits) but if we do not want to change X, the most robust way would be to do it at the wineserver level (I often get Wine crashing, it's more rare to get the server to crash). Of course, injecting X code in the server is maybe not to AJ's liking :-)
So the other solution would be to be able to hook somehow some 'clean-up' functions from DLLs to the Wine process that could be called when Wine exits (whether normally or when crashing). Of course, people 'kill-9'ing their Wine would get nothing but I do not think it's really a problem.
Lionel (in rant mode :-) )
Lionel Ulmer wrote:
Hi all,
There are just two (unrelated) points that I would like to discuss:
= the possibility to add a 'wine' launcher. Basically what happens is that some (maybe only one :-) ) application takes as an assumption that it is started via 'double clicking' on the .EXE file or via the installed link. From what I know, both these actions will start the game from its .EXE directory and with the full qualified path as the exe name.
So the application crashes if you start it with 'wine foo.exe', you need to type 'wine D:\Foo\foo.exe' to get it running.
One could then imagine having either 'wine' be a launcher that qualifies the name, changes to the good directory and just start the 'real' wine or do the reverse: publicize to new users that they should use 'winelaunch' to start applications and keep 'wine' how it is now.
Changing the directory is not a correct solution. Consider what would happen if user wants to perform an operation on a file in the current directory, and specifies the filename as a relative path. The program would start in the wrong directory and would not find the file.
Maybe the program is checking the base directory of the EXE file from argv[0] in its main function, in order to load some resource from itself or from a companion file. However this is something that should be done inside wine (that is, providing a full DOS path to the executable file for the program's argv[0]), not via a launcher. Could you please indicate which application has this behavior? Can you provide a download URL? Have you tested booting Windows, then opening a DOS window, switching to the program directory and running it as in:
C:> D: D:> cd Foo D:\Foo>Foo
If the program works like this in native, then this should also be done in wine, and you have discovered an application that relies on an (still) unimplemented behavior in Wine.
BTW, have you tried "wine ./foo.exe", as opposed to "wine foo.exe"?
Could you please indicate which application has this behavior? Can you provide a download URL?
All info here: http://bugs.winehq.org/show_bug.cgi?id=3542
Lionel (will answer to your other points after some more tests in Windows :-) )
Lionel Ulmer wrote:
Could you please indicate which application has this behavior? Can you provide a download URL?
All info here: http://bugs.winehq.org/show_bug.cgi?id=3542
Lionel (will answer to your other points after some more tests in Windows :-) )
The page says that you have a patch that fixes something. Is that the issue about the executable path name, or the one about the game refusing to go past the splash screen, or the one about the mouse cursor?
On Thu, Oct 27, 2005 at 04:17:17PM -0500, Alex Villacís Lasso wrote:
The page says that you have a patch that fixes something. Is that the issue about the executable path name, or the one about the game refusing to go past the splash screen, or the one about the mouse cursor?
It's only fixing the mouse cursor issue.
Lionel
Lionel Ulmer wrote:
On Thu, Oct 27, 2005 at 04:17:17PM -0500, Alex Villacís Lasso wrote:
The page says that you have a patch that fixes something. Is that the issue about the executable path name, or the one about the game refusing to go past the splash screen, or the one about the mouse cursor?
It's only fixing the mouse cursor issue.
Lionel
This is a patch to fix the primary bug on DungeonKeeper. I am surprised this bug was overlooked up to 0.9, since this is such a basic characteristic of Windows.
The basic problem is that Wine is passing the argv[] array unmodified (except for the removal of the 'wine' reference itself) to the PE process. This means that, unless the user writes a DOS-style path at wine invocation, the PE process receives an UNIX-style relative path as its argv[0]. This differs from standard behavior in MS-DOS and Windows, where the argv[0] of the process contains a fully qualified DOS-style path (such as C:\WINDOWS\FOO.EXE) regardless of the method used to run the executable. DungeonKeeper relies on this characteristic of MS-DOS/Windows and crashes when it sees the UNIX-style path.
This patch will also be sent to wine-patches, as a fix for one of the issues of bug 3542.
Note that the patch, as it stands, only fixes PE executables. Winelib applications continue to receive an UNIX-style path. I don't really know whether this is the right thing to do, but winelib apps surely know that they are running in an Unix environment, so they know how to deal with an Unix-style argv[0]. However, this poses the question of how to write a test for this bug, since all tests are winelib applications.
BTW, could you please post the mouse-cursor issue patch? I also have a Japanese RPG for which the mouse cursor gets stuck at the center of the window, and I think that problem and the one in DungeonKeeper might be one and the same.
Changelog: * Force a copy of the fully-qualified DOS-style executable path into argv[0] of the current PE process.
On Mon, 31 Oct 2005 12:08:36 -0500, Alex Villacís Lasso wrote:
This is a patch to fix the primary bug on DungeonKeeper. I am surprised this bug was overlooked up to 0.9, since this is such a basic characteristic of Windows.
I think the conclusion last time we looked at this was that this is actually a characteristic of Explorer, not Windows, and so it's really caused by the fact that most Wine users run the apps from the command line not via the shortcuts. If you run Dungeon Keeper in the wrong way from the command line in Windows it'll crash too IIRC.
thanks -mike
Mike Hearn wrote:
On Mon, 31 Oct 2005 12:08:36 -0500, Alex Villacís Lasso wrote:
This is a patch to fix the primary bug on DungeonKeeper. I am surprised this bug was overlooked up to 0.9, since this is such a basic characteristic of Windows.
I think the conclusion last time we looked at this was that this is actually a characteristic of Explorer, not Windows, and so it's really caused by the fact that most Wine users run the apps from the command line not via the shortcuts. If you run Dungeon Keeper in the wrong way from the command line in Windows it'll crash too IIRC.
thanks -mike
Sorry to disagree, but I have seen this behavior (fully qualified name in argv[0]) since MS-DOS and Windows 3.1. Even some old C tutorial books mention it in passing. I have also replicated this behavior from the command line (COMMAND.COM) in MS-Windows 98 in a DOS box, without using Explorer. My sample app prints out the argv[] array and it consistenly shows a fully qualified path to the executable in argv[0], even when run from a DOS box.
Alex Villacís Lasso
Alex writes:
... >> >> Alex> Sorry to disagree, but I have seen this behavior Alex> (fully qualified name in argv[0]) since MS-DOS and Alex> Windows 3.1. Even some old C tutorial books mention Alex> it in passing. I have also replicated this behavior Alex> from the command line (COMMAND.COM) in MS-Windows Alex> 98 in a DOS box, without using Explorer. My sample Alex> app prints out the argv[] array and it consistenly Alex> shows a fully qualified path to the executable in Alex> argv[0], even when run from a DOS box.
Alex,
can you please look at wine/dlls/kernel/test/process /* Test for Bug1330 to show that XP doesn't change '/' to '\' in argv[0]*/
Perhaps you can add a test case for your observation...
Bye
Alex Villacís Lasso [email protected] writes:
Sorry to disagree, but I have seen this behavior (fully qualified name in argv[0]) since MS-DOS and Windows 3.1. Even some old C tutorial books mention it in passing. I have also replicated this behavior from the command line (COMMAND.COM) in MS-Windows 98 in a DOS box, without using Explorer. My sample app prints out the argv[] array and it consistenly shows a fully qualified path to the executable in argv[0], even when run from a DOS box.
It's OK to change argv[0] when started from a Unix shell, but not when started from another Windows process. Your patch does it in all cases, which is not correct.
Alexandre Julliard wrote:
Alex Villacís Lasso [email protected] writes:
Sorry to disagree, but I have seen this behavior (fully qualified name in argv[0]) since MS-DOS and Windows 3.1. Even some old C tutorial books mention it in passing. I have also replicated this behavior from the command line (COMMAND.COM) in MS-Windows 98 in a DOS box, without using Explorer. My sample app prints out the argv[] array and it consistenly shows a fully qualified path to the executable in argv[0], even when run from a DOS box.
It's OK to change argv[0] when started from a Unix shell, but not when started from another Windows process. Your patch does it in all cases, which is not correct.
Sounds reasonable. What is the proper way to tell apart the two cases?
Alex Villacís Lasso [email protected] writes:
Alexandre Julliard wrote:
It's OK to change argv[0] when started from a Unix shell, but not when started from another Windows process. Your patch does it in all cases, which is not correct.
Sounds reasonable. What is the proper way to tell apart the two cases?
I would suggest something like this:
Index: dlls/kernel/process.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/kernel/process.c,v retrieving revision 1.109 diff -u -p -r1.109 process.c --- dlls/kernel/process.c 10 Oct 2005 10:28:48 -0000 1.109 +++ dlls/kernel/process.c 31 Oct 2005 21:43:46 -0000 @@ -515,19 +515,23 @@ static void set_registry_environment(voi */ static void set_library_wargv( char **argv ) { - int argc; + int argc, first = 0; char *q; WCHAR *p; WCHAR **wargv; DWORD total = 0;
- for (argc = 0; argv[argc]; argc++) + /* if we didn't get a command line from our parent, + * force argv[0] to be the path of the main binary */ + if (argv[0] && !NtCurrentTeb()->Peb->ProcessParameters->CommandLine.Buffer) first = 1; + + for (argc = first; argv[argc]; argc++) total += MultiByteToWideChar( CP_UNIXCP, 0, argv[argc], -1, NULL, 0 );
wargv = RtlAllocateHeap( GetProcessHeap(), 0, total * sizeof(WCHAR) + (argc + 1) * sizeof(*wargv) ); p = (WCHAR *)(wargv + argc + 1); - for (argc = 0; argv[argc]; argc++) + for (argc = first; argv[argc]; argc++) { DWORD reslen = MultiByteToWideChar( CP_UNIXCP, 0, argv[argc], -1, p, total ); wargv[argc] = p; @@ -535,6 +539,7 @@ static void set_library_wargv( char **ar total -= reslen; } wargv[argc] = NULL; + if (first) wargv[0] = NtCurrentTeb()->Peb->ProcessParameters->ImagePathName.Buffer;
/* convert argv back from Unicode since it has to be in the Ansi codepage not the Unix one */
I think the conclusion last time we looked at this was that this is actually a characteristic of Explorer, not Windows, and so it's really caused by the fact that most Wine users run the apps from the command line not via the shortcuts. If you run Dungeon Keeper in the wrong way from the command line in Windows it'll crash too IIRC.
Yes this is what I wanted to test as I brought my Windows laptop home: i.e. start the application from the Explorer, from a shortcut, from a DOS windows, from a .... a get in all cases what 'argv[0]' is and the current work dir.
Lionel
Alex Villacís Lasso wrote:
This differs from standard behavior in MS-DOS and Windows, where the argv[0] of the process contains a fully qualified DOS-style path (such as C:\WINDOWS\FOO.EXE) regardless of the method used to run the executable.
This means that [...] the PE process receives an UNIX-style relative path as its argv[0].
Mike Hearn wrote:
I think the conclusion last time we looked at this was that this is actually a characteristic of Explorer, not Windows, and so it's really caused by the fact that most Wine users run the apps from the command line not via the shortcuts. If you run Dungeon Keeper in the wrong way from the command line in Windows it'll crash too IIRC.
Uhm. Explain to me how the above ratifies _not_ converting the Unix-style path to a Windows-style path before handing it to the app? We ARE trying to emulate Windows, are we not?
On Mon, Oct 31, 2005 at 07:18:24PM +0100, Molle Bestefich wrote:
Uhm. Explain to me how the above ratifies _not_ converting the Unix-style path to a Windows-style path before handing it to the app? We ARE trying to emulate Windows, are we not?
There is a difference between converting an Unix-style path to a Windows-style patch and converting between an Unix-style relative path to a fully-qualified Windows path.
Basically, the question here is whether argv[0] contains always a full-qualified path or can it contain a relative path.
Lionel
"Molle" == Molle Bestefich [email protected] writes:
...
Molle> Uhm. Explain to me how the above ratifies _not_ converting the Molle> Unix-style path to a Windows-style path before handing it to the Molle> app? We ARE trying to emulate Windows, are we not?
Please verify your speculations with test cases (dll/kernel/tests/process.c)
Bye
On Mon, 2005-10-31 at 19:18 +0100, Molle Bestefich wrote:
Uhm. Explain to me how the above ratifies _not_ converting the Unix-style path to a Windows-style path before handing it to the app? We ARE trying to emulate Windows, are we not?
Cut the sarcasm please, there's no need for that here. I've been involved with Wine for several years now and am quite aware of the goals.
Imagine the case of an app which changes to its program directory and then does CreateProcess(..., "foo.exe", ...) and "foo.exe" assumes argv[0] will not be absolute. This sort of thing happens.
Blindly changing argv[0] to always be of one form could break as much as it fixes. In Wine, you *never* make such assumptions, instead you do what Lionel said he wanted to do and test the actual behaviour (preferably with unit tests to go with it). Then if we determine that the problem is with apps that expect to be started by Explorer and not via the command line, we can fix it (probably by making user-invoked wine processes loop back through start.exe and changing the behaviour there, but there might be another way).
thanks -mike
On 10/31/05, Mike Hearn [email protected] wrote:
On Mon, 31 Oct 2005 12:08:36 -0500, Alex Villacís Lasso wrote:
This is a patch to fix the primary bug on DungeonKeeper. I am surprised this bug was overlooked up to 0.9, since this is such a basic characteristic of Windows.
I think the conclusion last time we looked at this was that this is actually a characteristic of Explorer, not Windows, and so it's really caused by the fact that most Wine users run the apps from the command line not via the shortcuts. If you run Dungeon Keeper in the wrong way from the command line in Windows it'll crash too IIRC.
This is a quite interesting theory. So I went ahead and tried to launch LogicWorks with a "windows" method in wine, and well, I've failed so far with wine's ProgMan.exe. The progman crashes anyway I've tried.
So I boot to windows and try logicworks from cmd.exe. Indeed, I hit the same bug as in wine. So what we have are programs that expect a certain behavior and the command line doesn't do it. Bad design.
So could we have a program or launcher in wine to launch programs the "windows" way?
Jesse
Jesse Allen wrote:
On 10/31/05, Mike Hearn [email protected] wrote:
On Mon, 31 Oct 2005 12:08:36 -0500, Alex Villacís Lasso wrote:
This is a patch to fix the primary bug on DungeonKeeper. I am surprised this bug was overlooked up to 0.9, since this is such a basic characteristic of Windows.
I think the conclusion last time we looked at this was that this is actually a characteristic of Explorer, not Windows, and so it's really caused by the fact that most Wine users run the apps from the command line not via the shortcuts. If you run Dungeon Keeper in the wrong way from the command line in Windows it'll crash too IIRC.
This is a quite interesting theory. So I went ahead and tried to launch LogicWorks with a "windows" method in wine, and well, I've failed so far with wine's ProgMan.exe. The progman crashes anyway I've tried.
So I boot to windows and try logicworks from cmd.exe. Indeed, I hit the same bug as in wine. So what we have are programs that expect a certain behavior and the command line doesn't do it. Bad design.
So could we have a program or launcher in wine to launch programs the "windows" way?
Jesse
Hmmm... this raises doubts on whether the behavior should be implemented at all. What version of Windows are you using? Does your version supply a COMMAND.COM (in WinXP, it is at c:\windows\system32)? Have you tried running your program from COMMAND.COM? I would guess that COMMAND.COM supplies a fully qualified path to the executable file (as in MS-DOS and Windows 9x), but WinNT/WinXP do not when CMD.EXE is used (???). Then, explorer.exe supplies the fully qualified path at all times - that is why the programs do not crash when started from the shortcuts.
So, what should be the policy in Wine? Should Wine supply the qualified name at all (I still think it should)? Mr. Julliard sent a patch proposal that conditionally sets the name. I will try it at home and report on it tomorrow.
Alex Villacís Lasso
On 10/31/05, Alex Villacís Lasso [email protected] wrote:
Jesse Allen wrote:
This is a quite interesting theory. So I went ahead and tried to launch LogicWorks with a "windows" method in wine, and well, I've failed so far with wine's ProgMan.exe. The progman crashes anyway I've tried.
So I boot to windows and try logicworks from cmd.exe. Indeed, I hit the same bug as in wine. So what we have are programs that expect a certain behavior and the command line doesn't do it. Bad design.
Hmmm... this raises doubts on whether the behavior should be implemented at all. What version of Windows are you using?
WinXP
Does your version supply a COMMAND.COM (in WinXP, it is at c:\windows\system32)? Have you tried running your program from COMMAND.COM? I would guess that COMMAND.COM supplies a fully qualified path to the executable file (as in MS-DOS and Windows 9x), but WinNT/WinXP do not when CMD.EXE is used (???).
I tried command.com and it does not provide a full path in argv[0], I believe. I'm gonna write a test program.
Then, explorer.exe supplies the fully qualified path at all times - that is why the programs do not crash when started from the shortcuts.
So, what should be the policy in Wine? Should Wine supply the qualified name at all (I still think it should)? Mr. Julliard sent a patch proposal that conditionally sets the name. I will try it at home and report on it tomorrow.
I think 'wine' should launch like explorer by default, and wine's cmd should launch like window's cmd. A winecfg per-app setting could work too but I don't like that as much.
Jesse
Jesse Allen wrote:
On 10/31/05, Alex Villacís Lasso [email protected] wrote:
Jesse Allen wrote:
This is a quite interesting theory. So I went ahead and tried to launch LogicWorks with a "windows" method in wine, and well, I've failed so far with wine's ProgMan.exe. The progman crashes anyway I've tried.
So I boot to windows and try logicworks from cmd.exe. Indeed, I hit the same bug as in wine. So what we have are programs that expect a certain behavior and the command line doesn't do it. Bad design.
Hmmm... this raises doubts on whether the behavior should be implemented at all. What version of Windows are you using?
WinXP
Does your version supply a COMMAND.COM (in WinXP, it is at c:\windows\system32)? Have you tried running your program from COMMAND.COM? I would guess that COMMAND.COM supplies a fully qualified path to the executable file (as in MS-DOS and Windows 9x), but WinNT/WinXP do not when CMD.EXE is used (???).
I tried command.com and it does not provide a full path in argv[0], I believe. I'm gonna write a test program.
Then, explorer.exe supplies the fully qualified path at all times - that is why the programs do not crash when started from the shortcuts.
So, what should be the policy in Wine? Should Wine supply the qualified name at all (I still think it should)? Mr. Julliard sent a patch proposal that conditionally sets the name. I will try it at home and report on it tomorrow.
I think 'wine' should launch like explorer by default, and wine's cmd should launch like window's cmd. A winecfg per-app setting could work too but I don't like that as much.
Jesse
I have now tried Mr. Julliard's patch. It works for me.
I have also tried the tests on both Windows 98 and Windows XP (I have a triple-boot configuration):
Windows 98: explorer.exe gives qualified name. command.com gives qualified name WindowsXP: explorer gives qualified name. Neither command.com or cmd.exe give a qualified name.
The conclusion is that both DungeonKeeper and LogicWorks expect the Win98 behavior, and crash on both shells in WinXP. I think wine should follow the Win98 behavior (in order to minimize the crashes), and Mr. Julliard's patch does just that.
Alex Villacís Lasso
On 11/1/05, Alex Villacís Lasso [email protected] wrote:
I have now tried Mr. Julliard's patch. It works for me.
I have also tried the tests on both Windows 98 and Windows XP (I have a triple-boot configuration):
Windows 98: explorer.exe gives qualified name. command.com gives qualified name WindowsXP: explorer gives qualified name. Neither command.com or cmd.exe give a qualified name.
The conclusion is that both DungeonKeeper and LogicWorks expect the Win98 behavior, and crash on both shells in WinXP. I think wine should follow the Win98 behavior (in order to minimize the crashes), and Mr. Julliard's patch does just that.
Alex Villacís Lasso
Good work, but shouldn't the behavior be determined by the windows version selected in winecfg since the windows version does make a difference?
On 10/31/05, Jesse Allen [email protected] wrote:
So could we have a program or launcher in wine to launch programs the "windows" way?
Just to let ya'll know, I've found winefile.exe will execute programs the "windows" way, and LogicWorks does work launching from it. Er... it launches, but it's buggy with mfc now =/
On the windows side, I've found that start.exe using it from the command line doesn't put in the full path in either. So the only thing I know of is explorer for the correct behavior, under WinXP.
I still don't know the best way to go with launching programs with 'wine'. There really isn't anything analogous to it in windows. Maybe we need to get people to start using some wine shell program or associate the wine command with some shell, like cmd or explorer. Maybe choose using environment variable?
Jesse
"Jesse" == Jesse Allen [email protected] writes:
Jesse> On 10/31/05, Jesse Allen [email protected] wrote: >> So could we have a program or launcher in wine to launch programs the >> "windows" way?
Jesse> Just to let ya'll know, I've found winefile.exe will execute Jesse> programs the "windows" way, and LogicWorks does work launching Jesse> from it. Er... it launches, but it's buggy with mfc now =/
Run with a native, matching MSVCRT and look for the failing calls in our msvcrt implementation. Write test cases for our test suite and perpahs a patch for our msvcrt.
Bye
On Mon, Oct 31, 2005 at 12:08:36PM -0500, Alex Villacís Lasso wrote:
BTW, could you please post the mouse-cursor issue patch? I also have a Japanese RPG for which the mouse cursor gets stuck at the center of the window, and I think that problem and the one in DungeonKeeper might be one and the same.
I will post it when I find the patch (must be somewhere on this hard drive but no idea where I put it :-) ) and merge it with the current CVS tree.
Now if you game uses DInput (easy to see: just do a +dinput trace) I doubt that my patch would fix anything as it is another of the 'common' bugs linked to mouse warping.
Lionel
On 10/31/05, Alex Villacís Lasso [email protected] wrote:
This is a patch to fix the primary bug on DungeonKeeper. I am surprised this bug was overlooked up to 0.9, since this is such a basic characteristic of Windows.
The basic problem is that Wine is passing the argv[] array unmodified (except for the removal of the 'wine' reference itself) to the PE process. This means that, unless the user writes a DOS-style path at wine invocation, the PE process receives an UNIX-style relative path as its argv[0]. This differs from standard behavior in MS-DOS and Windows, where the argv[0] of the process contains a fully qualified DOS-style path (such as C:\WINDOWS\FOO.EXE) regardless of the method used to run the executable. DungeonKeeper relies on this characteristic of MS-DOS/Windows and crashes when it sees the UNIX-style path.
This is the same bug I experience in a program called LogicWorks. Here is a trace of what I think is suspect:
0009:Call kernel32.GetCommandLineA() ret=1002cf90 0009:Ret kernel32.GetCommandLineA() retval=7fd20e30 ret=1002cf90 0009:Call kernel32.lstrlenA(7fd20e30 "LogicWorks.exe") ret=6c37396c 0009:Ret kernel32.lstrlenA() retval=0000000e ret=6c37396c 0009:Call msvcrt.malloc(00001404) ret=6c373844 0009:Ret msvcrt.malloc() retval=7fdb37a0 ret=6c373844 0009:Call msvcrt.memcpy(7fdb37b0,7fd20e30,0000000e) ret=6c37398b 0009:Ret msvcrt.memcpy() retval=7fdb37b0 ret=6c37398b 0009:Call msvcrt._mbslwr(7fdb37b0 "LogicWorks.exe") ret=6c3cbdf5 0009:Ret msvcrt._mbslwr() retval=7fdb37b0 ret=6c3cbdf5 0009:Call msvcrt._mbschr(7fdb37b0 "logicworks.exe",00000022) ret=6c3cbda0 0009:Ret msvcrt._mbschr() retval=00000000 ret=6c3cbda0 0009:Call msvcrt._mbsstr(7fdb37b0 "logicworks.exe",10077a1c ".exe") ret=6c3c4256 0009:Ret msvcrt._mbsstr() retval=7fdb37ba ret=6c3c4256 0009:Call msvcrt._mbsrchr(7fdb37b0 "logicworks.exe",0000005c) ret=6c3c421c 0009:Ret msvcrt._mbsrchr() retval=00000000 ret=6c3c421c 0009:Call msvcrt._mbsrchr(7fdb37b0 "logicworks.exe",0000002e) ret=6c3c421c 0009:Ret msvcrt._mbsrchr() retval=7fdb37ba ret=6c3c421c 0009:Call msvcrt.memcpy(7fdb3800,7fdb37b0,0000000a) ret=6c3cbbe9 0009:Ret msvcrt.memcpy() retval=7fdb3800 ret=6c3cbbe9 0009:Call msvcrt._mbsrchr(7fdb3800 "logicworks",0000005c) ret=6c3c421c 0009:Ret msvcrt._mbsrchr() retval=00000000 ret=6c3c421c 0009:Call msvcrt._mbsrchr(7fdb3800 "logicworks",0000003a) ret=6c3c421c 0009:Ret msvcrt._mbsrchr() retval=00000000 ret=6c3c421c 0009:Call msvcrt._strdup(7fdb3800 "logicworks") ret=1002d1e3 0009:Ret msvcrt._strdup() retval=7fdb0f58 ret=1002d1e3 0009:Call msvcrt._chdir(7fdb37b0 "logicworks.exe") ret=1002d1fd
This is obviously wrong.
-
Alex Villacís Lasso -
Alexandre Julliard -
Jesse Allen -
Lionel Ulmer -
Mike Hearn -
Molle Bestefich -
Uwe Bonnes