Detecting keyboard layout used on Windows

[code lang="c"]//Pseudo C/C# code:

int localeId = GetKeyboardLayout(0);

// The low word contains a Language Identifier for the input language
// and the high word contains a device handle to the physical layout
// of the keyboard.
localeId &= 0xffff; // mask off high word to get the locale
// identifier

switch (localeId) {
0x040c:
0x080c:
0x1009:
useAzertyMapping();
default:
useQwertyMapping();
}
[/code]

Relevant links:
GetKeyboardLayout()
Default Input Locales
Locale IDs assigned by Microsoft

UCHAR and SByte

Recently I have to do a lot of C# programming. It’s a quite ok language to be honest. I need to wrap certain unsafe code in C# code. Some of this unsafe code uses the old type UCHAR, which is defined as an unsigned char type with a limit of 0 to 255, inclusive. Perusing some websites to look for some marshaling information I actually find people recommending using the sbyte data type for this. This datatype (sbyte, SByte or the full System.SByte) is a signed 8-bit integer type. This means it has a range of -128 to 127. This is also extensively documented in the sbyte C# reference. So I am left wondering how well these programmers actually do understand their data types.

strmode() function declaration buglet fixed

Was converting files to proper ANSI C function declarations and a user tripped over the fact that old 4.4 BSD’s function prototype of strmode() had int as a parameter, whereas it has been mode_t for a long, long time (read 1994 at least).

This broke buildworld of course.

Also asked Dima Dorfman to fix this for FreeBSD (broken in 4.x, 5.x, and 6.x).

NetBSD is fixed (as was to be expected to be honest).

And OpenBSD made the parameter int everywhere with a XXX comment in the strmode.c file that it should be mode_t actually. Weird.

Code cleanliness…

Sid is quite the powerful LL(1) parser, but my god, do its internals need some major clean-up and overhaul. Functions with 14 arguments?! That’s just asking for trouble.

Going to do the entire de-OSSG routine right now… Slow progress. At least the -y flag to tcc has been committed and now we need to get the apis correctly build and installed.

We’re getting there…