Trzydziestodwubitowa biblioteka w sześćdziesięcioczterobitowym świecie
Im dluzej zajmuje sie IT, tym lepiej widze jak wazne sa nawyki, przyzwyczajenia i osobiste "sympatie" technologiczne. Jezeli tylko sympatie takie sa uzasadnione merytorycznymi argumentami, to nie ma w nich nic zlego. Zestawione z innymi konkretami daja sie latwo i racjonalnie obronic albo podwazyc i sa podstawa do owocnych i merytorycznych dyskusji. Takich sympatii sa cale masy w kazdym obszarze technologii: Dell czy HP, VBS czy PowerShell, Hyper-V czy VMWare itp. Mam oczywiscie takie sympatie i ja. Dwie z nich zderzyly sie ostatnio ze soba, poniewaz wcale idealnie do siebie nie pasuja. Od razu zdradzam, o jakie sympatie chodzi.
Pierwsza sympatia to ISAPI. Tak naprawde, to chyba z powodów historycznych. Technologia jest elastyczna, ma ogromne mozliwosci, pracuje w natywnym kodzie i (co chyba bardzo wazne) potrafie cos w niej na wlasne potrzeby wystrugac. Oczywiscie jestem swiadomy wad, które ISAPI nie sa obce.
- Po pierwsze, projekt w tej technologii jest trudny w zarzadzaniu. Modna i potrzebna separacja warstwy logiki od warstwy prezentacji jest niemal niewykonalna. W efekcie, zespoly programistyczne musza skladac ze specjalistów od wszystkiego. Poniewaz nie jestem zespolowym programista a tylko czasem dla siebie cos potrzebuje wystrugac od poczatku do konca – nie przeszkadza mi ta wada bardzo mocno.
- Po drugie, sposób dzialania ISAPI sprawia, ze kazda zmiana (chocby poprawienie literówki na wyswietlanej stronie), wymaga uprawnien administracyjnych na serwerze IIS. Oznacza to miedzy innymi, ze technologia taka jest nieprzyjazna rozwiazaniom hostingowym, gdzie jeden serwer powinien obslugiwac wielu odseparowanych od siebie klientów. I znowu – gdy to ja sam jestem jedynym opiekunem, twórca i wlascicielem rozwiazania, nadmiernie mnie to nie dotyka.
Druga technologiczna sympatia to platforma IA64 i osobiscie nakrzycze na kazdego, kto pomyli ja z x64. Po latach rozwoju platformy PC polegajacej na poszerzaniu i przyspieszaniu, w latach dziewiecdziesiatych Intel zdecydowal sie na prawdziwy krok naprzód – Itanium. To samo UEFI, które obecnie posiadaczom Apple kaze mówic, ze ich sprzet jest zaawansowany technologicznie, dziesiec lat temu w stacji roboczej z Itanium swietnie pracowalo pod kontrola Windows 2000. Aby zapewnic zgodnosc wstecz, platforma miala emulowac x86, co w mojej opinii bylo poczatkiem jej konca. Tak czy inaczej, rewelacyjne rozwiazanie zostalo w duzym stopniu zignorowane przez rynek i mimo, ze nadal spotykane, to stopniowo jest "wyprzedzane" przez pecetowate serwery z procesorami x64. Niby IA64 nadal jest wspierana przez Windows Server czy SQL Server, ale niestety nie moge oprzec sie wrazeniu, ze juz niedlugo.
Po tym przydlugim wprowadzeniu, pora wrócic do tytulowego zagadnienia. Otóz moje biblioteki ISAPI sa trzydziestodwubitowe. Bo taki mam kompilator a rola, jaka te biblioteki pelnia nigdy mnie wystarczajaco nie zmotywowala do zdobycia nowych narzedzi i nowej wiedzy. A moje serwery (slabnaca pozycja Itanium spowodowala, ze takie systemy staly sie osiagalne finansowo dla prywatnych zastosowan) sa w pelni szescdziesiecioczterobitowe. I niby da sie, ale diabel tkwi w szczególach.
Po pierwsze IIS. Na Windows 2008 R2 dla platformy Itanium, IIS dziala swietnie, ale pierwsze podejscie konczy sie komunikatem o bledzie.
Zeby IIS mógl obsluzyc ISAPI, jego proces roboczy (w3wp.exe) musi zaladowac biblioteke DLL. W normalnych warunkach, proces roboczy jest szescdziesiecioczterobitowy (z %windir%\System32\inetsrv\w3wp.exe) i z trzydziestodwubitowa DLLka rozmawiac nie bedzie. Zeby to umozliwic, w konsoli zarzadzajacej IIS, we wlasciwosciach puli aplikacji jest specjalne ustawienie
Przelaczenie go na True sprawia, ze IIS moze ladowac procesy robocze z pliku %windir%\SysWOW64\inetsrv\w3wp.exe, a takie procesy robocze sa trzydziestodwubitowe i siegaja bez trudu po stara biblioteke DLL/ISAPI.
Druga zasadzka jest wspólpraca z ODBC. Moje biblioteki uzywaja takiej metody dostepu do danych, poniewaz upraszcza mi to szybkie odseparowanie serwera IIS od serwera SQL. Baza moze sobie dzialac gdziekolwiek i tylko w parametrach ODBC przestawiam wskazanie na nia. Jako, ze (tak jak juz pisalem) zmiany w ISAPI wymagaja dlubania w kodzie i rekompilacji – uznalem w swoich zabawkach, ze tak bedzie latwiej. Tak wiec, do dzialania tej konkretnie biblioteki, na serwerze IIS trzeba wybrac z narzedzi administracyjnych "Data Sources (ODBC)" i dodac System DSN. Niby nic niezwyklego tyle, ze próba uruchomienia skonczyla sie komunikatem "The specified DSN contains an architecture mismatch between the Driver and Application ". Zgodnie z ta strona, rozwiazanie jest proste: usunac DSN i zalozyc jeszcze raz, ale uzywajac trzydziestodwubitowej wersji apletu do administracji ODBC – %windir%\sysWOW64\odbcad32.exe
I wreszcie wszystko gra.
Na koniec wyjasnie jeszcze dwie kwestie:
- Temat w równym stopniu dotyczy wersji IA64 jak i x64. Rzecz w tym, ze platforme Itanium lubie bardziej i dlatego tutaj uzylem jej jako przykladu. Kazdy Windows 2008R2 bedzie zachowywal sie tak, jak tu opisalem.
- Przyznaje sie bez bicia, ze dotad nie potknalem sie o problem zgodnosci bibliotek ISAPI, poniewaz swoje wynalazki uruchamialem zawsze na systemach w wersji 32bit, czyli na Windows 2008. Swiadomie i dobrowolnie rezygnowalem z dobrodziejstw nowej wersji systemu, poniewaz uznalem, ze maszyna wirtualna z Windows x86 jest latwiej przenosna niz x64. Po prostu, w razie awarii sprzetu latwiej mi w pare chwil znalezc cos zgodnego z x86 niz x64. I mialo to dla mnie na tyle duze znaczenie, ze wybralem tak, a nie inaczej. Od niedawna mam taki komfort równiez z IA64 i stad przesiadka.
Autor: Grzegorz Tworek [MVP]
Comments
Anonymous
January 01, 2003
Nie przyznam się tutaj, bo to nie-microsoftowe i nie wypada ;))) A co do wyboru technologii.... kiedyś zarabiałem na życie programowaniem i wtedy miał sens jakiś rozwój w tym kierunku. Potem zmieniłem profil i jeżeli chodzi o "developerkę", to zostałem na poziomie sprzed wielu lat. Po prostu (w mojej subiektywnej opinii) moje inwestowanie w siebie ma większy sens w innych działkach i dlatego ta zaniedbana leży od lat. Trudno. Nie da się wszystkiego na raz :)Anonymous
January 01, 2003
Lepszego...? Pomysł, idea, architektura. W teorii wszystko. W praktyce nic, bo na tę platformę praktycznie już nic nikt nie tworzy i zwykłe x64 jest szybsze, tańsze i lepiej znane. Używam do czego tylko się da ;) Windows działa, IIS działa, SQL działa a resztę sobie jakośtam wyrzeźbię ;) Najbardziej brakuje mi wirtualizacji, bo maszyny IA64 są zwykle na tyle potężne, że pewnie łatwo uniosłyby kilka wirtualek.Anonymous
August 16, 2011
Widze, ze nie tylko ja lubie hardcore'owe rozwiazania :) Przyznaje, ze jednak juz wiele lat temu rozstalem sie z ISAPI i ODBC, podobnie jak z RPC, etc. - po prostu .NET wieele upraszcza... Odnosnie kompilatora - z czego korzystasz? m.Anonymous
August 17, 2011
>kiedyś zarabiałem na życie programowaniem No cóż, można to było wyczuć: tu jakiś programik, tam narządko... Co potwierdza tylko moją teorię, że do głębszej znajomości internalsów bez podstaw dev nie da rady :) m.Anonymous
August 24, 2011
Grzegorzu,czy mógłbyś troszkę opisać do czego używasz IA64 i co faktycznie jest w tej wersji "lepszego" niź w x64?