> > > However, as we import data from Python16.dll rather then purely > > > addresses, we can't use any of these interception solutions. > > > > What's wrong with: > > > > #define PyClass_Type *(GetProcAddress(hdll, "PyClass_Type")) > > My only objection is that this is a PITA. It becomes a maintenance > nightmare for Guido as the code gets significantly larger and > uglier. Why is it a nightmare for Guido? It can be done by the extension writer: You in the case for PythonCOM.dll. > > > I have only looked at PythonCOM15.dll, and it seems that > > there are only references to a handfull of exported data items: > > > > some Py*_Type, plus _PyNone_Struct, _PyTrue_Struct, > > _PyZero_Struct. > > Yep - these structs, all the error objects and all the type objects. > > However, to do this properly, we must do _every_ exported data item, > not just ones that satisfy COM (otherwise the next poor soul will > have the exact same issue, and require patches to the core before > they can work...) IMHO it is not a problem of exporting, but a question how *you* import these. > > Im really not convinced it is worth it to save one, well-named DLL > in the system directory. As long as no one else installs a modified version there (which *should* have a different name, but...) > > Mark. > Thomas Heller
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