CITATION(SteC @ 17/02/2006 à 16:01 )

Non, les applications seront exécutées sur un émulateur (comme c'est déjà le cas pour beaucoup d'applications avec PalmOS 5).
D'ailleurs la news de
Clubic et surtout
le diagramme ne laisse aucun doute sur l'organisation du système. En revanche, je ne vois rien concernant l'émulation d'application utilisant une optimisation des processeurs ARM ?
Les machines actuelles faisant tourner PalmOS 5 ont déjà recours à l'émulation. En effet, la plupart des applications Palm continuent d'être écrites et compilées pour le 68k, et tournent dans un émulateur inclus dans la couche de compatibilité PACE. Sur ce point il n'y aura donc pas de changement.
En ce qui concerne les API et bibliothèques systèmes de PalmOS, elles sont constituées de code ARM, appelé depuis les applications. Dans la couche de compatibilité de l'ALP, toutes ces API devront être réécrites pour tenir compte de l'architecture et des changements des couches inférieures (par exemple, le "data manager" devra tenir compte du fait qu'il y aura en dessous soit un système de fichiers "plats", soit SQLlite, le "Form Manager" devra reposer sur GTK ou peut être simplement tout dessiner dans une simple bitmap affichée par GTK). On peut donc en principe s'attendre à des ralentissements pour certaines fonctions qui devront beaucoup être adaptées pour être compatible avec les couches d'en dessous (je pense surtout au "data manager") - pour la plupart des autres fonctions, il n'y aura que peu "d'overhead".
Reste le cas des bouts de code ARM utilisés dans les applications optimisés pour OS 5. Si les futures machinent continuent d'utiliser des processeurs ARM, il n'y aura à priori rien à changer. En effet, les sections ARM des applications bien écrites sont très délimitées et ne font aucun appel système - elles n'exécutent que du code "autiste" qui n'interragit pas avec le système (en général, les calculs, algorithmes ou codecs complexes). Je ne vois pas ce qui aurait à changer ici.
Reste donc des cas tordus:
- Les applications "Protein" entièrement natives, qui font donc des appels systèmes directement depuis du code ARM - je n'en ai jamais vu dans la nature.
- Les applications utilisant des fonctions système privées (qui ne seront pas inclues dans la couche d'émulation) pour détourner certaines limitations de l'OS.
- Les applications qui papotent directement avec le hardware sans passer par PalmOS (en général, tous les jeux). Pour celles là, je ne me fais pas de soucis, les fonctions à modifier sont en général très localisées, et les développeurs pourront s'en tirer avec une recompilation et quelques journées de travail.
Tout ça pour dire qu'il n'y a pas d'obstacle technique majeure à une couche d'émulation qui ferait tourner la majeure partie de la logithèque Palm. Evidemment, tout ça ne reste que de la spéculation, mais le gros atout de la plateforme étant sa logithèque, Access a intérêt à tout faire pour assurer ou faciliter la transition.