|
Sommaire

Introduction
Le système
d'exploitation DOS (DR-DOS, MS-DOS, PC-DOS,
FreeDOS, boîte de compatibilité OS/2 et
Windows NT) fournissent des services de fonctions à
partir essentiellement de l'interruption 21h. Cependant , tous
particulièrement le MS-DOS fait également appel
à l'interruption 2Fh pour des fonctions personnels, cependant
elles ne sont pas officiel et nous référençable
pour une application voulant tourner sur n'importe quel DOS,
cette interruption ne devrait être utilisé que pour les
pilotes et les périphériques supplémentaires et
il n'y a donc aucun intérêt à décrit ici
l'utilisation qu'en font certain marginal. De ce fait, nous nous
centrerons essentiellement sur l'interruption 21h car lorsqu'on
désigne une interruption DOS, on parle en général
de celle-ci. L'interruption 2Fh est surnommée l'interruption
multiplex.
Un détail important pour
les néophytes, Windows 95 et considéré
comme un DOS 7.0 et Windows 98 est de sont côté
comme une version déboguer du DOS 7 et est donc
numéroté comme 7.10. Le fin de ne pas prendre ce
système d'exploitation comme pour une véritable système
différent du DOS tient du fait qu'il n'est en réalité
aucunement différent du DOS. En fait il s'agit d'un DOS
avec un environnement intégrée au moyen «d'une
broche à cheveux» (MSDOS.SYS) dans lequel il
suffit de spécifier le chargement de l'environnement graphique
multi-tâche ou non. Alors comment pourrait tout différencier
messieurs? Par ses bugs? Peut-être mais cette technique ne
serait pas loyal envers les émulateurs de Windows 95 et
98 qui eux fonctionne parfaitement. Vous me ferez remarquer
que les noms longs ne sont pas disponibles lorsqu'on ne fait que
charger le noyau, c'est vrai, mais il ne s'agit que d'un drapeau à
activer pour que le tour soit jouer.
De
quel unité votre système d'exploitation DOS a-t-il
démarrer?
Naturellement, il s'agit de la
demande en information la plus importante pour un programmeur, de
quel unité le système d'exploitation a-t-il été
chargé avant d'arriver en mémoire? La réponse
devrait être fort simple mais hélas, il faudra attendre
une version 4 du DOS (peu fiable d'ailleurs)avant d'obtenir ce
service, cependant les boîtes de compatibilité OS/2
et NT offre heureusement ce service dès leur premier
version.
Pour connaître la réponse
à cette mystérieuse question, il faudra faire appel à
l'interruption 21h, appeler la fonction 33h et la sous-fonction 05h
et regarder le contenu du registre AL. Dans le registre AL la réponse
retourner commence à 1 pour A:, 2 pour B et ainsi de suite, le
0 n'est pas utilisée, toutefois on peut l'exploitation
éventuellement dans un programme pour en déduire que le
DOS à qui ont à faire ne comprend pas la
question.
Dans
l'exemple suivante, cette fonction permet de connaître l'unité
de démarrage sous lequel le système d'exploitation a
été lancée. Si la fonction ne réussit pas
à déterminer de quel unité a été
lancée le système, elle renvoie l'unité A:. La
fonction suivant permet de renvoie des unités correspondant à
ceci à une lettre d'unité correspondante: A=A:, B=B:,
C=C:,....
|
Exemple en Turbo Pascal 6 ou
postérieur
|
|
FunctionGetBootDisk:Char;Assembler;ASM
MOV AX,3305h INT
21h MOV AL,DL OR
AL,AL JZ @End DEC
AX @End: ADD
AL,65 { Addition la lettre A }
END;
|
De
quel version de système d'exploitation DOS s'agit-il?
Mais si vous avez remarquée
les remarques de la fonction précédente, vous avez sens
doute remarquer que la version de DOS était
nécessairement requis pour obtenir des résultats
satisfaisant. De ce fait, il en existe deux disponibles, sous le
système d'exploitation DOS. Quoi deux fonctions? Oui,
avec le DOS tout est possible, mais le voile n'est pas encore
lever:
La plus ancienne n'est
disponible qu'à partir de la version 2 du DOS et ne
retourne pas toujours la vérité à partir du DOS
5 et postérieur (Interruption 21h, fonction 30h).
Normalement c'est toujours elle qu'on utilise.
La deuxième ne
disponible qu'à partir de la version 5 du DOS et
retourner cependant toujours la vérité (Interruption
21h, fonction 33h, sous-fonction 06h).
Le pourquoi de ce genre de
casse-tête? Figurer vous que les concepteurs du DOS
n'ont songer qu'à partir de la version 2 du DOS qu'il
pourrait être d'intérêt, pour le programmeur, de
connaître la version, puisqu'il ne s'agissait que d'une version
copier du CP/M enfin de compte, il ne semblait pas, pour eux,
qu'une évolution été nécessaire.
Cependant à partir de la version 2, les fichiers furent gérer
par les Handles et on n'eut pas d'autres choix que d'informer
le programmeur de la présence de ces fonctions si on veut
qu'il puisse être utilisé. Toutefois, le problème
ne s'arrête pas là! Ainsi, le système
d'exploitation DOS effectua tellement des modifications
importantes et qui plus est n'étant pas toujours présente
pour longtemps (exemple la fonction 63h n'existant qu'avec la version
2.25 seulement, 50h, 51h n'étant disponible qu'avec la version
2 du DOS, les fonctions de pays étant mise-à-jour
de façon douteuse entre les versions 2, 3 et 3.3) que certains
programmes sont devenus tout simplement paranoïaque avec le
système d'exploitation et ainsi il ne fonctionnait qu'avec une
version spécifique du DOS. Par exemple il fonctionnait
avec la version 2 mais refusait de partir avec la version 3 et ainsi
de suite. Ainsi pour remédier au cafouillis qu'ils ont créer
avec leur DOS, ont du offrir les services d'une deuxième
fonction permettant d'obtenir la véritable version de DOS.
Puisque dorénavant elle peut changer pour n'importe quel
numéro afin de berner les programmes trop atteint d'une forme
aiguë de schizophrénie...
Donc comment permettre de
répondre correctement à ce genre de problème,
surtout que les nouveaux système d'exploitation plus puissant
que DOS ont rendu les calculs encore plus compliqué:
L'OS/2 retourne une
version multiplié par 10 ainsi la version Warp 3
(numéro 2.1) retournera 20.10, la version Warp 4
retournera 20.30. (Et 20.20 ne semble pas exister...).
Le Windows NT retourne
une version correspondant à un DOS fictif numéroté
5.5.
|
Exemple en Turbo Pascal 6 ou
postérieur
|
|
Function GetDosVersion:Word;Assembler;ASM
MOV AH,30h INT
21h OR AX,AX JNZ
@End MOV AH,1 {
Écrit la version 1.0 si le DOS est 0.0 donc en fin de
compte la version 1} @End:
END;
|
Est-ce
que l'unité spécifiée est un disque virtuel?
Une
des inquiétudes qu'on les programmeurs quand il s'agit
d'installer un logiciel , c'est de savoir si l'unité
référencer n'est pas un disque dur mais un disque
virtuel, car il est inutile d'installer un logiciel si vous l'effacer
au prochain redémarrage de la machine, NON? Alors, comment
faire pour savoir si l'unité spécifié n'est en
faite qu'une unité virtuel (disque en mémoire RAM
de la machine). Il existe une technique semblant faire l'affaire,
elle n'est pas officiellement référencer par les
système d'exploitation, mais tous les éléments
existe sur n'importe quel DOS ou boîte de compatibilité
OS/2. Cependant celle-ci peut parfois avoir certains
accrochages avec la boîte de compatibilité de Windows
NT. En effet celle-ci n'autorise pas la lecture du premier
secteur d'un disque quelconque même s'il s'agit que d'un
vulgaire disque virtuel, de ce fait l'utilisateur de votre programme
verra apparaître un message l'inviter sois à fermer
l'application ou à continuer. Mais hormis cette boîte de
compatibilité, les autres systèmes comprennent mieux
les motivations d'un programme DOS.
Enfin
voici donc la technique a utilisé pour y arriver, technique
inspiré d'un certain Li-Hsin Huang:
Il
s'agit d'utiliser l'interruption 25h (celle-ci lisant un secteur
absolue spécifique sur l'unité spécifier).
Ensuite
de tester le nombre de FAT présente sur l'unité
de disque spécifier et si son nombre correspond à 1
(et non pas 2) c'est qu'il s'agit d'un disque virtuel.
Dans
l'exemple suivant la routine attend une unité correspondant à
0=A:, 1=B:, 2=C:,... et retourne vrai (TRUE) si le teste est
concluant et faux (FALSE) s'il ne s'agit pas d'une unité
virtuel.
*ATTENTION
au programmeur voulant la traduire directement en assembleur sans le
Pascal, l'exemple suivant nécessite une pile d'au moins 1 Ko.
|
Exemple en Turbo Pascal 6 ou
postérieur
|
|
Function
IsRAMDrive(Drive:Integer):Boolean;Assembler;Var
Temp:Boolean;ASM
MOV Temp,False PUSH
DS MOV BX,SS MOV
DS,BX SUB SP,0200h MOV
BX,SP CLD MOV
AX,DS MOV ES,AX MOV
DI,BX MOV CX,0100h XOR
AX,AX REP STOSW {
Initialise le tampon à 0 en cas d'erreur} MOV
AX,Drive { le tampon ne sera pas
fonçement interpréter} MOV
CX,1 XOR DX,DX INT
25h { Lecture du secteur de démarrage
} ADD SP,2 JC
@@1 MOV BX,SP
{**** Les deux lignes d'assembleur
suivantes devront peut-être être éliminer car
certaines unités virtuel comporte malgré tout un
identificateur de disque dur}
CMP Byte Ptr SS:[BX+15h],0F8h {
Vérification de disque dur } JNE
@@1
{Fin du teste d'identificateur de disque
à enlever au besoin... **** }
CMP Byte Ptr SS:[BX+10h],1 {
Vérification d'une simple FAT } JNE
@@1 MOV Temp,True @@1:
ADD SP,0200h POP
DS MOV AL,Temp END;
|
Changer
le titre d'une application DOS sous OS/2
Sous
le système d'exploitation OS/2,
n'importe quel application y compris une application DOS, peut
changer le titre de la fenêtre sous lequel OS/2 le fait
tourner. Pour pouvoir modifier ce nom, on utilise la fonction 64h de
l'interruption 21h de la façon suivante:
|
Procedure
OS2SetTitle(Name:PChar);Assembler;ASM
MOV AH,64h
MOV DX,0001h
MOV CX,636Ch
XOR BX,BX
LES DI,Name
INT 21h
END;
|
Changer
le titre d'une application DOS sous Windows 9X
Dans
l'environnement Windows , il est également possible de
modifier le nom de l'application comme sous OS/2, on utilisera bien
entendu une fonction différente, d'une autre interruption,
c'est a dire l'interruption 2Fh, fonction 16h:
|
Function
Win95SetTitle(Name:PChar):Boolean;Assembler;ASM
MOV AX,168Eh
XOR DX,DX
LES DI,Name
INT 2Fh
END;
|
|