DLL separation has been mentioned quite a few times on this list (usually as the ultimate solution to a problem), but I don't think I've ever seen it actually defined. Based on my own misadventures in this area, however, I would hazard a guess that is essentially the conversion of all inter-DLL function calls from OS-based dynamic linking to the Wine DLL loading mechanism.
Under this assumption, adding 'IMPORTS = ntdll' to a DLL's Makefile.in file (in order to use one of the PROFILE functions) seems like a definite step backwards. I think that the proper approach is to add the function in question to dlls/ntdll/ntdll.spec and make sure that the importing DLL lists ntdll.dll as an import in its own SPEC file.
All of which is wonderful until you consider the following in ntdll.spec:
################## # Wine extensions # # All functions must be prefixed with '__wine_' (for internal functions) # or 'wine_' (for user-visible functions) to avoid namespace conflicts.
This would seem to indicate that the PROFILE functions (in files/profile.c) need to have their names changed before they are exported. Is this an appropriate time to go crazy with grep and sed? (For example, PROFILE_EnumWineIniString would become __wine_EnumIniString.)
On Tue, 15 May 2001, Ian Pilcher wrote:
DLL separation has been mentioned quite a few times on this list (usually as the ultimate solution to a problem), but I don't think I've ever seen it actually defined. Based on my own misadventures in this area, however, I would hazard a guess that is essentially the conversion of all inter-DLL function calls from OS-based dynamic linking to the Wine DLL loading mechanism.
Yes, this is needed to be able to have Wine DLLs and Winelib apps be able to seamlessly import and use native PE DLLs.
Under this assumption, adding 'IMPORTS = ntdll' to a DLL's Makefile.in file (in order to use one of the PROFILE functions) seems like a definite step backwards.
The profile functions are not exported and you should not use them. If you're trying to access the config file, use the registry API instead; for an example, see what Alexandre did in dlls/x11drv/x11drv_main.c. You'll see the reason Alexandre changed the .wine/config file format to the registry format.
################## # Wine extensions # # All functions must be prefixed with '__wine_' (for internal functions) # or 'wine_' (for user-visible functions) to avoid namespace conflicts.
This would seem to indicate that the PROFILE functions (in files/profile.c) need to have their names changed before they are exported. Is this an appropriate time to go crazy with grep and sed?
You could use #defines in a .h file too, but you shouldn't add wine extensions without a *very* good reason. Alexandre has even advocated code duplication in some instances to keep DLL separation tight.
-
Ian Pilcher -
Ove Kaaven