Embedding data (such as images) in a executable seems to have a few advantages, like easier distribution of the executable and easier compatibility with different OSes.

But, is it a good practice? More specifically, how does the OS deals with a big executable? Would it be using much more RAM than needed?

  • Do you mean using Resources or actually embedding images in constants in source code? Dec 22, 2014 at 10:36
  • 1
    I mean more like embedding data as constants, since Resources are Windows-only AFAIK. Dec 22, 2014 at 10:39
  • If you are looking for something cross-platform you will need to give some specifics about the environment. All the platforms that I know of have the concept of bundling resources with executables in some form or another Dec 22, 2014 at 11:24
  • @TristanBurnside Really? I wasn't aware that you could bundle resources in executables on Linux! Do you have any specifics on that? Dec 22, 2014 at 11:40
  • 1
    Well, my original question is about bundling data in executables. Dec 22, 2014 at 11:54

2 Answers 2


For embedding data files directly into an executable, there's several things to consider.

If the data isn't needed, will it be loaded? If your program always needs the data then the answer is "no". Also, for most OSs the executable file is memory mapped (where parts aren't loaded until they're used) so the answer may be "no" anyway. If the answer is "yes" then embedding the data files directly into the executable may increase startup time and waste RAM.

Will the data be needed temporarily (e.g. an image that's only shown when the application is starting)? In this case you want to free the memory when you no longer need it, and it can be hard/complicated to free part of the executable file.

Is there's an executable file size limit? For example, maybe it needs to work on some sort of 32-bit system where there's a 2 GiB executable file size limit, and the data you're embedding simply won't fit.

How well do your tools handle it? For some tools it's extremely easy to insert arbitrary binary files "as is" into an executable or object file (e.g. NASM's incbin or GAS's .incbin directive). For other tools it can be a pain in the neck (e.g. converting it to an array of bytes you can include as source code just so the compiler can convert it back into binary).

How hard should it be for people to modify/change the data? This can go both ways - maybe you want to make it easy for other project members (e.g. artists) to change the file and embedding it is a disadvantage; but maybe you want to make it hard for end users to change the file and embedding it is an advantage.

How hard is it to actually use the embedded data? For some cases (e.g. libraries that expect a file name) embedding the data might cause significant problem.

Will you have some sort of "auto-updater"? If you will, then it'd be more efficient to have multiple smaller files that can each be updated independently, rather than one large file where you can't update part of it and have to replace/update the entire file.

  • 1
    Good answer. Whether it is a good practice or not depends strongly on the needs of the app: how often the resource will be changing, memory requirements, ease of tools, etc. But overall I'd add this: It isn't necessarily a bad practice. It just depends. Dec 23, 2014 at 5:40
  • Thank you. I suppose one size doesn't fit all. Dec 23, 2014 at 10:19
  1. If you mean using Resources, then embedding images and similar data is fine. They are loaded on demand, so the memory footprint won't change a lot.

    You may also end up putting this data in an external DLL, which has a benefit: if you need to push a new revision of your software to your clients' machines, you don't need to send the DLL containing the resources, unless they changed too.

    Remember that Resources are fine for icons or localized strings or images shown by your app, but there may be easier ways to do what you need to do. For example, I may use Resources for a 2D game which uses a few sprites, but not to store hundreds of textures for a large 3D video game: either storing the textures directly or in a 0% ZIP container would be a more flexible way to do it.

  2. If you mean embedding data directly in source code in constants, I'll rather avoid it for mostly those three reasons:

    • You may not necessarily need the data to be available directly. If it's stored on disk, you can access it through a stream. If it's a constant, you are forced to get it all at once.

    • Viewing and editing data would be hell. In general, developers don't have skills to visualize (and modify) images through their binary/hexadecimal representations. What if you copy-pasted the image in the wrong constant? What if you need to change the image? The readability (and maintainability) of your code suffers, and you don't want that.

    • How do you store binary data in a text file? Hexadecimal form will waste a lot of space. Even Base64 has a 4:3 ratio. Moreover, you would need to find (or write) a converter.

    and also because:

    • You may start getting weird problems, such as the encoding issues.

    • Compilation may take more memory (depending on your language, framework and compiler),

    • Compile times may be affected (depending on your language, framework and compiler),

    • Start time and runtime memory footprint might be affected, although it shouldn't be assumed, but rather measured. Different languages, frameworks and compilers may perform differently.

  • "Viewing and editing data would be hell"...I've had to do this in the past in an embedded system environment with no file system. You can write a utility to convert a binary file to static C (or whatever language) source array data then compile the data into the executable. If it is a small amount of data that doesn't change often this work OK. If the data constantly changes, this is no fun unless you find a way to add such a utility program to the build process.
    – semaj
    Dec 22, 2014 at 16:54
  • @semaj Actually, it seems pretty easy to it with linuxjournal.com/content/… . Dec 22, 2014 at 17:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.