My point is this: 1.these language IDs are in the WINE header files. They are not in the MingW or MS SDK header files. If you are building with WineLib and WineGCC and the Wine header files, then these IDs will be defined and it will work. But if you are building with MingW or MS SDK (e.g. building a dll or exe on windows for testing), it wont work because of compiler errors. Basicly, we add code that says "if the resource compiler can find a definition for these "non-standard" (acording to the wine header files) language IDs, it will use them. If not, it wont pull in those header files.
For someone building wine, they would get the resources. For someone building on Win32 with MingW, they wouldnt get the resources unless they added the definitions somewhere (AFAIK windows doesnt know about those language IDs or those languages anyway)
IMO, any compiler claiming to compile win32 programs and providing header files and libraries for the win32 API should be defining WIN32, regardless of what executable format it spits out at the end. I have at least one piece of code that uses #ifdef WIN32 //win32 specific code including calls to win32 API #else //other code #endif