FIXMEs in DllCanUnloadNow and friends (and how to handle them)
msclrhd at googlemail.com
Wed Jan 6 01:49:46 CST 2010
As a result of the "Wine FIXME Report 2009 Aug - Dec" thread, I
created the following to hunt for DllCanUnloadNow calls that were
marked as being FIXME stubs:
cat > DllCanUnloadNow.pl < EOF
# Based on http://www.unix.com/unix-dummies-questions-answers/56703-multiline-grep.html
my $filename = shift;
open (FILE, "<", $filename) or die "Failed to read file $filename : $! \n";
$whole_file = <FILE>;
if ($whole_file =~ m#HRESULT WINAPI DllCanUnloadNow ?\( ?(void|VOID)
print $filename . "\n";
and used it with the following:
$ grep -F DllCanUnloadNow -r dlls | grep -F HRESULT | sed -e
's/:.*//' | while read line ; do perl DllCanUnloadNow.pl $line ; done
| sort | tee results.log
This gives the following results:
----- 8< -----
----- >8 -----
I am currently going through the results and removing the FIXME stubs
for the DllCanUnloadNow calls, as returning S_FALSE is a perfectly
valid implementation (see the "Wine FIXME Report 2009 Aug - Dec"
While doing this, I noticed that some implementations of
DllGetClassObject, DllRegisterServer and DllUnregisterServer also have
FIXMEs. This is because the DLLs implement COM objects, but the wine
versions are incomplete.
For the DllRegister/UnregisterServer calls, the FIXMEs should be
removed -- the FIXMEs do not add any value, and are only likely to
appear during install or when calling regsvr32.
For DllGetClassObject, the FIXME should output the GUID of the object
that is trying to be created.
NOTE: I have also seen some implementations of DllCanUnloadNow that
always return S_OK (e.g. dlls/hlink/hlink_main.c, even though it is
implementing COM objects). I will keep a note of these and look to see
whether they implement COM objects or not. I will sent a separate
patch to address this issue.
More information about the wine-devel