Python plugin works in NPP 7.7 but does work in NPP 7.8 upward

[Stier Hahn]

@Ekopalypse said in Python plugin works in NPP 7.7 but does work in NPP 7.8 upward:

/exports

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

Summary

    2000 .data
    1000 .gfids
    6000 .rdata
    1000 .reloc
    1000 .rsrc
    D000 .text

[Ekopalypse]

Let me do some tests with your code and the mentioned npp versions.

[Ekopalypse]

Works for me

Where is your python3.dll located in 7.8?
Should be within your plugin directory.

[Stier Hahn]

@Ekopalypse i’ve bin using same setup. I.e. only plugin dll is located in plugin dir. And python dir in path.

[Ekopalypse]

@Stier-Hahn
and there is no other python3 dll (64bit) in the path before the 32bit one?

[Stier Hahn]

@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.

Ps
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

[Ekopalypse]

Starting from 7.8 plugins are allowed to load their own dlls from within the plugin directory.

[Ekopalypse]

Ah - could it be that path is not evaluted anymore? I guess so.

[Stier Hahn]

@Ekopalypse could you please check if it works for you if python dll is located in path and not in plugin dir

[Ekopalypse]

@Stier-Hahn - currently trying

[Ekopalypse]

@Stier-Hahn
Yes, it is not found but then I do get

[Ekopalypse]

and next window is

[Ekopalypse]

but npp 7.7 works.

[Ekopalypse]

@Stier-Hahn

I start to remember that I read some conversation about
security concerns regarding sideloading dlls.

[Stier Hahn]

@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!

ps

I still need to check if my main plugin will be working…
Struggling to upgrade third-party libs and other dependencies…

[Ekopalypse]

If there is anything we can do to help let us know.

[Stier Hahn]

@Ekopalypse you are doing great job , thank you !

ps
I came across a next roadblock , that’s more a pywin32 issue.

See https://github.com/mhammond/pywin32/issues/1658

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]

@Stier-Hahn pywin32 is installed sort of correctly as it works from python command line.

[Ekopalypse]

@Stier-Hahn

there is an additional
...\AppData\Roaming\Python\Python38\site-packages
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??

[Stier Hahn]

@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