U
Utente 125751
Ospite
Ciao a tutti
Premetto che non ho intenzione di creare nessun s.o. e ne di realizzare le cose che chiederò in questa discussione ma se per favore mi potete rispondere come se per assurdo dovessi realizzarle(cosa che non farò mai in vita mia).
La microsoft aveva rilasciato, come ben sapete due versioni di window 7, una a 32 bit e l'altra a 64 bit(ognuna delle quali ha altre versioni).
Windows 7 32 bit, chiaramente non legge i programmi a 64 bit e legge una quantitativo di ram tra i 3/4 gb max. e per usare i programmi a 64 bit bisogna installare windows 7 64 bit che chiaramente legge moltissime programmi a 32 bit ma non legge i programmi a 16 bit. Per poter far girare questi programmi(16 bit) dentro a 7 64 bit bisogna installare o una macchina virtuale con un s.o a 16 o 32 bit oppure un emulatore per ms-dos, es. dosbox.
E possibile creare un S.O. multitasking su cui posso far girare tutti programmi windows a 16, 32 e a 64 bit? E' possibile far in modo che su questo s.o. si possano installare sia driver a 32 bit e che driver a 64 bit in modo che i programmi, tools, giochi etc..a 16, 32 e 64 bit possono girare ed interfacciarsi con l'hardware. Se si non so se bisogna cambiare il kernel. Intendo che magari un kernel monolitico non bene per questo scopo. Chiaramente i programmi a 16 bit leggeranno una quantitativo molto inferiore rispetto alla ram fisica.
Come si realizza? Che struttura deve avere?
Chiaramente la Cpu del computer sarà a 64 bit.
E possibile invece, tralasciando per un momento il copyright, licenze, brevetti e leggi giuridiche, unire windows 7 32 bit professional a windows 7 64 bit professional(unire i due kernel etc..etc..) ed affiancare i relativi driver(un programma a 16 bit si interfaccia con il driver a 32 bit, tramite emulazione[come avviene in windows xp] un programma a 32 bit si interfaccia o con il driver a 32 bit o con il driver a 64 bit, magari a scelta dell' utente esperto, invece i programmi a 64 bit si interfacciano con i driver a 64 bit)? Poi i driver tramite le api(etc.. etc..) si interfacciano all' hardware. Come si fa? Chiaramente ipotizzando di avere i codici sorgenti.
Poi un ultima cosa, dato che su windows 7 qualsiasi versione sia a 32 bit che a 64 bit c'è il problema con la lettura dei floppy dato che questa funzionalità non è stata finita di programmare. E' possibile creare un tools che permetta di colmare le lacune e poter leggere e scrivere sui floppy a manetta(permetta anche di formattarli etc..)?? Come per windows media player hanno creato un tools o programma aggiuntivo che permette di leggere i file avi su windows media player.
Se per favore potete prendere questa discussione seriamente(spiegandomi sia a livello teorico che pratico, chiaramente in generale[non nei particolari]) anche se non ho intenzione di realizzare le cose scritte in precedenza e anche se esistono varie soluzioni per avviari programmi etc.. a 16 bit attraverso altri programmi.
Grazie mille a chi mi risponderà
Scusate per il poemaXD
- - - Updated - - -
Originariamente Scritto da pabloski
No. I sistemi operativi a 32 bit ( girano in Protected Mode ) consentono ai programmi l'uso della modalità Virtual 86, che consente a questi programmi a 16 bit di girare. Nella modalità Long ( 64 bit ) le cpu non consentono l'uso della modalità Virtual 86, dunque i programmi a 16 bit non possono girare. E' una limitazione imposta dai microprocessori.
Come ho scritto sopra, i s.o. a 64 bit non consentono di avviare programmi a 16 bit ed infatti servono dei programmi di emulazione o macchine virtuali. Non capisco, se c'è una limitazione della cpu allora i programmi a 16 bit non possono girare su s.o. a 32 bit e tramite macchine virtuali o programmi di emulazione su s.o a 64 bit. Perchè il Virtual 86 non gira nella modalità long? La colpa sarà del kernel a 64 bit.
Ma se non si utilizza la virtual 86 e si trova un'altra maniera per risolvere questo problema, che ne pensi?. Io all' inzio parlavo di scrivere un s.o. da zero, compreso anche il kernel e chiaramente progettando una struttura a livello software diversa, progettando un nuovo tipo di kernel diverso(se creo un kernel monolitico a 64 bit con la modalità long starò al punto di partenza).
Driver e programmi sono separati. I driver a 32 bit non possono girare su kernel a 64 bit e viceversa. I programmi a 32 bit sono invece supportati dai sistemi a 64 bit, in quanto la modalità Long è un'estensione di quella Protected, per cui occorre solo che il sistema operativo fornisca apposite librerie a 32 bit.
Il tipo di kernel non c'entra in queste faccende.
Certo che programmi e driver sono separati. Io intendevo che un programma si interfaccia alla periferica(tramite le api) e che c'è bisogno del driver per far funzionare l'hardware e poter usare un programma relativo all' hardware in questione.
Come avevo detto io prima i driver 32 bit non possono girare su s.o. a 64 e bit e viceversa perchè il s.o. operativo e stato scritto, progettato a 64 bit. Il kernel c'entra perchè se fai un s.o a 64 bit con il relativo kernel a 64 bit e la long mode non potranno girare driver a 32 bit e programmi a 16 bit dato che la virtual 86 e il kernet a 32 bit non possono stare insieme. Quindi come come ho scritto sopra il s.o. non avrà il kernel a 64 bit e nemmeno quello a 32 bit, non avrà la virtual 86 mode, la protected mode e la long mode.
Le cpu x86 attuali supportano i 64 bit, ma supportano anche le modalità retrocompatibili Protected e Real ( 32 e 16 bit ).
Pure io ho scritto che si può utilizzare una Cpu a 64 bit dato che è retrocompatibile perfino con l'assembly 8086. Ma non era Virtual 86? Real e Virtual 86 sono la stessa cosa?XD
No. Un programma a 16 bit gira in un sistema a 32 bit senza problemi ( a patto che il sistema preveda questa possibilità ). Ma non girerà mai in un sistema a 64 bit, a meno di usare un emulatore/virtualizzatore.
QUando ho detto se era possibile unire i due s.o. (32+64 bit), intendevo modificare i due s.o. per farne diventare uno solo(modificando i due kernel, le tre mode(quelle che hai menzionato
e la struttura dei due s.o.). Certo se li metto uno a fianco all'altro non risolverò nulla dato che avrò gli stessi problemi di prima.
E comunque i programmi non s'interfacciano con i driver, ma con la libc, la quale invoca il kernel, che poi usa i driver.
Grazie per avermi corretto e grazie per avermi insegnato parecchie cose
Quello che vuoi è creare un device driver.
Originariamente Scritto da De Sire Dario
Come si crea un device driver?
http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644(v=vs.85).aspx
Originariamente Scritto da De Sire Dario
Non dovrò iniziare da capo dato che la funzionalità floppy è presente in windows 7 anche se non l'hanno completata.
Non mi è chiaro cosa intendi. Ho visto su vari forum che si dice che windows 7 e successivi non riescono proprio a gestire correttamente i floppy, evidentemente ci sono dei bug nei relativi driver.
Però tu non hai i sorgenti di quei driver, quindi l'unica cosa che puoi fare è crearne uno tu da zero.
Originariamente Scritto da De Sire Dario
Invece nel kernel ibrido e nel micro-kernel com'è la situazione (mi riferisco a programmi, driver, kernel e le tre mode[se ci stanno]) ?
L'architetttura dei kernel non ha nulla a che fare con i limiti imposti dall'hardware. Il problema relativo alla Long mode e alla V86 mode non dipende dal kernel, ma è un blocco imposto dal processore, cioè dall'hardware.
Premetto che non ho intenzione di creare nessun s.o. e ne di realizzare le cose che chiederò in questa discussione ma se per favore mi potete rispondere come se per assurdo dovessi realizzarle(cosa che non farò mai in vita mia).
La microsoft aveva rilasciato, come ben sapete due versioni di window 7, una a 32 bit e l'altra a 64 bit(ognuna delle quali ha altre versioni).
Windows 7 32 bit, chiaramente non legge i programmi a 64 bit e legge una quantitativo di ram tra i 3/4 gb max. e per usare i programmi a 64 bit bisogna installare windows 7 64 bit che chiaramente legge moltissime programmi a 32 bit ma non legge i programmi a 16 bit. Per poter far girare questi programmi(16 bit) dentro a 7 64 bit bisogna installare o una macchina virtuale con un s.o a 16 o 32 bit oppure un emulatore per ms-dos, es. dosbox.
E possibile creare un S.O. multitasking su cui posso far girare tutti programmi windows a 16, 32 e a 64 bit? E' possibile far in modo che su questo s.o. si possano installare sia driver a 32 bit e che driver a 64 bit in modo che i programmi, tools, giochi etc..a 16, 32 e 64 bit possono girare ed interfacciarsi con l'hardware. Se si non so se bisogna cambiare il kernel. Intendo che magari un kernel monolitico non bene per questo scopo. Chiaramente i programmi a 16 bit leggeranno una quantitativo molto inferiore rispetto alla ram fisica.
Come si realizza? Che struttura deve avere?
Chiaramente la Cpu del computer sarà a 64 bit.
E possibile invece, tralasciando per un momento il copyright, licenze, brevetti e leggi giuridiche, unire windows 7 32 bit professional a windows 7 64 bit professional(unire i due kernel etc..etc..) ed affiancare i relativi driver(un programma a 16 bit si interfaccia con il driver a 32 bit, tramite emulazione[come avviene in windows xp] un programma a 32 bit si interfaccia o con il driver a 32 bit o con il driver a 64 bit, magari a scelta dell' utente esperto, invece i programmi a 64 bit si interfacciano con i driver a 64 bit)? Poi i driver tramite le api(etc.. etc..) si interfacciano all' hardware. Come si fa? Chiaramente ipotizzando di avere i codici sorgenti.
Poi un ultima cosa, dato che su windows 7 qualsiasi versione sia a 32 bit che a 64 bit c'è il problema con la lettura dei floppy dato che questa funzionalità non è stata finita di programmare. E' possibile creare un tools che permetta di colmare le lacune e poter leggere e scrivere sui floppy a manetta(permetta anche di formattarli etc..)?? Come per windows media player hanno creato un tools o programma aggiuntivo che permette di leggere i file avi su windows media player.
Se per favore potete prendere questa discussione seriamente(spiegandomi sia a livello teorico che pratico, chiaramente in generale[non nei particolari]) anche se non ho intenzione di realizzare le cose scritte in precedenza e anche se esistono varie soluzioni per avviari programmi etc.. a 16 bit attraverso altri programmi.
Grazie mille a chi mi risponderà
Scusate per il poemaXD
- - - Updated - - -
Originariamente Scritto da pabloski
No. I sistemi operativi a 32 bit ( girano in Protected Mode ) consentono ai programmi l'uso della modalità Virtual 86, che consente a questi programmi a 16 bit di girare. Nella modalità Long ( 64 bit ) le cpu non consentono l'uso della modalità Virtual 86, dunque i programmi a 16 bit non possono girare. E' una limitazione imposta dai microprocessori.
Come ho scritto sopra, i s.o. a 64 bit non consentono di avviare programmi a 16 bit ed infatti servono dei programmi di emulazione o macchine virtuali. Non capisco, se c'è una limitazione della cpu allora i programmi a 16 bit non possono girare su s.o. a 32 bit e tramite macchine virtuali o programmi di emulazione su s.o a 64 bit. Perchè il Virtual 86 non gira nella modalità long? La colpa sarà del kernel a 64 bit.
Ma se non si utilizza la virtual 86 e si trova un'altra maniera per risolvere questo problema, che ne pensi?. Io all' inzio parlavo di scrivere un s.o. da zero, compreso anche il kernel e chiaramente progettando una struttura a livello software diversa, progettando un nuovo tipo di kernel diverso(se creo un kernel monolitico a 64 bit con la modalità long starò al punto di partenza).
Driver e programmi sono separati. I driver a 32 bit non possono girare su kernel a 64 bit e viceversa. I programmi a 32 bit sono invece supportati dai sistemi a 64 bit, in quanto la modalità Long è un'estensione di quella Protected, per cui occorre solo che il sistema operativo fornisca apposite librerie a 32 bit.
Il tipo di kernel non c'entra in queste faccende.
Certo che programmi e driver sono separati. Io intendevo che un programma si interfaccia alla periferica(tramite le api) e che c'è bisogno del driver per far funzionare l'hardware e poter usare un programma relativo all' hardware in questione.
Come avevo detto io prima i driver 32 bit non possono girare su s.o. a 64 e bit e viceversa perchè il s.o. operativo e stato scritto, progettato a 64 bit. Il kernel c'entra perchè se fai un s.o a 64 bit con il relativo kernel a 64 bit e la long mode non potranno girare driver a 32 bit e programmi a 16 bit dato che la virtual 86 e il kernet a 32 bit non possono stare insieme. Quindi come come ho scritto sopra il s.o. non avrà il kernel a 64 bit e nemmeno quello a 32 bit, non avrà la virtual 86 mode, la protected mode e la long mode.
Le cpu x86 attuali supportano i 64 bit, ma supportano anche le modalità retrocompatibili Protected e Real ( 32 e 16 bit ).
Pure io ho scritto che si può utilizzare una Cpu a 64 bit dato che è retrocompatibile perfino con l'assembly 8086. Ma non era Virtual 86? Real e Virtual 86 sono la stessa cosa?XD
No. Un programma a 16 bit gira in un sistema a 32 bit senza problemi ( a patto che il sistema preveda questa possibilità ). Ma non girerà mai in un sistema a 64 bit, a meno di usare un emulatore/virtualizzatore.
QUando ho detto se era possibile unire i due s.o. (32+64 bit), intendevo modificare i due s.o. per farne diventare uno solo(modificando i due kernel, le tre mode(quelle che hai menzionato
E comunque i programmi non s'interfacciano con i driver, ma con la libc, la quale invoca il kernel, che poi usa i driver.
Grazie per avermi corretto e grazie per avermi insegnato parecchie cose
Quello che vuoi è creare un device driver.
Originariamente Scritto da De Sire Dario
Come si crea un device driver?
http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644(v=vs.85).aspx
Originariamente Scritto da De Sire Dario
Non dovrò iniziare da capo dato che la funzionalità floppy è presente in windows 7 anche se non l'hanno completata.
Non mi è chiaro cosa intendi. Ho visto su vari forum che si dice che windows 7 e successivi non riescono proprio a gestire correttamente i floppy, evidentemente ci sono dei bug nei relativi driver.
Però tu non hai i sorgenti di quei driver, quindi l'unica cosa che puoi fare è crearne uno tu da zero.
Originariamente Scritto da De Sire Dario
Invece nel kernel ibrido e nel micro-kernel com'è la situazione (mi riferisco a programmi, driver, kernel e le tre mode[se ci stanno]) ?
L'architetttura dei kernel non ha nulla a che fare con i limiti imposti dall'hardware. Il problema relativo alla Long mode e alla V86 mode non dipende dal kernel, ma è un blocco imposto dal processore, cioè dall'hardware.
Ultima modifica da un moderatore: