Baza wiedzy oferowana przez Microsoft powinna zwać się raczej bazą przeprosin za błędy. Interpretacja zawartych w niej wątków przypomina nieraz próby dopasowania do rzeczywistości przepowiedni Nostradamusa, co jest o tyle uzasadnione, że rozwiązanie zagadki zależy w dużej mierze od dobrej woli osoby interpretującej i sprzyjających okoliczności. Być może Nostradamus napisał ''knota'', ale było to dawno temu i nie widzę powodów, aby we współczesnym świecie posiłkować się średniowiecznymi wzorcami.

Instalując program napisany w Visual Basicu, możemy mieć wrażenie zagięcia czasoprzestrzeni. Bogata koincydencja zjawisk i faktów, uniemożliwiająca w wielu przypadkach bezkolizyjne posadowienie programu wykonywalnego na innej maszynie, wyzwala w autorach oprogramowania jak najgorsze skojarzenia i odruchy. Przebogata jest baza wiedzy mówiąca, dlaczego to program sporządzony np. na Windows NT nie raczy zainstalować się na Windows 2000 i dlaczego instalator stwierdza, że biblioteki są przeterminowane, nakazując w kółko restartować system, bez żadnych pozytywnych skutków zresztą. Chodzi tu o prozaiczną sprawę, a mianowicie biblioteki w rodzaju oleout32 użyte do sporządzenia wersji instalacyjnej są nowsze niż ich odpowiedniki na docelowym systemie, podczas gdy mechanizmy zabezpieczające nie zezwalają na ich podmianę. Dziwne, ale prawdziwe. Można to obejść na różne sposoby, ręcznie poprawiając wpisy w pliku instalacyjnym setup.lst.

Analogiczne zachowania są zresztą udziałem także systemu NT, gdzie podobne wątki z ponadczasowością lubią się zdarzać.

Po przebrnięciu "schodów" z instalacją, okazuje się nieraz, że uruchomienie programu nie zawsze przynosi pozytywny rezultat. Tajemniczy komunikat "klasa nie zarejestrowana" mówi wiele i nic jednocześnie. Nie wiadomo o jaką klasę chodzi i czego ona ma dotyczyć. Można rozczytywać się w dokumentacji Microsoftu jak w najlepszych kryminałach, śledząc, kto jest sprawcą zamieszania - ofiarą pozostaje zawsze użytkownik. Można też próbować coś doinstalowywać, edytować rejestry i wyczyniać różne cuda. Jeżeli i to nie pomoże, to na pewno zainstalowanie pełnego pakietu Visual Basic i jego odinstalowanie niwelują wszelkie dysfunkcje, środowisko wykonywalne zostaje ustabilizowane, a program zaczyna wreszcie działać. O wykonywaniu tego typu sztuczek można by całą rozprawę napisać, ale czy rzeczywiście o to chodzi?

Inną ciekawostką, na którą niedawno się natknąłem, było programowe ustawianie daty w stacjach klienckich, tak aby synchronizowały się z serwerem. Otóż Windows NT przyjmuje datę w formacie m-d-r, zarówno z linii poleceń, jak i z programu, natomiast Windows 2000 w formacie r-m-d. Niby podobnie, ale jednak odwrotnie. No i napisz człowieku program mający działać w obu środowiskach identycznie. Na szczęście (nie wiedzieć jakiemu szczęściu można przypisać ten fakt) Windows NT toleruje ze środowiska programu także datę w postaci r-m-d. No i programista jest uratowany i użytkownik ma, czego chciał.

A zupełnie już nie rozumiem, dlaczego MS SQL Server 2000 Enterprise wersja Evaluation (120-dniowa) wykrywa konflikt typu deadlock, gdy dwie transakcje próbują w tym samym czasie aktualizować ten sam wiersz tabeli. Ktoś, kto chciałby czegoś się nauczyć, dysponując taką wersją serwera, z pewnością wyciągnąłby niezbyt poprawne wnioski.

Na szczęście w pełnych, zalegalizowanych wersjach produktu wszystko jest w normie i jedna transakcja czeka cierpliwie, aż druga się skończy.

Opisane tutaj sprawy nie są wielkie i utrudniają życie tylko garstce osób parających się akurat tymi zagadnieniami. Niemniej uważam, że powinno być prościej, bardziej czytelnie i przede wszystkim jednolicie.