Ah, okay, thanks, I just wanted to know that ....It's not ported from GLIBC (I think GLIBC uses the information supplied by the OS it's running on).
Part of the information that my database will originate from comes from IBM
I wouldn't say that my C library would be broken, just that it wouldn't comply with the standard.Solar wrote: Yes, and that's the problem. A strictly compliant C program must be able to run. The programmer went to some lengths to make his/her programm fully compliant so it can be compiled and run on the widest range of platform. No matter how much "better" your C library might be, the second you stop fully supporting the standard, it is your environment that is broken.
This would depend on how much I differ from the standard. If a few time related functions are the only thing that is different (for e.g. the exact data in a time_t) then other developers may be a little annoyed. If the entire library is completely different then other developers may be completely annoyed. It also depends on the results - if the other developers are impressed with the end result that my differences achieve then perhaps they won't mind too much..Solar wrote: With the publicity of the C standard, you can rest assured that the standard will be extended in crucial areas before it becomes a problem. Until then, you better support the standard, or developers will get annoyed at you.
This is a good idea where it is possible. If (for example) the way an OS starts a process is completely different to the standard, then developers may end up with:Solar wrote:Supply those additional features as option. Microsoft supplies CString, but you can also use std::string. AmigaOS supplies AllocMem(), but you can also use malloc(). The standard is what people know, and fully expect. If your options actually are better, people will use them after a while. But an OS that can't run fully compliant C programs is simply broken.If you spent years writing an OS that supports far more advanced features than those that currently exist, and people ported crusty old C programs to your OS, and users used these crusty old C programs on your OS, then what would be the point of writing an OS that supports far more advanced features in the first place?
Code: Select all
int WINAPI WinMain(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR m_lpCmdLine, int nCmdShow)
When the motor car was first invented did people say "I'm not using that because I don't know where to put my saddle?". If people want Unix let them use Unix. I completely expect to write all the software myself until the OS is fully functional (which is likely to be the case regardless). At this point there will be plenty of example code to use, and people will be able to see the benefits. I don't want to waste years writing an OS that ends up looking like another Unix clone. The standard "Hello World" won't work well under any GUI.Solar wrote:Expect to create an OS without software, except for what you wrote yourself.I do not want people to port code to my OS without making huge changes...
People start learning about a programming language, usually from a book or tutorial. If they fail to compile their "Hello World" because your OS doesn't support printf() but only your far superior (but unknown) printme() function, you'll end up being flamed, ignored, or both.
Ok, my statement was far too general. All standards that are used by my OS to communicate with other OS's should have been excluded.Solar wrote:Erm... like, TCP/IP, POP3, SMTP, HTTP, ...?...and I have no interest in being compatible with any standard unless that standard is extremely similar to what I would have come up with anyway.
Code: Select all
#include <stdio.h>
int main()
{
printf("Hello World!\n");
return 0;
}
This code works does it? Under MINGW it compiles and runs, but it creates a console window that disappears before anything can be read. With GCC and Linux it does the same when I run it in KDE. Obviously it doesn't work as expected, like it would have 40 years ago. To make it work properly you could add code that waits for a key to be pressed before it terminates - that way you would be able to read it.Solar wrote:Code: Select all
#include <stdio.h> int main() { printf("Hello World!\n"); return 0; }
I'm an assembly programmer, and I'm not too sure what's POSIX and what's ANSI. Are the standard file IO functions (fopen, fgetc, fread, etc) ANSI? If so I won't be supporting them - my OS doesn't do blocking file IO, for instance "fopen" returns immediately (with an error code that determines if the request was accepted) and some time later the OS sends a message containing the status of the request (if the file was opened or not, and a file handle if it was). The thread using fopen needs to handle unrelated messages in between calling fopen and receiving it's results.Solar wrote: Not supporting POSIX is one thing - that's a Unix standard, with severe implications for your OS architecture. But not supporting ISO / ANSI C in an OS using C as a language (I assume)... that's heavy stuff.
). It seems that FRANCE.TXT could perfectly fit be/fr. Cannot tell for BE/deA french user in belgium shouldn't just use FRANCE.TXT, as the internet code ('be') and the international telephone dialing (when present) will be wrong. I'll add some sub-zones to handle this, as belgium doesn't need sub-zones for different times zones.Pype.Clicker wrote: hmm ... you need to know that belgium has 3 national languages: dutch, french and german (in alphabetical order
That's an issue of current GUIs handling console applications badly. (IIRC, AmigaOS would pop a window titled like the executable, and reading "Hello World!" until you close it). Of course the standard output of applications has to go somewhere, but that's for your runtime environment to handle, not the application in question (which is allowed to be as simple as possible).Brendan wrote: Under MINGW it compiles and runs, but it creates a console window that disappears before anything can be read.
Someone who wants to write up a quick&dirty solution? Testing whether the compiler works, without writing up some lengthy GUI code?Under windows it'd look much better if a dialog box was used instead (same goes for KDE/Gnome/X) - after all who wants software that looks like a 1970's dumb terminal?
Wrong notion. C (and C++ as well) don't go into GUI, networking etc. because they want to leave all options in your hands. They just define bare necessities.I wonder what the standard library call for creating a dialog box is? Hmm - there isn't one. It seems that if this code is written with any professionalism it isn't portable anymore. Pity.
They're standard in all application programming languages I know of. You'll have a heyday implementing "your way" in all these languages - or waiting till judgement day for others to adapt widespread languages to your niche OS.Are the standard file IO functions (fopen, fgetc, fread, etc) ANSI?
What keeps you from implementing both? A blocking wrapper called fopen() around your non-blocking OpenFile()?If so I won't be supporting them - my OS doesn't do blocking file IO...
Absolutely ACK. My OS is designed the same way. But every time I come up wih a nifty new design, I ask myself two things: 1) "Does it improve things for the programmer and / or user?", and 2) "Could I possibly add some compatibility with the old ways without compromising my design?".My OS is designed from scratch without any consideration for current programming methods.
But other people will want to code in their language of choice. They will add such wrappers around your nifty OS API anyway. Doing so in advance will make your OS a friendlier place for all of them.I'm not even sure I'll have a C compiler, as currently I'm leaning towards a language with syntax remotely similar to BASIC (which would be both interpretted and compiled).
I understand your approach, but there's a difference in avoiding crippling legacies and needlessly crippling your OS. Just make sure you're making your design decisions for the right reasons.I fully accept that I might have difficulty getting other people to write software for my OS. This is fine (and likely regardless of what I do)
While it may not be entirely relevant to the discussion, I might point out that there was some discussion on the General Programming forum on the design of a BASIC-like systems language; while the original thread has ceased being active, you may find it worth looking at. I've been meaning to revisit langauge threads for a while now, but haven't had a chance lately.Brendan wrote: I'm not even sure I'll have a C compiler, as currently I'm leaning towards a language with syntax remotely similar to BASIC (which would be both interpretted and compiled).
My general motivation here is that simple data types should be defined with allowable ranges, instead of it's size and if it's signed or not. For example, "I-128to127" would be equivelent to C's "char", but so would "I0to2" if the char doesn't need as much range. The interpretter can constantly check that variables are within range, and (optionally) compiled code could also. The main benefit being array indexing, structure/bitfield packing and code optimizing. When the code is compiled simple functions could automatically be converted into tables (with the values in the tables generated by interpretting the code). Also functional languages refuse to return more than 1 value (an unecessary artificial limitation). C programs normally get around it by supplying the return variables as input instead of output (IMHO it's like getting the shop to pay you a negative amount when you buy something).Schol-R-LEA wrote: While it may not be entirely relevant to the discussion, I might point out that there was some discussion on the General Programming forum on the design of a BASIC-like systems language; while the original thread has ceased being active, you may find it worth looking at. I've been meaning to revisit langauge threads for a while now, but haven't had a chance lately.
Code: Select all
void splitColor(int colorCode, char *red, char *green, char *blue) {
*red = (colourCode >> 10) & 0x1F;
*green = (colourCode >> 5) & 0x3F;
*blue = colourCode & 0x1F;
}
void test(int colorCode) {
char red, green, blue;
splitColor(colorCode, &red, &green, &blue);
printf("%c, %c, %c\n", red, green, blue);
}
Code: Select all
(I0to31 red, I0to31 green, I0to31 blue)splitColor(I0to32767 colorCode) {
red = (colourCode >> 10) & 0x1F;
green = (colourCode >> 5) & 0x1F;
blue = colourCode & 0x1F;
}
void test(I0to32767 colorCode) {
I0to31 red, green, blue;
(red, green, blue)splitColor(colorCode);
printf("%c, %c, %c\n", red, green, blue);
}
I'd rather have very good software that does take advantage of the features my OS will support. I'm willing to do anything I can to make this happen, including annoying developers who don't care about these features or the quality of the end product.Schol-R-LEA wrote: OTOH, as Solar points out, while you might not care to implement a C compiler on your system, it is likely that at least some of the users of your OS would. Making it difficult to accomodate the users' needs and wants is mever a good idea, even when there are good design reasons for it.
Don't confuse the end users with developers. The end users will say "make the OS brilliant and innovative" while developers will say "re-invent the wheel (but make it rounder) because we already know about wheels". Fortunately developers are also a type of end user, which makes them schitzophrenic.Schol-R-LEA wrote: I've been trying to deal with a similar problem myself and I'm not sure yet how to balance the design goals with the needs of the users. For one of my OS designs, I've been considering forbidding native executables outside of the kernel and the 'driver space' and 'services space' in CR1 and CR2, respectively; all user applications and utilities would have to be interpreted. Needless to say, while this would have some advantages for system stability and security, it would be unpopular for it's effect on performance. I'm hoping to find some compromise solution, but chances are, this particular design idea will end up getting shelved.
An interesting approach, and one taken (in different forms) in several other languages; compare the [tt]FIXED BIN[/tt] types in PL/1, and the [tt]range[/tt] types in Ada. Your goal seems to be more general, though, and in some ways is similar to [tt]range[/tt] variables in Python (not to be confused with the Ada construct of the same name). However, the downside to this is that many programmers, esp. systems programmers, tend to be lazy and consistently use sizes that match the machine word size on the system they are coding for. The solution used by Ada is to provide predefined Integer types similar to those in C; not surprisingly, they tend to get used even for tasks where a more carefully specified subtype would be better.Brendan wrote: My general motivation here is that simple data types should be defined with allowable ranges, instead of it's size and if it's signed or not. For example, "I-128to127" would be equivelent to C's "char", but so would "I0to2" if the char doesn't need as much range.
First off, C is an imperative language, not a functional one. Many functional languages do allow multiple value returns, either directly as a list like you propose, or indirectly as lists or tuples. Python, which combines imperative, functional and OO features, has a multiple return construct quite similar to the one you describe below IIRC. In C, one could return a structure pointer to return several values, though as a general solution it would be rather awkward.When the code is compiled simple functions could automatically be converted into tables (with the values in the tables generated by interpretting the code). Also functional languages refuse to return more than 1 value (an unecessary artificial limitation). C programs normally get around it by supplying the return variables as input instead of output [[...]].
Code: Select all
]
While I see your point, in this case it would make more sense to me to use a [url=http://www.harpercollege.edu/bus-ss/cis/166/mmckenzi/lect13/l13h.htm]bitfield[/url] for the RBG values:
[code]
typedef struct {
unsigned int red:8;
unsigned int green: 8;
unsigned int blue:8;
} RGB;
RGB colors;
RGB setColors(unsigned int ColorCode)
{
return (RGB) ColorCode;
}
void test(RGB color) {
???printf("%d, %d, %d\n", color.red, color.green, color.blue);
}While I agree regarding Pascal, as for BASIC, it depends on the dialect. In any case, C is still much easier to parse than, say, Java, and LISP is still easier than Pascal.C is also a difficult language to write compilers & interpretters for. BASIC and Pascal are much easier to parse...
Antagonizing your developers is a poor idea; or do you mean to write ]all of the applications, games, utilities, etc. for the system by yourself? Even the best OS cannot succeed without programs to run on it. Mind you, my own design sidesteps the issue to some extent, and for all I know yours may too, but even them it is a concern.I'd rather have very good software that does take advantage of the features my OS will support. I'm willing to do anything I can to make this happen, including annoying developers who don't care about these features or the quality of the end product.
Schol-R-LEA wrote: I've been trying to deal with a similar problem myself and I'm not sure yet how to balance the design goals with the needs of the users.
Performance is just as much a concern of the end user as it is of the developer. If the system is intolerably slow, users will avoid it; I've seen programs fail for a delay of mere seconds, when it occured too often for the users' liking. Game players are especially harsh critics; indeed, it is in games that the power of the CPU and peripherals is most heavily taxed, and even a small drop in performance can make a world of difference.Don't confuse the end users with developers. The end users will say "make the OS brilliant and innovative" while developers will say "re-invent the wheel (but make it rounder) because we already know about wheels". [...]
The end user shouldn't need to know anything about development. They are office workers, games players and accountants and don't care if the software is OOP or interpretted or pure assembly, as long as it works and supports the features they want (and it's stable).
I expect to write enough software for the OS to enable other developers to see the benefits that can be attributed to using the features of the OS. My software would also become coding examples so that they know how it's all supposed to work. I agree antagonizing developers is a poor idea - it's more like taking steam engine designers and showing them the benefits of internal combustion engines and how to use them.Schol-R-LEA wrote: Antagonizing your developers is a poor idea; or do you mean to write ]all of the applications, games, utilities, etc. for the system by yourself? Even the best OS cannot succeed without programs to run on it. Mind you, my own design sidesteps the issue to some extent, and for all I know yours may too, but even them it is a concern.
