Je reconnais que c'est hors sujet et je m'en excuse ;-)

On Thu, 26 Jul 2007 06:17:16 -0700, James Kanze
<james.kanze@gmail.com>:

une fenêtre « commande prompte » (drôle de nom),

Je ne sais pas où tu as été pêcher cette francisation, mais l'original
est "command prompt" (et la traduction en français "invite de
commande").
Ça désigne les quelques caractères (suivant l'OS et le paramétrage,
ils peuvent contenir un #, un > ou un $, avec le nom d'utilisateur ou
le nom de répertoire), placés juste avant le curseur, et qui
t'invitent à taper une commande.
Désigner le fenêtre de console par ce terme n'est pas absurde, car le
prompt est absent de l'interface GUI.

James Kanze wrote on 26/07/2007 15:17:

On Jul 25, 10:24 pm, Sylvain <noS...@mail.net> wrote:

James Kanze wrote on 25/07/2007 11:18:

Si c'est l'IDE qui démarre son programme, il ne doit pas y avoir
de problème, parce qu'il exécute sous l'IDE, dans un
environement définit par l'IDE. L'IDE capture les sorties
standard, et les affiche dans une fenêtre de l'IDE dédiée à ça.

non, pas pour Studio sous Windows en tout cas.

Ce n'est donc pas un environement integré, puisque pouvoir faire
exécuter le programme sous un environement contrôlé me semble
une fonctionalité fondamentale du développement:-).

toujours aussi nuancé ! ;)

trancher sur le fait que ce "c'est un IDE" ou "ce n'est pas un IDE" sur
la seule gestion d'une console est, à mes yeux, plus que léger.
depuis des lustres je considère que Studio ou Eclipse sont des IDE, et
que g++,gdb ou MPW et ses tools ne sont pas des IDE.

Ou peut-être
ils trouvaient simplement que de changer vers une fenêtre
« commande prompte » (drôle de nom), et d'exécuter le
programme là, était tellement simple sous Windows qu'on n'avait
pas besoin d'offrir plus.

ton a priori biaise ton appréciation.
Windows n'est PAS un système basé sur des shell, un programme ""normal""
("en charte") n'utilise jamais une console.
Unix est un OS basé sur des shell (avec bien sur des serveurs X qui
existait bien avant que Windows ne sache dessiner correctement un bouton).

la console qui capture les entrées/sorties dans programme mode console
n'est pas un shell - ni l'OS, ni l'IDE ne lance un shell (pas de bash ni
rien de ressemblant); c'est juste une fenêtre (dépendante du CRT!) qui
capture au vol se qui est envoyé sur les IO standards (cin, cout, ...).

lorsque le même programme est lancé depuis un interpréteur, ces IO (cin,
cout, ...) sont (par défaut) redirigés sur cet interpréteur (comem pour
un shell unix).

plus que l'environ.t de dév. j'aurais dis que c'est le CRT utilisé qui
peut conditionner la façon dont un programme se lance et s'arrête.

Je ne comprends pas trop. J'aurais pensé que quand on parle du
lancement, on parle de ce qui se fait avant que le programme se
démarre. Donc, de quelque chose qui est indépendant du CRT.

Suite à des discussions dans comp.lang.c++, Alf Steinbach m'a
renvoyé à un papier excellent
(http://home.no.net/dubjai/win32apitut/01.pdf) qu'il a écrit.
D'après ce que j'ai bien compris de ce papier, l'éditeur de lien
ajoute un attribute (appelée « subsystem ») au fichier .exe,
que le système utilise pour faire certains choix :

oui c'est un des attributs du format PEM.
ce flag conditionne complètement les IO du prog.; si c'est un prog
console une fenêtre s'ouvrira au premier output ou saisie; à l'inverse
si c'est un programme avec GUI, toutes les IO standards (j'entends cout,
printf, etc) iront nulle part et ne seront pas affichés.

l'interprêteur de commande attend la fin du programme ou non

non puisque ce n'est pas "l'interpréteur" mais une fenêtre texte
(identique à celle utilisée par cet interpréteur) - la différence est
qu'aucun shell n'a lancé se programme et n'est là pour temporiser à la fin.

(C'est une autre philosophie que Unix, où c'est à l'utilisateur
de préciser chaque fois.)

une différence importance est l'héritage de l'environment sous unix, un
processus fils héritant de l'env. du shell et les sous-processus du
parent; cela n'existe quasiment pas sous Windows, à tout le moin scela
n'a pas la même philosophie.

A priori, je supposerais que cette
attribute serait disponible à n'importe quel logiciel qui
voulait lancer un programme. Donc, à IDE, qui pourrait alors
prend ces avants, pour que l'information ne se perd jamais.

tu supposes ici que "l'attribut" dispose de nombres d'option, ce n'est
pas le cas - il contient juste mode console ou mode GUI.

sous Windows, en mode console, le programme est lancé dans un
""shell"" totalement (heureusement) distinct de l'IDE.

Le problème n'est pas où le programme est lancé. Le problème,
c'est d'une part, l'environement qu'on lui fournit, et de
l'autre, où arrive cout et cerr. Le programme même, ne sait pas
qui l'a lancé (et il se peut bien que l'IDE Sun se sert d'un
shell pour le lancer).

par "où" j'entendais "dans quel contexte", ce que tu décris.

je répète, un prog console se voit greffer une console qui redirige cin
et cout parce que le CRT de ce programme contient (au final) des printf
qui a) s'assure qu'une fenêtre console est ouverte, b) utilise cette
fenêtre.
un prog. GUI utilise un CRT où (au final) printf n'écrit rien, nul part.

Quelle est la différence ? Le shell n'est qu'un programme, qui
tourne dans une fenêtre (un xterm, sur mes Unix). Que les
fonctionnalités du terminal soient fournies par le programme
xterm, ou par le programme sun-studio, que le programme soit
lancé par un programme qui s'appelle bash ou ksh, ou qui
s'appelle sun-studio, qu'est-ce que ça change pour le
programme ?

ce qui change est que Windows ne dispose ni de xterm, ni de shell, ni
rien de comparable - je ne caricature pas en disant que unix est un OS
texte qui sait afficher des fenêtres tandis que Windows serait un
systèpe pur graphique (la cuisine interne n'est pas du tout cela) mais
cela se comporte malgré tout ainsi.

les CRT MS mode console n'incluent aucun "pause" en fin d'exécution...

Qui a ouvert la fenêtre ? Pas le CRT, je crois. Et qui le
ferme ? Pas le CRT non plus ; elle ne se ferme pas si je lance
le programme à la main dans une fenêtre terminal.

Cf ci-avant.

J'avoue que je ne me sert du debuggueur pratiquement que pour
les post mortem. Mais je ne vois pas l'intérêt de ne pas avoir
une fenêtre ou une sous-fenêtre avec les sorties standard.

personne a dit qu'il n'y avait pas d'intérêt.

pour tracer dans la sous-fenêtre de l'IDE un code Windows doit utiliser
OutputDebugString (API système hooké par l'IDE durant l'exécution du
programme sou sson contrôle) mais pas printf; s'il le fait ses IO ne
sont pas gérés par l'IDE et il doit s'assurer tout seul que sa console
ne disparait pas trop vite (comme un prog. GUI doit s'assurer tout seul
que ses fenêtres sont au bon endroit, l'IDE ne le fera pas pour lui).

je ne parlerais pas de régression mais de mode de fonctionnement.
et pour de trop récents clicodromes de développement qui redirigeraient
abusivement toutes les IO, je parlerais d'obfuscation nuisible.

Qui redirigeraient quoi ?

cin, cout, cerr

Les sorties standard doivent toujours
aboutir quelque part.

"/dev/null" pour un prog. Windows ""normal"".

Sylvain.

Sylvain wrote:

James Kanze wrote on 26/07/2007 15:17:

On Jul 25, 10:24 pm, Sylvain <noS...@mail.net> wrote:

James Kanze wrote on 25/07/2007 11:18:

Si c'est l'IDE qui démarre son programme, il ne doit pas y avoir
de problème, parce qu'il exécute sous l'IDE, dans un
environement définit par l'IDE. L'IDE capture les sorties
standard, et les affiche dans une fenêtre de l'IDE dédiée à ça.

non, pas pour Studio sous Windows en tout cas.

Ce n'est donc pas un environement integré, puisque pouvoir faire
exécuter le programme sous un environement contrôlé me semble
une fonctionalité fondamentale du développement:-).

toujours aussi nuancé ! ;)

trancher sur le fait que ce "c'est un IDE" ou "ce n'est pas un IDE" sur
la seule gestion d'une console est, à mes yeux, plus que léger.
depuis des lustres je considère que Studio ou Eclipse sont des IDE, et
que g++,gdb ou MPW et ses tools ne sont pas des IDE.

Ou peut-être
ils trouvaient simplement que de changer vers une fenêtre
« commande prompte » (drôle de nom), et d'exécuter le
programme là, était tellement simple sous Windows qu'on n'avait
pas besoin d'offrir plus.

ton a priori biaise ton appréciation.
Windows n'est PAS un système basé sur des shell, un programme ""normal""
("en charte") n'utilise jamais une console.
Unix est un OS basé sur des shell (avec bien sur des serveurs X qui
existait bien avant que Windows ne sache dessiner correctement un bouton).

la console qui capture les entrées/sorties dans programme mode console
n'est pas un shell - ni l'OS, ni l'IDE ne lance un shell (pas de bash ni
rien de ressemblant); c'est juste une fenêtre (dépendante du CRT!) qui
capture au vol se qui est envoyé sur les IO standards (cin, cout, ...).

lorsque le même programme est lancé depuis un interpréteur, ces IO (cin,
cout, ...) sont (par défaut) redirigés sur cet interpréteur (comem pour
un shell unix).

plus que l'environ.t de dév. j'aurais dis que c'est le CRT utilisé qui
peut conditionner la façon dont un programme se lance et s'arrête.

Je ne comprends pas trop. J'aurais pensé que quand on parle du
lancement, on parle de ce qui se fait avant que le programme se
démarre. Donc, de quelque chose qui est indépendant du CRT.

Suite à des discussions dans comp.lang.c++, Alf Steinbach m'a
renvoyé à un papier excellent
(http://home.no.net/dubjai/win32apitut/01.pdf) qu'il a écrit.
D'après ce que j'ai bien compris de ce papier, l'éditeur de lien
ajoute un attribute (appelée « subsystem ») au fichier .exe,
que le système utilise pour faire certains choix :

oui c'est un des attributs du format PEM.
ce flag conditionne complètement les IO du prog.; si c'est un prog
console une fenêtre s'ouvrira au premier output ou saisie; à l'inverse
si c'est un programme avec GUI, toutes les IO standards (j'entends cout,
printf, etc) iront nulle part et ne seront pas affichés.

l'interprêteur de commande attend la fin du programme ou non

non puisque ce n'est pas "l'interpréteur" mais une fenêtre texte
(identique à celle utilisée par cet interpréteur) - la différence est
qu'aucun shell n'a lancé se programme et n'est là pour temporiser à la fin.

(C'est une autre philosophie que Unix, où c'est à l'utilisateur
de préciser chaque fois.)

une différence importance est l'héritage de l'environment sous unix, un
processus fils héritant de l'env. du shell et les sous-processus du
parent; cela n'existe quasiment pas sous Windows, à tout le moin scela
n'a pas la même philosophie.

A priori, je supposerais que cette
attribute serait disponible à n'importe quel logiciel qui
voulait lancer un programme. Donc, à IDE, qui pourrait alors
prend ces avants, pour que l'information ne se perd jamais.

tu supposes ici que "l'attribut" dispose de nombres d'option, ce n'est
pas le cas - il contient juste mode console ou mode GUI.

sous Windows, en mode console, le programme est lancé dans un
""shell"" totalement (heureusement) distinct de l'IDE.

Le problème n'est pas où le programme est lancé. Le problème,
c'est d'une part, l'environement qu'on lui fournit, et de
l'autre, où arrive cout et cerr. Le programme même, ne sait pas
qui l'a lancé (et il se peut bien que l'IDE Sun se sert d'un
shell pour le lancer).

par "où" j'entendais "dans quel contexte", ce que tu décris.

je répète, un prog console se voit greffer une console qui redirige cin
et cout parce que le CRT de ce programme contient (au final) des printf
qui a) s'assure qu'une fenêtre console est ouverte, b) utilise cette
fenêtre.
un prog. GUI utilise un CRT où (au final) printf n'écrit rien, nul part.

Quelle est la différence ? Le shell n'est qu'un programme, qui
tourne dans une fenêtre (un xterm, sur mes Unix). Que les
fonctionnalités du terminal soient fournies par le programme
xterm, ou par le programme sun-studio, que le programme soit
lancé par un programme qui s'appelle bash ou ksh, ou qui
s'appelle sun-studio, qu'est-ce que ça change pour le
programme ?

ce qui change est que Windows ne dispose ni de xterm, ni de shell, ni
rien de comparable - je ne caricature pas en disant que unix est un OS
texte qui sait afficher des fenêtres tandis que Windows serait un
systèpe pur graphique (la cuisine interne n'est pas du tout cela) mais
cela se comporte malgré tout ainsi.

les CRT MS mode console n'incluent aucun "pause" en fin d'exécution...

Qui a ouvert la fenêtre ? Pas le CRT, je crois. Et qui le
ferme ? Pas le CRT non plus ; elle ne se ferme pas si je lance
le programme à la main dans une fenêtre terminal.

Cf ci-avant.

J'avoue que je ne me sert du debuggueur pratiquement que pour
les post mortem. Mais je ne vois pas l'intérêt de ne pas avoir
une fenêtre ou une sous-fenêtre avec les sorties standard.

personne a dit qu'il n'y avait pas d'intérêt.

pour tracer dans la sous-fenêtre de l'IDE un code Windows doit utiliser
OutputDebugString (API système hooké par l'IDE durant l'exécution du
programme sou sson contrôle) mais pas printf; s'il le fait ses IO ne
sont pas gérés par l'IDE et il doit s'assurer tout seul que sa console
ne disparait pas trop vite (comme un prog. GUI doit s'assurer tout seul
que ses fenêtres sont au bon endroit, l'IDE ne le fera pas pour lui).

je ne parlerais pas de régression mais de mode de fonctionnement.
et pour de trop récents clicodromes de développement qui redirigeraient
abusivement toutes les IO, je parlerais d'obfuscation nuisible.

Qui redirigeraient quoi ?

cin, cout, cerr

Les sorties standard doivent toujours
aboutir quelque part.

"/dev/null" pour un prog. Windows ""normal"".

Sylvain.

Avec des bibliothèques comme la SDL, qui n'est pas des plus
"professionnelles", stdout.txt et stderr.txt sont créés et toute sortie
vers cout ou cerr respectivement sont redirigées dans ces fichiers.
Cela arrive avec quelques autres, dont je n'ai plus le nom.

On Fri, 27 Jul 2007 03:15:35 +0200, Alp Mestan <alpmestan@free.fr>:

[...]

Évite de recopier les 150 lignes d'un message juste pour ajouter
quelques lignes !

Je t'invite à lire d'urgence la page
<http://www.usenet-fr.net/fr.usenet.reponses/usenet/repondre-sur-usenet.html>.

On Jul 26, 5:19 pm, Fabien LE LEZ <grams...@gramster.com> wrote:

On Thu, 26 Jul 2007 06:17:16 -0700, James Kanze
<james.ka...@gmail.com>:

une fenêtre « commande prompte » (drôle de nom),

Je ne sais pas où tu as été pêcher cette francisation, mais l'ori ginal
est "command prompt" (et la traduction en français "invite de
commande").

C'est que la version de Windows ici au travail est anglaise, et
que je copiait l'original. Sauf qu'automatiquement, puisque
j'écrivais en français, je l'ai orthographié en français. (Ne me
rappelant pas la traduction en français, j'ai préféré donner
exactement ce que je lisais sur mon écran. Seulement, mes doigts
m'ont trompé.)

Ça désigne les quelques caractères (suivant l'OS et le paramétrag e,
ils peuvent contenir un #, un > ou un $, avec le nom d'utilisateur ou
le nom de répertoire), placés juste avant le curseur, et qui
t'invitent à taper une commande.

Je sais ce que sait qu'un « prompt », oui:-).

Désigner le fenêtre de console par ce terme n'est pas absurde, car le
prompt est absent de l'interface GUI.

Et « console » a une autre signification sous Unix (et sous
d'autres OS aussi -- le « console », c'est un terminal
privilégé). Beaucoup d'unixiens dirait une fenêtre tty,
je crois. Je crois que la terme « consacrée », c'est
« terminal window », mais c'est possible aussi que ce soit un
X'isme -- sur les anciens Sun, on avait des « command tool »
(et des « shell tool », mais ça, c'est clairement un
Unix'isme). Personellement, j'aime bien le nom de pseudo-tty
pour de telles fenêtres, mais je ne crois pas qu'il soit compris
en dehors de Unix, voire même en dehors des programmeurs système
sous Unix.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jul 26, 11:47 pm, Sylvain <noS...@mail.net> wrote:

James Kanze wrote on 26/07/2007 15:17:

On Jul 25, 10:24 pm, Sylvain <noS...@mail.net> wrote:

James Kanze wrote on 25/07/2007 11:18:

Si c'est l'IDE qui démarre son programme, il ne doit pas y avoir
de problème, parce qu'il exécute sous l'IDE, dans un
environement définit par l'IDE. L'IDE capture les sorties
standard, et les affiche dans une fenêtre de l'IDE dédiée à ça.

non, pas pour Studio sous Windows en tout cas.

Ce n'est donc pas un environement integré, puisque pouvoir faire
exécuter le programme sous un environement contrôlé me semble
une fonctionalité fondamentale du développement:-).

toujours aussi nuancé ! ;)

J'ai bien mis l'émoticon pour une raison. C'est que je ne tenais
absolument pas à ce qu'on me prend au sérieux.

trancher sur le fait que ce "c'est un IDE" ou "ce n'est pas un
IDE" sur la seule gestion d'une console est, à mes yeux, plus
que léger.

Je suis tout à fait d'accord. Ce qui ne m'empèche pas un petit
essai humoristique.

depuis des lustres je considère que Studio ou Eclipse sont des
IDE, et que g++,gdb ou MPW et ses tools ne sont pas des IDE.

Je serais probablement d'accord. J'utilise l'environement Unix
(tout l'environement) comme un IDE, mais l'integration, c'est
dans ma tête. En revanche, la puissance en est incroyable, et je
me sens très limité quand je ne l'ai pas à ma disposition.

Ou peut-être
ils trouvaient simplement que de changer vers une fenêtre
« commande prompte » (drôle de nom), et d'exécuter le
programme là, était tellement simple sous Windows qu'on n'avait
pas besoin d'offrir plus.

ton a priori biaise ton appréciation.
Windows n'est PAS un système basé sur des shell, un programme ""norma l""
("en charte") n'utilise jamais une console.

Je ne suis pas sûr ce que tu entends par « programme
normale ». Il y a beaucoup de types de programmes, des
serveurs, des applications à interface graphique, des
utilitiaires... Aucun programme C++ que j'ai jamais écrit
utilise une « console » (ni un terminal quelconque). Dans mon
cas, les seuls programmes qui utilisent un shell, ce sont des
scripts de shell.

Le fait que un programme n'utilise pas le shell n'exclut pas
qu'il puisse être invoqué depuis un shell. Et ça m'étonnerait
que des .bat ne servent pas sous Windows ; ils servent ici, au
moins, pas mal.

Et enfin, si je veux tester un programme, ce n'est pas mal de
l'invoquer depuis un shell. (On peut invoquer n'importe quel
programme Windows depuis un shell.)

Unix est un OS basé sur des shell (avec bien sur des serveurs X qui
existait bien avant que Windows ne sache dessiner correctement un bouton).

Unix est un OS. Il s'avère que sous cet OS, il y a des
programmes d'interprêtation de commande dont on peut se servir,
et que la tradition est de s'en servir, pour combiner des
programmes existants, plutôt que d'écrire de nouveaux
programmes. Mais si je régarde sur mes machines Windows, il y a
pas mal de fichiers .bat aussi. Il doit y être pour une raison.
(Et avant ça, il y avait des JCL sur les IBM. Si j'avais à
comparer, les JCL, c'est l'assembleur, l'interprêteur de
commande par défaut sous Windows, c'est un langage évolué de la
première génération, et les shells d'Unix, c'est à peu près le
niveau de C.)

la console qui capture les entrées/sorties dans programme mode console
n'est pas un shell - ni l'OS, ni l'IDE ne lance un shell (pas de bash ni
rien de ressemblant); c'est juste une fenêtre (dépendante du CRT!) qui
capture au vol se qui est envoyé sur les IO standards (cin, cout, ...).

Certes. Comme sous Unix. C'est ce que je disais. Donc, l'IDE
pourrait le faire aussi bien. Il suffit qu'il capture les
sorties (et éventuellement fournir une possibilités des
entrées) et les afficher quelque part.

lorsque le même programme est lancé depuis un interpréteur, ces IO (cin,
cout, ...) sont (par défaut) redirigés sur cet interpréteur (comem pour
un shell unix).

Ce n'est pas comme ça que ça se passe sous Unix. Au moins de le
démander exprès, les entrées/sorties ne sont pas redirigés par
le shell ; le programme « hérite » les entrées/sorties du
shell. Si le shell tourne dans un xterm, les entrées/sorties
sont connectées au « pseudo-tty » fournit par l'xterm. (Au
fond, même le shell ne sait pas qu'il tourne dans un xterm.)

C'est possible aussi de lancer un xterm avec n'importe quel
programme, et non seulement un shell. Qu'on le fasse, et l'xterm
ferme la fenêtre dès que le programme termine. Exactement comme
sous Windows, en fait. Un IDE sous Unix pourrait très bien
lancer ses applications sous un xterm. Mais pourquoi, en
général ? (Il y a des cas précis où l'absense d'un xterm nuit.
Si le programme cherche à gérer l'écran complet, par exemple.
Mais de nos jours... Un programme qui veut dépasser la ligne de
commande en interactif utilise une interface graphique, et ne
s'amuse pas avec des positionnement de cursor, etc., dans un
fenêtre tty.)

plus que l'environ.t de dév. j'aurais dis que c'est le CRT utilisé qui
peut conditionner la façon dont un programme se lance et s'arrête.

Je ne comprends pas trop. J'aurais pensé que quand on parle du
lancement, on parle de ce qui se fait avant que le programme se
démarre. Donc, de quelque chose qui est indépendant du CRT.

Suite à des discussions dans comp.lang.c++, Alf Steinbach m'a
renvoyé à un papier excellent
(http://home.no.net/dubjai/win32apitut/01.pdf) qu'il a écrit.
D'après ce que j'ai bien compris de ce papier, l'éditeur de lien
ajoute un attribute (appelée « subsystem ») au fichier .exe,
que le système utilise pour faire certains choix :

oui c'est un des attributs du format PEM.

Le format PEM, c'est comme le format a.out sous Unix ? (C-à-d
le format normal d'un fichier binaire exécutable.)

ce flag conditionne complètement les IO du prog.; si c'est un prog
console une fenêtre s'ouvrira au premier output ou saisie; à l'inverse
si c'est un programme avec GUI, toutes les IO standards (j'entends cout,
printf, etc) iront nulle part et ne seront pas affichés.

Mais qui fait tout ça ? Le programme qui lance le programme,
non ? Ou est-ce que le comportement de la fonction standard
system(), ou de la fonction CreateProcess() va faire quelque
chose de différent ?

Prenons un cas concret : j'écris un programme interactif (donc,
avec interface graphique). À un moment donné, suite à une
commande de l'utilisateur (clique sur un bouton), le programme
veut imprimer une lettre à envoyer à un client. Évidemment,
c'est un programme à part qui s'occupe de formatter les données
dans une lettre et l'envoyer sur l'imprimante ; mon programme
se contente d'écrire des données dans un fichier temporaire, et
d'invoquer ce deuxième programme avec le nom du fichier. (C'est
un scénario assez fréquent, j'imagine.) Et ce deuxième
programme, évidemment, n'a aucun besoin d'une interface
graphique ou d'autre. Maintenant, d'après ce que j'ai compris
jusqu'ici, ce deuxième programme serait une application console
(parce qu'il n'a pas de GUI). J'espère quand même que quand
j'invoque CreateProcess pour le lancer, que le système ne va pas
ouvrir une fenêtre « invite à la commande ».

l'interprêteur de commande attend la fin du programme ou non

non puisque ce n'est pas "l'interpréteur" mais une fenêtre texte
(identique à celle utilisée par cet interpréteur) - la différence est
qu'aucun shell n'a lancé se programme et n'est là pour temporiser à la fin.

OK. J'ai compris.

Mais alors, quel est l'avantage de faire comme ça, par rapport à
simplement recupérer les sorties soi-même et les afficher
quelque part. Est-ce que c'est à cause des « code pages », ou
les positionnements de cursor, etc., possible ?

(C'est une autre philosophie que Unix, où c'est à l'utilisateur
de préciser chaque fois.)

une différence importance est l'héritage de l'environment sous unix, un
processus fils héritant de l'env. du shell et les sous-processus du
parent; cela n'existe quasiment pas sous Windows, à tout le moin scela
n'a pas la même philosophie.

D'où est-ce qu'un processus hérite son environement, alors ?
Selon la documentation Microsoft : « By default, a child
process inherits a copy of the environment block of the parent
process. » Ça ressemble bien à ce que je connais d'Unix. (En
fait, sous Unix, dans la fonction de base de création d'un
nouveau processus, execve, on précise l'environement ; on peut
passer ce qu'on veut. Mais la convention est bien de passer son
propre environement, et il existe des formes d'exec simplifier
qui le font automatiquement.)

A priori, je supposerais que cette
attribute serait disponible à n'importe quel logiciel qui
voulait lancer un programme. Donc, à IDE, qui pourrait alors
prend ces avants, pour que l'information ne se perd jamais.

tu supposes ici que "l'attribut" dispose de nombres d'option, ce n'est
pas le cas - il contient juste mode console ou mode GUI.

Le nombre des possibilités n'est pas la question. (Aussi, j'ai
appris depuis que dans la passée, il y en avait plus, et que les
options était bien différentes : posix et os2.)

sous Windows, en mode console, le programme est lancé dans un
""shell"" totalement (heureusement) distinct de l'IDE.

Le problème n'est pas où le programme est lancé. Le problème,
c'est d'une part, l'environement qu'on lui fournit, et de
l'autre, où arrive cout et cerr. Le programme même, ne sait pas
qui l'a lancé (et il se peut bien que l'IDE Sun se sert d'un
shell pour le lancer).

par "où" j'entendais "dans quel contexte", ce que tu décris.

je répète, un prog console se voit greffer une console qui redirige c in
et cout parce que le CRT de ce programme contient (au final) des printf
qui a) s'assure qu'une fenêtre console est ouverte, b) utilise cette
fenêtre.
un prog. GUI utilise un CRT où (au final) printf n'écrit rien, nul pa rt.

Il faudra que je régarde de plus près, mais une chose est
certaine : j'ai écrit des programmes dite « console », et le
CRT ne m'ouvre pas un nouveau fenêtre console quand je les
invoque. (Et ce que tu dis contradit ce que m'a dit Alf
Steinbach et Jerry Coffin dans le groupe anglophone.)

Quelle est la différence ? Le shell n'est qu'un programme, qui
tourne dans une fenêtre (un xterm, sur mes Unix). Que les
fonctionnalités du terminal soient fournies par le programme
xterm, ou par le programme sun-studio, que le programme soit
lancé par un programme qui s'appelle bash ou ksh, ou qui
s'appelle sun-studio, qu'est-ce que ça change pour le
programme ?

ce qui change est que Windows ne dispose ni de xterm, ni de shell, ni
rien de comparable -

Et c'est quoi, la fenêtre « invite à la commande » ? Et c'est
quoi qui interprête les fichiers .bat ? Ils me semblent jouer
exactement le même rôle sous Windows que xterm et shell sous
Unix.

je ne caricature pas en disant que unix est un OS
texte qui sait afficher des fenêtres tandis que Windows serait un
système pur graphique (la cuisine interne n'est pas du tout cela) mais
cela se comporte malgré tout ainsi.

Que le GUI de Windows soit plus integré dans le système que le
GUI de Unix, je sais bien. Mais il y a quand même énormement de
similarités entre les deux systèmes. Tous les deux supportent
des applications qui utilise une GUI, et celles qui le
l'utilisent pas. Tous les deux ont des scripts, qu'ils utilisent
aussi pour configurer les fonctionalités système. Tous les deux
supportent le lancement automatique des programmes, soit à
l'initialisation, soit à une heure programmée. Tous les deux
permettent une gestion centralisée des machines en reseau. C-à-d
la possibilité de modifier la configuration et d'exécuter des
programmes à partir d'une machine distante, sans avoir accès à
la GUI locale.

Microsoft, au moins, prétend qu'on peut se servir de Windows
comme serveur, et d'après ce que j'entends dire, il y a des gens
qui le font. Qui dit serveur dit une machine qui tourne sans
qu'il y ait quelqu'un devant l'écran.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze wrote on 27/07/2007 09:53:

ton a priori biaise ton appréciation.
Windows n'est PAS un système basé sur des shell, un programme ""normal""
("en charte") n'utilise jamais une console.

Je ne suis pas sûr ce que tu entends par « programme
normale ». Il y a beaucoup de types de programmes, des
serveurs, des applications à interface graphique, des
utilitiaires...

j'entendais "en charte" avec la charte graphique de l'OS.

bien sur que différents types de programmes ont besoin de différents
types d'interface / d'interaction - je ne les qualifiais pas, je disais
seulement que les outils de dev. pour Windows sont plus orientés vers la
construction d'applis avec GUI windows (par exemple comme cité Studio
n'interagit pas avec la console hôte d'un programme).

pour poursuivre la liste de ces petites différences qui rendent les
choses très différentes, un daemon unix utilisera souvent des logs, et
des programmes connexes à ce daemon permettront de le redémarrer /
stopper, d'analyser ces logs, etc.
sous Windows, une appli type serveur aura souvent son control panel ou
sa fenêtre de configuration (généralement réduite dans la systray), si
l'appli est complètement faceless, elle loguera ses info dans les listes
systèmes d'évènements; tout ceci n'est pas une obligeation, mais le
conformisme est souvent de règle sous Windows.

Le fait que un programme n'utilise pas le shell n'exclut pas
qu'il puisse être invoqué depuis un shell. Et ça m'étonnerait
que des .bat ne servent pas sous Windows ; ils servent ici, au
moins, pas mal.

un batch réponds à d'autres règles (puisque qu'il est nécessairement
interprété par le shell qui le lance); je parlais ici d'exécutables
compilés.

à nouveau, unix fera exactement ce que l'utilisateur demande ('&' a une
conséquence lors d'un lancement depuis un shell).
windows ne fera qu'en fonction du type de programme; si c'est une appli
avec GUI, un lancement depuis l'invite de commande est strictement
identique à un clic sur ce programme et donc l'interpréteur rends
aussitôt la main; si c'est un prog console, la fenêtre de l'interpréteur
est utilisée ou une fenêtre similaire est adjointe si le prog. est lancé
par clic / scheduler / etc.

Et enfin, si je veux tester un programme, ce n'est pas mal de
l'invoquer depuis un shell. (On peut invoquer n'importe quel
programme Windows depuis un shell.)

"invoquer", si cela ne signifie que démarrer, oui.
pour autant on ne garde aucun contrôle sur les progs non console lancé
depuis le shell (ni la boite "Exécuter", ni le scheduler, ...)

Unix est un OS basé sur des shell (avec bien sur des serveurs X qui
existait bien avant que Windows ne sache dessiner correctement un bouton).

Unix est un OS. Il s'avère que sous cet OS, il y a des
programmes d'interprêtation de commande dont on peut se servir,
et que la tradition est de s'en servir, pour combiner des
programmes existants, plutôt que d'écrire de nouveaux
programmes.

tout à fait d'accord - également d'accord avec ton raccourci: unix est
un IDE en soi.

Mais si je régarde sur mes machines Windows, il y a
pas mal de fichiers .bat aussi. Il doit y être pour une raison.

il y a en très très peu - un développeur peux bien sur en créer pour
automatiser qlq taches mais le système ne les utilise quasiment plus; de
plus leur syntaxe a tjrs été très pauvre comparé aux scripts shell unix
(ou à l'interpréteur d'OS/2).

la console qui capture les entrées/sorties dans programme mode console
n'est pas un shell - ni l'OS, ni l'IDE ne lance un shell (pas de bash ni
rien de ressemblant); c'est juste une fenêtre (dépendante du CRT!) qui
capture au vol se qui est envoyé sur les IO standards (cin, cout, ...).

Certes. Comme sous Unix. C'est ce que je disais. Donc, l'IDE
pourrait le faire aussi bien. Il suffit qu'il capture les
sorties (et éventuellement fournir une possibilités des
entrées) et les afficher quelque part.

il pourrait peut être, ce que j'indiquais par mon point précédent est
que cela ne correspond pas à une façon "naturelle" (privilégiée) sous
Windows, donc la plupart des IDE ne s'embettent pas avec cela (ils
fournissent néanmoins un CRT capable d'interfacer une console en cas de
besoin - en fait c'est plus compliqué, le CRT lui-même ne contient pas
cette console (la fenêtre, la gestion du clavier, etc) il utilise des
routnies systèmes pour rediriger une fois pour toutes les IO; même une
appli avec GUI peut faire apparaître une console et l'utiliser
(WriteConsole etc) mais je connais peu de cas ou cela vaut la peine
d'être utilisé.

Suite à des discussions dans comp.lang.c++, Alf Steinbach m'a
renvoyé à un papier excellent
(http://home.no.net/dubjai/win32apitut/01.pdf) qu'il a écrit.
D'après ce que j'ai bien compris de ce papier, l'éditeur de lien
ajoute un attribute (appelée « subsystem ») au fichier .exe,
que le système utilise pour faire certains choix :

oui c'est un des attributs du format PEM.

Le format PEM, c'est comme le format a.out sous Unix ? (C-à-d
le format normal d'un fichier binaire exécutable.)

le 'M' est une coquille, désolé, il faut lire format 'PE' (portable
executable).

c'est un format qui contient les modules linkés statiquement et les
informations pour les lins dynamiques à résoudre au lancement; il
contient également quelque informations sur les compatiblités du module
(16, 32 ou 64 bits, mode graphique ou non).

ce flag conditionne complètement les IO du prog.; si c'est un prog
console une fenêtre s'ouvrira au premier output ou saisie; à l'inverse
si c'est un programme avec GUI, toutes les IO standards (j'entends cout,
printf, etc) iront nulle part et ne seront pas affichés.

Mais qui fait tout ça ? Le programme qui lance le programme,
non ? Ou est-ce que le comportement de la fonction standard
system(), ou de la fonction CreateProcess() va faire quelque
chose de différent ?

je ne sais pas répondre précisemment à "qui fait ça".

à tout le moins le CRT (MS en tout ça) dirige, par défaut, les flux
standards vers des sorties muettes, des APIs pures MS-Win32 permettent
de rediriger ces flux ailleurs (y compris pour une appli GUI).
(note que c'est bien l'appli qui doit rediriger ses flux, un IDE ne peut
pas le faire trivialmeent pour elle).

Prenons un cas concret : j'écris un programme interactif (donc,
avec interface graphique). À un moment donné, suite à une
commande de l'utilisateur (clique sur un bouton), le programme
veut imprimer une lettre à envoyer à un client. Évidemment,
c'est un programme à part qui s'occupe de formatter les données
dans une lettre et l'envoyer sur l'imprimante ; mon programme
se contente d'écrire des données dans un fichier temporaire, et
d'invoquer ce deuxième programme avec le nom du fichier. (C'est
un scénario assez fréquent, j'imagine.)

le scénario oui, mais pas directement la méthode qui tu sous-entends.

Et ce deuxième
programme, évidemment, n'a aucun besoin d'une interface
graphique ou d'autre. Maintenant, d'après ce que j'ai compris
jusqu'ici, ce deuxième programme serait une application console
(parce qu'il n'a pas de GUI). J'espère quand même que quand
j'invoque CreateProcess pour le lancer, que le système ne va pas
ouvrir une fenêtre « invite à la commande ».

soit ce que tu décris correspond à une sortie raw sur une imprimante
basique, ou, pour un flux imprimante complexe, suppose une génération
complète des codes imprimantes (Esc IBM, PCL, PS, ...) par le 2ième
programme (sauf matériel d'impression très spécifique, personne
n'imprime comme cela sous Windows).

soit le 2ième programme est en fait le gestionnaire du spool
d'impression; en effet pour imprimer, un programme dessine simplement ce
qu'il doit imprimer dans un port graphique (plus précisemment un device
context) lié à l'imprimante, et il trace exactement de la même façon et
avec les mêmes primitives de dessin pour pour tracer dans un port
graphique d'écran - ceci du fait que 99% des imprimantes utilisées sous
Windows disposent d'un driver dit GDI (graphical device interface).

le spool d'impression qui reçoit les séquences GDI les transmets au
driver qui lui convertit un jargon spécifique à l'imprimante.
ce spool n'est pas une application console mais un daemon faceless (et
la plupart des appli unix de ce type (pour du mail par exemple) sont en
fait des services faceless sous Windows).

l'interprêteur de commande attend la fin du programme ou non
non puisque ce n'est pas "l'interpréteur" mais une fenêtre texte

OK. J'ai compris.

Mais alors, quel est l'avantage de faire comme ça, par rapport à
simplement recupérer les sorties soi-même et les afficher
quelque part. Est-ce que c'est à cause des « code pages », ou
les positionnements de cursor, etc., possible ?

faire "soi-même" est possible, via des API MS (non standards) un code
peut créer sa console, gérer son curseur etc; mais par défaut les lib.
systèmes ne le font pas - ce n'est pas tant une avantage que, encore une
fois, un principe d'autorité des prog. Windows, une appli. Windows
/doit/ se cogner tout le GUI Windows dès qu'elle veut afficher quelque
chose (on est à des années lumière des possibilités offertes à un client
X-Window).

une différence importance est l'héritage de l'environment sous unix, un
processus fils héritant de l'env. du shell et les sous-processus du
parent; cela n'existe quasiment pas sous Windows, à tout le moin scela
n'a pas la même philosophie.

D'où est-ce qu'un processus hérite son environement, alors ?
Selon la documentation Microsoft : « By default, a child
process inherits a copy of the environment block of the parent
process. » Ça ressemble bien à ce que je connais d'Unix. (En
fait, sous Unix, dans la fonction de base de création d'un
nouveau processus, execve, on précise l'environement ; on peut
passer ce qu'on veut. Mais la convention est bien de passer son
propre environement, et il existe des formes d'exec simplifier
qui le font automatiquement.)

c'est bien le cas, mais, et c'est une opinion personnelle, je considère
que l'environnement hérité (quelque variables systèmes (path, etc) et
les droits liés à l'utilisateur) est assez pauvre; la gestion des
appartenances des processus est également non limpide (et non standard
pour ces APIs).

Il faudra que je régarde de plus près, mais une chose est
certaine : j'ai écrit des programmes dite « console », et le
CRT ne m'ouvre pas un nouveau fenêtre console quand je les
invoque. (Et ce que tu dis contradit ce que m'a dit Alf
Steinbach et Jerry Coffin dans le groupe anglophone.)

c'est un raccourci - comme dit plus haut, je ne saurais pas décrire
précisemment qui fait exactement quoi.
je ne dis pas qu'il ouvre systématiquement une console, il ne le fait
que si le programme est lancé par le gestionnaire de taches (qui utilise
un CreateProcess ou qlq chose du genre); s'il est lancé depuis une
invite de commande il utilise celle-ci - ce n'est pas en contradiction
avec le papier cité (ni surement les propos de A. Steinbach et J. Coffin).

pour reformuler, un appli console commence par un main standard, les
flux standards sont alors connectés à la console en cours, si aucune
console n'existe les primitives de kernel32 en connecte une propre au
programme exécutée.
une appli GUI commence par un WinMain (non standard) ce starter établit
une autre connexion (non standard) des flux standards qui masque /
inhibe les affichages directs (l'interface est alors gérée par les
primitives de user32 et non kernel32).

ce qui change est que Windows ne dispose ni de xterm, ni de shell, ni
rien de comparable -

Et c'est quoi, la fenêtre « invite à la commande » ? Et c'est
quoi qui interprête les fichiers .bat ? Ils me semblent jouer
exactement le même rôle sous Windows que xterm et shell sous
Unix.

non, pas vraiment "exactement" le même rôle car ils sont bcp bcp moins
évolués.
ce qui interprêtre est le programme "command.com" c'est lui-même une
appli console; si tu lances "command" depuis un gestionnaire de taches
(comme le lanceur invoqué par "windows+R") il récupère (via kernel32)
une console "par défaut" qui hérite des variables d'env. systèmes mais
d'aucun paramètre utilisateur (sauf défini comme variable
d'environnement). si tu le lances depuis une invite de commande, il
utilise la console du premier interpréteur (un "exit" quittera ce second
shell, un autre "exit" quittera l'invite et fermera la fenêtre). note
qu'il est impossible de lancer "command&" pour obtenir un second shell
hérité du premier mais indépendant de celui-ci.

Que le GUI de Windows soit plus integré dans le système que le
GUI de Unix, je sais bien.

euh, je prenais plutôt des réserves vis a vis de cette affirmation.

Mais il y a quand même énormement de
similarités entre les deux systèmes. [...]

nous sommes d'accord, mais tu listes ici des fonctionnalités, elles se
ressemblent forcément car ce sont bien deux O.S.

mon point ne valait que pour souligner qlq différences de principes de
mode de fonctionnement qui créent des différences notamment sous des
choses aussi basiques que cout.

Microsoft, au moins, prétend qu'on peut se servir de Windows
comme serveur, et d'après ce que j'entends dire, il y a des gens
qui le font. Qui dit serveur dit une machine qui tourne sans
qu'il y ait quelqu'un devant l'écran.

pour ma part - et parce que j'ai bien pratiqué les serveurs MS, et des
applicatifs comme IIS ou SQL-Server) j'utilise un serveur linux et des
applicatifs Apache ou MySQL - mais oui, on prétends que l'on peut s'en
servir comme serveur - et d'ailleurs pour un serveur de droits (avec que
des protocoles 100% MS) ou un serveur de fichiers (avec des proto 100%
MS) il vaut mieux en effet utiliser un svr MS.

Sylvain.

On Jul 28, 11:55 pm, Sylvain <noS...@mail.net> wrote:

James Kanze wrote on 27/07/2007 09:53:

ton a priori biaise ton appréciation.
Windows n'est PAS un système basé sur des shell, un programme ""no rmal""
("en charte") n'utilise jamais une console.

Je ne suis pas sûr ce que tu entends par « programme
normale ». Il y a beaucoup de types de programmes, des
serveurs, des applications à interface graphique, des
utilitiaires...

j'entendais "en charte" avec la charte graphique de l'OS.

bien sur que différents types de programmes ont besoin de différents
types d'interface / d'interaction - je ne les qualifiais pas, je disais
seulement que les outils de dev. pour Windows sont plus orientés vers la
construction d'applis avec GUI windows (par exemple comme cité Studio
n'interagit pas avec la console hôte d'un programme).

C'est parfois l'impression que j'ai aussi : que Windows n'est
bon que pour les applications graphiques -- les GUI
d'interface. Mais ce n'est pas ce que dit Microsoft, qui essaie
de le vendre pour les serveurs, aussi. Et évidemment, fort peu
d'interfaces graphiques s'écrivent en C++ de nos jours : dans
la plupart des systèmes modernes, l'« interface graphique »,
c'est le navigateur, et sa programmation se fait en javascript,
voire éventuellement des appets Java (mais c'est fort rare). Ou
sinon en C# (pour l'instant -- je le prévois la même réussite
que Java dans ce domaine).

pour poursuivre la liste de ces petites différences qui rendent les
choses très différentes, un daemon unix utilisera souvent des logs, et
des programmes connexes à ce daemon permettront de le redémarrer /
stopper, d'analyser ces logs, etc.
sous Windows, une appli type serveur aura souvent son control panel ou
sa fenêtre de configuration (généralement réduite dans la systray ), si
l'appli est complètement faceless, elle loguera ses info dans les listes
systèmes d'évènements; tout ceci n'est pas une obligeation, mais le
conformisme est souvent de règle sous Windows.

Pardonne, mais en général, une machine serveur n'a pas d'écran
(y compris quand il tourne sous Windows). Sous Unix, aussi,
c'est assez courant de fournir une petite application de
configuration, avec une interface graphique, quand le serveur
est conçu pour tourner chez beaucoup d'utilisateurs différents
(je pense ici à Samba, par exemple). Quand le serveur est une
application « in house », en revanche, c'est plutôt rare ;
c'est du travail supplémentaire pour en fin de compte bien peu
de chose.

Quant aux sorties, les logs (sur support persistant), c'est
essentiels, quelque soit l'OS. Comment avoir l'historique en cas
de pepin, sinon ? De même, il y a toujours un niveau de log
ultra-critique qui se convertit en email, pour avertir le
gestionnaire. (Sous Unix, il y a aussi syslog. Qui peut être
utile si tu utilises d'autres utilitaires qui savent
l'exploiter.)

Le fait que un programme n'utilise pas le shell n'exclut pas
qu'il puisse être invoqué depuis un shell. Et ça m'étonnerait
que des .bat ne servent pas sous Windows ; ils servent ici, au
moins, pas mal.

un batch réponds à d'autres règles (puisque qu'il est nécessairem ent
interprété par le shell qui le lance); je parlais ici d'exécutables
compilés.

Tout à fait. Qu'est-ce que tu crois qu'un batch invoque ? Tôt
ou tard, il faut bien arriver soit à un built-in du shell (mais
il y en a fort peu, que ce soit Unix ou Windows), soit à un
exécutable compilé. Soit à un autre interpréteur, genre JVM,
évidemment, mais l'autre interpréteur, c'est aussi un exécutable
compiler (comme d'ailleurs le shell).

à nouveau, unix fera exactement ce que l'utilisateur demande ('&' a une
conséquence lors d'un lancement depuis un shell).
windows ne fera qu'en fonction du type de programme; si c'est une appli
avec GUI, un lancement depuis l'invite de commande est strictement
identique à un clic sur ce programme et donc l'interpréteur rends
aussitôt la main;

Ça dépend de l'interpréteur. Bash, par exemple, ne le fait pas.
C'est ce qui me fait croire que c'est le programme qui lance ton
programme qui lit l'attribute, et choisit. L'interpréteur de
commande par défaut sous Windows (qui est ? je ne sais pas
comment il s'appelle) lit l'attribute, et modifie son
comportement en conséquence ; le bash de CygWin ne le fait pas.
(CygWin cherche à créer un milieu « Unix » sous Windows.
Jusqu'à la perversité, à vrai dire : si je voulais un
environement 100% Unix, je ne serais pas sous Windows.)

si c'est un prog console, la fenêtre de l'interpréteur
est utilisée ou une fenêtre similaire est adjointe si le prog. est la ncé
par clic / scheduler / etc.

Et enfin, si je veux tester un programme, ce n'est pas mal de
l'invoquer depuis un shell. (On peut invoquer n'importe quel
programme Windows depuis un shell.)

"invoquer", si cela ne signifie que démarrer, oui.
pour autant on ne garde aucun contrôle sur les progs non console lanc é
depuis le shell (ni la boite "Exécuter", ni le scheduler, ...)

J'invoque des programmes GUI sous Windows, dans un shell, et le
shell attend. Bien que dans le cas concerné, ce n'est pas ce que
je veux (et le shell n'attend pas sous Unix:-)). Mais ça, c'est
sous le bash de CygWin. (Je ne l'ai pas installé momentanément,
mais ça serait intéressant de voir le comportement du bash de
MSys ou du ksh de UWin ou de MKS.)

Unix est un OS basé sur des shell (avec bien sur des
serveurs X qui existait bien avant que Windows ne sache
dessiner correctement un bouton).

Unix est un OS. Il s'avère que sous cet OS, il y a des
programmes d'interprêtation de commande dont on peut se servir,
et que la tradition est de s'en servir, pour combiner des
programmes existants, plutôt que d'écrire de nouveaux
programmes.

tout à fait d'accord - également d'accord avec ton raccourci: unix est
un IDE en soi.

Windows aussi, si on veut. Mais c'est vrai que la combinaison de
cmd.exe/notepad et bien moins puissant que ksh/bash et
gvim/emacs:-). Je crois, effectivement, que la différence, c'est
que sous Unix, l'intention est qu'on s'en sert, alors que sous
Windows, c'est surtout pour l'interprétation des batch (et que
l'intention aussi est qu'on utilise bien moins de batch que sous
Unix).

Mais si je régarde sur mes machines Windows, il y a
pas mal de fichiers .bat aussi. Il doit y être pour une raison.

il y a en très très peu - un développeur peux bien sur en créer p our
automatiser qlq taches mais le système ne les utilise quasiment plus; de
plus leur syntaxe a tjrs été très pauvre comparé aux scripts shel l unix
(ou à l'interpréteur d'OS/2).

Et quel est l'alternatif offert ? J'utilise les scripts
énormement ; je n'ai pas envie d'écrire un programme C++ pour
chaque petite opération de gestion système.

[...]

Suite à des discussions dans comp.lang.c++, Alf Steinbach m'a
renvoyé à un papier excellent
(http://home.no.net/dubjai/win32apitut/01.pdf) qu'il a écrit.
D'après ce que j'ai bien compris de ce papier, l'éditeur de lien
ajoute un attribute (appelée « subsystem ») au fichier .exe,
que le système utilise pour faire certains choix :

oui c'est un des attributs du format PEM.

Le format PEM, c'est comme le format a.out sous Unix ? (C-à-d
le format normal d'un fichier binaire exécutable.)

le 'M' est une coquille, désolé, il faut lire format 'PE' (portable
executable).

Ce qui ne m'aurait pas avancé beaucoup plus, si Jerry ne me
l'avait pas expliqué déjà:-). (Mais en effet, je m'étonnais un
peu que lui, il parlais de format PE, et toi de PEM.)

c'est un format qui contient les modules linkés statiquement et les
informations pour les lins dynamiques à résoudre au lancement; il
contient également quelque informations sur les compatiblités du modu le
(16, 32 ou 64 bits, mode graphique ou non).

Selon Jerry, c'est un variant de COFF (le « common object file
format » des anciens Unix).

[...]

Prenons un cas concret : j'écris un programme interactif (donc,
avec interface graphique). À un moment donné, suite à une
commande de l'utilisateur (clique sur un bouton), le programme
veut imprimer une lettre à envoyer à un client. Évidemment,
c'est un programme à part qui s'occupe de formatter les données
dans une lettre et l'envoyer sur l'imprimante ; mon programme
se contente d'écrire des données dans un fichier temporaire, et
d'invoquer ce deuxième programme avec le nom du fichier. (C'est
un scénario assez fréquent, j'imagine.)

le scénario oui, mais pas directement la méthode qui tu sous-entends.

Et ce deuxième
programme, évidemment, n'a aucun besoin d'une interface
graphique ou d'autre. Maintenant, d'après ce que j'ai compris
jusqu'ici, ce deuxième programme serait une application console
(parce qu'il n'a pas de GUI). J'espère quand même que quand
j'invoque CreateProcess pour le lancer, que le système ne va pas
ouvrir une fenêtre « invite à la commande ».

soit ce que tu décris correspond à une sortie raw sur une imprimante
basique, ou, pour un flux imprimante complexe, suppose une génération
complète des codes imprimantes (Esc IBM, PCL, PS, ...) par le 2ième
programme (sauf matériel d'impression très spécifique, personne
n'imprime comme cela sous Windows).

Je ne sais pas trop comment ça se fait sous Windows, mais en
gros, la situation est que j'ai des données brutes (mettons que
le client X n'a pas payé la facture N), et qu'il faut que je
formule une lettre (un rappel de payement). J'ai donc un
procéssus qui prend ces données brutes, et génère une lettre
(probablement en s'appuyant sur un modèle de lettre quelque
part, avec peut-être aussi des accès à une base de données pour
des compléments d'information : l'adresse, etc.). Sous Unix, le
format le plus répandu pour les sorties de ce processus serait
du Postscript, pipé au gestionnaire de l'impression (un
processus système). Sous Windows, je ne sais pas ; d'après le
peu que j'ai vu, Postscript n'est pas le format par défaut, et
je ne crois pas qu'on pipe très souvent non plus. Mais le
problème reste le même : j'ai des données simples
(éventuellement seulement le numéro de la facture), que je
complète avec d'autres données (mais on pourrait aussi envisager
que je sois fourni toutes les données qu'il me faut), et
qu'ensuite, je génère une « lettre » (dans quel format ?
qu'importe, mais probablement un format assez « high
level » ; je ne veux pas avoir à me déméler avec les codes
d'impression de l'imprimante elle-même) et que je m'arrange avec
le système pour qu'elle soit imprimée.

Le processus que j'envisage ici n'a rien à faire avec les codes
imprimantes, ni la gestion du spool de l'imprimante. Il ne fait
que communiquer avec des programmes systèmes qui s'occupent de
ces détails. Il va en revanche bien s'occuper du format de la
lettre (addresse du destinataire, correctement formattée en
haut, la date, le sujet de la lettre, les formules de politesse,
etc., etc.).

[...]

faire "soi-même" est possible, via des API MS (non standards) un code
peut créer sa console, gérer son curseur etc; mais par défaut les l ib.
systèmes ne le font pas - ce n'est pas tant une avantage que, encore une
fois, un principe d'autorité des prog. Windows, une appli. Windows
/doit/ se cogner tout le GUI Windows dès qu'elle veut afficher quelque
chose (on est à des années lumière des possibilités offertes à un client
X-Window).

Et ce que j'essaie à dire, c'est qu'il y a énormement de
programmes qui, normalement, ne veut pas (forcément) afficher
quoique ce soit. Mes applications, par exemple, qui tournent
souvent sur des machines sans écran. Mes petits outils, qui
effectuent des transformations entre les entrées et les
sorties ; si je les utilise seul dans une fenêtre avec un
shell, elles affichent, mais je les utilise aussi souvent, sinon
plus, dans des scripts, ou comme des filtres sur des blocs de
texts dans l'éditeur. (J'ai donc des outils pour formatter des
commentaires, convertir des blocs de code en macro -- c'était
très utile avant les templates --, etc.)

une différence importance est l'héritage de l'environment sous uni x, un
processus fils héritant de l'env. du shell et les sous-processus du
parent; cela n'existe quasiment pas sous Windows, à tout le moin sce la
n'a pas la même philosophie.

D'où est-ce qu'un processus hérite son environement, alors ?
Selon la documentation Microsoft : « By default, a child
process inherits a copy of the environment block of the parent
process. » Ça ressemble bien à ce que je connais d'Unix. (En
fait, sous Unix, dans la fonction de base de création d'un
nouveau processus, execve, on précise l'environement ; on peut
passer ce qu'on veut. Mais la convention est bien de passer son
propre environement, et il existe des formes d'exec simplifier
qui le font automatiquement.)

c'est bien le cas, mais, et c'est une opinion personnelle, je considère
que l'environnement hérité (quelque variables systèmes (path, etc) et
les droits liés à l'utilisateur) est assez pauvre; la gestion des
appartenances des processus est également non limpide (et non standard
pour ces APIs).

Une fois qu'on a des variables d'environement, on peut le faire
aussi complexe qu'on veut.

[...]

ce qui change est que Windows ne dispose ni de xterm, ni de shell, ni
rien de comparable -

Et c'est quoi, la fenêtre « invite à la commande » ? Et c'est
quoi qui interprête les fichiers .bat ? Ils me semblent jouer
exactement le même rôle sous Windows que xterm et shell sous
Unix.

non, pas vraiment "exactement" le même rôle car ils sont bcp bcp moins
évolués.

Comme beaucoup de choses dans Windows:-). Mais c'est vrai que
l'interpréteur de commandes est un cas extrème ; il me rappelle
plutôt celui de CP/M, d'il y a 25 ans.

ce qui interprêtre est le programme "command.com" c'est lui-même une
appli console; si tu lances "command" depuis un gestionnaire de taches
(comme le lanceur invoqué par "windows+R") il récupère (via kernel3 2)
une console "par défaut" qui hérite des variables d'env. systèmes m ais
d'aucun paramètre utilisateur (sauf défini comme variable
d'environnement). si tu le lances depuis une invite de commande, il
utilise la console du premier interpréteur (un "exit" quittera ce second
shell, un autre "exit" quittera l'invite et fermera la fenêtre). note
qu'il est impossible de lancer "command&" pour obtenir un second shell
hérité du premier mais indépendant de celui-ci.

Oui, mais j'ai l'impression que c'est pour la plupart la
fonctionnement de cmd.exe qui est en question. Si je clique sur
« executer » dans le popup de « démarrer », et entre
« command », j'ai bien une fenêtre « console », mais je n'ai
pas besoin de faire exit deux fois.

Mais je me démande bien quelle est la différence entre cmd.exe
et command.com, en tant qu'interpréteur de commande. À part que
command.com semble utiliser les noms de fichiers manglés pour
passer dans le modèle 8.3. (Et que je n'arrive pas à trouver le
processus correspondand dans la liste des processus du
gestionnaire des tâches.)

Que le GUI de Windows soit plus integré dans le système que le
GUI de Unix, je sais bien.

euh, je prenais plutôt des réserves vis a vis de cette affirmation.

Je ne sais pas. Sous Unix, X n'est qu'un processus comme un
autre (ou plutôt plusieurs processus). Il communique avec les
applications au moyen des sockets, jusqu'au point où le serveur,
le gestionnaire des fenêtres et l'application peuvent être sur
trois machines différentes (et qu'une application peut se
connecter à plusieurs serveurs différents, et donc afficher sur
plusieurs machines différentes). Le serveur même, évidemment,
doit être un processus priviléger, parce qu'il gère le hardware,
mais il reste en dehors du noyau ; on le démarre exactement
comme on démarre n'importe quel serveur (y compris mes
applications).

Mais il y a quand même énormement de
similarités entre les deux systèmes. [...]

nous sommes d'accord, mais tu listes ici des fonctionnalités, elles se
ressemblent forcément car ce sont bien deux O.S.

Mais la plupart des OS ont bien d'avantage de différences.

mon point ne valait que pour souligner qlq différences de principes de
mode de fonctionnement qui créent des différences notamment sous des
choses aussi basiques que cout.

Microsoft, au moins, prétend qu'on peut se servir de Windows
comme serveur, et d'après ce que j'entends dire, il y a des gens
qui le font. Qui dit serveur dit une machine qui tourne sans
qu'il y ait quelqu'un devant l'écran.

pour ma part - et parce que j'ai bien pratiqué les serveurs MS, et des
applicatifs comme IIS ou SQL-Server) j'utilise un serveur linux et des
applicatifs Apache ou MySQL - mais oui, on prétends que l'on peut s'en
servir comme serveur - et d'ailleurs pour un serveur de droits (avec que
des protocoles 100% MS) ou un serveur de fichiers (avec des proto 100%
MS) il vaut mieux en effet utiliser un svr MS.

Pour fournir un service propre aus systèmes MS, où tous les
clients sont Windows, c'est sûr qu'il vaut mieux utiliser MS. La
même chose vaut probablement pour n'importe quel Unix. Mais j'ai
l'habitude des reseaux hétérogène : Windows, Linux, Solaris...
et parfois des systèmes spécifiques : j'ai déjà eu des Simbian
comme clients à mes serveurs.

--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34