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

[Steven Davidson]

Hola Xonly,

xonly wrote:
> Hola bueno, antes de nada dar las gracias a Steven por ayudarme y
> hacer que este mensaje sea posible, y felicitar a todos por hacer que
> esto mejore, ya que es de lo mejorcito que he visto por la red.
> 

De nada, por mi parte. No quisiera hablar en nombre de todos los socios
y socias, pero el éxito y mejoramiento de esta lista con su foro y
nuestra página con sus cursos, artículos, y demás colaboraciones son
gracias a todos vosotros quienes colaboran en la medida que podáis.

> Ahora ya en materia, resulta que me encanta complicarme la vida, y a
> pesar que me encanta el mundo de la programación desde hace mucho
> tiempo (época del Spectrum y el Amstrad) resulta que no he podido
> dedicarme demasiado a este mundo, y cada día tengo más ganas de
> dedicarme en sério, pero resulta que como decía antes me encanta
> romperme la cabeza en tonterías, y por ello me cuesta tanto avanzar.
> 

Es bueno cuestionar los temas que estés tratando y las metodologías,
pero no deberías dejar que te consuman hasta tal punto de que no puedas
avanzar. Si se trata de cuestiones cruciales, entonces obviamente son
dudas principales que deben ser aclaradas y resueltas, pero si son
minucias, opino que eso es bastante problemático.

> CUESTIÓN: porqué resulta que si hago un simple ejemplo que hay para
> empezar (ese que te trae el Dev-C++ de "Hola mundo") resulta que
> ocupa nadamenos que 474.990 bytes, resulta que según esto jamás sería
> posible escribir algo con el amstrad o con el spectrum (los primeros
> tenían solo 4k) que pasa es que vamos para atrás en lugar de hacia
> delante, pues parece ser que sí.
> 

En primer lugar, esta cantidad total del fichero ejecutable proviene del
trato de las bibliotecas de ANSI C++ (no las de ANSI C), en concreto son
las STL: Bibliotecas de Plantillas Estándares. Dependiendo de los
conocimientos que tengas, esto debería ser evidente si ya sabes acerca
del tema de las plantillas (templates, en inglés). En breve, las STL no
existen como bibliotecas en su idea popular como puede ocurrir con las
bibliotecas de ANSI C. Las STL no son biblitoecas compiladas, sino que
son ficheros fuentes; o sea, código escrito en C++. Las bibliotecas de
ANSI C sí son compiladas; o sea, son ficheros con código binario para
una plataforma específica.

En segundo lugar, nadie usaría C/C++ para Spectrum ni Amstrad. En
cualquier caso, usaríamos Sinclair Basic para Spectrum y si mal no
recuerdo Basic para Amstrad. Lo que ambos sí aceptaban, como muchos
ordenadores (computadoras), era ensamblador.

Si quieres un tamaño menor, entonces puedes usar las funciones de ANSI 
C, especialmente bajo MS-Windows, ya que existe una DLL con todas estas 
funciones y algunas más.

Por último, tienes que definir muy bien a lo que te refieres con "ir 
para atrás" e "ir hacia delante". Ten presente que muchas decisiones no 
solamente acerca de este tema pero cualesquier otros en la informática 
se basa en la evolución. El propósito de las STL - de ANSI C++ - es el 
de ofrecer facilidad de extensibilidad y establecer una base común para 
cualesquier proyectos que tengas entre manos. El problema es que al 
ofrecer tal extensibilidad a través de plantillas, introducimos más 
código fuente "engordando" nuestro propio código fuente. Esto obviamente 
implica que nuestro fichero ejecutable también crece, porque tiene más 
código fuente que nosotros hemos escrito.

> El caso es que yo ya tenía mis sospechas pero al ir empezando
> aprovechando estas mini vacaciones que me ha dado el trabajo, he
> decidido intentarlo una vez más, y resulta que a las primeras de
> cambio me he quedado altamente indignado, además de por supuesto
> tener que tragarte numerosa documentación toda en inglés, que ya nos
> valdría a algún españolito o latinoamericano el hacer alguna

Depende de qué documentación te refieres. Tenemos en nuestra página 
versiones en español, obviamente, acerca de las funciones de ANSI C: 
http://c.conclase.net/librerias/index.php  No tenemos todavía la 
documentación completa de las STL, pero sí tenemos aquellas bibliotecas 
que tengan que ver con los canales o flujos (streams, en inglés). Puedes 
consultar el apéndice D de nuestro curso de C++: 
http://c.conclase.net/curso/index.php?cap=903

> traducción que otra, y sobre todo me he mosqueado muchísimo al ver
> que el tema este de código abierto, es todo un poco menos que una
> gran "farsa" al final todo está en librerías ocultas que no dejan ver
> ni la mitad de código que realmente va debajo de cada #include que

Esto depende de cuál compilador y bibliotecas estés mirando. Como ya he 
dicho antes, las STL son código fuente, por lo que puedes mirar el 
código sin problemas. Si quieres el código fuente de las bibliotecas 
estándares de ANSI C o incluso del propio compilador, puedes descargar 
los códigos fuentes de ciertos compiladores, como los de GNU.

Sin embargo, tener el código fuente de las bibliotecas y de las 
herramientas que usas no influye demasiado en lo que uno intenta hacer, 
al menos que estés planeando en modificar las bibliotecas o las 
herramientas como el compilador, el enlazador, el depurador, etc.. Si 
pretendes ser un desarrollador de estas herramientas, entonces es normal 
que quieras obtener sus códigos fuentes; si no, no veo que sea 
tremendamente necesario tener o no tener sus fuentes.

> hacemos, así que decidí ponerme manos a la obra con "buscar otros
> métodos" encontrandome gratamente con una actualización de los
> "viejos asm" con un super programa, el WinASM que tiene muy muy buena
> pinta, de hecho el mismo ejemplo me ha dejado el ficherito del "hola
> que tal" en tan solo 2.886 bytes al que después de alguna
> optimización lo he llegado a conseguir dejar en 2.560 bytes, todo un
> buen resultado comparandolo con el anterior ejemplo, el caso es que
> en este caso el WinASM, adolece de los mismos principios que el
> compilador de C, que tiene "librerías con funciones ocultas".
> 

Desconozco el funcionamiento interno de WinASM, pero nuevamente, no veo 
el gran problema de que no tengas a mano los códigos fuentes de las 
bibliotecas. En general, esto no es necesario para el funcionamiento de 
las herramientas ni de los programas que quieras hacer. Al menos que 
tengas serias inquietudes por las bibliotecas, no veo que esto sea causa 
de gran preocupación.

> Para mejorar esto, y en vista de que ningún debugger me resulta
> satisfactorio, no me ha quedado más remedio que utilizar el Visual
> Studio (al que me negaba tremendamente debido a que no me gusta
> precisamente su política de "ocultar" para que me puedas pagar....),
> pero sin duda, es un debugger genial, en el que al ir dándole a la
> ejecución paso a paso, te va mostrando las repetidas llamadas a
> funciones y más funciones, en el que creo haber contado hasta 26
> ficheros abiertos, y por supuesto casi todos ellos inentendible e
> indescifrable para alguien que esta "medio empezando", a pesar de
> ello, me he dado cuenta de que por lo visto, la salida de datos en
> pantalla, la toma como si fuera un fichero, en la que como "stdout"
> tiene la "consola", aunque luego también es super patético y ridículo
> la conversión que realiza a una supuesta tabla de caracteres UTF que
> luego encima lo pone fatal, pues resulta que en el ejemplo
> precisamente del Dev-C++ resulta que en lugar de escribir "¡Hola!
> mundo!" escribe "ÍHola Mundo" confundiendo el signo "¡" por una i
> mayúscula con acento, totalmente patético...

Eso es porque las funciones de <cstdio> no usa UTF, sino ASCII. Además, 
los caracteres como los acentos, las eñes, y otros más, no forman parte 
del estándar de ASCII de 7 bits. Ha habido extensiones, los cuales 
aceptan estos caracteres, pero me temo que no forma parte de ASCII en sí.

> 
> Vamos a ver señores de windows, que lo único que necesito es:
> 
> - activar el modo consola
> - escribir literalmete("Hola que tal")
> - devolver el control sacando otro mensaje de "pulsa una tecla porque
> he terminado"
> - cerrar la consola
> 
> para todo esto se necesitan 474.990 bytes, que no, que no me lo
> trago, que así no se llega a ningún sitio, que no me puedo permitir
> comprarme ordenadores todos los días, ni megas ni discos duros...
> 

Bueno, básicamente he explicado anteriormente la razón del tamaño.

> En fin que si alguien me puede ayudar (preferiblemente en español)
> pues encantado, sino pues seguiré peleandome con los debugger y con
> "los supuestos servicios o APIs" o historias que no me gustaria
> aprender, pero que veo que no me quedará más remedio.
> 

No estoy seguro si sigues hablando de averiguar el "código interno" de 
las funciones. Si es así, vuelvo a repetir que esto no es necesario para 
programar. Uno usa las herramientas que tiene a su disposición para 
poder llevar a cabo sus propios proyectos. Si las cuestionas al detalle, 
es posible que entiendas algo más acerca de cómo fueron creadas, pero a 
su vez perderás todo ese tiempo que podrías haber invertido en 
desarrollar tu proyecto.

> NOTA: el linux es otra batalla abandonada que tengo, puede que retome
> esta historia si es que veo que el seguir con las libreríass estas no
> tiene buen final, pero me temo, que debido a que los supuestos "open
> source" no son más de lo mismo que lo que estoy viendo en programas
> de "código abierto" como con Dev-C++ o MinGW, que son las librerías
> que "intento destripar" sin ningún éxito por cierto, y al final me he
> tenido que "vender al enemigo". No me gusta tener que practicar esta
> forma de ingeniería inversa, pero veo que no queda más remedio.

La verdad es que no veo esta gran necesidad de "ingeniería inversa". Las 
bibliotecas son una herramienta más, que las usamos para nuestros fines.

Sinceramente, tengo que comentar que pareces algo obsesionado con el 
hecho de que no sepas exactamente al detalle lo que hacen las funciones. 
Puedo entender si tienes curiosidad, pero por lo que he leído, parece 
más obsesión que el propio deseo de conocimiento.

También veo que no entiendes fundamentalmente la idea del "código 
abierto". El hecho de ofrecer el código fuente por parte de los 
desarrolladores no es para aquellos que quieran aprender a programar. 
Ofrecer el código fuente era para que aquellos otros desarrolladores con 
otros sistemas y plataformas puedan adaptar el programa o la biblioteca 
a su plataforma y posiblemente a sus necesidades. En otras palabras, la 
idea del código abierto fundamentalmente fue concebida por y para 
desarrolladores. Los demás que somos usuarios nos interesa muy poco, si 
funciona claro está.

Mi consejo es que aprendas a programar primero, si es lo que te 
interesa. Cuando tengas bastante experiencia en programar, ya te puedes 
dedicar a otros temas y afrontarlos, como puede ser todo este tema del 
funcionamiento interno de las bibliotecas, porque entonces estarás más 
preparado que ahora.


En fin, espero que haya aclarado algunos temas que mencionas.

Steven