Discussion :

[smyley]

Simple curiosité, peut on créer un driver grâce à un code managé ?
Je crois que directement l'écrire par exemple en C# ne sera pas possible, car j'ai jamais vu quelqu'un charger le CLR en mode noyau (), mais par exemple créer un driver qui utilise un service en mode utilisateur pour faire les véritables, qui lui est fait en .NET. On aurai par exemple une architecture où le C++ est là qu'en tant que wrapper pour le service managé.

Réalisable ou pur utopie ?

Merci d'avance (en espérant qu'une bonne âme me répondra )

[tomlev]

Tiens, c'est marrant, je me posais justement la question tout à l'heure en répondant à un autre post...
Enfin, à mon avis c'est pas gagné !
Il faudrait poser la question sur les forums MSDN

[smyley]

Rolala, aller jusque là, en anglais en plus
I'll see.

[tomlev]

qui sait, peut-être qu'un jour viendra où le noyau de windows fonctionnera sous .NET
bon ok, c'est pas très réaliste...

[smyley]

Ben en fait si c'est réaliste, regarde du coté de Singularity

[Thomas Lebrun]

Simple curiosité, peut on créer un driver grâce à un code managé ?
Je crois que directement l'écrire par exemple en C# ne sera pas possible, car j'ai jamais vu quelqu'un charger le CLR en mode noyau (), mais par exemple créer un driver qui utilise un service en mode utilisateur pour faire les véritables, qui lui est fait en .NET. On aurai par exemple une architecture où le C++ est là qu'en tant que wrapper pour le service managé.

Réalisable ou pur utopie ?

Merci d'avance (en espérant qu'une bonne âme me répondra )

Disons que si l'on suit ton raisonnement, tu souhaites:
- créer un driver C++
- faire un wrapper en .NET (C#/C++)
- Utiliser ce driver via le wrapper

Dans ce cas là, oui, c'est possible (COM Interop) mais au final, tu ne fais pas ton driver en managé

[smyley]

Disons que si l'on suit ton raisonnement, tu souhaites:
- créer un driver C++
- faire un wrapper en .NET (C#/C++)
- Utiliser ce driver via le wrapper

No, you didn't got it.

Ce que je voudrais savoir c'est si on peut
- créer un squelette de driver en C++
- faire le véritable code dans un service Windows managé
- Utiliser se driver comme un vrai driver

En fait en reprenant le principe du C#, le driver serai une interface et le service l'implémentation de l'interface du driver.
Un appel au driver C++ appellerai en faite la fonction dans le service managé avant de revenir à l'appelant natif.

[cinemania]

bien qu'il existe certains drivers qui fonctionne avant tout comme des services windows...

je me demande si cela est réalisable. Disons que ca l'est, ca c'est évident, mais de là a dire que ce soit "fonctionnel" ca l'est moins.

En plus créer un wrapper en C++ qui serve de squelette nécessite que tu choisisse un modele de communication entre le driver réel (C++) et le code managé qui est dans un Service windows, un processus totalement à part donc.
Qui dit choisir un modele de comm, signifie que tu aura pas mal de prog entre l'appelant/wrapper, et le service windows managé qui implante ton "interface"

Sinon il te reste la solution d'hoster la CLR directement dans ton driver C++, je me demande si cette solution ne serait pas plus simple.
Hoster la CLR ne signifie pas que ton code managé ne peut pas se trouver dans une assembly séparée donc tu pourrais écrire l'assembly séparée en C#... Mais encore... faut t'il arriver à le faire.

[smyley]

Sinon il te reste la solution d'hoster la CLR directement dans ton driver C++, je me demande si cette solution ne serait pas plus simple.
Hoster la CLR ne signifie pas que ton code managé ne peut pas se trouver dans une assembly séparée donc tu pourrais écrire l'assembly séparée en C#... Mais encore... faut t'il arriver à le faire.

Je pense que cette dernière partie est irréalisable. On parle bien de charger le CLR dans un processus s'exécutant en mode kernel. Tu penses qu'il est fait pour ça le CLR ?

[cinemania]

Le fait qu'il n'ai pas été concut pour... ne signifie pas que ce n'est pas possible, tout est affaire de droits et sécurité.

Maintenant je reconnais que c'est un peu tiré par les cheveux mais bon... créer un driver sans développement natif n'est pas viable sans cette solution.

Utiliser les RPC en natif, c'est assez hardcore s'il fait un service managé qui sert de coeur.