Let's start with a simple approach: Stored on your hard drive is a 1 to 1 image of an executable file. Your operating system allocates space for the executable file, reads it from the hard drive, and transfers control to the address where the executable file should start execution. That works just fine.
Now we can make it more complicated: When we create the executable file on the hard drive, compiler and linker create an image of the executable file, then they compress the executable file, then they encrypt it with your public key, then create a checksum using their private key. No loading the executable file into memory is just slightly more difficult:
Your operating system reads what is on the hard drive. Then it uses the compilers public key to check if the checksum is correct. If it is correct, then the operating system knows that only the genuine compiler could have created the checksum, so the data is genuine and not forged by a hacker.
Then the data is decrypted using your private key. This will only work if the compiler used your public key to encrypt the data. So if a hacker manages to get a copy of the encrypted data, they cannot decrypt it without your private key. So the compiler is now sure that the executable file didn't fall into the wrong hands.
Next the data is decompressed - that's only done to save time to transmit the executable. There are actually computers where reading say 1MB of data and decompressing it to 2MB is both faster, and saves space on your hard drive. That's the reason for this step, to save some space.
Well, and at that point the data is in RAM and execution can start, just as before. The only difference with the three steps (compression, encryption, checksum) is that we save some space and possibly time due to the compression, that the compiler knows the code didn't go to some hacker, and that your computer knows it wasn't a hacker producing the code.
