DLL separation for shell32

Steven Edwards steven_ed4153 at yahoo.com
Fri Dec 13 10:30:45 CST 2002


--- Rolf Kalbermatter <rolf.kalbermatter at citeng.com> wrote:
> Looking at shell32.dll I do see that it is the intention to get rid
> completely of any link time dependencies to ole32.dll for DLL separation.
> 
> There are several late bound dependencies but I guess these are not any
> issue as they can not possible cause circular dependencies at load time.
> 
> I have identified following direct dependencies from shell32 on ole32.
> 
>    location                  resolution
> 
>    pidl.c
> 	CLSIDFromString        change to SHCLSIDFromString
>    shell32_main.c
> 	CoCreateInstance       change to internal late bound __CoCreateInstance  
>    shellole.c
> 	CoCreateInstance       change to internal late bound __CoCreateInstance 
> 	CLSIDFromString        SHCLSIDFromString either link or forward to
>                              SHLWAPI_436 or create late bound CLSIDFromString
>    shellord.c
>       CoCreateInstance       change to internal late bound __CoCreateInstance
> 	CoUninitialize         create late bound CoUninitialize
> 	CoInitialize           create late bound CoInitialize
>    shellstring.c
>       CoTaskMemFree          create late bound CoTaskMemFree
>    shlfldr_desktop.c
> 	CLSIDFromString        change to SHCLSIDFromString
> 
> The questions I have is, is it desirable to change those dependencies to late bound calls
> to OLE32, as there are already several in shell32.dll to remove any direct load dependency
> or does this only create additional problems?
> 
> Also the remark in shlwapi.ordinal.c about SHLWAPI_436 that it must recode the function
> as the native DLL seems not to import ole32 or vice versa seems a bit strange. What if
> native also uses late binding for those functions?
> 
> Rolf Kalbermatter

Hello Rolf
I know your focus is on DLL separation but with all of the work you have been doing of late on
shell32 I was wondering if you could take a look at the unixisms and win9xism's in shell32 and see
if there is a way to fix it so it can build/link on mingw. ATM shell32 imports fork and waitpid in
shellexec and of course this wont work for our port to windows. Also there are a few places where
some win32 functions are still importing  MapSL and MapLS both of which I dont think are exported
under WindowsNT/2K.

I was going to try to submit a patch to work around waitpid because that seems easy but to emulate
fork under windows is going to involve a nasty CreateProcess hack that I have not been able to get
to work right. If you have the time and are interested let me know and I can help you debug/test
shell32 via mingw on Win2k.

Thanks
Steven


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



More information about the wine-devel mailing list