# Os 9 usb



## Vivid (4 Mars 2008)

Bonjour,

je suis pas foutue de trouver de la doc pour Os 9 sur tout ce qui touche a l'USB, si quelqu'un a des liens!


----------



## Didier Guillion (4 Mars 2008)

Vivid a dit:


> Bonjour,
> 
> je suis pas foutue de trouver de la doc pour Os 9 sur tout ce qui touche a l'USB, si quelqu'un a des liens!



Ceci je pense :
ftp://ftp.apple.com/developer/Development_Kits/Mac_OS_USB/USB_DDK_1.5.5f1.img.sea.hqx

Cordialement


----------



## Céroce (4 Mars 2008)

Y'a encore des gens sous Mac OS 9 ?!


----------



## Didier Guillion (4 Mars 2008)

Céroce a dit:


> Y'a encore des gens sous Mac OS 9 ?!



Dans certains domaines, plus sur Mac OS 9.2 que sur Mac OS X 10.0

Cordialement


----------



## Vivid (4 Mars 2008)

Céroce a dit:


> Y'a encore des gens sous Mac OS 9 ?!



oui ! c'est super tendance, viendez! 



merci Didier, je l'oublie souvent ce ftp.


----------



## Leyry Hynemonth (4 Mars 2008)

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.


----------



## tatouille (4 Mars 2008)

printing press, , c est vrai que leo est plutot gourmand comme OS
c est une vilaine goulue coquine qui suce un max


----------



## Céroce (5 Mars 2008)

Vivid a dit:


> oui ! c'est super tendance, viendez!


Ah non! J'ai vraiment trop galèré sur Mac OS 7, vive Cocoa!


----------



## Vivid (5 Mars 2008)

Céroce a dit:


> Ah non! J'ai vraiment trop galèré sur Mac OS 7, vive Cocoa!



Et bien voila un sujet qu'il est bon!

Si tu peut être précis pour pouvoir comparer.


----------



## grumff (6 Mars 2008)

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.


----------



## Céroce (6 Mars 2008)

Vivid a dit:


> Et bien voila un sujet qu'il est bon!
> 
> Si tu peut être précis pour pouvoir comparer.



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.


----------



## Vivid (6 Mars 2008)

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:
> ...



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 . 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 (6 Mars 2008)

Qu'est ce que vous appellez extensions ? Les extensions de fichiers ? Pourquoi on ne le gère plus ?

Cordialement


----------



## Vivid (6 Mars 2008)

Didier Guillion a dit:


> Qu'est ce que vous appellez extensions ? Les extensions de fichiers ? Pourquoi on ne le gère plus ?
> 
> Cordialement



(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.


----------



## Didier Guillion (6 Mars 2008)

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


----------



## tatouille (6 Mars 2008)

"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


----------



## Didier Guillion (6 Mars 2008)

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


----------



## grumff (6 Mars 2008)

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.


----------



## tatouille (6 Mars 2008)

tu preches chez des convertis et des Nix nerds 


```
.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


----------



## Didier Guillion (6 Mars 2008)

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


----------



## Vivid (7 Mars 2008)

tatouille a dit:


> 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



Intel connait pas.

par rapport au PPC si tu as des commentaires, n'hesite pas


----------



## Céroce (10 Mars 2008)

Didier Guillion a dit:


> 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.


Ah bon Didier, tu fais tes interfaces utilisateur avec QT ou WxWidget? 

Le seul avantage de Carbon sur Cocoa, c'est qu'elle est compatible avec Mac OS 9. Toutefois, ça fait quand même 7 ans que MacOS X 10.0 est sorti, et le pourcentage d'utilisateurs sous Mac OS 9 doit quand même être super faible. Vue la différence de temps de développement entre les deux environnements (un facteur 10, je dirais), le choix économique est vite fait.

Didier, je conçois toutefois que vu le profil de tes utilisateurs (musiciens amateurs, pas forcément des gens qui changent de machine tous les 3 ans) et l'ancienneté du logiciel, que le re-développement avec Cocoa n'est pas économiquement intéressant. As-tu toutefois une idée du pourcentage d'utilisateurs sous OS 9 ?


----------



## Didier Guillion (10 Mars 2008)

Sur Mac OS 9, je dirait 10%. Mais pas mal de personnes ont Mac OS X plus un portable sur Mac OS 9 pour composer en déplacement.

Pour certaines appli, j'utilise Cocoa, mais plutot pour des Freeware. Je n'ai absolument pas confiance à la perennité des technos Apple, surtout quand elles sont fermées. J'en ai trop vu passer à la "trappe" sans préavis (MPW) ou qui ne voyaient venir aucune amélioration (AppleScript Studio).

A ma connaissance, le format des ressources NIB est toujours fermé, donc, difficilement portable sur une autre plateforme. Développer une appli sur Mac OS et Windows demanderait donc de rédéfinir entièrement les objets de l'interface ce qui est impensable quand l'appli devient un peu importante. Par exemple, mes appli ont chacune environ 300-400 boites de dialogues en 8 langues...

Note que j'ai fait des trucs en Cocoa+OBJ-C et je trouve ca pas mal du tout, bien que la syntaxe d'OBJ-C soit assez prise de tete parfois. Je prefère la verbosité d'AppleScript ou la concission du C, Java ou Perl.
J'admire ceux qui se lancent dans des applis complete Cocoa pur mais je ne prendrait pas ce risque, je veut que mes applis tournent encore dans 10 ans et puisse être adaptés facilement aux plateformes futures.


Cordialement


----------



## Luc G (10 Mars 2008)

Didier Guillion a dit:


> 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.



Je rebondis sur ton message : tu confirmes que c'est toujours le souk pour déboguer sous applescript studio avec xcode 3 si tu l'as essayé ?

J'ai quelques velléités de reprendre une ou deux petites applis hypercard vu que ça devient dur pour les faire touner sur macintel ! (et plus si affinités ) sous applescript studio. Pour faire l'interface, c'est assez sympa pour mes besoins, pour le langage idem quand la vitesse ne joue pas (pour les procédures gourmandes, des petites externes de calcul en pascal sous hypercard, je pense faire du C bête malgré mon allergie malheureuse mais incontournable à la syntaxe C). J'espère que l'absence de débogueur ne me perturbera pas trop vu mes besoins. Ceci dit, ça relève plus du jeu et d'une velléité (j'aime bien ce mot ) de rester un minimum branché sur la programmation que d'un besoin crucial.

C'est vrai que notre Steve a une fâcheuse tendance à jeter le bébé avec l'eau du bain plus souvent qu'à son tour.

Ceci dit, Galerie est toujours un régal et ne m'a pas posé de problème pour l'instant même avec Léopard et iphoto 7 (ilife 8).


----------



## Didier Guillion (10 Mars 2008)

C'est toujours le Souk. Je n'arrive toujours pas a faire fonctionner le déboggeur sous AppleScript.
La moindre correction qui se ferait en 5 mn, Hop ! point d'arret, Boum ! les variables,Zou! on corrige devient une prise de tete de demi-journée avec truffage du code du Log.

Une discussion houleuse sur le forum Apple d'AppleScript a eut lieu à ce sujet. J'ai pas tout compris mais grosso modo, les devs demandaient à Apple s'ils continuaient à vouloir faire progresser ou non.


Cordialement


----------



## Céroce (10 Mars 2008)

J'ai cru qu'avec l'arrivée d'Automator sous OS 10.4, ils amélioreraient un peu AppleScript, mais en effet, tout cela semble bien à l'abandon (et pourtant, toutes les applis utilisant les bindings Cocoa profitent automatiquement d'AppleScript).


----------



## Luc G (10 Mars 2008)

c'est vrai que devoir coller des log partout, c'est plus que pénible.
À croire que Apple, qui voulait faire sauter applescript lors de la préparation d'OSX et était revenu sur ses pas au dernier moment, n'a pas abandonné l'idée, sinon de le supprimer, du moins d'en dégoûter les gens 

Et pourtant, avec Hypercard dans le temps ou avec un bon applescript studio, il y a de quoi permettre à plein de gens de faire des petits trucs en programmation, certes différents des grosses applis pro mais très utiles. Je pense à tout ce qui est éducation et à plein de petites niches dans le domaine pro (par exemple, parce que je connais un peu  ce domaine, le traitement  de données de mesure).

Reste plus qu'à espérer que le balancier reparte un peu du bon côté (je pense que l'iphone a bouffé beaucoup de ressources R&D chez Apple depuis un bon moment).


----------

