Bob Warren wrote:
1. An "executable" (e.g. a file produced by VB in Windows) is not a
program, it's half a program. Nor is it executable. It finds its other
half in the operating system it is running under (in the form of
libraries), and when the 2 halves are put together, it can do something.
This is way OT, but folks here who enjoy what is usually a true
standalone may get a kick out of what ToolBook makes as an executable:
it adds only the tiniest stub of code to the stack file to help it find
a collection of DLLs strewn all over three or more directories across
the user's system.
Given this complex hodge podge, the boot sequence is so complicated that
as of v6 it was not in the docs that came with the product. I had to
trace it out once for a project, and when I was done I submitted my
summary to Asymetrix tech support who thanked me for what they described
as the first time their complex boot sequence had been documented.
I'll take a self-contained executable file any day. :)
When I described my apps' structure to my VB developer friends, they
almost fall out of their chair with disbelief at its simplicity and ease
of installation (how many millions of hours are wasted each year
resolving DLL conflicts among apps built with VB?).
2. A "standalone" is a whole program, not half. It does not refer to any
libraries at all in the runtime operating system**, and can be executed
directly.
[** except perhaps totally invariable ones - if such a thing exists??]
What Jacque seems to be trying to tell me is that in spite of the
denomination, Rev "standalones" for Linux are not pure. They mainly have
the characteristics of the 2nd category, but they have some of the
characteristics of the 1st.
Although this does not seem to fit in with an ideal situation, is it
certainly true in Linux?
This may be because the Linux GUI experience isn't an actual "thing",
but really a collection of many different things, chiefly the kernel and
the window manager. KDE isn't Linux, Gnome isn't Linux, and KDE and
Gnome use different APIs.
So while adding a GUI layer on top of Linux can provide a reasonably
satisfying GUI, Linux itself is not a GUI per se, with the GUI being
handled by these window managers delivered by different teams.
In contrast, while Apple's OS X is a window manager that rides on top of
BSD, the vendor has assumed responsibility for integrating the two into
a single cohesive experience.
If you take away the Finder and all the Aqua support from OS X, and
allow anyone to make any number of alternative GUIs, OS X would provide
the same level of confusion and fragmentation in the market, and
developers would have as much difficulty delivering consistent
appearances as they have with Linux.
I agree that it would be desirable for RunRev to come up with a scheme
to have native appearances on all of the various incompatable Linux
window managers, but it's not a simple task until those development
teams start prioritizing Linux adoption higher than they value market
fragmentation.
Admittedly this does raise a philosophical question of what constitutes
"self contained" when it comes to Linux executables, but I'm not sure I
would place any blame solely on RunRev, esp. given that RB has related
issues. It seems more fair to chalk it up to the inherently fragmented
nature of GUI Linux.
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
