[ale] difference between android and linux ?

[Michael B. Trausch]

On 08/13/2011 05:49 PM, Ron Frazier wrote:
> At a binary level, applications for Windows, Mac, GNU Linux, and Android

"GNU/Linux" is the operating system.  GNU isn't a brand of Linux, the
slash exists to tie the two words together in the same way that an
implementation is tied together.  "Android/Linux" isn't exactly a
standard term, but I've patterned my usage on GNU because Android
provides a userland to complete the operating system in the same manner
as GNU.

Note that neither GNU nor Android are, by themselves, operating systems!
 There are implementations of GNU on other operating systems, for
example, FreeBSD or the perpetually incomplete Hurd kernel.  However,
the interface can and does change between systems, and so really
"GNU/kFreeBSD" (so named because they took only the kernel from FreeBSD)
and "GNU/Hurd" are different operating systems than "GNU/Linux".

Again, as I previously mentioned, there is confusion here because of
nearly two decades of "Linux" referring to pretty much everything that
had a Linux kernel on it.  But it's too vague these days.  (I'd argue it
has always been that way, but once upon a time people with those views
were looked at as extremists.  Hell, some still are.  And sadly, many
don't even know what an operating system is, and simply parrot the
arguments because they think that RMS is right or wrong, or whatever.)

> Linux are not compatible with each other.  Even on machines with
> comparable and adequate resources, the API's, functions, and libraries
> are too different among the various systems, in general.  So, Firefox
> for Ubuntu is fundamentally different, even though functionally the
> same, than for Windows or Mac (if available), for example.

Yes and no.  In the default case, an application written for one system
will never run on another system.  But there is so much about today's
world that is no longer the default.

You need to realize that this conversation will not cover everything
possible here.  You will need to spend a significant amount of time
studying systems to learn all there is to know; you should probably pick
up a low-level book on operating systems in general, and spend the time
to read through it.

Now, there are 3 major points you need to consider when looking at
programs and the operating systems that they run on, in order from
lowest- to highest-level:

 - What ISA does the program use?
 - What format is the executable stored in?
 - What entry points does the program use?

I am also going to highly qualify the remainder of this email: It is
possible to write software to make me utterly wrong!  :)  And in some
specific cases, it already has; see WINE, OS X's Rosetta, coLinux, some
of the various qemu-linux programs, and so forth.  From here forward I
am talking about the normal, usual way of things.  Also, I'm talking
about binary programs here: talking about source compatibility is a
_completely_ different beast altogether.

Now, then.  I'm going to use my /bin/ls as an example.  My software is
compiled for the x86-64 CPU architecture, and therefore, that is the ISA
(Instruction Set Architecture) that my /bin/ls uses.  (Note that this
has _nothing_ to do with the source code that was used to create
/bin/ls, for our purposes.)  What this means is that my /bin/ls will not
run on a system that implements only IA-32 (or IA-64, for that matter)
ISAs.  (Caveat: it is possible, albeit traditionally expensive, to
translate from one ISA to another.  And for now, we'll ignore that.)

The next thing is to determine the format.  As I use a system with a
modern Linux kernel (3.0.0 as of right now, haven't updated to 3.0.1
yet...), and as Linux was only ported to x86-64 after ELF became it's
executable file format, my /bin/ls is (quite obviously) an ELF-formatted
binary executable file.  Most non-Windows system kernels today use the
ELF format, including the BSD systems and the Hurd.  Other examples of
executable file formats are COFF, MZ, PE, LZ, and so forth.  If you want
details, google for "osdev wiki" and start reading, a lot.

> Even various binary executables for different GNU Linux systems may be
> fundamentally different.

And here is where the last question comes in:  what entry points does
the program use?  For ELF programs on x86-64, a program must be able to
find the functions it wishes to call regardless of their address in
memory.  That means it tells the dynamic linker what it needs, and the
dynamic linker will attempt to find it.  If the dynamic linker can
resolve all of the entry points that the program calls upon, then the
program is said to be fully linked and will begin execution.  (Note that
at least on the Linux kernel, the dynamic linker is a userspace
component of the operating system, and on the most traditional
implementations, the dynamic linker ["ELF Interpreter"] is in fact
provided by glibc).

If my /bin/ls uses entry points that are available on your Ubuntu
system, and your Ubuntu system is running an x86-64 kernel and has
x86-64 libraries, then it will run on your Ubuntu system.

Additionally, we could talk about statically linked executables.  I will
however leave that as an exercise for you to research.

> Full desktop OS's like Ubuntu generally will not run on something like
> an Android tablet due to resource constraints.  A more stripped down
> version of GNU Linux may be able to run on a tablet with decent hardware.

Depends.  Any distribution won't work without extra effort if the device
in question isn't directly supported by the distribution.

> I'm making up this scenario, so it may or may not ever happen.  Let's
> say that I want to create a great application for stellar cartography. 
> Let's say the user should be able to use a menu and form query system to
> select star charts and view them in windows or print them.  Let's say
> that there are various calculation functions included, so you can find
> out how far it is from various points in the galaxy in three
> dimensions.  Let's say you can also do things like calculate the
> cumulative mass of stars in various nebulae and generate reports and
> graphs on this data.  As I said, I'm just making this up, and I'm not an
> astronomer.  The point is, that this application, like many, will have
> (at least) a GUI UI component, a logic and calculation component, a
> database component, and perhaps an output component (printing) other
> than the GUI.  Let's say I want this application to work on Windows,
> Mac, Android Linux, and the top 5 flavors of GNU Linux.  A quick check
> of distrowatch.com says those are Ubuntu, Mint, Fedora, Debian, and
> SUSE.  Nothing against the others, but developing for 8 OS's is probably
> enough of a challenge for now.  The application has to be functionally
> identical on each system.  We could make allowances for UI design guides
> and traditions on each, but might choose to make them all exactly the
> same as well.  The executables may be different, but the data files the
> app creates, loads, and saves must be compatible across all systems.  A
> user must be able to use the app on any of the mentioned systems and do
> exactly the same things, or transport data from any system to any
> system.  Code reuse must be maximized among different versions, since I
> don't want to spend 8X the time it would take to make one version.

This is an issue of source code compatibility.  You'll want to use
something like wxWidgets and ensure that you write your code portably.
However, this has nothing to do with binary compatibility at all.

> Putting aside what it actually takes to design a stellar cartography
> application, I want to address what it takes to set up the development
> environment.  I had read somewhere that you can maximize portability
> among apps by breaking them into the UI, logic, and database sections,
> which is why I structured this the way I did.  I added an output section
> because it seemed logical and appears that that would encompass a major
> subsystem.  The stuff I read said that if each subsection is built as a
> black box, so to speak, with a clearly defined IO interface at its
> boundary, then you could share some black boxes among multiple systems
> and customize others for each system.

Your program will mostly have components that are OS and processor
independent.  Assuming we're talking about something like C, you have
the the stdio APIs available on all systems that have a conforming C
compiler; for C++ you have streams on all conforming implementations.
Math works the same regardless of OS, and transformations on data for
the most part as well.  (Unless you code additional dependencies into
your system, but that'd be up to you.)

> Now, as far as I know, C++ standards based compilers are available for
> each platform, although I'm not totally sure about Android.  Assuming
> that's true, then I should be able to make the logic and calculations
> "box" identical for each system, with exactly the same code.

GCC runs on all of them.  Pretty sure Android uses GCC as well; it has
to at least for the kernel (nothing else can compile Linux reliably
because it uses extensions that only GCC reliably provides).

> It appears to me that the other "boxes", UI, database, and output; would

UI goes through a library; if you use wxWidgets, you have a fully
source-code portable system and need not worry about it.  Otherwise,
your program will conditionally compile UI components specifically for
Win32, GTK+, Qt, or Cocoa.

Database libraries are typically portable; at least for PostgreSQL, you
can use the libraries regardless of OS.  If you use another database
(why would you? :-)) you can secure an appropriate cross-platform
library or you can implement the database's wireline protocol yourself.

Other I/O is typically covered by the standard library of whatever
programming language you're working with (e.g., stdio or C++ streams).

> have to be customized to each system, based on the API that each is
> presenting.  So that makes it sound like my code reuse factor is taking
> a beating, with somewhere in the range 25% of code that is common and
> 75% of code that is unique for each system.  However, it also seems that
> I may be able to get some help from libraries, such as FLTK or QT, which
> are available on different systems.

Eh.  Won't catch _me_ dead installing Qt libraries!

> the type of thing I've described, when I'm ready for it.  What I don't
> want is a system that forever prevents me from porting my apps to other
> OS's.

There is no such thing in the free software world.  As long as you're
using GCC or other free software compilers, you can build for virtually
anything.  If you're interested in binary compatibility, you can even go
for a managed system -- Java (yuck) or C#/Boo/any of the other CLR
languages.  Then you have an abstract CPU and standard methods for
interfacing with any OS that there exists a CLR implementation for.

  Thus far, I'm thinking GNU tool chain (G++, GCC, GDB, MAKE,
> etc.).  I know this is available on GNU Linux systems and on Windows,
> although I don't know how to install it on Windows at this point.

You probably want to cross-compile to Windows from Linux.  No need in
slowing yourself down by building on Windows.

> I
> don't know for sure if it's available on Mac or Android.

GCC is the compiler Apple uses.  Android again has to use it at least
for the kernel; I'm unsure about the rest of the C portions of the
Android system.

I'm skipping the rest; it sounds like you're confused.  I would suggest
that you start doing a _lot_ of reading, and if you're new at all of
this, don't worry about being portable (yet!) outside of an OS family.
Being portable to POSIX applications is one thing; being portable to
both POSIX and Windows APIs, OTOH, will require that you have a firm
grasp on learning how, when, and why to write (or use) abstractions.

	--- Mike