Предполагается, что с файлом я работаю строго через API, в основном вот эта:
GetPrivateProfileInt function

Дополнительно могу сообщить:
сам файл в кодировке Unicode, т.е. W-функции.
Файл предполагается быть большим, т.е. м.б. даже раз в несколько больше чем 64кБ.
Проблем со скоростью чтения через API ну лично я никак не наблюдаю (сейчас пока чуть больше 64кБ).
Предполагается использование ini-конструкций для "языковой поддержки". Здесь заранее прошу не критиковать, почему не ресурсы, БД, реестр и прочая "более современная" хрень. Мне так удобно. Плюс это удобно для пользователя, если он будет переводить (даже без интерфейса переводчика). Типа скопировал английские файлы, открыл и редактируешь.

На ряде форумов видел что не может быть больше 64кБ.

На Microsoft никакого подтверждения этому не нашел.

Единственное:
GetPrivateProfileSection function
nSize [in]
The size of the buffer pointed to by the lpReturnedString parameter, in characters. The maximum profile section size is 32,767 characters.
Но это размер отдельной секции (который точно не будет больше), а не всего файла и скорее намекает на отсутствие каких-либо ограничений на размер самого файла.

Так как все-таки обстоят с этим дела?

hclubmk тынц
Видел я ее.
Не убедительно:
Applies to
Microsoft Windows 3.0 Standard Edition
Microsoft Windows 3.1 Standard Edition
Microsoft Windows 3.11 Standard Edition
Microsoft Windows for Workgroups 3.1
Microsoft Windows for Workgroups 3.11
Речь идет об XP-Win10 (Win2003-2012R2).
Dima TКак где-то читал INI в виндовсе обернут средствами работы с реестром. Для ускорения. Причем точно могу сказать что обернут нездорово, в плане записи, сам пользуюсь ини и натыкался в Win7 (в XP работало) на случаи что некоторые записи не пишутся, т.е. прога пишет (даже читает для проверки), закрывается, запускается и читает то что было до записи. Это был капец.
На проблемы такие не нарывался (с некоторых пор отказался от настроек в реестре в пользу INI), возможно у тебя где-то была ошибка в логике кода или в чем-то еще, у меня все работает и из XP, и из 7 и из 8 (что касается настроек проги), не готов это обсуждать. В любом случае, чтение русского напр. перевода при загрузке из ini -это чистая статика.

А именно API работают да, очень быстро, проверено.
написав свой парсер я как раз рискую нарваться на тормоза при указанных размерах, поэтому нет.
Что касается комментариев "only for compatibility with 16-bit Windows-based applications",
плевать я думаю на это можно.
Там еще написано "Applications should store initialization information in the registry",
а с т.зрения .Net, на котором сейчас пишу походу и реестр - старье, типа все надо в XML хранить и т.п. И что, каждый раз следовать моде?
bazileДмитрий77, по моему проще и надежнее проверить самостоятельно. Сгенерируй файл с секциями размером больше 32 Кб, файл общим размером больше 64 Кб и т.д. и убедись что чтение/запись происходит без ошибок.
Ну скажем так (не очень чистый эксперимент), я скопировал первую секцию раз 150 (в начало файла), и получилось что-то около 300кб, при этом проблем с чтением нижних секций не возникло, и потери скорости чтения тоже не возникло.
Так что пока проблем не вижу.
Проверял на современном компе с Win8.1, для чистоты надо б проверить на P-III на Win2003 (есть у меня такая штука в работе), но я думаю вряд ли что-то изменилось с этими API с тех пор.


По поводу "с секциями размером больше 32 Кб" -да нет и не будет у меня таких, и кстати говорится про ограничение секции в "32,767 characters", т.е. символов, а не байт, а у меня сейчас в сумме по всем секциям файл 64кб (в Юникоде!!!, который W, а не который UTF8 в .Net , да какая разница), и вряд ли будет больше чем в 2-3 раза по окончании "работ".

Пока тупо двигаюсь в заданном направлении.

Изопропилдумаешь API функции - небожители писали?
Нет конечно, но у меня вряд ли получится лучше. Особенно если этот парсер писать через .Net классы, которые в большинстве своем "курица лапой".

ИзопропилMayton'у идею можно подкинуть
Чтоб он типа оптимальный парсер на C++ за меня написал?
И тема эта на C++-форуме будет жеваться недели 2.
Время где?
Итак уже отупел вторую неделю только и пишу, на каждую сраную Label типа


И это еще хорошо, когда сраная label, а если текст составленный из кусков...
и конца не видно, первый exe-шник только поверхностно до половины м.б. допилил, до MsgBox-ов еще даже не дошел.
Не, а как иначе, этот механизм - это рутина еще та, будь то БД или что-то другое.
Интеллекта в этой работе -нуль. А времени уйдет - до фига.
Причем на выходе из реально законченного то будет только "русский", который не понятно нужен ли, при текущей то ситуации (его даже и не стоит втыкать в основную сборку).

Самое паршивое - это именно аккуратная рутинная имплементация самого механизма загрузки языка (в силу объема тупой работы), интерфейс переводчика, про который говорил если уж захочу - это то как раз наверно фигня -два редактируемых столбика рядом загрузить, ну там на секции разбить для понятности.

ЗимарглТипа велосипед.

https://msdn.microsoft.com/ru-ru/library/y99d1cd3(v=vs.110).aspx
Уже обсуждали в соотв. теме.
Этот стандартный метод не дает возможности пользователю самостоятельно создавать произвольный языковой профиль из шаблона и править его.
Причем следует заметить что рутины "для каждой кнопки" там никак не меньше и при этом эту рутину надо делать заново для каждого нового языка.