Ho iniziato ad leggere/informarmi un po' ed ho scoperto delle cose interessanti tra cui altre possibili opzioni. Ma voglio continuare ad informarmi per saperne di più. Ho pure trovato pareri/interpretazioni più o meno discordanti su internet. Si "interpretazioni" anche se è strano che ci siano.
Legacy significa settare il processore in modalità protected ( 32 bit ) e a quel punto ti scordi dei 64 bit però. Non vorrei che avessi la convinzione che si possa allegramente passare da una modalità all'altra come pare e piace.
Inoltre un programma applicativo gira su un sistema operativo. Ed è quest'ultimo a stabilire in che modalità il processore deve funzionare. Mini-kernel? Un kernel in ogni caso deve decidere in che modalità vuole settare il processore. E la sua ABI è stabilita da tale modalità. Il software applicativo semplicemente non può comunicare col kernel se non usa la stessa ABI. L'unica che si avvicina un pò è l'ABI x32. Ma si tratta semplicemente di usare puntatori a 32 bit e comunque il software va ricompilato/riscritto per supportarla.Usare la modalità legacy significa usare OS a 32 bit. E questi stanno lentamente sparendo.
E' come temevo. No, non è possibile. Altrimenti perchè creare WOW64?
Quello che hai scritto nella prima frase già lo sapevo XD.
La mia convinzione non prevede il passaggio da un mode ad un' altra o vicerversa.
La mia idea/ipotesi era quella di poter accedere in fase di boot a tutte e due. Ad es. due kernel (non devono per forza comunicare tra di loro) di cui uno a 64 bit che imposta la long mode mentre l' altro a 32 bit oppure a 16 bit imposta la legacy mode. Ad es. i programmi dos 16 bit comunicheranno con il kernerl a 32 o 16 bit, avranno la stessa ABI del kernel a 32 oppure a 16 bit e potranno essere essere eseguiti all' interno della V8086 mode (disponibile solo in legacy mode).
L' abi x32 è un opzione. Non so è possibile a livello hardware scrivere puntatori a 16 bit.
Se il software va ricompilato/riscritto vuol dire che non c'è una limitazione hardware (es. il processore).
l' abi x16 quindi a 16 bit è possibile a livello hardware (es. il processore)?
Oppure un unico kernel che però ad es. abbia 2 abi. Sempre se a livello hardware (es. la cpu) lo permette. In ogni caso non vado su questa opzione.
A seconda delle opzioni aumenta il grado di complessità, il livello di conoscenze/esperienza/requisiti minimi etc...
Però per assurda non serve a nulla mettersi a studiare, fare pratica etc... per un opzione che a livello hardware non è possibile fare.
Io vorrei conoscere la verità, i limiti hardware e gli eventuali limiti software. Sempre nei limiti del possibile considerando che sono un privato.
In primis per conto mio sto facendo ricerche, sto leggendo etc...I tempi sono lughissimi.
WOW64 è stata creato da Microsoft ad es. perchè i sistemi operativi a 64 bit (quindi il relativo Kernel a 64 bit) dell' azienda nella fase del boot impostano il processore Solo nella Long Mode.
Poi ad es. con Wow64 i programmi a 32 bit possono accedere ad un quantitativo di ram maggiore rispetto ai sistemi operativi a 32 bit.
La Wow64 permette di eseguire nativamente il codice a 32 bit però è un emulatore con il layer che creare un enviroment a 32 bit.
Tra i vari siti, forum etc... ho trovato un sito che ha detto/visto che Wow 64 c' entra con
"Heaven’s Gate" e che fa lo switch tra la compability mode (non la protect mode) e la 64 mode.
Ha fatto il reverse engineering.
http://rce.co/knockin-on-heavens-gate-dynamic-processor-mode-switching/
Poi ho anche trovato info utili ed interessanti sul sito della microsoft, sezione per i programmatori etc...:
https://docs.microsoft.com/it-it/windows/desktop/WinProg64/running-32-bit-applications
Alla fine spiega il motivo principale perchè Wow64 non supporta il codice a 16 bit.
Ci sono altre informazioni nelle altre voci all' interno di "
Running 32-bit Applications".
In generale ci sono cose che ho capito, altre no per via del mio livello/preparazione ed altre sui ho trovato contraddizioni e pensieri/interpretazioni diverse. C'è un mondo di dati/informazioni.
In riferimento a Window server 2008 R2 ho trovato questo:
Forse i programmi a 16 bit sono stati convertiti a 32 bit ed i file si trovano in quella voce del registro?
Una delle possibili soluzioni è la CM16 (compatibily mode 16 bit). Il programma andrà riscritto dato che non dovrà essere compatibile la Real modem oppure con la V8086. Ad es. non deve avere le INT del Bios e del DOS.
Un' altra opzione riguarda i segment a 16 bit nella long mode.
Se mi risponderai tra tipo una settimana visto tutte le informazioni e le foto che ho postato, va bene uguale. Dico sul serio :)
Che poi come faresti a creare un singolo binario se da una parte c'hai il/i binari del programma da eseguire e dall'altra te ne serve per forza uno che implementi il vm monitor?
Su un editor di testo scrivo entrambi i codici relativi ai due file sorgenti e poi assemblo oppure compilo il tutto creando poi alle fine un unico file exe. In questo modo facendo doppio click si avvierà una finestra con dentro la macchina virtuale e poi il mio programma.
Se avrò difficoltà chiederò aiuto in questa discussione :D
Certo che ne basta una. Il bus PCI è un esempio di periferiche essenziali che il sistema operativo guest cerca ed usa attivamente. Il DOS non va a scandagliare il bus PCI, perchè all'epoca in cui nacque DOS, il PCI non esisteva. Ma il DOS usa comunque il PIC ad esempio. L'unico modo per non dover emulare parte dell'hardware è di scrivere programmi ad hoc bare metal che girano nella VM. Ma in questo caso i programmi legacy ( di cui spessissimo circolano solo i binari ) a 16 bit sono tagliati fuori. Per far girare questi programmi devi installare il DOS nella VM e quindi fornire tutto quanto il DOS chiede ( in termini di hardware ) per funzionare.
Se Qemu è complesso non ti resta altro che un emulatore DOS.
No, Qemu è pensato per fornire soluzioni di virtualizzazione, non singoli binari.
Comunque Windows e macOS hanno dei framework preinstallati che implementano i vm monitor. Si può usare quelli. Ma comunque ci vuole un programma che s'interfacci con questi framework, crei le VM, legga i binari da eseguire a 16 bit e li esegua. E trattandosi di binari a 16 bit NON BARE METAL, devi comunque portarti dietro un'immagine disco contenente il DOS preinstallato.
In sostanza no, scordati un unico binario.
C' era l' interfaccia ISA e credo che inizialmente fosse ad 8 bit.
Intendevo un programma che permette di virtualizzare ma che fosse custom, più limitato e più semplice di Qemu.
Io ho visto che ad es. è possibile creare programmi a 16 bit bare metal (anche il più semplice hello world) che vengono caricati al boot. Penso che la stessa cosa si possa fare su una macchina virtuale con il bios legacy.
Mi devo portare dietro un' immagine disco etc...? Non avrò un unico file?:skept:
Cosa c' entro io che il file lo invio tramite internet (molto probabilmente tramite un social network).
Io nel primo post ho scritto che ho la necessità che qualsiasi utente, a cui vorrò inviare il file contenente il mio codice, possa aprirlo su un pc Windows 7, 8, 8.1 e 10 (32 bit o 64) e che non deve scaricare o installare altri programmi etc... e che non debba per forza conoscere gli emulatori, il dos, la virtualizzazione, l' asm etc...
Dato che tu mi hai proposto come prima opzione la virtualizzazione ho giustamente pensato che potessi alla fine avere 1 file da inviare all' utente e che lo potesse aprire facendo doppio click e basta.
Si sta creando un pò di confusione
@Cibachrome oltre a qualche fraintendimento, cerco di essere più chiaro.
Quando ti dicevo del comprimere il COM, mi riferivo a creare uno zip ed allegarlo direttamente al post del forum, nient'altro. Ti chiedevo il COM per non scaricare l'assemblatore del TASM a 16bit ed assemblare i sorgenti.
Questo lo avevo capito fin dall' inizio. Quello che non avevo capire è perchè devo comprire un file .com se ha un peso talmente irrisorio.
Ho avuto dei problemi tra cui creare un file com. Tra l' altro non lo avevo mai fatto un file e sono pure un po' arruginito sull' asm 16 bit.
Nel link che ho postato c' era uno zero di troppo. Poi credevo che bastasse sostituire quelle due righe di codice al posto di quello che c' era ma invece no dato che ho poi scoperto che ci sono istruzioni che vanno cancellate mentre altre modificate.
O mi dava errore tasm oppure il td.
Sono riuscito a rivolvere gli errori ma fino ad un certo punto. Ancora il td da errore ma credo sia uno diverso.
L 'errore è questo:
https://stackoverflow.com/questions...annot-generate-com-file-stack-segment-present
Per tutti gli errori ho seguiti i consigli trovati su stack ed i forum.
Codice:
.MODEL tiny
.DATA
at DB 40 ;aperta tonda
num1 DB 52 ;numero 4
sim1 DB 43 ; +
num2 DB 50 ;numero 2
; +
num3 DB 56 ;numero 8
sim2 DB 45 ; -
num4 DB 53 ;numero 5
; -
num5 DB 49 ;numero 1
ct DB 41 ;chiusa tonda
sim3 DB 61 ; =
spac DB 32 ;spazio
res DB 55 ;risultato 7
.STARTUP
.code
org 100h
mov DL,at ;copia il valore di at,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,num1 ;copia il valore di num1,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,sim1 ;copia il valore di sim1,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,num2 ;copia il valore di num2,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,sim1 ;copia il valore di sim1,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,num3 ;copia il valore di num3,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,sim2 ;copia il valore di sim2,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,num4 ;copia il valore di num4,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,sim2 ;copia il valore di sim2,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,num5 ;copia il valore di num5,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,ct ;copia il valore di ct,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,sim2 ;copia il valore di sim2,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,num5 ;copia il valore di num5,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,sim3 ;copia il valore di sim3,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,spac ;copia il valore di spac,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov DL,res ;copia il valore di res,in DL
mov AH,02H ;stampa carattere sullo schermo
int 21H
mov AH,4CH ;restituisce il controllo all' O.S
int 21H
END ;termina programma
.code "e" org 100h c'è chi lo mette all' inizio e c'è chi lo mette dove l' ho messo io. Sempre per creare i file com.
Infatti ho utilizzato il C, come dicevo all'inizio del precedente post. ;)
Scriverlo in asm sarebbe stato inutile. Consigliavo a te, piuttosto, l'utilizzo dell'asm a 32bit invece che di quello a 16bit. A 16 al di fuori di fini didattici è inutile, oltretutto visto che vuoi eseguire codice su 64bit.
Non penso che sarebbe stato inutile^^
Emu8086 se non sbaglio è stato creato interamente in asm. Ho visto dei file asm del programmatore su github.
Però voglio precisare che ognuno è libero di scegliere/usare il linguaggio che vuole.
Sono gli ancora agli inizi con l' asm 16 bit e l' 8086.
Un giorno e se riuscirò ad arrivare all' X86 386 e al 32 bit allora mi piacerebbe scrivere codice a 32 bit sui S.O. Microsoft a 32 o 64 bit. Anche perchè rivolverai il problema della compatibilità/portabilità quando devo voglio inviare un file ad una persona.
Però per me anche il 16 bit e l' 8 bit non saranno solo didattici ^^ Ho anche dei progetti (ovviamente non lavorativi).
Lascia perdere PCI, come ha precisato pabloski, non esisteva (quindi non è da emulare).
Meno male, una cosa in meno da non aggiungere al programma XD.
Il discorso lo si può semplificare così: se hai programmi a 16bit (tuoi o non tuoi) e vuoi eseguirli, magari anche giochi ad esempio, ti serve qualcosa di completo, come le soluzioni sopra citate. In questo caso come dicevo nel primo post, e come dice pabloski, non viene caricato ed eseguito il tuo binario (che sia EXE o COM); c'è il sistema operativo che viene caricato ed eseguito, e che successivamente esegue il programma a 16bit.
A me serve 1 solo file. Non userò il mio binario.Se scegliere l' opzione dell' emulatore userò il codice sorgente del mio programma che si troverà in un nuovo file sorgente dopo le righe di codice dell' emulatore.
Per il momento i programmi sono solo testuali e addirittura sono molto semplici. Prima che arriverà a fare il primo programma con una GUI molta elementare ne passerà di tempo.
Per quanto riguarda il mio primo videogioco 2D semplice con asm 8 o 16 bit non so se ce la farò prima dello sbarco dell' uomo su marte XD.
Generalmente un emulatore di 8086 si occupa di emulare
l'hardware, quindi ad esempio può essere composto dalle seguenti parti:
- fetch/decode delle istruzioni in linguaggio macchina;
- emulazione dell'i8042 (keyboard e mouse);
- i8259, il PIC, per gestire le interruzioni hw;
- PIT (il timer), per la sincronizzazione, il clock;
- il suono, magari sound blaster, ad esempio;
- supporto a VGA, CGA, MCGA, Herclues,...
Più o meno queste sono le cose necessarie.
Ad esempio DOSBox emula x86 e non solo 8086, quindi hanno anche un supporto per la modalità protetta andando a supportare paginazione, indirizzi virtuali etc etc.
Ho capito in linea generale :)
Non immaginavo che oltre al processore bisognasse emulare pure un microcontrollore. Ma c'è pure un altro integrato che è PIC.
Meno male che non mi serve un emulatore del genere. Sto tirando un sospiro di sollievo.
Quindi DOSBox supporta anche codice a 32 bit?
Non si può eseguire codice a 16bit su un 64bit, quindi mettiti il cuore in pace: se vuoi farlo, ti serve un programma che lo esegua.
Ti consiglio di leggere:
la prima frase che ho scritto nel mio primo messaggio di questa discussione.
quello che ho scritto a Pabloski (in questa risposta) e di vedere le foto che ho postato.
Nel tuo caso senza emulatore servirebbe qualcosa di "fatto su misura" e limitato, ma si tratterebbe sempre di un emulatore.
La mia soluzione prevede appunto un programma, ad esempio a 32bit, che "inglobi" quel codice a 16bit (in una sezione dell'eseguibile); non avendo sotto un sistema operativo che esegue questo programma, sarebbe necessario gestire, tanto per fare un esempio, le INT che richiami (del DOS e del BIOS).
Si tratterebbe di una soluzione con forti limiti, o comunque parecchie complessità. Dipende tutto da come deve essere il "prodotto finale"; le soluzioni di emulazione esistono, e come hai visto non sono poche. Quindi se vuoi in futuro qualcosa di completo, è la soluzione migliore.
La tua soluzione, se non ha il sistema operativo, è meno complessa (^^) e si può modificare il sorgente del mio programma aggiundendo il boot etc... in maniera tale da farlo diventare bare metal. Poi sarà limitata dato che dovrà fare solo le cose che ho chiesto, quindi custom e sarà meno complessa rispetto all' elenco che hai postato. Però il codice del mio programma presente all' interno dell' unico file verrà tradotto oppure no?
C'è l' opzione di creare un emulatore (sempre un unico file) che non vada a tradurre il codice a 16 bit del mio programma(contenuto all' interno) ma che crei un layer ed un enviroment a 16 bit. Mi sono ispirato a Wow64. Però questo programma finale che poi invierò all' utente sarà a 32 bit (non a 64 bit) e l' enviroment sarà a 16 bit (non a 32 bit). Un' altra differenza, rispetto a Wow64 e che non dovrà switchare tra la 64 bit mode e la compability mode (ma non confondere con la protect mode). Forse grazie a Wow64 l' utente potrà aprire questo programma a 32 bit.
Mi stavo dimenticando che qualsiasi opzione sceglierò il programma dovrà essere compatibile anche con la protect mode per chi ha Windows 7, 8, 8.1 o 10 a 32 bit e una cpu X86 32 bit o X86-64 a 64 bit.
Altra possibile opzione (o forse è la stessa della compability mode 16 bit):
"64 Bit Long mode cleans up some of the mess left by this evolution of chip designs. Of course the chip designers can't get rid of the old cruft completely because even the newest multicore system still needs to be able to behave like an over 30 year old machine. But in Long mode there is no more segmented memory, no more four-ring model and other things which weren't really used by modern systems anyway. Also Virtual 86 mode was tossed out because the DOS era is long gone now. The new old thing to be supported now, and probably for a long time, is 32 Bit applications. And they will happily run next to 64 Bit programs in long mode because, again, the bittiness is determined by a flag.
Interesting enough you can still mark a code segment as 16 Bit and the CPU will execute it in 16 Bit mode".
Ovviamente non si parla del codice 16 bit compatibile con la Real Mode oppure con la V8086. Devo modificare il sorgente del mio programma. Devo cancellare ad es. tutti gli INT del Dos e del Bios etc...
I code segment c' entrano con
Di fatto non puoi emulare solo questo quindi.
Tieni presente che scrivendo un emulatore che vada a caricare l'immagine di un OS non implica dover scrivere le ISR, ovviamente; quando avviene un INT software il codice "salta" nella IVT e carica l'indirizzo presente in quella posizione della IVT (che è l'indirizzo della ISR). Questa ISR non viene implementata da chi scrive l'emulatore insomma (ecco perchè specificavo sopra che l'emulazione è del solo hardware).
Spero sia tutto più chiaro ora.[/QUOTE]