MFC -> tod
-
Uuups, da bin ich doch auch ein bisschen vom ursprünglichen Thema abgekommen.
Das führt mich zu der Frage, was denn wirklich passiert, wenn die MFC stirbt (sprich nicht mehr supported wird). Da sie ja nur die WinApi kapselt und alle DLLs eh beim Visual Studio dabei sind dürfte es doch gar keine Rolle spielen, wenn ich halt partout dmmit weiterentwickeln will.
-
Warum ist QT denn dafür nicht in Ordnung? Da gibt es doch auch einen grafischen Editor für die GUI, damit es fix geht.
-
Longhorn basiert NICHT auf Win32 soweit ich weiss
dementsprechend wird es so sein das die platform zwar das laufen von win 32 systemen noch unterstuetzt - aber win32 wird spaetestens im OS nachher tot sein.Net ist das neue Framework - bzw .Net 2
du wirst also auf longhorn die alten win32 programme noch laufen lassen koennen
aber das wird sicher so sein das die Win32 Kompatiblitaet auf das .Net Framework zugreift. Also hast du wieder Overhead
na ja - bin ja gespannt wieviel von dem ganzen stimmt und wie sich der SQL Server im kernel benimmt
-
.Net 2 ??
-
ComeronPo schrieb:
.Net 2 ??
Die naechste Version von dotNET
Die hat dann eine Menge mehr am Kasten als dotNET 1.1 (das aktuelle)
Man muss .NET 1 also eine Art Beta-Version sehen, um die Leute langsam an .NET zu gewoehnen und noch die eine oder andere Aenderung fuer .NET 2 zu erkennen. Denn .NET 1.1 hat eigentlich keine Daseinsberechtigung - denn es bietet nichts, wofuer es nicht schon etablierte Technologien gibt. Aber wenn .NET 2 dann in Longhorn integriert ist, ist .NET auf einmal sehr wichtig.
-
Marc++us schrieb:
Zu C++ ist das noch nicht zu 100% raus, da MS lustigerweise den C++-Standard inzwischen mit dem VC7.1 besser abdeckt als jemals zuvor (und besser als jemand jemals erwartet hätte). Würden sie das tun, wenn sie C++ unter Windows eliminieren wollten?
vielleicht wollten sie ein paar leute in ihr lager hollen und haben sie mit iso98 gelockt oder sie hatten das die ganze zeit in der schublade und bevor sie es wegschmeissen wollen sie noch etwas geld machen
Marc++us schrieb:
Zur Zeit würde ich eine Oberfläche (nachdem Borland auch den Builder in den Ruhestand schicken wird) mit C# und .NET machen, wenn es für Windows sein soll.
meinst du in iso-c++ das backend und in c# die gui, beides verbunden durch COM? wird dadurch die gui nicht etwas zäher?
-
Warum soll QT (womit ich in der obengenannten Auswahl am meisten zu tun hab) nur unwesentlich besser sein als die MFC?
Ich finde die MFC um einiges umständlicher, und in QT kann ich einfach auch ohne Designer gute Oberflächen erstellen.
-
Selbes gillt imho auch für Gtkmm.
Da brauche ich keinen Meta-Compiler und kann auch den
Kompfort eines GUI-Designers genießen.
-
Ich denke, dass Marc++us absolut Recht hat. Möglichst wenig Aufwand in die GUI. Den geistigen Input in das Innenleben der Programme stecken. Beim Anwender spielt auch dort die Musik. Filme in Farbe sind oft schlechter als die alten Schwarzweiß-Schinken. Bei King Kong ist der erste Film immer noch der Beste.
-
Hallo!
(
C# ist in meinen Augen auch nur eine Kreuzung aus Delphi und C++ nach MS Vorstellungen.)
Das ist alles so ungewiss. Und deswegen habe ich jetzt auch angefangen WinAPI zu lernen. Da ist man unabhängig. Auch vom Compiler. Das ist in IMHO ein größes Problem der neuen "Sprachen". Delphi, C#, BASIC sind alle komerziell. C und C++ sind nicht aus kommerziellen Gründen entstanden. Das war eine ihrer Stärken.MFG, the flyingCoder.
-
flyingCoder schrieb:
(
C# ist in meinen Augen auch nur eine Kreuzung aus Delphi und C++ nach MS Vorstellungen.)C# ist ein Java-Clone mit einer stark verbesserten VCL als GUI.
Das ist alles so ungewiss.
Nein, nicht alles.
dotNET wird unter Windows der Standard fuer GUI Anwendungen werden, es sei denn Java liefert bis zum Longhorn-Release noch eine Sensation ab.Und deswegen habe ich jetzt auch angefangen WinAPI zu lernen.
WinAPI wird aber sterben, das ist gewiss.
Da ist man unabhängig.
Nein, warum? Mit der WinAPI bist du zwar Sprachunabhaengig, aber dafuer stark Plattform abhaengig.
-
Warum wird die WinAPI sterben? Auf ihr baut doch alles auf!?
Ich habe mir C# nicht tiefgehender angeguckt. Deswegen frage ich: Ist es nicht so, dass C# dem C Grundsatz, die Sprache möglichst klein zu halten, widerspricht?mfg ...
-
flyingCoder schrieb:
Warum wird die WinAPI sterben? Auf ihr baut doch alles auf!?
MS gibt in Win64 einfach die nativen WinAPI-Schnittstellen für die ganzen neuen Funktionen einfach nicht mehr bekannt. Dann kannst Du zwar noch Win32-Progs erstellen, aber nicht mehr die Features von Win64 nutzen. Und damit kannst Du keine aktuellen Programme erstellen => finish.
flyingCoder schrieb:
Ist es nicht so, dass C# dem C Grundsatz, die Sprache möglichst klein zu halten, widerspricht?
Zwei Dinge:
-
C-Grundsätze gelten nicht für C#, da dies eine andere Sprache ist.
-
Die Sprache C# ist relativ knapp gehalten, besitzt halt viele OO-Features und Schlüsselwörter dafür, aber eigentlich nur das was man dafür braucht. So schlank wie C ist sie nicht, aber das geht ja auch gar nicht.
-
-
Kane schrieb:
Selbes gillt imho auch für Gtkmm.
Da brauche ich keinen Meta-Compiler und kann auch den
Kompfort eines GUI-Designers genießen.Full Ack; Glade(mm)+GTK(mm) ist eine sehr elegante Möglichkeit auch komplexe GUIs zu erstellen.
-
Bis zum Longhorn release lohnt es sich auf alle Fälle noch die Winapi anzuschauen,
da es bis dorthin noch ein Weilchen dauert und dann dauert es nochmal eine lange
Zeit bis man wirklich auf NET2 umstellen kann ohne WinXp,Win2k,... auszusperren.
Von daher mach ich mir da wenig Sorgen, bis in 3Jahren kann ich noch fleißig mit
der Winapi arbeiten und dann schau ich mir vllt. mal NET2 an wenn ich auf
Longhorn aufrüsten sollte, bis jetzt hört sich das ja noch gut an, wenn MS da
nicht wieder Müll wie bei XP einbaut, nen OS das ohne Anfrage ins Inet geht und
ne Firewall eingebaut hat, erweckt auf mich kein Vertrauen, ich will die gesamte
Kontrolle über den Netzverkehr haben um mich sicher zu fühlen.
-
"MS gibt in Win64 einfach die nativen WinAPI-Schnittstellen für die ganzen neuen Funktionen einfach nicht mehr bekannt."
Das kommt alles irgendwie raus. Dann blüht Win64API richtig auf.
-
... lustig - wenn nur noch in C# oder VB.NET programmiert wird kann man ja den Quellcode dem Programmen gleich mit beilegen, naja wers mag
Alle kommerziellen Produkte werden auch weiterhin in C++ programmiert werden, oder glaubt Ihr wirklich die wollen sich so leicht in Ihren Code schaun lassen ?
-
maty schrieb:
... lustig - wenn nur noch in C# oder VB.NET programmiert wird kann man ja den Quellcode dem Programmen gleich mit beilegen, naja wers mag
Wie soll man von C# Programmen den Source anschauen können?
-
Weil man den MSIL disassemblieren kann, da der MSIL-Code eine 1:1 Übersetzung des Quellcodes ist, kann man damit den Sourcecode erhalten (allerdings ohne Kommentare und so Zeugs), fast im Original. Kein Vergleich zu C oder C++, wo dies nahezu unmöglich ist.
Extrembeispiel: es gibt die Möglichkeit, ein mit VB.net nach MSIL übersetztes Programm revers nach C# zu übersetzen!
Das Problem ist aber uralt, da Java seit Jahren damit kämpft - es gibt für Java sogenannte "Obfuscatoren", das sind Programme, die den VM-Code so verzwirbeln, daß man den logischen Ablauf nicht mehr so gut erkennen kann. Und demnach war die Lösung für C# einfach, es gibt auch schon Produkte dafür, z.B. den "Dotnetobfuscator".
@maty: und da es seit Jahren kommerzielle Java-Programme auf dem Markt gibt, scheint dies ja kein wirkliches Hindernis zu sein, oder? Selbst SAP bringt Java-Programme raus... und die wollen sich wirklich nicht in den Quellcode schauen lassen. Dein Argument ist von geringer praktischer Relevanz.
-
Wie wärs wenn man das Problem in zwei Programme aufteilt?
Ich hab mein GUI-Prog (vielleicht in einer extra GUI-Scriptsprache geschrieben)
das über ein Interface (Pipes?) mit einem C++/C/Java/WasAuchImmer-Hintergrundprozess kommuniziert.
Ichh kann dann auch einfach auf eine anderes GUI-Interface wechseln oder
irgendwas zu recompilen.