Trzydziestodwubitowa biblioteka w sześćdziesięcioczterobitowym świecie

Trzydziestodwubitowa biblioteka w sześćdziesięcioczterobitowym świecie

  • Comments 5
  • Likes

Im dłużej zajmuję się IT, tym lepiej widzę jak ważne są nawyki, przyzwyczajenia i osobiste "sympatie" technologiczne. Jeżeli tylko sympatie takie są uzasadnione merytorycznymi argumentami, to nie ma w nich nic złego. Zestawione z innymi konkretami dają się łatwo i racjonalnie obronić albo podważyć i są podstawą do owocnych i merytorycznych dyskusji. Takich sympatii są całe masy w każdym obszarze technologii: Dell czy HP, VBS czy PowerShell, Hyper-V czy VMWare itp. Mam oczywiście takie sympatie i ja. Dwie z nich zderzyły się ostatnio ze sobą, ponieważ wcale idealnie do siebie nie pasują. Od razu zdradzam, o jakie sympatie chodzi.

Pierwsza sympatia to ISAPI. Tak naprawdę, to chyba z powodów historycznych. Technologia jest elastyczna, ma ogromne możliwości, pracuje w natywnym kodzie i (co chyba bardzo ważne) potrafię coś w niej na własne potrzeby wystrugać. Oczywiście jestem świadomy wad, które ISAPI nie są obce.

  • Po pierwsze, projekt w tej technologii jest trudny w zarządzaniu. Modna i potrzebna separacja warstwy logiki od warstwy prezentacji jest niemal niewykonalna. W efekcie, zespoły programistyczne muszą składać ze specjalistów od wszystkiego. Ponieważ nie jestem zespołowym programistą a tylko czasem dla siebie coś potrzebuję wystrugać od początku do końca – nie przeszkadza mi ta wada bardzo mocno.
  • Po drugie, sposób działania ISAPI sprawia, że każda zmiana (choćby poprawienie literówki na wyświetlanej stronie), wymaga uprawnień administracyjnych na serwerze IIS. Oznacza to między innymi, że technologia taka jest nieprzyjazna rozwiązaniom hostingowym, gdzie jeden serwer powinien obsługiwać wielu odseparowanych od siebie klientów. I znowu – gdy to ja sam jestem jedynym opiekunem, twórcą i właścicielem rozwiązania, nadmiernie mnie to nie dotyka.

Druga technologiczna sympatia to platforma IA64 i osobiście nakrzyczę na każdego, kto pomyli ją z x64. Po latach rozwoju platformy PC polegającej na poszerzaniu i przyspieszaniu, w latach dziewięćdziesiątych Intel zdecydował się na prawdziwy krok naprzód – Itanium. To samo UEFI, które obecnie posiadaczom Apple każe mówić, że ich sprzęt jest zaawansowany technologicznie, dziesięć lat temu w stacji roboczej z Itanium świetnie pracowało pod kontrolą Windows 2000. Aby zapewnić zgodność wstecz, platforma miała emulować x86, co w mojej opinii było początkiem jej końca. Tak czy inaczej, rewelacyjne rozwiązanie zostało w dużym stopniu zignorowane przez rynek i mimo, że 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 mogę oprzeć się wrażeniu, że już niedługo.

Po tym przydługim wprowadzeniu, pora wrócić do tytułowego zagadnienia. Otóż moje biblioteki ISAPI są trzydziestodwubitowe. Bo taki mam kompilator a rola, jaką te biblioteki pełnią nigdy mnie wystarczająco nie zmotywowała do zdobycia nowych narzędzi i nowej wiedzy. A moje serwery (słabnąca pozycja Itanium spowodowała, że takie systemy stały się osiągalne finansowo dla prywatnych zastosowań) są w pełni sześćdziesięcioczterobitowe. I niby da się, ale diabeł tkwi w szczegółach.

Po pierwsze IIS. Na Windows 2008 R2 dla platformy Itanium, IIS działa świetnie, ale pierwsze podejście kończy się komunikatem o błędzie.

isapi1

Żeby IIS mógł obsłużyć ISAPI, jego proces roboczy (w3wp.exe) musi załadować bibliotekę DLL. W normalnych warunkach, proces roboczy jest sześćdziesięcioczterobitowy (z %windir%\System32\inetsrv\w3wp.exe) i z trzydziestodwubitową DLLką rozmawiać nie będzie. Żeby to umożliwić, w konsoli zarządzającej IIS, we właściwościach puli aplikacji jest specjalne ustawienie

isapi2

Przełączenie go na True sprawia, że IIS może ładować procesy robocze z pliku %windir%\SysWOW64\inetsrv\w3wp.exe, a takie procesy robocze są trzydziestodwubitowe i sięgają bez trudu po starą bibliotekę DLL/ISAPI.

Drugą zasadzką jest współpraca z ODBC. Moje biblioteki używają takiej metody dostępu do danych, ponieważ upraszcza mi to szybkie odseparowanie serwera IIS od serwera SQL. Baza może sobie działać gdziekolwiek i tylko w parametrach ODBC przestawiam wskazanie na nią. Jako, że (tak jak już pisałem) zmiany w ISAPI wymagają dłubania w kodzie i rekompilacji – uznałem w swoich zabawkach, że tak będzie łatwiej. Tak więc, do działania tej konkretnie biblioteki, na serwerze IIS trzeba wybrać z narzędzi administracyjnych "Data Sources (ODBC)" i dodać System DSN. Niby nic niezwykłego tyle, że próba uruchomienia skończyła się komunikatem "The specified DSN contains an architecture mismatch between the Driver and Application ". Zgodnie z tą stroną, rozwiązanie jest proste: usunąć DSN i założyć jeszcze raz, ale używając trzydziestodwubitowej wersji apletu do administracji ODBC – %windir%\sysWOW64\odbcad32.exe

I wreszcie wszystko gra.

Na koniec wyjaśnię jeszcze dwie kwestie:

  1. Temat w równym stopniu dotyczy wersji IA64 jak i x64. Rzecz w tym, że platformę Itanium lubię bardziej i dlatego tutaj użyłem jej jako przykładu. Każdy Windows 2008R2 będzie zachowywał się tak, jak tu opisałem.
  2. Przyznaję się bez bicia, że dotąd nie potknąłem się o problem zgodności bibliotek ISAPI, ponieważ swoje wynalazki uruchamiałem zawsze na systemach w wersji 32bit, czyli na Windows 2008. Świadomie i dobrowolnie rezygnowałem z dobrodziejstw nowej wersji systemu, ponieważ uznałem, że maszyna wirtualna z Windows x86 jest łatwiej przenośna niż x64. Po prostu, w razie awarii sprzętu łatwiej mi w parę chwil znaleźć coś zgodnego z x86 niż x64. I miało to dla mnie na tyle duże znaczenie, że wybrałem tak, a nie inaczej. Od niedawna mam taki komfort również z IA64 i stąd przesiadka.

Autor: Grzegorz Tworek [MVP]

Comments
  • 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.

  • 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 :)

  • >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.

  • Grzegorzu,czy mógłbyś troszkę opisać do czego używasz IA64 i co faktycznie jest w tej wersji "lepszego" niź w x64?

  • 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.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment