.net-Strategie von Microsoft (?)

[bodenheim]

Hallo,
als Hobby-Programmierer lese ich immer von der .net-Strategie von Microsoft.
Wer kann mir einmal erklären, was damit gemeint ist ?

Warum ist es besser ein .net-Programm zu entwickeln, anstatt ein Win32-Programm?

Soviel ich weiss läuft doch das net-Framework auch vor allem auf Windows-PCs..

[s-off]

Zitat:

Zitat von bodenheim

Soviel ich weiss läuft doch das net-Framework auch vor allem auf Windows-PCs..

Genau, wobei die Betonung auf 'auch' liegt.

Mit 'Mono' bspw. läuft ein unter Win kompiliertes Projekt dann auch unter Linux, MacOS usw.

[bodenheim]

[quote="s-off"]

Zitat:

Zitat von bodenheim

Mit 'Mono' bspw. läuft ein unter Win kompiliertes Projekt dann auch unter Linux, MacOS usw.

Also geht es bei der Strategie um Plattformunabhängigkeit, und eine Konkurrenz zu Java..

[Namenloser]

Hallo.
Ich glaub eher, es geht darum, Mitbewerber für IDEs auszugrenzen. Z.B. Borland: Das -NET-Framework wird so schnellw eiterentwickelt, dass Borland nicht hinterherkommt. Bei Mono werden sie wohl auf das gleiche spekulieren. Wenn es etwas gibt, was Microsoft unbedingt vermeiden will, dann dürfte das wohl Plattformunabhängigkeit (außer natürlich bei Sachen wie Pocket PC, die ja wiederum mit Windows betrieben werden) sein :angel2: ... meine Meinung...

edit: Plattformunabhängigkeit ist in diesem fall wohl eher eine unpassende Bezeichnung. Hardwaremäßige Plattformunabhängigkeit dürfte auch im Interesse von M$ sein. Plattformunabhängigkeit auf Betriebssystemebene aber nicht. Letzteres meinte ich.

[mkinzler]

Microsoft setzt doch auf Plattformunabhängigkeit. Sie meinen damit allerdings ARM (Windows mobile), x86 ( Windows xxx)

[Bernhard Geyer]

Zitat:

Zitat von mkinzler

Microsoft setzt doch auf Plattformunabhängigkeit. Sie meinen damit allerdings ARM (Windows mobile), x86 ( Windows xxx)

Sehe ich genauso.

Und MS hat auch mal wieder eine aktuelle Klassenbibliothek benötigt. Mit MFC/ATL gewinnt man bezüglich Produktivität keinen Blumentopf und wenn schon was neues dann was komplettes (Und das ist .NET als Managed Plattform nunmal).

[s-off]

Microsoft selber hat ein Projekt namens 'Rotor' am laufen, welches wohl auch für MacOS gedacht ist.

[bodenheim]

Verstehe es auch nicht so ganz..
z.b. kenne ich Programme, welche für .net entwickelt wurden, aber als Systemanforderung Windows nennen.
Warum dann .net, warum nicht Win32? Läuft doch auch schneller.
Frage ich mich halt so als Hobby-Entwickler, für meine Programme..

[Bernhard Geyer]

Zitat:

Zitat von bodenheim

z.b. kenne ich Programme, welche für .net entwickelt wurden, aber als Systemanforderung Windows nennen.

Wenn es entsprechend nur auf Windows getested wurde bzw. Komponenten verwendet die es nur unter Windows gibt (MS SQL Express/SQL Everywhere)

Zitat:

Zitat von bodenheim

Läuft doch auch schneller.

Falsch! .NET Programme sind teilweise schneller als Delphi-Progamme. Kinderkrankheiten von Java darf man nicht einfach auf .NET umsetzen.
.NET ist kein Interpreter-System!

[Namenloser]

Zitat:

Zitat von Bernhard Geyer

Kinderkrankheiten von Java darf man nicht einfach auf .NET umsetzen.
.NET ist kein Interpreter-System!

Java auch nicht. Trotzdem ist es langsamer.

[JasonDX]

Zitat:

Zitat von bodenheim

Warum dann .net, warum nicht Win32?

Plattformunabhängigkeit ist ein Faktor. Produktivität ein anderer. Unter keiner (kaum einer) nativen Sprache konnte man Klassen und ganze Bibliotheken einfach so verwenden, und dabei eine so große Klassenbibliothek als gegeben voraussetzen. Es ist Programmiertechnisch ein Fortschritt, genauso wie es ein Konkurrent zu Java sein soll.
Und was die Plattformunabhängigkeit betrifft, so gibts hier 2 unterschiedliche Seiten zu betrachten.
Einmal die Hardware-Seite: Dadurch, dass man Bytecode, und kein endgültiges Kompilat hat, sind immer Optimierungen auf die Zielplattform möglich. (Multi-CPU, Speicher vs. Geschwindigkeits-Auslastung, 32 vs. 64Bit). In der Hinsicht also hauptsächlich für alle von Vorteil.
Von der BS-Seite betrachtet ist auch hier eine gewisse Unabhängigkeit von Vorteil, wenn sie sich durchsetzt - auch für Microsoft. Man nutzt ihr Technologie, und unterstützt damit mehere Plattformen. Sie verkaufen einen geringen Prozentsatz an Versionen von Windows weniger, aber ich möcht gern wissen, wieviele Leute andere MS-Programme auf anderen Systemen gern nutzen (=kaufen) würden. Office:mac lässt dies nur erahnen ;)

greetz
Mike

[Khabarakh]

Zitat:

Zitat von bodenheim

Also geht es bei der Strategie um Plattformunabhängigkeit, [...]

Dann würde Microsoft Mono doch wohl selbst entwickeln ;) . Mit dem zweiten Punkt hast du allerdings genau ins Schwarze getroffen: Java und .Net sind die zwei großen Managed Code Runtimes.
Natürlich wird man immer Kritikpunkte gegen eines der zwei Frameworks finden, aber ganz allgemein sollte eigentlich jeder Entwickler zustimmen: Wenn es nicht um höchste Performance geht, ist managed Code gegenüber unmanaged Code im Vorteil. Dieses Gebiet wollte Microsoft Sun natürlich nicht kampflos überlassen.

Zitat:

Zitat von NamenLozer

Ich glaub eher, es geht darum, Mitbewerber für IDEs auszugrenzen.

W..t..f?
Abgesehen davon, dass es keinen .Net-IDE-Markt gibt oder je gab (frag einmal die .Net-3.5-Entwickler, ob sie schon einmal was von RAD Studio gehört haben, das Ergebnis würde mich interessieren. Und Sharp/MonoDevelop wird (leider) auch nie eine ernsthafte Konkurrenz sein), was soll das für eine Logik sein? "Wir gründen eine neue Plattform, um dort alle anderen zu verdrängen"?
Es gibt nur zwei Gründe, warum die Entwicklung so schnell vonstatten geht, dass sogar manche Entwickler nicht mehr hinterherkommen: .Net ist jung und Microsoft kann es sich leisten. Und ich freue mich drüber.

Zitat:

Zitat von NamenLozer

Wenn es etwas gibt, was Microsoft unbedingt vermeiden will, dann dürfte das wohl Plattformunabhängigkeit (außer natürlich bei Sachen wie Pocket PC, die ja wiederum mit Windows betrieben werden) sein :angel2:

Wohl nicht komplett, warum würden sie sonst Mono unterstützen ;) ? Und mit Silverlight 2.0 wird bald sogar höchst offiziell ein .Net-Subset auf MacOS und Handys laufen.

[edit]Das wären dann 7 unsichtbare rote Kästen. Jo :gruebel: . [/edit]

[Bernhard Geyer]

Zitat:

Zitat von NamenLozer

Java auch nicht. Trotzdem ist es langsamer.

Komisch? Ich kenn ein paar Java-Anwendungen bei denen ich keine native-Anwendung kenne die genauso schnell ist. Liegt wohl eher an den Programmen die du kennst die inperformant entwickelt wurden.

Zitat:

Zitat von JasonDX

[Einmal die Hardware-Seite: Dadurch, dass man Bytecode, und kein endgültiges Kompilat hat, sind immer Optimierungen auf die Zielplattform möglich. (Multi-CPU, Speicher vs. Geschwindigkeits-Auslastung, 32 vs. 64Bit). In der Hinsicht also hauptsächlich für alle von Vorteil.

Theoretisch stimmt das, aber AFAIK hat in diesem Bereich MS noch nichts implementiert.

[Reinhard Kern]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von bodenheim

Läuft doch auch schneller.

Falsch! .NET Programme sind teilweise schneller als Delphi-Progamme. Kinderkrankheiten von Java darf man nicht einfach auf .NET umsetzen.
.NET ist kein Interpreter-System!

Falsch ist es sicher nicht - wie immer das technisch begründet ist, ich kenne verschiedene Software, z.B. eine bekannte einfache Buchhaltung, die nach Umstellung auf .NET etwa die 20fache Zeit zum Start benötigt. Die Software ist funktionell mit der vorherigen Version ansonsten so gut wie identisch, schliesslich kann man in eine Buchhaltung nicht beliebig Features einbauen.

In allen Fällen, in denen es vergleichbare Lösungen in Win32 und .NET gibt, z.B. wegen einer Umstellung, ist .NET um mindestens den Faktor 10 langsamer.

Gruss Reinhard

[Bernhard Geyer]

Zitat:

Zitat von Reinhard Kern

Falsch ist es sicher nicht - wie immer das technisch begründet ist, ich kenne verschiedene Software, z.B. eine bekannte einfache Buchhaltung, die nach Umstellung auf .NET etwa die 20fache Zeit zum Start benötigt. Die Software ist funktionell mit der vorherigen Version ansonsten so gut wie identisch, schliesslich kann man in eine Buchhaltung nicht beliebig Features einbauen.

In allen Fällen, in denen es vergleichbare Lösungen in Win32 und .NET gibt, z.B. wegen einer Umstellung, ist .NET um mindestens den Faktor 10 langsamer.

Dann haben die Verantwortlichen einen der Grundfehler der SW-Entwicklung gemacht: Die Umstellung eines System auf eine andere Plattform bei der gleichen Architektur nur um der Umstellung willen läuft eigentlich immer schief.

Wir selbst lösen gerade eine .NET-Anwendung ab (mit einer Delphi-Win32 und Java-Lösung) welche erst in den letzten Jahren von einer alten Win32-Lösung "1:1" auf eine .NET-Lösung portiert wurde. Die .NET-Lösung hatte den Charm einer Win3.1-Anwendung und war dementsprechend schlecht bedienbar da die veraltete Bedienphilosophie ebenfalls übernommen wurde.

[s-off]

Zitat:

Zitat von Reinhard Kern

In allen Fällen, in denen es vergleichbare Lösungen in Win32 und .NET gibt, z.B. wegen einer Umstellung, ist .NET um mindestens den Faktor 10 langsamer.

Wobei ich mir gut vorstellen kann, dass bei einer Umstellung nicht unbedingt in den Maßen auf Performanceoptimierung geachtet wird wie es bei einer Neuentwicklung der Fall wäre.

[OregonGhost]

Zitat:

Zitat von Reinhard Kern

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von bodenheim

Läuft doch auch schneller.

Falsch! .NET Programme sind teilweise schneller als Delphi-Progamme. Kinderkrankheiten von Java darf man nicht einfach auf .NET umsetzen.
.NET ist kein Interpreter-System!

Falsch ist es sicher nicht - wie immer das technisch begründet ist, ich kenne verschiedene Software, z.B. eine bekannte einfache Buchhaltung, die nach Umstellung auf .NET etwa die 20fache Zeit zum Start benötigt. Die Software ist funktionell mit der vorherigen Version ansonsten so gut wie identisch, schliesslich kann man in eine Buchhaltung nicht beliebig Features einbauen.

In allen Fällen, in denen es vergleichbare Lösungen in Win32 und .NET gibt, z.B. wegen einer Umstellung, ist .NET um mindestens den Faktor 10 langsamer.

Gruss Reinhard

Ich kann dir ohne weiteres ein Win32-Programm schreiben, das langsamer ist als jedes .NET-Programm. Und nun? Wenn die Software um den Faktor 10 langsamer ist, dann ist sie schlecht programmiert. Die einzige Schwäche von .NET ist die Kaltstartzeit. Sobald man die hinter sich hat, kann man damit Code schreiben, der genauso schnell ist oder sogar schneller läuft (z.B. konstruiere und zerstöre mal 100.000 Objekte in schneller Folge - du wirst überrascht sein, wie langsam hier C++ und Delphi sind und wie schnell .NET und Java sind). Tut mir leid, aber diese ewigen Verallgemeinerungen, weil irgendjemand mal irgendwo was gesehen oder gesagt hat, werden langsam langweilig. John Carmack hat auch mal gesagt, dass Direct3D die schlechteste und langsamste 3D-API ist, die es gibt... und wieviele Spiele werden jetzt nochmal in Direct3D entwickelt? Hoppla.
Ich weiß, dass es immer noch eine Menge Leute gibt, die diesen ulkigen "Tests" glauben, in denen Java und .NET um den Faktor 15 langsamer sind als nativer Code. Aber das stimmt einfach nicht. Natürlich kann man in C++ noch schneller sein. Aber dafür sitzt man dann Wochen an der Optimierung, nur um hinterher 5% gewonnen zu haben. Supi. Und übrigens selbst gesehen. Und wenn ich mir so die Performance von z.B. der VCL und Qt angucke im Vergleich zu .NET, dann steht letzteres noch nicht einmal so schlecht da.

Also nochmal in Kurzfassung meinen beiden Vorrednern folgend: Wenn man sein Programm durch die Portierung nach .NET um den Faktor 10 langsamer macht, dann hat man das Programm den Paradigmen der alten Entwicklungsumgebung folgend umgesetzt und hat damit schlampig gearbeitet.

Weiter zum Thema: Warum sollte man ein Win32-Programm schreiben wollen, wenn man ein .NET-Programm schreiben kann?

[bodenheim]

Zitat:

Weiter zum Thema: Warum sollte man ein Win32-Programm schreiben wollen, wenn man ein .NET-Programm schreiben kann?

Weil viele das net Framework gar nicht installiert haben; schon gar nicht Mono.
eine Java RE hat aber jeder.

[OregonGhost]

Zitat:

Zitat von bodenheim

Weil viele das net Framework gar nicht installiert haben; schon gar nicht Mono.
eine Java RE hat aber jeder.

Falsch. Java muss man auch installieren. Jeder gekaufte PC mit XP SP2 hingegen hat .NET 2.0 vorinstalliert. Unter Vista kann man .NET 2.0 nicht mehr deinstallieren, ausgeliefert wird es mit 3.0. Man bekommt es davon abgesehen per Windows Update (als empfohlenes Update)

Mono unter z.B. Linux ist genauso trivial zu installieren wie eine JRE.

Aber das war bei meiner Frage gar nicht der Punkt. Der Punkt war, warum man sich mit Win32 herumärgern sollte, wenn man .NET benutzen kann, aus reiner Entwickler- und nicht aus Vertriebssicht.

[bodenheim]

Zitat:

Zitat von OregonGhost

Zitat:

Zitat von bodenheim

Weil viele das net Framework gar nicht installiert haben; schon gar nicht Mono.
eine Java RE hat aber jeder.

Falsch. Java muss man auch installieren. Jeder gekaufte PC mit XP SP2 hingegen hat .NET 2.0 vorinstalliert. Unter Vista kann man .NET 2.0 nicht mehr deinstallieren, ausgeliefert wird es mit 3.0. Man bekommt es davon abgesehen per Windows Update (als empfohlenes Update).
Mono unter z.B. Linux ist genauso trivial zu installieren wie eine JRE.

Dann hat Microsoft sein Monopol mal wieder gut genutzt, und es spricht nichts dagegen :mrgreen:
Thx.

[bluesbear]

[quote="OregonGhost"]

Zitat:

Zitat von bodenheim

Der Punkt war, warum man sich mit Win32 herumärgern sollte, wenn man .NET benutzen kann, aus reiner Entwickler- und nicht aus Vertriebssicht.

Kann man denn in .NET wirklich alles machen, was man mit Win32 kann? <blödfrag>

[mkinzler]

Zitat:

Aber das war bei meiner Frage gar nicht der Punkt. Der Punkt war, warum man sich mit Win32 herumärgern sollte, wenn man .NET benutzen kann, aus reiner Entwickler- und nicht aus Vertriebssicht.

-Vielleicht weil man nicht auf der grünen Wiese anfängt, sondern bereits viel fertigen Code hat, den man wiederverwenden will
-Kunden mit älteren OSen hat.
-Man in Delphi arbeitet
-Auf Fremsdoftware angewiesen ist, welche noch nicht .Net fähig ist.
...

Zitat:

Kann man denn in .NET wirklich alles machen, was man mit Win32 kann? <blödfrag>

Notfalls per INVOKE

[OregonGhost]

Zitat:

Zitat von mkinzler

Zitat:

Aber das war bei meiner Frage gar nicht der Punkt. Der Punkt war, warum man sich mit Win32 herumärgern sollte, wenn man .NET benutzen kann, aus reiner Entwickler- und nicht aus Vertriebssicht.

-Vielleicht weil man nicht auf der grünen Wiese anfängt, sondern bereits viel fertigen Code hat, den man wiederverwenden will
-Kunden mit älteren OSen hat.
-Man in Delphi arbeitet
-Auf Fremsdoftware angewiesen ist, welche noch nicht .Net fähig ist.

Ich stimme dir zu. Wir haben uns häufig für .NET entschieden, wenn entweder der Kunde dies wünscht (!), oder es nur unter Windows lauffähig ist (wegen nur unter Windows erhältlicher Komponenten, die es auch nicht so bald für Linux geben wird) und als Mindestanforderung Windows 2000 (.NET 2.0) oder Windows XP (.NET 3.5) hat. Dabei handelt es sich meist um Neuentwicklungen, und Delphi ist bei uns kein Thema aus verschiedenen Gründen, die nicht Thema dieses Threads sind. Wenn es bei uns fertigen Code gibt, der wiederverwendet werden will, ist der erstens in C++ geschrieben und/oder zweitens nur über COM zu erreichen. Das sind nicht die schlechtesten Voraussetzungen, um ihn in .NET einzubinden.

Zur Frage nach "was alles geht": Eigentlich ist das genauso wie wenn du mit Delphi programmierst. Das meiste geht pur mit der VCL - manches geht eben nicht, dann muss man die API direkt benutzen. Das ist unter .NET nicht anders.

[Jelly]

Zitat:

Zitat von OregonGhost

Der Punkt war, warum man sich mit Win32 herumärgern sollte, wenn man .NET benutzen kann, aus reiner Entwickler- und nicht aus Vertriebssicht.

Ich nutze hier bei der Arbeit ausschliesslich Visual Studio 2005, und somit .NET 2.0. Das Problem, das ich aber hier erkenne, ist dass ich eben nicht alleine entwickle, und wir jede Menge Software hier am Laufen haben. Und da sind einige alten Kamellen dabei, und somit benötigt unsere Software zur das Framework .NET 1.0, 1.1 und 2.0. Und wie es aussieht, wohl auch bald 3.0 und 3.5.

Für die Administration von 400 PCs in unserem Haus ist das ein Riesenaufwand, und nicht zu unterschätzen, dass die Hardwareanforderunge der Client PCs damit ziemlich anspruchsvoll sind. Denn wenn 3 Applikationen unter 3 unterschiedlichen Frameworks laufen, steigt der Speicherbedarf doch erheblich an.

Das finde ICH persönlich eine der grössten negativen Aspekte im .NET. Und wo steht Microsoft in 10 Jahren? Gibts da .NET noch. Krieg ich da meine Programme aus VS 2005 noch unter Visual Studio 2015 und dem .NET Framework 13.0 kompiliert? Ich bin da eher skeptisch. Unter Delphi weiss ich, dass das zumindest in der Vergangenheit geklappt hat (ich krieg heut noch meine alten Delphi 4 Projekte problemlos unter Delphi 2007 kompliliert... zumindest die, für die ich den Quellcode aller Komponenten habe).

Ich liebe Delphi. Und ich liebe auch .NET. .NET ist eine sehr mächtige Bibliothek, Delphi bietet eine wesentlich grössere VCL Palette. Alles Vor- und Nachteile, das perfekte System gibts in meinen Augen nicht. Das sollte man schon individuell nach seinen eigenen Bedürfnissen anpassen.

Nicht immer urteilen, sondern abwiegen. Zu behaupten, Win32 sei besser als .NET oder umgekehrt, ist in meinen Augen absoluter Quatsch. Man sagt ja auch nicht ein SUV fahren ist besser als ein Cabrio... Beides hat seinen Charme, je nach Anwendungsbedarf :zwinker:

[OregonGhost]

Zitat:

Zitat von Jelly

Nicht immer urteilen, sondern abwiegen. Zu behaupten, Win32 sei besser als .NET oder umgekehrt, ist in meinen Augen absoluter Quatsch. Man sagt ja auch nicht ein SUV fahren ist besser als ein Cabrio... Beides hat seinen Charme, je nach Anwendungsbedarf :zwinker:

Also ich fahr einen Golf.
:P

Meine Erfahrung mit der Abwärtskompatibilität in .NET ist, dass alles ab .NET 2.0 auch unter .NET 3.5 läuft, und vermutlich auch noch mit .NET 6 laufen wird. .NET 1.0 sollte man wegwerfen und wenigstens durch 1.1 ersetzen, und fast alle 1.1-Anwendungen laufen unter 2.0.
Bei Java hingegen werden alle zwei Major-Versionen die Hälfte aller Klassen umgeschrieben. Und bei Delphi, naja, ich hab laut dem, was ich hier im Forum lese, eher den Eindruck, dass es nicht so einfach ist, ältere Delphi-Projekte unter neueren Versionen zum Laufen zu kriegen. Was natürlich an den Komponenten liegen mag. Was ich dabei aber wichtig finde, ist, dass Delphi eng an Win32 gekettet ist, während man .NET-Anwendungen (wenn man tunlichst kein SWF2 oder WPF verwendet) problemlos unter Mono zum Laufen bekommt. Für Delphi braucht man da erstmal FreePascal und die zugehörige IDE ist ein deutlicher Sprung zurück.
Was die Größe der VCL-Palette angeht - ja, mitgeliefert werden bei Delphi mehr visuelle Komponenten. Aber ich habe regelmäßig den Eindruck, dass der Klassenbibliothek selbst eine Menge fehlt, was in der BCL von .NET dabei ist.

[QuickAndDirty]

Zitat:

Zitat von OregonGhost

Die einzige Schwäche von .NET ist die Kaltstartzeit. Sobald man die hinter sich hat, kann man damit Code schreiben, der genauso schnell ist oder sogar schneller läuft (z.B. konstruiere und zerstöre mal 100.000 Objekte in schneller Folge - du wirst überrascht sein, wie langsam hier C++ und Delphi sind und wie schnell .NET und Java sind).

Mit c++ mit einem Memory Manager der ne garbage collection integriert hat ist C++ sicherlich schneller.
Dein Argument hinkt sowas von. Denn das einzige was da in diesem konkreten Beispiel java und .Net besser können ist das sie erstmal nichts machen,
wenn du ein Objekt zerstörst oder den letzten Zeiger dahin nulltst. Es gibt diverse Garbage collections für c++ die das auch so machen können. Aber das Problem ist auch wenn ich z.b. mein Java Programm starte läuft die Garbage Collection erstmal gar nicht bis ich 30 MB voll gemüllt habe (der Wert ist einstellbar). Sogar System.gc führt zu nichts!!!
Das erzeugen und frei geben von Objecten ist also kein brauchbarer Geschwindigkeitsindicator.

Sortieren dagegen schon.

Zitat:

Zitat von OregonGhost

Tut mir leid, aber diese ewigen Verallgemeinerungen, weil irgendjemand mal irgendwo was gesehen oder gesagt hat,

bilden die Tatsachen hinreichend genau ab.

Zitat:

Zitat von OregonGhost

John Carmack hat auch mal gesagt, dass Direct3D die schlechteste und langsamste 3D-API ist, die es gibt... und wieviele Spiele werden jetzt nochmal in Direct3D entwickelt? Hoppla.

Video 2000 vs. VHS???

Zitat:

Zitat von OregonGhost

Ich weiß, dass es immer noch eine Menge Leute gibt, die diesen ulkigen "Tests"

zurecht

Zitat:

Zitat von OregonGhost

glauben, in denen Java und .NET um den Faktor 15 langsamer sind als nativer Code. Aber das stimmt einfach

Zitat:

Zitat von OregonGhost

Natürlich kann man in C++ noch schneller sein.

Zitat:

Zitat von OregonGhost

Aber dafür sitzt man dann Wochen an der Optimierung, nur um hinterher 5% gewonnen zu haben. Supi. Und übrigens selbst gesehen. Und wenn ich mir so die Performance von z.B. der VCL und Qt angucke im Vergleich zu .NET, dann steht letzteres noch nicht einmal so schlecht da.

Du sprichst hier von Bibliotheken, bitte das zu trennen. Du sagst ja selbst das du nichts auf Pptimierung gibst, naja das spricht irgendwie schon für sich.

Zitat:

Zitat von OregonGhost

Weiter zum Thema: Warum sollte man ein Win32-Programm schreiben wollen, wenn man ein .NET-Programm schreiben kann?

Weil dein Code in .net nicht mal nen Versionswechsel überlebt und sich die Paradigen von Dotnet mit jedem
Unterversionswechsel ändern können?

[Namenloser]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von NamenLozer

Java auch nicht. Trotzdem ist es langsamer.

Komisch? Ich kenn ein paar Java-Anwendungen bei denen ich keine native-Anwendung kenne die genauso schnell ist. Liegt wohl eher an den Programmen die du kennst die inperformant entwickelt wurden.

Wenn man mal logisch nachdenkt, ist es klar, dass eine native Anwendung immer schneller ist als eine halbinterpretierte - bei gleichem Code und auch sonst gleichen Voraussetzungen natürlich. Es sei denn, der Code wird vor der Ausführung von einem JIT-Compiler in nativen Code übersetzt, was für mich aber dann den Sinn von .net in Frage stellt... Schließlich kann ich das ganze auch mit z.B. Lazarus gleich für die entsprechende Ziel-Plattform compilieren.

Zitat:

Zitat von Khabarakh

Abgesehen davon, dass es keinen .Net-IDE-Markt gibt oder je gab (frag einmal die .Net-3.5-Entwickler, ob sie schon einmal was von RAD Studio gehört haben, das Ergebnis würde mich interessieren. Und Sharp/MonoDevelop wird (leider) auch nie eine ernsthafte Konkurrenz sein)

Genau das ist ja der Punkt. Wenn Microsoft tatsächlich die Win32-Unterstützung irgendwann einstellen oder einschränken sollte, kann man alle IDEs außer Visual Studio in die Tonne schmeißen.

[Bernhard Geyer]

Zitat:

Zitat von QuickAndDirty

Mit c++ mit einem Memory Manager der ne garbage collection integriert hat ist C++ sicherlich schneller.

Nö. Muß er nicht. In der c't wurde gezeigt das C++ AFAIK bei Vererbung und ähnlichen objektorientierten Techniken Delphi, C# und Java um welten langsamer war.

Zitat:

Zitat von QuickAndDirty

Das erzeugen und frei geben von Objecten ist also kein brauchbarer Geschwindigkeitsindicator.

Ist nur ein Aspekt. Wird in 95% Geschwindigkeitsvorteile bringen und in 5% der Fälle probleme Verursachen.

Zitat:

Zitat von OregonGhost

Natürlich kann man in C++ noch schneller sein.

Aber auch Langsamer. Ich würde sagen in 99% der Fälle ist ein vernünftige Implementierung (Algorithmus/Architektur) wichtiger als die verwendete Programmiersprache.

Zitat:

Zitat von QuickAndDirty

Weil dein Code in .net nicht mal nen Versionswechsel überlebt und sich die Paradigen von Dotnet mit jedem
Unterversionswechsel ändern können?

Ich denke auch .NET wird mit jeder Version stabiler werden und mit größerer Verbreitung muß selbst M$ auf verstärkter Codeschutz im Sinne von Sourceschutz achten.

Zitat:

Zitat von NamenLozer

Wenn man mal logisch nachdenkt, ist es klar, dass eine native Anwendung immer schneller ist als eine halbinterpretierte - bei gleichem Code und auch sonst gleichen Voraussetzungen natürlich. Es sei denn, der Code wird vor der Ausführung von einem JIT-Compiler in nativen Code übersetzt, was für mich aber dann den Sinn von .net in Frage stellt...

.NET und Java sind kein (halb)interpretierente Systeme. Der Code wird JIT-Compiliert und dann die compilierten Teile (bei .NET) entsprechend im System abgelegt. Dies stellt den Sinn von .NET überhaupt nicht in Frage da damit keinerlei Vorteile einer managed Plattform in Frage gestellt werden.

Zitat:

Zitat von NamenLozer

Schließlich kann ich das ganze auch mit z.B. Lazarus gleich für die entsprechende Ziel-Plattform compilieren.

Und entsprechend x Compilate bereitstellen gegenüber einem IL-Compilat.

[OregonGhost]

Zitat:

Zitat von QuickAndDirty

Mit c++ mit einem Memory Manager der ne garbage collection integriert hat ist C++ sicherlich schneller.
Dein Argument hinkt sowas von. Denn das einzige was da in diesem konkreten Beispiel java und .Net besser können ist das sie erstmal nichts machen,
wenn du ein Objekt zerstörst oder den letzten Zeiger dahin nulltst. Es gibt diverse Garbage collections für c++ die das auch so machen können. Aber das Problem ist auch wenn ich z.b. mein Java Programm starte läuft die Garbage Collection erstmal gar nicht bis ich 30 MB voll gemüllt habe (der Wert ist einstellbar). Sogar System.gc führt zu nichts!!!
Das erzeugen und frei geben von Objecten ist also kein brauchbarer Geschwindigkeitsindicator.

Da ein normales Programm, insbesondere ein .NET-Programm, in seinem Lebenszyklus ständig kleine Objekte erzeugt und wieder freigibt, doch. Und C++ mit Garbage Collector, das ist doch schon fast wieder wie .NET.

Zitat:

Zitat von QuickAndDirty

Sortieren dagegen schon.

Ja. Schonmal einen Sortieralgorithmus in .NET geschrieben? Nein? Nanu. Dabei gehört das doch zur Lieblingsbeschäftigung von Informatikern. Warum macht man es nicht?

Deine Zerpflückungen, in denen du irgendwelche Satzteile einfügst (bitte schreib lieber selbst ganze Sätze - oder ist bei dir QuickAndDirty überall Programm?), spare ich mir mal zu zitieren.

Zitat:

Zitat von QuickAndDirty

Video 2000 vs. VHS???

Wenn du denkst, dass sich das so verhält, dann hast du keine Ahnung, sry. Schonmal in Direct3D UND in OpenGL etwas programmiert? Ich schon. Also solche unqualifizierten Gleichstellungen bitte beiseite lassen.

Hast du selbst schonmal solche Vergleiche angestellt? Ich schon. Und sie sehen nicht gut aus für nativen Code, wenn sie von jemandem geschrieben werden, der sich in der jeweiligen Welt gut auskennt. Und deine Aussagen wie "Du sagst ja selbst das du nichts auf Pptimierung gibst, naja das spricht irgendwie schon für sich." kannst du dir bitte auch sparen. Denn du hast recht, ich optimiere nicht wochenlang, um dann 5% mehr Performance in einer Anwendung zu erreichen, die 99% ihrer Lebenszeit auf Eingaben vom Anwender wartet. Ich optimiere da, wo es notwendig ist. Nicht da, wo es nichts bringt.

Zitat:

Zitat von QuickAndDirty

Weil dein Code in .net nicht mal nen Versionswechsel überlebt und sich die Paradigen von Dotnet mit jedem Unterversionswechsel ändern können?

In .NET wechseln keine Paradigmen. Es kommen lediglich ein paar neue syntaktische Möglichkeiten dazu. Und mein Code in .NET überlebt problemlos jeden Versionswechsel. Du erwartest wirklich, dass die Firma, die Milliarden (!) investiert, damit irgendwelche Popelanwendungen von vor 10 Jahren noch problemlos auf aktuellen Systemen laufen, alles mit jeder neuen Version anders macht?

Jetzt habe ich wertvolle Minuten meines Lebens verschwendet, um auf einen völlig unqualifizierten Post zu antworten. Da wäre ein Paradigmenwechsel fällig. Bernhard Geyer hat viel besser geantwortet als ich. Naja, was soll's. Der Mann weiß wenigstens, was er sagt. Aber ich bitte dich, Bernhard, die Zitate, die nicht von mir stammen, auch nicht mit meinem Namen zu versehen ;)

[bluesbear]

Zitat:

Zitat von OregonGhost

Weiter zum Thema: Warum sollte man ein Win32-Programm schreiben wollen, wenn man ein .NET-Programm schreiben kann?

Eine Antwort darauf habe ich: Weil ich Win32 programmiere seit es das gibt - ich das also einigermaßen kann - und von .NET keine Ahnung habe. :stupid:
Eine Anwendung ist mit Win32 ist vielleicht nicht unbedingt schneller als mit .NET, aber ich! :mrgreen:
Glaube ich zumindest... :-D

[Chemiker]

Hallo,

hier sind ja die erfahrende .NET Programmierer. Deshalb mal einige Fragen,
wie ist die Zusammenarbeit zwischen .NET und Assembler. Gibt es Komponenten um eine serielle Schnittstelle anzusprechen? Wie kann man mit .NET eine SPS programmieren?

Bis bald Chemiker

[mkinzler]

Im Notfall kann man immer mit Hilfe von P/INVOKE, COM/INVOKE auf die native Ebene zugreifen.

[Dax]

Zitat:

Zitat von Chemiker

wie ist die Zusammenarbeit zwischen .NET und Assembler.

Wie meinst du das.. Sowas wie Inline-Assembly in Delphi? Das gibt es nicht. Du kannst zwar deinen Code auch als ILasm schreiben, was gewissermassen auch Assembler ist - nur eben für eine virtuelle Maschine statt für eine reale. "Echten" Assemblercode musst du aber per P/Invoke einbinden.

Zitat:

Zitat von Chemiker

Gibt es Komponenten um eine serielle Schnittstelle anzusprechen?

Seit 2.0 ist sogar eine im Framework enthalten ;)

Zitat:

Zitat von mkinzler

Im Notfall kann man immer mit Hilfe von P/INVOKE, COM/INVOKE auf die native Ebene zugreifen.

Die genannten Techniken sind hässlich und zum Zeil fehleranfällig ;) Aber sie können auch extrem nützlich sein - viele DB-Provider setzen auf P/Invoke, und der Win32-Teil des Frameworks ist ohne P/I nicht vorstellbar.

[Jelly]

Zitat:

Zitat von Chemiker

Wie kann man mit .NET eine SPS programmieren?

Das kann man sehr wohl. Ich hatte mal eine OPC Bibliothek, das ganze für .NET... Leider weiss ich nicht mehr wie die hiess, aber google mal nach OPC und .NET.

[Macci]

.NET ist eine Konkurrenz zu Java. Als Microsoft damals J++ herausbrachte, war das so beliebt, dass Sun Microsoft promt verklagte, weil die mit J++ entwickelten Java-Anwendungen zu windowsähnlich waren. Microsoft musste daraufhin ihr J++ mit sovielen Warnmeldungen spicken, dass es für die User unattraktiv wurde. Deswegen entschloss man sich bei MS dann eine eigene platformunabhängige Virtualisierungsumgebung zu erschaffen, und das Ergebnis davon ist .NET. Solche Anwendungen können dann z.B. mit Visual C# geschrieben werden. Was mir daran allerdings gar nicht gefällt ist, dass Pointer praktisch völlig fehlen. Deswegen bleibe ich bei Delphi und C++.

Viele Grüße,
Macci

[bluesbear]

Hallo Chemiker,
ich habe das Gefühl das ist irgendwie die falsche Frage. Wie soll ich das erklären? Ich versuche das mal konkred krass vereinfacht.
Also ganz am Anfang gab es Assembler. Damit sagt man dem Prozessor, was der tun soll. alle Ports usw. bekannt.
(Ich hatte mir damals eine Seagate Festplatte an meinen Atari ST gebaut. Ja, ich kann löten). Ok, das war OT.
Dann kam C, damit man nicht mehr mit Registern und Speicheradressen rummachen musste.
Dann kamen die Hochsprachen, manche davon objektorientiert, und ich lasse sowas wie LISP oder PROLOG mal bewußt außen vor.
Es wurde mit der Zeit immer abstrakter. Man hat sich lösen können von Prozessoren und Registern, das konnte man einem Compiler überlassen.
Die logische Fortsetzung davon ist, sich von Betriebssystemen zu abstrahieren.
Bytecodesysteme wie .NET schaffen das. Oder Java.
Nur bei .NET abstrahiert man sich nicht vom Hersteller des Betriebssystems <g>. Microsoft unterstützt Mono, habe ich in diesem Thread gelesen. Ja wie sehr haben die die Zügel in der Hand. <eg>
Das ist heute eine schwierige Zeit. Man kann schwer absehen, wo der Hase hin läuft. Java oder .NET?
Vom Konzept her ist das klar: Wenn es eine Entwicklungsumgebung und Programmiersprache geben sollte, mit der man Betriebssystemübergreifend brauchbare Programme schreiben kann - ich würde das benutzen. Da geht die Zukunft hin.
Wenn ich es könnte bzw. wüsste, oder genug Zeit für die Einarbeitung hätte. Habe ich nicht. Ich Schuster bleibe bei meinen Leisten, und tu das, was ich kann.
:mrgreen:

[mkinzler]

Zitat:

Was mir daran allerdings gar nicht gefällt ist, dass Pointer praktisch völlig fehlen

Braucht man auch nicht.

[jfheins]

Zitat:

Zitat von mkinzler

Zitat:

Was mir daran allerdings gar nicht gefällt ist, dass Pointer praktisch völlig fehlen

Braucht man auch nicht.

Wenn du unbedingt Spaß (no Risk no Fun ^^) haben willst, kannste ja alle Variablen als System.Object (oder so ... die Grundklasse von allem halt ^^) deklarieren ;)

Ansonsten ist ja eh alles Objekt, du wirst also nur selten in die Verlegenheit kommen "Ich nehm mal nen Pointer damit ich nicht mehr das ganze gedöns durch die Gegend schiebe" - und Call by Reference gibt es ja nach wie vor ;)

[phXql]

Das is schon sehr gut so dass diese Pointer fehlen.

Und man kann mit .NET problemlos Programme schreiben, die unter Windows und Linux laufen. Das neuste Mono unterstützt sogar zu 98% WinForms, d.h. man muss nichmal WxWidgets, GTK etc verwenden.

Grüße, phXql

[bluesbear]

Zitat:

Zitat von mkinzler

Zitat:

Was mir daran allerdings gar nicht gefällt ist, dass Pointer praktisch völlig fehlen

Braucht man auch nicht.

Pointer sind antike Nervzwerge aus der Assembler-Zeit. Man kann damit umgehen. Schöner wäre es, sich um sowas keinen Kopp machen zu müssen.