Microsoft veröffentlicht den Sourcecode des .NET Frameworks

[Phoenix]

Ab Version 3.5 des .NET Frameworks wird der Source des Frameworks selber zum Download zur Verfügung stehen.

Zitat:

Zitat von Microsoft

We'll begin by offering the source code (with source file comments included) for the .NET Base Class Libraries (System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, System.Security, System.Runtime, System.Text, etc), ASP.NET (System.Web), Windows Forms (System.Windows.Forms), ADO.NET (System.Data), XML (System.Xml), and WPF (System.Windows). We'll then be adding more libraries in the months ahead (including WCF, Workflow, and LINQ). The source code will be released under the Microsoft Reference License (MS-RL).

Quelle

:love:

[mkinzler]

Allerdings unter einer sehr restriktiven Lizenz. Aber vielleicht hilft es CodeGear schneller ihre Win32-Abhängigkeit von Vcl.Net loszuwerden
http://www.heise.de/newsticker/meldung/96909

[Edit: Elvis war schneller: http://www.delphipraxis.net/internal....php?t=119859]

[Dax]

Es gibt schon einen Thread dazu, Phoe...

http://www.delphipraxis.net/internal...t.php?t=119859

[JamesTKirk]

Sers mitnand!

Ich weiß, dass es schon einen anderen Thread dazu gibt, aber das muss ich hier loswerden ;)

@mkinzler: Hatten die Entwickler von Borland/CodeGear nicht behauptet nachgeschaut/-forscht zu haben, wie die WinForms funktionieren, um ihre VCL.NET Implementierung genauso aufzubauen? Hatten Sie dabei nicht herausgefunden, dass WinForms auch "nur" auf der Win32 API aufbaut? (Ich hatte das irgendwo mal gelesen, fragt mich aber nicht mehr wo :gruebel: )

[mkinzler]

Zitat:

@mkinzler: Hatten die Entwickler von Borland/CodeGear nicht behauptet nachgeschaut/-forscht zu haben, wie die WinForms funktionieren, um ihre VCL.NET Implementierung genauso aufzubauen? Hatten Sie dabei nicht herausgefunden, dass WinForms auch "nur" auf der Win32 API aufbaut? (Ich hatte das irgendwo mal gelesen, fragt mich aber nicht mehr wo Grübelnd... )

Ja WinForms ist auch nur ein Wrapper um Win32. Aber es besteht trotzdem ein Unterschied, den die WinForms-Implemtierung umgeht erstens die CAS und 2. ist so die Plattformabhängigkeit nicht in der Exe, sondern in einem Systemteil (Programme laufen auf alternativen .Net-Plattformen wie Mono; sogar auf anderen Betriebssystemen)
Aber ich dachte eigentlich nicht an WinForms (welches ja nur als Übergangslöung gedacht war) sondern and WPF

[jbg]

Zitat:

Zitat von mkinzler

umgeht erstens die CAS und 2.

Das ist der einzige Grund, den man aber auch mit viel Geld umgehen kann.

Zitat:

Programme laufen auf alternativen .Net-Plattformen wie Mono;

Warum das wohl so ist? Doch wohl nur, weil sich eine Firma dahinter geklemmt hat, WinForms für X und MacOS zu portieren. Das selbe könnte man auch mit der VCL machen (wenn CodeGear eine bessere VCL Quellcode Lizenz hätte).

Zitat:

Aber ich dachte eigentlich nicht an WinForms (welches ja nur als Übergangslöung gedacht war) sondern and WPF

Genau das kam mir auch als erstes in den Kopf. Nur wirkt da das Lizenzmodel von Microsoft etwas sperrig.

[mkinzler]

Borland hat ja schon länger angekündigt VCL.Net auf WPF aufzusetzen, bisher ist halt noch nichts davon zu sehen und auch in der RoadMap nichts ersichtlich.

[sakura]

Zitat:

Zitat von mkinzler

Borland hat ja schon länger angekündigt VCL.Net auf WPF aufzusetzen, bisher ist halt noch nichts davon zu sehen und auch in der RoadMap nichts ersichtlich.

Falsch, man hat gesagt, dass man der Möglichkeit nachgeht und über die Umsetzung nachdenkt. Ob es passiert steht leider auf einem anderen Blatt und nach der Ansage von Nick auf der EKON sieht es eher mau aus ;(

...:cat:...

[mkinzler]

Hat sich CodeGear schon mit ihrem Ende abgefunden oder hat Nick einen anderen Grund dafür genannt?

[Phoenix]

Er ist der Meinung, die VCL.NET sei, so wie ist, eine 'superior solution' gegenüber Windows Forms.

Und dann ein technisches Detail: WPF wird ohne Partial Classes nicht funktionieren können. Zu meiner Frage nach Partial Classes hatte Nick gemeint, eine saubere Klassenhierarchie sei besser.

Ich persönlich habe aus diesem Grunde Delphi für .NET abgeschrieben. Im nativen Bereich gibts nix besseres, das ist ganz klar, aber was die managed Welt angeht werde ich nicht auf eine Firma setzen, die ihre Kunden in dieser Hinsicht bereits mehr als einmal schwer enttäuscht hat und auch keine Anstalten macht, das Vertrauen wieder aufzubauen.

[Elvis]

Zitat:

Zitat von Phoenix

:love:

*hust*

[Bernhard Geyer]

Zitat:

Zitat von Phoenix

Und dann ein technisches Detail: WPF wird ohne Partial Classes nicht funktionieren können. Zu meiner Frage nach Partial Classes hatte Nick gemeint, eine saubere Klassenhierarchie sei besser.

Für "normale" Klasse geb ich ihm recht, aber für Klassen wo Wizards mit "reinspucken" ist Partial Classes besser, da man dem Wizard nicht mehr so einfach in die Suppe spuckt, da er seine eigene Unit hat.

Zitat:

Zitat von Phoenix

Ich persönlich habe aus diesem Grunde Delphi für .NET abgeschrieben. Im nativen Bereich gibts nix besseres, das ist ganz klar, aber was die managed Welt angeht werde ich nicht auf eine Firma setzen, die ihre Kunden in dieser Hinsicht bereits mehr als einmal schwer enttäuscht hat und auch keine Anstalten macht, das Vertrauen wieder aufzubauen.

Stimmt. Unsere (wenigen) Teile in .NET sind mit SharpDevelop entwickelt.

[Phoenix]

Du glaubst auch alles was bekennende MS-Hasser schreiben, oder?

Mono ist in keinster Weise gefährdet, weil es durch das Microsoft-Novell Patentabkommen mit geschützt ist.

Und wäre dem nicht so: Das Mono-Team kann durch sein SVN-Log nachweisen, wann welcher Code von wem in die Runtime geflossen ist. Eine Kopie könnte es frühstens dann sein, wenn solcher Code von einem Entwickler nach dessen Unterzeichnung der Lizenz eingecheckt wurde, und dieser dann auch tatsächlich mit dem Originalcode nahezu identisch ist. Und ganz ehrlich: Wenn ein Entwickler wirklich so blöd ist und sowas macht, dann ist er selber schuld.

[Elvis]

Zitat:

Zitat von Phoenix

Du glaubst auch alles was bekennende MS-Hasser schreiben, oder?

Mir ist das absolut, komplett Bohne. Ich habe kein Problem it Leuten, die eher abneigend gegenüber amerik. Corps. oder AGs sind. Es sind diejenigen, die sich verpflichtet fühlen solche Entitäten zu verteidigen, die mir Angst machen. Eine Corp wie MSFT hat per Definition kein Konzept von Ethik und Moral, sondern nur das was heute und jetzt für die Corporate Identity und Verkäufe wichtig ist.
Das gilt genauso für Apple, siehe iPhone, oder T-Com, siehe Rechungsbetrug,...
Ist also kein reines MS-Bashing (wie bekloppt dieser Begriff an sich auch immer sein mag).

Zitat:

Mono ist in keinster Weise gefährdet, weil es durch das Microsoft-Novell Patentabkommen mit geschützt ist.

Was aber eine ziemliche einseitige Sache ist, und mögliche Änderungen von mir, in meinen Apps nicht mitschützen würde.

Zitat:

Zitat von Phoenix

Und ganz ehrlich: Wenn ein Entwickler wirklich so blöd ist und sowas macht, dann ist er selber schuld.

Egon lädt die CLR sources und akzeptiert die Bedingungen.
1 Woche später setzt sich Egon wieder an die Mono sources und schreibt ein paar kleinere Methoden (< 20 Zeilen).
Dadurch dass sowohl MS.Net als auch Mono das gleiche öffentliche Interface haben, sind ähnliche oder identische Implementierungen alles andere als unwahrscheinlich.
Und in diesem Falle hätte MSFT einen Fall von dem SCO nur hätte träumen können, Mono wäre gehörig gefickt.
Mit Mono wäre auch de Icaza gefickt, der mal so nebenbei Leites des einzigen wirklich freien und brauchbaren Desktops (GNOME) ist.

[Phoenix]

Wie gesagt: der von Dir beschriebene Fall ist durch das Patentabkommen abgesichert.
Zudem wäre in dem von Dir inszenierten Szenario dann wohl eher Egon der gefickte. Er ist derjenige, der gegen die Lizenzbestimmungen verstossen hat und er ist auch derjenige, der dafür geradestehen muss.
Im übrigen hat Microsoft gar kein Interesse sowas zu machen. Es sitzen im Mono-Core Team nicht nur Novell-Leute, sondern auch zwei die ihren Hauptarbeitsplatz in einem etwas größeren Firmencampus in der Nähe von Seattle haben. Wieso sollte eine Firma die ein Projekt aktiv unterstützt es hintenrum abschiessen wollen? Das macht mal so gar keinen Sinn.

[Daniel]

string_replace( 'gef***', 'gekniffen' ); ...


Achtet bitte ein wenig auf die Wortwahl.

[Bernhard Geyer]

Zitat:

Zitat von Phoenix

Wie gesagt: der von Dir beschriebene Fall ist durch das Patentabkommen abgesichert.
Zudem wäre in dem von Dir inszenierten Szenario dann wohl eher Egon der gefickte. Er ist derjenige, der gegen die Lizenzbestimmungen verstossen hat und er ist auch derjenige, der dafür geradestehen muss.

Egon hat sowas gemacht und 5 Jahre später fällt sowas auf und Egon ist in Rente aber der entsprechende Code ist so zentral das man 2 Monate zum Umbau benötigt? Wird Egon per Zivilgericht verklagt?

Zitat:

Zitat von Phoenix

Im übrigen hat Microsoft gar kein Interesse sowas zu machen. Es sitzen im Mono-Core Team nicht nur Novell-Leute, sondern auch zwei die ihren Hauptarbeitsplatz in einem etwas größeren Firmencampus in der Nähe von Seattle haben. Wieso sollte eine Firma die ein Projekt aktiv unterstützt es hintenrum abschiessen wollen? Das macht mal so gar keinen Sinn.

Es gab genügend Beispiele über geänderte Firmenpolitik über die Jahr. War Windows bzw. Windows CE nicht mal auf mehreren Plattformen lauffähig? Wieviel Patente sind auf .NET-Teilbereiche vorhanden?
Ich erinnere mich noch an eine EKON-Gespräch mit einem Vortrager der über entsprechende persönliche Erfahrungen mit MS-Praktiken hatte. Kooperationen werden nur solange gefahren bis man genügend (Monopol-)Macht besitzt. Wer sagt denn das in 5 Jahren bei genügend .NET-Macht MS alle Mitarbeiter abzieht und sein volles Patentportfolio auffährt?

[mkinzler]

Momentan profitieren beide Seiten durch den Deal. Sollte das mal anders sein, hätte Microsoft alle Karten in der Hand.

[Elvis]

Zitat:

Zitat von mkinzler

Momentan profitieren beide Seiten durch den Deal. Sollte das mal anders sein, hätte Microsoft alle Karten in der Hand.

Ganz genau, keine rosige Aussicht, IMO.
Ganz besonders wenn man selbst nicht durch den Deal von Novell <-> MSFT abgesichert wäre...