Win_Lnk
Inhalt
ÜberblickEntwicklungsstandInstallationDeinstallationDie Erweiterungen im einzelnenFür Programmierer
Logfile
Veränderten Funktionen
Fcreate(60) Fopen(61), Pexec(75) und Fattrib(67)Pexec(75) und shel_envrn(AES 125)
Win_Lnk diente ursprünglich nur dazu die Windows-Verweise unter MagicPC als vollwertige symbolische Links zu verwenden. Mit und mit werden aber auch andere MagicPC-Erweiterungen eingebaut.Dazu werden einige GEM-DOS- und AES-Routinen angepaßt. Zum Verbiegen der BS-Routinen wird Trapper benutzt.
Dies ist eine der ersten öffentlichen, also nicht ß-Versionen, aber garantieren, daß keine Fehler auftreten kann ich leider nicht.
Zur Installation muß die unlnk.dll in das MPS Verzeichnis (ggf. anlegen) im MagicPC-Ordner kopiert werden. Das Win_Lnk.prg gehört eigentlich in den Auto-Ordner, Start-Ordner oder die Autoexec.bat, kann aber auch normal gestartet
werden. Auf alle Fälle muß Trapper vorher gestartet werden!
Zu win_lnk gehört auch ein win_lnk.ini. Dies gehört normalerweise in den gleichen Ordner wie win_lnk.prg, bzw bei Start aus autoexec.bat o.ä. ins Routverzeichnis der
Bootpartition, also normalerweise nach C:\. Hier kann man die einzelnen Erweiterungen bei bedarf deaktivieren. Genaueres steht in dem beigefügten win_lnk.ini
Startet man Win_Lnk obwohl es bereits installiert ist, so kann man es deinstallieren. Dies geht aber ggf. nur Schrittweise, da evtl. noch Speicher freigegeben werden muß. Dies kann beliebig lange dauern. Wenn z.B. für Pexec Speicher reserviert wurde kann der erst freigegeben werden wenn das Programm beendet wird.Dies gilt aber nur wenn beide Instanzen die gleiche Versionsnummer haben. Läuft aber z.B. win_lnk 1.05 und man startet 1.06 so beendet sich 1.05 und die 1.06 wird installiert.
Die Erweiterungen im einzelnen
- Windows-Verweise unter MagicPC als vollwertige symbolische Links verwenden. Das Ziel war, daß sich MagicPC bei Links möglichst genau so verhält wie Magic. Dies aber so, daß es tranparent auf den Möglichkeiten von Windows aufbaut.Wie man unter MagicPC symbolische Links verwendet steht in der Magic Anleitung. Es gibt aber einige Besonderheiten. Links anlegen kann man unter MagicPC oder unter Windows. Dabei sind unter Windows Sachen möglich die unter Magic nicht möglich wären und dadurch zu Problemen führen. I.W. geht es dabei um doppelte Namen. Genaueres s.u. unter Dreaddir(297) und Dxreaddir (322). Mein Rat, so etwas einfach unterlassen.
- Win_lnk bietet eine Möglichkeit an Environmentvariablen unter Windows zu definieren und unter MagicPC zu nutzen. Dies ist vor allem sinnvoll bei Multiuser-Windowsvarianten, da man dort für jeden User die Variable anders definieren kann. Details s.u. unter Pexec(75) und shel_envrn(AES 125)
- Zum starten von Windows Programmen aus MagicPC heraus gibt es MPC_ACC.ACC. Dies hat aber den Nachteil, daß es vergißt die Pfade anzupassen. Das Windows Programm bekommt also die MagicPC - Pfade. WIN_LNK bietet nun die
Möglichkeit Windowsprogramme wie normale Programme zu starten. Das ACC wird also nicht mehr benötigt. Durch definieren eines Environmentstrings kann man bestimmen welche Programme WIN_LNK durch Windows ausgeführen lassen
soll. Dies geschieht in magx.inf im Rootverzeichis. Soll also z.B. nur *.exe an Windows übergeben werden, so muß dort:
#_ENV WinExeExt=.EXE;
stehen. Um weitere Endungen hinzuzufügen werden diese einfach jeweils durch einen Punkt getrennt angefügt. Außerdem muß der verwendeten Shell klar gemacht werden, daß sie diese Files wie Programme behandeln soll. Dies geschieht in Jinnee z.B. unter Sonstiges/Einstellungen. Dort links Programme auswählen und unter GEM-Programme die Endung, also z.B. *.exe, hinzufügen. - Eigentlich kann MagicPC die Zwischenablagen auf Atari Seite mit der Windowsablage verbinden. leider funktioniert dies in der Richtung Atari -> Windows nur einmal. Dies kann WIN_LNK korrigieren. Bisher kümmert sich WIN_LNK (wie MagicPC überhaupt) nur um Texte. Win_lnk ignoriert die Einstellung von MagicPC ob die Windows - Zwischenablage benutzt werden soll. Wer es also nicht will muß es an beiden Stellen abstellen.
- Égale: damit Égale weniger Probleme mit der Groß/Kleinschreibung von Filenamen hat habe ich es gepatcht, dazu gehörn aber auch noch geänderte BS-Funktionen, diese kann man entweder über das separate dir_lwr instalieren oder eben hier. Weitere Infos bei Dir_lwr
Ab V 0.32 kann von der Windowsseite ein Logfile geschrieben werden. Dise Funktion ist in 2
Stufen (de)aktivierbar:
Ab Version 1.0 ist DOLOG standarmäßig nicht mehr definiert.Wer will kann es also im Quelltext leicht reaktivieren. Einfach DOLOG definieren . Der Grund, daß es rausflog war, daß diese Funktion ebensoviele Fehler verursachte wie
sie half zu lösen. Damit das mitlogen funktioniert muß die Systemvariable LOGDIR oder TEMP definiert sein (auf Windowsseite!)!
Alternativ kann man auch MagicPC debuggen (im Taskmanager rechts anklicken...) Dann werden bei
abgeschaltetem Logfile (aber definiertem DOLOG) TRACE-Ausgaben in das Debugfenster gemacht. Da einige MagicPC Versionen mit dieser Debug-dll aber Probleme haben lege ich nur die Release-Version bei. Zur Reaktivierung der Logausgabe
muß man die dll ja sowieso neu erstellen..
In Klammern sind jeweils die Gemdos-Funktionsnummern angegeben Die Funktionen sind Gruppenweise aufgeführt. Einzelne Funktionen können mehrfach auftreten.
Fcreate(60) Fopen(61), Pexec(75) und Fattrib(67)
Werden diese Funktionen auf einen Link angewendet, so wird dieser verfolgt. Allerdings nur wenn die Endung .lnk nicht angegeben wird. Da der Fileselector, Fsfirst/Fsnext, und D(x)readdir das LNK abschneiden ist dies der Normalfall. Bei Pexec werden außerdem Windowsenvironments ermittelt, s. hiernach und es kann das Starten von Windowsprogrammen an Windows übergeben. Fcreate und Fopen werden auch zum Übertragen der Zwischenablage verändert s.u.
Pexec(75) und shel_envrn(AES 125)
Ein Problem von MagicPC ist, daß es keine Multiuserfähigkeiten hat. Ein wichtiger Punkt dabei sind userabhängige
Environments. Vor allem z.B. HOME. Je nach Windowsversion unter MagicPC bietet dies aber das Hostsystem. Was liegt also näher als Environments durchzureichen. Ich erkläre es am einfachsten an einem Bsp. Nehmen wir an, ich möchte
HOME auf Windowsseite definieren, dann setze ich in Magx.inf die folgende Zeile:
#_ENV HOME=%WIN%
Wird jetzt HOME abgefragt, so erkennt Win_Lnk, daß es als Resultat die Definition von HOME auf Windowsseite nehmen soll. Angenmmen es gäbe aber auf Windowsseite auch ein HOME und beide sollen verschieden sein, dann kann man auf
Windowsseite einen beliebigen anderen Namen wählen, z.B. HOME_MPC. Dazu setzt man in Magx.inf die folgende Zeile:
#_ENV HOME=%WIN%:HOME_MPC
Im 1. Fall muß man also unter Windows HOME im 2. HOME_MPC definieren. Environments können unter MagicPC auf 2 Arten abgefragt werden, entweder per shel_envrn das der Shell, oder über die eigene Basepage. Letzteres wird bei pexec
vererbt bzw neu definiert. Deshalb werden beide Befehle angepaßt. Die Syntax muß genau eingehalten werden, also keine zusätzlichen Leerzeichen o.ä. Win_Lnk versucht den von Windows erhaltenen Parameter als Pfad zu interpreteren und
in das MagicPC Filesystem zu übertragen, schlägt dies fehl wird der String unverändert übergeben. Also Pfade so definieren wie sie unter Windows richtig sind.
Fcreate(60) Fopen(61) Fclose(62) und Fdelete(65)
wird scrap.txt (im entsprechenden Direktory) zum schreiben geöffnet (Fopen oder Fcreate) so merkt sich win_lnk das Handle. Wird dieses File
später wieder geschlossen, so kopiert win_lnk den Inhalt in die Windowsablage.
Hier wird ggf. das S_IFLNK Bit gesetzt
Je nach Flag werden Links verfolgt oder nicht. Ordnerlinks werden immer verfolgt.
Gibt das Ziel eines Links zurück
Dreaddir(297) und Dxreaddir (322)
Wird ein File als Link erkannt, wird das .lnk entfernt Ist der Filename dann nicht mehr eindeutig ein ~L an den Filenamen angehängt. Außerdem wird in mode S_IFLNK gesetzt. Bsp es gebe in einem Dir folgende 3
Files:
würde bei 1) einfach das .lnk entfernt, wäre 1) und 2) nicht mehr unterscheidbar. file1~L.txt file1.txt file2.txt
Deshalb macht D(x)readdir daraus:
Diese beiden Funktionen reagieren wie gehabt, allerdings benötigen D(x)readdir Parameter von Dopendir, deshalb speicher ich diese hier zwischen. Und da dieser Speicher auch irgendwann wieder freigegeben werden soll mußte auch Dclosedir verändert werden.
Das Ziel ist, kurze Dateinamen zurück zu geben, die bei Links aber die richtige Endung haben. Das normale Fsnext würde immer *.lnk zurückgeben Probleme machen Files die einmal normal und einmal als LNK existieren.
Außerdem muß die Änderung der Endung später wieder rückgängig gemacht werden können. Zur Erklärung ein Bsp: Alle lnk Files seien Links. Das normale Fsfirst würde aus diesen 9 Namen so etwas machen:
Die Datei 2) wäre also für einen Editor nicht mehr als Textfile erkennbar, und die Dateien 4),6),7) 8) und 9) hätten Endungen mit denen die wenigsten Programme und User etwas anfangen könnten. Deshalb machen die
neuen Fsfirst/Fsnext Routine daraus:
Sollen diese Dateien später z.B. mit Fopen geöffnet werden, so erkennt Win_Lnk an den ~ gefolgt von einem Buchstaben, daß es entsprechend manipulierte Dateinamen sind. Und es kann die ursprünglichen auf 8.3 gekürzten Namen
rekonstruieren. "~L" und ".~L" werden einfach weggelassen ~A bis ~J werden durch ~0 bis ~9 ersetzt. Außerdem wird eine vorhandene Endung durch lnk ersetzt bzw .lnk angehängt. Am wenigsten gefällt mir 4), aber
bei Filenamen >6 ist die Methode von 6) leider in den Grenzen von 8.3 nicht mehr durchführbar. Auch 9) ist etwas gewöhnungsbedürftig.
In einem Dir seien die folgenden Dateien:
fsel_input (AES 90) und fsel_exinput(AES 91), rsrc_load (AES 110), shel_find(AES 124) und shel_write (AES 121)
haben sich sozusagen automatisch angepaßt, sie rufen wohl intern geänderte Gemdos-Funktionen auf.
Handelt es sich bei der Quelle um einen Link, so wird dieser (also das lnk-File) gelöscht bzw umbenannt.
Hier habe ich eine eigene Routine geschrieben, die auf die entsprechenden Windows Routinen zugreift. Das Linkziel wird ggf. verfolgt. So entstehen keine Links auf Links. Dies macht Windows genau so, und da MagicPC sich ja im Windowsfilesystem an dessen Regeln halten sollte mach ich das eben auch so.
hier werden nur Ordnerlinks verfolgt.
Dcreate(57), Ddelete(58) und Dsetpath(59)
Falls diese ein EPTHNF zurück geben wird versucht den Pfad zu dereferenzieren und dann ggf die Funktion nochmal aufgerufen.