FreeLibrary() library freeing
a.mohr at mailto.de
Tue May 1 16:23:43 CDT 2001
can't we just free the libraries for real now in FreeLibrary() ?
I just got a report from someone who had an InstallSh***** installer
Call kernel32.192: CreateFileA(40566cf4 "C:\\WINDOWS\\uninst.exe",c0000000,00000001,00000000,00000004,00000080,00000000) ret=0044364e fs=008f
trace:file:CreateFileA C:\WINDOWS\uninst.exe GENERIC_READ GENERIC_WRITE FILE_SHARE_READ OPEN_ALWAYS
trace:dosfs:DOSFS_GetFullName C:\WINDOWS\uninst.exe (last=0)
trace:string:lstrcpynA (0x40566148, "/home/jnu/.wine/fake_windows", 1024)
trace:dosfs:DOSFS_FindUnixName (/home/jnu/.wine/fake_windows,WINDOWS\uninst.exe) -> Windows (WINDOWS)
warn:dosfs:DOSFS_FindUnixName 'uninst.exe' not found in '/home/jnu/.wine/fake_windows/Windows'
trace:dosfs:DOSFS_GetFullName returning /home/jnu/.wine/fake_windows/Windows/uninst.exe = C:\WINDOWS\uninst.exe
warn:file:FILE_CreateFile Unable to create file '/home/jnu/.wine/fake_windows/Windows/uninst.exe' (GLE 32)
Ret kernel32.192: CreateFileA() retval=ffffffff ret=0044364e fs=008f
Call kernel32.943: lstrcpyA(40566834,40380370 "Setup Initialization Error") ret=00403322 fs=008f
Ret kernel32.943: lstrcpyA() retval=40566834 ret=00403322 fs=008f
trace:string:wvsnprintfA 0x40566960 1024 "Setup is unable to find a hard disk location to store temporary files.\n\nMake at "...
trace:string:wvsnprintfA "Setup is unable to find a hard disk location to store
temporary files.\n\nMake at "...
Call user32.425: MessageBoxA(00000000,40566960 "Setup is unable to find a hard disk location to store temporary files.\n\nMake at "...,40566834 "Setup Initialization Error",00000010) ret=00403402 fs=008f
This happened because the program did some FileVersionGet*() calls before
on uninst.exe, which do LoadLibrary()/FreeLibrary() internally, but of
course the file handle didn't get freed any more.
I believe the potential problems that this can cause are way more important
than some claims that "there are some problems with library freeing".
I've had that FreeLibrary() #if hack removed for a long time,
and I haven't see any adverse effects (not that it's too easy to spot
and attribute to this problem probably, though).
Besides, Musicmatch Jukebox used zillions of MB (yes, that's a leak for you)
due to that Wine "feature".
I for one would truly like to see it fixed ASAP.
If FreeLibrary() has a problem, then we need to fix it.
Running away from the problem by implementing strange hacks does no good
Microsoft Windows: Made for the Internet
The Internet: Made for Unix
More information about the wine-devel