October 2005 - Wine-Devel - list.winehq.org

Re: KERNEL: force copying of DOS-style path into argv[0] of PE process

by Jesse Allen

On 10/31/05, Alex Villacís Lasso <a_villacis(a)palosanto.com> 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

Oct. 31, 2005

Re: KERNEL: force copying of DOS-style path into argv[0] of PE process

by Alex Villacís Lasso

Jesse Allen wrote: >On 10/31/05, Mike Hearn <mike(a)plan99.net> 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

Oct. 31, 2005

Re: DirectSound problems - dlls/dsound/mixer.c

by Jesse Allen

Hi Davin, Juergen and I have tested Diablo 2 with your patch and found it has improved the sound. But there is still more to do: ---------- Forwarded message ---------- From: Juergen Wieczorek <juergenw_(a)web.de> Date: Oct 31, 2005 3:58 PM Subject: Re: Fwd: DirectSound problems - dlls/dsound/mixer.c To: Jesse Allen <the3dfxdude(a)gmail.com> Sorry, but things are a bit weird with the supplied wine-0.9 for FC3. In order to counter-proof, I did a rpmbuild -bb ... with the *unpatched* sources from wine-0.9-1fc3-winehq and also ended up with dead sound, until I set winecfg to "OSS"! Then sound worked with patched or unpatched mixer.c source. Strangely, when I installed the provided binary FC3.rpm, winecfg works only with "ALSA" sound setting. Obviously there is something wrong with the build specs of this package, I have to check later. As for the patched mixer.c source: Sound is now much more fluid and not crackling perpetually, but some long drawn sounds like power-ups have a jarring note to them. Also walking around on the map with the mouse button pressed down produces a jarring noise when in the vicinity of moving flames like those at waypoints or near any sort of open fire. Ths stops when you're at some distance from the flames. Here is my resp. console output for reference: err:dsound:DSOUND_PhaseCancel length not a multiple of block size, len = 2454, block size = 4 err:dsound:DSOUND_PhaseCancel length not a multiple of block size, len = 2482, block size = 4 err:dsound:DSOUND_PhaseCancel length not a multiple of block size, len = 2498, block size = 4 err:dsound:DSOUND_PhaseCancel length not a multiple of block size, len = 2550, block size = 4 err:dsound:DSOUND_PhaseCancel length not a multiple of block size, len = 3966, block size = 4 err:dsound:DSOUND_PhaseCancel length not a multiple of block size, len = 3026, block size = 4 fixme:wave:DSD_CreateSecondaryBuffer (0x7fe72db8,0x7fa6842c,e0,0,0x70ff007c,0x70ee3bec,0x70ff00 58): stub fixme:wave:DSD_CreateSecondaryBuffer (0x7fe72db8,0x7fa6842c,e0,0,0x70ed007c,0x721000f4,0x70ed00 58): stub fixme:wave:DSD_CreateSecondaryBuffer (0x7fe72db8,0x7fa6842c,e0,0,0x70ed01b4,0x70ee508c,0x70ed01 90): stub fixme:wave:DSD_CreateSecondaryBuffer (0x7fe72db8,0x7fa6842c,e0,0,0x70ed02ec,0x70ed03dc,0x70ed02 c8): stub fixme:wave:DSD_CreateSecondaryBuffer (0x7fe72db8,0x7fa6842c,e0,0,0x70ed047c,0x70ed058c,0x70ed04 58): stub fixme:wave:DSD_CreateSecondaryBuffer (0x7fe72db8,0x7fa6842c,e0,0,0x70ed062c,0x70ed073c,0x70ed06 08): stub fixme:wave:DSD_CreateSecondaryBuffer (0x7fe72db8,0x7fa6842c,e0,0,0x70ed07dc,0x70ed08ec,0x70ed07 b8): stub fixme:wave:DSD_CreateSecondaryBuffer (0x7fe72db8,0x7fa6842c,e0,0,0x70ed098c,0x70ed0a9c,0x70ed09 68): stub All in all, much better now, but still a way from being nice. -- Juergen Wieczorek Hamburg / Germany

Oct. 31, 2005

Re: Help with WINE and POSIX threading

by Vincent Béron

Le jeu 27/10/2005 à 20:02, Troy Rollo a écrit : > On Thu, 27 Oct 2005 22:19, Marcus Meissner wrote: > > dlopen() is possible from within a WINE context. > > I don't believe this is true. LoadLibrary does a bunch of stuff dlopen won't - > resolving imports, such as loading dependent DLLs and calling DLLEntry. While > you can call dlopen, you must also call LoadLibrary either before or > immediately after to make sure all this stuff is sorted out. Don't use dlopen() for Wine's dlls (or Windows native ones), use it for Linux native .so. Vincent

Oct. 31, 2005

Re: KERNEL: force copying of DOS-style path into argv[0] of PE process (was: Re: Queries about some 'usability' points) - partially fixes #3542

by Jesse Allen

On 10/31/05, Mike Hearn <mike(a)plan99.net> 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

Oct. 31, 2005

Unmet dependency with Mozilla ActiveX install

by Ron Jensen

I tried installing a free game at random [1] from a web site I found [2]. I downloaded it and tried installing it into a freshly created with "wineprefixcreate" .wine folder. The game installed without a problem. When I tried to run the game wine presented a dialog that said I needed Mozilla ActiveX controls and offered to download & install them. The download worked, however the install _FAILED_ . I found a web site [3] with troubleshooting tips. It suggested I was missing two dlls, MSVCP60.DLL and MSVCRT.DLL. I downloaded the zip file [4] and unzipped it into ~/.wine/drive_c/windows/system . Reran the game, wine presented the same dialog about ActiveX. This time it downloaded & installed properly. The game started, ran and played. Two issues come to mind for the ActiveX installer: - it need to check for MSVCP60.DLL and MSVCRT.DLL before it bothers to download ActiveX. - it should cache the ActiveX download ( in /tmp maybe? ) with an option to keep it on hand. Since wine is installed per user it is probable a machine may need to install this more than once. [1] http://www.kprobe.com/kprobe/Downloads/SetupXMasMath.exe [2] http://www.kprobe.com/kprobe/index.htm [3] http://www.iol.ie/~locka/mozilla/troubleshooting.htm [4] http://www.iol.ie/~locka/mozilla/runtime60.zip

Oct. 31, 2005

Re: KERNEL: force copying of DOS-style path into argv[0] of PE process (was: Re: Queries about some 'usability' points) - partially fixes #3542

by Jesse Allen

On 10/31/05, Alex Villacís Lasso <a_villacis(a)palosanto.com> 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.

Oct. 31, 2005

Re: Small visual issues with P-CAD2000 and wine 0.9

by Walt Ogburn

Hi Marcos, What are the buttons supposed to look like? The ones in your screenshot look OK to me. On Mon, 31 Oct 2005, Marcos Vicente Cruz wrote: > HI, > > I having small visual issues in P-CAD 2000's toolbar on Linux since I've > upgraded to wine 0.9. The buttons aren't displayed properly. See the > screenshot attached. > > Thank you, > > Marcos >

Oct. 31, 2005

Re: KERNEL: force copying of DOS-style path into argv[0] of PE process (was: Re: Queries about some 'usability' points) - partially fixes #3542

by Mike Hearn

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

Oct. 31, 2005

Re: KERNEL: force copying of DOS-style path into argv[0] of PE process

by Alexandre Julliard

Alex Villacís Lasso <a_villacis(a)palosanto.com> 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 */ -- Alexandre Julliard julliard(a)winehq.org

Oct. 31, 2005