Os 9 usb

  • Créateur du sujet Créateur du sujet Vivid
  • Date de début Date de début
Dans certains cas, c'est follement pratique : L'autonomie de mon iBook palourde par exemple.

Batterie neuve + OS 9 + peux d'extensions + Luminosité au minimum - AirPort + Calepin pour la prise de note en cours = 8h30 d'autonomie... (et encore, après 3h30 de notes, il m'affichait 6h)
Idem avec OS 10.3...... ben c'est la fin des haricots.
 
Il y a bien quelques petites choses sous mac os 9 que mac os x n'est toujours pas capable de faire. En terme de réactivité par exemple, on a beaucoup perdu avec aqua et le tout en 3D. ;) Il faut 2,5 secondes minimum pour ouvrir une pile bien remplie sous forme d'icône sous Leopard sur un mbp à 2,5Ghz, alors que mac os 9 ouvrait une fenêtre tiroir (qui est fonctionnellement équivalente) en instantané sur n'importe quelle vieille machine.
Même s'il avait quelques défauts, et pas mal de choses en moins, mac os 9 (et depuis le 7.5) était un système très correct. Je dirais même qu'en terme d'ergonomie il surpasse n'importe quel windows récent, vista compris. Peut-être pas en terme de stabilité, certes.

Mais on s'écarte du sujet. ;)
 
Vivid a dit:
Et bien voila un sujet qu'il est bon!

Si tu peut être précis pour pouvoir comparer. :zen:
Cliquez pour agrandir...

En fait, sous Mac OS 7 (et MacOS 9, c'est un peu pareil, même s'il y a eu des améliorations), tout était très compliqué. En gros tu avais deux choix de développement:

Soit tout programmer à la mano
Avec les fonctions de la Toolbox. Exemple, pour savoir si un clic a eu lieu sur un bouton:
- Boucler en sondant la fonction pour obtenir les évènements
- Regarder si l'évènement est un clic
- Regarder dans quelle fenêtre le clic s'est produit (la barre de menu est aussi une fenêtre)
- Convertir les coordonnées globales en coordonnées locales à la fenêtre
- Clic dans le bouton -> On exécute le code correspondant

Tout est aussi compliqué avec la Toolbox, même simplement ajouter un gros cadre autour du bouton par défaut. Et je ne vous parle pas du patch nécessaire pour afficher des palettes flottantes (point qui a été amélioré sous Mac OS 9).

Soit utiliser PowerPlant (ou MacApp):
- Là, c'est plus simple: on programme en C++, alors on fait hériter le bouton de la classe semi-abstraite Bouton et on ajoute le code correspondant.
Et là on obtient une application qui fait 3 Mo.

Il s'agit d'une approche à la Visual C++ sous Windows: on hérite de tout. A la fin, on a un code énorme et très compliqué à mettre à jour.


Sous Cocoa:
- Hériter de l'objet NSObject
- Ajouter une méthode pour répondre à l'action sur le bouton
- sous Interface Builder, relier la méthode au bouton

Cet exemple n'est pas très probant, mais la méthode Cocoa est plus flexible. De plus, on programme en Objective-C qui est bien plus élégant que C++.


Le débat "Mac OS X est-il mieux que Mac OS 9" est un autre débat. Personnellement, je ne me suis jamais fait au Dock que je trouve très inférieur au menu Applications d'OS 9. A côté de ça, on ne gère plus les extensions (et dieu sait que c'était emmerdant), ni la mémoire allouée à chaque application.
 
Céroce a dit:
En fait, sous Mac OS 7 (et MacOS 9, c'est un peu pareil, même s'il y a eu des améliorations), tout était très compliqué. En gros tu avais deux choix de développement:

Soit tout programmer à la mano
Avec les fonctions de la Toolbox. Exemple, pour savoir si un clic a eu lieu sur un bouton:
- Boucler en sondant la fonction pour obtenir les évènements
- Regarder si l'évènement est un clic
- Regarder dans quelle fenêtre le clic s'est produit (la barre de menu est aussi une fenêtre)
- Convertir les coordonnées globales en coordonnées locales à la fenêtre
- Clic dans le bouton -> On exécute le code correspondant

Tout est aussi compliqué avec la Toolbox, même simplement ajouter un gros cadre autour du bouton par défaut. Et je ne vous parle pas du patch nécessaire pour afficher des palettes flottantes (point qui a été amélioré sous Mac OS 9).

Soit utiliser PowerPlant (ou MacApp):
- Là, c'est plus simple: on programme en C++, alors on fait hériter le bouton de la classe semi-abstraite Bouton et on ajoute le code correspondant.
Et là on obtient une application qui fait 3 Mo.

Il s'agit d'une approche à la Visual C++ sous Windows: on hérite de tout. A la fin, on a un code énorme et très compliqué à mettre à jour.


Sous Cocoa:
- Hériter de l'objet NSObject
- Ajouter une méthode pour répondre à l'action sur le bouton
- sous Interface Builder, relier la méthode au bouton

Cet exemple n'est pas très probant, mais la méthode Cocoa est plus flexible. De plus, on programme en Objective-C qui est bien plus élégant que C++.


Le débat "Mac OS X est-il mieux que Mac OS 9" est un autre débat. Personnellement, je ne me suis jamais fait au Dock que je trouve très inférieur au menu Applications d'OS 9. A côté de ça, on ne gère plus les extensions (et dieu sait que c'était emmerdant), ni la mémoire allouée à chaque application.
Cliquez pour agrandir...

c'est vrai au début, c'est rude ! x lignes pour gerer une fenêtre.. les événements, mais c'est comme tout il faut un minimum 'd'investissement', de plus une fois que tu l'a écrit...
on va me dire, comme avec Objective C! certe mais le C ou l'asm me suffit, un peu de rigeur..

Maintenant Objective C comme d'autre POO sont des 'gestionnaires' de données, l'ancienne méthode me convient toujours : routine avec en entrée... en sortie..
jaime les langages non verbeux, style C, asm, mais demande plus de vigilance mais te donne aussi plus de satisfaction. Plus c'est dur plus c'est bon :D. Mon esprit reste plus proche de la machine. Ce qui est pour certain une horreur (langage dit de bas niveau) reste pour moi un plaisir.

Je pousse pas l'esprit du Mac (ergonomie, facilitée d'utilisation) juqu'a la façon de programmer.

Economiquement faut aller vite, mais je suis pas dans ce registre, moi je 'déguste' :).

pour ce qui est de;

"A côté de ça, on ne gère plus les extensions (et dieu sait que c'était emmerdant), ni la mémoire allouée à chaque application."
jaime pas les gens qui pense pour moi en me soustraillant des libertées. Que l'on 'cache' pour l'utilisateur lambda, histoire de ne pas l'effayé, ok, mais en laisser l'accés c'est mieux. Les extensions = modularitée ce n'est pas parceque il y avait des conflits possible (l'erreur est humaine) qu'il faut jeter le bébé avec l'eau du bain. Idem pour le reste. Maintenant pour ces deux exemples, cela reste peut-être possible sous X, je ne sais pas!

tout ca cela ne fait pas avancer le shimblik, une question de goût. Désoler :(

ps:Mille excuses pour les fautes.
 
Didier Guillion a dit:
Qu'est ce que vous appellez extensions ? Les extensions de fichiers ? Pourquoi on ne le gère plus ?

Cordialement
Cliquez pour agrandir...

(un peu hors sujet), les extensions; les 'programmes' qui ce charge avec le système pour lui rajouter des 'possibilitées' opentransport, quicktime... sous Os 9.

:)
 
Ah, d'accord, merci !

Je trouvait cela sympa les extensions. J'en avait écrite une qui "trappait" les acces aux fichiers et faisait automatiquement des copies de sécurité afin que l'on puisse revenir à n'importe laquelle des versions, cela s'appellait "Baker". Ca a pas mal marché à l'époque.

Mais bon, la seule chose que je ne regrette pas de Mac OS 9 c'est la gestion mémoire, obligé de "locker"-"unlocker" les zones, c'était casse pieds. De plus sur Mac OS X, une application ne peut en "crasher" une autre, et ca c'est cool.
Par contre, niveau réactivité, et en tenant compte de la vitesse des processeurs de l'époque et ceux de maintenant, on a fait un grand bon en arrière. Chaque fois que je redémarre mon petit SE, je suis surpris...

Cordialement
 
"locker"-"unlocker" , c est toujours vrai mais c est le system qui le fait, mais ca depend ce que tu utilises
par exemple si tu vm_wire avec un mod en VM_PROT_READ | VM_PROT_WRITE c est preferable de locker
pendant les operations d ecritures et de lectures que tu vas faire et puis de relacher ensuite, ca depend a quel niveau de l api system tu te situes
 
Rassure toi, a un niveau suffisamment élevé pour ne plus avoir à me préoccuper de tout cela.
Le développement des pilotes ou autres modules près du système, ce n'est plus ma tasse de thé...
Je cherche au contraire à m'en éloigner le plus possible pour pouvoir l'ignorer.


Cordialement
 
Sur le débat mac os 9/mac os x, je crois qu'il faut pas exagérer non plus, mac os x est un énorme pas en avant, un système bien mieux élaboré, bien plus complet, la mémoire protégée, du vrai multi-tache, + tous les avantages d'unix et une ergonomie encore améliorée. Disons juste qu'il y avait des points intéressants dans mac os 9 qui n'ont pas forcément tous été égalés par mac os x.

Pour ce qui est des langages de programmation haut niveau/bas niveau, je suis un peu comme vivid, j'adore le bas niveau. Mais pas au point d'aller me compliquer la tâche à écrire en assembleur un truc pour lequel les performances n'ont aucune importance et qui se ferait en 100x moins de temps en Java ou en php. L'important c'est de ne pas être prisonnier d'à priori et de toujours choisir la solution la mieux adaptée au contexte. Et c'est vrai que souvent aujourd'hui on accorde plus d'importance à la réduction des coûts de développement qu'à la performance, ce qui est tout à fait logique vu qu'on a des machines de plus en plus puissantes et de plus en plus gavées de RAM et que dans bien des cas (pas tous évidemment, et loin de là) la puissance des machines compense largement des performances moyennes.
Mais dans tous les cas et quoi qu'on utilise comme technos, savoir ce qui se passe au niveau de la machine est essentiel.
 
  • J’aime
Réactions: tatouille
:D tu preches chez des convertis et des Nix nerds :D

Bloc de code: 
.data
    msg: 
        .asciz "j'ai installé gimp 2.4.5\n"
        len = . - msg - 1       

.text
    .globl _main

_main:
    pushl   $len
    pushl   $msg
    pushl   $1
    call    _write
    addl    $12, %esp
    call     libc_exit

exit:    
    movl    $0,%ebx
    movl    $1,%eax
    pushl   $0
    pushl   $1
    int     $0x80
    
libc_exit:    
    pushl   $1
    pushl   $0
    call    _exit
tiens pour les amoureux de asm, j'ai bien sur simplifie pour le cas mais c est un truc interressant
si vous avez des explications sur (appel syms libc):

si au lieu de faire call libc_exit (appel indirect) j appel _exit j ai un segfault
dans la methode exit je suis oblige de pushl $0 et $1 pour obtenir un exit 0

j'ai trifouille ds la doc intel-apple pour voir un peu la gestion des pseudo-opts
j'ai fouille ds les sources et je n'ai pas d'explication rationnel enfin j'ai une petite idee
mais je voudrais l'avis des asm boys
:zen:
 
De l'assembleur de moins en moins, j'y touche plus. Mon médoc me l'interdit, a cause de mon coeur.
Je reste en C, bien trivial, et je continue a faire tourner des trucs que j'avais écrit en 1987 et cela me sert tous les jours.
J'ai essayé une appli avec les technos Apple 100%, il y a quelques années. AppleScript Studio, Obj-C, C. Elle s'appelle Galerie.
Mortalité, Apple est toujours incapable de fournir un déboggeur pour ce genre d'appli. Alors les technos Apple je les prends avec une pincette de trois mètres.
Tout ce qui ne marche pas avec au moins sur deux plateformes différentes, je l'ignore.


Cordialement
 

Sujets similaires

Gwen
Chat GPT et OS 9
Réponses
21
Affichages
1K
Classic Mac
Gwen
Gwen
R
Syquest comme une clé usb ?
Réponses
3
Affichages
692
Classic Mac
René-Raoul
R
K
macOS Tahoe Création d'un dossier lors de l'enregistrement d'1 doc dans dossier existant
Réponses
10
Affichages
531
macOS
Karito
K
B
iPad Différence de numéro de modèle entre la boîte d'achat et iPad OS
Réponses
4
Affichages
911
iPad
Beauchadiniou
B
B
Arobase sur mon MacBook Pro depuis un Clavier Logitech USB
Réponses
4
Affichages
790
Accessoires Mac
Moonwalker
Moonwalker
Haut Bas