Blog de Kosh

Dans le cadre de Nova Server (oui cette superbe technologie de la mort avec des vrais morceaux de code qui poutre à l’intérieur que vous pourrez découvrir ici), j’ai été amené à essayer de faire tourner Nova dans un service windows.

Et là c’est le drame. Il est juste IMPOSSIBLE de faire tourner DirectX (ou OpenGL) dans un service Windows depuis Windows Server 2008 et Vista. En effet, pour la petite histoire, ces systèmes font tourner les services dans une session appelée session 0. Cette session posséde la charmante limitation de ne pas permettre l’accès au desktop et donc à l’accélération graphique.

Ce qui me tue c’est qu’avant on pouvait. Mais apparemment il y a un bucheron dans l’équipe qui a conçu la sécurité des nouveaux OS. Le jour ou il a réfléchi à la sécurité des sessions, il devait être constipé parce que bloquer l’accès au desktop, je ne suis pas contre mais pourquoi à DirectX? Il croit que je vais détourner un avion avec?

C’est fou quand même parce que pour le coup le déport des rendus sur des serveurs c’est la foire à la saucisse avec une ouverture de session manuelle et tout le package “je code comme un veau”.

Donc, bam, carton rouge!

Divers, 3D, Windows

Une question qui revient souvent concerne le fait qu’il y existe deux classes Timers dans le .NET : System.Windows.Forms.Timer et System.Timers.Timer.

Alors pourquoi me direz-vous? Et bien parce que ce ne sont pas les mêmes usages.

System.Windows.Forms.Timers

Ce timer se base sur un message Windows envoyé à l’application et qui sera donc traité par la boucle des messages et donc dans le thread de l’interface.

Avantage : Pas besoin de faire des Invoke pour accéder à l’interface puisque l’événement levé par le timer sera traité par le thread de l’interface.

Inconvénient : Le timer n’est pas précis car il passe par le système de messages de Windows. De plus il ne profite pas des multi-cpus du fait que tout est exécuté par un seul thread.

System.Timers.Timer

Ce timer se base sur des timers natifs (qui utilisent des threads).

Avantage : Très précis et gére bien les ressources mutli-cpus.

Inconvénient : Nécessite des Invoke pour accéder à l’interface.

.Net, Windows, Windows Forms

Je viens de rajouter la gestion d’une source lumineuse à mon moteur 3D soft.

Notre modèle objet est donc composé des entités suivantes:

• Scene
• Objet
• Camera
• Light

La scène est composée d’une liste d’objets, d’une lumière et d’une caméra active.

Un objet est composé d’une liste de vertices (des points 3D) et de faces. Chaque face est responsable de son rendu.

Pour optimiser un peu tout ça, j’ai rajouté une classe qui simule les buffers de travail dans une image (la classe UnsafeBitmap).

La prochaine étape va être d’accèlerer le rendu en refaisant l’algorithme de remplissage de faces (rastérisation).

Tout ceci se trouve ici.

3D, .Net, Win32, Windows

Suite à une formation que je fais en interne chez Bewise, je vais déposer sur mon blog l’archive d’un petit moteur 3D entièrement en C# et surtout uniquement soft.

Donc ici pas de DirectX, que du calcul au CPU comme au temps de papy.

Suite aux évolutions que j’apporterai je reposterai les modifications.

Pour le moment le moteur gére:

• Scéne/Objets/Faces
• Textures
• Rotation/Scaling/Translation

Le projet Visual Studio 2008 peut être téléchargé ici.

Windows, Windows Forms, 3D

Et voila, les TechDays 2009 sont finis. Ce fut une fois de plus un superbe événement ou j’ai eu beaucoup de plaisir à animer 3 sessions. Je pense notamment à ma session Coding For Fun avec mon camarade Mitsu Furuta ou l’on s’est bien amusé.

Pour ceux qui souhaitent retrouver les présentations et tout le code des démos, c’est par ici que ca se passe.

.Net, DirectX, WPF, Windows

Petite pub pour mes sessions aux TechDays 2009:

 DirectX10 pour les Windows Forms

 Nouveautés de WPF 3.5 SP1

 Coding4Fun

Comme toujours mes sessions sont très orientées 3D et présentation. Nous parlerons donc de DirectX10, de pixels shaders et avec Mitsu nous vous montrerons que l’on peut s’amuser avec des petites applications “ludiques” ;)

DirectX, .Net, Windows, WPF

Après avoir installé le SDK de Windows 7, il y a de très grandes chances que l’intellisense ne marche plus sous Visual Studio 2008 au niveau de WPF.

Pour résoudre ce petit soucis (lié à la modification d’une clé de registre par l’installeur du Windows SDK), il suffit de taper cette ligne de commande:

regsvr32 "%CommonProgramFiles%\Microsoft Shared\MSEnv\TextMgrP.dll"

Fermez pluis relancez Visual Studio et l’intellisense est de retour :).

Windows, WPF

Je viens tout juste d’installer Windows 7 (build 7000) sur ma machine. C’est vraiment un OS très prometteur qui risque bien de nous faire oublier les désagréments de Vista.

Un truc qui m’a intrigué (parmi tant d’autres) est le support direct des 4Go de RAM de ma machine.

Hélas, Visual Studio 2008 marche pour l’instant très mal sous Windows 7.

Retour donc sous Vista.

Cette histoire de 4Go m’a toutefois chiffonné. Sous Vista de base, mon système me donnait 3Go de dispo alors que sous Vista SP1 j’avais bien 4Go.

Après une petite enquête il s’avère que Vista ne donne accès aux processus qu’à 3,12 Go (c’est précis) car il faut savoir que le matériel utilise un peu de la mémoire physique pour travailler (mapping de certains ressources comme la carte son, carte graphique, etc…).

Heureusement, il existe une technique toute bête pour demander à Vista de ne plus se limiter à 3,x Go (avec un maximum a 4Go de toute manière).

Il suffit pour cela de lancer une console en mode administrator et de taper la commande suivante:

BCDEdit /set PAE forceenable

Le mode PAE est un mode étendu des processeurs x86 qui permet d’avoir un adressage sur 36 bits (contre 32 normalement). Ceci permet donc théoriquement d’avoir 64Go de RAM.

Toutefois sous Vista 32 bits cela permettra uniquement d’avoir droit à 4Go (dans l’absolu bien sûr) par processus.

On pourrait alors se demander pourquoi Microsoft n’active pas par défaut ce mode? Tout simplement parce que finalement ca ne sert à rien. Le matériel va continuer à prendre sa place, donc on ne disposera finalement que de 3,x Go et la gestion de l’adressage en 36bits plutôt qu’en 32bits ralentit le système.

Win32, Windows

Un de mes clients vient de me demander comment faire pour sortir une assembly déployée dans le GAC. Depuis l'interface de Windows, ce n'est pas directement possible.

Une solution simple existe : le command prompt :).

Il suffit de lancer cmd.exe, de faire un joli "cd c:\windows\assembly" et de faire "dir" :

On se retrouve avec des sous-répertoires en fonction du type. Prenons par exemple une assembly de type MSIL. Dans ce cas on fait un petit "cd GAC_MSIL".

Si on fait un "dir", on obtient alors la liste des assemblies sous la forme de répertoires. Dans chaque répertoire on peut trouver un sous-répertoire par version et dans chaque sous-répertoire, on obtiendra l'assembly recherchée.

Avec un "copy toto.dll c:\" on pourra alors extraire l'assembly.

.Net, Windows

Malgré ce que peuvent en dire certains, je continue de penser que l'UAC est une bonne chose. Le fait de ne pas être tout puissant lorsque l'on est administrateur ou même le fait de pouvoir localement acquérir des droits plus élévés est à mon sens une excellente chose.

Il faut cependant penser ses applications dans ce sens lorsqu'elles doivent toucher à des fonctions gardées par l'UAC (comme le répertoire de Windows, Program Files ou bien encore la base de registre).

Pour ce faire il faut, au sein de son projet Visual Studio 2008, rajouter le fichier suivant (que l'on appelera xxxx.manifest):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">    
<security>      
<requestedPrivileges>        
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>      
</requestedPrivileges>    
</security>  
</trustInfo>
</assembly>

Ce qui est important dans ce fichier, c'est la notion de requestedExecutionLevel. Elle peut valoir trois valeurs:

• asInvoker
• requireAdministrator
• highestPossible

Dans notre cas, nous voulons que Vista propose à l'utilisateur une confirmation de l'élévation de droits pour notre application (si nous sommes administrateur) ou une fenêtre de demande de droits (si nous sommes simple utilisateur).

Pour lier le manifest à notre application, cela se passe dans les propriétés de l'application sous Visual Studio 2008 dans l'onglet Application. On y trouve une liste qui nous permet de lier un fichier .manifest du projet à l'application générée.

Et le tour est joué :).

.Net, Windows