Well, the Dependency Walker thing got a bit spread out between this thread and the one regarding my 3D Engine...
It's wrapped up now for the most part, covered in this thread: http://www.asmcommunity.net/board/index.php?topic=29617.msg209612#msg209612
It implements some of the 'hinting' that I spoke of in the above post.
I suppose that pretty much wraps up this thread. 64-bit abstraction is in place, and I have the basic checking of dependencies to pinpoint loading problems that we were brainstorming about earlier.
Posted on 2009-11-15 05:27:53 by Scali
This technique of a single 32-bit executable that optionally launches a 64-bit one is the same technique that some sysinternals tools use, like Process Explorer and Process Monitor.
Posted on 2009-11-15 21:50:32 by comrade
Yea Comrade, ChaperonNoir also said something about that. Apparently they include the 64-bit binary in the resource section, and execute it when they detect running in Wow64 on an AMD64 machine (would be cool if they forgot to check for Itanium, like my code does, so theirs would crash on IA64 :) But I doubt that, in fact, I wouldn't be surprised if they had a native IA64 image in there aswell).
Posted on 2009-11-16 06:47:17 by Scali

You could delay-load potentially troublesome DLLs, and use SEH to handle the situation - dunno if you get the DLL name in the exception handler, though.

Revisiting this idea a bit...
Theoretically you could 'reverse' the DLL loading order, right?
Eg, I have DLL X, which loads DLL Y.
I can delay-load X, but X doesn't have delay-loading for Y.
However, if I know that X depends on Y, I can delay-load Y myself, before X attempts to.
Once I already loaded Y, then it can no longer fail for X, it will just re-use the in-memory copy (insert UPX-rant here).

In more general terms... you can 'flatten' the 'tree' that is the DLL dependencies, and try to delay-load everything in a depth-first kind of way.
This flattening could be automated via the dependency walker. It can build you a sorted list of the DLLs to load, then you just delay-load them for your application, and use a generic handler. That way the dependency walking isn't required at runtime.

It's just a thought, do you think there is any use in this approach?
Posted on 2009-12-24 06:39:46 by Scali