MFC -> tod



  • 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.



  • Das klingt ziemlich clever. 👍



  • Redest du von XAML?



  • ja Marc++us, mag ja sein aber es sind doch bestimmt mindestens 90 % der kommerziellen Anwendungen , wie Spiele, Betriebsysteme, Office-sachen , und alle andere PC Software in C++ geschrieben.
    Ich glaub also schon das mein Argument von praktischer Relevanz ist. C# ist ja schon mindestens ein Jahr, glaub ich auf dem Markt aber das neue MS Office z.b. ist immer noch in C++ geschrieben, ist das nicht seltsam 😕 ?





  • maty schrieb:

    C# ist ja schon mindestens ein Jahr, glaub ich auf dem Markt aber das neue MS Office z.b. ist immer noch in C++ geschrieben, ist das nicht seltsam 😕 ?

    Natuerlich ist Office in C++ geschreiben. Denkst du die entwickeln jetzt einfach Office neu, nur weil es .NET gibt?

    Aber ich denke, dass das Office welches mit Longhorn released wird, sehrwohl eine .NET Anwendung ist. Vermutlich zwar managed C++ anstatt C# (denn C++ nach managed C++ ist angeblich recht leicht portierbar) - aber .NET bleibt .NET

    ABer vergiss bitte nicht, dass .NET erst mit Longhorn wirklich wichtig wird. Momentan ist es eine Art Testphase um die Leute an .NET zu gewoehnen.



  • Toll, heißt das jetzt, dass ich meinen teuer-ersparten Petzold gleich aus dem Fenster werfen darf?



  • vieleicht ist MS Office ein schlechtes Beispiel. Es geht mir einfach nur um die Code-Sicherheit (MSIL disassemblierung). Deshalb werde ich und bestimmt viele andere weiterhin c++ verwenden. Im Serverbereich proge ich aber sehr gern mit c# und asp.net - nur eben im Kommerzielen Bereich ists mir noch nicht sicher genug.



  • Ist der Unterschied zwischen Win32-API und Win64-API wirklich so groß?
    Gibt es überhaubt Einen?
    😕 😕 😕

    ´Mfg`, the ``flyingCoder´´



  • Win64 ist glaub ich schneller ...



  • Ja, aber ändert sich was an der Art und Weise, wie man die Programme zu schreiben hat?



  • Was soll das sein?
    Die M$-Version von XML die bald mal wieder zum Standard erhoben wird?



  • Kane schrieb:

    Was soll das sein?
    Die M$-Version von XML die bald mal wieder zum Standard erhoben wird?

    Meinst du XAML?

    Das ist eine Beschreibung der GUI in XML

    <button click="button1_click">Klick mich</button>
    

    Wuerde einen Button definieren, der die Funktion button1_click() aufruft, wenn er gelickt wird.

    Das Prinzip ansich schaut sehr gut aus - warten wir die Umsetzung ab.



  • Kane schrieb:

    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.

    Hört sich sehr interessant an. Die GUI mit dem Windows Forms Designer in C# machen, und dann irgendwie mit nem C++ Programm "verbinden".
    Hast du da etwas näheres zu bieten? Links, Artikel, ...



  • das ist doch schon sehr populär. Schau dir einfach mal die verschiedenen IPC/RPC Techniken an, wenn du so etwas machen willst.

    Gibt es überhaubt Einen?

    die Win64 API ist auf 64Bit ausgelegt 🙄



  • Hab dabei nur an die vielen Linuxprogs gedacht, für die
    erst später ein Frontend entwickelt wurde. k.A. ob die das da über
    Pipes machen.



  • Was soll Win64 sein? Redet ihr von WinFX?



  • Das ist die Zukunft ... ! 😃



  • Kane: Schau Dir doch mal die Architektur von licq an! (Für das GUI werden einfach Plugins verwendet und es gibt eine licq_fifo zur Steuerung von licq.)



  • Marc++us schrieb:

    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.

    naja, das sehe ich anders. Microsoft hat nicht zuletzt zu Linux den großen Vorsprung weil es ein großes Softwareangebot gibt. Viele Entwickler nutzen die nativen Schnittstellen. Insbesondere die Entwickler von hardwarenahen Anwendungen wie Steurungen und in der Mess- und Regeltechnik. Meiner Meinung nach ist gerade das große Softwareangebot der entscheidene Vorteil von Windnows, ohne dem Windows entscheidend an Marktanteilen verlieren wird.

    Ich glaube nicht, dass MS das Risiko eingeht, von Linux überrollt zu werden.

    Davon mal abgesehen. Stellt sich sowieso die Frage, was der Sinn der ganzen Geschichte ist.
    Reflektieren wir mal:

    Man will Plattformunabhängigkeit. Das geht aber aufgrund der unterschiedlichen Struktur der Plattformen von Linux MS Solaris und co nicht. Was macht man also - man erzeugt eine eigenständige Plattform auf der aktuellen Plattform. Für jede Plattform schreibt man also eine Plattform, die auf diese Plattform läuft. Hat da schon mal jemand drüber nachgedacht was für ein Quatsch das eigentlich ist ? Der richtige Ansatz wäre doch alle Plattformen zu eliminieren und nur EINE grundlegende Struktur für Plattformen schaffen, worauf man ansetzt. Dann kann man sich dieses, aus kommerziellen Gründen entstandene, sinnlose Gehampel von Java und .net sparen und wäre zudem noch wesentlich performanter.

    Naja, Geld regiert die Welt....


Anmelden zum Antworten