MFC oder WinAPI oder .NET

Sebastian Thalhammer

Erfahrenes Mitglied
Hi.

Mir geht die Frage durch den Kopf, welcher dieser Teile die Zukunft gehört.
Zahlt es sich überhaupt noch aus reines WinAPI zu programmieren oder soll man gleich mit MFC anfangen. Wie steht es aber mit den .NET Sprachen.

P.S.: Kann man MFC eigentlich mit Win API kombinieren?
 
Also .NET is neu, alles will .NET haben, und in ein paar jahren wird man drauf kommen wie blöd man eigendlich is wenn man .NET programmiert.

round(Portabilität) = NULL

Also unter linux is nix mit .NET, und ich sag dir das linux in ein´paar jahren 30 - 50% marktanteil haben wird.

MFC is das gleiche...

Das einzige wo du ner chance hast, zumindest halbwegs einfach einen linux port herzustellen is das winAPI

Dann is bei .NET das problem das es net überall läuft weil man n .NET framework braucht, und viele nutzer weigern sich das zu installiere...
bei MFC braucht man die MFC runtimes, also sieht es ähnlich aus...

Tja.. bleibt das API.

Kombination von API und MFC ist grundsätzlich nicht vorgesehen, aber möglich. Sollte jedoch vermieden werden, schon aus dem grund weil sich MFC über die API header aufregt und umgekehrt.
 
Mit was programmierst du?

Bei Win API stört mich aber das detailgenau editieren der Form. (Buttons, Textboxen, usw.) Bei MFC geht das ja leichter mit dem Editor. Grundsätzlich programmiere ich ja auch gerade Win API aber da ich gerade erst angefangen habe wollte ich mich mal nach anderen Möglichkeiten umhören.
 
ch programmiere eigendlich fast ausschließlich API... nur wenn ich n bestehendes Programm erweitern oder abändern muss greif ich auf die dort verwendeten elemente zurück.

Die einzige Ausnahme stellt hier die Spiele Programmierung dar, da arbeite ich im 2D bereicht fast ausschließlich mti DirectDraw und im 3D bereich mit OpenGL

btw: den Editor kannst du auch beim API benutzen, spaart viel arbeit.
 
Erstell deinen Dialog ganz normal mit dem Resourcen editor, und dann:

HWND CreateDialog(
HINSTANCE hInstance, // handle to application instance
LPCTSTR lpTemplate, // identifies dialog box template name
HWND hWndParent, // handle to owner window
DLGPROC lpDialogFunc // pointer to dialog box procedure
);


hInstance ist klar
lpTemplate ist die resourcenID (ACHTUNG: MAKEINTRESOURCE() benutzen)
hWndParent ist das elternfenster
und lpDialogFunc ist die dialog prozedur die zu dem dialog gehöhrt. Funktioniert ähnlich wie eine WindowProc nur das sie BOOL zurück gibt,

BOOL CALLBACK DialogProc(
HWND hwndDlg, // handle to dialog box
UINT uMsg, // message
WPARAM wParam, // first message parameter
LPARAM lParam // second message parameter
);

Du musst außer bei WM_INITDIALOG, true zurück geben wenn du die message verarbeitet hast, und false wenn nicht.

Wenn du Window-handle von den elementen brauchst gibt die mit GetDlgItem();

Ähnliches gilt auch für Menüs....
Menüs werden mit
HMENU LoadMenu(
HINSTANCE hInstance, // handle to application instance
LPCTSTR lpMenuName // menu name string or menu-resource
// identifier
);
aus den resource geladen.
 
Original geschrieben von chibisuke
Also .NET is neu, alles will .NET haben, und in ein paar jahren wird man drauf kommen wie blöd man eigendlich is wenn man .NET programmiert.

round(Portabilität) = NULL

Also unter linux is nix mit .NET, und ich sag dir das linux in ein´paar jahren 30 - 50% marktanteil haben wird.

Die Portabilität ist sehr wohl gegeben. Was ist denn mit Mono? Ganz nebenbei ist alles andere (also MFC + Win32-API) noch weniger Portabel. Wenn Du portibilität willst, nimm Java oder C++ mit QT.

Original geschrieben von chibisuke

Das einzige wo du ner chance hast, zumindest halbwegs einfach einen linux port herzustellen is das winAPI

lol. Das ist nicht Dein Ernst, oder ? Jetzt sag mir mal, wie Du mit der Win32-API einen Port machen willst ? Unter Linux ist so ziemlich alles anders und man müsste jeden Klein umschreiben. Da wäre es vermutlich sogar einfacher in .Net zu programmieren und sich dann die Klassen, die man braucht, noch einmal unter Linux neu zu programmieren (was man aber dank Mono größtenteils nicht braucht)...

Original geschrieben von chibisuke

Dann is bei .NET das problem das es net überall läuft weil man n .NET framework braucht, und viele nutzer weigern sich das zu installiere...

Sicher? Ich sehe das eher anders. Wenn man es mit dem Programm mitliefert (z.B. auf CD) wird wohl kaum ein Nutzer damit Probleme haben. Einzig über das Internet gibt es Probleme, weil es doch relativ groß ist. Aber das wird auch Ende dieses Jahres Geschichte sein, weil dann sehr viele Leute auf Windows .Net haben werden und unter Linux wird es länger dauern aber auch kommen.

Original geschrieben von chibisuke

bei MFC braucht man die MFC runtimes, also sieht es ähnlich aus...

Die kann man auch statisch linken.

Original geschrieben von chibisuke

Tja.. bleibt das API.

Klar, damit man auch wirklich alle Portabilität verliert (es gibt da Teilweise schon Probleme zwischen den einzelnen Versionen von Windows!) und man sau viel Arbeit hat, weil man wirklich jeden von Hand machen muss.

MfG

Tobias
 
Original geschrieben von Sebastian Thalhammer
Hi.

Mir geht die Frage durch den Kopf, welcher dieser Teile die Zukunft gehört.
Zahlt es sich überhaupt noch aus reines WinAPI zu programmieren oder soll man gleich mit MFC anfangen. Wie steht es aber mit den .NET Sprachen.

P.S.: Kann man MFC eigentlich mit Win API kombinieren?

Hallo,

kommt darauf an für welche Plattform du hauptsächlich programmieren willst.
Sollte dies Windows sein, würde ich dir auf alle Fälle zu .net und C# raten, denn das ist nunmal die Zukunf von Windows.

Wenn du aber auch gerne unter Linux arbeiten willst solltest du evt. bei Java oder C++ etc. reinschnuppern. C# wäre allerdings auch eine Möglichkeit. Wie schon erwähnt gibts es das mono Projekt, welche das .net Framework für Linux umsetzt. Leider ist die Class Library noch nicht komplett, aber es ist schon recht funktionsfähig.
Solltest du dich für .net und C# entscheiden bist du (bei mir) im .net Forum herzlich willkommen. :)

Also .NET is neu, alles will .NET haben, und in ein paar jahren wird man drauf kommen wie blöd man eigendlich is wenn man .NET programmiert.
Vorallem will MS .net. Aber kannst du deine Aussage irgendwie begründen?


Mfg,
Alex
 
Tobiasm hat gesagt.:
Die Portabilität ist sehr wohl gegeben. Was ist denn mit Mono? Ganz nebenbei ist alles andere (also MFC + Win32-API) noch weniger Portabel. Wenn Du portibilität willst, nimm Java oder C++ mit QT.
das ist nicht DEIN ernst! Mono? ja mono schön und gut, wie sollen die aber die APIs von .NET nachbilden wenn nahezu alle elemente daran (z.B. DCOM) durch Patentrecht geschützt ist? Von daher, Portabilität nahezu NULL... Aber das Thema wunde in anderen Threads schon hundert mal durchgekaut, ich ich bins leid über Tatsachen zu diskutieren.
lol. Das ist nicht Dein Ernst, oder ? Jetzt sag mir mal, wie Du mit der Win32-API einen Port machen willst ? Unter Linux ist so ziemlich alles anders und man müsste jeden Klein umschreiben. Da wäre es vermutlich sogar einfacher in .Net zu programmieren und sich dann die Klassen, die man braucht, noch einmal unter Linux neu zu programmieren (was man aber dank Mono größtenteils nicht braucht)...
ich sagte nicht, das es ideal ist, ich sagte lediglich, das es DAS element von den 3en ist das noch am ehesten portablen ist... MFC kannst du vergessen, außer du willst die MFC klassen von hand schreiben, .NET, Mono... Da benutzt du mal die :google: funktion, dann findest du dazu sicher genug was hier gegen portabilität spricht.
Sicher? Ich sehe das eher anders. Wenn man es mit dem Programm mitliefert (z.B. auf CD) wird wohl kaum ein Nutzer damit Probleme haben. Einzig über das Internet gibt es Probleme, weil es doch relativ groß ist. Aber das wird auch Ende dieses Jahres Geschichte sein, weil dann sehr viele Leute auf Windows .Net haben werden und unter Linux wird es länger dauern aber auch kommen.
Ja, ich kenne viele nutzer die sich weigern, und zwar schon deshalb, wenn man den Datenverkehr von .NET Analysiert findet man ettliches was da nicht hinein gehöhrt,,,, änlichkeiten zu Mediaplayer 9 durchaus beabsichtigt, wenn man so will... aber das ist ja auch der Grund wiso diverse Spyware Scanner inzwischen meckern.
Die kann man auch statisch linken.
und eine datei die normal 200kB hatt auf 3MB aufblasen.
Klar, damit man auch wirklich alle Portabilität verliert (es gibt da Teilweise schon Probleme zwischen den einzelnen Versionen von Windows!) und man sau viel Arbeit hat, weil man wirklich jeden von Hand machen muss.
natürlich, aber immer noch besser als MFC oder .NET, und andere Alternativen waren ja nicht gefragt.
Vorallem will MS .net. Aber kannst du deine Aussage irgendwie begründen?
Das hab ich doch oder etwa nicht? Linux ist immer mehr im kommen, und Mono wird nie das .NET framework exakt nachbilden können wegen lizenzrechte. Und vor allem, Wenn es dir entgangen ist, viele Leute Pfeifen inzwischen auf M$.

C# wäre allerdings auch eine Möglichkeit.
Wenn man davon absieht das C# eigendlich Microsofts implementation von Java ist... mit dem C/C++ syntax hatt es jedenfalls nicht mehr so viel gemein wie mit dem Java syntax. das einzige was noch an C++ erinnert ist die tatsache das man kein "extends" zum vererben benutzt sondern einen : ...Aber naja..
Ach und wo wir schon bei Java sind... Das ist das andere Extrem zu .NET ;-) zwar nahezu komplett Platformunabhängig, solange man kein JNI benutzt, aber naja...

Noch dazu kommt, das das WinAPI eine viel leichtere migration auf andere Sprachen erlaubt, was ja auch nicht ohne ist... z.B. hab ich vor einiger zeit Stunden damit verbracht eine Externe Assembler routine als Member einer klasse zu Linken! Nichts im vergleich zu der zeit die ich durch Assembler gespaar hab, aber immerhin.

So langsam bin ich das den Ewigen streit "Was ist besser" leid. Jeder hatt hier seinen Standpunkt, und jeder kann immer wieder Argumente hin und her schieben, also spaar euch eure Argumentationen. Jeder hatt seinen Standpunkt.

Trotzdem, gut wenn auch jemand die andere Seite der Geschichte ein wenig besser erwähnt, so kann sich Sebastian seine eigene Meinung dazu bilden, und nicht nur meine nachplappern.
 
Zuletzt bearbeitet:
Portabilität?!

Ich behaupte mal einfach, das die Zukunft nicht .Net gehören wird.
Auf Windows kann/wird .Net Zukunft sein, aber auch nur weil M$ es so will.
Aber die haben uns ja noch nie gefragt was wir wolllen, oder?
Ich gehöre zu denjenigen, die sich weigern .Net zu installieren.
Warum:
- Groß
- Überladen
- Unnötig

Zum Thema Plattformunabhängig:
Viele Leute sind zu engstirning, sie blicken nicht weiträumig.
Bei Plattformunabhängikeit spreche ich nicht nur von Windows und Linux, denn es gibt noch zig andere Betriebssysteme, die durchaus ihre Daseinsberechtigung haben.
Und im Bereich professioneller Plattformunabhängiger Anwendungen wird .Net keine Rolle Spiele. Auch Java ist glaube ich keine große Alternative. (Chris bitte verzeih mir :) ).
Ok ich kann über Java nicht groß Urteilen, aber ich kann auch Gründe nennen, die dagegen Sprechen:
- benötigt JRE
- Performance
- kein echten Binaries (oder täusch ich mich da) in bezug auf Closed Source

Zum Thema Mono
Also beim kurzen Überfliegen des Mono-Projektes sind mir 2 große Nachteile aufgefallen.
- Nicht Plattformunabhängig bezieht sich nur auf Linux (ok evtl. lässt es sich auf anderen UNIX-Systemen übersetzten
- Absolut unvollständig und das wird es evtl. auch immer bleiben, siehe Aussage von chibisuke

Also bedeutet der Weg .Net über Mono doch auch nur eine Sackgasse, oder?
Ich für meinen Teil muss beruflich Anwendungen (mit GUI) entwickeln, die auf folgenen Betriebssystemen Lauffähig sind:
Windows
Linux
SunOS
HP-UX
Irix
AIX
und da hat .Net keine Chance.
Denkt mal darüber nach.

Gruß Homer
 
Zurück