Názory k článku
Historie vývoje GUI (10): počítače IBM PC a aplikace využívající textový režim

Chvíli jsem pracoval se správcem souborů ArcShell.

Asi největším lákadlem tohoto shellu bylo několik her a pár zajímavých utilit, které jako samostatné binárky šly používat i bez ArcShellu. Jinak mě moc nezaujal, takže jsem zůstal u VC.

Kdyby byl zájem, jeho manuál bych ještě někde vyhrábnul. Tady jsem našel jeho fotku: http://www.mimibazar.cz/bazar.php?id=7707417

ArcShell jsem používal v letech 1992 - 93. Umožňoval dělení souborů a existovala i unixová verze. Později se prodával cca. za 75 Kčs včetně manuálu viz. odkaz v minulém příspěvku. Autor pracoval jaku programátor na UNIXových programech a ArcShell pro DOS byl asi jen vedlejší produkt jeho práce, takže ve vývoji nepokračoval.

75kč nebo 75sk? :)

V roce 1992 asi Kčs, ne?

Dakujem autorovi za naozaj prijemny a obsazny clanok.

Také děkuji za perfektní článek.

Mimochodem, mám ten pocit, že Dos Navigátor měl mimo jmenovaných utilitek i jednoduchý ale efektní spořič obrazovky :)

V dobách W95 - 98 jsem si vytvořil něco jako rescue CD, který pomocí dávkového souboru startoval defaultně NC, a hned se s tou hromadou šrotu dalo lépe pracovat, když se něco po... :-)

Jinak pro DOS byl ještě Commander Keen, ale to už je asi trochu jiná kategorie :-D

screensavery plazma a plameny, se mi střídaly a tenkrát jsem si dn spouštěl v shellu FastTrackera 2 kde mi běžely s3m-ka, super při serial party, když jsme zrovna pařili něco na jednom kompu a na druhém z pc-skřípru chrastila elektronika :-D na kopírování souborů jsme používali tuším laplink2, který dokázal posílat komprimovaně, kolikrát se přenos nezdařil a soubory se posílaly celé znova... to byly časy, rád jsem si u článku zavzpomínal...

Je třeba dodat, že správci souborů se snažily překonat omezení DOSu Například Dos Navigator uměl některé úlohy prokládat, takže bylo možné současně formátovat disketu, kopírovat soubory a hrát tetris. Dos Navigator se na sklonku éry MS-DOSu dokonce dočkal otevření svých zdrojových kódů, zřejmě proto, že jeho výrobce Rit Labs spatřoval budoucnost v konkurenčím programu pro Win32 – FAR.

Super článek, až na mě dýchla nostalgie. Já jsem začínal s NC 3.0, chvilku zkoušel M602 a nakonec skončil u naprosto fantastického Dos Navigatoru. Pochopitelně na žádné záchranné disketě nikdy nemohla chybět binárka Volkov Commanderu. Také vzpomínám, když se jako zjevení objevil RAR s rozhraním podobným file manažerům, to bylo žrádlo :-)

Mel jsem to uplne stejne - Dos Navigator pro beznou praci a VC na zachranne diskete spolu s orezanymi norton utilities (NDD), ARJckem atd.

FAR - jeden z najlepsich spravcov suborov pod Win. Akonahle sadam za komp, kde sa nachadza win, jedna z prvych veci, ktore stahujem je FAR Manager. Teraz je vo verzii 2.0, tiez znama ako Unicode FAR. Je pod neho kooopa pluginov (zvyraznovanie synatxu, praca s archivmy, FTP, SCP, ...). Podporuje aj editaciu viacerych suborov naraz, rozne vyhladavania, zobrazenia, skratka je dokonaly. Raz skusis a nevratis sa k inym.

Souhlas.

Nene, to platilo az u dalsich verzi NC, v prvni verzi bylo "vse" v jednom exe souboru:

07/06/1986 08:27 AM 1,627 CURSOR.TBL
06/18/1986 03:37 PM 28 DIRINFO
05/15/1986 01:00 PM 65,840 NC.EXE
05/15/1986 01:00 PM 149 NC.EXT
11/23/2007 10:36 PM 725 NC.MNU
05/15/1986 01:00 PM 11,468 NCSMALL.EXE
06/27/1985 05:23 PM 60 NPROMPT.BAT

NCSMALL.exe je pouze wrapper pro NC.EXE.

Prvni odstavec seste kapitoly je cely o NC 1.0:

"Zajímavé bylo, že celý NC byl naprogramován
v assembleru a délka spustitelného souboru nc.exe byla pouze 65840 bajtů

Treti odstavec je o NC 3.0 a dalsich verzich:

ale mnoho uživatelů tento manažer považovalo za bloatware, protože jen samotný manažer měl velikost
přesahující 200 kB.

Naschval jsem tam nepsal nic o ncmain.exe ci .ovl atd., protoze jen vysvetleni rozdilu mezi wrapperem a overlayem by si vyzadalo dalsi odstavec :-)

Prosím, zkuste alespoň tady: k čemu vlastně ty OVL soubory byly??

To byly tzv. overlays, čili překryvné soubory. V MS-DOSu bylo možné spouštět programy pouze v adresovém prostoru pod 1 MB (prakticky spíše 640 KB, i když se používala i část paměti těsně pod 1 MB, pak směrem dolů byl V/V prostor, ROM, videoRAM atp.), což činilo tento úsek paměti velice vzácným. Obcházelo se to tak, že se program rozdělil do dvou souborů, z nichž první (.EXE) byl "hlavní" částí, jež byla přítomna vždy v paměti pod 640 KB, a druhý (.OVL) obsahoval rutiny, jež se zaváděly do konvenčního adresového prostoru (pod 640 KB) jen pokud byla daná rutina potřebná. Když byla potřebná jiná, nahradil se inkriminovaný úsek odpovídající částí z OVL-souboru. V podstatě šlo o takové listování mezi stránkami. Daný úsek se zaváděl buď ad hoc z OVL-souboru, nebo se při spouštění programu celý OVL-soubor nahrál do rozšířené paměti (paměť nad 1 MB, pokud byla instalována - extended, resp. expanded memory, k níž se pod MS-DOSem dalo přistupovat prakticky jen tak, že se v prostoru pod 1 MB vytvořilo okno do této paměti, do nějž se namapoval požadovaný úsek rozšířené paměti) a pak se daná část nahrávala do konvenční paměti odsud.

Zajímavé. Děkuji moc za popis!!

(Už si to moc nevybavuji, tak daleko jsem se v programování pod DOSem nedostal. Skončil jsem u nějakých hrátek s přerušením.)

U FoxBase jsem používal fintu: Zavedl jsem ramdisk v XMS, do něj zkopíroval soubor *.OVL a ten pak tahal z Ramdisku. Rychlost se podstatně zvýšila. FoXPro už nahrával OVL soubory automaticky do XMS.
Mimochodem soubory *.DLL pod Win se chovají vlastně stejně jako *.OVL pod DOSem.

Diky za nostalgickou pripominku, leta jsem ho pouzival, to byly casy, turbo assembler (tlink, tasm) k tomu rezidentne spusteny sysman, athelp, Mira Nemecek, digger, asi stokrat spatrene demo SecondReality, CBcka, LSTM polnicka ... mno jo,je to pryc, svet se hodne zmenil, ale presto dekujem, dobre navyky a vychova lidi k smysluplne cinnosti nezustane zapomenuta.

Omlouvam se, trochu jsem nechal unest.

Zrovna Sysman je jeden z programu, u kterych se stydim za to, ze jsem je pouzival bez zaplaceni. Tenkrat to byl uzasnej zdroj informaci.

Tohle mě v článku docela zaujalo. Vím že kódování češtiny bylo docela dost, ale to je asi tak všechno. Chystá se o něm a jeho historii nějaký článek?

No já si na začátku oblíbil kameníky. Ty byli čitelní i tam, kde čeština nebyla nainstalována, protože byly zvoleny podobné znaky

Třeba Ç bylo Č, ⌐ bylo ř, ê bylo ě, ñ bylo ň, atd. Bohužel to pak Windowsy vzaly hákem a všude zavedli CP 852 a bylo vymalováno

CP852 bylo DOS kódování, ve Win zavedly Win-1250 (CP-1250)

CP 852 byl děs. Fakticky to znemožnilo používání právě "grafických" programů v textovém režimu, které používaly rámečkových pseudografických znaků. Tekže se na obrazovce místo rámečků objevovali řady :"čččččččččččč" a "ňňňňňňňň" a vrozích další nesmysly. V tom byly "Kameníci" mnohem lepší. Většinou se používaly všude až do nástupu Voken.

Presne tak.

CP 852 je typicka norma navrzena od zeleneho stolu kdesi za oceanem, tj. lidmi, kteri ji nemuseli pouzivat :-)

Naopak Kamenici vychazely z ceskych realii, kdy dostali sanci i uzivatele vlastnici puvodni Hercules se znaky v ROM (nikoli v RAM) a vlastnici jehlickovych tiskaren, kteri nemeli moznost si nechat prepalit EPROM nejakou jinou znakovou sadou.

Ale KOI8-CS bylo snad zdejšího původu, nebo ne? Proto nechápu, proč byla i tato norma udělána tak nešikovně. Neznám nikoho, kdo to používal.

KOI8-CS byl docela hojně používaný na osmibitech. Nezdá se mi nešikovný - znaky s diakritikou se mapovaly nastavením MSB u odpovídajících znkaů bez diakritiky, takže pokud se vypustil nejvyšší bit, dostali jste zase poměrně dobře čitelný text bez diakritiky. Pravda, byly tam i nějaké nepravidelnosti u písmen, které se vyskytují s různými diakritickými znaménky jako je ŮÚ ÉĚ apod. Ještě se asi měnila velikost písmen, moc si to nepamatuju a nechce se mi googlovat...

Nevím přesně jak moc byl kód KOI8-CS zdejšího původu přihlédneme-li ke zkratce KOI8 je Kod obměny informacii = kód pro výměnu dat, 8 = osmibitový.

Puvod KOI bych hledal trosku na vychod od nas, znamena to puvodne Код Обмена Информацией (mozna i z toho vyplyvala nechut k tomuto kodovani :-) Tato norma byla pouzivana na (mini)pocitacich vyrabenych v ramci RVHP, takze se dostala i na tiskarny s typovym koleckem atd. Taky byla standardizovana v CSN, cislo ted z hlavy nevim.

Problem s KOI8-CS ovsem spociva v tom, ze sice mnoho programu psalo, ze tuto normu podporuji, ale ve skutecnosti napriklad nedokazaly korektne pracovat se znaky 'Ch' a 'ch', coz komplikovalo vymenu textu (samozrejme - pokud se na nejake platforme vsude pouzivala ta sama nekorektni KOI8-CS, tak si toho uzivatele nevsimli :).

Druhy problem je v tom, ze chybely nektere dulezite znaky, napriklad $, ktery se nahrazoval univerzalnim symbolem meny ("ruskym dolarem").

To nevadilo na mikropocitacich (proste se preprogamovala znakova sada), ale na terminalech, tiskarnach s typovym koleckem a dalnopisech uz ano.

Druhy problem je v tom, ze chybely nektere dulezite znaky, napriklad $, ktery se nahrazoval univerzalnim symbolem meny ("ruskym dolarem").

To bylo takové to sluníčko (malé kolečko se čtyřmi "paprsky"), co bylo vždycky vidět ve výpisech?

Presne tak, my jsme tomu v Brne kdysi rikali rusky dolar, ale jinak je to obecny placeholder pro symbol meny.

O tom, proc dolar nebyl v oficialnim KOI8 jsem slysel ruzne vice ci mene humorne historky, ale tezko dneska rict, jak to bylo doopravdy.

Jeste bych nekde sehnal vypisy BASICovych zdrojaku na minipocitacove tiskarne, kde se to namisto A$ hemzilo A¤ :-)

My jsme tomu rikali 'kutalejici se rubl'.

Samotní Rusové tomu říkali "čort ragatyj". :-)

pekne to jsem nevedel ;-)

Opravdu?

Já na svém osmibitu používám ASCII, nebo ISO8859-2
http://cygnus.speccy.cz/popis_ufeditor.php

Používáno na Amigách ovšem taky jako jedno z mnoha. Mělo (pokud se nepletu, pokud ano, opravte) výhodu v tom, že nevyužívalo znak na pozici 160, kde Amiga měla nedělitelnou mezeru. Všechna ostatní kódování z PC měla na pozici 160 nějaký znak.

Ani ne tak návrh od zeleného stolu, jako snaha v jedné tabulce vyřešit celou východní Evropu. Kód bratří kamenických řešil pouze české znaky, kdežto Microsoft v CP 852 řešil i ostatní znakové sady východní Evropy (slovenské, maďarské a další národní znaky). Proto musel do druhé poloviny původní tabulky ASCII vměstnat o něco více znaků než bři Kameničtí.

V podstate suhlas, akurat "Kamenici" riesili ako ceske tak aj slovenske znaky (vtedy bolo este Ceskoslovensko ...:-)).

Pouzili na ne prave tie miesta v tabulke, ktore boli pre narodne znaky inych jazykov (napr. katalancina) a tym nechali zachovane pozicie pre semigraficke znaky, cize v Kamenikoch isli v pohode zobrazovat rozne ramiky, dvojite ramiky a pod., co v CP852 nebolo mozne. Kamenici dokonca mali aj oficialne oznacenie - CP895.

Svojho casu dokonca existoval jeden americky vyrobca RISC-ovych pocitacov (Data General), ktory v ramci svojho unixu (DG-UX) mal podporu tejto CP priamo zabudovanu. Akurat v menu sa to dalo nastavit ako "czechoslovak", v locales to bolo sk_SK a aj v skutocnosti to bolo len po slovensky (zeby nejaky zamestnanec - emigrant?) ...

Proč "byl"? CP852 se stále používá v konzoli i nejnovějších Windows.

Dobre, zkusim neco sepsat, i kdyz to nebude uplne jednoduche, protoze prave na PC se pouzivala nejak pojmenovana kodovani, ktera se ovsem nekdy dost podstatne lisila od skutecneho kodovani toho jmena (prikladem je KOI8-CS apod.).

Díky. Už podle diskuze nahoře vidím, že toho je docela dost. Takže se budu těšit na článek.

Myslim, ze si muzete vybrat jine tema. O kodovani cestiny existuje velmi slusny web www.cestina.cz

Trosku skoda ze tam nemaji i neco o historii vzniku tech kodovani, ale jinak to maji pekne udelane.

(btw me pobavil retro dotaznik :-)

S oblibou jsem používal DOSMAN od Ing. Miroslava Němečka. Napsané to bylo v assembleru, malé, rychlé, velmi konfigurovatelné, se spoustou zajímavých utilit. To byly časy :-)

Díky za opět super článek, přečetl jsem to jedním dechem a už se těším na další. Ty mladší to asi tolik neosloví, ale mně se vybavila fantastická doba, která se už nikdy nevrátí :(

I když to tak autor asi nemyslel, vyznívá to, jako by Commodore nebo Atari byly nějaké garážové firmy. Což samozřejmě nebyly. :-)

Hmm autor to tak nemyslel, jen to kostrbate napsal :-|

Z ceskych manageru jsou pomerne zapomenute dva vytecne projekty a to manager IT a Cybex Shell.

Jenže Cybex Shell bylo grafické rozhraní a přišlo relativně pozdě.

Tehdy se navíc používalo jen to, co měli kamarádi, kteří to byli ochotni zkopírovat.

Proč "škudlit na jednotlivých bajtech": Protože s UTF-8 a UTF-16 je práce podstatně pomalejší (kvůli tomu, že má každý znak jinou délku, nemluvě o tom, že je potřeba uvažovat o odlišných byte-orderech) a UTF-32 zase svým zečtyřnásobením délky většiny běžných souborů plýtvá kapacitou až příliš.

Práce s UTF8 nemusí být citelně pomalejší. Pro řadu úloh je rozdíl minimální, pro některé je nutné upravit některé algoritmy. UTF8 má jinak dost výhod, minimálně v tom, že ty nejdůležitější ASCI znaky jsou jedno bajtové a tudíž se ušetří čas v jiných operacích - např. při parsování textových souborů nemusíte řešit dvou a více bajtové znaky - většinou vás zajímají základní ASCII znaky a ty jsou jednobajtové, tudíž nedochází k žádnému výraznému zpomalení.

Pokud budeme řešit efektivitu jednotlivých kódování, tak se asi budeme bavit o hromadném zpracování dat - o databázích. Je otázkou jak to bude v budoucnu, nicméně aktuálně u db není procesor úzkým hrdlem. Problém je pomalé čtení dat z disku a málo paměti. Tudíž UTF8 je minimálně pro střední a západní Evropu nejvýhodnější. Latin2 by bylo výhodnější, ale to přeci jen nedostatečně pokrývá požadavky.

Myslím si že UTF-16 môže drvivá väčšina programov považovať za znaky s pevnou dĺžkov 2 bajty. Sám to tak robím :) Len nejaké špeciálne exotické znaky, ktoré som nikdy nevidel sú dlhšie.

Neměly by, otestování surrogate pair je poměrně jednoduché a rozbití kompatibility, pokud to neděláte, značné. Přesně kvůli takovým programátorům bylo tolik problémů s používáním horní paměti, s rokem 2000 a se zavedením UTF-8.

Mezi ty „speciální exotické znaky“ patří například noty (

Tak ještě jednou a bez ukázek, zdejší redakční systém si s nimi neporadí, zřejmě také předpokládá UTF-16 jako dvoubajtové kódování :)

Mezi ty „speciální exotické znaky“ patří například noty, smajlíci, mapové symboly, značky (tagy) nebo matematická písmena.

UTF-8 je kódování na výměnu dat. Má jenom jednu endianitu (velkou), má automatickou synchronizaci (takže nevadí, když skočíte doprostřed znaku) a je celkem úsporné na místo. Převod mezi UTF-8 a UTF-32 je triviální a velmi rychlý (ne tak mezi UTF-8 a UTF-16).

UTF-16 je nesmyslné kódování, které s námi bohužel ještě dlouho pobude kvůli Windows a ICU/Java (tentokrát za to ale nemůže MS ani IBM, ale Unicode Consortium, když v Unicode 1.0 prohlásilo, že 16 bitů bude stačit — historie se opakuje :).

UTF-32 je ideální kódování na práci s daty v paměti. Na ukládání do souborů se moc nehodí kvůli plýtváním a endianitě.

Ja som začínal s HH managerom (či manažérom?, čo bol (ďalší český!) klon mc. Mal zopár dobrých vlastností (napr. dosť dlho som nemohol prísť na chuť mc, lebo sa tam komplikovane prechádzalo medzi diskami – v HH stačilo CTRL A pre prvú disketu, CTRL B pre druhú, CTRL C pre harddisk atď), ale aj niektoré menej domyslené veci (horšia podpora príkazového riadku).

Dokonca som ten program mal ÚPLNE LEGÁLNE (kúpený spolu s počítačom), čo na tú dobu bolo naozaj veľmi nezvyklé.

a v duchu tohoto zpusobu gui je vyvijena stovka projektu diky knihovne ncurses. kterou miluju!

Pamatuju M602 a kopirovani souboru pres seriovy kabel. V jedne verzi vsechny soubory vetsi nez nevim kolik bajtu poskodil...

Mozna to byla integrovana ochrana proti pirateni :-)

Ještě mám doma ve sklepě kabel LPT-LPT, co jsem si sám udělal. Přes M602 kopírování , oproti sériovému kabelu, parádně svištělo. Hojně jsem ho používal.
M602 používal nějaký standartní typ propojení LAPLINK, ale už nevím co to bylo.

V M602 mi to kopirovani po kabelu prislo trochu krkolomne. NC to mel od jiste verze (5.0?) vychytanejsi: stacilo zvolit, kdo je master a kdo slave a po spojeni videl master v jednom panelu disky od slave.

A pak existoval jeste nejaky rezidentni programek, ktery umel disk slave mapovat rezidentne. Proste master mel jakoby najednou o par disku vic. A tenhle programek umel i pokrocilejsi verze LPT (lepsi nez to standardni zapojeni "Laplink", i kdyz zpusob zapojeni byl mozna stejnej, hlavni byl jiny rezim komunikace) a to pak byla rychlost.

Jo, už jsem si vzpoměl. Něco takového bylo přímo v DOSu od nějaké verze. Byla to dvojice programů interlink a interserver, nebo nějak zkráceně. Interlink byl rezident který připojil do DOSu vzdálené disky. Interserver měl takovou velkou statusovou obrazovku přes celej monitor. Také jsem občas používal.

V té verzi na obrázku v článku jsem někdy v roce 1990 viděl i v české verzi - copyright byl nějaké ostravské firmy - ovšem silně se zdálo, že to byl ukradený PC Tools počeštěný úpravou spustitelného souboru v nějakém hexa editoru (nesmyslně zkrácená slova, délkou odpovídající původním anglickým výrazům, občas něco nepřeloženo).

Chybí mě zde zcela nepostradatelný AFD - advanced full screen debugger a jeho krásně barevná textová obrazovka ;)

O IDE, debuggerech a dalsich aplikacich v textovem rezimu se jeste zminim nekdy priste, v tomto clanku uz nezbylo misto ;-)

Též aplikace využívající textový režim:
http://en.wikipedia.org/wiki/DESQview

:-)

www.ztree.com

Po více než dvaceti letech strávených prací na PC už mám tolik souborů a adresářů, že bych se bez tohoto textového file manageru vůbec neobešel. Sem tam něco udělám v Total Commanderu, ale ZTree u mne bezvýhradně vede.

Většinu programů spouštím z příkazového řádku krátkými jedno- až třípísmennými zkratkami. Je to velice rychlé a pohodlné, když pracujete s více různými aplikacemi.

Bez textového režimu si efektivní práci na PC nedovedu představit.