Visualizza post

Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.


Post - Syxtem

Pagine: [1] 2 3 ... 5
1
PC Hacking / Re:Estrarre script da gioco Z-machine
« il: Gennaio 26, 2011, 18:37:45 »
Non so se ti serve ancora, comunque di programmi automatici per la decompilazione di avventure scritte in Inform ce ne sono parecchi. Personalmente non ne ho mai usato nemmeno uno (e non so quanto siano affidabili per garantire anche una successiva ricompilazione) ma sono abbastanza fiducioso che, se ti servono solo per copiare il testo del gioco, possano fare al caso tuo.
Tra le tante pagine, io comincerei prima da questa: http://www.darkweb.com/~benrg/if-decompilers/
In particolare fai attenzione, perchè nonostante su Wikipedia ci sia scritto che il gioco è per Z-Machine, sono quasi sicuro che il gioco non sia compilato in Z-Code, ma bensì in Glulx (che ne è in qualche modo una sua evoluzione). Al limite fai qualche tentativo.

Altri link di tool analoghi che potrebbero esserti utili:
http://www.ifarchive.org/indexes/if-archiveXinfocomXtoolsXztools.html (una raccolta di tool piuttosto famosa, che contiene anche un disassemblatore)
http://www.inform-fiction.org/zmachine/zcode.html (altra pagina con alcuni disassemblatori)

Ah ricordati anche che se si tratta di Glulx, molto probabilmente sarà accorpato in file Blorb, che sono una specie di ZIP per intenderci... ci sono alcuni tool che permettono di accedervi in maniera automatica, mentre altri richiederanno il file GLX già estratto. Comunque anche gli estrattori per Blorb si dovrebbero trovare abbastanza facilmente su internet.

2
Rom Hacking / Voglio capirci qualcosa di più...
« il: Luglio 10, 2007, 13:31:37 »
Per quanto mi riguarda l'asm dello Z80 è uno dei più facili in assoluto. Innanzitutto è di tipo CISC (e questo non può che farmi molto piacere) e poi segue molto da vicino quello per architetture x86 (pur in maniera MOLTO più semplificata), che io tratto con maggiore frequenza.
Poi, ovviamente, non è necessario sapere il c per sapere l'assembly (altrimenti il primo compilatore c come avrebbero fatto a scriverlo?). Invece, è abbastanza utile avere qualche nozione di assembly quando si programma con linguaggi di un certo livello. Questo per motivi di ottimizzazione, di stesura del codice etc.
C'è da dire cmq che in genere il c ha diverse analogie rispetto al corrispettivo codice assembly (per lo meno con l'asm di tipo CISC) per cui io spesso e volentieri cerco di convertire mentalmente il codice da asm a c (dato che che in quest'ultimo linguaggio tutto diventa molto più "accessibile"). Tempo fa avevo pure scritto una specie di pseudo-guida che trattava in maniera relativamente approfondita l'assembly x86 e quello per lo Z80 (con elencate le differenze tra quel tipo di asm e quello nei processori del gameboy). Alla fine era una specie di traduzione/rielaborazione di alcuni documenti che avevo trovato in giro sulle varie architetture però c'era anche un esempio (secondo me carino) su una rom GB per imparare un po' a capire quel tipo di asm (si trattava proprio di un esercizio di reversing). Purtroppo con lo spostamento del sito ad un nuovo dominio ancora non ho avuto la voglia di spostare tutto il materiale e rimetterlo online.

Per capire i puntatori, il C non serve... o almeno... non serve per capire come modificare i puntatori in una rom. Questo per un semplice motivo.
Fai conto di considerare un puntatore come una specie di freccia. Le informazioni interessanti di questo pseudo-vettore sono il punto di applicazione (il punto di partenza), la lunghezza di questo vettore e la fine di questa freccia (ossia il punto di arrivo).
Codice: [Seleziona]
  Partenza                 (Lunghezza)                  Arrivo
         -------------------------------------------------->
In un linguaggio di programmazione viene considerato esclusivamente il punto d'arrivo (perchè è l'unica cosa che serve per far andare il programma), per altro in maniera piuttosto implicita. Alla fine poi il punto di arrivo è calcolato come la somma dell'indirizzo di partenza con la lunghezza, ma tutto ciò viene fatto in maniera completamente trasparente. Tieni conto che poi in altri linguaggi, tipo Java, i puntatori manco esistono come tipo di dato e sono totalmente impliciti nel linguaggio.
Quello che invece più probabilmente interessa a te è conoscere gli altri due parametri. Il punto di partenza non ha un vincolo preciso. Può essere determinato dalle specifiche della rom o può essere stabilito all'interno del codice stesso. La lunghezza in genere invece è sempre espressa da qualche parte all'interno della rom. È ovvio poi che, sapendo il punto di arrivo e la lunghezza è possibile risalire al punto di partenza e non ho intenzione di scrivere come "modificare" i puntatori anche perchè il tuo problema hai detto che è "capirli". Una volta capiti avrai tutto il tempo per fare le dovute prove e sbatterci la testa sopra.
Quello che ho scritto sopra è in pratica l'implementazione pratica di un puntatore (astraendo tutto ad offset e byte).
Se ti può essere più semplice capirlo come concetto puoi pensare ai puntatori come un array informatico (spero tu sappia cos'è... in caso contrario leggilo sulla guida che ti sei stampato). [Infatti in c è possibile anche dichiarare dei puntatori e poi utilizzarli direttamente e nello stesso modo degli array, tanto per far capire che i due concetti non sono poi così distanti.]
Ecco, fai conto la tua variabile array si chiami "memoria" e la variabile "index" sia appunto l'indice di questo array. Si ha una cosa di questo tipo: memoria[index]
Beh, questo index è in pratica un puntatore a tutti gli effetti. Se ci rifletti un po' su riuscirai a cogliere l'analogia.
È ovvio che tutto quello che ho scritto è un po' sintesi di tutto il concetto e vengono fatte anche alcune approssimazioni che nemmeno ho esplicitato (ma mica volevo scrivere una guida... volevo solo rispondere ad un post), ma in linea di massima tutto dovrebbe essere corretto. Poi magari in alcune guide si adottano ulteriori semplificazioni (con esempi) ed è ancora più chiaro, ma qua io ho cercato di mantenere un certo rigore tra concetto in sè ed implementazione dello stesso (in maniera volendo un po' alternativa, così da vedere se in questo modo è più chiaro).

Per i font a larghezza variabile è inutile scrivere qualcosa in un topic. Ti rimando alle guide specifiche e ti consiglio di appoggiarti a qualche tutorial e a 2-3 esempi pratici.

Per quanto riguarda le compressioni invece... non c'è una regola per "capirle". Sono algoritmi. Li leggi e cerchi di capire perchè funzionano (magari facendoti un debug mentale o su un foglio di carta con qualche esempio). Ad esempio la compressione huffman mi pare piuttosto semplice da capire perchè riesce a comprimere. L'unica difficoltà lì è capire i concetti fondamentali dell'informatica, come gli alberi e com'è sfruttato l'albero in quel particolare algoritmo.

Infine, per rispondere a "Già che ci siamo: libri sull'ASM da reperire?", se sei abbastanza pazzo puoi cercare "The Art of Assembly" che è un tomo gigante da centinaia di pagine, rigorosamente in inglese e rigorosamente su asm x86. Ma in quella bibbia viene sviscerato quasi tutto quello che può essere interessante riguardo all'assembly x86 e all'asm in generale, con consigli, riflessioni ed osservazioni, esempi a palate ed anche una guida che ti insegna ad usare il compilatore MASM, che rimane forse il miglior compilatore assembly x86 sulla piazza. È uscita anche la versione per compilare asm x64, ma quello ancora non l'ho provato.

3
Rom Hacking / Sito interessante
« il: Maggio 14, 2007, 20:54:01 »
Beh, è veramente tanto tempo che non scrivo qua qualcosina... un po' perchè ho meno tempo (o preferisco dedicarlo ad altre cose), un po' perchè noi (UST) abbiamo un forum personale e più o meno badiamo principalmente solo a quello.
Ciononostante mi è capitato tra le mani un sitarello che forse potrebbe piacere ai più smanettoni tra voi che pasticciate con le rom (a me, che in genere preferisco i giochi PC, interessa meno).
Il sito in questione è: http://datacrystal.org/ e contiene diverse informazioni riguardo ad alcuni giochi memorizzati. Tanto per fare qualche esempio... per il gioco Soul Blazer (SNES) viene fornita la TBL, per Pokemon Trading Card (GBC) viene fornita la struttura del mappaggio della ram. E per ogni gioco vengono fornite informazioni interne come "tipo di cartuccia", "dimensione SRAM", "Codice Licenza", "Checksum"...
Tutte queste informazioni sono molto comode per chiunque voglia provare a fare qualche hacking o qualche trainer... o anche traduzioni.
Inoltre per alcuni giochi vengono elencati i vari hack e traduzioni amatoriali che sono già state realizzate. Ad esempio per Tales of Phantasia viene citato anche il gruppo
|GeO|, mentz, Vash e Evrain per quanto riguarda la traduzione italiana.
Non so... forse lo conoscevate già da tempo... però se non è così vi consiglio di darci un'occhiata. Secondo me la struttura da loro usata è veramente intuitiva (e riesce ad essere allo stesso tempo completa e flessibile).
Magari potreste anche provare a partecipare al loro progetto fornendogli tbl, appunti, programmi ed altro materiale che voi avete e che manca ancora su quel sito.
Sarebbe carino se diventasse un sistema sfruttato da tutti (e soprattutto specifico per quei dettagli più tecnici che a volte si tende a considerare meno da altre parti).
Ciao  :saluto:  

4
Off Topic / Tanti Auguri Syxtem
« il: Gennaio 02, 2006, 17:53:31 »
Vi ringrazio e, anche se un po' in ritardo... buon anno  :lol:  

5
Rom Hacking / Traduzione Golden Axe
« il: Dicembre 26, 2005, 12:02:05 »
Per le rom del megadrive c'è il SEGATOOL (la controparte dello SnesTool)
È facilmente reperibile in rete... ad esempio qui

6
Off Topic / Windows 98
« il: Dicembre 08, 2005, 17:37:08 »
No... invece il mio prof di Fondamenti di Informatica 1 l'ho trovato abbastanza windowsiano. Usa Powerpoint, internet explorer, chiramente lavora quindi sotto windows e raramente durante le sue lezioni ha menzionato Linux (come del resto il discorso tra sistemi operativi).
Poi nei computer ci stanno tutti e due... e ognuno usa quello che gli pare.

7
Off Topic / Windows 98
« il: Dicembre 08, 2005, 08:27:16 »
Citazione
giusto GeO forse sei l'unico che se dico "Windows è un buon sistema operativo, dipende tutto dall'uso che ne fai dei due sistemi" non cercherebbe di uccidermi :P
Forse a parte Ntoskrnl e specialmente Quake2 che di sicuro ti direbbe piuttosto di abbandonare il kernel linux verso un freebsd  :D
Comunque... sarà anche vero che ognuno dei due sistemi ha vantaggi e svantaggi riconosciuti, ma secondo è anche vero che linux induce al fanatismo.
Cavoli... non si può andare in facoltà, portandosi il portatile, con venti cd dietro... e ognuno di essi è una distribuzione linux diversa. E questo tizio non c'aveva manco un gioco in quei CD. Nemmeno un disco musicale...
Boh... cose dell'altro mondo.
Queste cose per windows non esistono (anche se personalmente mi piacerebbe avere tutte le versioni del DOS4/GW, ma putroppo tutte sono ormai introvabili).  :D

8
Rom Hacking / Traduzioni Neogeo
« il: Ottobre 27, 2005, 19:21:39 »
Citazione
inoltre le difficoltà tecniche che ti puoi trovare davanti se stai facendo una traduzione NeoGeo possono essere tante (sopratutto se sono criptate, algoritmo di xor talmente incasinato che non voglio neanche toccare ._.)
Fai una bella cosa allora, se hai tempo... fai una bella analisi dell'algoritmo di checksum che c'è nella rom di Rage of The Dragons. Secondo me sarebbe una cosa piuttosto interessante.

9
Collaborazioni / [psx] Rpg Maker Us Ntsc
« il: Settembre 03, 2005, 06:33:34 »
La tua richiesta è abbastanza scarna.
Prendendo spunto dall'esperienza personale e ipotizzando tu stia parlando di RpgMaker2K, suppongo si tratti del formato xyz.
In questo caso il compressore che ti serve ce l'hai già nell'editor, e forse anche il decompressore.

10
Filo Diretto / Sezioni Di Clomax Dominion
« il: Luglio 29, 2005, 06:54:11 »
Per quello non è indispensabile ricorrere al java (che oltre a richiedere una JVM è abbastanza lento da caricare e da eseguire), ma può essere sufficiente anche il javascript.
Linko un file con qualche esempio...
Su www.javafile.com ne trovate altri, ma secondo me questi sono i più efficaci.
Dentro ci sono 3 file: 2 in javascript (foldermenu e menubrand) e 1 in DHTML e javascript (slideinmenu).
Per me il più efficiente rimane il foldermenù. Qui è stato implementato al click del mouse, ma poco ci vuole per poterlo adattare al solo passaggio del mouse (e risparmiarsi quindi qualche click).

11
Off Topic / Xkè Il Mondo Delle Traduzioni Sta Morendo?
« il: Luglio 15, 2005, 08:33:17 »
Mah.... secondo me non è così.
Che i traduttori possano essere pochi, può anche essere vero... e sicuramente un sacco di traduttori "che sapevano dove mettere le mani da soli" hanno cambiato hobby.
Ma non credo che i giochi diventino sempre più difficili da modificare. Anzi... secondo me è proprio vero il contrario.
Specialmente in ambito PC (nel quale mi sono, per così dire, specializzato) troviamo sempre più spesso TXT coi dialoghi (TXT!!!!), il più delle volte in archivi che non sono altro che ZIP a cui hanno cambiato l'estensione... oppure utilizzando altri archivi più o meno conosciuti, ma sempre realizzati da terze parti, di cui spesso è possibile trovare una soluzione cercando per la rete.
Tempo fa le cose erano molto più ostiche. Basta prendere praticamente qualsiasi gioco datato più di 10 anni fa, per trovarsi di fronte ad archivi di archivi, di file criptati e/o compressi, in un formato che conoscono solo loro (che hanno fatto il gioco) o che funziona in modo assurdo, con puntatori di puntatori su puntatori che puntano ad altri puntatori. Inoltre spesso si ha a che fare con formati assolutamente non standard... ma questo non vale solo per file testuali (altrimenti mi ripeterei), ma anche per l'audio, i filmati e le immagini.
Diciamo che quasi qualsiasi gioco abbastanza vecchio, nasconde in sè una discreta sfida. La stessa cosa non si può dire per giochi recenti. Faccio un nome... Vampire The Masquerade. Lo so che è già in italiano, ma è un discorso di principio. Se date un'occhiata ai suoi file, noterete che si tratta di file txt contenuti in ZIP rinominati (anche i file di configurazione). E allora il divertimento così dove sta?
Io non sono molto informato nelle altre piattaforme, ma credo che il discorso sia simile. O comunque non credo che i giochi stiano diventando più complicati da modificare. Al limite posso credere che stiano rimanendo sulla stessa soglia di difficoltà. È ovvio che poi ci può essere la classica eccezione che viene classificata mitologicamente "inviolabile", ma qui si sta considerando l'andazzo generale.
L'unica cosa, per quanto riguarda le console, per cui forse può essere complicato ora più che prima è semplicemente che le console cambiano. Quindi la difficoltà non è tanto data dalla complicatezza di un gioco, ma dal fatto che usa un sistema che ancora non è conosciuto... ma questo è un discorso che vale per qualsiasi console. Scommetto che anche per le rom N64 a suo tempo spuntarono fuori lo stesso tipo di considerazioni.
Per quanto riguarda il reverse engineering invece... quello fondamentalmente è sempre uguale. In questo caso però si parla più di "abitudine" alle cose, che è ciò che rende più semplice o meno un caso di reversing dall'altro.
Fondamentalmente richiede le stesse abilità tecniche, ma non è sempre facile passare da un assembly ad un altro. Vuoi perchè cambiano le istruzioni e il loro comportamento, vuoi perchè cambia proprio il tipo di assembly (CISC/RISC), vuoi perchè i giochi, per fare prima una cosa che vedevi sempre realizzata con alcune istruzioni, ora utilizzano tutta un'altra serie di istruzioni che ti confonde un po' le idee.
Come ho detto non è niente di insormontabile... basta abituarcisi e diventa una cosa normalissima, ma già passare dal assembly di un programma Windows, a quello di un programma DOS non è una cosa semplicissima. Sia perchè ci sono meno API da sfruttare (e più Interrupt da controllare), sia perchè ogni cosa che è stata ottimizzata e semplificata in Windows, di là non è più così. Come si può vedere, stesso assembly, stesso processore ed un ambiente già diverso dove muoversi. Il reversing è stato e sarà sempre così... ed è necessario che rimanga così, per poter garantire la stessa flessibilità ad ogni condizione.
Secondo me il periodo non è felicissimo perchè è svanito da una parte l'entusiasmo di nuovi elementi che si affacciavano a questo "mondo"... dall'altra è diminuita la volontà e la serietà degli stessi. Se ne può concludere una "crisi demografica", dove quelli che ci sono già dopo un po' cambiano hobby e siccome non c'è abbastanza gente nuova, il numero totale diviene sempre minore. Cambiano hobby perchè è una cosa naturale. Alcuni rinunciano, altri non vi si riconoscono più in quel mondo. Altri trovano cose più congeniali per loro (ad esempio... uno che nelle traduzioni si è solo interessato al rom hacking puro, è difficile che vi rimanga incollato per sempre. A furia di risolvere sempre lo stesso tipo di "problematiche" si stufa. O si trova sempre una nuova idea da dover tentare di realizzare in un gioco o il tutto diventa persino noioso).
Altri ancora, che facevano traduzioni per loro stessi, hanno capito che per loro stessi possono fare benissimo tutta un'altra serie di cose, che magari dà loro più soddisfazione e forse gli è pure più utile.
Forse è diminuita la "moda" di tradurre (non credo la pubblicità, visto che adesso le patch si trovano pure nelle riviste e quindi sicuramente queste cose le conoscono più persone che prima)... o forse è diminuita la magia.

12
Off Topic / Acquisire Video Da Webcam In Backgroung
« il: Luglio 09, 2005, 21:41:37 »
Beh, considerando che esistono pure dei virus che lo fanno, qualche programma esisterà sicuramente. Purtroppo adesso come adesso non ne conosco che rimangano solo in systray.  :unsure:
Cmq, se la "vittima" non è molto esperta di PC, in teoria basterebbe mettere in "Nascondi Automaticamente" la barra di Windows, ridurre ad icona il programma e, al limite, spegnere pure il monitor del PC.

13
L'angolo della modestia / Translhextion .NET (nuova versione)
« il: Giugno 02, 2005, 12:13:57 »
Il guaio non è tanto come infilarci le note, ma come farle rimanere memorizzate. È ovvio che non possono venire memorizzate insieme al programma che si edita. Le soluzioni quindi sono due:
1) Creare un file esterno (tipo di progetto) per ogni file che si va ad editare, in cui memorizzare varie informazioni (al di là delle note) che possono essere molto interessanti e carine (come segnalibri a particolari offset, TBL da caricare automaticamente, impostazioni predefinite per un particolare file aperto, la posizione dell'offset in cui ci si trovava prima che si chiudesse il prog, e altre cose).
[es. IDA (che però supporta anche la gestione da un unico database)]
2) La seconda soluzione è memorizzare in un unico database (magari memorizzato nella stessa cartella dell'applicazione), tutte le informazioni sopra citate... quindi memorizzando anche il percorso del file che si sta modificando.
[es. ACDSee]
Entrambe possiedono vantaggi e svantaggi. Con la prima soluzione sicuramente c'è una maggiore flessibilità, visto che diventa possibile passarsi anche i file di progetto, e quindi usufruire anche di queste informazioni extra. C'è da dire che però in questo modo, da ogni file su cui si lavora viene generato un nuovo file (che probabilmente non sarà molto grosso in termini di dimensione) e quindi c'è la tendenza a "inquinare" il proprio PC con questi file.
La seconda scelta è sicuramente più "elegante" a prima vista, perchè non crea altri file sparsi per il PC, ma è più complessa da gestire. Inoltre diventa praticamente impossibile scambiarsi le informazioni memorizzate in questo modo (a meno di sostituire il proprio database con l'altro, in cui saranno memorizzate anche informazioni che non ci interessano e sicuramente ci impedirà di usufruire delle nostre informazioni che noi avevamo memorizzato.). Un'alternativa a questo metodo è quella di creare un'utilità che permetta di creare un file (tipo di patch) apposito per i dati relativi al file che si sta modificando. E ovviamente anche una funzione per caricare nel proprio database i dati nuovi contenuti in questo file.
Forse questa è la soluzione ottimale, che permetterebbe sicuramente di usufruire dei benefici di un file di progetto, senza essere troppo invadente (conservando tutto in un unico file che teoricamente non dovrebbe diventare troppo grande, data la natura delle informazioni da memorizzare), ma conservando allo stesso tempo una certa flessibilità. L'unico svantaggio è che si tratta della soluzione più complicata da implementare, e che richiede una certa analisi di ciò che si vuole memorizzare e come... Anche solo la scelta di limitare lo spazio per le note ad un numero di caratteri massimo o di lasciare illimitato lo spazio può presentare stravolgimenti di implementazione, dovendo abbandonare l'idea di un classico database per esempio, con un organizzazione sequenziale dei dati. In questo secondo caso ad esempio può diventare comodo l'utilizzo di un secondo file di indice, in cui vengono memorizzati i puntatori per i dati relativi ad ogni file. È ovvio che ad ogni modifica delle informazioni per ogni file (variando la lunghezza dello spazio occupato) diventa necessario anche ricalcolare tutti i puntatori relativi ai dati memorizzati dopo quelli del file che si è modificato.
Come si può notare (e questa è stata un analisi a freddo... possono benissimo esserci molte altre problematiche) i problemi da gestire ci sono e non sono nemmeno pochi. Poi sta a te decidere quanto ti vuoi impegnare per questa cosa o se, capito il mazzo che c'è da farsi, rinunciare a questa opportunità.
Se si decide di supportare la gestione di queste informazioni extra, consiglio comunque di comprimere i file (o il file) in qualche modo, per guadagnare spazio. Una compressione Zip usando la Zlib va benissimo (ed è gratuita). Al massimo gli dici di cambiare l'estensione con una più personalizzata.
Comunque decidi te.

14
L'angolo della modestia / Translhextion .NET (nuova versione)
« il: Maggio 21, 2005, 16:47:10 »
Citazione
Per farvi un esempio pensate quanto sarebbe semplice tradurre roms di cui si conoscono i formati di compressione perche' ben documentati o di cui addirittura si hanno i sorgenti originali, in cui basta editare i testi e ricompilare il tutto. Quante rom tradotte avremmo???
Personalmente io mi sentirei molto meno invogliato a tenere d'occhio questo "mondo". Insomma, se le cose sono già pronte si perde tutta la magia e tutto il divertimento. No... la cosa deve nascondere le sue insidie e le sue sorprese, altrimenti non c'è nemmeno gusto. Io mi annoierei a trovare solamente e subito un txt da tradurre e non comincerei nemmeno col progetto. E credo che ogni traduttore (o rom hacker, come lo chiamate voi, se volete proprio fare una distinzione) che abbia cominciato questo passatempo per sfida, la pensi come me.
Ed è anche per questo spirito di sfida che alcuni (o forse anche perchè è la moda del momento) si sono imparati uno o più linguaggi assembly. Perchè oltrepassando questa frontiera, la sfida diventa maggiore (e quindi più eccitante, stimolante, divertente ed appagante).
Esistono numerosi hack fatti ad alcune funzionalità di Windows, visto che non è opensource... ma non perchè è un tentativo di attaccare microsoft, ma proprio perchè si tratta di spirito di sfida. Linux ha tanti bei lati positivi, ma non può appagare nello stesso modo quello spirito di sfida che una persona può trovare in un sistema "chiuso e nascosto".
Dal mio punto di vista, Gemini ha tutti i diritti di pubblicare la sua applicazione compilata (anche se io, visto che si tratta di un progetto nuovo che non ha riferimenti con altri programmi, lo chiamerei con un altro nome). Ci possono essere un sacco di motivi validi per cui può decidere di non rilasciare i sorgenti. Il primo tra tutti (ed il più banale) è che siccome l'applicazione è sua, decide lui... anche se si trattasse di sfizio personale. Oppure siccome l'applicazione è sua, vuole che "rimanga sua", senza che altri ci mettano le mani senza che lui lo sappia. O ancora... può darsi che non sia fierissimo del codice che ha scritto (magari non è stilisticamente perfetto o si tratta di un cattivo codice) e che quindi preferisca tenere nascosta la cosa preferendo rilasciare solo un'applicazione che funziona lo stesso, invece dei sorgenti (che avrebbero rubato altro tempo per la messa a punto). Oppure si tratta di egoismo personale... o chissà cos'altro.
Di qualunque ragione si tratti, sono tutte legittime e io non mi sento di condannare questa scelta.
Inoltre non credo che si tratti di strani algoritmi o di codice particolare per cui sia veramente importante avere il sorgente a portata di mano. Secondo me una persona in grado di capire il codice di quel sorgente è una persona che saprebbe già rifarlo. Non credo tanto alla scusa del "guardare i sorgenti per imparare come fare". I sorgenti sono utili solo quando uno ha già un'idea di come sviluppare l'applicazione. Tanto per fare un esempio, basta prendere i sorgenti di alcuni programmi come Snes9x o EmulePlus. Una persona fa fatica a capirci se non ha anche altre basi. Nel caso di questo editor esadecimale io sono convinto che nel momento uno abbia le basi per capire il codice sorgente, sia già in grado in riproporlo in gran parte.
E se proprio una parte del programma rimane un mistero, o si chiede direttamente all'autore (che in genere, se l'applicazione non è commerciale, è sempre ben disposto nel dare dritte che possano aiutare gli altri), oppure si lavora di asm  ;)


Edit by yuumeikai: Ma io parlo al vento?

15
L'angolo della modestia / Translhextion .NET (nuova versione)
« il: Maggio 08, 2005, 21:41:31 »
A questo punto direi che sarebbe più sensato caricare una TBL invece della tabella ascii... tanto per quella basta caricare comunque una Table.
E cmq secondo me diventerebbe necessaria un'opzione per visualizzare solo una delle due tbl. Averne due in alcune occasioni può dare fastidio.

Pagine: [1] 2 3 ... 5