Maciek, czy Ty wiesz co piszesz? Jaką wsteczną kompatybilność? Takie rzeczy jak HKEY_CURRENT_USER, %AppData% odpowiedni dobór uprawnień itd. istniały od początku Windows NT, zalecenia co do tworzenia oprogramowania pozostały niezmienione co najmniej od czasów Windows 2000. WINAPI się nie zmieniło, co najwyżej doszły nowe elementy, wszystkie stare funkcje, struktury, stałe są nadal, wszystko działa zgodnie z zapiskami z czasów Windows 95, a czasami nawet wcześniejszych.
.
Wiecie jaki jest powód tego 'braku kompatybilności'? W momencie wejścia XP czy Visty były jaja z softem 'niekompatybilnym' z nowym systemem… oczywiście podobno winni temu są programiści Microsoftu. Prawie cały ten soft był pisany niezgodnie z wytycznymi – programiści sobie 'upraszczali' robotę poprzez olewanie rzeczy, które sprawdzać powinni, nadmiarowe uprawnienia (bo łatwiej walnąć jedną flagę zamiast sumy kilku o niższych wymaganiach), nieprawidłowe argumenty – jest wyraźnie napisane w jakich sytuacjach efekt wywołania funkcji jest niezdefiniowany, ale kto by się przejmował, SoA#1 – u mnie działa. Częsta praktyka to brak programowania defensywnego – 'to się zawsze uda, nie ma po co sprawdzać' – efektem jest efektowny dialog 'Program wykonał nieprawidłową operację' bo wcześniejsza wersja systemu była bardziej pobłażliwa dla nieprawidłowych danych, za które przecież odpowiada programista.
.
Programowanie to taki fajny fach – programować może każdy, wewnętrznej mechaniki programu normalny user nie widzi, widzi jedynie wycacane GUI, dziurawego syfu 'pod maską' nigdy nie zobaczy. Efektem czego jakość softu jest bardzo różna, jak pisałem, wielu autorów idzie po linii najmniejszego oporu i leje na wytyczne, obostrzenia – w końcu większość ludzi pracuje na koncie admina, a jak nie to sobie kliknie w UAC tak z 10 razy. Wprowadzenie UAC wymusiło pisanie w sposób bardziej zgodny z założeniami… Ile razy musiałem poprawiać w całym kodzie flagi bo jakiś kretyn wszędzie wali *_ALL_ACCESS, w miejscu, gdzie minimalne prawa związane z odczytem i ew. współdzieleniem są tylko potrzebne. UAC się drze bo dana akcja wymaga przez to wyższych poświadczeń, które zwykle są zbędne a mogą być niebezpieczne. A jak się UAC nie drze – program może się wywalić, bo komuś kilka literek więcej przeszkadzało, bo przecież on wie lepiej niż Microsoft. Każdy kij ma dwa końce – wśród amatorskich twórców malware'u nie brakuje debili robiących to samo, w efekcie czego trojanwtf odpalony bez uprawnień admina jest bezradny.
.
Windows zachowuje kompatybilność wsteczną, wszystko działa zgodnie z dokumentacją WINAPI starszych wersji i zgodnie ze starymi wytycznymi. Po prostu zawsze znajdą się sytuacje, w których źle napisany kod mimo wszystko się nie wysypie, po tym jak część systemu zostanie przepisana to po prostu wyjdzie. Szczerze? Jeszcze nie spotkałem się z programem, który by nie chodził jedynie na najnowszej wersji Windowsa – jak coś nie chodzi na ViścieSeven to zwykle na koncie użytkownika z ograniczonymi uprawnieniami na XP też się sypie.
.
Podam na koniec taki jeden przykład, dosyć ciekawy moim zdaniem. Jest sobie taki konkurs jak Hacker Challenge, który sam w sobie tyczy się wyłącznie reverse engineeringu. Zadanie w trzecim etapie polegało na analizie pewnej binarki, która m.in. korzystała z nieudokumentowanego zachowania funkcji IsDebuggerPresent, z efektu ubocznego. Co w tym złego? To, że ten efekt uboczny zachodzi tylko w pewnych warunkach i tylko na XP SP2, binarka nie działa poprawnie na Windows 2003, 2000 czy Seven. Co to ma do rzeczy? Ano to, że kompatybilność między wersjami Windows jest zachowana jedynie dla zachowań stricte zgodnych ze specyfikacją, wszystkie nieudokumentowane rzeczy (lub opisane jako zachowania niezdefiniowane) mogą chodzić lub prowadzić do nieprawidłowego zachowania programu. Jeżeli programista popełni błąd lub spróbuje sobie coś uprościć to efekty tego mogą nie być widoczne na wszyskich wersjach systemu, będzie sypać się tylko na niektórych. Tak samo ma się sprawa z Linuksem, bibliotekami standardowymi większości języków programowania itd. Właśnie, żeby się nie rozwodzić – przykład ze znajomego forum dyskusyjnego o zachowaniach niezdefiniowanych w C++, podobne rzeczy chodziaż na nieco innej płaszczyźnie dotyczą interakcji z systemem operacyjnym, opieranie się na tym zwykle kończy się nieciekawie.
.
W sumie jak już przy RE jesteśmy to podam przykład z życia – Immunity Debugger, jedno z popularniejszych narzędzi. Większość rzeczy robię na XP bądź 2003, pracując na koncie zwykłego użytkownika z dodanymi prawami do debugowania. Generalnie zwykły użytkownik XP/2003 jest podobny do tegoż na Viście, czyli brak praw do zapisu w Program Files, HKEY_LOCAL_MACHINE itd. Immunity Debugger radośnie rzuca wyjątkiem przy próbie odpalenia na takiej konfiguracji i idzie w cholerę, dlaczego? Dlatego, że zamiast jak Microsoft przykazał składować konfigurację w kluczach i folderach użytkownika stara się to robić w wyżej wymienionych. Oczywistym rozwiązaniem jest odpalenie programu jako root albo przyznanie konkretnemu userowi praw do konkretnych kluczy i plików…
…bo prawie każdy użytkownik Windows siedzi na adminie… 'programistom' robiącym takie cyrki najchętniej urwałbym jaja – przez ich wygodnictwo i niekompetencję (vide wybiórcze czytanie dokumentacji) oprogramowanie jest niepewne i po aktualizacji systemu lub zredukowaniu poświadczeń może zacząć się sypać, a wszystkiemu winien Microsoft, bo przez przypadek program nie sypał się wcześniej, amen.
.
Dobra, koniec pisania, lubię sobie od czasu do czasu poklnąć na kumpli po fachu, ale już chyba dość.