Sehe ich nicht so. Delphji hat einfach eine ganz andere Zielgruppe. Und wenn du einen Treiber brauchst, dann Programmkier ihn mit VC und den Rest mit Delphi.

Du hast es noch nicht ganz verstanden, oder ?

C# ist nur eine Ausdrucksweise der .NET Platform - es ist dabei völlig egal ob du VB.NET, Delphi.NET, C# oder was auch immer programmierst - sie alle produzieren MSIL.

Und wenn du ein Programm in VB.NET und C# schreibst, was den selben Algorithmus zu Grunde liegt, du wirst dich wundern - beide Assemblies sind identisch (klar - sind ja auch beide von MS, aber ich denke, auch Delphi-Code wird nicht sehr davon abweichen - wieso auch).

Also ist die Frage der Programmiersprache der Zukunft keine Frage - wenn sich die .NET-Platform etabliert wie damals Win95 oder IE, dann gibts bald keine Unterschiede mehr, was du programmierst. Der Output ist egal welche Programmiersprache identisch.

ja, schon, das ist richtig. Bin nur gespannt, wann Delphi über den Status des RAD-Tools hinausdigitiert (bitte um Verzeihung für meine gerade ziemlikch kindische Ausdrucksweise @digimon) und zu einer Plattform für alle Arten von Programmen und Systemkomponenten wird. Darauf warte ich gespannt

Hallo,

ShadowCaster hat folgendes geschrieben:

Treiber sind wichtig. [...] Ich bin der Meinung dass C seine Darseinsberechtigung hat aber ich glaube nicht, dass sich C# durchsetzen wird. Vielleicht wird es mal so eine Verbreitung wie Visual C++ erreichen in ein paar Jahren aber mehr sicher nicht...

damit wiedersprichst du dir ein wenig. Denn einerseits behauptest du, das Delphi zur verbreitung von C++ aufschließen könnte, wenn man Treiber damit erstellen könnte. Andererseits sagst du aber, das Visual C++, der einzige Compiler der Windows Treiber erstellen kann, nur eine geringe verbreitung hat.
Also irgendwie passt das nicht.

Gruß
Klabautermann

ShadowCaster hat folgendes geschrieben:

Bin nur gespannt, wann Delphi über den Status des RAD-Tools hinausdigitiert

Warum sollte es das? Porsche baut auch keine Panzer.

naja, warum? die Frage hättest du gar nicht stellen brauchen. Weil Entwickler die Funktionen brauchen und deswegen früher oder später auf VC++ umsteigen müssen, nur weil Delphi das und einiges anderes nicht kann. Da kann ich ja dann gleich bei C++ bleiben, wenn ich systemnah entwickeln will und delphi in der Sparte ganz vergessen.

Du kannst das etwa folgendermaßen vergleichen: Warum baut Porsche auch ABS und ESP in seine Autos ein? Zum einen (der wichtigste Punkt) um den Fahrkomfort der Autobesitzer zu steigern und das Unfallrisiko zu mindern und um mehr Kunden zu gewinnen und weil das andere Hersteller auch tun.

Porsche könnte ja auch sagen, vergleichbar mit Borlands oder deiner Meinung: Wir bauen in unserem Autosegment nur Sportwagen, wofür brauchen die ESP oder ABS? Die Autos unserer Konkurrenz haben das ja schon. (Sollen die Kunden zu unserer Konkurrenz gehen. Wir nennen unsere Autos Sportwagen und nicht Unfallfreiwagen oder Luxuswagen, das tut die Konkurrenz).

Naja, ein Auto ist immer noch ein Auto. Letztendlich ist es das Problem der Hersteller. Den Vergleich mit dem Panzer halte ich schlicht für übertrieben. Warum werden in Autos Kilometerzähler eingebaut? Damit man das Auto nicht trocken fährt. Wenn man nach dem Prinzip entwickelt: die Konkurrenz besitzt das ja schon! dann wird man nie was in allen Segmenten der Technik erreichen. So ist das auch bei Compilern. Was nützt mir ein Compiler oder RAD-Tool wenn ich damit nur Anwendungen auf vorhandenen Systemfunktionen entwickeln kann? Was ist wenn mir die Systemfunktionen von Windows zu langsam oder zu schlecht sind oder ich systemnah entwickeln will? Dann brauch ich auch nicht den Inlineassembler von Delphi, weil der mir da sowieso nix bringt.

Was hätten denn die ersten Entwickler von DirectX sagen sollen? Es gab die Schiene OLE und COM, DCOM. Damals haben Spieleentwickler in DOS entwickelt, weil Windows und die lahme COM- OLE-Schiene nicht ging. Es war einfach zu langsam oder nicht möglich was dafür gescheit zu entwickeln, bis private Programmierer die Schiene neu definiert haben mit DirectX. Dann kam plötzlich M.... und hat dieses Tool aufgekauft, weil immer und immer mehr Spielehersteller damit entwickelt haben und M.... entdeckt hat, das DirectX im Bereihc der Spiele die Zukunft ist.

Wenn ich für Windows oder andere Systeme nicht mal Treiber entwickeln kann, dann ist das so, als würde ich mit einer Blackbox arbeiten. Ich kann sie bedienen und was mit ihr machen, aber ich kann nicht in sie reinschauen oder Dinge in ihr ersetzen. Ich hab doch gar nichts gegen Delphi und ich weiß, dass Delphi als RAD-Tool deklariert ist, aber die Systemschiene ist unerlässlich. Soviele Anwendungen wie Virenscanner, Grafikkartentreiber, Soundkartentreiber, COM-OLE-Treiber, Directx-Treiber, Mainboard-treiber, etc. Wie soll ich in Delphi jemals solche Treiber als Systemhersteller entwickeln können? Da fang ich ja bei 0 an. Also nehme ich VC++ oder C# oder was auch immer. Das find ich total schade. Es ist einfach fast gemein von Borland, Delphi nicht so zu erweitern, weil Delphi für mich einfach die Zukunft darstellt. Wenn diese Features in Delphi drinnen wären, würde Borland mit einem Schlag ein komplettes Marktsegment konkurrenzfähig besetzen können. Das ist nicht gerade wenig.

Naja, lange Rede, kurzer Sinn. Das was oben steht, wars was ich sagen wollte ... *lol*. Ich will jetzt nicht von C# abschweifen. Die Idee halte ich ja schon für gut, dass Sachen von Delphi und Java und C vereint wurden, allerdings ist C# systemabhängig. Man macht sich von Microsoft abhängig und das ist fahrlässig. Sofern bald Palladium und TCPA oder wie das jetzt mittlerweile heißt auf den Markt kommen, dann gute Nacht Windows. Wer auf der C#-Schiene fährt, der sitzt in einem Zug, der auf einer Strecke fährt, deren Gleise bald enden ... und dann irgendwann macht es Bumm... und Windows ist nicht mehr da und plötzlich stehen alle Firmen deren Programme auf C# entwickelt wurden ohne Absatzmarkt da, da niemand mehr Windows benutzt.

Das sind jetzt sehr düstere Aussichten... aber so denke ich wird ich der Markt höchstwahrscheinlich entwickeln. Ich sehe nicht ein warum ich C# benutzen soll. Das ist ein Gleis, was nach 3 Kilometern endet, es sei denn jemand entwickelt Interpreter für Browser und unterschiedliche Betriebssysteme, aber es gibt ja schon Java. Ich nehm doch lieber Java, auch wenns langsamer ist. Java ist C# schon mindestens 5 Jahre in der Entwicklung vorraus. Das gibt es schon seid 1990, wenn die Daten in meinem Gedächtnis stimmen.

... C# ist systemabhängig stimmt eben nicht.

Nochmals: C# ist nur eine Programmiersprache des .NET Frameworks.

Weiters kann man mit jeder .NET Sprache gleichwertige .NET Anwendungen schreiben (oder auch nur Assemblys).

Und das .NET Framework wird derzeit auch auf andere Platformen (wie z.B. Linux) portiert ... du kannst also auch eine .NET Anwendung früher oder später unter anderen OS laufen lassen (auch wenns noch ein paar Problemchen gibt ...).

Die Aussage c# ist abhängig von Windows ist damit schlicht und ergreifend falsch - die Aussage, MS gibt vor, was das Framework macht, kann, darf und somit auch jede darauf laufende Anwendung ist eine andere Geschichte.

Zur Treiberprogrammierung: Schlicht und ergreifend unwichtig - wenn eine OS-API oder auch ein darüberliegendes Framework Klassen/Funktionen bietet, welche die Aufgabe auch lösen können (z.B. für Virenscanner), dann ist Treiberprogrammierung schlicht unnötig - und sollte meiner Meinung nach auch bei den Hardwareherstellern und OS-Entwicklern bleiben.

Sonst reißt man nur Sicherheitslücken in sein System, weil man vorher immer checken müßte, was der Treiber eigentlich tut und kann.

Ich hatte doch oben gesagt, dass C# systemabhängig und damit Abhängig von microsoft macht, oder nich? Naja egal... hab mich vielleicht falsch ausgedrückt. Werde mich an dieser Stelle wegen zu wenig Fachwissen über C# aus der Diskussion zurückziehen, bevor ich noch Falsches von mir geb. Ich hoffe, ihr versteht das...

nachtrag: wenn ich immer erst warten muss, bis microsoft mir die Api-funktionen anbietet,damit ich nicht selbst schnittstellen schreiben muss, dann bin ich aber ganz schön aufgeschmissen. Ich werd mal sehen, ob ich mich nicht in VC++ einarbeite und wenn mir die Sprache gefällt muss ich schauen, ob ich nicht hauptsächlich darin entwickel, was die Systemprogrammierung angeht, weil ich bei Delphi ja nicht genug geboten bekomm.

Lest du eigentlich meine Postings ?

C# und alle damit verbundenen Sprachen sind N I C H T systemabhängig - das ist nämlich der Sinn von Frameworks (siehe Java auch wenns dort ziemlich schlampig implementiert wurde, aber auch .NET ist ja nicht perfekt).

ich hab ein Tool für die Treiberentwicklung auch mit delphi gefunden... nach ziemlich langem Suchen. Es sind keine Kenntnisse des DDK nötig. Allerdings turnt mich dieses Tool noch nicht so an. Scheinbar haben da schon ein paar Leute eine Schnittstelle zwischen DDK und Delphi geschaffen, nur warum kommt das nicht von Borland?

www.jungo.com/windriver_windows.html

Hallo,

ShadowCaster hat folgendes geschrieben:

nur warum kommt das nicht von Borland?

ich kenne dieses Tool nicht, und kann nicht sagen, wie gut es arbeitet. Aber Borland hat höchst warscheinlich eine Kosten nutzen Rechnung aufgemacht, und festgestellt, dass die entwicklung eines Compilers für Treiber seine Kosten nicht wieder einspielt. Denn wenn ich recht informiert bin, ist das Compilat für treiber von denen für "normale" Anwendungen komplett unterschiedlich, so das es tatsächlich auf einen Zweiten Compiler hinauslaufen würde (dessen funktionen natürlich in die selbe EXE wie der erste integriert werden könnte).

Sicher ist es schade, dass Delphi keine Treiber erzeugen kann, allerdings ist mir lieber, das es dies nicht kann, als wenn ich auf irgendwelche RAD funktionen verzichten müsste.

Gruß
Klabautermann

naja, wieso sollte man auf RAD-Funktionen verzichten müssen? Das wäre ja als wenn du behaupten würdest, dank CLX müsste man auf VCL-Funktionen verzichten. Das ist doch nicht der Fall. Lediglich eine SChnittstelle zur DDK wäre super, die das Entwickeln von Treibern ermöglicht.

ShadowCaster hat folgendes geschrieben:

Lediglich eine SChnittstelle zur DDK wäre super, die das Entwickeln on Treibern ermöglicht.

Diese Schnittstelle zu schreiben ist kein Problem. Nur wer übersetzt die zig MB DDK Header-Dateien nach Pascal um sie dann in einem einzigen Treiber zu verwenden? Auch wenn diese dann Online gestellt werden sollten, was ich mir bei dem Übersetzungsaufwand eher als entgeltlich vorstellen kann, werden nicht all zu viele Delphi-Programmierer Treiber schreiben.

Zitat:

Denn wenn ich recht informiert bin, ist das Compilat für treiber von denen für "normale" Anwendungen komplett unterschiedlich

Nein, es ist das selbe compilat. Der Linker von Delphi ist die "Schwachstelle", denn dieser kann keine Treiber zusammenlinken, wie es der Linker von VC++ kann. Beim ilink.exe von BCB ist ein Linken von Treibern zwar vorgesehen, aber dann tatsächlich einen Treiber zu Linken ist ein anderes Problem, da wiederum mit den unterschiedlichen .lib-Formaten zu tun hat.

Es sind nicht nur die Header-dateien, sondern auch bestimmte Sprachkonstrukte von C, die Probleme bereiten. Siehe auch hier: "Wo hat Delphi seine Grenzen" von Nico Bendlin.

Hi,

ShadowCaster hat folgendes geschrieben:

naja, wieso sollte man auf RAD-Funktionen verzichten müssen?

weil dafür menpower benötigt wird, die irgendwo anders abgezogen wird.

ShadowCaster hat folgendes geschrieben:

Das wäre ja als wenn du behaupten würdest, dank CLX müsste man auf VCL-Funktionen verzichten. Das ist doch nicht der Fall.

Von Kylix verspricht Borland sich eine führende Position auf einem neuen Markt. Daher wurden daher wohl zum teil neue Leute eingestellt. Dennoch habe ich das gefühl, das die neuerungen in Delphi weniger sauber umgesetzt werden als früher (tActionToolbar & Co sind unverschämt Buggy [auch noch nach dem Patch]) und Kylix ist erst mit der Aktuellen Version 3 halbwechs einsetzbar. Trotzdem kämpft Borland schon fast anisch um der erhoffte Marktposition (bei €20 für K3 Pro können die keinen Gewinn machen). Es würde mich nicht mal überraschen, wenn diese Schiene zu gunsten von .NET (welches auch wieder Manpower kostet) eingestellt würde. Auf jeden Fall kämpft das Delphi-Language Team von Borland momentan an drei Fronten, die werden da keine vierte eröffnen. Selbst wenn Delphi Treiber erstellen könnte, würde das seine Marktposition nur unwesentlich verbessern, da die wenigsten Benutzer Treiber Programmieren wollen/müssen. Wie, gesagt, ich fände es auch nicht schlecht, wenn Delphi könnte, aber es gibt Dinge die wichtiger sind.
Viele Programmierer würden warscheinlich auch auf grund ihrer Überzeugung nicht auf Pascal als Sprache zur Treiber Programmierung zurückgreifen. Da für Systemnahe Programmierung C(++) als ideal angesehen wird. Denn in C(++) ist alles möglich was technisch realisierbar ist, in Pascal nicht. Dies wird bei Leuten die nah an der Maschiene sind als riesen Vorteil gesehen.

Gruß
Klabautermann

Klabautermann hat folgendes geschrieben:

bei €20 für K3 Pro können die keinen Gewinn machen

Wenn genug Leute bestellen, dann vielleicht doch. Bei 14 Käufern hat man schon 280 €, wie die Kylix 3 Pro Version kostet (Steckenborn.de) eingefahren.

Klabauterman, du hast wohl recht