A Completeley Redesigned C library

[Brynet-Inc]

Hopefully, something like the Optimus Keyboard will finally come out (supposed to in 2007) and make this entire conversation obsolete

Looks kinda neat.. Let's just hope it doesn't sport any Windows-only vendor lock-in.

But who would pay for a keyboard that will cost around $1,200 USD.

[Alboin]

Hopefully, something like the Optimus Keyboard will finally come out (supposed to in 2007) and make this entire conversation obsolete

Looks kinda neat.. Let's just hope it doesn't sport any Windows-only vendor lock-in.

But who would pay for a keyboard that will cost around $1,200 USD.

LED keys? Who wouldn't want one? (I could just imagine an os for that keyboard. Instead of posting errors on the screen, it would just rearrange the keys. You could have real fun with your user then. )

[Solar]

..something like the Optimus Keyboard...

The point is: using QWERTY, I get my keyboards cheap, everywhere, and in any shape I want. (Having large hands, I really like the MS Natural layout.) Using DVORAK, I either have to "fudge" with the keyboard or pay extra $$$.

[Ready4Dis]

..something like the Optimus Keyboard...

The point is: using QWERTY, I get my keyboards cheap, everywhere, and in any shape I want. (Having large hands, I really like the MS Natural layout.) Using DVORAK, I either have to "fudge" with the keyboard or pay extra $$$.

Yes, i never disagreed that it wasn't main-stream. When one product is mainstream, it's hard to replace it, because that requires a LOT of extra training and a learning curve. Someone with no knowledge of keyboards would have just as easy a time learning a dvorak keyboard as qwerty, but not to many people have not used a keyboard before and become accustomed to it's layout. Besides, "fudging" a keyboard to change it to dvorak isn't hard, especially if you don't look at the keys while you type anyways.

[GLneo]

the Optimus Keyboard

imagine the games you could play with just the keyboard!

[TheQuux]

..something like the Optimus Keyboard...

The point is: using QWERTY, I get my keyboards cheap, everywhere, and in any shape I want. (Having large hands, I really like the MS Natural layout.) Using DVORAK, I either have to "fudge" with the keyboard or pay extra $$$.

And, you can't get a Type 6 keyboard (still the best I've tried) in Dvorak.

However, I have given the dvorak layout a fair chance, and found that hunt-n-peck is no faster on Dvorak than qwerty

[iammisc]

This thread has turned from a thread about the C library to a thread about keyboards and other weird things. There are 4 pages here about KEYBOARDS and EVERYTHING ELSE except the C library. In all, there were only about 5 posts about the actual topic. Please put this keyboard-related stuff in another thread.

[Solar]

Unfortunately thread-splitting isn't as easily done here as on the old MT forum.

And besides, the keyboard thing arose and was largely about something that is significant for a "completely redesigned C library" as well: the hen-and-egg problem, and that "being mainstream" can be a very strong factor in decisions.

To bring it back on topic: For me, providing the standard library, and all of the standard library, is simply a "must have" for any platform outside of very dedicated appliances (embedded). No matter how "bad" the standard lib might be, it's there, people are used to it, and fully expect their ANSI/ISO "hello world" to compile cleanly even if your OS provides much superior APIs.

So it's really not a matter of "redesigning the C library", but a matter of how good your additional API libraries are.

[iammisc]

well that is the question i am asking i guess what do you expect to see in those extra api's? they would still have to re-implement the same c library functions but on a better level.

[Solar]

Would they?

In your OS API you are "boss", you can do whatever you consider best. Me, personally, I wouldn't bother too much about what the standard lib does, or what could be improved there. I would think about what my OS wants to offer, and the best way to represent it. Don't think of your API as an extension of the standard library (as POSIX did); you might (should?) want to do something completely different. AmigaOS AllocMem() or MSFC CString spring to mind.

In the end, OS API design is at least as much important (and a question of personal style) as some nifty kernel features. Other things are also important, like, can different languages use the same API (and each other's libraries)...

[pcmattman]

Exactly, some of us actually enjoy loading up our hex editors and writing COM files from scratch, via machine language. I find it incredibly engaging and exciting...

Don't you just love sarcasm?

Edit: oh no I did it again... didn't realize I was replying to a post on an earlier page, now I've been left behind

[earlz]

So it's really not a matter of "redesigning the C library", but a matter of how good your additional API libraries are.

so maybe we should have a standard API library type thing?

[maddog39]

[Off Topic] Dam, that keyboard is gunna be a huge pain in the @$$ to write drivers for when it comes out. You'll need to make a whole gfx library for it...

[Candy]

In the end, OS API design is at least as much important (and a question of personal style) as some nifty kernel features. Other things are also important, like, can different languages use the same API (and each other's libraries)...

I would say, design your lower-level libraries keeping in mind that you'll have to be able to emulate POSIX or ISO C on top of it. As long as you can do that, possibly with an unintentional or intentional speed loss, you can support older style programming and your newer style.

I only recently found the Wiki page for C++0x and just about all the things I've figured out for my own OS are in the new stdlib... so I've turned a bit around and started to implement most of that instead. It's going to be pretty bare for non-C++ programmers and they still lack a few things I did include (which are pretty easy to add, such as write&forget and read&ignore, first is a nonblocking write that just buffers in kernel memory, second is a read that imitates a read by reading to a nonpaged page).

One thing I'm struggling with is how to present the user with explicit buffers, so that you don't pass a buffer to read() but you get a buffer from it instead, and you don't retain your buffer after write() but you give it up to him instead. That way, zero-copy implementation is trivial.