[DOMANDA] Eseguire codice sorgente 16 bit su Windows 64 bit senza scaricare un emulatore o un hyper-visor

Cibachrome

Utente Attivo
8,404
3,019
Hardware Utente
#1
Ciao a tutti.

So che su una cpu Intel/Amd a 64 bit qualsiasi sistema operativo a 64 bit accede alla long mode (o 64 bit mode). La V86-mode non è disponibile nella long mode (è un limite/caratteristca hardware) e giustamente la V86-mode non è supportata all' interno dei sistemi operativi a 64 bit.

Avrei la necessità (non è per lavoro) di creare un programma senza GUI che una volta aperto (intendo il doppio click del mouse) dall' utente possa eseguire il mio codice asm 8086 presente all' interno.
Chiunque lo aprirà non dovrà avere o scaricare un emulatore oppure un hyper-visor. Non dovrà configurare nulla. Non dovrà per forza sapere cosa sia un emulatore o/e un hyper-visor, non dovrà per forza avere una o più conoscenze dal punto di vista della programmazione o/e dell' architeturra dei calcolatori.

Questo programma non dovrà eseguire altri codici o/e programmi esterni. Chiunque l' aprirà non potrà scrivere codice o/e avviare altri programmi o/e altro codice.

Il sorgente del programma (righe di codice) all' interno avrà il sorgente del mio programma 16 bit 8086 (altre righe di codice). Tutto il sorgente andrà poi assemblato oppure compilato per ottenere 1 solo file .exe . Non ci devono essere altri file o/e programmi insieme al file .exe affinchè il tutto funzioni. Il programma se viene aperto dovrà funzionare per chiunque ha Windows 7, 8, 8.1 e 10.

Il codice a 16 bit 8086 presente all' interno del programma non dovrà essere lo stesso. Nel senso che devo avere la posibilità di modificare, all' interno del sorgente, la parte di codice asm a 16 bit 8086 per creare una variante del programma oppure un altro programma (sempre a 16 bit 8086). Ovviamente poi tutto il sorgente (contiene anche quello asm 8086) lo dovrò assemblare oppure compilare di nuovo per poi alla fine avere un file .exe da poter inviare ad uno o più utenti.

Ci tengo a precisare che questo programma (compreso il codice a 16 bit 8086) sarà sicuro e non sarà illegale.

Non sono intessato a riscrivere il sorgente asm 8086 in asm 32 bit o 64 bit. Tra le varie cose il codice non sarà lo stesso.

Potrei usare uno di quei linguaggi di programmazione che permettono l' assembly inline (es. C, Pascal o forse il QBasic). Però non posso inserire le parti relative all' assemblatore e tra l' altro non avrebbe senso farlo visto che con il C o con il Pascal il programma andrà compilato mentre con il Qbasic andrà interpretato.
In questo modo però si perde una parte del mini-programma asm 8086.

Foorse un programma pseudo-OS virtuale mono-tasking senza GUI. Deve contenere il masterboot, deve rispettare quello che ho scritto sopra e non deve permettere di fare altro. Non so se a livello tecnico sia fattibile e qual'è il livello di difficoltà.

Mi è venuta in mente un' altra opzione però non sono sicuro che sia fattibile. Ci sono diversi siti che permettono di scrivere il codice e di compilarlo oppure di interpretarlo (a seconda del linguaggio di programmazione che si sceglie). Non so se c'è n'è almeno uno che permetta di inserire il codice asm 8086 e di memorizzarlo per poi fornire un url. In questo modo posso inviare l' url e se l' utente in questione ci cliccherà sopra si aprirà il browser e si carichèa il sito e poi il programma asm 8086.

Non so se avete altre opzioni considerando che tra i miei interessi c'è l' assembly. Non mi importa di quanti anni abbia o/e di quanto mercato abbia. Vivi e lascia vivere.

Ho cercato un po' di riassumere visto che ho cancellato delle parti. Dico sul serio.
Non so se ho dimenticato qualcosa. In tal caso fatemelo sapere :)
 
Ultima modifica:
566
321
Hardware Utente
CPU
Intel i7 6700HQ, 2.60Ghz, 4 core 8 threads
Scheda Madre
Asustek
Hard Disk
Hitachi 7200 rpm, 1TB
RAM
16GB DDR4 (2 slot su 4)
Scheda Video
Nvidia Geforce GTX 960M, 4GB
Scheda Audio
Realtek
Sistema Operativo
Windows 10 64bit
#2
Non sarebbe eseguibile in quanto se avevi come target il DOS ci saranno - ad esempio - le chiamate dirette alle INT. Ma non solo, l'accesso alla memoria in modalità virtuale è diverso, così come alla memoria video. In Windows qualsiasi servizio richiede una chiamata alle API di sistema.
Oltretutto non sfrutteresti minimamente le CPU attuali ma saresti costretto a registri a 16bit di fatto (essendo stato scritto a 16bit il tuo programma).

In sintesi, l'unica soluzione che mi viene in mente, è scrivere un programma che emuli il tuo, inglobandolo direttamente (caricandolo ad esempio all'avvio). Di fatto si tratta di scrivere un emulatore, almeno parziale, anche e soprattutto per emulare le chiamate di sistema che fai sotto ad 8086 (le INT appunto).

Il tuo programma fa uso della modalità testo e basta, oppure no?
 
#3
Che io ricordi è tecnicamente impossibile eseguire codice nativo a 16 bit su una CPU a 64 bit, sia per questioni di hardware che di sistema operativo. L'unica è l'emulazione ma ti dovresti scrivere un emulatore di una CPU precedente all'80386 e farci girare dentro il tuo codice (l'emulatore però te lo scrivi in C/C++ coi compilatori almeno a 32 bit).
 

Cibachrome

Utente Attivo
8,404
3,019
Hardware Utente
#4
Per tutti:

mi piacerebe sapere ad un livello molto generale (tanto per farsi un' idea generale) come funziona su Windows XP 32 bit e su Windows 7 32 bit oppure 64 bit:

un emulatore cpu (es. 8086)
emulatore dos
hyper-visor (non bare metal) + VM Ms dos

Accetto anche link sempre se il livello è molto generale.

Ho fatto una ricerca ed ho visto che ad es. un sito utilizza un assemblatore online nasm mentre altri 2 uno online GCC. Mi è venuto in mente che nel primo post mi era sfuggito il fatto che se il sito web non ha un assemblatore online basato su Tasm allora nessuno dei programmi che ho funzionano dato che sono in asm Tasm.

Non sarebbe eseguibile in quanto se avevi come target il DOS ci saranno - ad esempio - le chiamate dirette alle INT. Ma non solo, l'accesso alla memoria in modalità virtuale è diverso, così come alla memoria video. In Windows qualsiasi servizio richiede una chiamata alle API di sistema.
Oltretutto non sfrutteresti minimamente le CPU attuali ma saresti costretto a registri a 16bit di fatto (essendo stato scritto a 16bit il tuo programma).

In sintesi, l'unica soluzione che mi viene in mente, è scrivere un programma che emuli il tuo, inglobandolo direttamente (caricandolo ad esempio all'avvio). Di fatto si tratta di scrivere un emulatore, almeno parziale, anche e soprattutto per emulare le chiamate di sistema che fai sotto ad 8086 (le INT appunto).

Il tuo programma fa uso della modalità testo e basta, oppure no?
Non mi sono venute in mente le INT presenti nel DOS e le Api presenti in Windows. Già solo questa cosa cambia tantissimo la situazione.

Non ho la necessità di sfruttare le cpu attuali e di usare i registri fino a 32 bit oppure fino a 64 bit.
I programmi 8086 sono e saranno testuali e quindi non c'è nessuna GUI. Non vado nemmeno ad inserire il codice per la GUI. Stessa cosa vale per il programma che dovrà emulare il codice a 16 bit 8086.

Nella tua soluzione viene emulato anche l' O.S dos che però non sarà visibile all' utente? Forse Sto facendo un po' di confusione con Dos box.
Mi piacerebbe saperne di più sullo scrivere questo programma che permetta di emulare uno dei programmi che ho 16 bit 8086.

Cosa ne pensi invece dell' idea di "BAT00cent"?

Che io ricordi è tecnicamente impossibile eseguire codice nativo a 16 bit su una CPU a 64 bit, sia per questioni di hardware che di sistema operativo. L'unica è l'emulazione ma ti dovresti scrivere un emulatore di una CPU precedente all'80386 e farci girare dentro il tuo codice (l'emulatore però te lo scrivi in C/C++ coi compilatori almeno a 32 bit).
Riguarda alla prima frase, come ho scritto all' inizio del mio primo post, nella long mode purtroppo non è possibile accedere alla V86-mode. Di conseguenza chi scrisse gli O.S. a 64 bit, giustamente non ha integrato la V86-mode.

Però se si ha un S.0. a 32 bit ed una cpu a 64 bit allora esso si avvierà invece in legacy mode e potrà accedere alla V86-mode. Può eseguire codice a 16 bit.

Con i programmi 8086 però va benissimo un emulatore di una cpu 8086. E' un po' meno difficile rispetto ad emulatore per una cpu Intel a 16 bit successiva all' 8086 e all' 8088.
Però al momento, anche andando sull' 8086, scrivere un emulatore per questa cpu non è assolutamente alla mia portata.
Curiosità: è possibile integrare anche le direttive Tasm oppure si può solo scrivere il codice in assembly puro?

So che c'è Emu8086 però non so se può essermi utile per questa cosa che devo fare e se per uso privato lo posso utilizzare per il mio scopo. In questo modo non devo andare a crearne uno.

Cosa pensi della soluzione proposta da "Dispatchcode"?
 
566
321
Hardware Utente
CPU
Intel i7 6700HQ, 2.60Ghz, 4 core 8 threads
Scheda Madre
Asustek
Hard Disk
Hitachi 7200 rpm, 1TB
RAM
16GB DDR4 (2 slot su 4)
Scheda Video
Nvidia Geforce GTX 960M, 4GB
Scheda Audio
Realtek
Sistema Operativo
Windows 10 64bit
#5
A me era venuta la pazza idea di iniziare un emulatore per Intel 8086 e per DOS. Io volevo di fatto non solo emulare la CPU, quindi opcodes e hw, come le periferiche ed il PIC, ma scrivere direttamente un piccolo kernel compatibile con DOS. Usavo SDL2 per emulare la grafica.
È lo fermo al momento. Vengono emulate per ora circa il 36% degli opcodes se non ricordo male.

Tornando a te: un'idea potrebbe essere quella di avere un programma a 32bit che faccia da emulatore del tuo. In pratica caricherà un semplice binario (devi generare un COM e non un EXE, almeno si evita l'header) e poi lo emula.
Non essendoci la modalità video è più semplice. La difficoltà sta solo con le INT, ma se non vuoi qualcosa di proprio puro... si fa tutto con delle "callback", senza bisogno caricare del binario che si occupi delle INT.

Comunque si, ad esempio Windows 64bit non esegue codice a 16bit. Ha rarissimi casi concessi nel suo core; ci sono installer a 16bit che vengono eseguiti comunque, ma se non ricordo male opera una sorta di conversione comunque, solo che lo fa una maniera trasparente.

Nel tuo caso l'unica soluzione è quella che dicevo sopra secondo me, che è poi quanto detto anche da BAT.

Un emulatore, e ce ne sono un po', di norma non emula 8086 e DOS ma solo 8086. Viene poi caricato DOS, magari in una versione equivalente (FreeDOS). In questo modo vengono implementate le ISR nell'emulatore, ma ciò che fa l'emulatore è solo "pushare" CS, FLAGS ed IP (che emula, quindi è tutta la parte emulata quella di cui parlo io, sono variabili pushate sulla ram emulata, un'array) e poi farli puntare alla giusta posizione nella IVT. Da quel punto il codice eseguito è quello di FreeDOS (diciamo del DOS, genericamente); l'emulatore lo esegue trattandosi di codice esattamente come quello del programma... a 16bit insomma.

Se mi dai un tuo COM semplice (allega pure qui zippato), possiamo provare ad eseguirlo. Anche solo un hello world. Levo la parte grafica e dirotto tutto sul terminale.
Sino a stasera o domani non potrò metterci mano però.
 
#6
Cosa ne pensi invece dell' idea di "BAT00cent"?
che sono matto da legare! :parladi:
Quello che ti ho suggerito non è alla mia portata con le conoscenze che ho e senza nessuna esperienza pratica in merito. Come se non bastasse quando feci gli esami di architettura dei calcolatori studiammo l'assembly Motorola 68000 che girava su MS-DOS in un emulatore Assembly 68xxx scritto in turbo Pascal (dall'insegnante e dai suoi specializzandi); era pure in beta-version (ma più vicino ad alpha che a beta, e spesso si piantava, però tutto sommato per esercitarci funzionava). Più nebuloso di così!

Cosa pensi della soluzione proposta da "Dispatchcode"?
A occhio, e considerando la sua molto maggiore perizia tecnica rispetto a me di questioni "basso livello" (intendo assembly, emulazione ecc), mi sembra concettualmente non lontanissima a quanto dicevo io nella mia follia. Solo che se lui dice che si potrebbe fare, c'è da crederci. Sul come, devi chiedere a lui. :ok:
 
Ultima modifica:
Mi Piace: Andretti60
#7
Questa domanda l'avevi già posta mesi fa se non sbaglio. E anche allora la risposta fu no. La modalità long ( quella a 64 bit ) non supporta la transizione in modalità 86 virtuale, perchè è impossibile far girare un eseguibile a 16 bit in un sistema a 64 bit direttamente.

Le uniche opzioni sono: emulazione o virtualizzazione. Della prima ne hanno parlato gli altri. Riguardo la seconda, devi crearti una virtual machine monitor che instanzi delle cpu virtuali. E ovviamente c'è bisogno di emulare delle periferiche e dei dispositivi standard ( bus PCI innanzitutto ). Ma la salvezza è che esistono già soluzioni del genere ( Qemu ad esempio ). Per cui prepari la tua immagine del software a 16 bit ( ovviamente ci vuole un sistema operativo se il programma da far girare non è bare metal ) e la lanci con Qemu o simili.
 

Cibachrome

Utente Attivo
8,404
3,019
Hardware Utente
#8
A me era venuta la pazza idea di iniziare un emulatore per Intel 8086 e per DOS. Io volevo di fatto non solo emulare la CPU, quindi opcodes e hw, come le periferiche ed il PIC, ma scrivere direttamente un piccolo kernel compatibile con DOS. Usavo SDL2 per emulare la grafica.
È lo fermo al momento. Vengono emulate per ora circa il 36% degli opcodes se non ricordo male.

Tornando a te: un'idea potrebbe essere quella di avere un programma a 32bit che faccia da emulatore del tuo. In pratica caricherà un semplice binario (devi generare un COM e non un EXE, almeno si evita l'header) e poi lo emula.
Non essendoci la modalità video è più semplice. La difficoltà sta solo con le INT, ma se non vuoi qualcosa di proprio puro... si fa tutto con delle "callback", senza bisogno caricare del binario che si occupi delle INT.

Comunque si, ad esempio Windows 64bit non esegue codice a 16bit. Ha rarissimi casi concessi nel suo core; ci sono installer a 16bit che vengono eseguiti comunque, ma se non ricordo male opera una sorta di conversione comunque, solo che lo fa una maniera trasparente.

Nel tuo caso l'unica soluzione è quella che dicevo sopra secondo me, che è poi quanto detto anche da BAT.

Un emulatore, e ce ne sono un po', di norma non emula 8086 e DOS ma solo 8086. Viene poi caricato DOS, magari in una versione equivalente (FreeDOS). In questo modo vengono implementate le ISR nell'emulatore, ma ciò che fa l'emulatore è solo "pushare" CS, FLAGS ed IP (che emula, quindi è tutta la parte emulata quella di cui parlo io, sono variabili pushate sulla ram emulata, un'array) e poi farli puntare alla giusta posizione nella IVT. Da quel punto il codice eseguito è quello di FreeDOS (diciamo del DOS, genericamente); l'emulatore lo esegue trattandosi di codice esattamente come quello del programma... a 16bit insomma.

Se mi dai un tuo COM semplice (allega pure qui zippato), possiamo provare ad eseguirlo. Anche solo un hello world. Levo la parte grafica e dirotto tutto sul terminale.
Sino a stasera o domani non potrò metterci mano però.
Sono d' accordo con la tua idea anche se è po' pazza per via della complessità del progetto. Però piano piano si arriverà alla meta.
Curiosità: quale linguaggio di programmazione hai usato?

Nel mio caso:
Per il momento potrei usare i file COM.

Pensavo che tu e BAT avevate proposto due soluzioni diversi. Tu un programma che emulasse il mio programma a 16 bit mentre lui un emulatore di una cpu che permettesse di avviare il mio codice a 16 bit. Quindi avevo capito male.

Non c'è un modo, nel mio caso, per sfruttare il core del sistema operativo?

Non ho file COM al momento. Ho visto che devo fare 2 modifiche semplicissime al codice:

https://stackoverflow.com/questions/50245900/does-anyone-know-how-to-create-com-files-with-tasm

Poi tramite tasm creo il file COM. Non so se ce la faccio stanotte.
Anche se riesci a farlo entro la fine di domani (o dopodomani) per me va benissimo.
Perchè dev' essere compresso? Ad es. uno dei programmi exe 16 bit 8086 pesa 1,67 kbyte. Perfino un floppy 720k 5.25" è sprecato :D

Invece la virtualizzazione proposta da pabloski?

che sono matto da legare! :parladi:
Quello che ti ho suggerito non è alla mia portata con le conoscenze che ho e senza nessuna esperienza pratica in merito. Come se non bastasse quando feci gli esami di architettura dei calcolatori studiammo l'assembly Motorola 68000 che girava su MS-DOS in un emulatore Assembly 68xxx scritto in turbo Pascal (dall'insegnante e dai suoi specializzandi); era pure in beta-version (ma più vicino ad alpha che a beta, e spesso si piantava, però tutto sommato per esercitarci funzionava). Più nebuloso di così!
A occhio, e considerando la sua molto maggiore perizia tecnica rispetto a me di questioni "basso livello" (intendo assembly, emulazione ecc), mi sembra concettualmente non lontanissima a quanto dicevo io nella mia follia. Solo che se lui dice che si potrebbe fare, c'è da crederci. Sul come, devi chiedere a lui. :ok:
Appena ho letto la soluzione che mi avevi proposto ho pensato che fosse almeno complessa (per me) e che non ti ricordavi fino a dove sono arrivato con il C/C+ e quale quale fosse il livello reale su questi argomenti tra cui il C o/e il C++. Avevo pensato che la tua soluzione fosse diversa e più complicata rispetto a quelle di Dispatchcode mentre invece è la stessa.

Oltre al Dispatcode c'è anche ad es. Pabloski. Serve tutto l' aiuto possibile visto che la soluzione al problema è complessa. Di quest' ultimo ho letto prima una discussione su un altro forum in cui spiegava in linea generale cosa fa un emulatore. Non so se posso linkare la discussione.

Questa domanda l'avevi già posta mesi fa se non sbaglio. E anche allora la risposta fu no. La modalità long ( quella a 64 bit ) non supporta la transizione in modalità 86 virtuale, perchè è impossibile far girare un eseguibile a 16 bit in un sistema a 64 bit direttamente.
La domanda è diversa rispetto alla discussione che avevo aperto qui sul forum nel 2014:
https://forum.tomshw.it/threads/info-sviluppo-s-o-ed-un-implementazione-per-windows-7.433332/

Poi non hai letto completamente quello che ho scritto in questa discussione dato che:

Nel primo post ho scritto questo:
"So che su una cpu Intel/Amd a 64 bit qualsiasi sistema operativo a 64 bit accede alla long mode (o 64 bit mode). La V86-mode non è disponibile nella long mode (è un limite/caratteristca hardware) e giustamente la V86-mode non è supportata all' interno dei sistemi operativi a 64 bit. "

Nel secondo messaggio, in risposta a BAT, ho scritto questo:
"Riguarda alla prima frase, come ho scritto all' inizio del mio primo post, nella long mode purtroppo non è possibile accedere alla V86-mode. Di conseguenza chi scrisse gli O.S. a 64 bit, giustamente non ha integrato la V86-mode.
Però se si ha un S.0. a 32 bit ed una cpu a 64 bit allora esso si avvierà invece in legacy mode e potrà accedere alla V86-mode. Può eseguire codice a 16 bit. "

Mi è venuto in mente che 1 o 2 anni fa avevo visto in uno dei manuali Intel relativi all' architettura X64 una tabella che riportava: 8 bit, 16 bit, 32 e 64 bit. "Sembrava" a prima vista come se un processore Intel 64 bit potesse eseguire anche il codice ad 8 bit, 16 bit e 32 bit. Anche allora sapevo della long mode etc... e quindi chissà cosa in realtà significa questa tabella. Se la trovo la posto qui.

Questi argomenti (Intel 32 bit e 64 bit) mi interessano però al momento non voglio aggiungere altra carne al fuoco. Forse nel futuro non prossimo ci sarà una discussione apposita XD.

Le uniche opzioni sono: emulazione o virtualizzazione. Della prima ne hanno parlato gli altri. Riguardo la seconda, devi crearti una virtual machine monitor che instanzi delle cpu virtuali. E ovviamente c'è bisogno di emulare delle periferiche e dei dispositivi standard ( bus PCI innanzitutto ). Ma la salvezza è che esistono già soluzioni del genere ( Qemu ad esempio ). Per cui prepari la tua immagine del software a 16 bit ( ovviamente ci vuole un sistema operativo se il programma da far girare non è bare metal ) e la lanci con Qemu o simili.
Mi pare un po' strano che ci siano solo 2 opzioni :boh:
Ad es. c'è la legacy mode nel processore che è inutizzata.

Ipotesi: se si riuscisse ad accedere in qualche modo, usando la programmazione più l' ingegno e la creatività, alla legacy mode e senza disconnettersi da Windows 64 bit allora sarebbe bello. Windows 64 bit accede solo alla Long mode e quindi foose magari creare un mini-kernel semplice all' interno che sia a 32 bit ma che possa comunicare all' esterno dell' O.S ed accedere alla lelacy mode. Poi il programma a 16 bit tramite altre codice (se serve) si interfaccia con questo mini-kernel 32 bit.
Poi è anche vero che a partire da Windows 2000 in poi,ogni versione è diventata piano piano sempre più blindata e le limitazione per quanto riguarda la programmazione basso livello/medio livello sono aumentate. Windows 10 sarà tipo Fort Knox :lol:

Non basta nel mio caso una solo cpu virtuale?
Non capisco a cosa possa servirmi il bus PCI, in questo caso.

Hai detto bene "la salvezza". Se sceglierò l' opzione della virtualizzazione sicuramente mi affiderà ad una delle soluzioni del genere. Non so cosa devo cercare su "google" per trovarle.
Ho visto Qemu e non lo conoscevo. Per quello che devo fare io è avanzato e troppo complesso. Non so se sia possibile lasciare solo il codice che permetta di fare solo le cose che ho menzionato sopra.

Con una di queste soluzioni del genere alla fine avrà 1 solo file che poi possa essere avviato su qualsiasi S.O. 7,8, 8.1 e 10 senza scaricare nessun altro programma o/e file?

L' opzione dell' emulazione è meno complessa oppure no?
 
566
321
Hardware Utente
CPU
Intel i7 6700HQ, 2.60Ghz, 4 core 8 threads
Scheda Madre
Asustek
Hard Disk
Hitachi 7200 rpm, 1TB
RAM
16GB DDR4 (2 slot su 4)
Scheda Video
Nvidia Geforce GTX 960M, 4GB
Scheda Audio
Realtek
Sistema Operativo
Windows 10 64bit
#9
Sono d' accordo con la tua idea anche se è po' pazza per via della complessità del progetto. Però piano piano si arriverà alla meta.
Curiosità: quale linguaggio di programmazione hai usato?
Ho utilizzato C.
La meta è definibile concretamente solo definendo gli scopi reali. Che vuoi eseguire, precisamente?

Nel mio caso:
Per il momento potrei usare i file COM.

Pensavo che tu e BAT avevate proposto due soluzioni diversi. Tu un programma che emulasse il mio programma a 16 bit mentre lui un emulatore di una cpu che permettesse di avviare il mio codice a 16 bit. Quindi avevo capito male.
No, praticamente abbiamo detto qualcosa di simile.
Il programma a cui faccio riferimento io per emulare il tuo a 16bit deve emulare la CPU ed a questo punto le INT del DOS, almeno quelle che utilizzerai per certo (esempio: se non userai mai la modalità video, non serve implementare le INT di DOS e BIOS per la gestione della modalità video; in particolare la INT 10h del BIOS).

La differenza in ciò che dicevo io è che avresti un eseguibile, che è poi l'emulatore, che carica il COM e lo esegue, come farebbe Emu8086, QEmu, DOSBox etc etc.
L'alternativa a cui pensavo è attuabile solo considerando (1) la dimensione ridotta dei programmi che eseguirai, (2) della memoria a cui puoi accedere (la RAM emulata sarà poca). Sto ancora pensando quando sia fattibile... teoricamente si potrebbe utilizzare un programmino che scriva il binario direttamente in una sezione dell'EXE che si andrà ad eseguire.
All'avvio, al posto di caricare un file, verrà letta la sezione per intero (tanto le dimensioni emulate della RAM sono comunque ridotte, appunto) e caricate in memoria; da qui partirà l'emulazione per eseguire il tuo programma.

Comunque rimando le considerazioni al termine del mio intervento...

Non c'è un modo, nel mio caso, per sfruttare il core del sistema operativo?

Non ho file COM al momento. Ho visto che devo fare 2 modifiche semplicissime al codice:

https://stackoverflow.com/questions/50245900/does-anyone-know-how-to-create-com-files-with-tasm

Poi tramite tasm creo il file COM. Non so se ce la faccio stanotte.
Anche se riesci a farlo entro la fine di domani (o dopodomani) per me va benissimo.
Perchè dev' essere compresso? Ad es. uno dei programmi exe 16 bit 8086 pesa 1,67 kbyte. Perfino un floppy 720k 5.25" è sprecato :D
Creare un COM è il meno. Si tratta di un file con del codice macchina senza alcuna intestazione.

Difficilmente riuscirò entro domani se non so nemmeno che vuoi eseguire... :D
Eseguire il tuo non sarebbe un problema, a patto che gli opcodes che ho attualmente siano sufficienti; mi stavo concentrando sulla memoria video ed altri dettagli, trascurando le istruzioni.

Ti dicevo di comprimerlo per evitare qualsiasi limite di upload dovuto ad esempio all'estensione.

Puoi anche utilizzare qualche tecnica come la "ricompilazione dinamica", ma non mi sembra il caso... :)

La domanda è diversa rispetto alla discussione che avevo aperto qui sul forum nel 2014:
https://forum.tomshw.it/threads/info-sviluppo-s-o-ed-un-implementazione-per-windows-7.433332/

Poi non hai letto completamente quello che ho scritto in questa discussione dato che:

Nel primo post ho scritto questo:
"So che su una cpu Intel/Amd a 64 bit qualsiasi sistema operativo a 64 bit accede alla long mode (o 64 bit mode). La V86-mode non è disponibile nella long mode (è un limite/caratteristca hardware) e giustamente la V86-mode non è supportata all' interno dei sistemi operativi a 64 bit. "

Nel secondo messaggio, in risposta a BAT, ho scritto questo:
"Riguarda alla prima frase, come ho scritto all' inizio del mio primo post, nella long mode purtroppo non è possibile accedere alla V86-mode. Di conseguenza chi scrisse gli O.S. a 64 bit, giustamente non ha integrato la V86-mode.
Però se si ha un S.0. a 32 bit ed una cpu a 64 bit allora esso si avvierà invece in legacy mode e potrà accedere alla V86-mode. Può eseguire codice a 16 bit. "

Mi è venuto in mente che 1 o 2 anni fa avevo visto in uno dei manuali Intel relativi all' architettura X64 una tabella che riportava: 8 bit, 16 bit, 32 e 64 bit. "Sembrava" a prima vista come se un processore Intel 64 bit potesse eseguire anche il codice ad 8 bit, 16 bit e 32 bit. Anche allora sapevo della long mode etc... e quindi chissà cosa in realtà significa questa tabella. Se la trovo la posto qui.

Questi argomenti (Intel 32 bit e 64 bit) mi interessano però al momento non voglio aggiungere altra carne al fuoco. Forse nel futuro non prossimo ci sarà una discussione apposita XD.
Sta facendo riferimento alla discussione di qualche mese fa, forse anche 1 annetto circa. Siamo andati avanti per non so quante pagine...

x64 ha numerosi registri, anche a 8bit, e può accedere anche agli 8bit passi di RSI e RDI. Sotto un OS a 32bit non te ne rendevi conto, ma in realtà i programmi a 16bit venivano comunque emulati: NTVDM.

Ipotesi: se si riuscisse ad accedere in qualche modo, usando la programmazione più l' ingegno e la creatività, alla legacy mode e senza disconnettersi da Windows 64 bit allora sarebbe bello. Windows 64 bit accede solo alla Long mode e quindi foose magari creare un mini-kernel semplice all' interno che sia a 32 bit ma che possa comunicare all' esterno dell' O.S ed accedere alla lelacy mode. Poi il programma a 16 bit tramite altre codice (se serve) si interfaccia con questo mini-kernel 32 bit.
Poi è anche vero che a partire da Windows 2000 in poi,ogni versione è diventata piano piano sempre più blindata e le limitazione per quanto riguarda la programmazione basso livello/medio livello sono aumentate. Windows 10 sarà tipo Fort Knox :lol:
Stai iniziando a parlare di racconti, come in quel precedente topic citato sopra però. :P

Non basta nel mio caso una solo cpu virtuale?
Non capisco a cosa possa servirmi il bus PCI, in questo caso.

Hai detto bene "la salvezza". Se sceglierò l' opzione della virtualizzazione sicuramente mi affiderà ad una delle soluzioni del genere. Non so cosa devo cercare su "google" per trovarle.
Ho visto Qemu e non lo conoscevo. Per quello che devo fare io è avanzato e troppo complesso. Non so se sia possibile lasciare solo il codice che permetta di fare solo le cose che ho menzionato sopra.

Con una di queste soluzioni del genere alla fine avrà 1 solo file che poi possa essere avviato su qualsiasi S.O. 7,8, 8.1 e 10 senza scaricare nessun altro programma o/e file?

L' opzione dell' emulazione è meno complessa oppure no?

L'emulazione delle periferiche è necessaria in quanto il sistema operativo che gira li sopra non deve accorgersi di non essere sull'HW (è un pò forzata, ma fatico ad esprimermi diversamente vista l'ora).
Devi entrare nell'ottica che il codice macchina che hai generato non può essere eseguito su un OS a 64bit. Mettendolo su un emulatore del DOS il tuo programma verrà interpretato dall'emulatore, così da poter decodificare le istruzioni, e ad esempio le chiamate alle INT come una INT 09h per la stampa a schermo di una stringa causerà la chiamata della relativa ISR del sistema operativo.
Magari il programma si ferma in attesa di input, invocando quindi la relativa ISR: a questo punto tutto è fermo, sino a che non premi un tasto sulla tastiera. Il tasto che premi, in realtà, manderà un impulso al PIC (emulato) ed avviserà la CPU (emulata) che c'è un interrupt HW da eseguire...
Ancora una volta verrà chiamata la procedura nella IVT, che è una ISR che andrà a leggere dal buffer della tastiera (emulato) etc etc.

Come vedi non è cosa immediata.
Sopra, quando parlavo di un programma che carica il tuo a 16bit, non facevo riferimento ad un OS: ecco perchè ho specificato che anche tutte le INT (o meglio, le relative ISR) sarebbero da implementare (almeno tutte quelle utilizzate). Si tratta in sostanza di avere un emulatore della CPU e parzialmente del DOS (almeno per le ISR); ovviamente non può mancare la memoria virtuale.
E' tutto una semplificazione comunque... ti assicuro che le cose sono complesse.



Ora le mie considerazioni...
Avevamo già affrontato discorsi sull'asm a 16bit, sul DOS etc etc. Non capisco a cosa ti serva scrivere qualcosa per il DOS nel 2019 che vada oltre l'apprendimento base dell'architettura e dell'asm a 16bit. Vuoi scrivere qualcosa in asm? Scrivilo per un 32bit...
Oltretutto a fronte delle limitazioni imposte. La scelta come diceva anche pabloski è tra emulazione e virtualizzazione, non ci sono altre strade, semplicemente perchè: o esegui direttamente il programma (ma non puoi), o lo fai eseguire (e quindi lo emuli).
Chiaramente sei libero di scrivere programmini a 16bit, ci mancherebbe! :) Tuttavia le cose non cambiano: se vuoi eseguirlo sotto 64bit, emuli.

Le alternative per gli emulatori son tante. Guardati anche DOSBox, DOSEmu, Emu8086... solo per citare quelli che sono i più popolari.

In conclusione, questo è uno dei sorgenti forniti come esempio da Emu8086 (ho allegato anche il COM):
Codice:
name "hi-world"

; this example prints out  "hello world!"
; by writing directly to video memory.
; in vga memory: first byte is ascii character, byte that follows is character attribute.
; if you change the second byte, you can change the color of
; the character even after it is printed.
; character attribute is 8 bit value,
; high 4 bits set background color and low 4 bits set foreground color.

; hex    bin        color
;
; 0      0000      black
; 1      0001      blue
; 2      0010      green
; 3      0011      cyan
; 4      0100      red
; 5      0101      magenta
; 6      0110      brown
; 7      0111      light gray
; 8      1000      dark gray
; 9      1001      light blue
; a      1010      light green
; b      1011      light cyan
; c      1100      light red
; d      1101      light magenta
; e      1110      yellow
; f      1111      white

org 100h

; set video mode   
mov ax, 3     ; text mode 80x25, 16 colors, 8 pages (ah=0, al=3)
int 10h       ; do it!

; cancel blinking and enable all 16 colors:
mov ax, 1003h
mov bx, 0
int 10h

; set segment register:
mov     ax, 0b800h
mov     ds, ax

; print "hello world"
; first byte is ascii code, second byte is color code.

mov [02h], 'H'
mov [04h], 'e'
mov [06h], 'l'
mov [08h], 'l'
mov [0ah], 'o'
mov [0ch], ','
mov [0eh], 'W'
mov [10h], 'o'
mov [12h], 'r'
mov [14h], 'l'
mov [16h], 'd'
mov [18h], '!'

; color all characters:
mov cx, 12  ; number of characters.
mov di, 03h ; start from byte after 'h'

c:  mov [di], 11101100b   ; light red(1100) on yellow(1110)
    add di, 2 ; skip over next ascii code in vga memory.
    loop c

; wait for any key press:
mov ah, 0
int 16h

ret
Questo è uno screen del mio emulatore, visto che ne ho parlato; in realtà nella prima colonna ci sarebbe il cursore lampeggiante. :P
La finestra è creata con SDL2.
 

Allegati

Cibachrome

Utente Attivo
8,404
3,019
Hardware Utente
#10
Ho utilizzato C.
La meta è definibile concretamente solo definendo gli scopi reali. Che vuoi eseguire, precisamente?
Per il momento un programmino (senzala GUI) che stampa sullo schermo un piccola espressione aritmetica. L' avevo creato mesi fa.
Avevo creato due varianti e quindi 2 sorgenti. Sono leggermente/un pochino diversi:

Codice:
.MODEL Small
.STACK 100H
.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
  
.CODE
.STARTUP
  
      mov AX,@DATA    ;copia in AX il contenuto del .DATA
      mov DS,AX       ;copia nel segmento dei dati,il contenuto del .DATA
    
      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
Secondo:

Codice:
.MODEL small
.STACK 100H
.DATA

      at    DB ?      ;aperta tonda
      num1  DB ?      ;numero 4
      sim1  DB ?      ; +
      num2  DB ?      ;numero 2
                      ; + 
      num3  DB ?      ;numero 8
      sim2  DB ?      ; -
      num4  DB ?      ;numero 5
                      ; -
      num5  DB ?      ;numero 1
      ct    DB ?      ;chiusa tonda
      sim3  DB ?      ; =
      spac  DB ?      ;spazio
      res   DB ?      ;risultato
  
.CODE
.STARTUP
  
      mov AX,@DATA    ;copia in AX il contenuto del .DATA
      mov DS,AX       ;copia nel segmento dei dati,il contenuto del .DATA
  
      sub AL,?        ;sottrae ad AL,num3
      mov AL,?        ;copia in AL,num1
      add AL,?        ;somma in AL,num2
      sub AL,?        ;sottrae ad AL,num4
      mov res,AL      ;copia il valore di AL,in res
  
      mov DL,res      ;copia il valore di res,in DL
      mov DL,48
      mov AH,02H      ;stampa carattere sullo schermo
      int 21H
  
      mov AH,4CH      ;restituisce il controllo all' O.S
      int 21H     
  
END                   ;termina il programma
No, praticamente abbiamo detto qualcosa di simile.
Il programma a cui faccio riferimento io per emulare il tuo a 16bit deve emulare la CPU ed a questo punto le INT del DOS, almeno quelle che utilizzerai per certo (esempio: se non userai mai la modalità video, non serve implementare le INT di DOS e BIOS per la gestione della modalità video; in particolare la INT 10h del BIOS).

La differenza in ciò che dicevo io è che avresti un eseguibile, che è poi l'emulatore, che carica il COM e lo esegue, come farebbe Emu8086, QEmu, DOSBox etc etc.
L'alternativa a cui pensavo è attuabile solo considerando (1) la dimensione ridotta dei programmi che eseguirai, (2) della memoria a cui puoi accedere (la RAM emulata sarà poca). Sto ancora pensando quando sia fattibile... teoricamente si potrebbe utilizzare un programmino che scriva il binario direttamente in una sezione dell'EXE che si andrà ad eseguire.
All'avvio, al posto di caricare un file, verrà letta la sezione per intero (tanto le dimensioni emulate della RAM sono comunque ridotte, appunto) e caricate in memoria; da qui partirà l'emulazione per eseguire il tuo programma.
QEmu, Pabloski me lo ha proposto perchè permette invece di creare una macchina virtuale (cpu virtuale etc...) su cui eseguire il dos etc...
Emu8086 e Dosbox non c' entrano con la virtualizzazione ma sono solo degli emulatori. Per certi cose emulatore e virtualizzori sembrano uguali boh.

Quello che dicevi tu all' inizio riguarda un file COM 16 bit 8086 mentre l' alternativa riguarda un file .EXE 16 bit. Però alla fine ovviamente il file non sarà a 16 bit ma a 32 bit.
L' argomento per me è complesso e mi sono un pochino perso.

Difficilmente riuscirò entro domani se non so nemmeno che vuoi eseguire... :D
Eseguire il tuo non sarebbe un problema, a patto che gli opcodes che ho attualmente siano sufficienti; mi stavo concentrando sulla memoria video ed altri dettagli, trascurando le istruzioni.

Ti dicevo di comprimerlo per evitare qualsiasi limite di upload dovuto ad esempio all'estensione.

Puoi anche utilizzare qualche tecnica come la "ricompilazione dinamica", ma non mi sembra il caso... :)
Non c'è nessuna fretta da parte mia.
Speriamo che gli opcodes siano sufficienti :)

Non ho capito la frase sull' upload etc...
So che il limite max di un file COM è 64 kbyte. Se ho un sorgente che ha un peso inferiore allora non devo comprimerlo giusto?

Non so cos'è la ricompilazione dinamica e non vado a cercare su google perchè altrimenti mi confondo.

Sta facendo riferimento alla discussione di qualche mese fa, forse anche 1 annetto circa. Siamo andati avanti per non so quante pagine...

x64 ha numerosi registri, anche a 8bit, e può accedere anche agli 8bit passi di RSI e RDI. Sotto un OS a 32bit non te ne rendevi conto, ma in realtà i programmi a 16bit venivano comunque emulati: NTVDM.
Non mi pare che in quella discussione si era parlato di long mode e V86-mode, boh.
Non so cosa siano RSI e RDI.
Sapevo che da Windows 95 in poi ci fosse un emulatore DOS. Esso ovviamente non è presente nelle versioni a 64 bit.
Windows 98 e forse anche 98 SE erano gli ultimi O.S che avevano la possibilità di uscire dal sistema operativo ed avviare l' O.S. Ms dos.
Con Windows ME poi c'è stata tipo un limitazione per quanto riguarda l' emulatore DOS.

Stai iniziando a parlare di racconti, come in quel precedente topic citato sopra però. :P
Io invece ho scritto un ipotesi (che riguarda la legacy mode) affinchè qualcuno mi potesse dire se era fattibile a livello tecnico. Se la risposta dovesse essere: "no" allora vorrei sapere/imparare il perchè.

L'emulazione delle periferiche è necessaria in quanto il sistema operativo che gira li sopra non deve accorgersi di non essere sull'HW (è un pò forzata, ma fatico ad esprimermi diversamente vista l'ora).
Devi entrare nell'ottica che il codice macchina che hai generato non può essere eseguito su un OS a 64bit. Mettendolo su un emulatore del DOS il tuo programma verrà interpretato dall'emulatore, così da poter decodificare le istruzioni, e ad esempio le chiamate alle INT come una INT 09h per la stampa a schermo di una stringa causerà la chiamata della relativa ISR del sistema operativo.
Magari il programma si ferma in attesa di input, invocando quindi la relativa ISR: a questo punto tutto è fermo, sino a che non premi un tasto sulla tastiera. Il tasto che premi, in realtà, manderà un impulso al PIC (emulato) ed avviserà la CPU (emulata) che c'è un interrupt HW da eseguire...
Ancora una volta verrà chiamata la procedura nella IVT, che è una ISR che andrà a leggere dal buffer della tastiera (emulato) etc etc.
Come vedi non è cosa immediata.
Sopra, quando parlavo di un programma che carica il tuo a 16bit, non facevo riferimento ad un OS: ecco perchè ho specificato che anche tutte le INT (o meglio, le relative ISR) sarebbero da implementare (almeno tutte quelle utilizzate). Si tratta in sostanza di avere un emulatore della CPU e parzialmente del DOS (almeno per le ISR); ovviamente non può mancare la memoria virtuale.
E' tutto una semplificazione comunque... ti assicuro che le cose sono complesse.
Non ho mai pensato che fosse una cosa immediata.
Questa sintesi è un po' complicata per certe cose.
Se vorrai, durante, il giorno spiegherai il concetto in maniera non forzata :)
Io pensavo che fosse necessaria solo l' emulerazione di quelle perifiche che mi servono. Ad es. il floppy, la porta parallela, una scheda ISA, una scheda PCI, una scheda audio e una porta com, non mi servono per quello che devo.

Io sapevo che un emulatore era molto complesso. Forse nel mio caso, viste le mie esigenze ed il fatto che deve fare solo le cose che ho scritto sopra, sarà è un po' meno complesso.
Già un emulatore solo la cpu (8086) è difficile.

Di sicuro non voglio partire da zero o quasi.

Ora le mie considerazioni...
Avevamo già affrontato discorsi sull'asm a 16bit, sul DOS etc etc. Non capisco a cosa ti serva scrivere qualcosa per il DOS nel 2019 che vada oltre l'apprendimento base dell'architettura e dell'asm a 16bit. Vuoi scrivere qualcosa in asm? Scrivilo per un 32bit...
Oltretutto a fronte delle limitazioni imposte. La scelta come diceva anche pabloski è tra emulazione e virtualizzazione, non ci sono altre strade, semplicemente perchè: o esegui direttamente il programma (ma non puoi), o lo fai eseguire (e quindi lo emuli).
Chiaramente sei libero di scrivere programmini a 16bit, ci mancherebbe! :) Tuttavia le cose non cambiano: se vuoi eseguirlo sotto 64bit, emuli.

Le alternative per gli emulatori son tante. Guardati anche DOSBox, DOSEmu, Emu8086... solo per citare quelli che sono i più popolari.

In conclusione, questo è uno dei sorgenti forniti come esempio da Emu8086 (ho allegato anche il COM):

Questo è uno screen del mio emulatore, visto che ne ho parlato; in realtà nella prima colonna ci sarebbe il cursore lampeggiante. :P
La finestra è creata con SDL2.
Sono mesi che non creo un programma e che non mi dedico all' apprendimento dell' architettura, dell' asm, del C, del DOS etc...
Per quanto riguarda l' 80386 + l' architettura a 32 bit + manuali Intel assembly 32 bit + direttive Tasm 32 bit + Api Windows, non voglio mettere altra carne al fuoco e non voglio aumentare la difficoltà. Poi nel futuro si vedrà.
Nel 2019 ancora non ho creato un programma XD.
Io invece non ho capito perchè, per realizzare il tuo emulatore non hai utilizzato il C anzichè l' Asm 32 bit. Il C è più facile però a te piace l' assembly ed il basso livello :)

Ho capito qual'è la scelta. Le opzioni sono 2.

Ho visto lo screen del tuo emulatore :)
Ho visto il codice di Emu8086 però non è alla mia portata.[/QUOTE]
 
Ultima modifica:
#11
Ad es. c'è la legacy mode nel processore che è inutizzata.
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. Usare la modalità legacy significa usare OS a 32 bit. E questi stanno lentamente sparendo.

Ipotesi: se si riuscisse ad accedere in qualche modo, usando la programmazione più l' ingegno e la creatività, alla legacy mode e senza disconnettersi da Windows 64 bit allora sarebbe bello.
E' come temevo. No, non è possibile. Altrimenti perchè creare WOW64?

Windows 64 bit accede solo alla Long mode e quindi foose magari creare un mini-kernel semplice all' interno che sia a 32 bit ma che possa comunicare all' esterno dell' O.S ed accedere alla lelacy mode. Poi il programma a 16 bit tramite altre codice (se serve) si interfaccia con questo mini-kernel 32 bit.
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.

Non basta nel mio caso una solo cpu virtuale?
Non capisco a cosa possa servirmi il bus PCI, in questo caso.
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.

Ho visto Qemu e non lo conoscevo. Per quello che devo fare io è avanzato e troppo complesso. Non so se sia possibile lasciare solo il codice che permetta di fare solo le cose che ho menzionato sopra.
Se Qemu è complesso non ti resta altro che un emulatore DOS.

Con una di queste soluzioni del genere alla fine avrà 1 solo file che poi possa essere avviato su qualsiasi S.O. 7,8, 8.1 e 10 senza scaricare nessun altro programma o/e file?
No, Qemu è pensato per fornire soluzioni di virtualizzazione, non singoli binari. 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?

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.
 
Mi Piace: Andretti60
566
321
Hardware Utente
CPU
Intel i7 6700HQ, 2.60Ghz, 4 core 8 threads
Scheda Madre
Asustek
Hard Disk
Hitachi 7200 rpm, 1TB
RAM
16GB DDR4 (2 slot su 4)
Scheda Video
Nvidia Geforce GTX 960M, 4GB
Scheda Audio
Realtek
Sistema Operativo
Windows 10 64bit
#12
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.

Io invece non ho capito perchè, per realizzare il tuo emulatore non hai utilizzato il C anzichè l' Asm 32 bit. Il C è più facile però a te piace l' assembly ed il basso livello
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.



Io pensavo che fosse necessaria solo l' emulerazione di quelle perifiche che mi servono. Ad es. il floppy, la porta parallela, una scheda ISA, una scheda PCI, una scheda audio e una porta com, non mi servono per quello che devo.
Lascia perdere PCI, come ha precisato pabloski, non esisteva (quindi non è da emulare).

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.

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.

Nel tuo caso senza emulatore servirebbe qualcosa di "fatto su misura" e limitato, ma si tratterebbe sempre di un emulatore. 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.
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.

Già un emulatore solo la cpu (8086) è difficile.
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.
 
Mi Piace: Andretti60

Cibachrome

Utente Attivo
8,404
3,019
Hardware Utente
#13
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]
 

Allegati

#14
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.
Ho letto ma non vedo interpretazioni. Semplicemente c'è scritto che esiste la modalità V86, che però esiste in P-mode ( 32 bit ). Se avvii il processore in P-mode puoi usare la V86. Se lo avvii in long mode, non puoi usarla. IA-32e è un modo per confondere la gente, perchè indica l'unione della long mode e della modalità legacy ( che per cpu x86_64 è la P-mode ). Ma in ogni caso niente V86.

WoW64 fa dei magheggi e consente di far girare programmi a 32 bit in long mode. Linux fa lo stesso con le sue lib32-blahblah.


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.
Ma il punto è che non puoi far "girare due kernel" su un'unica CPU. Se fosse possibile avrebbero inventato la virtualizzazione? Il processore è un ciclo che legge istruzioni, le decodifica e le esegue. Il multiplexing di più programmi/flussi di istruzioni avviene perchè c'è un pezzo di software sotto che lo fa. Questo pezzo di software in molti casi fa proprio parte del kernel del sistema operativo.

Quello che puoi fare è avviare una macchina virtuale nella quale farai girare un altro kernel, con altri programmi e nella modalità preferita.

L' abi x32 è un opzione. Non so è possibile a livello hardware scrivere puntatori a 16 bit.
x32 non ha niente da spartire coi 16 bit. x32 è x86_64 ma con puntatori a 32 bit.

l' abi x16 quindi a 16 bit è possibile a livello hardware (es. il processore)?
E' noto che le cpu x86 supportano la modalità reale a 16 bit. Anzi appena attive partono in modalità reale, ed è compito del kernel settarle prima in p-mode e poi in long mode. Ma il punto è che se Mario sta usando Windows 10, starà quasi sicuramente funzionando in long mode. E non c'è scampo in quel caso. Mario potrà usare i programmi a 16 bit solo se starà usando il DOS ( al 100% impossibile ).

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.
No, l'hardware non permette cose del genere. Una cpu settata in long mode, ad esempio, considera che le stack entry sono a 64 bit. Cioè ogni push/pop muove 64 bit alla volta. Non puoi dirgli di muovere 32 o 16 bit a piacere. E questo è un caso banale, benchè molto chiaro e comprensibile. C'è di peggio oltre.

Io vorrei conoscere la verità, i limiti hardware e gli eventuali limiti software.
La verità è scritta nei manuali. I manuali Intel sono pubblici. C'è poi un ottimo wiki su osdev.org, con articoli riassuntivi che spiegano molto bene queste cose https://wiki.osdev.org/Expanded_Main_Page

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.
Ma tu solo una modalità puoi impostare. Non puoi dire al processore di fare il saltimbanco.

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.
Sei fuori strada. Non viene cambiata la modalità del processore. Tant'è che in una delle slide che hai postato e anche qui https://docs.microsoft.com/it-it/windows/desktop/WinProg64/running-32-bit-applications

c'è scritto "WOW64 is the x86 emulator"

Quello che WoW64 fa, è convertire i dati passati alle syscall del kernel NT da/a 64 bit. La restante parte dell'emulatore sono versioni a 32 bit delle principali librerie di sistema ( a cominciare da Ntdll.dll e kernel32.dll ).

L'hai letto? Se lo leggi, noterai che per switching lui intende lato software. In nessun momento la CPU viene fatta passare in P-mode. Il punto è che l'IA-32e supporta l'accesso ai registri a 32 bit. In un programma x86_64 tu puoi usare RAX, ma puoi benissimo usare AX ( che è a 32 bit ). Per questa ragione il software a 32 bit può continuare a fare i suoi comodi, finchè...finchè non deve comunicare col kernel. Ed è lì che WoW64 agisce, implementando le syscall secondo le regole dell'ABI x86_64.

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.
No. Quando Windows parla di "compatibility" sta parlando di emulazione. E faccio notare che Windows 10 supporta vari meccanismi di virtualizzazione leggeri, che vengono messi in campo in maniera del tutto trasparente all'utente. Fanno girare addirittura programmi Linux!!!

Un' altra opzione riguarda i segment a 16 bit nella long mode.
I segmenti sono deprecati in long mode.

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
Ma se hai i sorgenti, fai prima a portare il programma a 16 bit verso 32 o 64 bit. Perchè diavolo fare tutto questo ambaradan? Avrebbe senso solo per quei programmi di cui non si hanno i sorgenti.


Intendevo un programma che permette di virtualizzare ma che fosse custom, più limitato e più semplice di Qemu.
Certo che ci sono. Ma comunque i programmi si aspettano di trovare un certo ambiente d'esecuzione, che in genere comprende pure un sistema operativo.

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.
Certo che si può fare. E infatti questo dicevo. Una macchina virtuale è come un processore a parte che si sta avviando da spento.

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.
E si può fare pure questo. L'embedding di vari binari in un singolo binario è una tecnica usata da 40 anni. Però è complessa da implementare.
 
566
321
Hardware Utente
CPU
Intel i7 6700HQ, 2.60Ghz, 4 core 8 threads
Scheda Madre
Asustek
Hard Disk
Hitachi 7200 rpm, 1TB
RAM
16GB DDR4 (2 slot su 4)
Scheda Video
Nvidia Geforce GTX 960M, 4GB
Scheda Audio
Realtek
Sistema Operativo
Windows 10 64bit
#15
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.
Avevo compilato il tuo codice comunque, mi ero scordato di dirtelo, e poi l'ho eseguito sul mio emulatore; gli opcodes che utilizzi fanno parte di quelli implementati:

 

Discussioni Simili


Entra