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

NoDot wrote:
> First, I appologise. My new news server obviously didn't register this
> post (probably because it's too big) so I'm replying through Google
> Groups. I'll make note to scrap that server later.

Ah, don't worry...*** happens...

> Beth wrote:
> > it all depends what you're "targetting" exactly
>
> Just for the sake of definning it, my target is desktop x86 PCs. Why
> x86? Simple, because I don't have anything else to test it on!

A good a reason as any; Though, of course, this "target" is hardly a bad
one...this is what most people have: A desktop x86 PC...

> > BUT, you could also, for example, have a "RAM disk"
>
> Yet another thing I didn't think of.

:)

They can be useful at times...for instance, if you've got the RAM to spare,
make a "RAM disk" that pretends to be a hard drive, as the target for your
"temporary internet files" and "history" and that kind of thing...the
browser then actually runs ever-so-slightly faster (RAM works faster than
the hard drive motor :) while giving you an automatic "wipe" of all the
files, the instant you turn off the power...faster, better "privacy",
avoids "clutter" building up, acts as a "cookie autokill" when you turn off
the power (although, if you prefer to keep your cookies, then you can
normally dump them in a different folder to everything else with most
browsers :), etc....and, you know, the "temporary internet files" folder
already has a "limit" on its size, anyway, so a size fixed RAM disk of
similar size is no real disadvantage here to the hard drive in any
way...just a case of having enough "spare RAM" for it...

> > No, no...it's very simple..._THAT_ is why you _ask_ the OS to load
> > the drivers...
>
> On re-evaluation, I thought the driver itself would be what works with
> the firewall. (i.e. The DO for the connection calls the DO for the
> firewall, rather than the OS passing stuff to the firewall, which
> passes stuff to the connection.) What you're doing is asking for
> interception, which, now that I think about it, could be used
> elsewhere, though it's use in other areas isn't likely to be often.

No, it's preferrable that it's not used often - as direct a path as
possible to most things means a faster system, generally - but it could be
handy to allow for it for these kinds of things...

Although, in the case of the "firewall", this might be a little bit of a
"false example" in that maybe firewall functionality should now be
considered "automatic" and worked directly into the OS itself or something
(might be good in not giving any opportunity for something to "sneak its
way" in there, from a security perspective ;)...but, you know, it makes for
a nice obvious example to explain what I was talking about there :)...

> > > On the subject of networking, is anyone else annoyed by the level
> > > of network transparency in Linux. I know it's derived from UNIX,
> > > which has to be network transparent, but I find it annoying for a
> > > simple desktop. Anyone else agree?
> >
> > First, Linux is a kernel...X is the GUI...
>
> I'm talking about the network transparency of Linux, not X.

Ah, okay...sorry...

> Specifically, how Linux is typically setup bugs me. Wannabee summed it
> up nicely, "linuxmachine new everything about windows machine, before
> windows machine even knew its own name." (I was LOL-ing at that one,
> half the reason being, he's probably telling the truth.) Linux is
> defaulted (hard-wired?) to opening the LAN/Internet automatically. I do
> NOT like that. If I want the LAN/Internet up, I'll *tell* the system
> that. Otherwise, don't bring it up.

Ah! The way it connects up the LAN during boot up?

Yeah, that is rather annoying, I agree...

Nevermind, here's some possibly useful commands for Linux about that:

/sbin/ifconfig eth0 down

....which brings down your "eth0" interface...and:

/sbin/ifconfig eth0 up

....brings it back up...use:

/sbin/ifconfig -a

....to get all the details about your various network "interfaces"...

So, you could create a "shell script" that uses this command to bring the
interface "up" or bring it "down", when you click on it...then place it as
an "icon" on your desktop (with, say, a "globe" icon image to represent
"the internet" and you could set its name to that too, if you like
:)...then - hey presto - it's a "toggle switch" for your network
interfaces, so you can bring it up or send it down, at the whim of a hat
(as Bush likes to say :)...

Though, a more "advanced" version could be to create an X program, that
sits in the "system tray" of the "panel" at the bottom of the screen and
uses a "two monitors" icon to "mimic" the Windows' method of doing things
(and a big red cross over it when disconnected :)...which could, indeed,
flicker the icon or something to show when it's being used...and
double-clicking could produce a dialogue with "statistics" and a
"disconnect / connect" button...then, you could have something exactly like
you get with Windows for it (as noted, "ifconfig" already can do that for
you - and a lot more besides...want to change your MAC address too? - but,
you know, it's "command-line" and I don't know if there's any X-based
program that automatically interfaces with it, to give it a "friendly" GUI
face...like I was saying before, Linux has the "power" for these
things...but the applications that put a GUI "face" on them aren't
necessarily written yet :)...indeed, the source code for "ifconfig" has got
to "open source" somewhere out there...there's something you could practice
your "X programming" with: Write a GUI-based "ifconfig" replacement, which
pops up an "icon" and has a "dialogue box" to make this all easy to
"reconfigure"...in a sense, you're right that this is probably something
that's "lacking"...as you are NOT the only one - e.g. "me too" - who'd like
a program like that, so that, you know, you could actually manually "turn
on and switch off" the internet connection, as you please...and have some
kind of "visual icon" on the screen to show you when it's "on" or "off"...

> > [snip - lots of misunderstanding]
> > Increasingly, the usefulness of the real mode BIOS to a protected
> > mode OS is questionable...
>
> I must really be bad at explaining what I mean. I was thinking of the
> using the real-mode BIOS to tell me what hardware is attached and what
> not. I came up with this:
>
> There's a specific interrupt which AoA-16 identified its use as the
> "are you there" interrupt. I was thinking of the OS calling that with
> the location of a block of memory and having the chained interrupts
> writting out a little info about what hardware they represent.
> Specifically, they'd probably return a port, a command to send there,
> and a size to have reserved. The OS could send the command to the port
> and then send the address of a block of memory of that size. The
> hardware would then copy the code for its driver into that location.
>
> I know, probably bad, but I came up with that is little time.

Ah, no...I know what you mean here...actually, many OSes - including Linux
and probably Windows too - actually call BIOS interrupts to get
"information" before switching to protected mode...the most obvious example
is to "determine memory size"...because of "memory-mapped devices" - which
"overlays" a hardware device onto memory - then it's NOT actually "safe" to
work out "memory size" by using a "walking bit" (that is, you write a byte
and then read it back for the byte at the start of each 4KB page, say...the
idea being that for all actual RAM, you'll read back what you wrote...but,
when RAM runs out, you'll read back gibberish, not actually what you
wrote...as there isn't actually any RAM at that point :)...it's a "nice
idea" but it's not a "safe" method in general because, you know, videocards
may "memory map" the card's "video buffer" into areas where there isn't any
actual physical RAM...and you'd get the wrong results...

So, many OSes simply call the BIOS "memory size" routines before switching
to protected mode...why not doing it in protected mode? Well, you
could...but "querying" the "memory controller" and "chipset" about how much
RAM is installed? This can very often be "motherboard / chipset
specific"...and, so, you really could only get away with this generally
where you have a "motherboard driver" for the specific chipset...so, the
"trick" is simply to ask the BIOS about this, record the "memory size"
somewhere, _THEN_ switch to protected mode...well, you know, the RAM size
can't change while the machine's switched "on" (or, at least, the nutter
who tries to pull out RAM while the machine's still "on", is going to wreck
their hardware very quickly ;)...so, you can check with the BIOS for this
(the BIOS will know how to "query the chipset" to find out the memory size
:)...and then just use that value...and, you know, much easier to simply
use the BIOS _BEFORE_ switching to protected mode for things like this...

So, instead of making the BIOS accessible from protected mode...just use
the BIOS for the "plug and play" stuff _BEFORE_ switching to protected
mode...of course, that's a bit of a "cheap" implementation in that the
stuff that can be "dynamically attached / detached" wouldn't work with
that...but, for that, you'll really need to write protected mode "plug and
play" / "USB support" stuff...

BUT, I've never actually written any code about this, personally...the best
person around here to ask is wolfgang...you know, I'm talking from "theory"
(this particular problem being one discussed on the alt.os.development
group before, that I was "listening in" on what problems people were
getting trying to implement it :)...wolfgang's actually written an OS that
_actually_ does it, so he'll know all the details much better than me...I
tried reading the "USB specifications" but they seem stupidly
over-complicated to me (all "trees" and "stacks" and "hubs" everywhere
;)...best to see what wolfgang can tell you about it, as he might know some
specific "problem" I have no idea about with this...also, really, if you're
not already looking in on news:alt.os.development then it's wise to do so
because they discuss all this kind of stuff all the time...and have
"experts" in the "internals" of UNIX and Windows, who could tell you how
those two manage to do what they do...don't worry about being a "newbie"
there because, in fact, the group welcomes any enthusiastic people (hey,
they used to put up with my nonsense when I posted there, so, if they can
handle me, they'll handle anyone ;)...indeed, they even had a group-wide
project called "OS development for dummies", exactly to be an
"introduction" with a simple "demo" OS for you to follow through...

Yes, here it is:
http://my.execpc.com/~geezer/osd/

There's some good OS development information on here...and stuff about
programming hardware directly...and all that kind of thing...

[ I still find it funny that my name is in the "contributors" section...all
I actually did was spot a mistake in Tim Robinson's UK keyboard layout
diagram (one or two of the keys - or was it scancodes? I can't remember
now - weren't right...which were probably typos, rather than actual errors
:) and pointed it out...it's actually kind of "cheeky", really, because Tim
Robinson really should have full credit on that...he did all the hard work
there...I corrected a very small mistake in the diagram...but the way it's
credited, it looks like me and Tim did "half each" on the work or
something...not actually what happened, for the record :) ]

Beth :)


.

Loading