   Inprogram to beable to export to an executable
  Right now I am considering of making my program, a game engine beable for the user to make the game using Drag and Drop and then beable to export it to there own game (.exe for  windows etc) so how would I beable to do this, do they have to have extra software like a compiler or a linker. I just want then to beable to click on export and they will have there own game file. I really hope someone could help me.   
  You could make a stub program containing your engine logic (engine.cpp etc.) and build it into an object file (engine.o etc.). When the user builds their game project, the game logic that they've created gets written to a file (game.dat), in the form of either a scripting language or bytecode. You can use objcopy to compile this data file into an object file (game.o), which you would then link with the engine application using ld to produce an executable.You can find a basic tutorial on how to use objcopy at LinuxJournal.   ;  thankyou. so does that mean there will be no aditional download on the users end?   ;  I'd try to instead hack the data section of a PE executable stub, inject the properly formated user data into the .exe, for that you'll need to study the PE format specification for a while, but no compiler or linker would be required.A test or maybe sufficient enough for your idea would be to provide a large empty buffer to your executable and later replace the empty space with the user data, but that would limit the amount of data a user can pack into a game to the size of the buffer (You may have to recalculate a cyclic redundancy test number).   ;Quote:so does that mean there will be no aditional download on the users end?Right. If you distribute a component of GCC, you are required to provide a link to the GCC homepage or source, so that people have access to the source code, but your application does not need to be under the GPL, and you can sell it.Quote:I'd try to instead hack the data section of a PE executable stub, inject the properly formated user data into the .exe, for that you'll need to study the PE format specification for a while, but no compiler or linker would be required.Any answer that has the word "hack" in it...What's so bad about the solution I proposed? It's easy, it doesn't require directly muddling with an executable file format, and it's cross-platform. The only reason I proposed what I did is because I've gone down both roads and I find that one unnecessarily bumpy.;Quote:Original post by EvincarOfAutumnWhat's so bad about the solution I proposed? It's easy, it doesn't require directly muddling with an executable file format, and it's cross-platform.Quote:Original post by EvincarOfAutumn...which you would then link with the engine application using ld to produce an executable.That. It means distributing binutils (at the very least, since you'd also need the Windows API libraries) for Windows and writing a lot of wrapper code around it, or expecting users to download and install it on their own, chances are, your market is 90% non technical Windows users.I think probably the cleanest would be to write some sort of self extracting executable that extracts the engine and data to the/a temp directory and runs the executable from there, passing the location of the original self extracting exe to write saves and such.   ;Quote:It means distributing binutils (at the very least, since you'd also need the Windows API libraries)Nothing wrong with that. Of executables, you would need objcopy and ld, and of libraries, you'd need only a small handful, what you actually use in your engine.Quote:writing a lot of wrapper code around itCare to explain? As I see it, there's no need to write any real "wrapper code" other than simply invoking objcopy and the linker. ld does all of the real work. On Windows, you can also include windres if you want the user to be able to specify their own application icon.Quote:I think probably the cleanest would be to write some sort of self extracting executable that extracts the engine and data to the/a temp directory and runs the executable from there, passing the location of the original self extracting exe to write saves and such.That is an interesting solution, to be sure, but probably overkill in this situation. The self-extractor stub has to be written, for one, and the engine has to manage its temporary directory, all transparently to the user. Why bother?   ;  Have two files:engine.exegame.datEngine.exe contains everything needed to run game.dat.Game.dat contains resources and game description.Last 4 bytes of game.dat contain the size of game.dat.Next:copy /B engine.exe + /B game.dat /B final.exeThis packs the resource and engine into one single file called final.exeWhen engine starts, it does the following:#include <iostream>#include <fstream>int main(int argc, char **argv) {std::cout << argv[0] << "\n";std::ifstream f(argv[0]);f.seekg(-4, std::ios_base::end);  // last 4 bytes of executableint size;f.read((char*)&size, 4);// read size of game.datf.seekg(-size, std::ios_base::end); // go to start of game.datchar * data = new char[size];// read entire game.datf.read(data, size);}And voila - data contains 'game.dat'.And it's not even hackish. May require a slight tweak for *nixes (maybe even for Windows with user accounts), perhaps it would be necessary to copy the executable to temp, and work on that copy.   ;Quote:Last 4 bytesThis thread is over. Antheus wins.;Quote:Original post by EvincarOfAutumnQuote:Last 4 bytesThis thread is over. Antheus wins.Its similar to what I originally proposed, a more detailed implementation, sure, but not too far from the idea.Anyway, in the end it all comes down to what do you allow yourself to have and what not, you could just as easily add some installer generator and have the executable produced be the installer of game.exe and game.dat into Program Files, so it all comes down to your restrictions on the final product.   