Kernel ou nostub ? - Page 2

Et <SARCASM>vive</SARCASM> les anciennes DLL qui traînent, et qui en plus sont souvent incompatibles avec les programmes plus récents... Cf. aussi la DLL hell sous Windows...

Minime. La valeur précise dépend de plusieurs facteurs, notamment: des fonctionnalités utilisées (ROM_CALLs, BSS, variable de données externe), du type de relogements choisi (le code pour décompresser les relogements compressés prend plus de place, évidemment), du type de section BSS (initialisée à 0 ou pas initialisée du tout). Mais c'est de l'ordre de grandeur de 100 octets (ce qui n'est pratiquement rien sur un gros programme, et très petit par rapport à un kernel aussi).

Ximoon
: F-Line, t'as pas trouvé plus lent ?

Ximoon
: Quant au BSS nostub, dans tous les cas que j'ai pu tester ça prend moins de place de mettre les variables en BSS mergé à cause du code supplémentaire donc bon ...

Pour presque tous.

Mais c'est de l'ordre de grandeur de 100 octets

Kevin Kofler
:

Ximoon
: Quant au BSS nostub, dans tous les cas que j'ai pu tester ça prend moins de place de mettre les variables en BSS mergé à cause du code supplémentaire donc bon ...

Contre-exemple: CC.

Nil
:

Et <SARCASM>vive</SARCASM> les anciennes DLL qui traînent, et qui en plus sont souvent incompatibles avec les programmes plus récents... Cf. aussi la DLL hell sous Windows...

C'est un autre souci qui est la faute du développeur... normalement, une librairie plus récente devrait toujours être compatible avec une version antérieure... Je n'ai jamais compris pourquoi ça n'était pas le cas .

Bah oui, sauf que c'est encore du code redondant, AMHA. Je trouve ça dommage.

comment l'utilisateur est-il censé savoir quelle est la version la plus récente?

Flanker
:

Pour presque tous.

ça fait toute la différence. C'est dû à quoi pour les programmes kernel ? (à part le changement des vecteurs)

Mais c'est de l'ordre de grandeur de 100 octets

pour le tout ?

Ximoon
:

Kevin Kofler :
Contre-exemple: CC.

C'est pas lui qui gagne encore plus en mode Kernel ?

Flanker
:

Pour presque tous.

ça fait toute la différence. C'est dû à quoi pour les programmes kernel ? (à part le changement des vecteurs)

Mais c'est de l'ordre de grandeur de 100 octets

pour le tout ?

Une fois de plus, ça dépend de ce que tu prends et ne prends pas, ce que j'ai donné n'est qu'un ordre de grandeur. Tout le point fort du code de démarrage est qu'on peut ne prendre que ce dont on a besoin au lieu de se taper un gros bloc de 4 KO.

Flanker
:

comment l'utilisateur est-il censé savoir quelle est la version la plus récente?

les numéros de versions, par exemple

Flanker
:

Flanker
:

Ximoon
: tu oublies les niveaux de gris,

la restauration de l'écran,

l'émulateur fline,

Et il les trouve comment? Avec un éditeur hexa? En regardant le fichier .89z de loin, il n'a aucun moyen de savoir quelle version c'est, il voit juste que c'est la nème copie de genlib.89z. Et souvent, la version dans le header kernel ne change même pas pour des mises à jour qui ne font que corriger des bogues (et c'est normal, sinon on est vite arrivé à la version 256 qui ne rentre plus).

#define MIN_AMS 204

Flanker
: si la version n'est pas suffisante, PreOS marque un joli "Lib outdated" ou un truc de ce genre.

N'importe quoi! C'est une solution à court terme pour détecter les libs pre-PreOs, mais:
1. ça ne marche pas dans tous les cas, il y a de faux positifs (des librairies où la version 0 est bien la plus récente) et de faux négatifs (il y a déjà pas mal de versions de genlib avec un numéro de version non nul).
2. ça ne sert pas à long terme (cf. les faux négatifs).
Bref, c'est un essai de "solution" qui ne résout pas du tout le problème, mais essaye juste de le cacher (sans y arriver vraiment).

Flanker
:

#define MIN_AMS 204

ça c'est de la compatibilité !

Et si tu parles des programmes qui demandent explicitement la version n de la librairie, ben, je peux te dire qu'il n'y en a pratiquement pas

Kevin Kofler
:

Flanker
: si la version n'est pas suffisante, PreOS marque un joli "Lib outdated" ou un truc de ce genre.

N'importe quoi! C'est une solution à court terme pour détecter les libs pre-PreOs, mais:
1. ça ne marche pas dans tous les cas, il y a de faux positifs (des librairies où la version 0 est bien la plus récente) et de faux négatifs (il y a déjà pas mal de versions de genlib avec un numéro de version non nul).
2. ça ne sert pas à long terme (cf. les faux négatifs). Bref, c'est un essai de "solution" qui ne résout pas du tout le problème, mais essaye juste de le cacher (sans y arriver vraiment).

Ben, il faut faire son choix: place ou compatibilité.

Flanker
: on ne doit pas parler de la même chose. Si la lib a la fonction, alors elle est censée marcher (sinon elle est bugguée mais dans ce cas c'est indépendant du format kernel). Si elle ne l'a pas, alors il y a un message

Kevin Kofler
:

Flanker
: on ne doit pas parler de la même chose. Si la lib a la fonction, alors elle est censée marcher (sinon elle est bugguée mais dans ce cas c'est indépendant du format kernel). Si elle ne l'a pas, alors il y a un message

Elle peut très bien avoir une fonction qui accepte un paramètre "mode" et ne gérer que les modes 0, 1 et 2, alors que la version la plus récente gère aussi 3 et 4... Et ce n'est qu'un exemple de problèmes. Ce n'est pas parce que ça linke que ça marche.

Ximoon
:

Et si tu parles des programmes qui demandent explicitement la version n de la librairie, ben, je peux te dire qu'il n'y en a pratiquement pas

un peu comme des programmes qui lisent les commentaires nostub quoi

Pollux :
Mais qu'est-ce que tu racontes ?
- je comprends pas pkoi y aurait des faux positifs : si le type update sa lib et revient en arrière pour les n°s de version, il est vraiment con
- je comprends pas pkoi y aurait des faux négatifs non plus

Pollux
: D'où l'intérêt des # de version...