Could you, please, comment more your code. As I want to understand it completely and not just use it.

For me it is a good enough solution to have one common .com file per application which I want to use from CON and GUI both.

Kind regards,
Posted on 2005-06-09 13:58:38 by SamiP
Hi SamiP,

While commenting and further testing the method I posted earlier, I found it has a number of problems:

  • The loader has to be at an unusual base address so as not to clash with the GUI app

  • If they do clash, LoadLibrary doesn't seem to care and relocates them, even if the GUI app has no relocs. Even if there are relocs I don't think it applies them (not sure). When I applied the relocs myself there were still problems anyway...

  • It seems strange to have to build the IAT.. I can't find documentation saying it would be necessary, so why is it?

  • The GUI app would not be the one that started the process, so it will not get values it expects from, say GetModuleHandle(NULL). This can be solved by placing pointers to our own functions when building the IAT but still it doesn't seem very neat...

So I tried another idea- to copy the GUI app, patch it so that its subsystem is WINDOWS and the run it. This works much more nicely, with no need to build IATs or worry about relocations or hooking functions. It is probably also easier to understand.

Attached is the (commented :)) source of this new method and example executables.

EDIT: added assembler version of the above. is the C++ version, the asm version. Example executables are only in the C++ one, though, which is also better commented.
Posted on 2005-06-10 09:31:32 by stormix