IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Windows Discussion :

DDK et Delphi ?


Sujet :

Windows

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    fd
    fd est déconnecté
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    131
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 131
    Par défaut
    Bon reprenons :
    Au départ il était question de la fonction :
    IoCreateDevice (j'ai parlé de driver car c'est à CA que sert cette fonction)

    Voila comment elle s'utilise :
    (j'ai tiré ça d'un driver que j'ai fait pour OCE Graphics - toutes les fonctions commençant par Oce sont de moi - les autres des fonctions du DDK)



    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    184
    185
    186
    187
    188
    189
    190
    191
    192
    193
    194
    195
    196
    197
    198
    199
    200
    201
    202
    203
    204
    205
    206
    207
    208
    209
    210
    211
    212
    213
    /*********************************************************************************************
    
      Initialisation function : call by system when driver load
    
      DO :
        create the device object with our extention (LOCAL_DEVICE_INFO)
    	try to find the PCI adapter
    	report ressource (IRQ and port to NT system)
    	initialise AMCC chip
    	connect the interrupt to our ISR
    	create symbolink link
    
      IF FAIL write to WinDbg, free ressources and return STATUS_error_code
    
    **********************************************************************************************/
    
    NTSTATUS
    DriverEntry(
        IN PDRIVER_OBJECT [b]DriverObject[/b],
        IN PUNICODE_STRING RegistryPath
        )
    {
    
        PDEVICE_OBJECT deviceObject = NULL;
        NTSTATUS status;
        UNICODE_STRING uniNtNameString;
        UNICODE_STRING uniWin32NameString;
        LOCAL_DEVICE_INFO *pDev;
    	BOOLEAN bResConflict;
    	PHYSICAL_ADDRESS PortAddress;
    	PHYSICAL_ADDRESS MappedAddress;
    	ULONG MemType;
    
    
    
        KdPrint( ("OceDrv: Entered the Load/Unload driver!\n") );
    
        //
        // Create counted string version of our device name.
        //
    
        RtlInitUnicodeString( &uniNtNameString, NT_DEVICE_NAME );
    
        //
        // Create the device object
        //
        
        status = IoCreateDevice(
                     [b]DriverObject[/b],
                     sizeof(LOCAL_DEVICE_INFO), // Our private extension (in DeviceExtension of
    				                            // DeviceObject) 
                     &uniNtNameString,
                     OCE_TYPE,              // Our defined Device Type 
                     0,                     // No standard device characteristics
                     FALSE,                 // Not exclusive device
                     &deviceObject
                     );
    
    	
        if (! NT_SUCCESS(status) )
          {
    	     KdPrint( ("OceDrv : can't create the device\n") );
    		 return(status);
    	  } 
    		
    	deviceObject->Flags |= DO_DIRECT_IO;  // method direct I/O for read/write
    	pDev = (LOCAL_DEVICE_INFO *) deviceObject->DeviceExtension;
    	pDev->DeviceObject    = deviceObject;
        pDev->DeviceType      = OCE_TYPE;
        pDev->PortCount       = PCI_NBRPORT * 4;
        pDev->OpenCount       = 0;     
    	pDev->TimerRead = pDev->TimerWrite = -1;
    
    
    	// Try to find the PCI Adapter
    
        status = pOceGetBus(deviceObject,PCI_VID,PCI_DID);
    	if(! status)
            {
                KdPrint( ("OceDrv: Couldn't find adapter\n") );
    			status = STATUS_UNSUCCESSFUL;
                IoDeleteDevice( DriverObject->DeviceObject );
    			return(status);
            }
    
    	pDev->Pbase = (pDev->PciConf.u.type0.BaseAddresses[0] & ~1); // base port of AMCC
        // we mask bit 0 because it's just the I/O indicator
    
    	pDev->Irq = pDev->PciConf.u.type0.InterruptLine;	  // Irq of AMCC
    	pDev->isIrq = FALSE;
    	
    	PortAddress.LowPart  = pDev->Pbase;
        PortAddress.HighPart = 0;
    
    	
    	// Convert the IO port address into a form NT likes.
    	MemType = 1;                        // located in IO space
    	HalTranslateBusAddress( PCIBus,
    				0,
    				PortAddress,
    				&MemType,
    				&MappedAddress );
    
    
    	if (MemType == 0)
    	{
    	    // Port is accessed through memory space - so get a virtual address
    
    	    pDev->PortWasMapped = TRUE;            
            pDev->PortBase = MmMapIoSpace(MappedAddress, pDev->PortCount, FALSE);
    	}
    	else
    	{
    	    pDev->PortWasMapped = FALSE;
    	    pDev->PortBase = (PVOID)MappedAddress.LowPart;
    	}
    
      
    	PortAddress.LowPart  = (ULONG) pDev->PortBase;
        
    	// report the status to NT system
    	if(! pOceReportUsage(DriverObject,PortAddress,pDev->PortCount,pDev->Irq,&bResConflict))
    	  {
    	     status = STATUS_DEVICE_CONFIGURATION_ERROR;
    	     KdPrint( ("Resource reporting problem %8X", status) );
             pOceUnMap(DriverObject);
    		 IoDeleteDevice( DriverObject->DeviceObject );
    		 return status;
    	   }
    
    	// Init our Irq
    	if(! pOceConnectInterrupt(pDev,pDev->Irq))
    	  {
    		 status = STATUS_BIOS_FAILED_TO_CONNECT_INTERRUPT;
    	     KdPrint( ("Interrupt Not connected %8X", status) );
    		 pOceUnMap(DriverObject);
    		 pOceUnreport(DriverObject);
    		 IoDeleteDevice( DriverObject->DeviceObject );
    	     return(status);
    	  }
        
    
            //
            // Create dispatch points for create/open, close, unload.
            //
    
            [b]DriverObject[/b]->MajorFunction[IRP_MJ_CREATE] = OceOpen;
            DriverObject->MajorFunction[IRP_MJ_CLOSE] = OceClose;
            
    		
    	DriverObject->MajorFunction[IRP_MJ_READ] = OceRead;	  // Read
            DriverObject->MajorFunction[IRP_MJ_WRITE] = OceWrite;  // Write
            DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = OceDispatch; // Ioctl
    
    	DriverObject->DriverStartIo = OceStartIo;
    
            DriverObject->DriverUnload = OceUnload;
    
    
            //
            // Create counted string version of our Win32 device name.
            //
        
            RtlInitUnicodeString( &uniWin32NameString, DOS_DEVICE_NAME );
        
            //
            // Create a link from our device name to a name in the Win32 namespace.
            //
            
            status = IoCreateSymbolicLink( &uniWin32NameString, &uniNtNameString );
    
            if (!NT_SUCCESS(status))
            {
                KdPrint( ("OceDrv: Couldn't create the symbolic link\n") );
    			pOceUnMap(DriverObject);
                pOceDiscInterrupt(DriverObject);
    			pOceUnreport(DriverObject);
    		    IoDeleteDevice( DriverObject->DeviceObject );
            }
    		/************/
    		if(! pOceInitTimer(deviceObject))
    		{
    		    KdPrint( ("OceDrv: Can't create timer\n") );
    			status = STATUS_INSUFFICIENT_RESOURCES;
    			pOceUnMap(DriverObject);
                pOceDiscInterrupt(DriverObject);
    			pOceUnreport(DriverObject);
    			IoDeleteSymbolicLink(&uniWin32NameString); 
    		    IoDeleteDevice( DriverObject->DeviceObject );
    		}
            else
            {
    
    			pOceGetAdapter(pDev);
    			// init our event for pOceAdapterControl
    	        KeInitializeEvent(&(pDev->AdapterChannelEvent),NotificationEvent,FALSE );
    			// init our event for pOceDpcForIsr()
    			KeInitializeEvent(&(pDev->ReadInterruptEvent),SynchronizationEvent,FALSE);
    			KeInitializeEvent(&(pDev->WriteInterruptEvent),SynchronizationEvent,FALSE);
    
    
    			// init our DPC for ISR
    	        IoInitializeDpcRequest(deviceObject,pOceDpcForIsr);
    
    			AMCC_LoadRegister(&(pDev->DrvPort),pDev->PortBase);
    			bidon(pDev);
    
            	pOceInitDma(&(pDev->DrvPort));
    			KdPrint( ("OceDrv: All initialized!\n") );
            }
        return status;
    }
    Comme vous pouvez le remarquer le DriverObject est passé au driver par Windows.
    IL n'y a aucun moyen de reconstituer cet objet soi méme.

    PS : pour les bouquins je te recommande plutot :
    Programming the WDM de W. Oney

  2. #2
    Membre confirmé Avatar de - Robby -
    Inscrit en
    Juillet 2003
    Messages
    266
    Détails du profil
    Informations forums :
    Inscription : Juillet 2003
    Messages : 266
    Par défaut
    Merci fd !
    Joli morceau de code !
    Retiré de l'ensemble, Il serait difficile d'arriver a en tirer toute
    la "substance" bien évidemment. Mais la, n'est pas le propos.
    Je te remercie beaucoup d'etre revenu me faire signe en me donnant
    ces quelques éléments de compréhension.
    Ces quelques lignes sont de toute facon bien intéressantes,
    quand a leurs structures et leur enchainement.
    Merci également pour l'info bouquin.
    Merci fd, sympa

  3. #3
    fd
    fd est déconnecté
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    131
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 131
    Par défaut
    he bien la méthode du call gate est intéressante (quoique je sois de l'avis de HW c'est pas la chose à faire)

    et bien évidement c'est pas dans les docs Microsoft, c'est dans la doc Intel !

  4. #4
    Membre confirmé Avatar de - Robby -
    Inscrit en
    Juillet 2003
    Messages
    266
    Détails du profil
    Informations forums :
    Inscription : Juillet 2003
    Messages : 266
    Par défaut
    Oui, fd, le CallGate .. intéressant oui ... mais le CallGate pose un soucis important, en tout cas sous XP ! Je rentre pas dans les détails ... a moins que tu ne le désires, mais ce n'est pas une manière fiable de pouvoir acceder au ring0 sous XP. CallGate est parfait dans l'absolu ... mais avec XP cela forme un couple instable. Et je suis de toute facon d'accord avec toi ... ce n'est pas une facon totalement pro d'acceder au mode kernel !
    Ceci étant dit, toutes ces méthodes, qualifiées de bidouilles par Hw ... et je ne suis pas totalement contre son avis, permettent d'apprendre énormément de choses, réellement, c'est une voie royale pour apprendre. La plus belle des facons est de construire sa propre table de service et ensuite de passer en ring0 via l'instruction Sysenter. Cette méthode, bien que non conformiste également, a l'avantge de s'intégrer beaucoup mieux au fonctionnement meme de windows. Elle est fiable et ne pose aucun soucis de stabilité. Le seul soucis est : comment construire cette table proprement. IL y a différentes méthodes, mais qui sortent probablement du sujet initial de cette discussion. Mais chemin faisant d'avoir un peu épuisé tout cela ... je me retrouve devant le driver. Si ce domaine intéresse ... que celui qui aimerait en savoir plus, ouvre un sujet, j'y participerai avec plaisir.
    (je tiens a associer a tout ceci .. Chris_Hks et YoLeJedi ... mes pères )
    Merci a toi fd ,

  5. #5
    Expert confirmé

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 756
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 756
    Billets dans le blog
    3
    Par défaut
    Ceci étant dit, toutes ces méthodes, qualifiées de bidouilles par Hw ... et je ne suis pas totalement contre son avis, permettent d'apprendre énormément de choses, réellement, c'est une voie royale pour apprendre.
    Il me semble avoir dit plusieurs fios que c'était la seule excuse valable à mes yeux à l'utilisation de bidouilles (de manière générale).

  6. #6
    Membre confirmé Avatar de - Robby -
    Inscrit en
    Juillet 2003
    Messages
    266
    Détails du profil
    Informations forums :
    Inscription : Juillet 2003
    Messages : 266
    Par défaut
    Oui, c'est exact Hw ...
    Quand vous déciderez vous a faire le pas de nous apprendre la différence? ...
    Oui, c'est de la bidouille ! mais de la bidouille de qualité !
    Heureux qui comme Ulysse pourra me trouver un CallGate en Delphi mis a part le mien ! ... sur tout le Net ... ! Idem pour l'utilsation d'une table de services perso, tout en Delphi ... c'est introuvable, ca sur le Net !
    Un driver mode kernel tout complet, ca aussi c'est introuvable !
    Mais, force est de constater que tout cela n'est qu'une étape ! Pourquoi ne pas aller plus loin ? et nous faire cadeau d'éléments qui nous permettraient de ... heu ... changer de camp ?
    Je déconne ... de toute facon, on trouvera, on est mordu ! ... mais c'est vrai qu'avec votre aide, ce serait plus facile ! ... Perso, je suis bloqué pour alimenter ce débat. Pour aller plus loin, il me faut la connaissance du C, donc du temps.
    Et j'en reviens au début du débat,
    NON, il n'est pas possible d'implémenter un driver en Delphi ...
    OUI, il s'agit la d'une limite évidente des possibilités de Delphi. (cqfd)
    Respect a toi Hw ...

  7. #7
    fd
    fd est déconnecté
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    131
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 131
    Par défaut
    avec le ddk il y a tout un tas d'exemple de driver en mode kernel.
    Dont un qui fait exactement ce que vous faite (mapview etc...) et qui permet d'avoir un pointeur sur de la memoire physique, et qui, comme c'est un driver, marchera dans tous les cas.

    Pour revenir au ring 0 je me suis posé la question de l'utilité de la chose.
    Il m'apparait qu'une des seules utilités serait de pouvoir attaquer les ports IO.
    Ce qui est en principe totalement déconseillé !

    (je suis interessé par les "soucis importants" sous XP)

    Si tu te met aux driver et si je peux t'aider n'hésite pas.

    (un premier conseil : si tu developpe un driver procure toi un second pc et une rs232 croisée (le windbg n'utilise que 2 fils r/w, peu importe le cablage du reste) cela permet un debug au niveau du code source)

    d'autre part jette un coup d'oeil aux exemples fournis avec le ddk.

  8. #8
    Membre confirmé Avatar de - Robby -
    Inscrit en
    Juillet 2003
    Messages
    266
    Détails du profil
    Informations forums :
    Inscription : Juillet 2003
    Messages : 266
    Par défaut
    Avant d'essayer d'etre intelligent, une question débile ..
    Je ne trouve pas les exemples dont tu parles dans le DDK !!!
    ca se trouve ou ? ... La, je vais faire rigoler !
    Mais la fin justifie les moyens, un moment de honte est vite passé
    Bon, on y va:
    Une liaison croisée rs232 pour débugger du code ring0 ?
    Mais j'ai ce qu'il faut pour ca, et avec un seul PC.
    Mais peut etre que le systeme "2 pc" permet d'avantage ? Je ne vois pas quoi. A toi de me dire fd.

    Les soucis particulier entre CallGate et XP.
    Je ne sais pas si c'est totalement typique a xp, mais en tout cas, CallGate+XP c'est un couple non fiable et inexploitable pratiquement.
    La différence entre un passage en Ring0 via CallGate ... par rapport a un passage via Sysenter ... ou via un vecteur d'exeption dévié (par exemple le n°0 avec un "mov eax,0 div eax") .. est que le CallGate ne positionne pas, a son arrivée en ring0, l'interrup flag a 0.
    Sysenter, une interruption soft (div 0), oui !
    Ca pose un problème majeur ! Sous Xp, le registre FS est tjs a 38h en ring3 et tjs a 30h en ring0 (la chose est reconnue et documentée).
    Donc,... sous XP, quand on arrive en ring0, il faut placer le registre FS a 30h . Si on passe en ring0, via un sysenter et une table se service perso ou une entrée de la table principale de windows déviée, pas de problème ... intrinsèquement le Systenter place IF a 0 et a donc tout le temps pour faire son " mov X,30h + mov fs,X ". Ensuite, une fois cette opération faite, il fait STI ! J'ai débuggé le code du "dispatcher" de service de windows (code d'arrivée avec un sysenter ... pas question de reprogrammer le sysenter sous xp, bien entendu!) ... et cela se passe comme ca ... et pas de soucis. Idem avec une soft Int ... ce type d'instruction zérote e IF ... on a donc tout le temps de positionner FS aussi. Mais avec CallGate, nada, pas de If=0 ... conclusion, la, on est dans l'urgence pour placer FS a 30h. Le départ d'un callGate est en fait un "Call Far [eax]" ... on a donc ceci:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
      asm
          pushad
          push  fs
          push  Ma_Demande
          mov   ebx, 00000030h       // FS d'arrivée.
          mov   eax, offset CgCall
          
    dw    Call_Far_eax         // Call far ptr [eax] ... --> Ring0 --> @tremplin
    
          pop   fs
          popad
    end;
    
    et le code de " mon dispatcher ring0 " ...
    TOTO ....
     asm     // ici <=====
          mov   fs, bx       // bx = 30h.
          mov   eax, cr0   // ... je suis bien en ring 0 !
          call  &#91;esp+8&#93;      // ici, je Call a " Ma_Demande ".  call  &#91;esp + 8&#93;
          retf  4               // et retour juste après le Call Far.
       end;
    Avec le Call far , je saute en ring0 a "TOTO" et le retf me fait repasser
    en ring3. Mais ... la ou j'ai marqué " ici <===== ", y'a un gros soucis !
    Si Windows (le gestionnaire de taches) prend la main entre le "Call Far" et ma 1ere instruction ring0, celle qui place FS a 30h , boum !
    Et ca arrive ! , une fois sur 500 environ, si je place le Callgate en boucle.
    Le Kernel prend la main sur une tache sensée etre en ring0, alors que le registre FS est toujours a 38h .... je me retrouve (j'ai debuggé) sur une fonction du kernel (KidispatchInterrup ... je sais plus de mémoire) et je tombe sur une instruction du type " mov eax, FS:[eax+165]" et la, vu que FS est tjs a 38h, j'ai une "fault page". Normal !
    J'ai retourné le problème dans tous les sens, tu t'en doutes, mais rien a faire. Faudrait pouvoir placer IF a 0 avant le Call Far, en ring3, mais ca, c'est impossible. Encore une fois, ce soucis ne se présente pas avec des instruction "de départ" qui positionne IF a 0.

    PS:
    a) je viens de faire connaissance avec Dev-C++, freeware.
    Ce "truc" est un environnement complet de développement C++.
    De plus il incorpore d'origine les fichiers du DDK, je prend comme exemple Ntddk.h, Winddk.h et LibNtOsKrnl.a ... qu'en penses tu ?
    b) Oui, le but final, ce sont les ports I/O (acquisition en temps réel et convertisseur D/A)... mais le but final est devenu accessoire pour le moment ! c'est trop intéressant tout ca ! Fd ... a partir du moment ou tu veux faire qq chose toi meme, meme proprement, c'est de toute facon déconseillé par Microsoft. Si mon PC, lui , a de quoi dialoguer avec les I/O, je ne vois pas pourquoi je ne pourrais pas impléménter la chose moi meme ! Il faut s'incorporer nickel dans la dynamique de Windows.

    Merci pour ta proposition de "coup d'main ", ca c'est sympa !
    Oui, je veux bien ... mais doucement ! plus j'avance plus je me dis que oui, effectivement ... suis pas a deux doigts ! allez ... cinq ..

  9. #9
    fd
    fd est déconnecté
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    131
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 131
    Par défaut
    Tu peux débogger en code source avec un seul PC ?
    je suppose que tu utilise soft-ice ou un truc comme ça.
    Les exemples du ddk étaient livré avec l'abonnement Msdn, a ce que tu dis il n'ont pas l'air d'étre sur le net

  10. #10
    Membre confirmé Avatar de - Robby -
    Inscrit en
    Juillet 2003
    Messages
    266
    Détails du profil
    Informations forums :
    Inscription : Juillet 2003
    Messages : 266
    Par défaut
    Oui Fd, le debugger que j'utilise permet de debugger du code ring0 avec un seul Pc. Concernant le ddk, je l'ai acheté sur cd-rom directement chez microsoft au USA ... mais sur ce cd-rom, je ne vois pas les exemples dont tu parles ? ...
    As tu d'autres info a ce sujet ?
    Et le soucis précédemment exposé concernant Callgate, ton avis ?
    merci fd,

  11. #11
    fd
    fd est déconnecté
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    131
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 131
    Par défaut
    J'ai regardé mes CD, hélas microsoft ne distribue plus les exemples.
    Ceux que j'ai date du ddk pour NT 4

    Pour le Callgate, comme tu l'as dit, ça ne semble pas exploitable.
    D'autant qu'il existe des drivers tout fait qui permettent, via des ioctl, de
    programmer un port

    pour le debug, a moins de pouvoir le lancer AVANT XP, tu ne pourra pas débogger driverentry

  12. #12
    Membre confirmé Avatar de - Robby -
    Inscrit en
    Juillet 2003
    Messages
    266
    Détails du profil
    Informations forums :
    Inscription : Juillet 2003
    Messages : 266
    Par défaut
    Oui, ok ... je vais m'équiper en double pc alors.
    Non, Callgate sous XP est un cas d'école fort fort intéressant a implémenter, mais non réellement exploitable. Oui, bien entendu qu'il y a des Driver tout fait comme tu dis ! Mais en ce qui me concerne, c'est un chemin totalement non commercial. On apprend rien a utiliser des trucs tout fait.

  13. #13
    Membre confirmé Avatar de - Robby -
    Inscrit en
    Juillet 2003
    Messages
    266
    Détails du profil
    Informations forums :
    Inscription : Juillet 2003
    Messages : 266
    Par défaut
    Une seule question ... juste pour le plaisir ...

    S'il n'y a pas de réponse, ce sera ----->[résolu]
    voici:
    Existe t il la moindre information, quelque part ..., pour pouvoir utiliser le DDK de Mircosoft depuis Delphi ... ou ...
    une quelconque facon d'arriver a implémenter un Driver sous Delphi en "bypassant" le DDK ?


    Juste un dernier "Baroud d'Honneur" ... avant d'abandonner le navire ... ... promis !

    [edit]
    Voila, That's All ! ... Merci a tous pour votre participation.

  14. #14
    fd
    fd est déconnecté
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    131
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 131
    Par défaut
    La réponse est claire : non

    Maintenant il existe un moyen de gérer du matériel en turbo pascal (c'est une méthode peu efficace mais qui existe)

    1) tu écris un pgm dos ou win16 (le mieux c'est dos) ou tu fais tes in/out, tu détourne ton IT etc...

    2) tu fais un vdd (en delphi ça doit être possible car, bien que les fonctions du vdd soient ds le ddk, elle travaillent en mode user)
    un vdd te permet de "trapper" les in/out, les it et les accés direct en mémoire (ça c'est assez compliqué, le reste est simple)

    3) he oui t'y échappe pas il te faut un driver que le vdd utilisera (mais ce driver est minimaliste)

    evidement c'est pas trés efficace. Exemple :
    ton pgm dos fait un in
    exception géré par le kernel
    appel du callback du vdd
    appel du vdd au driver

  15. #15
    Membre confirmé Avatar de - Robby -
    Inscrit en
    Juillet 2003
    Messages
    266
    Détails du profil
    Informations forums :
    Inscription : Juillet 2003
    Messages : 266
    Par défaut
    Je te remercie pour cette piste supplémentaire fd.
    "trapper" une instruction interdite ... oui ... je peux faire ca, pas de problème.
    Mais pas avec un vdd. Je n'ai jamais abordé cette notion de vdd. Ecrire un vdd avec Delphi, j'en doute. Oui, les fonctions utilisées tournent en mode user, mais la n'est pas le soucis. Delphi est incapable de dialoguer avec les header et les librairies de ddk. Une fonction qui s'exécute en ring0 ne pose pas de soucis a Delphi, encore faut il y avoir acces ! Je suis en "transition" pour le moment ... j'attends un environnement c++ de qualité (Noel faisant, je vais m'offrir Visual Studio .Net ) et je passe du temps en recherche de doc. J'attends 2 bouquins des usa et je scanne la planète a propos du livre en francais.

  16. #16
    fd
    fd est déconnecté
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    131
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 131
    Par défaut
    il n'y a aucune raison pour laquelle tu ne puisse pas écrire un vdd en delphi : ça tourne en ring 3

  17. #17
    Membre confirmé Avatar de - Robby -
    Inscrit en
    Juillet 2003
    Messages
    266
    Détails du profil
    Informations forums :
    Inscription : Juillet 2003
    Messages : 266
    Par défaut
    heu ... je comprends pas la fd.
    Peu importe ring3 ou ring0 ! Delphi n'est absolument pas réfractaire au ring0. J'exécute du code en ring0 sous Delphi chaque matin !
    Non, le soucis c'est la non accessibilité des librairies du ddk depuis Delphi. Les fichiers de déclarations, les header .h du ddk, c'est pas un soucis ca. Je déclare moi meme. Mais les librairies .Lib du ddk, niet.
    Si pour faire un vdd, il faut utiliser des fonctions api du ddk, le problème est identique au soucis déjà rencontré.
    Depuis Delphi, c'est non !
    Ou alors ... je comprends plus rien !

  18. #18
    fd
    fd est déconnecté
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    131
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 131
    Par défaut
    le ddk c'est le nom d'un produit.
    il contient plusieurs lib, les lib du vdd étant des dll du mode user il n'y à pas de raison que tu ne puisse pas les linker
    (bon j'ai pas essayé, faudrait vérifier, mais à priori je vois pas pourquoi ça serait pas possible)

  19. #19
    Membre confirmé Avatar de - Robby -
    Inscrit en
    Juillet 2003
    Messages
    266
    Détails du profil
    Informations forums :
    Inscription : Juillet 2003
    Messages : 266
    Par défaut
    comment veux tu linker un fichier .lib avec Delphi ?
    Il doit certainement me manquer un truc de compréhension,
    mais je ne vois pas ce que le mode user ou le mode kernel vient faire ici ?
    Si je pouvais utiliser les .lib depuis delphi, je place tout de suite NtOsKrnl.lib dans "uses", je déclare moi meme et hop, j'implémente un driver sous Delphi. Avec delphi, ce sont des .dll avec la déclaration external... Les .lib , il ne connait pas. C'est le centre du problème depuis le départ en fait. En Delphi, je me débrouille, mais en C , je débute !
    En Delphi, les déclarations se trouvent dans des .dcu , ces .dcu font référence a des .dll dans lesquels il y a le code. En C, les déclarations se trouvent dans des .h , et ces .h font références a des .lib dans lesquels il y a le code, non ? je me trompe peut etre ! ...
    Si je me trompe, alors je pose la question suivante :
    repenons notre fameuse fonction "IoCreateDevice"
    Quand j'utilise cette fonction au départ du language C (C++),
    via sa déclaration contenue dans Ntddk.h ...
    ou se trouve le code de cette fonction (code machine) ....
    pas dans NtOsKrnl.lib ? alors ou ? quelle dll ? quel fichier ? ...
    Ta réponse m'intéresse au plus haut point fd, merci.

  20. #20
    fd
    fd est déconnecté
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    131
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 131
    Par défaut
    Je sais pas mais je vais chercher.

    Bon pour le reste si tu ne peux pas linker un .lib, tu peux avec LoadLibrary et GetProcAddress charger dynamiquement les fonctions du vdd :
    en c ça donne :
    HMODULE hm = LoadLibrary("C:\\WINDOWS\\ServicePackFiles\\i386\\ntvdm.exe");
    void *p = GetProcAddress(hm,"VDDAllocMem");

    j'ai mis p en void * j'étais pressé
    et hm et p ne sont pas NULL donc ça marche

    Au fait : j'ai installé le ddk xp et il y a des sources d'exemple avec

+ Répondre à la discussion
Cette discussion est résolue.
Page 3 sur 4 PremièrePremière 1234 DernièreDernière

Discussions similaires

  1. Différences entre Delphi et Visual Basic ?
    Par Anonymous dans le forum Débats sur le développement - Le Best Of
    Réponses: 75
    Dernier message: 30/03/2009, 20h09
  2. Réponses: 1
    Dernier message: 13/05/2002, 09h19
  3. [Kylix] Migration delphi -> kylix
    Par Christian dans le forum EDI
    Réponses: 1
    Dernier message: 03/04/2002, 22h50
  4. Réponses: 4
    Dernier message: 27/03/2002, 11h03
  5. Réponses: 2
    Dernier message: 20/03/2002, 23h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo