Почему у Win32-API столько пользовательских типов?

Я новичок в API Win32, и многие новые типы начинают меня путать.

Некоторые функции принимают в качестве аргументов 1-2 ints и 3 UINTS.

Почему они не могут просто использовать ints? Что такое UINTS?

Тогда есть и другие типы:

DWORD LPCWSTR LPBOOL

Опять же, я думаю, что "примитивных" типов C будет достаточно - зачем вводить 100 новых типов?

Это была боль: WCHAR*

Мне пришлось перебирать его и push_back каждого символа в std::string, поскольку не было другого способа конвертировать его в один. Horrible.

Почему WCHAR? Зачем изобретать колесо? Они могли бы просто использовать char* вместо этого, или?

Ответ 1

API Windows был впервые создан еще в 1980-х годах, и на протяжении многих лет ему приходилось поддерживать несколько разных архитектур и компиляторов. Они перешли от однопользовательских однопроцессорных автономных систем к сетевым многопользовательским многоядерным системам безопасности. Им приходилось решать проблемы с 16-разрядными и 32-разрядными процессорами, а теперь и с 64-разрядными процессорами. Им приходилось сталкиваться с проблемами с компиляторами pre-ANSI C. Им пришлось поддерживать компиляторы С++ в ранние нестандартные времена. Им приходилось иметь дело с сегментированной памятью. Они должны были поддерживать интернационализацию до того, как существовал Юникод. Они должны были поддерживать некоторую совместимость на уровне исходного кода с MS-DOS, с OS/2 и с Mac OS. Им пришлось запускать несколько поколений чипов Intel, PowerPC и MIPS, Alpha и ARM. Тот же базовый API используется на настольных компьютерах, на серверах, на мобильных телефонах и во встроенных системах.

Еще в 1980-х годах C считался языком высокого уровня (да, действительно!), и многие люди считали его хорошей формой использовать абстрактные типы, а не просто указывать все как примитивные int, char, или void *. Назад, когда у нас не было IntelliSense, инфо-роутов и кодовых браузеров, онлайн-документации и т.п., Такие подсказки были полезны, и это упростило перенос кода между разными компиляторами и разными языками программирования.

Да, это ужасный беспорядок, но это не значит, что они сделали что-то неправильно.

Ответ 2

У Win32 на самом деле очень мало примитивных типов. То, что вы смотрите, это десятилетия застроенных #defines и typedefs и венгерской нотации. Потому что было так мало типов, и мало или вообще нет разработчиков intellisense дали себе "подсказки" относительно того, что конкретно должен был делать определенный тип.

Например, нет логического типа, но существует "псевдониженное" представление целого числа, которое сообщает вам, что определенная переменная должна рассматриваться как логическая. Взгляните на содержимое WinDef.h, чтобы узнать, что я имею в виду.

Вы можете посмотреть здесь: http://msdn.microsoft.com/en-us/library/aa383751(VS.85).aspx заглядывать на настоящую вершину айсберга. Например, обратите внимание, как HANDLE является базовым typedef для каждого другого объекта, который является "дескриптором" для объекта Windows. Конечно, HANDLE определяется где-то еще как примитивный тип.

Ответ 3

Мой коллега сказал бы: "Нет проблемы, которая не может быть решена (обфускация?) на уровень косвенности". В WIN32 вы будете иметь дело с WCHAR, UINT и т.д., И вы привыкнете к этому. Вам не придется беспокоиться, когда вы развертываете ту DLL, с которой базовый тип компилируется WCHAR или UNIT, - он будет "просто работать".

Лучше всего прочитать часть документации, чтобы привыкнуть к ней. Особенно в поддержку Wide char (WCHAR и т.д.). Там хорошее определение в MSDN для WCHAR.

Ответ 4

UINT - целое число без знака. Если значение параметра не будет/не может быть отрицательным, имеет смысл указать unsigned. LPCWSTR - это указатель на массив const char, а WCHAR * - не const.

Вероятно, вы должны скомпилировать свое приложение для UNICODE при работе с широкими символами или использовать процедуру преобразования для преобразования из узкого в широкий.
http://msdn.microsoft.com/en-us/library/dd319072%28VS.85%29.aspx

http://msdn.microsoft.com/en-us/library/dd374083%28v=VS.85%29.aspx