plus de portages Morphos qu’amiga OS4.0
-
ton Os est et restera un émulateur d’AmigaOs 3.1 de luxe
C’est bien parti pour être le cas… pour le commun des mortels en tout ca. Il est possible qu’une minorité de personnes « au dessus » des autres aient accès à quelque chose de mieux: mais quel intérêt ?
@+,
Léo.
Monsieur Crisot,
D’un coté ils disent « on vas implémenter de la protection mémoire »
Il est bien beau de prédire l’avenir et d’essayer de persuader les gens que cela va vraiment avoir lieu sans aucun doute. Vous savez, tous le monde ne croit pas au chose rien qu’en entendant dire par quelqu’un qu’elles existent. Un certains nombre de personnes ont besoin de voir concretement ces choses pour y croire.
Le fait est que vous utilisez un futur dans votre phrase. De cela on en déduit que cela n’est pas encore fait et donc que comme toute chose future et theorique, cela a une probabilité de ne pas se réaliser en pratique.
Il existe donc une façon simple et beaucoup plus efficace que votre ton de vieil ado en rute et vos insulte pour appuyer votre theorie, c’est de démontrer de façon argumenté, scientifique, raisonné avec une rigueur mathématique que effectivement il y a beaucoup plus de chance que cela se réalise en pratique que cela ne se réalise pas. Attention, par là je ne parles pas de faire quelques experiences pratiques isolées, tous le monde sait que quelque exemple empiriques ne suffisent pas à démontrer une theorie. Il faut un raisonnement bien construit voir mathématique qui ne puisse pas laisser place au doute.
Evidement, l’idéal est encore de mettre en pratique la theorie à grande echelle, c’est à dire dans le cas présent dans la totalité de l’OS. Evidement sans tricher, c’est à dire sans revoir la theorie sans prevenir après s’être rendu compte que dans l’état originalement annoncé, elle ne pouvait pas fonctionner en pratique.
Cordialement.
Le fameux Hobbit
Bonjour,
En fait la QBox c’est: Quark (le noyau) + ses services + nouvelles APIs native Quark. C’est pour cela qu’elle s’appelle QBox (QuarkBox).
D’ailleurs pour être exact, l’ABox tourne dans l’environnement QBox, mais l’environnement QBox tourne dans rien il est la premiere couche (epaisse puisqu’on peut découper cet environnement encore en sous-couche).
Le texte de MorphOS in detail est un peu ambigue à ce niveau, peut être à cause de la simplification des choses pour essayer de faire en sorte que cela soit pas trop difficilement comprehensible. En effet, dans ce texte on ne comprend pas bien que la QBox c’est Quark + des services + nouvelles APIs et effectivement on a tendance à croire que c’est un element isolé. En fait, et sauf si on considère qu’un noyau couplé à un jeu d’APIs suffit à constituer un environnement isolé, La QBox n’est pas plus isolé que le noyau Linux + les APIs de Linux, ou le noyau BeOS + les APIs BeOS.
A noter que tu dis que ce qui caracterise la QBox c’est d’utiliser Quark et ses fonctionnalité *avancées* directement, sache qu’en fait l’ABox, puisque c’est une application QBox et donc qui tourne directement au dessus de Quark et de ses services, elle utilise aussi Quark et ses services directement. D’ailleurs l’ABox de part le fait qu’elle est une application QBox, est une application beneficiant de la protection mémoire complète entre autre, c’est justement cela qui fait que même si l’ABox plante, cela ne plante pas le reste, puisqu’en fait dans ce cas les dégat possibles ne peuvent s’étendre en dehors de la zone mémoire allouée pour l’ABox, grâce à la protection mémoire.
Ce sont les applications qui sont dans l’ABox qui eux n’utilisent pas les fonctionnalité de Quark directement.
A+
Le fameux Hobbit
Il y avait un outils « équivalent » a GrimReppear dans MCP.
On pouvait décider d’arreter l’applis, d’essayer de la tué…
-> pourtant c’etait pas moderne
Bon, ceci dis. J’espere que GrimReppear est plus avancé que MCP:-)
Est-ce que tu pourrai faire un post avec *un* arguement sans être mal
poli ?
-> L’ABox n’est *pas* un émulateur
-> Quark *existe* depuis le début, l’API est plublique. Le vieux SDK
marche peut-etre même avec un MorphOS 1.4 (pas sur!)
Cordialement
@Frodon: je voulais dire par là que les applications QBox bénéficieront directement de ces fonctionnalités. Ce qui n’est pas le cas des applications ABox (actuelles), même si cette dernière utilise évidemment directement ou indirectement (via QBox) Quark.
@+,
Léo.
Je remarque juste que Crisot n’a pas répondu clairement aux questions de fab a propos des pb liés à la protection mémoire sous AOS…
Moi je demande qu’a voir que cela peux marcher…
En ce qui conserne Grimpripper c’est un plus même si dans mon cas les debugs via le port serie qui melange mes messages de debug + les hits sont beaucoup plus explicite sur l’ordre des évènements. De plus Grimpripper pointe son nez uniquement quand il y a un guru ou a chaque hit ?
Si c’est a chaque hit… on a pas fini…
Si c’est uniquement pour les guru ca sert a pas grand chose…
Donc c’est une gui certes mais ca ne fait pas tout…
A+
/me qui finalise son Organiser pour MOS (on verra plus tard pour la version OS4…)
sache qu’en fait l’ABox, puisque c’est une application QBox et donc qui tourne directement au dessus de Quark et de ses services, elle utilise aussi Quark et ses services directement.
Donc, si je comprends bien, mais je voudrais confirmation, l’ABox a son propre noyau (scheduler, ram manager et tout le tintouin) compatible Exec qui tourne au dessus de Quark.
Ou est-ce que certaines choses sont déléguées à Quark ?
des réponses pour fab1, qui me pose des questions à moi personnellement:
Puisque krabob semble si bien connaitre le développement d’OS4, il va sans doute pouvoir nous dire comment arriver à une vraie protection mémoire *pas* bancale sur OS4 sans casser la compatibilité avec l’api existante (et donc les applis existantes par la même occasion).
Mes connaissances sur l’OS4 lui même sont de l’ordre de son architecture générale, de la même façon que pour morphos. Tout ce que j’ai prétendu (ma signature, le fait qu’un portage mos/ABox->OS4 sera plus facile qu’un mos/ABox->mos/QBox) est pourtant vrai. Je ne sais pas les méthodes qu’emploie et que vont employer hyperion pour réaliser la protection mais d’aprés mes connaisances du systéme OS3.X c’est tout à fait possible. On ne peut donc ici que tergiverser sur des solutions possibles pour un probléme donné. Les developpeurs OS4 gérent les sources de maniéres privés. D’autre part il y a une hypothése de départ évidente: les applis concernés sont codé dans les régles de l’art, c’est a dire
qu’elles ne sont pas sencé faire des trucs déconseillé par les docs amiga officiel. (pas de oôôô le vieu prog pourri que j’utilise depuis 15 and va plus marcher.)
Alors quelques points intéressants à soulever (loin d’être exhaustif, car ma connaissance est limitée) :
– Comment OS4 prévoit de gérer le système de messages qui marche je le rappelle dans un espace mémoire commun à l’heure actuelle, ce sur quoi toute communication IPC des applis existant actuellement dépend ?
Je pense que la MMU peut déclarer des zones mémoires privé à des taches (empechant les lecture/ecriture des autres), ou publique ( MEMF_Public, mais ça ne devrait jamais etre utilisé c’est caca), mais aussi: EN LECTURE POUR CERTAINE TACHE ET EN ECRITURE pour d’autre. donc pour le cas des messages, il ne doivent être en écriture que par la faktory qui les gére, et en lecture pour tout le reste. c’est pas des factory ? (je sais plus…) pas de probléme: hop une petite copie au moment de l’envoie par une factory encapsulé, puisque les msg sont des struct de taille minimale c’est kifkif la cache. (par exmple,… on peut imaginer pleeein de solutions plus stables les unes que les autres.)
– Quid de l’accès aux structures système communément utilisées par beaucoup d’applis ?
Pareil, mais note importante: en faisant karate j’ai découvert que quand on fait une library par exemple, son intégralité doit être écrite de maniére ré-entrante. ( Surtout pas de var globale,tout en pile). Foutez vous de ma gueule mais je suis sur qu’il y a plein de lib buggué a cause de ça. Hors les « bases » des libs c’est le cas elle sont globale a la lib! Bon, mais les bases de lib ont une logique objet comme « statique au niveau du systeme » Donc ? -> meme sol. que pour les msg. L’execution d’une fonction .library se fait dans le contexte de la tache qui la lance et tape dans tout ça ? c’est vrai la plupart du temps en os3.x, mais rien n’empeche de
se servir maintenant de ces fonctions comme interfaces de commandes vers d’autres tâches.(par exemple)
– Comment interdire l’utilisation de certaines fonctions qui peuvent deadlocker ou anéantir le multitache de l’OS (forbid()/disable() blah blah blah…)
la seule utilisation de ces fonctions que j’ai vu c’était les pitoyable startup des demos A500 qui juste aprés faisait du code auto-modifier vers lui meme dans une meme boucle. Donc oui, ça poserait probléme, mais de memoire, dans les docs ya marqué un truc du genre: oôô n’utilisez pas ça y faut paaas ! Donc je te ramene au dessus. [edit] Et n’oubliez pas que OS4 rajoute des fonctions, ce n’est pas seulement un OS3.X, donc tout ceci ne s’applique que pour les taches émulé[/piaf]
Il y a surement des moyens pour certains des points soulevés, mais je serais intéressé d’avoir une liste exhaustive des problèmes et solutions liés à l’implémentation d’une protection mémoire sur aos, et à la mise en place de fonctions privilégiées.
Le développement d’OS4 est privé, je comprend que les utilisateurs mos sont curieux, mais tu m’as pris pour un frieden, désolé !
Mais écoute enfin ceci: face a un probléme, si toi tu n’as pas vu (ou pas bien cherché) la solution, un autre peutr la trouver quand meme.
Soyons logicien: Prouver que quelque chose « n’est pas possible », ça se fait aussi, mais les démonstrations pour cela sont beaucoup plus difficile à mettre en place.
@Krabob: Ce que tu viens d’énnoncer, ne marche pas et/ou ne permet pas
d’avoir une protection de mémoire complete.
les applis concernés sont codé dans les régles de l’art, c’est a dire
qu’elles ne sont pas sencé faire des trucs déconseillé par les docs amiga officiel
Ouais, mais il y a legion d’applis codé avec les pieds…
Certains soft check même pas leur stack au démarrage…
hop une petite copie au moment de l’envoie par une factory encapsulé, puisque les msg sont des struct de taille minimale c’est kifkif la cache.
L’interret des Message c’est bien d’éviter d’avoir a les copier.
Les .device peuvent être gérer par des taches indépendantes, ces
taches peuvent avoir besoin de lire/écrire dans le tampon (CMD_WRITE
ou CMD_READ la plupart du temps).
->Tu veux faire une copie CPU a chaque fois que t’écris sur ton HD?
bouge ta sourie, joue un sample ?
Hors les « bases » des libs c’est le cas elle sont globale a la lib!
On peux faire des library « multibases ». La vorbisfile_68kgate.library
a besoin de quelques variables pour chaque « opener ». Chaque opener a
une base différente.
la seule utilisation de ces fonctions que j’ai vu c’était les pitoyable startup des demos A500
Un programme comme Scout qui liste les trucs du systemes (libs, tache,
port…) utilise Forbid()/Permit(). Si tu vire Forbid()/Permit() Scout
ne marchera plus.
C’est aussi utilisé (implicitement) dans les LibInit, et tu dois
l’utilise dans LibExpunge pour pas exploser la liste des libraries.
Extrait de l’autodoc DU NDK 3.1 de FindPort():
>This function will search the system message port list for a port
>with the given name. The first port matching this name will be
>returned. No arbitration of the port list is done. This function
>MUST be protected with A Forbid()/Permit() pair!
Forbid() dans le source OS4 de SimpleMail
—
Il y a peut-etre des solutions diverses et variés. Mais, je vois mal
comment on peux implémenter tout ca sans faire des grands écarts
permants entre trucs modernes et compatibilité.
D’ou l’interret de laisser ce bordel de coté, et de faire un vrai truc
tout neuf.
Cordialement
Nico: Laisse tomber, de toute façon tout ce qui vient d’Hyperion n’est pas valable pour toi. Tout ce que tu cherches à faire c’est détruire sans même chercher à sa savoir si ce que tu attaques est touchable ou non.
Krabob: Laisse tomber: On l’aura notre protection mémoire, point final. Ils ont pas encore digéré que l’Articia S, ils ne vont pas digéré que l’Os 4 ai une protection mémoire sans tout foutre dans des boites, d’ailleur ça se comprend bien quand on voit tout ce qu’il faut digérer de leur coté.
Ta-taaaaaaaaaaaaaaannnnnn!
Ayé, je suis revenu sous mon pseudo orginiel, étant donné que nombreux sont ceux qui m’appellent encore par mon vieux pseudo
.Bon, et pour répondre à Poly en 2-4-6, GrimReaper apparaît vraisemblablement à chaque hit. Rassure-toi, pour mon utilisation, il apparaît seulement sous iBrowse, lors d’une orgie de JavaScript ou de SSL. Un clic anodin (et pas « ragondin ») sur « kill », et iBrowse continue comme si de rien ne fut (de chêne). Par contre, à la moindre apparition de GrimReaper sous iBrowse, le prog ne peut plus se fermer complètement; il reste toujours, au final, une mini fenêtre de fermeture. Il existe un hack qui permet de pallier ce problème; j’essaierai et vous tiendrai au courant.
Tigr… ah, bord…eaux, Kokin0u, avec un « 0 »
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Général › plus de portages Morphos qu’amiga OS4.0
