Ну насколько я могу судить там не все так тривиально. Чтобы добавить нормальную поддержку UTF-8 там по хорошему нужно реализовать поддержку всех остальных кодировок.

Да нет, зачем же всех? Вот как раньше ANSI была, так сделать UTF-8 вместо неё.

libiconv здесь зачем? Даже если нужны кодировки, я видел сопоставление юниксовых и виндовых кодировок, а там уж виндовыми средствами перекодировку можно доделать. Я не совсем уловил суть проблемы.

API POSIX вроде бы не такое необъятное, как WinAPI. Можно примерно представить объём работ. Коль скоро эти работы будут сделаны, MinGW проги станут 100% Юникодными. Мб, придётся чуть допилить, в любом случае, много людей скажут спасибо.

Умножайте все оценки на 20.

Меня не устраивает текущая реализация MinGW. MinGW — это инструмент портирования юниксовых программ. Все юниксовые программы нормально держат Юникод на настоящих Юниксах, потому что там UTF-8. Под MinGW, однако же, POSIX API принимают ANSI строки. Оправдывается это тем, что, мол, MinGW — это minimalistic в самом названии, а перекодировка из UTF-8 в UTF-16 — это уже не minimalistic. Хотите, мол, полной эмуляции, есть cygwin. Эта позиция меня не устраивает. Хотелось бы увидеть форк MidGW (midimalistic, соответственно), в котором всё в порядке. Просто MinGW — это сейчас единственный способ делать нормальные бинарии под Windows. Cygwin’овские слишком “инопланетные”. Вот эмуляция POSIX fork() и ptty меня, к примеру, не интересует, а UTF-8 — да. Если делать UTF-8 в MidGW, то там ещё проблема возникает, библиотека должна различать консольный хендл и неконсольный. На неконсольный нужно выводить UTF-8, а на консольный — преобразовывать его в UTF-16 и выводить через особые функции WinAPI. По–хорошему ещё нужно адекватно реагировать на ANSI.

На этапе инициализации, когда природа stdin, stdout и stderr не ясна, на них нужно попытаться вывести 0 символов, но именно через консольную процедуру вывода. Если это файл, то будет ошибка. Если консоль, то OK.
В других случаях (кроме stdin, stdout, stderr) обычно должно быть понятно сразу, файл открывается или консоль. Ну это так, к слову о том, какие проблемы могут встретиться.

API POSIX вроде бы не такое необъятное, как WinAPI. Можно примерно представить объём работ. Коль скоро эти работы будут сделаны, MinGW проги станут 100% Юникодными. Мб, придётся чуть допилить, в любом случае, много людей скажут спасибо.

Но что делать с COM интерфейсами?

Не надо пытаться объять необъятное. Сделаем сначала Win32 API, набъём руку…

Хотя именно с COM интерфейсами особых сложностей может и не случиться. Особенно если есть в наличии IDL или type library.

ни язык, ни рантайм не позволят их туда вставить.

В случае COM задачу внедрения Utf-8 API можно решить только замещением содержимого vtbl слотов оригинальных интерфейсов для ANSI функций, например в прокси-стабах, причем тут же появляется проблема с подсовыванием таких стабов, в том числе для COM интерфейсов, которые создаются не стандартным CoCreateInstance, а custom способом, как тот же Direct3D.

При этом никто не мешает модифицитовать код приложения так, что получаемые объекты будут заворачиваться в proxy. Так что никаких страшных манипуляций с vtbl не требуется.

Но что делать с COM интерфейсами? Это значительная часть API. Тот же Direct3D имеет в интерфейсах как XxxA так и XxxW функции плюс макрос для этих целей, но XxxU8 там нет, и ни язык, ни рантайм не позволят их туда вставить.

Недавно я стал программистом под Mac OS X, ее “новый” системный язык, Objective C, имеет интересную особенность. Вызов любого метода там осуществляется динамически. Компилятор преобразует сигнатуру вызываемого метода в селектор, который в рантайме ищется в аналоге vtbl. Этот подход, привнеся накладные расходы, позволил некоторые уникальные вещи - например, чужой класс можно расширить своими методами, которые станут неотличимы от первоначальных. Что-то типа написать новый метод для System.Object, который станет доступен всем, как только будет загружена assembly с его реализацией, возможно динамически.

В случае COM задачу внедрения Utf-8 API можно решить только замещением содержимого vtbl слотов оригинальных интерфейсов для ANSI функций, например в прокси-стабах, причем тут же появляется проблема с подсовыванием таких стабов, в том числе для COM интерфейсов, которые создаются не стандартным CoCreateInstance, а custom способом, как тот же Direct3D. Безнадега

до сих пор не встретил ещё ни одного неинтересного вашего поста

Нивапрос! Исправлюсь.