[Q]: setlocale() в OS/2
[A]: Alex Samorukov (2:463/598)
Итак, в стандарте ANSI определена ф-ия setlocale, которая позволяет
устанавливать локаль процесса. Мне это потребовалось заюзать в одной из своих
софтинок. Оказалось это несколько не так просто сделать как мне думалось
Итак, варианты LIBC:
EMXLIBC
"C" Locale only, сразу отпадает.
Innotek LIBC:
setlocale() есть и работает. При этом используется системная OS2 локаль, локаль C существует и работает. Особых проблем при использовании не выявлено.
Watcom LIBC
аналогично
VAC 3.06 RT:
В принципе работает. Правда, какой-то косяк с наследованием в DLL, а также
системная локаль HЕ ЮЗАЕТСЯ. Для функционирования надо прописать LOCPATH к
папке с lcl файлами (внутри это dll). Причём было замечено, что lcl файлы от
других версий VAC`а не подходят. Короче, не самая удобная вещь, но жить можно.
Синтаксис вызова такой:
setlocale(LC_ALL,“ru_ru.ibm-866”). Это подразумевает что в %locpath% у вас есть
директория ru_ru и в ней лежит ibm-866.loc. В случае неуспеха остаётся на “c”
локали. Лучше юзать static linking или инитить локаль как в DLL так и в
основном коде.
OS/2 LIBC (ACP2):
Как известно, в OS/2 входит свой LIBC который большая часть OS/2 програм и
юзает. В нём, в частности есть setlocale().
И она даже работает Более того, она не требует LCL файлов юзая внутреннюю
OS/2 подсистему. И не имеет проблем с dll (локаль наследуется). Hо имеет
другую, крайне неприятную особенность - “c” locale такой на самом деле не
является
т.е.
setlocale(LC_ALL, “c”)
printf(“out: A=%c locale in exe=%s\n\n”,
toupper(0xa0),setlocale(LC_CTYPE,NULL));
даст A=A вместо положенных A=a в C locale. Что является ну совсем нехорошо и для моей задачи не подошло. Хотя, если не считать этой баги всё остальное работает хорошо.