J'attend avec impatience
>Donc je devrais accepter PreOs comme le monopole?
Le monopole, c'est mal
> Il y a toujours eu une multitude de kernels compatibles entre eux dans l'histoire des TI-89/92+/V200, je ne vois pas pourquoi ça devrait changer maintenant.
Tout a fait d'accord.
> Et je ne vois pas non plus pourquoi PpHd se permet de rajouter des trucs sans me demander mon avis,
Je te l'ai demande...
>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.
>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...
Il aurait fallu faire un InstallVector. Mais c'est assez orthogonal a un GHOST_SPACE.
>En plus, avec le relogement du RAM_CALL, ce n'est même plus intéressant en taille, c'est juste un hack qui ne sert strictement à rien.
Le but n'est pas d'etre interressant en taille.
>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.
>Je voudrais bien, mais je ne peux pas empêcher aux utilisateurs de l'avoir, et des programmes qui plantent sous quelles conditions que ce soit ne sont
>pas acceptables pour TIGCC.
Dites. Si vous pouvez aussi les faire marcher sous PlusShell 0.9, ca serait bien. Ou DoorsOS 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 ?
>est-ce que ce n'est pas ce "hack affreux" qui a été utilisé dans TIGCC pdt pas mal de temps, contrairement à ce que certains conseillaient, et qui a causé des problèmes d'incompatibilité, justement ?
Ben oui.
>Je ne vois toujours pas l'intérêt d'un Iceberg 2.00, à part faire emmerder tout le monde en faisant deux kernels incompatibles entre eux
>(enfin, faire une version light et sans toutes les fonctions et une version complète).
>Enfin, si on m'avait dit qu'un jour tu te mettrais à programmer des kernels, j'avoue que je ne l'aurais sûrement pas cru
C'est ca le plus fort dans l'histoire
>n'empêche qu'il reste le kernel le plus utilisé
Ca n'est pas une raison.
>Et tu veux arranger les choses en faisant un kernel incompatible avec PreOS 0.70 ?
Nan juste sans les nouvelles ramcalls.
>Et en plus, même lui documente même GHOST_SPACE comme "deprecated". Je ne comprends pas pourquoi il rajoute un nouveau RAM_CALL
> s'il est "deprecated" dès le départ! Ni pourquoi il utilise un RAM_CALL "deprecated" dans sa graphlib, d'ailleurs.
Parce que c'est plus rapide pour porter les programmes mais que ca reste pas top
>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.