> But, I still don't understand why Perl/COM doesn't need a > DLL in the > system directory. Or is it just because they change PATH? > > (I don't know zit about COM, so that may be it. I > understand that a > COM object is registered (in the registry) as an entry point of a > DLL. Couldn't that DLL be specified by absolute > pathname??? Then no > search path would be necessary.) Yes - but it all gets back to the exact same problem that got us here in the first place: * COM object points to \Python1.6\PythonCOM16.dll * PythonCOM16.dll has link-time reference to Python16.dll * As COM just uses LoadLibrary(), the path of PythonCOM16.dll is not used to resolve its references - only the path of the host .EXE, the system path, etc. End result is Python16.dll is not found, even though it is in the same directory. So, if you have the opportunity to intercept the link-time reference to a DLL (or, obviously, use LoadLibrary()/GetProcAddress() to reference the DLL), you can avoid override the search path. Thus, if PythonCOM16.dll could intercept its references to Python16.dll, it could locate the correct Python16.dll with runtime code. However, as we import data from Python16.dll rather then purely addresses, we can't use any of these interception solutions. If we could hide all data references behind macros, then we could possibly arrange it. Perl _does_ use such techniques, so can arrange for the runtime type resolution. (Its not clear if Perl uses "dynamic loading" via GetProcAddress(), or delayed loading via the new VC6 feature - I believe the former, but the relevant point is that they definately hide data references behind magic...) Mark.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4