PpHd :
>pourquoi en tant qu'auteur de Iceberg (et co-auteur de PreOs, même, d'ailleurs!) je serais moins important que les auteurs de DoorsOS, TeOS et Universal OS auxquels il a demandé leur avis (même si c'était juste pour avoir la confirmation qu'ils s'en foutent et qu'ils lui donnent carte blanche)? Ben ton avis importe. Mais moins que le mien.

Vive ta disponibilité à la discussion...

>Dites-donc, vous avez lu au moins la doc pour savoir de quoi je parle, tous les deux? GHOST_SPACE est un RAM_CALL visé
>à permettre de continuer ce hack affreux:
>move.l foo,GHOST_SPACE+0x64
>au lieu d'utiliser la méthode propre:
>bclr.b #2,0x600001
>move.l foo,0x64
>bset.b #2,0x600001 Rien ne dit que la seconde methode soit plus sure a l'avenir que la premiere...

Elle est documentée dans la doc de TIFS contrairement à la première.

>Et évidemment, PpHd utilise ça dans la graphlib de PreOs 0.70 au lieu d'utiliser la méthode propre comme je l'ai fait dans Iceberg. Plus rapide a modifier.

Bah, je peux t'envoyer la version que j'ai déjà modifiée (cf. ./602). Elle gère tous les modèles maintenant, pas seulement les 89 HW2 et Titanium comme celle de Iceberg 1.00.

>S'il y avait un moyen fiable de détecter un kernel dépassé comme on le fait pour les AMS dépassés, ça se discuterait, mais là, on ne peut rien faire à part ne pas utiliser le RAM_CALL si on ne veut pas que ça plante. Qu'est-ce que tu proposes ?

Bah, un truc comme ce que tu as proposé pour le kernel v6: flipper le sign bit de 0x34.

>Et tu veux arranger les choses en faisant un kernel incompatible avec PreOS 0.70 ? Nan juste sans les nouvelles ramcalls.

Plutôt sans autopatcheur, sans flag Titanium (CALCULATOR==0 et c'est tout), avec les patches de Iceberg 1.00 et la graphlib de Iceberg. Et peut-être avec des changements dans l'anti-crash:
* Si le programme n'a pas planté, les leaks de mémoire et les interruptions non restaurées sont reportées à l'utilisateur, qui a le choix de les corriger ou pas. Il y aurait donc des routines de restauration différentes pour le cas "normal" et le cas "plantage".
* L'anticrash sera appliqué aux programmes _nostub ne portant pas de flags d'incompatibilité à travers une redirection du trap #11 et un default kernel stub dans le kernel (portant le flag 2, cf. ci-dessous).
* L'écran sera toujours sauvegardé pour les programmes kernel ne portant pas le flag 2, même s'ils sont appelés depuis un autre programme kernel. Cela pour faire marcher les ttstart-titanium originaux correctement malgré le default kernel stub.

>Quel est l'avantage d'utiliser une section BSS plutôt qu'un handle en mémoire? Pas de gestion de l'allocation / desallocation. Puis le segment est mis a 0 automatiquement aussi.

Sauf que TIGCC 0.95 ne fait pas confiance au kernel parce que les vieux ne le faisaient pas, et appelle memset lui-même.

Pollux :
Franchement, je comprends pas l'intérêt PRATIQUE de séparer CALCULATOR entre 89 et 89t

Entièrement d'accord.
Il y a une seule personne ici qui pense qu'il soit une bonne idée de mettre -1...

>c'est qu'aucun des aspects de la calc n'a été séparé de CALCULATOR et que si une nouvelle calc apparaissait, il n'y avait aucun moyen de savoir
>quelles propriétés elle avait : il aurait fallu définir des pseudo-constantes SCREEN89, KEYBOARD89, ROMADDR89, etc... Tu devrais relire les ramcalls. SCREEN89 et ROMADDR89 existent.

On attend tjs un header qui permette d'utiliser les ramcalls tout en utilisant tigcclib

Pas mal de RAM_CALLs, dont ROM_base, LCD_HEIGHT et LCD_WIDTH, sont définis dans compat.h.

Link :
PpHd, finalement, comment tu vas gérer ceux qui font "CALCULATOR ? a : b" ? En patchant les programmes comme tu l'a montré au ./594?

Les programmes en C ne mettront pas son flag Titanium, tout simplement. On a documenté CALCULATOR==0, on le fait respecter.