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.
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 :-)
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.
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 :-)
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.
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.
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.
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.
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¤ :-)
Opravdu?
Já na svém osmibitu používám ASCII, nebo ISO8859-2
http://cygnus.speccy.cz/popis_ufeditor.php
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?) ...
Myslim, ze si muzete vybrat jine tema. O kodovani cestiny existuje velmi slusny web www.cestina.cz
no, ono to je tak normální.
I dneska je všude kodovací babylon - obzvlášť když se jedná o web či databáze. navíc když se někdo pokouší natvrdo transformovat data do ISO 8859-1 ... zakázat veškeré jiné kodování než utf-8. nevim k čemu je dobré v dnešním světě škudlit na jednotlivých bajtech... když se ke všemu přicpe miliarda různých metadat a metadat k metadatům a tak dál...
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.
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 (
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é.
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).
Též aplikace využívající textový režim:
http://en.wikipedia.org/wiki/DESQview
:-)
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.