[C con Clase] ¿Alguien sabe destripar librerías...?

[Programante]

xonly escribió:
> P> #define Mensaje "Hola mundo"
> P> #include <fcntl.h>
> P> int main() {
> P>  write (1, Mensaje, sizeof(Mensaje) - 1);
> P>  return 0;
> P> }
> P> En código asm, 20 líneas
> P> 16.091 bytes de programa
> P> #include <stdio.h>
> P> int main() {
> P>  printf("Hola mundo");
> P>  return 0;
> P> }
> P> 15.473 bytes
> P> Mucho menos de lo que tú mencionas. No estamos incluyendo templates y 
> P> las llamadas
>
> ciertamente con otras historias que estoy probando, también he mejorado, con la compilación del WinASM me da 2.560 bytes y el código en asm es:
> Include Console.Inc
>
>   

> Con el código en C, ciertamente tengo lo mismo que tu puesto en principio, pero ahora he probado a ir incluyendo en el fichero todos los códigos de la librería que he ido "recortando" y se me ha quedado en 3.584 bytes, aunque no pongo aquí el cógido porque sería morirse, pero como decía he cogido cachos creo que de unos 26 ficheros diferentes, y aún así parece que quedan todavía más ficheros, pues tengo que importar ahora como unas 10 librerías.
>   
Olvídate de C++ y limítate al C. Estarás mucho más cerca de la 
plataforma nativa. Posiblemente incluya también muchas cabeceras, pero 
no se traducen en código. En cambio las templates sí generan código que 
se tiene que incluir con tu programa. Y si nos ponemos quisquillosos, 
las clases también "cuestan más" porque pasamos el puntero this en cada 
llamada, y estamos haciendo indirecciones para cada miembro...

> P> Pero no hemos acabado, si eliminamos la información de símbolos y 
> P> reposicionamiento (necesaria si queremos que se pueda cargar en otra 
> P> dirección de memoria virtual), ambos casos bajan a 5.632 bytes.
> P> Y buena parte de ese espacio se debe a "redondeos" de las secciones del 
> P> ejecutable, para que sea múltiplo del tamaño de página, etc. Podría 
> P> comprimirse más. Sin ir más lejos, podríamos eliminar los últimos 322 bytes.
> P> Pero tienes que tener en cuenta la sobrecarga que se añáde al principio. 
> P> Así, los primeros 1024 bytes del ejecutable no contienen nada del programa.
>
> hey me interesa muchísimo saber eso de los 1024 bytes y demás, ¿dónde puedo encontrar más información?
>   
El Portable Executable es el formato que usa windows para los 
ejecutables de 32 bits. Me temo que -como siempre- la mejor 
documentación está en inglés.

> P> Sólo el stub de msdos y la definición de lñas secciones. 
> P> Además el compilador añade antes de tu programa algo más de código para 
> P> procesar los argumentos del programa, establecer el acceso a la consola...
> P> En todo caso es un tamaño fijo, que en programas que no sean un "hola 
> P> mundo" es superado por el código del propio programa.
> P> Si te empeñas en seguir reduciendo el tamaño, podemos usar un compresor, 
> P> como upx, bajando a 3584 bytes.
>
> no es por ir reduciendo tamaño, sino más bien por eliminar operaciones inútiles que mete las librerías sin que yo las necesite ni le haya dicho que haga eso (como la puñetera conversión que me hace en visual)
>   
Dudo que de la haga el visual. Es más probable que sean de las APIs de 
windows de Ascii a Unicode. Inicialmente windows usaba ascii en todas 
sus APIs (Windows 95, 98 y ME), pero luego pasó a usar Unicode (más 
exactamente, usa UTF-16) para no tener problemas con los múltiples 
idiomas. Ahora las API nativas usan unicode, pero sigue manteniendo las 
versiones ascii, que normalmente lo que hacen es transformar el texto a 
unicode y llamar a la función en unicode. cuando llamas a una función 
como CreateFile, en realidad estás llamando a *CreateFileW* (Unicode) o 
*CreateFileA* (ANSI) (las cabeceras suelen escogerlo en función de si 
tienes definido UNICODE o no).

> P> Puedes usar nasm.
>
> lo de usar esto de WinASM, es que me ha impresionado que exista un IDE para ASM el caso es que funciona, pero no me ha gustado que tenga que importar lo de kernel32.lib y lo de masm32.lib, pues estos ficeros están en binario y no en ASM, sabes si el NASM tiene esos ficheros en ASM u otro lenguaje entendible...
>   
Esas son librerías de importación, para que sepan enlazar con 
kernel32.dll Las funciones que exporta una librería las puedes mirar con 
dumpbin.exe /exports <nombre librería> (búscalo entre los binarios de 
visual studio)

> P> No lo confunde. Se debe a la diferencia de charsets entre MS-DOS y 
> P> Windows. En todo caso, esas conversiones y "funciones y funciones" deben 
> P> estar en alguna librería del sistema, no en tu programa. La consola 
> P> utiliza el mismo charset que los antiguos programas de ms-dos. Redirige 
> P> la salida a un archivo y verás cómo puedes leer los caracteres bien en 
> P> Windows.
>
> no sé como se puede redirigir una salida de msdos a una ventana de windows que no sea a través de consola...,
programa.exe > archivo_de_texto.txt
Y abres el archivo_de_texto.txt con el bloc de notas, por ejemplo.

>  pero entiendo perfectamente tu razonamiento, por eso tal vez en visual haga esa conversión, pero la verdad es que si no metemos caracteres raros, no me hace falta convertir nada, pues coincide las letras normales con cualquier tipo de "charset", o no?
>   
Sólo coinciden en ASCII 7. Como ves "hola mundo" no te lo cambia, pero 
las tildes, eñes, apertura de exclamaciones e interrogaciones, etc. sí 
varía. Puedes hacer que se impriman bien en la ventana de ms-dos si 
introduces en tu programa los códigos (que desde windows no tendrían 
sentido) que se transforman a esos.

> P> Las prioridades han cambiado. Antes lo importante era que el programa 
> P> ocupase poco, debiendo los programadores adaptar los programas a la 
> P> máquina. Ahora es al revés, la prioridad está en que los programadores 
> P> puedan programar de forma rápida, fácil y segura, aunque ello conlleve 
> P> un ligero aumento del espacio. Es más importante el programador que la 
> P> máquina, gracias a la Ley de Moore.
>
> el caso es que toda ley tiene una excepción, y no creo que esta ley de moore tienda a infinito, sobre todo porque si los clientes no pueden pagar a la industria de miniaturización con las épocas de recesión que quedan por venir, por mucha "posibilidad que haya" si no hay dinero, no hay miniaturización, y si no se puede aprovechar mejor los recursos que se tienen, habrá que esperar mejor a los extraterrestres que vengan a salvarnos....
>
> muchas gracias por tus comentarios, se vé que tienes conocimientos internos de como va un ejecutable por dentro, me interesaría saber más como dice la peli de STARSHIP TROOPERS
¿Pero merece más pagar al programador muchas más horas para que haga un 
programa 300 bytes menor o merece más la pena comprar un poco más de 
memoria ram? A mi también me gusta hacer programas eficientes, pero hay 
ciertas cosas que es mejor dejárselas al compilador.