Aspects du développement d'applications pour Windows TSE

Les applications doivent utiliser correctement les clefs HKEY_LOCAL_MACHINE et HKEY_CURRENT_USER de la base de registre.

• L'application doit utiliser la clef HKEY_LOCAL_MACHINE uniquement pour stocker des informations globales, communes à tous les utilisateurs.
• L'application doit utiliser la clef HKEY_CURRENT_USER uniquement pour stocker des informations propres à l'utilisateur.

Tout développement doit tenir compte que dans un environnement TSE, une machine n'est pas équivalente à un utilisateur.

Pour fournir les fonctionnalités multiutilisateurs, le système TSE gère les fichiers INI de manière à ce que chaque utilisateur ait ses propres fichiers (utilisation du répertoire Windows dans le %HOMEPATH% de l'utilisateur).
Pour accéder aux fichiers INI, l'application doit utiliser les API Win32 spécifiques à la gestion de ces fichiers et ne doit surtout pas utiliser des fonctions classiques d'ouverture, de modification de fichier (par exemple les fonctions de type « fopen » ne doivent pas être utilisées pour manipuler les fichiers .INI).

Aucun chemin d'accès ne doit être codé en dur dans l'application, exemple C:\Path. En particulier si l'application utilise des fichiers temporaires il est impératif que le répertoire de travail soit pris dans l'environnement de l'utilisateur par exemple en utilisant la variable d'environnement %TEMP%.

Dans le cas d'une application client/serveur, l'application ne doit pas utiliser l'adresse IP comme identifiant du client. Sur un système TSE (Microsoft )/METAFRAME (Citrix) tous les utilisateurs accèdent au réseau avec la même adresse IP. Il est recommandé d'utiliser soit un fichier INI avec l'identifiant de l'utilisateur soit les variables %USERNAME% et/ou %CLIENTNAME%.

%USERNAME% retourne le nom de login NT de l'utilisateur.
%CLIENTNAME% retourne le nom du poste client de l'utilisateur, cette variable n'est disponible que dans l'environnement TSE/METAFRAME, les applications doivent alors prendre en compte cette remarque si le code utilisé doit fonctionner sur un poste classique et sur un serveur TSE/METAFRAME.

Si l'application gère la communication IP, il faut s'assurer que les sockets privées sont allouées dynamiquement. Cette technique doit permettre d'exécuter plusieurs instances de la même application.
Sur un poste local, il doit être possible de lancer plusieurs instances de l'application. Si ça n'est pas le cas l'application ne peut pas être installée sur un système TSE/METAFRAME.

Il est évident que l'application doit gérer correctement l'allocation et la libération des espaces mémoire. Sachez que la consommation anormale de mémoire est ici amplifiée par le fait que l'application sera lancée plusieurs fois sur le serveur.

Les applications qui utilisent des ports de communication (PARALLÈLE ou SÉRIE) doivent utiliser l'environnement système pour retrouver la configuration des ports disponibles et les fonctions du système NT pour piloter ces ports.

Il est vivement déconseillé d'accéder à ces ports directement par des codes d'interruption DOS.

Toute application faisant usage des « regional settings » (paramètres régionaux) doit le faire de manière à s'adapter aux « regional settings » en vigueur dans l'implantation ou le groupe d'utilisateurs concernés.

Par exemple, une application susceptible d'être déployée à l'étranger ne peut imposer d'utiliser des formats de dates issus des regional settings « french » alors que les « regional settings » en vigueur des sessions utilisateurs des sites à l'étranger peuvent être « english ».

Note : ces précautions sont identiques que l'on soit dans une session utilisateur TSE/Metaframe ou que l'on soit dans une session NT Workstation.

Il faut vérifier que l'outil de développement utilisé construit les applications avec les objets Microsoft NT4 (exemple : boite de dialogue d'ouverture de fichier).

L'application ne doit pas forcer le rafraîchissement des menus par des fonctions qui désactivent et activent l'affichage complet de l'application. Ces méthodes ont pour effet de provoquer un réaffichage complet de l'interface ce qui est coûteux en ressources réseau dans le cas d'un client distant.

Pour Citrix
Lorsque l'application est destinée à être utilisée au travers de la publication ICA, il est nécessaire que la gestion de la fin d'exécution soit gérée correctement.
Si l'utilisateur termine l'application par un clic sur la croix en haut à droite de la fenêtre ou en sélectionnant la fonction Close (Alt-F4) il faut que le programme gère cette fin de programme comme si l'utilisateur quittait l'application par le menu 'Quitter'.

Tous les objets animés de type écran de veille ou horloge sont à proscrire de tous les écrans d'une application, car chaque mise à jour de l'écran, répercutée sur le poste client, a un coût réseau important.
Par ailleurs les fonds d'écran doivent être le plus simple possible, les fonds de type photo en haute résolution sont déconseillés.

Tous les pilotes d'imprimantes ne sont pas forcement supportés par le système TSE/METAFRAME.
Il est important de vérifier que l'application n'exige pas une imprimante particulière (caractéristiques spécifiques à cette imprimante). Si tel est le cas, il faut vérifier que le pilote de l'imprimante est supporté sur TSE/METAFRAME, le site du constructeur de l'imprimante peut fournir ce renseignement ou le site du support de CITRIX contient des informations sur les pilotes déjà référencés comme n'étant pas supportés sur TSE/METAFRAME.

Pour compléter l'installation et la configuration d'une application, il est possible de créer des scripts de compatibilité qui vont assurer la distribution de fichiers et la configuration de l'environnement pour chaque utilisateur.
Des scripts sont déjà disponibles pour les applications standards telles que MS Office. Ces scripts sont stockés dans le répertoire « Application Compatibility Scripts » et peuvent être utilisés comme base pour configurer une application particulière.