How are image files, sounds, data, etc. compiled/linked in to a single file?

Question

I'm both asking for me & future readers as to how pictures, sounds, textures, assets, and such are compiled and linked in to one binary/program, and how that process works.

I have seen this in standalone programs I have downloaded on Windows, and I'm fairly certain any OS can implement this. It appears that, instead of keeping the data stored separately as individual files within the filesystem, all data is converged in to one file. When you run the program, it's as if the data could have just, instead of requiring multiple scattered files through the drive, directories, subdirectories, etc., been bound to one program with everything in it; no need for fragmentation, missing files, etc.

So, to sum this question up, let me first illustrate some key points:

I had originally thought that, since all files on the computer are basically high-and-low voltage sources at the lowest level, files can be converged together, being similar to "zipping/unzipping files." Using this common ground, it's easy to see how the data of a file, any file, could be bound/binded together with other data, and act, from the scope of the filesystem and GUI, as "just a file." But many things are actually in it that don't have to only represent just a typical idea of a "program" with some people's view of it as only instructions like adding, moving data around, etc.

I am not sure of this, but I have a good sense that it's similar, so this why I'm asking for clarification.

When you see a standalone program from one file that contains external assets when you run it (texture files, video data format, image data, sounds, other resources, etc.), it's clear that the single executable file has all the data necessary "packed" in to one somehow, or the such.

How does the compiler/linker do this, how would the program/library/etc. access the data converged in it as opposed to differing from separate "files" independently, and how are compiler's/linker's settings adjusted to do this in any general sense?

NOTE: Programmers, StackOverflow, Superuser, and few others deny this question, and give no reason why, so I figured this area might see it fit.

Answer 1

A file is just a file. Any given sequence of bytes can be interpreted as instructions for the CPU, pixels of a graphics file or anything else. And a file can contain sequences of bytes that should be interpreted as instructions and sequences of bytes that should be interpreted as graphics. If the executable part has been written correctly, it will never try to interpret the graphics part of the file as CPU instructions; when it needs to refer to the graphics, it knows where they are in the file (and, hence, the memory image) and starts reading from the appropriate address. In principal, the operating system doesn't even need to know it's doing this.

Answer 2

Sounds like you've already have a good intuition for this; your understanding is about right. How do they do it? They include the external asset in the file, as part of the file. You understand how you can create a zip file that contains multiple files, right? Well, one can do the same thing when creating a standalone program (embed multiple other files or other resources in it). There's nothing super mysterious or magical about it: it's pretty much the obvious approach that you would probably come up with, if you faced this problem.