OSDev.org

RantStart();

Why are emulators such a pain for OS development these days? When I develop my OS, I want an emulator that can be started very quickly and easily so I can quickly debug and test my OS, that leaves about Bochs and QEMU open (for Windows) because this way I can bind the executables to my Visual C++ project debugging executable and a tap on the F5 button makes the entire OS (minimal) rebuild, link and run the emulator with the new version.

But why (WHY!) does Bochs have to be so crappy from time to time? When I'm looking for something that causes a page-fault, I have to restart Bochs 5 times before I have actually made the page-fault occur. Bochs crashes ALL the time, in my OS, in another OS, in any OS here on Windows. That said, Bochs hasn't been updated for quite a while, so I decided to try QEMU, as it is faster and a new version got recently released. I try to set it up the same way as Bochs (using command line this time) and QEMU whines that it can not detect a bootable floppy from my virtual floppy. I unmout my virtual floppy and tell QEMU to use the image instead of the drive and BANG it works. But what now? To update my OS on the floppy the floppy needs to be mounted. So to run QEMU with my OS, I have to unmount the floppy and remount it everytime I want to build & debug my OS. I doubt it's me messing some settings up, cause I tried every possible combination and the drive is found, but it just doesn't detect any bootloader (GRUB) on it, while Bochs does.

RantEnd();

So here I am, stuck between 2 emulators. Bochs is a pain, has good debugging features, I like the bochsrc way of doing things, as it's pretty easy using working directories, but crashes 75% of my runs and hasn't been updated for quite some time (WHY! WON'T! YOU! UPDATE!). Wilst QEMU is much faster, also has pretty good debugging features, recently had a new version released with loads of bugfixes and new features, but won't work with my virtual floppy drive.

RantStart();

Bochs runs like a charm
QEMU runs like a charm
Images work like a charm.

PEBKAC

RantEnd();

Creature wrote:So here I am, stuck between 2 emulators. Bochs is a pain, has good debugging features, I like the bochsrc way of doing things, as it's pretty easy using working directories, but crashes 75% of my runs and hasn't been updated for quite some time (WHY! WON'T! YOU! UPDATE!). Wilst QEMU is much faster, also has pretty good debugging features, recently had a new version released with loads of bugfixes and new features, but won't work with my virtual floppy drive.

I feel for you. I also used to use Bochs for testing my boot loader / my OS, and I also used a virtual floppy drive. Now that the only floppy emulator that could be installed under WinXP x64 was a Total Commander addon, which can't be automated. I emailed the author, and he said he would consider a command-line utility in the future. Until then I would be stuck. On my other computer, which has an actual floppy drive, this wasn't an issue, but laptops don't have floppy drives... I also tried to compile various disk emulators for x64, but all of them failed to compile and/or run...

Otherwise I had no problem with Bochs, it doesn't crash for me, and I used several versions. I used official builds and ones I compiled for myself. My only problem with Bochs is that I couldn't get it to break into the debugger on Ctrl-C (or Ctrl-Break), and sometimes it would get stuck in the CPU_LOOP=1 (or something similar) loop. I haven't tried Qemu yet, so I can't say anything about that.

I dont know what your problem is with this, but couldn't you just do a nice simple script or set of commands to unmount the floppy, test the image, and remount it?

When I test my OS, I execute 'sh ./buildf' and it compiles, links, creates the ramdisk, updates the floppy image and if it all worked start s Qemu. Simple. Gets it done.

-JL

piranha wrote:I dont know what your problem is with this, but couldn't you just do a nice simple script or set of commands to unmount the floppy, test the image, and remount it?

When I test my OS, I execute 'sh ./buildf' and it compiles, links, creates the ramdisk, updates the floppy image and if it all worked start s Qemu. Simple. Gets it done.

-JL

BASH scripts generally don't work that well on Windows , unless I use Cygwin. Anyway, the point is, my scripts work and they work the way I want, but the emulators annoy me so much sometimes! Mostly when I'm irritated because of a persistent bug and I try to fix it, Bochs crashes every 10 seconds (it just plainly freezes for some reason) whilst QEMU won't even seem to run my virtual floppy (however I do remember getting it to work with the previous QEMU). The other emulators, VirtualBox, VMWare, etc... are in fact probably better in amount of features and (possibly) speed, but as I said, they don't come with a lot of debugging features nor do they have a command line way of starting (too bad).

RantStart();

Bochs runs like a charm
QEMU runs like a charm
Images work like a charm.

PEBKAC

RantEnd();

Look, if you don't have anything useful to say or to contribute to this thread, then don't post anything at all . I was ranting to get a load of my chest, which I assume everybody needs every now and then. There's no need to be annoying with that. If your post wasn't meant like that, then sorry, my mistake.

BASH scripts generally don't work that well on Windows

Duh
I was using that as an example, but windows can do scripts too.....

-JL

Since you have cygwin, you can easily get and compile the most recent CVS version of the bochs code. I have never seen anyone else who has a problem with bochs crashing. Since that is true, and you have MSVC, it's not that hard to load bochs into MSVC and debug it yourself to find out why it is crashing. I'm sure Stanislav would love to know. I think getting bochs running properly on your machine would save you an enormous amount of time. Are you even using the graphical debugger on it, with your version?

(It is true that bochs will not load automatically into MSVC -- the workspace files are messed up. You have to create your own workspace, and load the files into the project by hand -- and set up the "build" parameters by hand, too. I can tell you what you need, if you want. Or, conceivably, I could zip up my workspace and email it to you.)

bewing wrote:Since you have cygwin, you can easily get and compile the most recent CVS version of the bochs code. I have never seen anyone else who has a problem with bochs crashing. Since that is true, and you have MSVC, it's not that hard to load bochs into MSVC and debug it yourself to find out why it is crashing. I'm sure Stanislav would love to know. I think getting bochs running properly on your machine would save you an enormous amount of time. Are you even using the graphical debugger on it, with your version?

(It is true that bochs will not load automatically into MSVC -- the workspace files are messed up. You have to create your own workspace, and load the files into the project by hand -- and set up the "build" parameters by hand, too. I can tell you what you need, if you want. Or, conceivably, I could zip up my workspace and email it to you.)

Yes, I have this crazy MSVC setup (because I'm just used to the VC++ environment). So I did some crazy stuff with build rules, GCC and the debug settings and now everything runs mostly like a normal programming on Windows would. I realize that there is no real minimal rebuild that you can use, but I did manage (through build rules) to let Visual C++ not rebuild any source files unless they've been modified (VC++ doesn't recompile on inter-dependency changes however). I couldn't find a good way to implement a 'don't-link-if-there-are-no-changes' feature though.

About Bochs, no I don't have the CVS version, I tried compiling the CVS version a while back, but my Cygwin installation was sort of messed up back then (don't ask how, it just messed up ), I'll try debugging Bochs with Visual Studio and recompiling from the Bochs CVS source.

for the mount-unmount problem..

if you are using Virtual Floppy or vfdwin.exe as I know it.. there is a command line version or something than you can use to do something like
<mount floppy>
cp kernel.bin A:
<unmount floppy>
qemu -fda floppy.img

With VFD what you can do is this: VFD.EXE is the command-line equivalent that you can pass args to.

Troy Martin wrote:With VFD what you can do is this:

Code: Select all

vfd open A: image.img
copy kernel.bin A:
vfd close A:
qemu -fda image.img

VFD.EXE is the command-line equivalent that you can pass args to.

If you use Bochs, you can modify the bochsrc file to use A: (or your virtual floppy drive) - eliminating the need to constantly mount and unmount the image. I don't know if there is a similar option for Qemu though.

Why not just pointing to the image directly?

Hi,

I used to mount/unmount a floppy image to use an emulator, but don't bother anymore. Try mtools under Cygwin, which will allow you to copy files to a disk image without mounting it. Then, just emulate using the image file as suggested above.

I do agree with Combuster, though. Bochs has always worked very well (me assuming that there is a bug with Bochs has always ended up being a bug in my code) and so has qemu. Of the two, I now favour qemu due to the speed thing. When I don't need emulation, I always use virtualbox.

One thing that's working quite well now is that my build script creates bochs and qemu configuration files after a compile, inserting the correct disk image names, so the correct config files are always there in my build directory

Cheers,
Adam

Creature wrote:That said, Bochs hasn't been updated for quite a while, so I decided to try QEMU, as it is faster and a new version got recently released.

Interesting, the latest info I head was that Bochs was still actively developed (at least the debugger is :)), and Qemu wasn't. Anyway, I develop under Linux, and don't have the problems you cite.


JAL

jal wrote:

Creature wrote:That said, Bochs hasn't been updated for quite a while, so I decided to try QEMU, as it is faster and a new version got recently released.

Interesting, the latest info I head was that Bochs was still actively developed (at least the debugger is ), and Qemu wasn't. Anyway, I develop under Linux, and don't have the problems you cite.


JAL

Nope, March 5th 2009, 0.10 released.