eine offene implementierung einer sprachumgebung is doch bei weitem besser als die closed-source version oder? vielleicht haben viele leute die befürchtung, dass mono so "versagt" wie kaffe damals für java. aber ich kenne das projekt und die arbeiten wirklich hervorragend.
versteht mich nicht falsch, aber ich versuche seit wochen zu verstehen, was ist das besondere am .NET und an der Strategie die da verfolgt wird? (ich rede nicht von C# un dem Compiler?!)
Ich mein, für mich sieht das nach nix neuem aus? sondern eher nach einer von M$ geschürten sache wie XP (nach dem ja alles auf XP lauten muss (siehe nVidia-treibe o. M$-Office XP; das läuft auch locker auf einem win98!)) und morgen heist halt alles .NET ???!!
Von Schwuler Richter Fenthick am Mi, 10. Juli 2002 um 08:31 #
> versteht mich nicht falsch, aber ich versuche seit wochen zu verstehen, was ist das besondere am .NET und an der Strategie die da verfolgt wird? (ich rede nicht von C# un dem Compiler?!)
Dann bist du offtopic. Tschüss!
PS Gibts bei Prolinux noch Flamewars um .NET wie vor ein, zwei Jahren? Na, ich werds ja gleich sehen. *g*
Das Besondere an .NET ist, daß es jetzt endlich auch bei Windows gibt, was bei Unix seit Jahrzehnten Gang und Gäbe ist:
Die Remote-Ausführbarkeit von Windows-Anwendungen!
.NET ist kurz gesagt nichts anderes als eine netzwerkfähige API für das (fast) komplette Windows-System, ergänzt um diverse Klassen für Security, Webservices etc. .NET ist klar von Java bzw. J2EE abgekupfert. Im Grunde sind .NET und J2EE ein- und dasselbe, obwohl MS das durch geschicktes Marketing zu kaschieren versucht. .NET unterscheidet sich von J2EE im Wesentlichen nur dadurch, daß J2EE eine Sprache (nämlich Java) für viele Plattformen (Windows, Unix, Mac etc.) anbietet, während es bei .NET viele Sprachen (C#, Perl#, Ruby# etc.) für eine Plattform (Windows) gibt. Wenn MS von "Plattformunabhängigkeit" spricht, sind damit nur die Windows-Plattformen gemeint.
Mono könnte die Vorteile beider Systeme verbinden und viele Sprachen für viele Plattformen unterstützen. Ich befürchte aber, daß das Mono-Projekt irgendwann heftig mit Patentproblemen zu kämpfen haben wird. MS wird sich da bestimmt nicht die Butter vom Brot nehmen lassen. Wenn die Mono-Leute erst mal gezwungen sind, Kernteile aus Mono herauszunehmen und umzuschreiben, gibt es über kurz oder lang einen Versions-Wirrwarr, den die Kunden sicher nicht lange mitmachen werden.
Das DotGNU-Projekt halte ich für vielversprechender, weil es nicht so eng an .NET wie Mono gekoppelt ist. Die Erfolgsaussichten sind hier IMHO deshalb gut, weil sich ca. 1/3 aller bisherigen MS-Kunden wegen der sehr kundenunfreundlichen neuen Lizenz 6.0 von MS abwenden und auf Linux, MacOSX und OpenOffice umsteigen oder es zumindest erwägen.
> Ich befürchte aber, daß das Mono-Projekt irgendwann heftig mit Patentproblemen zu kämpfen haben wird.
Nein, die Probleme werden sie nicht bekommen, weil 1. enthält das aktuelle .NET-Framework von MS keinen patentierten Code 2. wenn MS patentierten Code integriert, wird Mono entsprechende Funktionen, nicht übernehmen.
> Das DotGNU-Projekt halte ich für vielversprechender, weil es nicht so eng an .NET wie Mono gekoppelt ist.
Bitte? Wo willst Du die Information denn her haben? Das Ziel von DotGNU ist das komplette .NET nachzuprogrammieen (und nicht nur das .NET-Framework). Dazu zählen vor allem auch die Internet-Services wie Passport, die DotGNU reimplementieren möchte. Als ein kleiner Teil von DotGNU zählt auch Portable.NET, was gewissermaßen ein C#-Compiler mit Laufzeitumgebung und noch etwas mehr ist. Die Klassen, die Portable.NET verwendet sind zum überwiegenden Teil die von Mono. Bloß daß Portable.NET die unter der MIT-Lizenz stehenden Bibliotheken bei sich unter die LGPL oder GPL mit speziellen Erweiterungen stellt. Der C#-Compiler ist in Mono in C# und bei Portable.NET in C geschriben. Angebich, weil man ja erst einmal einen Compiler braucht, mit dem man die nötigen .NET-Klassen erstellen kann. Bloß kann der Portable.NET-Compiler gerade mal ein textbasiertes HelloWorld-Programm kompilieren, während der Compiler von Mono sich selbst und größere Anwendungen kompilieren kann. Und der Interpreter von Portable.NEt wandelt erst mal den .NET-Code in Code der eigenen VM um, um diesen dann auszufühen.
Einiges zu Mono und Portable.NET sagen auch die Autoen selbst unter folgender Adresse: http://www.devx.com/free/hotlinks/ 2002/ednote061902/ednote061902-1.asp (dort auf "read the interview" gehen)
Wenn Du es gelesen hast, dann kannst Du hier ja noch mal schreiben, welches Projekt Dir besser zusagt.
> Die Erfolgsaussichten sind hier IMHO deshalb gut, weil sich ca. 1/3 aller bisherigen MS-Kunden wegen der sehr kundenunfreundlichen neuen Lizenz 6.0 von MS abwenden und auf Linux, MacOSX und OpenOffice umsteigen oder es zumindest erwägen.
Ja, aber was Mono und Portable.NET betrifft, so versucht gerade Mono mit seiner Lizenz (und nicht nur mit der Lizenz) sowohl OpenSource-Fans als auch den Firmen entgegenzukommen. Portable.NET scheint sich hingegen überhauptnicht für Firmen zu interessieren, sondern sucht bloß Sponsoren für ihr Projekt, das sie selber toll finden.
>Nein, die Probleme werden sie nicht bekommen, weil >1. enthält das aktuelle .NET-Framework von MS keinen patentierten Code
Auf Heise.de wurde Ballmer bei der Cebit zitiert --------------------------------------------------- Auf die Öffnung des .NET-Framework angesprochen, kündigte Ballmer an, dass es sicherlich eine Common-Language-Runtime-Implementation für Unix geben werde, schränkte diese Entwicklung jedoch als Subset ein, der "nur für den akademischen Einsatz gedacht sei". Überlegungen zur Unterstützung freier .NET-Implementationen wie Mono erteilte Ballmer eine Absage: "Wir haben so viele Millionen in .NET gesteckt, wir haben so viele Patente auf .NET, die wir pflegen wollen." ---------------------------------------------------
Das DotGNU-Projekt halte ich für vielversprechender, weil es nicht so eng an .NET wie Mono gekoppelt ist.
Bitte? Wo willst Du die Information denn her haben? Das Ziel von DotGNU ist das komplette .NET nachzuprogrammieen (und nicht nur das .NET-Framework). Dazu zählen vor allem auch die Internet-Services wie Passport, die DotGNU reimplementieren möchte. Als ein kleiner Teil von DotGNU zählt auch Portable.NET, was gewissermaßen ein C#-Compiler mit Laufzeitumgebung und noch etwas mehr ist.
Nein, es stimmt, dass DotGNU nicht so stark an .NET gebunden ist: Der Mono-C#-Compiler wurde ursprünglich vom .NET-Compiler erzeugt. Der Portable.NET-Compiler hat nicht die geringste Spur von .NET. (Portable.NET ist eine richtige Cleanroom-Implementierung)
Portable.NET scheint sich hingegen überhauptnicht für Firmen zu interessieren, sondern sucht bloß Sponsoren für ihr Projekt, das sie selber toll finden.
Im Gegenteil würde ich eher sagen, dass DotGNU professioneller ist (du glaubst wohl immer noch mit GPL-Software lässt sich kein Geld verdienen), Mono dagegen wird von enthusiastischen Hackern vorangetrieben, denen es egal ist, ob man die GPL verwendet oder nicht (viele von ihnen kommen übrigens direkt von der Windows-Welt), hauptsache jeder kommt an den Code und kann mitentwickeln.
>.NET unterscheidet sich von J2EE im Wesentlichen nur dadurch, daß J2EE eine Sprache (nämlich Java) für viele Plattformen (Windows, Unix, Mac etc.) anbietet, während es bei .NET viele Sprachen (C#, Perl#, Ruby# etc.) für eine Plattform (Windows) gibt.
.Net is nicht wirkklich sprachunabhängig! Bei .NET werden ja nur bestimmte Sprachfeatures unterstützt. C++ geht z.B. nicht mit .NET weil Templates nicht unterstützt werden. Da viele Sprachen wie Java, C#, Python, Perl einander sehr ähnlich sind ist das wohl nichts Besonderes.
Man sollte mal hervorheben dass es im Linux/Freie Software Bereich schon Lösungen gibt, die .Net ähneln. Perl kann in Java Bytecode übersetzt werden und Java Libs benutzen. Python kann auch in Java Bytecode überstezt werden und Java Libs benutzen. Somit gibt es schon drei Sprachen die auf den JVM's laufen und die Java Klassen benutzen können und es gibt bestimmt noch mehr die ich nicht kenne.
Richtige Bindings können die jeweiligen Features der Sprache voll unterstützen. Und so viel Arbeit sie zu erstellen und zu pflegen ist es ja auch nicht mehr, seitdem das automatisiert worden ist (vor allem leichter als einen Compiler zu schreiben). Dazu kommt dass C- und C++Libraries ja sowieso schon von allen vom GCC unterstützen Sprachen benutzt werden können. Die sprachunabhängigkeit von .Net ist eigentlich nichts neues.
.Net is nicht wirkklich sprachunabhängig! Bei .NET werden ja nur bestimmte Sprachfeatures unterstützt. C++ geht z.B. nicht mit .NET weil Templates nicht unterstützt werden.
Na ja, das wäre so als ob ich sagen würde: Die IA32 unterstützt keine parametrische Polymorphie, weil es kein entsprechendes Konstrukt in den Prozessor-Opcodes gibt.
Jede Art Polymorphismus kann jedoch von einem Compiler "wegübersetzt" werden, was zugegeben nicht sehr elegant ist, aber gleichwohl möglich, wie entsprechende Projekte für die JVM zeigen. Nur weil die IML der CLR keine entsprechenden Sprachkonstrukte aufweist, bedeutet dies nicht, das die Sprachen die die CLR ansteuern keine parametrische Polymorphie anbieten können.
Im Übrigen soll eine der nächsten CLR-Versionen um entsprechende Konstrukte erweitert werden.
Also in der MS Dokumentation ist C++ nicht bei den unterstützten Sprachen aufgezählt. Bloss managed C++. Und wenn man sich dann ansieht, was die unter managed C++ verstehen, dann bedeutet das daß man ein normales C++ programm komplett überarbeiten muss, um es .Net tauglich zu machen.
hallo wenn die .NET laufzeitumgebung unter linux läuft, kann ich dann mit VB.NET geschriebene programme unter linux laufen lassen (falls es auch GUI's für mono gibt) ???? das wären doch dann viele neue programme automatisch auch für linux verfügbar. sorry, wenn die frage deppert ist, ich hab keine ahnung von .NET
> wenn die .NET laufzeitumgebung unter linux läuft, kann ich dann mit VB.NET geschriebene programme unter linux laufen lassen (falls es auch GUI's für mono gibt) ????
Ja - jedoch mit einer Einschränkung. Wenn nicht bereits heute, so wirst Du zumindet in Zukunft unter Windows mit VB.NET Programme erstellen können, die auch auf Linux laufen. Jedoch nur mit der Einschränkung, daß Du dann auch nur Klassen verwendest, die es für beide Systeme gibt. Wenn es sie für Windows nicht gibt, kannst Du Dein Programm nicht kompilieren und wenn es sie für Linux nicht gibt, läuft das Programm nicht auf Linux. Im übrigen wurden die ersten Gtk#-Bibliotheken und -Programme auf Windows geschrieben, da der C#-Compile von Mono sie anfangs nicht kompilieren konnte (inzwischen kann man jedoch Gtk#-Programme sowohl auf Windows als auch auf Linux schreiben und sie laufen auch auf beiden Systemen).
> das wären doch dann viele neue programme automatisch auch für linux verfügbar.
Nicht unbedingt. Wenn die Programme auf Native-Code Bibliotheken von Windows zugreifen oder Klassen verwenden, die es nur für Windows gibt, dann läuft auch das Programm selber bloß auf Windows.
Ja, es wäre sogar sehr schwierig. Mit einem einfachen API-Binding wäre es nicht getan. Es müßte dabei gewissermaßen auch Windows zum großen Teil emuliert werden.
Daher wird zumindest Ximian sich nicht an einer Implementierung von Windows.Forms für Linux beteiligen. Und auch bei der Erstellung von Windows.Forms, ist es wahrscheinlich, daß diese die WINE-lib verwenden wird und nicht Gtk oder Qt, weil letzteres zu aufwändig wäre.
eine offene implementierung einer sprachumgebung is doch bei weitem besser als die closed-source version oder?
vielleicht haben viele leute die befürchtung, dass mono so "versagt" wie kaffe damals für java.
aber ich kenne das projekt und die arbeiten wirklich hervorragend.
gruss,
comrad
Ich mein, für mich sieht das nach nix neuem aus? sondern eher nach einer von M$ geschürten sache wie XP (nach dem ja alles auf XP lauten muss (siehe nVidia-treibe o. M$-Office XP; das läuft auch locker auf einem win98!)) und morgen heist halt alles .NET ???!!
Für hinhweise und tips, wäre ich echt dankbar!
Dann bist du offtopic. Tschüss!
PS Gibts bei Prolinux noch Flamewars um .NET wie vor ein, zwei Jahren?
Na, ich werds ja gleich sehen. *g*
Sehe ich nicht so. Mich würde das auch schon lang interessieren.
Für sachliche Antworten schonmal Danke im Voraus...
Michael
Die Remote-Ausführbarkeit von Windows-Anwendungen!
.NET ist kurz gesagt nichts anderes als eine netzwerkfähige API für das (fast) komplette Windows-System, ergänzt um diverse Klassen für Security, Webservices etc. .NET ist klar von Java bzw. J2EE abgekupfert. Im Grunde sind .NET und J2EE ein- und dasselbe, obwohl MS das durch geschicktes Marketing zu kaschieren versucht. .NET unterscheidet sich von J2EE im Wesentlichen nur dadurch, daß J2EE eine Sprache (nämlich Java) für viele Plattformen (Windows, Unix, Mac etc.) anbietet, während es bei .NET viele Sprachen (C#, Perl#, Ruby# etc.) für eine Plattform (Windows) gibt. Wenn MS von "Plattformunabhängigkeit" spricht, sind damit nur die Windows-Plattformen gemeint.
Mono könnte die Vorteile beider Systeme verbinden und viele Sprachen für viele Plattformen unterstützen. Ich befürchte aber, daß das Mono-Projekt irgendwann heftig mit Patentproblemen zu kämpfen haben wird. MS wird sich da bestimmt nicht die Butter vom Brot nehmen lassen. Wenn die Mono-Leute erst mal gezwungen sind, Kernteile aus Mono herauszunehmen und umzuschreiben, gibt es über kurz oder lang einen Versions-Wirrwarr, den die Kunden sicher nicht lange mitmachen werden.
Das DotGNU-Projekt halte ich für vielversprechender, weil es nicht so eng an .NET wie Mono gekoppelt ist. Die Erfolgsaussichten sind hier IMHO deshalb gut, weil sich ca. 1/3 aller bisherigen MS-Kunden wegen der sehr kundenunfreundlichen neuen Lizenz 6.0 von MS abwenden und auf Linux, MacOSX und OpenOffice umsteigen oder es zumindest erwägen.
Nein, die Probleme werden sie nicht bekommen, weil
1. enthält das aktuelle .NET-Framework von MS keinen patentierten Code
2. wenn MS patentierten Code integriert, wird Mono entsprechende Funktionen, nicht übernehmen.
> Das DotGNU-Projekt halte ich für vielversprechender, weil es nicht so eng an .NET wie Mono gekoppelt ist.
Bitte? Wo willst Du die Information denn her haben?
Das Ziel von DotGNU ist das komplette .NET nachzuprogrammieen (und nicht nur das .NET-Framework). Dazu zählen vor allem auch die Internet-Services wie Passport, die DotGNU reimplementieren möchte.
Als ein kleiner Teil von DotGNU zählt auch Portable.NET, was gewissermaßen ein C#-Compiler mit Laufzeitumgebung und noch etwas mehr ist.
Die Klassen, die Portable.NET verwendet sind zum überwiegenden Teil die von Mono. Bloß daß Portable.NET die unter der MIT-Lizenz stehenden Bibliotheken bei sich unter die LGPL oder GPL mit speziellen Erweiterungen stellt.
Der C#-Compiler ist in Mono in C# und bei Portable.NET in C geschriben. Angebich, weil man ja erst einmal einen Compiler braucht, mit dem man die nötigen .NET-Klassen erstellen kann. Bloß kann der Portable.NET-Compiler gerade mal ein textbasiertes HelloWorld-Programm kompilieren, während der Compiler von Mono sich selbst und größere Anwendungen kompilieren kann.
Und der Interpreter von Portable.NEt wandelt erst mal den .NET-Code in Code der eigenen VM um, um diesen dann auszufühen.
Einiges zu Mono und Portable.NET sagen auch die Autoen selbst unter folgender Adresse:
http://www.devx.com/free/hotlinks/ 2002/ednote061902/ednote061902-1.asp
(dort auf "read the interview" gehen)
Wenn Du es gelesen hast, dann kannst Du hier ja noch mal schreiben, welches Projekt Dir besser zusagt.
> Die Erfolgsaussichten sind hier IMHO deshalb gut, weil sich ca. 1/3 aller bisherigen MS-Kunden wegen der sehr kundenunfreundlichen neuen Lizenz 6.0 von MS abwenden und auf Linux, MacOSX und OpenOffice umsteigen oder es zumindest erwägen.
Ja, aber was Mono und Portable.NET betrifft, so versucht gerade Mono mit seiner Lizenz (und nicht nur mit der Lizenz) sowohl OpenSource-Fans als auch den Firmen entgegenzukommen. Portable.NET scheint sich hingegen überhauptnicht für Firmen zu interessieren, sondern sucht bloß Sponsoren für ihr Projekt, das sie selber toll finden.
>1. enthält das aktuelle .NET-Framework von MS keinen patentierten Code
Auf Heise.de wurde Ballmer bei der Cebit zitiert
---------------------------------------------------
Auf die Öffnung des .NET-Framework angesprochen, kündigte Ballmer an, dass es sicherlich eine Common-Language-Runtime-Implementation für Unix geben werde, schränkte diese Entwicklung jedoch als Subset ein, der "nur für den akademischen Einsatz gedacht sei". Überlegungen zur Unterstützung freier .NET-Implementationen wie Mono erteilte Ballmer eine Absage: "Wir haben so viele Millionen in .NET gesteckt, wir haben so viele Patente auf .NET, die wir pflegen wollen."
---------------------------------------------------
So viel zum Thema "keine Patente".
odoggy
http://www.heise.de/newsticker/data/jk-12.03.02-000/
odoggy
Bitte? Wo willst Du die Information denn her haben?
Das Ziel von DotGNU ist das komplette .NET nachzuprogrammieen (und nicht nur das .NET-Framework). Dazu zählen vor allem auch die Internet-Services wie Passport, die DotGNU reimplementieren möchte.
Als ein kleiner Teil von DotGNU zählt auch Portable.NET, was gewissermaßen ein C#-Compiler mit Laufzeitumgebung und noch etwas mehr ist.
Nein, es stimmt, dass DotGNU nicht so stark an .NET gebunden ist: Der Mono-C#-Compiler wurde ursprünglich vom .NET-Compiler erzeugt. Der Portable.NET-Compiler hat nicht die geringste Spur von .NET. (Portable.NET ist eine richtige Cleanroom-Implementierung)
Portable.NET scheint sich hingegen überhauptnicht für Firmen zu interessieren, sondern sucht bloß Sponsoren für ihr Projekt, das sie selber toll finden.
Im Gegenteil würde ich eher sagen, dass DotGNU professioneller ist (du glaubst wohl immer noch mit GPL-Software lässt sich kein Geld verdienen), Mono dagegen wird von enthusiastischen Hackern vorangetrieben, denen es egal ist, ob man die GPL verwendet oder nicht (viele von ihnen kommen übrigens direkt von der Windows-Welt), hauptsache jeder kommt an den Code und kann mitentwickeln.
.Net is nicht wirkklich sprachunabhängig! Bei .NET werden ja nur bestimmte Sprachfeatures unterstützt. C++ geht z.B. nicht mit .NET weil Templates nicht unterstützt werden. Da viele Sprachen wie Java, C#, Python, Perl einander sehr ähnlich sind ist das wohl nichts Besonderes.
Man sollte mal hervorheben dass es im Linux/Freie Software Bereich schon Lösungen gibt, die .Net ähneln. Perl kann in Java Bytecode übersetzt werden und Java Libs benutzen. Python kann auch in Java Bytecode überstezt werden und Java Libs benutzen. Somit gibt es schon drei Sprachen die auf den JVM's laufen und die Java Klassen benutzen können und es gibt bestimmt noch mehr die ich nicht kenne.
Richtige Bindings können die jeweiligen Features der Sprache voll unterstützen. Und so viel Arbeit sie zu erstellen und zu pflegen ist es ja auch nicht mehr, seitdem das automatisiert worden ist (vor allem leichter als einen Compiler zu schreiben). Dazu kommt dass C- und C++Libraries ja sowieso schon von allen vom GCC unterstützen Sprachen benutzt werden können. Die sprachunabhängigkeit von .Net ist eigentlich nichts neues.
Marc
Na ja, das wäre so als ob ich sagen würde: Die IA32 unterstützt keine parametrische Polymorphie, weil es kein entsprechendes Konstrukt in den Prozessor-Opcodes gibt.
Jede Art Polymorphismus kann jedoch von einem Compiler "wegübersetzt" werden, was zugegeben nicht sehr elegant ist, aber gleichwohl möglich, wie entsprechende Projekte für die JVM zeigen. Nur weil die IML der CLR keine entsprechenden Sprachkonstrukte aufweist, bedeutet dies nicht, das die Sprachen die die CLR ansteuern keine parametrische Polymorphie anbieten können.
Im Übrigen soll eine der nächsten CLR-Versionen um entsprechende Konstrukte erweitert werden.
Marc
wenn die .NET laufzeitumgebung unter linux läuft, kann ich dann mit VB.NET
geschriebene programme unter linux laufen lassen (falls es auch GUI's für mono
gibt) ????
das wären doch dann viele neue programme automatisch auch für linux verfügbar.
sorry, wenn die frage deppert ist, ich hab keine ahnung von .NET
Ja - jedoch mit einer Einschränkung.
Wenn nicht bereits heute, so wirst Du zumindet in Zukunft unter Windows mit VB.NET Programme erstellen können, die auch auf Linux laufen.
Jedoch nur mit der Einschränkung, daß Du dann auch nur Klassen verwendest, die es für beide Systeme gibt.
Wenn es sie für Windows nicht gibt, kannst Du Dein Programm nicht kompilieren und wenn es sie für Linux nicht gibt, läuft das Programm nicht auf Linux.
Im übrigen wurden die ersten Gtk#-Bibliotheken und -Programme auf Windows geschrieben, da der C#-Compile von Mono sie anfangs nicht kompilieren konnte (inzwischen kann man jedoch Gtk#-Programme sowohl auf Windows als auch auf Linux schreiben und sie laufen auch auf beiden Systemen).
> das wären doch dann viele neue programme automatisch auch für linux verfügbar.
Nicht unbedingt. Wenn die Programme auf Native-Code Bibliotheken von Windows zugreifen oder Klassen verwenden, die es nur für Windows gibt, dann läuft auch das Programm selber bloß auf Windows.
Mit einem einfachen API-Binding wäre es nicht getan. Es müßte dabei gewissermaßen auch Windows zum großen Teil emuliert werden.
Daher wird zumindest Ximian sich nicht an einer Implementierung von Windows.Forms für Linux beteiligen. Und auch bei der Erstellung von Windows.Forms, ist es wahrscheinlich, daß diese die WINE-lib verwenden wird und nicht Gtk oder Qt, weil letzteres zu aufwändig wäre.
"So would be the Gtk#-Projekt (http://gtk- sharp.sf.net), which as goal have, to create .NET- bindings for Gtk+, by Ximian supported, too."
Jup. All your base are belong to us. ;-)
monty
Erstaunlich wie tolerant die bezüglich der englischen Rechtschreibung und Grammatik sind.
Die Sprachfehler in diesem Artikel sind ja wirklich haarsträubend, man versteht ja teilweise überhaupt nicht mehr, was der Autor ausdrücken will.
monty
Ist das die 'Programmiersprache' die ich meine ? Nicht im Ernst, oder ? Wann gibt es BASIC for .NET ?
Der Autor (gesendet von ...) hat eine Hotmail-Adresse ?
Hier macht sich doch nicht etwa jemand ueber uns lustig ?
Merkwuerdig merkwuerdig ...
http://www.atoker.com/phonic/
gibt es nun auch einen Media-Player für Mono, der auf Gtk# aufbaut.
Der Screenshot ist jedenfalls schon mal vielversprechend.