How these executables access those assets and scripts if they are packed into single archive?
It's quite simple, actually.
Archive formats store some sort of look-up table somewhere in the file. In a very basic archive format, each entry in your table will contain the name of the file, the offset of that file in the archive (ie: where to fseek to), the compressed size of the file, and the size of the file when decompressed. It could also store flags such as whether the file is compressed, which can be useful if you're storing files that are already compressed (such as PNG images) because there's no point in compressing a file twice.
Typically, how it works is that your code will tell your I/O module to include an archive in the search path. Then, the first thing your I/O module will do (well, after maybe file-mapping the archive) when you give it that archive is to read that table and put it in somewhere in memory, probably in a dictionary or a hash table, so it knows where to find all the files. Later, when your program requests a file from that archive, your I/O code can quickly determine whether that file is contained in the archive, and it already knows where to find it. (In what archive and at what offset.)
For a very simple real-life example, here's the archive format of good old FFVII's LGP files: http://wiki.qhimm.com/view/FF7/LGP_format. It's obviously a very simple archive format. A lot of companies want additional features such as encryption or formats that make it easy to update, remove or insert files without rebuilding the whole archive.
Also, sorry if I'm stating the obvious, but Archive formats, including generalist ones like ZIP, don't compress all files together. Rather, each file is compressed (and optionally encrypted) separately, AND THEN concatenated into one single (or several) archive. Otherwise you would have to decompress the entire file to reach a file stored at the end of the archive, which is obviously not optimal.
Shameless plug but since this is related to the topic, I'm actively working on an archive format partly inspired by Blizzard's MPQ format which I am a fan of, with an easy to use C++ 11 API library to access those archives. It has/is going to have features like built-in localization support, platform-based include/exclude of files, first-class support for modding and patching, high performance file reading, multi-threaded access, etc. I wonder if there would be any interest in that kind of library because I wouldn't mind releasing it to the public if it's something that could help developers.
Edited by Bearhugger, 14 August 2013 - 01:42 PM.