https://bugs.winehq.org/show_bug.cgi?id=39297
--- Comment #23 from Hin-Tak Leung htl10@users.sourceforge.net --- (In reply to Austin English from comment #22)
The content of attachment 52399 [details] has been deleted for the following reason:
Reverse engineered from Windows dll
FWIW, nls files are not dll's - it does not seem to be officially documented, but there is an on-line description about its format, and it is basically a header plus two arrays, one for raw encoding and another for console output (they differ by just the unprintable characters below 0x20, I think ), and the reverse encoding table from unicode back to code points.
So for single-byte encodings (i.e. non-CJK), somewhat after the beginning of the file is simply an array of 512 bytes, telling you how 0-255 are mapped to unicode (UTF16). It is hardly "reverse-engineering" if you simply read 2 x 256 bytes and write it out.
The array is quite easy to spot, because for single-byte encodings, ascii's are mapped to asciis, so the alignment is just that with the higher byte of an UTF16 padded with nulls.
wine's source never documented how wine/loader/l_intl.nls was made, but if the logic of making it (i.e. writing it) is implemented and extended into reading such files also, you can close this bug as duplicate of -
bug 39298 - "kernel32 does not support custom nls installation".
since wine being capable of reading nls files, would also mean that one can install code page 708 as an add-on.