Civilisation - Page 9

* Pour faire sa liste de programmes qui marchent sous PedroM, il a pris de vieilles versions qui marchent, pas les versions les plus récentes qui utilisent plus de ROM_CALLs et ne marchent donc plus.
* Pour le format natif de PedroM, il dit toujours que c'est le format kernel, alors que le format _nostub est au moins aussi "natif": ils sont tous les 2 supportés dès le départ. Et le support kernel est relativement facile à supprimer (mais PpHd devrait proposer une option de compilation pour pouvoir le désactiver automatiquement).

Quel intérêt ?

Épargner de la place. Place qui pourrait être utilisée pour rajouter plus de ROM_CALLs sans prendre un secteur de plus.

Qu'il soit facile à supprimer je dis pas, mais ça serait d'une stupidité affligeante de l'enlever. Et en tant qu'auteur de PedRom c'est encore lui qui définit les formats natifs non ? Toi qui parles toujours de fonctionnalités...
Mais bon, tout ça c'était pour faire remarquer qu'XDanger a beau faire le malin sur votre board, il ne vaut pas mieux que l'image qu'il se fait de ceux qu'il critique.

Kevin Kofler a écrit :
Épargner de la place. Place qui pourrait être utilisée pour rajouter plus de ROM_CALLs sans prendre un secteur de plus.

super, gagner meme pas 50ko par rapport aux 1.9MO de libres vive les arguments bidons

Ce n'est pas un argument bidon, mais un argument bien réel. Pourquoi gaspiller un secteur de 64 KO pour quelque chose dont on n'a pas besoin?

pphd programme pour lui Kevin, pas pour toi...
il fait ce qu'il veut

dont TU n'as pas besoin, moi j'en ai besoin, pphd en a besoin, plein de monde en a besoin, arrete d'etre egocentriste....
et me sors pas l'argument de merde de "une minorité de personnes se servent du kernel", a partir du moment ou il y a UNE personne qui s'en sert, il faut que ça reste(c'est exactement ce que tu dis qd tu parles de lynx et des javascripts sur yN)

Ça t'embête bien que le kernel devienne natif sur PedroM.

solid
a écrit : dont TU n'as pas besoin, moi j'en ai besoin, pphd en a besoin, plein de monde en a besoin, arrete d'etre egocentriste....

Désolé, j'aurais dû préciser ce que je voulais dire par "on". C'est la grande partie de la communauté qui n'a plus besoin d'un kernel.

et me sors pas l'argument de merde de "une minorité de personnes se servent du kernel", a partir du moment ou il y a UNE personne qui s'en sert, il faut que ça reste(c'est exactement ce que tu dis qd tu parles de lynx et des javascripts sur yN)

Que ça reste, soit, mais désactivable!

jackiechan
a écrit : Ça t'embête bien que le kernel devienne natif sur PedroM.

Il n'est pas vraiment "natif" (pas plus que le _nostub en tout cas), c'est juste PpHd qui l'appelle comme ça pour faire sa publicité.

Kevin Kofler
a écrit : Désolé, j'aurais dû préciser ce que je voulais dire par "on". C'est la grande partie de la communauté qui n'a plus besoin d'un kernel.

cette grande partie de la communauté s'en fou de pedrom alors elle fait pas chier !

c'est son OS non?
et quand tu parles de la majorité de la communauté j'imagine que tu te bases sur des chiffres concrets? ça sert a rien remarque on a déjà débattu de ça...

plus simple suffit de virer le format _nostub

Kevin Kofler a écrit :
Il n'est pas vraiment "natif" (pas plus que le _nostub en tout cas), c'est juste PpHd qui l'appelle comme ça pour faire sa publicité.

Le format kernel devient aussi natif que le _nostub puisqu'on peut lancer un prog kernel sans passer par l'installation (très laborieuse, avouons le) du kernel...

N'empêche que ce n'est pas "le" format natif comme le prétend PpHd.

Tu parle de natif par rapport au systeme. Or le systeme, c'est plus AMS, c'est PedroM. Etant donné que PpHd a créé le support, c'est lui qui définit ce qui est natif ou non, certainement pas toi. Il a integré le Kernel à PedroM, le kernel est devenu format natif, c'est aussi bête que ça. Que ça ne te plaise pas, c'est un autre problème.

Ce n'est pas le format natif. Le(s) format(s) natif(s) n'est / ne sont pas ce que le(s) développeur(s) du système d'exploitation prétend(ent) être "natif", mais les formats nativement supportés (c'est-à-dire supportés sans layer d'émulation) par le système d'exploitation. C'est un terme technique bien précis, et personne ne peut "définir" un format comme étant "natif", même pas le développeur du système d'exploitation. Soit il l'est, soit il ne l'est pas.

Et ici, il y a 2 questions:
1. Le format kernel est-il natif à PedroM?
2. Si oui, est-ce le seul format natif à PedroM?

La réponse à la première question n'est pas évidente, parce qu'il y a bien un layer d'émulation, mais il est intégré au système d'exploitation. Personnellement, je répondrais "non". Si on répond "oui", la logique veut qu'on considère aussi Win16 comme un format natif de Windows XP (parce que le layer d'émulation WOW fait partie du système d'exploitation, ce qui le place exactement dans la même situation). Et cela me paraît carrément abusé.

Quant à la deuxième question, la réponse est évidemment "non": le format _nostub est un format natif à PedroM quoi qu'en dise PpHd, donc même si on considère le format kernel comme un format natif à Pedrom, ce n'est pas le format natif. C'est avant tout sur cela que portaient mes messages #250 et #256.

Kevin Kofler a écrit :
Ce n'est pas le format natif. Le(s) format(s) natif(s) n'est / ne sont pas ce que le(s) développeur(s) du système d'exploitation prétend(ent) être "natif", mais les formats nativement supportés (c'est-à-dire supportés sans layer d'émulation) par le système d'exploitation. C'est un terme technique bien précis, et personne ne peut "définir" un format comme étant "natif", même pas le développeur du système d'exploitation. Soit il l'est, soit il ne l'est pas.

A t'entendre parler on croirait presque que la "nativité" d'un format ne dépend de rien autre qu'une operation du saint esprit... Les format "nativement supportés" comme tu dis si bien, sont ceux qui sont, comme leur nom l'indique, supporté par le systeme natif = sans modification. Il faudra que tu pense à me trouver les modifications nécessaires à PedroM pour qu'il supporte le mode Kernel.

Et ici, il y a 2 questions:
1. Le format kernel est-il natif à PedroM?
2. Si oui, est-ce le seul format natif à PedroM?
La réponse à la première question n'est pas évidente,

J'ai donné mon point de vue, qui n'engage que moi (je ne cherche pas à le faire passer pour la seule et unique parole, la moindre des choses serait que tu reconnaisse qu'en faire autant est tout ce que tu peux te permettre).

Quant à la deuxième question, la réponse est évidemment "non": le format _nostub est un format natif à PedroM quoi qu'en dise PedroM, donc même si on considère le format kernel comme un format natif à Pedrom, ce n'est pas le format natif. C'est avant tout sur cela que portaient mes messages #250 et #256.

Ce n'est peut-être pas le seul format natif de PedroM, qui se paie donc le luxe d'en posseder deux, mais ça n'en est pas moins un

Kevin que tu es bête mais mon dieu que tu es bête et borné .... ta mauvaise foi est sans limites ...

PS: J'ai regardé les sources, donc je sais de quoi je parle. Tous les appels de programme assembleur (kernel ou _nostub) de PedroM sont envoyés à travers kernel::exec qui fait techniquement partie de PreOs. (Aucune autre fonction de PreOs n'est nécessaire pour le lancement des programmes _nostub.) Bref, ils sont gérés par la même fonction d'exécution, et le format kernel a (évidemment) besoin de code d'émulation supplémentaire par rapport au format _nostub, donc je ne vois pas du tout ce qui permet à PpHd d'appeller le _nostub "non natif". Si le format kernel est natif à PedroM, le format _nostub l'est aussi.

Vertyos
a écrit : A t'entendre parler on croirait presque que la "nativité" d'un format ne dépend de rien autre qu'une operation du saint esprit... Les format "nativement supportés" comme tu dis si bien, sont ceux qui sont, comme leur nom l'indique, supporté par le systeme natif = sans modification. Il faudra que tu pense à me trouver les modifications nécessaires à PedroM pour qu'il supporte le mode Kernel.

Donc tu considères le Win16 (Windows 16 bits) comme un format natif de Windows XP??? Comme tu veux, mais je trouve que c'est étendre de beaucoup la définition de "natif" (qui implique normalement "sans émulation").

J'ai donné mon point de vue, qui n'engage que moi (je ne cherche pas à le faire passer pour la seule et unique parole, la moindre des choses serait que tu reconnaisse qu'en faire autant est tout ce que tu peux te permettre).

J'ai aussi donné le mien.

Ce n'est peut-être pas le seul format natif de PedroM, qui se paie donc le luxe d'en posseder deux, mais ça n'en est pas moins un

Sauf que PpHd a dit a plusieurs reprises que c'est "le format natif", et c'est ça que je critique:

Lionel Debroux (XDanger) a écrit sur le forum de la TICT:
At least, PpHd, program PedroM in such a way that the built-in kernel can be removed with a define...

PatrickPelissier (PpHd) a répondu: I can't since it is the native format of PedroM.

Remarque l'utilisation (injustifiée) de "the native format".

Mais qu'est-ce que ça peut te faire que le kernel soit inclu ds pedrom ? tu l'as dit toi-même cette rom n'a pas d'avenir alors pourquoi tu emmerdes PpHd avec ta croisade anti-kernel alors que si tu appliques tes propos cette rom ne t'interresse pas !
C'est juste pour le plaisir de critiquer ou alors c'est du à votre haine maladive du kernel ???

Kevin Kofler a écrit :
Bref, ils sont gérés par la même fonction d'exécution, et le format kernel a (évidemment) besoin de code d'émulation supplémentaire par rapport au format _nostub, donc je ne vois pas du tout ce qui permet à PpHd d'appeller le _nostub "non natif".

Simplement le fait que le code d'émulation supplémentaire, quel qu'il soit, est inclus lui aussi dans la ROM, et n'a plus à être considéré en tant qu'ajout comme c'est le cas sous AMS.

Kevin Kofler a écrit :
Si le format kernel est natif à PedroM, le format _nostub l'est aussi.
[ ... ]
Remarque l'utilisation (injustifiée) de "the native format".

Ok pour "the", le format _nostub ne devrait pas, sauf intervention volontaire (et stupide), cesser d'être natif.

Pour faire sa liste de programmes qui marchent sous PedroM, il a pris de vieilles versions qui marchent, pas les versions les plus récentes qui utilisent plus de ROM_CALLs et ne marchent donc plus.

C'est vrai mais il n'empèche pas mois que les version citées marchent et en ce qui concerne des jeux comme TI-Chess ils n'ont pas eu de grosses évolutions depuis bien longtemps donc ce n'est pas vraiment grave. Le but n'était pas de faire une liste de ce qui ne marche pas surtout que PedroM n'est pas encore en version finale. Des programme comme sh'l 0.2 sont dépassés mais j'ai testé avec la 0.6 ca marche aussi.

Pour le format natif de PedroM, il dit toujours que c'est le format kernel, alors que le format _nostub est au moins aussi "natif": ils sont tous les 2 supportés dès le départ. Et le support kernel est relativement facile à supprimer (mais PpHd devrait proposer une option de compilation pour pouvoir le désactiver automatiquement).

Bah le format kernel a des avantages sur le nostub et l'integration suprimme le seul véritable inconvéniant: l'obligation d'installer un kernel. Donc si on veut programmer pour PedroM je conseillerai plustôt le kernel. D'ailleurs les PedroM APPS sont au format kernel.
Donc si c'est vrai que le kernel et aussi natif que le nostub, le kernel n'en reste pas moins le plus avantageux sous Pedrom. Et je ne penses pas que tu ais attentivement regardé le source de PedroM pour voir comment c'est implémenté et pouvoir dire ce qui est natif ou pas.

super, gagner meme pas 50ko par rapport aux 1.9MO de libres vive les arguments bido

heu plustôt 4ko et l'integration à du lui faire perdre pas mal de place. De plus comme il est en flash et que c'est par segment de 64ko la perte réelle est de 0ko.

Ca servirait a quoi de le désactiver?

c juste la mauvaise foi de kevin qui fait rage, il sait qu'il a tort mais il aime ça

Uther Lightbringer
a écrit : C'est vrai mais il n'empèche pas mois que les version citées marchent et en ce qui concerne des jeux comme TI-Chess ils n'ont pas eu de grosses évolutions depuis bien longtemps donc ce n'est pas vraiment grave.

Ben, justement TI-Chess est un des jeux concernés: la version la plus récente ne marche plus sous PedroM. Et la version qu'il a testée a des bogues qui ont été corrigés dans la version la plus récente. Corruption de la pile superviseur pour n'en citer qu'un.

Bah le format kernel a des avantages sur le nostub et l'integration suprimme le seul véritable inconvéniant: l'obligation d'installer un kernel. Donc si on veut programmer pour PedroM je conseillerai plustôt le kernel.

Mais le _nostub est à préférer si on programme aussi pour AMS (et pas exclusivement pour PedroM).

Et je ne penses pas que tu ais attentivement regardé le source de PedroM pour voir comment c'est implémenté et pouvoir dire ce qui est natif ou pas.

As-tu lu le message #261?
Je peux te dire ce qui se passe lors d'un appel d'un programme assembleur sous PedroM avec encore plus de détails si tu veux:
* NG_execute appelle la routine interne EvalESI.
* EvalESI appelle la routine interne EvalASMFUNC.
* EvalASMFUNC appelle kernel::exec des sources de PreOs.
* kernel::exec appelle EX_patch.
* kernel::exec appelle le programme avec un jsr (a5).
Si le programme est _nostub, on a fini là. Si le programme est en mode kernel, il va appeler le vecteur exec ($34) pour donner une fois de plus le contrôle à PreOs.
Comme vous pouvez le voir à travers cette séquence d'appel, la seule fonction de PreOs qui est toujours utilisée est kernel::exec, qui est totalement indépendante du reste du kernel sauf pour le cas des packs archive (et même là, le traîtement spécial ne serait pas strictement nécessaire, il évite juste la double recopie en RAM).

heu plustôt 4ko et l'integration à du lui faire perdre pas mal de place. De plus comme il est en flash et que c'est par segment de 64ko la perte réelle est de 0ko.

Maintenant oui. Dans le futur, on atteindra un certain moment où la perte réelle sera de 64 KO!

solid
a écrit : c juste la mauvaise foi de kevin qui fait rage, il sait qu'il a tort mais il aime ça

Arrête de raconter n'importe quoi. Tu sais très bien que je n'ai pas tort (ou alors tu le saurais si tu avais lu les messages auxquels tu réponds), mais tu m'accuses de mauvaise foi parce que tu aimes ça.

Mais le _nostub est à préférer si on programme aussi pour AMS (et pas exclusivement pour PedroM).

Dans certain cas oui, mais restons dans le débat, la on parle de Pedrom pas d'AMS.

As-tu lu le message #261? Je peux te dire ce qui se passe lors d'un appel d'un programme assembleur sous PedroM ...

Je l'avais pas encore lu au moment ou j'ai posté, en effet s'est juste le kernel qui est inclus mais ca ne change rien dans la pratique : les progs kernel s'execute aussi facilement que les progs nostub et c'est tant mieux vu qu'ils y perdent quasiment tous leurs inconvéniant et gardent tous les avantages.

Maintenant oui. Dans le futur, on atteindra un certain moment où la perte réelle sera de 64 KO!

PpHd ne s'apelle pas TI si y'a un tel problème il fera des efforts pour y remédier et vu la place dont il dispose encore et celle qu'il va gagner quand side sera externe, il a de la marge pour des truc beaucoup moins utiles que le kernel

Arrête de raconter n'importe quoi. Tu sais très bien que je n'ai pas tort (ou alors tu le saurais si tu avais lu les messages auxquels tu réponds), mais tu m'accuses de mauvaise foi parce que tu aimes ça.

Quand tu dis que tu veux virer le kernel pour le problème de place oui c'est de la vraie mauvaise fois. Si tu veux le viver c'est que le mode kernel te dérange (j'arriverai sans doute jamais a comprendre pourquoi tu le détestes a ce point)
.

Pourquoi il gagnera de la place quand side sera externe ?