Discussion :

[camboui]

J'ai installé le DDK pour pouvoir faire appel à certaines fonctions qui ne se touvent pas dans l'API.

J'ai eu quelques difficulté avec les include, par exemple
#include <windows.h>
#include <ntddk.h>
ensemble ne font pas bon ménage.

Ensuite il y a un problème de link car une fonction est définie dans deux modules, ntdll.lib et libcmtd.lib
Comment résoudre cette ambiguité ?
Merci.

[Mac LAK]

Le DDK est fait pour créer du code kernel, pas du code user... C'est normal que les deux entêtes principaux se bouffent le nez, et ce n'est pas prêt de s'arranger !

[camboui]

Ok, ça c'est résolu en utilisant des .cpp différents.

Reste le problème de link. En fait en link dynamique c'est OK mais en link statique ça ne passe pas
Une idée pourquoi ?

[Mac LAK]

Reste le problème de link. En fait en link dynamique c'est OK mais en link statique ça ne passe pas

Tu ne peux PAS mélanger du code niveau kernel et niveau user dans le même processus... Ce n'est pas parce que ça linke que ça va marcher, ou que ça passera sur une machine "normale" (= sans le DDK installé).

Si tu veux utiliser une fonction kernel dans un programme en mode user, tu dois créer un driver dédié (ou utiliser un driver existant effectuant le boulot) qui fera le "pont" entre les deux mondes. C'est la seule méthode réellement propre et fiable.

En l'occurrence : quelle(s) fonction(s) kernel cherches-tu à utiliser ?

[camboui]

L'API a certaines lacunes qui sont comblées par des fonctions dispo ailleurs ou non documentées.

Je suis en mode user, je cherche simplement à utiliser les fonctions ZwXxx qui se trouvent dans ntdll.dll. En particulier ZwQueryInformationFile().
Le but est de faire du logging en cas d'erreur IO. Je ne trouve pas qu'il soit utile de stocker les informations en amont, infos dont je n'ai pas besoin en tant normal. Je souhaite que l'OS me fournisse cette info si nécessaire.
Exemple typique: retrouver le nom d'un fichier dont on ne connait que le handle.

[homeostasie]

Au lieu de passer par un driver afin d'exécuter du code kernel comme l'a dit Mac LAK pour utiliser des fonctions de type Zw(n)*(x), passe par la récupération de l'adresse de ta fonction exportée par le module ntdll.
Pour cela, utilise GetProcAddress().

Allez je mets un exemple pour la fonction NtQueryInformationFile():

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
typedef long NTSTATUS;

typedef NTSTATUS (NTAPI *NTQUERYINFORMATIONFILE)(
    IN  HANDLE                 FileHandle,
    OUT PIO_STATUS_BLOCK       IoStatusBlock,
    OUT PVOID                  FileInformation,
    IN  DWORD                  Length,
    IN  FILE_INFORMATION_CLASS FileInformationClass
    );

NTQUERYINFORMATIONFILE NtQueryInformationFile = NULL;

int main()
{
    NTSTATUS status = -1;
    HMODULE hNtdll = NULL;

    hNtdll = LoadLibrary("ntdll.dll");
    if(hNtdll == NULL)
        return EXIT_FAILURE;

    NtQueryInformationFile = (NTQUERYINFORMATIONFILE)GetProcAddress(hNtdll, "NtQueryInformationFile");
    if(NtQueryInformationFile == NULL)
        return EXIT_FAILURE;

    // Utilisation de NtQueryInformationFile() à ta guise

    FreeLibrary(hNtdll);

    return 0;
}

Je te laisse définir les structures nécessaires pour pouvoir compiler.

;-)

[Mac LAK]

L'API a certaines lacunes qui sont comblées par des fonctions dispo ailleurs ou non documentées.

Certes, mais il est en général dangereux et/ou caractéristique d'une "mauvaise pratique" de les utiliser. Si elles ne sont pas publiées "normalement", c'est qu'il y a une bonne raison.

Dans ton cas, cela revient à peu près à la même chose que d'aller "fouiller" le contenu interne d'une structure FILE* (en C) pour trouver des informations sur le fichier en cours d'utilisation... Chose hautement non-portable, bien sûr, mais également très dangereux car cela peut changer d'une version à l'autre du compilateur.

Je suis en mode user, je cherche simplement à utiliser les fonctions ZwXxx qui se trouvent dans ntdll.dll. En particulier ZwQueryInformationFile().
Le but est de faire du logging en cas d'erreur IO. Je ne trouve pas qu'il soit utile de stocker les informations en amont, infos dont je n'ai pas besoin en tant normal. Je souhaite que l'OS me fournisse cette info si nécessaire.
Exemple typique: retrouver le nom d'un fichier dont on ne connait que le handle.

Normalement, tu es censé utiliser les fonctions NtXxx en mode user, et pas les ZwXxx.

Pour l'exemple que tu cites, tu as GetFileInformationByHandleEx (API Win32 "normale") qui répond à ton besoin, et qui sera nettement plus propre à utiliser.