Unix binaries

[Roedy Green]

Pardon my ignorance here, but I went to have a look at the JRE
download page, and saw only Windows, Linux and Solaris versions. What
about all the other Unices? What are all these server farms out there
running?

The last time I looked, circa 1985, it seemed most Unix software
typically arrived as C source, and you compiled it. A ton of
pre-processor statements embedded in the code tuned it for your
platform. Nobody wrote to the assembler API the way you did in DOS.

1. Are there now binary standard exe formats for the various chips?

2. Would i86 Linux binaries run on NetBSD, especially the JRE.

3. Isn't Solaris a flavour of Unix?

--
Roedy Green Canadian Mind Products
http://mindprod.com

"Simplicity is prerequisite for reliability,"
~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72)

 

[Mike Schilling]

Pardon my ignorance here, but I went to have a look at the JRE
download page,

That is, Sun's JRE download page.

and saw only Windows, Linux and Solaris versions. What
about all the other Unices? What are all these server farms out
there
running?

Java provided by the platform vendor, most of whom license the source
from Sun. Unless things have changed an awful lot since I knew about
this stuff back in the late 80s/early 90s, porting a complex,
multithreaded, performance-critical application to a particular Unix
variant required knowing quite a lot about its ins and outs.
Admittedly, that was before SVR4 ironed out a lot of the AT&T vs. BSD
wrinkles.

3. Isn't Solaris a flavour of Unix?

Yes. Sun's UNIX, which is why Sun provides it themselves.

 

[Arne Vajhøj]

Pardon my ignorance here, but I went to have a look at the JRE
download page, and saw only Windows, Linux and Solaris versions. What
about all the other Unices? What are all these server farms out there
running?

AIX - Java from IBM
HP-UX - Java from HP
etc.

(I would guess that Free/Open/NetBSD would be using OpenJDK)

The last time I looked, circa 1985, it seemed most Unix software
typically arrived as C source, and you compiled it. A ton of
pre-processor statements embedded in the code tuned it for your
platform. Nobody wrote to the assembler API the way you did in DOS.

1. Are there now binary standard exe formats for the various chips?

Not in the sense that they would run unchanged.

2. Would i86 Linux binaries run on NetBSD, especially the JRE.
No.

3. Isn't Solaris a flavour of Unix?

Yes.

Arne

 

[Tom Anderson]

The last time I looked, circa 1985, it seemed most Unix software
typically arrived as C source, and you compiled it. A ton of
pre-processor statements embedded in the code tuned it for your
platform. Nobody wrote to the assembler API the way you did in DOS.

What do you mean by "the assembler API"?

1. Are there now binary standard exe formats for the various chips?

There always have been standard formats for each unix. Both executable
formats, ABIs and APIs. Are they the same across all unices? No. I think
most unices now use the ELF format, and all of those which run on the x86
use the SysV ABI (?), but things like system call tables are different.

2. Would i86 Linux binaries run on NetBSD, especially the JRE.

Possibly. Not natively, but the BSDs have binary compatibility layers,
which basically re-map another OS's system call table onto BSD. Linux is
one of the emulated OSs:

http://www.netbsd.org/docs/compat.html#ports

However, the emulation is not necessarily perfect, and whether something
of the intricacy of the JVM would run successfully, i don't know. A NetBSD
newsgroup would be the place to ask.

3. Isn't Solaris a flavour of Unix?

Yes.

tom

 

[Roedy Green]

What do you mean by "the assembler API"?

In DOS you call OS services primarily with INT 21, a software
interrupt. BIOS services have other interrupt numbers e.g. INT 13 for
low level floppy and hard disk i/o. Presumably, there is something
similar buried inside the system C methods you call on Unix. At some
pint there is usually a flip between user mode and supervisor mode,
and user address space and system address space. If you provide
services in pure user mode, they would not need to be OS functions.
They could just be part of a class library.

I asked about this back 1n 1985 and was told these magic numbers are
never any concern of the programmer, and not to worry my then pretty
little head about them. There was a linking process to C system
methods, and such an interface was private and internal to those
wrappers. The numbers need not be published or stable the way it was
in DOS.


--
Roedy Green Canadian Mind Products
http://mindprod.com

"Simplicity is prerequisite for reliability,"
~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72)

 

[Mike Schilling]

I asked about this back 1n 1985 and was told these magic numbers are
never any concern of the programmer, and not to worry my then pretty
little head about them. There was a linking process to C system
methods, and such an interface was private and internal to those
wrappers. The numbers need not be published or stable the way it
was
in DOS.

Not really true back then, since libc was an object library that got
hard-linked into each executable. Changing the numbers for OS traps
would break existing executables, or, to say it another way, require
that all executables be relinked. Nowadays, with libc being a shared
library on every Unix I know of, it could be wholly reimplemented at
will.

 

[Tom Anderson]

In DOS you call OS services primarily with INT 21, a software
interrupt. BIOS services have other interrupt numbers e.g. INT 13 for
low level floppy and hard disk i/o. Presumably, there is something
similar buried inside the system C methods you call on Unix.

Okay, this is more or less what i understand by "application binary
interface".

At some pint there is usually a flip between user mode and supervisor
mode, and user address space and system address space. If you provide
services in pure user mode, they would not need to be OS functions. They
could just be part of a class library.

I asked about this back 1n 1985 and was told these magic numbers are
never any concern of the programmer, and not to worry my then pretty
little head about them. There was a linking process to C system
methods, and such an interface was private and internal to those
wrappers. The numbers need not be published or stable the way it was in
DOS.

Here's what the System V ABI specification for the x86 [1], which is
something of an ur-text for unix ABIs, on the x86 at least, says (page
3-24):

A program executes the lcall instruction through a system call gate to
change execution modes, and thus the lcall instruction provides the
low-level interface to system calls. For the Intel386, one low-level
interface is defined: _exit(BA_OS).

To ensure a process has a way to terminate itself, the system treats
_exit as a special case. The ABI does not specify the implementation of
other system services. Instead, programs should use the system libraries
that Chapter 6 describes. Programs with other embedded lcall instructions
do not conform to the ABI.

So there isn't really an equivalent to INT21h, because as you say, you're
only supposed to go through the libraries!

tom

[1] http://www.sco.com/developers/devspecs/abi386-4.pdf