¿Por qué Win32-API tiene tantos tipos personalizados?

Question

Soy nuevo en la API de Win32 y los muchos tipos nuevos comienzan a confundirme.

Algunas funciones toman 1-2 ints y 3 UINTS como argumentos.

• ¿Por qué no pueden simplemente usar ints? ¿Qué son UINTS?

Luego, están los otros tipos:

DWORD LPCWSTR LPBOOL 

• Una vez más, creo que los tipos primitivos "C" serían suficientes - ¿por qué introducir 100 nuevos tipos?

Éste era un dolor: WCHAR*

que tenía que recorrer a través de él y push_back todos los personajes a un std :: string ya que no había otra manera de convertirlo en uno. Horrible.

• ¿Por qué WCHAR? ¿Por qué reinventar la rueda? Pudieron haber usado char* en su lugar, o?

Answer 1

La API de Windows fue creado por primera vez en la década de 1980, y ha tenido que soportar varias arquitecturas de CPU y compiladores diferentes a lo largo de los años. Pasaron de los sistemas independientes de un solo usuario de un solo usuario a los sistemas multinúcleo de seguridad multinúcleo en red. Tuvieron que solucionar problemas con los procesadores de 16 bits frente a los de 32 bits, y ahora con los procesadores de 64 bits. Tuvieron que solucionar problemas con los compiladores anteriores a ANSI C. Tenían que soportar compiladores de C++ en los primeros tiempos no estandarizados. Tuvieron que lidiar con la memoria segmentada. Debían apoyar la internacionalización antes de que existiera Unicode. Tenían que admitir compatibilidad de nivel de fuente con MS-DOS, con OS/2 y con Mac OS. Han tenido que ejecutar varias generaciones de chips Intel, y PowerPC, y MIPS, y Alpha, y ARM. La misma API básica se utiliza para sistemas de escritorio, servidor, dispositivos móviles y sistemas integrados.

En la década de 1980, C se consideraba un lenguaje de alto nivel (sí, realmente!) y muchas personas consideraron que era bueno usar tipos abstractos en lugar de simplemente especificar todo como un primitivo int, char o void *. Cuando no teníamos IntelliSense, infotips, navegadores de códigos, documentación en línea y similares, tales sugerencias de uso eran útiles, y facilitaban el código de puertos entre diferentes compiladores y diferentes lenguajes de programación.

Sí, es un lío horrible, pero eso no significa que hayan hecho algo mal.

Answer 2

Un colega mío decía: "No hay problema que no se pueda resolver (¿ofuscado?) Por un nivel de indirección". En WIN32 lidiarás con WCHAR, UINT, etc. y te acostumbrarás. No tendrá que preocuparse cuando despliegue esa DLL, que tipo básico compila WCHAR o UNIT, "simplemente funcionará".

Es mejor leer toda la documentación para acostumbrarse a ella. Especialmente en el soporte ancho de char (WCHAR, etc.). Hay un buen definition on MSDN for WCHAR.

Answer 3

UINT es un entero sin signo. Si el valor de un parámetro no será/no puede ser negativo, tiene sentido especificar unsigned. LPCWSTR es un puntero a una matriz de caracteres amplia, mientras que WCHAR * no es const.

Probablemente deberías compilar tu aplicación para UNICODE cuando trabajas con caracteres anchos, o usar una rutina de conversión para convertir de angosta a ancha.
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 en realidad tiene muy pocos tipos primitivos. Lo que estás viendo son décadas de # definiciones definidas y typedefs y notación húngara. Debido a que había muy pocos tipos y pocos o ningún desarrollador de intellisense se dieron a sí mismos "pistas" sobre qué se suponía que debía hacer un tipo particular.

Por ejemplo, no hay un tipo booleano, pero hay una representación "con alias" de un entero que indica que se supone que una variable en particular debe tratarse como un booleano. Eche un vistazo a los contenidos de WinDef.h para ver a qué me refiero.

Puede consultar aquí: http://msdn.microsoft.com/en-us/library/aa383751(VS.85).aspx para echar un vistazo a la verdadera punta del iceberg. Por ejemplo, observe cómo HANDLE es el typedef base para cada otro objeto que es un "handle" para un objeto de Windows. Por supuesto, HANDLE se define en otro lugar como un tipo primitivo.