Adobe, Microsoft, Google… des corrections de bugs pour 299 apps dans macOS
Normalement, les bugs des apps doivent être corrigés par leurs développeurs, qu’il s’agisse d’Apple pour celles qui sont installées par défaut dans macOS, ou bien une autre entreprise pour les apps tierces. Mais dans certains cas, les développeurs de Cupertino prennent les devants et corrigent eux-mêmes les bugs de ces apps, en intégrant des patchs directement dans macOS. Ce n’est pas un phénomène isolé d’ailleurs : dans la dernière version de macOS High Sierra, on trouve ainsi pas moins de 299 correctifs pour des bugs d’apps.
Quelles apps sont prises en charge spécifiquement par Apple ? En majorité (64 sur 299), il s’agit d’apps… d’Apple ! Cela peut sembler surprenant, mais un patch chargé de corriger un bug ou de modifier un comportement par défaut est souvent utilisé au lieu de corriger directement la source. C’est le cas par exemple de Radar, l’app utilisée dans les bêtas pour permettre de remonter un bug (quelle ironie), mais aussi de composants utilisés par le système. Dans le lot, on repère notamment com.apple.loginwindow, le processus qui gère la connexion à une session utilisateur et qui est actuellement corrigé par un patch plutôt qu’à la source.
Le deuxième plus gros acteur est Adobe, avec 31 apps dans la liste. Tout le catalogue de l’éditeur est probablement concerné, notamment pour corriger les boîtes de dialogue qui servent à ouvrir et enregistrer des documents. Pour Photoshop, c’est aussi un bug lié à la Touch Bar des MacBook Pro qui est corrigé à la volée par le système. De son côté, la suite Office de Microsoft est également touchée par plusieurs patchs, dont un qui modifie légèrement l’algorithme de tri utilisé par Excel.
On trouve aussi un grand nombre de jeux dans la liste, notamment pour qu’ils utilisent des APIs graphiques plus anciennes plutôt que les plus modernes qui devaient poser problème. Apple a pris en charge les apps les plus connues et les plus utilisées, en vrac : Chrome, Spotify, Dropbox, VMWare Fusion, Sketch, 1Password, Evernote ou encore VLC et Firefox. Vous utilisez certainement plusieurs apps corrigées manuellement par macOS, sans le savoir… et on imagine que bon nombre de développeurs ne sont pas plus au courant. Cette liste montre bien qu’Apple teste de nombreuses apps tierces en interne et n’hésite pas à les corriger plutôt que d’attendre un correctif de la part de leurs concepteurs.
iOS ne dispose pas d’une liste similaire, mais quelques cas ont été pris en charge spécifiquement par le système mobile. On trouve notamment les anciennes apps de Popcap et Real Racing 3, mais aussi des cas étranges, comme cette app qui n’est plus disponible aujourd'hui et qui a connu un certain succès en 2009. Autant dire qu’Apple ne semble pas particulièrement pressée de retirer ces patchs spécifiques…
Cette pratique est clairement à mettre au crédit d' !
J'en profite pour poser une question générale.
Maintenant que High Sierra est sorti en version 10.13 depuis presque 8 mois (25 septembre 2017), avec la dernière version 10.13.4, reste-t-il encore des incompatibilités avec les logiciels de productions pro image, vidéo et 3D les plus courants ?
Je suis toujours sous Sierra : un passage en High Sierra m'apportera-t-il un gain sur un iMac 5K 2017 ?
Merci de vos éclairages... ;-)
Oh, IDA!
Microsoft étant incapable de livrer une version stable de Word (le mien plante régulièrement quand je travaille sur des documents lourds en marques de révision), je serais reconnaissant à Apple de se pencher sur le sujet (et ce n'est pas faute de signaler chaque plantage) ?
@Splinter
"je serais reconnaissant à Apple de se pencher sur le sujet"
Pour paraphraser Joe Louis : « There’s nothing wrong with Word that Apple could fix. »
Word est un sac à problèmes, rien à faire, sauf à le remplacer (et je cite là un ancien collègue passé ingénieur chez MS, qui en a marre d’être taquiné à ce sujet : « we can fix Windows, we can fix most things ; Word we can only scrap, and replace it with something that works — but then everybody would see it wasn’t needed in the first place... »)
@occam
C’est un peu le cas de tous les softs qui se trimballe un héritage de plusieurs décennies et que personne ne s’aventure à redévelopper from scratch avec des approches modernes.
@Yacc
"C’est un peu le cas de tous les softs qui se trimballe un héritage de plusieurs décennies"
Comme Unix ? ? ?
Je pense, au contraire, qu’il y a de bons et de (très) mauvais héritages.
Là où la sélection peut opérer, elle amorce l’adaptation, la modification et donc l’évolution. Ce qui demeure, le fait plutôt par vertu que par inertie.
C’est surtout en situation de monopole que l’on peut se permettre de perpétuer un code pourri, comme Microsoft l’a fait pendant longtemps avec Office, ou de dépérir des fonctionnalités pour implémenter des lubies, comme Apple le fait depuis quelques années avec OS X/macOS.
@occam
« Comme Unix ? ? ? »
Tu te doutes bien que j’évoquais les divers soft tel la suite Office, celle d’Adobe, celle d’Autodesk ...?
Après pour Unix le noyau de Linux n’est pas forcément le reflet de l’état de l’art.
Il y a aussi pas mal d’héritages conceptuels douteux dans les divers Unix ?(Tanenbaum est pour moi loin d’avoir totalement tort)
Sans aller bien loin t’es tu déjà amusé de comparer les éléments de code de Linux et ceux d’OpenSolaris ?
@occam
« ou de dépérir des fonctionnalités pour implémenter des lubies, comme Apple le fait depuis quelques années avec OS X/macOS. »
Je ne sais pas si certains que la source des pb de MacOS puisse se réduire à ses questions de fonctionnalités « lubies »
@occam : pour l'héritage Office dont Word : https://www.youtube.com/watch?v=3HROqnw-nf4
@Eurylaime
merci très intéressant ?
«C’est le cas par exemple de Radar, l’app utilisée dans les bêtas pour permettre de remonter un bug (quelle ironie)»
C'est pas une ironie, c'est une explication a l'inneficacité des programmes beta d'Apple. Si le moyen de remonter les bug est bugué c'est normal qu'ils mettent sur le marché des versions de plus en plus bugués...
;)
«Mais dans certains cas, les développeurs de Cupertino prennent les devants et corrigent eux-mêmes les bugs de ces apps, en intégrant des patchs directement dans macOS.»
Surtout ce que dit l'article d'origine c'est que Apple altere le comportement de logiciels tiers pour les rendre compatibles avec une nouvelle version de l'OS.
Il ne s'agit pas de corriger des bug presents dans ces logiciels, mais de compenser la violation que fait Apple face a un principe de programmation de base: la consistance des API.
Lorsqu'un developpeur ecrit une application, il y a 2 parties:
1) son propre code dont il maitrise l'execution
2) des appels a des fonctions et services fournis par le systeme
Cette seconde partie va concerner l'acces a l'interface, la gestion des acces au reseau, aux volumes de stockage, et tout services fourni par le systeme. Si le developpeur peut utiliser ces fonctions et services, il n'a par contre aucune maitrise ni connaissance de la façon dont fonctionne ces services (c'est souvent un secret de l'editeur de l'OS).
Pour arriver a cela le developpeur utilise une API qui est un protocole d'appel a ces services.
L'API est aussi regit par un contrat, le developpeur doit la respecter avec la garantie par l'editeur de l'OS que ce respect garantie la compatibilité de l'application avec toutes les versions ulterieures de l'OS.
Ici on voit qu'Apple introduit une inconsistance dans l'API et les appels systeme en general qui viole le contrat etablie avec le developpeur.
Comme c'est Apple qui viole le contrat, Apple patch alors les appels aux API dans les softs tiers...
Le plus grave dans cette histoire c'est qu'Apple viole non seulement un principe fondementale de l'informatique, mais qu'en plus Apple decide de maniere purement partiale, unilaterale et arbitraire quelles sont les applications qui seront patchés pour assurer qu'elles tourneront sur la version suivante de MacOS. A cela se rajoute encore un autre elements aggravant: le patch est une alteration du fonctionnement d'une application, alteration qui se fait sur l'executable et qui necessite qu'Apple "truc" la signature de l'application...
L'article d'origine le dit clairement: Apple a acquis une mauvaise reputation en terme de compatibilité entre version de MacOS. Ces patch sont des "bidouillages" pour compenser l’inconsistance des API de MacOS et sont une violation des regles de bases en developpement...
@C1rc3@0rc
Les gros vilains pas beaux quand même ?
Ils font rien qu’être méchant ?
Ce qui est agréable avec Circé c’est son absence absolue de manichéisme ?
Du côté des fournisseurs d’application c’est propre, élégant, maîtrisé... mais hélas Apple sabote tout ?
Vision dogmatique réductrice comme toujours ?
@C1rc3@0rc
Moi je remarque quand même qu'avec Windows on arrive à avoir de vieux programmes de 10 ou 15 ans qui tournent toujours sur un système récent. Au passage Microsoft maintient un Windows 7 (par exemple) plus de 10 ans. Et avec Apple au bout de 2 ou 3 ans on a des logiciels qui ne fonctionnent plus sur un système récent. Et plus de correctifs de sécurité sur un système qui n'a que quelques années. Pas très pro tout ca... En tous cas j'en ai raz le bol des mises à jour annuelles qui ne fonctionnent (presque) bien qu'au bout de 11 mois et rebelote pour l'année suivante (avec de nouveau les logiciels incompatibles). By Apple !
Hum… s'agit-il vraiment de bugs dans les applications en question, ou alors de bugs dans macOS qu'Apple préfère ne corriger que pour ces applications, de peur d'introduire d'autres bugs dans les autres applications? Je ne connais pas la réponse, mais je suppose quand même que c'est le deuxième cas… De mon côté, ça fait des années que je rapporte les mêmes bugs à Apple dans leurs APIs, sans qu'ils ne corrigent rien du tout :-(
Si cela est vrai c'est une faute majeure. Ce type de bidouille est une hérésie qui s'oppose à toutes le règles du développement de code.
Je n'imagine pas Apple capable de faire cela.
Lionel
À lire l’article originel, ce ne sont pas les applications elles-mêmes que corrige Apple mais le comportement de ses propres frameworks vis-à-vis d’elles dans certaines circonstances.
Toutafé.
Soit parce que les applis en question font un usage non prévu (mais non bloqué) d'une API d'Apple, soit parce qu'elle font un usage conforme à un ancien contrat d'interface d'une API mais que ce contrat est caduque mais comme l'application est jugée trop importante Apple préfère maintenir la rétrocompatibilité spécialement pour cette application, soit c'est un bug dans l'application (comme pour l'oubli de l'autoreleasepool dans les exemples) mais qu'Apple s'est résigné à corriger à la place de l'éditeur parce que la conséquence est perçu par l'utilisateur final comme un problème de stabilité et de performance dégr&dé de macOS et non comme étant de la faute de la consommation des ressources par telle application...
Dans tous les cas, c'est pas joli joli, mais c'est hélàs la réalité derrière le décors.
Le décors d'Apple étant en général plus lisse que la moyenne, cela choque plus, mais y'a pas de miracle, c'est toujours moins joli à voir de près, un code qui vieillit....
@byte_order
Ce type de rustine n’est pas l’apanage d’Apple ?
Et la masse de pratiques fort inélégante dans le développement logiciel de quasiment tous les acteurs du marché a de quoi donner la nausée à qui aime les solutions élégantes.
Je ne pense pas avoir dit le contraire.
@byte_order
Dans ce cas nous sommes simplement d’accord ?