Hallo, wie funktioniert die Paketverwaltung unter Windows und Mac OSX? Grundsätzlich haben beide Betriebssysteme ja keine Paketverwaltung an Bord, trotzdem kann man so gut wie alle Programme mit einem einzelnen Installer installieren. Wie handhaben diese Installer das also mit Abhängigkeiten, linken sie alle Bibliotheken statisch ein oder installieren sie diese separat? Wie funktioniert es unter Windows, dass über eine komplette Version hinweg Gerätetreiber kompatibel sind, statt wie bei zB Linux bei Kernelupdates neu gelinkt werden? Gibt es Gründe, warum manche Treiber im Linuxkernel, jedoch nicht bei Windows dabei sind? (zB USB-Seriell Wandler (FT232 etc)) Ich freue mich auf sachliche (nicht religiöse :)) Antworten
package maintainer schrieb: > trotzdem kann man so gut wie alle Programme mit einem einzelnen > Installer installieren. Ach kann man das? Würdest du uns den Installer auch nennen? Du wirst wohl eher einen Installer für MS-Programme meinen. package maintainer schrieb: > Wie funktioniert es unter Windows, dass über eine komplette Version > hinweg Gerätetreiber kompatibel sind, statt wie bei zB Linux bei > Kernelupdates neu gelinkt werden? Eine Windowsversion ist eine Windowsversion. Außer Sicherheitsupdates ändert sich am Kernel normal nicht mehr viel. Erst zur nächsten Version kommt wieder wirklich neues dazu. package maintainer schrieb: > Gibt es Gründe, warum manche Treiber im Linuxkernel, jedoch nicht bei > Windows dabei sind? (zB USB-Seriell Wandler (FT232 etc)) Die Treiber im Linux-Kernel sind oft selbst entwickelt und nicht vom Hersteller.
> Wie handhaben diese Installer das also mit Abhängigkeiten, linken sie > alle Bibliotheken statisch ein oder installieren sie diese separat? Jeder Installer installiert alle Bibliotheken mit, in der benötigten Version. Das Resultat ist dann, das häufig benutzte Bibliotheken zig mal vorhanden sind, wie libz, libpng, etc. Früher war das ja sogar mit DirectX so... Aber wen scherts, Festplatten sind billig. Und dass man nicht im Falle einer Sicherheitslücke die Bibliothek eben schnell auf eine neue gefixte Version updaten kann macht auch nichts, denn wofür gibt es Virenscanner? > Wie funktioniert es unter Windows, dass über eine komplette Version > hinweg Gerätetreiber kompatibel sind, statt wie bei zB Linux bei > Kernelupdates neu gelinkt werden? Ganz einfach: Bei Windows gibts keine Kernelupdates, also bleibt das API gleich... > Gibt es Gründe, warum manche Treiber im Linuxkernel, jedoch nicht bei > Windows dabei sind? (zB USB-Seriell Wandler (FT232 etc)) Vermutlich rechtliche Gründe, dass sie das nicht einfach einbauen können. Und dass Windows dann 100GByte groß sein würde, denn scheinbar muss ja heutzutage selbst ein Ethernet-Treiber 100MByte groß sein... > Ich freue mich auf sachliche (nicht religiöse :)) Antworten Bitte, völlig atheistisch ;-)
Der Weise schrieb: > Ganz einfach: Bei Windows gibts keine Kernelupdates, also bleibt das API > gleich... nein, der Kernel wird mit jeden SP und auch einigen Update erneuert. Aber MS hat sich vorher ein paar geanken zu den API gemacht, sie müssen nicht ständig die schnittstellen zum Kernel anpassen. Das hat bestimmt auch nachteile aber der grosse vorteil ist, das alle Treiber nach einem update auch noch gehen. Linux nimmt sich die freiheit bei jeder Kernel version an den Kernelschnittstellen rumzubasteln, weil sie auch alles Treiber selber pflegen. Jeder Entwickler der aber seine Treiber nicht als opensource veröffentlichen will oder kann hat das nachsehen.
Der Weise schrieb: > Das Resultat ist dann, das häufig benutzte Bibliotheken zig mal > vorhanden sind, wie libz, libpng, etc. Und was ist deine Alternative?
Der Weise schrieb: > Jeder Installer installiert alle Bibliotheken mit, in der benötigten > Version. Das Resultat ist dann, das häufig benutzte Bibliotheken zig mal > vorhanden sind, wie libz, libpng, etc. Früher war das ja sogar mit > DirectX so... das ist zwar oft so, liegt aber nicht an MS. Sie habe die möglichkeit für dlls die in System32 liegen einen zähler mitzuführen. Jedes Programm was die dll braucht macht +1 und bei deinstall wird wieder -1 gemacht, wenn er 0 ist dann fragt der Installer ob er die dll mit löschen soll.
Dann würden aber noch immer nicht mehrere DLLs rumliegen. Es geht wohl um verschiedene Versionen einer DLL. Und die müssen alle da sein. Gibt keine Alternative.
XTerminator schrieb: > Dann würden aber noch immer nicht mehrere DLLs rumliegen. Es geht wohl > um verschiedene Versionen einer DLL. Und die müssen alle da sein. kommt darauf an. Wenn es schnittstellen kompatibel ist dann sollte sie gleich heisen und muss nur einmal da sein. Wenn an der Schnittstelle etwas geändert wird, dann sollte es im namen erkennbar sein. Dann gibt es mehre davon. Beispiel: msvcrt80.dll msvcrt90.dll msvcrt100.dll wenn es nur ein sicherheitsupdate ist, wenn wir sie überschrieben.
Na also, nix einzusparen. Die Kompatibilität muß sich übrigens auf die ABI erstrecken, nicht nur die API. Klar hats Linux da leichter. Die Distribution baut halt alles neu gegen die neue Lib...
Peter II schrieb: > Der Weise schrieb: >> Jeder Installer installiert alle Bibliotheken mit, in der benötigten >> Version. Das Resultat ist dann, das häufig benutzte Bibliotheken zig mal >> vorhanden sind, wie libz, libpng, etc. Früher war das ja sogar mit >> DirectX so... > das ist zwar oft so, liegt aber nicht an MS. Sie habe die möglichkeit > für dlls die in System32 liegen einen zähler mitzuführen. Jedes Programm > was die dll braucht macht +1 und bei deinstall wird wieder -1 gemacht, > wenn er 0 ist dann fragt der Installer ob er die dll mit löschen soll. Funktioniert nur leider nicht, da jede Applikation eine andere Version braucht, die ggf. inkompatibel ist, daher wird fast immer im Programmordner installiert / statisch gelinkt. Dies funktioniert unter Linux auch nur weil die Abhängigkeiten in den Packages bekannt sind, bei Windows Paketen ist dies nicht bekannt. Mit einem Packagesystem ist es auch nicht möglich das man neue und veraltete Software verwendet wird, es wird entweder alles oder nichts upgedatet. Bei Windows muss ja jedes Programm manuell geupdatet werden, was somit ein ziemliches Versionschaos mit sich bringt. Mit Windows 8 wird ja ein Appstore kommen, mal schauen ob sich da etwas in diese Richtung tut, aber warscheinlich nicht... Peter II schrieb: > Der Weise schrieb: >> Ganz einfach: Bei Windows gibts keine Kernelupdates, also bleibt das API >> gleich... > nein, der Kernel wird mit jeden SP und auch einigen Update erneuert. > Aber MS hat sich vorher ein paar geanken zu den API gemacht, sie müssen > nicht ständig die schnittstellen zum Kernel anpassen. Das hat bestimmt > auch nachteile aber der grosse vorteil ist, das alle Treiber nach einem > update auch noch gehen. Linux nimmt sich die freiheit bei jeder Kernel > version an den Kernelschnittstellen rumzubasteln, weil sie auch alles > Treiber selber pflegen. Jeder Entwickler der aber seine Treiber nicht > als opensource veröffentlichen will oder kann hat das nachsehen. Naja, es wird nie etwas grosses nachgeliefert, wenn du etwas neues willst, also ein Mehrwert, musst du bei MS immer dafür zahlen. Trotzdem gibt es teilweise Änderungen bei SPs, was dann auch dazu führen kann das gewisse Treiber nicht mehr funktionieren. Da die wenigsten Treiber unter Windows Open Source sind ist man dann auf den Hersteller angewiesen. Ist die Supportzeit des Herstellers abgelaufen, kann man die Entsprechende Hardware nicht mehr unter einer aktuellen Windows Version verwenden. Bei Linux werden die Treiber einfach nachgezogen. package maintainer schrieb: > Gibt es Gründe, warum manche Treiber im Linuxkernel, jedoch nicht bei > Windows dabei sind? (zB USB-Seriell Wandler (FT232 etc)) Wer einen Open Source Treiber für Linux schreibt wird den entweder selbst dem Kernel hinzufügen, oder jemand anders wird das tun. Ich weiss nicht genau wie du einen Treiber in Windows kriegst, aber alleine für die Zertifizierung eines Treibers wird viel Geld verlangt. Zudem wird MS keine GPL Treiber in Windows aufnehmen. mfg Andreas
Andreas B. schrieb: > Funktioniert nur leider nicht, da jede Applikation eine andere Version > braucht, die ggf. inkompatibel ist, daher wird fast immer im > Programmordner installiert / statisch gelinkt. ebend nicht, wenn eine DLL gleich heist, sollte sie immer kompatibiebel sein, es dürfen also nur fehler entfernt werden. Wenn sie eine neue funktionen bekommt dann sollte sie einen neuen namen bekommen. Dann würde das ganze schon funktionieren. Leider macht es so gut wie niemand. Der installier kann dann sicherstellen das niemals eine älter datei eine neuere ersetzt. > Trotzdem gibt es teilweise Änderungen bei SPs, was dann auch dazu führen > kann das gewisse Treiber nicht mehr funktionieren. es gehen bloß die Treiber nicht mehr, die vorher zufällig funktioniert haben. Jeder Treiber der sich auch an das kleingedruckte von der doku gehalten hat wird nach einem update noch funktioneren.
Peter II schrieb: >> Trotzdem gibt es teilweise Änderungen bei SPs, was dann auch dazu führen >> kann das gewisse Treiber nicht mehr funktionieren. > es gehen bloß die Treiber nicht mehr, die vorher zufällig funktioniert > haben. Jeder Treiber der sich auch an das kleingedruckte von der doku > gehalten hat wird nach einem update noch funktioneren. Nur ein Beispiel: http://stackoverflow.com/questions/423391/windows-api-to-determine-service-pack-version Natürlich hast du theoretisch Recht. Jedoch ist auch nicht immer alles korrekt dokumentiert, geschweige denn wird die Doku immer zu 100% richtig interpretiert oder gelesen. mfg Andreas
package maintainer schrieb: > Wie handhaben diese Installer das also mit Abhängigkeiten, linken sie > alle Bibliotheken statisch ein oder installieren sie diese separat? Mac OS X: die meisten Bibliotheken sind Teil des Betriebssystems. Wenn ein Entwickler für seine Anwendung zusätzliche Bibliotheken benötigt, dann muss er sie im Installationspaket mitliefern und zur Aktualisierung ein neues Paket bereitstellen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.