Discussion :

[Sub0]

J'ai refais des essais et effectivement, tu as raison; Le nom de service peut très bien être le même pour tous les programmes! Alors, je ne comprend pas ce qui a de différents par rapport au code original du coups, mis à part le fait que l'on est mis l'initialisation et la finalisation dans des procédures et séparé le nom du service de celui du fichier SYS... Bon, j'ai donc supprimé le paramètre de ZLInit puisque ça ne sert à rien...

http://sub0.developpez.com/delphi/LPT_1d.zip

[petitcoucou31]

Dans mon cas je pense que le fait de passer l'initialisation et la finalisation par procedure me permet de ne faire qu'une finalisation quand je quitte mon programme principal et seulement là . Contrairement au code d'origine , qui devait me faire autant de finalisation que d'appel a ZlportIo !! et au final la finalisation se passer mal !! .

[edam]

salut
j'ai pas fai de test moi de tt sa, , en plus je travail sous P2 IBM pro +win98, sa veu dire que j'utilise jamai zlportio.sys,mai comme même j'aime bien savoire ce qu'il contient
alors sub autre faveur, si tu as les sources de zlportio.sys merci de ns le présenter ,si non au moins une idée de ce qu'il peut contenir
merci

[Sub0]

Je n'ai pas les sources du fichier SYS. L'auteur ne les distribue pas. Le fichier SYS est en fait un programme compilé (un EXE). Mais bon, il n'est pas prévu pour fonctionner seul, c'est pour ça qu'il possède l'extension SYS, il doit être administrer par un autre programme, un particulier les fonctions de l'unité DDKInt. Ce programme est un service qui gère les droits d'accès aux ports dans un système d'exploitation multi-tâches... Sous ces systèmes, tous le matériel est géré avec des droits d'utilisateurs donnés aux programmes. Cela doit permettre d'éviter les conflits lorsque plusieurs programmes fonctionnent en simultanné et utilisent le même matériel (la mémoire ou le disque dur par exemple). Le matériel ne peut pas faire plusieurs choses à la fois. J'espère que cela répond à ta question, à+

[Sub0]

Salut!

Edam, suite à ton MP (et ce n'est parceque le sujet est résolu qu'on ne peut plus débattre ), je vais essayer de te donner des pistes sur ce que tu veux réaliser... En fait, tu aimerai comprendre et développer ton propre service d'accès matériel dans un système Windows multi-tâches si j'ai bien saisi... Perso, je ne me suis jamais pencher sur ce genre de projet, estimant qu'il fallait savoir utiliser les outils qui nous sont proposés sans chercher plus loin, sans vouloir surtout réinventer la roue comme on dit...

Déjà, ZLPortIO est un pilote, un service s'occupant de fournir l'accès du matériel avec ce que l'on appelle des interfaces. Ce sont des accès provenants directement du pilote "hardware" développé par le fabriquant du matériel. En général, les sources de ces pilotes sont secrètes (surtout lorsqu'il sagit de matériel spécifique et non standard).

Bref, le matériel est géré à la base par le pilote du fabriquant. Ce pilote fournit les fonctions essentielles du matériel au système. Windows a défini dès le départ un protocol standard permettant à tous les périphériques d'être "compatibles" avec ce système et de pouvoir communiquer avec les autres périphériques...

Pour illustrer cela, je prend par exemple l'audio sous Windows, souvent géré par DirectSound, le module audio de DirectX. Pour accéder aux fonctionalités du matériel via DirectSound dans un programme, on utilise l'interface standard suivante :

Code :

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

IDirectSound=interface (IUnknown)['{279AFA83-4981-11CE-A521-0020AF0BE560}']

Le pilote de la carte son, crée par le fabriquant utilise le "protocol", les consignes données par Windows et DirectX. Ainsi toutes les cartes sons ont le même accès au final, la même interface, mais pas le même pilote matériel. Ce sont les fabriquants qui sont chargés de fournir l'accès compatibilité de leur matériel au système avec leur pilote "hardware"... Les services eux utilisent directement ces accès compatibles ce qui leur permet donc d'être eux-même des programmes compatibles.

L'exemple de DirectSound est bien selon moi, parcequ'il te permettra de comprendre le vrai multi-tâches, dans la mesure où l'on peut jouer plusieurs samples en simultané sans utiliser un code de mixage, mais en utilisant justement les propriétés du multi-tâches!

La conception de service est probablement expliqué en détail sur Internet. Fais donc des recherches, et tiens-nous informés car pour ma part, je n'en sais pas plus sur le sujet (j'en ai pas trop l'utilité à vrai dire). En tous les cas, si tu veux aller aux bouts des choses avec le port parrallèle, il te faudra probablement savoir comment fonctionne le matériel à la base (UART). Il te faudra aussi savoir quelle est l'interface du matériel et comment l'utiliser pour accéder aux fonctions de base...

Sources complètes du mixage temps réel avec DirectSound :
http://sub0.developpez.com/FormatWAV/mixsound.zip

à+