Est-il possible de gérer les ports série par un programme
DOS, exécuté sur les postes sous Win NT, 2000 ou XP ?
Les essais que j'ai effectués permettent d'envoyer les
données vers le port COM mais ne donnent pas de résultat
en lecture (cette application de communication bi-
directionnelle fonctionne parfaitement sur les postes Win
9x).
Est-il possible de gérer les ports série par un programme
DOS, exécuté sur les postes sous Win NT, 2000 ou XP ?
Les essais que j'ai effectués permettent d'envoyer les
données vers le port COM mais ne donnent pas de résultat
en lecture (cette application de communication bi-
directionnelle fonctionne parfaitement sur les postes Win
9x).
Est-il possible de gérer les ports série par un programme
DOS, exécuté sur les postes sous Win NT, 2000 ou XP ?
Les essais que j'ai effectués permettent d'envoyer les
données vers le port COM mais ne donnent pas de résultat
en lecture (cette application de communication bi-
directionnelle fonctionne parfaitement sur les postes Win
9x).
Yves s'est ainsi exprimé:
> Est-il possible de gérer les ports série par un programme
> DOS, exécuté sur les postes sous Win NT, 2000 ou XP ?
>
> Les essais que j'ai effectués permettent d'envoyer les
> données vers le port COM mais ne donnent pas de résultat
> en lecture (cette application de communication bi-
> directionnelle fonctionne parfaitement sur les postes Win
> 9x).
Il est strictement interdit sous NT d'accéder DIRECTEMENT (par des "in",
"out", "intxxh",... au matériel)
(ports E/S, DD, vidéo,..)!
Tout accès au matériel DOIT passer par le système.
Dans un programme Win32, on doit utiliser la fonction "CreateFile" (de
kernel32.dll), qui permet d'ouvrir à peu près n'importe quoi (fichiers,
répertoires, ports COM et LPT,..)
Syntaxe C :
HANDLE CreateFile(
LPCTSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
);
On doit avoir, dans le cas d'un port, :
dwShareMode = 0 (accès exclusif)
dwCreationDisposition = OPEN_EXISTING
hTemplateFile = NULL
On peut aussi s'en tirer à l'aide d'une interface nommée "NTPort", qui
fonctionne très bien (sous Win9X/ME/NT3.5x/NT4/W2K/XP/W2K3) , et est
utilisable dans toute appli C,/C++, VB, Delphi, VN.NET, C#, ...(tout est
fourni : les *.h, *.cpp, *.dsw, ..*.dfm, *.dpr, *.pas, ...*.frm..)
Son usage est plus simple que celui de Createfile.
Ce n'est pas gratuit, mais le prix est raisonnable (30 $)
http://zealsoftstudio.com/ntport/
Si le programme est non modifiable (parce qu'on n'a pas le source, ...)
et/ou parce que c'est une vieille appli DOS, la seule solution (pas
évidente!) est de développer un VDD (Virtual Dos Driver), qui est une DLL
bits un peu spéciale, dont le rôle est d'intercepter tous les appels
matériels directs d'une appli DOS, pour les retransmettre "correctement" à
Windows.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
*
Yves <anonymous@discussions.microsoft.com> s'est ainsi exprimé:
> Est-il possible de gérer les ports série par un programme
> DOS, exécuté sur les postes sous Win NT, 2000 ou XP ?
>
> Les essais que j'ai effectués permettent d'envoyer les
> données vers le port COM mais ne donnent pas de résultat
> en lecture (cette application de communication bi-
> directionnelle fonctionne parfaitement sur les postes Win
> 9x).
Il est strictement interdit sous NT d'accéder DIRECTEMENT (par des "in",
"out", "intxxh",... au matériel)
(ports E/S, DD, vidéo,..)!
Tout accès au matériel DOIT passer par le système.
Dans un programme Win32, on doit utiliser la fonction "CreateFile" (de
kernel32.dll), qui permet d'ouvrir à peu près n'importe quoi (fichiers,
répertoires, ports COM et LPT,..)
Syntaxe C :
HANDLE CreateFile(
LPCTSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
);
On doit avoir, dans le cas d'un port, :
dwShareMode = 0 (accès exclusif)
dwCreationDisposition = OPEN_EXISTING
hTemplateFile = NULL
On peut aussi s'en tirer à l'aide d'une interface nommée "NTPort", qui
fonctionne très bien (sous Win9X/ME/NT3.5x/NT4/W2K/XP/W2K3) , et est
utilisable dans toute appli C,/C++, VB, Delphi, VN.NET, C#, ...(tout est
fourni : les *.h, *.cpp, *.dsw, ..*.dfm, *.dpr, *.pas, ...*.frm..)
Son usage est plus simple que celui de Createfile.
Ce n'est pas gratuit, mais le prix est raisonnable (30 $)
http://zealsoftstudio.com/ntport/
Si le programme est non modifiable (parce qu'on n'a pas le source, ...)
et/ou parce que c'est une vieille appli DOS, la seule solution (pas
évidente!) est de développer un VDD (Virtual Dos Driver), qui est une DLL
bits un peu spéciale, dont le rôle est d'intercepter tous les appels
matériels directs d'une appli DOS, pour les retransmettre "correctement" à
Windows.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Jean-Claude.Bellamy@wanadoo.fr * JC.Bellamy@free.fr
Yves s'est ainsi exprimé:
> Est-il possible de gérer les ports série par un programme
> DOS, exécuté sur les postes sous Win NT, 2000 ou XP ?
>
> Les essais que j'ai effectués permettent d'envoyer les
> données vers le port COM mais ne donnent pas de résultat
> en lecture (cette application de communication bi-
> directionnelle fonctionne parfaitement sur les postes Win
> 9x).
Il est strictement interdit sous NT d'accéder DIRECTEMENT (par des "in",
"out", "intxxh",... au matériel)
(ports E/S, DD, vidéo,..)!
Tout accès au matériel DOIT passer par le système.
Dans un programme Win32, on doit utiliser la fonction "CreateFile" (de
kernel32.dll), qui permet d'ouvrir à peu près n'importe quoi (fichiers,
répertoires, ports COM et LPT,..)
Syntaxe C :
HANDLE CreateFile(
LPCTSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
);
On doit avoir, dans le cas d'un port, :
dwShareMode = 0 (accès exclusif)
dwCreationDisposition = OPEN_EXISTING
hTemplateFile = NULL
On peut aussi s'en tirer à l'aide d'une interface nommée "NTPort", qui
fonctionne très bien (sous Win9X/ME/NT3.5x/NT4/W2K/XP/W2K3) , et est
utilisable dans toute appli C,/C++, VB, Delphi, VN.NET, C#, ...(tout est
fourni : les *.h, *.cpp, *.dsw, ..*.dfm, *.dpr, *.pas, ...*.frm..)
Son usage est plus simple que celui de Createfile.
Ce n'est pas gratuit, mais le prix est raisonnable (30 $)
http://zealsoftstudio.com/ntport/
Si le programme est non modifiable (parce qu'on n'a pas le source, ...)
et/ou parce que c'est une vieille appli DOS, la seule solution (pas
évidente!) est de développer un VDD (Virtual Dos Driver), qui est une DLL
bits un peu spéciale, dont le rôle est d'intercepter tous les appels
matériels directs d'une appli DOS, pour les retransmettre "correctement" à
Windows.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
*
Si le programme est non modifiable (parce qu'on n'a pas le source, ...)
et/ou parce que c'est une vieille appli DOS, la seule solution (pas
évidente!) est de développer un VDD (Virtual Dos Driver), qui est une DLL 32
bits un peu spéciale, dont le rôle est d'intercepter tous les appels
matériels directs d'une appli DOS, pour les retransmettre "correctement" à
Windows.
Si le programme est non modifiable (parce qu'on n'a pas le source, ...)
et/ou parce que c'est une vieille appli DOS, la seule solution (pas
évidente!) est de développer un VDD (Virtual Dos Driver), qui est une DLL 32
bits un peu spéciale, dont le rôle est d'intercepter tous les appels
matériels directs d'une appli DOS, pour les retransmettre "correctement" à
Windows.
Si le programme est non modifiable (parce qu'on n'a pas le source, ...)
et/ou parce que c'est une vieille appli DOS, la seule solution (pas
évidente!) est de développer un VDD (Virtual Dos Driver), qui est une DLL 32
bits un peu spéciale, dont le rôle est d'intercepter tous les appels
matériels directs d'une appli DOS, pour les retransmettre "correctement" à
Windows.
On Thu, 16 Oct 2003 10:19:39 +0200, "Jean-Claude BELLAMY"
wrote:Si le programme est non modifiable (parce qu'on n'a pas le source,
...) et/ou parce que c'est une vieille appli DOS, la seule solution
(pas évidente!) est de développer un VDD (Virtual Dos Driver), qui
est une DLL 32 bits un peu spéciale, dont le rôle est d'intercepter
tous les appels matériels directs d'une appli DOS, pour les
retransmettre "correctement" à Windows.
J'ai une question :
existe t il un programme analysant un vieux programme dos afin de
savoir quelles sont les appel au materiel ?
J'ai un programme qui ne fonctionne pas sous 2000 et qui rame a fond
sur XP au point que si je le lance une deuxieme fois j'ai le temps de
boire un café entre chaque manip (celeron 2000). J'aimerai developper
un VDD si cela permet d'accelerer son traitement mais je ne sais pas
où trouver de tutorial en francais.
On Thu, 16 Oct 2003 10:19:39 +0200, "Jean-Claude BELLAMY"
<Jean-Claude.Bellamy@wanadoo.fr> wrote:
Si le programme est non modifiable (parce qu'on n'a pas le source,
...) et/ou parce que c'est une vieille appli DOS, la seule solution
(pas évidente!) est de développer un VDD (Virtual Dos Driver), qui
est une DLL 32 bits un peu spéciale, dont le rôle est d'intercepter
tous les appels matériels directs d'une appli DOS, pour les
retransmettre "correctement" à Windows.
J'ai une question :
existe t il un programme analysant un vieux programme dos afin de
savoir quelles sont les appel au materiel ?
J'ai un programme qui ne fonctionne pas sous 2000 et qui rame a fond
sur XP au point que si je le lance une deuxieme fois j'ai le temps de
boire un café entre chaque manip (celeron 2000). J'aimerai developper
un VDD si cela permet d'accelerer son traitement mais je ne sais pas
où trouver de tutorial en francais.
On Thu, 16 Oct 2003 10:19:39 +0200, "Jean-Claude BELLAMY"
wrote:Si le programme est non modifiable (parce qu'on n'a pas le source,
...) et/ou parce que c'est une vieille appli DOS, la seule solution
(pas évidente!) est de développer un VDD (Virtual Dos Driver), qui
est une DLL 32 bits un peu spéciale, dont le rôle est d'intercepter
tous les appels matériels directs d'une appli DOS, pour les
retransmettre "correctement" à Windows.
J'ai une question :
existe t il un programme analysant un vieux programme dos afin de
savoir quelles sont les appel au materiel ?
J'ai un programme qui ne fonctionne pas sous 2000 et qui rame a fond
sur XP au point que si je le lance une deuxieme fois j'ai le temps de
boire un café entre chaque manip (celeron 2000). J'aimerai developper
un VDD si cela permet d'accelerer son traitement mais je ne sais pas
où trouver de tutorial en francais.