`DefinitionFilePath` keys in config not relative to HxD root directory

[exodustx0]

Hi there, been a while. I've had this issue for a few months now, but it's only now that I've discovered that files inside of HxD's root directory do still work.

To elaborate, when I open a file that's located in HxD's root folder in HxD, with the plugin loaded, it disassembles as expected. Any other file, including in sub-directories of HxD's root folder (like the plugin's DLL itself), will have the plugin produce "invalid" reports and not write log files for every ISA definition. Note that HxD's internal x86 disassembly types still work as normal.

The weird part is that this wasn't an issue in the past. In fact, I hadn't changed a thing about HxD, the plugin, or any of their configs between the plugin working for me and noticing this issue. There was only one notable event that I can point to as the origin of the issue, which was my PC having utterly frozen up one day, forcing me to force-shutdown. (For context, I had to reinstall some other apps in order to get them working again; apparently a few files got corrupted in the force-shutdown.)

I have completely purged this plugin and HxD from my system (program files, registry keys and AppData config files, as far as I could find them, but I might've missed something) and reinstalled them, and unlike with other apps that worked after doing this, the plugin remained in this state.

Unfortunately I don't know how to diagnose this issue further. Do you have any ideas?

[exodustx0]

Wow. I found the cause! That didn't take long at all.

The issue is with the DefinitionFilePath key in the plugin's .ini file. It looks to me like it's always treated as an absolute path, with only one relative-path check relative to the input file. Though, as I remember this plugin always working in the past, I assume it must've also had a hardcoded check for specifically paths relative to C:\Program Files\HxD? Or C:\Program Files (x86)\HxD. Weird how this stopped working before I moved the HxD install to another directory in an attempt to diagnose the issue when I first discovered it.

Personally I don't think it's terribly useful to allow people to store ISA definition files anywhere other than with the plugin in HxD's Plugins directory, so I'd suggest removing the DefinitionFilePath key altogether, or at the very least forcing it to be relative to HxD's root directory. Thoughts?

[DigicoolThings]

Hi,

The DefinitionFilePath is not hardcoded to be relative to any specific installation path.

If DefinitionFilePath is specified without a leading fully qualified path definition, it is treated as being relative to the running application's "current directory" (ie. where it has been run from).

I believe this is normal behaviour for a Windows file path string.

i.e. The supplied default definition: DefinitionFilePath=Plugins results in the definitions living within the application's installation directory's "Plugins" subdirectory.

Although, if you ran the application from a different directory (to that which it was installed). i.e. With an application path specified (so the run-time "current directory" is not the actually the application's own directory), then not using a fully qualified DefinitionFilePath would cause the application to go looking in the "current directory" for a "Plugins" subfolder.

However if a fully qualified path defintion of DefinitionFilePath=C:\Temp (for example) was used instead, then the aplication would always look in the C:\Temp folder for the definitions. etc.

Hope this clarifies?

[exodustx0]

Huh, that leads me to believe that HxD's "current directory" is set to the directory containing the opened file, if the file is opened through the Open with HxD context menu item, at least.

I've just tested this, and can confirm that, when DefinitionFilePath=Plugins, opening HxD then opening a file in it will have the definition take effect, whereas opening a file through the Open with HxD context menu item will not have the definition take effect. I'm not sure whether this is an unfortunate thing on Windows' end, a bug on HxD's end, or simply meaning that HxD's "current directory" isn't the path you should be using for relative lookup.

[DigicoolThings]

Okay, I've now had time to recreate this issue (by your example of using the Open with HxD file manager context menu).

I then proceeded to work on a solution, based on refering to the Application's Path, but quickly came to the conclusion that the root of the problem looks to be starting with HxD itself.

Specifically, HxD itself is expecting plugins to be installed in the 'Plugins' subfolder (of the HxD installation directory).

It appears that when using the Windows Open with HxD context menu, HxD is no longer finding the Plugins folder, and is therefore not even calling / initialising any Plugins!

As a result my code does not even run, therefore I am not able to code for a path workaround to then allow the installed CpuDefinitions to subsequently be loaded correctly.

Once the root HxD problem is resolved (so that HxD still finds and initialises it's plugins when run from elsewhere vis the Windows Open with HxD context menu), I will then be able to implement code changes in my disassembler extension to also resolve the rest of the path issue (the path to the location of the CPU definitions).

Hope this makes sense. I'll leave this issue open, pending an eventual HxD fix, to then allow me to continue work with resolving the path issue in the extension.

[exodustx0]

Darn, that's unfortunate, but happy to see it's clear where the issue lies now. Have you informed Mael about the bug yet, or would you like me to do it?

[DigicoolThings]

Have you informed Mael about the bug yet, or would you like me to do it?

I've just posted an issue on the HxD Plugin github, here

This is a interesting problem, so it will be good to be able to identify and resolve. Hopefully Maël can assist with either confirmation of an HxD issue as well, or alternatively some clues which I might be missing.

[maelh]

I'm not sure whether this is an unfortunate thing on Windows' end, a bug on HxD's end, or simply meaning that HxD's "current directory" isn't the path you should be using for relative lookup.

When you start any program from the command line, the current directory will be set to whatever the current directory was in the command line. So if you run notepad.exe after you opened a new cmd.exe window, and the prompt looks like this:

Microsoft Windows [Version x.x.x]
(c) 20xx Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\YourName>notepad

The current working directory of the newly opened Notepad will be C:\Users\YourName. (You can use ProcessHacker to validate this). The rationale (of Windows) is that you should be able to continue working from the same context you started the app/Notepad from.

There are various mechanisms that control the working directory, such as last opened file or depending on where you opened the executable from, if it was started through the shell, another application etc.

So in general it's best to not rely on the current working directory as a fixed reference, since it's not meant to be a fixed one.