Présentation	Documentation				L'équipe	Sérialisation
	Programmes	Objets	Libs Utilitaires	Libs Internes
	Editeur	Syntaxes	Windows	Versions

SCR/AL1 - TOME VII. Version Windows

2. Les versions DOSWIN et DOSW32

Dans une version intermédiaire, des versions Windows ont été proposées. Ces versions étaient implémentées sous Windows en mode "caractère". Elles restent disponibles et compatibles avec les versions caractères de SCR4/AL1.

Ces versions en 16 et 32 bits utilisent la gestion écran, souris, clavier et mémoire de Windows.

Ces versions ont été proposées à partir de la version 4.24 de SCR4/AL1.

Présentation générale

Les versions DOSWIN et DOSW32 présentent l'avantage d'être simples à mettre en oeuvre sur les sources existantes et complètement compatibles avec la version DOS de SCR/AL1, que ce soit au niveau des fichiers de données ctree ou des fichiers .scr et .cmt.

L'application exploite le jeu de caractères de Windows défini pour la "fenêtre DOS". Il s'agit cependant d'une application complètement Windows, exploitant le gestionnaire mémoire de Windows en permettant notamment d'allouer des blocs de plus de 64 KB et d'utiliser la mémoire virtuelle ou les imprimantes de Windows.

La souris est exploitable exactement comme elle l'est en DOS, mais d'une souris "bloc", on passe à la flèche normale de Windows.

Le multi-tâche est disponible et une même application peut être lancée plusieurs fois simultanément.

Tous les exécutables ne sont pas disponibles dans ces versions. Ceux qui le sont sont préfixés par S4W ou S32W, comme S4W_E.EXE et les librairies S4WO.LIB, S4WI.LIB et S4W4I.LIB. S32W préfixe la version DOSW32 et S4W la version DOSWIN.

Les fichiers générés par scr4_e et créés par scr4 sont identiques à ceux générés par la version DOSWIN. Les versions Windows "pures" génèrent également les mêmes fichiers que dans les autres versions.

Compatibilité

Les fichiers .scr, .dat, .idx, .prf, etc sont tous compatibles entre les versions DOS Borland et DOSWIN Borland. Il ne faut donc même pas recompiler les sources .f de la version DOS pour le portage en DOSWIN.

Pour l'essentiel, toutes les fonctions des librairies sont opérationnelles en DOSWIN comme en DOS. Cependant, quelques fonctions sont vidées de leur contenu, comme ACT_exec_system(), STD_dosformat() et STD_subshell(). En effet, ces fonctions font appel à system(), qui n'est pas disponible sous Windows, du moins dans une forme acceptable, comme indiqué plus bas.

Mise en oeuvre (version DOSW32)

Supposons une application SCR/AL1 classique. Pour procéder à son portage sous Windows (DOSW32), on procèdera comme suit:

• 1. Copie des sources (.c, .f, .h, ...) dans un directory séparé.
• 2. Modification du makefile :
• compilation (bcc32) : ajout des paramètres -W, -DDOSW32 et -3
• link :

* paramètre -ea.out pour sauver l'exécutable sous le nom a.out

* paramètre -M pour générer un map du link (debugging ultérieur)

* librairies s32wo.lib s32wi.lib et s32wi4.lib au lieu de scr4o.lib, scr4i.lib et scr4i4.lib

• compilateur SCR4_E : supprimer l'éventuel -t drivername de la ligne scr4_e -af ... -o ...
• 3. Modification des sources :
• annulation ou remplacement de la fonction system() : il est en effet impossible d'exécuter des commandes DOS dans l'environnement WINDOWS. Il s'agira donc de modifier le programme au cas par cas. S'il s'agit d'une commande comme system("copy truc a:"), il suffira d'écrire une fonction C qui effectuera cette commande. Si par contre on doit lancer un sous programme, il faudra porter ce sous programme sous Windows et exécuter la fonction LoadModule() ou WinExec() à la place de system().
• annulation ou remplacement de la fonction sleep(). Sleep() existe sous Win32.
• modification des fonctions d'impressions. Actuellement, l'impression se déroule de la façon suivante : le device LPT1: par exemple est ouvert comme un quelconque fichier et les données y sont écrites. Ce procédé fonctionne toujours sous Windows, du moins si on n'exploite pas les portes LPT2: ou LPT3: redirigée par un réseau comme WFW. Dans le futur, on redirigera les impressions de ce type vers l'imprimante par défaut de Windows, ce qui permettra une intégration plus élégante dans le système.
• 4. delete *.obj
• 5. touch *.f
• 6. make all
• 7. copie ou déplacement des bases de données référencées dans l'application
• 8. lancement et test sous Windows de l'application.

Remarques

En raison de la spécificité de l'interface Windows, certaines fonctions comme printf, getchar, etc ne sont pas disponibles ou ont une implémentation différente sous Windows.

La fonction printf (ou fprintf(stdin ou stderr)) affiche dans l'écran de fond de Windows le texte correspondant. La fonction de librairie Wprintf() a été ajoutée et possède la même syntaxe que printf. Elle affiche dans la fenêtre DOS et déroule automatiquement lorsque le texte dépasse la 25ème ligne.

Les macros getchar() et getc() posent un problème plus important: en effet, un tel appel bloque Windows sans autre possibilité que Ctrl-Alt-Del pour s'en sortir! Il faut donc les éliminer manuellement du code. Une alternative sera implémentée dans un avenir proche.

Ajout d'éléments spécifiques à Windows

Avant l'appel au main() de l'application, le programmeur a le loisir d'effectuer des opérations via la fonction WscrDOSUserInit(). Cette fonction est vide par défaut, mais peut contenir un code quelconque. En fait, cette fonction sert essentiellement à définir des variables globales (voir ci-dessous). Elle peut éventuellement éviter le démarrage de l'application.

Au moment de l'appel, la fenêtre de l'application n'est pas encore définie.

On peut par exemple fixer deux variables globales dans la fonction WscrDOSUserInit() :

• int WSCR_ICON; /* Numéro de la ressource icône */
• int WSCR_FONTNB; /* Numéro de la police de caractères */

La syntaxe de WscrDOSUserInit() est la suivante :

        WscrDOSUserInit(argc, argv)
        int     argc;
        char    *argv[];

où argc et argv sont les paramètres de programme, dans la forme classique de ceux du main(). Si la fonction retourne une valeur non nulle, le programme s'arrête. Sinon l'application démarre normalement.

Comment associer une icône à une application

Par défaut, aucune icône n'est associée à l'application. Seul le texte SCR4 est affiché dans les applications minimisées. Pour créer sa propre icône, il faut procéder comme suit:

• 1. Créer une icône à l'aide d'un outil comme Borland Resource WorkShop.
• 2. Définir un fichier myprog.rc (resource) qui doit contenir uniquement la définition de l'icône :

            #include <windows.h>
 
            1000 ICON myprog.ico

• 3. Compiler (dans le makefile) ce fichier pour obtenir un fichier myprog.res

            rc -id:\bc45\i -r myprog.rc

• 4. Créer la fonction WscrDOSUserInit() pour assigner le numéro de l'icône (1000 dans le cas présent) à la variable WSCR_ICON. Linker cette fonction avec l'éxécutable (soit myprog.exe).
• 5. Adjoindre les ressources définies dans myprog.res à l'exécutable myprog.exe généré par BCC -W:

            rc myprog.res

Comment changer la taille de la police par défaut

Il suffit d'assigner le numéro de la police sélectionnée à la variable WSCR_FONTNB. Par défaut, cette valeur est fixée à 5. Les polices disponibles peuvent varier de système à système. Au besoin, il faudra les ajouter dans le "Control Panel/Fonts" de Windows.

La liste des tailles disponibles est :

        0: 4  x 6
        1: 5  x 12
        2: 6  x 8
        3: 7  x 12
        4: 8  x 8
        5: 8  x 12
        6: 10 x 18
        7: 12 x 16
        8: 16 x 8
        9: 16 x 12

Le menu système permet à l'utilisateur de modifier ces tailles en cours de travail.

Menu System

Ce menu est actionné par la combinaison Alt+espace ou à l'aide de la souris. Dans le cas d'une application SCR/AL1, il ne permet pas de changer la taille de la fenêtre, mais par contre il offre deux possibilités intéressantes:

• changer la taille des caractères (dans les limites définies ci-dessus)
• terminer "proprement" la tâche en cours (record SCR_BREAK). La fonction SCR_end() est appelée pour fermer les ISAM éventuellement ouverts.

Une ligne "Properties" peut également être ajoutée au Menu par la variable WSCR_PROPSFN.

Debugging

Borland offre un debugger sous Windows. Pour l'exploiter, il faut compiler et linker avec l'option -v. Cependant, ce debugger présente manifestement certaines anomalies. On préfèrera la version 32 bits qui est nettement plus utilisable.

Il est également possible d'obtenir de l'informations directement par le message produit par Windows (16 bits) lors d'un plantage. En effet, le message indique l'adresse de l'instruction qui plante le programme. En recherchant dans la dernière partie du fichier a.map généré par le linker, on retrouve ainsi assez facilement le nom de la fonction en cause.