stuck writing keyboard driver

[Brendan]

Hi,

*sigh* Quite an aside there, based on a misinterpretation of what I said.
There are many philosophies you can use when building something for the first time. Building something so that it beautifully suits how *you* want to use it, is one of the best methods known for inventing new and wonderful things. The number of you that reject that pragmatic concept astonishes me. Trying to create a contraption that does everything for everyone is one of the *worst* ways known to make a good product. Perhaps you whippersnappers should contemplate that.

Writing something that beautifully suits how *you* want to use it (then expecting other developers to spend 3 times as long as you did to rewrite most of your crappy/inflexible code a few times, so that it's actually useful) does work well for open source software. This is mostly because other developers don't want to help until they see something work (so you rush to get any crud working to attract volunteers).

For example, imagine if I wrote a crappy Unix clone that doesn't support SMP, only runs on 80386 and doesn't have many device drivers, and it takes me 2000 hours of work. Then 9 other people see it and volunteer to help, and each volunteer spends 2000 hours making it work properly (and support SMP and other CPUs). That adds up to 20000 hours of work (but I would've only done a small part of it).

For "non-open source" software this doesn't work - it's much more efficient to spend 1000 hours designing the complete system, then spend 9000 hours implementing it once (ie. minimize the rewriting because there's no volunteers to fix your "lack of design" for free).

There may be a fundamental flaw in the way you approach OS design, and it's a flaw that (IMHO) other OS developers might share.

When designing an OS, you should/must try to take into account *everything*.

Right back atcha -- do you honestly not realize that it would take an infinite amount of code to take into account *everything*?

When designing an OS you should take into account *everything*. This might mean considering Unicode and deciding it doesn't suit your OS's goals, and doesn't mean implementing everything.

What you want to avoid is not taking into account something during the design, and then changing the design (and rewriting everything that's effected by the design change) when you realise you failed to take something into account.

If you don't you'll either end up with "hack on a hack on a hack" or "rewrite after rewrite after rewrite" as you try to add things you didn't originally consider.

I disagree. I will simply end up with two mutually incompatible versions of the OS. A US version, and an international version. The US version will be tiny and ultra-efficient, and the other will support everything for everyone and be fat and slow.

So you'd write the "US only" version, then waste time rewriting parts of it to support internationalisation, then waste more time trying to maintain the old/legacy "US only" version, and expect all the applications programmers to provide 2 seperate versions of their applications (one for the crippled/legacy version of the OS and another for the proper version of the OS)?

Why not design the OS for internationisation, and then only provide keyboard mappings, fonts, time zone information, etc for "US only"? What exactly would make the US version tiny and ultra-efficient compared to an internationalised OS that's been installed as "US only" (ie. installed without the unneeded data files for other countries)?

You'd still need to handle time zone differences (America isn't like China, with one time zone and consistant rules for the entire country), so not supporting internationisation here saves you some data files and nothing else.

If you support more than a few fixed size bitmap fonts (which look like crap when they're enlarged and don't support italics or bold) then you'll need some sort of font engine anyway. Not supporting internationisation here saves you some (optional) font data files and nothing else.

For keyboard drivers, how much CPU time do you think the keyboard driver consumes (would I need to buy an extra CPU just to handle the load from keypresses)? Does a hard-coded "US only" translation table take up less room than a dynamically loaded "US only" translation table, or are you worried about the 23 extra bytes of code needed in the keyboard driver to load the translation table from disk?

Probably the worst part is handling bidirectional text (e.g. languages like Arabic, that are written from right to left). This might add a few KB of code to your GUI (but including graphics and sound, the GUI is probably 50 MB or more anyway, so a few KB isn't going to matter much).

Most of the above examples of internationalization dealt with formats and daemon processes. These are all userapp level considerations. Almost none of them should be (or need to be) hardcoded into the kernel or OS or API. They are irrelevant to OS design.

An OS is more than just a kernel - usually "OS" includes device drivers, some daemons, a GUI (or CLI?), file system code, etc, but an OS is more than that - it's also a set of specifications that ensure interoperability between components.

Take my micro-kernel as an example - if an application programmer wants to do a "Hello world" application, do I (the OS developer) tell them to go speak to the GUI developer for whichever GUI they're writing the application for, or do I have a standard "GUI interface protocol" that all applications and GUIs rely on for interoperability (to ensure that any application works with any GUI)? The micro-kernel doesn't care how the applications communicate with the GUI (it's a user-level issue), but that doesn't make any difference - it's still an OS issue.

Unicode/UTF is one exception -- since it directly impacts the concept of "string termination". However, I consider the current impementation vastly unweildy, and I think it will certainly be completely superceded at some point by something better. Implementing and supporting a botched standard is not a guaranteed way to gain acceptance for your OS.

Unicode is unwieldy. The reason for this is that the variety of human languages is unwieldy. There won't be a less unwieldy standard that replaces Unicode, unless you can think of a way to get rid of the majority of the world's population so that there's less variety in human languages.

And I didn't mean to imply I was going to use ASCII-7. Of course I will be implementing extended ANSI Latin1. I have 8 bits, and my target is efficiency, remember. I want the US version of the OS to boot to a full GUI shell in under 1 second, and I'm well under that target, currently.

One second before the OS boots, and three seconds before the OS is uninstalled - sound much better than 1.05 seconds for the OS to boot and three years before the OS is upgraded...

Most OSs boot slow because device drivers, daemons, etc are started one at a time and not in parallel. The other reason is loading large amounts of graphics data (icons, bitmaps, etc) for the GUI. Bloated code and inefficiency do contribute to this, but that doesn't really have anything to do with internationisation.


Cheers,

Brendan

[LordMage]

Well, it's been a few days since I checked out the site and I must say that I never thought that my comments would spur so much misunderstanding, hatred, and mud flinging. I actually think it is kinda funny, just to let you all know. I was only trying to make a small point that regardless of what the rest of the world wants I think that any development project should only worry about A. what is required B. what you want.

@Solar - You want a multicultural OS that anyone can use and one that supports all possible nations and user styles. I might be wrong on somethings but I think that is the just of it. While I don't know for sure if that would make your OS slow, it would eventually make it bulky and for some of us that is a cost that is beyond what our OS is being designed for.

Other people like the mathematician and me prefer an OS that suppports our needs. Whether that be spanish support, Complex programs for calculating electron jumps and other quantum mechanic functions, 3rd grade english, Enhanced 3D aided graphical design, etc...

I want *my* OS to support the things I feel like I need. That means English characters, possibly some of the special characters for words like resume that should have an accent and a personalized GUI, I was thinking XML like the xbox. maybe not the best but I can make it look however I want that way. I don't however need mandarin characters because I wouldn't know them if I did have them. I don't know too many words that I use that would require an umlout, I know your going to nail me for spelling that incorrectly but please forgive my ignorance.

I appolagize if I came off as a racist though. I never think of myself that way although from time to time I may make comments that, I guess, could make me sound like one. It's tough being an American. Not living, but always having to watch what you say gets really annoying. It seems like just saying the word America makes so many people angry. We have a bad rap as being loud mouth, not caring what other people think, and many other things. I guess my posting on this particular thread isn't really a redeeming quality but most of the time I think that everyone is wrong when they generalize us that way. I made a comment about the "dumb white american male" thing as being a joke. Apparently nobody took it that way but that was the intent. Well, everyone have a good day and I do hope the original owner of this post finds what they need.

Well, I think that is the last I will say on this thread. Everyone have a great day and good luck with the OS deving.

[axilmar]

Besides, even with UCS-32, one can't assume array-cell-is-a-character (only that it's a codepoint), because one can compose characters using composition codepoints, which means one logical character that be practically any number of codepoints.

To clarify:

Unicode defines a "code point" as an integer value representing an abstract Unicode "character".

A Unicode "character" can be "printing", i.e. have a graphical representation (called "glyph"). It can be "non-printing", i.e. modify the next character instead. (Think of "dead keys" on the keyboard that add accents etc. to the next character typed.) It can even have a graphical representation of more than one glyph, especially in the asian alphabets. Or it can be not defined / reserved for later expansions of the standard.

That means, while we have a 1:1 relationship of Unicode "code points" and "characters", we do not have a 1:1 relationship of Unicode "characters" and glyphs (which are what the layman might call printing character). In fact, we have a m:n relationship here.

It gets worse. A non-printing Unicode "character" can induce a "shift state", which might not end with the next character - i.e., a "dead key" influencing more than one following character. (Not 100% sure if there are not even characters influencing preceding characters...)

Furthermore, as mystran stated above, several (combinations of) Unicode "characters" might result in the same glyph, yet still be very distinct (combinations of) "characters".

And finally, in encodings like UTF-8, one Unicode "code point" can be encoded by anywhere from 1 to 4 bytes.

And before you flame Unicode for being so complex, remember that we don't have any other way for representing all alphabets of the world in one encoding system. If you have ever fiddled with a system where the kernel messages are in one encoding, the console in another, and the file system in a third, you will know why there simply is no way around Unicode if you want your system to go anywhere beyond Montana.

Excuse me for this naive question, but isn't a 32-bit 1:1 representation of code points to glyphs enough to store every character of every language ever created by humans?

[LordMage]

Well, they weren't saying that Unicode has or doesn't have every character ever known to humankind. What they were saying is that not every value in unicode has a visible character associated with it. you could have a codepoint like in ASCII for NULL, or backspace, which doesn't really print but lets you know that your OS needs to remove the previous character. and even with 4294967296 possible values we still might have to expand to a 64bit unicode system when the governments of the world admit to aliens and we have to start making keyboards for them too. Just kidding about the last part

[Candy]

If you're considering not supporting unicode but only US/Western Europe for target, IE, ASCII or ANSI or ISO8859-1 or ISO8859-15 - if you can live with only ASCII for now, use that and postpone your decision on the other 128 values in a byte. You can then retrofit UTF-8 fairly easily.