.net-Strategie von Microsoft (?)

[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