Le Fri, 03 Jan 2014 11:34:03 +0100,
Moreira David écrivait :Sauf si c'est réellement meilleur. Mais casser la rétrocompati bilité
n'est que très rarement bon, pour ne pas dire jamais.
Mouais. J'ai mis les mains dans le camboui de MacOS X et j'ai
beaucoup de mal à le qualifier de système bien fichu. Je ne di scute
pas le côté ergonomique de l'interface, mais le fait qu'il soi t
moins mal conçu qu'un Windows n'en fait pas un système bien co nçu.
Je ne sais pas pourquoi, mais le remplaçant de MacOS X ne devrait
pas échapper à la règle.
Le Fri, 03 Jan 2014 11:34:03 +0100,
Moreira David <vash2593@myopera.com> écrivait :
Sauf si c'est réellement meilleur. Mais casser la rétrocompati bilité
n'est que très rarement bon, pour ne pas dire jamais.
Mouais. J'ai mis les mains dans le camboui de MacOS X et j'ai
beaucoup de mal à le qualifier de système bien fichu. Je ne di scute
pas le côté ergonomique de l'interface, mais le fait qu'il soi t
moins mal conçu qu'un Windows n'en fait pas un système bien co nçu.
Je ne sais pas pourquoi, mais le remplaçant de MacOS X ne devrait
pas échapper à la règle.
Le Fri, 03 Jan 2014 11:34:03 +0100,
Moreira David écrivait :Sauf si c'est réellement meilleur. Mais casser la rétrocompati bilité
n'est que très rarement bon, pour ne pas dire jamais.
Mouais. J'ai mis les mains dans le camboui de MacOS X et j'ai
beaucoup de mal à le qualifier de système bien fichu. Je ne di scute
pas le côté ergonomique de l'interface, mais le fait qu'il soi t
moins mal conçu qu'un Windows n'en fait pas un système bien co nçu.
Je ne sais pas pourquoi, mais le remplaçant de MacOS X ne devrait
pas échapper à la règle.
Le Fri, 03 Jan 2014 11:56:30 +0100,
Toxico Nimbus écrivait :Le 03/01/2014 11:34, Moreira David a écrit :JKB writes:Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Non (où alors il faut préciser). Le noyau n'est appelé que
lorsqu'une application lui rend la main par un yield(). Ça ressemble
fort à du Contiki, rien de plus. Un système multitâche possède un
scheduler. C'est le minimum vital.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
OSEF.
Sauf si c'est réellement meilleur. Mais casser la rétrocompatibilité
n'est que très rarement bon, pour ne pas dire jamais.
Et pourtant dans le monde GNU/Linux, les changement d'ABI sont courant.
D'ABI. Pas de l'API de la libc.
Le Fri, 03 Jan 2014 11:56:30 +0100,
Toxico Nimbus <toxn@free.fr> écrivait :
Le 03/01/2014 11:34, Moreira David a écrit :
JKB <jkb@koenigsberg.invalid> writes:
Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :
After serious thinking Trolleur Polémiqueur wrote :
Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Non (où alors il faut préciser). Le noyau n'est appelé que
lorsqu'une application lui rend la main par un yield(). Ça ressemble
fort à du Contiki, rien de plus. Un système multitâche possède un
scheduler. C'est le minimum vital.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
OSEF.
Sauf si c'est réellement meilleur. Mais casser la rétrocompatibilité
n'est que très rarement bon, pour ne pas dire jamais.
Et pourtant dans le monde GNU/Linux, les changement d'ABI sont courant.
D'ABI. Pas de l'API de la libc.
Le Fri, 03 Jan 2014 11:56:30 +0100,
Toxico Nimbus écrivait :Le 03/01/2014 11:34, Moreira David a écrit :JKB writes:Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Non (où alors il faut préciser). Le noyau n'est appelé que
lorsqu'une application lui rend la main par un yield(). Ça ressemble
fort à du Contiki, rien de plus. Un système multitâche possède un
scheduler. C'est le minimum vital.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
OSEF.
Sauf si c'est réellement meilleur. Mais casser la rétrocompatibilité
n'est que très rarement bon, pour ne pas dire jamais.
Et pourtant dans le monde GNU/Linux, les changement d'ABI sont courant.
D'ABI. Pas de l'API de la libc.
JKB writes:Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
JKB <jkb@koenigsberg.invalid> writes:
Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :
After serious thinking Trolleur Polémiqueur wrote :
Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
JKB writes:Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Je suppose tables indexées, donc relationnel. Si tu veux mettre une
étiquette base de données réseau sur ta collection de structure avec de
pointeurs, pourquoi pas, dans l'absolu c'est légitime. Mais dans ce cas,
où situes-tu la limite entre simple logiciel et base de données ?
Je suppose tables indexées, donc relationnel. Si tu veux mettre une
étiquette base de données réseau sur ta collection de structure avec de
pointeurs, pourquoi pas, dans l'absolu c'est légitime. Mais dans ce cas,
où situes-tu la limite entre simple logiciel et base de données ?
Je suppose tables indexées, donc relationnel. Si tu veux mettre une
étiquette base de données réseau sur ta collection de structure avec de
pointeurs, pourquoi pas, dans l'absolu c'est légitime. Mais dans ce cas,
où situes-tu la limite entre simple logiciel et base de données ?
Le 03/01/2014 12:19, JKB a écrit :Le Fri, 03 Jan 2014 11:56:30 +0100,
Toxico Nimbus écrivait :Le 03/01/2014 11:34, Moreira David a écrit :JKB writes:Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Non (où alors il faut préciser). Le noyau n'est appelé que
lorsqu'une application lui rend la main par un yield(). Ça ressemble
fort à du Contiki, rien de plus. Un système multitâche possède un
scheduler. C'est le minimum vital.
Un système multitâche permet à plusieurs tâches de fonctionner
apparemment simultanément. Au passage, c'est n'est pas parce que le
multitâche est coopératif qu'il n'y a pas d'ordonnanceur.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
OSEF.
Sauf si c'est réellement meilleur. Mais casser la rétrocompatibilité
n'est que très rarement bon, pour ne pas dire jamais.
Et pourtant dans le monde GNU/Linux, les changement d'ABI sont courant.
D'ABI. Pas de l'API de la libc.
Dans le cas de la libc, l'API est en grand partie normalisée, c'est
encore heureux qu'elle ne change pas trop.
Le 03/01/2014 12:19, JKB a écrit :
Le Fri, 03 Jan 2014 11:56:30 +0100,
Toxico Nimbus <toxn@free.fr> écrivait :
Le 03/01/2014 11:34, Moreira David a écrit :
JKB <jkb@koenigsberg.invalid> writes:
Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :
After serious thinking Trolleur Polémiqueur wrote :
Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Non (où alors il faut préciser). Le noyau n'est appelé que
lorsqu'une application lui rend la main par un yield(). Ça ressemble
fort à du Contiki, rien de plus. Un système multitâche possède un
scheduler. C'est le minimum vital.
Un système multitâche permet à plusieurs tâches de fonctionner
apparemment simultanément. Au passage, c'est n'est pas parce que le
multitâche est coopératif qu'il n'y a pas d'ordonnanceur.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
OSEF.
Sauf si c'est réellement meilleur. Mais casser la rétrocompatibilité
n'est que très rarement bon, pour ne pas dire jamais.
Et pourtant dans le monde GNU/Linux, les changement d'ABI sont courant.
D'ABI. Pas de l'API de la libc.
Dans le cas de la libc, l'API est en grand partie normalisée, c'est
encore heureux qu'elle ne change pas trop.
Le 03/01/2014 12:19, JKB a écrit :Le Fri, 03 Jan 2014 11:56:30 +0100,
Toxico Nimbus écrivait :Le 03/01/2014 11:34, Moreira David a écrit :JKB writes:Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Non (où alors il faut préciser). Le noyau n'est appelé que
lorsqu'une application lui rend la main par un yield(). Ça ressemble
fort à du Contiki, rien de plus. Un système multitâche possède un
scheduler. C'est le minimum vital.
Un système multitâche permet à plusieurs tâches de fonctionner
apparemment simultanément. Au passage, c'est n'est pas parce que le
multitâche est coopératif qu'il n'y a pas d'ordonnanceur.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
OSEF.
Sauf si c'est réellement meilleur. Mais casser la rétrocompatibilité
n'est que très rarement bon, pour ne pas dire jamais.
Et pourtant dans le monde GNU/Linux, les changement d'ABI sont courant.
D'ABI. Pas de l'API de la libc.
Dans le cas de la libc, l'API est en grand partie normalisée, c'est
encore heureux qu'elle ne change pas trop.
Toxico Nimbus submitted this idea :Le 03/01/2014 12:12, Moreira David a écrit :Toxico Nimbus writes:Le 03/01/2014 11:34, Moreira David a écrit :JKB writes:Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche.. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Pardon, je devais rajouter un utilisable ?
MacOS a longtemps fonctionné avec un multitâche coopératif et était
utilisable. Si un environnement multitâche coopératif n'est pas utilisable,
c'est forcément la faute d'une appli mal codée ou d'un driver pourri (genre
CPU-poll trop agressif).
Le nombre d'utilisateur de Mac OS 7 qui ne juraient que par le
multitâche de leur système ;>)
Avec raison, les développeurs faisient plus attention que sous Windows
Toxico Nimbus submitted this idea :
Le 03/01/2014 12:12, Moreira David a écrit :
Toxico Nimbus <toxn@free.fr> writes:
Le 03/01/2014 11:34, Moreira David a écrit :
JKB <jkb@koenigsberg.invalid> writes:
Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :
After serious thinking Trolleur Polémiqueur wrote :
Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche.. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Pardon, je devais rajouter un utilisable ?
MacOS a longtemps fonctionné avec un multitâche coopératif et était
utilisable. Si un environnement multitâche coopératif n'est pas utilisable,
c'est forcément la faute d'une appli mal codée ou d'un driver pourri (genre
CPU-poll trop agressif).
Le nombre d'utilisateur de Mac OS 7 qui ne juraient que par le
multitâche de leur système ;>)
Avec raison, les développeurs faisient plus attention que sous Windows
Toxico Nimbus submitted this idea :Le 03/01/2014 12:12, Moreira David a écrit :Toxico Nimbus writes:Le 03/01/2014 11:34, Moreira David a écrit :JKB writes:Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche.. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Pardon, je devais rajouter un utilisable ?
MacOS a longtemps fonctionné avec un multitâche coopératif et était
utilisable. Si un environnement multitâche coopératif n'est pas utilisable,
c'est forcément la faute d'une appli mal codée ou d'un driver pourri (genre
CPU-poll trop agressif).
Le nombre d'utilisateur de Mac OS 7 qui ne juraient que par le
multitâche de leur système ;>)
Avec raison, les développeurs faisient plus attention que sous Windows
Le Fri, 03 Jan 2014 12:36:40 +0100,
Toxico Nimbus écrivait :Le 03/01/2014 12:19, JKB a écrit :Le Fri, 03 Jan 2014 11:56:30 +0100,
Toxico Nimbus écrivait :Le 03/01/2014 11:34, Moreira David a écrit :JKB writes:Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Non (où alors il faut préciser). Le noyau n'est appelé que
lorsqu'une application lui rend la main par un yield(). Ça ressemble
fort à du Contiki, rien de plus. Un système multitâche possède un
scheduler. C'est le minimum vital.
Un système multitâche permet à plusieurs tâches de fonctionner
apparemment simultanément. Au passage, c'est n'est pas parce que le
multitâche est coopératif qu'il n'y a pas d'ordonnanceur.
Ce n'est pas ce qu'on appelle généralement un ordonnanceur. C'est une
liste de tâches. yield() permet de passer à la suivante. Contiki
utilise ce genre de chose (comme Windows durant la grande époque).
Qualifier ça d'ordonnanceur est osé mais c'est ton droit.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
OSEF.
Sauf si c'est réellement meilleur. Mais casser la rétrocompatibilité
n'est que très rarement bon, pour ne pas dire jamais.
Et pourtant dans le monde GNU/Linux, les changement d'ABI sont courant.
D'ABI. Pas de l'API de la libc.
Dans le cas de la libc, l'API est en grand partie normalisée, c'est
encore heureux qu'elle ne change pas trop.
C'est un peu le but. Et c'est ce qui fait cruellement défaut à
Windows.
Le Fri, 03 Jan 2014 12:36:40 +0100,
Toxico Nimbus <toxn@free.fr> écrivait :
Le 03/01/2014 12:19, JKB a écrit :
Le Fri, 03 Jan 2014 11:56:30 +0100,
Toxico Nimbus <toxn@free.fr> écrivait :
Le 03/01/2014 11:34, Moreira David a écrit :
JKB <jkb@koenigsberg.invalid> writes:
Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :
After serious thinking Trolleur Polémiqueur wrote :
Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Non (où alors il faut préciser). Le noyau n'est appelé que
lorsqu'une application lui rend la main par un yield(). Ça ressemble
fort à du Contiki, rien de plus. Un système multitâche possède un
scheduler. C'est le minimum vital.
Un système multitâche permet à plusieurs tâches de fonctionner
apparemment simultanément. Au passage, c'est n'est pas parce que le
multitâche est coopératif qu'il n'y a pas d'ordonnanceur.
Ce n'est pas ce qu'on appelle généralement un ordonnanceur. C'est une
liste de tâches. yield() permet de passer à la suivante. Contiki
utilise ce genre de chose (comme Windows durant la grande époque).
Qualifier ça d'ordonnanceur est osé mais c'est ton droit.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
OSEF.
Sauf si c'est réellement meilleur. Mais casser la rétrocompatibilité
n'est que très rarement bon, pour ne pas dire jamais.
Et pourtant dans le monde GNU/Linux, les changement d'ABI sont courant.
D'ABI. Pas de l'API de la libc.
Dans le cas de la libc, l'API est en grand partie normalisée, c'est
encore heureux qu'elle ne change pas trop.
C'est un peu le but. Et c'est ce qui fait cruellement défaut à
Windows.
Le Fri, 03 Jan 2014 12:36:40 +0100,
Toxico Nimbus écrivait :Le 03/01/2014 12:19, JKB a écrit :Le Fri, 03 Jan 2014 11:56:30 +0100,
Toxico Nimbus écrivait :Le 03/01/2014 11:34, Moreira David a écrit :JKB writes:Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Non (où alors il faut préciser). Le noyau n'est appelé que
lorsqu'une application lui rend la main par un yield(). Ça ressemble
fort à du Contiki, rien de plus. Un système multitâche possède un
scheduler. C'est le minimum vital.
Un système multitâche permet à plusieurs tâches de fonctionner
apparemment simultanément. Au passage, c'est n'est pas parce que le
multitâche est coopératif qu'il n'y a pas d'ordonnanceur.
Ce n'est pas ce qu'on appelle généralement un ordonnanceur. C'est une
liste de tâches. yield() permet de passer à la suivante. Contiki
utilise ce genre de chose (comme Windows durant la grande époque).
Qualifier ça d'ordonnanceur est osé mais c'est ton droit.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
OSEF.
Sauf si c'est réellement meilleur. Mais casser la rétrocompatibilité
n'est que très rarement bon, pour ne pas dire jamais.
Et pourtant dans le monde GNU/Linux, les changement d'ABI sont courant.
D'ABI. Pas de l'API de la libc.
Dans le cas de la libc, l'API est en grand partie normalisée, c'est
encore heureux qu'elle ne change pas trop.
C'est un peu le but. Et c'est ce qui fait cruellement défaut à
Windows.
Toxico Nimbus , dans le message <52c694cb$0$2271$,
a écrit :Je suppose tables indexées, donc relationnel. Si tu veux mettre une
Donc tu te trompes.
étiquette base de données réseau sur ta collection de structure avec de
pointeurs, pourquoi pas, dans l'absolu c'est légitime. Mais dans ce cas,
où situes-tu la limite entre simple logiciel et base de données ?
Quand il y des données à stocker.
Toxico Nimbus , dans le message <52c694cb$0$2271$426a74cc@news.free.fr>,
a écrit :
Je suppose tables indexées, donc relationnel. Si tu veux mettre une
Donc tu te trompes.
étiquette base de données réseau sur ta collection de structure avec de
pointeurs, pourquoi pas, dans l'absolu c'est légitime. Mais dans ce cas,
où situes-tu la limite entre simple logiciel et base de données ?
Quand il y des données à stocker.
Toxico Nimbus , dans le message <52c694cb$0$2271$,
a écrit :Je suppose tables indexées, donc relationnel. Si tu veux mettre une
Donc tu te trompes.
étiquette base de données réseau sur ta collection de structure avec de
pointeurs, pourquoi pas, dans l'absolu c'est légitime. Mais dans ce cas,
où situes-tu la limite entre simple logiciel et base de données ?
Quand il y des données à stocker.
Le 03/01/2014 12:53, JKB a écrit :Le Fri, 03 Jan 2014 12:36:40 +0100,
Toxico Nimbus écrivait :Le 03/01/2014 12:19, JKB a écrit :Le Fri, 03 Jan 2014 11:56:30 +0100,
Toxico Nimbus écrivait :Le 03/01/2014 11:34, Moreira David a écrit :JKB writes:Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Non (où alors il faut préciser). Le noyau n'est appelé que
lorsqu'une application lui rend la main par un yield(). Ça ressemble
fort à du Contiki, rien de plus. Un système multitâche possède un
scheduler. C'est le minimum vital.
Un système multitâche permet à plusieurs tâches de fonctionner
apparemment simultanément. Au passage, c'est n'est pas parce que le
multitâche est coopératif qu'il n'y a pas d'ordonnanceur.
Ce n'est pas ce qu'on appelle généralement un ordonnanceur. C'est une
liste de tâches. yield() permet de passer à la suivante. Contiki
utilise ce genre de chose (comme Windows durant la grande époque).
Qualifier ça d'ordonnanceur est osé mais c'est ton droit.
Je ne sais pas les détails d'implémentation des ordonnanceurs de Windows
3 et MacOS, mais le coopératif n'empêche pas d'avoir des priorités,
éventuellement dynamiques, il y a tout un monde au delà de round-robin.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
OSEF.
Sauf si c'est réellement meilleur. Mais casser la rétrocompatibilité
n'est que très rarement bon, pour ne pas dire jamais.
Et pourtant dans le monde GNU/Linux, les changement d'ABI sont courant.
D'ABI. Pas de l'API de la libc.
Dans le cas de la libc, l'API est en grand partie normalisée, c'est
encore heureux qu'elle ne change pas trop.
C'est un peu le but. Et c'est ce qui fait cruellement défaut à
Windows.
C'est un défaut ou une "feature". Si une API normalisée avait un intérêt
commercial pour Microsoft, elle existerait. Au lieu de cela, ils ont
simplement abandonné leur couche de "compatibilité" POSIX.
Le 03/01/2014 12:53, JKB a écrit :
Le Fri, 03 Jan 2014 12:36:40 +0100,
Toxico Nimbus <toxn@free.fr> écrivait :
Le 03/01/2014 12:19, JKB a écrit :
Le Fri, 03 Jan 2014 11:56:30 +0100,
Toxico Nimbus <toxn@free.fr> écrivait :
Le 03/01/2014 11:34, Moreira David a écrit :
JKB <jkb@koenigsberg.invalid> writes:
Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :
After serious thinking Trolleur Polémiqueur wrote :
Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Non (où alors il faut préciser). Le noyau n'est appelé que
lorsqu'une application lui rend la main par un yield(). Ça ressemble
fort à du Contiki, rien de plus. Un système multitâche possède un
scheduler. C'est le minimum vital.
Un système multitâche permet à plusieurs tâches de fonctionner
apparemment simultanément. Au passage, c'est n'est pas parce que le
multitâche est coopératif qu'il n'y a pas d'ordonnanceur.
Ce n'est pas ce qu'on appelle généralement un ordonnanceur. C'est une
liste de tâches. yield() permet de passer à la suivante. Contiki
utilise ce genre de chose (comme Windows durant la grande époque).
Qualifier ça d'ordonnanceur est osé mais c'est ton droit.
Je ne sais pas les détails d'implémentation des ordonnanceurs de Windows
3 et MacOS, mais le coopératif n'empêche pas d'avoir des priorités,
éventuellement dynamiques, il y a tout un monde au delà de round-robin.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
OSEF.
Sauf si c'est réellement meilleur. Mais casser la rétrocompatibilité
n'est que très rarement bon, pour ne pas dire jamais.
Et pourtant dans le monde GNU/Linux, les changement d'ABI sont courant.
D'ABI. Pas de l'API de la libc.
Dans le cas de la libc, l'API est en grand partie normalisée, c'est
encore heureux qu'elle ne change pas trop.
C'est un peu le but. Et c'est ce qui fait cruellement défaut à
Windows.
C'est un défaut ou une "feature". Si une API normalisée avait un intérêt
commercial pour Microsoft, elle existerait. Au lieu de cela, ils ont
simplement abandonné leur couche de "compatibilité" POSIX.
Le 03/01/2014 12:53, JKB a écrit :Le Fri, 03 Jan 2014 12:36:40 +0100,
Toxico Nimbus écrivait :Le 03/01/2014 12:19, JKB a écrit :Le Fri, 03 Jan 2014 11:56:30 +0100,
Toxico Nimbus écrivait :Le 03/01/2014 11:34, Moreira David a écrit :JKB writes:Le Fri, 03 Jan 2014 01:27:19 +0100,
P4nd1-P4nd4 <P4nd1-P4nd4@> écrivait :After serious thinking Trolleur Polémiqueur wrote :Je pense que ce qui était justifié c'était l'ajout du premier
windows avec ms
dos
Je sais que ms depuis windows 95 fait de l'artifice
La super blonde américaine qui se maquille de plus en plus au fur
et a mesure
qu'elle vieillie
Je vois que tu ne connait rien du tout à la technique des systèmes...
Win95 (et partiellement Win3.11 Workgroup) mettait en place une
architecture basée sur Win32 qui s'affranchissait de DOS, même si ces
systèmes bootaient dessus.
En effet, les logicies dans l'environnement Windows héritaient de
possibilités qui n'avaient plus aucun rapport avec MSDOS..., notamment
en terme de gestion de mémoire et de multitâche, puisque MSDOS n'était
pas multitâche...
Je t'arrête tout de suite. W3.11 n'était pas multitâche. Pas plus
que W95 lorsqu'on le regarde de près. W95 était tellement multitâche
qu'un accès à un périphérique lent (au hasard la disquette) gelait
toutes les autres tâches !
Microsoft disait que 3.1 était multi-tâche car il implémenter le syscall
yeld. Il fallait donc que l'application apelle de temps en temps ce
syscall.
Ce n'est donc pas un réel multi-tâche.
Un multitâche coopératif est réellement un multitâche.
Non (où alors il faut préciser). Le noyau n'est appelé que
lorsqu'une application lui rend la main par un yield(). Ça ressemble
fort à du Contiki, rien de plus. Un système multitâche possède un
scheduler. C'est le minimum vital.
Un système multitâche permet à plusieurs tâches de fonctionner
apparemment simultanément. Au passage, c'est n'est pas parce que le
multitâche est coopératif qu'il n'y a pas d'ordonnanceur.
Ce n'est pas ce qu'on appelle généralement un ordonnanceur. C'est une
liste de tâches. yield() permet de passer à la suivante. Contiki
utilise ce genre de chose (comme Windows durant la grande époque).
Qualifier ça d'ordonnanceur est osé mais c'est ton droit.
Je ne sais pas les détails d'implémentation des ordonnanceurs de Windows
3 et MacOS, mais le coopératif n'empêche pas d'avoir des priorités,
éventuellement dynamiques, il y a tout un monde au delà de round-robin.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
OSEF.
Sauf si c'est réellement meilleur. Mais casser la rétrocompatibilité
n'est que très rarement bon, pour ne pas dire jamais.
Et pourtant dans le monde GNU/Linux, les changement d'ABI sont courant.
D'ABI. Pas de l'API de la libc.
Dans le cas de la libc, l'API est en grand partie normalisée, c'est
encore heureux qu'elle ne change pas trop.
C'est un peu le but. Et c'est ce qui fait cruellement défaut à
Windows.
C'est un défaut ou une "feature". Si une API normalisée avait un intérêt
commercial pour Microsoft, elle existerait. Au lieu de cela, ils ont
simplement abandonné leur couche de "compatibilité" POSIX.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.
Pour info, Apple travaille aussi sur un nouveau système qui devrait
mettre de côté l'architecture UNIX.