Historisch: Microsoft veröffentlicht Source-Codes

Ein Stück Computergeschichte steht ab sofort für jedermann zur Verfügung. Wie das Computer History Museum heute mitteilt, ist der MS-DOS-Source-Code mit der Erlaubnis von Microsoft ab sofort Teil des frei zugänglichen Archivs. mehr... Microsoft, Ibm, MS-DOS, MS-DOS 1.1 Bildquelle: Robert Scoble Microsoft, Ibm, MS-DOS, MS-DOS 1.1 Microsoft, Ibm, MS-DOS, MS-DOS 1.1 Robert Scoble

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Nee, echt, unglaublich - Muss gleich mal nachgucken, ob zwischenzeitlich die Hölle eingefroren ist ;-)
 
@beeelion: Die Hölle friert ein, wenn Apple wirklich iTunes für Android raushaut.
 
@notepad.exe: ...was dann nächstes Jahr wäre :D ach nee das war nen traum :P
 
@beeelion: ist doch bereits passiert:

http://www.dailymail.co.uk/news/article-2535709/Its-cold-HELL-frozen-Michigan-town-falls-victim-record-cold-temperatures.html
 
Finds interessant, aber Microsoft hatte schon zuvor Source Code veröffentlicht. Dennoch interessant mal zu sehen, womit man eigentlich damals Geld machen konnte. Heutige Programme sind da deutlich komplexer...
 
@Arhey: Stimmt, obwohl die Komplexität zu einem Teil heutzutage auch daran liegt, dass sich viele Entwickler keine Gedanken über einfache oder effiziente Implementierungen machen. Früher musste man möglichst effizient programmieren, weil die Ressourcen knapp waren, heute spielen die kaum noch eine Rolle, also achten viele nicht drauf. Und viele Programmierer vergessen immer öfter, dass man komplexe Systeme auch aus kleinen, recht einfachen Komponenten zusammenbauen kann. Stattdessen bauen sie von vornherein unübersichtliche und komplexe Monolithen.
 
@HeadCrash: bitte nicht komplex mit kompliziert verwechseln.. komplexheit kann man kaum entfernen.. das was man ändern kann, ist wie kompliziert etwas umgesetzt wurde
 
@vires: Na, über den Begriff als solches will ich mich nicht streiten. Mir geht es auch nicht darum, dass man nichts komplexes mehr erzeugt, triviale Dinge braucht man halt meistens nicht. Es ist aber eben sehr gut möglich, komplexe Gebilde aus einfachen Bausteinen aufzubauen. Das fängt schon bei der Strukturierung einer einzelnen Quellcodedatei an, bei der sich viele mehr als schwer tun, den Code in überschaubare Methoden zu zerteilen und endet bei guter Softwarearchitektur, mit gut strukturierten Klassen, Interfaces etc. Stattdessen sieht man immer noch "Überklassen", die alles mögliche tun und Spaghetti-Code-Methoden mit hunderten Zeilen Code. Ob man's nun komplex oder kompliziert nennt, schlecht ist es auf jeden Fall.
 
@HeadCrash: da gebe ich dir ja absolut recht :) wollt nur den richtigen begriff einwerfen, wenn man schon fachnahe schreibt.
 
@HeadCrash: was ist für die Effizenz? Ich kenn genug Entwickler die 2Std an einer Implementierung, die dann wirklich sehr gut ist, sitzen, die nachher einmalig 20 Minuten spart. Ist das dann Effizienz? Man sollte sich immer an Prinzipien wie KISS, DRY und Co (evtl CCD) halten...
 
@TurboV6: Effizienz gibt es in vielen Bereichen. Was Du beschreibst nenn ich Mikrooptimierungen, als sich bei jedem kleinen Teilalgorithmus mühselig Gedanken machen, wie man das letzte Bisschen Laufzeit oder sonst was rausholen kann. Das meinte ich aber nicht wirklich, denn der Nutzen ist meist gering und es ist besser - wie Du schon sagst - sich z.B. an KISS zu orientieren, eine möglichst einfache, aber dafür wartbare und lesbare Implementierung zu erstellen und danach z.B. an die Performance mit einem Profiler ranzugehen, um die dicken Fische zu optimieren. Ich meinte mehr, dass sich heute z.B. niemand mehr Gedanken über Datenstrukturen oder über das macht, was tatsächlich so in den ganzen Frameworks passiert. Wer weiß denn heute noch wirklich, was z.B. in .NET der Unterschied zwischen einem Dictionary, einem Array und einer List ist? Leider wissen das sehr, sehr viele Entwickler nicht. Und in Summe lassen sich mit recht einfachen Überlegungen hier sehr viele Ressourcen einsparen, die man dann tatsächlich am benötigten Arbeitsspeicher oder der Laufzeit merkt. Oder noch ein gutes Beispiel: Linq. Ich hab mich mal mit einem Programmierer unterhalten, der sich beschwert hat, dass Linq so lahm ist. Als wir uns dann seinen Linq Query angeschaut haben, musste ich ihm erst mal erklären, dass er mit dem einen Query kurzerhand mehrere hunderttausend Objekte erzeugt und wieder verworfen, zig Casts durchgeführt und auch sonst einfach einen Haufen Müll produziert hat, den er mit einer simplen ForEach-Schleife elegant umgangen hätte. Und die Ursache lag einfach darin, dass er tatsächlich keine wirkliche Ahnung von Linq hatte und so lange rumprobiert hat, bis der Ausdruck irgendwie kompiliert hat. Und meiner Erfahrung nach sind solche Entwickler keine Einzelfälle. Die meisten "Programmieren", indem sie ihre Google-Suchergebnisse zusammenkopieren. Und wenn der Compiler sagt, dass alles gut ist, ist man zufrieden, egal wie der Code aussieht. :-/
 
@HeadCrash: ich weiß das alles - ist mein Job.Aber ich kann Deine Meinung nicht teilen.
Muss der Entwickler den technischen Hintergrund wissen, was ein Dict und was eine List ist? Ich denke, das wissen die meisten auch ohne zu forschen; allein wegen dem KV-Prinzip.
Viel wichtiger finde ich feinheiten, wie den Unterschied eines HashSets und eine List, da das eklatante Verhaltensänderungen hervorrufen kann.
In einem ForEach steckt nichts anderes als ein for; das direkte Nutzen von for ist also schneller, da der Overhead von ForEach wegfällt (zB BinaryCaompatibility).
Linq nutzt man nicht, weil man schnelleren Code haben will, sondern weil die Wartung einfacher ist und der Code leichter lesbar. Dass also eine ForEach Eleganter sein soll ist - sorry - humbug ;-)
Ich bin sehr in der .NET Community aktiv - ich weiß wie der Hase läuft und 80% der Leute vorgehen ;-)
 
@TurboV6: Na, so hat jeder seine Meinung ;-) Ich bin Berater für Softwareentwicklung und seit etwa 20 Jahren Entwickler, also darf ich wohl auch behaupten zu wissen, wie der Hase läuft. Und ja, ein Entwickler sollte verstehen, wo der Unterschied zwischen einem Dictionary (Hashtable) und einer List (verkettete Liste) und einem Array (zusammenhängender Speicherbereich) ist, da alle unterschiedliches Verhalten, sowohl was Laufzeit als auch Speicher angeht, haben. ForEach enthält natürlich ein For, aber es verhält sich vollkommen anders. Ein For muss keineswegs schneller sein und es gibt Situationen, wo ein For tatsächlich gar nicht genutzt werden kann, z.B. wenn man auf einzelne Elemente einer Auflistung nicht per Index zugreifen kann. In diesem Fall kann man natürlich mit GetEnumerator und Enumerator.MoveNext selbst programmieren, aber ForEach ist da deutlich übersichtlicher. Ich weiß, warum man Linq verwendet, ich weiß aber auch, dass Linq sowohl gut als auch schlecht verwendet werden kann. Und im Falle dieses Programmiere wären zwei For(Each)-Schleifen (genau kann ich es Dir nicht mehr sagen) sowohl lesbarer gewesen als auch DEUTLICH schneller und mit weniger Speicher gelaufen.
 
@HeadCrash: List<T> ist keine verkettete Liste, sondern intern ein Array. Du verwechselst das mit einer LinkedList. Vielleicht solltest Du Dir das doch noch mal ansehen ;-) Auch verhält sich ein ForEach absolut identisch mit einem for; plus eben Overhead. Du verwechselst das mit einem foreach, das sich wirklich je nach Compiler anders verhalten kann (modify closure warning). Auch Deine Enumerator-Argumentation stimmt nicht, da überall IList<T> verwendet werden kann, der einen Indexer hat, was aber eine Materialisierung des Inhalts erfordert. Erst bei yield-Elementen wie Lazy Loading kommt der Enumerator an seine Daseinsberechtigung. Dass for weniger Speicher frist als Linq ist ein Märchen. Bisher konnte mir NIEMAND solch eine Behauptung beweisen. Ich gebe Dir hiermit die Möglichkeit - auch Deine falschen Aussagen von oben zu korrigieren ;-) Edit: alles mit IEnumerable kann über einen Index (ElementAt) aufgerufen werden.
 
@TurboV6: Nope, in .NET kann eben NICHT alles, was IEnumerable implementiert, mit einem Index aufgerufen werden. Das ist ein Märchen. Schau Dir das Interface doch an; solange Du nicht noch IList implementierst, ist kein Indexer vorgeschrieben. Die Extension Method ElementAt hat nix mit einem Indexer zu tun und ist deutlich ineffizienter als z.B. der direkte Zugriff auf ein Array-Element per Pointer-Arithmetik, da ElementAt bei reinen IEnumerables auf den Enumerator zurückfällt und x-mal GetNext aufruft. Und der Speicherbedarf, der durch einen ungeschickten Linq Query anfällt kann natürlich höher sein. Was gibt es da zu beweisen? Du brauchst nur mehrmals in Arrays zu konvertieren, dann wieder Listen draus zu machen etc. pp. und erzeugst hunderte von Elementen, die nachher wieder verworfen werden. Genau das hat besagter Programmierer gemacht und wir haben das Ding massiv beschleunigt, indem wir seinen Linq-Blödsinn aufgelöst haben. Mit der List<T> hast Du sogar recht, das hab ich tatsächlich falsch in Erinnerung gehabt, Asche auf mein Haupt. Dann ersetze List durch LinkedList, dann stimmt die Aussage wieder ;-) Und sorry für das ForEach, ich rede immer von C# und damit von foreach. Ein ForEach gibt es in C# nicht ;-)
 
@HeadCrash: doch gibt es. ForEach ist eine Linq-Erweiterung (im Sinne, dass es mit Linq mit kommt, aber eine Generics-Erweiterung ist). ForEach ist ein for, und foreach ein echtes foreach. Sicher, dass Du Software Berater bist......???
 
@TurboV6: Ach, Du meinst die Linq Extension Method. Ich rede doch hier von Schlüsselwörtern. Jetzt wirfst Du aber alles durcheinander. Es ging im Ursprung darum, dass der Linq-Ausdruck deutlich ineffizienter als eine einfache Schleife gewesen ist. Und ja, ich bin Berater, aber ich springe nicht wild durch die Themen ;-P Und unser kleiner Wettstreit ändert nichts daran, dass viele Entwickler heutzutage ihr Handwerk eigentlich nicht mehr richtig verstehen, sondern sich auf Google-Suchen und fertige Code-Snippets aus dem Netz verlassen. Das ist es, was ich bemängele und was ich zu Hauf in nahezu allen Unternehmen von der kleinen Klitsche bis hin zum großen Konzern sehe. Natürlich gibt es noch eine ganze Reihe wirklich sehr guter Entwickler, aber prozentual gesehen ist deren Anteil an der Gesamtzahl der Entwickler relativ gering und - in meinen Augen - auf dem absteigenden Ast.
 
@HeadCrash: wir sind in der Software Entwicklung. Wenn Du von ForEach sprichst und es diese Methode einfach gibt, dann geht der Leser davon aus, dass Du auch genau diese meinst.
foreach != ForEach - das solltest Du wissen.
Ich bin freiberuflicher Entwickler und Berater. Ich finde es gut, dass es so viele Entwickler gibt, die es nicht können. Die Firmen melden sich bei Problemen bei mir
und ich solls wieder gerade biegen. Da es meist dringend ist kann ich eben auch 30% mehr verlangen ;-)
Mir schadet dieser Ast also nicht - im Gegenteil :-)
 
@TurboV6: Ja, das mit dem ForEach tut mir auch leid. Das passiert, wenn man Winfuture-Kommentare schreibt, während man einen Build Automation Workshop leitet. :-/ Gerade der letzte Punkt ist natürlich wahr, daher dürfte ich mich auch nicht beschweren. Aber es kratzt schon so ein bisschen an unserem Berufsstand.
 
MS-DOS 1.1 und 2.0? Warum nicht MS-DOS 6.22?
 
@IchEuchNurÄrgernWill: Das ist noch zu neu.
 
@IchEuchNurÄrgernWill: ich würde sogar nach MS-DOS 8.0 .... nicht zu verwechseln mit Win8... Das waren noch Zeiten zu WinME
 
"Mehr zum Thema: DoS-Attacken" ??? Ist klar...
 
wäre gut wenn man heutzutage wieder effizienter programmieren würde. nur weil man mehr speicher hat heisst das nicht das man 100mb für ein siples tic tac toe verwenden muss.
 
@gast27: Definiere 'effizienter programmieren'! Meinst Du kleineren Programmcode? Weniger Speicherbedarf? Schnelleren Code? Oder vielleicht besser wartbaren Code? Ich würde für mich den letzten Punkt wählen, da das meiner Meinung nach das Entscheidende ist.
 
kann man eigentlich noch was sinnvolles damit anfangen oder ist das wirklich mehr nur noch zum Verständnis aufbauen?
 
@MarcelP: Ich denke mal, es wäre recht interessant zum anschauen und evtl. für 64bit kompilieren :D
 
Ich will ja nicht wieder Spielverderber sein, aber warum konnte man nicht die letzte Version des reinen DOS (6.22) als Source veröffentlichen? Ich glaube das würde Microsoft auch keinen Zacken aus der Krone brechen, selbst unter Berücksichtigung von FAT32, da das erst mit DOS 7.10 als Bestandteil von Windows 95B eingeführt wurde.
 
@Memfis: Kommt vielleicht noch in ein paar Jahren. Man sollte den Sinn dieser Veröffentlichung nicht aus dem Auge verlieren. Es geht um Archivierung und letztlich um ein digitales Museum. Da sind die ersten Versionen sicher die interessanten Ausstellungsstücke, auch wenn der praktische Nutzen der neueren Versionen sicher höher ist.
 
Es fehlt die Information ob der einsehbare Quellcode unter einer Opensource-Lizenz verfügbar ist. Offener Code heißt noch lange nicht, dass andere Projekt wie z.B. FreeDOS sich daran bedienen dürfen. Wäre interessant zu wissen.
 
Der alte Source-Code ist kein Schlüssel zu den primitiven Wurzeln, sondern zu besonders effizienter Programmierkunst!
Kommentar abgeben Netiquette beachten!

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles