c - una - win32 api

¿Por qué la API Win32 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 UINTS y 3 UINTS como argumentos.

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

Luego, están esos otros tipos:

DWORD LPCWSTR LPBOOL 

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

Este fue un dolor: WCHAR*

Tuve que recorrerlo y empujar a cada carácter en una cadena std :: ya que no había otra forma de convertirlo en uno. Horrible.

• ¿Por qué WCHAR ? ¿Por qué reinventar la rueda? Podrían haber usado char* lugar, o?

Answer 1

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

En la década de 1980, se consideraba que C era un lenguaje de alto nivel (¡sí, en serio!) Y mucha gente consideraba que era una buena forma de usar tipos abstractos en lugar de simplemente especificar todo como un int , char o void * primitivo. Cuando no teníamos IntelliSense, infotips, navegadores de códigos, documentación en línea, etc., tales sugerencias de uso fueron útiles, y facilitó la transferencia de códigos entre diferentes compiladores y diferentes lenguajes de programación.

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

Answer 2

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

Probablemente debería compilar su aplicación para UNICODE cuando trabaje con caracteres anchos, o use una rutina de conversión para convertir de estrecho a ancho.
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 3

Un compañero de trabajo mío diría: "No hay ningún problema que no pueda resolverse (¿ofuscar?) Por un nivel de direccionamiento indirecto". En WIN32 tratarás con WCHAR, UINT, etc. y te acostumbrarás. No tendrá que preocuparse cuando implemente esa DLL a la que se compila el tipo básico que WCHAR o UNIT - "solo funcionará".

Lo mejor es leer algo de la documentación para acostumbrarse. Especialmente en el soporte Wide char (WCHAR, etc.). Hay una buena definición en MSDN para WCHAR .

Answer 4

Win32 en realidad tiene muy pocos tipos primitivos. Lo que estás viendo es décadas de #defines y typedefs construidos y notación húngara. Debido a que había tan pocos tipos y poco o ningún desarrollador inteligente se dieron a sí mismos "pistas" sobre lo que se suponía que un tipo en particular debía hacer.

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

Puede echar un vistazo 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 sea un "identificador" de un objeto de Windows. Por supuesto, HANDLE se define en otro lugar como un tipo primitivo.