Unter Windows werden die meisten Systemrelevanten DLLs auch in ihrer alten Majorversionsausführung in Windows mitgeliefert, was auch der Hauptgrund dafür ist, dass jedes Windows fetter ist als der Vorgänger. Fehlende libs und Runtimeumgebungen können nachinstalliert werden. Ich hatte jedenfalls noch nie ein Problem wegen Executables die zu alte DLLs verlangen.
Ich hatte jedenfalls noch nie ein Problem wegen Executables die zu alte DLLs verlangen.
Ist das so? Gerade bei alten Video-Spielen gibt es gerade deshalb Patches, um diese überhaupt wieder lauffähig zu machen.
Sowas kommt mir auch außerhalb von Videospielen ab und zu mal unter die Linse. Nur, weil dir es nicht passiert, heißt es nicht, dass es das Problem nicht gibt.
Und übrigens: ältere Major-Versioinen von Bibliotheken lassen sich auch unter GNU/Linux parallel betreiben, jetzt kein Alleinstellungsmerkmal oder Vorteil von Windows.
Ist das so? Gerade bei alten Video-Spielen gibt es gerade deshalb Patches, um diese überhaupt wieder lauffähig zu machen.
Die Frage hier ist dann aber eher, was genau gepatched wird. Ein Patch, damit das Spiel anstatt auf DLL XY Version 1.0 auch auf DLL XY Version 1.1 läuft ist das eher nicht, denn DLL XY Version 1.1 ist abwärtskompatibel zu DLL XY Version 1.0. Und die neue Windows Version schleppt die dann mit, auch wenn diese selbst schon längst bei DLL XY Version 3.0 ist
Sowas kommt mir auch außerhalb von Videospielen ab und zu mal unter die Linse. Nur, weil dir es nicht passiert, heißt es nicht, dass es das Problem nicht gibt.
Wie schon gesagt, es kommt darauf an, was da genau gepatched wurde. Ich hatte mal ein Spiel, das W2K ready gemacht werden musste. Mit der DLL Version hatte das nichts zu tun.
Ein anderes Spiel funktionierte nicht mit MutliCore CPUs zufriedenstellend und musste deswegen gepatched werden. Auch das hatte nichts mit der DLL Version zu tun.
Und übrigens: ältere Major-Versioinen von Bibliotheken lassen sich auch unter GNU/Linux parallel betreiben, jetzt kein Alleinstellungsmerkmal oder Vorteil von Windows.
Ich habe nicht behauptet, dass es ein Alleinstellungsmerkmal von Windows wäre. Natürlich kann man das auch unter Linux machen, aber üblich ist das oft nur dann, wenn es noch viele aktiv benutzte Open Source Software Produkte gibt, die nach einer alten Majorversion einer Lib verlangen. Sobald die meisten und wichtigsten aber auf die neue Majorversion umgestellt wurden, wird der Support fallen gelassen und die alte Lib aus dem Repo entfernt.
Der User kann sie dann nur noch selbst compilieren und installieren oder sie sich über dubiose Drittrepos besorgen.
qt < = 2.x findet sich bspw. nicht mehr in Debian stable. Gleiches gilt für gtk < 2. Du findest in Windows aber noch sehr wohl DLLs, die man verwendete, als die Entwickler noch mit Visual Studio 6.0 ihr Projekt compiliert haben.
qt < = 2.x findet sich bspw. nicht mehr in Debian stable. Gleiches gilt für gtk < 2. Du findest in Windows aber noch sehr wohl DLLs, die man verwendete, als die Entwickler noch mit Visual Studio 6.0 ihr Projekt compiliert haben.
Und? Ist das so ein großes Problem? Nimm doch die aus einem älteren Repo oder von einem älteren Installationsmedium.
Wenn du eine alte Software hast, die unbedingt auf dem neueren Rechner laufen muss, dann kann das mit ein bisschen Aufwand verbunden sein um die richtige Umgebung bereitzustellen, aber das ist unter Windows nicht anders. Wenn jemand ältere Software vertreiben will, dann steht es ihm dank GPL zudem auch frei die entsprechenden Bibliotheken gleich mitzuliefern, statisch zu linken o.ä.
Ich persönlich finde es gut, dass man alten Schrott nicht mehr mit sich rum schleppt, insbesondere, wenn das nicht mehr aktualisiert wird (was sicherlich auch in Windows nicht der Fall ist). So werden Nutzer nicht dazu verleitet irgendwelchen alten Schrott zu installieren der voll mit bekannten Sicherheitslücken ist. Wozu brauchst du Qt 2.x? Nur um mal für 5min anzuschauen wie toll oder hässlich KDE2 war? Vermutlich irgendwie sowas.
oh und btw, es gibt VM und darin kann man auch alte Distributionen laufen lassen. Ist nicht wirklich ein großer Aufwand und (genauso wie für ältere Windows Versionen und Software) in den meisten Fällen auch die bessere Variante als zu versuchen es direkt auszuführen.
Bei Closed Source Programmen, bei der du nur Binaries hast, ja. Die brauchen nämlich die alten Libs und du kannst sie auch nicht an die neuen anpassen.
Wenn du eine alte Software hast, die unbedingt auf dem neueren Rechner laufen muss, dann kann das mit ein bisschen Aufwand verbunden sein um die richtige Umgebung bereitzustellen, aber das ist unter Windows nicht anders.
Doch. Bei Windows ist es meist die Regel, dass entweder die Software seine eigenen DLLs mitführt, womit es hier diesbezüglich schon einmal keine Probleme gibt oder Windows führt die alten DLLs mit.
Ich persönlich finde es gut, dass man alten Schrott nicht mehr mit sich rum schleppt, insbesondere, wenn das nicht mehr aktualisiert wird (was sicherlich auch in Windows nicht der Fall ist).
Ich bevorzuge es Software, für die ich viel Geld bezahlt habe, auch noch nach vielen Jahren benutzen zu können. Mit Windows geht das in den meisten Fällen problemlos, solange kein Kopierschutz mit eigenen Treibern dazwischen funkt.
So werden Nutzer nicht dazu verleitet irgendwelchen alten Schrott zu installieren der voll mit bekannten Sicherheitslücken ist.
Sicherheitslücken sind natürlich überall ein Problem, aber Nutzer werden alte Software für die sie Geld ausgegeben haben, trotzdem weiternutzen wollen. Für die Sicherheit muss man die dann eben vom Netz abschotten, dann geht das auch.
Wozu brauchst du Qt 2.x? Nur um mal für 5min anzuschauen wie toll oder hässlich KDE2 war? Vermutlich irgendwie sowas.
Es gibt ja immerhin schon einmal diese eine 2d CAD Software, die es auch als closed Source Version gibt. Ich habe die zwar nicht, aber die wäre so ein Kandidat, die früher Qt 2.x benutzt hat und jemand der so eine alte Version hat, der wird somit Qt 2.x benötigen.
Bei Closed Source Programmen, bei der du nur Binaries hast, ja. Die brauchen nämlich die alten Libs und du kannst sie auch nicht an die neuen anpassen.
Dann installier halt die alten Libs. Sind frei verfügbar. Gerade Debian hat hier noch ein recht großes Archiv und bei Debian kann man ja jetzt nicht unbedingt von "dubiosen" Quellen sprechen, oder? ;) http://archive.debian.org/
Ich bevorzuge es Software, für die ich viel Geld bezahlt habe, auch noch nach vielen Jahren benutzen zu können. Mit Windows geht das in den meisten Fällen problemlos, solange kein Kopierschutz mit eigenen Treibern dazwischen funkt.
Tja, da habe ich andere Erfahrungen gemacht, nicht nur wegen Kopierschutz, sondern weil einfach Windows halt doch nicht wirklich rückwärtskompatibel ist. Aber zum Glück ist das in der heutigen Zeit eh kein großes Problem mehr, dank VM. Genau aus dem Grund habe ich auch noch Windows XP in einer VM installiert.
Gerade bei Spielen habe ich aber auch so manches Spiel erneut gekauft, da die Versionen auf gog oder Steam manchmal dann doch noch einige Fixes mitbringen, die ansonsten nicht veröffentlicht wurden. (z.B. für Widescreen oder eben neuere Versionen, vom entfernten Starforce/Securom und ähnlichem Mist ganz zu schweigen)
Ganz abgesehen davon gibt es für das von dir genannte Szenario auch schlicht keine wirkliche Grundlage. Die Software wird nämlich in allen Fällen für ein bestimmtes Betriebssystem verkauft, d.h. da steht dann drauf, dass sie für Windows 98/ME/XP oder was auch immer ist. Das ist auch unter Linux so. Alles andere darüber hinaus kann man mehr oder weniger als Glück verbuchen, kann laufen, kann aber auch schief gehen. Beides oft genug erlebt.
Es gibt ja immerhin schon einmal diese eine 2d CAD Software, die es auch als closed Source Version gibt. Ich habe die zwar nicht, aber die wäre so ein Kandidat, die früher Qt 2.x benutzt hat und jemand der so eine alte Version hat, der wird somit Qt 2.x benötigen.
Nun, gibt doch 2 praktikable Lösungen: 1. Entsprechende Distribution in einer VM installieren (dürfte die einfachste Variante sein) 2. Libraries aus Debian 2(?) auf neueres System migrieren, sollte dann auch laufen.
Ich sehe da einfach nicht das große Problem, sorry. Und vor allem sehe ich nach wie vor nicht ein, dass für solche Corner Cases dann Menschen völlig unnötig ihre Zeit verschwenden sollen um die alten Pakete zu maintainen. Insbesondere, da diese das ja oft in ihrer Freizeit machen.
Wenns nur an der CPU liegen würde, wie wäre es da möglich das gleiche 16bit Programm unter wine laufen zu lassen? Nota bene ebenfalls auf einem 64bit Kernel?
One thing to note about ReactOS' NTVDM is that unlike Windows' version ReactOS' does not set the CPU into a 16bit emulated mode. This mode in theory reduces overhead compared to the emulation done by ReactOS, but CPUs these days are fast enough that performance should not be an issue. An advantage of ReactOS' approach though is that our NTVDM is usable on 64bit x86 processors and potentially ARM processors as well.
https://reactos.org/node/794
Es wird also, wie ich sagte, die Hardware für 16 Bit Programme emuliert, anstatt die echte Hardware in den Compatibility Mode zu schalten. Das erklärt dann auch, warum 16 Bit Realmode Programme, die für die x86 Architektur geschrieben wurden unter ReactOS auch auf ARM Prozessoren laufen sollen, gesetzt den Fall, man würde ReactOS nach ARM portieren.
Noch etwas. Ja, man darf sich natürlich fragen, warum Microsoft das nicht aus so macht.
Dazu gibt es drei mögliche Antworten, die alle gültig sein können: 1. Die ntvdm von Windows ist historisch gewachsen und das Problem mit Real-Mode Programmen gab es zu Zeiten von 32 Bit Windows Versionen und 32 Bit CPUs noch gar nicht. Die 16 Real Mode Programme liefen also auch so.
2. Die Emulation in Software kostet mehr Leistung. Das erklärt den historischen Schritt von früher, heute könnte man es auch anders machen, wenn da nicht der dritte Punkt wäre.
3. Die ISA der x86 Architektur gehört Intel. Würde Microsoft diese in Software emulieren, dann wären Lizenzkosten denkbar.
Siehe oben, das liegt an x64, nicht an Windows.
Unter Windows werden die meisten Systemrelevanten DLLs auch in ihrer alten Majorversionsausführung in Windows mitgeliefert, was auch der Hauptgrund dafür ist, dass jedes Windows fetter ist als der Vorgänger.
Fehlende libs und Runtimeumgebungen können nachinstalliert werden.
Ich hatte jedenfalls noch nie ein Problem wegen Executables die zu alte DLLs verlangen.
Ist das so? Gerade bei alten Video-Spielen gibt es gerade deshalb Patches, um diese überhaupt wieder lauffähig zu machen.
Sowas kommt mir auch außerhalb von Videospielen ab und zu mal unter die Linse. Nur, weil dir es nicht passiert, heißt es nicht, dass es das Problem nicht gibt.
Und übrigens: ältere Major-Versioinen von Bibliotheken lassen sich auch unter GNU/Linux parallel betreiben, jetzt kein Alleinstellungsmerkmal oder Vorteil von Windows.
Ein Patch, damit das Spiel anstatt auf DLL XY Version 1.0 auch auf DLL XY Version 1.1 läuft ist das eher nicht, denn DLL XY Version 1.1 ist abwärtskompatibel zu DLL XY Version 1.0.
Und die neue Windows Version schleppt die dann mit, auch wenn diese selbst schon längst bei DLL XY Version 3.0 istWie schon gesagt, es kommt darauf an, was da genau gepatched wurde.
Ich hatte mal ein Spiel, das W2K ready gemacht werden musste. Mit der DLL Version hatte das nichts zu tun.
Ein anderes Spiel funktionierte nicht mit MutliCore CPUs zufriedenstellend und musste deswegen gepatched werden. Auch das hatte nichts mit der DLL Version zu tun.
Ich habe nicht behauptet, dass es ein Alleinstellungsmerkmal von Windows wäre.Natürlich kann man das auch unter Linux machen, aber üblich ist das oft nur dann, wenn es noch viele aktiv benutzte Open Source Software Produkte gibt, die nach einer alten Majorversion einer Lib verlangen.
Sobald die meisten und wichtigsten aber auf die neue Majorversion umgestellt wurden, wird der Support fallen gelassen und die alte Lib aus dem Repo entfernt.
Der User kann sie dann nur noch selbst compilieren und installieren oder sie sich über dubiose Drittrepos besorgen.
qt < = 2.x findet sich bspw. nicht mehr in Debian stable.
Gleiches gilt für gtk < 2.
Du findest in Windows aber noch sehr wohl DLLs, die man verwendete, als die Entwickler noch mit Visual Studio 6.0 ihr Projekt compiliert haben.
Nimm doch die aus einem älteren Repo oder von einem älteren Installationsmedium.
Wenn du eine alte Software hast, die unbedingt auf dem neueren Rechner laufen muss, dann kann das mit ein bisschen Aufwand verbunden sein um die richtige Umgebung bereitzustellen, aber das ist unter Windows nicht anders.
Wenn jemand ältere Software vertreiben will, dann steht es ihm dank GPL zudem auch frei die entsprechenden Bibliotheken gleich mitzuliefern, statisch zu linken o.ä.
Ich persönlich finde es gut, dass man alten Schrott nicht mehr mit sich rum schleppt, insbesondere, wenn das nicht mehr aktualisiert wird (was sicherlich auch in Windows nicht der Fall ist).
So werden Nutzer nicht dazu verleitet irgendwelchen alten Schrott zu installieren der voll mit bekannten Sicherheitslücken ist.
Wozu brauchst du Qt 2.x? Nur um mal für 5min anzuschauen wie toll oder hässlich KDE2 war? Vermutlich irgendwie sowas.
oh und btw, es gibt VM und darin kann man auch alte Distributionen laufen lassen. Ist nicht wirklich ein großer Aufwand und (genauso wie für ältere Windows Versionen und Software) in den meisten Fällen auch die bessere Variante als zu versuchen es direkt auszuführen.
Bei Closed Source Programmen, bei der du nur Binaries hast, ja.
Doch.Die brauchen nämlich die alten Libs und du kannst sie auch nicht an die neuen anpassen.
Bei Windows ist es meist die Regel, dass entweder die Software seine eigenen DLLs mitführt, womit es hier diesbezüglich schon einmal keine Probleme gibt oder Windows führt die alten DLLs mit.Ich bevorzuge es Software, für die ich viel Geld bezahlt habe, auch noch nach vielen Jahren benutzen zu können.
Mit Windows geht das in den meisten Fällen problemlos, solange kein Kopierschutz mit eigenen Treibern dazwischen funkt.Sicherheitslücken sind natürlich überall ein Problem, aber Nutzer werden alte Software für die sie Geld ausgegeben haben, trotzdem weiternutzen wollen.
Für die Sicherheit muss man die dann eben vom Netz abschotten, dann geht das auch.Es gibt ja immerhin schon einmal diese eine 2d CAD Software, die es auch als closed Source Version gibt.
Ich habe die zwar nicht, aber die wäre so ein Kandidat, die früher Qt 2.x benutzt hat und jemand der so eine alte Version hat, der wird somit Qt 2.x benötigen.
http://archive.debian.org/Tja, da habe ich andere Erfahrungen gemacht, nicht nur wegen Kopierschutz, sondern weil einfach Windows halt doch nicht wirklich rückwärtskompatibel ist.
Aber zum Glück ist das in der heutigen Zeit eh kein großes Problem mehr, dank VM.
Genau aus dem Grund habe ich auch noch Windows XP in einer VM installiert.
Gerade bei Spielen habe ich aber auch so manches Spiel erneut gekauft, da die Versionen auf gog oder Steam manchmal dann doch noch einige Fixes mitbringen, die ansonsten nicht veröffentlicht wurden. (z.B. für Widescreen oder eben neuere Versionen, vom entfernten Starforce/Securom und ähnlichem Mist ganz zu schweigen)
Ganz abgesehen davon gibt es für das von dir genannte Szenario auch schlicht keine wirkliche Grundlage.
Nun, gibt doch 2 praktikable Lösungen:Die Software wird nämlich in allen Fällen für ein bestimmtes Betriebssystem verkauft, d.h. da steht dann drauf, dass sie für Windows 98/ME/XP oder was auch immer ist.
Das ist auch unter Linux so.
Alles andere darüber hinaus kann man mehr oder weniger als Glück verbuchen, kann laufen, kann aber auch schief gehen. Beides oft genug erlebt.
1. Entsprechende Distribution in einer VM installieren (dürfte die einfachste Variante sein)
2. Libraries aus Debian 2(?) auf neueres System migrieren, sollte dann auch laufen.
Ich sehe da einfach nicht das große Problem, sorry.
Und vor allem sehe ich nach wie vor nicht ein, dass für solche Corner Cases dann Menschen völlig unnötig ihre Zeit verschwenden sollen um die alten Pakete zu maintainen.
Insbesondere, da diese das ja oft in ihrer Freizeit machen.
Wenns nur an der CPU liegen würde, wie wäre es da möglich das gleiche 16bit Programm unter wine laufen zu lassen? Nota bene ebenfalls auf einem 64bit Kernel?
In dem man die Hardware in Software emuliert und somit die Ausführung von Real-Mode Programmen ermöglicht.
Wenn ich mich nicht irre, dann macht ReactOS und Wine genau das.
Also bei 16 Bit Real-Mode Programmen. Also nicht generell.
Hier steht es:
https://reactos.org/node/794Es wird also, wie ich sagte, die Hardware für 16 Bit Programme emuliert, anstatt die echte Hardware in den Compatibility Mode zu schalten.
Das erklärt dann auch, warum 16 Bit Realmode Programme, die für die x86 Architektur geschrieben wurden unter ReactOS auch auf ARM Prozessoren laufen sollen, gesetzt den Fall, man würde ReactOS nach ARM portieren.
Noch etwas.
Ja, man darf sich natürlich fragen, warum Microsoft das nicht aus so macht.
Dazu gibt es drei mögliche Antworten, die alle gültig sein können:
1. Die ntvdm von Windows ist historisch gewachsen und das Problem mit Real-Mode Programmen gab es zu Zeiten von 32 Bit Windows Versionen und 32 Bit CPUs noch gar nicht. Die 16 Real Mode Programme liefen also auch so.
2. Die Emulation in Software kostet mehr Leistung. Das erklärt den historischen Schritt von früher, heute könnte man es auch anders machen, wenn da nicht der dritte Punkt wäre.
3. Die ISA der x86 Architektur gehört Intel. Würde Microsoft diese in Software emulieren, dann wären Lizenzkosten denkbar.