Liebe ExpertInnen,
warum läuft alte Software (immer? manchmal?) nicht unter Windows 7? Vom Kompatibiltätsmodus habe ich schon gehört, angeblich soll der die Performance aber heftig ausbremsen.
Genau genommen interessiert mich die Überlegung, auf welchen Wegen alte Software so frisiert werden könnte, dass sie unter Windows 7 ohne K. liefe. Mir fehlt aber jegliche Vorstellung, was dazu nötig wäre - vom Austausch der DLLs bis hin zu einer echten Neuentwicklung. Wer weiß was?
Gruß Ralf
Hallo!
In den meisten Fällen war es bei älterer Software so, dass diese implizit davon ausgegangen ist, dass sie mit Administratorenrechten läuft und somit überall Zugriff hat.
Spätestens seit Vista ist es aber nicht mehr so üblich, immer mit Admin-Rechten zu arbeiten (Stichwort UAC) und da kommen die meisten Probleme her. Die Entwickler der Altanwendung haben vielleicht einfach nicht damit gerechnet, dass sie einen bestimmten Registrykey nicht schreiben dürfen oder eine benötigte Datei nicht anlegen dürfen.
Wenn man bei Win7 die UAC abschaltet (nicht empfohlen!) und mit einem administrativen Konto angemeldet ist (auch nicht empfohlen!), dann funktionieren die meisten Altanwendungen auch ohne Kompatibilitätsmodus.
Gruß,
Martin
Hallo,
warum läuft alte Software (immer? manchmal?) nicht unter
Windows 7?
Das hat sehr viele Gründe.
Die Sache mit den Zugriffsrechten ist davon nur eine
einzige, die aber noch am leichtesten zu lösen wäre.
Die Hauptursache ist aber, dass Funktionen des
Betriebssystems und der Hardware nicht mehr kompatibel
zu alten Ständen sind.
So wurde z.B. beim Übergang von DOS6.2 zu Windows95
diverse DOS-Funktionen über Board geworfen und die
alte Methode auf Hardwareresourcen direkt zuzugreifen
funktioniert unter Win dann auch nicht mehr.
Bei Übergang von XP zu Vista -> Win7 wurde auch
einiges an Windows geändert.
Vielfach ist es auch schlecht programmierte Software
oder einfach miese Compiler, die schon beim nächsten
Betriebssystem nicht mehr läuft.
Beispiel: /t/kann-ein-win95-programm-umgeschrieben-werden/6849057
MS selbst ist da ja führend in der Methode, den Nutzern
das Leben schwer zu machen mit inkompatibler Software.
Da reicht es manchmal schon, wenn in einem Windowsupdate
eine System-DLL ersetzt wird, dass danach bestimmte
Programme nicht mehr laufen.
Vom Kompatibiltätsmodus habe ich schon gehört,
angeblich soll der die Performance aber heftig ausbremsen.
Da gibt es ja diverse Kompatibilitätsmodi.
Was du meist, ist aber wohl eher die Methode alte
Software in einer VM laufen zu lassen.
http://de.wikipedia.org/wiki/Virtuelle_Maschine
Unter Win7 Prof. gibt es dazu einen XP-Mode, der das
im Prinzip so macht.
Das VM langsamer läuft, ist richtig, aber oft wird das
durch die heute viel schnellere Hardware sogar
überkompensiert.
Das löst aber auch nicht alle Probleme.
Manche Programme laufen einfach auch deshalb nicht mehr,
weil die Hardware sich geändert hat.
Wenn z.B. ein Programm mal eine „COM1“ erfordert hat,
dann bekommt man das mit virtuellen COM-Ports per USB
kaum zum laufen.
Genau genommen interessiert mich die Überlegung, auf welchen
Wegen alte Software so frisiert werden könnte, dass sie unter
Windows 7 ohne K. liefe.
Ohne konkret zu werden, ist das ein Ratespiel.
Mir fehlt aber jegliche Vorstellung,
was dazu nötig wäre - vom Austausch der DLLs bis hin zu einer
echten Neuentwicklung. Wer weiß was?
Viele ist möglich, von Patsches, Updates, Simulationen,
VM, Neu compilieren, Neuprogrammieren usw.
Ob es im speziellen Fall geht und Sinn macht,
weiß niemand ohne konkrete Infos.
Gruß Uwi
Moin, Martin,
Wenn man bei Win7 die UAC abschaltet (nicht empfohlen!) und
mit einem administrativen Konto angemeldet ist (auch nicht
empfohlen!), dann funktionieren die meisten Altanwendungen
auch ohne Kompatibilitätsmodus.
besternten Dank, damit lässt sich schon mal was anfangen.
Meine Anfrage war wohl nicht genau genug, mir ging es tatsächlich um die Programmierung: Muss / kann ich meinen Quellcode dergestalt ändern, dass ein Einsatz unter Win 7 ohne Hakeln möglich ist? Wenn die UAC der einzige Unterschied wäre, ließen sich Performance-Einbußen kaum erklären. Muss allerdings dazusagen, dass ich da nur Gerüchte kenne.
Gruß Ralf
Hallo Ralf,
Meine Anfrage war wohl nicht genau genug, mir ging es
tatsächlich um die Programmierung: Muss / kann ich meinen
Quellcode dergestalt ändern, dass ein Einsatz unter Win 7 ohne
Hakeln möglich ist?
Ds wirst du wohl machen müssen.
Jetzt weiss hier abr keiner, was du für Sftwaretricks verwendet hast, welche mit Win7 nicht mehr so optimal funktionieren. Möglicherweise hast du auch och enen Bug in deinem Programm, welche unter anderen Windows sich anders oder gar nicht ausgewirkt hat.
Es kann natürlich auch an einer von dir verwendeten Bibliothek liegen.
Da müsste man jetzt also einen Prformancetest machen und nachsehen in welchen Routinen es hakt. Also wirf mal den Debugger an.
MfG Peter(TOO)
Moin, Peter,
dann gehe ich wohl richtig in der Annahme, dass niemand weiß, warum Windows 7 nicht abwärtskompatibel ist. Bislang galt ja als eherne Regel, dass neue Versionen - nicht nur bei Microsoft - zumindest das können müssen, was alte Versionen schon mal konnten. Und bitte jetzt keinen Verweis auf direkte Hardwarezugriffe, wie sie unter DOS noch möglich waren, das ist 100 Jahre her.
Gruß Ralf
Hallo!
Wenn Du nicht präziser wirst, inwiefern Win7 „nicht abwärtskompatibel“ ist, wird Dir hier leider niemand etwas Genaueres sagen können.
Also: Warum genau läuft Dein Programm unter Win7 nicht? Was passiert an welcher Stelle?
Gruß,
Martin
Hallo,
dann gehe ich wohl richtig in der Annahme,
dass niemand weiß, warum Windows 7 nicht
abwärtskompatibel ist.
Soll da jetzt ein Gag sei?
Natürlich gibt es Leute, die genau wissen,
warum Windows7 nicht vollständig abwärtskompatibel ist.
Zumindest die Softwareentwickler bei MS sollten
es auch wissen.
Bislang galt ja
als eherne Regel, dass neue Versionen - nicht
nur bei Microsoft - zumindest das können müssen,
was alte Versionen schon mal konnten.
Wird immer spaßiger!
Neue Versionen müssen nicht zwingend das können,
was alte Versionen konnten. Manches wird einfach
fallen gelassen.
Manche Aufgabe/Probleme werden auch einfach anders
gelöst, als in früheren Versionen. Da können
neue Versionen also nur im Prinzipdas , was alte
Versionen eben anders konnten.
Direkt mit Kompatibilität hat das allerdings
weniger zu tun.
Ansonsten hat besonders Microsoft diese angebliche
Regel noch nie als übermäßig wichtig angesehen.
Fehlende Abwärtskompatibilität gab es bei jedem OS
mehr oder weniger.
Ganz erhebliche Inkompatibilitäten gibt es zwischen
den größeren Designsprüngen, z.B. Win3.1 -> Win95
oder von Win95/98/Me -> Win XP/Vista und nochmal zu win7.
Dass es auch noch größere Inkompatibilitäten zwischen
Win95/98/ME und Win2000 gibt, ist auch nicht neu.
Und bitte jetzt keinen Verweis auf direkte
Hardwarezugriffe, wie sie unter DOS noch möglich waren, das
ist 100 Jahre her.
Ein Problem sind aber auch immer noch diverse Treiber
für Hardware, die in unterschiedlichen OS zu verschiedenen
Ergebnissen mit diversen Problemen führen können.
Gruß Uwi
Hallo Ralf,
dann gehe ich wohl richtig in der Annahme, dass niemand weiß,
warum Windows 7 nicht abwärtskompatibel ist.
Im konkreten Fall schon.
Bislang galt ja
als eherne Regel, dass neue Versionen - nicht nur bei
Microsoft - zumindest das können müssen, was alte Versionen
schon mal konnten.
Da kanns z.B. Probleme mit der Paameterübergabe bei Aufrufen geben:
Beim alten Aufruf wurden zwar 16Bit übrgebn, abr nur die untren 8Bit waren definiert. Man konnte also in den obren 8Bit irgendwelchen Schrott übergeben. Bein neuen Aufruf sind nun alle 16Bit definiert.
Hat doch früher immer funktioniert …
Ähnliche Probleme gibts auch mit Bitfeldern und Datenbanken.
Man verwendet ein früher unbenutztes Bit. Wenn die gespeicherten Bit nun Zufallswerte haben …
Es gibt bei einem Aufruf neue zusätzliche Fehlercodes.
Bei C und Unix ist es z.B. typisch dass negative Rückgabewerte einen Fehler bedeuten. Deshalb testet man zuerst auf negative Rückgabewerte, dekodiert dann die bekannten Fehlercodes und gibt andernfalls eine Meldung „unbekanntr Fehler“ aus. Das funktioniert immer, auh wenn die Fehlercodes erweitert wurden.
Wer nur di ihm bekannten Fehlercodes abprüft und andernfalls den Aufruf als Fehlerfrei betrachtet, rechnet man dann plötzlich mit ungültigen Wertn weiter …
Ein nicht initialisierter Zeiger kann mit mit einer Konstanten aus irgendeinem Afruf belegt sein, wie z.B. der Versionsnummer des Betriebssystems. Zufällig zeigt dieser Wert dann auch noch in einen Speicherbereich, welcher nicht belegt ist. Geht auch Jahrelang gut bis sich die Versionsnummer des Betriebssytem ändert …
Und wie man so in Fachkreisen munkeln hört, soll Code von Microsoft auch nicht immer Feherfrei sein …
MfG Peter(TOO)
Hi Peter,
danke für die ausführliche Erläuterung - das lässt mich hoffen, da ich mit dirty tricks wenig am Hut habe 
Und wie man so in Fachkreisen munkeln hört, soll Code von
Microsoft auch nicht immer Feherfrei sein …
Sind ja auch nur Menschen.
Gruß Ralf
Moin Ralf,
schlicht um die Planung der Aufgaben, die da evtl. auf mich
um welche Aufgaben handelt es sich denn?
Hört sich nach Migration von Windows xxx zu Windows 7 an.
Gruss
Joey
API Funktion Sleep bei 64 Bit
Muss / kann ich meinen
Quellcode dergestalt ändern, dass ein Einsatz unter Win 7 ohne
Hakeln möglich ist?
Hallo Ralf,
k.A. was deine Quellcodes sind.
Vielleicht interessiert dich folgendes. Wenn du die API-Funktion Sleep
einsetzt, die normalerweise so deklariert ist:
Private Declare Sub Sleep Lib „kernel32“ (ByVal dwMilliseconds As Long)
dann funktioniert sie nicht bei 64 Bit.
Du müßtest sie so bekanntmachen:
Private Declare PtrSafe Sub Sleep Lib „kernel32“ (ByVal dwMilliseconds As LongPtr)
dann soll sie funktionieren.
Ich habe das aktuell grad in einem anderen Forum mitgelesen und kann das nicht überprüfen da ich nur 32 Bit habe.
Ich würde mich freuen jmd. hier wäre so nett das mal bei 64 Bit Systemen zu testen ob das so ist und berichten. Dankeschön dafür.
Gruß
Reinhard