Dyskusja:Formaty plików
From Atariki
| Wersja z dnia 21:49, 23 wrz 2005 0xF (Dyskusja | wkład) ← Previous diff |
Wersja z dnia 22:27, 23 wrz 2005 KMK (Dyskusja | wkład) Next diff → |
||
| Linia 78: | Linia 78: | ||
| "ma też skończoną długość i stanowi dla systemu operacyjnego całość" - zgoda. | "ma też skończoną długość i stanowi dla systemu operacyjnego całość" - zgoda. | ||
| --[[Wikipedysta:0xF|0xF]] 23:48, 23 wrz 2005 (CEST) | --[[Wikipedysta: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 tylew, 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 ładowanbymi 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 [[Wikipedysta:KMK|KMK]] 00:27, 24 wrz 2005 (CEST) | ||
Wersja z dnia 22:27, 23 wrz 2005
"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 tylew, 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 ładowanbymi 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)
