maelh / hxd-plugin-framework

Plugin framework for HxD's data inspector
Mozilla Public License 2.0
166 stars 22 forks source link

HxD 'Plugins' folder not being looked for specifically relative to the HxD Application folder? #5

Closed DigicoolThings closed 1 year ago

DigicoolThings commented 2 years ago

Hi Maël,

A user of my Disassembler Plugin (exodustx0), has noted an issue when running HxD via the Windows "Open with" context menu. i.e. When opening HxD via right clicking on the target file.

When this is done, the Plugin does not appear to be activated by HxD.

Thinking the issue was just a problem with my Plugin itself not correctly locating it's own CPU Definitions (which default to being in the same 'Plugins' relative directory), I started implementing changes to ensure relative directory references also look relative to the actual Application path.

However, in testing I determined that in the case of "Open with" context menu use, my Plugin wasn't even being called/initialised by HxD.

i.e. It appeared HxD was not finding the HxD Applications directory's 'Plugins' subfolder, and therefore not intialising the Plugins contained therein.

I am now wondering if HxD is ensuring it looks for it's 'Plugins' folder relative to the Applcation path, to cater for cases where HxD is not being run directly (e.g. when run via the File Manager's "Open with" context menu)?

For interest, in first attempting to resolve this in my Plugin, I locate the actual Application's path via the either of the following:

  ApplicationPath := ExtractFilePath(Application.ExeName);
  // or
  ApplicationPath := ExtractFilePath(Paramstr(0));

...which I have verified returns the expected HxD installation folder.

In my Plugin's case, I also determine if the user provided CPU defintions path (DefinitionFilePath), is a Relative path or a Fully Defined path via:

System.IOUtils.TPath.IsPathRooted(IniSettings[CurrentDasmType].DefinitionFilePath)

But, as I say, my testing of the changes I need to make within my Plugin (essentially to not assume a relative folder reference is relative to the Windows Current Path), came to a halt when I discovered that HxD itself appears to not be calling/initialising my Plugin at all, when called via the Windows "Open with" contect menu.

Hope you can assist with zeroing in on the problem, so that I can find a solution to ensure the 'Plugins' relative folder (or any HxD application folder relative reference), is always being correctly located.

maelh commented 2 years ago

HxD will determine the Plugins directory using this logic:

PluginsPath := IncludeTrailingPathDelimiter(ExtractFilePath(ParamStr(0))) + 'Plugins';

ParamStr(0) is equivalent to calling GetModuleFileName(0, [...]), which means:

If this parameter is NULL, GetModuleFileName retrieves the path of the executable file of the current process.

Please be aware that the Windows explorer context menu integration is meant to be used with an unchanging executable directory, i.e., preferably the installed version of HxD, not the portable one. But it works fine, either way:

I just tested it with the demo plugins given in the framework and it works fine, when HxD is installed. It also works with the portable version, when adding it to the Windows explorer context menu. Both times the plugins in the Plugins directory get loaded properly, when the folder structure is as follows:

FolderName\HxD.exe
FolderName\Plugins\

Maybe "Open with HxD" starts another HxD.exe than you think? Try removing the Explorer integration and then readding it, and remove duplicates of HxD.exe on your disk to make sure the right one gets loaded.

maelh commented 1 year ago

Since there has been no feedback anymore, I assume the issue is resolved.