views:

320

answers:

6

Ok, so I was wondering how one would go about creating a program, that creates a second program(Like how most compression programs can create self extracting self excutables, but that's not what I need).

Say I have 2 programs. Each one containing a class. The one program I would use to modify and fill the class with data. The second file would be a program that also had the class, but empty, and it's only purpose is to access this data in a specific way. I don't know, I'm thinking if the specific class were serialized and then "injected" into the second file. But how would one be able to do that? I've found modifying files that were already compiled fascinating, though I've never been able to make changes that didn't cause errors.

That's just a thought. I don't know what the solution would be, that's just something that crossed my mind.

I'd prefer some information in say c or c++ that's cross-platform. The only other language I'd accept is c#.

also

I'm not looking for 3-rd party library's, or things such as Boost. If anything a shove in the right direction could be all I need.

++also

I don't want to be using a compiler.

Jalf actually read what I wrote

That's exactly what I would like to know how to do. I think that's fairly obvious by what I asked above. I said nothing about compiling the files, or scripting.

QUOTE "I've found modifying files that were already compiled fascinating"

Please read and understand the question first before posting.

thanks.

A: 

Ok, so I was wondering how one would go about creating a program, that creates a second program

You can look at CodeDom. Here is a tutorial

ram
Maybe I misread what I found, but it doesn't appear to be relavant. I appreciate the links though, better than how some people just say "use SomeFunction". Oh, well if I knew all about that function I wouldn't be asking :p
kelton52
+3  A: 

Invoke a compiler with data generated by your program (write temp files to disk if necessary) and or stored on disk?

Or is the question about the details of writing the local executable format?

dmckee
sorry I didn't specify...I'll update my question
kelton52
Unfortunately, given that you don't want a compiler, this is the correct answer and the only way you're going to get an executable at runtime.
Billy ONeal
+3  A: 

Unfortunately with compiled languages such as C, C++, Java, or C#, you won't be able to just ``run'' new code at runtime, like you can do in interpreted languages like PHP, Perl, and ECMAscript. The code has to be compiled first, and for that you will need a compiler. There's no getting around this.

If you need to duplicate the save/restore functionality between two separate EXEs, then your best bet is to create a static library shared between the two programs, or a DLL shared between the two programs. That way, you write that code once and it's able to be used by as many programs as you want.

On the other hand, if you're really running into a scenario like this, my main question is, What are you trying to accomplish with this? Even in languages that support things like eval(), self modifying code is usually some of the nastiest and bug-riddled stuff you're going to find. It's worse even than a program written completely with GOTOs. There are uses for self modifying code like this, but 99% of the time it's the wrong approach to take.

Hope that helps :)

Billy ONeal
as for your first paragraph...Please read my edit. I appreciate the rest. Thanks.
kelton52
+3  A: 

Building an executable from scratch is hard. First, you'd need to generate machine code for what the program would do, and then you need to encapsulate such code in an executable file. That's overkill unless you want to write a compiler for a language.

These utilities that generate a self-extracting executable don't really make the executable from scratch. They have the executable pre-generated, and the data file is just appended to the end of it. Since the Windows executable format allows you to put data at the end of the file, caring only for the "real executable" part (the exe header tells how big it is - the rest is ignored).

For instance, try to generate two self-extracting zip, and do a binary diff on them. You'll see their first X KBytes are exactly the same, what changes is the rest, which is not an executable at all, it's just data. When the file is executed, it looks what is found at the end of the file (the data) and unzips it.

Take a look at the wikipedia entry, go to the external links section to dig deeper: http://en.wikipedia.org/wiki/Portable_Executable

I only mentioned Windows here but the same principles apply to Linux. But don't expect to have cross-platform results, you'll have to re-implement it to each platform. I couldn't imagine something that's more platform-dependent than the executable file. Even if you use C# you'll have to generate the native stub, which is different if you're running on Windows (under .net) or Linux (under Mono).

Fabio Ceconello
Perfect. To point something out though, there are linux and windows executables...linux just doesn't use the suffex .exe . But this is interesting, I didn't realize they did something so ridiculously easy. That almost seams like some kind of cheating to me. But that's basically what I wanted to know. Thanks.
kelton52
Well, to correct what I wrote, I should've said "...than the executable file", not "...than the executable file format". The PE(Windows) is really a variant of COFF(Unix), but you have different runtimes, different symbols in the import tables for the OS API, etc. All those things would need to be implemented specifically for each targeted OS. And also today ELF is a more popular format in Unix-like OSes, and it's significantly different from PE and COFF.
Fabio Ceconello
A: 

Have you considered embedding a scripting language such as Lua or Python into your app? This will give you the ability to dynamically generate and execute code at runtime.

From wikipedia:

Dynamic programming language is a term used broadly in computer science to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them.

mikelong
I wrote a small script language. Thanks for your awnser, but please read my edit.
kelton52
A: 

Depending on what you call a program, Self-modifying code may do the trick.

Basically, you write code somewhere in memory as if it were plain data, and you call it. Usually it's a bad idea, but it's quite fun.

Bastien Léonard
That sounds exciting.
kelton52