Ver la versión completa : Packer sencillo para Wiz
Esta mañana me he levantado con un problemilla, estaba desarrollando un programa que incluye imágenes, fuentes ttf y otros ficheros de soporte, no son ficheros grandes, pero si muchos, y me molesta depender de el usuario para que instale estos ficheros, además dependo de que el usuario los ponga en el sitio correcto, si no mi aplicación debe fallar y mostrar un mensaje de error por pantalla de forma amigable, como todos sabemos la consola no es visible para un usuario normal (se podría decir que USBSerial es una herramienta estrictamente de desarrolladores)
No he encontrado ningún packer que "junte" ficheros (compresores si, como el clásico upx) así que me he programado el mio.
Es un código sencillo y bastante cutre, pero espero que a alguien le vaya bien, espero mejorarlo mas adelante, sobretodo por el grave problema de memoria que tenemos en estos dispositivos, 64mb se acaban con 4 texturas.
Lo he subido a google code y se llama wizpacker (http://code.google.com/p/wizpacker/) espero que os resulte útil
Por lo que he visto genera un fichero C con los datos de un archivo. Eso está bien para pocos datos como backgrounds o iconos, y de hecho se ha usado en varios programas así.
Para varios ficheros, se puede usar el formato .tar que está soportado en el firmware. Al menos lo estaba en GP2X. De esta manera, se puede "instalar" el programa desde un script de comandos, crear directorios, etc.
Para empaquetar un directorio:
tar -cf archivo.tar *
Para desempaquetarlo:
tar -xf archivo.tar
Para varios ficheros, se puede usar el formato .tar que está soportado en el firmware. Al menos lo estaba en GP2X. De esta manera, se puede "instalar" el programa desde un script de comandos, crear directorios, etc.
creo que el se refiere mas a una libreria tipo fpg o wad, para poder programar, no he entendido bien tu ejemplo del tar, que tiene que ver con lo que pregunta.
Aiken
creo que el se refiere mas a una libreria tipo fpg o wad, para poder programar
Aiken
Si, cierto cierto, un packer sería mas bien un compresor que descomprime el binario en memoria y lo ejecuta, mi intención es otra, upx ya va muy bien para eso, mi idea era que el programa con todas sus dependencias fueran un solo fichero, el código es una cutrez, sería mucho mas elegante si almacenara esos datos en el heap para luego poder liberarlos tras el volcado a fichero, pero para eso debería alterar el binario tras su compilación o usar un script del linker... por ahora es mucho trabajo, además desconozco las minucias del formato ELF-arm, seguramente varíe algo del elfx86
Tampoco tengo claro si sería posible alojar datos en el heap directamente de la imagen del binario para luego pescarlas como si fueran variables tal cual (con punteros forzados a direcciones conocidas)
Me refería más a la fase de instalación del programa, que se puede crear un mini-instalador en un script. Es una alternativa, aunque ya veo que lo que se busca es acceder a los ficheros del pak desde el programa. Aún así, los .tar creo que tienen un formato sencillo de interpretar.
se podría alterar el binario, creando una nueva sección SHT_NULL según http://www.skyfree.org/linux/references/ELF_Format.pdf esa sección es ignorada en tiempo de carga, pero podría usarse como bloque para almacenar datos y luego usar sh_name para guardar puntero al nombre del fichero asociado en la tabla strings... si le sumamos compresión eficiente, como bzip2 o similar, podremos abrirlo desde código, cargar los datos, descomprimir, guardar en /tmp y liberar el espacio usado en heap, no perdemos memoria, ganamos espacio en disco y evitamos problemas
Me pondré a ello!
Solo me corroe una duda... el binario queda bloqueado mientras se ejecuta?, creo recordar que si, si haces un open a argv[0] no te deja abrirlo... jummm
< - >
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char * argv[])
{
int desc = open(argv[0], O_RDONLY);
if ( -1 == desc )
{
printf("Ouch! can't open myself\n");
return EXIT_FAILURE;
}
close(desc);
return EXIT_SUCCESS;
}
Comprobado, se puede
He leido rápido el hilo y no se si es lo que comentas, pero, porque no te creas un programilla simple, que concatene los ficheros, cree una cabecera con offsets a los ficheros, y después lo montas como un sitema de archiovs virtual? Es decir que tú a tu manager de ficheros en tu programa le dices, cargame imagen/periquin.jpg. Y el sistema se encarga de cargar en memoria y ofrecer el stream a quien lo necesite, ya sea un manager de texturas, un documetno que contiene la imagen, etc...
Un saludo,
HexDump.
notbad si, algo así pretendo, pero no quiero que sea un fichero aparte, para eso ya están los pak o los wad, mi idea es incrustarlo en el binario .gpe, para crear programas autocontenidos, simulando lo que hacen el MacOSX con los programas o el fatELF con los binarios de varios sistemas
notbad si, algo así pretendo, pero no quiero que sea un fichero aparte, para eso ya están los pak o los wad, mi idea es incrustarlo en el binario .gpe, para crear programas autocontenidos, simulando lo que hacen el MacOSX con los programas o el fatELF con los binarios de varios sistemas
pues eso lo que habia era un programita que lo unico que hacia era convertirte los archivos de imagenes en archivos .h
Aiken
Sacaré el polvo a un viejo código que tengo en ensamblador http://blog.binarycell.org/2010/01/gnulinux-virii-sample.html aunque esta vez en C y con un fin mucho mas interesante
Pero MacOSX no hace eso, en Mac un programa es una carpeta normal y corriente que contiene un fichero info.plist, y el sistema lo detecta y lo interpreta como aplicación.
El problema de incrustarlo en el binario es la ram..
Supongo que si el usuario puede copiar un archivo, podrá copiar dos, el ejecutable y el archivo de datos (tar, pak, zip, lo que sea). Había una librería muy chula llamada physfs o algo así, que hacía precisamente lo de montar dentro del programa (no en el sistema operativo) un sistema de ficheros virtual con uno o varios archivos tar, zip..
pues eso lo que habia era un programita que lo unico que hacia era convertirte los archivos de imagenes en archivos .h
Aiken
Eso es justo lo que hace mi packer, echale un vistazo al código http://code.google.com/p/wizpacker/
< - >
Pero MacOSX no hace eso, en Mac un programa es una carpeta normal y corriente que contiene un fichero info.plist, y el sistema lo detecta y lo interpreta como aplicación.
El problema de incrustarlo en el binario es la ram..
Supongo que si el usuario puede copiar un archivo, podrá copiar dos, el ejecutable y el archivo de datos (tar, pak, zip, lo que sea). Había una librería muy chula llamada physfs o algo así, que hacía precisamente lo de montar dentro del programa (no en el sistema operativo) un sistema de ficheros virtual con uno o varios archivos tar, zip..
Claro, en mac está soportado por el sistema, pero no en la wiz, por eso creo que incrustarlo en el binario es la mejor opción, de ahí el generador de .h's
En cuanto al problema de ram, no es tal si se usa una sección del ELF que no sea cargable, como el .NOTES por ejemplo, que se mantiene en el binario, pero no en la copia en RAM, eso nos da un lugar donde guardar los datos sin ocupar ram, voy a seguir por ese camino a ver que veo
< - >
Segunda versión
http://code.google.com/p/wizpacker/source/browse/#svn/trunk/test2
He dejado el test anterior en el proyecto (el que generaba los .h)
Este es un poco mejor, altera el fichero binario y añade los ficheros, luego se puede desempaquetar con una simple llamada:
int main(int argc, char * argv [])
{
char *fullPathFilename = unpackFile(argv[0], "testfile.bin");
if ( NULL != fullPathFilename )
{
printf("Result: '%s'\n", fullPathFilename);
free(fullPathFilename);
return EXIT_SUCCESS;
}
printf("Unable to unpack file\n");
return EXIT_FAILURE;
}
Todavía es algo chapucero, ya que no usa las posibilidades de ELF para almacenar datos no ejecutables, pero al menos este test2 ya no ocupa espacio en RAM ni afecta al tiempo de carga del binario.
A ver si alguien lo prueba :)
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.