> > The answer is that Perl extensions never import data > from the core > > DLL. They always import functions. In many cases, > they can hide > > this fact with the pre-processor. > > This doesn't answer my question. My question is how they > support COM > without having a DLL in the system directory. Or at least I don't > understand how not importing data makes a difference. By not using data, they can use either "delay load", or fully dynamic loading. Fully dynamic loading really just involves getting every API function via GetProcAddress() rather than having implicit linking via external references. GetProcAddress() can retrieve data items, but only their address, leaving us still in a position where "Py_None" doesnt work without magic. Delay Loading involves not loading the DLL until the first reference is used. This also lets you define code that locates the DLL to be used. This code is special in a "DllMain" kinda way, but does allow runtime binding to a statically linked DLL. However, it still has the "no data" limitation. > But what DLLs does python16 use that could conceivably be > delay-loaded? > > Note that I have a feeling that there are a few standard > extensions > that should become separate PYDs -- e.g. socket (for the > above reason) > and unicodedata. This would greatly reduce the size of > python16.dll. Agreed - these were my motivation. If these are moving to external modules then I am happy. I may have a quick look for other preloaded DLLs we can avoid - worth a look for the sake of a linker option :-) 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