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
--- Rolf Kalbermatter rolf.kalbermatter@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
On Fri, 13 Dec 2002, Steven Edwards wrote: [...]
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.
It's not a basic fork. It's a fork+exec combination and that is easy to replace with a CreateProcess. The only issue is that it is not starting a Windows or Winelib app but a Unix shell script which is probably not in the Windows path. But that should be solvable (e.g. by putting that script in c:\Windows\System).
Francois Gouget wrote:
It's not a basic fork. It's a fork+exec combination and that is easy to replace with a CreateProcess. The only issue is that it is not starting a Windows or Winelib app but a Unix shell script which is probably not in the Windows path. But that should be solvable (e.g. by putting that script in c:\Windows\System).
Cool, Will take a look at it once I can get winewrap.c fixed.
Thanks Steven
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.
Well that was the next thing I was thinking about tackling. My problem here is that I know more about Win32 than Unix, so I was putting that on the wait list for the moment. One of my intents is in fact to get one DLL after the other to cleanly compile AND link under MSVC and as far as I see I think this will also make things quite easy for working under MingW.
As far as the MapSL and MapLS are concerned I think they can rather easily be removed at least from shell32. They are only sparsly used such as in Drag and Drop windows messaging and should most probably be replaced with the newer Drag and Drop mechanisme. The in this case used Drag and Drop messages are not (anymore?) documented at all and seem to use 16:16 bit pointers. I have at the moment no idea if they could be changed to use 32:0 pointers instead or if they have no meaning at all in Win32 but tend to believe the latter.
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.
I haven't really looked at fork yet nor at waitpid or the other unix calls but think there should be a clean Win32 way to get things working.
I would be happy to work with you on these issues. As it is I do not know enough Unix details to do all that work alone.
Rolf Kalbermatter
-
Francois Gouget -
Rolf Kalbermatter -
Steven Edwards