Discussion :

[serrepate]

programme qui tourne sous win98 et plante sous win xp
bonjour à tous,
tout d'abord,
le sujet.
un collègue, a fabriqué, pour moi, un .exe en vb4, celui ci fait appelle à une dll, écrite en assembleur (masm32), le tout fonctionne bien sous win98, mais "plante" sous win xp.

but du prog:
interrogation de l'état de la broche 6 (DSR) du port com1, à une fréquence élevée, au delà des capacités de réponse, de l'api win xp dédiée. ce qui explique que l'on n'y fasse pas appelle.

le programme "plante" lors de l'instruction "in" notament (boucle1 dans le .asm utiliser pour la dll) mais pas seulement.

l'explication mon collègue la connait:

on essaye de récupérer des informations, à des "emplacements" où il nous est "interdit d'accèder" par xp (protection)

la question maintenant:
comment devrait-on faire pour obtenir le résultat souhaité, tout en respectant les règles de programmation sous xp.
j'espère avoir été clair dans mon explication.
je place ci-dessous le contenu du .asm utilisé dans la dll pour plus de clareté.
merci d'avance
cordialement

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
75
76
77
78
79
80
81
82
83
84
85
  comment * -----------------------------------------------------
          début fonction MESURE:
Cette fonction renvoie le nb changements etats de DSR (com1) [DWORD] ,pendant le 
temps "nb_cycl" passé en argument [WORD] .
          ------------------------------------------------------- *
          
mesure PROC nb_cycl:WORD    ;nb_cycl contient nb pas de 54.9 ms

LOCAL   com_prec :BYTE
LOCAL   count_fin :WORD  ;heure fin
LOCAL   count_deb :WORD  ;heure debut
LOCAL   count_com :DWORD ;nb changements etats DSR (com1)

pushcontext all
pushfd


    ;debut time dans bx
push ds
mov bx,040h
mov ds,bx
mov bx,word ptr ds:[06Ch]
pop ds
    ;fin time dans bx
mov count_deb,bx


.while count_deb==bx       ;synchro compteur temps.
    ;debut time dans bx
push ds
mov bx,040h
mov ds,bx
mov bx,word ptr ds:[06Ch]
pop ds
    ;fin time dans bx
.endw

add bx,nb_cycl
mov count_fin,bx
mov count_com,0


;debut mesure nb cycles

push ds
mov dx,040h
mov ds,dx
mov dx,word ptr ds:[0000h] ; met adresse de COM1 dans dx.
pop ds

add dx,6 ; met adresse du registre d'etat de COM1 dans dx.
in al,dx
and al,20h  ;mesure le bit 5 de COM1
mov com_prec,al


boucle1 LABEL near           ;entree du test

in al,dx
and al,20h  ;mesure le bit 5 de COM1

.if al != com_prec
mov com_prec,al
inc count_com
.endif


    ;debut time dans bx
push ds
mov bx,040h
mov ds,bx
mov bx,word ptr ds:[06Ch]
pop ds
    ;fin time dans bx
.if bx != count_fin
jmp boucle1
.endif


popfd
popcontext all

return count_com 

mesure ENDP

[Médinoc]

Si les APIs de WinXP ne supportent pas ce que tu cherches à faire, tu n'as pas d'autre choix que de mettre tout ce code dans un driver en mode kernel.

[serrepate]

bonsoir,
le conditionnel laisserait-il penser qu'il peut exister une éventualité de réaliser malgré tout le projet (ouf)?

drivers, le mode kernel pourrais tu développer, c'est quoi?
merci d'avance
cordialement

[electroremy]

Bonsoir,

ceci résoudra peut-être ton problème :

télécharges l'utilitaire porttalk (cherches porttalk sur google)

ensuite, lance le fichier .exe de ton application avec porttalk.

j'avais le même problème avec mes logiciels de commande de montages électroniques branchés sur le port // qui fonctionnaient sous 95 et 98 mais pas sous NT ni XP.

porttalk m'a permis de continuer à utiliser mes logiciels sous XP

PS : Pour les participants de la conversation qui ont l'air de s'y connaître en programmation de drivers, pouvez-vous essayer de répondre à mon post (conseils pour un drivers) merci

EDIT : pour des raisons de sécurité lis la doc de porttalk et prends la peine de n'autoriser à ton app uniquement l'accès au port dont tu te sers.

A+

[Médinoc]

Désolé, je ne m'y connais pas en programmation de drivers.
Mais je sais que le mode kernel est l'unique moyen d'accéder aux instructions assembleur in et out, qui sont interdites en mode utilisateur.

[electroremy]

Désolé, je ne m'y connais pas en programmation de drivers.
Mais je sais que le mode kernel est l'unique moyen d'accéder aux instructions assembleur in et out, qui sont interdites en mode utilisateur.

Merci pour ta réponse.

"driver" est peut être un mot peu prétentieux pour mon projet; je souhaites créer un programme, ou plutôt un processus, assez rapide, pas trop gourmand en ressources, accédant aux ports de la machine. Ce processus serai utilisé par mes applications.

d'après ta réponse, je dois donc utiliser le mode kernel pour mon processus.

je parcours le site developpez.com, il est très complet, j'ai déjà téléchargé bcp de tutoriaux (assembleur, structures des fichiers EXE), je vais apprendre plein de choses mais je risque de partir dans toutes les directions et d'étouffer un peu

vers quelle direction me conseillerais-tu d'aller ?

j'ai consulté le site ReactOS mais je pense être hors sujet.

ce que je compte faire interesse énormément de monde dans l'électronique mais les personnes qui se sont lancées la dedans ont toutes laissé tomber; si j'arrives à quelque chose je metterais les sources en accès libre, cela rendera service à pas mal de monde

A+

[Melem]

Sous Windows XP, comme dans tout système fonctionnant en mode protégé, les instructions IN et OUT, entre autres, sont des instructions privilégiées. On accède aux ports d'E/S (ainsi qu'à d'autres ressources matérielles) aux moyens de fonctions dédiées, à moins de passer en mode noyau. Mais dans l'un ou l'autre cas, cela en effet ne signifie pas que le programme que tu souhaites réaliser est un driver. Si tu dis que le programme doit-être suffisament rapide, alors t'es parti pour le mode noyau, quoi qu'honnêtement, je ne trouve pas les APIs de Windows aussi lentes que cela ...

[electroremy]

Sous Windows XP, comme dans tout système fonctionnant en mode protégé, les instructions IN et OUT, entre autres, sont des instructions privilégiées. On accède aux ports d'E/S (ainsi qu'à d'autres ressources matérielles) aux moyens de fonctions dédiées, à moins de passer en mode noyau. Mais dans l'un ou l'autre cas, cela en effet ne signifie pas que le programme que tu souhaites réaliser est un driver. Si tu dis que le programme doit-être suffisament rapide, alors t'es parti pour le mode noyau, quoi qu'honnêtement, je ne trouve pas les APIs de Windows aussi lentes que cela ...

Bonjour,

ce que je reproche aux API et DLL du style "outport" c'est que leur communication avec l'app est trop basique; c'est l'app écrite en VB qui doit envoyer un par un les octets et gérer la tempo entre les deux et il est quasiment impossible de descendre en dessous de quelques millisecondes.

Il faudrai donc que je reprogramme une DLL "outport" à laquelle je donnerais des fonctions plus évolées (par ex, à qui on donnerai un paquet de données et quelques paramètres de gravure et qui se chargerai du reste)

De plus cette solution est peut être moins complexe à mettre en oeuvre, l'idéal serai de retrouver les auteur et le code source de ces fameuses DLL

Si je m'engage dans cette voie, quels outils et doc me recommendes-tu ?

A+

EDIT : je pense avoir trouvé mon bonheur ici http://www.logix4u.net/inpout32.htm; je vais étudier le code source de cette DLL attentivement et je vous tiens au courant