<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
(Responses inline)<br>
<br>
On 08/13/2011 05:49 PM, Ron Frazier wrote:
<blockquote cite="mid:4E46F156.6060901@c3energy.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
I want to say thanks to Pat R, Tavarvess W, James S, Jim K,
Michael T,
and others who have responded to this inquiry to try to clarify
things. It IS a bit confusing. I want to review each of your
replies
in more detail, but for now, I have a few more questions. What
I'm
getting from the discussion is that you first have "the core" or
the
Linux kernel on GNU Linux and on Android Linux. Serving
comparable
duty would be the NT Kernel in Windows and the Mac OSX Kernel on
Mac.
Then, wrapped around or sitting on top of the Kernel are various
libraries and functions which make up the API of the OS which
applications can call on. Then, you have the applications
themselves
which call on the API to get things done.<br>
<br>
</blockquote>
Correct. Just FYI, the OS X Kernel is named "Darwin."<br>
<blockquote cite="mid:4E46F156.6060901@c3energy.com" type="cite">
At a binary level, applications for Windows, Mac, GNU Linux, and
Android 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.<br>
</blockquote>
There are definitely big differences in the APIs. There are also
differences in the actual format the programs are presented within
the file. (Linux normally uses a format called 'ELF', Windows uses
'PE'--portable executable.)<br>
<blockquote cite="mid:4E46F156.6060901@c3energy.com" type="cite">
<br>
Even various binary executables for different GNU Linux systems
may be
fundamentally different.<br>
<br>
</blockquote>
Generally, they're not too different. Different systems may have
slightly different versions of the same library, but for the most
part, they're pretty similar. For example, you could build a binary
on a current Fedora Core and I would be surprised if it didn't run
on a current Ubuntu (provided that you had the dependent libraries
installed).<br>
<blockquote cite="mid:4E46F156.6060901@c3energy.com" type="cite">
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.<br>
</blockquote>
Sure. This is mostly due to the desktop environment in use. KDE
4/Gnome 3/Unity all expect a (relatively) modern desktop. I
currently run XFCE, and though I'm on a Core i5, it would run quite
nicely on even a Pentium III. Fluxbox and other WMs/DEs can
probably run on even less.<br>
<blockquote cite="mid:4E46F156.6060901@c3energy.com" type="cite">
<br>
I'd like to propose a hypothetical development scenario and gather
opinions on what factors will affect the developer.<br>
<br>
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.<br>
<br>
</blockquote>
Seems like reasonable specifications.<br>
<blockquote cite="mid:4E46F156.6060901@c3energy.com" type="cite">
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.<br>
<br>
</blockquote>
Absolutely. This "black box" concept is exactly what makes up an
API (application programming interface). For example, libc provides
a malloc() function. The implementation of this function probably
varies quite a bit by which libc you're using and on what hardware.
But no matter what, you can call malloc() and get some memory
allocated.<br>
<blockquote cite="mid:4E46F156.6060901@c3energy.com" type="cite">
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.<br>
</blockquote>
The only exposed API on Android is through the Dalvik Virtual
Machine, which is based on the Java programming language. No C++
for Android. (It might be available on some rooted systems, I'm not
sure.)<br>
<blockquote cite="mid:4E46F156.6060901@c3energy.com" type="cite">
<br>
It appears to me that the other "boxes", UI, database, and output;
would 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. If such
things
are available on all these systems, then I can write my app to
call the
API of the add on libraries only, and avoid native OS calls. That
way,
I would think that I could get my code reuse up to the range of
75% of
code that is common and 25% of code that is unique to each
system.
More common and less unique is obviously better.<br>
</blockquote>
UI and output seem to be the same to me. Use TK, QT, or GTK and
your UI will be easily portable with almost no trouble. For
databases, use MySQL, PostgreSQL, or sqlite. sqlite, unlike the
others, is implemented entirely in the library, so no DB server
needed -- great for single-user applications. (sqlite is used
within Firefox and Thunderbird, for example.)<br>
<blockquote cite="mid:4E46F156.6060901@c3energy.com" type="cite">
I'm trying to set up a development system which will let me do
exactly
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. 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.
I
don't know for sure if it's available on Mac or Android. I don't
own a
Mac or an Android device at this moment, so I cannot test that.
I'll
probably use VIM for editing. It would be nice if I can do
equivalent
development on any platform, but, if I'm stuck to developing on a
specific system, that's OK. I just have to be able to compile
applications that will run on each system. I'm thinking FLTK to
start
as a GUI library. It's available on Windows and GNU Linux.
Again, not
sure about Mac and Android. Maybe later, I'd advance to something
more
comprehensive. I don't know about database libraries and printing
libraries. Maybe MySQL, etc.<br>
</blockquote>
See above for databases. Even on Windows, you can build against a
GNU toolchain with Cygwin.<br>
<blockquote cite="mid:4E46F156.6060901@c3energy.com" type="cite">
So, I'd like any advice I can get as to how to build a TRULY cross
platform development environment, which can service all the OS's I
mentioned. Not that I'm ready to publish such an app, nor will I
be in
the near future, but I want to be eventually capable of it.<br>
<br>
I just had another idea, which may be great or crazy. Let's say I
encapsulate my app within a VM, even if it is not visible to the
user.
Let's take for example, the VM that VirtualBox (or VMWare)
presents.
These systems emulate a specific set of hardware every time. So,
assuming I could get the VM "player" modules on each target
platform as
part of my app installation, I could just target whatever
"machine" API
is being presented to my program by the VM player. I write code
solely
to the virtual machine, and ignore whatever is going on in the
real
machine. Any resources available on the real machine should be
presented to my app through the VM player's API. Great... or
crazy?<br>
</blockquote>
That was the idea behind Java. JVM = Java Virtual Machine. It's
not a fully-emulated VM, but it abstracts the user's machine to
create a "virtual machine."<br>
<blockquote cite="mid:4E46F156.6060901@c3energy.com" type="cite">
<br>
Sometime later, we can talk about version control, IDE's, and
packaging
and publishing for the various OS's. As usual, any advice is
greatly
appreciated.<br>
<br>
Sincerely,<br>
<br>
Ron<br>
</blockquote>
<br>
Developing for (non-rooted) Android devices is a completely
different ballgame from developing for the rest. You'd need to use
the toolkits, libraries, etc. available on the Android platform. If
I were you, I would focus on non-Android development first (unless
mobile is your goal.)<br>
<br>
In my opinion, the most portable language available these days is
python. There are plenty of functions to abstract things from the
underlying system, it's easy to get started with (shallow learning
curve) and there is plenty of good documentation and tutorials out
there.<br>
<br>
Hope this helps!<br>
<br>
David<br>
</body>
</html>