New daemon.dll behavior

[Jaime]

With the new Daemon Tools version, when daemon.dll is loaded from another application, it loads the libraries that it depends on from the app's current directory, unlike previous versions that loaded them from the correct path. This leads to an error stating that cryptapi.dll or other libraries can't be found.

That can be solved, for example by copying the executable that loads daemon.dll to the Daemon Tools install folder, or by changing the current dir before loading the library, but this is senseless in my opinion, since it worked fine before.

So the question is:

Is this a bug or is it intentional?; since having to revise working code because of this doesn't make much sense IMO.

[DevX]

Prob is that daemon.dll is now linked statically to cryptapi.dll
and Windows loads it from current directory only, so this is neither bug nor intentional.
We'll think about how to solve this prob better...

[Jaime]

Adding the Daemon Tools install folder to the PATH environment variable is an easy fix, so it's not such a big deal.

By the way, will a future version or your soft be able to coexist with a kernel debugger (f.e. Softice) as it was possible with 3.x?

[Copytrooper]

By the way, will a future version or your soft be able to coexist with a kernel debugger (f.e. Softice) as it was possible with 3.x?

No, of course not.

[Elandril]

By the way, will a future version or your soft be able to coexist with a kernel debugger (f.e. Softice) as it was possible with 3.x?

That would make it a bit to easy for the bad guys, I guess. You can all take your guesses who the bad guys are.