lib_pad of struct Library
-
A moins de ne pas utiliser RTF_AUTOINIT je ne vois pas comment cela est possible, mais comme je le disais ma machine est actuellement en panne je ne peux pas tester pour valider mes souvenirs. Toutefois je n’ai *jamais* mis explicitement une quelconque valeur dans lib_pad (qui se nomme lib_ABIVersion sous AmigaOS 4 ce qui semble confirmer ton troll
) et pourtant cela a toujours fonctionné.A moins de ne pas utiliser RTF_AUTOINIT je ne vois pas comment cela est possible, mais comme je le disais ma machine est actuellement en panne je ne peux pas tester pour valider mes souvenirs. Toutefois je n’ai *jamais* mis explicitement une quelconque valeur dans lib_pad
Si on n’y met pas une valeur explicite, lib_pad peut contenir une valeur aléatoire
Heureusement que, dans la plupart des cas, le champ contient 0 parce que la structure est une globale ou provient de MakeLibrary() qui l’alloue avec MEMF_CLEAR…
Mais dans les autres cas (structure construite à la mano, resident situé dans une ROM externe…), b00m aléatoire…
Le plus rigolo serait de constater que ce champ n’existait même pas dans des headers plus anciens qui profitaient de l’alignement naturel effectué par le compilateur. Il n’y aurait alors vraiment eu aucune raison de l’initialiser dans les anciens logiciels
Hyperos forever.
Si on n’y met pas une valeur explicite, lib_pad peut contenir une valeur aléatoire
Heureusement que, dans la plupart des cas, le champ contient 0 parce que la structure est une globale ou provient de MakeLibrary() qui l’alloue avec MEMF_CLEAR…
Mais dans les autres cas (structure construite à la mano, resident situé dans une ROM externe…), b00m aléatoire…
Euh je ne suis pas certain de ce que tu racontes : d’abord en lisant rapidement le fichier header (je rappelle que je ne peux pas tester pour le moment ma machine est en panne) 0 c’est pour les programmes 68k, 1 c’est pour les programmes PPC. Heureusement avec RTF_AUTOINIT ta structure arrive toute initialisée avec ce qui va bien dedans, après si tu veux tout faire à la main il ne faut pas venir se plaindre que ça marche plus quand tu ne mets pas la bonne valeur dans un champ jusque là non public (initialiser à zéro est un minimum AMHA quand on est un minimum sérieux…) et sinon pour les autres vive MakeLibrary() qui existe depuis Mathusalem !
L’accès aux structures internes de l’OS a toujours été (AMHA) la plus grande faiblesse d’AOS (possibilité de « tout casser ») en même temps que sa plus grande richesse (énormes possibilités d’extensions « intégrées » à l’OS)
Euh je ne suis pas certain de ce que tu racontes
Je remarque bien
Depuis le début, tu sembles te placer du côté applicatif recevant un struct Library de la part du systeme. Alors que (et c’est pour cela que j’ai escamoté le reste de ton message) je parle de la struct Library provenant d’une tierce partie et injectée dans le système.
Dans ce deuxième cas, lib_Pad n’a même pas à être initialisé puisqu’il ne s’est jamais agit d’un champ réservé à un usage ultérieur et dont la documentation préciserait la valeur qu’il devrait contenir.
Un simple « grep -ri reserved » sur les fichiers header devrait montrer qu’il existe vraiment beaucoup de champ véritablement *réservés* dans AmigaOS.
Mais ce dont on parle, c’est juste du padding.
Un tel champ peut donc parfaitement contenir une valeur aléatoire correspondant à ce qu’il y avait à cet endroit de la mémoire précédemment. Et donc tout faire exploser sur hyperos qui considère apparement ce champ comme anciennement réservé et forcément rempli de zéro.
Wow, il est fourni ce thread
Alors voila je suis découvert. C’est effectivement pour maintenir la liste des pilotes utilisés par ma pile usb. Certains sont internes, d’autres externes.
J’ai eu une sacré surprise: les modules externes ayant le ROMtag type à 3 sont non seulement considérés comme des devices, mais automatiquement ajoutés à la liste des devices système. J’avais donc à la fois le device dans MA liste et dans la liste des devices, ce qui fait planter irrémédiablement quand on essaye de l’enlever (puisque c’est un élément commun aux 2 listes)
Mes questions du lundi:
1) Pour les utilisateurs de Sirion OS4, voyez vous les .usbhcd dans la liste des devices (DeviceList d’exec) si c’est oui, Sirion est très mal codé (mais bon mon opinion sur ce sujet n’a aucune valeur).
2) Si je met -1 dans le Romtag Type, est ce que c’est suffisant? (ormi le fait que le ‘device’ ne s’ajoute plus dans la liste système !)
3) ok je ne touche pas à lib_pad, je tiens à l’intégrité de mon séant.
Depuis le début, tu sembles te placer du côté applicatif recevant un struct Library de la part du systeme. Alors que (et c’est pour cela que j’ai escamoté le reste de ton message) je parle de la struct Library provenant d’une tierce partie et injectée dans le système.
Non non à moins que j’ai loupé quelque chose mais du côté applicatif nul besoin de jouer avec RTF_AUTOINIT
Je parle donc bien du développeur d’une bibliothèque tierce qui se *doit* d’utiliser les fonctions à sa disposition pour allouer/initialiser/ajouter un objet au système (ici une bibliothèque tierce) comme tu le disais toi-même si on utilise exec.library/MakeLibrary (ou la fonctionnalité AUTOINIT) tout est géré comme l’attend le système (donc mis à 0 ou 1 selon le cas sous AmigaOS 4) après si quelqu’un préfère tout faire à la main et en plus utiliser des champs non documentés, bin il lui reste ses yeux si son application ne fonctionne plus sous les versions postérieures de l’OS… 1) Pour les utilisateurs de Sirion OS4, voyez vous les .usbhcd dans la liste des devices (DeviceList d’exec) si c’est oui, Sirion est très mal codé (mais bon mon opinion sur ce sujet n’a aucune valeur).
je regarde ce soir si je vois les .usbhcd dans la liste des devices systèmes
2) Si je met -1 dans le Romtag Type, est ce que c’est suffisant? (ormi le fait que le ‘device’ ne s’ajoute plus dans la liste système !)
La je ne sais pas trop. Mais -1 n’est à mon avis pas une bonne idée car rt_Type est de type UBYTE et donc -1 va correspondre à 255 qui signifie NT_EXTENDED… As-tu essayé avec NT_UNKNOWN (=0) tout simplement ?
3) ok je ne touche pas à lib_pad, je tiens à l’intégrité de mon séant.
Je te comprends j’aurais un peu la même tendance
Depuis le début, tu sembles te placer du côté applicatif recevant un struct Library de la part du systeme. Alors que (et c’est pour cela que j’ai escamoté le reste de ton message) je parle de la struct Library provenant d’une tierce partie et injectée dans le système.
Non non à moins que j’ai loupé quelque chose mais du côté applicatif nul besoin de jouer avec RTF_AUTOINIT Je parle donc bien du développeur d’une bibliothèque tierce qui se *doit* d’utiliser les fonctions à sa disposition pour allouer/initialiser/ajouter un objet au système (ici une bibliothèque tierce) comme tu le disais toi-même si on utilise exec.library/MakeLibrary (ou la fonctionnalité AUTOINIT) tout est géré comme l’attend le système (donc mis à 0 ou 1 selon le cas sous AmigaOS 4) après si quelqu’un préfère tout faire à la main et en plus utiliser des champs non documentés, bin il lui reste ses yeux si son application ne fonctionne plus sous les versions postérieures de l’OS…
En gros :
– Une application (au hasard, GoldEd) utilise MakeLibrary() pour créer dynamiquement une bibliothèque depuis son code.
– Les bibliothèques tierces (toutes) ont un struct Library en dur dans leur binaire. Et si le champ de padding n’est pas à zéro, c’est le drame sur les os incompatibles…
Donc je pense toujours que tu te places du côté applicatif
Ou alors je n’ai toujours pas compris ce à quoi tu pensais.
@Hénès :
Peut-être que le fait de définir ce flag à une valeur différente de 0 force le système à redéfinir un padding, d’appeler une fonction de la lib que l’on ne crée pas (car on a pas la doc pour ) et qui du coup fait planter le système ..
Lorsqu’il y a un plantage sur une valeur, il y a toujours une raison …
Ma réponse était toute réfléchie … un pic envers hypérion .. un pic envers hénès …. plas plus compliqué ..
… concernant la lib, j’avais déjà réfléchi à la question (d’où la réponse ici) mais j’avais pas envie de réellement prendre part au sujet car c’est pas un domaine sur lequel je bosse actuellement … je préfèrais laisser parler ceux qui savent … sans laisser passer le pic vers hypérion … c’est tout :p
EDIT : J’en profite pour rajouter … tu es le premier à troller de cette façon et tu oses faire une remontrance aux autres lorsqu’ils agissent comme toi … voyons voyons … prenons le temps de la réflexion
@ +
AmiDARK
tu ferais bien de te relire ou alors tu as trop fait de MUI
En gros :
– Une application (au hasard, GoldEd) utilise MakeLibrary() pour créer dynamiquement une bibliothèque depuis son code
Non sauf en MUI quand on fait un sous-classage privé ou similairement dans un programme qui créerait dynamiquement une bibliothèque privée, on ne fait pas de MakeLibrary() dans une application…
Pour infos GoldED marche très bien sous AmigaOS 4, mais peut-être que son auteur n’est pas si plouc que ça…
– Les bibliothèques tierces (toutes) ont un struct Library en dur dans leur binaire. Et si le champ de padding n’est pas à zéro, c’est le drame sur les os incompatibles…
Je suis assez étonné de lire ça de ta part toi qui disais qu’il était facile de simuler les interfaces avec leur possibilité de données spécifiques par processus en retournant des bases différentes à chaque appel
Comment on fait on en prévoit 15 en dur dans le code et on croise les doigts pour que ce soit suffisant ?Je pense que tu dois confondre avec la structure Resident qui elle est en dur dans le code mais elle ne contient évidemment pas le champ de bourrage de la structure Library
De plus comme je le dis depuis le debut en mettant RTF_AUTOINIT dans le champ rt_Flags tout se fait tout seul. Aller un p’tit extrait de exec.library/InitResidentAUTOINIT FEATUREAn automatic method of library/device base and vector table
initialization is also provided by InitResident(). Depending on the
RTF_NATIVE flag, the new style or old style initialization method is
used.
AUTOINIT FEATURE (Old style - 68K)
The initial code hunk of the library or device should contain
"MOVEQ #-1,d0; RTS;".
Following that must be an initialized Resident structure with
RTF_AUTOINIT set in rt_Flags, and an rt_Init pointer which points
to four longwords. These four longwords will be used in a call
to MakeLibrary();
CQFD : avec RTF_AUTOINIT le système appel MakeLibrary() (ou CreateLibrary() pour les bibliothèques PPC sous AmigaOS 4) et les moutons sont biens gardés…
centaurz a écrit :
1) Pour les utilisateurs de Sirion OS4, voyez vous les .usbhcd dans la liste des devices (DeviceList d’exec) si c’est oui, Sirion est très mal codé (mais bon mon opinion sur ce sujet n’a aucune valeur).
Oui (exemple). Comment veux tu que la pile USB puisse retrouver ses petits sinon ? Ils sont ajoutés à la liste des devices comme tous ceux du kickstart, je ne vois pas trop où est le problème…
C’est ce que je craignais!! les .device et .usbhcd sont dans la même liste.
Les .usbhcd sont des devices particuliers, utilisés uniquement par usbsys.device et devraient être masqués ou cachés. Je ne voudrais voir que usbsys.device dans la DeviceList d’Exec! (heureusement je fais ce que je veux avec MA pile
, mes usbhcd n’apparaissent pas, mais sont pourtant chargés comme des devices)Il sont vraiment besoin d’architectes logiciels dans l’équipe OS4.0…
Merci centaurz pour l’info!
Dans rc_Type on peut mettre ce que l’on veut (0, 3 device, 9 library…), si ce n’est que le device doit figurer dans une liste (car il y a un Remove() dans Expunge)
Mon problème était qu’après un LoadSeg(), j’enchainais avec un InitResident(), qui en cas de succès ajoute dans la liste exec adéquate (library ou device) J’ai donc remplacé le InitResident() par un MakeLibrary() + appel à InitLib (dur à faire en C mais j’ai trouvé).
- Vous devez être connecté pour répondre à ce sujet.
