@bluefisch200 & Mav1962:
Die Emulationsschicht für 16bit-Programme ist unter Windows 64bit nicht mehr vorhanden.
Die Autoexec.nt bzw. Config.nt sind lediglich für die Kompatibilität von Programmen die noch auf Windows 9x/Me (aber 32bit sind) liefen zuständig. Deshalb ist auch noch zB eine Win.ini im Windows-Verzeichnis vorhanden, obwohl sie schon lange nicht mehr verwendet wird.
Die Dateien werden eben beim Start geparst und ggf. in die Regestry übernommen. Eine direkte Ausführung findet nicht mehr statt und 16bit-Treiber können natürlich nicht mehr nachgeladen werden.
Das Ganze betrifft aber auch die 32bit-Versionen.
Mav1962 schrieb:
@DiableNoir
Ich habe SuSe Linux 11.1 64 bit am laufen und der Firefox "
soll" 64 bit sein und Flashplayer "
soll" auch 64 bit sein wie ich in den Eigenschaften gelesen habe und die laufen prima. Bin mir allerdings nicht sicher wie ich unter Linux überprüfen kann ob ein Programm auch tatsächlich mit 64 bit läuft.
Also ein 64bit-Firefox sollte nur 64bit-Plugins in den Speicher nachladen können, von daher muss man davon ausgehen, dass beide unter der selben Architektur laufen.
@DiableNoir,
verdrehte Welt. Ende der 80er hab ich schon 16/32Bit Prozessoren programmiert. Warum die keine echte Emulatoren implementieren. Wenn ich bedenke. Für die ganzen alten Kisten gibt es hervorragende Emulatoren. Für DOS ist die DOS-Box auch schon genial.
Schwer wird es vermutlich mit Direct X unter W95/98/me Anwendungen. Vermutlich nur noch mit VM lauffähig.
Ich wünsche mir einfach ein System in dem alle möglichen alten Emulatoren enthalten sind. Das bekomme ich auch hin.
Was die alte Windows Historie angeht, da scheint sich zwischenzeitlich das größte Problem eingeschlichen zu haben. Die sollen doch einfach ne VM der alten Windows Systeme implementieren und das Thema ist erledigt.
Was schliesse ich also aus Allem. Je mehr wir uns mit den Softwarepatenten und Copyrights rumschlagen desto schlechter und uneffektiver wird die Software. So langsam sollte man sich von den alten Geschichten abnabeln oder eine andere Strategie fahren. Wie das bei Linux und Unix der Fall ist. Das einzig Positive daran. Wenn man den Gedanken zu Ende führt, müsste sich irgendwann Open Source schneller entwickeln als rechtlich geschützte Software.
Ja, Emulatoren sind schön und gut...nur ist es aufwendig so etwas zu machen und IT-Unternehem verdienen kein Geld mit alter Software. Ein modernes Betriebssystem kann man auch eigentlich nicht mehr emulieren. Zumindest könnte ich mir nicht vorstellen wie.
Schon eine Wrapper-Schicht wie WINE zur Simulation einer Windows-API ist bereits extrem aufwendig. Wenn man bedenkt wie viele Firmen (zZ besonders Google) hier schon Code/Arbeit/Geld beigetragen haben. M$ wird aber niemals ein Projekt wie WINE in Windows integrieren, obwohl es eigentlich der Idealfall wäre, da man sich dann von den alten APIs abnabeln kann und M$ gleichzeitig etwas zur Kompatibilität von Windows-Programmen unter Linux beitragen würde.
M$ Research arbeitet allerdings an einem interessanten System das auf Hyper-V aufsetzt und damit zumindest alte Systeme virtualisieren kann, während neue Programme auf einer abgespeckten erneuerten Version laufen. (Projektname will mir leider spontan nicht einfallen.)
Wie performant dass dann ist, ist dann wieder eine andere Sache. Solange VMs zB nicht direkt auf die Grafikhardware zugreifen können oder diese virtualisiert werden können sieht es schlecht für Spiele aus. Außerdem müssten auch weiterhin Treiber für die alten Schnittstellen für neue Karten geschrieben werden. Aber das ist nur eine Annahme. Evtl. gibt es bei dem Projekt ja schon Lösungsansätze.
Bedeutet also. Wenn man den LAA-Flag für 32Bit Programm setzt können diese theoretisch wirklich bis zu 4GB RAM nutzen.
das ist ja schon klar. Mich interessiert es einfach nur ob es funktioniert. Wir schleppen ja durch alle Windows Systeme mehr als genug Altlasten mit oder? Ganz zu schwiegen von den an der Hand abzählbaren echten 64Bit Anwendungen. Ich finde es einen interessanten Mittelweg.
.
