Newsgroup: it.comp.lang.c
Titolo: Compilare in formato binario

Ciao a tutti.
Per scrivere programmi in C utilizzo il compilatore della Borland in
ambiente Windows XP. Volevo sapere se tramite questo compilatore č
possibile compilare i programmi in formato binario e non eseguibile
(cioč in un formato direttamente leggibile dalla macchina senza le
intestazioni che vengono inserite per poter interpretare il file dai
vari SO).
Se non fosse possibile con il Borland qualcuno di voi mi sa consigliare
quale compilatore poter utilizzare?
Ciao e grazie
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Non esistono.
Certo che esistono.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Guarda qui: 
http://developerpit.com/compiler_options.html
Aggiungo una cosa: se il tuo obiettivo e` capire che codice macchina
venga generato dal compilatore, ti consiglio anche di disabilitare
ogni tipo di ottimizzazione, le opzioni di debug e quelle per il
profiling, che sporcano il codice con roba che non serve.
Saluti,
Marco
-- 
To email me, remove the no_ and _spam from my address.

 bisogno è --oformat binary.
L'ho detto che non sai proprio leggere.  Lo chiami compilare quello ???


 Certo che esistono.
Oltre che non capire niente di C non sai neanche leggere.


 Oltre che non capire niente di C non sai neanche leggere.
ROTFL ! stai delirando!... :-)


 L'ho detto che non sai proprio leggere. Lo chiami compilare quello ???
Rieccolo che si arrampica. Spero che questa volta tu abbia delle buone
ventose.
Innanzitutto, se vuoi che l'OP ti capisca gli spieghi che cosa vuoi dire
esattamente, perché non mi sembra del tutto onesto escludere la possibilità
di ottenere ciò che egli vuole dal linker (liquidandolo con un "Non
esistono"), piuttosto che dal mero e semplice compilatore. Seconda cosa,
generalmente con un compilatore viene fornito anche un linker (è così con il
gcc, è così con il Borland C++, è così con il Visual C++, ecc.. ecc..) e
quindi parlare di "quale compilatore per fare cosa" generalmente implica
parlare di "quale sistema di sviluppo per fare cosa". Terza cosa: I
compilatori e gli IDE + compilatori Borland generalmente hanno la fase di
linking integrata in quella di compilazione, quindi compilare significa
compilare _E_ linkare, con l'opzione (attivabile o meno) di avere la
produzione dei file oggetto. Compilare, in questo caso, signfiica produrre
un eseguibile o un "raw binary". Me ne sbatto di stare a disquisire con te
su cosa sia o meno la fase di compilazione e cosa sia o meno la fase di
linking se l'OP raggiunge il suo scopo in questo modo.



Bene hadesso che hai parlato rileggiti il tuo post. E medita sulle tue 
cazzate.  Poi torna a studiare le basi dell'informatica.  Compilare NON 
vuol dire linkare.  Se poi per te non fa` alcuna differenza, bene tienti 
le tue convinzioni.
Ciao
Giovanni


 vari SO).
Mentre alcuni continuano a litigare :-)  non mi e'  chiaro se hai 
ottenuto risposta alla tua domanda.
Confesso che non ho capito bene cosa vuoi fare.
Vuoi ottenere il codice binario corrispondente alle tue singole function 
prima della fase di linking (il cosiddetto codice oggetto) ?
In tal caso dovrebbe essere l'  opzione -c (come opzione di linea). La 
stessa funziona anche su gcc.
Pero'  non e' esatto dire che i files oggetto sono codice binario "senza 
le intestazioni che vengono inserite per poter interpretare il file dai 
vari SO". In realta'  mancano tutte le risoluzioni di chiamate di 
librerie e le rilocazioni relative dei vari codici.
Giorgio

 le tue convinzioni.
ROTFL...ahah... sei tu che devi rileggere il mio post. Continui a fare la
figura del coglione ed è una cosa veramente penosa. Se c'è una persona che
dimostra di non conoscere di che sta parlando, quella sei tu. Ti abbandono
volentieri al tuo delirio.


 vari SO".
Se con "file oggetto" si intende l'eseguibile finale, sì, è corretto. Ma
bisogna intendere quello ;-)


 Se con "file oggetto" si intende l'eseguibile finale, sě, č corretto. Ma


 bisogna intendere quello ;-)
File oggetto ed eseguibile sono cose diverse.
Giorgio

 File oggetto ed eseguibile sono cose diverse.
Esatto e io sto cercando di capire se l'OP con "file oggetto" non intenda,
invece, il file eseguibile finale. Che sono due cose diverse lo so molto
bene anch'io.


Penso forse di aver capito cosa viene chiesto all'inizio della
discussione.
Se con "codice binario grezzo" si intende una sequenza di 0 e 1
"tradotta" dal sorgente (occhio, nè compilata nè linkata, ma
"tradotta"), credo che l'OP chieda se è possibile ottenere un file
"binario" (?) di tipo indefinibile che sia la traduzione pura del
codice sorgente da mandare direttamente in esecuzione (secondo uno
schema pari a una macchina di Turing).
Beh, *NON* è possibile. Forse lo è su una macchina a schede forate,
dove ai buchi corrispondono dei valori binari che vengono letti ed
eseguiti in successione senza il controllo alcuno da parte di nessun
sistema operativo, senza una memoria con indirizzamento, senza
un'architettura, senza un formato, senza un bel niente!
Tutto ciò, ovviamente IMHO...

 Beh, *NON* č possibile.
Ma per favore !


 "tradotta"),
kronos:/tmp$ cat hello.c
#include <stdio.h>
int main(void) {
        printf("Hello World!\n");
        return 0;
}
kronos:/tmp$ xxd -b hello.c
0000000: 00100011 01101001 01101110 01100011 01101100 01110101  #inclu
0000006: 01100100 01100101 00100000 00111100 01110011 01110100  de <st
000000c: 01100100 01101001 01101111 00101110 01101000 00111110  dio.h>
0000012: 00001010 00001010 01101001 01101110 01110100 00100000  ..int
0000018: 01101101 01100001 01101001 01101110 00101000 01110110  main(v
000001e: 01101111 01101001 01100100 00101001 00100000 01111011  oid) {
0000024: 00001010 00001001 01110000 01110010 01101001 01101110  ..prin
000002a: 01110100 01100110 00101000 00100010 01001000 01100101  tf("He
0000030: 01101100 01101100 01101111 00100000 01010111 01101111  llo Wo
0000036: 01110010 01101100 01100100 00100001 01011100 01101110  rld!\n
000003c: 00100010 00101001 00111011 00001010 00001001 01110010  ");..r
0000042: 01100101 01110100 01110101 01110010 01101110 00100000  eturn
0000048: 00110000 00111011 00001010 01111101 00001010           0;.}.
<g>
Luca
-- 
Home: 
http://kronoz.cjb.net
K.R.O.N.O.S
Kinetic Replicant Optimized for Nocturnal Observation and Sabotage

ROTFL

 ROTFL
Allora ripeto il post cercando di essere più chiaro in quello che vorrei
ottenere.
Ho realizzato una mini shell che mi permette di navigare all'interno del
file system FAT32.
Per fare ciò utilizzo l'int13h del bios leggendo settore per settore.
Ho realizzato anche un bootloader che mi carica in memoria partendo dal
secondo settore in poi.
Adesso vorrei poter copiare il mio programma scritto in C a partire dal
secondo settore di un floppy per fare in modo che, il boot lo carichi in
memoria e poi facendo una jump all'indirizzo in cui viene caricato, il
programma vada in esecuzione.
Chiaramente ho bisogno di compilare il programma in C in formato binario
grezzo proprio perchè quelle che andrò a caricare in memoria sono le
istruzioni che il processore dovrà eseguire.
Detto questo penso di essere stato abbastanza chiaro.
Spero che qualcuno di poi possa darmi una soluzione che sicuramente
esiste altrimenti sarebbe impossibile poter caricare in memoria
qualsiasi sistema operativo


 Detto questo penso di essere stato abbastanza chiaro.
Dal mio punto di vista era chiaro fin dall'inizio, in uno dei miei
precedenti messaggi c'è un link a una pagina che ti spiega come fare.



In ambiente DOS esisteva exe2bin per convertire i file .exe in binario 
rimuovendo l'header per il loader.  C:\windows\system32\exe2bin.exe (per 
Windows XP).


Come si può compilare in questo modo un programma sotto Win? So già
che non devo usare librerie. (se possibile vorrei avere un link a un
compilatore e a una pagina che spiega come fare o che parametri passare
al compilatore). Ho il Cygwin ma non funziona.
Come si usa l'INT 13H in mezzo al codice C?

 Come si usa l'INT 13H in mezzo al codice C?
Nel Microsoft e nel Borland c'e` la funzione int86() con una serie di 
parametri che vengono caricati nei registri come richiesto dalle 
funzioni del bios.  Altrimenti ti costruisci in assembler le funzioni 
della libreria.


 Come si usa l'INT 13H in mezzo al codice C?
Le alternative sono tante.
Molti compilatori C prevedono un assembler built-in, ma è possibile
assemblare e linkare del codice assembly esternamente.
http://www2.imm.dtu.dk/courses/02130/djasm.html
http://nasm.sourceforge.net/wakka.php?wakka=HomePage
