nie spotkałem programu na Atari, który zapisując ustawienia zrobił by to gdzie indziej niż tam, gdzie został uruchomiony. Teoretycznie zastanawiałem się nad takim rozwiązaniem w przypadku trsdesktop - lecz na chwilę obecną zapis ustawień jest związany z katalogiem gdzie program został zainstalowany :)

W sumie to jest duza zaleta a nie wada. Np. w Mac Os'ie tak jest i chcac przeniesc program, zrobic jego backup lub go  skasowac po prostu operuje sie na katalogu w ktorym zostal on zainstalowany.

Moje pytanie padło, bo chciałem wiedzieć czy istnieje juz wypracowany standard.
Czyli nie ma ogólnego katalogu dla plików *.ini  oraz   *.set

Chce dodać do Atari Commandera (a dokładnie jesli uruchomi się go pod SDX) opcje zapamiętywania w pliku *.set ostatnio używanych sciężek dla lewego i prawego panelu....

to propozycja z mojej strony brzmi tak, by za katalog dla plików z ustawieniami przyjąć katalog SPARTA.DOS - oczywiście w przypadku wersji 4.40. Nie pamiętam jednak, jak zareaguje na to dos, bo domyślnie w owym katalogu zapisywane są pliki z konfiguracją dosa możliwą do wyboru z poziomu menu startowego. Nie mam w tej chwili pod ręką Atarki, by to sprawdzić. Chodzi o to, by np. plik konfiguracyjny AC nie pojawił się w boot menu :) - W przypadku wcześniejszych wersji Sparty proponuję wrócić z ustawieniami do katalogu z którego ac został odpalony - czyli w tym przypadku dobrze by było, by plik ac.ini, czy ac.cokolwiek tam :) - był też poszukiwany z użyciem ścieżki definiowanej w Sparta dos - to na wypadek, gdyby ac został uruchamiany przy użyciu ścieżki z dowolnego miejsca na dysku.

A konkretnie najpierw katalog z ktorego uruchamiana jest binarka (niekoniecznie ten w ktorym ona jest, zawsze mozna uruchamiac podajac pelna sciezke), a potem zmienna path i juz.
Tak bylo i dzialalo od lat i bylo dobrze. Po co to zmieniac?
Zawsze mozna (tak jak ja) stworzyc sobie pliki wsadowe uruchamiajace najpopularniejsze aplikacje i katalog z takimi plikami umiescic na poczatku path, a potem juz w samych plikach przechodzic lub nie do odpowiedniego katalogu przed wywolaniem pliku binarnego.

Rozwiązanie proste (dla kodera), pliki *.set w jednym katalogu, np. D1:>SETUP>AC.SET czyli krótka informacja tekstowa...

Rozwiązanie proste (dla usera), plik *.set wraz z binarką:

 lda $700
 cmp #'S' ;sparta
 bne noFileSet
 lda $701
 cmp #$39
 bcc noFileSet

 lda $A  ;...get adress TABCOM+63
 clc
 adc #63
 sta $FE
 lda $B
 adc #0
 sta $FF

 ldy #0
nxt lda ($FE),y
 bmi fine
 cmp #'X'
 bne skip
 iny
 lda ($FE),y
 cmp #' '
 bne nxt

;znalezione CAR:X - usun z nazwy 
;zakoduj se :)))

skip iny
     jmp nxt
fine 

;zamien (jeśli jest) rozszerzenie na "SET"
;zakoduj se :)))

I to jest problem - mase kodu...

Ma być latwiej dla uzykownika a nie programisty - to nie system Finansowo-Ksiegowy :)

A skoro tak to poprostu plik konfiguracyjny jest w katalogu z ktorego uruchamiamy binarke i juz. Jak ktos chce umiescic go w innym miejscu zawsze moze przejsc do tego smiesznego katalogu i z niego wywolac binarke z pelna sciezka (plikiem wsatowym np).

...a 1 MB na simmie "miało wystarczyć każdemu" :D

Dokładnie tak jest, ale tylko do momentu, kiedy program nie wywoła CHDIR zmieniając bieżący katalog...

poza tym jeśli ac mamy w:

C:\utilz\ac.exe

a set wygląda tak:
...
path c:\utilz\;:.......
...

i AC odpalamy np. z D1:->D2:, lub D4:->D15: to o ile AC nie będzie przeszukiwać PATH to całość zakończy się brakiem możliwości dostępu do AC.SET. Co innego byłoby w chwili, gdy AC używałoby PATH, lecz w takim przypadku jeśli ścieżka jest długa spowoduje to znaczące opóźnienia przy próbie uzyskania dostępu do danych z AC.SET. Ogólnie wydaje mi się, że najlepszym rozwiązaniem jest krótki i prosty program instalacyjny do AC i ścisłe określanie lokalizacji katalogu roboczego programu - czyli instalator zapisuje na "stałe" w AC.EXE dane odnośnie lokalizacji. I problem z głowy :)