...tes appels aux interruptions BIOS...
Au fait il n'y a pas de DOS sous XP.
Hum, c'est un peu plus compliqué en mode protégé (depuis le 80386)
avec les *System Address Registers*
Oui pourquoi pas si tu respecte le traitement effectué avant la
redirection vers le vecteur 0x40.
...tes appels aux interruptions BIOS...
Au fait il n'y a pas de DOS sous XP.
Hum, c'est un peu plus compliqué en mode protégé (depuis le 80386)
avec les *System Address Registers*
Oui pourquoi pas si tu respecte le traitement effectué avant la
redirection vers le vecteur 0x40.
...tes appels aux interruptions BIOS...
Au fait il n'y a pas de DOS sous XP.
Hum, c'est un peu plus compliqué en mode protégé (depuis le 80386)
avec les *System Address Registers*
Oui pourquoi pas si tu respecte le traitement effectué avant la
redirection vers le vecteur 0x40.
Salut
Michel__D a écrit :
...tes appels aux interruptions BIOS...
Mais normalement je ne fais pas appel aux interruptions BIOS
(c'était exceptionnel pour le truc du clavier l'autre jour).
Si j'ai oublié ma montre je fais (par exemple)
mov ah,2ch
int 21h
....en faisant appel à _DOS_
(ce qu'il fait après et où il va creuser la réponse ne me regarde pas)Au fait il n'y a pas de DOS sous XP.
Dis-moi plus.
Même si ce n'est pas pareil pour NTFS, XP peut tourner sous et manipuler
des disques (qui n'ont pas changé) formatés FAT32.
Donc quoi qu'on les appelle il doit avoir des fonctions équivalentes du
type DOS ('Disque Operating System') dans le sens large (pas MS-DOS) -
pour la trilogie ouvrir - lire/écrire - fermer etc.
Hum, c'est un peu plus compliqué en mode protégé (depuis le 80386)
avec les *System Address Registers*
Merci pour ces infos. Je n'ai pas travaillé en assembleur 80x86 depuis
le 80186 (mon intérêt et boulot étant pour les 680x0, d'une
architecture orthogonale et propre; et toujours plus performante -
génération par génération et MHz pour MHz).
Mais ça soulève certaines questions:
1. Un DOS (MS-, DR-, GEM-, Caldéra etc) antérieur au 80386 ne connaît
rien à ces registres, donc ne va pas les initialiser. Avec leurs
valeurs par défaut je suppose donc que le proc se comporte comme un 80186.
2. Si j'ai bien compris tes explications on pourrait créer des machines
virtuelles sur un 80386 avec un DOS adéquat, sans avoir recours à un OS
à un niveau plus haut.
Oui pourquoi pas si tu respecte le traitement effectué avant la
redirection vers le vecteur 0x40.
Faudrait que je ressorte SoftICE ;-) - mais c'est juste par curiosité.
Salut
Michel__D a écrit :
...tes appels aux interruptions BIOS...
Mais normalement je ne fais pas appel aux interruptions BIOS
(c'était exceptionnel pour le truc du clavier l'autre jour).
Si j'ai oublié ma montre je fais (par exemple)
mov ah,2ch
int 21h
....en faisant appel à _DOS_
(ce qu'il fait après et où il va creuser la réponse ne me regarde pas)
Au fait il n'y a pas de DOS sous XP.
Dis-moi plus.
Même si ce n'est pas pareil pour NTFS, XP peut tourner sous et manipuler
des disques (qui n'ont pas changé) formatés FAT32.
Donc quoi qu'on les appelle il doit avoir des fonctions équivalentes du
type DOS ('Disque Operating System') dans le sens large (pas MS-DOS) -
pour la trilogie ouvrir - lire/écrire - fermer etc.
Hum, c'est un peu plus compliqué en mode protégé (depuis le 80386)
avec les *System Address Registers*
Merci pour ces infos. Je n'ai pas travaillé en assembleur 80x86 depuis
le 80186 (mon intérêt et boulot étant pour les 680x0, d'une
architecture orthogonale et propre; et toujours plus performante -
génération par génération et MHz pour MHz).
Mais ça soulève certaines questions:
1. Un DOS (MS-, DR-, GEM-, Caldéra etc) antérieur au 80386 ne connaît
rien à ces registres, donc ne va pas les initialiser. Avec leurs
valeurs par défaut je suppose donc que le proc se comporte comme un 80186.
2. Si j'ai bien compris tes explications on pourrait créer des machines
virtuelles sur un 80386 avec un DOS adéquat, sans avoir recours à un OS
à un niveau plus haut.
Oui pourquoi pas si tu respecte le traitement effectué avant la
redirection vers le vecteur 0x40.
Faudrait que je ressorte SoftICE ;-) - mais c'est juste par curiosité.
Salut
Michel__D a écrit :
...tes appels aux interruptions BIOS...
Mais normalement je ne fais pas appel aux interruptions BIOS
(c'était exceptionnel pour le truc du clavier l'autre jour).
Si j'ai oublié ma montre je fais (par exemple)
mov ah,2ch
int 21h
....en faisant appel à _DOS_
(ce qu'il fait après et où il va creuser la réponse ne me regarde pas)Au fait il n'y a pas de DOS sous XP.
Dis-moi plus.
Même si ce n'est pas pareil pour NTFS, XP peut tourner sous et manipuler
des disques (qui n'ont pas changé) formatés FAT32.
Donc quoi qu'on les appelle il doit avoir des fonctions équivalentes du
type DOS ('Disque Operating System') dans le sens large (pas MS-DOS) -
pour la trilogie ouvrir - lire/écrire - fermer etc.
Hum, c'est un peu plus compliqué en mode protégé (depuis le 80386)
avec les *System Address Registers*
Merci pour ces infos. Je n'ai pas travaillé en assembleur 80x86 depuis
le 80186 (mon intérêt et boulot étant pour les 680x0, d'une
architecture orthogonale et propre; et toujours plus performante -
génération par génération et MHz pour MHz).
Mais ça soulève certaines questions:
1. Un DOS (MS-, DR-, GEM-, Caldéra etc) antérieur au 80386 ne connaît
rien à ces registres, donc ne va pas les initialiser. Avec leurs
valeurs par défaut je suppose donc que le proc se comporte comme un 80186.
2. Si j'ai bien compris tes explications on pourrait créer des machines
virtuelles sur un 80386 avec un DOS adéquat, sans avoir recours à un OS
à un niveau plus haut.
Oui pourquoi pas si tu respecte le traitement effectué avant la
redirection vers le vecteur 0x40.
Faudrait que je ressorte SoftICE ;-) - mais c'est juste par curiosité.
Non dans ce cas précis tu fais appel à la fonction 0x2C de
l'interruption 0x21 qui a été mise en place par un système
d'exploitation qui par exemple pourrait être un DOS...
alors que sous XP, la présence et l'émulation de cette interruption
c'est plus pour une raison de compatibilité qu'autre chose.
Comme cela a déja été dit, sous XP c'est plutot une émulation car
derrière ce n'est pas le même code qui tourne.
Moi aussi je préférai l'architecture du 680x0 !
Ben le problème du DOS c'est qu'il est monotache donc je ne pense pas
que ce soit une bonne base à moins de tout reécrire et dans ce cas
là autant partir de 0 (mais sacré boulot en perspective).
PS:Pour te rendre compte que la table d'interruption n'est pas figée
il suffit (sous XP) de lançer debug à partir de cmd.exe et de
command.com et tu te rendras compte que les vecteurs d'interruptions
0x22,0x23,0x24 n'ont pas les mêmes valeurs.
Non dans ce cas précis tu fais appel à la fonction 0x2C de
l'interruption 0x21 qui a été mise en place par un système
d'exploitation qui par exemple pourrait être un DOS...
alors que sous XP, la présence et l'émulation de cette interruption
c'est plus pour une raison de compatibilité qu'autre chose.
Comme cela a déja été dit, sous XP c'est plutot une émulation car
derrière ce n'est pas le même code qui tourne.
Moi aussi je préférai l'architecture du 680x0 !
Ben le problème du DOS c'est qu'il est monotache donc je ne pense pas
que ce soit une bonne base à moins de tout reécrire et dans ce cas
là autant partir de 0 (mais sacré boulot en perspective).
PS:Pour te rendre compte que la table d'interruption n'est pas figée
il suffit (sous XP) de lançer debug à partir de cmd.exe et de
command.com et tu te rendras compte que les vecteurs d'interruptions
0x22,0x23,0x24 n'ont pas les mêmes valeurs.
Non dans ce cas précis tu fais appel à la fonction 0x2C de
l'interruption 0x21 qui a été mise en place par un système
d'exploitation qui par exemple pourrait être un DOS...
alors que sous XP, la présence et l'émulation de cette interruption
c'est plus pour une raison de compatibilité qu'autre chose.
Comme cela a déja été dit, sous XP c'est plutot une émulation car
derrière ce n'est pas le même code qui tourne.
Moi aussi je préférai l'architecture du 680x0 !
Ben le problème du DOS c'est qu'il est monotache donc je ne pense pas
que ce soit une bonne base à moins de tout reécrire et dans ce cas
là autant partir de 0 (mais sacré boulot en perspective).
PS:Pour te rendre compte que la table d'interruption n'est pas figée
il suffit (sous XP) de lançer debug à partir de cmd.exe et de
command.com et tu te rendras compte que les vecteurs d'interruptions
0x22,0x23,0x24 n'ont pas les mêmes valeurs.
Salut
Michel__D a écrit :
Non dans ce cas précis tu fais appel à la fonction 0x2C de
l'interruption 0x21 qui a été mise en place par un système
d'exploitation qui par exemple pourrait être un DOS...
[couic]alors que sous XP, la présence et l'émulation de cette interruption
c'est plus pour une raison de compatibilité qu'autre chose.
Sans vouloir quadrisectionner les poils:
- incorporées dans cette émulation il y a forcément des sections de
code qui exécute les mêmes fonctions que les interruptions d'un DOS
ordinaire quelconque (rétro-compatibilité oblige)
- si l'on considère l'ensemble de ces sections d'émulation (et même si
elles sont éparpillées), il existe donc bien tous les composants d'un
DOS dans XP.
Comme cela a déja été dit, sous XP c'est plutot une émulation car
derrière ce n'est pas le même code qui tourne.
Ce n'est pas le même code qui exécute les mêmes fonctions dans
MS-, DR-, GEM- et Caldéra DOS, mais le résultat est +/- le même.
Moi aussi je préférai l'architecture du 680x0 !
Eh oui, et si elle avait été adopté à la place du boulet de celle des
80x86 on aurait vite été plusieurs années plus en avance ;-)Ben le problème du DOS c'est qu'il est monotache donc je ne pense pas
que ce soit une bonne base à moins de tout reécrire et dans ce cas là
autant partir de 0 (mais sacré boulot en perspective).
En 1987 j'ai commencé à travailler sur un GEMDOS multitâche pour Atari
ST et j'avais déjà un prototype (limité) qui fonctionnait.
Puis à peu près en même temps
- Atari a développé un multiTOS pour les TT
- la vente des Atari a chuté (baisse de prix des Mac et des copies
importées)
- la vente des PC a décollé.
Alors il en est resté là.PS:Pour te rendre compte que la table d'interruption n'est pas figée
il suffit (sous XP) de lançer debug à partir de cmd.exe et de
command.com et tu te rendras compte que les vecteurs d'interruptions
0x22,0x23,0x24 n'ont pas les mêmes valeurs.
Pourquoi les auraient-ils?
'Terminate' (terminaison normal), '<CTRL>-C' (interruption utilisateur)
et 'Critical Error' (généralement du hardware) - sont pas pareils...
Salut
Michel__D a écrit :
Non dans ce cas précis tu fais appel à la fonction 0x2C de
l'interruption 0x21 qui a été mise en place par un système
d'exploitation qui par exemple pourrait être un DOS...
[couic]
alors que sous XP, la présence et l'émulation de cette interruption
c'est plus pour une raison de compatibilité qu'autre chose.
Sans vouloir quadrisectionner les poils:
- incorporées dans cette émulation il y a forcément des sections de
code qui exécute les mêmes fonctions que les interruptions d'un DOS
ordinaire quelconque (rétro-compatibilité oblige)
- si l'on considère l'ensemble de ces sections d'émulation (et même si
elles sont éparpillées), il existe donc bien tous les composants d'un
DOS dans XP.
Comme cela a déja été dit, sous XP c'est plutot une émulation car
derrière ce n'est pas le même code qui tourne.
Ce n'est pas le même code qui exécute les mêmes fonctions dans
MS-, DR-, GEM- et Caldéra DOS, mais le résultat est +/- le même.
Moi aussi je préférai l'architecture du 680x0 !
Eh oui, et si elle avait été adopté à la place du boulet de celle des
80x86 on aurait vite été plusieurs années plus en avance ;-)
Ben le problème du DOS c'est qu'il est monotache donc je ne pense pas
que ce soit une bonne base à moins de tout reécrire et dans ce cas là
autant partir de 0 (mais sacré boulot en perspective).
En 1987 j'ai commencé à travailler sur un GEMDOS multitâche pour Atari
ST et j'avais déjà un prototype (limité) qui fonctionnait.
Puis à peu près en même temps
- Atari a développé un multiTOS pour les TT
- la vente des Atari a chuté (baisse de prix des Mac et des copies
importées)
- la vente des PC a décollé.
Alors il en est resté là.
PS:Pour te rendre compte que la table d'interruption n'est pas figée
il suffit (sous XP) de lançer debug à partir de cmd.exe et de
command.com et tu te rendras compte que les vecteurs d'interruptions
0x22,0x23,0x24 n'ont pas les mêmes valeurs.
Pourquoi les auraient-ils?
'Terminate' (terminaison normal), '<CTRL>-C' (interruption utilisateur)
et 'Critical Error' (généralement du hardware) - sont pas pareils...
Salut
Michel__D a écrit :
Non dans ce cas précis tu fais appel à la fonction 0x2C de
l'interruption 0x21 qui a été mise en place par un système
d'exploitation qui par exemple pourrait être un DOS...
[couic]alors que sous XP, la présence et l'émulation de cette interruption
c'est plus pour une raison de compatibilité qu'autre chose.
Sans vouloir quadrisectionner les poils:
- incorporées dans cette émulation il y a forcément des sections de
code qui exécute les mêmes fonctions que les interruptions d'un DOS
ordinaire quelconque (rétro-compatibilité oblige)
- si l'on considère l'ensemble de ces sections d'émulation (et même si
elles sont éparpillées), il existe donc bien tous les composants d'un
DOS dans XP.
Comme cela a déja été dit, sous XP c'est plutot une émulation car
derrière ce n'est pas le même code qui tourne.
Ce n'est pas le même code qui exécute les mêmes fonctions dans
MS-, DR-, GEM- et Caldéra DOS, mais le résultat est +/- le même.
Moi aussi je préférai l'architecture du 680x0 !
Eh oui, et si elle avait été adopté à la place du boulet de celle des
80x86 on aurait vite été plusieurs années plus en avance ;-)Ben le problème du DOS c'est qu'il est monotache donc je ne pense pas
que ce soit une bonne base à moins de tout reécrire et dans ce cas là
autant partir de 0 (mais sacré boulot en perspective).
En 1987 j'ai commencé à travailler sur un GEMDOS multitâche pour Atari
ST et j'avais déjà un prototype (limité) qui fonctionnait.
Puis à peu près en même temps
- Atari a développé un multiTOS pour les TT
- la vente des Atari a chuté (baisse de prix des Mac et des copies
importées)
- la vente des PC a décollé.
Alors il en est resté là.PS:Pour te rendre compte que la table d'interruption n'est pas figée
il suffit (sous XP) de lançer debug à partir de cmd.exe et de
command.com et tu te rendras compte que les vecteurs d'interruptions
0x22,0x23,0x24 n'ont pas les mêmes valeurs.
Pourquoi les auraient-ils?
'Terminate' (terminaison normal), '<CTRL>-C' (interruption utilisateur)
et 'Critical Error' (généralement du hardware) - sont pas pareils...
Ben non, le DOS ne fait appel qu'au BIOS tandis que XP adresse
directement le matériel via ses pilotes/drivers.
Ha c'est sur que *superficiellemnt* le résultat est le même, c'est à
dire un traitement d'information.
Mouais mais avec le VDI et l'AES du GEMDOS on s'éloigne du simple DOS
!
C'est par rapport à une de tes réponses, je cite...
Ben non, le DOS ne fait appel qu'au BIOS tandis que XP adresse
directement le matériel via ses pilotes/drivers.
Ha c'est sur que *superficiellemnt* le résultat est le même, c'est à
dire un traitement d'information.
Mouais mais avec le VDI et l'AES du GEMDOS on s'éloigne du simple DOS
!
C'est par rapport à une de tes réponses, je cite...
Ben non, le DOS ne fait appel qu'au BIOS tandis que XP adresse
directement le matériel via ses pilotes/drivers.
Ha c'est sur que *superficiellemnt* le résultat est le même, c'est à
dire un traitement d'information.
Mouais mais avec le VDI et l'AES du GEMDOS on s'éloigne du simple DOS
!
C'est par rapport à une de tes réponses, je cite...
Re-salut
C'est vachement difficile de comprendre les détails des mécanismes tant
que l'éditeur fait tout pour empêcher les gens de s'informer...
Michel__D a écrit :
Ben non, le DOS ne fait appel qu'au BIOS tandis que XP adresse
directement le matériel via ses pilotes/drivers.
D'après ce que tu dis ça veut dire donc qu'au lieu des couches
classiques, genre
GUI Win 9x ->
--------
fonctions MS-DOS ->
--------
fonctions BIOS ->
--------
pilotes hardware normaux
....ça devient...
GUI Win XP ->
--------
machine DOS virtuelle ->
--------
pilotes hardware XP (en contournant entièrement le BIOS).
Comment ça se passe donc si XP daigne encore utiliser un ancien pilote
qui compte sur le BIOS pour que son périph' soit 'compris'?
Ha c'est sur que *superficiellemnt* le résultat est le même, c'est à
dire un traitement d'information.
Nan - si tu demandes à remplir un tampon avec le contenu du disque n,
face x, piste y, secteur z tu va toujours obtenir les mêmes données,
quelle que soit ta flaveur de DOS.
Mouais mais avec le VDI et l'AES du GEMDOS on s'éloigne du simple DOS
!
En fait ce n'est pas là le problème.
Puisque le BIOS n'est pas ré-entrant tu refuses tout simplement toute
requête pré-emptive tant que tu es actuellement dans
- le BIOS
- le VDI, ou
- les AES
....et tu l'enregistres mais tu la mets en file d'attente.
Comme ça tu évites tout conflit et (si tout va bien) l'utilisateur ne va
même pas s'en apercevoir)
Seulement puisque la majorité des programmes n'a pas écrite pour
fonctionner en multi-tâche, ça peut bloquer. Dans ce cas-là, tu prévois
des tranches de temps processeur limitées.C'est par rapport à une de tes réponses, je cite...
OK, compris, je parlais des procs jusqu'au 80186 avec des OS antérieurs
(MS-DOS 3.2, par exemple).
Mais qu'est-ce que ça change au niveau des interruptions 0x22, 0x23 et
0x24 -
'Terminate' (terminaison normal), '<CTRL>-C' (interruption utilisateur)
et 'Critical Error' (généralement du hardware).
Ça n'a jamais été autrement: les vecteurs ont toujours été différentes
comme il se doit; dans le cas contraire ça pourrait provoquer de graves
problèmes.
Re-salut
C'est vachement difficile de comprendre les détails des mécanismes tant
que l'éditeur fait tout pour empêcher les gens de s'informer...
Michel__D a écrit :
Ben non, le DOS ne fait appel qu'au BIOS tandis que XP adresse
directement le matériel via ses pilotes/drivers.
D'après ce que tu dis ça veut dire donc qu'au lieu des couches
classiques, genre
GUI Win 9x ->
--------
fonctions MS-DOS ->
--------
fonctions BIOS ->
--------
pilotes hardware normaux
....ça devient...
GUI Win XP ->
--------
machine DOS virtuelle ->
--------
pilotes hardware XP (en contournant entièrement le BIOS).
Comment ça se passe donc si XP daigne encore utiliser un ancien pilote
qui compte sur le BIOS pour que son périph' soit 'compris'?
Ha c'est sur que *superficiellemnt* le résultat est le même, c'est à
dire un traitement d'information.
Nan - si tu demandes à remplir un tampon avec le contenu du disque n,
face x, piste y, secteur z tu va toujours obtenir les mêmes données,
quelle que soit ta flaveur de DOS.
Mouais mais avec le VDI et l'AES du GEMDOS on s'éloigne du simple DOS
!
En fait ce n'est pas là le problème.
Puisque le BIOS n'est pas ré-entrant tu refuses tout simplement toute
requête pré-emptive tant que tu es actuellement dans
- le BIOS
- le VDI, ou
- les AES
....et tu l'enregistres mais tu la mets en file d'attente.
Comme ça tu évites tout conflit et (si tout va bien) l'utilisateur ne va
même pas s'en apercevoir)
Seulement puisque la majorité des programmes n'a pas écrite pour
fonctionner en multi-tâche, ça peut bloquer. Dans ce cas-là, tu prévois
des tranches de temps processeur limitées.
C'est par rapport à une de tes réponses, je cite...
OK, compris, je parlais des procs jusqu'au 80186 avec des OS antérieurs
(MS-DOS 3.2, par exemple).
Mais qu'est-ce que ça change au niveau des interruptions 0x22, 0x23 et
0x24 -
'Terminate' (terminaison normal), '<CTRL>-C' (interruption utilisateur)
et 'Critical Error' (généralement du hardware).
Ça n'a jamais été autrement: les vecteurs ont toujours été différentes
comme il se doit; dans le cas contraire ça pourrait provoquer de graves
problèmes.
Re-salut
C'est vachement difficile de comprendre les détails des mécanismes tant
que l'éditeur fait tout pour empêcher les gens de s'informer...
Michel__D a écrit :
Ben non, le DOS ne fait appel qu'au BIOS tandis que XP adresse
directement le matériel via ses pilotes/drivers.
D'après ce que tu dis ça veut dire donc qu'au lieu des couches
classiques, genre
GUI Win 9x ->
--------
fonctions MS-DOS ->
--------
fonctions BIOS ->
--------
pilotes hardware normaux
....ça devient...
GUI Win XP ->
--------
machine DOS virtuelle ->
--------
pilotes hardware XP (en contournant entièrement le BIOS).
Comment ça se passe donc si XP daigne encore utiliser un ancien pilote
qui compte sur le BIOS pour que son périph' soit 'compris'?
Ha c'est sur que *superficiellemnt* le résultat est le même, c'est à
dire un traitement d'information.
Nan - si tu demandes à remplir un tampon avec le contenu du disque n,
face x, piste y, secteur z tu va toujours obtenir les mêmes données,
quelle que soit ta flaveur de DOS.
Mouais mais avec le VDI et l'AES du GEMDOS on s'éloigne du simple DOS
!
En fait ce n'est pas là le problème.
Puisque le BIOS n'est pas ré-entrant tu refuses tout simplement toute
requête pré-emptive tant que tu es actuellement dans
- le BIOS
- le VDI, ou
- les AES
....et tu l'enregistres mais tu la mets en file d'attente.
Comme ça tu évites tout conflit et (si tout va bien) l'utilisateur ne va
même pas s'en apercevoir)
Seulement puisque la majorité des programmes n'a pas écrite pour
fonctionner en multi-tâche, ça peut bloquer. Dans ce cas-là, tu prévois
des tranches de temps processeur limitées.C'est par rapport à une de tes réponses, je cite...
OK, compris, je parlais des procs jusqu'au 80186 avec des OS antérieurs
(MS-DOS 3.2, par exemple).
Mais qu'est-ce que ça change au niveau des interruptions 0x22, 0x23 et
0x24 -
'Terminate' (terminaison normal), '<CTRL>-C' (interruption utilisateur)
et 'Critical Error' (généralement du hardware).
Ça n'a jamais été autrement: les vecteurs ont toujours été différentes
comme il se doit; dans le cas contraire ça pourrait provoquer de graves
problèmes.
Si tu as un pilote compatible avec un l'OS c'est qu'il respecte un
cahier des charges...
Ouais si tu veux, sauf que le terme DOS est associé à un système
d'exploitation qui n'est pas mis en oeuvre dans le cas présent.
C'était juste pour dire qu'avec ta théorie l'on aurait du trouver les
mêmes valeurs que l'on soit sous la ligne de commande classique
(cmd.exe) et/ou que l'on soit sous l'interpréteur de commande 16 bits
(command.com)...
Si tu as un pilote compatible avec un l'OS c'est qu'il respecte un
cahier des charges...
Ouais si tu veux, sauf que le terme DOS est associé à un système
d'exploitation qui n'est pas mis en oeuvre dans le cas présent.
C'était juste pour dire qu'avec ta théorie l'on aurait du trouver les
mêmes valeurs que l'on soit sous la ligne de commande classique
(cmd.exe) et/ou que l'on soit sous l'interpréteur de commande 16 bits
(command.com)...
Si tu as un pilote compatible avec un l'OS c'est qu'il respecte un
cahier des charges...
Ouais si tu veux, sauf que le terme DOS est associé à un système
d'exploitation qui n'est pas mis en oeuvre dans le cas présent.
C'était juste pour dire qu'avec ta théorie l'on aurait du trouver les
mêmes valeurs que l'on soit sous la ligne de commande classique
(cmd.exe) et/ou que l'on soit sous l'interpréteur de commande 16 bits
(command.com)...
C'était juste pour dire qu'avec ta théorie l'on aurait du trouver les
mêmes valeurs que l'on soit sous la ligne de commande classique
(cmd.exe) et/ou que l'on soit sous l'interpréteur de commande 16 bits
(command.com)...
C'était juste pour dire qu'avec ta théorie l'on aurait du trouver les
mêmes valeurs que l'on soit sous la ligne de commande classique
(cmd.exe) et/ou que l'on soit sous l'interpréteur de commande 16 bits
(command.com)...
C'était juste pour dire qu'avec ta théorie l'on aurait du trouver les
mêmes valeurs que l'on soit sous la ligne de commande classique
(cmd.exe) et/ou que l'on soit sous l'interpréteur de commande 16 bits
(command.com)...
Alors (je n'ai pas eu le temps de l'expérimenter) si on se limite au
lancement de programmes 16 bits depuis 'command.com', on devrait
retrouver toutes les fonctionnalités normales de MS-DOS? - même sous XP?
Alors (je n'ai pas eu le temps de l'expérimenter) si on se limite au
lancement de programmes 16 bits depuis 'command.com', on devrait
retrouver toutes les fonctionnalités normales de MS-DOS? - même sous XP?
Alors (je n'ai pas eu le temps de l'expérimenter) si on se limite au
lancement de programmes 16 bits depuis 'command.com', on devrait
retrouver toutes les fonctionnalités normales de MS-DOS? - même sous XP?
Michel__D a écrit :
>
> Si tu as un pilote compatible avec un l'OS c'est qu'il respecte un
> cahier des charges...
Ben oui, mais il existe des pilotes développés pour W9x qui continuent à
fonctionner parfaitement sous XP; même si le cahier des charges a évolué
depuis (mais dans ces cas particuliers, sans doute pas).
> Ouais si tu veux, sauf que le terme DOS est associé à un système
> d'exploitation qui n'est pas mis en oeuvre dans le cas présent.
Donc dans ce cas c'est l'émulation qui continue à fonctionner exactement
comme tous les divers DOS précédents (tant mieux).
Michel__D a écrit :
>
> Si tu as un pilote compatible avec un l'OS c'est qu'il respecte un
> cahier des charges...
Ben oui, mais il existe des pilotes développés pour W9x qui continuent à
fonctionner parfaitement sous XP; même si le cahier des charges a évolué
depuis (mais dans ces cas particuliers, sans doute pas).
> Ouais si tu veux, sauf que le terme DOS est associé à un système
> d'exploitation qui n'est pas mis en oeuvre dans le cas présent.
Donc dans ce cas c'est l'émulation qui continue à fonctionner exactement
comme tous les divers DOS précédents (tant mieux).
Michel__D a écrit :
>
> Si tu as un pilote compatible avec un l'OS c'est qu'il respecte un
> cahier des charges...
Ben oui, mais il existe des pilotes développés pour W9x qui continuent à
fonctionner parfaitement sous XP; même si le cahier des charges a évolué
depuis (mais dans ces cas particuliers, sans doute pas).
> Ouais si tu veux, sauf que le terme DOS est associé à un système
> d'exploitation qui n'est pas mis en oeuvre dans le cas présent.
Donc dans ce cas c'est l'émulation qui continue à fonctionner exactement
comme tous les divers DOS précédents (tant mieux).
