September 2004 - Wine-Devel

RE: SystemFunction006

by Rolf Kalbermatter

Hans Leidekker wrote: +NTSTATUS WINAPI SystemFunction006( LPCSTR password, LPSTR hash ) +{ + unsigned char buffer[16]; + + hash = CRYPT_LMhash( buffer, password, strlen(password) ); + + return STATUS_SUCCESS; +} I don't think this will work properly. The returned pointer from CRYPT_LMHash() will never be passed out to the caller of the function. There should be probably a function call before the return of the function along the lines of memcpy(hash, buffer, 16); The question here would also be why use an intermediate buffer at all in the first place? Also the use of strcmp() for comparing a hash in the according test seems a little misplaced to me. Or is a DES hash guaranteed to never contain 0x00 bytes? It doesn't occur in the test case so it is not a big problem in this case but principially it seems not right to me. Rolf Kalbermatter

Sept. 30, 2004

Re: WINEDLLOVERRIDES for all dlls?

by Alexandre Julliard

James Hawkins <truiken(a)gmail.com> writes: >> The Win95 advapi32 cannot work, but the NT one can. > > Is there ever a time when we would want to use the native NT advapi32? There might be, yes. > I just sent a patch to make sure only the builtin advapi32 gets > loaded, so that probably won't be committed if this is the case. No, unlike with kernel etc. there's no reason that native advapi32 cannot work, so it must not be added to that list. -- Alexandre Julliard julliard(a)winehq.org

Sept. 30, 2004

Re: ez-cdda sleep

by Robert Shearman

Mike Hearn wrote: >On Thu, 2004-09-30 at 17:37, James Hawkins wrote: > > >>err:thread:GetThreadContext Eip: ffffe410 >>err:thread:GetThreadContext Eip: ffffe410 >>err:thread:GetThreadContext Eip: ffffe410 >>err:thread:GetThreadContext Eip: ffffe410 >> >>and that is repeated until I terminate it. >> >> > >Wierd. That value of EIP would put the thread as stuck somewhere in >kernel address space (?), which doesn't sound right at all. > This is the so-called 'linux-gate' special area that is used for fast system calls. It typically means a blocking call, such as a call to the wineserver. I would investigate whether it is supposed to be in the middle of a blocking call and under what conditions it should return from it. Rob

Sept. 30, 2004

Re: ez-cdda sleep

by Mike Hearn

On Thu, 2004-09-30 at 17:37, James Hawkins wrote: > err:thread:GetThreadContext Eip: ffffe410 > err:thread:GetThreadContext Eip: ffffe410 > err:thread:GetThreadContext Eip: ffffe410 > err:thread:GetThreadContext Eip: ffffe410 > > and that is repeated until I terminate it. Wierd. That value of EIP would put the thread as stuck somewhere in kernel address space (?), which doesn't sound right at all. OK, I'm afraid this is a bit beyond my understanding. I had a theory related to kernel scheduling algorithms but this value of EIP makes no sense. I'd expect it to be the entry procedure if my theory was right, which it's clearly not. Maybe Alexandre will have an idea. The software can be found on google for "easy cd extractor" or something like that... I have it here. Hey, hopefully you learnt something though. thanks -mike

Sept. 30, 2004

winetest fails enumerating test files

by Saulius Krasuckas

It shows some message-box telling: "Can't enumerate test files: 1813" Greping programs/winetest/main.c gives: | report (R_STATUS, "Counting tests"); | if (!EnumResourceNames (NULL, MAKEINTRESOURCE(TESTRES), | EnumTestFileProc, (LPARAM)&nr_of_files)) | report (R_FATAL, "Can't enumerate test files: %d", | GetLastError ()); | wine_tests = xmalloc (nr_of_files * sizeof wine_tests[0]); I guess this may be some regression (have been running winetest a whole month ago last time). Am I alone with this?

Sept. 30, 2004

Problems with MSI installer

by Joaquín Fernández

Hello I am trying to install an EXE file packed with MSI. I installed InstMsiA before running the program, but the installer don't finish, stay in endless loop when copying the files, and progress bar is over 70%. I put WINEDEBUG=trace+all and show PENDING() when the installer stop. I ran wine with WINEDLLOVERRIDES="*advapi32=b", WINEDLLOVERRIDES="*advapi32=b;msi=n", WINEDLLOVERRIDES="*advapi32=b;msiexec.exe=n" and WINEDLLOVERRIDES="*advapi32=b;msi,msiexec.exe=n", only the last option let the installer advance but don't finish. So what event wait installer for to continue? Do i need override other(s) dlls when use MSI installer? Regards Joaquín -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQFCBEFI/gARAwDd2+ojasT3rCyRktSw+Ix3m+yoxSD0NkpMLlunmJxwvn6wKZVl mDw76/Zu9mqDWWeSGdSl+60T7fDLrJZSEB45O9T5jdujj01GFeer7xuiuHBTFw8o CXqD/hzhqYc46ecAoIQQjZ2qZtOWLPRBbegK/nyOIguNAv9QGiKPLBS8o0ksxEUp EfLAExVmu6Zp693uKGf6XrBWNcLriuwRPr1mjy3N/bhMlqc3vcTeUBwxiUuX5h2P NQgB3d2AbJS6oEvhmZL0Bn/8Ij/MSvVrartmCXuw9eSx0aMC/R7Kw9TtUfxFVUGx fQKwoA9BXNElPLcNohbBS/fH87IMMxCJyn+rmTeNCEcUEQ7UgvVCdlzZ8+L4PdlH qGR81nhZVEwPRnSSesLpSHRC1QQVoceBeb7PICr/b2eZiKMX+bQ+Sm9hcXXDrW4g TWFudWVsIEZlcm7DoW5kZXogUXVpbGVzIDxqb2FxdWluQGNhc2FkZWFsYWJhbnph Lm9yZz6IXgQTEQIAHgUCQUj+AAIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRBH 677/q7xL4e15AJwNfSpeaXXMH2EjuKblfeBe51MrUgCcCP5jEnpXrDXLWULIW5yD t6VdHlU= =a8BM -----END PGP PUBLIC KEY BLOCK-----

Sept. 30, 2004

Re: WINEDLLOVERRIDES for all dlls?

by James Hawkins

> The Win95 advapi32 cannot work, but the NT one can. Is there ever a time when we would want to use the native NT advapi32? I just sent a patch to make sure only the builtin advapi32 gets loaded, so that probably won't be committed if this is the case. On Thu, 30 Sep 2004 10:16:26 -0700, Alexandre Julliard <julliard(a)winehq.org> wrote: > James Hawkins <truiken(a)gmail.com> writes: > > > err:vxd:VMM_VxDCall Using the native Win95 advapi32.dll is no longer supported. > > err:vxd:VMM_VxDCall Please configure advapi32 to builtin. > > > > If we don't want any user using a native advapi32.dll no matter what > > the circumstances, shouldn't the default override for advapi32 be > > *advapi32=b (no matter whether it's in a config file or the registry > > or whatever)? > > The Win95 advapi32 cannot work, but the NT one can. > > -- > Alexandre Julliard > julliard(a)winehq.org > -- James Hawkins

Sept. 30, 2004

taking a stab at analyzing a debug log

by James Hawkins

Hi, I've been trying to get Easy CD Extractor to work for a while now, and the program ezcddax.exe is having some weird (possibly) scheduling and threading problems, so in the meantime I've looked at some of the other exe's that Easy Cd Extractor installed. One such exe is burn.exe. When I run this, it seemingly immediately exits. This is an interesting part of +relay: 0009:Call kernel32.GetModuleHandleA(00000000) ret=0040158a 0009:Ret kernel32.GetModuleHandleA() retval=00400000 ret=0040158a 0009:Call kernel32.GetModuleFileNameA(00400000,406cfc18,00000105) ret=0040114e 0009:Call ntdll.RtlAllocateHeap(40370000,00000000,0000020a) ret=404da841 0009:Ret ntdll.RtlAllocateHeap() retval=403a91d8 ret=404da841 0009:Call ntdll.LdrLockLoaderLock(00000000,00000000,406cfad4) ret=404eafce 0009:Ret ntdll.LdrLockLoaderLock() retval=00000000 ret=404eafce 0009:Call ntdll.LdrFindEntryForAddress(00400000,406cfad0) ret=404eafe0 0009:Ret ntdll.LdrFindEntryForAddress() retval=00000000 ret=404eafe0 0009:Call ntdll.LdrUnlockLoaderLock(00000000,00000009) ret=404eb02c 0009:Ret ntdll.LdrUnlockLoaderLock() retval=00000000 ret=404eb02c 0009:Call ntdll.RtlUnicodeToMultiByteN(406cfc18,00000105,406cfad4,403a91d8,00000 060) ret=404d2873 0009:Ret ntdll.RtlUnicodeToMultiByteN() retval=00000000 ret=404d2873 0009:Call ntdll.RtlFreeHeap(40370000,00000000,403a91d8) ret=404da871 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=404da871 0009:Ret kernel32.GetModuleFileNameA() retval=00000030 ret=0040114e 0009:Call kernel32.ExitProcess(00000001) ret=00401454 0009:Call ntdll.LdrShutdownProcess() ret=404f5bd0 It seems that the last system call burn.exe makes before exiting is GetModuleFileNameA. I added an ERR in this function to see what filename it was getting, and it is: err:module:GetModuleFileNameA filename: L"C:\\Program Files\\Easy CD-DA Extractor 7\\burn.exe" which is the path of the program. After this call, burn.exe starts the exit process. Maybe burn.exe didn't like the results from GetModuleFileName? I'm not exactly experienced with analyzing debug logs, so I'm probably way off, but hopefully I'll get better. -- James Hawkins

Sept. 30, 2004

Re: WINEDLLOVERRIDES for all dlls?

by Alexandre Julliard

James Hawkins <truiken(a)gmail.com> writes: > err:vxd:VMM_VxDCall Using the native Win95 advapi32.dll is no longer supported. > err:vxd:VMM_VxDCall Please configure advapi32 to builtin. > > If we don't want any user using a native advapi32.dll no matter what > the circumstances, shouldn't the default override for advapi32 be > *advapi32=b (no matter whether it's in a config file or the registry > or whatever)? The Win95 advapi32 cannot work, but the NT one can. -- Alexandre Julliard julliard(a)winehq.org

Sept. 30, 2004

Re: ez-cdda sleep

by James Hawkins

oops after moving the ERR() to after the server RPC, this is what we get: err:thread:GetThreadContext Eip: ffffe410 err:thread:GetThreadContext Eip: ffffe410 err:thread:GetThreadContext Eip: ffffe410 err:thread:GetThreadContext Eip: ffffe410 and that is repeated until I terminate it. On Thu, 30 Sep 2004 16:56:30 +0100, Mike Hearn <mike(a)navi.cx> wrote: > On Thu, 2004-09-30 at 16:33, James Hawkins wrote: > > I added the ERR output to GetThreadContext and the results are: > > > > err:thread:GetThreadContext Eip: 0 > > err:thread:GetThreadContext Eip: 0 > > err:thread:GetThreadContext Eip: 0 > > err:thread:GetThreadContext Eip: 0 > > > > and this continues until I break out of the program with ctrl-c. > > Huh, well that can't be right, Eip is supposed to be a pointer! Are you > sure you did this *after* the server RPC, and not before? If you did it > after the RPC returns from the server then maybe we've got a clue as to > the problem. > > -- James Hawkins

Sept. 30, 2004