BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 27 nov. 2006 à 09:37
VXD, c'est pour un antiquaire ???
Un driver en VB6... JAMAIS ni dans nimporte quel autre langage interprété (.net, java, etc...).
Il n'y a que les 2 seuls vrais langages, ASM et C, avec lesquels on puisse faire du kernel mode.
Je trouve un peu bizzare qu'à ton age tu puisses encore croire des publicités mensongères aussi grossières. La prog système en user mode étant deja inaccessible aux interprétés (hook CBT, etc...), il est insencé de penser qu'on puisse charger une virtual machine (prog user mode) dans l'espace kernel.
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 27 nov. 2006 à 11:33
VxD, c'était pour Windows 3.1 et Windows 95.
Depuis les drivers sont des drivers systèmes et ils ont l'extension .sys.
Donc en VB6 pour utiliser un driver, il te faut le dirvers (.sys) d'installer dans le système + une dll qui va faire l'interface entre le drivers et l'appli VB.
Ce que fait WinDriver est certainement un pseudo drivers basé sur un drivers générique propriétaire et une dll assez polyvalente pour pouvoir personalisé ton gout l'accès au driver véritable et ainsi avoir un pseudo drivers spécifique.
C'est ce que fait par exemple le produit WinRt de BlueWaters.
Quant à développer un vrai driver, uniquement en C "classique" ou ASM (pas de .net) et encore normalement il te faut le DDK pour pouvoir compilé en mode kernel.
---- Sevyc64 (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 27 nov. 2006 à 12:05
Je confirme WinDriver créer des pseudo drivers qui font appel à leur driver système windrvr6.sys
J'ai tenté de creer un driver (très basique, j'ia validé les différentes questions du wizard sans vraiment lire). J'ai effectivement un projet VB incluant les codes VB du driver dans un rpogramme d'exemple ou de test.
Première constatation : l'organistaion des fichiers me semble un peu fouillis.
Pour résumer Epson1, il va falloir que tu étudie ces sources, pour d'une comprendre comment elles marchent (il est possible que ce ne soit pas très simple), et de deux, pour savoir quels fichiers conserver (drivers), et quel fichiers rejetter (programme d'exemple).
A vérifier, mais je dirais quà priori les contenant le nom de ton projet dans leur noms, ne doivent pas faire partie du drivers.
Par contre je te conseille de bien lire l'aide de WinDriver (notamment pour faire le pack de distribution à la fin), ça à l'air quand même complexe.
---- Sevyc64 (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #
cs_epson1
Messages postés89Date d'inscriptiondimanche 12 novembre 2000StatutMembreDernière intervention29 mars 2013 28 nov. 2006 à 02:28
Merci beaucoup BruNews et Casy pour vos réponses aussi rapides .
Grâce à vous ,je viens d'apprendre et ,je pense ,comprendre un tas de choses .
Donc ,si j'ai bien compris ,le vrai driver ,c'est windrvr6.sys ,et WinDriver ne fait que fournir les APIs pour accéder au matos ?
Encore merci pour vôtre aide .
Bonne prog à tous .
Vous n’avez pas trouvé la réponse que vous recherchez ?
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 28 nov. 2006 à 11:02
Tu as bien compris.
En restant très général, on peut considéré qu'un driver (je parle ici du .sys et de la dll associée) est composé de 2 parties.
- l'accès physique ou matériel au périphérique (registre, port, zone mémoire). Cette partie est prise en charge par le driver et est inaccéssible à l'utilisateur
- l'accès aux fonctionnalités du périphérique. Pour cette partie, le driver fournis des API à l'utilisateur pour accèder au périf. Il se charge de faire l'interface entre ces api et le matériel en utilisant les fonctions de la partie "physique". C'est transparent pour l'utilisateur.
Dans le cas précis de WinDriver, les focntionnalités du périphérique sont par définition inconnues. Cependant créer un driver de toute piece sous Windows n'est pas simple. L'astuce est de fournir un driver générique prenant en charge la partie "physique" et fournissant au programmeur les api pour accèder à son matériel à travers le driver générique.
A charge au programmeur d'effectuer maintenant la partie "fonctionnalité" de son driver (gestion de la mémoire, des registres du périphérique, .....). Libre à lui de faire une gestion directe comme dans l'exemple de demo, ou de se creer des api (module VB, dll, ...) plus simple à utiliser
---- Sevyc64 (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #