Discussion :

[rocky77]

Bonjour,

J'ai un programme qui utilise une interruption 0x65h pour faire appel à un driver USB chargé via un executable appelé DOSUSB.COM
Lorsque je compile mon programme Turbo Pascal en mode réel tout ce passe bien mais lorsque je le compile en dos protected mode, ça ne marche plus.

C'est la qu'intervient l'assembleur et malheureusement je n'y connais rien. J'ai cru comprendre qu'il existait une interruption 0x300h qui permettait d’émuler une interruption en mode reel, on m'a même donné un exemple de code mais je n'arrive pas à l'utiliser.

Si vous pouviez faire un tour par ici et m'aider à resoudre mon probleme, ce serait génial, Merci d'avance
http://www.developpez.net/forums/d15...b/#post8431147

[chrtophe]

Pour compléter la réponse de Paul TOTH dans l'autre POST, les interruptions mode réel ne sont pas disponibles en mode protégé, le mode protégé utilisant une table d'interruption gérée différemment. Celles-ci ne sont cependant pas écrasé et toujours opérationnelle si tu retournes même provisoirement en mode réel.

Par ailleurs, MS-DOS fonctionne en mode réel. as-tu vraiment intérêt à compiler en mode protégé ?

Pour utiliser le mode protégé sous DOS, la solution était d'utiliser des dos extender de type DOS/4G, DOS/4GW. Pour utiliser les fonctions DOS, le dos extender repassait en mode réel le temps de traiter la demande. Il te faut donc regarder la doc du dos extender que utilises. L'interruption 0x300h que tu cites est probablement le point d'entrée utilisé par un de ces dos extender.

[rocky77]

Bonjour, tu me mets un doute.

Je ne pense pas utiliser de DOS Extender. Si c'est le cas, je ne sais pas comment m'en assurer.
Le Dos qui est installé est tres basique, il provient d'un windows 98 dans lequel on a utilisé la commande sys [lecteur] pour copier le systeme DOS et l'installer sur un autre PC

Le code de mon programme est compilé sous Borland Pascal 7 avec son compilateur par defaut. Lors de la compilation du programme, dans le menu compile..targert, j'ai le choix entre real mode application et protected mode application.
En real mode j'ai aucun soucis mais en protected cela ne fonctionne plus. Mon programme n'arrive plus à communiquer avec le DOSUSB Driver installé en IT65.
Malheureusement, j'ai cette contrainte de devoir compiler le programme en protected mode application

[chrtophe]

A mon avis, ça ne marchera pas sans dos extender, mais peut être y en a t'il un intégré au compilateur Borland. Les interruptions en mode réel sont différentes de celles en mode protégé.

[sambia39]

Bonsoir
Qu'entender vous par mode protéger ça ne marche pas ?
-> s'agit-il de la compilation ou l'utilisation du programme résidant qui vous a été fournis ?

Il faut comprendre que le mode protégé est un mode natif qui fait intervenir des privilèges (au nombre de 4) et si le privilège actuel est différent de 0 (0 niveaux de privilège haut permettant un accès free non restrictif) exemple 3 (protection totale) toute accès se verras peut être refuser. car elle dépendra du privilège et des paramètres définis du système.

Explication: Les différents privilèges sont encodés dans les registres EEFLAGS et les différentes structures de mémoire qui ont des liens avec la mémoire et les ports.
IOPL ( l/O Privilege Level ou indicateur de niveau de privilège d'entrées-sorties) présent dans le registre des drapeaux permet de déterminer le niveau de privilège d'accès a une ressource c'est a dire, toute tentatives d'accès à une ressource fait un appel systématique à une comparaison des champs IOPL avec le niveaux de privilège de la ressource en question et si le niveau de privilège de la ressource souhaitée est inférieur au niveau du champ IOPL. L'accès est immédiatement refusé et une exception levée (ce qui peut justifier que le code écris en mode réel ne peut fonctionner en mode protéger).

On comprend également que des instructions en privilège zéro ne peuvent exécuter ou faire appeler à une fonction ou des instructions du privilège 3, car elle n'est pas protégé. Mais en revanche, l'inverse est possible c'est-à-dire que l'on peut faire appel à des fonctions ou instruction du privilège zéro tout en restant en privilège 3 et d'un autre coter empêcher tout accès en dehors de l'activité en cours d'exécution.
Les autres privilèges intermédiaire à savoir 1 & 2 sont des compromis, car elle permettent l'exécution d'instruction ou l'écriture des drivers sans être en privilège zéro offrant ainsi, la possibilité de contourner (si je peux dire) la contrainte imposé par le niveau de privilège 3.
[I](De mémoire je pense que les machines actuelles travaille en mode réel à travers le mode protéger car elle est émulé mais à vérifier.

Cependant, l'idéale est d'avoir un point d'entrer (un bridge) permettant l'exécution ou l'accès à vos instructions en monde réel tout en restant en mode protéger et donc la proposition de @chrtophe peut être une solution à votre problème.
à bientôt

[Jipété]

-- snip --

Bonsoir,

Je ne comprends pas grand chose à tout ça, si je suis là c'est plus par curiosité.
Je me suis permis de corriger les fautes d'orthographe et de ponctuation, ça devient un peu plus clair, il me reste cependant un point incompréhensible, voir plus bas.
- - - - - - - -
Qu'entendez-vous par mode protégé ça ne marche pas ?
-> s'agit-il de la compilation ou de l'utilisation du programme résidant qui vous a été fourni ?

Il faut comprendre que le mode protégé est un mode natif qui fait intervenir des privilèges (au nombre de 4), et si le privilège actuel est différent de 0 (0 = niveau de privilège haut permettant un accès non restrictif), par exemple 3 (= protection totale), tout accès se verra peut-être refusé car il dépendra du privilège et des paramètres définis du système.

Explication : Les différents privilèges sont encodés dans les registres EEFLAGS et les différentes structures de mémoire qui ont des liens avec la mémoire et les ports.
IOPL (I/O Privilege Level ou indicateur de niveau de privilège d'entrées-sorties) présent dans le registre des drapeaux permet de déterminer le niveau de privilège d'accès à une ressource, c'est-à-dire que toute tentative d'accès à une ressource fait un appel systématique à une comparaison du champ IOPL avec le niveau de privilège de la ressource en question, et si le niveau de privilège de la ressource souhaitée est inférieur au niveau du champ IOPL l'accès est immédiatement refusé et une exception levée (ce qui peut justifier que le code écrit en mode réel ne peut fonctionner en mode protégé).

On comprend également que des instructions en privilège 0 ne peuvent exécuter ou faire appel à une fonction ou des instructions du privilège 3, car elles ne sont pas protégées. Mais en revanche, l'inverse est possible c'est-à-dire que l'on peut faire appel à des fonctions ou instructions du privilège 0 tout en restant en privilège 3, et d'un autre côté, empêcher tout accès en dehors de l'activité en cours d'exécution.
Les autres privilèges intermédiaires, à savoir 1 & 2, sont des compromis, car ils permettent l'exécution d'instructions ou l'écriture de drivers sans être en privilège 0, offrant ainsi la possibilité de contourner (si je peux dire) la contrainte imposée par le niveau de privilège 3.
[I] (De mémoire je pense que les machines actuelles travaillent en mode réel à travers le mode protégé car il est émulé, mais à vérifier.)

Cependant, l'idéal est d'avoir un point d'entrée (un bridge) permettant l'exécution ou l'accès à vos instructions en mode réel tout en restant en mode protégé, et donc la proposition de @chrtophe peut être une solution à votre problème.
- - - - - - - -

Ce qui n'est pas clair :

On comprend également que des instructions en privilège 0 ne peuvent exécuter ou faire appel à une fonction ou des instructions du privilège 3, car elles ne sont pas protégées.

Elles ne sont pas protégées... Qui ça ? Les fonctions ou les instructions du privilège 3 ? La phrase ne devrait-elle pas être alors car elles ne sont pas en mode protégé ? Ça serait plus clair, il me semble.


Autre point : on voit bien qu'il y a une note dans le texte, à l'avant-dernière ligne

[I] (De mémoire...

mais je n'ai pas été capable de trouver l'appel de note correspondant...

[sambia39]

.....
Ce qui n'est pas clair : Elles ne sont pas protégées... Qui ça ? Les fonctions ou les instructions du privilège 3 ? La phrase ne devrait-elle pas être alors car elles ne sont pas en mode protégé ? Ça serait plus clair, il me semble.

Autre point : on voit bien qu'il y a une note dans le texte, à l'avant-dernière ligne mais je n'ai pas été capable de trouver l'appel de note correspondant...

Quand je parle d'instructions et de fonction je parle d'un tout. Pour faire simple l'ensemble du code qui s'exécute dans la mémoire.

La phrase ne devrait-elle pas être alors car elles ne sont pas en mode protégé ? Ça serait plus clair, il me semble.

Le mode protégé est le mode qui vient compléter le mode réel avec les fonctionnalités suivantes:

• Protection de la mémoire grâce aux privilèges
• Commutation de contexte
• Gestion de la mémoire virtuelle

Techniquement le niveau de privilège le plus élevé est le zéro, le plus faible est le trois.


Les instructions du privilège le plus bas à savoir zéro ne peuvent faire appel aux instructions du privilège le plus haut (3) tout simplement parce que le CPU travail avec le privilège zéro donc non protéger (une fonction ou instruction d'un programme ne peut accéder ou s'exécuter dans un segment mémoire du privilège supérieur c'est-à-dire, travailler dans l'espace noyau, car celui-ci travail sans restriction). Mais par contre l'inverse est possible, le privilège trois peut faire appel aux fonctions du privilège zéro, mais le CPU reste en privilège trois ce qui permet d'évite des accès hors du contexte d'exécution actuelle.
Je préfère donc parler de privilège pour qu'il comprenne pourquoi certaines actions ne fonctionneront pas dans le mode protégé à cause du niveau de privilège du programme en cours d'exécution et qu'il est préférable d'adopter la solution proposée par @@chrtophe qui est de passer par un bridge -> DosExtender.

Autre point : on voit bien qu'il y a une note dans le texte, à l'avant-dernière ligne mais je n'ai pas été capable de trouver l'appel de note correspondant...

La phrase qui commence par de mémoire mise en italique entre parenthèses veut tout simplement dire que, les ordinateurs actuels (de nos jours) exécute le mode réel à travers le mode protéger en émulant le mode réel, mais à vérifier.

À bientôt et merci pour la remarque sur les fautes d'orthographe.

[rocky77]

Bonjour,

Merci bien pour la reponse. Malheuresement, je pense que mes connaissances en programmation sont loin d'etre au niveau. Pas sur d'avoir tout compris

Bonsoir
Qu'entender vous par mode protéger ça ne marche pas ?
-> s'agit-il de la compilation ou l'utilisation du programme résidant qui vous a été fournis ?

Alors il s'agit d'un programme qui est compilé sous Borland Pascal 7 et qui doit communiquer par USB avec une carte électronique d’entrée/sortie. La compilation se passe correctement en target mode reel comme en protected mode application.
C'est lors de l'execution de programme que la communication par USB ne fonctionne pas si je compile en protected mode. ( en mode reel, la communication est ok).

J'utilise un driver appellé DOSUSB.com :c'est un programme résidant. Il reste en mémoire et installe un vecteur sur l'interruption $65 qui sert de point d'entrée à mon programme.

Cependant, l'idéale est d'avoir un point d'entrer (un bridge) permettant l'exécution ou l'accès à vos instructions en monde réel tout en restant en mode protéger et donc la proposition de @chrtophe peut être une solution à votre problème.
à bientôt

Je ne sais pas du tout ce qu'est un DosExtender. Je vais faire des recherches. Est ce facile à mettre en place ?

[chrtophe]

J'utilise un driver appellé DOSUSB.com :c'est un programme résidant. Il reste en mémoire et installe un vecteur sur l'interruption $65 qui sert de point d'entrée à mon programme.

C'est un driver en mode réel, non disponible pour le mode protégé, car son interruption 0x65 est ne interruption mode réel. Pour y accéder depuis le mode protégé, il te faut repasser provisoirement en mode réel, puis revenir en mode protégé.

Je ne sais pas du tout ce qu'est un DosExtender.

MS-DOS ne connait pas le mode protégé. Un dos extender est une surcouche qui permet d'utiliser du code en mode protégé avec MS-DOS, ton code est en mode protégé, et reviens de façon ponctuelle en mode réel pour traiter les interruptions DOS notamment. c'est intégré lors de la compilation.
https://en.wikipedia.org/wiki/DOS_extender

les ordinateurs actuels (de nos jours) exécute le mode réel à travers le mode protéger en émulant le mode réel, mais à vérifier.

C'est un peu ça il s'agit du mode v86 :
https://fr.wikipedia.org/wiki/Mode_virtuel_8086
Attention ce mode n'est pas disponible en 64 bits, le CPU en mode 64 bits ne pouvant créer de tâche 16 bits, v86 s’exécute via une tache 16 bits, c'est opérationnel en mode legacy, pas en long mode.

[rocky77]

Si j'ai bien compris, il faut que je lance l'extender avec le driver USB qui fonctionne en mode reel, afin qu'il fonctionne en protected et qu'il puisse se comprendre avec mon programme ?

Je viens de tester Dos/4GW et Dos32A en tapant la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
c:\>dos4gw dosusb.com
DOS/4GW Protected Mode Runtime Version 2.01a
Copyright (c) Tenberry Software, Inc. 1996
DOS/4GW fatal error (1008) : can't load executable format for file DOSUSB.COM[1]

Idem avec DOS32A

[chrtophe]

Non, c'est conçu pour les applis en mode protégé compilé avec son support.

[rocky77]

J'ai exactement le meme message avec mon application. Je me demande si ces extenders sont compatibles les executables obtenus avec le compilateur Borland Pascal 7 ?

Arghh, Je pense qu'il me faut un dos extender 16 bits !! vu que mon programme compilé avec le compilateur borland pascal doit etre en 16bits....Vais voir où je peux trouver ça!

[rocky77]

J'ai trouvé celui-ci
http://www.sudleyplace.com/dpmione/
Je l'ai chargé et voila les résultats :
Si je lance mon programme compilé en mode reel, le programme s'execute comme d'habitude
Si je lance mon programme compilé en mode protected, le programme semble se lancer mais 1seconde apres je retombe sur le prompt

c:\> mon_programme.exe ...... j'appui sur entrée..... le curseur passe à la ligne suivante..... puis a nouveau l'affichage de c:\> sans que rien ne se passe.

[rocky77]

Bonjour,

J'ai laissé tomber les dos extender. Borland Pascal sait gerer le DPMI. J'ai pu contacter le gars qui a développé un des dos extenders (tenberry -dos4GW) et qui m'a dit que je pouvais m'en sortir mais que ce ne serait pas si évident.

Voila ce qu'il m'a dit mais que malheureusement je ne sais pas mettre en oeuvre.

Unfortunately, it isn't just a matter of getting the interrupt done in real mode. Your code seems like you understand the basic idea okay.

I see your structure has pointer fields, and the information is passed to the RM code in that structure.

The driver RM code at int $65 can only reference memory in the first megabyte. Your program and its data will be allocated somewhere above one megabyte, so you have to:

Allocate the structure to be passed to your driver in DOS memory.
If the structure points to memory buffers, those also have to be in DOS memory. Otherwise the driver won't be able to see them
Get a PM pointer to the structure in DOS memory.
Use that pointer to fill in the structure and buffers.
Change all of the addresses to be real-mode addresses in the structure.

There are DPMI calls to help you do all of the above, but it's not as simple as the code you've written so far.

It's all doable, and probably in a few days work for you, but it's not trivial.

You might start by trying an interrupt which doesn't need a structure, like the DOS get time subfunction. Once you have that working, try an int $65 which doesn't involve buffers so that you only have to worry about allocating the structure in DOS memory. Finally, you can do the full job, with buffers in DOS memory as well as the structure.

[Forthman]

Bonjour,

question : si ton programme se compile et fonctionner en mode réel, pourquoi vouloir le compiler en mode protégé ?

[rocky77]

Bonjour,

C'est parce que ce programme doit être intégré dans un autre beaucoup plus volumineux dont la taille dépasse le Mo.

[sambia39]

Bonjour
Je ne suis pas sûr, mais il peut avoir une solution plus technique, mais qui demande une bonne connaissance en programmation système.

Comme ce qui @chrtophe à mentionner dans l'un de ces postes; En mode protéger les interrupteurs ne sont plus disponible donc tout est à refaire à savoir la table des descripteurs interrupteurs, le contrôleur des interrupteurs et le chargeur de pilote (qui se charge de référencer les pilotes dans la table des interrupteurs). Donc si vous souhaitez passer en monde réel juste le tant de réaliser une opération, il vous faut sauvegarder les descripteurs du monde réel dans le GDT et de mettre en place un switch de façon à bascule en monde réel quand vous souhaitez utiliser votre pilote USB et à la fin revenir en mode protéger si tout est terminé.

Je ne me suis pas trop penché sur la question de ma solution, mais si un autre membre du forum pourrait nous éclairer davantage ou proposer une autre solution, je suis preneur.
à bientôt.

[chrtophe]

Le mode protégé a sa propre table d'interruptions fonctionnant un peu différemment de la table mode réel. En mode réel la table d'interruption se situe de l'adresse 0:0 à 0:400 (256 entrées de 4 octets). En mode protégé, la table est à l'adresse mémoire stockée dans le registre IDT. Le passage en mode protégé déclenche l'usage de la table d'interruptions (qui n'est pas qu'un liste d'adresse comme en mode réel) dans l'IDT, celle du mode réel n'est plus utilisée mais pas écrasée. Il est tout à fait possible de repasser en mode réel le temps d’exécuter ta fonction int 0x65 puis une fois celle-ci terminée de repasser en mode protégé. C'est lourd à faire mais c'est faisable, j'ai déjà fait mais en assembleur. DPMI permet d’exécuter les fonctions DOS.

C'est pas gagné ton truc car je ne suis pas sûr que DPMI te permette d'appeler autre chose que des fonctions DOS. Par ailleurs, si DPMI passe le CPU en mode V86 (https://fr.wikipedia.org/wiki/Mode_virtuel_8086), tu es encore en mode protégé et le CPU contrôle les interruptions et les accès au matériel, donc ton driver DOS risque de crasher et lever des exceptions.

Pour ton problème, restes à mon avis en mode réel, et gères le dépassement de 1 Mo via l'overlay et la mémoire XMS/EMS.

[rocky77]

Bonjour,

J'ai enfin reussi à regler mon probleme en jouant sur les adresses memoires mode reel/mode protegé. Voici un extrait du code resultant.

Merci a tous pour votre aide !!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
function Intr386(const int_number:byte; const stack_words:word;
                       var regs:DPMIRegisters): word; assembler;
asm
   push es
   push di
   xor bx, bx
   mov bl, int_number
   mov cx, stack_words
   les di,regs
   mov ax, 0300h
   int 31h
   pop di
   pop es
end;


(*//////////////////////////// DO_OUT //////////////////////////////////*)
Procedure do_out;  (* To PIC *)
Var
  DCS : DPMIRegisters;
  selseg, selseg_buff :longint;
  selector, selector_buff, segment, segment_buff : word;
  P_PM : p_buffer;
  P_PM_buff : p_buffer;

Begin
 selseg := globaldosalloc(40);
 selector := word(selseg and $FFFF);
 segment := word(selseg SHR 16);
 P_PM:=ptr(selector,0);

 selseg_buff := globaldosalloc(257);
 selector_buff := word(selseg_buff and $FFFF);
 segment_buff := word(selseg_buff SHR 16);
 P_PM_buff:=ptr(selector_buff,0);
 move(buffer_o,P_PM_Buff^,sizeof(buffer_o)); (*REMPLISSAGE AVEC POINTEUR PROTECTED VERS MEMOIRE AVEC DONNEES MODE REEL *)

(* set up out request *)
 urb.transaction_token := $E1;(* $E1= Sortie*)
 urb.chain_end_flag := 0;
 urb.dev_add := the_dev_add;  (* Adresse Microchip =1 si c'est le seul usb connecte à la carte mere*)
 urb.end_point := out_endpoint;    (* =1 *)
 urb.error_code := 0;
 urb.status := 0;
 urb.transaction_flags := 0;
 urb.buffer_off :=0; (* METTRE OFFSET A 0 *)
 urb.buffer_seg := segment_buff; (* SEGMENT ADRESSE EN MODE REEL *)
 urb.buffer_length := packetlen;
 urb.actual_length := 64;
 urb.setup_buffer_off := 0;
 urb.setup_buffer_seg := 0;
 urb.start_frame := 0;
 urb.nr_of_packets := 0;
 urb.int_interval := 0;
 urb.error_count := 0;
 urb.timeout := 0;
 urb.next_urb_off := 0;
 urb.next_urb_seg := 0;

(* now call DosUHCI *)
 fillchar(dcs, sizeof(dcs), 0);
 move(urb,P_PM^,sizeof(urb)); (*REMPLISSAGE AVEC POINTEUR PROTECTED VERS MEMOIRE AVEC DONNEES MODE REEL *)
 DCS.DPMI_ES := 0;(*segment;*)
 DCS.DPMI_DS := segment;(*ADRESSE SEGMENT MODE REEL DE MA STRUCTURE URB*)
 DCS.DPMI_EDX := 0;
 intr386($65, 0, dcs);
 GlobalDosFree(selector);
 GlobalDosFree(selector_buff);
 (* Reg.DS := seg(urb);
 Reg.DX := ofs(urb);
 Intr($65,Reg);*)
 Inc(ReqNr);
End (* do_out *);

[Forthman]

Alors là moi je dis bravo !

Moi j'aurais jeté l'éponge vite fait