Suggestion for Plugin handling

[Felheart]

Hi L.Spiro,
I have a simple feature request.
I'am currently developing a DLL for MHS (wich I will release here soon).
MHS loads the DLL directly from the project->release directory,
so I can't recompile until I delete all breakpoints and unload the DLL.
Could you add a feature so MHS doesn't "hold the dll" open + that MHS reloads the plugin as soon as changes are made ( ReadDirectoryChangesW Function )
This would be really great. It would save me and other plugin developers lots of time!
Thanks.

edit: also a question:
is it possible to tell MHS it should "SINGLE STEP" after calling the Custom Function from a DLL (ie: when working with breakpoints)?

[L. Spiro]

It is impossible to release a file just before it needs to be modified.
All I can do is add a feature to allow you to unload all DLL’s before you compile and reload when done.

It is impossible to single-step from a breakpoint. Doing so will invariably cause a lock-up.
However I already plan to add a feature to allow a delayed single-step from breakpoint handlers.


L. Spiro

[Felheart]

It is impossible to release a file just before it needs to be modified.

But it would be possible that MHS copys my breakpoint.dll to MhsDir\Dlls\breakpoint.dll.loaded or Memory-File-Map it directly into the memory or something.
Then it is possible that I can recompile without the linker, telling me that it cannot open the file and MHS releases and deletes all old copys and loads the new dll.

So basically the same as you said here

All I can do is add a feature to allow you to unload all DLL’s before you compile and reload when done.

but automatically.

And isn't breakpointing to a dll function the same as single stepping, with the diffence that it also calls a function?
Thanks!

[L. Spiro]

It is reasonable to consider a system that would have MHS watch the DLL it is actually using for changes and reload when changed (although impossible). It is not reasonable to add a system where MHS is using this DLL but watch that DLL for changes.

If you want such a system I will add the appropriate script functions for allowing one to make it him- or her- self.




As for single-stepping, what is your question?
You can not call SingleStep() from a breakpoint handler.
If that is not what you want to do, then you do not need to worry about anything else.


L. Spiro

[Felheart]

Why wouldn't that be possible? just copy the dll the user wants to open to
another path and open it from there, while saving original path to that file.
Now watch for that original file, while using the copy in MHS. when the original file changes, MHS reloads it.
This is easy to implement, isn't it?
If you are willing to make it possible through LSS, please do so, I will write a script for that feature then

As for the Single-Step thing: It's all clear now!

However I already plan to add a feature to allow a delayed single-step from breakpoint handlers.

Would be great!

Thanks L.Spiro!!

[spunge]

Having a feature that will unload all plugins is just as easy, and won't have the overhead of constant checks towards the file. Otherwise, your idea is plausible.

[Felheart]

Having a feature that will unload all plugins is just as easy,

I'am sorry I don't understand you correctly. Do you mean automatically? Or an extra button?
Because there already is already such a tool (Button)
Disassambler -> Tools -> BreakpointHandler Manager
But this way is inconvenient, because you have to remove all breakpoints by hand, unload the dll, compile, load the dll, set breakpoints again.....
Time consuming

I know what you mean by constant checks, but there is a WinAPI function
wich does these checks without a loop. Like a "FileModify hook".
I postet it in my first post: http://msdn.microsoft.com/en-us/library ... 85%29.aspx

It doesn't require you to do crap like this: while(1){ if(FileChanged()) {...} }
I read about it some time ago, it's really usefull when polling things is wasting to much resources and would be perfect to make a function that just "switches" or more precicely "hot-loads" the new dll.

[spunge]

It would be better if the breakpoints automatically were disabled upon dll unload, and having an instruction check for dll reload. If the instruction at the breakpoint previously matches before the reload, the bp is reinstated.

[Felheart]

It would be better if the breakpoints automatically were disabled upon dll unload, and having an instruction check for dll reload. If the instruction at the breakpoint previously matches before the reload, the bp is reinstated.

IF L.Spiro decides to implement it, that should of course be the main-part of this feature, besides auto-unload / auto-reload!
(because otherwise it's sort of useless and doesn't save time at all ^^ )

[spunge]

It wouldn't be useless considering the fact, offsets might change during PE file compilation.

[L. Spiro]

Your idea for watching a second file to determine the automatic reloadingness of the actual file in use is plausible, but not reasonable.

Yes, the underlying mechanism is simple. But in order to expose it to the user I then I have to add additional buttons, pop up another dialog, make 2 modes (one that does no watching and one that optionally watches an alternative file), save all of these settings to the settings file, and then reload them all again upon next start-up.

Frankly I am not into MHS that much anymore.
Adding the functions needed to do this to L. Spiro Script will be a more valuable enhancement that can be used in many more places.


L. Spiro

[Felheart]

Frankly I am not into MHS that much anymore.
Adding the functions needed to do this to L. Spiro Script will be a more valuable enhancement that can be used in many more places.

Thats very unfortunate to hear. MHS the best memory editing _environment_
i've seen so far and Iam sure that Iam not the only person who thinks that.

However, it's good to hear that you might add all the needed functionallity to
the scripting engine! Iam staying tuned for updates