Topic : Atari Infopages Author : M. Ssykor, D. Hagedorn, A. Wilhelm Version : Release 11 vom 21.01.1996 Subject : Nachschlagewerke/Atari Infopages Nodes : 1721 Index Size : 50824 HCP-Version : 3 Compiled on : Atari @charset : atarist @lang : @default : @help : @options : -i -s +z @width : 75 View Ref-FileDer folgende Artikel stammt von Harun Scheutzow und wurde am So, den 9.4.95 in Atari.News gepostet. Probleme bei DFÜ mit MagiC3 (MagiCMac) und dem HSMODA-Treiberpaket ================================================================== (Dies ist ein "redaktioneller" Beitrag, der aber auch ein Programm enthält.) Da ich in den letzten Tagen einige PMs zu diesem Thema bekommen habe und es wahrscheinlich noch einige Nutzer mehr betrifft, antworte ich auf diesem Wege. Nur das HSMODA05- und das HSMODA06-Paket sind für die Nutzung unter MagiC3 vorgesehen. HSMODA04 kann, muß aber nicht, übelst abstürzen! DRVIN ----- In der Datei DRVIN.GER des HSMODA06-Paketes steht "Es wird ein MagiC geben, wahrscheinlich MagiC3, das alle Funktionen von DRVIN enthält...". Die momentan ausgelieferten Versionen von MagiC3 und MagiCMac enthalten nicht alle Teile des DRVIN, konkret fehlt die XBIOS-Erweiterung, die das saubere Einhängen von Treibern im BIOS erlaubt, und ein leerer RSVF-Cookie. Inzwischen bin ich auch von dem "Es wird ein MagiC ..." nicht mehr überzeugt, da es die Behnes seit November 1994 nicht für wichtig genug erachten, diese Erweiterungen zu realisieren, obwohl ich ihnen soviel Arbeit wie möglich dabei schon abgenommen habe. DRVIN ist also noch erforderlich. Beschwerden darüber bitte an die Wilfried und Sven Behne richten! Unter MagiC3 wird aber nur der BIOS/XBIOS-Teil des DRVIN benutzt (wie auch nebenbei unter dem Konfigpunkt EXOPEN im DRVIN.GER erwähnt). Wer aufmerksam den Bootvorgang betrachtet, wird in der DRVIN-Meldung eine Zeile "No extra GEMDOS" sehen, die genau dies aussagt. (Den MACM1-Paketen liegt ein DRVIN bei, das ohnehin kein GEMDOS-Teil enthält und deshalb diese Meldung nicht ausgibt.) Unmöglich gewordene Zusammenarbeit ---------------------------------- Die EXOPEN-Einstellung des DRVIN ist unter MagiC3 wirkungslos!!! Mehr noch, das Device-Filesystem des MagiC3 verhält sich immer wie EXOPEN = "Ja" Was das für Programmierer von DFÜ-Programmen bedeutet, ist schon seit Monaten im MACM1.TXT des MACM1-Paketes (aktuell MACM1_06.LZH, auch in @B3) beschrieben und ich hatte bereits in ATARI.PROG (oder ATARI.EXP) darauf aufmerksam gemacht. Leider gibt es einige Programmierer, die sich bis heute in keiner Weise darum kümmern, so daß ihre Programme unter MagiC3/MagiCMac z.B. kein externes Zmodem mehr aufrufen können (z.B. Connect). Ich kann absolut nichts dafür, daß Connect unter MagiC3 das GSZRZ nicht mehr aufrufen kann (wenn die GEMDOS-Funktionen benutzt werden sollen)!!! Auch Michael Ziegler (GSZRZ-Autor) alleine kann sich bemühen wie er will, wenn das Terminalprogramm keine Voraussetzungen für die Zusammenarbeit schafft, ist das externe Übertragungsprotokoll machtlos. An wem bleibt der Mist (=Arbeit) hängen? ---------------------------------------- Wie schon beim DRVIN für MagiCMac, "natürlich" an mir. Es gibt aus meiner Sicht nur zwei Lösungen, bei denen die Programmierer der betreffenden DFÜ-Soft auf der faulen Haut liegen bleiben können. Beide Lösungen sind ziemlich stark "daneben", d.h. laufen in eine Richtung, die der eines sicheren Multitasksystems entgegengesetzt ist. "Lösungen" ---------- Variante 1) Ein kleiner Patch hängt im GEMDOS-Trap und ändert alle Fopen(/Fcreate) auf U:\DEV\ so, daß der Modus immer um "Filesharing erlaubt" ergänzt an MagiC weitergereicht wird. Variante 2) Ein kleiner "Treiber" sucht aus der RSVF-Struktur die Informationen eines schon installierten Schnittstellentreibers heraus und installiert im GEMDOS und BIOS einfach den Treiber unter einem anderen Namen nochmal. Dann steht eine physische Schnittstelle unter zwei verschiedenen GEMDOS-Namen und BIOS-Nummern zur Verfügung, z.B. die MODEM1-Hardware als MODEM1 und MO1KOPIE. Der Nutzer sagt dem Connect, es soll auf MODEM1 arbeiten, und dem GSZRZ, es soll MO1KOPIE benutzen. Mal sehen, ob ich diesen Sonntag noch Zeit finde, solchen Müll zu programmieren. An die Programmierer von DFÜ-Software ------------------------------------- Wenn eure Programme auch unter MagiC3 und MagiCMac zusammenarbeiten sollen, dann gibt es dafür einige Möglichkeiten. Kurzerklärung des Problems: MagiC verhindert es, daß eine mit mode=2 geöffnete Datei (=Schnittstellentreiber) nochmal mit mode=2 von einem anderen Prozeß geöffnet wird. 1.) Alle benutzen für die Geräte in U:\DEV\ beim Fopen den Modus "Sharing - alles erlaubt", d.h. im mode-WORD wird Bit6 gesetzt, also OR $0040. Nachteil: andere Programme können GEMDOS-mäßig auf der Schnittstelle herumfummeln, so wie es beim DRVIN bisher üblich ist. Das Terminalprogramm muß also die Schnittstelle mit diesem Modus öffnen, und das nachgestartete Übertragungsprotokoll ebenfalls. 2.) Vor dem Aufruf eines externen Programms macht der Aufrufer die Schnittstelle zu und nach der Rückkehr wieder auf. So kann der Aufgerufene ungehindert die Schnittstelle öffnen und benutzen und am Ende schließen. Dieser Modus ist einigermaßen vernünftig, hat nur ein Problem, was eventuell irgendwann mal unter MiNT oder in Zukunft zuschlagen könnte, wenn ein Schnittstellentreiber auf die Idee kommt, bei Fclose das DTR-Signal inaktiv zu schalten. Meine Treiber tun das jedoch nicht! 3.) Der Aufrufer übergibt dem Aufgerufenen in der Kommandozeile das Handle der geöffneten Schnittstelle. Unter MiNT müßte das funktionieren, wenn die Schnittstelle nicht als "nicht vererbbar" geöffnet wurde. Unter MagiC - jetzt habe ich schon wieder vergessen, ob da generell nur die Standardkanäle vererbt werden oder diese Einschränkung inzwischen offiziell aufgehoben ist - funktioniert es auf jeden Fall auch. Zusammenfassung: Bei 2.) sind nur die Programmierer der Aufrufer gefordert (Hallo Terminalprogrammbastler, hoffentlich habt ihr das zur Kenntnis genommen!), bei 1.) und 3.) müssen die Programmierer der Aufrufer und der Aufgerufenen etwas tun. Gruß HS Das Resultat ------------ Dieses Programm heißt einfallsloserweise SCHWEIN. Es realisiert Variante 1. (Siehe Schwein.UUE)