views:

268

answers:

2

Is there a way to link an existing .exe file with other C++ source files during compilation? What I'm actually trying to do is to compress and decompress some files in my console program using LZMA(7zip) SDK but unfortunately it's very difficult to use for a newbie.

There is a command line version of LZMA called 7za.exe and I am wondering if I can somehow embed it into my program and use it like a function. It can be easily used with system() function (which seems to be a very dangerous thing to use) but then if I send my program to someone who doesn't have 7za.exe in the right folder it won't work.

I came across CreateProcess() function in windows.h header files but it seems to achieve what system() does in a more proper and advanced way. I don't know if it can actually link the exe file like an object file during compilation

+1  A: 

CreateProcess() is a Windows API call to start a process, exactly as it sounds like, as a child of your program that you can control by knowing it's HANDLE. system() executes a system command. That's as much as you'll ever know and I personally avoid using it at all costs - not least because it isn't portable (the function exists on windows and linux but the command won't).

It is possible to append the data to the end of an EXE image - this is how installers work. Have a look at this microsoft support article, which bizarrely gives you code in basic but you should be able to turn it into C++ trivially. Here's an article on creating a self-extractor which might be more suitable. Both should allow you to embed files in the exe.

I don't recommend you extract 7za and call it from System() or CreateProcess() - I recommend you learn the SDK. It is difficult, but you'll learn a lot from doing it.

Finally, as you'll have to modify an existing exe file you won't be able to do this at compile-time. You'll need to have the code add whatever to its own image or another image.

More detail on addressing data appended to an exe.

Ninefingers
A: 

Okay, try this...

  1. Write a command-line utility that merely copies one file to the end of another. You could do this with Windows file I/O or shell commands.
  2. Make a post-build step that runs this utility. Your program will fully link the usual way, and then your utility will merely append bytes of the second exe to the target exe.

That is the linking step. Now runtime access to the exe is a different thing. Essentially, the algorithm is this:

  1. Open up the EXE to be embedded in a byte-level binary editor (msdev.exe will do). Take note of the first 30 or 40 bytes as a unique marker for the beginning of the file.
  2. Write a function that opens the compound file created above and searches for the embedded file by looking for the unique marker.
  3. Once the beginning of the embedded file is found, copy the bytes of that file to a second new file using file I/O.
  4. Execute the new file using system() or similar API.

If you distribute somebody else's work this way, please get the licensing correct. It generally is copyright infringement to throw someone else's binary into your own--there are exceptions, of course.

Erik Hermansen