> > Anyway, ActivePerl installs its DLLs (all 5) in c:\Perl\bin\. So > > there. It also didn't change PATH for me, even though the docs > > mention that it does -- maybe only on NT? > > In another mail you asked David to look into how Active State handle > their DLLs. Well, Trent Mick started the ball rolling... > > 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 avoiding the import of data, they have far more possibilities, > including the use of LoadLibrary(), For what do they use LoadLibrary()? What is it? We use LoadLibraryEx() -- isn't that just as good? > and a new VC6 linker feature called "delay loading". > To my mind, it would be quite difficult to make this work for > Python. There are a a large number of data items we import, and > adding a function call indirection to each one sounds a pain. Agreed. > [As a semi-related issue: This "delay loading" feature is very > cool - basically, the EXE loader will not resolve external DLL > references until actually used. This is the same trick mentioned on > comp.lang.python, where they saw _huge_ startup increases (although > the tool used there was a third-party tool). The thread in question > on c.l.py resolved that, for some reason, the initialization of the > Windows winsock library was taking many seconds on that particular > PC. > > Guido - are you on VC6 yet? Yes -- I promised myself I'd start using VC6 for the 1.6 release cycle, and I did. > If so, I could look into this linker > option, and see how it improves startup performance on Windows. > Note - this feature only works if no data is imported - hence, we > could use it in Python16.dll, as most of its imports are indeed > functions. Python extension modules can not use it against Python16 > itself as they import data.] 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. Since this way we manage our own DLL loading anyway, what's the point of delay-loading? --Guido van Rossum (home page: http://www.python.org/~guido/)
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