DOMANDA [C/Assembly] Nella programmazione I/O su Windows ci sono differenze tra Bios Legacy ed Uefi?

Cibachrome

Utente Èlite
15,061
5,534
Buonasera :)

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.
 

pabloski

Utente Èlite
2,406
625
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.
 
  • Mi piace
Reactions: BAT00cent

Cibachrome

Utente Èlite
15,061
5,534
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:

A) Direct IO http://www.direct-io.com/ (è per i S.O. NT fino ad XP/2003)

Poi ho trovato delle librerie I/O (che vanno abbinate ad un driver generico):
  1. Io.DLL per Windows NT/2000/XP
    http://geekhideout.com/iodll.shtml per Windows: 95,98, NT,2000 ed XP.

  2. PortTalk per i S.O. NT fino a XP


  3. VVIO
    https://www.vincenzov.net/progetti/vvio/vvio.htm Nella pagina vengono menzionatti gli IOCTL

  4. DriverLink
    a questo link c'è un installer (NT, 2000 ed XP) permette di rendere la configurare il tutto in modo facile ed automatico: http://www.giobe2000.it/Hw/progetto/Prg00_1.asp

  5. InpOut32 and InpOutx64 :
    http://www.highrez.co.uk/downloads/inpout32/ (comprende anche inpout64) Anche inpout32 è compatibile con i sistemi operativo a 64 bit (compreso pure XP 64 bit XD)
    [URL ]https://github.com/ellysh/InpOut32[/URL]

  6. WSC4C (serial communication library based on the Windows serial comm API)
    Vale solo per le porte seriali rs-*** e per l' usb in VCP

  7. Solo API di Windows
    Se non ho capito male riguarda solo le porte seriali rs-
    https://docs.microsoft.com/en-us/previous-versions/ff802693(v=msdn.10)?redirectedfrom=MSDN
Ho cercato la ioctl che mi hai consigliato ed esiste anche per windows (credo a partire da Win 7) ed ho trovato ad es. :
[URL ]https://docs.microsoft.com/en-us/windows/win32/devio/device-input-and-output-control-ioctl-[/URL]

https://github.com/microsoft/Windows-driver-samples/blob/master/serial/serial/ioctl.c

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...
 
Ultima modifica:

pabloski

Utente Èlite
2,406
625
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...
Esistono pure programmi per Alpha, ma non vai certo in giro a programmare periferiche contemporaneamente in assembly x86 e Alpha.


Per caso sono programmi Win 16?
Non esiste Win 16.

Non se il loader sarebbe il bootloader.
Non lo è.


Sto programmando un X86-64 su Windows 7 64 bit (verrà affiancato a Windows 10) in C Win 32 console.
Win32 è l'API storica di Windows. Soppiantata da WinRT in Windows 10. Ma comunque non c'entra con i 32 bit.

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.


Anche per il disegno 2D, la GUI 2D etc... mi tocca considerare tra le opzioni anche la programmazione dos 16 bit.
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?

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.
E infatti è quello che ho scritto nel post precedente. Googla ioctl.


A) Direct IO http://www.direct-io.com/ (è per i S.O. NT fino ad XP/2003)

Poi ho trovato delle librerie I/O (che vanno abbinate ad un driver generico):
  1. Io.DLL per Windows NT/2000/XP
    http://geekhideout.com/iodll.shtml per Windows: 95,98, NT,2000 ed XP.
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.

Non so se ioctl si può usare anche per la usb in VCP/porta RS-232.
L'ioctl è un meccanismo d'interazione del software con i driver. Niente di più.

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.
 

Cibachrome

Utente Èlite
15,061
5,534
Ho cercato il libro che mi hai consigliato e lo inizierò a studiare.

Esistono pure programmi per Alpha, ma non vai certo in giro a programmare periferiche contemporaneamente in assembly x86 e Alpha.
Il mio discorso era in generale :)

Non esiste Win 16.
Perchè dici che non esiste?
Win16 sono i programmi per i sistemi operativi Windows 16 bit dall' 1.0 fino al 3.11. Utilizzano le Api Win16.

Es. qui spiega come creare applicazioni Win16 con GUI


Però non devo creare programmi Win16. Non m' interessano.

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.


E infatti è quello che ho scritto nel post precedente. Googla ioctl.
L' ho scritto pure nel mio primo messaggio.
Su ioctl ti ho risposto sopra.


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.

L'ioctl è un meccanismo d'interazione del software con i driver. Niente di più.
Quindi è una libreria?


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.
 

pabloski

Utente Èlite
2,406
625
Il mio discorso era in generale :)
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.


Perchè dici che non esiste?
Win16 sono i programmi per i sistemi operativi Windows 16 bit dall' 1.0 fino al 3.11. Utilizzano le Api Win16.
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.

Es. qui spiega come creare applicazioni Win16 con GUI


Però non devo creare programmi Win16. Non m' interessano.
Ah bene. Quindi niente programmi. Leviamo questa Win16 che non c'interessa.


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.


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.
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".
Si ma fammi capire come intendi fare mille cose contemporaneamente. Cioè, ad oggi, hai deciso cosa vuoi fare esattamente?

Spero che ora sia chiaro e non continui a fraintendere XD
Mi è chiaro che parecchie cose non ti sono chiare.

Alle scelte per quanto riguarda le interfaccie rs-232 ed usb
Sarebbe? Ci sono gazillioni di programmi che usano RS-232 ed USB per comunicare con ogni genere di periferica.

alle Api Windows e sistemi operativi Windows compresi anche quelli NT. Sono tutti dati di fatto
Quali? Esempi? Cosa c'è che non va?

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.

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.
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.

Se è necessario un controllo più fine, si passa ad un driver che consenta l'accesso ai singoli pin, clock e quant'altro, tipo questo https://github.com/pyserial/pyparallel/tree/master/src/win32/giveio

Il tuo scopo è realizzare questi driver? Usarli? Non si è capito.

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.
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

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.
Allora sai già come programmare l'hardware.


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.
Non hai usato Win32/GDI. Suppongo avrai usato altro. Non dirmi che hai scritto direttamente nel framebuffer.

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.
Soluzione tipo?

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.

Quindi è una libreria?
No, è un modo per interagire coi driver. Com'è implementato è affare del sistema operativo.


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.

Se guardi cose come queste


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 ).
 
Ultima modifica:

Cibachrome

Utente Èlite
15,061
5,534
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).

Ah bene. Quindi niente programmi. Leviamo questa Win16 che non c'interessa.
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.

Sarebbe? Ci sono gazillioni di programmi che usano RS-232 ed USB per comunicare con ogni genere di periferica.
Quali? Esempi? Cosa c'è che non va?
Non ti preoccupare. Sono dati di fatto, non possiamo farci nulla e li dobbiamo accettare. Possiamo andare avanti.

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.

Non hai usato Win32/GDI. Suppongo avrai usato altro. Non dirmi che hai scritto direttamente nel framebuffer.
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:
C:
#include <stdio.h>
#include <graphics.h>

main()
{
  int *gdriver;
  int *gmode;

  detectgraph(gdriver, gmode);
  initgraph(gdriver, gmode,"");

  setcolor(12);
  circle(100,100,50);

  setcolor(14);
  line(130,30,300,200);

  system("PAUSE");
  return;

}

Soluzione tipo?
Mi pare: if-else e semplici calcoli di aritmetica tra numeri interi. Di più non mi ricordo.

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.
outp() *

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.
Sul gpu passthrough ho capito e lo escludo.

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 :)

Se ti serve una risorsa veloce per accedere alle informazioni di basso livello sui computer, vai qui https://wiki.osdev.org/Main_Page
Ti ringrazio per il link. Mi sembra una risorsa valida ed utile. Aggiungo il sito ai preferiti.
 

pabloski

Utente Èlite
2,406
625
Non capisco perchè sei malpensante nei miei confronti.
Hai frainteso quello che ho scritto e delle cose nemmeno le hai lette.
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...

So che la programmazione a 64 bit è più difficile ed infatti non faceva/fa parte del mio percorso.
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.

Certe librerie che ho linkato c'è scritto che sono compatibili o fino ad XP oppure a fino Windows 2003 (non devo usare).
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.

Non ti preoccupare. Sono dati di fatto, non possiamo farci nulla e li dobbiamo accettare. Possiamo andare avanti.
Mi preoccupo invece. Perchè potrebbero essere conclusioni a cui sei arrivato, ma sbagliate.

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.
Un buon libro di architettura dei calcolatori. Come quello che ho indicato sopra o quello di Hennessy e Patterson.



Puoi leggere da pag 4 a pag 7. Viene spiegato quello che intendo:
Quindi hai usato una libreria DOS sotto emulatore. E dunque non si tratta di accesso all'hardware.

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.


Per quanto riguarda la modalità protetta e le sue restrizioni farò una ricerca tra i manuali Intel X86-X86-64.
Praticamente obbligatorio. Programmare l'hardware richiede una conoscenza approfondita della piattaforma hardware.

Sul gpu passthrough ho capito e lo escludo.
Ovvio. Non c'entra nulla con la programmazione dell'hardware.

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.
E bisogna programmare. Inutile leggere senza applicare quello che s'impara.


Meno male che non ci sono differenze per quanto riguarda la programmazione in C e in Assembly :)
Ed è ovvio. I linguaggi sono linguaggi, perchè mai dovrebbero condizionare lo sviluppo delle API?
 

Entra

oppure Accedi utilizzando

Discussioni Simili

Hot del momento