Un Timer en dessous de la microseconde: comment faire?
18 réponses
chipolatof
Bonjour,
Dans le cadre d'une application qui doit lire l'état du port parallèle
à une fréquence fixe (~10µs), je suis à la recherche d'un moyen
d'obtenir un timer plus "granuleux" que tous les timers standard
disponibles dans Windows (qui sont pour les plus fins à la ms près!).
La seule chose que j'ai trouvé pour l'instant, c'est de faire une
boucle (tant que le temps écoulé depuis la dernière action est < ...),
en prenant directement un calcul sur le nombre de "ticks" processeurs
écoulés depuis la dernière lecture Pour cela j'utilise les routines
QueryPerformanceCounter et QueryPerformanceFrequency.
N'y a-t-il pas d'autre moyen de faire cela? L'idéal serait d'avoir un
handler déclenché toutes les 10µs, et de réaliser la lecture à ce
moment là.
Sinon, y-a-t-il possibilité d'utiliser des routines propres au port
parallèle directement?
J'en suis à essayer avec des morceaux d'assembleur!!!
j'ai installer un XP sur P200 , ca se sent un peu quand même :-)
Lol. Et ça tourne ? T'as combien de mémoire EDO ? 4 barettes de 64 ? <- Le gars qui avait ça à l'époque était millionnaire.
-- AMcD®
http://arnold.mcdonald.free.fr/
VB
Vincent Burel
"Pierre Maurette" wrote in message news:
AMcD® a écrit : > Vincent Burel wrote: > > Il faudrait parler de la préemption, de la sauvegarde de contexte, des
thread
> "idle", des completion I/O, des priorités, des attentes (events,
semaphore,
> etc.), etc. J'imagine qu'il existe des processus interruptifs du système dont il est impossible de se prémunir dans un programme utilisateur, non ?
ben oui, de deux ordres. Matériels et logiciels.
y'a les interruption matérielles , qui automatiquement arrète la tache en cours pour appeller le gestionnaire d'interuption de l'OS ... Ensuite l'OS fait ce qu'il veut, par exemple windows le traduit en évènement qu'il traite avec la priorité qu'il veut, comme bon lui semble. par exemple pour gérer le réseaux, ben dès qu'il y aura une interruption, Windows peut décider de traiter tout de suite, ou bien de prendre acte seulement et de redonner la main le plus vite possible à la tache interrompu... ca dépend de la stratégie mis en place par Microsoft... si qqn sait ce qui a été choisi ! :-) moi j'ai des doutes en fonction du type de périphérique :-)
Ensuite y'a l'interruption de la pré-emption par l'OS, qui ne peut donner un temps infini à la tache en cours, si celle si n'a pas rendu la main au bout d'un certain temps (le quantum), ou par exit, ou par un Sleep, ou par un WaitEvent, alors Windows l'interromp et regarde si un autre thread n'a pas besoin du processeur... Notons que la stratégie de gestion des resources processeurs sur les 32 niveau priorités de Thread sous Windows n'est pas des plus clair...
VB
"Pierre Maurette" <maurettepierre@wanadoo.fr> wrote in message
news:mn.74e07d5465091ed2.31483@wanadoo.fr...
AMcD® a écrit :
> Vincent Burel wrote:
>
> Il faudrait parler de la préemption, de la sauvegarde de contexte, des
thread
> "idle", des completion I/O, des priorités, des attentes (events,
semaphore,
> etc.), etc.
J'imagine qu'il existe des processus interruptifs du système dont il
est impossible de se prémunir dans un programme utilisateur, non ?
ben oui, de deux ordres. Matériels et logiciels.
y'a les interruption matérielles , qui automatiquement arrète la tache en
cours pour appeller le gestionnaire d'interuption de l'OS ... Ensuite l'OS
fait ce qu'il veut, par exemple windows le traduit en évènement qu'il traite
avec la priorité qu'il veut, comme bon lui semble. par exemple pour gérer le
réseaux, ben dès qu'il y aura une interruption, Windows peut décider de
traiter tout de suite, ou bien de prendre acte seulement et de redonner la
main le plus vite possible à la tache interrompu... ca dépend de la
stratégie mis en place par Microsoft... si qqn sait ce qui a été choisi !
:-) moi j'ai des doutes en fonction du type de périphérique :-)
Ensuite y'a l'interruption de la pré-emption par l'OS, qui ne peut donner un
temps infini à la tache en cours, si celle si n'a pas rendu la main au bout
d'un certain temps (le quantum), ou par exit, ou par un Sleep, ou par un
WaitEvent, alors Windows l'interromp et regarde si un autre thread n'a pas
besoin du processeur... Notons que la stratégie de gestion des resources
processeurs sur les 32 niveau priorités de Thread sous Windows n'est pas des
plus clair...
AMcD® a écrit : > Vincent Burel wrote: > > Il faudrait parler de la préemption, de la sauvegarde de contexte, des
thread
> "idle", des completion I/O, des priorités, des attentes (events,
semaphore,
> etc.), etc. J'imagine qu'il existe des processus interruptifs du système dont il est impossible de se prémunir dans un programme utilisateur, non ?
ben oui, de deux ordres. Matériels et logiciels.
y'a les interruption matérielles , qui automatiquement arrète la tache en cours pour appeller le gestionnaire d'interuption de l'OS ... Ensuite l'OS fait ce qu'il veut, par exemple windows le traduit en évènement qu'il traite avec la priorité qu'il veut, comme bon lui semble. par exemple pour gérer le réseaux, ben dès qu'il y aura une interruption, Windows peut décider de traiter tout de suite, ou bien de prendre acte seulement et de redonner la main le plus vite possible à la tache interrompu... ca dépend de la stratégie mis en place par Microsoft... si qqn sait ce qui a été choisi ! :-) moi j'ai des doutes en fonction du type de périphérique :-)
Ensuite y'a l'interruption de la pré-emption par l'OS, qui ne peut donner un temps infini à la tache en cours, si celle si n'a pas rendu la main au bout d'un certain temps (le quantum), ou par exit, ou par un Sleep, ou par un WaitEvent, alors Windows l'interromp et regarde si un autre thread n'a pas besoin du processeur... Notons que la stratégie de gestion des resources processeurs sur les 32 niveau priorités de Thread sous Windows n'est pas des plus clair...
VB
Vincent Burel
"AMcD®" wrote in message news:425ee6ec$0$11244$
Vincent Burel wrote:
> j'ai installer un XP sur P200 , ca se sent un peu quand > même :-)
Lol. Et ça tourne ? T'as combien de mémoire EDO ? 4 barettes de 64 ? <- Le gars qui avait ça à l'époque était millionnaire.
n'exagèrons rien :-) j'avais du commencé avec 2x8 Mo , puis plus tard j'avais du ajouter 2x32Mo , du coup j'ai 80Mo sur ce P200 qui marche d'ailleurs très bien... avec W98. :-)
VB
"AMcD®" <arnold.mcdonald@free.fr> wrote in message
news:425ee6ec$0$11244$636a15ce@news.free.fr...
Vincent Burel wrote:
> j'ai installer un XP sur P200 , ca se sent un peu quand
> même :-)
Lol. Et ça tourne ? T'as combien de mémoire EDO ? 4 barettes de 64 ? <- Le
gars qui avait ça à l'époque était millionnaire.
n'exagèrons rien :-) j'avais du commencé avec 2x8 Mo , puis plus tard
j'avais du ajouter 2x32Mo , du coup j'ai 80Mo sur ce P200 qui marche
d'ailleurs très bien... avec W98. :-)
> j'ai installer un XP sur P200 , ca se sent un peu quand > même :-)
Lol. Et ça tourne ? T'as combien de mémoire EDO ? 4 barettes de 64 ? <- Le gars qui avait ça à l'époque était millionnaire.
n'exagèrons rien :-) j'avais du commencé avec 2x8 Mo , puis plus tard j'avais du ajouter 2x32Mo , du coup j'ai 80Mo sur ce P200 qui marche d'ailleurs très bien... avec W98. :-)
VB
adebaene
Vincent Burel wrote:
y'a les interruption matérielles , qui automatiquement arrète la
tache en
cours pour appeller le gestionnaire d'interuption de l'OS ... Ensuite
l'OS
fait ce qu'il veut, par exemple windows le traduit en évènement
qu'il traite
avec la priorité qu'il veut, comme bon lui semble. par exemple pour
gérer le
réseaux, ben dès qu'il y aura une interruption, Windows peut
décider de
traiter tout de suite, ou bien de prendre acte seulement et de
redonner la
main le plus vite possible à la tache interrompu... ca dépend de la stratégie mis en place par Microsoft... si qqn sait ce qui a été
choisi !
:-) moi j'ai des doutes en fonction du type de périphérique :-)
De manière générale, sous Windows, une ISR (la routine appelée en réponse à l'interruption) doit en faire le moins possible de façon à ne pas bloquer longtemps le processeur dans un mode où les autres interruptions sont masquées. L'ISR en fait donc le minimum puis postes le reste du travail à faire sous forme d'APC (Asynchronous Procedure Call) sur un thread donné. L'APC sera traitée la prochaine fois que le le thread obtiendra un time-slice, mais avant que le thread continue son exécution "normale". Comme l'a dit AMcD, une seule référence sur le sujet : le bouquin de Solomon et Russinovitch (au fait, est-ce que quelqu'un sait si le dernière version apporte beaucoup de nouveautés par rapport à la 3ème édition ?)
Ensuite y'a l'interruption de la pré-emption par l'OS, qui ne peut
donner un
temps infini à la tache en cours, si celle si n'a pas rendu la main
au bout
d'un certain temps (le quantum), ou par exit, ou par un Sleep, ou par
un
WaitEvent, alors Windows l'interromp et regarde si un autre thread
n'a pas
besoin du processeur...
La préemption du task scheduler se fait aussi via un interruption matérielle (c'est l'APIC ou une autre horloge matérielle qui déclenche l'interruption en question à intervalles réguliers). Il y a aussi des interruptions logicielles, mais le mécanisme de traitement est le même...
Notons que la stratégie de gestion des resources processeurs sur les 32 niveau priorités de Thread sous Windows n'est
pas des
plus clair...
C'est très clair (quoiqu'un brin complexe :-) une fois qu'on a lu le Russinovitch : Chaque thread a une priorité "de base" que Windows peut ajuster temporairement pour un tas de raisons en cours d'exécution (ex : une fenêtre reçoit le focus, un thread sort d'un WaitFor*Object, un thread n'a pas tourné depuis longtemps, etc...). C'est le thread qui a la plus haute priorité une fois ces ajustements fait qui est schedulé...
Arnaud
Vincent Burel wrote:
y'a les interruption matérielles , qui automatiquement arrète la
tache en
cours pour appeller le gestionnaire d'interuption de l'OS ... Ensuite
l'OS
fait ce qu'il veut, par exemple windows le traduit en évènement
qu'il traite
avec la priorité qu'il veut, comme bon lui semble. par exemple pour
gérer le
réseaux, ben dès qu'il y aura une interruption, Windows peut
décider de
traiter tout de suite, ou bien de prendre acte seulement et de
redonner la
main le plus vite possible à la tache interrompu... ca dépend de la
stratégie mis en place par Microsoft... si qqn sait ce qui a été
choisi !
:-) moi j'ai des doutes en fonction du type de périphérique :-)
De manière générale, sous Windows, une ISR (la routine appelée en
réponse à l'interruption) doit en faire le moins possible de façon
à ne pas bloquer longtemps le processeur dans un mode où les autres
interruptions sont masquées. L'ISR en fait donc le minimum puis postes
le reste du travail à faire sous forme d'APC (Asynchronous Procedure
Call) sur un thread donné. L'APC sera traitée la prochaine fois que
le le thread obtiendra un time-slice, mais avant que le thread continue
son exécution "normale". Comme l'a dit AMcD, une seule référence sur
le sujet : le bouquin de Solomon et Russinovitch (au fait, est-ce que
quelqu'un sait si le dernière version apporte beaucoup de nouveautés
par rapport à la 3ème édition ?)
Ensuite y'a l'interruption de la pré-emption par l'OS, qui ne peut
donner un
temps infini à la tache en cours, si celle si n'a pas rendu la main
au bout
d'un certain temps (le quantum), ou par exit, ou par un Sleep, ou par
un
WaitEvent, alors Windows l'interromp et regarde si un autre thread
n'a pas
besoin du processeur...
La préemption du task scheduler se fait aussi via un interruption
matérielle (c'est l'APIC ou une autre horloge matérielle qui
déclenche l'interruption en question à intervalles réguliers). Il y
a aussi des interruptions logicielles, mais le mécanisme de traitement
est le même...
Notons que la stratégie de gestion des resources
processeurs sur les 32 niveau priorités de Thread sous Windows n'est
pas des
plus clair...
C'est très clair (quoiqu'un brin complexe :-) une fois qu'on a lu le
Russinovitch : Chaque thread a une priorité "de base" que Windows peut
ajuster temporairement pour un tas de raisons en cours d'exécution (ex
: une fenêtre reçoit le focus, un thread sort d'un WaitFor*Object, un
thread n'a pas tourné depuis longtemps, etc...).
C'est le thread qui a la plus haute priorité une fois ces ajustements
fait qui est schedulé...
y'a les interruption matérielles , qui automatiquement arrète la
tache en
cours pour appeller le gestionnaire d'interuption de l'OS ... Ensuite
l'OS
fait ce qu'il veut, par exemple windows le traduit en évènement
qu'il traite
avec la priorité qu'il veut, comme bon lui semble. par exemple pour
gérer le
réseaux, ben dès qu'il y aura une interruption, Windows peut
décider de
traiter tout de suite, ou bien de prendre acte seulement et de
redonner la
main le plus vite possible à la tache interrompu... ca dépend de la stratégie mis en place par Microsoft... si qqn sait ce qui a été
choisi !
:-) moi j'ai des doutes en fonction du type de périphérique :-)
De manière générale, sous Windows, une ISR (la routine appelée en réponse à l'interruption) doit en faire le moins possible de façon à ne pas bloquer longtemps le processeur dans un mode où les autres interruptions sont masquées. L'ISR en fait donc le minimum puis postes le reste du travail à faire sous forme d'APC (Asynchronous Procedure Call) sur un thread donné. L'APC sera traitée la prochaine fois que le le thread obtiendra un time-slice, mais avant que le thread continue son exécution "normale". Comme l'a dit AMcD, une seule référence sur le sujet : le bouquin de Solomon et Russinovitch (au fait, est-ce que quelqu'un sait si le dernière version apporte beaucoup de nouveautés par rapport à la 3ème édition ?)
Ensuite y'a l'interruption de la pré-emption par l'OS, qui ne peut
donner un
temps infini à la tache en cours, si celle si n'a pas rendu la main
au bout
d'un certain temps (le quantum), ou par exit, ou par un Sleep, ou par
un
WaitEvent, alors Windows l'interromp et regarde si un autre thread
n'a pas
besoin du processeur...
La préemption du task scheduler se fait aussi via un interruption matérielle (c'est l'APIC ou une autre horloge matérielle qui déclenche l'interruption en question à intervalles réguliers). Il y a aussi des interruptions logicielles, mais le mécanisme de traitement est le même...
Notons que la stratégie de gestion des resources processeurs sur les 32 niveau priorités de Thread sous Windows n'est
pas des
plus clair...
C'est très clair (quoiqu'un brin complexe :-) une fois qu'on a lu le Russinovitch : Chaque thread a une priorité "de base" que Windows peut ajuster temporairement pour un tas de raisons en cours d'exécution (ex : une fenêtre reçoit le focus, un thread sort d'un WaitFor*Object, un thread n'a pas tourné depuis longtemps, etc...). C'est le thread qui a la plus haute priorité une fois ces ajustements fait qui est schedulé...
Arnaud
AMcD®
wrote:
C'est très clair (quoiqu'un brin complexe :-) une fois qu'on a lu le Russinovitch
Ben moi, je n'irai pas jusqu'à dire que c'est lumineux. Certes, le bouquin sus-cité y consacre pas mal de pages mais c'est quand même chaud à comprendre. T'es noyé dans les tables, les figures et 15 concepts par page. Perso, j'ai bien du lire ce chapitre trois ou quatre fois avant d'avoir une vue globale du truc. Mais je me garderai bien de dire que je maîtrise le sujet. Avec mon style d'écriture et de précision, je me vois mal expliquer en détail et simplement la chose en dessous de 100 ou 150 pages. Et encore, je suis modeste. Sérieux, si tu veux faire un truc précis, avec les correspondances dans la base de registres, les implications du kernel (notamment les structures invoquées), les programmes de démonstrations adéquats, tous les termes clairements expliqués, tous les concepts mis à plats, les tests, etc. C'est un livre entier qu'il te faut.
Si t'as pigé l'APC et tout le bazar du premier coup, mes félicitations.
-- AMcD®
http://arnold.mcdonald.free.fr/
adebaene@club-internet.fr wrote:
C'est très clair (quoiqu'un brin complexe :-) une fois qu'on a lu le
Russinovitch
Ben moi, je n'irai pas jusqu'à dire que c'est lumineux. Certes, le bouquin
sus-cité y consacre pas mal de pages mais c'est quand même chaud à
comprendre. T'es noyé dans les tables, les figures et 15 concepts par page.
Perso, j'ai bien du lire ce chapitre trois ou quatre fois avant d'avoir une
vue globale du truc. Mais je me garderai bien de dire que je maîtrise le
sujet. Avec mon style d'écriture et de précision, je me vois mal expliquer
en détail et simplement la chose en dessous de 100 ou 150 pages. Et encore,
je suis modeste. Sérieux, si tu veux faire un truc précis, avec les
correspondances dans la base de registres, les implications du kernel
(notamment les structures invoquées), les programmes de démonstrations
adéquats, tous les termes clairements expliqués, tous les concepts mis à
plats, les tests, etc. C'est un livre entier qu'il te faut.
Si t'as pigé l'APC et tout le bazar du premier coup, mes félicitations.
C'est très clair (quoiqu'un brin complexe :-) une fois qu'on a lu le Russinovitch
Ben moi, je n'irai pas jusqu'à dire que c'est lumineux. Certes, le bouquin sus-cité y consacre pas mal de pages mais c'est quand même chaud à comprendre. T'es noyé dans les tables, les figures et 15 concepts par page. Perso, j'ai bien du lire ce chapitre trois ou quatre fois avant d'avoir une vue globale du truc. Mais je me garderai bien de dire que je maîtrise le sujet. Avec mon style d'écriture et de précision, je me vois mal expliquer en détail et simplement la chose en dessous de 100 ou 150 pages. Et encore, je suis modeste. Sérieux, si tu veux faire un truc précis, avec les correspondances dans la base de registres, les implications du kernel (notamment les structures invoquées), les programmes de démonstrations adéquats, tous les termes clairements expliqués, tous les concepts mis à plats, les tests, etc. C'est un livre entier qu'il te faut.
Si t'as pigé l'APC et tout le bazar du premier coup, mes félicitations.
-- AMcD®
http://arnold.mcdonald.free.fr/
Arnaud Debaene
AMcD® wrote:
wrote:
Si t'as pigé l'APC et tout le bazar du premier coup, mes félicitations.
Il y a vait un smiley, mais pas assez gros apparemment :-) Il est évident que pour comprendre tous les détails, avec les structures utilisées, etc... c'est chaud, mais les grands principes restent compréhensibles.
Arnaud
AMcD® wrote:
adebaene@club-internet.fr wrote:
Si t'as pigé l'APC et tout le bazar du premier coup, mes
félicitations.
Il y a vait un smiley, mais pas assez gros apparemment :-) Il est évident
que pour comprendre tous les détails, avec les structures utilisées, etc...
c'est chaud, mais les grands principes restent compréhensibles.
Si t'as pigé l'APC et tout le bazar du premier coup, mes félicitations.
Il y a vait un smiley, mais pas assez gros apparemment :-) Il est évident que pour comprendre tous les détails, avec les structures utilisées, etc... c'est chaud, mais les grands principes restent compréhensibles.
Arnaud
Aurélien REGAT-BARREL
> De manière générale, sous Windows, une ISR (la routine appelée en réponse à l'interruption) doit en faire le moins possible de façon à ne pas bloquer longtemps le processeur dans un mode où les autres interruptions sont masquées. L'ISR en fait donc le minimum puis postes le reste du travail à faire sous forme d'APC (Asynchronous Procedure Call) sur un thread donné.
C'est pas un DPC plutôt ? De ce que j'ai compris, l'ISR sert à mettre en queue des DPC, qui ont un niveau de privilège supérieur aux APC. Les APC c'est aussi utilisable en user mode, et c'est rattaché à un thread. Or une ISR c'est pas un thread, et un DPC est rattaché à un processeur. L'exécution des DPC est contrôlée par un dispatcher à part, qui s'exécute "à côté" (et même au détriment) du scheduler de threads. Il me semble même que ce dispatcher s'exécute dans le quantum de temps du thread interrompu, volant ainsi à ce dernier du temps d'exécution. Mais bon entre DPC, APC, LPC, RPC, je mélange peut être :-) Sinon une des seules infos sur le sujet de ce thread que j'ai, c'est en français, mais pour NT4: http://www.chez.com/psylon/dev/temps_reel/index.html le site semble être à l'abandon.
-- Aurélien REGAT-BARREL
> De manière générale, sous Windows, une ISR (la routine appelée en
réponse à l'interruption) doit en faire le moins possible de façon
à ne pas bloquer longtemps le processeur dans un mode où les autres
interruptions sont masquées. L'ISR en fait donc le minimum puis postes
le reste du travail à faire sous forme d'APC (Asynchronous Procedure
Call) sur un thread donné.
C'est pas un DPC plutôt ? De ce que j'ai compris, l'ISR sert à mettre en
queue des DPC, qui ont un niveau de privilège supérieur aux APC. Les APC
c'est aussi utilisable en user mode, et c'est rattaché à un thread. Or une
ISR c'est pas un thread, et un DPC est rattaché à un processeur. L'exécution
des DPC est contrôlée par un dispatcher à part, qui s'exécute "à côté" (et
même au détriment) du scheduler de threads. Il me semble même que ce
dispatcher s'exécute dans le quantum de temps du thread interrompu, volant
ainsi à ce dernier du temps d'exécution.
Mais bon entre DPC, APC, LPC, RPC, je mélange peut être :-)
Sinon une des seules infos sur le sujet de ce thread que j'ai, c'est en
français, mais pour NT4:
http://www.chez.com/psylon/dev/temps_reel/index.html
le site semble être à l'abandon.
> De manière générale, sous Windows, une ISR (la routine appelée en réponse à l'interruption) doit en faire le moins possible de façon à ne pas bloquer longtemps le processeur dans un mode où les autres interruptions sont masquées. L'ISR en fait donc le minimum puis postes le reste du travail à faire sous forme d'APC (Asynchronous Procedure Call) sur un thread donné.
C'est pas un DPC plutôt ? De ce que j'ai compris, l'ISR sert à mettre en queue des DPC, qui ont un niveau de privilège supérieur aux APC. Les APC c'est aussi utilisable en user mode, et c'est rattaché à un thread. Or une ISR c'est pas un thread, et un DPC est rattaché à un processeur. L'exécution des DPC est contrôlée par un dispatcher à part, qui s'exécute "à côté" (et même au détriment) du scheduler de threads. Il me semble même que ce dispatcher s'exécute dans le quantum de temps du thread interrompu, volant ainsi à ce dernier du temps d'exécution. Mais bon entre DPC, APC, LPC, RPC, je mélange peut être :-) Sinon une des seules infos sur le sujet de ce thread que j'ai, c'est en français, mais pour NT4: http://www.chez.com/psylon/dev/temps_reel/index.html le site semble être à l'abandon.
-- Aurélien REGAT-BARREL
Aurélien REGAT-BARREL
> continue son exécution "normale". Comme l'a dit AMcD, une seule référence sur le sujet : le bouquin de Solomon et Russinovitch (au fait, est-ce que quelqu'un sait si le dernière version apporte beaucoup de nouveautés par rapport à la 3ème édition ?)
Je me permet de citer un certains AMcD:
> J'hésite à acheter cette 4° édition, diposant de la 3°. Penses-tu que > ça vaille le coup ?
Pour moi oui. C'est sacrément actualisé quand même. J'ai attaqué la lecture méthodique page par page, pas mal de trucs on changé. C'est sûr que certains chapitres n'ont pas du trop bouger vu que de 2K à 2K3, il y a quand même pas eu des millions de bouleversements. 100 pages de plus, un nouveau chapitre, actualisé... Ce qui est pénible peut-être c'est quand fait c'est des petits paragraphes par ci, par là qui ont été rajoutés. Une note sur XP, une remarque sur 2K3, une modification de figure, etc. etc. Une actualisation quoi. Au premier coup d'oeil tu peux te dire bof, mais en lisant, tu vois bien les changements apportés. Pour 40 euros, moi je dis, très très intéressant. Surtout qu'a 40 euros aujourd'hui, t'as vraiment pas grand chose en bouquin ! Au pire case la 3e edition à un administratuer 2K ;-)
:-)
-- Aurélien REGAT-BARREL
> continue son exécution "normale". Comme l'a dit AMcD, une seule
référence sur le sujet : le bouquin de Solomon et Russinovitch (au
fait, est-ce que quelqu'un sait si le dernière version apporte
beaucoup de nouveautés par rapport à la 3ème édition ?)
Je me permet de citer un certains AMcD:
> J'hésite à acheter cette 4° édition, diposant de
la 3°. Penses-tu que
> ça vaille le coup ?
Pour moi oui. C'est sacrément actualisé quand même.
J'ai attaqué la lecture
méthodique page par page, pas mal de trucs on
changé. C'est sûr que certains
chapitres n'ont pas du trop bouger vu que de 2K à
2K3, il y a quand même pas
eu des millions de bouleversements. 100 pages de
plus, un nouveau chapitre,
actualisé... Ce qui est pénible peut-être c'est
quand fait c'est des petits
paragraphes par ci, par là qui ont été rajoutés. Une
note sur XP, une
remarque sur 2K3, une modification de figure, etc.
etc. Une actualisation
quoi. Au premier coup d'oeil tu peux te dire bof,
mais en lisant, tu vois
bien les changements apportés. Pour 40 euros, moi je
dis, très très
intéressant. Surtout qu'a 40 euros aujourd'hui, t'as
vraiment pas grand
chose en bouquin ! Au pire case la 3e edition à un
administratuer 2K ;-)
> continue son exécution "normale". Comme l'a dit AMcD, une seule référence sur le sujet : le bouquin de Solomon et Russinovitch (au fait, est-ce que quelqu'un sait si le dernière version apporte beaucoup de nouveautés par rapport à la 3ème édition ?)
Je me permet de citer un certains AMcD:
> J'hésite à acheter cette 4° édition, diposant de la 3°. Penses-tu que > ça vaille le coup ?
Pour moi oui. C'est sacrément actualisé quand même. J'ai attaqué la lecture méthodique page par page, pas mal de trucs on changé. C'est sûr que certains chapitres n'ont pas du trop bouger vu que de 2K à 2K3, il y a quand même pas eu des millions de bouleversements. 100 pages de plus, un nouveau chapitre, actualisé... Ce qui est pénible peut-être c'est quand fait c'est des petits paragraphes par ci, par là qui ont été rajoutés. Une note sur XP, une remarque sur 2K3, une modification de figure, etc. etc. Une actualisation quoi. Au premier coup d'oeil tu peux te dire bof, mais en lisant, tu vois bien les changements apportés. Pour 40 euros, moi je dis, très très intéressant. Surtout qu'a 40 euros aujourd'hui, t'as vraiment pas grand chose en bouquin ! Au pire case la 3e edition à un administratuer 2K ;-)
