[MFC/Win32] Toekomst van deze API's

[Verwijderd]

Wat zijn hier de meningen over de toekomst van de MFC en Win32 APi's?

Aan de ene kant is er het bericht van MS dat win32 -de- core API van nieuwe windows versies zal blijven. Tevens is er nog enorm veel bestaande MFC/Win32 software, die natuurlijk niet even snel omgebouwd gaat worden naar een nieuwe API. Microsoft's eigen Office produkten en Visual Studio zijn natuurlijk grote voorbeelden. Ook voor core operating system processes wordt expliciet win32 aangeraden:

http://support.microsoft....aspx?scid=kb;en-us;841927
We recommend that you only use C languages and Win32 APIs for any add-in components that are loaded by core operating system processes. Two examples of core operating system processes are Winlogon.exe and Lsass.exe.

Aan de andere kant lijkt er weinig ontwikkeling meer gedaan te worden voor deze beide API's, en zeker MFC staat op een laag pitje. De laatste platform SDK update is bv van february 2003, terwijl de laatste .NET update (wel beta) nog geen 2 maanden oud is. Ook zie ik in vacatures alleen nog maar .NET gevraagt worden (kwa MS technieken), terwijl win32 en MFC niet meer lijken te bestaan voor ondernemers.

Kwa software opzich kom ik ook nog niet super veel .NET applicaties tegen, maar mischien kijk ik gewoon niet zo goed. De komende ATI catalyst control centre is eentje die me zo te binnen schiet.

Een punt van twijfel zou mischien kunnen zijn: zou je nu nog applicaties gericht op win32/MFC moeten schrijven, of is het verstandiger om alle compleet nieuwe dingen die je nu begint juist niet daarop te bouwen vanwege de wellicht onzekere toekomst?

[curry684]

MFC is geen API, maar een class framework dat enkel een ultrathin wrapper om Win32 legt. Als zodanig wordt het dan ook al meerdere jaren niet meer gesupport.

Win32 wordt nog gewoon ontwikkeld en blijft bestaan, wat logisch is omdat .NET veel kan maar geen drivers of lowlevel programmatuur schrijven.

* curry684 vindt dit topic nogal mikken op open deuren

[Daantje20]

Ik heb er abslotuut geen verstand van, maar uit je vehaal maak ik op dat je zo ie zo met Win32 nog vooruit kan en later kan uitbouwen naar .NET als het echt nodig is.

jus my 2ct.

[Verwijderd]

curry684 schreef op 18 augustus 2004 @ 20:58:
MFC is geen API, maar een class framework dat enkel een ultrathin wrapper om Win32 legt. Als zodanig wordt het dan ook al meerdere jaren niet meer gesupport.

Zo thin is de wrapper niet altijd API, (class) library, en framework wordt natuurlijk nog als eens door elkaar gebruikt. In principe is .NET, of Java dan weer een platform waar defacto (class) libraries min of meer bijhoren.

Win32 wordt nog gewoon ontwikkeld en blijft bestaan, wat logisch is omdat .NET veel kan maar geen drivers of lowlevel programmatuur schrijven.

Sure, maar niet elk stuk code is natuurlijk een driver of gebruikt lowlevel dingen. Andersom kan het gros van de applicaties zowel met win32 of .NET geschreven worden. Als jij nu een applicatie van de grond af zou gaan schrijven, wat zou jij dat gebruiken?

* curry684 vindt dit topic nogal mikken op open deuren [/quote]

Ach

@daantje

Ik weet niet of dat 'ff' uitbouwen naar .NET wel zo'n goed idee is eigenlijk. Lijkt me eerder dat je als je toch al later naar .NET wilt overstappen, je dat gewoon nu meteen moet doen voor een nieuwe app.

[ Voor 11% gewijzigd door Verwijderd op 18-08-2004 21:11 ]

[curry684]

Verwijderd schreef op 18 augustus 2004 @ 21:09:
[...]

Zo thin is de wrapper niet altijd API, (class) library, en framework wordt natuurlijk nog als eens door elkaar gebruikt. In principe is .NET, of Java dan weer een platform waar defacto (class) libraries min of meer bijhoren.

Nee, een framework hoort iets te zijn dat werk van je overneemt. MFC gaat op (vrijwel) geen enkel punt verder dan het plaatsen van Win32-calls in een classcontext, waarbij de enige membervariabele de handle is en je dus alle calls met 1 parameter minder mag maken. MFC encapsuleert niet, is dom en slecht opgezet, en wordt dus al jaren niet meer gebruikt of gesupport.

[...]

Sure, maar niet elk stuk code is natuurlijk een driver of gebruikt lowlevel dingen. Andersom kan het gros van de applicaties zowel met win32 of .NET geschreven worden. Als jij nu een applicatie van de grond af zou gaan schrijven, wat zou jij dat gebruiken?

Dat was niet de vraag Win32/Win64 blijven bestaan, of je nu wilt of niet, en daarmee beantwoordde ik je vraag al volledig

Maar de nieuwe vraag: dat C#/.NET een zeer werkbaar alternatief is om GUI's te ontwikkelen is een feit, en zal ik ook als optie overwegen bij nieuwe projecten (ik werk al fulltime in C# op ASP.NET atm overigens). Voor services en vergelijkbaar lower-level werk zal ik voorlopig nog gewoon C++ op Win32 blijven gebruiken.

Daantje20 schreef op 18 augustus 2004 @ 20:59:
Ik heb er abslotuut geen verstand van, maar uit je vehaal maak ik op dat je zo ie zo met Win32 nog vooruit kan en later kan uitbouwen naar .NET als het echt nodig is.

.NET is alleen al voor de taalkeuze een dermate fundamentele beslissing dat je niet kunt om- of uitbouwen. .NET werkt alleen met C# of VB.NET, geen kip die managed C++ schrijft. En erger nog: C++ en MC++ zijn zo hard incompatible (en zullen dat zelfs met Whidbey nog redelijk blijven) dat omschrijven zelden haalbare kaart zal blijken.

[ Voor 18% gewijzigd door curry684 op 18-08-2004 21:15 ]

[MSalters]

whoami had gisteren een mooie link in #devschuur. De wijzigingen tussen MC++ en C++/CLI zijn idd erg groo, en C++/CLI lijkt wel een reeel genoeg alternatief voor C#.

[Verwijderd]

curry684 schreef op 18 augustus 2004 @ 21:13:
[...]

Nee, een framework hoort iets te zijn dat werk van je overneemt. MFC gaat op (vrijwel) geen enkel punt verder dan het plaatsen van Win32-calls in een classcontext.

Valt wel mee hoor. Bv de threading support gaat wat verder. Tevens brengt het een aantal eigen dingen mee als messagemaps, dynamic class instantiation etc (maar of je daar blij mee moet zijn is natuurlijk weer een heel ander verhaal). Plus dat MFC een soort van eigen kernel heeft. Het is juist een van de kritiek punten op MFC, dat het eigenlijk een wrapper lib had moeten zijn, en onnodig (?) veels te zwaar is.

En, MFC wordt net zo vaak met de term class library als framework aangeduid hoor!

Dat was niet de vraag

uhm dit is toch hetzelfde:

Verwijderd schreef op 18 augustus 2004 @ 20:54:
zou je nu nog applicaties gericht op win32/MFC moeten schrijven, of is het verstandiger om alle compleet nieuwe dingen die je nu begint juist niet daarop te bouwen vanwege de wellicht onzekere toekomst?

Nouja, mischien was ik beetje onduidelijk met formuleren.

Win32/Win64 blijven bestaan, of je nu wilt of niet, en daarmee beantwoordde ik je vraag al volledig

Er zijn natuurlijk ook nog wat rumors over de opvolger van de Win32 api: WinFx.

.NET is alleen al voor de taalkeuze een dermate fundamentele beslissing dat je niet kunt om- of uitbouwen. .NET werkt alleen met C# of VB.NET, geen kip die managed C++ schrijft.

Dat is natuurlijk ook zo. Voor een C++ app zijn de .Net libraries mischien niet echt een keuze. Ik verwacht echter toch wel vrij veel van de nieuwe C++/CLI binding. Als de .NET libraries wel de belangrijkste libs worden (als we alleen even het lib gedeelte beschouwen), dan is dat natuurlijk op z'n minst 'jammer' voor C++ programmeurs (als het bij MC++ zou blijven).

Overigens was ik nog vergeten op te merken dat veel van de .NET libraries natuurlijk ook een wrapper zijn voor de win32 API.

[whoami]

MSalters schreef op 18 augustus 2004 @ 22:03:
whoami had gisteren een mooie link in #devschuur. De wijzigingen tussen MC++ en C++/CLI zijn idd erg groo, en C++/CLI lijkt wel een reeel genoeg alternatief voor C#.

deze link dus.

henk_DE_man: een framework (bv: VCL, .NET)is zeker niet hetzelfde als een class library (MFC, Borlands OWL) hoor.
Ik zal er thuis eens een mooie definitie van opzoeken. Doch dit geheel terzijde.

[Verwijderd]

whoami schreef op 19 augustus 2004 @ 08:36:
henk_DE_man: een framework (bv: VCL, .NET)is zeker niet hetzelfde als een class library (MFC, Borlands OWL) hoor.
Ik zal er thuis eens een mooie definitie van opzoeken. Doch dit geheel terzijde.

Ja, natuurlijk weten we allemaal wel dat een framework niet hetzelfde is als een class library.

Ik zal er ook eens een mooie definitie voor opzoeken, maar gevoelsmatig zeg ik dat een (application) framework een overkoepelende 'skeleton' applicatie is waar jij min of meer je eigen functionaliteit aantoevoegd die dan door het framework wordt aangeroepen.

Een pure class library is veel meer extern. De initiele flow of control zit in jouw aplicatie, en je roept functionaliteit van de lib aan (precies andersom dus).

Dat gezegd te hebben, blijft het zo dat MFC vaak een class library wordt genoemd, mischien niet terecht, maar wel praktijk. MS zelf zegt het overigens zo:

The Microsoft Foundation Class Library is an application framework for programming in Microsoft Windows.

Die link is overigens wel aardig. Zat hem zelf gisteren ook te lezen; je kunt hem gewoon rechtstreeks vanaf de MSDN frontpage bereiken.

Overigens, ook related aan dit topic is een nieuwe open source win32 C++ wrapper: win32gui ( http://www.torjo.com/win32gui/ ), nog niet af, maar ziet er wel veelbelovend uit.

[ Voor 15% gewijzigd door Verwijderd op 19-08-2004 10:54 ]

[flowerp]

Ik zit wel een beetje met hetzelfde. Ik ben in de eerste instantie C++ programmeur. Nu moeten wij voor een klant een maatwerk windows applicatie schrijven. Het hele traject zal ongeveer 4 maanden gaan duren, maar 1 maand uitloop is al mee genomen.

Welke API, class library, framework, toolkit, etc zal ik eens gaan gebruiken? Traditioneel was het altijd MFC. Geen enkele API, class library, framework, toolkit, etc, heeft het eeuwige leven, maar aangezien MFC nu al dood is lijkt me dit nu geen goede keuze meer.

Hoewel we nu nog in de allereerste plannings fase zitten heeft mijn manager gesuggereerd dat we dan maar eens van de ouderwetse C++ moeten afstappen en dat ik maar eventjes C# moet gaan leren zodat we het project met de veel betere win32 wrapper van .NET kunnen maken.

Nouja, fine, dan leer ik wel 'eventjes' C#. Wel jammer, maar goed. Als C++ niet meer kan meekomen op het Windows platform...

(zowel dat win32gui als de nieuwe CLI versie van C++ lijkt me overigens wel leuk, maarja, ik moet nu aan de gang ongeveer, en niet over 2 jaar ofzo)

[whoami]

C++ niet meer kunnen meekomen op het Windows platform? Dat is wel een beetje hard van stapel lopen hoor.

Nee, het voordeel van .NET tov C++ is dat je je meer kunt focussen op je applicatie zelf, ipv met al het 'Windows geneuzel' bezig te zijn, waardoor je sneller iets kunt ontwikkelen.

[curry684]

C++ blijft leven op het Windows platform, maar C# gaat veel desktopwerk overnemen.

En over 'even snel leren', ach ik kreeg paar maanden terug op vrijdag te horen dat ik de maandagochtend erop werd verondersteld C# Expert te zijn... eitje

[flowerp]

whoami schreef op 21 augustus 2004 @ 12:47:
C++ niet meer kunnen meekomen op het Windows platform? Dat is wel een beetje hard van stapel lopen hoor.

Ja, nee, uh... het is natuurlijk niet C++ zelf, maar wel de API, class library, framework, toolkit, etc. De technische eisen voor mijn project zijn: het moet OO zijn (win32 valt dus af) en het moet goed ondersteund worden (tot in de overzienbare toekomst) op het doel platform (MFC en win32gui vallen dus af).

Tsja, wat blijft er over?

Nee, het voordeel van .NET tov C++ is [...]

Maar .NET is geen programmeertaal!

Het gaat mij niet om C++ zelf (dat blijft mijn favoriete taal), het gaat om de support API, class library, framework, toolkit, etc. De default MS library voor het .NET platform is rijk, wordt uitstekend ondersteund en is volledig OO.

Ik zou zeggen dat deze lib DE lib is om gewone windows applicaties mee te bouwen. En met gewoon bedoel ik dan zo'n beetje alles behalve device drivers enzo. Alleen is deze library dus niet (goed) te gebruiken vanuit C++, zodat deze taal dus op dit moment niet kan meekomen op het windows platform. En nee, voor alle zekerheid nogmaals: niet vanwege de taal zelf (al denkt mijn manager er wel zo over), maar vanwege de support.

Overigens is op het Apple platform C++ ook al niet de eerste keuze voor de primaire API, class library, framework, toolkit, etc. (wordt objective-c en java gebruikt), en onder Linux begreep ik dat alles liever in C gedaan wordt.

[flowerp]

curry684 schreef op 21 augustus 2004 @ 14:16:

En over 'even snel leren', ach ik kreeg paar maanden terug op vrijdag te horen dat ik de maandagochtend erop werd verondersteld C# Expert te zijn... eitje

Ja, zoiets ging het bij ons dus ook

Ik gebruik meestal toch al niet vaak de aller complexte dingen uit C++, ( zoals mischien .oisyn of henk_de_man wel doen gezien hun postings ). Ik wissel nu al kwa projecten vaak tussen C++ en Java, dus C# kan er dan ook nog wel bij.

[whoami]

flowerp schreef op 21 augustus 2004 @ 14:23:
[...]


Maar .NET is geen programmeertaal!

Nee, dat zeg ik ook niet. Ik heb bewust .NET genoemd hier, en niet één van de .NET talen.
Welke .NET taal je ook neemt, maakt niet uit. Je maakt gebruik van hetzelfde framework (.NET), en het is net dat framework dat veel uit handen neemt.

Als C++ je favoriete taal is, dan zou ik nu eens naar C# kijken, en dan later (als Whidbey er is), eens naar de nieuwe implementatie van C++ in .NET (C++/CLI).

C# is op dit moment dè .NET taal; het is een taal die specifiek ontworpen is daarvoor, en als je naar het .NET framework gaat, zou ik op dit moment zeker voor C# kiezen.
Eigenlijk doe je er goed aan denk ik om op dit moment voor .NET te kiezen als je desktop applicaties/business applicaties voor het Windows platform gaat gaan ontwikkelen.

Ik ben zelf enkele jaren geleden van Delphi naar .NET/C# overgestapt, en ik heb me die keuze nog niet beklaagd. Het is een leuke taal, het .NET framework is goed, uitgebreid, en je vind veel documentatie.
(Pas op; hiermee wil ik Delphi niet afvoeren ofzo, soms werk ik nog wel eens in Delphi ook, maar het is gewoon een leuke omgeving. )

[ Voor 17% gewijzigd door whoami op 21-08-2004 15:41 ]

[flowerp]

whoami schreef op 21 augustus 2004 @ 15:39:
C# is op dit moment dè .NET taal; het is een taal die specifiek ontworpen is daarvoor, en als je naar het .NET framework gaat, zou ik op dit moment zeker voor C# kiezen.
Eigenlijk doe je er goed aan denk ik om op dit moment voor .NET te kiezen als je desktop applicaties/business applicaties voor het Windows platform gaat gaan ontwikkelen.

Ik denk dat je gelijk hebt ja. Dit is dus waar we ook aan zaten te denken, maar het is natuurlijk altijd mooi om bevestiging van anderen te horen. Ik zat nog een heel klein beetje te twijfelen met J#, aangezien dat gewoon Java is met de .NET libraries, maar mischien is dat toch een beetje een rare keuze. Ook nam ik nog heel even Qt in overweging, maar portability is absoluut geen vereiste, plus dat er wat weerstand bij het management is tegen Qt (voor Unix omgeving zou het goedgekeurd zijn, maar voor Windows willen ze er niet aan beginnen).

C#/.Net is dus momenteel de enigste goede combinatie voor desktop/business/gui applicaties onder Windows.

[whoami]

flowerp schreef op 21 augustus 2004 @ 15:51:
[...]


C#/.Net is dus momenteel de enigste goede combinatie voor desktop/business/gui applicaties onder Windows.

De enigste; dat is straf verwoord hoor.
Het is een goede keuze, zeker als je van een C++ achtergrond komt.

[flowerp]

whoami schreef op 21 augustus 2004 @ 16:02:
[...]

De enigste; dat is straf verwoord hoor.

Niet de enigste, maar de enigste goede

Wat zou jij dan (persoonlijk) als een goede 2de keuze zien?

[Creepy]

flowerp schreef op 21 augustus 2004 @ 17:13:
[...]


Niet de enigste, maar de enigste goede

Wat zou jij dan (persoonlijk) als een goede 2de keuze zien?

Delphi/Delphi.NET bijv.

Imho is de VCL een goed framework. .NET heeft er overigens erg veel van weg En nu Borland met delphi 8 en VCL.NET ook het .NET gebeuren induikt lijkt dit me ook een prima kandidaat.

offtopic:
enige, geen enigste

[ Voor 25% gewijzigd door Creepy op 21-08-2004 18:56 ]

[EfBe]

Ach, totaan longhorn heb je geen problemen met win32/MFC en COM. VS.NET 2005 is ook volledig win32/COM met hierendaar wat .NET, dus het kan nog wel even voort

[flowerp]

Creepy schreef op 21 augustus 2004 @ 18:55:
[...]

Delphi/Delphi.NET bijv.

Het gaat natuurlijk (voor mij) juist om iets met C++ erin

offtopic:
[quote]
enige, geen enigste
[/quote]
Weer wat geleerd

[MSalters]

flowerp schreef op 21 augustus 2004 @ 15:51:
Ook nam ik nog heel even Qt in overweging, maar portability is absoluut geen vereiste, plus dat er wat weerstand bij het management is tegen Qt (voor Unix omgeving zou het goedgekeurd zijn, maar voor Windows willen ze er niet aan beginnen).

C#/.Net is dus momenteel de enigste goede combinatie voor desktop/business/gui applicaties onder Windows.

Portabiliteit is geen vereiste, ok - maar dat is geen nadeel van Qt. Ikzelf vindt Qt behoorlijk geschikt voor een GUI, signals/slots werken best prettig. Wat is het probleem van je management? Toekomstzekerheid is het ook niet, Qt 4 komt er al aan en vanwege de sterke positie in de Linux markt valt Trolltech niet 1-2-3 om.

[flowerp]

MSalters schreef op 21 augustus 2004 @ 20:52:
[...]

Portabiliteit is geen vereiste, ok - maar dat is geen nadeel van Qt. Ikzelf vindt Qt behoorlijk geschikt voor een GUI, signals/slots werken best prettig. Wat is het probleem van je management? Toekomstzekerheid is het ook niet, Qt 4 komt er al aan en vanwege de sterke positie in de Linux markt valt Trolltech niet 1-2-3 om.

Er is ook geen technische reden voor. Er wordt gedacht dat het een Unix technologie is die het 'toevallig' ook onder Windows doet. Voorts wordt het nooit genoemd als vereiste in vacatures voor Windows projecten van andere bedrijven. Daar staat wel telkens .NET of C# tussen. Allerlei klanten waar 'ze' langsgaan horen ze ook allemaal spreken over vorige projecten die heel sucesvol verliepen en die op .NET gebasseerd waren.

M.a.w. iedereen gebruikt het (.NET), dus wij moeten het ook gebruiken. Qt wordt niet genoeg gehyped, ze horen het nergens. Alleen een van die (lastige) programmeurs begint er over, dus is het automatisch niet interesant.

Gerelateerd: onze vorige web projecten waren bv gebasseerd op J2EE. Nu hoort een van de managers opeens het woord PHP heel vaak, en natuurlijk komt daarna dan de 'suggestie' waarom wij eigenlijk niet op PHP overstappen.