Projektując obiektowe pośrednictwo tekstowe dla systemu MS-DOS, zdawano sobie sprawę że rynek pośrednictw użytkowych jest bardzo nasycony. Funkcjonalność niektórych rozwiązań dedykowanych stricte systemowi MS-DOS jest bardzo wysoka. Pojawienie się systemu WINDOWS 95, a wraz z nim systemu MS-DOS 7.0 zmieniło diametralnie sytuację.
Obserwując pracę pośrednictw użytkowych, zauważono że prawie wszystkie pośrednictwa użytkowe w bardzo podobny sposób wywołują procesy potomne. Pośrednictwo jest zazwyczaj skonstruowane przy pomocy dwóch procesów. Pierwszy, niewielki proces, zwany częścią rezydentną lub częścią uruchamiającą, przez cały czas pracy pośrednictwa znajduje się w pamięci operacyjnej komputera. Ciało drugiego procesu, o znacznie większych rozmiarach jest w razie potrzeby odczytywane z dysku. Część rezydentna, przemienne uruchamia standardowy interpreter poleceń COMMAND.COM oraz usługową, obszerną część pośrednictwa. Ten niewielki proces liczący od kilku do kilkunastu kilobajtów jest odpowiedzialny za wywoływanie poleceń spoza pośrednictwa. Przygotowuje on kolejną kopię interpretera poleceń COMMAND.COM w pamięci operacyjnej i uruchamia przy jego pomocy polecenie.
Przykładowy obraz pamięci wykonany poleceniem mem /c z poziomu pośrednictwa tekstowego, programu "Norton Commander" wygląda tak.
MSDOS 16 752 (16K) 16 752 (16K)
DISPLAY 18 064 (18K) 18 064 (18K)
HIMEM 1 120 (1K) 1 120 (1K)
IFSHLP 2 864 (3K) 2 864 (3K)
SETVER 704 (1K) 704 (1K)
WIN 3 568 (3K) 3 568 (3K)
vmm32 960 (1K) 960 (1K)
KEYBPL 1 088 (1K) 1 088 (1K)
COMMAND 10 240 (10K) 10 240 (10K)
NC 5 792 (6K) 5 792 (6K)
COMMAND 7 216 (7K) 7 216 (7K)
Free 582 704 (569K) 582 704 (569K)
Jak widać program "Norton Commander" widoczny jako proces NC w pamięci komputera, zajmuje 6KB. Tymczasem proces odpowiedzialny za komunikację z użytkownikiem zajmuje około 230KB i jest on w razie konieczności odczytywany z dysku.
Nastąpiło powielenie interpretera poleceń. Proces on nazwie COMMAND pojawia się dwukrotnie na liście. Tak więc, różnica pomiędzy wywołaniem polecenia mem /c z poziomu pośrednictwa COMMAND.COM, a wywołaniem polecenia mem /c z poziomu pośrednictwa "Norton Commander" to różnica 13KB.
Jest jeszcze jedna, bardzo subtelna różnica. Korzystając z tego sposobu, nie ma możliwości zmiany zmiennych środowiskowych macierzystego procesu COMMAND. Powodem takiego zachowania jest fakt, że nawet polecenia wewnętrzne interpretera poleceń są realizowane przez jego kopię. Aby zmienić zmienne środowiskowe (procesowi macierzystemu pośrednictwa) należy pośrednictwo opuścić. W wersji 5.0 programu "Norton Commander" dodano program, pozwalający opuścić pośrednictwo. Program nazywa się nc_exit.com. Może być pomocy w sytuacji, gdy chcemy uruchomić np. system WINDOWS przy pomocy pośrednictwa, bez obciążania pamięci operacyjnej dodatkową kopią programu COMMAND.COM oraz NC.COM.
W trakcie pracy z pośrednictwem Dos Navigator II, można zmieniać zmienne środowiskowe bez uciekania się do tego typu sztuczek. Obraz pamięci i aktywnych procesów wygląda bardzo podobnie, część rezydentna programu Dos Navigator jest o wiele mniejsza, jednak sposób realizacji pozostał niejasny.
Projektując pośrednictwo użytkowe, należało zaprojektować część uruchamiającą tak, aby zewnętrzny proces miał do dyspozycji jak najwięcej wolnej pamięci operacyjnej. Rozwiązania polegające na pozostawieniu całego programu w pamięci operacyjnej nie były brane pod uwagę. Postanowiono rozbić program na dwie części. Część odpowiedzialną za uruchamianie procesów i część odpowiedzialną za komunikację z użytkownikiem. Część odpowiedzialna za komunikację z użytkownikiem w razie potrzeby powinna być usuwana z pamięci operacyjnej.
Pomimo że dysponowano gotowym przykładem, starano się szukać rozwiązań optymalnych. Pierwszym, bardzo prostym projektem części uruchamiającej, było stworzenie zbioru wsadowego o nazwie test.bat, następującej treści:
:work
copy con: plik.bat
call plik.bat
goto work
Bardzo prosta w swej idei konstrukcja działała w następujący sposób. Po uruchomieniu tego zbioru wsadowego należało wprowadzać polecenia kończąc je sekwencja klawiszy F6 i Enter. Przykładowy widok ekranu komputera po wydaniu polecenia test był taki:
C:\usr\TEST>test
C:\usr\TEST>copy con: plik.bat
dir^Z
1 file(s) copied
C:\usr\TEST>call plik.bat
C:\usr\TEST>dir
Volume in drive C is HARD DISK
Volume Serial Number is 1D81-9BBA
Directory of C:\usr\TEST
. <DIR> 95.09.04 0:59 .
.. <DIR> 95.09.04 0:59 ..
TEST BAT 51 95.09.04 1:00 TEST.BAT
PLIK BAT 3 95.09.04 1:03 plik.bat
2 file(s) 54 bytes
2 dir(s) 12 144 640 bytes free
C:\usr\TEST>goto work
C:\usr\TEST>copy con: plik.bat
Ten sposób, rzecz jasna, rozwinięty i udoskonalony został zastosowany w projekcie pośrednictwa użytkowego. Należało jeszcze rozwiązać pozostałą grupę problemów związanych z przygotowaniem środowiska i zmianą aktualnego katalogu roboczego procesu wywołującego.
Analizując funkcjonalność dostępnych rozwiązań interfejsu użytkownika, zdecydowano się na wizualizację struktury zbiorów i dostępnych akcji w postaci dwóch paneli, obszaru poleceń oraz belki narzędziowej. Przez akcję będziemy rozumieć metodę operującą na strukturze plików i katalogów systemu MS-DOS.
Ilustracja 4.1 Przykładowa struktura drzewa plików i katalogów
Rozważano zasadność użycia gotowych bibliotek obiektowych do konstrukcji interfejsu użytkownika. Analizowano czas jaki powinno się poświęcić na naukę posługiwania się konkretną biblioteką, łatwość modyfikacji oraz efektywność kodu generowanego przez konkretne rozwiązanie.
Brano pod uwagę obiektową bibliotekę "Turbo Vision" firmy Borland, dostępną w systemie programowym "Turbo Pascal" 6.0 lub 7.0, rozważano też możliwość użycia jej odpowiednika dla języka C++, o nazwie "Application Framework". Zarzucono oba te pomysły. Powodów było wiele. Jednym z głównych powodów był brak kodu źródłowego wymienionych bibliotek. Rzecz jasna - biblioteki te są zbiorem funkcjonalnie pełnym i każdy program jest możliwy do stworzenia przy ich pomocy, jednak czas przeznaczony na wzbogacenie i modyfikację istniejących w bibliotece obiektów był nie do przyjęcia. Drugim powodem dla którego nie można było zastosować powyższych bibliotek, był fakt że wykorzystanie obiektów z powyższych bibliotek wiązało się z bardzo dużym narzutem pamięci. Jako przykład można przytoczyć program inicjujący zaledwie środowisko pracy dla biblioteki obiektowej napisany w języku "Turbo Pascal" 6.0.
program Tvprzykład;
uses App,Drivers,Menus,Objects,Views;
type użytkowy_typ_obiektowy = object ( TApplication )
end;
var obiekt : użytkowy_typ_obiektowy;
begin
obiekt.Init;
obiekt.Run;
obiekt.Done;
end.
Przykład zaczerpnięto z książki [1].
Po skompilowaniu powyższego programu okazało się że kod wynikowy programu wynosi około 70KB. Fakt ten ma niebagatelne znaczenie dla szybkości pracy, gdyż pośrednictwo na czas wykonywania zewnętrznych poleceń powinno usunąć się z pamięci operacyjnej komputera. Przypomnieć należy, że szybkość pracy pośrednictwa była jednym z założeń projektowych programu.
Faktem przemawiającym za zastosowaniem tej biblioteki jest jej spójność i przemyślana konstrukcja wewnętrzna. Napisanie prostego programu z wykorzystaniem tej biblioteki zajmuje niewiele czasu. Problem pojawia się, jeśli zachodzi potrzeba wyjścia poza możliwości oferowane przez tą bibliotekę.
Czas przeznaczony na dogłębne studiowanie zasad pracy i możliwości modyfikacji postanowiono przeznaczyć na stworzenie własnego rozwiązania konstrukcyjnego. Prace nad własnym rozwiązanie rozpoczęto od przyjrzenia się innym podobnym rozwiązaniom. Przeglądano zbiory oprogramowania typu Shareware (dostępne na dyskach CD-ROM i w sieci internet). Należy stwierdzić że czas przeznaczony na poszukiwanie okazał się owocny. Nie znaleziono gotowego rozwiązania, ale odkryto szereg przesłanek pozwalających wykonać w skończonym okresie czasu pośrednictwo użytkowe. Początkowe prace prowadzono wykorzystując podejście strukturalne. Zdobyte informacje, dotyczące zasad pisania programów w języku C++, skierowały pracę na tory obiektowe. Postanowiono stworzyć własną bibliotekę obiektową. Obiektowe podejście systematyzuje i porządkuje prace nad programem. Modułowa konstrukcja programu pozwala na szybką identyfikację błędów i ich usuwanie, co ma niebagatelny wpływ na czas ukończenia pracy. Wykorzystywano większość możliwości oferowanych przez język C++. Zdecydowano się na wykorzystanie gotowej biblioteki obiektowej zapewniającej korzystanie ze strumieni we/wy. Próba zastosowania obiektowej biblioteki kontenerów zakończyła się fiaskiem. Po dołączeniu statycznej biblioteki kontenerów, dostarczonej przez producenta kompilatora, do programu w C++ program wynikowy urósł o 70KB. Postanowiono stworzyć własną klasę zachowującą część potrzebnych własności kontenerów.
Projektując wewnętrzną konstrukcję programu założono że obiekty odpowiedzialne za komunikację programu z użytkownikiem będą oddzielone od obiektów odpowiedzialnych za komunikację z systemem operacyjnym
Ilustracja 4.2 Rozdział funkcji w programie
Jak widać na rysunku, obiekty z grupy USERCONTOL sterują obiektami typu SYSTEMCONTROL. Taki rozdział funkcji, pozwala na prostą wymianę kodu źródłowego i dostosowanie całego pośrednictwa do nowego systemu operacyjnego.
Obiekty grupy USERCONTOL powinny zapewniać obsługę przycisków, pól wyboru, list ciągów tekstowych i pól wprowadzania ciągów tekstowych. Wszystkie te obiekty powinny reagować na zdarzenia i wizualizować na ekranie przechowywaną zawartość. Na bazie obiektów USERCONTROL powinna istnieć możliwość stworzenia obiektów zarządzających obiektami typu SYSTEMCONTROL. Powinna istnieć możliwość tworzenia okien dialogowych, przesuwania ich po ekranie, i wprowadzania i wyprowadzania z nich informacji. Na podstawie obiektów z grupy USERCONTROL powinna istnieć możliwość utworzenia dwóch paneli, pośrednictwa tekstowego oraz belki narzędziowej.
Obiekty typu SYSTEMCONTROL powinny zapewniać komunikację z systemem operacyjnym. Przyjęte rozwiązanie części uruchamiającej, wymaga aby obiekty tego typu przygotowywały programy wsadowe dla systemu operacyjnego. Komunikacja, odczyt plików konfiguracyjnych i tymczasowych, tworzenie tekstu procesów powinno być realizowane przy pomocy obiektów typu SYSTEMCONTROL.
Ilustracja 4.3 Przepływ sterowania w aplikacji
Obiekt sterujący zachowaniem pośrednictwa użytkowego powinien sterować obiektami typu USERCONTROL i SYSTEMCONTROL. Powinien on sterować pośrednictwem użytkowym, dobierać metody i podejmować odpowiednie akcje na obiektach lub grupach obiektów. Obiekt CORE powinien mieć ściśle zdefiniowane zmienne stanu. Zmienne stanu obiektu zawierają informacje pozwalające, po ponownym uruchomieniu pośrednictwa, na przywrócenie jego poprzedniego stanu. Zmienne stanu powinny być zachowane w plikach tymczasowych na czas nieobecności interfejsu użytkownika w pamięci operacyjnej komputera. Po ponownym odczytaniu z dysku części odpowiedzialnej za interfejs użytkownika, na podstawie zmiennych stanu obiektu CORE, powinna istnieć możliwość przywrócenia poprzedniego stanu aplikacji.
Pośrednictwo, po uruchomieniu, powinno prezentować swoje możliwości i informacje na ekranie komputera. Powinno ono wizualizować w sposób możliwie przystępny informacje pobrane z systemu operacyjnego oraz możliwe do wykonania akcje na zdefiniowanych obiektach. Projektowany wygląd ekranu pośrednictwa jest zamieszczony poniżej.
Ilustracja 4.4 Projekt ekranu pośrednictwa
Projekt ekranu pośrednictwa użytkowego zakłada że pojawią się na ekranie dwa panele, pośrednictwo tekstowe oraz belki narzędziowe.
W panelu będzie umieszczona informacja o plikach i katalogach, nazwa katalogu z jakiego te informacje zostały pobrane, pasek stanu, informujący o położeniu podświetlonego wskaźnika oraz belka narzędziowa udostępniająca metody pozwalające na operacje na obiektach.
Pośrednictwo tekstowe będzie umożliwiało wydawanie poleceń standardowemu pośrednictwu tekstowemu COMMAND.COM udostępniając rozszerzony zbiór możliwości edycyjnych tekstu polecenia.
Belka narzędziowa, wypełniona przyciskami, będzie udostępniała metody związane z kontrolą realizowanych procesów, edycją i tworzeniem obiektów, wyborem napędów, usuwaniem paneli z ekranu oraz zakończeniem pracy pośrednictwa.
P olitechnika Śląska - Gliwice, wrzesień 1995