See, ZIP files are strange because unlike most other archive formats, they put the "header" and table of contents at the end, and all of the members (files within the zip file) are listed in that table of contents as offsets relative to the start of the file. There's nothing that says that the first member has to begin at the start of the file, or that they have to be contiguous. This means you can concatenate an arbitrary amount of data at the beginning of a ZIP file (such as an exe that opens its argv[0] as a zip file and extracts it) and it will still be valid. (Fun fact! You can also concatenate up to 64KiB at the end and it will still be valid, after you do some finagling. This means that when a program opens a ZIP file it has to search through the last 64KiB to find the "header" with the table of contents. This is why writing a ZIP parser is really annoying.)
As long as whatever's parsing the .exe doesn't look past the end of its data, and whatever's parsing the .zip doesn't look past the beginning of its data, both can go about their business blissfully unaware of the other's existence. Of course, there's no real reason to concatenate an executable with a zip file that wouldn't access the zip file, but you get the idea.
A common way to package software is to make a self-extracting zip archive in this manner. This is absolutely NOT to say that all .exe files are self extracting .zip archives.
See, ZIP files are strange because unlike most other archive formats, they put the "header" and table of contents at the end, and all of the members (files within the zip file) are listed in that table of contents as offsets relative to the start of the file. There's nothing that says that the first member has to begin at the start of the file, or that they have to be contiguous. This means you can concatenate an arbitrary amount of data at the beginning of a ZIP file (such as an exe that opens its argv[0] as a zip file and extracts it) and it will still be valid. (Fun fact! You can also concatenate up to 64KiB at the end and it will still be valid, after you do some finagling. This means that when a program opens a ZIP file it has to search through the last 64KiB to find the "header" with the table of contents. This is why writing a ZIP parser is really annoying.)
As long as whatever's parsing the .exe doesn't look past the end of its data, and whatever's parsing the .zip doesn't look past the beginning of its data, both can go about their business blissfully unaware of the other's existence. Of course, there's no real reason to concatenate an executable with a zip file that wouldn't access the zip file, but you get the idea.
A common way to package software is to make a self-extracting zip archive in this manner. This is absolutely NOT to say that all .exe files are self extracting .zip archives.