Самое простое, построить COM-сервер как .exe-файл со встроенным config.fpw со строкой CODEPAGE=866. Тогда никакой настройки вызывающего потока Windows не требуется. Но создание множества потоков с экземплярами такого сервера потребует слишком много оперативной памяти. А COM-сервер как .DLL-файл использует CODEPAGE от вызывающего потока Windows, в котором CODEPAGE=1251 по умолчанию. Какими средствами можно изменить это умолчание в среде .NET (или Win32 API) ???
Опасаюсь, что такой вопрос на форуме .NET вызовет недоумение по поводу фоксовской CPCURRENT(). А нужен такой COM-сервер, чтобы в досовских таблицах использовать индексы по полям с двоичным текстом (с кодами символов от 0 до 255). При CPCURRENT()==1251 не работают SEEK и SET RELATION.

Dima T, спасибо. но это не про мой вопрос. Неловко быть невежливым, но повторю выборочно строки моего вопроса
Rostislav D. KudryashovСамое простое, построить COM-сервер как .exe-файл со встроенным config.fpw со строкой CODEPAGE=866. Тогда никакой настройки вызывающего потока Windows не требуется. ... А COM-сервер как .DLL-файл использует CODEPAGE от вызывающего потока Windows, в котором CODEPAGE=1251 по умолчанию.Как видишь, я начал именно с того, что ты советуешь попробовать. Но .exe-файл не годится (причина в 1-м сообщении), а .dll-файл не реагирует на config.fpw.
И разумеется, настройка потока Windows никак не исполнима средствами Фокса. Только через Win32 API или в среде .NET. Но пока не могу найти.

Dima T, ты это серьёзно? Dima TА что мешает включить config.fpw в DLL-проект ? Что тебе дважды помешало принять к сведению RostislavСамое простое, построить COM-сервер как .exe-файл со встроенным config.fpw со строкой CODEPAGE=866 ... А COM-сервер как .DLL-файл использует CODEPAGE от вызывающего потока Windows, в котором CODEPAGE=1251 по умолчанию. Rostislav.dll-файл не реагирует на config.fpw. Похоже, ты решил забить мой вопрос обструкцией. Но, поскольку умнее тебя здесь никого нет, придётся мне на мой вопрос махнуть рукой.

Вот напал на http://msdn.microsoft.com/en-us/library/aa272906(v=vs.60).aspx
setlocale( LC_ALL, ".OCP" );
Explicitly sets the locale to the current OEM code page obtained from the operating system.
Но экземпляр сервера, создаваемый после этого из .dll-файла, всё равно сообщает, что у него CPCURRENT()==1251.
Не помогает также и дот-нетовское
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("ru-RU.866");
Thread.CurrentThread.CurrentUICulture = CultureInfo.CreateSpecificCulture("ru-RU.866");

Dima T, COM-сервер конечно на Фоксе именно ради того чтоб использовать без ограничений индексы по текстовым полям с "двоичным" текстом в досовских таблицах.
Оформление этого сервера как .exe-файла со встроенным config.fpw с CODEPAGE=866 всегда сообщает о CPCURRENT()==866, а из .dll-файла всегда получаю 1251. Создаю экземпляр класса хоть в Фоксе (с CODEPAGE=1251), хоть в программе на C# (как мне реально и надо будет) - без разницы.
Dll строю Multi-threaded, Single не годится, т.к. при использовании генерирует буферный файл SERVERNAMEr.dll (с буковкой r) - совсем не нужный.

Эта CPCURRENT()==1251 для фоксовского сервера в виде .DLL-файла забита наверно где-то в исполняющей системе Фокса. Т.к. 1251 остаётся и при построении самого сервера и последующем запуске его из фоксовой среды, запущенной с config.fpw со строкой CODEPAGE=866.
Не помогает даже тотальное задание CodePage=866 на вкладке Files в диалоге "Project Information", вызываемом из контекстного меню проекта сервера.

Dima T, насчёт потоков нет проблем. Их предполагается создавать на серверном ПК на C#. Клиенты подключаются к серверному ПК по TCP/IP. Каждому клиенту своё соединение. Была идея запускать в каждом потоке свой экземпляр фоксовского сервера - желательно in-process из DLL-файла. Но получается, что из-за индексов по полям с двоичным текстом в досовских таблицах придётся оформлять фоксовский сервер out-process в exe-файле.
Не смертельно. Несколько десятков клиентов серверный ПК потянет, надо будет больше - поставят рядом столько ПК, сколько нужно. А больше сотни клиентов не будет никогда.
Кстати, про удалённый запуск DCOM-ских DLL-серверов, например, VFPOLEDB. У Микрософта на этот случай была изобретена RDS-технология, но они грозятся, что в Win8 исключат её.

NSFuimus1, если я обратился на форум за советом, значит ли это, что я обязан просвещать и указывать на нелепые ошибки всем моим советчикам?