Regional Settings

[DennisCGc]

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

Ah, okay, thanks, I just wanted to know that ....

[Brendan]

Hi,

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.

I wouldn't say that my C library would be broken, just that it wouldn't comply with the standard.

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 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..

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?

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.

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:

Code: Select all

int WINAPI WinMain(
  HINSTANCE hInstance,
  HINSTANCE hPrevInstance,
  LPSTR m_lpCmdLine, int nCmdShow)

Instead of the standard "int main (int argc, char *argv[])". In this case it's impossible to use the standard. As my OS uses messaging (where the central part of a thread's code is a message handler), old/Unix C programs will not be appropriate in general. With a lot of work this difference might be hidden by the library, but IMHO it wouldn't be worth the effort even if it is possible.

Understand that the original C library standard was designed for single threaded programs that aren't "event driven" (e.g. the original Unix). My OS is multi-threaded and event driven. The standard is getting better, but it's changing too slowly and the old functions won't ever be removed.

I do not want people to port code to my OS without making huge changes...

Expect to create an OS without software, except for what you wrote yourself.

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.

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.

...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.

Erm... like, TCP/IP, POP3, SMTP, HTTP, ...?

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.


Cheers,

Brendan

[Solar]

Even under VisualC++, I can write up

Code: Select all

#include <stdio.h>

int main()
{
    printf("Hello World!\n");
    return 0;
}

No matter how well-meant your intentions, if a program that is compliant to the standard breaks - no matter whether because of something as "subtle" as a different time_t or as blatant as a different entry point - it's your environment that will be blamed, and justifiable so.

Yes, Microsoft wants you to use WinMain(), Microsoft Foundation Classes and the Win32API. But they do allow for plain ISO/ANSI programs to run.

I am maintaining Astyle, a source code reformatter. To be portable, it's written in plain ANSI C++. Same goes for various other tools - sox, for example, or GCC itself. Be aware how serious the impact of your decision will be. 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.

[Brendan]

Hi,

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.

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? 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.

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.

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.

My OS is designed from scratch without any consideration for current programming methods. It is the best design I can think of, without restrictions and limitations caused by compatibility or compliance with (IMHO optional) standards. 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 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)

Cheers,

Brendan

[Brendan]

Hi everyone,

A preliminary version of the database is available here (source and binary):
http://www.users.bigpond.com/sacabling/regiondb.zip

Instead of messing about with a utility to convert the source files into binary I'm using NASM macros, as this ensures simplicity

This initial version is lacking UTC offsets, time zone codes, daylight savings information, internet codes, ASCII alternatives for hard to represent UTF strings and sub-zones (states) in most files. The database does have support for historical daylight savings information, plus some other things not present in IBM's original stuff. I intend adding international telephone dialing numbers too, but haven't got around to it yet.

I haven't done any documentation yet (currently working on documentation for the source and binary formats, including full descriptions of each keyword). I don't have any code that uses the database either (working on that too)..

Thanks,

Brendan

[Pype.Clicker]

hmm ... you need to know that belgium has 3 national languages: dutch, french and german (in alphabetical order ). It seems that FRANCE.TXT could perfectly fit be/fr. Cannot tell for BE/de

[Brendan]

Hi,

hmm ... you need to know that belgium has 3 national languages: dutch, french and german (in alphabetical order ). It seems that FRANCE.TXT could perfectly fit be/fr. Cannot tell for BE/de

A 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.


Thanks,

Brendan

[Solar]

@ Brendan:

Please understand me correctly. I'm not trying to discourage you, or tell you you're doing something wrong. I just want to make sure you realize the implications of your decisions, which are significant.

Under MINGW it compiles and runs, but it creates a console window that disappears before anything can be read.

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).

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?

Someone who wants to write up a quick&dirty solution? Testing whether the compiler works, without writing up some lengthy GUI code?

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.

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.

Languages like Java go into great detail on how a GUI has to be constructed, in addition to defining a standard-in and standard-out - leaving you less design leeway, not more.

Are the standard file IO functions (fopen, fgetc, fread, etc) ANSI?

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.

If so I won't be supporting them - my OS doesn't do blocking file IO...

What keeps you from implementing both? A blocking wrapper called fopen() around your non-blocking OpenFile()?

If your asynchronous OpenFile() is useful, people will use it. If it isn't (or people don't know about it), they will use fopen(). There is any number of reasons for people to use fopen() - because it's simpler, they're used to it, they want their tool to run on other platforms too... doesn't matter. Providing fopen() betters your chances of getting software for your system, of overcoming the chicken and egg problem. And the pain for you is near neglectable, especially with ISO C being a very small standard (and virtually every other language capable of being implemented in C).

Make it easy for people to migrate to your system, and - even more important - make it easy to migrate away again (highly recomended reading, that article!). Software is the lifeblood of any OS!

My OS is designed from scratch without any consideration for current programming methods.

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?".

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).

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.

You'd be surprised how few developers can be convinced to use a better mousetrap if it's sitting right in front of them, if it means to leave the old ways behind just right now. Smoothen the path, so they can run their crufty old stuff on your OS, getting used to your superior designs one by one.

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)

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.

Again, someone will attempt to write / port a C/C++ compiler for your system. You could make his work a charm, a hell, or nigh impossible. All the while he's trying to work for you...

OK, I've fielded all I had to say. No more ranting on this subject.

[Schol-R-LEA]

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).

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.

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 never a good idea, even when there are valid design reasons for it.

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.

[DennisCGc]

To get ontopic:
Bryan, pretty good actually, but on NETHERLA.TXT remove the ADDAM and so one, we only know 24 h time.

[Brendan]

Hi,

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.

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).

For example:

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);
}

..would become:

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);
}

Replacing code with tables could be one of the most effective optimizations that a compiler can make. While it is theoretically possible with C, for the above code you'd end up with a 4 Gb table for the 32 bit "int colorCode" (instead of 32 Kb), made worse because the programmer wrote 'portable' code and doesn't know how big an "int" will be in advance.

C is also a difficult language to write compilers & interpretters for. BASIC and Pascal are much easier to parse...

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.

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.

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.

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.

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).


Cheers,

Brendan

[Schol-R-LEA]

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.

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.

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 [[...]].

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.

[

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);
}

C is also a difficult language to write compilers & interpretters for. BASIC and Pascal are much easier to parse...

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.

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.

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'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.

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).

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.

Also, I still believe that the users should be able to modify and control the system themselves, and that tools for user-level programming should be as convival and open-ended as possible. The examples of Smalltalk and the LispMs, which let every user be a programmer, are ones I still take very seriously.

[Brendan]

Hi,

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 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.


Cheers,

Brendan

[Brendan]

Hi,

I changed the database format a bit - moved the language specific string data out of the sub-zones and into the (extended) language area. It makes the binary file a lot smaller as a lot of these strings were duplicated. I also added international telephone dialling and filled out more of the actual data.

I've also done the HTML documentation for it (still no code that uses it though)

The database and online documentation is at:
http://www.users.bigpond.com/sacabling/


Thanks,

Brendan

[Brendan]

Hi,

I've added heaps of information, and changed the web site so that every file can be viewed online

Can everyone please check the file/s for the area they are in (and any area they know enough about)? Currently there's lots of information I'm missing

http://www.users.bigpond.com/sacabling/

Code that uses this database will be released next..


Thanks,

Brendan