Invisible wrote:
> Well, certainly you give it a bunch of files and it knows how to compile 
> them. But do you want it to link them all into a single executable? Or 
> maybe two seperate executables?

Yes. That's what the separate "projects" in one "solution" are, in VS.

> Or perhaps you're trying to produce a 
> DLL? Presumably you have to configure this somewhere...

Sure. You set flags on the project properties pages.

> Interesting. I thought it was only object files that contain linker 
> tables...

Depends on the OS and CPU. For example, on CP/M, you're right. The binary 
.COM file is just bytes of machine code that load at 0x100, and the OS jumps 
to 0x100 when it starts. That's responsible for setting up the stack (based 
on an address left in global memory) and parsing the command line (at 0x80).

On even simple UNIXes, you have things in the headers to set up how big the 
stack is, how big the "zero out this memory space" area is, and which 
addresses have to have the start address where you loaded the executable 
added. Any OS taking advantage of memory protection is going to have 
metadata in the executable format.

> Mind you, having just said that... various programs have custom icons 
> and so forth. That's definitely not executable code. Hmm...

Yep, that too.

> [Now the old MS-DOS *.com files really *are* just bare machine code, 
> always loaded at a specific machine address...]

Yes, left over from CP/M.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message