[ce n'est pas un troll !] - Lenteur de Word c'est vrai ça ?
87 réponses
Aegidius
Mon gendre fort sympathique au demeurant Administrateur Réseau quant
même, un peu (voir beaucoup) allergique au Mac se plaint constamment des
lenteurs de ce dernier...
Même avec les derniers MacBookPro (Processeur Intel Core i7) RAM 4Go ...
Bien qu'il y ait une part de taquinerie entre nous, je lui dis donnes
moi un exemple de programme qui rame il me site Word bien sur il y a
mieux...
d'abord est-ce vrai ?
Et ensuite a-t-on une possibilité de booster la chose ?
> Ca s'applique à DOS également. Etonnamment pourtant, personne ne s'amuse > à soutenir que DOS n'est pas un OS.
Sans doute parce qu'on est plein de sous-marins à la solde de MS...
Non. Simplement parce que certains à l'époque n'ont pas apprécié qu'un soit prévu pour être utilisable par tout le monde, et non pas uniquement par les spécialistes. Et lui ont ainsi créé une réputation de "jouet", de "pas un vrai ordinateur" qui, bien évidemment, ne pouvait pas non plus avoir un "vrai" système d'exploitation.
Ceci dit le DOS me semble bien conçu autour d'un noyau résident en mémoire. http://www.patersontech.com/dos/byte/insidedos.htm
Mac OS était quasiment complètement résident, puisqu'il s'exécutait depuis la ROM ! A ma connaissance, quand un programme DOS était lancé, les seuls parties de l'OS qui pouvait s'exécuter était les librairies appelées par l'application et le code exécuté en réponse à des interruptions. Exactement comme sous Mac OS. A part le nom, ça n'a pas grand chose à voir avec un noyau comme il y a des un OS moderne genre Linux ou Mac OS X.
Patrick -- Patrick Stadelmann
In article <applhpFg9qiU1@mid.individual.net>,
pehache <pehache.7@gmail.com> wrote:
> Ca s'applique à DOS également. Etonnamment pourtant, personne ne s'amuse
> à soutenir que DOS n'est pas un OS.
Sans doute parce qu'on est plein de sous-marins à la solde de MS...
Non. Simplement parce que certains à l'époque n'ont pas apprécié qu'un
soit prévu pour être utilisable par tout le monde, et non pas uniquement
par les spécialistes. Et lui ont ainsi créé une réputation de "jouet",
de "pas un vrai ordinateur" qui, bien évidemment, ne pouvait pas non
plus avoir un "vrai" système d'exploitation.
Ceci dit le DOS me semble bien conçu autour d'un noyau résident en mémoire.
http://www.patersontech.com/dos/byte/insidedos.htm
Mac OS était quasiment complètement résident, puisqu'il s'exécutait
depuis la ROM ! A ma connaissance, quand un programme DOS était lancé,
les seuls parties de l'OS qui pouvait s'exécuter était les librairies
appelées par l'application et le code exécuté en réponse à des
interruptions. Exactement comme sous Mac OS. A part le nom, ça n'a pas
grand chose à voir avec un noyau comme il y a des un OS moderne genre
Linux ou Mac OS X.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
> Ca s'applique à DOS également. Etonnamment pourtant, personne ne s'amuse > à soutenir que DOS n'est pas un OS.
Sans doute parce qu'on est plein de sous-marins à la solde de MS...
Non. Simplement parce que certains à l'époque n'ont pas apprécié qu'un soit prévu pour être utilisable par tout le monde, et non pas uniquement par les spécialistes. Et lui ont ainsi créé une réputation de "jouet", de "pas un vrai ordinateur" qui, bien évidemment, ne pouvait pas non plus avoir un "vrai" système d'exploitation.
Ceci dit le DOS me semble bien conçu autour d'un noyau résident en mémoire. http://www.patersontech.com/dos/byte/insidedos.htm
Mac OS était quasiment complètement résident, puisqu'il s'exécutait depuis la ROM ! A ma connaissance, quand un programme DOS était lancé, les seuls parties de l'OS qui pouvait s'exécuter était les librairies appelées par l'application et le code exécuté en réponse à des interruptions. Exactement comme sous Mac OS. A part le nom, ça n'a pas grand chose à voir avec un noyau comme il y a des un OS moderne genre Linux ou Mac OS X.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article , pehache wrote:
"By modern standards, the original Mac OS was not an operating system at all, but a collection of application support libraries. There was nothing equating to a kernel that was responsible for mediating application access to limited resources like the CPU or hard drive. Instead, applications were placed in control of the entire system, using the libraries to handle common chores. Originally intended to support a single user running a single application at a time on a non-networked monochrome machine with a single floppy disk drive for storage and printing to a dot matrix printer, placing the applications in control of the system made sense, and allowed the developers to improve performance compared to a system with a kernel"
Tu remplaces "Mac OS" par DOS et ça reste valide. La différence c'est que le programme par défaut était sur Mac le gestionnaire de fichier (Finder) et sur DOS le shell (COMMAND.COM).
Patrick -- Patrick Stadelmann
In article <appmpnFgjkcU1@mid.individual.net>,
pehache <pehache.7@gmail.com> wrote:
"By modern standards, the original Mac OS was not an operating system at
all, but a collection of application support libraries. There was
nothing equating to a kernel that was responsible for mediating
application access to limited resources like the CPU or hard drive.
Instead, applications were placed in control of the entire system, using
the libraries to handle common chores. Originally intended to support a
single user running a single application at a time on a non-networked
monochrome machine with a single floppy disk drive for storage and
printing to a dot matrix printer, placing the applications in control of
the system made sense, and allowed the developers to improve performance
compared to a system with a kernel"
Tu remplaces "Mac OS" par DOS et ça reste valide. La différence c'est
que le programme par défaut était sur Mac le gestionnaire de fichier
(Finder) et sur DOS le shell (COMMAND.COM).
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
"By modern standards, the original Mac OS was not an operating system at all, but a collection of application support libraries. There was nothing equating to a kernel that was responsible for mediating application access to limited resources like the CPU or hard drive. Instead, applications were placed in control of the entire system, using the libraries to handle common chores. Originally intended to support a single user running a single application at a time on a non-networked monochrome machine with a single floppy disk drive for storage and printing to a dot matrix printer, placing the applications in control of the system made sense, and allowed the developers to improve performance compared to a system with a kernel"
Tu remplaces "Mac OS" par DOS et ça reste valide. La différence c'est que le programme par défaut était sur Mac le gestionnaire de fichier (Finder) et sur DOS le shell (COMMAND.COM).
Patrick -- Patrick Stadelmann
J.P
In article , pehache wrote:
> Entre le BIOS ou équivalent qui reçoit les interruptions du matériel et > les applications, il y a quelque chose, un "scheduler" quelconque, un > gestionnaire de priorités qui reçoit les requêtes des applis et attribue > le temps CPU à chacune.
Sur un système monotâche ou même multitâche coopératif, il n'y a rien de tel. Ce que tu décris c'est le multitâche préemptif.
En y regardant de plus près, c'était entre 1990 et 1993 et donc sous system 7. Wikipedia dit "System 7 made MultiFinder's co-operative multitasking mandatory". Par ailleurs, tu as peut-être raison avec le scheduler dans LabView puisque Wikipedia dit "Multi-processing and multi-threading hardware is automatically exploited by the built-in scheduler, which multiplexes multiple OS threads over the nodes ready for executions." A propos de LabView, programmation graphique pour de l'instrumentation, traitement de signal et d'image: un délice !!!
-- Jean-Pierre
In article <appmpnFgjkcU1@mid.individual.net>,
pehache <pehache.7@gmail.com> wrote:
> Entre le BIOS ou équivalent qui reçoit les interruptions du matériel et
> les applications, il y a quelque chose, un "scheduler" quelconque, un
> gestionnaire de priorités qui reçoit les requêtes des applis et attribue
> le temps CPU à chacune.
Sur un système monotâche ou même multitâche coopératif, il n'y a rien de
tel. Ce que tu décris c'est le multitâche préemptif.
En y regardant de plus près, c'était entre 1990 et 1993 et donc sous
system 7.
Wikipedia dit "System 7 made MultiFinder's co-operative multitasking
mandatory".
Par ailleurs, tu as peut-être raison avec le scheduler dans LabView
puisque Wikipedia dit "Multi-processing and multi-threading hardware is
automatically exploited by the built-in scheduler, which multiplexes
multiple OS threads over the nodes ready for executions."
A propos de LabView, programmation graphique pour de l'instrumentation,
traitement de signal et d'image: un délice !!!
> Entre le BIOS ou équivalent qui reçoit les interruptions du matériel et > les applications, il y a quelque chose, un "scheduler" quelconque, un > gestionnaire de priorités qui reçoit les requêtes des applis et attribue > le temps CPU à chacune.
Sur un système monotâche ou même multitâche coopératif, il n'y a rien de tel. Ce que tu décris c'est le multitâche préemptif.
En y regardant de plus près, c'était entre 1990 et 1993 et donc sous system 7. Wikipedia dit "System 7 made MultiFinder's co-operative multitasking mandatory". Par ailleurs, tu as peut-être raison avec le scheduler dans LabView puisque Wikipedia dit "Multi-processing and multi-threading hardware is automatically exploited by the built-in scheduler, which multiplexes multiple OS threads over the nodes ready for executions." A propos de LabView, programmation graphique pour de l'instrumentation, traitement de signal et d'image: un délice !!!
-- Jean-Pierre
yapu
pehache wrote:
>>> Même que du temps du Mac SE ou classic Apple avait décelé des boucles >>> d'attente destinée a freiner le démarrage d'Excel >> >> Source ? > > Légende urbaine, AMHA. >
C'est ce que je pense aussi, c'est pour ça que je demande une source...
je ne retrouve pas, mais c'est pour moi une certitude. les hackers mac avaient publié l'adresse de la boucle, et une rustine avait été diffusée permettant effectivement d'accéler considérablement certaines opérations.
Officieusement, des devs de MS avait prétendu que cette boucle était une temporisation de l'interface, car une réactivité trop importante pouvait générer des erreurs utilisateurs (le coup qui part avant qu'on ai bien vu ce qu'on faisait, la souris qui déclenche trop tot accidentellement, etc...)
ah, je retrouve un message de 98 :
...quand tu ajoutes une chaine "MenuShowDelay" à 0 dans Hkey_Local_Machine/Current_User/Desktop, tu t'aperçois que les sous-menus du menu "démarrer" réagissent au quart de tour. Ils bondissent au lieu de s'ouvrir au bout d'un délai intolérable. Pourquoi mettre des boucles d'attentes, alors ? Pour faire ramer les vieilles bécanes... et Windaube a toujours été plein de ces fameuses boucles...
-- Philippe Manet en fait, c'est manet avant @
pehache <pehache.7@gmail.com> wrote:
>>> Même que du temps du Mac SE ou classic Apple avait décelé des boucles
>>> d'attente destinée a freiner le démarrage d'Excel
>>
>> Source ?
>
> Légende urbaine, AMHA.
>
C'est ce que je pense aussi, c'est pour ça que je demande une source...
je ne retrouve pas, mais c'est pour moi une certitude.
les hackers mac avaient publié l'adresse de la boucle, et une rustine
avait été diffusée permettant effectivement d'accéler considérablement
certaines opérations.
Officieusement, des devs de MS avait prétendu que cette boucle était une
temporisation de l'interface, car une réactivité trop importante pouvait
générer des erreurs utilisateurs (le coup qui part avant qu'on ai bien
vu ce qu'on faisait, la souris qui déclenche trop tot accidentellement,
etc...)
ah, je retrouve un message de 98 :
...quand tu ajoutes une chaine "MenuShowDelay" à 0 dans
Hkey_Local_Machine/Current_User/Desktop, tu t'aperçois que les
sous-menus du menu "démarrer" réagissent au quart de tour. Ils
bondissent au lieu de s'ouvrir au bout d'un délai intolérable.
Pourquoi mettre des boucles d'attentes, alors ? Pour faire ramer les
vieilles bécanes... et Windaube a toujours été plein de ces fameuses
boucles...
>>> Même que du temps du Mac SE ou classic Apple avait décelé des boucles >>> d'attente destinée a freiner le démarrage d'Excel >> >> Source ? > > Légende urbaine, AMHA. >
C'est ce que je pense aussi, c'est pour ça que je demande une source...
je ne retrouve pas, mais c'est pour moi une certitude. les hackers mac avaient publié l'adresse de la boucle, et une rustine avait été diffusée permettant effectivement d'accéler considérablement certaines opérations.
Officieusement, des devs de MS avait prétendu que cette boucle était une temporisation de l'interface, car une réactivité trop importante pouvait générer des erreurs utilisateurs (le coup qui part avant qu'on ai bien vu ce qu'on faisait, la souris qui déclenche trop tot accidentellement, etc...)
ah, je retrouve un message de 98 :
...quand tu ajoutes une chaine "MenuShowDelay" à 0 dans Hkey_Local_Machine/Current_User/Desktop, tu t'aperçois que les sous-menus du menu "démarrer" réagissent au quart de tour. Ils bondissent au lieu de s'ouvrir au bout d'un délai intolérable. Pourquoi mettre des boucles d'attentes, alors ? Pour faire ramer les vieilles bécanes... et Windaube a toujours été plein de ces fameuses boucles...
-- Philippe Manet en fait, c'est manet avant @
pehache
Le 14/04/13 14:46, Philippe Manet a écrit :
pehache wrote:
Même que du temps du Mac SE ou classic Apple avait décelé des boucles d'attente destinée a freiner le démarrage d'Excel
Source ?
Légende urbaine, AMHA.
C'est ce que je pense aussi, c'est pour ça que je demande une source...
je ne retrouve pas, mais c'est pour moi une certitude. les hackers mac avaient publié l'adresse de la boucle, et une rustine avait été diffusée permettant effectivement d'accéler considérablement certaines opérations.
Officieusement, des devs de MS avait prétendu que cette boucle était une temporisation de l'interface, car une réactivité trop importante pouvait générer des erreurs utilisateurs (le coup qui part avant qu'on ai bien vu ce qu'on faisait, la souris qui déclenche trop tot accidentellement, etc...)
ah, je retrouve un message de 98 :
...quand tu ajoutes une chaine "MenuShowDelay" à 0 dans Hkey_Local_Machine/Current_User/Desktop, tu t'aperçois que les sous-menus du menu "démarrer" réagissent au quart de tour. Ils bondissent au lieu de s'ouvrir au bout d'un délai intolérable. Pourquoi mettre des boucles d'attentes, alors ? Pour faire ramer les vieilles bécanes... et Windaube a toujours été plein de ces fameuses boucles...
C'est cool, tu te cites toi-même comme source d'information :-)
Et il t'avait été répondu :
"Euh, non, faut arrêter la parano là ! ;-) C'est juste pour éviter que les sous-menus "papillonnent" comme des malades quand tu navigues dans le menu "Démarrer". Question de confort visuel. En même temps, ça évite que les bécanes faiblardes rament trop, justement."
Cette réponse me parait relativement crédible. D'ailleurs je viens de faire le test : quand je navigue dans les menus et sous-menus du Finder ou d'une appli sous Mac OS X, il y a aussi un délai d'affichage des sous-menus. Quasi-imperceptible certes, mais il y est. Alors que je suppose que mon iMac a la puissance qu'il faut pour un affichage instantané (ou perçu comme tel).
Soit-dit en passant, on n'est plus dans le cas de MS cherchant à torpiller la version Mac d'Office, là...
Le 14/04/13 14:46, Philippe Manet a écrit :
pehache <pehache.7@gmail.com> wrote:
Même que du temps du Mac SE ou classic Apple avait décelé des boucles
d'attente destinée a freiner le démarrage d'Excel
Source ?
Légende urbaine, AMHA.
C'est ce que je pense aussi, c'est pour ça que je demande une source...
je ne retrouve pas, mais c'est pour moi une certitude.
les hackers mac avaient publié l'adresse de la boucle, et une rustine
avait été diffusée permettant effectivement d'accéler considérablement
certaines opérations.
Officieusement, des devs de MS avait prétendu que cette boucle était une
temporisation de l'interface, car une réactivité trop importante pouvait
générer des erreurs utilisateurs (le coup qui part avant qu'on ai bien
vu ce qu'on faisait, la souris qui déclenche trop tot accidentellement,
etc...)
ah, je retrouve un message de 98 :
...quand tu ajoutes une chaine "MenuShowDelay" à 0 dans
Hkey_Local_Machine/Current_User/Desktop, tu t'aperçois que les
sous-menus du menu "démarrer" réagissent au quart de tour. Ils
bondissent au lieu de s'ouvrir au bout d'un délai intolérable.
Pourquoi mettre des boucles d'attentes, alors ? Pour faire ramer les
vieilles bécanes... et Windaube a toujours été plein de ces fameuses
boucles...
C'est cool, tu te cites toi-même comme source d'information :-)
Et il t'avait été répondu :
"Euh, non, faut arrêter la parano là ! ;-)
C'est juste pour éviter que les sous-menus "papillonnent" comme des
malades quand tu navigues dans le menu "Démarrer". Question de confort
visuel.
En même temps, ça évite que les bécanes faiblardes rament trop,
justement."
Cette réponse me parait relativement crédible. D'ailleurs je viens de
faire le test : quand je navigue dans les menus et sous-menus du Finder
ou d'une appli sous Mac OS X, il y a aussi un délai d'affichage des
sous-menus. Quasi-imperceptible certes, mais il y est. Alors que je
suppose que mon iMac a la puissance qu'il faut pour un affichage
instantané (ou perçu comme tel).
Soit-dit en passant, on n'est plus dans le cas de MS cherchant à
torpiller la version Mac d'Office, là...
Même que du temps du Mac SE ou classic Apple avait décelé des boucles d'attente destinée a freiner le démarrage d'Excel
Source ?
Légende urbaine, AMHA.
C'est ce que je pense aussi, c'est pour ça que je demande une source...
je ne retrouve pas, mais c'est pour moi une certitude. les hackers mac avaient publié l'adresse de la boucle, et une rustine avait été diffusée permettant effectivement d'accéler considérablement certaines opérations.
Officieusement, des devs de MS avait prétendu que cette boucle était une temporisation de l'interface, car une réactivité trop importante pouvait générer des erreurs utilisateurs (le coup qui part avant qu'on ai bien vu ce qu'on faisait, la souris qui déclenche trop tot accidentellement, etc...)
ah, je retrouve un message de 98 :
...quand tu ajoutes une chaine "MenuShowDelay" à 0 dans Hkey_Local_Machine/Current_User/Desktop, tu t'aperçois que les sous-menus du menu "démarrer" réagissent au quart de tour. Ils bondissent au lieu de s'ouvrir au bout d'un délai intolérable. Pourquoi mettre des boucles d'attentes, alors ? Pour faire ramer les vieilles bécanes... et Windaube a toujours été plein de ces fameuses boucles...
C'est cool, tu te cites toi-même comme source d'information :-)
Et il t'avait été répondu :
"Euh, non, faut arrêter la parano là ! ;-) C'est juste pour éviter que les sous-menus "papillonnent" comme des malades quand tu navigues dans le menu "Démarrer". Question de confort visuel. En même temps, ça évite que les bécanes faiblardes rament trop, justement."
Cette réponse me parait relativement crédible. D'ailleurs je viens de faire le test : quand je navigue dans les menus et sous-menus du Finder ou d'une appli sous Mac OS X, il y a aussi un délai d'affichage des sous-menus. Quasi-imperceptible certes, mais il y est. Alors que je suppose que mon iMac a la puissance qu'il faut pour un affichage instantané (ou perçu comme tel).
Soit-dit en passant, on n'est plus dans le cas de MS cherchant à torpiller la version Mac d'Office, là...
_Chap_
In article <1kz4bwr.1oca5yp1487logN%, (Anne Le Guennec) wrote:
Du coup, je sui spassée à Ragtimeet Appleworks selon mes besoins.
Voila une bonne démarche. Pourquoi s'empêtrer dans Office quand on peut faire Autrement ? J'utilise Pages la plupart du temps, et si nécessaire, j'ai installé Libre Office. C'est gratuit, et c'est pas crosoft.
Chap
In article <1kz4bwr.1oca5yp1487logN%spam.out@out.fr>,
spam.out@out.fr (Anne Le Guennec) wrote:
Du coup, je sui
spassée à Ragtimeet Appleworks selon mes besoins.
Voila une bonne démarche. Pourquoi s'empêtrer dans Office quand on peut
faire Autrement ? J'utilise Pages la plupart du temps, et si
nécessaire, j'ai installé Libre Office. C'est gratuit, et c'est pas
crosoft.
In article <1kz4bwr.1oca5yp1487logN%, (Anne Le Guennec) wrote:
Du coup, je sui spassée à Ragtimeet Appleworks selon mes besoins.
Voila une bonne démarche. Pourquoi s'empêtrer dans Office quand on peut faire Autrement ? J'utilise Pages la plupart du temps, et si nécessaire, j'ai installé Libre Office. C'est gratuit, et c'est pas crosoft.
Chap
_Chap_
In article , Patrick Stadelmann wrote:
> Après il faut voir aussi que la programmation sous Mac OS c'était un peu > spécial et assez particulier à cet OS (qui d'ailleurs n'était pas un > véritable OS, ceci expliquant cela),
Merci de ne pas troller.
Il ne trolle pas, il n'y connaît rien ;^)
In article
<Patrick.Stadelmann-02D20C.23281104032013@news.individual.net>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> Après il faut voir aussi que la programmation sous Mac OS c'était un peu
> spécial et assez particulier à cet OS (qui d'ailleurs n'était pas un
> véritable OS, ceci expliquant cela),
> Après il faut voir aussi que la programmation sous Mac OS c'était un peu > spécial et assez particulier à cet OS (qui d'ailleurs n'était pas un > véritable OS, ceci expliquant cela),
Sur windows les librairies d'Office sont chargée en mémoire dès le démarrage de l'ordi. Tant pis pour la RAM ! De toutes façons un OS microsoft ça ne sert qu'à faire tourner des softs microsoft !...
Pas toutafait, il me semble, elles sont chargées au premier lancement d'une des applications Office. C'est pour cela que le prémier lancement est toujours plus long. Tant que la session n'est pas fermée, les lancements des autres applications Office est quasi instantané.
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
In article <1kz4hsf.xxmqojvl8reoN%fra@alussinan.org>,
fra@alussinan.org (Fra) wrote:
Sur windows les librairies d'Office sont chargée en mémoire dès le
démarrage de l'ordi. Tant pis pour la RAM ! De toutes façons un OS
microsoft ça ne sert qu'à faire tourner des softs microsoft !...
Pas toutafait, il me semble, elles sont chargées au premier lancement
d'une des applications Office. C'est pour cela que le prémier lancement
est toujours plus long. Tant que la session n'est pas fermée, les
lancements des autres applications Office est quasi instantané.
--
Jacques PERROCHEAU
CNRS UMR 6226
Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
Sur windows les librairies d'Office sont chargée en mémoire dès le démarrage de l'ordi. Tant pis pour la RAM ! De toutes façons un OS microsoft ça ne sert qu'à faire tourner des softs microsoft !...
Pas toutafait, il me semble, elles sont chargées au premier lancement d'une des applications Office. C'est pour cela que le prémier lancement est toujours plus long. Tant que la session n'est pas fermée, les lancements des autres applications Office est quasi instantané.
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
