Ergebnis von Dgetpath() abhängig von der GEMDOS-Version?

[Count]

Ich mal wieder. 

Heute habe ich festgestellt, dass verschiedene TOS-Versionen beim Aufruf von Dgetpath() nicht immer den gleichen Pfad zurückliefern, wenn das Arbeitsverzeichnis das Wurzelverzeichnis eines Laufwerks ist.

Getestet habe ich das mit TOS 2.06 und TOS 4.04.

TOS 2.06 liefert "\" zurück, TOS 4.04 einen leeren String.

Ist dieser Bug (kann kein Feature sein) in TOS 4.04 bekannt und irgendwo dokumentiert?

Hintergrund: In einem Programm speichere ich zu Beginn das aktuelle Arbeitsverzeichnis, um später vor dem Aufruf bestimmter Programme das Arbeitsverzeichnis wechseln und anschließend zurückkehren zu können. Das funktioniert natürlich nicht, wenn Dgetpath() einen leeren String liefert, der später an Dsetpath() übergeben wird.

[1ST1]

Funktioniert das bei dir denn grundsätzlich mit dgetpath und dsetpath bei Sachen, die im Unterordner liegen? Ich habe das mal benutzt, um Programme zu starten, also erstmal mit dsetpath einen Pfad zu setzen, und dann mit psexec Programme darin zu starten. Das hat aber nie so wirklich funktioniert, viele zu startende Programme konnten ihre RSC-Datei auws dem gleichen Ordner nicht finden. Seit ich das nicht zuverlässig zum Laufen bekomme, hab ich an dem Tool nicht weiter gemacht.

[Thorsten Otto]

Natürlich geht das aus einem beliebigen Verzeichnis, oder liegen bei dir alle Programme in C:\? Allerdings ist das saubere starten von Programmen in Single-TOS tatsächlich nicht so trivial, wenn man nicht gerade der Desktop ist. Auf jeden Fall musst du dafür auch shel_write() benutzen damit die RSC-Dateien (und manchmal auch andere) gefunden werden.

TOS 3.06 liefert bei mir auch einen leeren String im Wurzelverzeichnis, und das GEMDOS dort ist absolut identisch zu 2.06. Weiss jetzt gerade nicht so genau ob das so dokumentiert ist, ist aber dann wohl kein Bug von 4.04

[1ST1]

Shel_write ist mir auch ein Begriff, ich glaube auch damit habe ich es versucht. Ich muss mir den Quellcode nochmal ansehen. (Ist in ST-Pascal+).

[Count]

Ach Mist, man soll einfach nicht Emulatoren vertrauen. Auf echter Hardware liefert Dgetpath() auch unter TOS 2.06 einen leeren String zurück.

Zu 1ST1:

Ich mache den Aufruf der Programme in etwa so:

Code: [Auswählen]

short appl_type; /* 0=TOS, 1=GEM, anhand der Dateiendung */
short win;
long rc;

shel_write(1, appl_type, 0, (char*)program, param);
wind_set(0, WF_NEWDESK, 0, 0, 0, 0);

/* alle Fenster schließen */

do {
    short dummy;
   
    wind_get(0, WF_TOP, &win, &dummy, &dummy, &dummy);
   
    if (win > 0) {
wind_close(win);
wind_delete(win);
    }
} while (win > 0);

rc = Pexec(0, program, param, env);

shel_write(0, 1, 0, "", "\0\0");


[czietz]

Ach Mist, man soll einfach nicht Emulatoren vertrauen. Auf echter Hardware liefert Dgetpath() auch unter TOS 2.06 einen leeren String zurück.

In diesem Fall musst Du nicht einmal echte Hardware verwenden. Es genügt, im Emulator (BTW: Hatari oder Steem?) die GEMDOS-Laufwerksemulation abzuschalten. Es ist bekannt, dass diese nicht immer 100% exakt ist. Wenn Du mit Disketten- oder Festplatten-Images arbeitest, verhält sich GEMDOS im Emulator so wie auf echter Hardware.

[Count]

In diesem Fall war es Steem 3.2. Da gibt es die Möglichkeit mit HD-Images zu arbeiten meines Wissens nicht.

[thh]

Falls es noch von Interesse ist: Zu mindest in Hatari wurde der Bug inzwischen behoben und sollte mit der nächsten Version verfügbar sein:
https://git.tuxfamily.org/hatari/hatari.git/commit/?id=775a9604644823a