Joyeux anniversaire Ndless 3.1

[critor]

19 janvier - cette date ne vous dit rien ?
C'est pourtant la date de sortie de Ndless 3.1, le jailbreak permettant d'exécuter des applications tierces sur TI-Nspire !
Ndless 3.1 a donc aujourd'hui 2 ans, et nous lui souhaitons un joyeux anniversaire, ainsi qu'à son auteur ExtendeD !

Espérons qu'ils sauront nous revenir très bientôt avec une version compatible avec les systèmes TI-Nspire 3.2 ou ultérieurs.

[quentin974]

Déjà 2 ans ! Et pourtant pas une ride !
Le temps passe vite dites donc ( et les OS Nspire aussi malheureusement... ) !
J'en profite pour remercier les créateurs ainsi que tous ceux qui travaillent sur la plateforme Nspire !

[Lionel Debroux]

Eh oui, deux ans déjà...

[Adriweb]

Le temps passe vraiment vite effectivement....

Bon anniversaire

[yatto]

Bon anniversaire Ndless !!

Deux ans, déjà deux ans ! J'étais en terminale, à l'époque !

(Joke, en PT*, aucun concours n'autorise la calculatrice, du coup je sais même pas ce que je fais encore ici à lire toutes les news...
Ca doit être parce que j'aime bien ça...)

[AnToX98]

Bon anniversaire Ndless <3
Et j'attends avec impatience la naissance de Ndless 3.2

[le solutionneur]

Bon anniversaire Ndless <3
Et j'attends avec impatience la naissance de Ndless 3.2

À mon avis, autant attendre la sortie d'un nouvel OS pour travailler d'arrache-pied et sortir un nouveau ndless.
Tant que l'on a pas créé un gestionnaire de NIDs qui soit intégré au SDK de ndless, je pense qu'il faut éviter de sortir trop de versions de ndless, au risque de voir sortir des programmes ne fonctionnant que pour un OS spécifique à cause d'adresses de calls hardcodées.

[critor]

Il n'y a pas de problème, le_solutionneur.

Seuls les rares programmes Ndless qui ont des adresses de syscalls hardcodées dans leur source C ne marcheraient pas sous un Ndless pour un OS différent.
Tous les autres devraient fonctionner sans aucun besoin de recompilation, comme ce fut déjà le cas pour le passage de Ndless 2.0 à Ndless 3.1.

[Lionel Debroux]

En effet, la bonne façon de faire pour gérer les syscalls custom est de les intégrer à Ndless, comme le font du reste une partie non négligeable des auteurs.

[le solutionneur]

En effet, la bonne façon de faire pour gérer les syscalls custom est de les intégrer à Ndless, comme le font du reste une partie non négligeable des auteurs.

Ce que je voulais dire allait plus loin : on devrait dans le programme ndless intégrer une table de correspondance entre adresse en numéro arbitraire de la syscall (qu'on a décidé mais qui ne change pas à travers les OS). Lorsqu'un programme souhaite utiliser la syscall dont on a attribué le numéro 5, il lui suffit d'appeler une fonction ndless pas inline mais définie par ndless lui même, qui lui renvoi à l'adresse ou bien fait l'appel lui-même. De cette manière, tout programme utilisant des syscalls fonctionnera sur les prochains OS, sans recompilation.

Édit :
Je n'avais pas vu cette partie

Tous les autres devraient fonctionner sans aucun besoin de recompilation, comme ce fut déjà le cas pour le passage de Ndless 2.0 à Ndless 3.1.

Je ne savais pas que c'était déjà implémenté !