Lorsque l'on est comme moi sous Snow Leopard 10.6.8, sur mon quad-core
i5 iMac 27" mid-2010, on n'a pas le droit =E0 une mise =E0 jour de iTunes=
12.0.1, car il faut au moins OS X 10.7.5.
<http://www.apple.com/fr/itunes/download/>
=C7a veut aussi dire que je n'aurai pas le droit =E0 la mise =E0 jour de
iOS 8.1 pour mon iPhone 5, lundi. C'est dommage, hein ? Il me semble que
l'obsolescence programm=E9e est un d=E9lit du fabriquant, en France, non =
?
=C7a doit avoir un rapport, sans doute. Yosemite ne m'int=E9resse pas plu=
s
que Mavericks, car mon iMac est trop ancien, et que je n'aimerais pas
le voir partir comme mon pr=E9c=E9dent PowerMac G4 MDD, avec Leopard. J'a=
i
d=E9j=E0 eu d'immenses probl=E8mes avec Skype sur SL. Maintenant c'est iT=
unes.
Je suis d=E9=E7u par Apple ! Mon iMac n'est pourtant pas encore d=E9clar=E9=
"obsol=E8te" par Apple. Il vient juste de f=EAter ses 4 ans de service.
ATARIstiquement v=F4tre =3D)
--=20
Fran=E7ois LE COAT
<http://eureka.atari.org/>
Et ce n'est pas comme si il n'existait pas d'émulateur sous Linux, aussi : Qemu émule du x86, de l'ARM, du SPARC, du PPC, et ce sur toutes les architectures hôtes sur lesquelles tourne Linux ! Qemu en fait 100 fois plus que Rosetta... Mais comment font-ils alors que Apple juge insupportable la maintenance de Rosetta ??
Ca n'est pas Rosetta le problème, c'est les frameworks !
> Ben voyons. Evidemment qu'ils sont différents vu qu'ils n'utilisent pas > le même jeux d'instructions !
Non mais n'importe quoi, là, franchement. Tu le fais exprès pour noyer le poisson ou quoi ?
Pas du tout.
C'est le même code source, compilé pour 2 cibles différentes ! Que le code binaire soit différent est évident, mais le travail de maintenance n'est pas à faire en double !
Tout le travail de validation, si.
En effet. Mais les versions PPC des librairies était déjà validées, puisqu'elles existaient déjà dans Mac OS X PPC. Ce n'est pas comme elles étaient sorties de nulle part.
Non, justement pas, cela aurait nécessité de ne pas toucher l'interface avec les couches inférieures, et donc limiter les modifications possibles à ce niveau. Les frameworks sont ont la même versions en PowerPC et x86. Je l'avais vérifié à l'époque en désassemblant le code PowerPC de l'une d'entre-elle : on y trouve les nouvelles méthodes introduites avec 10.6.
Le code source est en grande partie identique, mais la maintenance de la version PowerPC nécessite des adaptations spécifiques et, surtout, la validation de l'ensemble des API accessibles par les applications sur une architecture supplémentaire.
> Et là en plus, les frameworks PowerPC interfacent un OS qui > n'a pas la même endianness, ce qui nécessite évidemment une couche de > compatibilité qui n'existe pas côté Intel...
Oui, et c'est précisément le travail de Rosetta de s'occuper de ce genre de choses. On l'écrit une fois ça marche pour toutes les applications, et c'est tout l'intérêt du truc.
Rosetta ne sait pas si tel bloc de donnée que le framework PowerPC passe à une fonction native dans l'OS est un tableau de byte (aucune conversion dans ce cas) où s'il s'agit de valeurs multi-octects qu'il faut permutter. Tout modification au niveau inférieur nécessite donc potentiellement d'adapter le code qui fait l'interface.
> > Il y a eu des mise à jour de sécurité qui ont rendu certains logiciels > PowerPC inopérants dans Leopard ou SL, on se demande comment cela a pu > arriver si c'est tellement simple de maintenir l'environnement PowerPC > dans Mac OS X Intel. >
De même qu'une mise à jour de sécurité peut rendre un logiciel inopérant : aucune différence.
Non, là je parle d'un effet spécifique à Rosetta, qui n'affecte pas les applications natives : ça démontre que ça n'est de loin pas aussi simple que de recompiler.
Tu n'as pas répondu à la question : trouverais-tu normal qu'un logiciel sorti en 2006 sous 10.5 ne tourne plus en 2012 sous 10.8 ?
Il ne s'agit pas de trouver ça normal ou pas. La réalité c'est qu'à chaque sortie d'un nouvel OS, il y a des applications qui ne fonctionne plus correctement. Et je rappelle que là on ne parle pas simplement d'une mise à jour de l'OS, on parle d'un changement d'architecture de l'OS.
Patrick -- Patrick Stadelmann
In article <camctqF4ho5U1@mid.individual.net>,
pehache <pehache.7@gmail.com> wrote:
Et ce n'est pas comme si il n'existait pas d'émulateur sous Linux, aussi
: Qemu émule du x86, de l'ARM, du SPARC, du PPC, et ce sur toutes les
architectures hôtes sur lesquelles tourne Linux ! Qemu en fait 100 fois
plus que Rosetta... Mais comment font-ils alors que Apple juge
insupportable la maintenance de Rosetta ??
Ca n'est pas Rosetta le problème, c'est les frameworks !
> Ben voyons. Evidemment qu'ils sont différents vu qu'ils n'utilisent pas
> le même jeux d'instructions !
Non mais n'importe quoi, là, franchement. Tu le fais exprès pour noyer
le poisson ou quoi ?
Pas du tout.
C'est le même code source, compilé pour 2 cibles différentes ! Que le
code binaire soit différent est évident, mais le travail de maintenance
n'est pas à faire en double !
Tout le travail de validation, si.
En effet. Mais les versions PPC des librairies était déjà validées,
puisqu'elles existaient déjà dans Mac OS X PPC. Ce n'est pas comme elles
étaient sorties de nulle part.
Non, justement pas, cela aurait nécessité de ne pas toucher l'interface
avec les couches inférieures, et donc limiter les modifications
possibles à ce niveau. Les frameworks sont ont la même versions en
PowerPC et x86. Je l'avais vérifié à l'époque en désassemblant le code
PowerPC de l'une d'entre-elle : on y trouve les nouvelles méthodes
introduites avec 10.6.
Le code source est en grande partie identique, mais la maintenance de la
version PowerPC nécessite des adaptations spécifiques et, surtout, la
validation de l'ensemble des API accessibles par les applications sur
une architecture supplémentaire.
> Et là en plus, les frameworks PowerPC interfacent un OS qui
> n'a pas la même endianness, ce qui nécessite évidemment une couche de
> compatibilité qui n'existe pas côté Intel...
Oui, et c'est précisément le travail de Rosetta de s'occuper de ce genre
de choses. On l'écrit une fois ça marche pour toutes les applications,
et c'est tout l'intérêt du truc.
Rosetta ne sait pas si tel bloc de donnée que le framework PowerPC passe
à une fonction native dans l'OS est un tableau de byte (aucune
conversion dans ce cas) où s'il s'agit de valeurs multi-octects qu'il
faut permutter. Tout modification au niveau inférieur nécessite donc
potentiellement d'adapter le code qui fait l'interface.
>
> Il y a eu des mise à jour de sécurité qui ont rendu certains logiciels
> PowerPC inopérants dans Leopard ou SL, on se demande comment cela a pu
> arriver si c'est tellement simple de maintenir l'environnement PowerPC
> dans Mac OS X Intel.
>
De même qu'une mise à jour de sécurité peut rendre un logiciel inopérant
: aucune différence.
Non, là je parle d'un effet spécifique à Rosetta, qui n'affecte pas les
applications natives : ça démontre que ça n'est de loin pas aussi simple
que de recompiler.
Tu n'as pas répondu à la question : trouverais-tu normal qu'un logiciel
sorti en 2006 sous 10.5 ne tourne plus en 2012 sous 10.8 ?
Il ne s'agit pas de trouver ça normal ou pas. La réalité c'est qu'à
chaque sortie d'un nouvel OS, il y a des applications qui ne fonctionne
plus correctement. Et je rappelle que là on ne parle pas simplement
d'une mise à jour de l'OS, on parle d'un changement d'architecture de
l'OS.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Et ce n'est pas comme si il n'existait pas d'émulateur sous Linux, aussi : Qemu émule du x86, de l'ARM, du SPARC, du PPC, et ce sur toutes les architectures hôtes sur lesquelles tourne Linux ! Qemu en fait 100 fois plus que Rosetta... Mais comment font-ils alors que Apple juge insupportable la maintenance de Rosetta ??
Ca n'est pas Rosetta le problème, c'est les frameworks !
> Ben voyons. Evidemment qu'ils sont différents vu qu'ils n'utilisent pas > le même jeux d'instructions !
Non mais n'importe quoi, là, franchement. Tu le fais exprès pour noyer le poisson ou quoi ?
Pas du tout.
C'est le même code source, compilé pour 2 cibles différentes ! Que le code binaire soit différent est évident, mais le travail de maintenance n'est pas à faire en double !
Tout le travail de validation, si.
En effet. Mais les versions PPC des librairies était déjà validées, puisqu'elles existaient déjà dans Mac OS X PPC. Ce n'est pas comme elles étaient sorties de nulle part.
Non, justement pas, cela aurait nécessité de ne pas toucher l'interface avec les couches inférieures, et donc limiter les modifications possibles à ce niveau. Les frameworks sont ont la même versions en PowerPC et x86. Je l'avais vérifié à l'époque en désassemblant le code PowerPC de l'une d'entre-elle : on y trouve les nouvelles méthodes introduites avec 10.6.
Le code source est en grande partie identique, mais la maintenance de la version PowerPC nécessite des adaptations spécifiques et, surtout, la validation de l'ensemble des API accessibles par les applications sur une architecture supplémentaire.
> Et là en plus, les frameworks PowerPC interfacent un OS qui > n'a pas la même endianness, ce qui nécessite évidemment une couche de > compatibilité qui n'existe pas côté Intel...
Oui, et c'est précisément le travail de Rosetta de s'occuper de ce genre de choses. On l'écrit une fois ça marche pour toutes les applications, et c'est tout l'intérêt du truc.
Rosetta ne sait pas si tel bloc de donnée que le framework PowerPC passe à une fonction native dans l'OS est un tableau de byte (aucune conversion dans ce cas) où s'il s'agit de valeurs multi-octects qu'il faut permutter. Tout modification au niveau inférieur nécessite donc potentiellement d'adapter le code qui fait l'interface.
> > Il y a eu des mise à jour de sécurité qui ont rendu certains logiciels > PowerPC inopérants dans Leopard ou SL, on se demande comment cela a pu > arriver si c'est tellement simple de maintenir l'environnement PowerPC > dans Mac OS X Intel. >
De même qu'une mise à jour de sécurité peut rendre un logiciel inopérant : aucune différence.
Non, là je parle d'un effet spécifique à Rosetta, qui n'affecte pas les applications natives : ça démontre que ça n'est de loin pas aussi simple que de recompiler.
Tu n'as pas répondu à la question : trouverais-tu normal qu'un logiciel sorti en 2006 sous 10.5 ne tourne plus en 2012 sous 10.8 ?
Il ne s'agit pas de trouver ça normal ou pas. La réalité c'est qu'à chaque sortie d'un nouvel OS, il y a des applications qui ne fonctionne plus correctement. Et je rappelle que là on ne parle pas simplement d'une mise à jour de l'OS, on parle d'un changement d'architecture de l'OS.
Patrick -- Patrick Stadelmann
J.P
In article , pehache wrote:
Une appli écrite dans un langage haut niveau peut la plupart du temps être simplement recompilée pour tourner pour tourner sur une autre plateforme, du moment que c'est sous le même OS. Et Mac OS X PPC ou Mac OS X x86, c'est le même OS. L'OS est censé cacher aux applis les différences du matériel, justement. On n'est plus à l'époque où on développait les applis en assembleur lié à un matériel donné.
Et même l'essentiel d'un OS moderne a un code source commun. Les morceaux de code source spécifiques à une plateforme sont très minoritaires dans les librairies système, tant qu'on ne parle pas des fonctions de bas niveau qui interagissent directement avec le matériel.
et donc: soit Apple produit du logiciel vraiment mal foutu, hors de tous les concepts modernes de modularité, réutilisation, portabilité etc. soit l'abandon de Rosetta est une décision purement politique/stratégique/marketing ... La deuxième option semble quand même la plus vraisemblable.
Apple aurait négocié l'abandon de Rosetta avec les éditeurs (Adobe, MS, ...) avec quelques contreparties ?
-- Jean-Pierre
In article <camctqF4ho5U1@mid.individual.net>,
pehache <pehache.7@gmail.com> wrote:
Une appli écrite dans un langage haut niveau peut la plupart du temps
être simplement recompilée pour tourner pour tourner sur une autre
plateforme, du moment que c'est sous le même OS. Et Mac OS X PPC ou Mac
OS X x86, c'est le même OS. L'OS est censé cacher aux applis les
différences du matériel, justement. On n'est plus à l'époque où on
développait les applis en assembleur lié à un matériel donné.
Et même l'essentiel d'un OS moderne a un code source commun. Les
morceaux de code source spécifiques à une plateforme sont très
minoritaires dans les librairies système, tant qu'on ne parle pas des
fonctions de bas niveau qui interagissent directement avec le matériel.
et donc:
soit Apple produit du logiciel vraiment mal foutu, hors de tous les
concepts modernes de modularité, réutilisation, portabilité etc.
soit l'abandon de Rosetta est une décision purement
politique/stratégique/marketing ...
La deuxième option semble quand même la plus vraisemblable.
Apple aurait négocié l'abandon de Rosetta avec les éditeurs (Adobe, MS,
...) avec quelques contreparties ?
Une appli écrite dans un langage haut niveau peut la plupart du temps être simplement recompilée pour tourner pour tourner sur une autre plateforme, du moment que c'est sous le même OS. Et Mac OS X PPC ou Mac OS X x86, c'est le même OS. L'OS est censé cacher aux applis les différences du matériel, justement. On n'est plus à l'époque où on développait les applis en assembleur lié à un matériel donné.
Et même l'essentiel d'un OS moderne a un code source commun. Les morceaux de code source spécifiques à une plateforme sont très minoritaires dans les librairies système, tant qu'on ne parle pas des fonctions de bas niveau qui interagissent directement avec le matériel.
et donc: soit Apple produit du logiciel vraiment mal foutu, hors de tous les concepts modernes de modularité, réutilisation, portabilité etc. soit l'abandon de Rosetta est une décision purement politique/stratégique/marketing ... La deuxième option semble quand même la plus vraisemblable.
Apple aurait négocié l'abandon de Rosetta avec les éditeurs (Adobe, MS, ...) avec quelques contreparties ?
-- Jean-Pierre
pehache
Le mardi 21 octobre 2014 09:01:57 UTC+2, Jerome Lambert a écrit :
Le 20/10/2014 09:15, pehache a écrit : (...) > Quand on voit que certaines applications Win32 qui ont plus de 15 ans e t > tounaient sous Windows 98 peuvent encore tourner sur Windows 8, il faut > arrêter de chercher des excuses à Apple pour Rosetta.
1) Tu fais bien de préciser "certaines applications", puisque c'est loi n d'être le cas. Sur certaines versions, Microsoft propose même un XP virtualisé (XP mode) pour les cas les plus problématiques.
Pour importe comment elles tournent, le fait est qu'elles tournent.
2) C'est possible, mais à quel prix? Windows est quasi toujours le dernier dans le support des technologies récentes (64bits, EFI, GPT, etc.) ou des manières de gérer l'OS (je pense ici à l'UAC), préci sément au nom de la sacro-sainte compatibilité ascendante.
C'est certain que le maintien d'une compatibilité ascendante est une contrainte de ce point de vue. Après il ne faut pas exagérer sur les nouvelles technos en question : souvent elles sont théoriquement supportées mais peu utilisées, car MS ne les impose pas (du moins dans un premier temps). Par exemple Windows est passé à 64 bits relativement tôt en fait : le problème était alors surtout que très peu de drivers étaient compatibles et que les fabricants n'étaient pas pressés de les développer.
Exemple idiot: pourquoi le disque dur (ou la 1ère partition du disque dur) sur lequel on boote est-il référencé comme "C:". Que je sache, l'alphabet commence à A. Et bien ça date du temps où les machines étaient équipées d'un lecteur de disquettes 3 pouces 1/2 et d'un le cteur 5 pouces 1/4, avec respectivement les lettres A et B. Des lecteurs de disquettes, ça fait près de 10 ans que je n'en vois p lus sur les machines...
Et ? Qu'est-ce que ça fait que le disque de boot soit C: ou A: ?
Le mardi 21 octobre 2014 09:01:57 UTC+2, Jerome Lambert a écrit :
Le 20/10/2014 09:15, pehache a écrit :
(...)
> Quand on voit que certaines applications Win32 qui ont plus de 15 ans e t
> tounaient sous Windows 98 peuvent encore tourner sur Windows 8, il faut
> arrêter de chercher des excuses à Apple pour Rosetta.
1) Tu fais bien de préciser "certaines applications", puisque c'est loi n
d'être le cas. Sur certaines versions, Microsoft propose même un XP
virtualisé (XP mode) pour les cas les plus problématiques.
Pour importe comment elles tournent, le fait est qu'elles tournent.
2) C'est possible, mais à quel prix? Windows est quasi toujours le
dernier dans le support des technologies récentes (64bits, EFI, GPT,
etc.) ou des manières de gérer l'OS (je pense ici à l'UAC), préci sément
au nom de la sacro-sainte compatibilité ascendante.
C'est certain que le maintien d'une compatibilité ascendante est
une contrainte de ce point de vue. Après il ne faut pas exagérer sur
les nouvelles technos en question : souvent elles sont théoriquement
supportées mais peu utilisées, car MS ne les impose pas (du moins
dans un premier temps). Par exemple Windows est passé à 64 bits
relativement tôt en fait : le problème était alors surtout que très
peu de drivers étaient compatibles et que les fabricants n'étaient pas
pressés de les développer.
Exemple idiot: pourquoi le disque dur (ou la 1ère partition du disque
dur) sur lequel on boote est-il référencé comme "C:". Que je sache,
l'alphabet commence à A. Et bien ça date du temps où les machines
étaient équipées d'un lecteur de disquettes 3 pouces 1/2 et d'un le cteur
5 pouces 1/4, avec respectivement les lettres A et B.
Des lecteurs de disquettes, ça fait près de 10 ans que je n'en vois p lus
sur les machines...
Et ? Qu'est-ce que ça fait que le disque de boot soit C: ou A: ?
Le mardi 21 octobre 2014 09:01:57 UTC+2, Jerome Lambert a écrit :
Le 20/10/2014 09:15, pehache a écrit : (...) > Quand on voit que certaines applications Win32 qui ont plus de 15 ans e t > tounaient sous Windows 98 peuvent encore tourner sur Windows 8, il faut > arrêter de chercher des excuses à Apple pour Rosetta.
1) Tu fais bien de préciser "certaines applications", puisque c'est loi n d'être le cas. Sur certaines versions, Microsoft propose même un XP virtualisé (XP mode) pour les cas les plus problématiques.
Pour importe comment elles tournent, le fait est qu'elles tournent.
2) C'est possible, mais à quel prix? Windows est quasi toujours le dernier dans le support des technologies récentes (64bits, EFI, GPT, etc.) ou des manières de gérer l'OS (je pense ici à l'UAC), préci sément au nom de la sacro-sainte compatibilité ascendante.
C'est certain que le maintien d'une compatibilité ascendante est une contrainte de ce point de vue. Après il ne faut pas exagérer sur les nouvelles technos en question : souvent elles sont théoriquement supportées mais peu utilisées, car MS ne les impose pas (du moins dans un premier temps). Par exemple Windows est passé à 64 bits relativement tôt en fait : le problème était alors surtout que très peu de drivers étaient compatibles et que les fabricants n'étaient pas pressés de les développer.
Exemple idiot: pourquoi le disque dur (ou la 1ère partition du disque dur) sur lequel on boote est-il référencé comme "C:". Que je sache, l'alphabet commence à A. Et bien ça date du temps où les machines étaient équipées d'un lecteur de disquettes 3 pouces 1/2 et d'un le cteur 5 pouces 1/4, avec respectivement les lettres A et B. Des lecteurs de disquettes, ça fait près de 10 ans que je n'en vois p lus sur les machines...
Et ? Qu'est-ce que ça fait que le disque de boot soit C: ou A: ?
pehache
Le mardi 21 octobre 2014 09:36:23 UTC+2, Patrick Stadelmann a écrit :
> En effet. Mais les versions PPC des librairies était déjà valid ées, > puisqu'elles existaient déjà dans Mac OS X PPC. Ce n'est pas comme elles > étaient sorties de nulle part.
Non, justement pas, cela aurait nécessité de ne pas toucher l'interfa ce avec les couches inférieures, et donc limiter les modifications possibles à ce niveau. Les frameworks sont ont la même versions en PowerPC et x86. Je l'avais vérifié à l'époque en désassemblant le code PowerPC de l'une d'entre-elle : on y trouve les nouvelles méthodes introduites avec 10.6.
Le code source est en grande partie identique, mais la maintenance de la version PowerPC nécessite des adaptations spécifiques et, surtout, la validation de l'ensemble des API accessibles par les applications sur une architecture supplémentaire.
Dans ce cas, le choix d'insérer Rosetta entre les frameworks et les couches inférieures n'était pas forcément le plus inspiré.
> Tu n'as pas répondu à la question : trouverais-tu normal qu'un logi ciel > sorti en 2006 sous 10.5 ne tourne plus en 2012 sous 10.8 ?
Il ne s'agit pas de trouver ça normal ou pas. La réalité c'est qu' à chaque sortie d'un nouvel OS, il y a des applications qui ne fonctionne plus correctement.
C'est censé être l'exception pour les applications qui suivent les rè gles de développement préconisées par Apple.
Le mardi 21 octobre 2014 09:36:23 UTC+2, Patrick Stadelmann a écrit :
> En effet. Mais les versions PPC des librairies était déjà valid ées,
> puisqu'elles existaient déjà dans Mac OS X PPC. Ce n'est pas comme elles
> étaient sorties de nulle part.
Non, justement pas, cela aurait nécessité de ne pas toucher l'interfa ce
avec les couches inférieures, et donc limiter les modifications
possibles à ce niveau. Les frameworks sont ont la même versions en
PowerPC et x86. Je l'avais vérifié à l'époque en désassemblant le code
PowerPC de l'une d'entre-elle : on y trouve les nouvelles méthodes
introduites avec 10.6.
Le code source est en grande partie identique, mais la maintenance de la
version PowerPC nécessite des adaptations spécifiques et, surtout, la
validation de l'ensemble des API accessibles par les applications sur
une architecture supplémentaire.
Dans ce cas, le choix d'insérer Rosetta entre les frameworks et les
couches inférieures n'était pas forcément le plus inspiré.
> Tu n'as pas répondu à la question : trouverais-tu normal qu'un logi ciel
> sorti en 2006 sous 10.5 ne tourne plus en 2012 sous 10.8 ?
Il ne s'agit pas de trouver ça normal ou pas. La réalité c'est qu' à
chaque sortie d'un nouvel OS, il y a des applications qui ne fonctionne
plus correctement.
C'est censé être l'exception pour les applications qui suivent les rè gles
de développement préconisées par Apple.
Le mardi 21 octobre 2014 09:36:23 UTC+2, Patrick Stadelmann a écrit :
> En effet. Mais les versions PPC des librairies était déjà valid ées, > puisqu'elles existaient déjà dans Mac OS X PPC. Ce n'est pas comme elles > étaient sorties de nulle part.
Non, justement pas, cela aurait nécessité de ne pas toucher l'interfa ce avec les couches inférieures, et donc limiter les modifications possibles à ce niveau. Les frameworks sont ont la même versions en PowerPC et x86. Je l'avais vérifié à l'époque en désassemblant le code PowerPC de l'une d'entre-elle : on y trouve les nouvelles méthodes introduites avec 10.6.
Le code source est en grande partie identique, mais la maintenance de la version PowerPC nécessite des adaptations spécifiques et, surtout, la validation de l'ensemble des API accessibles par les applications sur une architecture supplémentaire.
Dans ce cas, le choix d'insérer Rosetta entre les frameworks et les couches inférieures n'était pas forcément le plus inspiré.
> Tu n'as pas répondu à la question : trouverais-tu normal qu'un logi ciel > sorti en 2006 sous 10.5 ne tourne plus en 2012 sous 10.8 ?
Il ne s'agit pas de trouver ça normal ou pas. La réalité c'est qu' à chaque sortie d'un nouvel OS, il y a des applications qui ne fonctionne plus correctement.
C'est censé être l'exception pour les applications qui suivent les rè gles de développement préconisées par Apple.
Patrick Stadelmann
In article , pehache wrote:
Le mardi 21 octobre 2014 09:36:23 UTC+2, Patrick Stadelmann a écrit : > > > En effet. Mais les versions PPC des librairies était déjà validées, > > puisqu'elles existaient déjà dans Mac OS X PPC. Ce n'est pas comme elles > > étaient sorties de nulle part. > > Non, justement pas, cela aurait nécessité de ne pas toucher l'interface > avec les couches inférieures, et donc limiter les modifications > possibles à ce niveau. Les frameworks sont ont la même versions en > PowerPC et x86. Je l'avais vérifié à l'époque en désassemblant le code > PowerPC de l'une d'entre-elle : on y trouve les nouvelles méthodes > introduites avec 10.6. > > Le code source est en grande partie identique, mais la maintenance de la > version PowerPC nécessite des adaptations spécifiques et, surtout, la > validation de l'ensemble des API accessibles par les applications sur > une architecture supplémentaire.
Dans ce cas, le choix d'insérer Rosetta entre les frameworks et les couches inférieures n'était pas forcément le plus inspiré.
Pas forcément. En procédant ainsi, les applications exécutée par Rosetta sur Tiger Intel et les applications exécutées nativement sur Tiger PowerPC utilise exactement les même frameworks (Power PC donc). Ca garantit un très bon niveau de compatibilité. Il n'est plus non plus nécessaire de gérer le changement d'endianness entre les applications et le frameworks. Il doit être géré plus bas, entre deux couches de l'OS qui ne sont pas publiques et donc où il est possible d'optimiser sans se soucier de casser la compatibilité. Par exemple dans le cas d'aller-retours fréquents, on modifier le framework pour qu'il gère les données dans le mode de la couche inférieur, sans devoir les convertir dans un sens et dans l'autre à chaque fois. Ca n'est pas possible entre les frameworks et les applications, puisque l'API entre les deux est publique.
> > > Tu n'as pas répondu à la question : trouverais-tu normal qu'un logiciel > > sorti en 2006 sous 10.5 ne tourne plus en 2012 sous 10.8 ? > > Il ne s'agit pas de trouver ça normal ou pas. La réalité c'est qu'à > chaque sortie d'un nouvel OS, il y a des applications qui ne fonctionne > plus correctement.
C'est censé être l'exception pour les applications qui suivent les règles de développement préconisées par Apple.
A court terme. A long terme, des API finissent par disparaître, rendant les logiciels qui les exploitent inopérants. OpenTransport par exemple, sur lequel à une époque toutes les applications avec des fonctionnalité réseau (navigateur, client de messagerie, ...) étaient basées, n'est plus supporté depuis 10.9. OpenTransport a été déclaré obsolète avec Tiger, soit 8 ans avant. On est dans le même ordre de grandeur qu'entre l'annonce de la transition vers Intel et l'abandon du support de SL et de Rosetta...
Patrick -- Patrick Stadelmann
In article <3e650d3e-6a3e-4942-b2f2-bf6dce9c7d98@googlegroups.com>,
pehache <pehache.7@gmail.com> wrote:
Le mardi 21 octobre 2014 09:36:23 UTC+2, Patrick Stadelmann a écrit :
>
> > En effet. Mais les versions PPC des librairies était déjà validées,
> > puisqu'elles existaient déjà dans Mac OS X PPC. Ce n'est pas comme elles
> > étaient sorties de nulle part.
>
> Non, justement pas, cela aurait nécessité de ne pas toucher l'interface
> avec les couches inférieures, et donc limiter les modifications
> possibles à ce niveau. Les frameworks sont ont la même versions en
> PowerPC et x86. Je l'avais vérifié à l'époque en désassemblant le code
> PowerPC de l'une d'entre-elle : on y trouve les nouvelles méthodes
> introduites avec 10.6.
>
> Le code source est en grande partie identique, mais la maintenance de la
> version PowerPC nécessite des adaptations spécifiques et, surtout, la
> validation de l'ensemble des API accessibles par les applications sur
> une architecture supplémentaire.
Dans ce cas, le choix d'insérer Rosetta entre les frameworks et les
couches inférieures n'était pas forcément le plus inspiré.
Pas forcément. En procédant ainsi, les applications exécutée par Rosetta
sur Tiger Intel et les applications exécutées nativement sur Tiger
PowerPC utilise exactement les même frameworks (Power PC donc). Ca
garantit un très bon niveau de compatibilité. Il n'est plus non plus
nécessaire de gérer le changement d'endianness entre les applications et
le frameworks. Il doit être géré plus bas, entre deux couches de l'OS
qui ne sont pas publiques et donc où il est possible d'optimiser sans se
soucier de casser la compatibilité. Par exemple dans le cas
d'aller-retours fréquents, on modifier le framework pour qu'il gère les
données dans le mode de la couche inférieur, sans devoir les convertir
dans un sens et dans l'autre à chaque fois. Ca n'est pas possible entre
les frameworks et les applications, puisque l'API entre les deux est
publique.
>
> > Tu n'as pas répondu à la question : trouverais-tu normal qu'un logiciel
> > sorti en 2006 sous 10.5 ne tourne plus en 2012 sous 10.8 ?
>
> Il ne s'agit pas de trouver ça normal ou pas. La réalité c'est qu'à
> chaque sortie d'un nouvel OS, il y a des applications qui ne fonctionne
> plus correctement.
C'est censé être l'exception pour les applications qui suivent les règles
de développement préconisées par Apple.
A court terme. A long terme, des API finissent par disparaître, rendant
les logiciels qui les exploitent inopérants. OpenTransport par exemple,
sur lequel à une époque toutes les applications avec des fonctionnalité
réseau (navigateur, client de messagerie, ...) étaient basées, n'est
plus supporté depuis 10.9. OpenTransport a été déclaré obsolète avec
Tiger, soit 8 ans avant. On est dans le même ordre de grandeur qu'entre
l'annonce de la transition vers Intel et l'abandon du support de SL et
de Rosetta...
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Le mardi 21 octobre 2014 09:36:23 UTC+2, Patrick Stadelmann a écrit : > > > En effet. Mais les versions PPC des librairies était déjà validées, > > puisqu'elles existaient déjà dans Mac OS X PPC. Ce n'est pas comme elles > > étaient sorties de nulle part. > > Non, justement pas, cela aurait nécessité de ne pas toucher l'interface > avec les couches inférieures, et donc limiter les modifications > possibles à ce niveau. Les frameworks sont ont la même versions en > PowerPC et x86. Je l'avais vérifié à l'époque en désassemblant le code > PowerPC de l'une d'entre-elle : on y trouve les nouvelles méthodes > introduites avec 10.6. > > Le code source est en grande partie identique, mais la maintenance de la > version PowerPC nécessite des adaptations spécifiques et, surtout, la > validation de l'ensemble des API accessibles par les applications sur > une architecture supplémentaire.
Dans ce cas, le choix d'insérer Rosetta entre les frameworks et les couches inférieures n'était pas forcément le plus inspiré.
Pas forcément. En procédant ainsi, les applications exécutée par Rosetta sur Tiger Intel et les applications exécutées nativement sur Tiger PowerPC utilise exactement les même frameworks (Power PC donc). Ca garantit un très bon niveau de compatibilité. Il n'est plus non plus nécessaire de gérer le changement d'endianness entre les applications et le frameworks. Il doit être géré plus bas, entre deux couches de l'OS qui ne sont pas publiques et donc où il est possible d'optimiser sans se soucier de casser la compatibilité. Par exemple dans le cas d'aller-retours fréquents, on modifier le framework pour qu'il gère les données dans le mode de la couche inférieur, sans devoir les convertir dans un sens et dans l'autre à chaque fois. Ca n'est pas possible entre les frameworks et les applications, puisque l'API entre les deux est publique.
> > > Tu n'as pas répondu à la question : trouverais-tu normal qu'un logiciel > > sorti en 2006 sous 10.5 ne tourne plus en 2012 sous 10.8 ? > > Il ne s'agit pas de trouver ça normal ou pas. La réalité c'est qu'à > chaque sortie d'un nouvel OS, il y a des applications qui ne fonctionne > plus correctement.
C'est censé être l'exception pour les applications qui suivent les règles de développement préconisées par Apple.
A court terme. A long terme, des API finissent par disparaître, rendant les logiciels qui les exploitent inopérants. OpenTransport par exemple, sur lequel à une époque toutes les applications avec des fonctionnalité réseau (navigateur, client de messagerie, ...) étaient basées, n'est plus supporté depuis 10.9. OpenTransport a été déclaré obsolète avec Tiger, soit 8 ans avant. On est dans le même ordre de grandeur qu'entre l'annonce de la transition vers Intel et l'abandon du support de SL et de Rosetta...
