MFC -> tod
-
"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.
-
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.