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

Question

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

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

• Почему они не могут просто использовать целые? Что такое УИНТС?

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

DWORD LPCWSTR LPBOOL 

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Вам, вероятно, следует скомпилировать свое приложение для 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

Answer 4

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

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