Original Idea : Gal Badishi

The original idea of this project was to create a generic application that is capable of "Gluing" together two independent application - and run them as if they are glued head to tail.

This application is supposed to run in a win32 environment, and work with Portable Executable files.
When one wishes to run an executable in win32 environment he just double-click it, and here the file starts running. What he doesn't know, is that Windows works fairly hard behind the scenes.
When windows wants to run a file, it first need to setup the memory space needed for the executable, load the executable's code itself in this memory, then load and prepare any external code and other resources the executable needs. After all this is done, the OS can finally start running the executable's code. Doing all those steps, prior to running the first code from the executable, let us (as programmers) more power in writing complicated softwares.

In the old days of DOS, we had COM files, where COM stands for Copy Of Memory. in those days, in order to run such files - the OS needed only to load the image into memory, and start processing the first instruction.
This was indeed easy to implement and manipulate, but in DOS we didn't had Dynamically Link Libraries (aka dll), nor we had Resources (and a whole bunch of cool stuff). In order to support such concepts - the OS should work a bit harder than just load an image into memory, this is what the Windows Loader does.

Every PE file that uses even one windows' API, needs to have an Import Table (a table where the Compiler 'tells' the OS what dlls it needs, and where to put them). By using this table - the OS can set the proper environment for the application. setting the environment cannot be done in runtime, it must be done prior to any application's code execution. But we have only one chance to set the environment for two applications.
If the file use resources (like most windows applications), things became even harder. The loader keeps a pointer to the resource section of an application - and use it when any Resource related API is being called. Again, we have one pointer, but two resource sections (assuming both applications are using resources).

The main challenge in this project, was to fool each application to think that the windows loader set the environment as it should, while a loader we created is the one that sets the environment for the applications.

In our eyes - the highest revenue from this project was our education. We studied a lot about how windows handles executable, what can and what cannot be manipulated in the loading process and how windows builds the environment prior to executing code. we learned how to use windows APIs, how to write assembler and how to use disassembles and debuggers. but mostly we learned how to search, investigate and finally master an unknown and undocumented area.

The application we created can be downloaded in the Binary section, this application is not perfect - and was never intended to be perfect, it is merely a proof of concept application (all though it has been successfully tested with a lots of files). please see release notes in Binary Section.
Ran Didi Gil Arbeli