It doesn't use it as source code as much as byte code. It doesn't have to compile or even translate it into local machine code -- all the programmer has to know is what bytes mean what instructions.

How about an imaginary processor with three registers and three instructions?

Code:

#include <stdio.h>

int main(void)
{
        int running=1;
        // The memory the emulated program is read from
        unsigned char program[]={0x01, 13, 0x02, 12, 0x03, 0x00 };
        unsigned char a=0, b=0, ip=0; // A reg, B reg, instruction pointer

        while(running)
        {
                printf("A=0x%02x B=0x%02x IP=0x%02x\n", a, b, ip);
                switch(program[ip++])
                {
                case 0x01:  // Load byte into a
                        printf("LODA 0x%02x\n", program[ip]);
                        a=program[ip++];
                        break;
                case 0x02: // load byte into b
                        printf("LODB 0x%02x\n", program[ip]);
                        b=program[ip++];
                        break;
                case 0x03:
                        printf("ADD B,A\n");
                        b += a;
                        break;
                case 0x00:
                        printf("HALT\n");
                        running=0;
                        break;
                default:
                        printf("ERROR invalid instruction 0x%02x\n", program[ip-1]);
                        return(1);
                        break;
                }
        }

        printf("A=0x%02x B=0x%02x IP=0x%02x\n", a, b, ip);
        return(0);
}

A real processor would be much more complicated of course. x86 and x86_64 for instance have instructions of different sizes, some as few as 1 byte and some more than 12.

I'm still not sure what you mean. emulation doesn't turn a foreign program into a local program. Usually you emulate more of the system and interact with the system itself.

How to get the data out depends on what's being emulated how. DOSbox for example supports files, you could write the data you wanted to file to make it available in the host OS. It can also pretend to have a fake modem or serial port, letting things outside the emulator connect to programs inside the emulator over TCP.

How to do that isn't always obvious. How do you make 16-bit real-mode base/offset style memory access work in 64-bit protected mode with all the same side-effects? How do you translate instructions your processor has no direct equivalent for -- some architectures have weird ones, like "skip next instruction if bit N is set in register W". You could do it in two instructions but then you'd have to worry about whether the flags register got altered by instruction 2 in ways that change how the program will branch later. How do you keep track of what your instruction pointer is supposed to be when the instructions aren't the same size they used to be? What about instructions like REP STOSB which are entire little self-contained loops?

And once you translate it, then what? The program's still going to expect to be talking to its native operating system and not yours. You'd need to write your own substitues. (Sort of what WINE does. WINE doesn't need to emulate anything, since it's running x86 programs on an x86 machine, but it does need to provide the Windows libraries that Windows programs expect.)

Not saying it's impossible, but it wouldn't be easy, would be difficult to debug, couldn't be ported anywhere, and could end up being as much overhead as just emulating it.