Page 2 of 3

Re: WinRT

Posted: 22 May 2012, 10:39
by neagu_laurentiu
In povestea asta pe mine nu RAD-ul ma incanta (ajuta si el cateodata) ci faptul ca biblioteca VCL include mult mai multe componente utile. MFC s-a dorit din start a fi un wrapper peste WinAPI care sa impace atat capra cat si varza si nu framework de nivel inalt.

Re: WinRT

Posted: 22 May 2012, 11:17
by Ovidiu Cucu
neagu_laurentiu wrote:In povestea asta pe mine nu RAD-ul ma incanta (ajuta si el cateodata) ci faptul ca biblioteca VCL include mult mai multe componente utile. MFC s-a dorit din start a fi un wrapper peste WinAPI care sa impace atat capra cat si varza si nu framework de nivel inalt.
Tocmai asta imi place cel mai mult la MFC.
Intradevar, in prima faza a unui proiect e posibil sa fie nevoie de timp si de unul-doi in echipa care sa "bungheasca" (pe langa "furnicute", "masini de scris cod" sau "negri pe plantatie", ca sa citez expresiile denumind developerii pe care le-am intalnit cel mai des) ca sa se faca oaresce extensii si componente, care alte framework-uri ti le-ar da mura-n gura.

Insa pe cealalta parte, folosind un framework bengo, ce facem daca nu contine de-a gata ceva ce musa-i sa fie, sau contine dar nu-i tocmai cum vrea nenea clientul?
Asteptam versiunea urmatoare (poate, poate...), dam parale sa cumparam (si cheltuim ce-am economisit angajand doar "furnicute"), sau ne uitam la figura disperata a "negrisorilor" bajbaind prin chestii care nu se pot face din drag-and-drop si lista pe proprietati? ;)

Re: WinRT

Posted: 22 May 2012, 11:34
by neagu_laurentiu
Tu duci la extrem povestea cu cele de nivel inalt. La multe din ele poti face custom la fel de bine ca in MFC. Totul e sa fi "venit" din WinAPI ori MFC si nu ai probleme. Sigur ca incepatorii care sar direct in el si nici OOP nu stiu sau intreaba cei aia WndProc vor zice ca nu se poate.

Re: WinRT

Posted: 22 May 2012, 12:08
by Ovidiu Cucu
neagu_laurentiu wrote:Tu duci la extrem povestea cu cele de nivel inalt. La multe din ele poti face custom la fel de bine ca in MFC. Totul e sa fi "venit" din WinAPI ori MFC si nu ai probleme. Sigur ca incepatorii care sar direct in el si nici OOP nu stiu sau intreaba cei aia WndProc vor zice ca nu se poate.
O "furnicuta MFC" nu are nevoie si poate foarte bine sa-si faca treaba fara sa aiba habar de WndProc. Mai mult, eu i-as recomanda sa nu-si bage nasul (pardon, antenele) pe-acolo daca nu stie bine ce face.
Chiar si unul care "bungheste" stie ca in general, in MFC nu e nevoie sa suprascrii CWnd::WindowProc decat ca sa te afli-n treaba. :)

Well, stiu si eu ca poti scrie extensii folosind WinAPI si in VB si in limbajele .NET, in mod sigur si in Delphi.
Problemele sunt doua:
  • e mai greu, mai nenatural, mai peste mana;
  • odata ce cineva a stat/sta cocotat pe-un norisor (framework-uri inalte), e mai putin probabil sa faca treaba buna pe pamant (prin WinAPI de la mama lor).

Re: WinRT

Posted: 22 May 2012, 12:16
by neagu_laurentiu
Problemele ridicate tin de experienta fiecaruia.
Iar "furnicuta MFC" va consuma mai mult cu acelasi rezultat.

Re: WinRT

Posted: 22 May 2012, 12:38
by Ovidiu Cucu
Apropo:
Q: Ce anume zapaceste, inerveaza, umple de oroare cel mai mult o "albinuta .NET", bazaind prin norisor si privind in jos la MFC?
A: Faptul ca vede "prea multe tipuri de stringuri: CString, LPSTR, LPWSTR, LPCSTR, LPCWSTR, LPCTSTR, s.a.m.d. "

Caz real, insa nu vreau sa pun link aici pentru ca e vorba totusi de o albinuta .NET de treaba. :D

Re: WinRT

Posted: 22 May 2012, 12:52
by neagu_laurentiu
Cunosc discutia :)

Re: WinRT

Posted: 22 May 2012, 16:38
by tudor_t
Ovidiu Cucu wrote:
neagu_laurentiu wrote: Insa pe cealalta parte, folosind un framework bengo, ce facem daca nu contine de-a gata ceva ce musa-i sa fie, sau contine dar nu-i tocmai cum vrea nenea clientul?
Asteptam versiunea urmatoare (poate, poate...), dam parale sa cumparam (si cheltuim ce-am economisit angajand doar "furnicute"), sau ne uitam la figura disperata a "negrisorilor" bajbaind prin chestii care nu se pot face din drag-and-drop si lista pe proprietati? ;)
Depinde de tipul de aplicatii de care se loveste zi de zi - cum marea majoritate fac doar aceleasi aplicatii de gestiune, forms over data, cu mult CRUD si putin business logic, in care partea de UI e cel mai adesea triviala, rarele cazuri in care e nevoie de customizari sunt acoperite de frameworkul folosit (VCL, WinForms, WPF, Silverlight etc..) fara mare efort..
Pentru genul asta de aplicatii 'RAD'-ul e mai potrivit.
Normal, pentru cei norocosi sa lucreze pe aplicatii mai interesante, MFC, ATL etc. sunt mai potrivite.

Re: WinRT

Posted: 22 May 2012, 20:06
by Ovidiu Cucu
Orice aplicatie se poate face fara prea mare efort, doar cu Excel + VBA. :)
Fara misto, multi chiar cred asta.

Re: WinRT

Posted: 23 May 2012, 08:26
by cristianamarie
WinRT si alte din astea folosesc COM ca e singura treaba care poate transporta un vtable de colo colo clar. COM n-a aparut ca sa deseneze mesterii net progress bar verzulii (in alt thread, evident), ci pentru interoperabilitate si lifetime. Dovada ca a iesit foarte bine (si ca alti MS haters copie odata la 2-3 ani IUnknown - Bonobo, OpenDOC, XPCOM de la Mozilla care chiar cu COM se cheama) e ca nici dupa 20 de ani de atita "COM is dead" el e bine mersi. Numai daca ne uitam cite API-uri noi de COM apar...

Problema lor nu e HWND si altele - oricit ar da-o, o fereastra tot un obiect kernel e pina la urma si tot cu ZwCreateMutant se face, ca si orice alt HANDLE. Cit ca le e destul de greu sa foloseasca treburi C in limbaje non-C. Numai cind vad armata de PInvoke care nu difera cu nimic de declaratiile VB6 imi dau seama ca nu a evoluat nimic din punctul asta de vedere. (Vorba lui Mark Russinovich care zicea de XP - si acum ce nu puteam face in NT4 si pot in XP? Nimic.)

Probabil o sa fie ca si pina acum: o noua supertehnologie care face tot numai din mouse. Asta pina cind dai de primul IUnknown care e creat intr-un thread si ai nevoie sa il accesezi din altul, si incepem CoLockObjectExternal, proxy, IGlobalInterfaceTable etc. si constati ca tot Win32/COM e singura cale. Nu poate fi nimic mai puternic decit ce e nativ, sper ca nu crede nimeni ca File.Open() e mai puternic decit NtCreateFile...

Re: WinRT

Posted: 23 May 2012, 09:40
by tudor_t
cristianamarie wrote:Probabil o sa fie ca si pina acum: o noua supertehnologie care face tot numai din mouse. Asta pina cind dai de primul IUnknown care e creat intr-un thread si ai nevoie sa il accesezi din altul, si incepem CoLockObjectExternal, proxy, IGlobalInterfaceTable etc. si constati ca tot Win32/COM e singura cale. Nu poate fi nimic mai puternic decit ce e nativ, sper ca nu crede nimeni ca File.Open() e mai puternic decit NtCreateFile...
Nici nu trebuie sa ajunga asa departe - in WinRT+.NET omu' trebuie sa stie uneori din prima ce-i ala STA si MTA, doar ca sa afle coordonatele GPS: http://msdn.microsoft.com/en-us/library ... geolocator , chiar daca 10 ani multi au ignorat "detaliile" astea, desi poate s-au intrebat uneori ce rost are acel
[STAThread]
static void Main()
ce il vedeau in fiecare nou proiect WinForms.. :)
Din pacate multi doar se vor multumi sa aplice niste reguli mecanic, fara sa inteleaga de fapt ce inseamna "chestia" aia.

Re: WinRT

Posted: 23 May 2012, 10:31
by Ovidiu Cucu
tudor_t wrote:
cristianamarie wrote:Probabil o sa fie ca si pina acum: o noua supertehnologie care face tot numai din mouse. Asta pina cind dai de primul IUnknown care e creat intr-un thread si ai nevoie sa il accesezi din altul, si incepem CoLockObjectExternal, proxy, IGlobalInterfaceTable etc. si constati ca tot Win32/COM e singura cale. Nu poate fi nimic mai puternic decit ce e nativ, sper ca nu crede nimeni ca File.Open() e mai puternic decit NtCreateFile...
Nici nu trebuie sa ajunga asa departe - in WinRT+.NET omu' trebuie sa stie uneori din prima ce-i ala STA si MTA, doar ca sa afle coordonatele GPS: http://msdn.microsoft.com/en-us/library ... geolocator , chiar daca 10 ani multi au ignorat "detaliile" astea, desi poate s-au intrebat uneori ce rost are acel
[STAThread]
static void Main()
ce il vedeau in fiecare nou proiect WinForms.. :)
Din pacate multi doar se vor multumi sa aplice niste reguli mecanic, fara sa inteleaga de fapt ce inseamna "chestia" aia.
Din pacate, dupa 10 ani de avant in industria software (si nu numai) au urmat 10 ani de declin.
Ajustand perioada la cei 11 ani ai ciclului solar si sperand ca vom fi toti bine-mersi dupa 21.12.2012, vor veni la rand si vremurile bune... :biggrin:

Re: WinRT

Posted: 23 May 2012, 10:44
by tudor_t
Depinde din ce perspectiva :) - daca in astia 10 ani o firma a produs o multime de aplicatii, clientul a fost multumit si banu' a venit, nu e declin.. ;)
WinRT si metro apps vor lua si mai mult din "libertatea" si controlul developerului decat a facut-o .NET-ul pe vremuri, dar pentru un business nu e decat o sansa sa intre mai usor pe piata mobile/tablets..

Re: WinRT

Posted: 23 May 2012, 10:50
by Ovidiu Cucu
Ok, sper insa ca Metro nu va aduce MS in situatia lui HP de cand unor manageri de acolo li s-a facut greata de PC. ;)

[ Later edit ]
Pentru HP (Hewlett Packard) am o stima deosebita inca din anii '80, cand nici macar nu auzisem de Microsoft.
Pacat de ei sa se duca la vale. Asta e... vedem ce se intampla dupa 21.12.2012... :)

Re: WinRT

Posted: 24 May 2012, 13:04
by viorel2005
WinRT si alte din astea folosesc COM ca e singura treaba care poate transporta un vtable de colo colo clar. COM n-a aparut ca sa deseneze mesterii net progress bar verzulii (in alt thread, evident), ci pentru interoperabilitate si lifetime.
Cand eram in facultate(prin anul 2003) am incercat sa invat COM. Nu am reusit datorita faptului ca documentatia nu prea exista. Totusi m-a atras.
Cand am luat prima bursa mi-am luat carte de Visual C++.NET 2002 de la Teora. Si am cumparat si cartea Modern C++ Design si Bazele utilizarii Visual C++ 4.
Surprinzator cartea de Visual C++ 4.0 a fost mult mai buna decat cartea Utilizare Visual C++ 6 Editie speciala. Apoi am piratat o carte de pe net despre COM
din multe alte carti. Si pot sa spun ca una din ele mi-a atras atentia prin modul cum le prezenta. Dar nenorocirea acestor tehnologii este ca nici o carte nu iti prezinta bazele proiectarii.
In 2003-2004 au fost o serie de carti de tipul: Professiona Projescts in Visual C++, PHP etc. In zilele de azi nu mai apar astfel de editii. Din fericire sunt bloguri.
Si acest forum de C++ imi place ca spune o multime de lucruri bune despre MFC si C++. Dar problema este la COM. Nu pot sa inteleg faptul de ce acest aspect a fost
neglijat cand tehnologia COM se foloseste mult in sistemele Windows.


In legatura cu intrebarea despre RAD. In comparatie cu Visual C++, C++ Builder este un fel de Java al lui C++. A nu se compara limbajul C# cu Java, deoarece Java este mult
mai traditional si bine proiectat. Personal nu cred ca era nevoie de C#. O librarie pentru C++ cum este VCL era suficienta. Singura problema care o am acum este Objective-C
si programarea unui produs Apple. Daca ObjectiveC il mai putem accepta(deci personal as fi dorit un simplu C), nu pot sa ma pronunt pentru partea de API. Tinand cont
ca la baza are Linux, nu inteleg de ce au trebuit sa aleaga ObjectiveC.