Warum sind viele DLLs, die Windows zur Verfügung stellt, Bibliotheken, die nur von C / C++ gelesen werden können?
Ich probiere gerade alles mit statischen / dynamischen Bibliotheken zu verstehen (wir haben das in der Vorlesung nur kurz überflogen) und frage mich jetzt, warum die DLL-Dateien, die man auf Windows findet, überwiegend für C / C++ geschrieben sind.
Den Sinn hinter DLLs habe ich kapiert. Das sind im Prinzip Programmteile, auf die viele verschiedene Programme zugreifen können. Anstatt dass jedes Programm immer wieder seine Bibliotheken selbst mitbringt und dann lädt, kann man darüber eine Bibliothek von Windows aus laden und im Programm strenggenommen nur einen Pointer verwenden, um auf Funktionen der Fall zuzugreifen. Das spart dann eine Menge Speicherplatz.
Jedoch verstehe ich nicht so ganz, warum all diese Bibliotheken C- / C++-DLLs sind, die also ohne weiteres nur von diesen zwei Sprachen benutzt werden können. Ich habe jetzt schon viel gelesen, wo Leute z.B. in Java oder Python einige Windows-Bibliotheken (wie z.B. zipfldr.dll, was die Anweisung enthält, wie man in ZIP-Pakete, ohne sie zu entpacken, hineinschauen kann) nutzen wollten und das aber nur über Umwege funktioniert hat (wo im Übrigen auch C- / C++-Code benutzt werden musste).
Warum ist das so?
Ist das nicht ziemlich unpraktisch? Ich meine, dann müssten doch quasi alle Programme, die nicht in C oder C++ geschrieben wurden, entweder immer ihre eigenen DLLs beim Download mitbringen, was sehr speicherintensiv wäre oder man müsste, wenn man eine Windows-DLL z.B. in Java nutzen möchte, für jede Funktion, die man aus dieser nutzen wollte, sich in C eine Konvertierungsmöglichkeit zusammenbasteln. Und C / C++ wird zwar für viel Anwendungsprogrammierung verwendet, aber andere Sprachen sind doch weiter verbreitet, oder?
Ich hätte nur ein paar Ideen, warum das so ist:
- Windows wurde selbst zu großen Teilen in C(++) programmiert und bringt die DLL-Dateien nur mit, weil es die selber braucht.
- C(++) ist die bekanntere Sprache, die sehr hardwarenah noch vor Assembler funktioniert.
- C(++) wird mit Abstand am meisten für Anwendungsprogrammierung verwendet und die meisten Programme die man installiert sind somit in C(++) erstellt worden. Python z.B. nutzt man ja eher für Dinge wie KI oder Data Science, weil Python nicht so schnell ist.
Aber was ist der richtige Grund? Und gäbe es nicht eine Möglichkeit, dass alle Programme irgendwie auf die System-DLLs von Windows zugreifen könnten?
3 Antworten
Das "DLL" ist nur ein Name, es hat nichts damit zu tun, was die Datei ist und wie man sie benutzt.
Damit eine DLL aber auch als DLL genutzt werden kann, braucht man eine klare Struktur, wie ein anderes Programm (oder ein Compiler) findet, was daraus genutzt werden soll.
Und genau diese klare Struktur unterscheidet sich zwischen den Programmiersprachen. Wie es bei C++ aufgebaut ist, weiß ich nicht, aber bei C# bzw. .NET sind es sehr umfangreiche Metadaten, die der .NET-Runtime erlauben, alle Bestandteile zu suchen, zu prüfen und zu aufzurufen. Die DLLs bei C++ und .NET unterscheiden sich also grundlegend.
Die Antwort ist also ganz einfach: Weil sie mit C++ entwickelt wurden.
Möchte ich in C++ eine DLL entwickeln, die man normal in .NET nutzen kann, wäre das nur mit C++/CLI möglich, da das selber .NET nutzt und einen .NET-Compiler mit bringt, der die .NET-Datei (Assembly) mit den wichtigen Metadaten erstellen kann.
Und die Frage, warum so vieles in C/C++ entwickelt wurde:
- Windows ist alt, alles zu modernisieren, wäre viel zu viel Arbeit und viel zu gefährlich
- C++ ist eine Sprache, die sehr hardwarenahe Programmierung erlauben, Windows braucht das
- C++ bietet sehr umfangreiche Möglichkeiten, den Code bzw. die Performance zu optimieren
Außerdem will man C++ gar nicht ersetzen, auch nicht nur die DLLs. Weil das so grundlegend arbeitet und so alt aber immer noch weit verbreitet ist, bieten viele Programmiersprachen entsprechende Funktionen, um genau diese DLLs doch zu benutzen.
Also stimmt deine Annahme eigentlich nicht. Die meisten Programmiersprachen können C++-DLLs nicht als "normale" Referenz einbinden, aber sie können sie trotzdem nutzen.
Umgekehrt, wenn ich eine .NET-DLL hätte und müsste sie aus einem C++-Programm aufrufen - ja, dann hätte ich Spaß :D Da ist es leichter, in C# ein Programm zu entwickeln, das z.B. CLI-Funktionen anbietet, die man dann aus dem C++-Programm heraus aufrufen kann. So hat es ein ehemaliger Arbeitgeber von mir gemacht: Ein C++-Programm, das zig C#-Programme aufgerufen, riesige XML-Dateien rüber geschaufelt und das Ergebnis wieder in Form von XML entgegen genommen hat.
aus der Sicht vieler Linux Nutzer (inklusive mir) Windows so langsam ist.
Naja, der Unterschied der verwendeten Ressourcen ist schon bemerkbar...
Wer nie Linux verwendet hat, wird das auch wohl kaum bemerken
Von Grundgerüst ist Linux auch alt.
Linux basiert auf dem Linux Kernel von 1991...
Windows halt auf Windows NT von 1993
Bekommt beides laufend Updates.
Vom Alter her ist das ähnlich alt. Ist aber kein Problem, denn die Kernideen haben sich seit dem nicht geändert.
Es gibt neue Kernel, sie den Linux Zen Kernel.
Und zu dem aufeinander aufbauen, es gibt auch viele eigenständige Systeme. Void Linux und Gentoo beispielsweise.
Ich benutze auf meinem Laptop z.B. Manjaro, mit dem i3-gaps Window Manager(hatte Mal nen xfce Desktop, aber habe gewechselt), das basiert auf Arch.
Linux ist modular aufgebaut. Du hast einen fetten Kernel, dazu hast du dann deinen package Manager und nein Haufen packages. Diese packages kannst du auch belieben rausnehmen und reinbauen.
Wenn du Spaß dran hast kannst du Ubuntu nehmen, den xserver, den Desktop, alle tools usw. Alles deinstallieren bis nurnoch der Kernel da ist.
Windows 11 mag zwar irgendwie modern aussehen, ist vom Grundgerüst aber schon uralt. Wenn Microsoft ein Windows Update rausbringt dann wird auf Windows einfach was neues "obend drauf gesetzt".
Das ist immer so - außer die Entwickler wollen jede Bestandssoftware auf einen Schlag unbrauchbar machen.
Die Frage ist, ob das Alte weiter funktioniert, oder ob man Workarounds finden muss, oder es sogar überarbeiten muss und wie viel Arbeit das ist.
Ich bin kein Linux-Experte, aber meine laienhafte Vermutung ist ganz simpel: Geld
Hinter Windows steht ein riesiger Konzern und die Entwicklung hinter Windows ist teuer, verdammt teuer. Gleichzeitig wirft Windows aber kaum Geld ab und abschaffen können sie es auch nicht (bei der Marktmacht könnte sich der Führungskreis direkt erhängen), es bleibt also nur: Zeit sparen und irgendwie alle möglichen Gewinne raus holen, die gehen.
Bei Linux arbeiten auch viele privat mit und ich könnte mir vorstellen, dass hier mehr der Erfinder-Geist und der Spaß am Entwickeln von etwas Neuem antreibt, nicht das Geld. Die Leute, die daran arbeiten, machen das also, weil sie Spaß daran haben und investieren dann auch die Zeit, die sie privat vertreten können.
Und das heißt: Bei Linux ist immer wieder genug Zeit, auch mal zu refaktorisieren. Jede Software (egal wie groß) sollte permanent refaktorisiert werden, so hält man die entstehenden Kosten klein und für die Zukunft wartbar.
Wenn man sich das bei Windows auch nur einmal gespart hat (bedenke: Konzern, Geld - ich hab noch unter keinem Chef gearbeitet, der das freiwillig bezahlt hätte), kann das langfristig Auswirkungen haben, die später auf die Füße fallen und noch mehr Zeit kosten.
So stauen sich die die "Schulden" (technical debt) auf und werden mit der Zeit unbeherrschbar. So geht es vielen Programmen, egal welche Größe und es endet zwangsläufig immer in einem sehr langwierigen und noch sehr viel teureren Refactoring oder einem kompletten Rewrite - beides aus mehreren Gründen sehr grausige Optionen.
Du merkst, worauf ich hinaus will? ;)
Ob das bei Windows der Fall ist, weiß ich nicht, ich gehe stark davon aus, dass einfach gespart wird und solange die breite Masse der Nutzer (DAUs, Privatnutzer, etc.) glücklich ist, reicht das.
Und es gibt noch einen Punkt:
Am Windows arbeiten DAUs, am Linux kaum und die DAUs, die es gibt, verzweifeln meist recht schnell ^^
Windows muss also immer mit dem Nutzer "mitdenken", das macht Linux auch, aber Windows eben mehr und mehr Funktionen sind durch bunte UI verfügbar. Das ist übrigens auch ein Punkt, warum ich Linux für eine Privatperson nicht als "sicherer" bezeichnen würde - ist es nur, wenn man es richtig nutzt, aber dann bekommt man auch Windows sicher.
Und 2. Was passiert dann wenn x86 2026/2027 begraben wird... Klar Windows läuft strenggenommen schon auf Arm, aber in so einem Fall wäre es doch absolut albern den ganzen alten Code von Windows noch irgendwie auf eine neue Architektur zu übertragen... Oder etwa doch ?
*Wird* es begraben, oder *soll* es begraben werden? ;)
Windows muss es so lange mit schleppen, bis es gar nicht oder wenigstens kaum noch genutzt wird. Einfach alle x86-Software unbrauchbar zu machen, können sie sich nicht leisten.
Aber auch wenn sie es ewig mit schleppen, es macht Windows ja nicht langsamer - Speicherplatz alleine macht keinen Performance-Unterschied, außer der Datenträge ist bis auf das letzte Byte voll.
Aber Intel hat angekündigt ab 2027 keine x86 Chips mehr zu produzieren.
Was auf der einen Seite eigentlich gut ist, immerhin ist x86 noch veralteter als der Windows Kernel, und eigentlich überhaupt nicht mehr zeitgemäß, (riesen groß, ineffizient) ich frage ich mich schon was microsoft dann macht...
Intel will dann auf eine Risc-vi Architektur setzen, und AMD vielleicht auf ARM wie Apple, aber was apssiert dann mit Windows ? Ich keine Linux läuft schon seit Ewigkeiten auf Arm und Windows strenggenommen ja auch. Nur dann trotzdem noch die ganzen Altlasten aus dem Code mitnehmen ? Ich weiß ja nicht...
Und wenn dann jeder Hersteller auf eine andere Architektur setzt, müssen dann ae Programme immer für alle Architekturen geschrieben werden ?
Aber Intel hat angekündigt ab 2027 keine x86 Chips mehr zu produzieren.
Und? Deshalb werfen doch nicht plötzlich alle ihre alten PCs und Server weg.
Viele große Konzerne sitzen noch auf uralt-Hardware mit uralt-Software, vermutlich ist da selbst Windows XP noch "neu".
ich frage ich mich schon was microsoft dann macht.
Nichts - weiter x86 supporten, bis es keiner mehr nutzt, aber das wird dauern.
Das ist übrigens auch der riesige Vorteil von Apple: Sie haben volle Kontrolle über die Hardware. Windows und Linux müssen auf jeder Holzkiste laufen, entsprechend wird es immer Hardware geben, auf der es aus welchen Gründen auch immer nicht perfekt läuft.
müssen dann ae Programme immer für alle Architekturen geschrieben werden ?
Prinzipiell ja, aber weil da keiner Bock drauf hat, gibt's schon seit langem entsprechende Technologien, die das zentralisieren. Eine davon ist .NET z.B. mit C#, da kannst Du gegen eine bestimmte Architektur entwickeln, das macht man aber nur, wenn man Abhängigkeiten hat, die das erzwingen - z.B. eine native API für Maschinen. Meistens arbeitet man gegen "AnyCPU" und dann wird beim Start entschieden, mit welcher Architektur der Prozess läuft.
Da bist du auf einen Aprilscherz reingefallen. Intel wird auch nach 2027 noch x86 Chips produzieren.
Joa, dann wird Intel eben 2017 noch auf eine komplett veraltete Architektur setzen die aber so null konkurrenzfähig ist.
Die müssen schnell sein, Java und Python sind langsamer, die brauchen einen ganzen Interpreter der nebenbei läuft. C und c++ können nativ laufen.
Also, überwiegend Nummer 2 von dir.
Muss aber nicht c oder c++ sein. Kannst auch dlls in Rust schreiben oder so.
Korrigier mich wenn ich falsch liege, aber Rust ist eine Programmiersprache die ebenso wie c direkt in assembler / Maschinencode übersetzt wird und damit ohne irgendeinen Interpreter wie bei Java oder Python laufen kann ?
Kenne ich jetzt nicht so deswegen.
Das ist korrekt.
Performance ist grob ähnlich in rust und c.
Ein wichtiger unterschied ist dass rust automatisch thread safe ist. Du kannst also beliebigen code auf mehreren cpu threads laufen lassen ohne dir gedanken über semaphore oder was auch immer zu machen. Keine race conditions oder ähnliches.
Und auch generell mehr sicherheit, mehr code wird beim kompilieren überprüft. Du bekommst mehr fehler zur compilezeit und weniger zur laufzeit.
Außerdem, mit cargo ein ordentlichen build system.
All diese Gründe. Außerdem ist C/C++ eine der schnellsten Sprachen.
Aber schränkt dass den Sinn von den dlls nicht ziemlich ein ?
Wäre doch viel besser wenn Windows einfach einen Baukasten über dlls zur Verfügung stellen würde die alle nutzen können.
Oder ist das technisch nicht machbar ?
Ich glaube du verstehst nicht was libraries sind.
Das sind nur Sammlungen an Funktionen in einer Programmiersprache.
Logischerweise funktioniert ein Java Programm nicht mehr, wenn du einfach eine C Funktion einfügst.
Doch das ist mir schon klar... Danke für deine Antwort ! :)
Okay, erstmal vielen Dank für deine ausführliche Antwort ! <3
Ich muss sagen, den unteren Teil habe ich nicht zu 100 Prozent verstanden, das ist aber nicht schlimm, das was du mir erklären wolltest ist angekommen und ich habe das ganze verstanden.
Und ganz nebenbei hast du mir auch noch die Frage beantwortet warum aus der Sicht vieler Linux Nutzer (inklusive mir) Windows so langsam ist.
Windows 11 mag zwar irgendwie modern aussehen, ist vom Grundgerüst aber schon uralt. Wenn Microsoft ein Windows Update rausbringt dann wird auf Windows einfach was neues "obend drauf gesetzt". Deswegen schleppt Windows noch Teile und Anwendungen mit sich die über 20 Jahre alt sind und die heutzutage niemand mehr benutzt...
Wenn du das beantworten kannst habe ich dann aber noch w fragen, wie sieht das ganze bei Linux / Unix Systemen aus ? Ich meine, immerhin basieren fast alle von denen irgendwie auf Debian, und Linux Mint basiert ja zB auf Ubuntu. Haben die dann nicht das gleiche Problem dass einfach immer wieder neue Dinge oben draufgesetzt werden wie bei Windows ?
Und 2. Was passiert dann wenn x86 2026/2027 begraben wird... Klar Windows läuft strenggenommen schon auf Arm, aber in so einem Fall wäre es doch absolut albern den ganzen alten Code von Windows noch irgendwie auf eine neue Architektur zu übertragen... Oder etwa doch ?
Bin übrigens erst im 1. Semester, als nimm mir nicht übel dass vieles von dem was ich sage vielleicht ein wenig wie Halbwissen rüberkommt.