Dyskusja:Formaty plików
From Atariki
| Wersja z dnia 12:32, 21 wrz 2005 KMK (Dyskusja | wkład) ← Previous diff |
Wersja z dnia 21:49, 23 wrz 2005 0xF (Dyskusja | wkład) Next diff → |
||
| Linia 72: | Linia 72: | ||
| 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ść :-) [[Wikipedysta:KMK|KMK]] 14:31, 21 wrz 2005 (CEST) | 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ść :-) [[Wikipedysta: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. | ||
| + | --[[Wikipedysta:0xF|0xF]] 23:48, 23 wrz 2005 (CEST) | ||
Wersja z dnia 21:49, 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)
