Re: Need help on modifying and assembly of a small program!

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 02/05/05 

Date: Sat, 05 Feb 2005 09:43:47 GMT

NoDot wrote:
> Come to think of it, are you going to make a reply to my DotOS post? (it
> might still be under the previous thread's title)

Yes; I've grabbed your posts and saved them locally this time...in fact,
I'd started the reply to the first one but then you kept adding more
on...indeed, I perhaps should have made a short version just to get up the
beginning of the reply: 1. Sorry if my criticisms in the earlier reply
sounded somewhat harsh BUT: 2. If you want good and useful reply, then
"good and useful" does _sometimes_ mean "didn't really want to hear that"
from time to time...after all, would you prefer me saying "oh dear, better
be careful of such-and-such" now or for me to say "that's just great", you
spend months working on it, try it out and it doesn't work properly...all
that time and effort wasted...so you ask me: "Why did you say that was okay
when it clearly wasn't?" / "Just being polite"...ummm, no...though perhaps
"abrupt", wouldn't the other really be the greater "impolite" thing to do?
Just dismiss: "yes, yes...it's all good" when it isn't and you waste all
your time and effort that I could have at least "guided" to be slightly
more productive because I can see an "issue" with it already (something
that, indeed, may not be at all "problematic" now but just wait until
later! ;)...

Plus - again, not being "impolite", just honest to save time and put
everyone on the "same page" - you have just "demanded" I take a look at
this from nowhere...now, I don't mind doing so (like I have anything better
to be doing with my time ;)...but, well, if the replies are delayed, it's
because I'm already juggling plates and you've just thrust another in
there...again, I don't directly mind that...after all, I'm already juggling
plates, what's one extra going to matter? BUT if you're going to do that
kind of thing, you've got to realise that other people can't automatically
make it their "priority", just because it is for you...you know what I
mean? I'm interested in OS development and so forth...BUT, then again, I'm
not currently developing any OS, I'm working more on ideas to do with
programming language stuff (like LuxAsm) and such...the point being: If you
just dump something on me like this, then, yes, though I'm interested and
will get around to a reply, I can't necessarily "drop everything" to make
your stuff "priority"...hence, "expect delay"...again, like that other
post, this is not "impolite" or whatever, this is just "telling it like it
is" so that we know where we stand...I've already started a reply to the
original post and have saved away your "additions" to add that on too...I
mean, presumably you're asking me because I write long posts and will point
out all the various bits and pieces in such a long post...well, if that's
what you want, then this is the "price" attached: It takes me longer to
write such things...

A quick general comment would be to check out other OS development
resources...it's not as if there's some "scarcity" of such things out
there...there's news:alt.os.development (it's a very good group to discuss
things on and has many members who're on this group too...indeed, the sole
reason I stopped posting to that group was that my ISP suddenly dropped it
:)...and a Google on "OS development" should pop up lots of things (not
solely "technical information" but also stuff about design: Hence, they may
"inspire" some new ideas or make you realise that you've "left something
out"...for instance, Russian Cyrillic keyboards? Did you remember this kind
of thing? Russians have a different alphabet and a different keyboard...are
you being too "ASCII" and "English-biased" in your designs? Greeks are the
same...Israelis have the Hebrew alphabet...Japanese, Arabic, etc....hence,
this is one reason, for example, for posting to such a newsgroup: You can
actually talk to Russians and ask them about their keyboard layouts and
such...well, it's easier than going out to order a bunch of keyboards from
all over the world or whatever, yes? Of course, perhaps you don't really
care for "international support" at the moment...BUT will you care _LATER_?
Because, if so, then you must still remember to "leave room" for it...for
example, make your keyboard driver use "keymaps" or something (which simply
"map" the hardware scancodes to, say, UNICODE characters and, as keyboards
also have non-character keys (like "SHIFT", "ALT", etc. :), "virtual keys"
or whatever :) so that it can be loaded with different keyboard layouts in
future...and then, to begin with, just create a US layout and use
that...BUT you've left in the "support" for a British layout (oh,
yes...just because both places speak English doesn't mean we actually have
the same keyboard layouts ;) or a Russian layout or whatever to be added in
easily later by just creating some more "keymaps" for each kind of keyboard
(which is just data you can load the keyboard driver with, really...you
know, the driver has a "table" in its memory for converting key presses
into characters and stuff...simply make this "flexible" that you can load
in different "tables" - "keymaps" - from files :)...

There's a _lot_ of considerations to make with an OS...of course, how much
all depends on what kind of "system" you want to create...you could say
"this is English only" and then all the above just doesn't apply (but, of
course, in doing so, you have to "accept" the consequences of this
decision: International users might not be too eager to use your OS because
it's not really supporting their keyboard correctly...note, even when
people post in English, their keyboards aren't necessarily labelled in
English...it was interesting talking about this on the
news:alt.os.development group with Maxim and Alexei - who are Russians -
that there's a kind of "standard" for typing English with their Cyrillic
keyboards...you hit some keys and then it switches to "English mode" (or
something like this :) and the keys pop up Latin characters...tap the key
again and it's back in "Cyrillic mode" and up pop the Cyrillic
characters...BUT this kind of thing depends on "OS support" to make it
happen...and, of course, if _YOU_ are writing that OS, then it's _YOU_ who
has to think it over and add in the right "support" to make it
happen...also, for something like this, you'll probably want to follow the
"established standards" and not make up your own...simply for practical
reasons: It takes a while to learn to type according to these standards, so
users will not appreciate "re-learning" some other standard you've just
"invented" (plus, the standards are, of course, usually invented by people
who _know_ about the languages involved to know what is and isn't
needed...making up your own "standard" when you don't know the
language...well, it's asking for trouble that you might "forget" to support
something...for example, French and German people use Latin characters BUT
they also have the "accented characters" too...so, even for people who use
Latin characters, then ASCII isn't necessarily "good enough"...and if
you're going to support all this, then the simplest solution would seem to
be to make things "UNICODE" throughout...that changes a lot of things
around in your design: Filename conventions for Japanese characters? ASCII
compatibility for "porting" over some ASCII-based utilities from UNIX
(suggesting the UNIX "solution" of using UTF-8 because it's "ASCII
compatible UNICODE", so to speak)? Your API having to pass around UNICODE
names...blah-blah-blah...

So, this is my point, really: Even a keyboard driver is "non-trivial" (and
can effect the entire OS design), depending on what you do and don't want
to include...after all, "international support" is a good (and arguably
very needed) thing, if you intend people all around the world to use your
OS...on the other hand, adding such things isn't necessarily "easy"
(though, of course, one often used idea is to "leave room"...that is, pass
around UNICODE so it's "supported" BUT, yeah, don't bother with any
non-Latin initially...you can "get around to that later" :)...

And, in a sense, decisions in one place effect design decisions
elsewhere...if you're going to add in UNICODE support for the keyboards
then you'll probably need to make your "filename conventions" work with
Japanese characters...after all, someone who speaks Japanese is probably
going to prefer that they can name their files in Japanese than be forced
to use English (which would also be especially weird if allowed to use
Japanese _everywhere_ except, ummm, filenames...that would be a little
"unnatural" for them, yes? ;)...

To please Annie, there's a Bono lyric that I think captures it: "It's no
secret that ambition bites the nails of success"...if you're "ambitious"
then it's a lot of work and that will, ironically, "bite the nails" of
getting it done and getting it to work...if you're "modest", then it's
easier to get things working and working well BUT you'll have a "limited"
thing from doing so...

This is the "firm decision" behind what I was saying about making
"specific" OSes...it's NOT some clear-cut thing that "specific" OSes are
"better"...and I Hope I gave no impression or indication that it was...the
point, though, is that _IF_ you can make a "firm decision" to be "specific"
then you can _take advantage_ of that to be "modest": Hence, it's easier to
get it working and it's possible to get it _working well_ (optimised for
the machine and so forth :) and to develop it faster and so forth...BUT, at
the same time, it's "limited" by that...

It's a "trade-off" kind of thing...my point was that some kinds of
"portability" seem to provide very little use to the users but require a
lot of effort from the developer...the most obvious is "portable source
code" for the OS...this tends to "compromise" the performance to the user
and is of no direct use to them (well, as a "user" it isn't...if they are
also a "developer", it might be useful :)...to get things "portable", the
OS is also often "compromised" from a "lowest common denominator"
perspective (consider, for instance, the original CD-ROM format: To make it
useful to DOS, it only supported the 8.3 convention...this might have been
"portable" but was annoying, awkward and very limited for other OSes...so
much so, they couldn't stand it for long and "extended" the specifications:
Again, this is another demonstration that though "portable" _THEORY_ sounds
good, it often proves _USELESS_ in practice...another example: Windows NT
was originally coded to be "portable"...Microsoft - and, remember, this is
one of the richest companies in the entire world with the "resources" of a
small country behind it - couldn't really see that the "audience" on other
machines was really worth bothering with...they dropped bothering to
support other machines except the x86...though, that original "portable"
decision, in a sense, still "haunts" the OS design...again, people were
"theorising" that "portable" was great...but, in actual practice, it proved
useless or pointless and "retracted" that support...

Now, this is NOT to say that "portability" is "always useless"...of course
not...but, generally, the only real "success" that uses it is UNIX...BUT -
here's the "irony" - there's many different versions of UNIX out
there...and due to "copyright" (bloody SCO! ;), then Linux and such are
_re-written from scratch_, anyway...you starting to see what I mean,
perhaps? In hindsight, would it have been smarter to have not considered
"portable source code" (note: This is the "portability" of the OS source
code itself...the "portability" that UNIX itself has - standard syscalls,
filename conventions, etc. - are a different matter and don't need to be
compromised) at all, in fact? Instead, to have simply written "specific"
versions for each platform...after all, when writing something like a
"libc" library, this is what tends to be the case when all the OSes have
different underlying "API" to implement things...and so on and so forth...

It's great "theory" to have "portable source code" BUT, in _practice_, is
it really worth the efforts and compromises and typically reduced
performance? From observation, it appears NOT to be the case...Microsoft -
well-placed with their money and resources, that you have to ask "if they
can't make it fly economically, then can anyone?" - dropped their
"portability" when it proved the "market" just doesn't need it (the
"audiences" on other machines are comparatively small...also, they
typically _ALREADY HAVE_ their own OSes...so, in a sense, you can say
"Apple already have Macs covered"...Mac users have a generally good OS
there, they probably don't want to change...hence, after Macs, what other
non-x86 machines are there left to cater for? And do they really have
enough users to _JUSTIFY_ your "portable source code"? Another example is
from NASM...it _CAN_ compile onto any system with a C compiler (which
basically means "any system" because they all typically have a C compiler
:)...BUT, check the NASM downloads and discussions, they ain't bothering
too much anymore with the 16-bit version...and who has even bothered
compiling it on a Mac? Oh, someone has, I think I recall...but that's kind
of the point: someone..._singular_...is it worth the effort just for one
person to "experiment" but never really use it for the Mac? I'm not
criticising NASM, though...in a sense, we _need_ at least one utility that
can do the "portable" thing (and, with OSes, UNIX does that :)...

BUT, basically, "genericism" has been pushed so hard for many decades (with
good reason: originally, no-one gave the slightest thought to "portability"
_at all_, which caused "nightmares" everywhere...but things _change_:
Drivers "solve" one portability problem, "standards" solve other ones...now
we have the internet protocols and so forth...is it quite as important as
it once was, in that respect? :)...that "specialisation" has almost become
a "dirty word"...if you suggest it, then people attack you for daring to
question the almighty "portability"...

BUT, we have to ask if the _REALITY_ has changed - "open standards",
"drivers", the internet protocols, "open source" methodology, etc. - that
the practices should also _change_..."adapt" to their new
situation...hence, my proposal: Instead of creating a single "portable
source code" OS, for example (though note: an OS is just an example, could
also make sense for applications too :) then create an "OS standard" - file
system conventions, system calls, etc. - and then re-write this OS
_specifically_ for each platform, employing, for example, a series of
"sister project" open-source developments (generally, this _won't_ cut into
the "thousand eyes" at all because there probably won't be any "overlap":
x86 users work on the x86 version, Mac users work on the Mac version,
etc....these groups are likely to be quite different people, anyway...and
"overlap" is not a bad thing: Such people who work in both groups, make
natural "co-ordinators" to ensure that the separate OS developments
correspond...if one project has an idea, then it can be propogated to the
other projects...indeed, we would still prefer things to be _standard_
across these OSes - no "re-learning" how to use them from one platform to
another - so the point is, in a sense, that I'm saying "portability by
standard", not by literally having the exact same "portable source code"
files...in a sense, something like X or Java already does that and
demonstrates that it can work and work well :)...

But it's NOT "automatic" that "specific" is always a good idea or
whatever...it'll all depend on your design and "intention" and so
forth...are you just doing it this way "because Beth said so" or because
_YOU_ want it this way for some of the reasons I've stated? Because,
simply, if you don't _believe_ it's a good idea yourself or understand why
I'm saying these things, then - even though it's my idea and I would like
to see it adopted somewhere - I'd have to recommend it's not done in that
kind of way, if you know what I mean...not least because, to do it right,
you really do have to understand _why_ things should be done in a
particular way...the "peer to peer" / "channels" stuff in LuxAsm - which is
"toolmaker's view" in attitude - _IS_, I Hope, a good idea...but if you
don't "get" _WHY_ I'm doing it the way I'm doing it, then it'll be hard to
implement it correctly...

Speaking of which - you are a LuxAsm developer too - I've been working on
writing some basic "design map" stuff about these concepts...another one of
my "mad ideas": The "design map" as some kind of "wiki" / "RFC" device for
development...I detail the idea better in the actual "design map" itself
but, basically, a _delibrately dynamic_ set of "documentation" about the
design ideas...a "development wiki", basically, except it's a bunch of HTML
pages and you edit them directly (I presume everyone involved knows
sufficient basic HTML - nothing complicated involved - that there's no need
for "wiki software" to do it specifically: After all, the CVS does
"versioning" automatically for "roll back"...so just stick HTML pages on
there and, in "wiki" spirit: "have at it!" ;)...

Beth :)

Quantcast