[svlug] Understanding executables

Tim tim at tetro.net
Fri Oct 18 21:39:20 PDT 2002


On Fri, Oct 18, 2002 at 08:57:04PM -0500, Jay Link wrote:
> Can anyone recommend a good book or website to help me truly understand
> executables?

There probably are some of each, but I haven't read any that
specifically cover this subject.

I'm not an expert on these things, but I have some understanding of it,
and I'll try to answer your questions.  Those who know better, please
correct me.

> * What makes a binary file executable, aside from the permissions flag?

Support for the binary format in the kernel, or in an interpreter
registered with binfmt_misc:
  http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html

> * How the operating system differentiates between a binary executable
> & a text script?

The kernel calls on each registered binfmt which will inspect the file
and load it if it recognized the format.

> How far into each file does it read, and what it is looking
> for? (Obvously, #! in the case of a script).

Depends on the binfmt handler.

> * What are stubs and all that?

Something that is unfinished or unused..?

The Free On-line Dictionary of Computing has a definition:
  http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=stub

     1.  A dummy procedure used when linking a program
     with a run-time library.  The stub routine need not contain
     any code and is only present to prevent "undefined label"
     errors at link time.

     2.  A local procedure in a remote
     procedure call.  The client calls the stub to perform some
     task and need not necessarily be aware that RPC is involved.
     The stub transmits parameters over the network to the server
     and returns the results to the caller.

I remember back when I was learning C and using a Borland C++ 3.1
compiler that my dad brought home when the programmers where he worked
threw it out.  Ah, if only he had brought home Linux.. I'd be years
ahead of where I am now.  Oh well.

Anyhow, in the project's .def ("Module Definition File") file, you could
specify a "STUB" "old-style executable".  It would be placed at the
beginning of your compiled .EXE instead of the default "WINSTUB.EXE".
It's purpose was, if someone runs the program under DOS, the STUB would
get executed and display a message like "This program cannot be run in
DOS mode" or whatever.  The Windows loader would, of course, skip over
the "old-style executable" and load the NZ (Win16) or PE (Win32) format
executable.

> * Why won't a statically linked executable, compiled for Linux on an x86,
> work on another x86 running M$, and vice-versa?

A number of reasons, some of which are:
  - Even a statically linked Windows executable relies on certain
    libraries (KERNEL32/USER32/GDI32/etc), interrupts, and probably
    other stuff, to execute properly.
  - Statically linked Linux binaries still use system calls (handled by
    the kernel. done via interrupt 0x80) that must be available to
    execute properly.  I learned this part from http://linuxassembly.org/


> * Possibly a bit-by-bit description of what's going on in a simple "Hello
> World!" program.

I read part of a HOWTO or something that had something like that..
..dang, I can't seem to find it right now.  This might be interesting to
you, it is to me:

   "Startup state of a Linux/i386 ELF binary"
   http://linuxassembly.org/articles/startup.html

Neat stuff.  Lots to learn.

  - Tim



More information about the svlug mailing list