BREAK=OFF
FCBS=4,2
FILES=45
LASTDRIVE=T

...

country=049,437,%SystemRoot%\system32\country.sys
device=%SystemRoot%\system32\himem.sys
devicehigh size=0090 %SystemRoot%\system32\setver.exe
dos=high,umb
dosonly
shell=%SystemRoot%\system32\command.com %SystemRoot%\system32\ CON /E:4096 /P

@echo off

REM C:\AUTOEXEC.BAT wird nicht zum Initialisieren der 
REM MS-DOS-Umgebung verwendet.
REM Stattdessen wird die Datei AUTOEXEC.NT verwendet,
REM wenn es nicht anders in einer PIF-Datei angegeben wird.

REM Installieren der CD ROM-Erweiterung
lh %SystemRoot%\system32\mscdexnt.exe

REM Installieren des Netzwerk-Redirectors
lh %SystemRoot%\system32\redir.exe

REM Installieren der DPMI-Unterstützung
lh %SystemRoot%\system32\dosx.exe

REM Installieren von APPEND-Unterstützung
lh %SystemRoot%\system32\append.exe /e /path:off

REM Installieren der Tastatur-Unterstützung
lh %SystemRoot%\system32\kb16.com gr,437,%SystemRoot%\system32\keyboard.sys /E

REM Installieren der Ländercode-Unterstützung
lh %SystemRoot%\system32\nlsfunc.exe %SystemRoot%\system32\country.sys

REM PATH wird nicht verändert (NT-VDM verwendet die in der Win32-Umgebung
REM definierte Variable)

REM PROMPT verändern
prompt [MS-Windows NT 4.00 DOS, $P]: 

REM Umgebungsvariablen verändern, DIR-Befehl
set DIRCMD=/P

REM Umgebungsvariablen verändern, Zeitzone
set TZ=CET-01:00:00CST

3 Antworten zu dieser Frage

1. Antwort von nach 7 Stunden 2 hilfreich

   Re: Seltsames Verhalten von 16bit Programmen :(

   Hallo Walter,
   verwende folgende Systemumgebung:
   
   Betriebssystem: Windows NT 4.00 mit SP6a (ohne IE - nur den
   "Standard" Internet Explorer 2.0) mit dem MPS Multiprozessor
   HAL auf einem
   TYAN Tiger i7505 Dual-iXEON 2,4 GHz, 533 MHz FSB System;
   Eine etwas exotische Kombination aus Uralt BS und modernster CPU.
   
   So auf Anhieb habe ich folgende Tips:
   1. BIOS-Update:
   Unter Anderem nimmt das BIOS Patches am MicroCode der CPU vor, sofern Fehler bekannt sind. Bei einem so neuen System besteht die Möglichkeit das im BIOS noch ein paar Fehler sind.
   
   2. Graphik-Karten Treiber:
   Da dein Problem davon abhängig ist ob du im Vollbild- oder Fenster-Modus arbeitest, könnte das Problem auch hier versteckt sein.
   
   3. Timing-Problem:
   Da die Hardware um Grössenordnungen schneller arbeitet, als das zu NT 4.0-Zeiten üblich war und der Xenon die Befehlsabarbeitung selber noch optimiert, könnte es dadurch zu Problemen kommen, dass z.B. kleine Zeitschleiffen einfach zu schnell abgearbeitet werden !
   
   Das Hauptproblem wird wohl sein, dass NT 4 eigentlich nicht mehr weitergepflegt wird (Weder das BS durch MS, noch Treiber durch irgendwelche anderen Hersteller) und wohl deshalb von dieser Seite keine Unterstützung für deine Konfiguration zu erwarten ist.
   
   Was spricht eigentlich dagegen Win XP auf diesem Systen einzusetzen ?
   
   
   MfG Peter(TOO) das Problem:
   
   Starte ich z.B. den DOS-Editor in einem DOS-Fenster scheint
   der zu hängen, Tastatureingaben erscheinen etwa 1-3 Minuten
   später; schalte ich den Editor mit Alt+Enter in den
   Ganzbildmodus sind auf einem Schlag alle Tastatureingaben
   sichtbar und das Programm läuft mit normaler Geschwindigkeit.
   Starte ich den DOS-Editor gleich im Ganzbildmodus läuft er
   ohne Probleme in normaler Geschwindigkeit; ein Umschalten
   mittels Alt+Enter in den Fenstermodus läßt den Editor
   scheinbar einschlafen :(
   
   weitere Diagnoseinformationen
   
   meine CONFIG.NT:
   
   

   BREAK=OFF
   FCBS=4,2
   FILES=45
   LASTDRIVE=T
   
   ...
   
   country=049,437,%SystemRoot%\system32\country.sys
   device=%SystemRoot%\system32\himem.sys
   devicehigh size=0090 %SystemRoot%\system32\setver.exe
   dos=high,umb
   dosonly
   shell=%SystemRoot%\system32\command.com %SystemRoot%\system32\
   CON /E:4096 /P
   

   
   
   meine AUTOEXEC.NT:
   

   @echo off
   
   REM C:\AUTOEXEC.BAT wird nicht zum Initialisieren der
   REM MS-DOS-Umgebung verwendet.
   REM Stattdessen wird die Datei AUTOEXEC.NT verwendet,
   REM wenn es nicht anders in einer PIF-Datei angegeben wird.
   
   REM Installieren der CD ROM-Erweiterung
   lh %SystemRoot%\system32\mscdexnt.exe
   
   REM Installieren des Netzwerk-Redirectors
   lh %SystemRoot%\system32\redir.exe
   
   REM Installieren der DPMI-Unterstützung
   lh %SystemRoot%\system32\dosx.exe
   
   REM Installieren von APPEND-Unterstützung
   lh %SystemRoot%\system32\append.exe /e /path:off
   
   REM Installieren der Tastatur-Unterstützung
   lh %SystemRoot%\system32\kb16.com
   gr,437,%SystemRoot%\system32\keyboard.sys /E
   
   REM Installieren der Ländercode-Unterstützung
   lh %SystemRoot%\system32\nlsfunc.exe
   %SystemRoot%\system32\country.sys
   
   REM PATH wird nicht verändert (NT-VDM verwendet die in der
   Win32-Umgebung
   REM definierte Variable)
   
   REM PROMPT verändern
   prompt [MS-Windows NT 4.00 DOS, $P]:
   
   REM Umgebungsvariablen verändern, DIR-Befehl
   set DIRCMD=/P
   
   REM Umgebungsvariablen verändern, Zeitzone
   set TZ=CET-01:00:00CST
   

   
   zusätzlich habe ich in der _DEFAULT.PIF den Speicher
   hinaufgeschraubt:
   - EMS: 4096 kB
   - XMS: 4096 kB
   - DPMI: 4096 kB
   
   Habe schon microsoft.com durchgegrast => erfolglos
   
   Wer weiß Rat, was ich machen muß, um auch 16bit Programme
   im Fenstermodus laufen zu lassen?
   
   Mit bestem Dank,
   Walter H.
   

   • Antwort von nach 20 Stunden 0 hilfreich

     Re^2: Seltsames Verhalten von 16bit Programmen :(

     Hallo Peter, verwende folgende Systemumgebung:
     
     Betriebssystem: Windows NT 4.00 mit SP6a (ohne IE - nur den
     "Standard" Internet Explorer 2.0) mit dem MPS Multiprozessor
     HAL auf einem
     TYAN Tiger i7505 Dual-iXEON 2,4 GHz, 533 MHz FSB System;
     Eine etwas exotische Kombination aus Uralt BS und modernster
     CPU.
     
     Ja, das mag einem außenstehenden tatsächlich exotisch vorkommen :( So auf Anhieb habe ich folgende Tips:
     1. BIOS-Update:
     Unter Anderem nimmt das BIOS Patches am MicroCode der CPU vor,
     sofern Fehler bekannt sind. Bei einem so neuen System besteht
     die Möglichkeit das im BIOS noch ein paar Fehler sind.
     
     Mein BIOS Release: 1.01, aktuelles BIOS Release: 1.02 <-- das kam erst vor ein paar Tagen, werde ich installieren sobald der Rechner mir das Ergebnis der momentan laufenden Berechnung geliefert hat, bis dahin haben sich Reaktionen bei denen ergeben die das selbe Board haben. 2. Graphik-Karten Treiber:
     Da dein Problem davon abhängig ist ob du im Vollbild- oder
     Fenster-Modus arbeitest, könnte das Problem auch hier
     versteckt sein.
     
     Das kann ich schon mal ausschließen, weil es auch mit Standard-VGA Treiber 640x480 (16) nicht funktioniert. 3. Timing-Problem:
     Da die Hardware um Grössenordnungen schneller arbeitet, als
     das zu NT 4.0-Zeiten üblich war und der Xenon die
     Befehlsabarbeitung selber noch optimiert, könnte es dadurch zu
     Problemen kommen, dass z.B. kleine Zeitschleiffen einfach zu
     schnell abgearbeitet werden !
     
     hmm, das klingt für mich paradox, weil WinNT 3.51, das noch älter ist, dieses Problem nicht hat - hab' das mal installiert, weil ich es wissen wollte; Das Hauptproblem wird wohl sein, dass NT 4 eigentlich nicht
     mehr weitergepflegt wird (Weder das BS durch MS, noch Treiber
     durch irgendwelche anderen Hersteller) und wohl deshalb von
     dieser Seite keine Unterstützung für deine Konfiguration zu
     erwarten ist.
     Leider :'(
     Was spricht eigentlich dagegen Win XP auf diesem Systen
     einzusetzen ?
     - ich hab kein WinXP und etwas gegen die Art mit der Lizenzierung, will Microsoft nicht fragen müssen, wenn ich es neu installieren muß/will!- es gibt kein WinXP ohne Internet Explorer! *grr*
     - es gibt für meine Graphikkarte keine accelerated Treiber f. Win2K/XP aber für WinNT :)- um bei WinXP eine Performance mit meinen Berechnungsprogrammen wie mit WinNT zu haben, müsste ich Hyperthreading aktivieren, was aber sinnlos ist, weil es "nur" 2 CPUs unterstützt;
     
     hatte mal kurz WinSrvr2003 bzw. Win2K/XP und war bitter enttäscht :(
     
     Gruß,
     Walter
     

     • Antwort von nach einem Tag 0 hilfreich

       Re^3: Seltsames Verhalten von 16bit Programmen :(

       Hallo Walter, 3. Timing-Problem:
       Da die Hardware um Grössenordnungen schneller arbeitet, als
       das zu NT 4.0-Zeiten üblich war und der Xenon die
       Befehlsabarbeitung selber noch optimiert, könnte es dadurch zu
       Problemen kommen, dass z.B. kleine Zeitschleiffen einfach zu
       schnell abgearbeitet werden !
       
       hmm, das klingt für mich paradox, weil WinNT 3.51, das
       noch älter ist, dieses Problem nicht hat - hab' das mal
       installiert, weil ich es wissen wollte;
       Ein Beispiel aus der Windows-Welt:
       Ein Win2k-System lief problemlos, bis ein Service-Pack aufgespielt wurde. Danach konnte Win, beim booten, die Boot-HD nicht mehr mounten. Neuinstallation, Treiber etc. brachte immer den gleichen Effekt. Erst ein BIOS-Update brachte den Erfolg.
       
       Es gibt viele Fehler, welche erst durch Zufall entdeckt werden. z.B. ein nicht gerettetes Register in einer BIOS-Routine. Erst wenn man das Programm mit einem neueren Compiler, mit besserer Optimierung, neu übersetzt können solche Fehler plötzlich verherend werden.......
       
       Dann war da noch ein Problem beim Umstieg vom 8086 auf den 80286 welches uns das, heute noch vorhandene, "GateA20" bescherte. Durch "geschickte" Wahl von Segment und Offset war es beim 8086 möglich Adressen über 1 MB zu generieren. Der 8086 griff dann auf physikalische Adressen innerhalb der ersten 64Kb des Speicherraums zu, der 80286 aber auf die korrekten Adressen am Anfang des zweiten 1MB Bereichs.
       
       MfG Peter(TOO)