Microsoft Foundation Class (MFC) biblioteka se oslanja na programski interfejs Microsoft Windowsa. MFC biblioteka sadrzi klase koje omogucavaju strucnjacima za razvoj softvera da s lakocom prave programe ugradjivanjem veceg dela Windowsovog API-ja u dobro organizovane klase. Zato ce vam razumevanje Windowsovog programskog interfejsa pomoci da razumete i koristite MFC biblioteku.

Prvi deo ove knjige upoznaje vas sa terminima, konceptima i istorijatom proizvoda sa Microsoftovog stanovista. S obzirom da citate ovu knjigu, pretpostavljamo da ste zainteresovani za koriscenje MFC biblioteke kako biste razvili softver koji radi pod Windows okruzenjem. Iako ste mozda u iskusenju da predjete na druga, "vaznija" poglavlja, pazljivo citanje prvog dela ove knjige dace vam siru perspektivu o porodici Windows operativnih sistema.

Prvo poglavlje hronoloski prikazuje razvoj Microsoft Windows API-ja. Dolaskom Windowsa 95, Microsoft je poceo da okrece ledja svom starijem, 16-bitnom API-ju, pod nazivom Win16. U isto vreme Microsoft pocinje da promovise novo 32-bitno okruzenje, Win32 API, kao primarni Windows API. MFC biblioteka skriva mnoge razlike izmedju Win16 i Win32. Zbog toga ce se Win16 program, koji je napravljen uz pomoc MFC biblioteke, mnogo lakse prebaciti na Win32, nego isti takav Win16 program napisan u jeziku C.

Vecina API funkcija je podeljena u tri grupe koje cine jezgro sistema: KERNEL, GDI i USER. U drugom poglavlju saznacete vise o funkcionalnim razlikama izmedju ova tri dela. Takodje cete saznati i o internim strukturama podataka koje svaki deo koristi, a saznacete i kako MFC biblioteka uspeva da ugradi (ili ignorise) osnovne strukture podataka.

Trece poglavlje vas, korak po korak, uvodi u osnove pokretanja i koriscenja razvojnog studija (engl. Developer Studio), Visual C++ programskog okruzenja.

U ovom poglavlju

ekada su strucnjaci za razvoj softvera koji su zeleli da prave programe za rad pod okruzenjem Microsoft Windows morali da pisu na jeziku C. Takvi programi su se povezivali direktno na Windows Application Programming Interface (API), puki skup funkcija operativnog sistema. U to vreme, pored Windows kompatibilnog prevodioca, jedini dostupan razvojni alat je bio Microsoftov Software Development Kit ili SDK.

Ucenje SDK za razvoj Windows programa oduvek je bio tezak i neprijatan zadatak, delom i zbog toga sto zahteva novi nacin misljenja. Graficki izlaz se prilicno razlikuje od izlaza zasnovanog na znacima. Interaktivni, na dogadjajima zasnovani programi mogu "pasti" na nacin na koji sekvencijalno orijentisani "batch" programi nece. Potrebno je i dodatno vreme i napor da se shvati potreba za prihvatanjem svih razlicitih vrsta ulaznih podataka koje ce korisnik poslati programu.

Takodje, morate se navici i na rad sa svim osobenostima objekata korisnickog interfejsa koje obezbedjuje Windows, odnosno: prozorima, menijima, dijalozima, pokazivacima, ikonama itd. Svi ti ugradjeni objekti vam omogucavaju da budete produktivni, kada naucite kako da ih koristite, ali ucenje moze trajati prilicno dugo.

Cak i kad se prilagodite novom nacinu misljenja, primeticete nedovoljno organizacije u pozivima funkcija. Veliki broj poziva funkcija, nekoliko hiljada, otezava pronalazenje onih funkcija koje su vam potrebne. S druge strane, cak i kada ih pronadjete, izgubicete jos vise vremena trudeci se da razumete njihove osobenosti i nedoslednosti.

Strucnjaci za razvoj Windows programa sada imaju siri izbor. SDK programiranje, kako se ponekad zove, i dalje je opcija za C programere. Medjutim, pojavom Windows kompatibilnih Pascal, FORTRAN i COBOL prevodilaca, jezik C vise nije potreban za pravljenje Windows programa. Strucnjaci za razvoj mogu da biraju jezike kao sto su Smalltalk i Basic. Smalltalk je omiljen kod objektno orijentisanih puritanaca. BASIC, dugo smatran za jezik pocetnika, ojacao je i pojavio se u obliku Microsoft Visual Basica, proizvoda koji se koristi za pravljenje malih i srednjih projekata.

Programeri mogu, takodje, koristiti i jezik C++ za pravljenje Windows programa. Sa ugradjenom C kompatibilnoscu, C++ se moze koristiti za programiranje u SDK stilu. Medjutim, ovakva upotreba ne koristi prednosti objektno orijentisanih mogucnosti jezika. Koriscenje ovih mogucnosti zahteva biblioteku klasa koja je napisana da bi pojednostavila neprijatne zadatke i ceste osobenosti zbog kojih je SDK programiranje prava avantura. Nekoliko takvih biblioteka su komercijalno dostupne, ukljucujuci Borlandovu Object Windows Library (OWL) i Microsoft Foundation Class (MFC) biblioteku. MFC biblioteka je, naravno, predmet ove knjige.

Svi jezici i razvojni alati koje mozete koristiti za pravljenje Windows programa imaju jednu zajednicku osobinu: svaki od alata se oslanja samo na izvorni Windows API. Iako izvorni API moze biti osoben i tezak za pisanje koda, on je i dalje jedina veza sa mogucnostima i osobinama operativnog sistema. Zato, boljim razumevanjem API-ja sticete vece znanje o izborima koji su vam dostupni.

Na primer, povremeno cete primetiti da cak i najbolji jezik ili razvojni alat skriva neku mogucnost koriscenja izvornog API-ja. U tim slucajevima obicno cete dobiti ono sto zelite direktnim pozivom izvornih funkcija bez obzira da li pisete u jeziku C++, Visual Basicu ili Smalltalku. Izvorne API funkcije mozete cak pozivati i iz programa kao sto su programi za tabelarne proracune i programi za obradu teksta to je mogucnost koja nikada ne prestaje da nas zapanjuje.

Razumevanje izvornog API-ja moze biti od pomoci bez obzira koji razvojni alat za pravljenje Windows programa koristite. Medjutim, ono je neophodno kada pisete kôd za MFC biblioteku, jer se struktura MFC biblioteke ogleda u strukturi izvornog API-ja. U stvari, MFC biblioteka sadrzi osnovne strukture podataka Windowsa. Mnoge MFC klase imaju funkcije clanice sa imenima koja su identicna imenima izvornih API funkcija. U vecini slucajeva, otkricete da je funkcija clanica MFC klase implementirana kao poziv izvorne API funkcije.

Iako se sve dosad navedeno odnosilo na "izvorni" API, razliciti Windows operativni sistemi podrzavaju dva razlicita programska okruzenja: 16-bitno okruzenje poznato kao Win16 API i 32-bitno okruzenje poznato kao Win32 API. Ova dva API-ja su toliko slicna da je MFC biblioteka kompatibilna sa oba. U stvari, ne samo da je moguce, nego je i prilicno jednostavno napisati MFC program koji mozete prevesti i povezati ili u Win16 ili u Win32 izvrsnu datoteku. (Iako je to jednostavno uraditi, ipak vam je potreban Win16 kompatibilan prevodilac i program za povezivanje da biste napravili Win16 programe i Win32 kompatibilni prevodilac i program za povezivanje da biste napravili Win32 programe.) Iako MFC uspeva da sakrije mnoge razlike izmedju Win16 i Win32, razumevanje oba ova API-ja pomoci ce vam da bolje iskoristite prednosti svakog od njih.

Pocecemo osvrtom na starije 16-bitno Windows okruzenje Win16. Dalje, upoznacemo glavne osobine Win32, 32-bitnog Windows okruzenja. (Ako vas prisustvo dva Windows API-ja zbunjuje, pogledajte odeljak "Operativni sistemi i API-ji".) Oba API-ja su implementirana koriscenjem tri biblioteke: KERNEL, USER i GDI. Kao sto ce biti detaljnije objasnjeno u 2. poglavlju, svaka od ovih biblioteka obezbedjuje sistemske objekte koji su ugradjeni u MFC klase.

Win16 API je postao dostupan 1985. godine sa pojavom prve verzije Windowsa i bio je osnovno programsko okruzenje za Windows 1.x, 2.x i 3.x. Win16 API je napravljen za 16-bitne procesore Intel 8088 i 80286 koji su bili popularni sredinom osamdesetih godina. S obzirom na cinjenicu da su Intelovi novi 32-bitni procesori kompatibilni sa starijim verzijama procesora, sistemi zasnovani na 80386, 80486 i Pentium procesorima mogu da izvrsavaju Win16 programe.

Mozda je najvaznija karakteristika Win16 API-ja ta sto je on bio osnovno programsko okruzenje Windowsa 3.0, koji je postigao veliki uspeh posle svoje promocije maja 1990. godine. Win16 je bio daleko od savrsenstva, pa je zato Microsoft promovisao Win32. Ali uspeh Windowsa 3.0 zahtevao je od Microsofta da Win32 napravi sto je moguce vise kompatibilnim sa Win16 bez uvodjenja manje prenosivih i zastarelih osobina Windowsa 3.0.

Dve razlicite karakteristike Win16 programa su format datoteka i arhitektura memorije. Win16 izvrsna datoteka cuva kôd i podatke u segmentima. Na 16-bitnim Intelovim procesorima, segmenti su jedinice memorijskog adresiranja i njihova velicina se moze kretati od jednog bajta do 64 KB. Segmentacija procesorske memorije prvi put je upotrebljena da bi podrzala prenosenje koda sa starijih 8-bitnih procesora. Iako je kao memorijska sema segmentacija zgodna za rad, ona moze biti vrlo iritirajuca kada radite sa blokovima podataka vecim od 64 KB, sto je maksimalna velicina segmenta. Takvi objekti se moraju podeliti na delove velicine 64 KB i obradjivati deo po deo.

Jos jedna karakteristika Win16 API-ja je sklonost ka 16-bitnim (kratkim) celobrojnim vrednostima (engl. short integer). Takve vrednosti se lako uklapaju u registre koje su koristili raniji Intelovi procesori. U nekoliko slucajeva, 32-bitne vrednosti se koriste sa razlicitim pozivima Win16 funkcija, ali se uglavnom koriste 16-bitne vrednosti. Na primer, Win16 verzija GDI (engl. Graphics Device Interface) biblioteke koristi 16-bitne oznacene celobrojne vrednosti, kao koordinate za crtanje u intervalu od -32768 do +32767. (I Windows 95 se jos uvek oslanja na 16-bitni GDI i to je razlog zasto i Win32 programi koji rade pod Windowsom 95 mogu da racunaju na 16-bitnu grafiku.)

Tvorci Win16 API-ja znali su vrednost pisanja prenosivog API-ja, ali su morali da naprave veliki broj kompromisa. Prvo, Win16 API nije nikada imao ugradjenu podrsku za ulaz/izlaz podataka (engl. file I/O). Umesto toga, Win16 programi su se oslanjali na MS-DOS za citanje i pisanje podataka u datoteke. Mnogi programeri koriste bibliotecke C potprograme da bi prosirili prenosivost svojih Win16 programa. Medjutim, s obzirom da se odredjene osobine sistema datoteka mogu koristiti samo pozivom MS-DOS prekida (engl. interrupt), cak i najbolje napisani Win16 programi mogu imati kôd koji zavisi od MS-DOS-a. Na primer, da biste saznali ime diska morate pozvati MS-DOS prekid.

Platformski zavisna priroda Win16 se takodje vidi i kod funkcija napravljenih za kontrolu Intelovih specificnih osobina memorije (primeri imaju cudna imena kao npr. AllocSelector, AllocCStoDSAlias, SetSelectorBase, GlobalDosAlloc i GlobalPageLock). Iako one nisu bile deo originalnog API-ja, te funkcije su dodate kao pomoc u resavanju specificnih problema koji su nastali tokom evolucije Windowsa. Sta god da je uzrok koriscenja ovih funkcija, njihovo prisustvo u Win16 programu predstavlja specifican teret za procesor, koji je tesko preneti na druge procesore.

Jos jedna osobina koja vezuje neke, ali ne sve, Win16 programe sa MS-DOS-om je MS-DOS-ova osobina zvana zavrsi-i-ostani-rezidentan-u-memoriji (engl. terminate-and-stay-resident, TSR) program. Kao jednoprocesno okruzenje, MS-DOS obicno ne dozvoljava da u isto vreme radi vise programa. Medjutim, TSR program moze biti ucitan i ostavljen u memoriji pruzajuci usluge drugim programima. Zbog ove osobine TSR program je idealan za pruzanje podrske programima za upravljanje uredjajima (engl. device drivers), a to je bas ono za sta se TSR programi i koriste od strane mnogih proizvodjaca hardverskih komponenti. Iznenadjujuce veliki broj MS-DOS programa se oslanja na MS-DOS TSR programe kao programe za upravljanje uredjajima koji kontrolisu programski specificne hardverske komponente.

I Win16 program takodje moze pristupiti MS-DOS-ovom TSR programu. Ova osobina je omogucila strucnjacima za razvoj MS-DOS softvera da prenesu svoje programe na Windows. Dozvoljavanjem Win16 programima da koriste TSR programe, Microsoft je napravio kratkorocni ustupak nadajuci se da ce strucnjaci za razvoj TSR programa poceti da pisu programe za upravljanje uredjajima, koji su vise Windows kompatibilni. Programi koji se oslanjaju na takve programe za upravljenje uredjajima, nece raditi u Win32 sve dok novi specificni programi za upravljanje uredjajima, pisani pod Windowsom NT i Windowsom 95, ne zamene takve MS-DOS programe.

Uprkos arhitekturi memorije zasnovanoj na segmentima, 16-bitnoj orijentaciji i specificnim MS-DOS osobinama, Win16 API, koji radi pod Windowsom 3.0, predstavljao je veliki uspeh na trzistu. Do sada, Microsoft je prodao vise od 210 miliona kopija Windowsa. Ovaj uspeh je zahtevao podrsku za Win16 programe za brojne platforme, ukljucujuci sisteme koji nisu zasnovani na Intelovim procesorima. Tabela 1-1 prikazuje podrsku koja je na raspolaganju za Win16 programe.

Tabela 1-1     Platforme koje podrzavaju Win16 API

Procesor	Operativni sistem
Intel x86 (80386 i visi)	Izvorna binarna podrska na Windowsu 3.0, Windowsu 95 i Windowsu NT
Silicon Graphics MIPS R4000	Emulacija Win16 i Intel x86 na Windowsu NT 3.1 i 3.5
Digital Alpha	Emulacija Win16 i Intel x86 na Windowsu NT 3.1 i 3.5
Motorola Power PC 601	Emulacija Win16 i Intel x86 na Windowsu NT 3.1 i 3.5
HP Workstation i Sun SPARC	Binarna emulacija na HP-UX i SunOS sa WABI (Windows Application Binary Interface) emulacijom
(razni)	Kompatibilnost izvornog koda na UNIX-u sa programom Wind/U, proizvodjaca Bristol Technologies
Intel x86 (80386 i visi)	Izvorne masinske instrukcije i emulacija Win16 API-ja na OS/2 2.x
(razni)	Emulacija Win16 i Intel x86 od strane Insignia SoftWindowsa na Macintosh System 7 i na UNIX implementacijama na IRIS, NextStep, HP, DEC, SUN i SGI
Intel x86	Operativni sistem Linux sa programom WINE (Windows Emulator); dostupno samo na Intelovim verzijama Linuxa

Cak i sa platformski specificnim pozivima funkcija, Win16 program je prilicno prenosiv na druge platforme. Povrsno gledano, izgleda da ovaj API ima sve sto je potrebno da bi bio prenosiv. Za razliku od Win32 API-ja, koji zahteva ponovno prevodjenje izvornog koda za razlicite procesore, Win16 ima dodatni bonus time sto je binarno kompatibilan sa razlicitim platformama. Kako je naznaceno u tabeli 1-1, Win16 programi mogu da rade cak i na ne-Intel procesorima kroz emulaciju Intel x86 skupa instrukcija.

Iako ovakva emulacija cini Win16 programe vrlo prenosivim, njihove performanse znatno padaju. Na primer, iako Win16 programi mogu da rade na UNIX radnim stanicama, u vecini slucajeva oni rade mnogo sporije nego sto bi radili na sistemu opremljenom Intel x86 procesorom, a sigurno su i mnogo sporiji od programa koji koriste izvorni skup instrukcija. Medjutim, bez obzira sto je ovakva prenosivost korisna kao kratkorocna popravka, vrlo malo korisnika zeli da kupi RISC radne stanice i da dobije performanse Intelovog procesora 80386.

Microsoft je zapoceo rad na Win32 API-ju 1991. godine. Osnovni razvojni cilj za Win32 bio je kompatibilnost sa Win16 API-jem. Uspeh Windowsa 3.0 (a samim tim i Win16 API-ja) doveo je do stvaranja velikog broja Win16 programa. Zato je jedino imalo smisla da Microsoft uradi sve sto je mogao da nagovori strucnjake za razvoj softvera da prenesu svoje Win16 programe na novi API i da to prebacivanje ucine sto je moguce jednostavnijim.

Drugi razvojni cilj je bio da Win32 iskoristi svu snagu 32-bitnih procesora. Uspesi u razvoju hardvera doveli su do toga da i memorija i procesorska snaga budu relativno jevtini. Win32 nije napravljen samo za tekucu generaciju 32-bitnih (i 64-bitnih) procesora vec i za nove procesore koji se jos uvek razvijaju.

Da bi svoje operativne sisteme oslobodio zavisnosti od Intelovih mikroprocesora, Microsoft je dodao i treci razvojni cilj, prenosivost. Prethodni Microsoftovi operativni sistemi bili su pravljeni za Intelove procesore, ali je Microsoft odlucio da prosiri broj procesora koje podrzava omogucavajuci da Win32 radi na sto je moguce vecem broju procesora i platformi. Iako Microsoftov operativni sistem, Windows 95, radi samo na Intelovim platformama, drugi, Windows NT, prenet je na nekoliko procesora nekompatibilnih sa Intel procesorima.

Win32 API je napravljen kao kamen temeljac za novu generaciju Microsoftovih operativnih sistema. Operativni sistemi, medjutim, ne mogu opstati bez aplikativnog softvera. Zbog velikog uspeha Windowsa 3.0 i njegovog Win16 API-ja, Microsoft je zacrtao da Win16 kompatibilnost bude najvazniji razvojni cilj za Win32.

Lako je postaviti visoke ciljeve kao sto je kompatibilnost navise, ali ih nije uvek lako ostvariti. Medjutim, Microsoft je napravio izvanredan posao omogucavajuci da prenos koda sa Win16 na Win32 bude jednostavan. Nasa tvrdnja da je Microsoft uspesno ostvario svoj razvojni cilj potkrepljena je nasim sopstvenim razvojnim iskustvima, kao i nasim laickim posmatranjem u svojstvu strucnjaka za razvoj koji su kôd prenosili.

Interesantno je istaci da je Win32 Microsoftov drugi pokusaj u pravljenju naslednika Win16 API-ja. Prvi pokusaj, ciji je rezultat bio uzasno nekompatibilan API, bio je OS/2 Presentation Manager. Iako je medju navedenim ciljevima za Presentation Manager bila i kompatibilnost, strucnjaci za razvoj OS/2 su se zaglavili u pokusajima da "poprave" mane u Win16. Kada su zavrsili, dobijeni Presentation Manager API je imao istu arhitekturu kao i Win16, ali se veoma razlikovao u nivou detalja. U stvari, veliki broj imena funkcija, struktura podataka i imena simbolickih konstanti su u OS/2 bili drugaciji. Kao rezultat toga, bilo je potrebno previse napora da bi se Win16 kôd prebacio u Presentation Manager API i zato je vecina strucnjaka za razvoj to uvek izbegavala.

Visoka cena prebacivanja sa Win16 na OS/2 Presentation Manager je jedan od glavnih razloga sto je Microsoft napustio OS/2 1991. godine. U to vreme je IBM, Microsoftov partner u razvoju OS/2, i sam postao vlasnik operativnog sistema. Iz ovog iskustva, odnosno velike greske, proistice Microsoftova tvrdoglava odluka da Win32 bude potpuno kompatibilan sa Win16.

Slobodna upotreba korisnicki definisanih tipova (eng. typedefs) krije mnoge razlike izmedju Win16 i Win32. Na primer, Win16 POINT struktura je definisana sa 16-bitnim celobrojnim vrednostima:

typedef struct tagPOINT

{

 int x;

  int y;

} POINT;

Odgovarajuca Win32 struktura je napravljena od 32-bitnih celobrojnih         vrednosti:

typedef struct tagPOINT;

{

  LONG x;

  LONG y;

} POINT;

Ovaj primer pokazuje najvazniju razliku izmedju Win16 i Win32: Win32 celobrojne vrednosti su siroke samo i jedino 32 bita. Kao stari seoski put, koji je prepravljen da izdrzi bolji saobracaj, tako je i konverzija sa Win16 na Win32 udvostrucila kapacitet bitova podataka. Win16 programeri, koji su se oslanjali na bogat skup korisnickih tipova podataka umesto koriscenja izvornih tipova jezika C, vec su utrli put za lak prelazak na Win32. Prednost MFC izvornog koda je prakticno bezbolan prelazak sa Win16 na Win32.

Vredno je napomenuti da se neki problemi mogu pojaviti i kod najbolje isplaniranih prenosenja. U stvari, visok stepen prenosivosti izmedju ova dva API-ja ne prilagodjava automatski izmene u formatu datoteka programskih podataka. Da bi podrzao format datoteka Win16 programa, koji koristi 16-bitne celobrojne vrednosti, kompatibilni Win32 program mora da procita 16-bitne vrednosti. Na primer, Win16 program moze upisati POINT u datoteku ovako:

POINT pt;write (hf, &pt, sizeof(POINT));

Na prvi pogled ne izgleda da ce nastati problemi kada Win32 program pokusa da procita iste vrednosti:

POINT pt;read (hf, &pt, sizeof(POINT));

Win32 program, medjutim, nece dati ocekivane rezultate. Razlog je koliko jednostavan toliko i zao; struktura POINT je u Win16 programu velicine cetiri bajta, dok je ista struktura u Win32 programu velicine osam bajtova.

Ostavljajuci po strani ovaj mali problem, prelasci sa Win16 na Win32 su iznenadjujuce jednostavni. Andrew Schulman, poznati kolumnista i skeptik u pogledu Microsofta, preneo je svoju WINIO biblioteku, "2500 redova Win16 koda", na Win32. Ovo iskustvo je opisao u clanku "Najzad: Pisanje 32-bitnih programa koji rade pod Windowsom 3.1 koristeci Win32" (At Last: Write Bona Fide 32-Bit Programs that Run on Windows 3.1 Using Win32) koji se pojavio u casopisu Microsoft Systems Journal, broj iz aprila 1993. godine:

Prenos je bio apsurdno jednostavan i mada WINIO sada srecno radi pod Win32 zajedno sa mnogo mojih programa koji se oslanjaju na WINIO, ja i dalje mislim da mora biti da sam nesto propustio.

Strucnjaci za razvoj MFC biblioteke iskoristili su prednost visokog nivoa prenosivosti sa Win16 na Win32 tako sto su napravili biblioteku klasa koja podrzava oba API-ja. Iz jednog skupa izvornog koda mozete koristiti 16-bitne alate za pravljenje Win16 izvrsnih programa i 32-bitne alate za pravljenje Win32 izvrsnih programa. MFC dalje poboljsava kompatibilnost izmedju API-ja skrivajuci nevazne i neizbezne nekompatibilnosti izmedju Win16 i Win32.

Microsoft je hteo da se uveri da je prenos sa Win16 na Win32 sto je moguce jednostavniji. Medjutim, kao sto znate, to nije bio jedini cilj na kome je kompanija radila za vreme stvaranja Win32. Drugi cilj je bio potvrda da novi API moze iskoristiti prednosti brzih, sposobnijih 32-bitnih procesora, koji su postali siroko dostupni. U daljem tekstu cete videti neke od stvari koje je zahtevao ovaj razvojni cilj.

Mozda najvaznije poboljsanje koje je Win32 doneo u odnosu na Win16 programiranje jeste cist pristup adresnom prostoru. Win16 program je morao da adresira memoriju koristeci bubicavo segmentiranu adresnu semu 16-bitnih Intelovih procesora x86. Iako je Intelova dokumentacija hvalila segmentirano adresiranje na sva zvona (pomaze organizovanje programa, prisiljava na ogranicavanje memorije, vodi ka pravljenju robustnijih programa itd.), programeri koji su radili sa segmentiranim adresiranjem nisu se slozili. Na nivou masinskog koda i u visim programskim jezicima, segmentirano adresiranje je teskoca, nespretan put u pristupanju memoriji. Na primer, segmentirano adresiranje zahteva od vas da vodite racuna o dve razlicite velicine pokazivaca: 16-bitnih NEAR pokazivaca i 32-bitnih FAR pokazivaca. Sa Win32, segmentirano adresiranje je nestalo. Dovoljno vam je da baratate samo sa jednom velicinom pokazivaca, 32-bitnom, da biste pristupili svemu onome sto zelite da stavite u adresni prostor velicine cetiri gigabajta.

Sa Windowsom 95 i Windowsom NT, cisto memorijsko adresiranje je obezbedjeno kroz sopstveni adresni prostor koji se odvaja za svaki proces. Nasuprot ovome, Win16 programi koji rade pod Windowsom 1.x, 2.x i 3.x, rade u obicnom, segmentiranom adresnom prostoru. Mnogi strucnjaci za razvoj iskoristili su ovu cinjenicu tako sto su pisali Win16 programe, koji su delili memoriju tako sto su jednostavno delili adrese. Medjutim, ako ostavimo na stranu ovu beznacajnu dobit, nedostatak granica adresnog prostora ugrozavao je stabilnost i zastitu sistema. On je, takodje, podsticao programe da se takmice izmedju sebe u osvajanju adresnog prostora. Za razliku od ovoga, Win32 programi pod Windowsom 95 i Windowsom NT imaju ekskluzivno pravo koriscenja sopstvenog adresnog prostora. (Win32 programi koji rade pod Win32s koji radi pod Windowsom 3.1 dele jedan adresni prostor sa tekucim Win16 programima.)

Koristeci Win32 rad, Win32 program ima pristup sirem spektru vrednosti nego Win16 program. Vecina Win16 parametara su kratke (engl. short), 16-bitne, celobrojne vrednosti. Na primer, x i y koordinate prosledjene u GDI biblioteku za crtanje moraju da budu u intervalu izmedju -32766 i +32767. Win32 GDI-ju prosledjuje tridesetdvobitne parametre za vreme crtanja sto vam daje prostor za crtanje od -2147483647 do +2147483648.

Iako Win32 GDI definise 32-bitne parametre, ne prepoznaju sve tekuce verzije Windowsa ceo interval vrednosti. U ovom trenutku samo Windows NT obezbedjuje 32-bitni GDI. I Win32s i Windows 95 obezbedjuju 16 bitni GDI koji koristi samo nizih 16 bita 32-bitnih parametara.

Jos jedna pogodnost koju Win32 programi imaju u odnosu na Win16 programe su poboljsane performanse u radu sa 32-bitnim celobrojnim vrednostima. Na primer, kada se Win16 program prevodi, rezultujuci masinski kôd koristi Intelov 16-bitni skup instrukcija da omoguci programu da radi na Intelovim 80286 procesorima. Sa 16-bitnim registrima u tom procesoru, operacije nad 32-bitnim vrednostima zahtevaju najmanje dve procesorske instrukcije (a cesto i vise) da bi obradile prekoracenja i dodatne bitove za znak. S druge strane, kada se Win32 programi prevode, oni mogu da rade sa 32-bitnim vrednostima u samo jednoj masinskoj instrukciji.

Bolji rad sa 32-bitnim vrednostima ukazuje na jos jednu kljucnu prednost prenosivosti Win32 nad Win16. Sesnaestobitni rad Intelovih procesora x86 realizuje se na poseban nacin. S druge strane, rad 32-bitnih Intelovih procesora (80386 i visih) realizuje se kao i rad mnogih ne-Intel procesora. Najzad, danas su mnogi procesori ili 32-bitni ili podrzavaju 32-bitni nacin rada. Na primer, DEC Alpha je 64-bitni cip, koji podrzava i 32-bitni nacin rada kada radi sa Windowsom NT.

S druge strane, Win32 program verovatno ce zauzeti neznatno vise mesta u RAM memoriji i na disku nego isti takav Win16 program. Ovo se desava zbog toga sto su sve vrednosti 32-bitne, cak iako se skladisti manji opseg vrednosti. Kako cene hardvera sve vise padaju, ovo sve vise postaje zanemarljiva cinjenica.

Treci razvojni cilj pri pravljenju Win32 bio je prenosivost. Procesori su za kratko vreme postali brzi, ali je oduvek trebalo mnogo vremena da bi se napravio novi operativni sistem sa API-jem koji moze iskoristiti mogucnosti novih procesora. Sa svojim visoko prenosivim Win32 API-jem, Microsoft planira da bude jedna od prvih kompanija koja ce obezbediti sistemski softver za dolazece generacije procesora. Sto je jos vaznije, Win32 programi ce pomoci lansiranje buducih generacija jos brzih i sposobnijih procesora.

Iz prenosivog Win32 API-ja korist mogu izvuci i strucnjaci za razvoj softvera i krajnji korisnici. Prenosivost pomaze strucnjacima za razvoj da ulazu manje napora za viseplatformsku podrsku. Umesto rvanja sa neprijatnim zadatkom prenosenja na razne platforme, strucnjaci za razvoj mogu usredsrediti svoje napore na prosirenje mogucnosti. Krajnji korisnici imaju koristi od velikog broja programa dostupnih na sirokom spektru platformi.

Iako Win16 programi takodje rade na vise platformi, oni ovu mogucnost ostvaruju kroz emulaciju skupa instrukcija Intelovih procesora x86, sto je skopcano sa velikim padom performansi. Win16 ima veliki broj "intelizama" (na primer, segmentirano adresiranje), koji su teski za emulaciju, a oslanjanje Win16 programa na MS-DOS otezava obezbedjivanje kompletne podrske. Na primer, neki Win16 programi se oslanjaju na nedokumentovane MS-DOS osobine i osobenosti koje su teske za pouzdanu implementaciju na ne-Intel procesorima.

Za vreme pravljenja Win32 API-ja, Microsoft je izostavio 31 funkciju specificnu za Win16 platformu; 20 ovih funkcija su radile sa specificnim Intelovim strukturama podataka, tri su pristupale specificnim MS-DOS-ovim mogucnostima, a osam su predstavljale Win16-oliki model za rad sa programima za upravljanje uredjajima. Uklanjanje ovih funkcija oslobodilo je Win32 tereta Win16, povecavajuci tako prenosivost. Iako izostavljanje ovih funkcija moze neznatno sputati prenosenje koda sa Win16 na Win32, ukupna poboljsanja prenosa pokazuju opravdanost izostavljanja.

Microsoft daje tabelu svih Win16 i Win32 funkcija u datoteci win32api.csv koja se isporucuje sa prevodiocem koji dolazi uz paket Microsoft Visual C++ 2.0 (i kasnijim verzijama). Ova tekstualna datoteka ima po jedan red za svaki poziv funkcije (ili simbolicku konstantu), a moze se procitati i iz programa za tabelarne proracune, koji podrzava CSV format datoteka. Stavke koje su oznacene kao "izostavljene" ("dropped") postoje u Win16, ali nisu ukljucene u Win32. Iako ova tabela pokazuje da je 137 funkcija izostavljeno, neke su jednostavno samo zamenjene, tako da su funkcionalne mogucnosti jos uvek dostupne. Po nasem misljenju, samo 31 od 1855 funkcija u dva API-ja, manje od 2 procenta, zaista su izostavljene.

Jos jedan nacin na koji Win32 sece veze sa MS-DOS-om je obezbedjivanje kompletnog skupa funkcija za ulaz/izlaz podataka (engl. file I/O). Win16 programi moraju da se oslanjaju na MS-DOS da bi pristupili sistemu datoteka. Pozivi sistemu prekida u softveru pisanom u MS-DOS stilu, od kojih neki Win16 programi zavise, nisu dostupni u Win32 programima.

Zarad prenosivosti, Win32 programi ne mogu pristupati MS-DOS programima za upravljanje uredjajima kao sto je to moguce u Win16 programima. Win32 programi sa posebnim hardverskim potrebama zahtevaju specifican program za upravljanje uredjajima u okviru operativnog sistema. Platformski specifican kôd ce nastaviti da postoji tamo gde i pripada, u programima za upravljanje uredjajima, ali specificni MS-DOS programi za upravljanje uredjajima nisu podrzani u Win32.

Softverska prenosivost je prosirena dobrim razvojem, ali nista bolje ne dokazuje prenosivost od stvarnog pustanja softvera da radi na vise od jedne platforme. Da bi se uverio da su neprenosive osobine iskljucene iz Win32, Microsoft je simultano razvijao Win32 implementacije na dve platforme. Ove implementacije su inkorporirane u nov, prenosivi operativni sistem koji je takodje bio razvijan, Windows NT.

Prve dve implementacije Win32 (i Windowsa NT) bile su za 32-bitne Intelove procesore x86 i za MIPS R4000 RISC procesore. Obe verzije su pocele da se isporucuju u julu 1992. godine. Prenosivi dizajn Win32 i Windowsa NT se potvrdio dva meseca kasnije, kada je Microsoft isporucio implementaciju za DEC Alpha procesor. Ovo ne znaci da je implementiranje na Alpha platformu trajalo samo dva meseca; tim u DEC-u je radio na tome najmanje godinu dana. Medjutim, to prenosenje, zajedno sa ostalim kao sto je ono na PowerPC procesor, potvrdilo je tvrdnje o prenosivosti koje je Microsoft objavio za Windows NT i Win32 API. Tabela 1-2 prikazuje Win32 implementacije, koje su dostupne u vreme kada se pise ova knjiga.

Tabela 1-2     Platforme koje podrzavaju Win32 API

Procesor	Operativni sistem
Intel x86 (80386 i visi)	Windows 3.1 sa Win32s koji je podskup Win32 API-ja
Intel x86 (80386 i visi)	Windows 95 sa vecinom GUI delova Win32. Windows NT obezbedjuje kompletnu implementaciju.
Silicon Graphics MIPS R4000	Windows NT
Digital Alpha	Windows NT
Motorola PowerPC 601	Windows NT
Motorola 68xxx	WINGS na Macintosh System 7
(razni)	UNIX sa Bristol Wind/U

Win32s Windows 3.1 podrska za Win32 API

Kada je Microsoft isporucio Windows NT 1992. godine, njegov izvorni API je bio Win32. Da bi podrzao Win16 programe, ovaj novi operativni sistem je bio opremljen sa Windows-on-WindowsNT (WOW) delom koji je pretvarao Win16 pozive u njihove Win32 ekvivalente. U isto vreme, Microsoft je pustio i dodatak za Windows 3.1 zvani Win32s, koji pretvara Win32 pozive u njihove Win16 ekvivalente. Win32s omogucava programu za ucitavanje Windowsa 3.1 da prepozna, ucita i pocne izvrsavanje Win32 izvrsnih datoteka.

Iako WOW omogucava Windowsu NT celokupnu podrsku za Win16, Win32s podrzava samo deo celog Win32 API-ja (na sta ukazuje i slovo s u nazivu, koje znaci podskup (eng. subset)). Ceo Win32 API je prisutan, ali funkcije bez Win16 ekvivalenata se izbacuju, a njihova upotreba dovodi do pojave greske. Zbog toga je moguce napisati jednu Win32 izvrsnu datoteku koja radi pod Windowsom 3.1, Windowsom 95 i Windowsom NT. Pod Windowsom 3.1 takav program nece imati pristup Win32 osobinama, koje nisu dostupne u Win32s.

Verujemo da podskup funkcija u Win32s pruza pristojnu podrsku na sve tri platforme za sve osim za najzahtevnije programe. Najzad, Win16 API, koji radi ceo "pravi posao" za podrsku Win32s, podrzava raznovrstan skup Win16 programa koji su trenutno na trzistu. Verovatno bi trebalo da razmisljate o Win32s API-ju ako vasa korisnicka baza ukljucuje veliki broj obicnih korisnika, koji verovatno nece preci na Windows 95 ili Windows NT u skorije vreme. Medjutim, za programe pisane za ozbiljne korisnike, moracete da razmisljate o siroj Win32 podrsci za Windows 95 i Windows NT. Naravno, ako vas program apsolutno zahteva Win32 osobine koje Win32s ne podrzava, izberite Windows 95 i Windows NT kao vase ciljne platforme.

Win32 program moze proveriti da li radi pod Win32s pozivajuci funkciju GetVersion(). Pod Win32s, kôd dat u sledecem primeru testira rad u Win32s okruzenju ispitivanjem da li je najvisi bit znaka postavljen na vrednost jedan:

#define WIN31_OR_WIN95 0x80000000

#define WIN95 0x00000004

int nVer! = GetVersion();

// visi bit vise reci je 0 za NT, a 1 za 32s i 95

if (nVer & WIN31_OR_WIN95)

{

 if (nVer & WIN95)

  {

//Win95

 }

 else

 {

 //Win32s

 }

}

else

{

//NT

}

Kao sto je ranije napomenuto u ovom poglavlju, Microsoft daje tabelu svih Win16 i Win32 funkcija koje se isporucuju sa prevodiocem, koji dolazi uz paket Microsoft Visual C++ 2.0 (i kasnije verzije). Cetvrta kolona u tabeli pokazuje da li Win32s podrzava odredjenu funkciju. (D oznacava da Win32s podrzava funkciju, a N oznacava da Win32s ne podrzava funkciju). Tabela 1-3 prikazuje Win32 osobine koje Win32s ne podrzava.

Win32s obezbedjuje podskup Win32 API-ja u stvari, ne podrzava svaku osobinu i funkciju. S druge strane, obezbedjuje nove mogucnosti. Iako Win32 program, koji radi pod Win32s, ima pristup manjem broju funkcija nego sto bi to bio slucaj pod Windowsom 95 ili Windowsom NT, takav program ima pristup vecem broju funkcija nego sto ih ima sam Windows 3.1. Tabela 1-4 daje pregled nacina na koje Win32s prosiruje Windows 3.1.

Tabela 1-3     Win32 osobine koje Win32s ne podrzava   

Osobina	Opis
GDI prosirenja	32-bitni GDI ima takve mogucnosti crtanja kao sto su putanje, Bezijeove krive i rotacija bit mapa.
Podrska za vise niti	API-ji za Win32 niti i procese nisu podrzani od strane Win32s, jer je Windows 3.1 jednonitno okruzenje.
API-ji za mreze	Imenovani kanali i mesta za elektronsku postu nisu podrzani, iako Socket API (API za prikljucke) jeste.
Zastita	Win32 prosirenja za zastitu podrzavaju diskrecioni pristup Windowsa NT, koji nije dostupan pod Windowsom 3.1 i, zbog toga, ni pod Win32s i Windowsom 95.
Snimanje na traku	Win32 podrska za snimanje na traku ne postoji.
Poziv udaljenih procedura	Podrska za kontrolu procesa sa razlicitih racunara. Komunikacija kroz mrezu nije obezbedjena (iako je RPC sa strane klijenta podrzan).
Konzolni API	Podrska za pravljenje programa zasnovanih na znacima nije obezbedjena. U Windowsu 3.1, ovo je obezbedjeno od strane MS-DOS API-ja.

Tabela 1-4     Prosirenja Windowsa 3.1 od strane Win32s

Osobina	Opis
32-bitno adresiranje	Win32 procesi pristupaju cistom, 32-bitnom adresnom prostoru umesto segmentiranom adresnom prostoru kao sto je slucaj u Win16.
32-bitna heap memorija	Win32 podrzava procedure za alociranje heap memorije kao sto su HeapAlloc i HeapFree
Upravljanje strukturiranim izuzecima	Ovu osobinu Win32 API-ja takodje podrzava Win32s. Upravljanje strukturiranim izuzecima vam pomaze da napravite robusniji softver, pojednostavljujuci proces otkrivanja izuzetaka tj. hardverskih i softverskih gresaka.
Deljena memorija	Win32s obezbedjuje neku vrstu podrske za medjuprocesno deljenje memorije.
Virtuelna memorija	Odredjene Win32 funkcije i mogucnosti za virtuelnu memoriju su obezbedjene da bi dozvolile vecu kontrolu nad programskim adresnim prostorom.
Ulaz/izlaz podataka	Win32s obezbedjuje funkcije za ulaz/izlaz podataka kao zamenu za MS-DOS funkcije na koje se Win16 programi oslanjaju, ali koje ne mogu koristiti Win32 programi.
Univerzalnost	Win32s dozvoljava Win32 programu da poziva Win16 DLL-ove.

Rezime

Microsoft se nada da ce iskoristiti slavu starog Windowsa za pravljenje Win32 API-ja i novog talasa operativnih sistema i programa, koji koriste prednosti 32-bitnih procesora. Jasno, postoje dva razlicita API-ja: jedan napravljen za 16-bitni rad i jedan za 32-bitni rad. Ali, visok stepen kompatibilnosti olaksava prenosenje koda izmedju ova dva API-ja.

Nastavljajuci nase putovanje kroz izvorne Windows API-je, u drugom poglavlju cemo razmatrati kljucne strukture podataka i uobicajene elemente od kojih su sastavljena dva gore pomenuta API-ja. Iako razmatranje tih delova moze izgledati kao nesto sto strucnjaci za razvoj MFC biblioteke ne moraju da znaju, oni cine osnovu na kojoj je izgradjena MFC biblioteka. Kao takvi, oni su osnova za razumevanje strukture i mogucnosti same MFC biblioteke.