Autor Thema: Virtual Box  (Gelesen 9178 mal)

bscreator

  • Gast
Gespeichert
« am: 26. May 2011, 19:52 »
Hallo,

ich möchte meine Betriebssysteme (REAL-Mode OSes) unter mehreren virtuellen Maschinen ausprobieren.
Darum hab ich Bochs, VirtualBox unter VMWare im Einsatz.

Das Problem liegt nur bei VirtualBox :
Bei einigen OSes (*.img-Dateien) kommt immer die Meldung:
Zitat
Die Das Diskettenabbild C:\NASMIDE\myos.img konnte nicht geöffnet werden
Wenn ich das Abbild dann auf Diskette schreibe und vom physischen Laufwerk A starte, funktioniert es aber.

Bei Bochs und VMWare kann ich auch myos.img problemlos öffnen und direkt starten, ohne das ganze erst auf Diskette zu kopieren.
PS : Ich hab die derzeit neueste Version 4.0.8 mit Extension Pack im Einsatz.

Wisst ihr, wo der Fehler bei VirtualBox liegt ?


PNoob

  • Beiträge: 106
    • Profil anzeigen
    • Mein Blog
Gespeichert
« Antwort #1 am: 26. May 2011, 20:31 »
Ist da die Datei zufällig nicht genau 1,44MB groß? wenn ja, dann kanns daran liege. Ich hab das schon öfters gelesen das es Emulatoren gibt die das nicht mögen. qemu und bochs ignorieren das ganz einfach aber bei Virtualbox war glaube ich das Problem das die größe der Datei geprüft wird.

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 26. May 2011, 20:47 »
Das Problem liegt daran, dass VirtualBox nicht mit IMG-Dateien umgehen kann.
VirtualBox versteht nur reale Massenspeicher oder ISO-Dateien.
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

bscreator

  • Gast
Gespeichert
« Antwort #3 am: 26. May 2011, 23:17 »
Zitat
Ist da die Datei zufällig nicht genau 1,44MB groß? wenn ja, dann kanns daran liege.
Das wird wohl der Fehler sein.

Kennt ihr ein Programm (für Windows XP), das dann so ein Floppy Drive emulieren kann, ohne eine exakt 1,44 MB große Datei haben zu müssen ?
(Habs mit Virtual Floppy versucht, dass kann aber leider auch nur 1,44MB grosse Dateien emulieren)

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 26. May 2011, 23:20 »
Wieso machst du das Image nicht einfach 1,44 MB groß?
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

bscreator

  • Gast
Gespeichert
« Antwort #5 am: 27. May 2011, 08:04 »
Naja, ich will keine hunderttausend Programme auf meinem Rechner haben, nur um ein Betriebssystem auf einer weiteren virtuellen Maschine testen zu müssen.
Zum anderen hab ich momentan wenig Zeit, so ein Programm zum FilePattern selbst zu schreiben.

Zitat
Wieso machst du das Image nicht einfach 1,44 MB groß?
Gibt es einen Befehl der Windows Konsole, um ein Programm 1,44 MB groß zu machen ?

Gruss,
bsc

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 27. May 2011, 08:30 »
Notfalls gibt es dd auch für Windows.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 27. May 2011, 10:32 »
Hallo,


Zum anderen hab ich momentan wenig Zeit, so ein Programm zum FilePattern selbst zu schreiben.
Zum einen gibt es da doch im Assembler passende Kommandos womit man den Code auf eine bestimmte Größe Ausdehnen kann und zum anderen ist ein C-Programm das eine Datei öffnet, deren Größe mit 1474560 vergleicht und dann passend etwas anhängt nun wirklich höchstens 10 Zeilen lang (schwierig wird es nur wenn die Datei per Kommandoparameter übergeben werden soll und das dann auch zuverlässig und fehlertolerant funktionieren muss).

Achso, dd gibt es ja auch noch, also keine Notwendigkeit das Rad neu zu erfinden.


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 27. May 2011, 17:33 »
Gibt es einen Befehl der Windows Konsole, um ein Programm 1,44 MB groß zu machen ?
@ECHO OFF
SET X1=1234567890
SET X2=%X1%%X1%%X1%%X1%%X1%%X1%%X1%%X1%%X1%%X1%
SET X3=%X2%%X2%%X2%%X2%%X2%%X2%%X2%%X2%%X2%%X2%
FOR /L %%W IN (%~z1,1002,1438998) DO>>%1 ECHO.%X3%
FOR /L %%W IN (%~z1,102,1439898) DO>>%1 ECHO.%X2%
FOR /L %%W IN (%~z1,12,1439988) DO>>%1 ECHO.%X1%
FOR /L %%W IN (%~z1,1,1439999) DO>>%1<NUL SET/PX=D
In eine Batch-Datei kopieren und mit der Datei als Parameter aufrufen. (Eigentlich ist nur die letzte Zeile notwendig. Aber die hat einen Durchsatz im Byte/s-Bereich ...)

keine Notwendigkeit das Rad neu zu erfinden.

Diese Mainstream-Räder haben zu wenig Ecken.
« Letzte Änderung: 27. May 2011, 17:36 von PorkChicken »
Dieser Text wird unter jedem Beitrag angezeigt.

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 27. May 2011, 19:39 »
Hallo,


Diese Mainstream-Räder haben zu wenig Ecken.
Hm, stimmt, da bleibt ja der Fun-Faktor völlig außen vor. ;)

Das Batch ist aber cool, hät ich gar nicht vermutet das sowas geht.


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

bscreator

  • Gast
Gespeichert
« Antwort #10 am: 30. May 2011, 12:51 »
Hallo,

Zitat
keine Notwendigkeit das Rad neu zu erfinden.
Leider zu spät. Hab ein ASM-Programm geschrieben, das eine Datei 1,44 MB gross macht.

Unter bochs und VMWare läuft die neue Datei problemlos. Aber Virtual Box hat immer noch keine Lust.
Also kanns an der Dateigröße auch nicht liegen.

Falls jemand von euch StupidOS (lowlevel Ausgabe 1) oder irgendeinen anderen einfachen Bootloader, der einfach nur nen Text ausgibt, unter ORACLE Virtual Box zum laufen bekommt, dann teilt mir das bitte mit, wie ihr das gemacht habt.


PS: Mein Manko mit FETT-Schreiben kenn ich bereits, aber bitte keine neuen Antworten, dass man es auch ohne FETT lesen kann.

Gruss,
bsc

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 30. May 2011, 13:16 »
Hallo,


Leider zu spät. Hab ein ASM-Programm geschrieben, das eine Datei 1,44 MB gross macht.
lol
Wenn Du damit wenigstens Deine Assembler-Fertigkeiten geübt hast ist das in Ordnung aber ansonsten, naja.

Aber Virtual Box hat immer noch keine Lust.
Also kanns an der Dateigröße auch nicht liegen.
Dann lade das Image doch einfach mal als HDD in Virtual-Box (des kann doch bestimmt simple .img-Dateien), ein Versuch kann IMHO nicht schaden. Und nein HDDs müssen nicht zwangsläufig Partitioniert sein. Ein ordentliches BIOS lädt einfach den ersten Sektor der HDD, prüft die Signatur in den letzten 2 Bytes (die ja bei MBR-Sektoren und Boot-Sektoren identisch ist) und führt das dann einfach aus.

Mein Manko mit FETT-Schreiben kenn ich bereits ....
Einsicht ist der erste Schritt zur Besserung. Wir sind alle sehr gespannt ob wir auf diesem Pfad noch weitere Schritte erleben werden. Die Richtung scheint ja schon mal zu stimmen, also nur Mut! ;)


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

XanClic

  • Beiträge: 261
    • Profil anzeigen
    • github
Gespeichert
« Antwort #12 am: 30. May 2011, 13:28 »
(des kann doch bestimmt simple .img-Dateien)
Bei Festplatten nicht.

Also folgendes (FASM, sollte auch mit NASM tun):
use16
org 0x7C00

jmp     far 0x0000:_start
_start:

xor     ax,ax
mov     ds,ax
mov     ss,ax
xor     sp,sp

mov     si,string
push    word 0xB800
pop     es
xor     di,di

mov     cx,80*25
rep     stosw

xor     di,di

print_loop:
lodsb
test    al,al
jz      printing_done
stosb
mov     al,7
stosb
jmp     print_loop

printing_done:
cli
hlt

string: db "WORKSFORME", 0

times 510-($-$$) db 0

dw 0xAA55

times 1474560-($-$$) db 0

tut bei mir wunderbar:


PS: Mein Manko mit FETT-Schreiben kenn ich bereits, aber bitte keine neuen Antworten, dass man es auch ohne FETT lesen kann.
Ändert nichts daran, dass es stimmt. :roll:

bscreator

  • Gast
Gespeichert
« Antwort #13 am: 01. June 2011, 07:44 »
Hallo,

erstmal danke für das Beispiel.

Habs mal kurz mit NASM versucht zu kompilieren, aber das geht nicht.
jmp far 0x0000:_start
_start:
durch jmp start
start:
ersetzt und use16 durch [BITS 16]

Beim kompilieren erscheint immer
Zitat
nasm: fatal out of memory
.
Weiss jemand warum ?

Gruss,
bsc


XanClic

  • Beiträge: 261
    • Profil anzeigen
    • github
Gespeichert
« Antwort #14 am: 01. June 2011, 13:52 »
Also, wenn ich das „far“ durch ein „dword“ ersetze, tut es bei mir mit NASM ohne Probleme (also „jmp dword 0x0000:_start“).

bscreator

  • Gast
Gespeichert
« Antwort #15 am: 01. June 2011, 14:10 »
Hallo,

habs jetzt nochmal versucht...................................nasm: fatal out of memory

Der Fehler liegt in der letzten Zeile times 1474560-($-$$) db 0Wenn die Zeile nicht auskommentiert ist, dann erscheint ständig der Fehler.


kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #16 am: 01. June 2011, 14:27 »
Für ein 16-Bit-Programm wird das halt irgendwie arg groß, oder?

Hm, wobei selbst das bei mir tut. Vielleicht zeigst du mal das ganze Programm und die nasm-Kommandozeile her statt nur irgendwelche Teile, von denen du vermutest, dass sie schuld sein könnten.
« Letzte Änderung: 01. June 2011, 14:29 von taljeth »
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

bscreator

  • Gast
Gespeichert
« Antwort #17 am: 01. June 2011, 15:00 »
[bits 16]
org 0x7c00
jmp dword 0x0000:_start
_start:
xor ax,ax
mov ds,ax
mov ss,ax
xor sp,sp

mov si, string
push word 0xb800
pop es
xor di,di

mov cx,80*25
rep stosw

xor di,di

print_loop:
lodsb
test al,al
jz printing_done
stosb
jmp print_loop
printing_done:
cli
hlt

string: db "WORKFRAME",0
times 510-($-$$) db 0
dw 0xAA55

times 1474560-($-$$) db 0

nasm -f bin -o fasmboot.asm fasmboot.bin

Dann wird der Code zwar kompiliert, aber VirtualBox kanns immer noch nicht wiedergeben.

Liegts am [BITS 16] vielleicht ?

PNoob

  • Beiträge: 106
    • Profil anzeigen
    • Mein Blog
Gespeichert
« Antwort #18 am: 01. June 2011, 15:31 »
nein daran kanns nicht liegen, weil das sagt dem Assembler nur, das er ab sofort 16 Bit Code produzieren soll und genau den brauchst du im BL. ich hab mir den Code jetzt aufgrund von Zeitmangel nicht näher angesehen, aber versuchst du eventuell mehr als 640kb auf einmal zu adressieren?
« Letzte Änderung: 01. June 2011, 15:35 von PNoob »

bscreator

  • Gast
Gespeichert
« Antwort #19 am: 04. June 2011, 14:12 »
Ne, daran kanns nicht liegen. Im Bootloader wird ja lediglich nur der 512-Byte große Bootsektor reserviert, sonst
wird ja im Bootloader kein anderer Speicherbereich adressiert, sondern nur die Meldung ausgegeben.
(Wie man im Code sieht)


 

Einloggen