Vlákno názorů k článku Podpora unifikované práce se zařízeními v operačním systému Atari: CIO od MilanV - Na CIO jsem se těšil. Dodnes si pamatuju...

Na CIO jsem se těšil. Dodnes si pamatuju na ten šok, když jsem přišel na MS-DOS a dostal jsem odpověď na svou otázku: "Kde je tady centrální správa zařízení?" :D

Jen přidám pár bodů: jak Pavel rád píše všechny příklady kompletní, tak tady trošku zaniklo, že ty první tři příklady v BASICu jsou úplně stejné a liší se jen tím názvem zařízení, což je jednoduše řetězec, který může být i v proměnné a klidně tentýž kód můžeme zavolat několikrát pro různé řetězce a kopii dat tak poslat na obrazovku, tiskárnu i kazetu...

A dokonce, jak vidíme, v asembleru je to vlastně totéž, jen chybějící syntax pro zápis více proměnných nahradíme vyplněným IOCB blokem. Ony totiž ty příkazy v BASICu jsou jen velmi primitivní wrapper nad CIO systémem - a stačí to, protože je ten CIO systém už tak high-level.

(Malá poznámka: podobně mě fascinovalo na ZX Spectru, když jsem objevil v operačním systému tak high-level kalkulačku s plovoucí čárkou.)

Těším se, že v příštím díle zavedeme vlastní zařízení do tabulky HATABS !

díky!

(popravdě ještě nemám ani čárku o HATABS, ale času dost :-)

Já bych ten MS-DOS tolik nepodceňoval. První verze byla sotva něco víc než port CP/M na 8086.

Ale už od verze 2.0 měl MS-DOS standardizovanou a celkem robustní podporu znakových zařízení (CON, PRN, AUX, cokoliv dalšího) a dalo se k nim přistupovat pomocí služeb souborového systému. Existoval centrální spojový seznam ovladačů těchto zařízení (něco jako HATABS). Stejně tak měl MS-DOS od verze 2.0 standardizovanou podporu blokových zařízení.

akorát když někdo vytvořil adresář nebo soubor se stejným jménem, jako zařízení (nebo jako vnitřní příkaz COMMAND.COM), tak si zadělal na docela velké problémy - a musel nastoupit disk editor. DOSBox to ovšem neumí emulovat (a nebo to v MS opravili později).

Jednou v zahranici behem COVIDu jsem jel do copycentra tisknout nejake dokumenty. Doma jsem si je pohodlne spojil pres pdftk do souboru, ktery jsem dle sveho celkem logicky pojmenoval prn.pdf.

V samoobsluznem copycentry Widle hroznej problem. Soubor ma 0 bajtu a podobne, pritom ve vypisu videt byl a nejake bajty mel. Chvili mi to nedochazelo, nez mi docvaklo, ze je to vzdalene podobne PRN:.

Takze ani v soudobych Widlich neni mozne mit soubor s nazvem treba aux.neco nebo nul.neco. To je opravdu zoufalost. Pominu to, ze nejakej blbec vymyslel, ze ta dvojtecka bude nepovinna. Ale proc to jeste jinej idiot vylepsil tim, ze se ignoruje i to .pdf na konci? Pominu, ze naprosta vetsina techto zarizeni, nejspis vsechny, ani neni implementovana a jen to odmitaji funkce na otevreni souboru.

Nakonec jsem hledal zoufale na netu, jak z toho ven, resenim bylo v PowerShellu zadat naprosto silenej escaping o snad peti znacich pred tim prn* a pak to slo prejmenovat.

já bych v tom žádnou logiku nehledal, protože tam žádná není :-) já si tak naběhl s adresářem CDROM, který fungoval v DOSu (když jsem nabootoval bez podpory CD-ROM), ale Windows to odmítaly (a nastoupil diskeditor).

prostě prakticky od začátku DOSu jen slepě kopírovali zpočátku CP/M a později Unix, aniž by pochopili, proč to v Unixu funguje, jak funguje. Tudíž to "vylepšili" jmény zařízení, potom náhradou - (přepínače) za /. A když došlo na lámání chleba a i v DOSu se objevily adresáře, tak už bylo / obsazeno, takže se nabastlil \ (o koncích řádku nemluvě).

Jo jo, občas je nejjednodušší nabootovat jiný systém z USB klíčenky, např. SystemRescue Linux, a opravit ten disk z něj - tam nemá žádný speciální význam a můžou se prostě "opravit data". A pak jen boot zpátky do původních Windows a voila! Ani šroubovák není potřeba...

Ale souhlasím s hodnocením jak nepovinné dvojtečky, tak ignorování přípon. Navíc nechápu, proč nepomůže úplně obyčejné zadání nějaké delší cesty. To ta wokna neumějí soubor přejmenovat ani např. příkazem 'move C:\adresar\prn.pdf C:\adresar\ne­prn.pdf' ??

Je možné, že si to po letech už nepamatuju, ale nemám pocit, že bych viděl někoho, jak udělá ovladač třeba na svou nestandardní tiskárnu, původní PRN přejmenuje standardním a definovaným způsobem na něco jiného, svůj ovladač zaregistruje jako PRN, také standardním způsobem, a odteď mohl nahrát jakýkoli program a poslat v něm výstup na svou tiskárnu aniž by ten program zpozoroval změnu.

Myslím, že tam byl nějaký neustálý souboj residentů (občas na ostří nože, nekradli si IRQ?) a do toho nekompatibilní způsoby správy paměti definované v SYS, takže měnitelné pouze bootem. A různé programy potřebovaly buď ten nebo onen.

A pak už si pamatuju jenom, že u vedlejšího stolu byli nějací starší kluci, kteří měli zařízení seřazená v /dev ...a tak jsem tady :)

Ano, realita byla poněkud jiná a tak trochu stejná jako u Atari. Programy náročné na výkon zobrazovacího systému (třeba i tabulkové kalkulátory jako Lotus 1-2-3) určitě nebyly psané pro zařízení CON v MS-DOSu, ale přistupovaly k obrazové paměti přímo. Stejně tak hry pro Atari většinou nepoužívaly zařízení S: pro vykreslování.

Zato zařízení P: pro tisk bylo na Atari v kurzu, protože pohodlně poskytlo vhodnou vrstvu abstrakce. V MS-DOSu si to každý pokročilejší textový editor a slovní procesor řešil sám (hromadou ovladačů nebo definičních souborů pro všemožné tiskárny, hoši ze Software602 by mohli vyprávět o DST souborech).

I na Linuxu je to asi všelijaké. Třeba zvuk se pořád dá posílat na /dev/dsp (pokud se neztratíte v hromadě IOCTL na nastavení vzorkovací frekvence atd.), ale myslím, že použití všemožných API dnes převažuje. Zvuk je ale jenom střípek.

Zajímalo by mne, jak něco jako CIO fungovalo na minipočítači, kterým se konstruktéři 8bitové řady inspirovali.

Jo, to sedí na moje vzpomínky - tj. správa zařízení s možností registrace pod jménem, přejmenovat ty "systémové" apod. v MS-DOS prostě nebyla. Ba naopak, dodnes jsou PRN a podobné jen nabastlené výjimky dělající potíže i ve Windows - jak tu vzpomínají další. Přesný opak CIO.

Na Linuxu mi vždycky zase přišlo divné, proč všechna zařízení jsou v /dev kromě síťových...