.net - Interface med enhedsdriver fra administreret kode - nej P/Invoke?

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg begynder at dykke ind i nogle Windows 7-driverudvikling. En ting, der ikke er klart, er, hvordan et administreret kodeprogram kan få adgang til information fra føreren (kommunikerer f.eks. Med et digitalt I/O-kort).


For eksempel vil en driver (kerne- eller brugerfunktion) styre adgang til registre på et PCI/PCIe-kort, men læsning/skrivning af registerdata skal være tilgængelig for en programmør, der skriver styret kode (C #, VB.NET) via en .NET klasse.


Jeg ønsker ikke at ty til P/Invoke som i Win32API-opkald.


Er dette et spørgsmål om hukommelsesdeling (IOCTL), bruger jeg en mellemliggende administreret DLL til at 'skjule' P/Invoke, eller er der noget, som jeg mangler?


Tak!

Bedste reference


Hvis du vil dykke ind i Windows 7-driverudvikling, skal du ikke bruge styret kode overhovedet. Men hvis du mener at du vil ringe til visse drivere, kan du bruge forskellige teknikker, og P/Invoke er nok det nemmeste.


Årsagen er enkel: Enhedsdrivere er uhåndterede af deres natur, derfor skal du bruge en teknik som P/Invoke. Her er et eksempel på, hvordan du kan påberåbe enhedsdrivere. Og her kan du tale med en USB-enhed. [1] [2]


Jeg forstår din vrede mod P/Invoke. Men på en eller anden måde behøver du at bygge bro over kløften mellem forvaltet og uhåndteret. Du kan gøre alt for hånden (ved hjælp af dine egne marshalere og alt), men jeg foreslår at du kun skulle ty til det, hvis normal P/Invoke ikke gør det passer til jobbet. Selvfølgelig kan du altid gemme kompleksiteten ved at lave et tyndt lag sæt af klasser, der gør de grådige detaljer i grænsefladen, og så kan du ringe dette selvfremstillede bibliotek frit fra administreret kode.