Nedávno jsem adaptoval instalátor jedné aplikace, aby běžel bez problémů i na 64bitových Windows a zde se podělím o pár poznatků.

Nejprve jsem potřeboval zjistit, zda je moje aplikace zrovna spuštěna na systému 32bitovém nebo 64bitovém. Nápady s kontrolou velikosti číselných datových typů je třeba zavrhnout, ta by se totiž určila natvrdo již během kompilace a ne až při spuštění aplikace.

Architektura procesoru je uložená v proměnné prostředí Windows s názvem PROCESSOR_ARCHITECTURE, kde najdete buď „x86″ nebo něco jako „AMD64″ (i na Intel procesorech). Má to ale jeden háček – funkce GetEnvironmentVariable() v klidu vrátí „x86″ i na 64bitovém systému, voláte-li ji z 32bitové aplikace. Tudy cesta také nevede.

Informaci je potřeba vyčíst z registru, to funguje spolehlivě:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment\PROCESSOR_ARCHITECTURE

Další zajímavá vlastnost 64bitových Windows je oddělený přístup do části registrů. 32bitová aplikace pracuje s jinými registry, než 64bitová (týká se větve Software\ jak v HKEY_LOCAL_MACHINE, tak v HKEY_CURRENT_USER). Větve pro 32bitové aplikace jsou umístěny pod uzlem Wow6432Node, přistupuje se k nim však zcela transparentně.

Co však v případě, pokud potřebujeme přistupovat v 32bitové aplikaci do 64bitové části registru nebo naopak? Řešení je poměrně jednoduché, existují speciální příznaky pro samDesired parametr funkcí RegCreateKeyEx(), RegDeleteKeyEx() a RegOpenKeyEx(): KEY_WOW64_64KEY a KEY_WOW64_32KEY.

Z 32bitové aplikace tak můžeme otevřít klíč v 64bitové části registru třeba takto:

RegOpenKeyEx(HKEY_LOCAL_MACHINE, regPath, 0, KEY_READ | KEY_WOW64_64KEY, &hKey);

Toť zatím vše, příště možná něco třeba o podepisování ovladačů a utilitě DpInst.exe

V dnešní době mají běžné počítače dostatečně velký výkon na to, aby zvládaly provádět více věcí naráz než kdy jindy. Na co jste dříve potřebovali síť o několika strojích, dnes hravě zvládne jeden jediný.

Na jednom fyzickém počítači tak může naráz běžet několik počítačů virtuálních, z nichž každý může poskytovat určité služby, mít nainstalovaný jiný operační systém apod. Výhodou je, že tyto počítače běží zcela izolovaně a nemohou se ovlivnit navzájem. Mohou být ale propojeny do virtuální sítě a využívat všech možností, které síťování nabízí.

Jaké výhody mi to nabízí?

1. Oddělení projektů. Když potřebuji pro jeden projekt webový server, je zbytečné ho mít instalovaný i pro projekty jiné. Sám jsem dospěl do stavu, kdy mám na fyzickém počítači instalovaný pouze prohlížeč internetu, fotek, komunikační programy, pár dalších utilit a samozřejmě VMWare.
2. Pokusný prostor. Občas je potřeba vyzkoušet nějaký kód nebo aplikaci, které člověk nedůvěřuje. Ven z virtuálního počítače (v tomto případě tzv. sandboxu) se to nedostane a případné negativní následky lze jednoduše smazat.
3. Přenositelnost. Když si koupíte nový hardware nebo potřebujete přenést projekt jinam, stačí pouze překopírovat pár souborů tvořících virtuální stroj (za předpokladu, že i cílový hardware používá stejnou instrukční sadu procesoru). Odpadá nutnost pokaždé instalovat všechny potřebné aplikace. S tím souvisí i snadná obnova projektu po reinstalaci fyzického počítače nebo naopak možnost reinstalovat pouze počítač virtuální.
4. Testování. Můžete mít řadu virtuálních počítačů s různými systémy a jejich konfiguracemi a testovat na nich svůj vyvíjený software.

Praxe

Zůstal jsem věrný VMWaru, jiná řešení měla problémy třeba s USB zařízeními nebo dokonce stabilitou (MS Virtual PC). VMWare Player je zdarma, neumí však vytvářet nové virtuální počítače. V tom ho však může zastoupit třeba tento online generátor: easyvmx.com.

Používám síťový režim bridged, každý virtuální stroj pak může mít vlastní IP adresu a být tak pohodlně používaný jako server.

Virtualizujte, ulehčí vám to práci

Total Commander je fajn aplikace, ale občas v něčem trochu opožděná. Ještě před pár lety třeba vypadala jako v dobách největší slávy Windows 3.1.

Ale časy se mění a nové verze už dokonce zvládají mít pro každého uživatele vlastní nastavení. To se samozřejmě hodí a odpadá i nutnost být administrátorem, aby se vaše konfigurace ukládala (což bylo nezbytné, když býval wincmd.ini soubor přímo v adresáři windows). Instaloval jsem tedy verzi 7.04a a během instalace zvolil, že uživatelská konfigurace má být v profilu každého uživatele (Profil/Application Data).

Pro uživatele Administrator, kde jsem prováděl instalaci, to i fungovalo. U ostatních běžných uživatelů ovšem ne, Total Commander se vytrvale pokoušel načíst a uložit konfiguraci do starého dobrého adresáře windows.

Řešení je poměrně jednoduché, pro každého uživatele je potřeba zapsat do registru tyto údaje:

[HKEY_CURRENT_USER\Software\Ghisler\Total Commander]

"IniFileName"="%APPDATA%\\GHISLER\\wincmd.ini"

"FtpIniName"="%APPDATA%\\GHISLER\\wcx_ftp.ini"

a do adresáře %APPDATA%\GHISLER\ případně nakopírovat vaši oblíbenou konfiguraci.

Obecně se má za to, že software pro správu verzí se vyplatí používat na větších projektech, neboť právě ohlídání kolizí ve změnách prováděných více programátory současně je jeho hlavní úkol.

Nicméně, verzovací systémy nabízejí i další funkce, které využijete i na projektech vyvíjených klidně jedním člověkem.

Práce na více počítačích

Verzovací systémy jsou výborné pro jednoduchou synchronizaci dat mezi různými počítači, na kterých pracujete.

Archivace všech změn

U jakéhokoliv souboru se vždy můžete vrátit k jeho libovolné verzi nebo se podívat na rozdíly mezi jeho různými verzemi. To se hodí v případech, kdy chcete zjistit, jak jste kdysi něco udělali; nebo nedejbože tehdy, kdy na něčem začnete pracovat, a pak vám dojde, že takto raději ne. Nemusíte se pak starat o to, jestli jste všechny změny dobře vrátili a jednoduše obnovíte poslední revizi.

Rychlý přístup ke starším verzím

Vždy když vydáte novou verzi, jednoduše si ji ve verzovacím systému pojmenujete (SVN tomu říká tag, ClearCase label). Kdykoliv se pak do této verze můžete přepnout a pracovat s ní, udělat její build pro zákazníka, který má s novější verzí problém apod. Rozhodně je to praktičtější, než staré verze třeba zipovat a pak pracně rozbalovat.

Vývoj na více větvích

Někdy se stane, že do programu chcete přidat nějaký větší balík funkcí. Jeho vývoj trvá třeba půl roku a mezitím chcete zákazníkům dodávat aktualizace původní verze. Co však rozhodně nechcete, aby v nich měli obsaženou část funkcí nových a byli tak ohroženi chybami a nestabilitou této vývojové verze.

V takovém případě oddělíte před započetím vývoje těchto novinek tzv. branch od hlavní verze a vývoj provadíte na této nové branchi. V případě potřeby se samozřejmě do hlavní verze můžete kdykoliv přepnout. Po odladění nové verze přenesete změny i do verze hlavní, nebo-li provedete merge.

Jsem přesvědčen, že jednoduchý systém pro správu verzí (jakým je třeba SVN), najde své opodstatnění pro nasazení na libovolném softwarovém projektu, který vám trvá víc než jedno odpoledne, nebo u kterého je pravděpodobnost, že se k němu někdy budete chtít vracet.

V okamžiku, kdy začnete vyvíjet aspoň trochu seriozní webové aplikace, pak má jistě smysl uvažovat o nějakém testování, nejlépe automatizovaném.

Co jsou unit testy

Základem by měl být unit testing (testování aplikačních jednotek), tedy v případě objektového programování testování toho, zda každá třída dělá správně to, co by měla. Zjednodušeně řečeno, napíšete si testovací skript a proklepnete jím správnou funkčnost všech metod ve vaší třídě pro různé vstupy, s důrazem na různé „speciální“ případy apod.

Výhody

Testovací skripty pro celý projekt můžete sdružovat do makefilů a pak pouhým make unit_tests rychle zkontrolovat všechny zdrojáky (o tom někdy příště). Při provádění úprav ve zdrojovém kódu se následně můžete rychle přesvědčit, zda jste si nezavlekli novou chybu někam, kde byste to vůbec nečekali.

(Celý příspěvek…)

Při tvorbě webu je stále potřeba přizpůsobovat vzhled různým obskurním prohlížečům, třeba takovému IE verze 6 (například na Trainweb chodí z IE6 18,3 % všech lidí).

Naposledy jsem se nad tím vztekal včera, kdy jsem potřeboval mít div element vysoký přesně 6 pixelů. Stylopis hovořil jasně:

.divider
{
	height: 6px;
}

Nicméně IE tvrdojíšně kreslil daný rámeček vysoký dobrých 15 pixelů. Někde jsem se dočetl, že je potřeba nastavit ještě line-height na nulu. To taky nepomohlo.

Nakonec se ukázalo, že starostlivý Internet Explorer se obával, že by se mi do tohoto elementu nevešlo písmo o velikosti 10pt (zděděno z elementu body) a tak výšku raději přizpůsoboval. Text jsem dovnitř samozřejmě dávat nehodlal. Řešení je tedy prosaické:

.divider
{
	height: 6px;
	font-size: 1pt;
}

Můžete si tak v případě potřeby ušetřit zhruba 20 minut googlování

Už přes rok kontinuálně vyvíjím jistou webovou aplikaci a již od začátku jsem si dával záležet na tom, abych ke každé třídě a metodě psal tzv. doxygen-style komentáře, popisující co která třída a metoda dělá, u metod navíc třeba dokumentaci parametrů a návratových hodnot.

Jak komentovat v kódu

/**
 * Ukázka doxygen-style komentáře.
 *
 * @class UkazkovaTrida
 * @author Hans
 *
 * @date 2008-05-29
 */
class UkazkovaTrida
{

	/**
	 * Ukázka doxygen-style komentáře.
	 * Funkce vracející nulu.
	 *
	 * @author Hans
	 *
	 * @date 2008-05-29
	 *
	 * @param zbytecny zbytečný parametr
	 * @return vždy 0
	 */
	function Nula($zbytecny)
	{
		return 0;
	}
}

Co pak s tím

Teď jsem to konečně nějak zužitkoval – stáhnul si Doxygen, v rychlosti nakonfiguroval projekt (pomocí přiloženého doxywizardu; stačilo v podstatě definovat adresář projektu a výstupní adresář pro dokumentaci) a vygeneroval konfigurační soubor projektu (Doxyfile). Ten lze pak doupravit ručně v textovém editoru (jedná se vlastně o jakýsi „makefile“ pro Doxygen).

Na ten jsem následně spustil doxygen.exe z příkazové řádky a rázem mám čtyřmegový balík provázané dokumentace v HTML včetně grafického znázornění závislosti tříd a podobných vymožeností.

To se mi líbí, v podstatě se jedná o jediný smysluplný (a zároveň snadný a nepříliš otravující) způsob dokumentování kódu. Kdysi jsem svůj kód zkoušel prohnat tuším PhpDocumentorem, ale ten se mi nepodařilo nakonfigurovat a rozchodit během jednoho odpoledne, toto šlo oproti tomu zcela samo.

(Celý příspěvek…)