Jak vyvíjet (nejen) pro Windows 2000

Spolu s Windows 2000 přichází i relativně velké množství nových technologií. Velká část z nich se týká způsobu používání aplikací - od instalace přes uživatelské prostředí po ukládání dat na disk. Již od června roku 1999 je možné stáhnout si ze stránek firmy Microsoft dokument pod názvem Aplikační specifikace pro Microsoft Windows 2000.

Tato aplikační specifikace je určena pro dva druhy aplikací: desktopové a distribuované vícevrstvé. V tomto článku se budu věnovat pouze první specifikaci. Provedu vás jejími jednotlivými částmi a uvedu několik postřehů a názorů na probírané téma. Budu-li používat slovo specifikace, budu tím myslet specifikaci pro desktopové aplikace. Vlastní text specifikace je možné získat na adrese http://msdn.microsoft.com/…/appspec.asp, překlad naleznete na http://msdn.microsoft.cz/…/default.htm.

Pro koho je dokument určen

Specifikace není vázána na žádný programovací jazyk, ani na žádný vývojový nástroj. Je určena pro každého vývojáře nebo vývojový tým, který chce vytvořit kvalitní aplikaci (nejen) pro Windows 2000 a chce, aby se aplikace chovala přátelsky. Specifikace je primárně napsána pro produkty, které usilují o získání loga Certified for Windows, ale domnívám se, že by si ji měli přečíst všichni vývojáři, neboť poskytuje velké množství rad a doporučení, z nichž většina je, ať se nám to líbí nebo ne, velice rozumná a divím se, že tento dokument je aktuální až nyní.

Stejně tak si mohou specifikaci přečíst i ti, kteří chtějí vědět, co že znamená logo Certified for Windows umístěné na krabici se softwarem, jenž si chtějí zakoupit.

Kdo testuje

Aplikace testuje laboratoř VeriTest, která provádí nezávislé testy pro velké množství společností – ať už hardwarových nebo softwarových – a uděluje různá loga nebo certifikace. Seznam společností, jejichž loga můžete získat, je uveden na stránkách testovací laboratoře. Pokud vaše aplikace projde všemi testy a splní veškeré požadavky kladené ve specifikaci, získá uvedené logo.

Co lze ve specifikaci nalézt

Specifikace je rozdělena do sedmi ucelených částí. Na konci každé z nich je návod, jak aplikaci testovat a na co si dát pozor. Většina napsaných požadavků je logická a mnohdy je dráždění uživatele, pokud se tak program nechová (např. chybějící podpora dlouhých názvů souborů).

Kapitola 1: Základy Windows

První kapitola popisuje výchozí požadavky na konsistenci a stabilní funkčnost aplikace. Základní požadavek kladený na aplikaci je její 32-bitovost. Formát EXE souboru musí být ve tvaru PE (Portable Executable). Nedoporučuje se používat 16-bitové komponenty kvůli zpětné nekompatibilitě budoucích 64-bitových Windows. Aplikace musí podporovat dlouhé názvy souborů (LFN) a universální konvenci pojmenování (UNC). Některé aplikace mají stále ještě špatný zvyk zapisovat do souboru AUTOEXEC.BAT anebo CONFIG.SYS. Tomu by již měl být učiněn konec. Další věcí, která vytáčela jinak flegmatické uživatele, bylo vytváření souborů nebo dokonce složek mimo domovskou složku, kde byla aplikace nainstalována. Pokud to chce autor aplikace provádět i nadále, musí aplikace zaregistrovat přípony inkriminovaných souborů nebo je skrýt (což je ale ještě horší než je nechat viditelné). Pokud je přípona registrována jiným programem, může si ji aplikace přivlastnit pro sebe, bohužel se na to nemusí ptát uživatele, takže pokud se programy budou chovat nepřátelsky, budou si vzájemně přebírat registrované přípony a uživatel si může objednat lůžko na klinice. Při registraci přípony musíte mj. také dodat srozumitelný popis. Co to je srozumitelný popis již není nikde řečeno. Vaše aplikace musí ověřit (třeba při instalaci nebo při spouštění), zda operační systém, kde chce uživatel aplikaci provozovat, má správnou minimální verzi. Poslední poznámka: distribuujete-li aplikaci na CD-ROM, musí podporovat funkci Auto-Play, což ale dnes splňuje většina aplikací.

Kapitola 2: Instalování/o­dinstalování

Instalace byla, a dosud často je, problémem. Uživatelé se často ptají, co všechno se instaluje, co který soubor znamená a k čemu slouží, proč se instaluje velké množství souborů do složky Windows případně System, když se o to nikdo neprosil (za tohle by se měl opravdu někdo zodpovídat). Při odinstalování je běžně uživatel vyzýván k tomu, aby se rozhodl, zda knihovna xxx.dll, která třeba náhodou může být sdílena, má být odstraněna nebo ne. Uživatel zapřemýšlí jednou, dvakrát, ale když se odinstalační program zeptá po třetí či po čtvrté, ztratí trpělivost a odklepne Yes to all (ti radikálnější) nebo No to all (ti, kteří mají dostatek místa na disku). (Pokud někdo patří do obou skupin, pak zuří.) Jak by se tedy měla chovat aplikace dle specifikace a co nabízejí Windows? Windows 2000 obsahují čítač referencí a kontrolují verze sdílených komponent. Zákazník tím získá „méně problémů během instalace aplikace“ – všimněte si, že Microsoft i nadále připouští možné problémy.

Instalace by měla (pokud chce získat certifikát tak musí) využívat služby Windows Installer. To mj. znamená, že instalace musí být ve formě balíčků na bázi Windows Installer. Windows Installer se k instalování nebo odinstalování chová transakčně, takže aplikace je brána jako monolitická skupina informací (nazývaná komponenta) a jako taková je odstraněna celá nebo vůbec. Komponenta může obsahovat soubor(y), klíče registrů, zástupce, ale i jiné informace, které jsou důležité pro instalaci. Každá komponenta má své jednoznačné GUID. Aby odinstalování mohlo proběhnout korektně, musí být splněno několik požadavků (např. že jeden prostředek komponenty musí být součástí maximálně jedné komponenty nebo že všechny soubory, které jsou v komponentě umístěny, musí být nainstalovány do stejné složky). Windows si sami zjistí, zda je komponenta sdílena dalšími aplikacemi a podle toho zvyšují či snižují čítač referencí v závislosti na instalování či odinstalování aplikací.

Aplikace by se měla standardně instalovat do složky Program Files (pokud neprovádíte upgrade) a musí dodat všechny důležité informace pro dialog Přidání/odebrání programů.

Na této kapitole je krásná následující věta: „Nejste-li si jisti, zda odstraněním DLL nemůžete ublížit jiným aplikacím, bude lepší ponechat je.“ Já osobně si nejsem jist, zda je to myšleno vážně. Pokud čítače komponent pracují správně, pak je to dobrý vtip. Není-li si Microsoft jist svými službami, pak nechápu, proč je poskytuje.

Kapitola 3: Sdílení komponent

Používá-li vás program nějakou cizí knihovnu DLL, pak bylo dosud možné, že jiný program přepsal tuto knihovnu novější nebo starší verzí. Použití vaší aplikace bylo následně leckdy nemožné (Microsoft toto nazývá výstižným termínem DLL Hell). Windows 2000 přicházejí s novou formou sdílení, která se nazývá side-by-side (bok po boku). Toto sdílení umožňuje, aby více verzí jedné COM nebo Win32 komponenty běželo současně v paměti a své služby aplikaci poskytovala ta správná verze. Tyto komponenty nejsou instalovány do systémových složek, ale do složky k aplikaci a musí být správně registrovány systémem. Vývojáři takovýchto komponent musí zajistit, aby jejich jednotlivé verze nebyly vzájemně v konfliktu.

Kapitola 4: Správa dat a nastavení

Oddělení vytvořených dokumentů od aplikačních souborů je velmi podstatné. V současné době většina aplikací ukládá data k sobě do domovské složky, což může mít neblahý důsledek. Uvažte sami. Uživatel smaže složku s aplikací a pokud následně potřebuje vytvořené soubory, může se jen modlit, že záloha z minulého měsíce je co nejaktuálnější. Specifikace požaduje ukládat všechna vytvořená data implicitně do složky Documents (případně u grafických aplikací My Pictures). Tato složka je součástí uživatelského profilu a tedy je chráněna před neoprávněným přístupem ostatních uživatelů. Pro sdílení dat mezi uživateli může sloužit složka All users/Documents. Tyto dokumenty budou ovšem pouze pro čtení. Pokud se vaše aplikace snaží otevřít soubor, ke kterému je odepřen přístup, měla by inteligentním způsobem skutečnost oznámit a umožnit otevřít jiný soubor nebo provést nějakou odpovídající akci. Má-li uživatel odepřen přístup například k položce Spustit… v nabídce Start, aplikace by neměla umožnit spustit jiný program. Všechna takováto nastavení je možné nalézt v registrech a je na vás, abyste je jakožto vývojáři akceptovali.

Kapitola 5: Základy uživatelského nastavení

Uživatelské prostředí je to první, co uživatel na vaší aplikaci spatří. O tom, jak by mělo toto prostředí vypadat, bylo již napsáno mnoho knih, dokonce jsou vydány mezinárodní normy, jak se má aplikace z uživatelského hlediska chovat. Aplikace musí být přátelská i pro tělesně postižené lidi.

Základem je využívání standardních systémových nastavení velikosti, barvy, písma a vstupu. Současně je zapotřebí zajišťovat kompatibilitu s volbou Vysoký kontrast (volba, která říká, že uživatel požaduje pro zvýšení čitelnosti vysoký kontrast). Každá funkce aplikace musí být přístupná nejen pomocí myši, ale i pomocí klávesnice. Tento přístup by měl být dostatečně zdokumentovaný. Využívá-li vaše aplikace vyjadřování některých stavů pomocí zvuků (chybové stavy, příchozí mail apod.), je potřeba, aby tento stav bylo možné oznámit i jinými prostředky.

Změny se také týkají nabídky Start. Obsahuje-li složka Programs příliš mnoho informací, uživatelé přestávají nabídku používat. Do nabídky Programs dávejte pouze zástupce na vaši aplikaci, aniž byste vytvářeli další složky nebo tam dávali soubory typu readme.txt. Je-li vaše softwarové řešení přeci jenom rozsáhlé, složku si samozřejmě vytvořit můžete.

Co mi připadne jako přehnaný požadavek je podpora více monitorů. Uživatelů s více monitory je poskrovnu. Pokud ale chcete certifikát získat, nedá se nic dělat. Obzvláště morbidní, je situace, kdy si uživatel nějakým způsobem poskládá okna aplikace, následně aplikaci ukončí, přeuspořádá si libovolně monitory (třeba z matice monitorů 2×2 udělá řadu čtyř monitorů), a následně spustí vaši aplikaci. Nyní musíte zajistit správné přeuspořádání a správné zobrazení všech oken. Pro „zjednodušení“ situace každý monitor samozřejmě může mít jinou barevnou hloubku a jiné rozlišení.

Kapitola 6: Podpora OnNow/ACPI

Podpora správy napájení je důležitá především pro přenosné počítače. Aby tato podpora mohla fungovat správně, musí se i aplikace zapojit do této činnosti. Základním požadavkem je reagovat na zprávu o nízkém napětí baterií, o vypínání počítače či o přechodu do standby režimu. Aplikace musí tyto stavy přečkat tak, aby bylo možno po obnovení dále pokračovat v činnosti.

Kapitola 7: Migrace aplikace

Migrací aplikace je myšleno přechod z Windows 9× nebo NT na Windows 2000. Pokud uživatel provádí upgrade na Windows 2000, pak se aplikace musí chovat stejně jako na předešlé verzi, tj. např. při spuštění použít nastavení, která si uživatel uložil na předešlé verzi systému. Na této části je asi nejnepříjemnější testování, kdy musíte provést nastavení na starší verzi Windows a pak provést upgrade, který není zrovna nejrychlejší.

Implicitní cesty

Často se tu mluvilo o implicitních cestách jako například Documents, Program Files a podobně. Jak tuto cestu získat? Rozhodně ne tak, že napíšete řetězec ‚C:\Program Files‘. Ačkoliv je to cesta na 90 % počítačů správná, postup je to špatný. K získání cesty se používá funkce SHGetFolderPath, která je importována z knihovny SHFOLDER.DLL. Jedná se o novou knihovnu, která je mj. dodávána s Windows 2000, Windows NT SP4, Internet Explorerem 5.x a Windows 98 SE. Tuto knihovnu můžete legálně šířit se svými aplikacemi. Jedním z parametrů je identifikátor udávající, jakou složku potřebujete získat. Cesta může být ve tvaru UNC, což by ale vaší aplikaci nemělo dělat problémy, splňuje-li požadavky uvedené v kapitole 1. Divím se, že se nedodávala dříve, protože se jedná o velký krok ke spokojenosti nejen uživatelů, ale i programátorů.

Jak testovat

Na konci každé kapitoly je vždy popsáno, jak danou problematiku testovat, co vše se musí udělat a vyzkoušet, aby aplikace prošla testem. Současně jsou v textu uvedeny příklady, jak požadavku dosáhnout, což ze specifikace dělá velmi dobře použitelný dokument.

Poznámky

Někdy se zdálo, že specifikaci nepřekládal člověk k tomu vhodný. Napsat do takového dokumentu, že aplikace nesmí „zůstat viset“ není zrovna profesionální. Vhodnější může být třeba „přestat reagovat na zprávy Windows“. Stejně tak nad nadpisem „Hlavní důvody přínosu pro zákazníky“ musí čtenář dlouho přemýšlet, co že to vlastně znamená. Taktéž mi připadne jako podceňování inteligence programátora, když jsou mu nabízeny popisky, které by měl dávat do svých dialogových oken.

Poznámka k instalování

Dnes má většina programů vlastní instalační proces, který je ve velké míře vytvořen v produktu InstallShield. Díky tomu proces instalování je téměř automatický a známý. Instalace vytvořená v jiném (byť třeba stejně kvalitním) produktu vypadá „divně“. Co však již není správné, je umístění souborů jinam, než uživatel chce. Jako příklad zde uvedu instalaci Microsoft Office 97. Instalace je za trest, pokud jej neinstalujete na standardní místo. Po zadání místa, kam jej chcete instalovat (třeba jen na jiný disk), musíte ještě na spoustě dalších míst přepisovat cestu a někde vám to instalační program ani nedovolí. Ještě že logo Certified for Windows nový kancelářský balík Office 2000 má.

Celkový dojem

Z dokumentu je patrné, že se Microsoft snaží (konečně) zabránit zběsilostem s knihovnami DLL (DLL Hell). Další výhodou pro uživatele aplikací s logem Certified for Windows je sjednocení míst, kam se ukládají data aplikace a uživatelské soubory. Stejně tak vývojáři mají zdokumentované důležité informace a postupy, které bych doporučoval v co nejvyšší míře (ke spokojenosti zákazníka) používat.

V tomto článku nebylo cílem popsat všechny vlastnosti specifikace (to si ji můžete přečíst sami), ale šlo o jakýsi průřez specifikací, který jsem si dovolil rozšířit o vlastní názory.

Související odkazy

• Hlavní stránka loga
• Program připravenosti pro Windows 2000 pro aplikace a vývojáře
• Testovací laboratoř VeriTest
• Specifikace v češtině
• Specifikace v angličtině
• Loga certifikace