Dyskusja:Formaty plików

From Atariki

"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)