The Windows 7 API Code Pack for Microsoft .NET Framework

Ko hoce da se poigra novotarijama iz Win7 RC

http://code.msdn.microsoft.com/WindowsAPICodePack




PS: Ova verzija (0.9) je obsolete, vidi dole za finalnu verziju...



_{[Ovu poruku je menjao mmix dana 11.08.2009. u 10:12 GMT+1]}

---

Ne znam jesam li u pravu, ali imam osjecaj da se vrlo malo ljudi igralo i sa WPF / Avalon-om, ne znam, stanje ce se vjerovatno jako promjeniti ako Win7 postigne znacajniji uspjeh, i onaj WinXP market-share konacno opadne :))

---

Nema ovo veze sa WPF-om, vecina Win7 vizuelnih promena u ovom codepack-u se odnosi na koriscenje novih kontrola u COMCTL bibliotekama i dodatnim hookovima i strukturama za komunikaciju sa novim GUI elementima. Bez prosirenja API-a to se ne moze iskoristiti (npr da tvoj aplikacija moze da ima custom meni kad korisnik pritisne rclick na taskbar, itd). Avalon/WPF je GUI api i nema veze sa OSom direktno.

Cak iako Win7 skroz zameni XP ljudi nece morati da znaju niti da prave aplikacije u WPF-u.

---

Ne znam za druge, ja u firmi radim sa WPF-om i mogu reci da mi se vema svidja. Lakse mi je raditi u njemu nego klasicnom Win Forms-u a mogucnosti su mnogo vece.

@mmix, stvari koje si pomenuo.. I dalje se baziraju na COM-u?

---

Jok, COM u COMCTL dolazi od Common Controls, ne od Component Object Model, mada postoji OCX koji je u stvari samo COM wrapper oko native HWND kontrola, mislim da je on dosao sa visual basicom da bi isti mogao da koristi native kontrole.


Windows 7 API Code Pack je zapravo vise od toga, on je u stvari managed wrapper za funkcionalnosti WinAPIa koje nemas u samom framework-u a tu ima vise stvari od samih native kontrola (koje btw imas i imaces indirektno kroz framework).

---

Iskreno, možda se nisam najbolje izrazio, jer sam mislio na generalno sve nove stvari koje se pojave...

Ipak, sada imam osjećaj da baš i nisam upućen u neke stvari kao što sam mislio. Evo, molio bih vas da me ispravite ako negdje griješim:
1. Koliko znam, WinForms je managed code napisan kao wrapper za WinAPI.
2. WPF se razlikuje što skoro sve kontrole i funkcionalnosti gradi na osnovu DirectX-a, a ne WinAPI-a.
3. COMCTL je .dll unutar windowsa, s Win32 kontrolama.
4. Ovaj Windows 7 API code pack je managed code za Win7 funkcionalnosti, IZ WINAPI-a - kao što je jump list. Bez windowsa 7, ili barem Viste za većinu mogućnosti, ovaj kod nije moguće pokrenuti?

Ontopic: kakva je veza ovog pack-a sa Vista Bridge-om? Koliko vidim radi se o skoro istoj stvari...

@Shadowed
WPF jeste vrlo moćan, ali što se tiče korištenja, istina je da jako mali broj ljudi isti i koristi. Dovoljno je pogledati .NET PF podforum na ES :)

---

1. Ne. Iako ima kontrola u winformsu koje jesu iz winapi-a to nije bio cilj vec pogodnost za izradu WinForms-a na windows platformi. WinForms je zapravo framework koji apstrakuje GUI, omogucava ti da u potpunosti zaobidjes ugradjene kontrole i napravis svoju od "korena", sto inace rade svi proizvodjaci 3rd party komponenti, otvore blanko HWND i crtaju preko GDI+. To sto se sve winforms kontrole interno baziraju na GDI+ i HWND i imaju WndProc je samo posledica implementacije WinForms-a za Windows platformu, na nekom drugom sistemu stvari bi bile manje ili vise drugacije ali bi managed API ostao isti.

2. Zapravo WPF/Xaml je isto apstraktni layer samo podignut na sledeci nivo (deklarativno), u tom pogledu nema neke vece razlike, oba se bukvalno koriste u istu svrhu samo imaju razlicite mogucnosti i drugacije se "programiraju". Jedini razlog zasto je DirectX usao u pricu je zato sto je vec bio tu, uradjen kako treba i sa funkcionalnoscu koja je bila neophodna WPF-u, i nije bilo ekonomskog smisla prosirivati GDI+ i dodavati mu DX funkcionalnosti samo da bi se WPF renderovao preko HWND; MS je isto tako mogao da krene i tim putem i da prosiri GDI+ u GDIWPF+ recimo i onda bi WPF isto bio HWND based. Isto vazi u obrnutom smeru, kad bi preradili interni kod WinForms klasa mogli bi da prebace WiForms da bude DX based, ali ni to se naravno nece desiti kako zbog kolicine posla tako i zbog cinjenice da postoji gomila 3rd party kontrola koje bi onda postale nefunkcionalne.
Moras da razdvojis apsktraktnu tehnologiju od njene implementacije, npr Xaml implementacija silverlighta na linuxu (Moonlight) nema DX ali svejedno ganja silverlight aplikacije (donekle ). Tebe kao WPF/Silverlight programera ne interesuje kako je on implementiran dok god je high-level API kompatibilan i dok sve radi u skladu sa specifikacijama.

3. comctl32.dll je WinAPI dll koji pominjes i u njemu su native kontrole, on je samo jedan deo WinAPI-a. I mada sam ja to prvi izrekao u ovoj temi, reci da su to kontrole je malo "prejako" jer su to bas hard-core native prozori, kontrolu kreiras tako sto kreiras prozor odredjene klase (tj naziva) i sa kontrolom komuniciras slanjem WM_ poruka i pozivanjem GDI+ metoda nad rezultovanim HWND, ako hoces da obradjujes neki event moras da zamenis fabricki WndProc sa svojim i da presreces odgovarajuce WM_ poruke, itd. Sve je prilicno linearno jos od Win3.1, nema klasa, nema metoda, itd.
Sa druge strane WPF nije deo WinAPI-a iako ide uz Windows od Viste na ovamo. Razmisljaj o WPF-u kao o MFCu svojevremeno. On je C++ wrapper oko WinAPI-a i od neke verzije je i on bio na svim Windowsima ali opet nije deo WinAPI-a, ako je tvoja aplikacija bila MFC onda ti je bio neophodan MFC ili dinamicki ili staticki linkovan, ali su ne-MFC WinAPI based aplikacije radile savim fino i bez njega.

4. Nisam probao jos, ali moja pretpostavka je da nece moci. Rezultovani EXE ce verovatno bindovati direktno na specificne nove verzije DLL-ova i pokusaj startovanja ce verovatno prijaviti "cannot find DLL" gresku.



Managed stvari iz VistaBridga bi trebalo da su vec ubaceni u novi Windows SDK 6.1 tako da ti vista bridge vise ne treba (doduse nisam proverio), mada da ti direktno odgovorim, da, slicna stvar samo za Windows 7, valjda da ga ne bi zvali Windows 7 Bridge zovu ga Win7 API Code Pack i sluzice ovoj svrsi dok te klase ne prebace u novi Windows SDK kad Win7 bude GA.



Pa vi se aktivirajte malo Zapravo iz mojih kontakata znam da je PUNO ljudi probalo WPF, skoro svako koga znam a radi .NET je bar probao WPF ali je malo ljudi srecno njime (ako iskljucimo silverlight na koji se lozi dosta ljudi). Mnogima je previse spor, nekima je tesko da svare deklarativno programiranje na tom nivou (ne mogu da izbiju aspnet/HTML iz glave), nekima smeta siromasan fond gotovih kontrola (ovde ja spadam), nekom smeta losa podrska za xaml dizajn iz visual studia a ne vole da kucaju xaml rucno itd. Ja iskreno ne verujem da ce WPF postati mainstream, imace neki svoj market ali trenutno je vrlo tesko ovu ideju prodati u jednom biznis okruzenju sa neistreniranim programerima i radnim stanicama sa integrisanom grafikom koja ne moze ni tetris da ponese.

---

Uredu to sve, ali koje onda još implementacije WinForms-a postoje, a da nisu bazirane na WinAPI-u? Vjerovatno ćeš reći Mono, i slažem se, ali ono što si naglasio jeste da je cilj Microsoft-a bio da se WinForms napravi kao cross-platform rješenje, u što baš i nisam siguran...



Mislim da za WinForms nema nikakve potrebe da pređa na DX, iako je to sada besmisleno reći kad postoji WPF. Hoću samo da kažem da je meni GDI+ bio i više nego dobar za gomilu stvari koje sam programirao (custom buttons sa animiranim rollover efektima, animirana chart kontrola, hrpa animacija unutar aplikacija ... ). Naravno, kada je trebalo preći na korak dalje, i konačno se rješiti starih gluposti i ograničenja (kao što je promjena rezolucije i problemi unutar aplikacije koji nastaju pri tome), bio je potreban kompletan overwrite podloge. Ono što ja mislim da se desilo, jeste da su imali 2 izbora:
- ovo što ti navodiš, da promjene podlogu WinForms-a na DX. Ne slažem se s ovim jer mislim da nije bilo potrebno samo izmjeniti podlogu platforme da se postignu WPF mogućnosti, već da se MORALA napisati nova tehnologija iz korjena. Ovdje vjerovatno dolazi do izražaja moje površno sadašnje poznavanje WPF-a, ali kako bi se npr. XAML uklopio u WinForms, prema tome što kažeš?
Evo recimo abstraktni layer za GDI+ podršku u System.Drawing namespace-u; da li se on mogao napisati da bude DX based, i kakve bi (za WinForms) bilo koristi od toga?
- druga opcija je već rečena - izmišljanje nove tehnologije - WPF. Po mome mišljenju, zar WPF nije napravljen nad DX-om (ok, na windows platformi ) zbog nepostojanja hardverske podrške za GDI+, za koju se donekle očekivalo de će je proizvođači graf. kartica uvesti (što se nikad nije desilo)? Možda si na ovo mislio pod "ekonomskim smislom"?



Ja sam ga samo površno pogledao, pokrenuo par demo-a i sl.



E ovo je već zanimljivo ... Šta će onda nasljediti WPF ? Mislim da mu samo treba dati vremena

---

Tom logikom mozes da kazes da sumnjas i da je CLS napravljen kao cross-platofrm resenje, pa ga opet ima svuda . Ne radi se o cilju MS-a, niko tebe ne sprecava da napravis winforms implementaciju. MS drzi patente na implementacione detalje za svoju implementaciju ali ne drzi na API metadata, ako je tvoja implementacija drugacija od njihove sasvim je legitimna, Mono je zapravo i zaziveo po tom osnovu. Takodje obrati paznju da Mono nije samo JEDNA implementacija, mono je dizajniran da radi sa vise GUI toolkita i svaka od kombinacija je implementacija za sebe.
Sad sto je izrada WinForms implementacije PUNO, PUNO posla pa niko to ne radi uzalud, to je druga prica. Ne smeti i ne hteti su razlicite motivacije


Ni blizu. WPF nije managed DX, on samo koristi jedan relativno mali deo DX-a za svoje potrebe. GDI+ je jednostavno i pri punoj akceleraciji nekompletan funkcionalno za sve ono sto su u WPF projektu zamislili. Tako da izbor nije bio taj koji si ti naveo nego je bio: a) hocemo li downsizovati WPF da bi radio na GDI+ ili b) hocemo li iskoristiti DX za to posto je vec gotov i radi ili c) hocemo li prosiriti GDI+ da ima funkcionalnost koja nama treba. Izbor i nije bio neki narocito zbog pojavljivanja Viste i napustanje GDI-a kao low-level rendering engina, opcija C je ta koja nema ekonomskog smisla, a opcija A znaci svodjenje WPF-a na deklarativni WinForms.

A inace, GDI+ je bio pokriven hardverom odlicno ne znam odakle ti to, mada je ta prica sad obsolete zbog DWM-a, od viste na ovamo GDI+ ne koristi hardversku akceleraciju vec renderuje direktno u DWM-ove bufere a brzina GDI aplikacija se dobija na tome sto DWM kesira renderovan GDI izlaz kao bitmapu i drasticno smanjuje broj WM_PAINT poruka ka aplikaciji. Vista efektivno koristi DX9 kao osnovni rendering layer i sve ostalo se skuplja kroz DWM bufere, ukljucujuci i high level WPF i DX aplikacije.


Ne vidim sa cim se ne slazes, ja sam i rekao da se to nece desiti, a i zasto se nece desiti. Xaml je samo deklarativni nacin da se serijalizuje GUI, Winforms koristi kod iz .designer.xx parcijalne klase, WPF koristi xml format (Xaml) ili binarni format (Baml) za to, u oba slucaja koncept je isti, kako opisati izgled forme a ne kako je renderovati. Oni su mogli i sam Winforms da promene (mozda i hoce, nikad nije kasno za to) da se forme ne serijalizuju u kod vec u neki XML fajl, recimo Waml (lupam) i to bi i dalje radilo preko GDI+. Isto tako ti bi mogao da ispises System.Drawing klase da koriste DX, ali bi morao da promenis i sve ostale klase koje se baziraju na HWND handlovima jer ne bi imao GDE na HNWD formi da izrenderujes System.Graphics generisane DX surface, a kad bi SVE HWND based klase u WinForms-u prebacio sa HWND na DX onda bi uradio ono sa pocetka ovog pasusa, napravio bi da se WinForms renderuje kao DX aplikacija i onda nijedna 3rd party kontrola koja koristi HWND ne bi radila u toj aplikaciji.
Winforms na Windowsu je zakucan na GDI+ i tu ce biti dok bude Windowsa.


A sto mora nesto da ga nasledi? Sta je nasledilo MFC? Pogresno posmatras celu ovu pricu time sto WPF smatras naslednikom WinForms-a za sta je mahom kriva stampa i pompezni naslovi i mislim da sve tvoje zabune poticu odatle. MFC, WinForms i sada WPF nisu u srodstvu, oni su konkurentske GUI tehnologije i sve tri su tu da ostanu. GDI+ ce uvek biti deo Windowsa ili Windows vise nece biti Windows, oni mogu da ga preusmere, optimizuju ali ne mogu da ga ukinu i prave se i pravice se aplikacije koje na kraju rezultiraju upotrebom GDI+ toolkita. WPF to ne menja.

---

Moj cilj u početku diskusije je bio da dam jednostavno objašnjenje šta je to u biti Windows Forms. Quote sa wikipedije:



Sve što ti govoriš, u suštini si u pravu, samo što mislim da je ova definicija zbog same filozofije MS-a više prihvaćena.



Mislio sam na grafičku hardware akceleraciju. Zar nije jedini Matrox u svojim grafičkim karticama pružao akceleraciju za GDI+ ? GDI+ je za većinu mogućnosti zakucavao procesor u sami vrh...

Ostalo sve OK, sviđa mi se šira slika pogleda na stvari ...

---

Ah to te muci.

Istina, i ja sam svojevremeno cuo da je Matrox bio jedini koji je bio GDI+ accelerated, ali su sve kartice od poodavno (definitivno sve danas) GDI accelerated i to je pokrivalo skoro sve potrebe jer se GDI+ oslanjao na GDI gde god moguce. U praksi to znaci da su samo neke GDI+ operacije (kao sto je gradient brush) bile 100% emulated i trosile CPU nemilice.
Ali to je bio problem nekad (zato i nisam provalio sta te brine), sad na Visti nemas hardversku akceleraciju uopste, GDI/GDI+ vide DWM kao 100% emulated graficku karticu i sav rendering se radi softverski iz samog GDI/GDI+ emulatora direktno u DWM DC, ali posto ti je za Vistu generalno potrebna masina ciji CPU je daleko jaci nego sto su pocetkom veka bili CPU i GPU zajedno to vise nije problem.

Zaniljivo je sad pogledati neke WPF "winforms is dead" blogove iz 2003e, 2004e, i videti da se nista u tom pogledu nije desilo, velika vecina dev timova i profesionalaca nije preslo na WPF i kljucne aplikacije su i dalje WinForms only. Delimicno mislim da su se malo prevarili sa Vistom, valjda su mislili da ce svi da pohrle kao na XP i da ih je taj neuspeh malo omeo na putu sahranjivanja winforms-a.

---

Iako logika kaže da stvarno nema smisla da feature sa 7-ice može na neki drugi OS, nada je uvijek tu ... :)
Ipak naravno, ne može:



Napomena: Windows 7 je ustvari 6.1, vjerovatno jer je građen na Vista kernelu...

Ako izbacimo prethodni dio koda: Unable to find an entry point named 'SetCurrentProcessExplicitAppUserModelID' in DLL 'shell32.dll'.

Ovo se odnosi samo na neke primjere, kao što je tasklist. Ima dosta stvari koje sasvim OK rade na Visti.

---

Izasao final Codepack-a

Windows® API Code Pack for Microsoft® .NET Framework 1.0

---