| www.aresluna.org/attached/terminology/articles/rekonstrukcja | |
|
|
|
|
(Note: This page is available in Polish language only. If you would like it translated to English, please let me know. Sorry for the inconvenience) |
Rekonstrukcja Jak korzystać z obcych, dobrych wzorów? Oto pytanie, jakie stawiają przed czytelnikiem materiały publikowane w tym numerze w dyskotece. Autor testowanego programu, Roland Wacławek (dalej zwany RW), określa “Pelikan” jako “dogłębną adaptację” jednego z czołowych programów do redagowania: MS-Word 3.0. Adaptacji tej RW dokonał bez zgody i wiedzy firmy Microsoft. Testowi towarzyszy swoisty manifest RW, w którym uchyla on rąbka tajemnic warsztatu, uważając swą działalność za nową gałąź sztuki programowania. Propozycja testowania “Pelikana” postawiła nas wobec decyzji: zachować moralną czystość i przemilczeć znaczące na naszym rynku zjawisko, czy też publicznie je przeanalizować, co nieuchronnie wiąże się ze zwróceniem uwagi czytelników na omawiane produkty. Wybraliśmy drugą możliwość. Ostatecznej oceny moralnej dokonają potencjalni nabywcy, kupując i używając ten program lub rezygnując z niego. Zbierzmy teraz argumenty za i przeciw wybranej przez RW (a także Zbigniewa Kasprzyckiego z firmy XOR, autora “Pismaka”, czyli spolszczonej wersji Chiwritera) metodzie postępowania. Przeciw: Jest to handel cudzym dorobkiem z naruszeniem polskiego prawa autorskiego, zakazującego nieautoryzowanych przeróbek cudzych dzieł (polskich i obcych), nawet jeśli autor nie występuje w obronie swych praw. Za: Formalnie RW nie sprzedaje programu MS-Word, lecz osobny program dostosowujący go do potrzeb klienta. Pochodzenie adaptowanej kopii MS-Word jest sprawą etyki użytkownika. Przeciw: RW wie, że żaden z klientów nie ma legalnej kopii MS-Word. Otrzymują oni gotowy, przerobiony program, zawarte zaś w instrukcji pouczenie o konieczności nabycia legalnej kopii MS-Word traktują jako puste słowa. Za: A gdzie ją kupić? RW nie przerabia programów, których polskie wersje oferowane są w Polsce legalnie za złotówki. Dlaczego klient ma płacić za reklamę, koszty sprzedaży i serwisu na obcym rynku? Przeciw: Niech więc kupi program opracowany w kraju i tu sprzedawany. Popierajmy własny przemysł! Za: Po co powtórnie odkrywać Amerykę? Dobre programy pisano w świecie latami i powtarzanie tej pracy w Polsce jest bez sensu. Oryginalność takich opracowań bywa wątpliwa, a jakość, w tym także niezawodność, znacznie ustępuje światowym standardom. Przeciw: Tworzą one jednak narodową bazę oprogramowania podstawowego, co może oszczędzić krajowi wiele dewiz, które inaczej trzeba by z czasem wydać na autoryzowane kopie cudzych programów. Nawet ci konkurenci RW, którzy również naśladują obce wzory, ale zachowując pozory, utrudniają przyszłe restrykcje prawne wobec użytkowników swych wyrobów. Za: Sami przy tym narażają się na przykry proces i miano oszusta i plagiatora. RW poznaje adaptowane programy na tyle dokładnie, że z czasem będzie go stać na prawdziwe “projektowanie od tyłu” (reverse engineering) – tworzenie produktów własnych, nie gorszych od wzorców. Przeciw: Całe to spolszczanie w ogóle nie ma sensu. Łatwiej poznać kilkadziesiąt słów angielskich, które mają przynajmniej w informatyce ustalone znaczenie, niż domyślać się, “co autor miał na myśli” używając pewnych słów rodzimego pochodzenia. Za: O tym, co lepsze, decydują klienci, kupując polskie i spolszczone programy lub rezygnując z nich. Niemcy, Francuzi, a nawet Holendrzy używają wyłącznie narodowych wersji oprogramowania. Angielskie terminy mogą być łatwiejsze dla fachowca, ale nie dla przeciętnego użytkownika (sekretarki). Napisana w Polsce, po polsku i z myślą o problemach polskiego użytkownika instrukcja przydatna jest nawet dla fachowca. Dalsze głosy w tym dialogu z pewnością dopiszą w listach nasi Czytelnicy. O co tu chodzi? Analiza i adaptacja obcej technologii jest dziedziną inżynierską samą w sobie (na Zachodzie wymyślono nawet dla niej nazwę: Reverse engineering). “Łamanie” gier może być zajęciem dla amatorów. Adaptacja oprogramowania profesjonalnego wymaga metod profesjonalnych. Poziom adaptacji tylko pozornie wydaje się sprawą gustu. Manipulacja w kodzie maszynowym programu – bo na tym przecież polega przeróbka – jest sprawą trudną i złożoną. Można przy tym łatwo wprowadzić uszkodzenia i usterki, które albo ujawnią się katastroficznie dopiero po pewnym czasie, po użyciu specyficznej funkcji programu, bądź staną się przyczyną drobnych, ale trudnych do wyjaśnienia i dokuczliwych “wybryków” programu w codziennej pracy. Oceniamy adaptację W ofertach firm uwypuklane są zalety, a problemy ujawniają się dopiero po zakupie. Jak ocenić poziom adaptacji? Cennych danych o technice adaptacji może dostarczyć już łatwy do szybkiego sprawdzenia sposób spolszczenia konwersacji. Oto kilka przykładowych pytań kontrolnych: – Czy polskie komunikaty są naturalne, czy też wyglądają na produkty Madejowego łoża? Wymiana znaków w komunikatach metodą 1:1 jest prymitywnie prosta, ale daje efekty trudne do zaakceptowania dla osób o pewnej wrażliwości językowej. Widać to zwłaszcza w krótkich napisach, złożonych z pojedynczych słów. Jeśli polski odpowiednik jest nie dłuższy niż angielski oryginał, to pół biedy (np. file = plik, error = błąd). W przeciwnym razie – tragedia (np. end, run, key). Aby ten problem rozwiązać, trzeba znacznie więcej wysiłku. Na ogół nie obejdzie się bez przesuwania lub kompresji fragmentów kodu, albo przynajmniej reorganizacji wskaźników (najpierw trzeba je znaleźć!). Niekiedy konieczna jest rekonstrukcja całego bloku programu. – Czy program dopuszcza odpowiedzi: Tak/Nie zamiast np. Yes/No? To dobry sprawdzian, gdyż przeróbka taka jest wprawdzie z reguły dość prosta, ale wymaga już elementarnej znajomości języka maszynowego. Nierozwiązanie tego problemu jest świadectwem haniebnego partactwa. – Wiele programów pozwala wybrać opcję w menu nie tylko przez jej podświetlenie, ale i przez podanie pierwszej litery nazwy, co znakomicie ułatwia obsługę. Jeśli przerobiono tylko napisy w menu nie interesując się mechanizmem wyboru opcji, to wynik może być wysoce irytujący. – Czy program zapewnia operowanie polskimi znakami na ekranie i w wydrukach bez potrzeby przeróbki sprzętu? Jeżeli program pracuje w trybie graficznym, to zwykle zawiera własne wzorce czcionki, które można znaleźć i przerobić. W programach obsługujących ekran w trybie znakowym sprawa jest trudniejsza. Wymiana sprzętowego generatora znaków w komputerze lub drukarce znakomicie ułatwia życie programiście, ale niestety nie użytkownikowi. Można spróbować całkowicie przerobić mechanizmy obsługi ekranu, tak aby program funkcjonował w trybie graficznym. Niestety, większość zaawansowanych aplikacji wpisuje dane wprost do pamięci obrazu. Przeróbka jest wtedy bardzo żmudna i skomplikowana, gdyż konieczne jest nie tylko uchwycenie wszystkich fragmentów programu, w których bezpośredni dostęp do pamięci obrazu ma miejsce (może ich być kilkadziesiąt!), ale i napisania własnych, zastępczych procedur obsługi ekranu. Co więcej, aby program nie działał ślamazarnie, procedury te muszą być starannie optymalizowane pod kątem szybkości pracy. Metodę tę zastosowano m.in. przy spolszczaniu dBase III+ (dBASE POLONUS).
Jeżeli adaptacja dopuszcza stosowanie polskich liter, powinna także umożliwić ich wprowadzanie z klawiatury, np. za pomocą osobnego, rezydującego programu obsługi. W przypadku edytorów tekstów, arkuszy kalkulacyjnych, baz danych itd. dochodzą następne, ważkie pytania: – Czy program sortuje i indeksuje alfabetycznie z uwzględnieniem polskich liter? Pytanie to dotyczy nie tylko baz danych; w większości arkuszy kalkulacyjnych i w wielu edytorach tekstu także występują elementy sortowania (np. przy tworzeniu skorowidza). – Czy spolszczony program potrafi automatycznie zamieniać małe polskie litery na duże i odwrotnie, tak jak czyni to z literami alfabetu angielskiego? Ten pozornie błahy problem jest w istocie ważniejszy niż sortowanie według polskiego alfabetu. Tak np. błędnie działająca funkcja UPPER i LOWER w adaptacji dBase III+ może skutecznie uniemożliwić odnalezienie w bazie danych nazwisk: Łabudek i Bączek (wystarczy napisać: łabudek i BĄCZEK). – Czy program rozpoznaje polskie znaki diakrytyczne jako litery? Czy poprawnie rozpoznaje litery duże i małe? Przykład: funkcje ISALPHA, ISLOWER i ISUPPER w DBase III+. Jak to się robi? Z wyjątkiem operacji najprostszych, jak spolszczenie meldunków, opcji menu i odpowiedzi Tak/Nie, pozostałe wymagają z reguły głębokiej ingerencji w kod programu. Jakimi narzędziami wykonuje się takie przeróbki? Otóż nie jest to tylko prywatna sprawa wykonawcy przeróbek: rodzaj użytego narzędzia istotnie wpływa na jej rzetelność. Na początek generalna zasada: stosowanie do przeróbek dużych programów wyłącznie odpluskwiacza (ang. debugger) lub podobnie prymitywnego narzędzia (PCTOOLS itd.) dyskredytuje wykonawcę, nie dlatego, że jest to “w złym tonie”, ale że przeróbka jest niewiarygodna. Nawet przy przerabianiu samych napisów w tekście metodą 1:1 palec może zbłądzić i zmodyfikować któryś ze wskaźników albo rozkazów. Człowiek jest “urządzeniem” stochastycznym i nie zawsze może utrzymać koncentrację uwagi – zwłaszcza gdy praca jest nużąca i monotonna (a czymże jest przerabianie napisów?). Jakże łatwo jest np. przeoczyć bajt zerowy, oddzielający dwa łańcuchy, i wpisać w jego miejsce spację? Mówimy tu tylko o błędach przypadkowych. Szereg błędów jest wynikiem błogiej niewiedzy. Mój znajomy po przeróbce napisu w pewnym programie bardzo się dziwił, że program przestał funkcjonować. Przyczyna: ogranicznikiem napisu był znak $, jak tego wymaga funkcja usługowa nr 9 MS-DOS. Znajomy sądził, że ogranicznikiem musi być bajt zerowy, i skwapliwie zastąpił “zbędny” symbol $ innym znakiem. Za napisem występowały co prawda bajty zerowe, ale był to zupełny przypadek... Aby móc sprawnie i bez ryzyka “głupich” błędów przerabiać duży program, potrzebne są odpowiednie narzędzia programistyczne, nieraz dość wymyślne. Programy te z grubsza można podzielić na 2 grupy:
Jeśli idzie o programy analityczne, często można posłużyć się gotowymi odpluskwiaczami (AFD, Periscope itd.). Ładujemy SideKick, a następnie np. AFD i śledzimy pracę programu krok po kroku, protokołując i natychmiast opisując rozszyfrowane fazy pracy w SideKicku, wykorzystując jego funkcję importu danych z ekranu i wbudowany edytorek. SideKick pozwala na bieżącą korektę notatek, co jest o tyle cenne, że pierwsza analiza rzadko jest w pełni trafna – po zbadaniu kolejnych partii programu wyniki trzeba zweryfikować. W praktyce analiza programu zazwyczaj odbywa się równolegle na dwóch komputerach, z których jeden często bywa “dozbrajany” w sprzęt wspomagający śledzenie pracy programu maszynowego. Twórcy wielu programów zadali sobie jednak sporo trudu, aby obrzydzić życie włamywaczom, używającym klasycznych odpluskwiaczy. Program taki prowadzi dynamiczne zmiany wektorów przerwań używanych przez odpluskwiacz, nr 2 i 3, kontroluje wektor przerwań klawiatury (INT 9), co i raz wykonuje ekwilibrystyczne skoki z modyfikacją rejestrów segmentowych – wszystko po to, aby “oślepić” odpluskwiacz. Wtedy trzeba sięgać po oprogramowanie specjalne, często tworzone do jednorazowego użytku.
Oprogramowanie do modyfikacji kodu najczęściej jest pisane dla spolszczania jednego, określonego programu. W programach graficznych jednym z głównych zadań jest ewentualna przeróbka wzorców czcionek, do której trzeba sporządzić stosowny edytor. Pół biedy, jeżeli wzorce czcionek są zapisane w modułach o stałych rozmiarach, np. po 8, 12 lub 14 bajtów na znak. W bardziej zaawansowanych programach występuje jednak pismo proporcjonalne, w dodatku o różnych rozmiarach i dość wymyślnie zakodowanych wzorcach. Nie zawsze są to wzorce matrycowe – trafiają się też i wektorowe. Za przykład niech posłuży spolszczanie systemu WINDOWS z programem PageMaker. W sumie trzeba było zmodyfikować ok. 110 kompletnych zbiorów wzorców czcionki różnych krojów i rozmiarów – w każdym po 18 znaków. Większość to kroje proporcjonalne, część – wektorowe. Napisany specjalnie do tego celu edytor liczy ok. 3500 wierszy programu pascalowego. Wyższa szkoła jazdy Najtrudniejsze są modyfikacje kodu programu. Większość modyfikacji w kodzie programu prowadzi do wzrostu jego złożoności. Skąd wziąć miejsce na dodatkowe rozkazy? Jeżeli miejsca nie trzeba zbyt wiele, a program był kompilowany z języka wysokiego poziomu, drogą starannej optymalizacji kodu udaje się przeważnie wygospodarować potrzebne kilka do kilkudziesięciu bajtów, co wystarcza tylko na drobne poprawki. Jeżeli trzeba dołączyć procedury o większych rozmiarach, konieczne jest zgrupowanie tych procedur w osobnym pliku, ładowanym do pamięci przed uruchomieniem programu zasadniczego. Najprostsza i dość efektywna metoda zapewniania łączności programu z procedurami dodatkowymi polega na wykorzystaniu zbywających wektorów przerwań programowych. Twórcy niektórych programów byli tak uprzejmi, że wydzielili fragmenty istotne z punktu widzenia dialogu z użytkownikiem w osobne pliki. W idealnym przypadku teksty występują tam wraz z tablicami wskaźników lub są zorganizowane jako lista. Wtedy można pokusić się o skompilowanie tego fragmentu programu od nowa, co jest rozwiązaniem najpewniejszym i najwygodniejszym, gdyż nie nakłada ograniczeń na rozmiar meldunków. Przedtem trzeba jednak “rozgryźć” dokładnie strukturę danych w takim pliku i zmajstrować odpowiedni kompilator... Większość programistów nie myśli niestety o biednych włamywaczach i wkomponowuje meldunki wprost w kod programu. Na szczęście meldunki te tworzą często zwarty blok (bloki) o dającej się rozpoznać strukturze, co pozwala zastosować metodę rekompilacji. Tym razem jednak objętość bloku jest limitowana. Jak poradzić sobie ze wzrostem objętości meldunków? Metoda najprostsza polega na skróceniu meldunków mało istotnych i występujących sporadycznie i oddaniu wygospodarowanej pamięci meldunkom częstym i ważnym. W praktyce często okazuje się, że wiele meldunków w programie jest prawie lub całkowicie identycznych. Można wtedy pozostawić w nim tylko jedną kopię takiego meldunku, a wskaźnik do niego wpisać zamiast wskaźników meldunków podobnych. Przed takim manewrem trzeba jednak rozpoznać, czy wszystkie meldunki należą do jednego segmentu, gdyż w przeciwnym razie...
Dodatkowym, choć nie całkiem oczywistym urokiem modyfikacji meldunków i menu jest konieczność wymyślania sensownych odpowiedników dla specyficznych terminów angielskich. Jak np. zwięźle nazwać po polsku clipboard, croptool lub kerning? Autorowi spolszczenia programów nowej generacji przypada rola pioniera terminologii oraz pewność, że cokolwiek wymyśli, dostarczy innym jakże lubej pożywki do krytyki. Przerabianie meldunków byłoby mimo wszystko miłym zajęciem, gdyby nie fakt, iż czasem są one skomprymowane – często powtarzające się frazy, albo nawet sylaby, są reprezentowane w meldunkach przez jedno- lub dwubajtowe kody. Wtedy najpierw należy rozpoznać i przekonstruować słownik fraz, a dopiero potem przystąpić do rekonstrukcji samych meldunków. Bez odpowiednich narzędzi do edycji i rekompilacji nie da się tutaj wiele wskórać.
Jak widać, porządna adaptacja programu wymaga zarówno odpowiedniego uzbrojenia technicznego, jak i – a może przede wszystkim – know-how. Aby biegle odczytywać kod maszynowy, trzeba mieć solidną praktykę w samodzielnym pisaniu programów asemblerowych, aby umieć na podstawie skompilowanego kodu programu w C lub Pascalu rozszyfrować sens poszczególnych procedur i zarys struktury danego fragmentu programu w języku źródłowym, oprócz wyobraźni potrzebna jest wprawa w pisaniu programów w tych językach, a przede wszystkim – znajomość stosowanych algorytmów i metod programowania. Przydaje się też wiedza o samych kompilatorach, zwłaszcza zaś o generacji kodu. Powierzchownej adaptacji napisów może przy odrobinie szczęścia podjąć się nawet partacz. Natomiast gruntowna i konsekwentna adaptacja programu to mordercza harówka, o wielkim stopniu trudności. Jako ilustracja pracochłonności głębokiej adaptacji programu niech posłuży MS-WORD – PELIKAN. Prace nad nim trwały prawie 8 miesięcy, z czego 3 poświęcono na analizę kodu, ponad 2 – na stworzenie oprogramowania modyfikującego, sama przeróbka trwała 3 tygodnie, resztę czasu poświęcono na testowanie i poprawki. W fazie analitycznej sporządzono bogato skomentowane zapisy programu, będące wynikiem analizy programu maszynowego i programu w języku maszyny wirtualnej, o łącznej objętości prawie 400 KB (w wersji ostatecznej – korekt nikt nie zliczy). Ogólna objętość oprogramowania do analizy i modyfikacji kodu przekroczyła objętość samego oryginału WORD 3.0 (fakt faktem, nikt nie troszczył się o optymalność tego oprogramowania). Źródło: “Komputer,” popularny miesięcznik informatyczny, nr 2/89 (35), str. 29-31 |
Page added on 1st April 2003. |
|
