Stai usando un browser non aggiornato. Potresti non visualizzare correttamente questo o altri siti web. Dovreste aggiornare o usare un browser alternativo.
Su Windows 32/64 bit, ci sono differenze tra Bios Legacy ed Uefi per quanto riguarda la programmazione I/O in C/Assembly? Se si, quali sono?
Con Windows 32 bit mi riferisco a: Windows 95,98, 2000, XP, Server 2008, Windows 7 e 10. Però effettivamente 95 e 98 sono sistemi operativi ibridi a 16-32 bit.
Con Windows 64 bit mi riferisco a: 7, Server 2008 R2, Server 2016/2019 e Windows 10.
Con programmazione intendo: 16 bit, 32 bit e 64 bit. Programmi Console, programmi TUI/COW e quelli con la GUI.
Per I/O mi riferisco alla porta parallela LPT (in: SPP, EPP e ECP), porta seriale RS-232, porta usb in VCP, porta usb, scheda video (registri etc...), scheda audio, slot PCI e quello Pci-express.
Per quanto riguarda la programmazione ( ampio spettro) in C/Assembly volevo sapere se ci sono differenze tra:
1) Windows Server 2008 e Vista. Hanno lo stesso kernel.
2) Windows server 2008 R2 e Windows 7. Tra i due il kernel è lo stesso.
3) Windows Server 2016 quindi 10 fino alla versione 1809 (forse pure quella 1903). Anche queste versioni tra di loro hanno lo stesso kernel
4) Windows server 2019 (non la prima versione) e Windows 10 1909 (forse pure quella precente) e successiva. Ho letto l' anno scorso che Microsoft ha integrato nel Kernel Windows una versione modificata del Kernel Linux. Ho letto che con Windows server 2019 ci sono opzioni/funzioni in più che riguardano Linux. Di più non so.
Se, si quali sono?
Per i programmi 16 bit dos su Windows 64 bit uso un emulatore oppure una VM.
So che a partire dal primo sistemo operativo Windows NT, in poi, non è più possibile accedere direttamente all' hardware e quindi ok. Le applicazioni lato utente si trovano nel ring 3 mentre solo nel ring 0 (dove c'è il kernel) si può accedere all' hardware. Solo un driver può accedere al ring 3. L' utente anche con l' account predefinito "Amministratore" non può accedere al ring 0 e forse nemmeno al ring 1 e al ring 2. Sui S.O. NT bisogna utilizzare o un libreria esterna + un driver generale oppure in alternativa un driver specifico.
All' inizio vorrei imparare a programmare una delle seguenti porte: "LPT, rs-232 e usb in VCP" usando il linguaggio C 32/16 bit e la console di Windows.
Non capisco la fissazione con 16/32/64 bit. In genere si usa quello che si ha. Se stai programmando un x86-64 su Windows 10, perchè mai dovresti voler programmare a 16 bit? Ben sapendo che quel programma verrebbe fatto girare in un emulatore che Windows avvia in maniera trasparente.
Cioè la modalità di esecuzione è fissata dal sistema operativo e NON PUOI CAMBIARLA!! Ne abbiamo già discusso un annetto fa, se ricordi.
Non sei tu a stabilire se la macchina girerà in long mode, p-mode o real mode. E' il sistema operativo. E devi adattarti. Esiste una sola eccezione ( che sta scomparendo oltretutto ) ed è quella delle librerie di compatibilità a 32 bit, pensate per far girare software a 32 bit su sistemi operativi a 64 bit.
Questo perchè, dal punto del vista dell'esecuzione, la modalità a 32 bit può essere incastonata in quella a 64 bit. Cioè hai accesso a tutte le istruzioni e a tutti i registri della modalità a 32 bit, anche in modalità a 64 bit. I metodi d'indirizzamento sono gli stessi ( tanto la segmentazione non era usata nemmeno a 32 bit ). Ragion per cui, un piccolo supporto da parte del loader e una manciata di librerie che fungono da wrapper, e il gioco è fatto.
Poi, riguardo l'I/O. Non puoi programmare l'I/O in un sistema operativo moderno. L'unica possibilità è usare le API fornite dai driver del sistema operativo. Cerca su Google ioctl, per farti un'idea.
Potresti ovviamente realizzare un driver, ma anche in questo caso devi sfruttare le funzioni messe a disposizione dal sistema operativo per l'I/O a mappa di I/O e quello mappato in memoria. Il punto è che non invocherai mai, dal tuo programma, le istruzioni IN e OUT.
UEFI e Bios non c'entrano un tubo. Se programmi l'hardware, bypassi tutto quello che c'è in termini di software. Altrimenti a che pro? Se usi il sistema operativo, non è affar tuo se lui usa parzialmente o meno le API del BIOS/UEFI.
Se vuoi creare un'applicazione UEFI, è ancora un altro paio di maniche. Ma in quel caso, si suppone, il tuo programma venga eseguito SENZA un sistema operativo.
Le differenze tra i kernel non ti riguardano. Tu parli col SO tramite API. E le API di Windows sono notoriamente stabili. Chiaro che c'è un gap tra Win9x e NT. Ma questo è. Da Windows NT a Windows 10, moltissimo è rimasto tale e quale.
Le opzioni Linux di cui parli, sono WSL, ovvero una macchina virtuale che fa girare una distribuzione Linux dentro Windows. Non vedo perchè debbano riguardare la programmazione I/O.
Ma la domanda è: "sai, a livello teorico, come funziona l'I/O"? Perchè altrimenti è impossibile che tu possa programmare un dispositivo del genere. Tanto per dire, sai come inviare un messaggio qualsiasi/comando ad un dispositivo USB? Quanti dispositivi sono coinvolti e perchè? Qual è il ruolo degli interrupt?
Io direi di procurarti un libro come Architettura e organizzazione dei calcolatori di Stallings e cominciare a studiarlo.
E ti consiglio vivamente di procurarti un Raspberry PI o similare e giocare con quello. O meglio ancora un Arduino, visto che espone, senza mezzi termini, la macchina, il bare metal. Senza intermediari. Senza BIOS. Senza UEFI. E senza sistema operativo.
Non capisco la fissazione con 16/32/64 bit. In genere si usa quello che si ha. Se stai programmando un x86-64 su Windows 10, perchè mai dovresti voler programmare a 16 bit? Ben sapendo che quel programma verrebbe fatto girare in un emulatore che Windows avvia in maniera trasparente.
Cioè la modalità di esecuzione è fissata dal sistema operativo e NON PUOI CAMBIARLA!! Ne abbiamo già discusso un annetto fa, se ricordi.
Non sei tu a stabilire se la macchina girerà in long mode, p-mode o real mode. E' il sistema operativo. E devi adattarti. Esiste una sola eccezione ( che sta scomparendo oltretutto ) ed è quella delle librerie di compatibilità a 32 bit, pensate per far girare software a 32 bit su sistemi operativi a 64 bit.
Questo perchè, dal punto del vista dell'esecuzione, la modalità a 32 bit può essere incastonata in quella a 64 bit. Cioè hai accesso a tutte le istruzioni e a tutti i registri della modalità a 32 bit, anche in modalità a 64 bit. I metodi d'indirizzamento sono gli stessi ( tanto la segmentazione non era usata nemmeno a 32 bit ). Ragion per cui, un piccolo supporto da parte del loader e una manciata di librerie che fungono da wrapper, e il gioco è fatto.
Poi, riguardo l'I/O. Non puoi programmare l'I/O in un sistema operativo moderno. L'unica possibilità è usare le API fornite dai driver del sistema operativo. Cerca su Google ioctl, per farti un'idea.
Potresti ovviamente realizzare un driver, ma anche in questo caso devi sfruttare le funzioni messe a disposizione dal sistema operativo per l'I/O a mappa di I/O e quello mappato in memoria. Il punto è che non invocherai mai, dal tuo programma, le istruzioni IN e OUT.
UEFI e Bios non c'entrano un tubo. Se programmi l'hardware, bypassi tutto quello che c'è in termini di software. Altrimenti a che pro? Se usi il sistema operativo, non è affar tuo se lui usa parzialmente o meno le API del BIOS/UEFI.
Se vuoi creare un'applicazione UEFI, è ancora un altro paio di maniche. Ma in quel caso, si suppone, il tuo programma venga eseguito SENZA un sistema operativo.
Le differenze tra i kernel non ti riguardano. Tu parli col SO tramite API. E le API di Windows sono notoriamente stabili. Chiaro che c'è un gap tra Win9x e NT. Ma questo è. Da Windows NT a Windows 10, moltissimo è rimasto tale e quale.
Le opzioni Linux di cui parli, sono WSL, ovvero una macchina virtuale che fa girare una distribuzione Linux dentro Windows. Non vedo perchè debbano riguardare la programmazione I/O.
Ma la domanda è: "sai, a livello teorico, come funziona l'I/O"? Perchè altrimenti è impossibile che tu possa programmare un dispositivo del genere. Tanto per dire, sai come inviare un messaggio qualsiasi/comando ad un dispositivo USB? Quanti dispositivi sono coinvolti e perchè? Qual è il ruolo degli interrupt?
Io direi di procurarti un libro come Architettura e organizzazione dei calcolatori di Stallings e cominciare a studiarlo.
E ti consiglio vivamente di procurarti un Raspberry PI o similare e giocare con quello. O meglio ancora un Arduino, visto che espone, senza mezzi termini, la macchina, il bare metal. Senza intermediari. Senza BIOS. Senza UEFI. E senza sistema operativo.
Io non vedo la fissazione su 16/32/64 bit. Semplicemente esistono programmi, sistemi operativi ed hardware a 64 bit, 32 bit, 16 bit etc...
Qui, io non ho parlato della modalità di esecuzione e poi mica voglio cambiarla. Ho pure scritto sopra che per i programmi a 16 bit uso un emulatore oppure una VM.
Dato che hai menzionato quella discussione di 1 anno fa, mi viene in mente che ho saputo che ad es. ci sono quei programmi a 16 bit che, non sono compatibili con l' 8086 mode visto che non sono programmi dos 16 bit. Per caso sono programmi Win 16?
Sui sistemi operativi Windows a 64 bit c'è WOW64 per le applicazioni a 32 bit. Mi sa che intendevi questo. Anche su X86-64 se ho capito bene si possono occupare solo 8 oppure solo 16 bit di uno o più registri general purpose della cpu. Non so cosa sono i wrapper ed il loader. Non se il loader sarebbe il bootloader.
Io ho diversi computer. Non ho mai avuto modo fin'ora di programmare su Windows 10 e Windows Server. Sto programmando un X86-64 su Windows 7 64 bit (verrà affiancato a Windows 10) in C Win 32 console.
Per quanto riguarda l' I/O (non mi riferisco a monitor e tastiera) in C non è che voglio proprio programmare a 16 bit è solamente una delle varie opzioni alternative che sto valutando perchè la mia idea/opzione iniziale (Win 32 console e pc principale con la porta usb) è impossibile per me ora, viste determinate scelte fatte (da: Microsoft, altre aziende e consorzi) e visto com'è il mio livello di conoscenze/esperienza in programmazione etc... Anche per il disegno 2D, la GUI 2D etc... mi tocca considerare tra le opzioni anche la programmazione dos 16 bit. Non sono qui per criticare o/e fare polemica. Ho accettato le cose come stanno e vado avanti :)
Anche sui sistemi operativi moderni è possibile programmare l' I/O, PERO' non è possibile accedere direttamente all' hardware. Si può usare un DLL + un driver generico oppure in alterivativa un driver specifico.
Nel secondo link di Portlank che ho postato sotto ho trovato scritto questo: "Accessing I/O Ports under NT/2000/XP
There are two solutions to solving the problem of I/O access under Windows NT. The first solution is to write a device driver which runs in ring 0 (I/O privilege level 0) to access your I/O ports on your behalf. Data can be passed to and from your usermode program to the device driver via IOCTL calls. The driver can then execute your I/O instructions. The problem with this, is that it assumes you have the source code to make such a change.
Another possible alternative is to modify the I/O permission bitmap to allow a particular task, access to certain I/O ports. This grants your usermode program running in ring 3 to do unrestricted I/O operations on selected ports, per the I/O permission bitmap. This method is not really recommended, but provides a means of allowing existing applications to run under windows NT/2000. Writing a device driver to support your hardware is the preferred method. The device driver should check for any contentions before accessing the port."
Io sono alle prime armi e forse l' idea che mi hai proposto di creare un driver dovrebbe corrispondere alla seconda "Another possibile alternative etc..." . Non so cosa sia "the I/O permission bitmap" (vale anche tradotto in italiano).
Da quello che ho capito/visto in precedenza: la creazione di un driver su Windows (su Linux non lo so) quando si , per il momento è fuori dalla mia portata. E' un argomento che mi interessa, che vorrei imparare in C (per l' assembly si vedrà in futuro) partendo da zero anche uno che permetta di accende un solo diodo led con una resistenza in serie. Poi i driver base presenti nei vecchi (meno complessa) sistemi operativi Windows. Suppongo che anche qui un driver base dos 16 bit sia più semplice.
Poi ho anche letto su un sito che creare un driver con l' DDK di Windows è più complicato. Però da diversi anni c'è Poi c'è l' SDK di Windows.
Ora vedo che ci sono driver generici e driver specifici per l' I/O e non so cosa cambia effettivamente e qual è il livello di difficoltà di uno rispetto all' altro. Tra l' altro non so perchè e quindi non capisco perchè con un driver specifico I/O non c'è una libreria. Non è perchè voglio o penso che ci debba andare per forza ma è solamente a scopo didattico e perchè sono curioso.
Per quanto riguarda un driver specifico per l' I/O ho trovato questo:
Windows Serial Communications component library for C/C++. C++ developer tool for serial port communications programs; Supports RS232, multidrop RS422 and RS485 ports, virtual serial ports, usb to serial converter,Includes modem control,Ymodem, Xmodem, ASCII and ANSI terminal emulation.
Non so se ioctl si può usare anche per la usb in VCP/porta RS-232.
Inf effetti le istruzioni IN e OUT sono disponibili su 95,98 ed Me (oltre no), però non ho capito se si possono utilizzare anche per i programmi C Win 32 console (sempre su questi 3 O.S).
Mi piacerebbe, prima o poi, anche imparare la programmazione in C (assembly si vedrà) baremetal inziando da zero ad es. Bios Legacy programmi 32 bit senza GUI che stampano sulla schermo un numero intero o/e una lettera o/e una striga. E poi aumentare la gradualmente la difficoltà. Ora che mi viene se si arriva ad un determinato livello si potrebbe fare anche l' I/O in baremetal. Però non ne ho parlato perchè non riguarda questa discussione ed il mio obiettivo attuale e perchè non voglio mettere troppa carne sul fuoco.
Effettivamente con un microcontrollore non c'è il sistema operativo, il bios legacy/Uefi, i driver, le Api etc... ed anche questo ha i suoi pro/contro. Mi piacerebbe iniziare con un microcontrollore e l' embedded (ho già delle idee in mente XD) però non ne ho parlato perchè non riguarda questa discussione/mio obbiettivo, è una cosa per me aggiuntiva/complementare, non risolve i problemi/le lacune (etc...) che rimangono lì dove sono ed infile non voglio mettere troppa carne al fuoco.
Non ho nessun disposittvo/dispositivo usb che devo programmare.
Alla fine pensavo di andare sulla porta parallela oppure su quella rs-232 (+ convertitore to TTL) e di trovare un opzione meno complicata per scrivere programmi in C Win 32 console, senza usare le Api (se poi vengono usate dietro le quinte non m' importa), su Windows 95/98 o 2000/XP o successivi (che ho menzionato sopra). Altrimenti forse dovrei considerare la programmazione dos 16 bit magari optando per un sistema operativo Windows 32 bit o ibrido che ha le virtual DOS machine.
Ho creato un programmino (non è assolutamente finito) in Win32 Console in cui marca la parte relativa alla programmazione della porta parallela oppure della seriale. Esso permette di accendere o/e spegnere un led oppure anche di regolare la luminosità etc...
Per quanto riguarda l' I/O (non mi riferisco a monitor e tastiera) in C non è che voglio proprio programmare a 16 bit è solamente una delle varie opzioni alternative che sto valutando perchè la mia idea/opzione iniziale (Win 32 console e pc principale con la porta usb) è impossibile per me ora, viste determinate scelte fatte (da: Microsoft, altre aziende e consorzi) e visto com'è il mio livello di conoscenze/esperienza in programmazione etc...
Onestamente non capisco di che stai parlando. Scelte fatte? Opzioni? Non hai opzioni. Se programmi l'hardware sotto Windows a 64 bit DEVI obbligatoriamente programmare a 64 bit. Forse non è chiaro che non sei tu che decidi, ma il sistema operativo.
A che scelte ti riferisci esattamente? Alla modalità protetta? Surprise!! I moderni sistemi operativi non consentono l'accesso diretto all'hardware. E' un dato di fatto e non possiamo farci nulla.
E ho scritto nel post precedente che, se vuoi comunque accedere all'hardware, devi creare dei driver. Cioè gli unici programmi che possono accedere all'hardware in un sistema operativo moderno, sono i driver. E lo fanno nei limiti stabiliti dal sistema operativo.
Se tutto questo non ti piace, segui il mio consiglio e compra un Raspberry o un Arduino e inizia a programmare bare-metal.
Questa frase mi fa pensare che hai una mostruosa confusione in testa. Ti tocca considerare? Ma dove? Perché? Tu scrivi software per il DOS? No perchè altrimenti questi 16 bit non li vedi nemmeno col binocolo.
Anche sui sistemi operativi moderni è possibile programmare l' I/O, PERO' non è possibile accedere direttamente all' hardware. Si può usare un DLL + un driver generico oppure in alterivativa un driver specifico.
Leggi bene, perchè il range di possibilità è limitato. E non potrebbe essere altrimenti, senza entrare in conflitto col sistema operativo. L'hardware moderno è sottoposto a procedure di inizializzazione al boot, dopo le quali può cambiare le interfacce di comunicazione con l'esterno. E' quello che succede spessissimo a chi prova a fare il GPU passthrough e gli compare un bell'errore 43 nel device manager del guest Windows.
Infatti le istruzioni IN e OUT sono disponibili su 95,98 ed Me (oltre no) però non ho capito se si possono utilizzare anche per i programmi C Win 32 console.
Le istruzioni IN e OUT sono disponibili nell'ISA x86, non in Windows. E no, non si possono usare da parte del software applicativo. Sono istruzioni privilegiate, riservate al software che gira in modalità supervisore.
Poi ho anche letto su un sito che creare un driver con l' DDK di Windows è più complicato, quindi suppongo che in passato non era così complicato. Ora però ho visto che c'è l' SDK di Windows.
Ti vedo tirare fuori termini a casaccio e la cosa mi preoccupa.
DDK = driver development kit = kit per lo sviluppo dei driver
SDK = software development kit = kit per lo sviluppo del software ( applicativo )
sono due cose completamente diverse, con scopi totalmente opposti.
Ma ripeto: "cosa stai cercando di fare"? Se vuoi programmare direttamente l'hardware, non perdere tempo con Windows, Linux e x86. Vai di Raspberry in bare-metal.
E continuo a non capire la tua fissazione con questi 16 bit. E' uno sfizio? No perchè altrimenti nessuno, nel 2020, è obbligato a realizzare software a 16 bit, a meno che non lavori nel campo dei sistemi di controllo SCADA. Ma non credo sia il tuo caso.
Win32 è l'API storica di Windows. Soppiantata da WinRT in Windows 10. Ma comunque non c'entra con i 32 bit.
Se programmi l'hardware sotto Windows a 64 bit DEVI obbligatoriamente programmare a 64 bit. Forse non è chiaro che non sei tu che decidi, ma il sistema operativo.
Per sapere: perchè non c' entra con i 32 bit? :)
Io sapevo che Win32 (console o GUI o installer) fosse un programma a 32 bit. Infatti ad es. su Ms dos non può essere eseguito. Come ho scritto sopra sui sistemi operativi Windows a 64 bit i programmi a 32 bit vengono tipi "emulati" grazie a Wow64.
Così come Win64 (console o GUI o installer) è un programma a 64 bit. Infatti ad es. non può essere eseguito su un S.O Windows a 32 bit.
Quando sopra ho scritto "programmare a 32 bit", intendo "creare programmi a 32 bit". Stessa cosa vale per programmazione a i 64 bit etc... Nel primo post ho scritto in aggiunta anche:" Programmi Console, programmi TUI/COW e quelli con la GUI".
Se poi su un S.O. Windows 64 bit vengono occupati sempre e solo 64 bit, anche con i programmi a 32 bit a me non mi riguarda.
Spero che ora sia chiaro e non continui a fraintendere XD
Onestamente non capisco di che stai parlando. Scelte fatte? Opzioni? Non hai opzioni.
A che scelte ti riferisci esattamente? Alla modalità protetta? Surprise!! I moderni sistemi operativi non consentono l'accesso diretto all'hardware. E' un dato di fatto e non possiamo farci nulla.
E ho scritto nel post precedente che, se vuoi comunque accedere all'hardware, devi creare dei driver. Cioè gli unici programmi che possono accedere all'hardware in un sistema operativo moderno, sono i driver. E lo fanno nei limiti stabiliti dal sistema operativo.
Se tutto questo non ti piace, segui il mio consiglio e compra un Raspberry o un Arduino e inizia a programmare bare-metal.
Alle scelte per quanto riguarda le interfaccie rs-232 ed usb, alle Api Windows e sistemi operativi Windows compresi anche quelli NT. Sono tutti dati di fatto, NON posso farci assolutamente nulla e l' ho accettato. Quello che POSSO fare io invece è studiare, migliorare le mie conoscenze/capacità, fare tanta pratica in modo tale da poter capire, affrontare determinati argomenti, esercizi e problemi da risolvere con i mezzi (software, libri, hardware e documentazione) che ci sono a disposizione.
Ho aperto questa discussione perchè non sapevo se per la programmazione I/O in C/assembly se su Windows cambiasse qualcosa tra un computer con Bios Legacy ed uno con Bios Uefi. Non so se ad es. la porta parella o la seriale vanno configurate (nel Bios/ in Uefi) in modo diverso o/e hanno diversi indirizzi o/e ci sono altre cose di mezzo.
Poi non sapevo se ci sono differenze tra la programmazione in C/Assembly su un sistema operativo desktop ed uno server con lo stesso Kernel.
Io sto imparando il linguaggio C etc.... e a programmare in C Win 32 console. Programmo (per fare pratica) in Win 32 console.Voglio continuare questo persorso imparando ad es. Anche la programmazione in C Win32 Console utilizzando la porta porta parallela o/e la porta rs-232 e fare dei progetti a fine didattico/hobbystico.
Ho la possibilità di scegliere quale computer usare, quale architettura Intel usare/cpu Intel usare, quale sistema operativo usare (Win9x, 2000, XP 32 bit, Windows 2008, Windows 7 32/64, Windows Server 2016 Windows 10 32/64.) e quale interfaccia usare. Non ho scelto uno SCU (switch Control Unit) oppure un board con un microcontrollore on un SoC perchè non fanno parte di questo mio obiettivo.
Ho scritto ad es. un programma in C win32 console che non è assolutamente finito, per accendere o spegnere un led e controllare la sua luminosità quando è accesso.
Questa frase mi fa pensare che hai una mostruosa confusione in testa. Ti tocca considerare? Ma dove? Perché? Tu scrivi software per il DOS? No perchè altrimenti questi 16 bit non li vedi nemmeno col binocolo.
Ma esattamente cos'è che vuoi fare?
No, ti assicuro che non ho alcuna confusione a riguardo. L' anno scorso a livello didattico ho scritto un programmino in C dos per disegnare una linea e poi un cerchio. Questo solo perchè, per me, è più difficile/complicato farlo in Win32 e non ho un livello adatto per farlo.
Mesi fa avevo un esercizio in C Win32 console, da risolvere, per la generazione casuale di uno o 2 numeri interi. Mi sono documentato perchè volevo utilizzare rand/srand ma non sono proprio riuscito a capirle e quindi alla fine ho optato per una soluzione, sempre in C Win32 console, senza l' uso delle 2 funzioni.
Dopo aver scritto il messaggio precedente ho scoperto per puro caso che esistono 2 porting in Win32 delle librerie Borland BGI (presenti nei compilatori Borland C/C++) e quindi questo vuol dire che non mi tocca considerare la programmazione dos su Win per queste cose.
Per quanto riguarda l' I/O in C da quello che ho visto, per me, sarebbe meno complicata/difficile farla in Win95/98 oppure in dos. Ho visto/letto pure che per me, ad es. la programmazione in C l' interfaccia parellela e quella meno complicata/difficile rispetto alle altre.
Leggi bene, perchè il range di possibilità è limitato. E non potrebbe essere altrimenti, senza entrare in conflitto col sistema operativo. L'hardware moderno è sottoposto a procedure di inizializzazione al boot, dopo le quali può cambiare le interfacce di comunicazione con l'esterno. E' quello che succede spessissimo a chi prova a fare il GPU passthrough e gli compare un bell'errore 43 nel device manager del guest Windows.
Hai saltato le altre librerie che ho scritto.
Sono un super principiante in queste cose. Ho letto però più di tanto non riesco a capire. Però voglio impare e capire ^^.
Oltre al libro che mi hai consigliato che altro mi serve/mi è utile per sarpene di pi+ a riguardo? Non mi riferisco al gpu passthrough.
Le istruzioni IN e OUT sono disponibili nell'ISA x86, non in Windows. E no, non si possono usare da parte del software applicativo. Sono istruzioni privilegiate, riservate al software che gira in modalità supervisore.
Io ho letto questo che Su win95/98/me si possono utilizzare inp() e out() per programma in C/assembly della porta LPT.
Anche in Windows 95/98 non si possono utilizzare le istruzioni IN/OUT? E allora per sapere: dove si possono utilizzare?
Ti vedo tirare fuori termini a casaccio e la cosa mi preoccupa.
DDK = driver development kit = kit per lo sviluppo dei driver
SDK = software development kit = kit per lo sviluppo del software ( applicativo )
sono due cose completamente diverse, con scopi totalmente opposti.
E continuo a non capire la tua fissazione con questi 16 bit. E' uno sfizio? No perchè altrimenti nessuno, nel 2020, è obbligato a realizzare software a 16 bit, a meno che non lavori nel campo dei sistemi di controllo SCADA. Ma non credo sia il tuo caso.
Ora ho imparato/capito la differenza tra DDK ed SDK.
Non c'è nessuna fissazione in merito. Ti sei fissisato su questa cosa.
Questa discussione non riguarda il lavoro.
In pratica non vuoi concludere niente. Perchè mettere diecimila bistecche al fuoco, porta solo a creare confusione. Oggi, vuoi programmare a 16 a 32 o a 64 bit? Oggi!! Non tra 5 anni. Devi decidere.
Ma non è un'ISA. E' un'API. Stai parlando di cose completamente separate. Avrebbero benissimo potuta chiamarla WinDeluxeProgramSuperSpecial. Ma sempre l'API di Windows 3 sarebbe stata. E sempre su 8086 e successori avrebbe girato.
Quindi non c'entra nulla ai fini della programmazione a basso livello di cui parli. Tant'è che per programmare l'I/O ( come dici di voler fare ) non userai mai nè Win32 nè Win16 nè Win64 nè WinRT.
Per sapere: perchè non c' entra con i 32 bit? :)
Io sapevo che Win32 (console o GUI o installer) fosse un programma a 32 bit. Infatti ad es. su Ms dos non può essere eseguito.
No. E' un'API. Ed è l'API da Windows 95 in poi. Ma tutto questo non ha nulla a che fare col processore, con l'ISA e con la tua presunta volontà di programmare l'I/O.
Hai le idee massicciamente confuse. Win64 è un'API, non è un programma. Non esiste un programma di nome Win64. Win64 è l'API che estende Win32 per il supporto ai 64 bit.
Quando sopra ho scritto "programmare a 32 bit", intendo "creare programmi a 32 bit". Stessa cosa vale per programmazione a i 64 bit etc... Nel primo post ho scritto in aggiunta anche:" Programmi Console, programmi TUI/COW e quelli con la GUI".
Ho aperto questa discussione perchè non sapevo se per la programmazione I/O in C/assembly se su Windows cambiasse qualcosa tra un computer con Bios Legacy ed uno con Bios Uefi.
Certo, cambia il fatto che le periferiche dotate di firmware, ne hanno uno che supporta UEFI. Ma francamente nemmeno t'interessa, perchè tu parlerai con la periferica tramite le solite strategie. Ma sai quali sono queste strategie? Il punto sta tutto qui. Ti stai preoccupando di UEFI e BIOS, quando ancora non sai come fare materialmente a comunicare con la periferica d'interesse.
Non so se ad es. la porta parella o la seriale vanno configurate (nel Bios/ in Uefi) in modo diverso o/e hanno diversi indirizzi o/e ci sono altre cose di mezzo.
Dall'introduzione dello standard PCI, parecchie cose sono cambiate. E tant'è. UEFI non c'entra.
Inoltre, rimane sempre il problema che non puoi programmare liberamente l'hardware dall'interno di un sistema operativo. Quindi cosa scegli di fare? Andare di bare metal? Il DOS è un'eccezione, perchè non implementa la modalità protetta e quindi tutto il software gira in modalità supervisore e può accedere all'hardware. Ma parlo del DOS, il sistema operativo, quello che s'installa sul PC con i dischetti. Non parlo dell'emulatore NTVDM di Windows a 32 bit o di DosBox e compagnia cantante. E nemmeno dei vari DOS estesi a 32 bit, tipo DR-DOS.
Intanto perchè mischi C e Assembly? Mi pare siano parecchio distanti. Poi un kernel è un kernel e offre determinati servizi. Attorno ci sono altre librerie che aggiungono ulteriori servizi. Il tuo programma, in qualsiasi linguaggio sia, usa questi servizi. Quindi perchè dovrebbe essere differente? Perchè MS dovrebbe mettersi a creare un set di API per Windows Server e uno totalmente diverso per Windows Desktop? Gli ingegneri vanno pagati, mica lavorano aggratis.
Io sto imparando il linguaggio C etc.... e a programmare in C Win 32 console. Programmo (per fare pratica) in Win 32 console.Voglio continuare questo persorso imparando ad es. Anche la programmazione in C Win32 Console utilizzando la porta porta parallela o/e la porta rs-232 e fare dei progetti a fine didattico/hobbystico.
Programmare la porta parallela è diverso da programmare direttamente l'hardware. Intanto, il metodo preferito per accedere a queste porte, è di trattarle come file. Le si apre e si usano read e write per leggere/scrivere.
Ho la possibilità di scegliere quale computer usare, quale architettura Intel usare/cpu Intel usare, quale sistema operativo usare (Win9x, 2000, XP 32 bit, Windows 2008, Windows 7 32/64, Windows Server 2016 Windows 10 32/64.) e quale interfaccia usare.
programmare è un lavoraccio e richiede una valanga di tempo e questo quando ci si focalizza su una specifica tecnologia
tu invece stai allungando la zuppa, includendo di tutto e di più
fermo restando, che non si è più fighi se si programma a 16 bit, per cui non c'è ragione...anzi, in verità, la programmazione a 64 bit è più complessa
e ricorda che i PC hanno mantenuto una ferrea retrcompatibilità, il che vuol dire che la famosa porta parallela, è programmabile oggi, sotto UEFI, 64 bit, ecc... così come lo era ai tempi del DOS e dei 16 bit
c'è solo il piccolo intoppo del sistema operativo che blocca ogni accesso diretto all'hardware
Ho scritto ad es. un programma in C win32 console che non è assolutamente finito, per accendere o spegnere un led e controllare la sua luminosità quando è accesso.
No, ti assicuro che non ho alcuna confusione a riguardo. L' anno scorso a livello didattico ho scritto un programmino in C dos per disegnare una linea e poi un cerchio. Questo solo perchè, per me, è più difficile/complicato farlo in Win32 e non ho un livello adatto per farlo.
Mesi fa avevo un esercizio in C Win32 console, da risolvere, per la generazione casuale di uno o 2 numeri interi. Mi sono documentato perchè volevo utilizzare rand/srand ma non sono proprio riuscito a capirle e quindi alla fine ho optato per una soluzione, sempre in C Win32 console, senza l' uso delle 2 funzioni.
Per quanto riguarda l' I/O in C da quello che ho visto, per me, sarebbe meno complicata/difficile farla in Win95/98 oppure in dos. Ho visto/letto pure che per me, ad es. la programmazione in C l' interfaccia parellela e quella meno complicata/difficile rispetto alle altre.
Forse non mi sono spiegato. WINDOWS NON TI DA' LA POSSIBILITA' DI ACCEDERE AI REGISTRI DELL'HARDWARE!!! Il Dos di cui parli, è un banale emulatore che gira sotto Windows. Ha il supporto per un certo numero di periferiche virtuali, che poi mappa su quelle reali e tant'è. Non pensare nemmeno per un istante che tu possa accedere ai registri della porta parallela ( o altro ) da un emulatore DOS.
Hai saltato le altre librerie che ho scritto.
Sono un super principiante in queste cose. Ho letto però più di tanto non riesco a capire. Però voglio impare e capire ^^.
Oltre al libro che mi hai consigliato che altro mi serve/mi è utile per sarpene di pi+ a riguardo? Non mi riferisco al gpu passthrough.
Lascia stare il gpu passthrough. Era un esempio. Non c'entra con quello che vuoi fare. A te serve una solida conoscenza di come sono strutturati i computer e di quale ruolo riveste il sistema operativo.
Quindi un libro di architettura di calcolatori e uno dei sistemi operativi. Leggili e capirai parecchie cose.
Io ho letto questo che Su win95/98/me si possono utilizzare inp() e out() per programma in C/assembly della porta LPT.
Anche in Windows 95/98 non si possono utilizzare le istruzioni IN/OUT? E allora per sapere: dove si possono utilizzare?
Ed è questo che succede quando si leggono cose a casaccio e fuori contesto. Inp e Out da dove vengono fuori? Non sono istruzioni x86. Non sono istruzioni dell'API Win32/Win16/vattelapesca. Magari sono parte di una libreria che un tizio ha implementato per interfacciarsi con qualcosa nel kernel, che gli permette di accedere allo spazio di I/O di una periferica.
Python parallel port access library. Contribute to pyserial/pyparallel development by creating an account on GitHub.
github.com
noterai che il pattern è sempre lo stesso. Driver -> libreria userland -> programma applicativo.
Ripeto che la modalità protetta dei processori x86, mette al bando l'uso di istruzioni privilegiati ( leggi i manuali Intel a riguardo, se vuoi saperne di più ) da parte di software usermode. L'unico a poterle usare è il supervisore, cioè il sistema operativo. Ed è l'unico che può accedere alle porte di I/O e ai registri hardware.
Tutto il resto, è solo un trucco per chiedere al sistema operativo se ci dà accesso alla periferica.
Ora ho imparato/capito la differenza tra DDK ed SDK.
Non c'è nessuna fissazione in merito. Ti sei fissisato su questa cosa.
Questa discussione non riguarda il lavoro.
Si, ma a me pare che tu voglia mantenere il tutto su un livello filosofico. Non hai intenzione di fare. Se vuoi fare, comincia a scegliere una strada e seguila fino alla fine. Invece salti da un posto all'altro senza meta.
Se ti serve una risorsa veloce per accedere alle informazioni di basso livello sui computer, vai qui https://wiki.osdev.org/Main_Page
Devi leggere. Perchè vedo che non ti sono affatto chiare le interazioni tra hardware, sistema operativo, librerie, software applicativo.
E ricordo che eri allo stesso punto anche l'anno scorso. E per favore, non cercare più roba su internet, che poi estrapoli dal contesto e fai casini ( come la cosa di Inp e Out ).
In pratica non vuoi concludere niente. Perchè mettere diecimila bistecche al fuoco, porta solo a creare confusione. Oggi, vuoi programmare a 16 a 32 o a 64 bit? Oggi!! Non tra 5 anni. Devi decidere.
Si ma fammi capire come intendi fare mille cose contemporaneamente. Cioè, ad oggi, hai deciso cosa vuoi fare esattamente?
Si, ma a me pare che tu voglia mantenere il tutto su un livello filosofico. Non hai intenzione di fare. Se vuoi fare, comincia a scegliere una strada e seguila fino alla fine. Invece salti da un posto all'altro senza meta.
CVD non vuoi concludere niente
programmare è un lavoraccio e richiede una valanga di tempo e questo quando ci si focalizza su una specifica tecnologia
tu invece stai allungando la zuppa, includendo di tutto e di più fermo restando, che non si è più fighi se si programma a 16 bit, per cui non c'è ragione...anzi, in verità, la programmazione a 64 bit è più complessa
e ricorda che i PC hanno mantenuto una ferrea retrcompatibilità, il che vuol dire che la famosa porta parallela, è programmabile oggi, sotto UEFI, 64 bit, ecc... così come lo era ai tempi del DOS e dei 16 bit
c'è solo il piccolo intoppo del sistema operativo che blocca ogni accesso diretto all'hardware
Non capisco perchè sei malpensante nei miei confronti.
Hai frainteso quello che ho scritto e delle cose nemmeno le hai lette.
Non capisco cosa c' entri l' essere più o meno fighi con la programmazione: a 16 bit, 32 bit e a 64 bit. Non ti seguo, sei andato fuori strada.
So che la programmazione a 64 bit è più difficile ed infatti non faceva/fa parte del mio percorso.
Il discorso verteva, per quanto riguarda il C, sui vari livelli difficoltà che variano in base al livello di conoscenze, esperienze etc... che ha una persona e poi in base alla sintassi (comprende anche le funzioni), alle funzioni delle librerie, etc...
A febbraio 2019 avevo deciso cosa fare, iniziaii un percorso ed ora nel presente lo sto ancora continuando. Ora volevo/voglio aggiungere la I/O in C, partendo da zero, scegliendo 1 sola interfaccia tra LPT e RS-232/VCP, 1 solo sistema operativo, 1 solo computer e 1 sola opzione tra: C in Win32 e C in dos.
Non è mi è mai passato per la mente di fare insieme più di 1 sola interfaccia oppure più di 1 solo sistema operativo etc... Poi tra l' altro nemmeno mi serve poter usare 2 interfaccie diverse etc...
Tu invece hai frainteso pensando che volessi cambiare la modalità di esecuzione del sistema operativo, che volessi fare tutte quelle interfaccie, tutti quei sistemi operativi che ho menzionato, la programmazione in C ed Assembly a [ 16 bit, 32 bit e a 64 bit] per quanto riguarda: TUI/COW, console e GUI.
Ora non sto affatto programmando a 16 bit e se possibile, nemmeno per la I/O vorrei farlo. Spero che ci sia un opzione in Win32 (non per forza su uno dei s.o NT), in cui la sintassi e le funzioni non siano più difficili rispetto alla programmazione dos 16 bit.
Certe librerie che ho linkato c'è scritto che sono compatibili o fino ad XP oppure a fino Windows 2003 (non devo usare).
Quoto.
Leva pure: Win 64, lo studio dell' architettura X86-64 e dell' assembly X86-64, la programmazione baremetal, la programmazione in Assembly (tutti), la modalità del sistema operativo a 64 bit, WoW64, il Borland BGI dos, raspberry pi, Arduino e WinRT.
Dall'introduzione dello standard PCI, parecchie cose sono cambiate. E tant'è. UEFI non c'entra.
Inoltre, rimane sempre il problema che non puoi programmare liberamente l'hardware dall'interno di un sistema operativo. Quindi cosa scegli di fare? Andare di bare metal? Il DOS è un'eccezione, perchè non implementa la modalità protetta e quindi tutto il software gira in modalità supervisore e può accedere all'hardware. Ma parlo del DOS, il sistema operativo, quello che s'installa sul PC con i dischetti. Non parlo dell'emulatore NTVDM di Windows a 32 bit o di DosBox e compagnia cantante. E nemmeno dei vari DOS estesi a 32 bit, tipo DR-DOS.
Dove posso informarmi di preciso per sapere quali sono queste "parecchie cose" che sono cambiate a partire dallo standard PCI?
Su Windows 95/98 so che si può accedere direttamente all' hardware. Scelgo di andare su Windows 98.
Certo, cambia il fatto che le periferiche dotate di firmware, ne hanno uno che supporta UEFI. Ma francamente nemmeno t'interessa, perchè tu parlerai con la periferica tramite le solite strategie. Ma sai quali sono queste strategie? Il punto sta tutto qui. Ti stai preoccupando di UEFI e BIOS, quando ancora non sai come fare materialmente a comunicare con la periferica d'interesse.
Non ci avevo pensato al firmware però lo tralascio.
Mi sto pure preoccupando anche di trovare una libreria con le relative funzioni che siano alla mia portata.
In questo periodo mi sto informando sulla porta parallela e la RS-232. Una delle due devo scegliere.
Ora c'è il libro che hai consigliato che tra l' altro ha un captolo apposito per l' I/O.
Win32/GDI è fuori dalla mia portata considerando il mio livello. Stessa cosa le Api Console e le Api GUi ed altre.
Se non mi sbaglio, non ho scritto direttamente nel framebuffer. Avevo usato un emulatore dos + turbo c.
Puoi leggere da pag 4 a pag 7. Viene spiegato quello che intendo:
Poi nelle pagine successive spiega WinBGIm, che è il porting delle librerie Borland BGI in Win 32. Prima dell' altro giorno non conoscevo l' esistenza di WinBGIm oppure di Win32 BGI perchè altrimenti l' anno scorso non avrei utilizzato l' emulatore dos etc... per poter scrivere questo programmino che mostra sullo schermo una linea ed un cerchio:
Forse non mi sono spiegato. WINDOWS NON TI DA' LA POSSIBILITA' DI ACCEDERE AI REGISTRI DELL'HARDWARE!!! Il Dos di cui parli, è un banale emulatore che gira sotto Windows. Ha il supporto per un certo numero di periferiche virtuali, che poi mappa su quelle reali e tant'è. Non pensare nemmeno per un istante che tu possa accedere ai registri della porta parallela ( o altro ) da un emulatore DOS.
Non urlare!
Sei andato di nuovo fuori strada. Forse mi dovevo spiegare meglio. Io mica ho parlato dei i registri dell' hardware dato che non c' entrano nulla con il mio discorso e non mi interessano.
Con "dos" intendo proprio l' emulatore. Mentre con "ms-dos" intendo invece il S.O.
Con la mia risposta mi riferisco esclusivamente al diverso livello di difficoltà che hanno le varie librerie per . Es. le librerie per la programmazione I/O
Ed è questo che succede quando si leggono cose a casaccio e fuori contesto. Inp e Out da dove vengono fuori? Non sono istruzioni x86. Non sono istruzioni dell'API Win32/Win16/vattelapesca. Magari sono parte di una libreria che un tizio ha implementato per interfacciarsi con qualcosa nel kernel, che gli permette di accedere allo spazio di I/O di una periferica.
Non ho letto cose a casaccio e fuori contesto.
Ho fatto ulteriori ricerche su internet.
IN e OUT sono 2 delle istruzioni I/O che fanno parte dell' ISA X86. E' possibile programmare in assembly su Windows 95/98 usando queste due istruzioni.
Ho fatto un errore, scrivendo, "assembly" in quella frase visto che non c' entra un tubo. Per quanto riguarda la programmazione in C in Windows 95/98: inp() ed outp() sono delle funzioni presenti nella libreria conio. E' una libreria che non fa parte delle Api Win16 e Win32.
INP e OUT fanno ad es. parte della libreria inpout32.
Nei primi due link che hai postato viene usata la stessa libreria.
Il terzo invece è un modulo per python che usa un estensione java. Di più non so e non mi riguarda.
Però è meglio non andare su altri linguaggi specie più astratti e che sono pure OOP perchè se no, mi vengono altri dubbi e domande.
Per quanto riguarda la modalità protetta e le sue restrizioni farò una ricerca tra i manuali Intel X86-X86-64.
Lascia stare il gpu passthrough. Era un esempio. Non c'entra con quello che vuoi fare. A te serve una solida conoscenza di come sono strutturati i computer e di quale ruolo riveste il sistema operativo.
Quindi un libro di architettura di calcolatori e uno dei sistemi operativi. Leggili e capirai parecchie cose.
Devi leggere. Perchè vedo che non ti sono affatto chiare le interazioni tra hardware, sistema operativo, librerie, software applicativo.
Concordo sul fatto che devo leggere. Dall' anno scorso ad ora mi rendo conto che avrei potuto fare di più.
Sulle interazione ci sono cose che devo approffondire, altre che non conosce e poi quelle che dove ho dubbi/confusione. Ci devi aggiungere anche: le funzioni, il preprocessore, le direttive, per il preprocessore e forse pure il linking.
In questo periodo sto facendo: "Sistemi di calcolo". C'è il libro: "Computer Systems: A Programmer's Perspective".
Non so se riesco a fare contemporaneamente anche il libro che mi hai consigliato sopra.
Il libro sui sistemi operativi rimane, per ora, in coda.
Intanto perchè mischi C e Assembly? Mi pare siano parecchio distanti. Poi un kernel è un kernel e offre determinati servizi. Attorno ci sono altre librerie che aggiungono ulteriori servizi. Il tuo programma, in qualsiasi linguaggio sia, usa questi servizi. Quindi perchè dovrebbe essere differente? Perchè MS dovrebbe mettersi a creare un set di API per Windows Server e uno totalmente diverso per Windows Desktop? Gli ingegneri vanno pagati, mica lavorano aggratis.
Non ho mischiato i due linguaggi dato che ho messo "/". Io non mischio nemmeno C e C++.
Meno male che non ci sono differenze per quanto riguarda la programmazione in C e in Assembly :)
Sono scettico. Leggo tanta filosofia qui, ma dagli altri tuoi post si nota che sei ancora agli inizi. Stai cercando di realizzare qualche programma CLI ( così si chiamano quelli che definisci "programmi DOS" ) e stai avendo i primi problemi con le funzioni di input/output.
Non sei al punto di doverti preoccupare di 16 e 32 bit, driver, programmazione diretta delle periferiche, ecc...
Ecco appunto. Stai iniziando e hai tanta confusione. Programma a 16, 32 o 64 bit in C, è praticamente la stessa cosa, salvo alcuni casi limite. Il tuo programma CLI userà le stesse identiche funzioni, farà le stesse cose, verrà compilato allo stesso modo. Tu non vedi niente di quello che c'è sotto il cofano. E nemmeno t'interessa.
Ora volevo/voglio aggiungere la I/O in C, partendo da zero, scegliendo 1 sola interfaccia tra LPT e RS-232/VCP, 1 solo sistema operativo, 1 solo computer e 1 sola opzione tra: C in Win32 e C in dos.
Il C non supporta niente che riguardi la programmazione diretta dell'hardware. Quello è compito del sistema operativo. Che ti dà la possibilità di accedere alle periferiche come fossero file. Tutto questo funziona perfettamente, tranne in alcuni casi limite.
Semmai la questione è che i sistemi operativi moderni non ti consentono l'accesso diretto all'hardware. Per cui o vai di DOS ( ma quello vero, non l'emulatore di Windows 10, Dosbox o il prompt dei comandi di Windows che invece si chiama CLI ) o non usi nessun sistema operativo.
Ma scrivere programmi senza appoggiarsi ad un sistema operativo, significa di fatto scriversi un proprio sistema operativo. E non è un qualcosa che puoi fare, visto che stai muovendo i primi passi.
Ora non sto affatto programmando a 16 bit e se possibile, nemmeno per la I/O vorrei farlo. Spero che ci sia un opzione in Win32 (non per forza su uno dei s.o NT), in cui la sintassi e le funzioni non siano più difficili rispetto alla programmazione dos 16 bit.
Si, l'opzione c'è. Scrivere un driver. O usarne uno già fatto che consenta ai programmi che lo usano di manipolare a basso livello le periferiche. Altre possibilità non ci sono.
E non è detto che sia così. Windows è notoriamente retrcompatibile. Quelle indicazioni riguardano il supporto offerto dal produttore della libreria. Ma potrebbero benissimo funzionare su Windows 10.
Dove posso informarmi di preciso per sapere quali sono queste "parecchie cose" che sono cambiate a partire dallo standard PCI?
Su Windows 95/98 so che si può accedere direttamente all' hardware. Scelgo di andare su Windows 98.
Sei andato di nuovo fuori strada. Forse mi dovevo spiegare meglio. Io mica ho parlato dei i registri dell' hardware dato che non c' entrano nulla con il mio discorso e non mi interessano.
Non puoi programmare l'hardware senza manipolarne i registri. Programmare l'hardware significa proprio manipolarne i registri. Quindi dovrebbero interessarti.
Non ho letto cose a casaccio e fuori contesto.
Ho fatto ulteriori ricerche su internet.
IN e OUT sono 2 delle istruzioni I/O che fanno parte dell' ISA X86. E' possibile programmare in assembly su Windows 95/98 usando queste due istruzioni.
E invece mi pare proprio che abbia letto cose a casaccio. Intanto sono IN e OUT e non Inp e Out. Non sono funzioni di libreria, ma istruzioni del processore.
E no, non puoi usarle in un programma usermode sotto Windows 9x. Windows 9x implementa la modalità protetta e pertanto impedisce ai programmi utente di manipolare direttamente lo stato dell'hardware.
programmazione in C in Windows 95/98: inp() ed outp() sono delle funzioni presenti nella libreria conio. E' una libreria che non fa parte delle Api Win16 e Win32.
Se è per questo, conio esiste anche in Borland C. Ed è per questo che dicevo che non devi leggere e mischiare cose a casaccio. Quelle librerie esistevano in un mondo dove l'accesso all'hardware era possibile, direttamente, parzialmente o tramite wrapper. Tant'è che oggi conio è deprecata.
Concordo sul fatto che devo leggere. Dall' anno scorso ad ora mi rendo conto che avrei potuto fare di più.
Sulle interazione ci sono cose che devo approffondire, altre che non conosce e poi quelle che dove ho dubbi/confusione.
L'unica confusione che vedo è voler mettere il carro davanti ai buoi. Come ho scritto all'inizio, mi pare di capire che sei agli inizi e stai realizzando qualche programma CLI. Da lì a programmare l'hardware ce ne vuole davvero tanto.
In questo periodo sto facendo: "Sistemi di calcolo". C'è il libro: "Computer Systems: A Programmer's Perspective".
Non so se riesco a fare contemporaneamente anche il libro che mi hai consigliato sopra.
Il libro sui sistemi operativi rimane, per ora, in coda.
Io quando ho reinstallato Windows 8.1 l ho installato in modalità legacy quando avevo ancora Linux opensuse in dual boot che poi ho tolto. Cambia l interfaccia d avvio, se non ricordo male . Poi ho i dischi in MBR anziche GPT .
Io quando ho reinstallato Windows 8.1 l ho installato in modalità legacy quando avevo ancora Linux opensuse in dual boot che poi ho tolto. Cambia l interfaccia d avvio, se non ricordo male . Poi ho i dischi in MBR anziche GPT .
Un piccolo esempio di driver per accedere alle risorse hardware (con NT/XP) è l' INOUT32D.SYS
"include"
Codice:
// Device Name
#define DEVICE_NAME L"InOut32D"
// Long device name for system and DOS link
#define WIN_DEVICE_NAME L"\\Device\\" DEVICE_NAME
#define DOS_DEVICE_NAME L"\\DosDevices\\" DEVICE_NAME
// Driver type
#define INOUT32D_TYPE 60000
// IOCTL READ PORT command definition
#define IOCTL_READ_PORT_UCHAR \
CTL_CODE(INOUT32D_TYPE, 0x904, METHOD_BUFFERED, FILE_ANY_ACCESS)
// IOCTL WRITE PORT command definition
#define IOCTL_WRITE_PORT_UCHAR \
CTL_CODE(INOUT32D_TYPE, 0x905, METHOD_BUFFERED, FILE_ANY_ACCESS)
"c"
Codice:
// Include DDK support
#include <ntddk.h>
// Include inout32d header
#include <inout32d.h>
///////////////////
// Driver unload
VOID InOut32DUnload(IN PDRIVER_OBJECT drvObj)
{
WCHAR DOSName[] = DOS_DEVICE_NAME; // DOS Device Name string
UNICODE_STRING uDOS; // Unicode string
// Convert DOS Device Name to unicode
// and delete DOS device link
RtlInitUnicodeString(&uDOS, DOSName);
IoDeleteSymbolicLink(&uDOS);
// Delete Device
IoDeleteDevice(drvObj->DeviceObject);
}
////////////////////
////////////////////////////////
// Handle Create request
// (already SUCCESS)
NTSTATUS InOut32DCreateDispatch(IN PDEVICE_OBJECT devObj, IN PIRP pIrp)
{
// Complete request with SUCCESS
pIrp->IoStatus.Information = 0;
pIrp->IoStatus.Status = STATUS_SUCCESS;
IoCompleteRequest (pIrp, IO_NO_INCREMENT);
return STATUS_SUCCESS;
}
////////////////////////////////
////////////////////////////////
// Handle Control request
// Command:
// IOCTL_READ_PORT_UCHAR
// IOCTL_WRITE_PORT_UCHAR
NTSTATUS InOut32DDeviceControl (IN PDEVICE_OBJECT devObj, IN PIRP pIrp)
{
NTSTATUS drvStat; // Returned status
PIO_STACK_LOCATION irpStack; // Stack location pointer
ULONG bLenIn, bLenOut; // I/O buffer len
PVOID vBuff; // Pointer <void> to buffer
PUCHAR chBuff; // Pointer <unsigned char> to buffer
PUSHORT shBuff; // Pointer <unsigned short> to buffer
// Get a pointer to the caller's stack location in the given IRP
irpStack = IoGetCurrentIrpStackLocation(pIrp);
// Get I/O buffer length
bLenIn=irpStack->Parameters.DeviceIoControl.InputBufferLength;
bLenOut=irpStack->Parameters.DeviceIoControl.OutputBufferLength;
// Create pointer to system buffer
vBuff=pIrp->AssociatedIrp.SystemBuffer;
chBuff=(PUCHAR)vBuff;
shBuff=(PUSHORT)vBuff;
// Default return status
drvStat=STATUS_SUCCESS;
// Examine IOCTL code received
switch( irpStack->Parameters.DeviceIoControl.IoControlCode )
{
// IOCTL request: read byte from I/O port
case IOCTL_READ_PORT_UCHAR:
// Check for I/O buffer size
if((bLenIn >= 2) && (bLenOut >=1 ))
// Read port (Address in shBuff, value in chBuff)
chBuff[0]=READ_PORT_UCHAR((PUCHAR)shBuff[0]);
else
drvStat=STATUS_BUFFER_TOO_SMALL;
// Information size to caller (1 byte)
pIrp->IoStatus.Information=1;
break;
// IOCTL request: write byte to I/O port
case IOCTL_WRITE_PORT_UCHAR:
// Check for I/O buffer size
if(bLenIn >= 3)
// Write port (Address in shBuff, value in chBuff)
WRITE_PORT_UCHAR((PUCHAR)shBuff[0], chBuff[2]);
else
drvStat=STATUS_BUFFER_TOO_SMALL;
// Information size to caller (no data)
pIrp->IoStatus.Information=0;
break;
default:
// Unknown IOCTL command.
// Return error status.
drvStat=STATUS_UNSUCCESSFUL;
pIrp->IoStatus.Information=0;
break;
}
// Complete request
// and report status
pIrp->IoStatus.Status = drvStat;
IoCompleteRequest( pIrp, IO_NO_INCREMENT );
// Report status
return drvStat;
}
////////////////////////////////
////////////////////////////
// Driver entry point
NTSTATUS DriverEntry(IN PDRIVER_OBJECT drvObj, IN PUNICODE_STRING regPath)
{
NTSTATUS drvStat; // Returned status
WCHAR Name[] = WIN_DEVICE_NAME; // Device name
WCHAR DOSName[] = DOS_DEVICE_NAME; // DOS device name
UNICODE_STRING uName, uDOSName; // Unicode string
PDEVICE_OBJECT devObj; // Device object pointer
// Init unicode string with driver and DOS driver name
RtlInitUnicodeString(&uName, Name);
RtlInitUnicodeString(&uDOSName, DOSName);
// Create device
drvStat = IoCreateDevice( drvObj, 0, &uName,
FILE_DEVICE_UNKNOWN,
0, FALSE, &devObj );
// Check success
if ( NT_SUCCESS(drvStat) )
{
// Create symbolinc link
drvStat = IoCreateSymbolicLink (&uDOSName, &uName);
// Check success
if ( NT_SUCCESS(drvStat) )
{
// Initialize function pointer for Create, Control and Unload
drvObj->MajorFunction[IRP_MJ_CREATE] = InOut32DCreateDispatch;
drvObj->MajorFunction[IRP_MJ_DEVICE_CONTROL] = InOut32DDeviceControl;
drvObj->DriverUnload = InOut32DUnload;
}
}
// Report status
return drvStat;
}
////////////////////////////
