Projekt VBA

Projekt VBA to zbiór modułów, formularzy i kodu makr powiązanych z jednym dokumentem lub szablonem.

Architektura i zasady osadzania środowiska programistycznego w strukturach plików binarnego i otwartego standardu

Projekt VBA stanowi autonomiczne, wewnętrzne środowisko uruchomieniowe implementowane bezpośrednio w obrębie kontenera pliku nadrzędnego, pełniącego funkcję hosta (np. arkusza kalkulacyjnego, dokumentu tekstowego lub bazy danych). Architektura przechowywania tego środowiska różni się w zależności od generacji formatu zapisu. W historycznych formatach binarnych, bazujących na architekturze OLE Compound File (rozpoznawalnych po rozszerzeniach takich jak .xls lub .doc), projekt osadzony był jako złożony zbiór hierarchicznych strumieni danych zorganizowanych w wewnętrznym systemie FAT pliku. Wraz z implementacją standardu Office Open XML (OOXML), reprezentowanego przez pliki z przyrostkiem "m" (np. .xlsm, .docm) lub pliki binarne nowej generacji (.xlsb), model przechowywania uległ przebudowie. Plik dokumentu to skompresowane archiwum ZIP, wewnątrz którego cały projekt VBA hermetyzuje się jako pojedynczy strumień binarny, najczęściej zlokalizowany w ścieżce wewnętrznej pod nazwą xl/vbaProject.bin (lub odpowiednio word/vbaProject.bin w edytorze tekstu). Wewnętrzna struktura tego wyodrębnionego pliku jest restrykcyjnie zdefiniowana przez dokumentację techniczną MS-OVBA. Obejmuje ona strumienie informacji o projekcie, strumienie odniesień do zewnętrznych bibliotek (References) oraz strumienie poszczególnych modułów. Wewnątrz środowiska obiekty dzieli się na klasy podstawowe. Moduły standardowe przechowują publiczne procedury i funkcje o zasięgu globalnym. Moduły klas odpowiadają za definiowanie niestandardowych obiektów z własnymi właściwościami i zdarzeniami. Formularze (UserForms) przechowują definicje interfejsu graficznego, a moduły obiektowe są trwale przypisane do konkretnych elementów modelu DOM aplikacji hostującej (np. klasa ThisWorkbook powiązana ze zdarzeniami samego skoroszytu).

Analiza strumieni binarnych i mechanika wykonywania skompilowanego kodu pośredniego

Specyfikacja MS-OVBA narzuca równoległe przechowywanie dwóch postaci instrukcji w strumieniach modułów. Pierwszą formą jest tekstowy kod źródłowy wprowadzany przez inżyniera, skompresowany za pomocą własnościowego algorytmu bazującego na LZ77. Drugą formą jest tak zwany p-code (pseudo-code), czyli zoptymalizowana, pośrednia reprezentacja binarna. Kompilacja do p-code następuje automatycznie w tle podczas zapisu pliku lub przy pierwszej próbie wykonania procedury. Maszyna wirtualna Visual Basic Environment, implementowana obecnie najczęściej poprzez bibliotekę dynamiczną VBE7.DLL, interpretuje i wykonuje wyłącznie p-code, ignorując skompresowany tekst źródłowy do momentu otwarcia edytora. Taki mechanizm przyspiesza inicjalizację, lecz wiąże skompilowany stan z konkretną wersją silnika, dokładną architekturą procesora oraz metadanymi aplikacji. Wykonywanie kodu odbywa się w modelu asynchronicznym, jednakże całkowicie jednowątkowym. Działająca pętla obliczeniowa blokuje główny wątek interfejsu użytkownika aplikacji hostującej do momentu zakończenia procedury lub wywołania funkcji systemowej zwalniającej zasoby (DoEvents). Ponadto silnik integracji intensywnie korzysta z interfejsu COM (Component Object Model) do manipulacji obiektami oraz pozwala na komunikację z zewnętrznymi bibliotekami C/C++ poprzez instrukcje zadeklarowane na poziomie systemu operacyjnego. Zmiana architektury pakietów biurowych z 32-bitowej na 64-bitową wymusiła modyfikację wskaźników pamięci. Bez implementacji instrukcji PtrSafe i typu danych LongPtr w wywołaniach Windows API, próba alokacji pamięci na 64-bitowym jądrze skutkuje natychmiastowym błędem wskaźnika i wyłączeniem procesu.

Anomalie w strukturze strumieni, błędy desynchronizacji i systemowe blokady bezpieczeństwa

W złożonych strukturach systematycznie dochodzi do zjawiska desynchronizacji pomiędzy skompresowanym kodem źródłowym a zbuforowanym stanem p-code. Powstaje wówczas błąd integralności pamięci w obrębie strumienia DirStream, co w środowisku produkcyjnym objawia się zamykaniem procesu aplikacji hostującej bez generowania logów diagnostycznych, utratą przypisań przycisków lub niemożnością otwarcia edytora. Naprawa takiej struktury wymaga ręcznego usunięcia uszkodzonych strumieni binarnych ze struktury vbaProject.bin przy pomocy edytorów szesnastkowych, wymuszając na maszynie wirtualnej ponowną dekompresję i rekompilację kodu ze źródła. Niezależnym aspektem technicznym są mechanizmy izolacji nakładane przez system operacyjny. W architekturze NTFS pliki pobrane ze źródeł zewnętrznych otrzymują alternatywny strumień danych określany jako Zone.Identifier (tzw. Mark of the Web). Silnik weryfikujący pakietu biurowego odczytuje te metadane i prewencyjnie blokuje proces wczytywania biblioteki VBE w pamięci RAM. Wykonanie jakiejkolwiek procedury zostaje zatrzymane na poziomie jądra aplikacji, niezależnie od lokalnych uprawnień w centrum zaufania, dopóki administrator nie zmodyfikuje atrybutów strumienia pliku z poziomu właściwości systemu. Problem stanowi również wrażliwość archiwum ZIP formatu OOXML na uszkodzenia nagłówków (Local File Headers). Modyfikacja pojedynczych bitów w strukturze kompresji sprawia, że parser XML odzyskuje surowe dane arkusza, lecz uznaje plik vbaProject.bin za uszkodzony, co skutkuje jego trwałym wycięciem z pliku podczas próby automatycznej naprawy dokumentu.

Procedury odzyskiwania danych w przypadku sprzętowej awarii nośnika macierzystego

Tworzenie, refaktoryzacja, debugowanie logiki i poprawianie błędów składniowych w kodzie VBA stanowi domenę inżynierii oprogramowania. Z tego powodu optymalizacja algorytmów czy aktualizacja deklaracji API wykracza całkowicie poza kompetencje usług sprzętowych. Współcześnie awarie systemów opartych wyłącznie na archaicznych implementacjach VBA i dedykowanym do nich starym sprzęcie są zjawiskiem rzadkim w kontekście diagnostyki warsztatowej. Interwencja serwisowa staje się konieczna, gdy warstwa sprzętowa, na której przetrzymywane są krytyczne dla przedsiębiorstwa pliki binarne (.xlsm, .docm), ulega fizycznemu zniszczeniu. W przypadku awarii silnika wrzeciona w dyskach HDD, mechanicznych uszkodzeń głowic czytających, degradacji komórek NAND lub awarii kontrolera pamięci flash w dyskach SSD, struktura plików staje się niedostępna dla systemu operacyjnego. W takich sytuacjach Warszawskie Pogotowie Komputerowe realizuje odzysk danych na poziomie sprzętowym. Proces ten wymaga pracy w komorach laminarnych, transferu modułów pamięci do sprzętowych narzędzi diagnostycznych (PC-3000) oraz budowy wirtualnego translatora omijającego zdegradowane bloki pamięci, co umożliwia niskopoziomowe sklonowanie sektorów dysku w trybie bit po bicie. W przypadku laptopów, w których płyta główna i wlutowany nośnik uległy zalaniu cieczą, stosuje się mikrolutowanie w celu odbudowy torów zasilania, pozwalające uruchomić układ na czas odczytu struktury logicznej. Skuteczne odtworzenie struktury blokowej nośnika daje możliwość wyekstrahowania nieuszkodzonych archiwów ZIP zawierających pliki projektów. Dalsza analiza spójności wyodrębnionego w ten sposób kodu źródłowego pozostaje w gestii specjalistów od oprogramowania.