🚀 go-pugleaf

In article <668@dcl-cs.UUCP>, stephen@dcl-cs.UUCP (Stephen J. Muir) writes:
> The answer is quite simple.  Put all the date conversion routines in the
> Kernel code with system calls for user programs to fetch the date in string
> form or whatever.  This way, local changes can be made to the kernel code to
> accommodate variations, without having to recompile any programs.  Of course,
> this kernel code would run in user mode (where possible) so as not to lock-ou
> other processes.

You don't really mean to put date conversion routines into the *kernel*,
do you? The 4.2 kernel already is much too big, too unwieldy, and has
far too many system calls. I am sure it is the same for other modern
versions of UN*X (in fact I know it for certain).

The point at which country specific routines are combined with a program
is usually linking. This means that you don't have to re-compile, but
just to re-link your binaries if you want to generate them for a different
country. It seems to me that what you really want is run-time linking
for the functionality and shared locked libraries for the efficiency,
an addition to UN*X that is even justified on grounds other than
this national date format silliness.

If you want to see what generality in terms of character sets, dates,
string comparisons, &c does to an operating system, just look at the
M*cIntosh ROM. It is a mess, and not much is gained by it, since most
(American) programs don't use the facilities provided by the operating
system anyhow (i.e. string comparisons are, of course, done numerically).

						Thomas.