.NET-Diskussion

[CalganX]

Hi,
wir hatten ja in einem anderen Thread über .NET diskutiert. Allerdings war das nicht ganz Ontopic. ;)

Deswegen würde ich sagen, machen wir hier weiter. :)
Ich selber habe Borlands C#-Builder und entwickle mit C++ und .NET. Ich muss sagen, dass es gar nicht so schlecht ist, wie alle sagen.
Den Vorteil, den Mathias (Simmack) angemerkt hatte, dass man auf Headerübersetzungen verzichten kann ist wirklich gut. Denn man kann z.B. mit Hilfe von VS.NET alte C++-Projekte oder Basic-Komponenten problemlos konvertieren.
Das war vor einigen Wochen ganz praktisch, denn das entsprechende Control gab es nur in Basic.NET. Ein Klick und ich konnte es unter C# verwenden.

Ich denke, dass die Einbindung von Delphi ins .NET-Framework nötig ist. Zwar wird - wie hier öfter angemerkt - die WinAPI in den Hintergrund rücken, aber dennoch kann ich mit Hilfe von C++.NET weiterhin auf WinAPI-Funktionen zugreifen. Ich selber sehe da keine großen Probleme.

Ich schaue erfreut auf die Zukunft von .NET auch, wenn dieser Anfang auch ein (vorerst) kleiner Abscheid ist. :|

Chris

[woki]

Hi,

warum soll man mit Delphi.Net nicht auf die WinApi zugreifen können? Die gesamte Portierung der VCL beruht doch darauf.

Grüsse
Woki

[neolithos]

Ich habe ja auch nichts gegen das Sprachkonzept! C# und wer weis was Delphi neues bringt ist schon aufregend genial!

Doch bin ich in die Versuchung gekommen selbst mal einkleines dotNET-Project in C# zu starten und dabei habe ich viele Funktionen der Win32 vermisst!

Entweder ich finde sie noch oder muss mich selbst daran machen sie zu implementieren! Was ich eigentlich nicht wollte, da solche rückgriffe auf die Win32-Api das Programm-Plattform abhängig machen.

Ich hoffe das Borland-FrameWork ist etwas besser als das derzeitig von MS.
Obwohl ich vermute, sobald MS beginnt ernsthaft dotNET-Anwendung zu entwickeln, wird es noch wachsen! (Ich hoffe mal)

Vermisst Funktionen:

-ListView32: Owner-Draw, Owner-Data
-ScrollWindow
-Caret's

---
Ist jemanden schon aufgefallen das man im VS.NET die Control's im Formular nur mit der Maus positionieren kann, nicht aber via Cursor-Tasten.

[CalganX]

Hi,
C# ist da etwas besonderes!
Aber du kannst alle DLLs laden und somit hast du automatisch alle API-Funktionen, nur halt importiert.

Chris

PS: @neo: ähm... das ist nicht ganz korrekt. Ich kann, wenn ich WinAPI-Anwendungen schreibe problemlos im Dialogeditor mit der Tastatur Controls verschiebe (einfach mit den Pfeiltasten). MFC weiß ich nicht => habe ich noch nie angerührt. *angewidert sei von mfc*

[MathiasSimmack]

Zitat:

Zitat von Chakotay1308

Aber du kannst alle DLLs laden und somit hast du automatisch alle API-Funktionen, nur halt importiert.

Ja, aber dann ist der oft genannte Vorteil von .NET wieder dahin. Wenn ich die grundlegenden Funktionen über .NET bekomme, spezielle Funktionen aber wieder über das API laden muss, dann stehe ich bspw. bei importierten XP-Funktionen vor dem Problem, dass mein Programm unter 2000 evtl. nicht läuft. Und wenn mit Longhorn wirklich der komplette Verzicht auf das API kommt, dann habe ich das nächste Problem, dass ich mein Programm erst mal wieder umschreiben muss, damit´s unter LH läuft.

In dem Fall könnte man mit einiger Berechtigung fragen: Wozu dann .NET?

[CalganX]

Hi Mathias,
okay. Natürlich hat (fast) jede Funktion der WinAPI ein .NET-Pendant und das angesprochene Problem exisitert. Daher frage ich mich warum man sich so aufregt? Wenn wir jetzt anfangen .NET mit Delphi zu Programmieren, dann gibt es doch kein großes Problem? Wir verwenden die Programmiersprache, die wir so gerne verwenden und sind dennoch mit Microsoft auf einer Linie und alle können unsere Programme verwenden.

Wenn wir jedoch weiterhin mit der WinAPI coden (was ja andererseits auch nicht verkehrt ist), dann haben wir das Problem, dass, wie du gesagt hast, kein Longhorn-User unsere Programme verwenden kann.

Ich werde auf jedenfall beides Coden. Denn so habe ich jederzeit die Möglichkeit mich auf eines festzulegen. Und was ist daran denn verkehrt?

Chris

[Christian Seehase]

Moin Zusammen,

also wenn ich mir mal so die Geschichte der Windows Versionen so ansehe, komme ich zu dem Schluss, dass es in absehbarer Zeit wohl kaum ein rein .NET basiertes Windows wird geben können.
Wenn ich mich nicht sehr irre, laufen sogar noch viele DOS Programme unter XP, zwar in einer Emulation, aber sie laufen.
Ausserdem spricht meiner Ansicht nach auch die Verfügbarkeit von Anwendungen dagegegen. Woher sollen den die 100%igen .NET Anwendungen so schnell kommen, die ihre Win32 Pendants ablösen? Klar, wenn sich alle auf die Entwicklung von .NET Anwendungen konzentrieren, wird man schnell eine ganze Menge zusammenbekommen, aber ich habe so meine Zweifel, dass das reichen wird, zumal gerade Unternehmen oft Spezialsoftware einsetzen, und Privatanwender wohl eher nicht so schnell Geld für neue Software auszugeben bereit/in der Lage sind/seien werden, nur um ein neues OS zu benutzen.

Da ich mal davon ausgehe, dass, u.a. aus den genannten Gründen, wohl zumindest eine Win32 Emulation erhalten bleiben wird, dürfte die Mischung, zumindest auf Jahre hinaus, kein grösseres Problem darstellen.

Was in diesem Zusammenhang immer mein Paradebeispiel ist, weil ich mich damit schon mal näher auseinandergesetzt habe ist die Registry.
Eigentlich sollte diese ja ursprünglich mal die INI Dateien ablösen, und das hat bis heute nicht vollständig geklappt. Stellt sich mir die Frage ob denn nun die Registry abgelöst werden soll. Immerhin bieten nicht einmal die MS Assemblys vollen Zugriff, zumindest nicht, wenn man über die normalen Schreib-/Lesezugriffe hinausgehen will, und ich kann kaum glauben, dass z.B. solche Informationen wie das Änderungsdatum eines Keys nicht mehr mit gespeichert werden sollen. Mit den MS Funktionen lässt sich dieses jedenfalls nicht mehr auslesen, sonder man muss sich die entsprechenden Funktionen selber importieren.

[Chewie]

Zitat:

Zitat von Christian Seehase

Da ich mal davon ausgehe, dass, u.a. aus den genannten Gründen, wohl zumindest eine Win32 Emulation erhalten bleiben wird, dürfte die Mischung, zumindest auf Jahre hinaus, kein grösseres Problem darstellen.

Ein Problem wird sie wohl nicht darstellen, aber ob noch lange für Win32 entwickelt wird, ist eine andere Frage. Schließlich entwickelt man ja heute nicht mehr für Win16 oder gar DOS, obwohl die Programme noch lauffähig wären. Warum? Weil man da auf einiges an Komfort verzichten müsste, den Win32 bietet. Vielleicht wird man in einigen Jahren auch für .NET vs. Win32 so argumentieren.

[Christian Seehase]

Moin Chewie,

Zitat:

Zitat von Chewie

Ein Problem wird sie wohl nicht darstellen, aber ob noch lange für Win32 entwickelt wird, ist eine andere Frage. Schließlich entwickelt man ja heute nicht mehr für Win16 oder gar DOS, obwohl die Programme noch lauffähig wären.

das ist wohl richtig, mir geht's dabei allerdings nicht um die Entwicklung für Win32, sondern darum, dass man, so zumindest mein derzeitiger Stand der Dinge, bei .NET Programmierung gar nicht immer ohne die Win32 Zugriffe auskommt, weil nicht alles was die Win32 API bietet dort implementiert ist.
Vielleicht ändert sich das ja noch.

[Chewie]

Nun ja, es gibt (glaube ich) eine Art GDI, es gibt Controls - also her mit dem Pinsel :mrgreen:

Im ernst, ich denke, Microsoft wird da schon nachrüsten, wenn notwendig. Sie werden kaum ein großes Projekt wie .NET mit hohen Kosten entwickeln und dann zusehen, wie es keiner nutzt.

[Marcel Gascoyne]

Zukünftig wird wohl kein Weg an .NET vorbeiführen. Auch wenn .NET im Gegensatz zu Win32 nicht so schnell ist (alle .NET Aufrufe werden ja auf Win32 umgesetzt) wird es sich gerade wegen der kompatiblität zwischen den Programmiersprachen durchsetzen.

Dies bietet gerade bei größeren Projekten enorme Vorteile, wo z.Zt. C++, Delphi, Cobol usw. in verschiedenen Teilbereichen eingesetzt wird. Dann ist endlich Schluß damit Schnittstellen zwischen allen Systemen zu implementieren.

Im Spielesektor wo die Performance am wichtigsten ist wird es .NET am Anfang noch schwer haben. Mal sehn was die Prozessorhersteller machen. Vielleicht wird .NET ja wie beim Transmeta Prozessor intern in die echten CPU Befehle umgesetzt :gruebel: ).

Gruß,
Marcel

[neolithos]

Zitat:

Zitat von Chakotay1308

PS: @neo: ähm... das ist nicht ganz korrekt. Ich kann, wenn ich WinAPI-Anwendungen schreibe problemlos im Dialogeditor mit der Tastatur Controls verschiebe (einfach mit den Pfeiltasten). MFC weiß ich nicht => habe ich noch nie angerührt. *angewidert sei von mfc*

Hast recht geht wirklich! Weis nicht was ich da vorvorgestern falsch gemacht habe!

[woki]

Zitat:

Zitat von Marcel Gascoyne

Auch wenn .NET im Gegensatz zu Win32 nicht so schnell ist (alle .NET Aufrufe werden ja auf Win32 umgesetzt).

Warum sollte ein API-Aufruf aus der Laufzeitumgebung merklich langsamer sein als aus einer Delphi oder C++ exe. Microsoft hat sich gerade in Performancefragen viel Mühe gegeben. Im Gegensatz gibt es viele Gründe zu der Annahme, daß .Net erheblich schneller sein wird als win32 Anwendungen, weil der .Net JIT-Compiler den erzeugten Code auf die aktuell angetroffene Hardware, also Pentium I, II, III ,IV AMD etc optimiert. Das hat sich in entsprechenden Tests auch wirklich bemerkbar gemacht.

Zitat:

Zitat von Marcel Gascoyne

Im Spielesektor wo die Performance am wichtigsten ist wird es .NET am Anfang noch schwer haben. Mal sehn was die Prozessorhersteller machen. Vielleicht wird .NET ja wie beim Transmeta Prozessor intern in die echten CPU Befehle umgesetzt :gruebel: ).

Auch das läßt sich durch meine bisherigen Informationen nicht bestätigen.

Grüsse
Woki

[merlin17]

hier noch etwas aktuelles von heute aus dem i-net:


Novell will Linux an Dotnet anbinden
Version 1.0 wird im kommenden Sommer fertig sein


Novell hat jetzt eine Roadmap für sein Mono-Projekt vorgelegt. Damit soll die Anbindung von Linux an Microsofts Dotnet geschaffen werden. Ziel ist eine Open-Source-Version der Plattform. Unix- und Linux-Entwicklern soll es so ermöglicht werden, die Microsoft-Anwendungen betriebssystem-übergreifend aufzubauen und einzusetzen.

Bei der Übernahme von Ximian, dem Initiator des Projekts, hatte sich Novell dazu verpflichtet, konstruktiv die Initiative der Open-Source-Gemeinschaft weiterzutragen. Seit über zwei Jahren wird an dem Projekt schon gearbeitet und einige Teile sind schon fertig. So ist etwa ein Dotnet-fähiger C#-Compiler beinahe fertig, ein virtuelles Hauptsteuersystem und einige Dotnet-Applikationen laufen bereits.

Die Version Mono 1.0 soll Mitte des kommenden Jahres fertig sein und nur Komponenten enthalten, die auch sicher laufen. Dennoch wird die Version bereits das Wichtigste, wie den Compiler, eine umfangreiche Klassenbibliothek und Java-Integration, enthalten und den Dotnet 1.1 Spezifikationen entsprechen. Den Release 1.2 sollen die 150 Entwickler Länder voraussichtlich Ende 2004 geschrieben haben.


:-) thomas