Python plugin works in NPP 7.7 but does work in NPP 7.8 upward
see my previous post on build setup
here is what I get with dumpin
Microsoft ® COFF/PE Dumper Version 14.28.29336.0
Copyright © Microsoft Corporation. All rights reserved.
Dump of file NppPluginTemplate.dll
File Type: DLL
Section contains the following exports for NppPluginTemplate.dll
00000000 characteristics 6013057D time date stamp Thu Jan 28 19:42:05 2021 0.00 version 1 ordinal base 6 number of functions 6 number of names ordinal hint RVA name 1 0 000010E0 beNotified 2 1 000010C0 getFuncsArray 3 2 000010B0 getName 4 3 000010F0 isUnicode 5 4 000010F0 messageProc 6 5 00001040 setInfo
2000 .data 1000 .gfids 6000 .rdata 1000 .reloc 1000 .rsrc D000 .text
Let me do some tests with your code and the mentioned npp versions.
Works for me
Where is your python3.dll located in 7.8?
Should be within your plugin directory.
@Ekopalypse i’ve bin using same setup. I.e. only plugin dll is located in plugin dir. And python dir in path.
and there is no other python3 dll (64bit) in the path before the 32bit one?
@Ekopalypse will check tmr in more details.
I can tell for sure (99%) I do not have any 64 bit builds of python on my box.
I’m still wondering that it works for me in 7.7 but not in 7.8. Just for my understanding were there any changes that could cause such behavior? Changes in dll lookup order or something
Starting from 7.8 plugins are allowed to load their own dlls from within the plugin directory.
Ah - could it be that path is not evaluted anymore? I guess so.
@Ekopalypse could you please check if it works for you if python dll is located in path and not in plugin dir
@Stier-Hahn - currently trying
Ekopalypse last edited by Ekopalypse
Yes, it is not found but then I do get
and next window is
but npp 7.7 works.
I start to remember that I read some conversation about
security concerns regarding sideloading dlls.
@Ekopalypse so, I’ve tested my minimal plugin build in 7.8 with python37.dll inside plugin dir and it works.
My question from the top of the thread has been solved.
Thank you very much!
I still need to check if my main plugin will be working…
Struggling to upgrade third-party libs and other dependencies…
If there is anything we can do to help let us know.
@Ekopalypse you are doing great job , thank you !
I came across a next roadblock , that’s more a pywin32 issue.
May be you would have a hint how to troubleshoot that. as that seems to be sort of related to dependency lookup process.
In a nutshell I’ve NPP plugin linked against boost::python which loads at startup some initialization python code. And it’s was working fine under py 3.7 and npp 7.7.
Finally ( with your help) I managed to upgrade npp from 7.7 to 7.9
and partially from winpython 3.7 to winpython 3.8.
My NPP python plugin is loaded at startup, but execution of initialsation python scripts fails to import win32api.
Embedded python wrapper is working fine ( I guess ) as import os / import sys and other simple code is working inside my plugin.
I’m using win py 3.8 and latest pywin32 ( 300)
@Stier-Hahn pywin32 is installed sort of correctly as it works from python command line.
there is an additional
path when used by the command line.
Maybe give it a try to add it to your sys.path from embedded python.
Do you know procmon?
It could be used to see what npp and your plugin tries to load with a filter set to
path contains whatever
If importing pywin32 failed with unable to load dll
then one of those
can not be found I guess.
python38 shouldn’t be the problem but pywintypes38.dll might be in this additional path I’ve mentioned earlier??
@Ekopalypse cool, thanks for advice, turned out to be pywin32_system32 not being searched for some reason
Apparently lookup path was (intentionally screwed up) modified
I managed to fix my problem by placing pywintypes38.dll and pythoncom38.dll to NPP root