Jon Griffiths jon_p_griffiths@yahoo.com writes:
I should clarify. Versions 6 and higher (XP+) of SHLWAPI are linked via delayed import to ole32. This is a change from previous versions because versions 5xs and below could be installed on installations that didn't have ole32 installed. SHLWAPI used to come with IE, and as such it was an add on to v3.1+, where sometimes ole32.dll was not available. The latest versions require ole32, however if Wine is running as a previous version it should _not_ be a requirement that this dll be installed.
I don't see any need for being compatible that way. Wine always comes with ole32 so it's perfectly acceptable to depend on it, as long as our builtin ole32 does what we need. We just have to make sure that it works with existing native ole32 dlls too, for instance by avoiding imports of functions that only exist in the latest versions; but making it work with a non-existing ole32 is not necessary.
If we should directly link with ole32 then we should probably remove the FIXME from Makefile.in. If we follow this path, we should eventually also link with the other DLLs that version 6 delay loads instead of being optional as before: apphelp, mlang, comctl32, mpr, msi, setupapi, userenv, winmm etc.
If both the native and builtin versions of these dlls implement what we need, and if you can import them without creating circular dependencies, then yes they should definitely be imported instead of using explicit function pointers.