Microsoft vient de l'annoncer via une mise à jour de la page dédiée au support de Visual Basic 6, le runtime de VB6 sera présent sur Windows 7. Windows 7 sera probablement ainsi le dernier OS a support ce runtime, l'éditeur n'ayant pas prévu de l'inclure dans les versions ultérieures.

Ceci est donc une bonne nouvelle pour la compatibilité de ces applications, mais bon, il va falloir penser à migrer vers .net un jour quand même :)

En savoir plus :
Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7

Disposer d'une machine virtuelle et d'une compilation en deux phases permet de bénéficier d'un support du 64 bits quasi-automatique. Si l'on compile une assembly en Any Cpu, celle-ci sera compilée en JIT en 32 bits si elle est chargée dans un process 32 bits ou en 64 bits dans le cas d'un chargement dans un process 64 bits. De plus si une assembly a des dépendances vers des assemblys 32 bits ou vers des DLL natives 32 bits,  elle se retrouvera automatiquement compilée en 32 bits même si chargée dans un environnement 64 bits.

Il faut cependant noter que cette analyse de dépendances ne concerne que les dépendances statiques et en aucun cas les dépendances dynamiques (introduites via du code).

J'ai récemment rencontré le problème à propos de l'utilisation d'un filtre DirectShow. Le filtre est instancié via un Activator.CreateInstance afin d'être manipulé et insérer au sein d'un graphe de cette manière :

    /// <summary>
    /// Wrapper of the HttpDestinationFilter
    /// </summary>
    public class HttpDestinationFilter
    {
        private static readonly Guid CLSID_HttpDestination = new Guid("E6788379-AAA3-4516-86EC-158B7A49EA74");

        public static IBaseFilter CreateInstance()
        {
            return (IBaseFilter) Activator.CreateInstance(Type.GetTypeFromCLSID(CLSID_HttpDestination, true));
        }
    }

Seul problème, lors de l'exécution de ce code sur une plate-forme 64 bits, l'instanciation peut échouer si le composant en question est en 32 bits et si l'assembly est compilée en Any Cpu.

Etant sur un Windows 64 bits, la base de registres est en grande partie divisée en deux versions, une copie pour les applications 32 bits et une autre copie pour les application 64 bits. Il est ainsi (entre autres raisons) impossible d'utiliser des composants COM 32 bits depuis une application 64 bits car le composant se retrouve introuvable du fait de la redirection. La correction du problème est simple : trouver une version 64 bits du composant en question ou alors définir manuellement la target de compilation afin d'indiquer un compilation en 32 bits.

Microsoft propose une version Checked Build de ses OS. Si vous êtes abonnés MSDN vous avez la possibilité de télécharger la version "normale" ainsi que cette fameuse version alternative :

La version Checked Build proposée par Microsoft est une version de Debug. Elle est définie selon 4 options qui sont activées pour cette version mais qui ne le sont pas pour d'autres types de build :

• Les optimisations de compilation [O]
• Les traces de debug [D]
• Les assertions [A]
• Les contrôles d'intégrités [S]

Concernant les build dites "checked", toutes ces options sont activées. Pour les autres types de builds vous pouvez vous référer au tableau suivant :

En savoir plus :
Checked and Free Build Differences
WHERE DO "CHECKED" AND "FREE" COME FROM?

Durant la PDC08, Microsoft a annoncé que la prochaine version de Visual Studio sera basé sur WPF afin de fournir une interface graphique plus riche. Malgré cette annonce nous n'avions jusqu'à présent rien vu de bien alléchant concernant cette fameuse intégration.

C'est à présent chose fait grâce à Jason Zander qui propose sur son blog quelques screenshots de VS 2010 qui est toujours en cours de développement. Bien que non définitifs, ils permettent d'avoir une idée de la direction prise par Microsoft en ce qui concerne le look & feel de l'IDE.

En savoir plus :
http://blogs.msdn.com/jasonz/archive/2009/02/20/a-new-look-for-visual-studio-2010.aspx

Telle est la pertinente conclusion de Scott Hanselman après l'analyse du fonctionnement des navigateurs Chrome et Internet Explorer 8. Ces deux browsers utilisent en effet le même modèle d'isolation inter-onglets. Chaque onglet tournant dans un process différent, la stabilité de ces applications s'en retrouve améliorée grâce à ce niveau d'isolation bien supérieur aux AppDomains que l'on connait dans le monde .net.

Cette utilisation peut être révelée via l'utilisation de Process Explorer ou plus simplement directement via la commande about:memory dans Chrome. Cette commande affiche la consommation mémoire du navigateur, consommation définie via les différents process utilisés :

Fait intéressant, les process créés et gérés par ces navigateurs sont des process d'un type particulier appelé jobs. Ces jobs peuvent être gérés de manière globale, et des quotas d'allocation de ressources peuvent leur être atrribués.

Pour en savoir plus, rendez-vous sur le post d''Hanselman.

Dans le genre truc à la con que j'oublie à chaque fois, pour parcourir la callstack durant l'exécution d'un programme - afin de par exemple connaitre la méthode d'appel - il faut utiliser la classe StackTrace présente dans le namespace System.Diagnostics afin de récupérer les différentes StackFrame représentant les différentes frames de votre pile d'appel. La première (indice 0) étant la méthode actuelle et la seconde représentant la méthode d'appel précédente. Vous pouvez ainsi remonter jusqu'où bon vous semble.

Exemple rapide de code :

             static void Main(string[] args)
             {
                    Toto();
             }

             static void Toto()
             {
                    StackTrace trace = new StackTrace();
                    StackFrame frame = trace.GetFrame(1);

                    MethodBase method = frame.GetMethod();

                    Console.WriteLine(frame.GetMethod().Name);
             }

Si vous êtes éditeur de logiciels et que vous souhaitez avoir des informations détaillées lorsque vos applications rencontres des problèmes inattendus sachez que vous pouvez récupérer les rapports envoyés par les utilisateurs lorsqu'ils rencontrent ce message d'erreur :

Si l'OS propose aux utilisateurs d'envoyer des rapports d'erreurs pour toutes les applications et non pas uniquement pour celle de Microsoft, ce n'est pas à des fins d'espionnage mais pour permettre aux éditeurs d'améliorer la qualité de leurs logiciels. Il est en effet possible d'accéder gratuitement à ces rapports d'erreurs via le site Windows Quality Online Services. Il suffit pour cela de s'inscrire et de s'identifier de manière formelle en tant qu'éditeur de logiciels via un certificat Verisign.

En savoir plus :
Windows Quality Online Services

La grande messe annuelle organisée par Microsoft à Paris s'est donc terminée la semaine dernière.

Comme je vous l'avais indiqué, Bewise était bien représenté puisqu'au final nous avons été 5 speakers à présenter 8 sessions sur des sujets aussi variés que DirectX 10, Sync Services, SQL Server 2008, WPF 3.5 SP1, etc.

Vous pourrez retrouver l'ensemble des Webcast et des slides des sessions dans les prochaines semaines sur le site des TechDays. Les sessions pleinières sont d'ores et déjà disponibles :

• Vidéo de la conférence plénière de la première journée (Développeurs)
• Vidéo de la conférence plénière de la seconde journée (Professionnels de l'informatique)
• Vidéo de la conférence plénière de la dernière journée (Futur de l'informatique)

J'ai beau y refléchir, je n'arrive pas à trouver d'exemples d'applications sous Windows ayant une ergonomie originale et pertinente, des exemples d'applications utiles, qui ne seraient pas une simple copie du look des autres logiciels Windows.

Je me souviens encore d'une des premières remarques que j'ai eu lors d'une présentation de WPF il y a quelques années. On m'avait alors fait remarquer que l'on revenait "un petit peu en arrière", à l'époque de MS-DOS, où les applications avaient des looks et ergonomies assez hétérogènes. Windows ayant homogénéisé plus tard le tout en proposant des APIs utilisées par toutes les applications. Les traitements de texte, outils de gestion de mails, anti-virus et autres logiciels ont ainsi adoptés de manière quasiment exclusive un seul et même look/ergonomie dictée par Microsoft. L'éditeur effectuant de temps en temps de légères évolutions notamment au niveau graphique soit via les différentes versions de Windows - look plus 3D ou plus plat - ou via les différentes versions d'Office qui proposaient régulièrement certains liftings esthétiques reproduis ensuite par les autres logiciels de la planète Windows. Une des dernières évolutions ergonomiques proposée concerne d'ailleurs le nouveau ruban introduit dans Office 2007.

Le problème est que nous restons toujours dans ce même schéma malgré le fait que nous disposons de technologies (WPF/silverlight) permettant de créer des applications riches ayant une ergonomie unique servant de manière pertinente leur utilisation.

Du coté du monde d'Apple, la donne semble bien différente. Plusieurs logiciels possèdent une telle originalité, et je dois bien avouer que je ferais bien volontiers l'acquisition de tels outils si ils existaient sur PC. Delicious monster est un bon exemple de ce genre d'application :

Autre exemple Things un outil de gestion de tâches :

D'autres nombreux exemples pourraient être cités puisque Apple organise chaque année les Apple Design Awards lors de la WWDC afin de récompenser ce type de logiciels. Vous pouvez d'ailleurs consulter la liste des derniers vainqueurs sur le site de la WWC ou encore consulter la liste intégrale sur l'article Wikipédia correspondant. Ces awards sont un excellent moyen de motiver les éditeurs de logiciels à créer des applications innovantes en mettant en avant ces dernières.

Afin de changer les choses on peut donc souhaiter que Microsoft mette en place un jour ces mêmes Awards. Ils pourraient être décernés lors du Microsoft Mix ayant lieu chaque année à Las Vegas qui est devenu la grande messe du développement d'applications web, RIA et RDA. M'enfin... il s'agit sans doute d'un voeux pieux...

Durant la session sur DirectX présentée par David lors de Microsoft TechDays 2009 à Paris, une personne posa une question afin d'avoir des informations sur les Compute Shaders qui seront introduits avec la version 11 de ce framework. Les Compute Shaders sont des shader spécialisés permettant d'utiliser le GPU en tant qu'unité de calcul destiné à faire des traitements autres que des calculs géométriques et graphiques. Cela permettra de déporter le traitement de calculs parrallèles du CPU vers le GPU afin de bénéficier de la puissance de calcul de ces puces très souvent délaissées.

Cette question m'a rappelé un projet initié par Microsoft Research il y a quelques années nommé Microsoft Accelerator. Ce projet basé sur DirectX 9 permet de faire exactement cela et la bonne nouvelle est que le projet est disponible en téléchargement avec des exemples d'utilisation (dont un en VB.net il faut le souligner :). Le modèle de programmation repose sur l'ajout de nouveaux types (essentiellement des tableaux) pour lesquels chaque opération effectuée sera réalisée non pas par le CPU mais donc par le GPU. Les Compute Shaders n'existant pas encore avec DirectX 9, les concepteurs du projet se basent sur les pixel shaders afin d'effectuer ces traitements. Les nouveaux types introduits par Acccelerator étant convertis en textures et la logique des opérations étant converties en plusieurs pixel shaders.

En savoir plus :
Microsoft Accelerator sur Microsoft Research
Télécharger Microsoft Accelerator
Informations sur les Compute Shaders de DirectX 11