WstΩp

Od czasu, kiedy mikrokomputery osobiste zago╢ci│y w domach przeciΩtnych ludzi oczywiste sta│o siΩ, ┐e aby mia│y szanse zdobyµ popularno╢µ i znale╝µ zastosowanie w wielu dziedzinach musz▒ byµ │atwe w obs│udze. Dlatego od wielu lat jeste╢my ╢wiadkami rozwoju technik programistycznych w kierunku uproszczenia obs│ugi komputera. Ju┐ w czasach systemu Microsoft DOS powstawa│y programy wyposa┐one w │atwe w obs│udze interfejsy u┐ytkownika. Mo┐na je by│o obs│ugiwaµ za pomoc▒ myszy. Opiera│y siΩ na idei okien, czyli prostok▒tnych obszar≤w ekranu prezentuj▒cych jakie╢ dane lub prowadz▒cych interakcjΩ (dialog) z u┐ytkownikiem, kt≤re mog│y siΩ wzajemnie przys│aniaµ. Jednak co do wygl▒du tego interfejsu nie by│o ustalonych standard≤w. Programy takie, jak Turbo Pascal i Turbo C++ firmy Borland a tak┐e Norton Commander realizowa│y ten interfejs w trybie znakowym poprzez bibliotekΩ Turbo Vision. Inne za╢ mog│y wypracowane w│asne, nierzadko graficzne interfejsy.

Du┐ym krokiem naprz≤d w dziedzinie rozwoju przyjaznych dla u┐ytkownika interfejs≤w by│o stworzenie przez firmΩ Microsoft najpierw nak│adki na DOS – Windows 3.11, a nastΩpnie samodzielnego systemu operacyjnego – Windows 95, 98, Me oraz NT 4.0, 2000 i innych mniej znanych wersji. Interfejs u┐ytkownika zosta│ ujednolicony, a jego g│≤wna idea – zastosowanie okien sta│a siΩ tak wa┐na, ┐e to w│a╢nie od niej pochodzi nazwa systemu. Od tego czasu niewiele siΩ ju┐ zmienia w rozwoju „przyjazno╢ci” komputera dla u┐ytkownika. Obecnie jeste╢my ╢wiadkami og≤lnego znudzenia powszednim widokiem szarych okien. Wiele firm lansuje w swoich programach (g│ownie s▒ to programy multimedialne – do odczytywania b▒d╝ edycji grafiki i d╝wiΩku - Winamp, Windows Media Player) w│asne, nietypowe, najczΩ╢ciej prze│adowane spowalniaj▒c▒ ich pracΩ grafik▒ interfejsy.

Problemy

W czasach DOS wszystkie programy by│y niezale┐ne. U┐ytkownik sam te┐ zarz▒dza│ dyskiem. Program wystarczy│o zwykle skopiowaµ (ewentualnie wystΩpuj▒ce instalatory ogranicza│y siΩ w│a╢nie do skopiowania plik≤w) i uruchomiµ jak▒╢ aplikacjΩ do konfiguracji pozwalaj▒c▒ wybraµ np. posiadany model karty graficznej czy d╝wiΩkowej. Program taki mo┐na by│o bez problemu usun▒µ z dysku. Ale by│o to okupione tym, ┐e ka┐dy program i ka┐da gra musia│a we w│asnym zakresie realizowaµ obs│ugΩ najpopularniejszych kart graficznych, d╝wiΩkowych, joystick≤w i innych urz▒dze±.

Dzi╢ jest inaczej. Instalacja programu w systemie Windows to opr≤cz skopiowania plik≤w do folderu docelowego tak┐e skopiowanie r≤┐nych bibliotek do wsp≤│u┐ytkowanego folderu C:\Windows\System, wykonanie odpowiednich wpis≤w w Rejestrze, zarejestrowanie obs│ugiwanych rozszerze± plik≤w, nowych komponent≤w COM i inne czynno╢ci. Analogicznie deinstalatory, w kt≤re wyposa┐one s▒ programy musz▒ (a przynajmniej powinny) to wszystko usuwaµ. Stan taki ma swoje zalety: w systemie mo┐e byµ tylko jedna kopia biblioteki u┐ywanej przez wiele program≤w (oszczΩdno╢µ dysku), system sam realizuje obs│ugΩ sprzΩtu dziΩki do│▒czanym do niego sterownikom (programy nie musz▒ siΩ o to martwiµ). Programy s▒ bardziej zale┐ne od systemu – wszystkie czynno╢ci, jakie robi▒ wykonuj▒ poprzez wywo│ywanie odpowiednich funkcji Win32API czy innych API, zawartych w systemowych bibliotekach .dll. Ale ma to te┐ swoje wady: ╝le napisane instalatory potrafi▒ nadpisaµ wsp≤│u┐ytkowan▒ bibliotekΩ przez jej starsz▒ wersjΩ (co mo┐e spowodowaµ problemy w dzia│aniu innych program≤w, a nawet za│amanie systemu). Tak┐e niesforne deinstalatory nader czΩsto pozostawiaj▒ na dysku i w Rejestrze r≤┐ne nieusuniΩte dane (co czasami, np. w przypadku Microsoft Office, jest zamierzone przez producenta).

Tzw. DLL hell, czyli opisane wy┐ej zjawisko nadpisywania bibliotek systemowych, sterownik≤w, obiekt≤w COM i innych to jeden z problem≤w, z kt≤rymi Microsoft pr≤buje walczyµ planuj▒c nowe wersje systemu Windows. Rozwi▒zaniem jest, wed│ug giganta z Redmond wprowadzenie nowego │adu, w kt≤rym ka┐dy program bΩdzie zawiera│ w│asne biblioteki. Jego zdaniem idea wsp≤│dzielenia bibliotek przez programy wywodzi siΩ z „prehistorycznych” czas≤w, gdy dysk twardy nie by│ w komputerze bynajmniej sk│adnikiem oczywistym. Dlatego ju┐ pocz▒wszy od Windows 98 SE Microsoft realizuje ideΩ Fusion, maj▒c▒ przeciwdzia│aµ temu negatywnemu zjawisku. W Win98SE by│o to side by side DLL-s, w Windows 2000 i Me s▒ to Windows File Protection i System File Protection. Te rozwi▒zania s▒ jak najbardziej dobre i sam jestem ich zwolennikiem. Gorzej wygl▒daj▒ plany na przysz│o╢µ: wraz z pojawieniem siΩ Whistlera i Visual Studio 7 idea Fusion przybierze now▒ formΩ: system operacyjny zacznie „oszukiwaµ” aplikacje. BΩd▒ one „my╢la│y”, ┐e nadpisa│y bibliotekΩ systemow▒, gdy w rzeczywisto╢ci wykorzystaj▒ swoj▒ starsz▒ wersjΩ, umieszczon▒ bezpiecznie we w│asnym katalogu programu. Tak naprawdΩ bΩd▒ one wykonywane w maszynie wirtualnej(...).

Niew▒tpliwie samo istnienie Fusion jest zjawiskiem pozytywnym i jest ona jak najbardziej potrzebna. Jednak moim zdaniem sprawy nie mog▒ zaj╢µ a┐ tak daleko. Oto dlaczego uwa┐am, ┐e taki kierunek rozwoju jest niew│a╢ciwy:

• Ka┐dy program ma we w│asnym zakresie posiadaµ u┐ywane przez siebie biblioteki? Choµ nie bΩdzie problemem, je╢li program taki zajmie na naszym dysku kilka MB wiΩcej, to ╢ci▒ganie go z Internetu takie bezproblemowe ju┐ nie bΩdzie (szczeg≤lnie w warunkach TP SA).

• Wykonywanie programu w wirtualnej maszynie znacz▒co spowolni jego pracΩ. Znowu przybΩdzie takich warstw, kt≤re po╢rednicz▒ miΩdzy programem a sprzΩtem, a kt≤rych i tak ju┐ jest bardzo du┐o, o ile nie za du┐o. Rosn▒ca moc obliczeniowa komputer≤w zamiast pozostawaµ do dyspozycji coraz lepszych i coraz bardziej z│o┐onych program≤w, po raz kolejny po┐arta zostanie przez system operacyjny i owe warstwy.

• I tak nie uda siΩ cofn▒µ czasu i realizowaµ program≤w tak, jak to by│o w DOSie. Bo co bΩdzie np. ze sterownikami do sprzΩtu. Znowu ka┐dy program bΩdzie musia│ realizowaµ to we w│asnym zakresie? To raczej niemo┐liwe.

• Naturaln▒ konsekwencj▒ rozwoju przystΩpno╢ci i │atwo╢ci obs│ugi program≤w jest ich wzajemna integracja, kompatybilno╢µ i mo┐liwo╢µ wymiany danych. A to w pewnym sensie stoi w sprzeczno╢ci przedstawion▒ wy┐ej ide▒ Microsoftu.

Idea przysz│o╢ciowego systemu

Na podstawie moich przemy╢le± na przedstawione powy┐ej tematy opracowa│em w│asn▒ koncepcjΩ, jak m≤g│by wygl▒daµ system operacyjny przysz│o╢ci. Wed│ug mnie system taki to... jeden wielki program. W takim systemie przestanie istnieµ s│owo program czy aplikacja. Nast▒pi tam totalna integracja ca│ego zgromadzonego kodu wykonywalnego (exe, dll, ocx, vxd i inne takie). Zamiast tego bΩd▒ modu│y (pewnie zostanie dla nich wymy╢lona jaka╢ nowa nazwa, kt≤rej teraz jeszcze nie jeste╢my w stanie przewidzieµ). Modu│y te bΩd▒ rozszerzaµ system o kolejne funkcje.

Przyk│ad

We╝my dla przyk│adu program graficzny. Chc▒c stworzyµ swoje ma│e dzie│o muszΩ w│▒czaµ kilka program≤w. Najpierw wielki kombajn – w nim po│▒czΩ zgromadzone wcze╢niej grafiki, dodam efekty. Ale okazuje siΩ, ┐e muszΩ dodaµ jaki╢ efekt, kt≤rego nie ma w tym programie. Jest w innym. W│▒czam wiΩc drugi program. Wreszcie trzeci – bo tylko on ma mo┐liwo╢µ eksportu do formatu, w kt≤rym moje dzie│o ma byµ docelowo zapisane. To jest oczywi╢cie wyj▒tkowo pesymistyczny przypadek, ale s▒dzΩ, ┐e do╢µ dobrze ukazuje obecn▒ sytuacjΩ.

W systemie przysz│o╢ci nie bΩdzie jako takich program≤w graficznych. Chc▒c stworzyµ rysunek bΩdzie siΩ w jaki╢ spos≤b wydawa│o systemowi polecenie, aby ten uruchomi│ (jak by to trafnie nazwaµ?) „podsystem” graficzny. Taki w systemie bΩdzie tylko jeden. Je┐eli np. kupi│em modu│ z ciekawymi efektami, to te efekty bΩd▒ po jego zainstalowaniu dostΩpne w systemie. Je╢li ╢ci▒gn▒│em sobie z Internetu darmowy modu│ – filtr do obs│ugi jakiego╢ egzotycznego formatu, to format ten stanie siΩ dostΩpny w moim systemie. Po prostu system operacyjny bΩdzie mia│ budowΩ modu│ow▒ – nowe modu│y bΩd▒ dodawaµ nowe funkcje, filtry, efekty. I tak dla ka┐dego typu dokument≤w. Podobnie w edytorze tekstu bΩdzie np. modu│ umo┐liwiaj▒cy wstawianie tabel albo wprowadzaj▒cy podw≤jne podkre╢lenie tekstu.

Pozostaje jeszcze zagadnienie format≤w plik≤w. Co siΩ stanie, je╢li zapiszΩ tekst zawieraj▒cy podw≤jne podkre╢lenie i zaniosΩ go do kolegi, kt≤ry nie ma odpowiedzialnego za to modu│u. Ot≤┐ s▒dz▒, ┐e pliki powinny byµ zbudowane podobnie, jak dzisiaj s▒ strony HTML tzn. oparte na znacznikach. Niekoniecznie jako pliki tekstowe. Mog▒ byµ to przecie┐ znaczniki binarne. Chodzi tylko o to, ┐e je╢li system odczytuj▒cy nie potrafi zinterpretowaµ jakiego╢ znacznika, po prostu go ignoruje i nie cierpi na tym reszta dokumentu.

Takie modu│y by│yby dystrybuowane na podobnych zasadach, jak dzisiejsze programy. Jedne komercyjne, p│atne, produkowane przez firmy. Inne darmowe. Jeszcze inne pisane przez programist≤w-hobbyst≤w jako open-source. Jedne do kupienia w sklepach, inne dostΩpne w Internecie.

Podobne modu│y mog│yby kreowaµ interfejs u┐ytkownika systemu. M≤g│by siΩ pojawiµ modu│, kt≤ry dodawa│by do systemu nowy pasek ze skr≤tami, kt≤ry mo┐na sobie konfigurowaµ. Inny pozwala│by na wymianΩ „sk≤r” – zestaw≤w bitmap w systemie.

Wszystko sta│oby siΩ wzglΩdne. Nie by│oby ju┐, ┐e uruchamiasz np. edytor tekstu czy program graficzny.

Znowu problemy

Przy takiej integracji modu│≤w z systemem mo┐na by siΩ spodziewaµ powa┐nych problem≤w z jego stabilno╢ci▒. Problemy takie spotykamy przecie┐ na co dzie±. Wszelkie „modu│y” (w dzisiejszym tego s│owa znaczeniu) maj▒ce bezpo╢redni kontakt z systemem (niskopoziomowe), czΩsto sprawiaj▒ problemy, powoduj▒ niestabilno╢µ systemu, „k│≤c▒ siΩ” z innymi programami, a nawet doprowadzaj▒ do za│amania systemu. S▒ to najczΩ╢ciej sterowniki sprzΩtowe, programy narzΩdziowe, r≤┐ne biblioteki systemowe (nowe wersje, kt≤re „koniecznie trzeba mieµ”), │aty i service packi. Ale... My╢lΩ, ┐e wystΩpowaniu takich sytuacji mo┐na zapobiec. W rzeczywisto╢ci obserwowalnej ju┐ dzisiaj coraz bli┐szej integracji miΩdzy r≤┐nymi czΩ╢ciami systemu operacyjnego i zainstalowanymi w nim programami ju┐ od dawna towarzysz▒ dzia│ania zapobiegaj▒ce takim niepo┐▒danym sytuacjom. Zauwa┐: w systemie DOS ka┐dy program mia│ nieograniczon▒ w│adzΩ w komputerze. System operacyjny by│ dla niego „przezroczysty”. M≤g│ robiµ co chcia│ z pamiΩci▒ RAM, z plikami na dysku, z ca│ym hardwarem i softwarem. W 32-bitowych systemach Windows tak ju┐ nie jest. Programy nie odwo│uj▒ siΩ ju┐ bezpo╢rednio do przerwa± itp. Te z nich (g│≤wnie stare, DOSowe), kt≤re pr≤buj▒ to nadal robiµ s▒ kategorycznie „wypraszane” przez system z pamiΩci, co dla u┐ytkownika objawia siΩ zwykle komunikatem, ┐e „program wykona│ niedozwolon▒ operacjΩ”, „b│▒d ochrony”, „access violation”. Programy pisane docelowo dla Windows wykonuj▒ swoje dzia│ania poprzez uruchamianie r≤┐nych funkcji zawartych w .dllach systemowych, kt≤re nazwane s▒ API (Application Programming Interface – interfejs do programowania aplikacji). Tak wiΩc, jak widaµ, programi╢ci tworz▒cy system operacyjny zapewniaj▒ jemu oraz zainstalowanym w nim programom bezpiecze±stwo poprzez kontrolΩ nad uruchomionymi procesami. Procesy te nie maj▒ pe│nej w│adzy (bo w systemach wielow▒tkowych „gryz│yby siΩ”), ale wykonywane przez nie czynno╢ci s▒ kontrolowane przez system i mo┐e on ka┐dej chwili odm≤wiµ wykonania jakiej╢ czynno╢ci. Je╢li programy zmuszone s▒ do realizowania wszystkich czynno╢ci przez API, to system mo┐e dowolnie ograniczaµ uprawnienia program≤w. Problem w tym, ┐e takie uprawnienia na razie nie istniej▒. »aden program nie mo┐e naruszyµ przestrzeni adresowej innego, bo za karΩ „wyleci” z pamiΩci, ale ju┐ ka┐dy z nich mo┐e np. usuwaµ dowolne pliki z dysku. Moim zdaniem, je╢li system przysz│o╢ci bΩdzie wygl▒da│ tak, jak przedstawi│em powy┐ej (budowa modu│owa), to po prostu niezbΩdne stanie siΩ zastosowanie zupe│nie nowej, a przynajmniej znacznie bardziej rygorystyczne polityki bezpiecze±stwa wobec zainstalowanych i uruchamianych w systemie modu│≤w. Wed│ug mnie rozwi▒zaniem jest zastosowane takiej polityki przydzielania uprawnie± dla modu│≤w, jak▒ obecnie stosuje siΩ dla u┐ytkownik≤w. Poza tym system powinien kontrolowaµ poczynania program≤w i sam dopilnowywaµ rzeczy, kt≤re obecnie s▒ w rΩkach program≤w. Dlaczego tak? Po prostu programy s▒ r≤┐ne tak samo jak r≤┐ni s▒ ludzie, kt≤rzy je pisz▒. Jedni porz▒dni, drudzy totalnie olewaj▒ wszystkie obowi▒zki, jakie na programi╢cie ci▒┐▒ i wyznaj▒ ideΩ „jak tylko dzia│a, to jest dobrze”.

Instalacja i deinstalacja

Dla przyk│adu we╝my proces instalacji i deinstalacji program≤w. Obecnie niemal ka┐dy program wyposa┐ony jest we w│asny instalator. Microsoft dopiero niedawno doszed│ do wniosku, ┐e nie op│aca siΩ w ka┐dym z nich zawieraµ tego samego kodu wykonywalnego i stworzy│ technologiΩ Windows Installer. Ale zanim ona siΩ przyjmie, minie du┐o czasu. P≤ki co nienajlepiej siΩ dzieje w tej dziedzinie. Co prawda wiΩkszo╢µ program≤w ma instalatory wykonane w InstallShield, ale wiele z nich ma tak┐e w│asne, niestandardowe, zrobione przez autor≤w program≤w. Programy instalacyjne niejednokrotnie czyni▒ du┐e spustoszenie w systemie. Potrafi▒ nadpisaµ jak▒╢ bibliotekΩ jej starsz▒ wersj▒, a tak┐e zrobiµ wiele jeszcze gorszych rzeczy. Nie lepsze od nich s▒ deinstalatory. Te potrafi▒ usun▒µ jaki╢ wa┐ny dla systemu plik, ale najczΩ╢ciej wrΩcz przeciwnie – pozostawiaj▒ na dysku i w Rejestrze r≤┐ne dane, kt≤re w tym momencie staj▒ siΩ zalegaj▒cymi tylko ╢mieciami.

A jak mog│oby to wygl▒daµ w systemie przysz│o╢ci? Moim zdaniem instalacjΩ powinien przeprowadzaµ sam system. Kopiowa│by on pliki i wykonywa│ inne czynno╢ci instalacyjne na podstawie specjalnych plik≤w, w kt≤rych by│yby opisane rzeczy, jakie kolejno nale┐y zrobiµ aby zainstalowaµ program. Podobnie z deinstalacj▒: system w czasie instalacji oraz dzia│ania programu zapisywa│by do wewnΩtrznych log≤w, jakie pliki, zapisy w Rejestrze i inne elementy nale┐▒ do programu i sam usuwa│by je wszystkie na ┐▒danie u┐ytkownika dotycz▒ce deinstalacji danego programu.

Polityka bezpiecze±stwa

A jak taka ochrona „reszty ╢wiata” przed dzia│aniami programu by│aby realizowana w czasie normalnej pracy programu? Jak ju┐ wy┐ej napisa│em proponujΩ przydzielaµ poszczeg≤lnym programom uprawnienia tak, jak obecnie robi siΩ to w stosunku do u┐ytkownik≤w. Przyk│adowo: edytorowi tekstu nie jest potrzebny dostΩp do ca│ego Rejestru. Wystarczy tylko do jednego klucza, w kt≤rym bΩdzie m≤g│ przechowywaµ swoje ustawienia. Podobne wymagania ma wiΩkszo╢µ program≤w. Ale ju┐ program narzΩdziowy do kontroli systemu bΩdzie chcia│ uzyskaµ prawo do operacji na ca│ym Rejestrze. Je╢li sprawa dotyczy tak szerokich , co za tym idzie, niebezpiecznych uprawnie±, to system m≤g│by np. poczekaµ z tym, a┐ zalogowany bΩdzie administrator i jego zapytaµ, czy darzy zaufaniem dany program i czy pozwala mu na wykonywanie takich a takich dzia│a±. Je╢li teraz np. Rejestr zostanie fizycznie lub logicznie uszkodzony i zajdzie potrzeba jego odtworzenia z kopii bezpiecze±stwa, to system na podstawie log≤w i we wsp≤│pracy z administratorem przeprowadzi dochodzenie, kt≤re bΩdzie mia│o na celu wskazanie winnego programu (modu│u). Je╢li winny siΩ znajdzie, jego uprawnienia zostan▒ odebrane i ograniczone do bezpiecznego poziomu dop≤ki sam administrator nie zdecyduje siΩ na jego „u│askawienie”.

Jak mog│oby to byµ zrealizowane na poziomie API? Program ubiega│by siΩ w systemie o przydzielenie mu jaki╢ uprawnie± poprzez wywo│anie odpowiedniej funkcji systemowego API. I zanim przeprowadzi jak▒╢ operacje, bΩdzie musia│ sprawdziµ, czy ma do jej wykonania prawo. Je╢li nie, zako±czy siΩ ona fiaskiem i program odbierze komunikat o b│Ωdzie.

Konsola

Zarz▒dzanie plikami

Przejd╝my do innego tematu: Zarz▒dzania struktur▒ plik≤w i katalog≤w na dysku przez u┐ytkownika z udzia│em i za po╢rednictwem systemu operacyjnego. Kiedy╢, w czasach DOS ka┐dy sam musia│ dbaµ o pliki i katalogi na dysku, o ich organizacjΩ, przeznaczenie, zawarto╢µ. Tu mam programy, tu bΩdΩ trzyma│ moje teksty, tu moje obrazki, ╢ci╢le tajne dane schowam tam, a tu, oczywi╢cie, jest DOS. W Windows sprawa uleg│a niewielkiej zmianie. Teraz system znajduje siΩ zwykle w C:\Windows. Tam te┐ instalowane programy kopiuj▒ wiele swoich w│asnych bibliotek i innych plik≤w. Instalowane programy najczΩ╢ciej usadawia siΩ w C:\Program files. Tam prawie nigdy siΩ nie zagl▒da. Z kolei w C:\Moje dokumenty u┐ytkownik powinien trzymaµ efekty swojej pracy, czyli dokumenty utworzone w r≤┐nych programach. Nie istnieje obowi▒zek stosowania siΩ do tych regu│, ale takie proponuje nam Windows i my╢lΩ, ┐e dobrze robi.

Dlaczego to jest dobre?

Poniewa┐ hierarchicznie zorganizowana struktura plik≤w i folder≤w na dysku, w kt≤rych znajduje siΩ tyle danych r≤┐nego rodzaju (programy, dokumenty) jest jedn▒ z trudniejszych rzeczy do zrozumienia dla pocz▒tkuj▒cych u┐ytkownik≤w. Sam znam osoby, kt≤re my╢l▒, ┐e umiejscowienie programu w C:\Program files, a skr≤tu do niego w Menu Start\Programy to jedno i to samo. Je╢li natomiast u┐ytkownik bΩdzie swoje dokumenty przechowywa│ tylko w specjalnie do tego przeznaczonym folderze i ewentualnie utworzonych przez niego samego podfolderach, a wszystkie inne rzeczy takie, jak wyb≤r folderu instalacyjnego bΩdzie zostawia│ domy╢lne, to znacznie upro╢ci mu to obs│ugΩ komputera.

Nie tak dawno zadzwoni│ do mnie jeden kolega. Prosi│ mnie o pomoc. Musia│ zrobiµ co╢ z pewnym plikiem w zainstalowanej na jego komputerze grze. Ju┐ nie pamiΩtam dok│adnie co to by│o i o jak▒ grΩ chodzi│o. W ka┐dym razie zacz▒│em mu t│umaczyµ jak tego dokonaµ. Dobrze, ┐e to jemu r≤s│ rachunek telefoniczny. Nerwy zacz▒│em traciµ, kiedy przez parΩ minut szuka│ na ekranie Menu Start nie wiedz▒c, o co chodzi. Ale na szczΩ╢cie dla mnie nasze rozmowa szybko siΩ sko±czy│a. A sko±czy│a siΩ na tym, ┐e kolega nie znalaz│ na dysku C: folderu Program files. Tak po prostu :-). Nie ma i koniec. Nie pomog│o mu nawet poszukiwanie za pomoc▒ funkcji Znajd╝ > Pliki lub foldery...

W│a╢nie dlatego uwa┐am, ┐e hierarchiczna struktura, obejmuj▒ca wszystkie miejsca na dysku, a dostΩpna dla u┐ytkownika jest dla niego nie tyle nieodpowiednia, co po prostu niepotrzebna. Niepotrzebnie komplikuje ona obs│ugΩ komputera.

Co z tego wynika?

Je╢li ja narysujΩ w programie graficznym rysunek, to wygodniej by│oby m≤c zapisaµ go pod jak▒╢ nazw▒, dajmy na to „Bazgro│y”, ni┐ martwiµ siΩ o to, w jakim on bΩdzie folderze, w jakim formacie i o inne takie rzeczy. W ko±cu komputer ma byµ │atwy w obs│udze, nieprawda┐?

M≤j pomys│

Wpad│em na pomys│, jak zrealizowaµ obs│ugΩ plik≤w i przy okazji wielu innych czynno╢ci upraszczaj▒c je przy tym do maksimum. Zagadnienie to jest nierozerwalnie zwi▒zane z wizj▒ systemu operacyjnego przysz│o╢ci. Jednak na system taki jest, jak siΩ wydaje, jeszcze trochΩ za wcze╢nie i nie potrafimy nawet jeszcze trafnie nazwaµ wystΩpuj▒cych w nim czΩ╢ci. Natomiast prezentowana przeze mnie poni┐ej idea, choµ w systemie takim odgrywa│aby z pewno╢ci▒ niebagateln▒ rolΩ, jest mo┐liwa do zrealizowana ju┐ teraz. Dlatego dla uproszczenia omawiaj▒c ten temat bΩdΩ pisa│ o nim tak, jakby mia│ znale╝µ zastosowanie dla systemu Windows w takiej postaci, w jakiej znamy go dzi╢.

Rozw≤j i rola konsoli

Podstaw▒ pierwszych system≤w operacyjnych by│a tzw. konsola. Nazw▒ to okre╢lany by│ czasem zestaw klawiatura – monitor traktowany jako jedno urz▒dzenie wej╢cia-wyj╢cia. S│owo to ma tak┐e inne znaczenia, ale pod wzglΩdem programowym konsola to realizowana w trybie tekstowym mo┐liwo╢µ wydawania komputerowi polece± w formie ci▒g≤w znak≤w. KonsolΩ tak▒ znamy choµby z DOS. Z czasem zaczΩ│y pojawiaµ siΩ programy na tyle skomplikowane, ┐e przesta│a ju┐ im wystarczaµ funkcjonalno╢µ wiersza polece±. Programy zaczΩ│y byµ wyposa┐ane w – bardziej lub mniej – graficzne interfejsy u┐ytkownika. Ale podstaw▒ systemu nadal pozostawa│a konsola. To z jej poziomu uruchamia│o siΩ programy. Sytuacja zmieni│a siΩ radykalnie wraz z pojawieniem siΩ na rynku graficznych system≤w operacyjnych, jak Windows. Tutaj podstaw▒ systemu s▒ okna.

O co chodzi?

Og≤lnie rzecz bior▒c chodzi o to, aby powr≤ciµ do konsoli. Ale nie, jak w DOSie, kiedy konsola by│a podstaw▒. Podstaw▒ nadal by│yby okna, a konsola by│a w nich zawieszona jako jedno z nich. Jak mog│oby to byµ zrealizowane? Na przyk│ad jako jaki╢ tam pasek, kt≤ry rezydowa│by sobie gdzie╢ na ekranie nie przeszkadzaj▒c nikomu. Jego klikniΩcie powodowa│yby rozwiniΩcie okna konsoli. Albo jako dzia│aj▒ca w tle aplikacja, kt≤rej ikona znajdowa│aby siΩ w polu systemowym. Albo, co wydaje mi siΩ najlepszym rozwi▒zaniem, jako rezyduj▒ca po prawej stronie u g≤ry ekranu Windowsowa kontrolka listy rozwijalnej combo. Wpisanie do niej polecenia i naci╢niΩcie klawisza Enter spowodowa│oby jego wykonanie. KlikniΩcie na strza│kΩ natomiast rozwinΩ│oby pe│ne okno konsoli, na kt≤rym mo┐na by│oby zobaczyµ ostatnio wykonywane polecenia i odpowiedzi komputera. Taka konsola mia│aby budowΩ modu│ow▒ i by│aby maksymalnie zintegrowana z systemem oraz z zainstalowanymi programami. Tzn. programy musia│yby byµ pisane pod k▒tem integracji z ni▒.

Przyk│ad

Dla przyk│adu wr≤µmy raz jeszcze do wspomnianego ju┐ wy┐ej programu graficznego. Narysowa│em arcydzie│o, ale mi gdzie╢ kartkΩ wciΩ│o. Dlatego postanowi│em rysowaµ na komputerze. I tak pracujΩ sobie z programem rysuj▒c co╢. Kiedy ko±czΩ, piszΩ na konsoli: Zapisz jako Bazgro│y. Konsola pr≤buje zinterpretowaµ to sformu│owane w jΩzyku naturalnym polecenie. Zapisz jako to nazwa czynno╢ci, jaka mo┐e zostaµ wykonana na dokumencie. Konsola wie, ┐e ostatnio pracowa│em przez d│u┐szy czas z programem graficznym, tote┐ chodzi pewnie o edytowany w nim aktualnie dokument. Czynno╢µ ta wymaga jednego parametru: nazwy dla dokumentu. Bazgro│y to pewnie ta nazwa. WiΩc konsola wysy│a do programu graficznego polecenie zapisania dokumentu jako Bazgro│y. Nie ma wyboru folderu, do jakiego ma zostaµ zapisany plik, ani wyboru formatu. Po prostu: dla u┐ytkownika ten rysunek kryje siΩ pod nazw▒ Bazgro│y. Prawda, ┐e proste i intuicyjne? Dlatego jestem zwolennikiem p│askiego (tzn. nie hierarchicznego) modelu obiekt≤w, z kt≤rych ka┐dy bΩdzie identyfikowany przez nazwΩ i ewentualnie inne cechy takie, jak typ.

Po jakim╢ czasie postanowi│em, ┐e moje arcydzie│o poka┐Ω koledze. W tym celu wydajΩ na konsoli polecenie: Kopiuj Bazgro│y na dyskietkΩ. Konsola interpretuje: Kopiuj to nazwa czynno╢ci nale┐▒cej do grupy operacji na obiektach systemu plik≤w. Wymaga ona dw≤ch parametr≤w. Jako jeden z nich potraktowany zostaje wyraz Bazgro│y. Konsola wie, ┐e niedawno u┐ywano tego obiektu (ma to zapisane gdzie╢ w jakim╢ pliku pamiΩci podrΩcznej cache) i jest on plikiem C:\Moje dokumenty\Bazgro│y.gif. Je╢li by tego nie wiedzia│, musia│by poszukaµ, co to takiego mo┐e byµ. Przeszuka│by pewnie najczΩ╢ciej u┐ywane foldery z dokumentami, Menu Start, Pulpit, listΩ zainstalowanych program≤w i inne takie miejsca. Drugi wyraz – dyskietka(Ω) jest aliasem do napΩdu A:. Tak wiΩc wykonane zostaje kopiowanie C:\Moje dokumenty\Bazgro│y.gif do A:\.

Czy to siΩ aby op│aca?

Dobre pytanie! Przecie┐ wydawanie polece± na konsoli od lat funkcjonuje niemal jako symbol niewygody i informatycznego zacofania. Ot≤┐ my╢lΩ, ┐e pora na prze│amanie tego stereotypu. Je╢li: po pierwsze – polecenia bΩdzie mo┐na formu│owaµ w spos≤b intuicyjny w jΩzyku naturalnym, po drugie jedno polecenie bΩdzie wykonywa│o wiele skomplikowanych czynno╢ci, to nawet, je┐eli mo┐na by to by│o wszystko wyklikaµ, to u┐ywanie takiej nowoczesnej konsoli zaczyna siΩ op│acaµ.

Rozszerzalno╢µ

Taka konsola mia│aby budowΩ modu│ow▒. Znaczy to, ┐e nie stanowi│aby jednej sp≤jnej ca│o╢ci, ale w swojej pierwotnej postaci sk│ada│aby siΩ z wielu czΩ╢ci odpowiedzialnych za r≤┐ne czynno╢ci. M≤g│by istnieµ modu│ odpowiedzialny za operacje na plikach (kopiowanie, przenoszenie, usuwanie) oraz na dokumentach (rozkazywanie uruchomionym aplikacjom zapisywania, otwierania, zamykania dokument≤w). Tak zbudowan▒ konsolΩ mo┐na by│oby rozszerzaµ o nowe modu│y np. do obs│ugi Rejestru.

Jak to dzia│a?

Prawid│owe interpretowanie polece± w naturalnym jΩzyku nie jest │atwe. My╢lΩ, ┐e mo┐na by│oby to zrealizowaµ w nastΩpuj▒cy spos≤b: W╢r≤d s│≤w i ich zespo│≤w w poleceniach znajdowane by│yby najpierw nazwy czynno╢ci, czyli czasowniki. Odpowiada│yby one czynno╢ciom, jakie konsola mo┐e wykonaµ. Ka┐dy modu│ konsoli rozszerza│by j▒ o nowe czynno╢ci np. modu│ do obs│ugi plik≤w potrafi kopiowaµ, przenosiµ, usuwaµ. WiΩkszo╢µ czynno╢ci wymaga jednego lub wielu parametr≤w, czyli np. co skopiowaµ i dok▒d. Ka┐dy z takich parametr≤w musia│by byµ okre╢lonego typu. Bo zorganizowane w p│ask▒ strukturΩ i identyfikowane przez nazwΩ obiekty nie by│yby tylko plikami i folderami. Mog│yby one reprezentowaµ np. klucze Rejestru (taki typ obiektu zosta│by wprowadzony po zainstalowaniu modu│u do obs│ugi Rejestru). Obiekty te nie by│yby, jak pliki, zawsze istniej▒ce i trwa│e. Ta ich lista by│aby tak jakby tymczasowym buforem, list▒ skr≤t≤w do r≤┐nych rzeczy w systemie. Taki cache m≤g│by byµ przechowywany w pamiΩci, a przy wy│▒czaniu komputera zachowywany na dysk. Mia│by z g≤ry okre╢lony maksymalny rozmiar i jego przekroczenie powodowa│oby usuwanie dawno czy rzadko nie u┐ywanych obiekt≤w. UsuniΩcie obiektu reprezentuj▒cego plik Bazgro│y.gif nie spowoduje usuniΩcia samego pliku. Je╢li teraz bΩdziemy chcieli skopiowaµ co╢, co okre╢limy jako Bazgro│y na dyskietkΩ, to program, nie maj▒c ju┐ w pamiΩci cache niczego o tej nazwie poszuka w r≤┐nych miejscach systemu czego╢, co siΩ tak nazywa i po znalezieniu tego pliku na nowo utworzy na li╢cie obiekt go reprezentuj▒cy.

Jeszcze o konsoli

My╢lΩ, ┐e taka konsola znalaz│aby jeszcze wiele wiΩcej zastosowa± opr≤cz przedstawionych powy┐ej. Mo┐na by│yby za jej pomoc▒ uruchamiaµ programy (Uruchom Painta).

S│u┐y│aby tak┐e jako pomoc. Wydanie jej polecenia np. Wy╢wietl pomoc o sieci lokalnej spowodowa│oby, ┐e jej mechanizmy w spos≤b inteligentny przeszukaj▒ wszystkie znane jej w systemie pliki pomocy .hlp, .chm, .doc, .pdf, .txt i inne a nastΩpnie przedstawi▒ listΩ temat≤w, kt≤rych klikniΩcie natychmiast wy╢wietli okre╢lony dokument. Taki globalny w skali systemu, a nawet szerszy (Internet?) system pomocy okaza│by siΩ nieocenionym ╝r≤d│em zintegrowanych informacji dla u┐ytkownik≤w na ka┐dym poziomie zaawansowania.

Dla zaawansowanych natomiast konsola umo┐liwia│aby tak┐e wydawanie precyzyjnych polece± niczym w tych konsolach znanych nam dzi╢. Dopiero, kiedy to okaza│oby siΩ niewykonalne pr≤bowa│aby zinterpretowaµ polecenie w spos≤b inteligentny traktuj▒c je jako sformu│owane w jΩzyku naturalnym.

Konsola interpretuj▒c polecenie mog│aby siΩ domy╢laµ pewnych rzeczy, kt≤re s▒ wymagane, a kt≤re nie zosta│y okre╢lone – na podstawie polece± wydawanych poprzednio (np. Zapisz jako Bazgro│y, a potem ju┐ tylko Skopiuj na dyskietkΩ – wiadomo co).

Inne sprawy...

Aby komputer sta│ siΩ jeszcze bardziej przyjazny dla u┐ytkownika mo┐na zrobiµ jeszcze wiΩcej. Ot≤┐ my╢lΩ, ┐e w systemie WSZYSTKO powinno siΩ w jakim╢ zakresie daµ cofaµ tak, jak dzi╢ mo┐emy cofn▒µ usuniΩcie linijki w edytorze tekstu. Nawet tak powa┐ne sprawy, jak instalacja i deinstalacja programu. Jedn▒ z najczΩstszych przyczyn utraty danych jest usuniΩcie czego╢ z dokumentu a nastΩpnie jego odruchowe zapisanie na dysku. Potem ju┐ zwykle nie mo┐na tego cofn▒µ, a nadpisanego pliku odzyskaµ siΩ nie da. Dlatego powinno istnieµ co╢ w rodzaju historii powstawania dokumentu – powinny byµ przechowywane r≤┐ne wersje jednego pliku tak, jak przebiega│o jego tworzenie i edycja.

Jeszcze jednym problemem jest usuwanie plik≤w. Doskonale znany nam wszystkim z Windowsa Kosz z pewno╢ci▒ wiele zas│ug przy│o┐y│ do polepszenia bezpiecze±stwa. Na pewno uratowa│ ju┐ tysi▒ce godzin pracy ludzi na ca│ym ╢wiecie, kt≤rzy z Kosza wyci▒gnΩli nieopatrznie skasowane zbiory. W DOSie zrobiµ siΩ tego nie da│o (chyba, ┐e specjalnymi programami, i to nie zawsze siΩ udawa│o). Tam po prostu wszystko by│o usuwane bezpowrotnie. Ale konieczno╢µ opr≤┐niania kosza wielu u┐ytkownik≤w doprowadza do wyrobienia sobie niezdrowych nawyk≤w. Jedni zaraz po skasowaniu czegokolwiek opr≤┐niaj▒ Kosz, inni wszystko, dla wygody, usuwaj▒ od razu bezpowrotnie – z klawiszem Shift.

Z usuwaniem mog│oby byµ tak, ┐e polecenie usuniΩcia jakiego╢ pliku spowodowa│oby tylko ustawienie mu pewnego atrybutu „usuniΩty” i zapisanie daty usuniΩcia. Poza tym funkcjonowa│by on jak dot▒d. I dopiero po jakim╢ czasie albo te┐ po wyczerpaniu siΩ wolnego miejsca na dysku, je╢li system widzia│by, ┐e plik ten nie by│ ju┐ od chwili usuniΩcia u┐ywany, fizycznie wymaza│by go z dysku.

Podsumowanie

Rozw≤j system≤w operacyjnych

Dla wielu z nas przygoda z komputerami rozpoczΩ│a siΩ od systemu DOS. Ja mam to szczΩ╢cie, ┐e pomimo m│odego wieku w swojej praktyce zar≤wno programisty, jak i u┐ytkownika zd▒┐y│em sporo „zahaczyµ” o DOS. Dzi╢ mamy epokΩ │atwych w obs│udze (w naszym rozumieniu tego pojΩcia), 32-bitowych, okienkowych system≤w. W ko±cu Windows, jaki jest, ka┐dy widzi. ZaczΩ│o siΩ od nak│adek na DOS typu Windows 3.x. Wprowadzano elementy wielow▒tkowo╢ci (wtedy jeszcze bez wyw│aszczenia). Pojawi│a siΩ wszΩdobylska grafika, okna. Ujednolicono interfejs u┐ytkownika, skr≤ty klawiszowe i wiele innych rzeczy. Wraz z wersj▒ 95 Windows sta│ siΩ samodzielnych, 32-bitowym systemem operacyjnym. Nadal jednak by│ oparty na, jedynie nieco udoskonalonym j▒drze DOS. Wydawane by│y coraz to nowe, lepsze, bardziej multimedialne i bardziej stabilne (no, mo┐e przesadzi│em :-) wersje. R≤wnolegle wydawane by│y kolejne edycje i service packi do Windows NT opartego na zupe│nie nowym j▒drze (st▒d NT – Nowa Technologia). Systemy z tej serii by│y przeznaczone do zastosowa± profesjonalnych. Obecnie Microsoft ma w planach po│▒czenie tych dw≤ch linii i stworzenie jednego, uniwersalnego Windowsa. Mo┐e bΩdzie nim Whistler nazywany te┐ Windows 2001? Zobaczymy... Tymczasem opr≤cz Microsoftowych istniej▒ tak┐e inne systemy. Choµby Linux – system na tyle niezwyk│y, ┐e doczeka│ siΩ bardzo wielu r≤┐nych dystrybucji. Jedne zajmuj▒ dyskietkΩ, inne kilka CD-ROM≤w. WiΩkszo╢µ z nich jest nie tylko darmowa, ale dostΩpne s▒ w Sieci nawet ich kody ╝r≤d│owe. Jeszcze innym systemem jest BeOS.

Jaka przysz│o╢µ?

Dla wielu, mo┐e nawet wiΩkszo╢ci z nas system Windows, okna, graficzny interfejs i inne tym podobne zagadnienia s▒ oczywiste. Nie wszyscy zdajemy sobie sprawΩ, ┐e wszystko to zale┐y od u┐ywanego przez nas systemu operacyjnego, a tych jest wiele i ka┐dy ma swoje cechy. Tym niemniej ka┐dy system, kt≤rego tw≤rcy chcieliby, aby zyska│ on popularno╢µ musi spe│niaµ pewne kryteria i dostosowaµ siΩ do og≤lnie panuj▒cych w danym czasie trend≤w. A te z kolei posiadaj▒ w│asn▒ drogΩ ewolucji. Jest to co╢, co trudno jest ogarn▒µ umys│em. Tym bardziej, ┐e zwykle nie zastanawiamy siΩ nawet nad cechami i ich znaczeniem jednego systemu, kt≤rego u┐ywamy. A co dopiero z pewnymi sprawami bΩd▒cymi jeszcze ponad wszystkimi systemami? Systemy operacyjne, ich rozw≤j rz▒dzi siΩ w│asnymi prawami, innymi ni┐ rozw≤j program≤w. Albowiem wiΩkszo╢µ program≤w podporz▒dkowana jest pod okre╢lony system. Surowy wiersz polece± DOS jest dzi╢ symbolem przestarza│ej generacji system≤w b▒d╝ te┐, np. jak w Linuksie, czym╢ niedostΩpnym, zarezerwowanym tylko dla profesjonalist≤w. Windows, okna, Alt+F4, Ctrl+Z, Kosz s▒ dla nas oczywiste.

Zako±czenie

Ja, jako programista szczeg≤lnie interesujΩ siΩ po│o┐eniem przeciΩtnego, nie zawsze przecie┐ zaawansowanego u┐ytkownika. I z jego strony staram siΩ patrzeµ na te wszystkie sprawy. Nie mam wprawdzie ani ambicji, ani umiejΩtno╢ci potrzebnych do napisania systemu operacyjnego (drugim Linusem Torvaldsem nie bΩdΩ :-), ale przedstawiona przeze mnie idea nowoczesnej konsoli jest, jak s▒dzΩ mo┐liwa do zrealizowania ju┐ teraz – w tym czasie, w tym Windowsie. Dlatego mo┐e wkr≤tce przedstawione pomys│y zaczn▒ nabieraµ realnych kszta│t≤w?

Ale teraz spr≤bujmy wsp≤lnie wznie╢µ siΩ ponad to wszystko: ponad program, w kt≤rym czytasz teraz ten tekst, ponad system, w kt≤rym ten program pracuje. Pomy╢l: w jakim kierunku potoczy siΩ ewolucja system≤w operacyjnych? Jaki bΩdzie ten nastΩpny krok? Jaka wielka rewolucja szykuje siΩ w najbli┐szym czasie w tej dziedzinie? W jakim kierunku w og≤le pod▒┐a ten rozw≤j? My╢lΩ, ┐e na te pytania ka┐dy powinien odpowiedzieµ sobie sam. Ja to zrobi│em i doszed│em do wniosk≤w, kt≤re opisa│em powy┐ej. A ty? Jakie jest twoje stanowisko w tej sprawie? My╢lΩ, ┐e temat jest ciekawy i wart po╢wiΩcenia chwili na zastanowienie. Czy tytu│owy system operacyjny przysz│o╢ci bΩdzie wygl▒da│ tak, jak wygl▒da moja jego wizja? A mo┐e to w│a╢nie Tobie uda siΩ trafnie przewidzieµ bieg wydarze±? Te pytania pozostawiam bez odpowiedzi. Bo tej mo┐e udzieliµ tylko czas...

Literatura: „W nowe tysi▒clecie” – CHIP nr 9/2000, str. 128

Adam Sawicki
e-mail: sawickiap@poczta.onet.pl
ICQ UIN: 91943513