Alexandre Julliard wrote:
Ove Kaaven ovehk@ping.uio.no writes:
Well, can this be done with delayed imports yet? I have a situation here where ole32 imports stuff from rpcrt4 (windows uses delayed imports for that), and rpcrt4 imports stuff from ole32 (again, windows uses delayed imports). It would be nice if I could use the winebuild delayed import mechanism to achieve this, instead of doing it manually with callout tables and stuff... but I suppose winebuild has to be changed to read the .spec files instead of using nm on compiled libraries... anyone working on it?
No, and I don't think it's a desirable feature, it's too error-prone. Besides, circular dependencies are really something to avoid, so it must not be too easy to do... (what does rpcrt4 need from ole32 BTW?)
<< à l'impossible, nul n'est tenu >> well, I think we need to differentiate two things: - circular deps in normal imports - circular refs of DLLs for delayed imports
doing the later with either pairs or delay loading doesn't change much. We still have the circular refs of DLLs. Some of them are done by design by MS (Ove ran into Ole32/rpcrt4, there's also comctl32/msvideo).
Could you explicit a bit more what you the error-prone side of this ? I only see drawback with current implementation of delay imports: - calling a delayed function in libmain could cause some issues to the dynamic loader... this can be easily fixed - there's so error reporting mechanism in delay imports. this is supported by MS, the correct functions are not hooked in.
Apart from that, I don't see nothing execpt, that you can introduce errors in the functions prototypes for LoadModule/GetProcAddress, which you usually don't get with delay loading.
from a tree build point of view, using .spec vs nm output for symbol lookup wouldn't change anything
A+