Schématiser AmigaOS sous forme de diagrammes.

• 

  serge

  21 mai 2012 à 12h23 #10577

  Je souhaiterais créer un diagramme (plus ou moins basique) du fonctionnement de notre système chéri AmigaOS 3.x.

  Des ajouts pourraient par le futur être faits pour les spécificités des systèmes NG.

  Ce schéma consisterait à lister les diverses parties du système et les liens qu’elles ont entre elles.

  J’en arrive à cette idée suite au besoin de comprendre le cheminement des informations lorsqu’une application imprime.

  On pourrait détailler les interactions entre les applications, lib, dev, assign, prefs, etc.

  Y a t il donc ici présent une âme généreuse et patiente qui souhaiterai m’aider à mettre ce projet sur pied?

  Cela peut être plusieurs personnes qui contribuent sur ce fil à hauteur de ce que chacun connait.

  Pour exemple, concernant l’opération d’impression, dans quel ordre mettriez vous ces éléments? Certains sont optionnels et pourraient servir à créer un schéma alternatif.

  Le device de l’imprimante (usb, parallel, net…)

  Les prefs d’impression

  PRT:

  options :

  GhostScript

  Turboprint

  Merci

  RyZen Rulez 😉

  

  Alex

  21 mai 2012 à 15h57 #161818

  Ton idée est intéressante, peut-être que tu pourrais te mettre en relation avec Steven Solie, depuis que le Wiki AmigaOS a été lancé ce genre d’initiative pourrait les intéresser (et tu pourrais même peut-être trouver des gens pour t’aider).

  Maintenant si ton but c’est de documenter AmigaOS 3.x et 3.x seulement alors considère que je n’ai rien dit et oublie carrément le paragraphe précédent. Mon but n’est nullement de dévier le fil ou je ne sais quoi, je cherche juste à de donner une indication sur l’endroit où tu pourrais trouver de l’aide.

  

  serge

  21 mai 2012 à 17h23 #161819

  Mon idée de base est de créer un document compréhensible par le plus grand nombre et qui montre les principaux rouges.

  Je commence par l’AmigaOS 3.x car il est la base commune à toute notre communauté mais l’idée c’est d’élargir le principe aux NG (OS4, MOS, AROS) pour que l’on comprenne de manière intuitive comment fonctionnent ces systèmes.

  Ma motivation vient du fait que la presse technique spécialisée à disparut et que la culture des systèmes d’exploitation en ce qui concerne l’Amiga n’est plus accecible au grand publique.

  Ce fait est à mes yeux une perte culturelle conséquente qu’il serait bien de combler.

  Donc Alex, pour revenir à ta proposition que je trouve intéressante, disons que l’AmigaOS4 arrive en second plan en tant que particularité de la base et puis je ne souhaite pas fermer ce travail en le proposant au wikiOS4.

  C’est une champ plus vaste que je souhaite pour ce document.

  Ps: bien qu’il faudra aussi schématiser l’OS4 bien entendu. C’est d’ailleurs en partant d’une question d’impression sur OS4 que tout à commencé

  RyZen Rulez 😉

  

  henes

  21 mai 2012 à 20h04 #161820

  Quelques exemples :

  [APDF]->[PRT:]->[port-handler]->printer.device]<->[pilote->[netprinter.device]->[bsdsocket.library]->[rtl8139.device]

  [APDF]->[PS: ]->[gs-handler ]->[ghostscript]->printer.device]<->[pilote->[netprinter.device]->[bsdsocket.library]->[rtl8139.device]

  [truc]->printer.device]<->[pilote->[netprinter.device]->[bsdsocket.library]->[rtl8139.device]

  

  serge

  21 mai 2012 à 22h21 #161821

  Génial !

  Merci Henes pour ces exemples précis qui vont devenir mes premières pierres de la version MorphOS du diagram

  Quelqu’un présent pour faire la même chose avec l’OS3.x avec et sans TurboPrint?

  Quelqu’un d’autre pour l’AmigaOS4?

  RyZen Rulez 😉

  

  henes

  21 mai 2012 à 22h34 #161822

  @serge

  C’est grosso modo la même chose quelque soit l’OS.

  A la limite, il est possible que Ghostscript s’interface différement suivant le printer.device utilisé.

  Et bien sûr tu peux remplacer tous les devices réseau par leur équivalent série, parallel, poseidon, sirion…

  Genre peut-être :

  [trucPDF]->[PS:]->[???]->[Ghostscript qui génère du PCL]->[PRT:]->[port-handler]->[printer.device<->[pilote]]->[usbparallel.device]->[printer.class]->[device uhci/ohci]...

  

  serge

  21 mai 2012 à 23h09 #161823

  ok, je vois. C’est assez similaire.

  Comment pourait on décrire l’intégration de TurboPrint courcircuitant le système natif d’impression de l’AmigaOS?

  j’imagine que sans turboprint ca donne:

  Est ce juste?

  [truc]->[PRT:]->[port-handler]->printer.device]<->[pilote->[parallel.device ou serial.device]

  ou

  [truc]->[SER:]->[port-handler]->[serial.device]

  ou

  [truc]->[PAR:]->[port-handler]->[parallel.device]

  Mais où vient s’intercaler TurboPrint? en remplacement du port-handler?

  RyZen Rulez 😉

  

  henes

  21 mai 2012 à 23h20 #161824

  En remplacement du printer.device de Commodore et de ses pilotes associés.

  « printer.device » ça peut être celui de CBM, de Turboprint, de Wolftruc, celui d’Aminet, etc…

  Certains printer.device (Turboprint, 3.5+…) viennent avec des extensions différentes de leur API… et qui sont uniquement (et éventuellement) utilisées par les logiciels parlant directement au printer.device. C’est à dire sans passer par PRT/PS.

  Tiens encore un exemple intéressant :

  [truc genre Multiview]->[picture.datatype]->[printer.device etc…]

  Le picture.datatype ayant une méthode pour imprimer via l’API du printer.device.

  

  serge

  21 mai 2012 à 23h53 #161825

  Ok, le Printer.device est donc le maitre de l’affaire. C’est lui qui va faire sa sauce avec les drivers d’imprimante et qui envoi le document à imprimer vers le bon device hardware. Quand à GhostScript, il intervient avant le printer.device si le port PS: est sollicité.

  Le PortHandler est en charge de créer les ports SER:, PAR:, NET:, PS:, mais est ce que le PortHandler est un élément généré par le printer.device ou est ce un élément totalement indépandant?

  J’imagine que oui. Une confirmation?

  EDIT : ma question est idiote concernant le port Handler je viens de m’en rendre compte

  Ce qui me manque c’est la définition d’un Handler.

  RyZen Rulez 😉

  

  Daff

  22 mai 2012 à 2h56 #161826

  Ce qui me manque c’est la définition d’un Handler.

  Le glossaire d’Obligement a la réponse :

  http://obligement.free.fr/glossaire/h.php

  J’y avais notamment inclus toutes les définitions trouvées dans la doc de l’AmigaOS 3.9.

  

  leo

  22 mai 2012 à 12h02 #161827

  Intéressant tout ça!

  Allez, dans quelques mois Serge va nous faire du code aux petits oignons

  

  centaurz

  22 mai 2012 à 22h11 #161828

  @serge

  Par contre si je puis me permettre la définition du glossaire d’Obligement décrit un handler au sens général.

  Dans le cas d’AmigaOS, un handler est un processus (DOS) qui gère un périphérique d’entrée/sortie (DOS) tel que PIPE:, PAR:, RAM:. Les systèmes de fichiers sont des cas particuliers de handlers.

  

  serge

  23 mai 2012 à 10h51 #161829

  centaurz a écrit :

  
  @serge

  Par contre si je puis me permettre la définition du glossaire d’Obligement décrit un handler au sens général.

  Dans le cas d’AmigaOS, un handler est un processus (DOS) qui gère un périphérique d’entrée/sortie (DOS) tel que PIPE:, PAR:, RAM:. Les systèmes de fichiers sont des cas particuliers de handlers.

  Oui, exacte centaurz,

  lorsque j’ai vu le message de daff, je me suis précipité sur son glossaire mais j’ai vite déchanté lorsque j’ai vu le peu de précisions de la définition qui m’interessait.

  Dans un sens, j’ai apprécié de découvrir ce glossaire car il semble très complet et peut servir dans d’autres occasions. Dans le cas de l’ Handler, j’en suis arrivé à la définition que tu donnes en cherchant par mes propres moyens.

  En tous cas merci beaucoup pour ta participation

  sinon, savez vous s’il est possible d’écrire directement sur le port parallel ou série depuis une application/Shell sans passer par le printer.device? Un peu comme le ferait une application sernet ou parnet.

  J’imagine que dans ce cas il faudrait que l’application/shell en question utilise un protocle très basic.

  Si oui, faudrait que j’inclue dans mes schémas un cas où le printer.device ne serait pas utilisé. Ce serait la façon la plus basique qu’une application/shell aurait pour communiquer avec une imprimante.

  RyZen Rulez 😉

  

  Mdwf

  23 mai 2012 à 11h03 #161830

  tu as le parallel.device, accessible par PAR: en shell

  

  Gilloo

  23 mai 2012 à 11h54 #161831

  sinon, savez vous s’il est possible d’écrire directement sur le port parallel ou série depuis une application/Shell sans passer par le printer.device? Un peu comme le ferait une application sernet ou parnet.

  Oh que oui! avec le trio OpenDevice/DoIO/CloseDevice

  c’est tout simplement décrit ici.

  http://gega.homelinux.net/AmigaDevDocs/dev_9.html

  J’imagine que dans ce cas il faudrait que l’application/shell en question utilise un protocle très basic.

  C’est tout simplement la couche DOS au dessus, Open/Write/Close en ouvrant le périphérique « PAR: »