Koliko ja znam na ovim leaked buildovima Longhorna Win16 aplikacije rade sasvim OK.

DOS-ovske aplikacije se ionako vrte pod emulacijom (NTVDM).

MS mora zadržati kompatibilnost unazad inače je pušiona. Makar morao u Windowse ugraditi VirtualPC :)

Meni se ta kompatibilnos cini kao jedna velika glupost... ja sam se pitao kada ce velike firme poceti da koriste .net i zasto bi to radili kada vec imaju svoje metode (placene kompajlere, programere koji su obuceni za neki programski jezik) koje sada moraju da menjaju (bez obzira koliko je to "jednostavno")... ali evo AutoCAD 2005 instalira i .net framework 1.1 tako da ce do izlaska Longhorna svi programi biti pisani u necemu sto se kompajlira u MSIL i zasto onda pruzati kompratibilnost sa nekim "zastarelim" tehnologijama???

This is wrong on, oh, so many levels.. Kompatibilnost treba biti imperativ, a ne opcija. Nova tehnologija treba da bude opcija.


A zašto da ne? I zato jer..


.. nema šanse.

Pitanje se uopšte ne postavlja. Ili će Longhorn biti kompatibilan, ili ga ljudi neće koristiti. Zašto bi iko odbacio silne investicije u postojeći softver koji dobro radi?

Znam ja tacno o cemu vi pricate... ali se meni cini da ja sada na Win2K ne koristim ni jedan program koji je pravljen za Win98 (kao i vecina XP korisnika)... Znaci svi oni porzavaju 98 (bar vecina) ali taj OS vise ne postoji... pa meni to izgleda besmisleno...

P.S. moram da napomenem da sam ja zaludjen otklanjanjem viskova :) pa mi se ta kompatibilnost cini kao jedan... moguce da ona nema nikakvu cenu kada su performanse u pitanju?

Da plaćaš softver, znao bi zašto je kompatibilnost bitna.

ahhahahh tu si 100% u pravu :)

OK, svakako nece sve (kao u originalnom pitanju) morati da bude .NET tj. radice i ostale aplikacije. Ali, mene interesuje koliko ce sam Longhorn koristiti .NET. Da li ce sastavni delovi Windows-a i aplikacije koje se uz njega dobijaju biti zasnovane na Win32 API-ju ili na .NET-u.

_{[Ovu poruku je menjao Shadowed dana 24.01.2005. u 18:16 GMT+1]}

Eh, moja greska. Poslao sam pogresan link - taj link nije za 'onaj' XP 64 koji ce uskoro da izadje, vec za neki drugi, koji je sada mnogo manje relevantan.

Tako da slobodno ignorisite ovu poruku :)

Kad će neki ljudi konačno shvatiti da je win32API mrtvac na izdisaju :)

Sve je .NET, sve sve... Što ne može managed, može kao unsafe...

Što opet ne znači da win32API neće biti podržan. I danas možeš na winXP lijepo pisati DOS-ovske i Win16 aplikacije i većina će ih fino raditi :)

Zanimljiv stav, Sundance. Sta ti predlazes kao zamenu za Win32 API? ;)

Pa WinFX (kad izađe), zasad .NET, jedan njegov mali dio :)

Win32API je ružan, bahat i neorganiziran; sve što još nije, treba enkapsulirati u managed wrappere, tako da što prije to smeće izumre i C# postane toliko popularan da na linuxu bude više mono aplikacija nego bilo čega drugog, i da svaki *nix admin umre od jada što mora koristiti tehnologije koje je MS izmislio :)

Da MS danas izbaci Longhorn, malo bi ga tko bio spreman koristiti (od developera). Ovako imamo .NET koji samo olakšava prijenos u revolucionarne nove tehnologije.

Smrt C-u!

_{NB: Ja sam malo ekstreman u nekim stavovima, što se može vidjeti, ne treba me uzimati za ozbiljno ;)}

To je sve u redu, ali WinFX kao sto i ti kazes nije zamena za Win32 vec je wrapper na njemu. Mozemo da kazemo sta god hocemo o Win32, cinjenica je da je star i da se to vidi, ali je takodje i cinjenica da je najkoriscenjiji API na svetu i da je vrlo stabilan i pouzdan (pre nego sto krenu zajedljivi komentari, probajte da uocite razliku izmedju Win32 i drugih podsistema Windowsa).

C[++] ne treba da umre 'eto onako', vec treba da umre ako mu je nadjena adekvatna zamena. Za sada nije, tako da se ne treba odricati vrlo mocnog alata. Treba izabrati pravi alat za pravu namenu.

Elem, ekstremni stavovi su ok, ali imaj u vidu da ono sto pises na internetu ostaje zauvek, i da preko toga gradis drugima sliku o sebi. Ekstremizam cesto nije popularan i kasnije ume da bude neprijatan. :)

Reljam, je l' ti to kažeš iz ličnog iskustva (neki sajtovi na akademskoj mreži mi padaju na pamet)?

Apsolutno! Ko je mogao da zna u to vreme da ce nasa akademska mreza ikada biti vidljiva sa interneta. :)

Da, ali jednom kad ljudi počnu koristiti wrappere originalna Win32 implementacija će se moći napustiti i napisati nova, bolja, u .NET jezicima!



Ma nije ovo klasičan ekstremizam...Mislim da je malo osoba na svijetu koji su toliko "očarani" Win32API-jem da bi imali ijedan drugi argument osim "gomila već postojećeg koda sa kojim se treba održati kompatibilnost".

Pa nije samo kompatibilnost u pitanju. .NET klase za sad pokrivaju samo deo funkcionalnosti Win32 API-ja. Još nisam video netrivijalan .NET program koji ne poziva makar jednu Win32 funkciju.

I ako smem da dodam, ni .NET BCL klase nisu baš preterano dobro dizajnirane (da upotrebim blagu formulaciju)

Pitanje #1.
Dragi Tata je napisao:

Da li možete reći nešto više o ovome? Da li postoje opšte prihvaćeni kriterijumi za ocenjivanje dizajna biblioteke klasa? Zašto bi Microsoft sa svim njihovim resursima (ljudskim i finansijskim) omanuo po ovom pitanju? Voleo bih da dobijem neku vrstu odgovora, sa obzirom da ste me zaintrigirali ovom tvrdnjom.

Pitanje #2.
Da li se .NET BCL klase nadovezuju na WinAPI? Da li njihovu funkcionalnost obezbeđuje WinAPI, ili je u pitanju potpuno nezavisan podsistem?
Naime, ako .NET klase koriste WinAPI, onda mi se čini da nema razloga prerano proglašavati kraj API-ja.

Većim (sistemskim) dijelom jesu, kojeg bi bio gubitak vremena ponovno pisati, s tim da se sve novo razvija ili pod .NET ili za .NET.



Gle, win32API je samo wrapper za nativne (Nt*) API-je koji su opet wrapperi za sistemske pozive NT kernela. Nitko ne garantira da, ako je recimo danas System.IO.FileStream interno wrapper za, recimo, CreateFileA, da sutra neće biti za NtCreateFile pri čemu bi se win32 potpuno zaobišao.



Usporedi broj izdanih knjiga u zadnjih 3-4 godine (tj. otkad je MS počeo sa .NET inicijativom) za win32 i za .NET.

Ovde nije običaj da persiramo jedan drugome pa ću, ako nemaš ništa protiv, da se držim tog običaja.

#1 Najpre da odmah raščistim da ne postoje opšte prihvaćeni kriterijumi za ocenjivanje dizajna klasa i to je i dalje više stvar ličnog ukusa nego preciznih metrika. Tako da ovde iznosim čisto svoje mišljenje sa kojim se mnogi ne slažu, ali se mnogi i slažu.

Mislim da je kod dizajna .NET BCL-a učinjen ozbiljan promašaj odmah u startu: izabrana je klasična OO arhitektura nalik na SmallTalk hijerarhiju koja je bila "state of the art" 80-ih, ali danas je već uveliko zastarela. Istu grešku su napravili i dizajneri Java API-ja i sad su Javine klase pravo zamešateljstvo puno dupliciranih funkcionalnosti i "deprecated" metoda, klasa i celih paketa koji i dalje moraju da budu prisutni zbog kompatibilnosti. Najsmešnije je što i .NET klase počinju da pate od bukvalno istih problema: uskoro ćemo imati dve odvojene GUI biblioteke (Win Forms i Avalon) baš kao što i Java ima (AWT i Swing), postojeće kolekcije postaju zastarele sa dolaskom novih u VS 2005 (a što je najgore ni te nove ne valjaju, pa je Microsoft inicirao neke spoljne saradnike da naprave dobre kolekcije - pogledaj Power Collections). Klase su ogromne, teško pregledne, sa prevelikim brojem metoda, i previše se koristi nasleđivanje kao sredstvo za "code reuse". Da i ne pominjem da je jako teško snaći se u toj džungli od klasa, što indirektno priznaju i u Microsoftu.

Jednostavno, "klasičan" OO ne skalira dovoljno dobro da pokrije ovako veliku biblioteku i to nije ništa novo, pa ljudi traže bolja rešenja - npr AOP. Microsoft je rešio da ne rizikuje previše sa tim (relativno) novim tehnikama i da koristi principe koji su poznati većem broju programera, ali samo je pitanje vremena kad ćemo da dobijemo Java-like kupusaru.

#2. Iskreno, ne znam. Da li .NET klase interno zovu Win32 API ili direktno subsystem nezavisne API-je nije mi poznato u ovom trenutku.

Čale (Dragi Tata) zadovoljstvo je citati tvoje postove :)

Odgovor na #2 je da, BCL je implemenitran pomocu Win32 APIja.

A nove stvari, kao što je Avalon? Koliko sam čuo, Win32 API neće imati podršku za njih.

Apsolutno.

I šta misliš Nemanja, hoće li WinForms u grob, a da još nije ni porastao? Odnosno, isplati li se više vremena posvetiti istom s obzirom na Avalon?

Ne znam, iskren da budem. Ako treba da se nešto odradi danas, onda moramo da koristimo današnje tehnologije, zar ne?

Ma to da, pitao sam onako da čujem šta misliš.

Zar se ne bi M$ ukidajuci kompatibilnost (koliko toliko) oslobodio vecine virusa (jedne od najvecih nocnih mora za njihov OS).

Kada sam postavljao pitanje mislio sam i na to da li ce sam Longhorn (kao i programi za njega) biti pisan u .NET-u ali sada vec znam odgovor na to pitanje. Tako da mi je jasno da kompatibilnost mora postojati... ali do koje mere???