Ich habe meinen PC im Büro auf NT 4.0 SP4 umgestellt (eine Standardkonfiguration hier bei uns). Leider habe ich aber Probleme hiermit (auf allen anderen Rechnern läuft es eigentlich problemlos).
Der Fehler sieht wie folgt aus:
Wenn ich eine 16 Bit Applikation starte (ich glaube zumindest das alle 16-Bit Applikationen betroffen sind), dann startet NTVDM.EXE und belegt 99 % der CPU. Leider passiert danach nichts mehr, also auch die 16 Bit Applikation läuft nicht. Bei einer Anwendung ist es mir gelungen sie in einem „seperaten Memory“ laufen zu lassen.
Einziger Unterschied zu den anderen Rechnern ist, daß bei meinem PC eine SCSI Karte (Adaptec AHA 2940 UW mit Festplatte und CD-Brenner) eingebaut sind. Beide Teile lassen sich auch problemlos ansprechen.
Was ich bisher versucht habe: Neuinstallation auf verschiedene Art und Weise.
Update des BIOS der SCSI Karte (Resultat - der Rechner startete nicht einmal mehr hoch, also hab ich das rückgängig gemacht)
Verwendung der neuesten Treiber von Adaptec.
Ziemlich ratlos warte ich jetzt auf göttliche Eingebungen
Ich kann Dir zumindest eingeschränkt helfen:
NTDVM: NT Dos Virtual Machine und sieh ist für alle 16-Bit Anwendungen zuständig, da NT ein 32-Bit Betriebssystem ist laut Billy.
… evtl. gibt es für dieses Verhalten eine recht ausgefallene Lösung: hast Du bei Dir auf dem PC einen Drucker installiert ? Wenn nicht, dann könnte dies den Fehler verursachen. (das ist echt KEIN Scherz)
Möglicherweise steht in der datei config.nt (\winnt\system32) Unsinn. Diese Datei wird, glaub ich, beim Start der 16-bit-Machine ausgewertet. HP-Scannertreiber schreiben da ganz gern bei „Files=…“ irgendwelchen Schmarrn rein.
ciao
martin
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Möglicherweise steht in der datei
config.nt (\winnt\system32) Unsinn. Diese
Datei wird, glaub ich, beim Start der
16-bit-Machine ausgewertet.
HP-Scannertreiber schreiben da ganz gern
bei „Files=…“ irgendwelchen Schmarrn
rein.
ciao
martin
Die Config.NT habe ich überprüft (gemäß Angaben im Technet von MS) - möglicherweise lag es sogar an einer fehlenden Einstellung (shell=…command.com …). Vielleicht aber auch an einem anderen Programm (Quickview), daß ich jetzt anders konfiguriert habe. Inzwischen läuft der SCSI Teil - bin aber noch am Testen.