Una visione di come le cose vengono stampati sullo schermo (cout,printf) e l'origine di davvero complesso di cose che io non riesco a trovare sui libri di testo

Question

Mi sono sempre chiesto questo, e ancora non ho trovato la risposta.Ogni volta che usiamo "cout" o "printf" come è stampato sullo schermo?.Come fa il testo come si fa...(probabilmente una domanda vaga qui, ill lavorare con quello che mi danno.).Quindi, fondamentalmente, come sono quelle funzioni?..è il montaggio?, se quindi dove cominciare?.Questo porta a più domande come: come diavolo hanno fatto openGl/directx funzioni..

scomposizione di rompere giù.:)

Answer 1

Ecco un piano d'azione, con le abbreviazioni:

1. printf o cout messi caratteri in un buffer nello spazio degli indirizzi del programma utente.
2. Alla fine il buffer si riempie, o forse printf chiede il buffer da svuotare presto. In entrambi i casi, la libreria I / O chiama il sistema operativo, che copia il contenuto del buffer per il proprio spazio.
3. Supponendo che il file di uscita è associato a un terminale, il sistema operativo fornisce i caratteri all'applicazione terminale.
4. L'applicazione terminale decide che per ogni carattere nel buffer, ha bisogno di dipingere pixel sullo schermo.
5. L'applicazione terminale imposta istruzioni pixel-pittura, e chiede un window manager per fare questo per suo conto. (In Unix in questi giorni questo è di solito un server X).
6. Il window manager prende i pixel. Se la finestra è effettivamente visibile sullo schermo, il window manager quindi aggiorna un buffer (chiamato frame buffer ) che contiene i pixel visibili. Il window manager può quindi comunicare al sistema operativo, o più probabilmente, il window manager è in combutta con il sistema operativo e che condividono la stessa memoria.
7. La volta successiva lo schermo viene aggiornato, l'hardware vede i nuovi bit nel frame buffer, e vernici schermo diverso.
8. Voilà! Hai caratteri sullo schermo.

E 'sorprendente che l'orso balla a tutti.

Answer 2

Quindi, fondamentalmente, come sono quelle funzioni?..è il montaggio?, se quindi dove cominciare?.Questo porta a più domande come: come diavolo hanno fatto openGl/directx funzioni.

Tali funzioni possono essere assembly o C, non cambia molto (e, comunque, si può fare in C praticamente qualsiasi cosa si può fare in assemblea.) La magia, in definitiva, succede all'interfaccia di software e hardware - come si arriva da printf e cout << può essere così banale come pochi puntatore operazioni (vedi 286 esempio riportato di seguito, o leggere cprintf più in basso), o complesso come passare attraverso più strati di diverse chiamate di sistema, forse andando anche oltre le reti, prima poi colpire l'hardware di visualizzazione.

Immaginare scenari seguenti:

1. Ho scavare il backup del mio vecchio 286 da sotto la polvere e il fuoco di MS-DOS;Compilare ed eseguire il seguente programma in modalità reale:

   void main(void) {
     far long* pTextBuf = (far long*)0xb8000L;
     /* Poor man's gotoxy+cprintf imitation -- display "C:" (0x43,0x3a) in
        silver-on-black letters in the top-left corner of the screen */
     *pTextBuf = 0x073a0743L;
   }
   

2. Io sono il collegamento con il mio portatile Windows HyperTerminal alla mia porta seriale, che è collegato con un cavo alla parte posteriore di un SOLE di dialogo, attraverso il quale posso accedere al mio SOLE della finestra di console.Da che console ssh in una seconda scatola, sulla rete, dove ho eseguito il mio programma che fa printf, nelle tubazioni , l'output tramite more.Il printf informazioni ha viaggiato attraverso un tubo attraverso more, poi tramite SSH pseudo-tty attraverso la rete di my SUN box, da lì attraverso il cavo seriale sul mio portatile, attraverso Windows GDI testo le funzioni di disegno di prima, infine, che appare sul mio schermo.

L'aggiunta di ulteriori dettagli per l' Norman risposta, si spera più nella direzione della tua domanda originale:

• printf e cout << di solito eseguire scrive stdout -- in genere operazioni di scrittura nel buffer, ma che non è sempre il caso
  • indietro nel giorno, diversi i produttori di compilatori (Borland, Microsoft), in particolare sul DOS, a condizione che funzioni come cprintf, che scritto direttamente alla memoria video senza fare chiamate di sistema, memcpy-stile (vedi il mio 286 esempio di cui sopra) -- più su che più in basso
• la scrittura stdout è una chiamata di sistema, sia esso write sotto *nix, WriteFile o WriteConsole sotto Windows, INT 21, 9 sotto DOS, etc.
• il vantaggio di passare attraverso il stdout astrazione è che permette al sistema operativo di fare qualche interno di impianti idraulici e di eseguire il reindirizzamento (sia esso un tty descrittore di un tubo, di un file, di una porta seriale, a un altro computer tramite un socket etc.)
  • inoltre, indirettamente, permette di avere più applicazioni' stdouts coesistere nella stessa schermata, ad esempioin diverse finestre, qualcosa che sarebbe molto più difficile da fare se ogni applicazione ha provato a scrivere direttamente nella memoria video sul proprio (come cprintf fatto in DOS -- non che cosa sarebbe chiamato oggi un vero o utilizzabile sistema operativo multi-tasking.)
• al giorno d'oggi, un'applicazione grafica come il tuo rxvt finestra di console applicazione di Stucco telnet/ssh client, console di Windows, etc.sarà:
  • leggere la vostra applicazione stdout:
    • da un tty descrittore (o equivalente) in caso di rxvt o della console di Windows
    • da una porta seriale se si utilizza qualcosa come Realterm per la connessione a un sistema embedded o a un vecchio SOLE casella di console
    • dalla presa, se si sta utilizzando PuTTY come un client telnet
  • visualizzare le informazioni da il rendering di grafica, pixel per pixel, nel grafico della finestra dell'applicazione buffer/contesto di periferica/etc.
    • questo è in genere fatto attraverso ancora un altro livello di astrazione e le chiamate di sistema (come GDI, OpenGL ecc.)
    • le informazioni sui pixel, in definitiva, finisce in un lineare frame buffer, che è, una memoria dedicata gamma (nei giorni di 8 mhz Cpu, ben prima AGP, questa zona potrebbe risiedere nella RAM di sistema, oggi potrebbe essere megabyte e megabyte di dual port RAM sulla scheda video stesso)
    • la scheda video (quello utilizzato per essere chiamato un RAMDAC), sarebbe periodicamente leggere il frame buffer di memoria gamma (es.60 volte al secondo, quando l'adattatore VGA era fissato per le 60Hz), scanline dopo scanline (possibilmente facendo tavolozza le ricerche di troppo), e trasmettere il display analogico o digitale i segnali elettrici
• indietro nel giorno, o anche oggi, quando si esegue il boot del *nix casella in modalità utente singolo o andare a schermo intero in una console di Windows, si scheda grafica è in realtà in in modalità testo
  • invece di una fodera del frame buffer, uno (il cprintf l'implementazione o il sistema operativo) scrive molto più piccolo di 80x25 o 80x50 etc. buffer di testo matrice, in cui (ad es.in caso di VGA) solo due byte sono necessari per la codifica di ogni valore di carattere come A o ▒ o ♣ (1 byte) così come i suoi attributi di colore (1 byte) - che è, il suo primo piano (4 bit 3 bit + luminosità bit) e i colori di sfondo (4 bit 3 bit + blink bit)
  • per ogni pixel su ogni linea di scansione, RAMDAC:
    • vorresti tenere traccia di quale colonna di testo e il testo riga di pixel appartiene a
    • sarebbe colonna/riga del valore di carattere e attributi
    • sarebbe il valore di carattere contro un semplice bitmap font definizione
    • vorrei vedere se il pixel viene eseguito il rendering in il valore del carattere del glifo bitmap definizione, dovrebbe essere di primo piano o di sfondo, e che colore che si basa sull'attributo di carattere in quella posizione
    • forse capovolgere il primo piano e lo sfondo, anche secondi se un batter bit è stato impostato o il cursore mostra e alla posizione corrente
    • disegnare i pixel

Iniziare a La storia delle Schede Video e GPU pagine su Wikipedia per una più approfondita di come siamo arrivati dove siamo oggi.

Anche guardare Come Gpu Lavoro e Come Schede Grafiche Di Lavoro.

Answer 3

Bene, passano attraverso una serie di funzioni di libreria, e alla fine finiscono per chiamare una chiamata di sistema write (), che invia i dati al descrittore di file appropriato, che poi induce a girare in un read () chiamare l'emulatore di terminale (o finestra comandi shell, se questo è Windows). Il terminale / shell fa sì che i dati da verniciare sullo schermo, probabilmente per mezzo di un gruppo di più chiamate di sistema per inviare al sistema grafico.

di Windows e della terminologia Unix / Linux è molto diversa, in particolare il concetto di un guscio non è affatto la stessa cosa in ogni. Ma l'uso di read () e write () chiamate è abbastanza simile in entrambi i casi.

Le chiamate di sistema sono funzioni speciali che causano il kernel a fare determinate cose; come vengono implementate è abbastanza magico, e molto dipende da che tipo di processore che hai, ma di solito è causando qualche tipo di errore del processore recuperabili che il kernel deve riordinare.

Answer 4

Crack aprire la fonte di glibc e vedere di persona.

Risposta breve, un sacco di codice C, cosparso di tanto in tanto, con un po 'assembler.

Answer 5

La magia che realmente accade nel driver di periferica. Il sistema operativo presenta un'interfaccia per i programmatori di applicazioni per agganciare in. Questo viene massaggiato leggermente (per esempio tamponata) e quindi inviato al dispositivo. Il dispositivo prende allora la rappresentazione comune e la trasforma in segnali particolare dispositivo può comprendere. Così ASCII viene visualizzato in formato ragionevole somme sulla console o in un file PDF, o ad una stampante o su disco, nella forma appropriata per quel dispositivo. Provate qualcosa di diverso da ASCII (o UTF8) che il driver non capisce e si vedrà che cosa sto parlando.

Per le cose il sistema operativo non può gestire (schede grafiche speciali per esempio) l'applicazione scrive i dati direttamente nella memoria del dispositivo. Questo è come qualcosa di simile a DirectX funziona (per semplificare drasticamente).

Ciascun driver è differente. Ma ciascuno è la stessa in termini di come si interfacciano con il sistema operativo, almeno per ogni classe di dispositivo (disco, scheda di rete, tastiera, ecc).