Re: Linux, X, ld, gcc, linking, shared libraries and stuff

NoDot wrote:
> Beth wrote:
> > ...then a driver would be a program that makes use
> > of that "direct access" to provide a standardised "interface" to
> > applications (for "portability")...
>
> How odd, we seem to be on a similar wavelength. I was considering
> merging EXs (EXecutables), DLs (Dynamic Libraries), and DDs (Device
> Drivers) into a single file type: DOs (Dynamic Objects). To load up a
> driver, you literally execute it like an executable. Using it is just
> like using a Dynamic Library (how this is done is currently being worked
> on).

Well, basically, I see no reason to create ninety different incompatible
"file types" when one - suitably structured - would suffice...as simple as
that, really...

You know the "mantra" by now: "Type is defined by _usage_"...

So, if the executable provides "API" to other programs that conform to some
standard "video interface" on the one side and that it does "direct access"
to run the hardware on the other then that's what makes it a "driver":
Simply that it fulfills that function and role of "driving" hardware...and
if all executables can be dynamic loaded and linked, then they can be
"dynamic libraries" too...

You know, why make it any more complicated than that? :)

> The idea, however, came from a different problem. I was hoping to
> support the concept of mounting virtual disks (IMG, IMA, ISO, VHD, VFD,
> etc.) like actual disks without "bending over backwords" to get it to
> work. This would require the capability to make a "Device Driver" for
> such a thing. Well, if you're going to try unifying this stuff, why not
> go whole hog.

Sounds interesting; Have you considered the "peer to peer" architecture I
was talking about before? Fairly simple, really...and the reason I was
thinking of putting all the "file types" together into one...

Instead of the usual "layered" style:

+---------------+ +------+ +----------+
| Application | <--> | OS | <--> | Driver |
+---------------+ +------+ +----------+

....where the OS "wedges" itself into the middle of everything (which is an
extra "layer" of "indirection" and "overhead")...then you put all the
components on a "level" and it's more like a "network" of components:

+---------------+ +------+
| Application | <--> | OS |
+---------------+ +------+
/|\ /|\
| +----------+ |
+--> | Driver | <--+
+----------+

....and then it's much more interesting...a "typical" sequence could be:

1. Application "queries" OS for primary sound driver
2. OS returns information about sound driver (yes, it's the right one :)
3. Application "requests" the sound driver
4. OS checks "permissions" - yes, this is okay - and then loads driver and
returns "handle" (or whatever fits with your OS) to the driver...
5. Application calls standard sound driver API (it's like a dynamic
library)
6. Sound driver controls hardware, per application requests
7. Application finishes and calls OS to "close driver"

....or, at least, something like that...

Applications can use the drivers directly (and, of course, the "driver"
itself is just another program that does "direct access" on behalf of other
programs, following the "standard API" for that type of hardware...the only
thing "special" about it is that, when installed, it can be "registered"
with the OS as being a "driver" for a particular device)...

The reason to go through the OS to "request drivers" is for a few reasons:

1. The OS can check "security"...
2. The OS can provide "virtual device drivers", as needed...for example,
file systems or these image files and what-not...so, you could present them
as "disk drives" to the application and then just have the ordinary
"standard file I/O interface" that all disk drives follow (so, you know,
all disks and images and ZIP files or whatever you like, all "look" the
same to applications...or maybe not...you don't have to do this but I'm
pointing out the "possibility" of such a thing :)...
3. The drivers could potentially be "hooked"...for example, the application
opens the "internet" driver...BUT the user installed a "personal
firewall"...and what happens is that the "firewall" presents the same
"interface" that the "internet driver" presents to applications...so,
applications program this no differently ("transparent" to the application
that the "firewall" is there :)...and the OS provides the application with
the "firewall", in fact...and the "firewall" passes things onto the real
"internet driver" (per doing its job as a "firewall", of course, that it
passes on what's "safe" and disallows what isn't :)...

And point 3 here is just to point out that this architecture _CAN_ do much
the same "tricks" that the "layered" one does...but without "insisting" on
an OS wedging itself in the middle, even when all the OS really does is
nothing more than "pass on" application requests to the drivers...instead,
they can "deal direct"...

This, to my mind, creates a situation that's more like how the old BIOS
used to work...the OS doesn't "nanny" everything...all the drivers follow a
"standard"...the OS can "define" this standard...but, also, it's
delibrately "free" so that if they all got together to come up with some
"standard VESA interface" then, by all means, publish your specifications,
create the drivers that fit this "interface" and then applications can use
these...

This sounds like inviting "chaos", perhaps...and, to an extent, yes, that
is somewhat the point...but it's just "Liberty" rather than "chaos"...if
hardware manufacturers could come up with a better interface than the OS
already has, then _LET THEM_ "take over"...that, yes, the OS _can't_ really
"control" such things...

Sounds a bit weird, maybe, to want to invite this...but it's like
IBM...they created the PC but it _COULD_ be "cloned" by other manufacturers
too...they specified BIOS routines BUT, as things change or manufacturers
get together to form organisations like VESA, then, yeah, new "BIOS
interrupts" could be introduced...and that was a _FANTASTIC_ thing for the
PC...IBM did "lose their baby" this way - that is, lose "control" over it
all - but it planted the seeds for _COMPETITION_...and "evolution"...and so
forth...

And, for an "open source" OS, _WHY_ should it care about "maintaining
control"? Wouldn't that be a bit "oxymoronic" against the "open source"
principle? No...instead of following "commercial" designs, aimed for
commercial "control" over everything, go with an architecture delibrately
designed to provide _LIBERTY_..._GIVE_ the hardware manufacturers back
their "freedom" to produce the best video cards and standards and drivers,
not the "most compliant cards to Herr Fuehrer Microsoft's DirectX
specifications"...

The OS _does_ provide an organised "framework" for this...but that's
it...the "framework" only...the "flesh" can be provided by the drivers and
the dynamic libraries and so forth...the OS "provides kernel services" to
the system and the "framework" for how applications find and load drivers
and such things, when they need it...but isn't "wedged" into the middle of
everything, trying to "control" everything...

You know, _of course_ Microsoft (and the other "commercial" OSes) follow
the "layered" architecture because they want to "control" everything for
commercial advantage...and "layered" forces the OS to be sitting in the
middle of everything...applications can only call OS API and, thus, are
effectively "controlled" by the OS...

But "open source" should perhaps realise that it's not just the
"development method" that can be improved by the "peer" concept (that
anyone and everyone - all "peers" - can work on developing the "open
source" software :)...but that this "model" also can "free" the OS, as much
as it can "free" the developers...make it "peer to peer" - network-like -
rather than "layered"...

"Chaos"? No, that's the "fear-mongering FUD" that people who want to
"control" everything just try to frighten people away with...calling
Liberty "anarchy" or "chaos", so it sounds "frightening" that everyone will
slot back into "client / server", "master / slave", "king / peasant" mode,
that makes them "all important" at the top of their "hierarchy"...

Well, "don't...don't...don't...don't believe the hype!" ;)

> (Yes, I see the relation to the Unified Model.)
>
> > (non-GUI OSes need not apply here)...
>
> :(

Hey, only because it's about putting the GUI into the drivers themselves!
So, you know, "no GUI" = "nothing to be putting into the drivers"...so, it
wouldn't be applicable in that case...

Although, you _could_ look at it in reverse...pop that basic "windowing"
into the video driver interface and just make it inherently an
"event-driven" architecture (between these "peers") and then that's your
"groundwork" for bringing in a GUI later on...

But, yeah, in this particular case, I'm going "whole hog" and simply saying
"let the OS be inherently and integrally a GUI OS from the ground
up"...screw "text mode"...a decision, of course, you may not wish to do
with your OS...after all, I'm not telling you what to do or anything...just
throwing ideas your way...and this idea relates to simply going "whole hog"
with the GUI, if you know what I mean: Not simply a "shell" but an
_inherent_ part of the whole structure...this idea is on the more "radical"
side for some...Annie'll hate it...but, you know, I've been "sold" on the
GUI for many years, I need no convincing...and, remember, this doesn't mean
you "can't" have some "console" application where you can't type out
"command-lines", as one of the many _GUI_ applications available...you see
what I mean? You can switch it around...and, to my mind, doing so makes
sense in the modern context where most applications are GUI...and, hence,
put "event-driven" into the kernel itself...put "windowing" into the
drivers...and so on and so forth...this being how it _inherently_ operates
rather than adding such things on as "shells" on top of some text-based
kernel...yes, a _reverse_ of how X works on top of UNIX OSes: Make X, so to
speak, the kernel itself...

With this idea, I've just annoyed loads of people for even contemplating
it, much less saying it aloud...but I long for the OS that has no "legacy"
from the '70s or '80s to "maintain until the end of time"...and has to make
NO compromises for it...that _EXPLOITS_ that very fact to its
advantage...my interest, in the end, has always been to know what the
"limits" of things are...the "scientist" in "computer scientist", so to
speak, to enjoy the "experiment", the finding of "new ways" and "new laws"
or whatever...there are many who seem to want to find a "comfortable patch"
and settle down and such...I'm the entire opposite, in that I want to learn
about new things all the time...and this is in that spirit...I fully
respect that there's sod all wrong with the "old ways" but this, in itself,
does not seem any reason not to look for "better ways"...at the very least,
to at least _look_ to see what's there, even if it might turn out to be
crap and going back to the "old ways" makes more sense...to a "scientist",
there is no such thing as "failure"...to be told that all your ideas are
utter crap, can be as exciting as being told you're perfectly
right...either way, it's "knowledge" and that's, in fact, what "science"
literally means: "knowledge" :)...

> > (just like we'd never
> > likely see that "UNIX subsystem" on NT because that would be
"supporting
> > the enemy" for them...
>
> Well, if they introduce a *NIX subsystem into NT, then technically, it'd
> allow for more people to program for their OS (though it works the other
> way to).
>
> (OK, so there'd be a massive flux of programmers going from Windows to
> Linux through this and no one comming from Linux to Windows.)

Oh, not totally absent of "the other direction", I think...there are people
out there who've only been doing UNIX or DOS and think "oh, I'll give this
Windows at least a try"...

Remember, wolfgang himself only recently "bit the bullet" to do some
Windows applications, when his clients asked him to...and I don't know how
much Annie knows about Windows programming (if "not much" then it's _BY
DESIGN_ and she's proud of it ;)...

It'll be "Windows -> elsewhere", simply because Windows has all the
developers because it has all the users and all the hardware and all the
"market"...it's only natural...you could call it "diffusion"...where "high
pressure" rushes to "low pressure"...

After all, you're in a pressurised cabin in an aeroplane high in the
sky..."high pressure" inside the "Windows airline" plane, "low pressure"
outside...along comes ReactOS and "opens the door" to allow the air to go
wherever it pleases and - BANG! - all the air rushes out of the aeroplane
(and the oxygen masks fall down...remember, put your own mask on first
before helping others...and the safety exist are here...here...and
here...well, this is the "grounding" of "Microsoft airlines": Expect a
"bumpy ride"...the only flaw in the plan is that Microsoft can up the
"airport security" with "trusted computing" to attempt to keep ReactOS
nowhere near their planes...okay, I'm "extending the metaphor" too far
here, I know ;)...

Also, though some may disagree, I'd say that Windows doesn't have all the
users because it's ever been "better"...it's just because Microsoft has the
"monopoly" to "pre-install" themselves everywhere and keep the hardware
manufacturers on a "leash"...and Windows doesn't have the developers
because it's "nice" to program or anything...it's just simple: That's where
the users are, so if we want to program things people actually use, we're
kind of forced to follow those users...Hopefully, my example began to show
this a little that these other things are as easy, if not much easier, to
program than Windows ever was...and aren't "lacking" either (X has more
"features" built-in...like the "network transparency" from the ground up,
which is remarkably powerful for something so, in fact, inherently
simple...mind you, the exact same thing can be said about the UNIX
"everything is a file" philosophy too, with "pipes" and "redirections",
leading to all manner of combinations and possibilities from one fairly
simple "feature" of making most things abstractually "files" that the "file
I/O" syscalls go an incredibly long way in UNIX...which is also why a
comparison of a few hundred Linux syscalls to thousands of Windows API
might initially look like Windows has the upper hand, until you consider
the _quality_...that just two syscalls - "read" and "write" - can do an
awful lot of things...you know, Windows has so many API exactly because
they ain't too clever in "unifying" and "re-using" and so forth ;)...

Beth :)


.

Relevant Pages

  • Re: Printing panoramas
    ... of the software applications in Windows use the same or very similar ... complete is they are installed with the driver form the printer mfg. ... and the 2 indicates some different glossy paper. ...
    (comp.graphics.apps.gimp)
  • Re: Cannot restore registry
    ... | feature, follow these steps: ... When the Windows Advanced Options menu appears, ... | Feature: Device Driver Roll Back ... | Feature: System Restore ...
    (microsoft.public.windowsxp.configuration_manage)
  • Re: Boot up problem... with a difference
    ... Safe mode boot is fine. ... Looked further into the last errors and noticed PXRD Driver. ... Event Type: Error ... Windows cannot unload your classes registry file - it is still in ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Cannot restore registry
    ... | feature, follow these steps: ... When the Windows Advanced Options menu appears, ... | Feature: Device Driver Roll Back ... | Feature: System Restore ...
    (microsoft.public.windowsxp.configuration_manage)
  • Re: Cannot restore registry
    ... feature, follow these steps: 1. ... When the Windows Advanced Options menu appears, ... Feature: Device Driver Roll Back ... Feature: System Restore ...
    (microsoft.public.windowsxp.configuration_manage)