PM NG v7.2.7.0 under Windows 10
@jan.cosmigo while working on my current plugin, I was cleaning up the source project by modularizing it, moving definitions to external files to make the source more manageable, and discovered a bug in the File I/O interface.
The plugin I’m working on works 100% (it exports pixel art images to the SVG format, for vector illustrations), but while moving the code from the single source to external modules I accidentally messed up the order of global variables and the DLL initialization functions definitions.
So, what happened is that the plugin initialization procedures getFileExtension(), getFileTypeId() and getFileBoxDescription() were being defined before the global strings which the plugin returns as pointers to PM through these functions.
As a result, the compiled DLL still passed the initialization test, but ended breaking up the export dialog, which now was showing an empty list of available extensions:
I then moved the global strings definitions before the statement that imports the DLL functions definitions and everything was working fine again:
I’m not sure of the nitty gritty behind the problem, but I’m aware that with DLLs any string that must be shared with the calling application needs to be defined as global, in order to survive in memory when the DLL function ends and goes out of scope. Possibly, there’s a problem with the language I’m using, since I’ve only moved out of order the definitions; maybe it’s a single-pass compiler that is not able to handle properly these globals if they’re not defined before exported functions that use them.
At this point, I’m not sure what’s actually happening during the plugin initialization — it most likely returns a pointer to a string which is being destroyed after the function call ends, or it might be a null pointer to start with. I just don’t know, but I’ve kept a copy of the buggy sources, the compiled DLL (and its .exp and .lib files), in case you need it for debugging.
The most likely culprits here are the the file extension and file box description strings which are supposed to be returned when getFileExtension() and getFileBoxDescription() are called — somehow, their invalid pointers are breaking up the entire extensions list in the export dialog.
In any case, the problem is that PM NG shouldn’t break the whole export interface due to malformed plugin functions, i.e. it needs to have some sanitation checks in place to prevent that a third party plugin can end up disrupting the whole export interfaces (probably, if the plugin was declared to also handle import, this bug would affect the import dialogs too).