Creare driver

[|giacomo|]

Ho aperto questo post per chiedere voi un aiuto e delle dritte sulla creazione di un driver per windows e per linux..so discretamente come lavora un so per quanto riguarda l' I/O, kernel ecc..o meglio so come agisce nulla di piu..come linguaggi utili conosco l assembly e java..quest' ultimo so che non e tra i piu adatti ma se c'e da studiare qualcosa di nuovo non mi tiro indietro..Se sapete darmi qualche indicazione,dritta o qualsiasi informazione e ben accetta..so che fare un driver e una cosa difficilissima..ma per passare il tempo....

[variabilepippo]

Che tipo di driver vuoi sviluppare? In altre parole: cosa vorresti "pilotare"?

[|giacomo|]

Ecco volevo specificare propio all' inizio poi pensavo fosse uguale..e piu facile "pilotare" un dispositivo gia fatto (chessò una cam) o magari un piccolo circuitino fatto da me che magari accende un led?

[variabilepippo]

In entrambi i casi devi avere un bagaglio di conoscenze che richiede anni per essere acquisito... Nel caso di un dispositivo non realizzato da te devi avere a disposizione le specifiche tecniche complete o essere in grado di fare reverse engineering (cosa non banale!).


Ecco volevo specificare propio all' inizio poi pensavo fosse uguale


Su Windows si possono sviluppare diverse tipologie di driver, ed in baso al tipo cambia il livello di difficoltà (da elevatissimo diventa elevato! :D).

Consulta questo sito (http://www.microsoft.com/whdc/devtools/wdk/default.mspx).

[|giacomo|]

Grazie mille x il sito.:D..cmq si immaginavo fosse una cosa assai difficile..ma magari pian piano, con l aiuto di persone piu esperte..il mio e solo un passatempo nulla di frettoloso o necessario quindi.:D..cmq..tu quindi mi consiglieresti (come minor male s' intende :D ) di pilotare un dispositivo semplice semplice creato da me?

[variabilepippo]

Inizia con lo studiare BENE il C, senza quello non vai da nessuna parte...

[|giacomo|]

Inizia con lo studiare BENE il C, senza quello non vai da nessuna parte...
Benissimo!era gia nei miei programmi futuri a dire il vero.:D

[variabilepippo]

I driver si sviluppano in C (e poco più) e non basta una conoscenza superficiale del linguaggio, bisogna avere molta esperienza nello sviluppo in C. Quando conoscerai BENE il C potrai pensare di acquistare libri sullo sviluppo di driver per il sistema operativo prescelto e studiare tutta la documentazione relativa.

[71104]

dico la mia: tanto per cominciare non è che allegramente puoi metterti a sviluppare driver per Windows E per Linux :D
sono due mondi completamente diversi, o l'uno o l'altro (e ti dirò, ho la netta sensazione che Linux sia più semplice, e non si tratta necessariamente di un vantaggio per Linux, anzi).
quindi per prima cosa scegli il tuo sistema target. non scegliere Linux solo perché ti ho detto che è più semplice: è più semplice una volta che hai imparato, ma la documentazione in queste cose è di importanza fondamentale e in quanto a documentazione nessuno può battere MSDN (Microsoft Developer's Network), quindi può darsi invece che ti riesca meglio sviluppare drivers per Windows.
in secondo luogo ribadisco il consiglio di un apprendimento totale del C (tranquillo, tutto sommato è un linguaggio molto semplice: il C++ è 10 volte più complesso ;)), e aggiungo che i due linguaggi che conosci ti saranno perfettamente inutili: che i drivers nel 2008 si sviluppino in assembly è un mito nato dall'ignoranza (visto che l'apprendimento in queste cose è molto arduo); un driver per Windows è sviluppato completamente in C, neanche una riga di assembly. se non ci credi scarica il WDK (Windows Driver Kit) e guardati tutti i drivers di esempio, non troverai una riga di assembly che sia una.
come ultima questione, non credo che sia necessario spendere soldi e acquistare un libro: come ho già scritto, la qualità della documentazione che c'è in MSDN è assolutamente ottima, basta solo armarsi di pazienza, tempo, e leggere tutto dall'inizio alla fine. to', qui c'è l'inizio:
http://msdn.microsoft.com/en-us/library/ms791699.aspx
:D

[|giacomo|]

dico la mia: tanto per cominciare non è che allegramente puoi metterti a sviluppare driver per Windows E per Linux :D
sono due mondi completamente diversi, o l'uno o l'altro (e ti dirò, ho la netta sensazione che Linux sia più semplice, e non si tratta necessariamente di un vantaggio per Linux, anzi).
quindi per prima cosa scegli il tuo sistema target. non scegliere Linux solo perché ti ho detto che è più semplice: è più semplice una volta che hai imparato, ma la documentazione in queste cose è di importanza fondamentale e in quanto a documentazione nessuno può battere MSDN (Microsoft Developer's Network), quindi può darsi invece che ti riesca meglio sviluppare drivers per Windows.
in secondo luogo ribadisco il consiglio di un apprendimento totale del C (tranquillo, tutto sommato è un linguaggio molto semplice: il C++ è 10 volte più complesso ;)), e aggiungo che i due linguaggi che conosci ti saranno perfettamente inutili: che i drivers nel 2008 si sviluppino in assembly è un mito nato dall'ignoranza (visto che l'apprendimento in queste cose è molto arduo); un driver per Windows è sviluppato completamente in C, neanche una riga di assembly. se non ci credi scarica il WDK (Windows Driver Kit) e guardati tutti i drivers di esempio, non troverai una riga di assembly che sia una.
come ultima questione, non credo che sia necessario spendere soldi e acquistare un libro: come ho già scritto, la qualità della documentazione che c'è in MSDN è assolutamente ottima, basta solo armarsi di pazienza, tempo, e leggere tutto dall'inizio alla fine. to', qui c'è l'inizio:
http://msdn.microsoft.com/en-us/library/ms791699.aspx
:D
Grazie mille per la risposta esaustivissima!:D..allora mi mettero a studiare il C..sinceramente anche io (nell' ignoranza) credevo che l assembly fosse il linguaggio principale per lo sviluppo di un driver..e non solo..per quanto riguarda la piattaforma da sciegliere sono ancora indeciso sinceramente...magari mentre studio il C cerco intanto di documentarmi e vedere quale delle due si adatta piu al mio scopo..Inoltre..dato che mi sembra di capire che hai una certa preparazione sull argomento (come ti stimo:D) secondo te e piu facile "pilotare" una periferica gia fatta o qualcosa di creato da me?:D

[variabilepippo]

come ultima questione, non credo che sia necessario spendere soldi e acquistare un libro: come ho già scritto, la qualità della documentazione che c'è in MSDN è assolutamente ottima, basta solo armarsi di pazienza, tempo, e leggere tutto dall'inizio alla fine.

Su MSDN si trovano molte informazioni e la documentazione ufficiale è decisamente completa, ma sono in tanti a preferire l'approccio organico ad un percorso di studio, approccio che solo un buon libro può dare. Inoltre sui buoni libri si trovano consigli, non inclusi nella documentazione tecnica, legati all'esperienza degli autori (quelli su DDK/WDK/WDM/WDF/etc vengono solitamente scritti da membri dei rispettivi team Microsoft). Poi se si è abituati ad usare un metodo di studio "custom" allora non ci sono problemi... :)


credevo che l assembly fosse il linguaggio principale per lo sviluppo di un driver


Concordo con 71104, l'Assembly (come linguaggio) non ti servirà quasi per niente nello sviluppo di driver.

[71104]

secondo te e piu facile "pilotare" una periferica gia fatta o qualcosa di creato da me?:D banalmente, è più facile pilotare una periferica dalle specifiche tecniche semplici; tra l'altro se la periferica l'hai creata tu le specifiche tecniche le conosci già. esistono invece periferiche per le quali le specifiche sono trade secret dell'azienda che le produce, e quindi creare un driver potrebbe anche essere praticamente impossibile, o comunque assolutamente irragionevole per un hobbysta.

la risposta breve: la seconda :p
inoltre ti avviso che potrebbe non essere neanche necessario scrivere un driver: se ad esempio crei un circuito che si attacca al PC tramite una porta esterna (COM, LPT, USB, ...) allora puoi manovrarlo anche con un semplice programma applicativo. se scrivi il programma in Win32 puoi comunicare con le suddette porte usando l'interfaccia di I/O standard (CreateFile, ReadFile, WriteFile, ...) più qualche altra funzione aggiuntiva; se invece programmi in .NET puoi usare classi come queste:
http://msdn.microsoft.com/en-us/library/system.io.ports.aspx

[|giacomo|]

Su MSDN si trovano molte informazioni e la documentazione ufficiale è decisamente completa, ma sono in tanti a preferire l'approccio organico ad un percorso di studio, approccio che solo un buon libro può dare. Inoltre sui buoni libri si trovano consigli, non inclusi nella documentazione tecnica, legati all'esperienza degli autori (quelli su DDK/WDK/WDM/WDF/etc vengono solitamente scritti da membri dei rispettivi team Microsoft). Poi se si è abituati ad usare un metodo di studio "custom" allora non ci sono problemi... :)



Concordo con 71104, l'Assembly (come linguaggio) non ti servirà quasi per niente nello sviluppo di driver.
Fin ora tutti i linguaggi che ho studiato per conto mio li ho studiati da tutorial su internet e per approffondire poi sui libri..quindi sapresti mica consigliarmi qualche bel libro per quando avro finito di studiarmi il C??Grazie!

[|giacomo|]

inoltre ti avviso che potrebbe non essere neanche necessario scrivere un driver: se ad esempio crei un circuito che si attacca al PC tramite una porta esterna (COM, LPT, USB, ...) allora puoi manovrarlo anche con un semplice programma applicativo. se scrivi il programma in Win32 puoi comunicare con le suddette porte usando l'interfaccia di I/O standard (CreateFile, ReadFile, WriteFile, ...) più qualche altra funzione aggiuntiva; se invece programmi in .NET puoi usare classi come queste:
http://msdn.microsoft.com/en-us/library/system.io.ports.aspx

Questa non la sapevo!!Quindi potrebbe risultarmi addirittura piu facile?A questo punto mi sorge il dubbio..creo un driver o mi conviene usare il secondo metodo,lasciando la creazione di driver a quando la mia esperienza e livello di studi saranno piu avanzati??Il mio scopo era solo quello di "divertirmi" ad attaccare qualcosa al pc e vedere che funzione per "mia" opera.:D

[Jean-Louis]

Fin ora tutti i linguaggi che ho studiato per conto mio li ho studiati da tutorial su internet e per approffondire poi sui libri..quindi sapresti mica consigliarmi qualche bel libro per quando avro finito di studiarmi il C??Grazie!

Se deciderai di orientarti verso linux esiste un libro chiamato Linux Device Drivers (Third Edition) (http://oreilly.com/catalog/9780596005900/) rilasciato con licenza CreativeCommons by-sa (http://creativecommons.org/licenses/by-sa/2.0/) scaricabile liberamente da questo sito LDD3 (http://lwn.net/Kernel/LDD3/)

un driver per Windows è sviluppato completamente in C, neanche una riga di assembly. se non ci credi scarica il WDK (Windows Driver Kit) e guardati tutti i drivers di esempio, non troverai una riga di assembly che sia una.

Visto che ho l'occasione, ne approfitto anch'io per una domanda :D

sono completamente all'oscuro dello sviluppo di driver per windows, ma alcuni mesi fa provai a cercare qualche informazione per capire un po' come funzionavano...

lo scopo era di vedere se riuscivo a capire come funzionava questo Filter Driver UsbSnoop (http://www.pcausa.com/Utilities/UsbSnoop/default.htm)

sul sito c'è scritto che hanno utilizzato il WDK 6000, provai a girare sul sito della microsoft, ma non ho capito se questo WDK 6000 si può scaricare gratuitamente o se c'è una licenza da pagare...

mi sapreste dare qualche informazione in più? Se c'è una licenza... quanto costa?

Grazie mille.

[agente mm8]

credo proprio che dovresti aprire un'altra discussione, Jean-Louis

[71104]

Visto che ho l'occasione, ne approfitto anch'io per una domanda :D

sono completamente all'oscuro dello sviluppo di driver per windows, ma alcuni mesi fa provai a cercare qualche informazione per capire un po' come funzionavano...

lo scopo era di vedere se riuscivo a capire come funzionava questo Filter Driver UsbSnoop (http://www.pcausa.com/Utilities/UsbSnoop/default.htm)

sul sito c'è scritto che hanno utilizzato il WDK 6000, provai a girare sul sito della microsoft, ma non ho capito se questo WDK 6000 si può scaricare gratuitamente o se c'è una licenza da pagare...

mi sapreste dare qualche informazione in più? Se c'è una licenza... quanto costa?

Grazie mille.

per il momento è tutto gratuito. registrati al sito http://connect.microsoft.com/ e dopodiché vai a questa pagina:
https://connect.microsoft.com/site/sitehome.aspx?SiteID=148
per scaricarlo clicca su Download nel menu a sinistra. ti farà installare un download manager della Microsoft, il File Transfer Manager.

[gugoXX]

Se vuoi accendere LED o pilotare ingressi di semplici circuiti elettrici/elettronici, e ti bastano 0-5V a basso amperaggio, e ti va di usare la parallela
(quindi no driver, ma un programmino che piloti la parallela a tuo uso e consumo)
Con il C# e' sufficientemente semplice.

Ed anche praticamente pronto leggendo qui
http://www.codeproject.com/KB/cs/csppleds.aspx

[|giacomo|]

Quindi anche il C# potrebbe essere una buona alternativa?Pero cercando di capire un po quello che ce all interno di quel link in pratica crea quel programmino "solo" gestendo la porta seriale..cosa che se la memoria non m' inganna si può fare anche in java e assembler..correggetemi se sbaglio!!

[|giacomo|]

[QUOTE=Jean-Louis;24745210]Se deciderai di orientarti verso linux esiste un libro chiamato Linux Device Drivers (Third Edition) (http://oreilly.com/catalog/9780596005900/) rilasciato con licenza CreativeCommons by-sa (http://creativecommons.org/licenses/by-sa/2.0/) scaricabile liberamente da questo sito LDD3 (http://lwn.net/Kernel/LDD3/)

Grazie per il consiglio!ora lo scarico!

[variabilepippo]

Quindi anche il C# potrebbe essere una buona alternativa?Pero cercando di capire un po quello che ce all interno di quel link in pratica crea quel programmino "solo" gestendo la porta seriale..cosa che se la memoria non m' inganna si può fare anche in java e assembler..correggetemi se sbaglio!!


Una valida alternativa per pilotare dispositivi connessi alle porte parallele/seriali, non certo per implementare dei veri e propri device driver. ;)

Con C#/Java/Assembly/..., così come con quasi tutti i linguaggi di programmazione decenti, puoi invocare le funzioni esposte dalla Windows API (alcune delle quali sono state suggerite da 71104) per comunicare attraverso le porte.

[71104]

cosa che se la memoria non m' inganna si può fare anche in java e assembler..correggetemi se sbaglio!! in assembly no, non si può fare (almeno non su Windows, e neanche su Linux); in Java non saprei.

[71104]

Con C#/Java/Assembly/..., così come con quasi tutti i linguaggi di programmazione decenti, puoi invocare le funzioni esposte dalla Windows API (alcune delle quali sono state suggerite da 71104) per comunicare attraverso le porte. in assembly puro di norma non si possono invocare funzioni API a causa del fatto che le DLL che le espongono potrebbero essere rilocate e quindi gli indirizzi non sono noti a priori; senza contare che servirebbe un minimo di reverse engineering per capire l'esatta calling convention (si, è una banalità, però non mi risulta che ci sia della documentazione tecnica che ufficializzi i dettagli che stanno dietro a una macro WINAPI, o CALLBACK, o altro).

per questo motivo in assembly non è possibile comunicare nemmeno con la porta seriale o parallela, ne' con le API ne' tantomeno lavorando direttamente su porte di I/O e memory ranges dedicate alla periferica; tuttavia con "assemblatori" un tantino sofisticati, come il Macro Assembler, è possibile produrre eseguibili che importano funzioni API.

[71104]

Quindi anche il C# potrebbe essere una buona alternativa? ti dico una regola generale della programmazione per Windows, vale quasi sempre: se puoi usare C#, usalo. :D

[variabilepippo]

per questo motivo in assembly non è possibile comunicare nemmeno con la porta seriale o parallela, ne' con le API ne' tantomeno lavorando direttamente su porte di I/O e memory ranges dedicate alla periferica; tuttavia con "assemblatori" un tantino sofisticati, come il Macro Assembler, è possibile produrre eseguibili che importano funzioni API.


Non riesco a pensare ad un assembler per Windows (MASM/FASM/NASM/etc) che non supporti "nativamente" (=con una banale CALL dopo aver incluso un file opportuno) l'invocazione di funzioni della Windows API... E' un po' come affermare che con il C non si possa comunicare con le API visto che bisogna includere <windows.h>. :rolleyes:

MASM:

; #########################################################################

.386
.model flat, stdcall
option casemap :none ; case sensitive

; #########################################################################

include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc

includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib

; #########################################################################

.code

start:

jmp @F
szDlgTitle db "Minimum MASM",0
szMsg db " --- Assembler Pure and Simple --- ",0
@@:

push MB_OK
push offset szDlgTitle
push offset szMsg
push 0
call MessageBox

push 0
call ExitProcess


FASM:


include 'win32ax.inc'

.code

start:
invoke MessageBox,HWND_DESKTOP,"Hi! I'm the example program!","Win32 Assembly",MB_OK
invoke ExitProcess,0

.end start

[71104]

E' un po' come affermare che con il C non si possa comunicare con le API visto che bisogna includere <windows.h>. :rolleyes: si che si può: basta ridichiarare il prototipo.

[71104]

Non riesco a pensare ad un assembler per Windows [...] che non supporti "nativamente" [...] l'invocazione di funzioni della Windows API... lo credo bene :asd: :tapiro:

[variabilepippo]

si che si può: basta ridichiarare il prototipo.


Lo so benissimo, ma non c'è bisogno di farlo né con un assembler né con un compilatore C, nessuno userebbe mai un assembler/compilatore che non venga distribuito con le dichiarazioni dei prototipi/costanti/strutture/... e con le librerie necessarie. Ciò significa che si può accedere alla Windows API anche programmando in Assembly, a meno di scegliere l'unico assembler (ne esisterà qualcuno?) per Windows privo di file di supporto.

Da un punto di vista concettuale non vedo differenze tra:


#include <windows.h>

int main(void){
MessageBox(HWND_DESKTOP, "Hi! I'm the example program!","Win32 Assembly",MB_OK);
ExitProcess(0);
}


e


include 'win32ax.inc'

.code

start:
invoke MessageBox,HWND_DESKTOP,"Hi! I'm the example program!","Win32 Assembly",MB_OK
invoke ExitProcess,0

.end start


Volendo, al posto della invoke si possono scrivere le istruzioni che compongono la macro, ma nella sostanza cambia poco o nulla.

[71104]

Lo so benissimo, ma non c'è bisogno di farlo né con un assembler né con un compilatore C, nessuno userebbe mai un assembler/compilatore che non venga distribuito con le dichiarazioni dei prototipi/costanti/strutture/... e con le librerie necessarie. Ciò significa che si può accedere alla Windows API anche programmando in Assembly, a meno di scegliere l'unico assembler (ne esisterà qualcuno?) per Windows privo di file di supporto. gli assemblatori non servono per programmare, per quello ci stanno i compilatori; gli assemblatori servono a scrivere routines in assembly da usare per svariati scopi, ad esempio codice ottimizzato da linkare ad un programma più ampio scritto in un linguaggio ad alto livello. chiamare le API Win32 da assembly a volte può essere utile ma non ce ne si fa molto.
comunque sappiamo perfettamente entrambi come stanno le cose, stiamo discutendo di aria fritta.

[cdimauro]

Alberto, io fino allo scorso millennio sviluppavo anche intere applicazioni in assembly. ;)

[variabilepippo]

gli assemblatori non servono per programmare, per quello ci stanno i compilatori; gli assemblatori servono a scrivere routines in assembly da usare per svariati scopi, ad esempio codice ottimizzato da linkare ad un programma più ampio scritto in un linguaggio ad alto livello.


In realtà si possono sviluppare intere applicazioni in Assembly anche in ambiente Windows, anche alla fine del 2008. Chiaramente, e per fortuna aggiungo io, sono in pochi a farlo, ma basta dare un'occhiata ai vari IDE per Assembly (WinAsm, RadASM, ...) implementati interamente in Assembly (!!!) per rendersi conto che si può andare ben oltre l'uso orientato all'ottimizzazione di piccole routine. ;)


chiamare le API Win32 da assembly a volte può essere utile ma non ce ne si fa molto.

Programmare con un macro assembler non è molto diverso rispetto a farlo in C, senza considerare che è molto più facile trovare strumenti RAD per Assembly in ambiente Windows rispetto a quelli per ANSI C. :rolleyes: