Dyskusja:Formaty plików
From Atariki
| Wersja z dnia 16:24, 19 wrz 2005 KMK (Dyskusja | wkład) ← Previous diff |
Aktualna wersja Sikor (Dyskusja | wkład) (==>>Użytkownik) |
||
| Linia 4: | Linia 4: | ||
| --[[0xF]] 13 wrz 2005 11:24 | --[[0xF]] 13 wrz 2005 11:24 | ||
| - | Tez mialem watpliwosci - chodzi tutaj o format handlera np interfejsu 850 ktory jest plikiem binarnym downloadowanym z urzadzenia na komputer --[[Wikipedysta:Mikey|Mikey]] 12:14, 13 wrz 2005 (CEST) | + | Tez mialem watpliwosci - chodzi tutaj o format handlera np interfejsu 850 ktory jest plikiem binarnym downloadowanym z urzadzenia na komputer --[[Użytkownik:Mikey|Mikey]] 12:14, 13 wrz 2005 (CEST) |
| - | :Nie handlera 850, ten ma "custom format", zależny od urządzenia. Chodzi o format handlerów "TYPE 3 POLL", zależny od relokatora, który jest w ROM-ie XL/XE. Tak więc, Foxie, mógłbyś na przyszłość pytać (-> Dyskusja), nim coś zbroisz. A ATP cofnęło się przypadkiem przy okazji. [[Wikipedysta:KMK|KMK]] 14:42, 13 wrz 2005 (CEST) | + | :Nie handlera 850, ten ma "custom format", zależny od urządzenia. Chodzi o format handlerów "TYPE 3 POLL", zależny od relokatora, który jest w ROM-ie XL/XE. Tak więc, Foxie, mógłbyś na przyszłość pytać (-> Dyskusja), nim coś zbroisz. A ATP cofnęło się przypadkiem przy okazji. [[Użytkownik:KMK|KMK]] 14:42, 13 wrz 2005 (CEST) |
| Ok, "handlery systemowe" jest zbyt mylące, przydałoby się sprecyzować. | Ok, "handlery systemowe" jest zbyt mylące, przydałoby się sprecyzować. | ||
| Sądziłem, że chodzi o handlery CIO. | Sądziłem, że chodzi o handlery CIO. | ||
| - | --[[Wikipedysta:0xF|0xF]] 14 wrz 2005 13:36 | + | --[[Użytkownik:0xF|0xF]] 14 wrz 2005 13:36 |
| - | :Owszem, CIO również. [[Wikipedysta:KMK|KMK]] 14:18, 14 wrz 2005 (CEST) | + | :Owszem, CIO również. [[Użytkownik:KMK|KMK]] 14:18, 14 wrz 2005 (CEST) |
| - | a może po prostu "pliki sterowników ..."? :) --[[Wikipedysta:Miker|miker/bjb/ng]] 20:34, 14 wrz 2005 (CEST) | + | a może po prostu "pliki sterowników ..."? :) --[[Użytkownik:Miker|miker/bjb/ng]] 20:34, 14 wrz 2005 (CEST) |
| - | :Czemu nie, o ile to cokolwiek zmienia :) [[Wikipedysta:KMK|KMK]] 20:40, 14 wrz 2005 (CEST) | + | :Czemu nie, o ile to cokolwiek zmienia :) [[Użytkownik:KMK|KMK]] 20:40, 14 wrz 2005 (CEST) |
| Gdyby ktoś je opisał, to może wreszcie bym wiedział, co to jest. :) | Gdyby ktoś je opisał, to może wreszcie bym wiedział, co to jest. :) | ||
| Czy aby na pewno są to pliki, czyli coś, co można zapisać na dysku | Czy aby na pewno są to pliki, czyli coś, co można zapisać na dysku | ||
| (i ma to jakiś sens)? Bo np. bloki PERCOM nie są plikami, chociaż mają swój format. | (i ma to jakiś sens)? Bo np. bloki PERCOM nie są plikami, chociaż mają swój format. | ||
| - | --[[Wikipedysta:0xF|0xF]] 10:33, 15 wrz 2005 (CEST) | + | --[[Użytkownik:0xF|0xF]] 10:33, 15 wrz 2005 (CEST) |
| - | :Ale blok PERCOM ma jednolitą strukturę, jest to po prostu ciąg 12 bajtów, natomiast te nieszczęsne handlery są podzielone wewnętrznie na bloki z nagłówkami, które sterują pracą relokatora czy też loadera (siedzącego w ROM-ie). Jest to jakiś format binarny i zamierzam go opisać, ale na razie tego jeszcze nie zrobiłem. [[Wikipedysta:KMK|KMK]] 15:02, 15 wrz 2005 (CEST) | + | :Ale blok PERCOM ma jednolitą strukturę, jest to po prostu ciąg 12 bajtów, natomiast te nieszczęsne handlery są podzielone wewnętrznie na bloki z nagłówkami, które sterują pracą relokatora czy też loadera (siedzącego w ROM-ie). Jest to jakiś format binarny i zamierzam go opisać, ale na razie tego jeszcze nie zrobiłem. [[Użytkownik:KMK|KMK]] 15:02, 15 wrz 2005 (CEST) |
| "podzielone wewnętrznie na bloki z nagłówkami" ? | "podzielone wewnętrznie na bloki z nagłówkami" ? | ||
| To w końcu są to pliki zapisywane na dysku, czy nie? | To w końcu są to pliki zapisywane na dysku, czy nie? | ||
| - | --[[Wikipedysta:0xF|0xF]] 16:32, 15 wrz 2005 (CEST) | + | --[[Użytkownik:0xF|0xF]] 16:32, 15 wrz 2005 (CEST) |
| - | :Co ma jedno do drugiego, bo nie bardzo rozumiem? [[Wikipedysta:KMK|KMK]] 16:47, 15 wrz 2005 (CEST) | + | :Co ma jedno do drugiego, bo nie bardzo rozumiem? [[Użytkownik:KMK|KMK]] 16:47, 15 wrz 2005 (CEST) |
| Nie rozumiem tego "podzielone wewnętrznie..." i nie odpowiedziałeś na moje pytanie wyżej, | Nie rozumiem tego "podzielone wewnętrznie..." i nie odpowiedziałeś na moje pytanie wyżej, | ||
| czy to są pliki. | czy to są pliki. | ||
| - | :Nie bardzo rozumiem, co jest niejasnego albo niemożliwego w sformułowaniu "podzielone wewnętrznie". A co do pytania, to chyba jednak odpowiedziałem (w zasadzie, to nawet przed zadaniem pytania). No i też nie bardzo rozumiem - już jakoś tak mam, że nic nie rozumiem - co ma pojęcie pliku wspólnego z tym, czy jest umieszczony na dysku. [[Wikipedysta:KMK|KMK]] 18:24, 19 wrz 2005 (CEST) | + | :Nie bardzo rozumiem, co jest niejasnego albo niemożliwego w sformułowaniu "podzielone wewnętrznie". A co do pytania, to chyba jednak odpowiedziałem (w zasadzie, to nawet przed zadaniem pytania). No i też nie bardzo rozumiem - już jakoś tak mam, że nic nie rozumiem - co ma pojęcie pliku wspólnego z tym, czy jest umieszczony na dysku. [[Użytkownik:KMK|KMK]] 18:24, 19 wrz 2005 (CEST) |
| - | :Jeśli chodzi o sterowniki nowych urządzeń, ściągane przez OS XL/XE | + | Jeśli chodzi o sterowniki nowych urządzeń, ściągane przez OS XL/XE |
| specjalnymi komendami SIO, to powinny być w Protokoły / SIO / Handlery systemowe, | specjalnymi komendami SIO, to powinny być w Protokoły / SIO / Handlery systemowe, | ||
| czy jak to się tam nazywa. Zgodzisz się chyba, że np. TCP/IP nie jest formatem pliku. | czy jak to się tam nazywa. Zgodzisz się chyba, że np. TCP/IP nie jest formatem pliku. | ||
| - | --[[Wikipedysta:0xF|0xF]] 15:06, 19 wrz 2005 (CEST) | + | --[[Użytkownik:0xF|0xF]] 15:06, 19 wrz 2005 (CEST) |
| - | :Oczywiście, że nie, TCP/IP jest protokołem przesyłu danych, podobnie - mutatis mutandis - jak np. SIO. Ale też jakby nie o ten poziom organizacji danych tu idzie. Przy użyciu protokołu SIO można przesłać plik binarny, a jednak prawdopodobnie nie byłbyś skłonny plików uruchamialnych DOS-u umieszczać w dziale "protokoły", zgodzimy się tu chyba. [[Wikipedysta:KMK|KMK]] 18:24, 19 wrz 2005 (CEST) | + | :Oczywiście, że nie, TCP/IP jest protokołem przesyłu danych, podobnie - mutatis mutandis - jak np. SIO. Ale też jakby nie o ten poziom organizacji danych tu idzie. Przy użyciu protokołu SIO można przesłać plik binarny, a jednak prawdopodobnie nie byłbyś skłonny plików uruchamialnych DOS-u umieszczać w dziale "protokoły", zgodzimy się tu chyba. [[Użytkownik:KMK|KMK]] 18:24, 19 wrz 2005 (CEST) |
| + | |||
| + | Oczywiście plik wykonywalny nie jest protokołem, ale to dlatego, że jest osobnym bytem, | ||
| + | który można zapisać w dowolnej pamięci masowej i przesłać dowolnym protokołem (w tym TCP/IP) | ||
| + | i '''ma to sens'''. Co innego PERCOM czy (jak podejrzewam) te "handlery": | ||
| + | nie mają racji bytu bez SIO. Nie wiem, jak są zorganizowane te "handlery": | ||
| + | może są osobnym protokołem "stojącym na" protokole SIO, tak jak TCP "stoi na" IP. | ||
| + | --[[Użytkownik:0xF|0xF]] 13:18, 20 wrz 2005 (CEST) | ||
| + | |||
| + | No więc właśnie jakby nigdzie nie jest napisane, że taki handler nie jest "osobnym bytem". Można sobie wyobrazić, że w urządzeniu typu pamięci masowej handler będzie właśnie zapisany na nośniku jako plik, nie ma tu żadnych przeciwwskazań. Z drugiej strony idąc tokiem twojego rozumowania, że plik to jest zbiór danych będący "osobnym bytem, który mozna zapisać na dowolnej pamięci masowej i przesłać dowolnym protokołem i ma to sens", łatwo dojść do wniosku, że plikiem nie jest DOS.SYS (albowiem co prawda można go przesłać dowolnym protokołem, ale już zapisywanie go na pamięci masowej innej niż dyskowa - np. na taśmie - ma sens dyskusyjny). | ||
| + | |||
| + | Nie bardzo więc widzę, jak DOS.SYS, który jest ładowany przez system z urządzenia komendami SIO i jest programem binarnym zawierającym sterownik można uznać za plik, natomiast dokładnie taki sam handler binarny również ładowany z urządzenia komendami SIO za plik uznany być nie może. DOS.SYS niby ma wpis w katalogu - ale przecież nie musi go mieć, prawda? A z drugiej strony, jak wyżej napisałem, nigdzie nie jest powiedziane, że dyskutowany tu handler wpisu katalogowego mieć nie może. | ||
| + | |||
| + | Po drugie PERCOM i wszystko inne ma bardzo dobrą rację bytu bez SIO i jego protokołu transmisji. Nie przypuszczasz chyba, że protokołem SIO komputer się posługuje do komunikacji z twardym dyskiem. Chyba, że SIO rozwijamy jako "Sector Input/Output", wtedy owszem, PERCOM (et consortes) nie ma racji bytu bez SIO. [[Użytkownik:KMK|KMK]] 15:21, 20 wrz 2005 (CEST) | ||
| + | |||
| + | Trafny przykład z tym DOS.SYS. Cofam "dowolnej" przy "pamięci masowej". :-) Wciąż jednak | ||
| + | jest to pamięć masowa (stąd plik). Odsyłam [[http://pl.wikipedia.org/wiki/Plik tu]]. | ||
| + | Jaką nazwę mają te Twoje handlery, hę? | ||
| + | |||
| + | Jeśli chodzi o transmisję DOS.SYS vs handlery przez SIO, to DOS.SYS jest przesyłany | ||
| + | jak każdy inny plik, natomiast dla handlerów, o ile wiem, są specjalne komendy. | ||
| + | |||
| + | Cofam też, że PERCOM jest fragmentem SIO. Natomiast komunikacja z twardym dyskiem | ||
| + | jak najbardziej może być przez SIO ([[SIO2IDE]]). Poza tym "Serial" w SIO może być tylko | ||
| + | nazwą - np. stacja [[Karin Maxi]] (jako nowe urządzenie) przechwytuje komendy SIO i nie ma | ||
| + | tam transmisji szeregowej. | ||
| + | --[[Użytkownik:0xF|0xF]] 13:09, 21 wrz 2005 (CEST) | ||
| + | |||
| + | No toż właśnie mówię - przy urządzeniach takich jak Karin albo większość twardych dysków (ok. oprócz SIO2IDE, ale to jest raczej emulator stacji dysków) nie ma transmisji szeregowej i nie ma zastosowania protokół komunikacji z urządzeniami szeregowymi. W SIO "serial" może być nazwą właśnie, i wtedy nie ma protokołu szeregowego. Ale dla normalnej stacji dysków ten protokół ma zastosowanie, przecież. | ||
| + | |||
| + | Natomiast przekonałeś mnie co do tych komend specjalnych - i niech będzie, że to protokół, ale nadal niezbyt mi się podoba fakt, że dane nie tylko są przesyłane specjalnymi komendami, ale ponadto muszą być w odpowiedni sposób sformatowane, bo inaczej nic się nie załaduje. Natomiast definicja pliku z pl.wiki jak najbardziej tu może mieć zastosowanie, już o tym była mowa: "jest to nazwany ciąg danych (inaczej zbiór danych), o skończonej długości, posiadający szereg atrybutów i stanowiący dla systemu operacyjnego całość". Handler jak najbardziej może mieć nazwę, ma też skończoną długość i stanowi dla systemu operacyjnego całość :-) [[Użytkownik:KMK|KMK]] 14:31, 21 wrz 2005 (CEST) | ||
| + | |||
| + | "niezbyt mi się podoba fakt, że dane nie tylko są przesyłane specjalnymi komendami, ale ponadto muszą być w odpowiedni sposób sformatowane" - moim zdaniem jeśli używa się specjalnych komend, | ||
| + | to właśnie oczekuje się odpowiednio sformatowanych danych (przykłady: status, PERCOM). | ||
| + | "Handler jak najbardziej może mieć nazwę" - gdzie ta nazwa jest przechowywana? | ||
| + | "ma też skończoną długość i stanowi dla systemu operacyjnego całość" - zgoda. | ||
| + | --[[Użytkownik:0xF|0xF]] 23:48, 23 wrz 2005 (CEST) | ||
| + | |||
| + | :Nie, status i PERCOM to nie jest to. Tutaj protokół SIO po prostu narzuca pewną wielkość bloku danych i tyle, podobnie jak w przypadku sektora. Natomiast taki np. DOS.SYS, oprócz "struktury" polegającej na tym, że jest podzielony na bloki, których wielkość jest narzucona przez ogólny protokół transmisji danych, ma też wewnętrzną strukturę od tego - czy jakiegokolwiek innego - protokołu niezależną. Mianowicie ma nagłówek sześciobajtowy i całą resztę. Podobnie jest z ładowanymi do RAM-u handlerami nowych urządzeń, mają nagłówki i całą resztę, czyli strukturę niezależną od tego, na jakie porcje podzieli je protokół transmisji (czy jakikolwiek inny). Dlatego jeśli ze względu na strukturę wewnętrzną DOS.SYS jest plikiem, to i to jest. | ||
| + | |||
| + | :Kwestię "nazwy" już omawialiśmy: por. DOS.SYS, który ma nazwę, ale przecież nie musi. Czy nazwa w directory decyduje o tym, że dany blok danych jest plikiem, a jak jej nie ma, to nie jest? Źrodło, na które się powołujesz (pl.wiki) wcale tak nie twierdzi. Przeciwnie, nazwa jest tam tylko jednym z atrybutów, tak samo jak długość oraz np. uid i gid, których na Atari żaden plik nie ma, choćby był najczystszej rasy. :P [[Użytkownik:KMK|KMK]] 00:27, 24 wrz 2005 (CEST) | ||
| + | |||
| + | Jeśli dobrze pamiętam, to DOS.SYS nie ma żadnych nagłówków, tylko jest kolejno wczytywany | ||
| + | "jak leci", przynajmniej w DOSach 2.x. Co jest plikiem zdecydowanie nie zależy od struktury | ||
| + | wewnętrznej (zawartości). Jeśli DOS.SYS nie ma nazwy, to skąd wiesz, że to DOS.SYS? :-) | ||
| + | DOS.SYS bez wpisu w katalogu jest raczej w niewiele większym stopniu plikiem, niż skasowany | ||
| + | plik (który może jeszcze mieć wpis w katalogu), przychylałbym się do tego, | ||
| + | że nie jest w ogóle plikiem (nigdy nie twierdziłem, że jest!). | ||
| + | pl.wiki stwierdza, że '''musi''' być nazwa, ale nie precyzuje gdzie. | ||
| + | Jednak "nazwa pliku" jest chyba zrozumiałe i nikt nie sądzi chyba, że chodzi np. | ||
| + | o napis w pierwszej linijce pliku tekstowego. Inne atrybuty wymieniane w pl.wiki są opcjonalne. | ||
| + | |||
| + | Boot sector(y) też mają strukturę (nagłówek) - sądzisz, że to pliki?! | ||
| + | --[[Użytkownik:0xF|0xF]] 00:48, 24 wrz 2005 (CEST) | ||
| + | |||
| + | :Zacytujmy wikulca: "Plik (ang. file), jest to nazwany ciąg danych (...), o skończonej długości, posiadający szereg atrybutów i stanowiący dla systemu operacyjnego całość. Atrybuty plików. Atrybutami mogą być: 1) rozmiar 2) nazwa 3) cośtam". Nigdzie tu nie jest napisane, że nazwa jest nieodzownym atrybutem pliku. Przeciwnie, jasno jest napisane, że jest tylko jednym z wielu opcjonalnych atrybutów ("Atrybutami '''mogą''' być: ... 2) nazwa" - nazwa może być atrybutem pliku, ale nie musi). | ||
| + | |||
| + | :Po drugie, przychylając się nawet do twojej definicji, że plik musi mieć nazwę, konieczne byłoby przyjęcie, że w Atari nie da się zapisać pliku na taśmie - bo dane zgromadzone na taśmie w ogóle nie mają przy sobie zapisanej nazwy, że o innych atrybutach nie wspomnę. | ||
| + | |||
| + | :Po trzecie, bootblok w Atari jest częścią DOS-u (przynajmniej DOS-u 2.x). Razem z nim rezyduje w pamięci, razem jest wczytywany, i bez bootbloku DOS.SYS - jakkolwiek się nazywa i czy w ogóle się nazywa - jest bezużyteczny. [[Użytkownik:KMK|KMK]] 01:19, 24 wrz 2005 (CEST) | ||
| + | |||
| + | "jest to '''nazwany''' ciąg danych" - a więc posiada nazwę. | ||
| + | Ale z plikami na taśmie to mnie zagiąłeś. :-/ | ||
| + | "bootblok w Atari jest częścią DOS-u..." - co to wnosi do dyskusji? | ||
| + | --[[Użytkownik:0xF|0xF]] 11:11, 26 wrz 2005 (CEST) | ||
| + | |||
| + | :To, że bootblok nie jest tu żadnym wyjątkiem, a wydawało mi się, że to sugerujesz. [[Użytkownik:KMK|KMK]] 16:46, 29 wrz 2005 (CEST) | ||
| + | |||
| + | :0xf: bootblock to tez "nazwany ciag danych", ale nie posiada nazwy w kontekscie tu rozpatrywanym - w katalogu... | ||
| + | |||
| + | Co do reszty - niech ktos opisze rzeczone [[Handlery systemowe]]. Choc moga one miec usankcjonowana strukture, to nadal sa czescia systemu (ktory mozemy zachowac w pliku/romie), ale plikiem nie sa... Chyba domyslam sie o co chodzilo Foxowi - chociaz handlery moga byc przechowywane jako pliki (w potocznym rozumowaniu tego slowa) to jednak takowymi nie sa. Handlery maja swoj format/strukture/łoteva, ale nadal nie czyni ich to plikami, tak jak wspomniane atrybuty (fotmat/struktura/łoteva) nie czynia plikiem, bootblocka, PRECOMPA, czy czegotam... Pod definicje z wiki podpada rowniez np. interpeter BASIC-a z atari - jest to nazwany ciąg danych (przyp.: Atari BASIC) (inaczej zbiór danych), o skończonej długości, posiadający szereg atrybutów i stanowiący dla systemu operacyjnego całość. Chyba jednak nikt nie bedzie mowil o formacie pliku interpretera Atari Basic, mimo iz ten interpreter moze byc przechowywany na blaszaku w postaci pliku... Chodzi raczej o forme. | ||
| + | |||
| + | Podobnie podobalo mi sie "przemianowanie" "plikow binarnych" pod nazwe "COM". Choc pliki .com rzezcywiscie uzywaja tego formatu, to jednak nie sa to jedyne pliki na male atari z niego kozystajace... Jest to standardowy sposob z plikow pod atarowskim DOSem, ale nie sluzy tylko do przechowywania plikow .com. Zzut pamieci w Atari Dos ma dokladnie ten sam format. Nie wazne co tam zzucamy - czy to bedzie nuta ([[CMC_(format_pliku)]]), obrazek, czy cos innego... W opisie formatu CMC stosowana jest nazwa '''nagłówek DOSa''', tak wiec mamy niejednoznacznosc w tej sprawie. Trzeba by to jakos naprostowac - pytanie jak. Proponowalbym rozpoczac na ten temat dyskusje (tymczasowo w dyskusji [[COM]]a). --[[Użytkownik:Jellonek|Jellonek]] 16:29, 5 sty 2006 (CET) | ||
| + | |||
| + | -- | ||
| + | |||
| + | brakuje sporo formatów, przykłady: .OBJ, .BAS, .TBA, .BXE, .BXL, .ARC, .CHR itd. --[[Użytkownik:Xxl|Xxl]] 12:03, 20 sty 2007 (CET) | ||
| + | |||
| + | ARC jest na liście. OBJ czym się różni od COM? A co do reszty - to chyba nikt ci nie zabrania ich opisać? :> [[Użytkownik:KMK|KMK]] 14:52, 20 sty 2007 (CET) | ||
| + | |||
| + | może trzeba dodac aliasy (OBJ, BIN, EXE)? --[[Użytkownik:Xxl|Xxl]] 12:45, 21 sty 2007 (CET) | ||
Aktualna wersja
"Przywrócono przedostatnią wersję, jej autor to Miker"
Dlaczego?? Jest taki format "ATP", a "handlery systemowe" to żadne pliki! --0xF 13 wrz 2005 11:24
Tez mialem watpliwosci - chodzi tutaj o format handlera np interfejsu 850 ktory jest plikiem binarnym downloadowanym z urzadzenia na komputer --Mikey 12:14, 13 wrz 2005 (CEST)
- Nie handlera 850, ten ma "custom format", zależny od urządzenia. Chodzi o format handlerów "TYPE 3 POLL", zależny od relokatora, który jest w ROM-ie XL/XE. Tak więc, Foxie, mógłbyś na przyszłość pytać (-> Dyskusja), nim coś zbroisz. A ATP cofnęło się przypadkiem przy okazji. KMK 14:42, 13 wrz 2005 (CEST)
Ok, "handlery systemowe" jest zbyt mylące, przydałoby się sprecyzować. Sądziłem, że chodzi o handlery CIO. --0xF 14 wrz 2005 13:36
- Owszem, CIO również. KMK 14:18, 14 wrz 2005 (CEST)
a może po prostu "pliki sterowników ..."? :) --miker/bjb/ng 20:34, 14 wrz 2005 (CEST)
- Czemu nie, o ile to cokolwiek zmienia :) KMK 20:40, 14 wrz 2005 (CEST)
Gdyby ktoś je opisał, to może wreszcie bym wiedział, co to jest. :) Czy aby na pewno są to pliki, czyli coś, co można zapisać na dysku (i ma to jakiś sens)? Bo np. bloki PERCOM nie są plikami, chociaż mają swój format. --0xF 10:33, 15 wrz 2005 (CEST)
- Ale blok PERCOM ma jednolitą strukturę, jest to po prostu ciąg 12 bajtów, natomiast te nieszczęsne handlery są podzielone wewnętrznie na bloki z nagłówkami, które sterują pracą relokatora czy też loadera (siedzącego w ROM-ie). Jest to jakiś format binarny i zamierzam go opisać, ale na razie tego jeszcze nie zrobiłem. KMK 15:02, 15 wrz 2005 (CEST)
"podzielone wewnętrznie na bloki z nagłówkami" ? To w końcu są to pliki zapisywane na dysku, czy nie? --0xF 16:32, 15 wrz 2005 (CEST)
- Co ma jedno do drugiego, bo nie bardzo rozumiem? KMK 16:47, 15 wrz 2005 (CEST)
Nie rozumiem tego "podzielone wewnętrznie..." i nie odpowiedziałeś na moje pytanie wyżej, czy to są pliki.
- Nie bardzo rozumiem, co jest niejasnego albo niemożliwego w sformułowaniu "podzielone wewnętrznie". A co do pytania, to chyba jednak odpowiedziałem (w zasadzie, to nawet przed zadaniem pytania). No i też nie bardzo rozumiem - już jakoś tak mam, że nic nie rozumiem - co ma pojęcie pliku wspólnego z tym, czy jest umieszczony na dysku. KMK 18:24, 19 wrz 2005 (CEST)
Jeśli chodzi o sterowniki nowych urządzeń, ściągane przez OS XL/XE specjalnymi komendami SIO, to powinny być w Protokoły / SIO / Handlery systemowe, czy jak to się tam nazywa. Zgodzisz się chyba, że np. TCP/IP nie jest formatem pliku. --0xF 15:06, 19 wrz 2005 (CEST)
- Oczywiście, że nie, TCP/IP jest protokołem przesyłu danych, podobnie - mutatis mutandis - jak np. SIO. Ale też jakby nie o ten poziom organizacji danych tu idzie. Przy użyciu protokołu SIO można przesłać plik binarny, a jednak prawdopodobnie nie byłbyś skłonny plików uruchamialnych DOS-u umieszczać w dziale "protokoły", zgodzimy się tu chyba. KMK 18:24, 19 wrz 2005 (CEST)
Oczywiście plik wykonywalny nie jest protokołem, ale to dlatego, że jest osobnym bytem, który można zapisać w dowolnej pamięci masowej i przesłać dowolnym protokołem (w tym TCP/IP) i ma to sens. Co innego PERCOM czy (jak podejrzewam) te "handlery": nie mają racji bytu bez SIO. Nie wiem, jak są zorganizowane te "handlery": może są osobnym protokołem "stojącym na" protokole SIO, tak jak TCP "stoi na" IP. --0xF 13:18, 20 wrz 2005 (CEST)
No więc właśnie jakby nigdzie nie jest napisane, że taki handler nie jest "osobnym bytem". Można sobie wyobrazić, że w urządzeniu typu pamięci masowej handler będzie właśnie zapisany na nośniku jako plik, nie ma tu żadnych przeciwwskazań. Z drugiej strony idąc tokiem twojego rozumowania, że plik to jest zbiór danych będący "osobnym bytem, który mozna zapisać na dowolnej pamięci masowej i przesłać dowolnym protokołem i ma to sens", łatwo dojść do wniosku, że plikiem nie jest DOS.SYS (albowiem co prawda można go przesłać dowolnym protokołem, ale już zapisywanie go na pamięci masowej innej niż dyskowa - np. na taśmie - ma sens dyskusyjny).
Nie bardzo więc widzę, jak DOS.SYS, który jest ładowany przez system z urządzenia komendami SIO i jest programem binarnym zawierającym sterownik można uznać za plik, natomiast dokładnie taki sam handler binarny również ładowany z urządzenia komendami SIO za plik uznany być nie może. DOS.SYS niby ma wpis w katalogu - ale przecież nie musi go mieć, prawda? A z drugiej strony, jak wyżej napisałem, nigdzie nie jest powiedziane, że dyskutowany tu handler wpisu katalogowego mieć nie może.
Po drugie PERCOM i wszystko inne ma bardzo dobrą rację bytu bez SIO i jego protokołu transmisji. Nie przypuszczasz chyba, że protokołem SIO komputer się posługuje do komunikacji z twardym dyskiem. Chyba, że SIO rozwijamy jako "Sector Input/Output", wtedy owszem, PERCOM (et consortes) nie ma racji bytu bez SIO. KMK 15:21, 20 wrz 2005 (CEST)
Trafny przykład z tym DOS.SYS. Cofam "dowolnej" przy "pamięci masowej". :-) Wciąż jednak jest to pamięć masowa (stąd plik). Odsyłam [tu]. Jaką nazwę mają te Twoje handlery, hę?
Jeśli chodzi o transmisję DOS.SYS vs handlery przez SIO, to DOS.SYS jest przesyłany jak każdy inny plik, natomiast dla handlerów, o ile wiem, są specjalne komendy.
Cofam też, że PERCOM jest fragmentem SIO. Natomiast komunikacja z twardym dyskiem jak najbardziej może być przez SIO (SIO2IDE). Poza tym "Serial" w SIO może być tylko nazwą - np. stacja Karin Maxi (jako nowe urządzenie) przechwytuje komendy SIO i nie ma tam transmisji szeregowej. --0xF 13:09, 21 wrz 2005 (CEST)
No toż właśnie mówię - przy urządzeniach takich jak Karin albo większość twardych dysków (ok. oprócz SIO2IDE, ale to jest raczej emulator stacji dysków) nie ma transmisji szeregowej i nie ma zastosowania protokół komunikacji z urządzeniami szeregowymi. W SIO "serial" może być nazwą właśnie, i wtedy nie ma protokołu szeregowego. Ale dla normalnej stacji dysków ten protokół ma zastosowanie, przecież.
Natomiast przekonałeś mnie co do tych komend specjalnych - i niech będzie, że to protokół, ale nadal niezbyt mi się podoba fakt, że dane nie tylko są przesyłane specjalnymi komendami, ale ponadto muszą być w odpowiedni sposób sformatowane, bo inaczej nic się nie załaduje. Natomiast definicja pliku z pl.wiki jak najbardziej tu może mieć zastosowanie, już o tym była mowa: "jest to nazwany ciąg danych (inaczej zbiór danych), o skończonej długości, posiadający szereg atrybutów i stanowiący dla systemu operacyjnego całość". Handler jak najbardziej może mieć nazwę, ma też skończoną długość i stanowi dla systemu operacyjnego całość :-) KMK 14:31, 21 wrz 2005 (CEST)
"niezbyt mi się podoba fakt, że dane nie tylko są przesyłane specjalnymi komendami, ale ponadto muszą być w odpowiedni sposób sformatowane" - moim zdaniem jeśli używa się specjalnych komend, to właśnie oczekuje się odpowiednio sformatowanych danych (przykłady: status, PERCOM). "Handler jak najbardziej może mieć nazwę" - gdzie ta nazwa jest przechowywana? "ma też skończoną długość i stanowi dla systemu operacyjnego całość" - zgoda. --0xF 23:48, 23 wrz 2005 (CEST)
- Nie, status i PERCOM to nie jest to. Tutaj protokół SIO po prostu narzuca pewną wielkość bloku danych i tyle, podobnie jak w przypadku sektora. Natomiast taki np. DOS.SYS, oprócz "struktury" polegającej na tym, że jest podzielony na bloki, których wielkość jest narzucona przez ogólny protokół transmisji danych, ma też wewnętrzną strukturę od tego - czy jakiegokolwiek innego - protokołu niezależną. Mianowicie ma nagłówek sześciobajtowy i całą resztę. Podobnie jest z ładowanymi do RAM-u handlerami nowych urządzeń, mają nagłówki i całą resztę, czyli strukturę niezależną od tego, na jakie porcje podzieli je protokół transmisji (czy jakikolwiek inny). Dlatego jeśli ze względu na strukturę wewnętrzną DOS.SYS jest plikiem, to i to jest.
- Kwestię "nazwy" już omawialiśmy: por. DOS.SYS, który ma nazwę, ale przecież nie musi. Czy nazwa w directory decyduje o tym, że dany blok danych jest plikiem, a jak jej nie ma, to nie jest? Źrodło, na które się powołujesz (pl.wiki) wcale tak nie twierdzi. Przeciwnie, nazwa jest tam tylko jednym z atrybutów, tak samo jak długość oraz np. uid i gid, których na Atari żaden plik nie ma, choćby był najczystszej rasy. :P KMK 00:27, 24 wrz 2005 (CEST)
Jeśli dobrze pamiętam, to DOS.SYS nie ma żadnych nagłówków, tylko jest kolejno wczytywany "jak leci", przynajmniej w DOSach 2.x. Co jest plikiem zdecydowanie nie zależy od struktury wewnętrznej (zawartości). Jeśli DOS.SYS nie ma nazwy, to skąd wiesz, że to DOS.SYS? :-) DOS.SYS bez wpisu w katalogu jest raczej w niewiele większym stopniu plikiem, niż skasowany plik (który może jeszcze mieć wpis w katalogu), przychylałbym się do tego, że nie jest w ogóle plikiem (nigdy nie twierdziłem, że jest!). pl.wiki stwierdza, że musi być nazwa, ale nie precyzuje gdzie. Jednak "nazwa pliku" jest chyba zrozumiałe i nikt nie sądzi chyba, że chodzi np. o napis w pierwszej linijce pliku tekstowego. Inne atrybuty wymieniane w pl.wiki są opcjonalne.
Boot sector(y) też mają strukturę (nagłówek) - sądzisz, że to pliki?! --0xF 00:48, 24 wrz 2005 (CEST)
- Zacytujmy wikulca: "Plik (ang. file), jest to nazwany ciąg danych (...), o skończonej długości, posiadający szereg atrybutów i stanowiący dla systemu operacyjnego całość. Atrybuty plików. Atrybutami mogą być: 1) rozmiar 2) nazwa 3) cośtam". Nigdzie tu nie jest napisane, że nazwa jest nieodzownym atrybutem pliku. Przeciwnie, jasno jest napisane, że jest tylko jednym z wielu opcjonalnych atrybutów ("Atrybutami mogą być: ... 2) nazwa" - nazwa może być atrybutem pliku, ale nie musi).
- Po drugie, przychylając się nawet do twojej definicji, że plik musi mieć nazwę, konieczne byłoby przyjęcie, że w Atari nie da się zapisać pliku na taśmie - bo dane zgromadzone na taśmie w ogóle nie mają przy sobie zapisanej nazwy, że o innych atrybutach nie wspomnę.
- Po trzecie, bootblok w Atari jest częścią DOS-u (przynajmniej DOS-u 2.x). Razem z nim rezyduje w pamięci, razem jest wczytywany, i bez bootbloku DOS.SYS - jakkolwiek się nazywa i czy w ogóle się nazywa - jest bezużyteczny. KMK 01:19, 24 wrz 2005 (CEST)
"jest to nazwany ciąg danych" - a więc posiada nazwę. Ale z plikami na taśmie to mnie zagiąłeś. :-/ "bootblok w Atari jest częścią DOS-u..." - co to wnosi do dyskusji? --0xF 11:11, 26 wrz 2005 (CEST)
- To, że bootblok nie jest tu żadnym wyjątkiem, a wydawało mi się, że to sugerujesz. KMK 16:46, 29 wrz 2005 (CEST)
- 0xf: bootblock to tez "nazwany ciag danych", ale nie posiada nazwy w kontekscie tu rozpatrywanym - w katalogu...
Co do reszty - niech ktos opisze rzeczone Handlery systemowe. Choc moga one miec usankcjonowana strukture, to nadal sa czescia systemu (ktory mozemy zachowac w pliku/romie), ale plikiem nie sa... Chyba domyslam sie o co chodzilo Foxowi - chociaz handlery moga byc przechowywane jako pliki (w potocznym rozumowaniu tego slowa) to jednak takowymi nie sa. Handlery maja swoj format/strukture/łoteva, ale nadal nie czyni ich to plikami, tak jak wspomniane atrybuty (fotmat/struktura/łoteva) nie czynia plikiem, bootblocka, PRECOMPA, czy czegotam... Pod definicje z wiki podpada rowniez np. interpeter BASIC-a z atari - jest to nazwany ciąg danych (przyp.: Atari BASIC) (inaczej zbiór danych), o skończonej długości, posiadający szereg atrybutów i stanowiący dla systemu operacyjnego całość. Chyba jednak nikt nie bedzie mowil o formacie pliku interpretera Atari Basic, mimo iz ten interpreter moze byc przechowywany na blaszaku w postaci pliku... Chodzi raczej o forme.
Podobnie podobalo mi sie "przemianowanie" "plikow binarnych" pod nazwe "COM". Choc pliki .com rzezcywiscie uzywaja tego formatu, to jednak nie sa to jedyne pliki na male atari z niego kozystajace... Jest to standardowy sposob z plikow pod atarowskim DOSem, ale nie sluzy tylko do przechowywania plikow .com. Zzut pamieci w Atari Dos ma dokladnie ten sam format. Nie wazne co tam zzucamy - czy to bedzie nuta (CMC_(format_pliku)), obrazek, czy cos innego... W opisie formatu CMC stosowana jest nazwa nagłówek DOSa, tak wiec mamy niejednoznacznosc w tej sprawie. Trzeba by to jakos naprostowac - pytanie jak. Proponowalbym rozpoczac na ten temat dyskusje (tymczasowo w dyskusji COMa). --Jellonek 16:29, 5 sty 2006 (CET)
--
brakuje sporo formatów, przykłady: .OBJ, .BAS, .TBA, .BXE, .BXL, .ARC, .CHR itd. --Xxl 12:03, 20 sty 2007 (CET)
ARC jest na liście. OBJ czym się różni od COM? A co do reszty - to chyba nikt ci nie zabrania ich opisać? :> KMK 14:52, 20 sty 2007 (CET)
może trzeba dodac aliasy (OBJ, BIN, EXE)? --Xxl 12:45, 21 sty 2007 (CET)
