funq
funq copied to clipboard
parkouss
Refactor Windows injector to get rid of winappdbg dependency
Funq still didn't work with Python 3 on Windows due to the winappdbg dependency (see #58). This is more and more a pain since Python 2 is end of life for quite some time now. Thus I refactored the Windows injector to no longer require this dependency. Now Funq also works with Python 3 on Windows! :rocket:
The injector works similar as it worked with winappdbg. However, I do no longer scan the process for the Qt DLLs to be loaded since this is quite painful :see_no_evil: I think it is actually not needed, the sleep(1) (which was already there before) should be enough to wait for the Qt DLLs to be loaded. Overall the injector is not perfect at all, but I think it's not worse than before as with the crappy WIN32 API it's probably not even possible to implement a really clean solution (I googled a lot for good solutions, but didn't find any).
I tested it quite excessive (with my project LibrePCB), both locally and on Azure Pipelines CI. So far it seems to be working reliable, no problems occurred in >1'500 injections.
Just let me know if you have any questions or suggestions.
Hm the CI seems to be quite broken - certificate error on AppVeyor, and Travis not working at all :cry:
However, at LibrePCB I run our tests with Funq on Windows, Linux and macOS, partly with Python 2 and with Python 3 - all successful, so I'd say the changes are not that bad :wink:
@rafaeldelucena I don't know the exact reason, but it seems that CI on Windows uses Python 2.7 which is EOL for quite some time. I think it's not worth to investigate that issue, I'd recommend to drop support for Python 2 and change CI to use Python 3. Maybe it fixes the problem, maybe not - then further investigation would be needed.
FYI in the meantime I dropped support for Python <3.5 in my fork (see https://github.com/LibrePCB/funq/pull/2 and https://github.com/LibrePCB/funq/pull/3) and we're using that funq version now with Python 3 on all operating systems, which works very well. But on our fork the CI is not enabled, thus I don't know if it would fix the CI problem...