Přidat článek mezi oblíbenéZasílat nové komentáře e-mailem Provozujeme 16-bitové aplikace ve Windows7 (popř. Vista)

K napsání článku mě vedlo několik posledních příhod s migrací (typicky) účetních programů na nové počítače. Považujte tento článeček jako takové malé kompendium vad, nástrah a chytáků při provozování "nepodporovaného" softwaru a moderního OS.

Úvodem

Hned na úvod je třeba poznamenat a předznamenat několik zásadních faktů. První z nich je ten, že při upgrade hardware je třeba již předem počítat s tím, že bude provozována 16-bitová aplikace. Podporu pro spouštění a vykonávání těchto aplikací obsahují totiž POUZE 32-bitové verze Windows, a tedy takovou dbaseIV, FoxPro, popř. PCFand na 64-bitovém OS vůbec nespustíte. Je tedy velmi vhodné být na tuto eventualitu připraven již při nákupu počítače (změnit "bitovost" systému můžete pouze s Ultimate verzí Windows), OEM produkty takto měnit nelze. Pokud již máme "nadrobeno" (64-bitový OS), jediným řešením zůstává použití emulátoru, typicky DOSbox, VMware Player, VirtualBox, popř. VirtualPC. Páni a paní účetní jsou tvorové velmi konzervativní, neradi mění své navyklé úkony a softwary a vůbec preferují ovládání klávesnicí oproti Windowsovým aplikacím - a v tomto se jim osobně vůbec nedivím, ovládání klávesnicí je totiž namnoze vysoce efektivní, obzvláště u účetních softwarů.

Dějství první, instalace aplikace

Paradoxně instalace aplikací nečiní většinou zásadnějšího problému, V těch nejextrémnějších případech je třeba nastavit kompatibilitu aplikace instalátoru se starší verzí OS. Zároveň bych ale rád upozornil na potenciální problém s UAC (více v následující kapitole), proto instalujte aplikaci buď do kořenového adresáře disku (pokud to sám instalátor navrhuje), nebo ještě lépe do vlastního adresáře, např. "programy", pokud to Vaše aplikace podporuje a jste-li si jisti, že takto bude fungovat.

Druhá varianta je přenos instalace z původního PC. Protože se jedná o "dosové" programy, jejich přenos na jiné PC (většinou) nečiní žádné větší problémy, výjimkou mohou být aplikace, které využívají jako backend nějakou windows službu, typicky databázi BDE, popř. podporu tisku. V takových případech je nutné tuto podporu doinstalovat. V některých případech je při změně pracovního adresáře třeba překonfigurovat konfigurační (cfg popř. ini) soubory a změnit v nich cestu k datům. Z tohoto důvodu nedoporučuji používat v názvech adresářů diakritiku nebo mezery, museli byste používat zkráceného "tildového" tvaru jmen adresářů - např. "data aplikací" lze psát i jako "dataap~1".

Dějství druhé, zprovoznění aplikace

Jak již bylo řečeno v předchozí kapitole, některé aplikace mají tendenci se nainstalovat do "Program files", popř. do jiných adresářů, nad kterými bdí UAC. V takových případech se dostanete téměř jistě do potíží, neboť UAC těmto programům, které běží "v emulaci 16bitů" může velmi účinně bránit v modifikaci datových či konfiguračních souborů. Řešení spočívá buď v přesunu mimo tyto adresáře, nebo ve vypnutí UAC. Zároveň je třeba poznamenat, že UAC je obecně přínosný systém (respektive je pevně včleněn do logiky ovládání systému) a jeho vypnutím ztratí běžný uživatel (tedy neadministrátor) značnou kontrolu nad OS. Doporučený postup je tedy ponechat UAC v chodu a přesunout aplikaci mimo chráněný prostor.

Z výše uvedeného již přímo vyplývá další krok - nastavení účtů tak, aby uživatel při běžné práci mohl pracovat pod neprivilegovaným účtem. Drtivá většina těchto aplikací nevyžaduje admin práva, postačuje jim nastavit práva na adresář aplikace, popřípadě ještě na separátní datový adresář. S ohledem na uživatelský komfort, bezpečnost systému i dat je velmi vhodné nepoužívat privilegovaný (správcovský) účet pro běžnou práci. Kombinace UAC s neprivilegovaným účtem funguje skvěle a dobře uživatele upozorňuje, že se pokouší o nestandardní modifikace systému.

Poslední problém, který můžete potkat, je potřeba zvýšit limit otevřených souborů. Do dob Windows98 se toto nastavovalo v souborech config.sys (a některé věci i v autoexec.bat), v NT větvi systémů Windows je na podobné věci vyhrazen soubor config.nt a autoexec.nt v adresáři system32,který se nachází v instalačním adresáři Windows. Stačí tedy doplnit na konec souboru config.nt položku FILES=150 (pokud tam již je, je třeba ji editovat na požadovanou hodnotu).

Dějství třetí, tisk

Program nám již funguje, nicméně tisk ještě nikoli. Pokud jsme měli štěstí a máme PC s možností vyvedení reálného paralelního portu a zároveň tiskárnu vybavenou paralelním rozhraním a interpretrem jazyku, který podporuje daný program (typicky jazyky rodiny HP PCL, např. PCL5), máme prakticky hotovo a stačí nastavit tisk na LPT1.
Ti méně šťastní uživatelé s tiskárnou pro USB, zato s podporovaným tiskovým jazykem, to už tak jednoduché nemají, nicméně i v tomto případě lze tiskárnu donutit k tisku. Vždy je nutno tiskárnu nasdílet a namapovat na port LPT1. Je-li uživatel administrátor a má-li PC připojené do sítě, je to vcelku triviální záležitost, postačí tiskárnu nasdílet např. jako "dostisk" a namapovat příkazem

net use lpt1: \\jmenoPC\dostisk /persistent:yes

Problémy nastanou v okamžiku, kdy uživatel není administrátor. V takovém případě je třeba práva alespoň na chvíli přidat. Druhý problém může nastat v okamžiku, kdy PC není vůbec připojeno k síti. Lze to vyřešit několika způsoby (dva jsou hardwarové, třetí čistě softwarový):

1. Nastavit pevnou IP adresu a připojit síťovou kartu k switchi
2. Nastavit pevnou IP adresu a použít ethernet loopback - v podstatě se jedná o kus UTP kabelu s propojenými piny 1-3 a 2-6.
3. Nainstalovat MS loopback adaptér a nakonfigurovat mu IP adresu.

http://www.windowsnetworking.com/img/upl/image0151         097073946881.jpg

V okamžiku, kdy máme nepodporovanou tiskárnu (typicky všechny GDI alias "windows" tiskárny) - což je v dnešní úpadkové době prakticky 99% všech tiskáren, nezbývá nám nic jiného, než použít nějaký "rastrovací" software běžící ve windows a předhazovat mu tisky z vlastní DOSové aplikace. Ty pak vyrastruje a odešle jako běžnou windowsovou tiskovou úlohu do tiskárny. Většina dodnes vyvíjených DOSových programů však s touto eventualitou počítá a v rámci své instalace nabízí tuto funkcionalitu sama. Ty programy, které takovou podporu výrobce nemají, mohou použít komerčních nástrojů, z těch nejznámějších lze zmínit např. DOSprn, který umí zachytávat přímo port LPT1, nebo český DOSprint. Těchto softwarů je mnoho, každému doporučuji vybrat si "ten svůj".

Dějství čtvrté, čeština

Čeština byla a doposud je zapeklitý problém. I dnešní moderní systémy s ní mají nemalé problémy, natož starší programy pro DOS. Platí, že většina softwarů si řeší problém češtiny po svém, menší část pak (někdy zčásti) spoléhá na služby systému. Ten nejzásadnější problém je, že za ta léta počítačových začátků se pro češtinu objevilo hned několik kódování (KOI-8, Kameničtí, LatinII, standardy jako ISO nevyjímaje), přičemž největších úspěchů dosáhla česká implementace bratří Kamenických, jejíž předností byla čitelnost i na počítačích, které neumožňovaly změnu fontu, a v pozdějších dobách pak nativní implementace Microsoftu, LatinII. V dnešní době se setkáte nejpravděpodobněji právě s těmito dvěma kódováními. Pro "kameníky" hovoří čitelnost, pro LatinII pak podpora MS a výrobců tiskáren.
Začněme kódováním s lepší podporou, tj. LatinII. U něj není problém zobrazit češtinu v programu bezchybně (s výjimkou Windows7 a fontů TTF, viz následující kapitola), taktéž není problém s mapou znaků pro klávesnici (obojí je zahrnuto ve standardní instalaci Windows). Podpora tiskáren je rovněž velmi dobrá, a pokud máte řádkově orientovanou tiskárnu (tj. např. maticovou tiskárnu Epson) nebo tiskárnu s tiskovým jazykem, bude mít podporu právě pro LatinII. Rovněž není problém získat fonty pro softdownload do těchto tiskáren v tomto kódování.
U Kameníků nastává v případě moderních OS problém. Zatímco změna mapy klávesnice bývá bez problémů, změna fontů v DOSové aplikaci funguje pouze při přepnutí do plné textové obrazovky, což je v případě Visty a Win7 možné jen v okamžiku, kdy jsou nainstalovány ovladače grafické karty určené pro WindowsXP. Toto řešení nepokládám za ideální, není totiž příliš stabilní a doporučované a s novými počítači, které již ani WindowsXP ani ovladačově nepodporují (a tento stav bude gradovat), ani možné. Je tedy třeba se buď smířit s "nekvalitní" češtinou, nebo si přepnout (pokud toto program podporuje) kódování do LatinII. Řešení v rámci běhu v okně bude popsáno v následující kapitole. Rovněž tisk bývá problematičtější, a samy programy většinou provádějí interní konverzi do LatinII, nebo tisknou bez diakritiky.
Na závěr této kapitoly budiž řečeno, že podpora češtiny a tisku bývá namnoze velmi kvalitním a přesným ukazatelem toho, do jaké míry výrobce softwaru svůj produkt udržuje v chodu na nových systémech a jak dobře podporuje své zákazníky - toť mé empirické zkušenosti s mnoha výrobci.

Dějství páté, ergonomie

Jak již bylo předznamenáno, Windows Vista a vyšší ztratily schopnost běhu DOSových aplikací v textovém režimu, nyní lze tyto programy provozovat pouze v okně. Navíc dnes nekoupíte monitor s menším rozlišením, než 1366x768px. Pro bystrozraké to není problém, pro dalekozraké, kteří již potřebují brýle, ano. Nastává okamžik, kdy je třeba okno zvětšit ideálně tak, aby bylo co největší na dané ploše. To lze provést bez problémů při kombinaci Vista + LatinII, ale jakákoli kombinace Kameníků, popř. Windows 7 je předem bez jistých úprav odsouzena k nezdaru. Proč? U kódování Kameníků je to jasné - systém Windows neobsahuje fonty, které by toto kódování podporovaly. U Windows 7 je situace prozaičtější - obsahují chybu, která znemožňuje použít systémové vektorové fonty správně (kódování se vizuálně vždy přepíná do LatinI (tj. CP437), namísto správného LatinII (CP852). Microsoft o situaci ví, ale věc neřeší. Bitmapové fonty naštěstí fungují, takže lze používat alespoň tyto, nicméně na větších zobrazovadlech jsou i ty největší systémové bitmapové fonty příliš malé.
Jak z toho ven? Jak uspokojit nevrlého pana účetního, který se nechce na takové blechy dívat? Řešení existuje a nazývá se upravené fonty. Pro kódování Kamenických existuje font Lucida Console Kameničtí, pro LatinII existuje dokonce několik variací, jednak větší bitmapový font (derivovaný z běžného fontu textového režimu), jednak opět upravená Lucida Console, která má na místech LatinI znaků "nasunuty" znaky české. S oběma fonty lze docílit správného zobrazení češtiny a velkého okna aplikace - stačí je nainstalovat do systému a v případě TTF fontů ještě přidat reg soubor, jímž řekneme systému že tyto fonty může nabízet pro použití v okně konzole. Všechny zmíněné fonty naleznete pod článkem jako přílohu.
Tím jsme vyřešili i poslední námitky pana účetního.. :-)

Dějství šesté, zálohování

Poslední dějství je dějstvím v naší režii. Většina uživatelů nechápe, proč by vlastně měla zálohovat, když "přece má všechno na disku a program dělá zálohy". Problém je v tom, že drtivá většina programů zálohuje na změny, nikoli na poškození disku, tedy zálohy ukládá na stejném médiu jako jsou uložena ostrá data. V případě zničení či zcizení počítače a/nebo disku tak přicházejí o svá veškerá data. Z tohoto důvodu je třeba, abyste uživatele vždy připravili na tuto eventualitu a nachystali proces, kterým si bude moci zálohy vytvářet sám.
Možností je přehršel, od prostého kopírování dat na USB flashdisk nebo jiný síťový počítač jednoduchým BAT skriptem, přes využití zálohovacích nástrojů nacházejících se ve Windows (musím říct, že se mi velmi stýská po velmi mocném programu ntbackup, jeho novodobá variace v Windows 7 se mi zdá velkým krokem zpět - staromilci mohou ntbackup získat zkopírováním z Windows XP dle návodu). Jako další varianta se jeví použití zálohovacího systému třetí strany, velmi oblíbeným je např. Cobian Backup, navíc je i zdarma.
Svou činnost je tedy vždy vhodné završit poučením uživatele o zálohování a jeho řádným proškolením a ideálně i vlastním otestováním chodu.

Finále

A jdeme do finále. Uživatel je spokojený, programy mu fungují, zálohuje. Ale co dál? Windows 7 je pravděpodobně poslední systém s podporou 16-bitových aplikací, další verze Windows již budou nejspíše pouze 64-bitové. To pro uživatele 16-bitových aplikací znamená výhledově konec podpory nových systémů (tj. zůstanou jim Win7 "na dožití" hardwaru), nebo nutnost použití virtualizace. Obě řešení nejsou ideální a tak bych všem již dopředu doporučil tlačit na výrobce programů, aby zajistili kontinuitu svých produktů s výhledem na několik let dopředu. Přejít totiž z 16-bitové aplikace rovnou pod WinAPI nebývá nejjednodušší ani nejrychlejší. A vývoj (zejména harware - typicky nedostatek ovladačů nových HW modelů PC a tiskáren pro starší verze OS) ale i zastarávání a zničení stávajícího HW uživatele dříve či později donutí k přechodu na vyšší verzi OS...

Máte-li vlastní zkušenosti, podělte se o ně prosím v diskusi.

Komentář k článku

1 Zadajte svou přezdívku:
2 Napište svůj komentář:
3 Pokud chcete dostat ban, zadejte libovolný text:

Zpět na články