C01

  • July 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View C01 as PDF for free.

More details

  • Words: 2,587
  • Pages: 8
Sisteme de operare Scurtă descriere VC ++ poate fi utilizat pentru a dezvolta programe pentru trei platforme Win32: Windows NT (pe procesoare multiple), Windows 95/98 si Win32s. Windows NT este un SO multifir (multithreaded ) pe 32 biti cu mediu grafic integrat si posibilitati de server avansate. A fost dezvoltat pentru a maximiza portabilitatea, stabilitatea si securitatea. Subsistemul Win32s este un alt nivel pentru Windows 3.1; acesta implementeaza un subset al sistemului Win32 care permite executia aplicatiilor pe 32 biti. Windows 95 mosteneste o parte semnificativa de cod de la Windows 3.1. Asigura o compatibilitate pentru aplicatiile scrise pentru Windows 3.1.

Windows şi Mesajele Windows este referit adesea ca un sistem de operare bazat pe mesaje. Fiecare eveniment (apasarea unei taste, clic de mouse, etc.) este transformat într-un mesaj. In mod obişnuit aplicaţiile sunt construite în jurul unei bucle de mesaje care regăseşte aceste mesaje şi apelează funcţia potrivită pentru a trata mesajul. Mesajele, deşi sunt trimise aplicaţiilor, nu se adresează acestora, ci unei alte componente fundamentale a SO, fereastra (windows). O fereastra este mai mult decât o zonă dreptunghiulară afişată pe ecran; aceasta reprezintă o entitate abstractă cu ajutorul căreia utilizatorul şi aplicaţia interacţionează reciproc.

Aplicaţii, Fire şi Ferestre O aplicaţie Win32 constă din unul sau mai multe fire (threads), care sunt căi paralele de execuţie. Gândim firele ca fiind multatsking-ul din cadrul unei aplicaţii. Observaţie: Sub Win32s, poate rula o aplicaţie cu un singur fir de execuţie. O fereastră este totdeauna “gestionată de” un fir; un fir poate fi proprietarul uneia sau mai multor ferestre sau pentru nici una. In final, ferestrele sunt într-o relaţie ierarhică; unele sunt la nivelul cel mai de sus, altele sunt subordonate părinţilor lor, sunt ferestre descendente.

Procese, fire şi ferestre Exista mai multe tipuri de ferestre in Windows; cele mai obişnuite sunt asociate cu o aplicaţie. Boxele de dialog din cadrul unei ferestre sunt de asemenea ferestre. Acelaşi lucru pentru butoane, controale de editatre, listbox-uri, icoane, etc.

Clase Window Comportarea unei ferestre este definita de clasa fereastră (window class). Clasa fereastră menţine informaţii despre modul de afişare iniţial, icoana implicită, cursor, resursele meniu şi cel mai important lucru adresa funcţiei ataşată ferestrei – procedura fereastră – window procedure. Când o aplicaţie procesează mesaje, aceasta se face în mod obişnuit prin apelul funcţiei Windows DispatchMessage pentru fiecare mesaj primit; DispatchMessage la rândul ei apelează procedura fereastră corespunzătoare, identificând iniţial cărei ferestre îi este trimis mesajul. În continuare procedura fereastră va trata mesajul. Există mai multe clase fereastră standard furnizate de Windows. Aceste clase sistem globale implementează în general funcţionalitatea controalelor comune. Orice aplicaţie poate folosi aceste controale, de exemplu orice aplicaţie poate implementa controale de editare, utilizând clasa fereastra Edit. Aplicaţiile pot de asemeni să-şi definească propriile clase fereastră cu ajutorul funcţiei RegisterClass. Acest lucru se întâmplă în mod obişnuit pentru fereastra principală a aplicaţiei (icoana, resurse, etc.). Windows permite de asemeni subclasarea sau superclasarea unei ferestre existente. Subclasarea substituie procedura fereastră pentru o clasă ferestră cu o altă procedură. Subclasarea se realizează prin schimbarea adresei procedurii fereastră cu ajutorul funcţiei SetWindowLong (instance subclassing) sau SetClassLong (subclasare globală). Instance subclassing – înseamnă că se schimbă numai comportarea ferestrei specificate. Global subclassing – înseamnă că se schimbă comportarea tuturor ferestrelor de tipul specificat.

Observaţie: Global subclassing se comporăţ diferit in Win32 şi în Windows pe 16 biţi (Win32s). In cazul Win32, aceasta afectează numai fereastra care este sub controlul aplicaţiei ce face subclasarea; în windows pe 16 biţi, efectul este global, se afectează ferestrele fiecărei aplicaţii. Superclasarea crează o nouă clasă bazată pe o clasă existentă, reţinând numai procedura fereastră. Pentru a superclasa o clasă fereastră, o aplicaţie regăseşte informaţiile despre clasa fereastră utilizând funcţia GetClassInfo, modifică structura WNDCLASS astfel recepţionată şi foloseşte structura modificată într-un apel al funcţiei RegisterClass. GetClassInfo întoarce de asemenea şi adresa procedurii fereastră. Mesajele pe care noua fereastră nu le tratează trebuie trecute acestei proceduri.

Tipuri de mesaje Mesajele reprezintă în fapt evenimente la diferite nivele ale aplicaţiei. Există o clasificare a acestor mesaje (din păcate nu prea exactă): mesaje fereastră, mesaje de notificare şi mesaje de comandă, dar deocamdată nu ne interesează acest lucru. Mesajele windows constau din mai multe părţi, descrise de structura MSG. typedef struct tagMSG { HWND hwnd; UINT message; WPARAM wParam; LPARAM lParam; DWORD time; POINT pt; } MSG; Descriere: hwnd identifică în mod unic fereastra la care a fost transmis acest mesaj. Fiecare fereastră în Windows are un asemenea identificator. message reprezintă identificatorul mesajului. Identificatorii mesajului sunt referiţi în mod obişnuit cu ajutorul constantelor simbolice decât prin valoarea lor numerică care o au în sistem. Această descriere se găseşte în windows.h. Următoarele elemente pot fi privite ca parametrii ai mesajului, care au valori specifice funcţie de fiecare mesaj în parte. Marea majoritate a mesajelor încep cu WM_. De exemplu WM_LBUTTONDOWN, WM_MOUSEMOVE, WM_LBUTTONUP, etc. Aplicaţiile pot să-şi definească propriile mesaje. Cerinţa majoră este ca identificatorul mesajului să fie unic. Pentru a defini un mesaj în sistem folosim funcţia RegisterWindowMessage.

Mesaje şi multitasking In Windows 3.1, bucla de mesaje are rol important în interacţiunea dintre aplicaţii şi SO. Funcţionarea corectă a unui SO Windows 3.1 depinde de cooperarea dintre aplicaţii. Aplicaţiile sunt cele care permit SO să preia controlul. Acest neajuns este înlăturat în Windows 95/98, NT, 2000. SO este cel care realizează programarea aplicaţiilor pentru cuantele de timp necesare pe procesor. Deşi această planificare a execuţiei este diferită pe Windows 95/98 faţă de NT, rolul primordial revine SO.

Cozi de mesaje În Windows pe 16 biţi, SO menţine o singură coadă de mesaje. Când o aplicaţie încearcă să găsească următorul mesaj din coada de mesaje prin funcţiile GetMessage sau PeekMessage, SO poate efectua un context switch şi poate activa o altă aplicaţie pentru care mesajele aşteaptă în coadă. Mesajul din vârful cozii este extras şi returnat aplicaţiei via structura MSG. Dacă aplicaţia eşuează în apelul lui GetMessage, PeekMessage sau Yield, aceasta blochează sistemul. Coada de mesaje poate deveni plină... În Win32 (95/98, NT, 2000) mecanismul cozii de mesaje este mult mai complicat. O singură coadă de mesaje nu mai rezolvă problema. Aici sistemul de operare dă controlul unei aplicaţii şi tot SO permite multitasking-ul. Două sau mai multe fire pot accesa coada de mesaje în acelaşi timp şi nu există nici o garanţie că mesajele extrase sunt ale lor. Acesta este unul motivele pentru care coada de mesaje a fost separată în cozi de mesaje individuale pentru fiecare fir din sistem.

Procese şi Fire Într-un SO non-multifir, de exemplu UNIX, unitatea cea mai mică de execuţie este task-ul sau procesul. Mecanismul de planificare (aparţine SO) al task-urilor va comuta între acestea; multitasking-ul se realizează între două sau mai multe procese (task-uri). Dacă o aplicaţie are nevoie să execute mai multe funcţii simultan, atunci aceasta se va divide în mai multe task-uri. Din această tehnică decurg anumite neajunsuri, consum de resurse, timp de lansare a unui nou task, spaţii de adrese diferite, probleme de sincronizare, etc. În contrast, într-un sistem multifir (multifilar, multithreaded) unitatea cea mai mică de execuţie este firul, nu procesul. Un proces sau task poate conţine mai multe fire, dintre care unul singur este firul principal, firul primar. Lansarea în execuţie a unui nou fir cere mai puţine resurse din partea SO, firul rulează în cadrul aceluiaşi proces, problemele de sincronizare sunt şi nu sunt complicate. Oricum apar două sincronizări: sincronizare între procese şi sincronizare între fire.

Fire şi Mesaje După cum am mai spus proprietarul ferestrei este firul de execuţie. Fiecare fir are coada proprie, privată, de mesaje în care SO depozitează mesajele adresate ferestrei. Aceasta nu înseamnă că un fir trebuie neapărat să aibă o fereastră proprie şi o coadă proprie de mesaje. Pot exista fire şi fără fereastră şi fără buclă de mesaje. În MFC, aceste fire se numesc worker threads (nu au ataşată o fereastră, nu prezintă interfaţă către utilizator), iar celelalte se numesc user-interface threads.

Apeluri de funcţii Windows Windows oferă un mare număr de funcţii pentru a executa o mare varietate de task-uri, controlul proceselor, gestionarea ferestrelor, fişierelor, memoriei, servicii grafice, comunicaţii, etc. Apelurile sistem pot fi organizate în trei categorii: 1. servicii nucleu (apeluri sistem pentru controlul proceselor, firelor, gestiunea memoriei, etc.); 2. servicii utilizator (gestiunea elementelor de interfaţă ale utilizatorului cum ar fi ferestre, controale, dialoguri, etc.); 3. servicii GDI (Graphics Device Interface) (ieşirea grafică independentă de dispozitiv). Sistemul Windows include de asemenea funcţii API pentru alte funcţionalităţi – MAPI (Messaging API), TAPI (Telephony API) sau ODBC (Open Database Connectivity).

Servicii Nucleu Serviciile nucleu cuprind de obicei: getionarea fişierelor, memoriei, proceselor, firelor, resurselor. Gestionarea fişierelor nu ar trebui să se mai facă cu funcţii din bibliotecile C sau prin iostream-urile din C++. Aplicaţiile ar trebui să utilizeze conceptul Win32 de obiect fisier – file object – şi funcţiile asociate cu acesta. De exemplu există fişiere mapate în memorie care asigura comunicarea între task-uri. Referitor la gestionarea memoriei pe lângă funcţiile cunoscute, SO Windows oferă funcţii care pot manipula spaţii de adrese de sute de MB alocându-le dar nefăcând commiting. Cea mai importantă faţetă a proceselor şi firelor este gestiunea sincronizării. Problema este complet nouă şi nu a fost întâlnită în Windows 3.1. În Win32, sincronizarea se face cu ajutorul unor obiecte de sincronizare, pe care firele le pot utiliza pentru a informa alte fire despre starea lor, de a proteja zone senzitive de cod sau de a obtine informatii despre alte fire sau starea altor obiecte. In Win32 multe resurse nucleu sunt reprezentate ca obiecte – obiecte nucleu: fişiere, fire, procese, obiecte de sincronizare, etc. Obiectele sunt referite prin manipulatori, identificatori (handlers); există funcţii pentru manipularea generică a obiectelor, pentru manipularea obiectelor de un anumit tip. Sub NT, obiectele au ataşate proprietăţi de securitate. De exemplu, un fir nu poate accesa un obiect fişier dacă nu are drepturile necesare care să coincidă cu proprietăţile de securitate. Modulul nucleu furnizezză de asemeni funcţii pentru gestionarea resurselor interfaţă-utilizator. Aceste resurse includ icoane, cursoare, şabloane de dialog, resurse string, tabele de acceleratori, bitmap-uri, etc. Nucleul NT furnizează printre altele: atribute de securitate pentru obiectele nucleu, backup, funcţionalitatea aplicaţiilor de tip consolă care pot utiliza funcţii pentru memoria virtuală sau pot utiliza mai multe fire de execuţie.

Servicii utilizator Modulul utilizator furnizează apeluri sistem care gestionează aspecte şi elemente ale interfeţei utilizatorului; sunt incluse funcţii care manipulează ferestre, dialoguri, meniuri, controale, clipboard, etc. Se exemplifică tipurile de operaţii pentru fiecare resursă în parte (în general creare, modificare, ştergere, mutare, redimensionare, etc.). Modulul utilizator furnizează funcţii pentru managementul mesajelor şi cozilor de mesaje. Aplicaţiile pot utiliza aceste apeluri pentru a controla conţinutul cozii de mesaje proprii, a regăsi şi a procesa mesajele, a crea noi mesaje. Noile mesaje pot fi trimise (sent) sau plasate (posted) la orice fereastră. Un mesaj plasat pentru o fereastră – funcţia PostMessage - înseamnă pur şi simplu intrarea acestuia în coada de mesaje nu şi procesarea imediată a acestuia. Trimiterea unui mesaj (sent) implică tratarea lui imediată sau mai corect spus funcţia SendMessage nu-şi termină execuţia pînă când mesajul nu a fost tratat.

Servicii GDI Funcţiile din GDI sunt utilizate în mod obişnuit pentru a executa operaţii grafice primitive independente de dispozitiv pe contexte de dispozitiv. Un context de dispozitiv este o interfaţă la un periferic grafic specific (în fapt este o structură de date păstrată în memorie). Contextul de dispozitiv poate fi utilizat pentru a obţine informaţii despre periferic şi pentru a executa ieşirile grafice pe acest periferic. Informaţiile care pot fi obţinute printr-un context de dispozitiv, descriu în detaliu acest periferic. Ieşirea grafică este executată printr-un context de dispozitiv prin pasarea (trecerea) unui manipulator (identificator) al contextului de dispozitiv funcţiilor grafice din GDI. Contextele de dispozitiv pot descrie o varietate mare de periferice. Contextele de dispozitiv obişnuite includ: contexte de dispozitiv display, contexte de dispozitiv memorie (pentru ieşirea unui bitmap memorat în memorie) sau contexte de dispozitiv printer. Un context de dispozitiv foarte special este contextul de dispozitiv metafile care permite aplicaţiilor de a înregistra permanent apelurile din GDI (fişierul păstrează o serie de primitive grafice) care sunt independente de dispozitiv. Metafişierele joacă un rol crucial în reperzentarea independentă de dispozitiv a obiectelor OLE înglobate.

Desenarea într-un context de dispozitiv se face cu ajutorul coordonatelor logice. Coordonatele logice descriu obiectele utilizând măsurători reale independente de dispozitiv, de exemplu, un dreptunghi poate fi descris ca fiind lat de 2 inch şi înalt de 1 inch. GDI furnizează funcţionalitatea necesară pentru maparea coordonatelor logice în coordonate fizice. Diferenţe semnificative există în modul cum această mapare are loc în Win32s, Windows 95 şi Windows NT. Win32s şi Windows 95 folosesc reprezentarea coordonatelor pe 16 biti. Windows NT poate manipula coordonate pe 32 biţi. Toatre cele trei sisteme suportă mapări (transformări) din coordonate logice în coordonate fizice. Aceste transformări sunt determinate (influenţate) de valorile ce specifică originea coordonatelor şi (signed extent) extensia cu semn a spaţiului logic şi al celui fizic. Originea coordonatelor specifică deplasarea pe orizontală şi verticală, iar extensia (extent) determina orientarea şi scara obiectelor după mapare (transformare). În plus, Windows NT oferă ceea ce se numeşte world transformation functions. Prin aceste funcţii, orice transformare liniară poate fi folosită pentru transformarea spaţiului de coordonate logice în spaţiul de coordonate fizice; în plus pentru translaţii şi scalare ieşirile pot fi rotite sau sheared. Exemple de funcţii grafice: Rectangle, Ellipse, Polygon, TextOut, etc. Alte funcţii de interes deosebit (bit blit functions: PatBlt, BitBlt, StechBlt) sunt cele legate de desenarea şi copierea bitmap-urilor. Contextele de dispozitiv pot fi create şi distruse, starea lor poate fi salvată şi reîncărcată. Un alt grup de funcţii gestionează transformările de coordonate. Funcţii comune tuturor platformelor pot fi utilizate pentru a seta sau regăsi originea şi extent-ul unei ferestre (spaţiul de coordonate logic) şi viewport-ului (spaţiul de coordonate al perifericului destinaţie). NT posedă funcţii specifice pentru transformări matriceale. Funcţiile GDI pot fi folosite de asemenea pentru gestionarea paletelor, aceasta înseamnă că prin gestionarea paletei de culori, aplicaţiile pot selecta o mulţime de culori care se potrivesc cel mai bine cu culorile din imaginea (gif, pcx.) care trebuie afişată. Gestionarea paletei poate fi utilizată şi în tehnici de animaţie. O altă trăsătură a GDI-ului este crearea şi gestionarea obiectelor GDI (pensoane, peniţe, fonturi, bitmap-uri, palete) precum şi a regiunilor şi a clipping-ului.

Alte API-uri • • • • • •

Funcţii pentru controale comune; Funcţii pentru dialoguri comune; MAPI, (Messaging Applications Programming Interface); MCI (Multimedia Control Interface); OLE API; TAPI (Telephony API).

Raportarea erorilor Majoritatea funcţiilor Windows folosesc un mecanism pentru evidenţierea erorilor. Când apare o eroare, aceste funcţii setează o valoare a erorii pentru firul respectiv, valoare care poate fi regăsită cu funcţia GetLastError. Valoarile pe 32 biţi, returnate de această funcţie sunt definite in winerror.h sau în fişierul header al bibliotecii specifice. Valoarea erorii poate fi setată şi din cadrul aplicaţiei cu ajutorul funcţiei SetLastError. Codurile de eroare trebuie să aibă setat bitul 29.

Folosirea funcţiilor din biblioteca C/C++ Aplicaţiile Win32 pot folosi setul standard al funcţiilor din biblioteca C/C++ cu anumite restricţii. Aplicaţiile Windows nu au acces în mod normal la stream-urile stdin, stdout, stderr sau obiectele iostream din C++. Numai aplicaţiile consolă pot utiliza aceste stream-uri. Funcţiile relative la fişiere pot fi folosite, dar acestea nu suportă toate facilităţile oferite de SO Windows – securitate, drepturi de acces. În locul funcţiilor din familia exec se va folosi CreateProcess. În ceeea ce priveşte gestionarea memoriei se folosesc cu succes funcţiile din C sau C++. Funcţiile din biblioteca matematică, pentru gestionarea stringurilor, a bufferelor, a caracterelor, a conversiilor de date pot fi de asemenea folosite. Aplicaţiile Win32 nu trebuie să folosească întreruperea 21 sau funcţii IBM PC BIOS.

Related Documents

C01
June 2020 12
C01
July 2020 3
C01
November 2019 22
C01
May 2020 6
C01
November 2019 20
C00-c01
June 2020 5