Falsch! Die DOS-Box ruft lediglich den Interpreter (cmd oder unter 9X command) auf und stellt ihn in einer Konsole dar - bei einem direkten Aufruf einer DOS-Software hat Windows immer noch volle Kontrolle über den Prozess, seine Timings und so weiter. Insgesamt teilen sich alle Prozesse den Prozessor(RAM wird in der Regel auch von der VM dynamisch alloziert). Wenn nun die dem Prozess zugewiesene Prozessorleistung kurzzeitig unter die Mindestanforderungen der Software gehen, der FIFO leerläuft(wenn überhaupt ein Puffer programmiert ist), haben wir den Salat und der Programmierung schlägt fehl, ähnliches bei nem Interrupt. Es muss nicht tödlich sein, aber das Risiko steigt im Vergleich zu ner echten DOS-Umgebung stark.Zitat von Grisuchris
In einer VM steht die volle Leistung der emulierten CPU erstmal zur Verfügung, solange keine Prozesse auf der selben Prioritätsebene im Gastsystem laufen und die CPU belasten. Dann wird gerecht geteilt. Auch hier ist die Möglichkeit gegeben, dass uns ein Prozess in die Quere kommt. Wenn jedoch die VM im Leerlauf ist und keinen Sleepzyklus anfordert(wie bei alten DOS-Schinken üblich, was anderes läuft ja eh nicht, was Leistung brauchen könnte), dann bleibt die Prozessorlast im Gastsystem belegt. In der DOS-Box wird die zugeteilte CPU-Leistung dynamisch geregelt und kommt evtl zu spät. Viel sicherer ists nicht, aber doch etwas.
Würde es sich bei der DOS-Box um natives DOS in einer VM handeln, könnte man keine Windows Programme starten, weiterhin hätte man in echtem DOS erstmal keinen Zugriff auf NTFS Partitionen, CD-Roms, USB und alles, wofür Treiber erforderlich sind.
Zitieren