Je ne commenterai pas les points 1 et 2, ne m'étant pas plongé dans les méandres du code.
Concernant le point 3, c'est effectivement un problème crucial et général. Il arrive malheureusement que des programmes dépendent, volontairement ou non, de détails d'implémentation qui sont suceptibles de changer à tout moment (effets de bord, fonctions non documentées, etc.).
Je pense qu'on ne devrait pas se retenir de changer (et améliorer) une implémentation sous prétexte que des programmes bogués en dépendent. Comme le dit Theo, c'est un peu dur au début, le temps de corriger les programmes, mais au final tout le monde y gagne : le système étant moins laxiste, il laisse passer moins de bugs.
Mais c'est parfois plus facile à dire qu'à faire. Microsoft, garant de la sacro-sainte compatibilité, a souvent préféré faire l'inverse. Le blog « The Old New Thing » de l'un des programmeurs du noyau de Windows regorge d'histoires croustillantes expliquant certains choix techniques pris historiquement par Microsoft (au hasard http://blogs.msdn.com/oldnewthing/archive/2003/12/24/45779.aspx(...) ). Je me rappelle notamment qu'une faille avait dû être insérée dans le noyau de Windows 95 uniquement car Sim City en dépendait, et sortir un nouveau Windows incompatible avec l'un des jeux phares du moment aurait été impensable (invendable).
# Choix cornélien
Posté par Lagoon . En réponse au journal "Improved Memory Allocation" dans OpenBSD 3.8. Évalué à 5.
Concernant le point 3, c'est effectivement un problème crucial et général. Il arrive malheureusement que des programmes dépendent, volontairement ou non, de détails d'implémentation qui sont suceptibles de changer à tout moment (effets de bord, fonctions non documentées, etc.).
Je pense qu'on ne devrait pas se retenir de changer (et améliorer) une implémentation sous prétexte que des programmes bogués en dépendent. Comme le dit Theo, c'est un peu dur au début, le temps de corriger les programmes, mais au final tout le monde y gagne : le système étant moins laxiste, il laisse passer moins de bugs.
Mais c'est parfois plus facile à dire qu'à faire. Microsoft, garant de la sacro-sainte compatibilité, a souvent préféré faire l'inverse. Le blog « The Old New Thing » de l'un des programmeurs du noyau de Windows regorge d'histoires croustillantes expliquant certains choix techniques pris historiquement par Microsoft (au hasard http://blogs.msdn.com/oldnewthing/archive/2003/12/24/45779.aspx(...) ). Je me rappelle notamment qu'une faille avait dû être insérée dans le noyau de Windows 95 uniquement car Sim City en dépendait, et sortir un nouveau Windows incompatible avec l'un des jeux phares du moment aurait été impensable (invendable).