[[cHackAll]]

Vamos a definir todos y cada uno de los argumentos, creo que en éste punto están todas las ideas pero algunas inconclusas o mal definidas.

Hablamos de los ResourceStrings: La utilizacion o no de éstos es el tema que tanta polémica a formado. Voy a exponer cada uno de los puntos de la forma mas clara posible refiriendome al por qué dije "GUACA" de tales y por que yo evitaré en lo posible hacer uso de los mismos.

1. "Recursos mutilados" quienes les gusta realizar aplicaciones de pocos Kb?
Posiblemente sea el argumento más refutado por Uds.; comparé un grupo de compresores, scramblers, y encriptadores; concluí que existen dos que son los mejores, el PECompact fué el mejor para ejecutables normales a grandes. y el mew, el cual utilizo para los archivos más pequeños, éste último es muy bueno y hasta comparable con el upx en aplicaciones medianas. Una de sus características es que posibilita la mutilación de los recursos.

No defiendo con ahínco esta posición pues quienes utilizan mew? quienes lo conocen? solo yo??

1.1. Inmerso en el punto está el hecho de que otros compresores como el upx se rayan al comprimir algunos ejecutables con cadenas de recursos. Para que no pase esto normalmente te dan la opción en un CheckBox que dice "Compress resources" para que el usuario decida hacer un programa (como citaba algúno): "configurable" y cuando éstos datos los ve cualquiera pues los cambia... talvez le pone insultos! yo se que arán con mi programa? si es bueno hasta dónde o que manos llegara? y eso es un tema que deja mucho que desear con respecto a la seguridad (o por lo menos con la integridad de la aplicación), pero claro que es subjetivo a la forma en que el programador plasma sus ideas. Para configurar (repito), lo correcto (creo yo) es un menú, un archivo ini, xml o datos en el registro (que tambien puede ser un hecho polémico).

2. Hablaba del WideString (unicode), una aplicación tiene cierto peso (tamaño), éste en muchos de los casos no nos interesa. Pues hablamos de PCs que antes hubiensen sido consideradas como MainFrames. Pero yo sigo con un pensamiento de ahorro; considero que una aplicacion pequeña que hace muchas cosas tiene los procedimientos bien optimizados, o en lenguaje de maquina o que simplemente interactúa de una forma adecuada con el S.O. Cuando el Güindos lee dichas variables en unicode debe llamar a la API 'UnicodeToUtf8' (claro después de usar APIs como: FindResourceEx, LoadResource, y LoadString para obtener la posicion en memoria donde se encuentra el recurso), como siempre una caja negra! parece estar bastante optimizada pero quién sabe!. Nuestro Delphi tiene su versión:

cuando uno hace lo siguiente:

Código Delphi [-]
 
uses Windows;
ResourceString
 hello = 'Hola amigos de ClubDelphi!';
begin
 MessageBox(0, PChar(hello), nil, 0);
end.

obtiene un ejecutable de 15.5 Kb. y cuando uno hace:

Código Delphi [-]
 
uses Windows;
const
 hello = 'Hola amigos de ClubDelphi!';
begin
 MessageBox(0, PChar(hello), nil, 0);
end.

obtiene un ejecutable de 8 Kb. Compruebenlo Uds. mismos!

Se preguntarán por qué? Es simple: con la segunda el Compilador genero un programa que llama directamente a la API con una direccion en memoria que contiene la cadena. Con la segunda; primero debe cargar el recurso, ésto lo hace con un procedimiento llamado 'LoadResString' que está en la unidad System. éste procedimiento genera un arbol de llamadas muy interesante:

LoadResString
FindResourceHInstance
DelayLoadResourceModule
GetModuleFileName
LoadResourceModule
GetModuleFileName
RegOpenKeyEx
ToLongPath
GetModuleHandle
GetProcAddress
GetLongPathName
lstrcpyn
FindBS
lstrcpyn
lstrcpyn
FindFirstFile
FindClose
_strlen
lstrcpyn
_strlen
lstrcpyn
RegQueryValueEx
RegCloseKey
lstrcpyn
GetLocaleInfo
lstrcpyn
LoadLibraryEx
LoadString
SetString
LStrToPChar

Y que de seguro se me fue un par! 0j0 que solo fueron llamadas, y todo el código (if, then, or, else, operadores ifs anidados) lo obvio, pues no quiero aburrirlos.

El unicode es una cosa buena, pero no muy aplicable para todos los casos al igual que esa palabrita reservada que tanto dolor de cabeza nos dá. En las primeras participaciones del hilo ví que hacían referencia a un archivo! un .txt y considero que no lo notaremos, pero qué sucede si se nos vuelve costumbre? si hacemos una aplicacion mediana a grande los mínimos retardos se sumarán y notarán. Pero bueno.. paso al último punto que a propósito es nuevo.


3. Agarré y comparé los recursos que el 'explorer.exe' tiene en la versión para eQuispe; encontré 102 cadenas de recurso (si me equivoque es porque los conté a "dedo")
y agarré el 'explorer.exe' de la versión Vista... encontré asombrado 0 (cero), recursos de cadena. Que sucedió?? por que una empresa como Microsoft decidió ya no utilizarlos en sus cadenas? tendrá que ver con aquellos usuarios perrisimos como yo? será más seguro o que?

NOTAS:
Una de las posiciones mas valederas decía: "...they can be modified without recompiling the program..." a mi no me molesta hacer Ctrl+F9! o si voy a poner algun dato que sirva
como configuración pues hago un menu, ini o xml que al final llega a ser la opcion mas "correcta"

Otro me decía "...harina de otro costal..." pues yo digo que siempre y cuando dicha harina tenga que ver con la misma familia del trigo vale la pena hecharle un 0j0.

MI conclusión con respecto al hilo: pues queda claro lo que yo pienso, al lector amante del Delphi le dejo a su criterio los argumentos adjuntos. Si Ud. piensa que el uso de éstos es el adecuado talvez tenga razón y yo sea (como que si soy) un paranoico ahorrador de bits. El unicode sirve y mucho, pero es aplicable solo en aplicaciones como el µTorrent en las que todo el mundo necesita un archivo de idiomas... y 0j0 que es un archivo adjunto, en ningun momento dejaron al usuario la posibilidad de usar un ResHacker como comentaba en otro post.

Programas utilizados para el análisis: Delphi 6 & 7SE, mew11 SE v1.2, ResHacker 3.4, upx 2.03w, Visual Estudio 2005, Güindos eQuispe & Vista Ultimate.


Saludos afectuosos amigos de Club Delphi, y lleguemos como alguien decía: lejos !!!