v9n12ny

Introducere

Evolutia sistemelor de operare a capatat o dinamica crescuta incepind cu anii '90. Puternice firme comerciale, ca IBM, Microsoft, DEC, Sun Microsystem si USL (Novell's Unix System Laboratories), s-au angajat in dezvoltarea de noi sisteme de operare care sa revolutioneze ceea ce exista in prezent. Calculatoarele desktop au devenit mai puternice decit poate fi gestionat de catre sistemul de operare DOS, chiar cu Windows instalat deasupra (cele mai cunoscute si vindute sisteme de operare). Avind in vedere aceasta discrepanta de acoperit, intre posibilitatile resurselor hardware si functiile sistemelor de operare clasice, s-au creat premisele pentru aparitia altor sisteme de operare. De asemenea, in universitati sunt elaborate sisteme de operare ce includ tehnici avansate: MINIX cu extensia Amoeba, Oberon, Spring etc. Aceste sisteme nu prezinta pretentii comerciale, ci medii de studiu a functionalitatilor la nivelul mecanismelor.
Evident, noile sisteme de operare trebuie sa poata rula programe DOS si Windows si in plus sa ofere facilitati atractive. Rezultatul este o schimbare profunda in modul de abordare a proiectarii, dezvoltarii si intretinerii sistemelor de operare. De asemenea se schimba si modul de interactiune al utilizatorului, in sensul cresterii indenpendentei unei aplicatii fata de sistemul de operare
(OS/2 ofera deja aceasta facilitate). Este posibila si inglobarea diverselor functii sistem intr-o aplicatie care are posibilitatea de a executa o gama mult mai variata de operatii (obiectivul propus de OpenDoc al lui Apple si IBM precum si OLE al lui Microsoft). Trebuie observat ca proiectantii de sisteme de operare nu au modele in alegerea noilor facilitati si capabilitati astfel ca se creaza noi paradigme din mers. Se observa, de asemenea, lipsa unei clarificari in utilizarea sistemelor de operare in viitor. O cauza ar putea fi influenta experientei in proiectarea vechilor sisteme de operare, orientate mainframe, la care care utilizatorul final putea accesa resursele unui sistem de calcul numai in cadrul unei aplicatii. Doar administratorii sau managerii de sistem puteau avea acces la resurse, ei controlind tot sistemul. Sistemele erau orientate pe interfata linie de comanda ceea ce necesita memorarea sau apelarea permanenta a manualelor. Deci, sistemele de operare respective erau destinate specialistilor. Este clar ca in prezent un sistem de operare trebuie sa se adreseze oricarui utilizator. Centrul de greutate s-a mutat dinspre hardware spre utilizator. Inceputul acestei mutatii a fost realizarea unei interfete grafice utilizator - GUI (icoane, ferestre, butoane, cutii de dialog, etc). Astazi se considera ca exista trei principii generale pentru proiectarea unui sistem de operare :

- satisfacerea joburilor utilizatorilor transparent pentru ei si pe cit posibil fara a invata prea multe despre sistemul de operare;
- sistemele de operare au un ciclu de viata de aprox 20 de ani;
- conectivitatea si comunicatiile sunt o posibila cauza si efect a cresterii puterii si nevoii de calcul. Inteligenta de a comunica trebuie inglobata astazi in sistem, permitind o distribuire a insusi sistemului de operare pe mai multe masini precum si alocarea resurselor pentru un anumit task indiferent unde se afla ele.

De exemplu, cind a fost proiectat UNIX (sfirsitul anilor '60, inceputul anilor '70), cel mai cunoscut SO (sistem de operare), invatat in atitea facultati ca state of the art in materie, nu au fost avute in vedere principiile de mai sus (vezi preluarea comenzilor scurte in linia de comanda cu destul de multe optiuni, ceea ce face anevoioasa memorarea lor de un utilizator obisnuit).
Programatorii si specialistii aveau nevoie insa de comenzi cit mai scurte pentru a nu pierde timpul. Dar UNIX este vechi si din punctul de vedere arhitectural. Stratificarea functionala realizata era un pas major fata de alte sisteme de operare similare in acea perioada dar o modificare in sistem era o treaba destul de anevoioasa. Proiectantii nu si-au pus problema unor extensii si modificari continui ce vor fi aduse sistemului. Orice upgrade s-a facut pornind de la SO de baza: comunicatii si interconectivitate prin protocolul TCP/IP (Transmission Control Protocol/Internet Protocol), sistem de fisiere in retea NFS (Network File System), interfata grafica utilizator
X-Windows precum si procesare distribuita prin RPC (Remote Procedure Call).
Modificari viitoare vor fi si mai greu de facut.

Apare in mod evident problema schimbarii arhitecturii sistemelor de operare de la un sistem monolit rezident partial sau total in memorie, si care este lipsit de flexibilitate si adaptabilitate, la o arhitectura microkernel
(micronucleu) definita prin structurare, simplitate si distributie. De fapt, preocuparile marilor firme producatoare de SO converg catre trei teme majore:

- microkernel + distribuit;
- utilizarea conceptului de obiect;
- personalitati (servicii).

De exemplu, in Windows NT subsistemele de pe diverse nivele comunica prin mesaje (message passing) prin intermediul microkernelului. Totusi NT nu are o arhitectura microkernel standard, astfel ca toate serviciile neesentiale sa ruleze in mod neprivelegiat (user). IBM, USL si altii sustin ca executivul NT, un subsistem deasupra microkernelului NT ce realizeaza securizarea, I/O si alte servicii in mod privelegiat (kernel) nu este un SO bazat pe microkernel. Pe de alta parte, Microsoft sustine ca de vreme ce subsistemele executive ce ruleaza in mod privelegiat comunica cu microkernelul propriu-zis prin mesaje, ca si subsistemele din modul user, atunci arhitectura este de tip microkernel.
Workplace, shell-ul sistemului de operare OS/2 al lui IBM bazat pe nucleul
Mach este realmente un microkernel deoarece lasa gestiunea paginilor, planificarea, securizarea, sistemul de fisiere si chiar componente importante din drivere I/O importante la latitudinea utilizatorului (mod user). Astfel
IBM spera ca microkernelul sau sa fie folosit de OEM (producatori autorizati de firma) la producerea de software specific intr-o platforma IBM. USL, care foloseste microkernelul Chorus, sustine ca toate serviciile pot fi rulate atit in modul kernel cit si user ceea ce ofera un avantaj pentru fiecare, permitind performanta in modul kernel si flexibilitate in modul user.
Exista doua cai prin care calculatoarele isi pot spori capacitatea de prelucrare si memorare: pe de o parte procesoare cit mai puternice si memorie interna si externa cit mai mare, iar pe de alta parte cresterea conectivitatii calculatoarelor, permitind cooperarea in realizarea unor performante superioare fiecaruia in parte. Prima directie duce la sisteme centralizate tot mai puternice iar a doua duce la sisteme distribuite. Realitatea face ca multe operatii ce compun o activitate sa fie dispersate geografic, astfel ca avantajele ce decurg din conectarea PC-urilor ce realizeaza operatiile respective nu mai trebuie subliniata: datele sunt accesibile tuturor precum si dispozitive ca imprimante, scannere, fax(modemuri, CD-ROM-uri etc. Sistemul poate lucra si prin scoaterea partiala din folosinta a unor echipamente. Problemele ce apar nu sunt putine: securitate, compatibilitate intre SO-uri de pe diversele PC-uri, protocoale de comunicatii etc. Este clar ca un microkernel distribuit ca subsistem de nivel 0 care sa permita pina si incarcarea unor SO clasice ar rezolva multe probleme. Tehnologia microkernel creeaza o fundatie solida sistemelor modulare care astfel se pot extinde dar nu garanteaza rezultatele.
Desigur si MS-DOS poate fi privit ca un SO tip microkernel caruia i se fac extensii in directia conectivitatii sau GUI (Windows). Insa, toata lumea stie ca apar probleme cu TSR-urile, drivere, gestiunea memoriei. Este nevoie in mod clar de o abordare OO in proiectarea SO, astfel ca cel putin sa existe o disciplina in modul de adaugare a extensiilor. De asemenea, multe din SO distribuite merg mina in mina cu tehnologia OO. Firmele mari, Microsoft, Apple,
IBM, Novell/USL trec la tehnologia OO pentru sistemele lor de operare.
Principala caracteristica a obiectelor care le face utile din punctul de vedere al unui SO este incapsularea. Este posibil astfel o abordare de tipul OLE
(Object Linking and Embedding) de la Microsoft care nu ar fi posibila printr-o reprezentare a datelor bazat pe fisiere. Obiectele sunt unitati de cod si date care comunica intre ele prin transmiterea si receptia de mesaje. Intr-un SO OO mesajele fac legatura intre date si metodele de prelucrare a lor. Construite corect, obiectele intr-un sistem sunt interschimbabile permitind utilizarea atit a obiectelor remote (la distanta) cit si locale. Modularizarea sistemului este evidenta, transferul de date nemaifiind dependent de apelul unei proceduri.

Problema de rezolvat este numirea si regasirea obiectelor intr-o retea prin servicii speciale asupra directoarelor. Datorita naturii uniforme a obiectelor nu putem sti cu siguranta unde se afla ele si, deci, nici datele incapsulate.
Ele vor fi transferate insa prin functii ale microkernelului acolo unde rata de accesare este mare, realizindu-se o flexibilizare a localizarii prin transparenta stocarii. O alta problema ce apare este realizarea securizarii prin validarea sau invalidarea comunicatiei inter obiecte prin autentificarea mesajelor si protocoale criptografice. Sa aruncam o privire asupra eforturilor realizate in acest domeniu. Shell-ul lui IBM din OS/2, Workplace, este realizat OO, fundatia fiind modelul SOM (System Object Model). Tehnologia IBM a evoluat si acum exista DSOM (Distributed SOM), avind extensii specifice lucrului in retea.
SOM 1.0 este o extensie a SO care ofera mecanisme OO cum ar fi mostenirea si distribuirea metodelor. Limbajele OOP traditionale cum ar fi Smalltalk sau C++ nu pot crea obiecte reutilizabile utilizind proceduri din alte limbaje. SOM 2.0 ofera mostenirea multipla (locala si remote) si un limbaj de definire a interfetelor conform cu ultimul standard elaborat de Object Management Group. DSOM poate comunica cu protocoale ca TCP/IP, IPX, NetBios, oferind un nivel de indirectare suplimentar celui standard RPC (Remote Procedure Call). Cu RPC putem face apeluri locale ce sunt transformate in apeluri la distanta. Cu DSOM apelurile locale si cele la distanta sunt distribuite prin tabele de metode, informatii privind rutinele de la distanta existind astfel in memoria locala ceea ce micsoreaza traficul in retea. In paralel cu SOM, IBM sustine eforturile de dezvoltare si impunere a
DCE (Distributed Computing Environment) distribuit de OSF. DCE este o arhitectura conceputa pentru proiectare distribuita pe platforme eterogene.
Se ofera un mecanism RPC, securitate si autentificare prin preluarea unor functii din Kerberos de la MIT, servicii de timp si sincronizare, de directoare si multiprocesare prin fire (threads) din OS/2 de la IBM. Impunerea acestui mediu depinde de folosirea lui de companii precum Microsoft sau Novell. O alta tehnologie care trebuie amintita este OLE 2.0 de la Microsoft in care centrul de greutate cade asupra documentelor si nu asupra aplicatiilor care le-au creat.
Tehnologia permite tehnica drag&drop asupra obiectelor. OLE 2.0 nu permite insa executia la distanta (remote execution) si nu permite utilizarea datelor din mai multe platforme ca UNIX, OS/2 (recent permite din Mach). Arhitectura de obiecte de la Microsoft se va baza pe modelul COM (Component Object Model). Prin COM, aplicatiile client OLE pot apela aplicatii server rulind oriunde in retea, de pe orice platforma care suporta ORB de la DEC. Cind un client Windows genereaza un apel de functie OLE, acesta este convertit intr-un RPC compatibil DCE si transmis in retea. ORB-ul (Object Request Broker) preia apelul si il distribuie spre server, generind apoi rezultatul care va fi transmis prin RPC inapoi.
Diferenta intre modelele OO SOM si COM este in principal in modul de realizare a mostenirii. Daca SOM trateaza mostenirea in modul clasic, COM ofera un mecanism numit agregare, care cere obiectelor in mod explicit includerea de pointeri la obiectele de pe nivele ierarhice superioare.

Mostenire Agregare
³ ³
\/ \/
ÚAAAAAAAA¿ ÚAAAAAAAAA¿
³ ORB ³ ³ ORB ³
AAAAAAAAAÙ AAAAAAAAAAÙ
\ \³/
ÚAAAAAAAA¿ \ ÚAAAAAAAAA¿
³ obiect ³ \ ³ obiect ³
AAAAAAAAAÙ \ AAAAAAAAAAÙ
\ \
ÚAAAAAAAAAAAAAAAA¿ ÚAAAAAAAAAAAAAAAA¿
³Clasa de baza ³ ³Clasa de baza ³
³continind metoda³ ³continind metoda³
³selectata ³ ³selectata ³
AAAAAAAAAAAAAAAAAÙ AAAAAAAAAAAAAAAAAÙ

fig. 1 - conceptul de mostenire la OO SOM si COM.

Este anuntat OLE 3.0 distribuit, care are posibilitatea de a memora si regasi obiectele. NT 4.0 Cairo va fi construit in intregime pe baza lui OLE 3.0, componentele SO avind posibilitatea de a fi incarcate si descarcate dupa dorinta.
O alta inovatie la NT 4.0 va fi OFS, sistem de fisiere OO. Obiectele OLE vor putea fi memorate intr-o baza de date de obiecte pentru a putea fi usor regasite la nevoie. Se vor putea face interogatii pe baza unor liste de proprietati fara a mai consulta fiecare fisier in parte. Ca raspuns la tehnologia foarte puternica OLE, mai multe firme dintre care IBM si Apple s-au unit pentru a dezvolta o noua tehnologie numita OpenDoc care promite un cadru OO pentru dezvoltarea aplicatiilor ce opereaza pe platforme multiple si cu SO distribuite. OpenDoc va ingloba mai multe tehnici printre care DSOM de la IBM, Bento de la Apple si standardul industrial CORBA (Common Object Request Broker Architecture).
Consortiul OpenDoc este similar cu consortiul X sustinut tot de IBM in realizarea unui standard de sisteme deschise (pot fi implementate independent de producatori diferiti de hardware). Merita amintit aici SO OO realizate deja: NextStep al firmei Next care anunta versiunea PDO (Portable Distributed Objects) precum si
Taligent, SO realizat din conlucrarea IBM/Apple/Taligent.

Elemente ale structurii

Conceptia, realizarea si intretinerea unui sistem de operare distribuit reprezinta o activitate dificila si costisitoare, datorita dimensiunii si complexitatii problemelor (vezi cele de mai sus). Abordarea eficienta a aplicatiilor, in continua diversificare si crestere a complexitatii lor, impune SOD (sistem de operare distribuit) prin intermediul caruia se executa, sa poata fi utilizat prin intermediul modulelor sale de baza fara alterari de performanta sau cost si independent de platforma. Pentru aceasta SOD trebuie sa aiba flexibilitatea si modularitatea care permite configurarea transparenta a unor servicii specifice, adaptate cerintelor utilizatorului si resurselor distribuite, eterogene si cu facilitati de prelucrare diferite. Apare necesitatea unei noi viziuni de SOD, aceea de sistem deschis construit in jurul unui sistem minimal numit microkernel (micronucleu) si prevazut cu un ansamblu de servicii, facilitati. Compararea si evaluarea caracteristicilor microkernelurilor SO sau

SOD cunoscute in prezent va duce la desprinderea specificatiilor optime in proiectarea si realizarea unui sistem microkernel distribuit.
Pina la propunerea modelului microkernel, SO se bazau pe un nucleu indivizibil, rezident in memorie, monolitic si care oferea servicii aplicatiilor ce rulau in sistem. Ierarhizarea era stricta, serviciile sistemului fiind divizate pe nivele ce puteau comunica numai cu nivelele adiacente. Existau astfel servicii de control al proceselor, drivere de I/O, sistemul de fisiere, gestiunea memoriei, securitatea datelor, servicii de retea, etc. (exemplu tipic UNIX). Un astfel de nucleu devenea foarte mare si greu de controlat, mai ales in ceea ce priveste introducerea/eliminarea de noi servicii sau nivele, deoarece punctele de legatura erau foarte numeroase. Pentru a rezolva aceasta problema proiectantii de SO au recurs la tehnica microkernel in care ierarhizarea nu se mai face pe verticala ci pe orizontala. Diversele componente ale sistemului comunica unele cu altele prin intermediul apelurilor de sistem catre MK
(microkernel), iar acesta valideaza si transmite mesajele, permitind si accesul la hardware. Adaugarea/eliminarea unei componente in sistem nu necesita re-linkarea MK. Mai mult, mai multe MK pot actiona ca un singur sistem multiprocesor scalabil. In cadrul MK sunt incluse servicii care trebuie sa ruleze in mod privilegiat, cum ar fi cele de administrare a memoriei (sau o parte), gestiunea intreruperilor, planificarea proceselor pentru executie, transmiterea de mesaje. Restul serviciilor, inclusiv driverele, pot fi in afara
MK partial sau total, incarcabile dinamic. Ceea ce ramine in MK reprezinta serviciile absolut necesare care ar fi prea costisitor de implementat in alta parte. Daca un proces are nevoie sa citeasca dintr-un fisier, el va trimite un mesaj prin intermediul MK catre un alt proces, rulind tot in spatiul utilizator si care functioneaza ca server de fisiere. Acest proces-server va realiza operatia si va transmite rezultatul la procesul apelant tot prin intermediul mesajelor. Avantajul metodei este evident: exista o interfata bine definita pentru fiecare serviciu (un set de mesaje pe care serverul pentru serviciul respectiv il intelege) in timp ce serviciile sunt echi-disponibile fiecarui client, indiferent unde se gaseste acesta. Apare astfel evidenta usurinta instalarii de noi servicii, monitorizarea si protejarea lor. Utilizatorii care nu sunt multumiti de facilitatile serviciilor au posibilitatea scrierii si instalarii de servicii proprii. Un exemplu ar fi existenta simultana a doua servere de servicii de fisiere intr-un sistem distribuit, unul pentru DOS altul pentru UNIX. Pentru un sistem monolitic acest lucru nu este posibil. Nucleele monolitice au insa in aparenta o superioritate in ce priveste performatele.
Studiile de evaluare a performantelor, care vor fi efectuate, vor demonstra ca timpul pierdut cu schimbul de mesaje este neglijabil in raport cu cistigul unei mari parti a memoriei. De asemenea, eficienta transmiterii mesajelor va fi optimizata prin algoritmii propusi.
Deci, o arhitectura MK are ca principal avantaj scalarea sistemului, putindu-se incarca numai acele servicii necesare rularii aplicatiei. Un MK poate fi incarcat si in memoria cache, crescind considerabil viteza de raspuns, poate fi incapsulat in memorii ROM pentru aplicatii industriale, sau permite optimizarea scrierii unor aplicatii distribuite.
MK este un nucleu de SO ce constituie baza pentru extensii portabile, modulare. Orice SO din generatia urmatoare va fi construit pe un MK, dar exista diferente de opinii relativ la serviciile care sa apartina sau nu MK.
Problemele sunt de tipul:

- cum trebuie proiectate drivere I/O astfel ca sa avem cele mai bune performante ale echipamentelor in acelasi timp cu abstractizarea functiilor fata de hardware ?
- daca sa se execute servicii non-kernel in spatiu user sau kernel ?
- daca sa se mai pastreze ceva din SO existente sau sa se construiasca de la zero ?

MK este o colectie de servicii dintr-un nucleu de SO care conceptual sunt separate de serviciile auxiliare (obisnuite) sau aplicatii. MK asigura interfete bine definite cu serviciile auxiliare, astfel ca acestea sa poata transfera simplu date prin mesaje cu serviciile din MK (esentiale), sau intre ele. MK valideaza mesajele, le transfera intre diverse servicii si face accesul la hardware. Arhitectura MK este foarte potrivita pentru calculul distribuit.
Mecanismul de transfer al mesajelor este o baza solida pentru RPC. Dimensiunea este in jur de 50-70 KB, la Windows NT, sau 8 KB la QNX. In cadrul serviciilor auxiliare regasim: sistemul de fisiere, interfata grafica, securitatea.
Serviciile esentiale sunt cele puternic dependente hardware: intreruperi, planificarea/sincronizarea proceselor si alocarea resurselor (inclusiv suport pentru arhitecturi multiprocesor), comunicatia. Dupa cum am mai mentionat driverele pot ramine in afara sau pot fi partial incluse in MK. Unele implementari
(OSF-Mach) localizeaza driverele in MK, iar altele (Chorus) in afara lui, cu conditia ca o zona de cod aferenta driverului sa ruleze in spatiul kernel pentru a dezactiva si apoi rearma intreruperile. In NT, driverele ruleaza in spatiul kernel doar pentru a rezolva intreruperile. Arhitectul sef pentru

Workplace-ul lui IBM, Paul Giangarra, declara ca numai separarea driverelor de
MK permite o configurare dinamica. De exemplu, un driver performant pentru un anumit SGBD nu va putea fi incarcat decit daca avem MK cu solutia de mai sus.
Trei sunt caracteristicile esentiale ale unei arhitecturi MK:

- portabilitatea;
- extensibilitatea (modularitate, flexibilitate);
- siguranta.

Avind tot codul specific unui procesor izolat in MK, schimbarile pentru trecerea la un alt procesor sunt clare si grupate logic. De asemenea, arhitecturile multiprocesor devin o investitie mai rentabila si deci atractiva in contextul unui SO cu MK. Cu toate ca Intel detine suprematia la capitolul proiectare arhitecturi multiprocesor, IBM, Motorala, DEC, Mips si Sparc fac eforturi pentru a avea o pozitie pe piata. Extensibilitatea este unul din dezideratele majore ale unui SO modern. In timp ce hardware-ul se schimba de la an la an, un SO are o durata de viata mult mai mare, de decade, timp in care trebuie adaugate facilitati care nici nu se banuie la momentul actual. Proiectantii de SO au invatat lectia aceasta din experienta DOS-ului sau UNIX-ului de pilda.
Aceeasi problema apare cind anumite facilitati trebuie scoase, ca de exemplu limitarea la 16 MB de memorie sau 70 MB hard-disk minim pentru NT. Siguranta oferita de MK provine din numarul si calitatea apelurilor API oferite programatorilor atit de sistem cit si de aplicatii. Dupa cum se stie SO actuale ofera fiecare sute de apeluri API dintre care multe sunt nedocumentate, consecinta a imposibilitatii testarii SO pentru toate situatiile, avind in vedere dimensiunea de sute de mii de linii a unui SO. Practic multe apeluri sunt putin sau deloc folosite. Astfel, un numar mic de apeluri compacte, clare si bine documentate ceeaza un suport excelent pentru programatorii de sistem in realizarea serviciilor auxiliare (aprox 200 la MK IBM+OSF, 14 la QNX). In continuare, programatorii de aplicatii vor avea sute de apeluri la dispozitie provenind din interfetele serviciilor auxiliare.
Prima introducere comerciala serioasa a unui SO bazat pe MK, Mach a fost facut de NeXT. In practica, cu toata modularitatea si flexibilitatea oferite de nucleul privelegiat inconjurat de servicii in mod user, datorita serverului
BSD 4.3 pentru compatibilitate UNIX, avantajele nu erau cele asteptate. Un pas in plus a fost facut de NeXT, cu permisiunea lui Mach, prin introducerea mecanismului message-passing si a serviciilor interfata utilizator cu grafica in cazul comunicatiei, administrarea sistemului, toate realizate OO. Windows NT a exploatat si portabilitatea in afara de modularitatea MK-urilor. NT a fost proiectat pentru a rula pe Intel, Alpha, Mips, PowerPC configurate cu unul sau mai multe procesoare. Arhitecturi MK utilizeaza Novell/USL, OSF (Open Software
Foundation), IBM, Apple. Competitorul principal al lui NT este Mach-ul de la
Carnegie Mellon, preluat comercial de OSF (OSF(1) si IBM (Workplace). Alt MK este Chorus de la Chorus Systems, preluat de USL precum si propriul sistem MiX.
De asemenea, succesorul lui Solaris al firmei Sun va fi SpringOs, iar MK de la
Taligent Operating Environment, complet OO, este folosit de Apple si IBM in dezvoltarea SO Workplace, succesor al lui OS(2 precum si de Taligent separat la Mac System 7. Trebuie amintit aici doua MK-uri, QNX si CTOS, ale firmelor
QNX Software si Unisys, care ani de zile au vindut sistemele lor in medii timp-real respectiv bancar.

Odata cu aparitia microprocesoarelor , SO si tehnologiilor de retea pe
32 biti, calculatoarele personale au putut oferi o platforma buna pe care sa se ruleze aplicatii care pina nu de mult existau numai pe minicalculatoare sau mainframe-uri. Prima si poate cea mai importanta cerinta pentru migrarea catre noile sisteme este pastrarea compatibilitatii "in jos" (sa poata executa tot ce vechiul sistem putea sa execute) si sa functioneze pe suportul hardware existent.
Experienta arata ca sistemele care nu respecta aceste cerinte sunt eliminate usor de pe piata - exemplu Windows 2.x si OS/2 1.x
Avind in vedere tendintele de evolutie, putem stabili citeva din caracteristicile viitoarelor SO. Astfel, statia client va trebui nu numai sa poata rula software-ul existent, dar sa si ofere un API (Applications Programming Interface) portabil, scalabil si independent de platforma care sa includa servicii pentru retea, multitasking, protectie, memorie virtuala si comunicare intre procese. Serverul va trebui sa ofere toate facilitatile statiei client si chiar mai mult. Va trebui sa poata partaja resurse ca fisirere, imprimante, scannere, fax/modemuri si sa suporte standarde precum OSI, SNA, TCP/IP, Appletalk, Novell, Lan Server,
Lan Manager, Banyan-Vines.
Scalabilitatea sau posibilitatea de a functiona intr-o gama foarte larga de configuratii si interoperabilitatea (posibilitatea de a functiona intr/un mediu ce contine sisteme eterogene) reprezinta criteriile esentiale ce diferentiaza SO client/server. Criteriile ce trebuie avute in vedere la compararea mai multor
SO pot fi :

- multitaskingul
- utilizarea facila a interfetei grafice (GUI)
- scalabilitatea
- interoperabilitatea
- integritatea sistemului
- compatibilitatea cu sisteme existente
- administrarea sistemului si functii de retea
- securitatea
- suportul tehnic

Tema :

- puneti in evidenta principalele caracteristici ale unui viitor SO
- analizati si completati prin informatii suplimentare termenii :
SO, MK, GUI, OLE, DCE, DDE, ORB, CORBA, TCP/IP, IPX/SPX, NetBios, NFS, RPC