Newsgroup: it.comp.programmare.win32
Titolo: Per esperti di compilazione VC++ 6.0

Uso VC++ 6.0 con cui sto
scrivendo un giochino usando OpenGL.
Ho cercato di ridurre le dimensioni del mio eseguibile: da 256KB l'ho
portato a 64KB, eppure credo si possa ridurre ulteriormente. Ho fatto una
ricerca fra gli eseguibili più piccoli presenti nel mio computer: il
Solitario (il giochino incluso in Windows) di  è 56KB! E ce ne saranno
sicuramente dei più piccoli. Per ridurre le dimensioni ho specificato che
non volevo informazioni di debug, single-threaded, ottimizzazione dello
spazio piuttosto che delle prestazioni
ecc., ma sicuramente mi sarà sfuggita qualche altra operazione per ridurlo
al minimo.
Ho aperto (per curiosità) l'eseguibile con blocco note: ci sono almeno due
aree completamente "vuote" (saranno byte a zero). Inoltre l'eseguibile è
*esattamente* 64K (65536 B). Mi hanno detto che probabilmente il compilatore
allinea a 64K per motivi di paging, inoltre mi hanno detto che si può usare
UPX, ma mi sembra logico che ci sia un modo per ottenere codice più
ottimizzato dal puro utilizzo del compilatore.
Ho visualizzato l'exe di un giochino (Arkanoid 4000 di Alawar) e ho notato
che è completamente "compatto" e incomprensibile, mentre il mio contiene,
oltre alle suddette sfilze di byte ripetuti, cose di questo tipo:
____________________________________________________________________________
__
t empty Function not implemented    No locks available  Filename too long
Resource deadlock avoided   Result too large    Domain error    Broken pipe
Too many links  Read-only file system   Invalid seek    No space left on
device File too large  Inappropriate I/O control operation Too many open
files Too many open files in system   Invalid argument    Is a directory
Not a directory No such device  Improper link   File exists Resource device
Unknown error   Bad address Permission denied   Not enough space    Resource
temporarily unavailable    No child processes  Bad file descriptor Exec
format error   Arg list too long   No such device or address   Input/output
error  Interrupted function call   No such process No such file or directory
Operation not permitted No error    stdenvp.c   stdargv.c   a_env.c runtime
error
  TLOSS error
   SING error
    DOMAIN error
  R6028
- unable to initialize heap
    R6027
- not enough space for lowio initialization
    R6026
- not enough space for stdio initialization
    R6025
- pure virtual function call
   R6024
- not enough space for _onexit/atexit table
    R6019
- unable to open console device
    R6018
- unexpected heap error
    R6017
- unexpected multithread lock error
    R6016
- not enough space for thread data
___________________________________________________________________
Qualcuno sa illuminarmi? Grazie.
PS: la curiosità mi è venuta quando sono venuto a conoscenza della demo
".the product", una demo grafica in 64K. Visto che il mio giochino è molto
semplice, non vedo perché debba essere più di 32K...

Ciao, Marco!
Il giorno 24/05/2004 alle ore 14:56 hai scritto:
 MM> Ho cercato di ridurre le dimensioni del mio eseguibile: da 256KB l'ho
 MM> portato a 64KB, eppure credo si possa ridurre ulteriormente. Ho fatto
 MM> una ricerca fra gli eseguibili più piccoli presenti nel mio computer:
 MM> il Solitario (il giochino incluso in Windows) di  è 56KB! E ce ne
 MM> saranno sicuramente dei più piccoli. Per ridurre le dimensioni ho
Una domanda: perche' tutto cio' ?
Con hard disk da centina di gigabyte, almeno mezzo giga di memoria ram (per
non essere considerati straccioni) e schede video che impiegano piu' ram di
quanta fosse necessaria ai computer che mandarono l'uomo sulla luna, che
senso ha cercare di ridurre ai minimi termini un programma ? Capisco che tra
un programma che occupa 500 mega e uno che ne occupa 10 c'e' una bella
differenza, ma tra 64k e 56k non starei a dannarmi tanto.
 MM> Ho visualizzato l'exe di un giochino (Arkanoid 4000 di Alawar) e ho
 MM> notato che è completamente "compatto" e incomprensibile, mentre il mio
 MM> contiene, oltre alle suddette sfilze di byte ripetuti, cose di questo
 MM> tipo:
Probabilmente hanno usato un compattatore di eseguibili (come UPX che hai
citato). Di solito gli eseguibili compattati sono riconoscibili "a vista"
per avere dei segmenti con nomi che richiamano il compattatore.
 MM> Qualcuno sa illuminarmi? Grazie.
Se non vuoi usare un compattatore di eseguibili, potresti riscrivere il
programma in assembler, oppure tentare di utilizzare un altro compilatore.
Bye
-- 
Fear is the path to the Dark Side.
http://www.maccasoft.com

 Una domanda: perche' tutto cio' ?
L'unica risposta che per me ha senso, considerando che anche su un Pentium
1 con hard Disk da 1 GB la differenza di 10k di un exe e' irrisoria, e' la
partecipazione a quelle gare in cui gli sviluppatori si cimentano proprio
nella creazione di demo grafiche in pochi kb.
Me ne era capitata una veramente incredibile: in 64 kb c'era una animazione
di svariati minuti, con texture e bitmap non banali...
Questi software normalmente sono sviluppati in assembler.
Stefano "HappyMan" (Lake Maggiore - Italy)
-- 
http://www.sgr.info
Email happyman69 (at) 
despammed.com

 nella creazione di demo grafiche in pochi kb.
Infatti è quello che ho scritto nel P.S. del post originale.

, è una spamtrap
Usate zello <at> despammed <dot> com

Perfetto! Con "Multithreaded DLL" si è ridotto a 16K!
Poi ho usato UPX: 5K! Fantastico.
In realtà non sto partecipando ad una di quelle gare sulle demo di 64K
(magari avessi tempo... e anche competenze, ok!), più che altro era una mia
curiosità, cmq scaturita da quelle competizioni. Ritengo molto affascinante
il fatto che si possa racchiudere una quantità tale di informazioni in così
poco spazio.

Poi ho usato UPX: 5K! Fantastico.
Forse lo puoi abbassare con i settaggi di default per la parte dati e
codice.
-- 
sito Papero 1 (programmazione): censurato dai puzzoni di Lycos
sito Papero 2 (database):       
http://user.7host.com/papero/
sito Papero 3 (passatempi):     
http://digilander.iol.it/davidequack



Sorry mi erano sfuggite le ultime righe :-)


 In realtà non sto partecipando ad una di quelle gare sulle demo di 64K...
Però in quelle competizioni non credo sia consentito usare UPX.
Per ridurre l'EXE senza comprimere puoi iniziare a eliminare la tabella per
la rilocazione (che serve solo nelle DLL e *non* negli EXE). In secondo
luogo, modifica l'allineamento del file. Per finire puoi cercare di ridurre
al minimo la parte di caricamento DOS dall'EXE (quello che visualizza "This
program cannot run in DOS mode"). Esistono programmi che fanno tutto questo.
Scaricati "StripReloc" e poi fai una ricerca con i termini "PE Editor" .
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Però in quelle competizioni non credo sia consentito usare UPX.
Gli exepacker sono da sempre non solo consentiti ma anzi ben visti,
piuttosto sono le dll ad essere viste male.
Per ridurre ulteriormente gli exe cercare con google Libctiny e
aggesssiveoptimize.h, per non parlare di PE2COM, sfruttato spesso nelle
4kb compo.
-- 
-=[]=---iAN CooG/HokutoForce+TWT---=[]=-
La vita e` meravigliosa.  Senza saresti morto!

 Con hard disk da centina di gigabyte
Ti sei mai chiesto il perche' di tutto questo spreco di spazio? A me ad
esempio gli sprechi non piacciono.
-- 
-=[]=---iAN CooG/HokutoForce+TWT---=[]=-
We are Pentium of Borg. Division is futile. You will be approximated.

 aggesssiveoptimize.h
aggressiveoptimize.h
-- 
-=[]=---iAN CooG/HokutoForce+TWT---=[]=-
Linking error. Your mistake is now in every file.

Ringrazio tutti coloro che sono intervenuti, tutte queste cose non le sapevo
(ma in effetti non mi ero mai posto il problema).
Cmq credo che siano applicate raramente, giusto per queste competizioni,
altrimenti neanch'io vedo il senso.

 del compilatore.
[...]
Se ti puň ancora interessare, molto tempo fa questo articolo mi aveva
aiutato:
http://www.microsoft.com/msj/archive/S572.aspx
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog: 
http://www.ugidotnet.org/2082.blog

Sembra interessante, grazie del link.