OSDev.org

The versions of my kernel that run on bochs and on real hardware are somewhat different -- mostly having to do with the difference between the bochs disk image, and the real hard disk sizes. Sometimes, like now, I have an issue where the bochs version runs fine, and the version running on hardware has some bug. Since I still do not have a debugger running on the real hardware, this becomes a very tedious debugging process -- because I can't use bochs to track the bug down.

I had a momentary brainstorm, and said "Oh! I can attach the hard drive to the other PC, and tell bochs to use that hard drive as the disk image, and run bochs to debug the REAL hard drive!" -- And then I realized that it wouldn't work ... at least with a Windoze system, AFAIK.

The disk is not formatted with a filesystem that Windoze recognizes ... so Windoze will not assign a drive letter. So, AFAIK, bochs has no way of accessing the drive. Even if Windoze did assign a drive letter, I'm betting that it would not let bochs have full access the whole logical drive (FAT tables and all)?

And then I started wondering, if I had done all this development under Linux, could I have done it then? So, this is my question to all of you: do any of you know if bochs can access a disk image, under linux, that is a raw blockmode (or character) device? Or alternately, am I full of sh*t, and there IS a way to get bochs to access an unrecognized "physical drive" on a Windoze system?

There is one way: Cygwin - it allows you to access /dev/sd(xx) as a file directly (!)

Which suggests that if you compile bochs from source under cygwin you can point it directly to a physical drive like you would under linux.

Enjoy your d'oh moment

Heh.

I never even bothered looking at the /dev directory in cygwin ... I assumed there couldn't possibly be anything interesting in there.

Hmmm. Well, if I reinstall all 40K+ files of cygwin, at least it would give me a good reason for erasing and reusing my old Linux (which isn't working right anyway) disk for better purposes.

Surprisingly, it may be possible to directly access devices under NT without using the Cygwin solution Combuster provided.

http://support.microsoft.com/kb/100027

No clue if it actually works or not... but the QEMU related page below claims it does.

http://www.h7.dion.ne.jp/~qemu-win/HowT ... alharddisk

But yes, it probably would have been easier on a Unix system, for one, most don't try to hide direct drive access from the user.

I haven't had the need, but under OpenBSD I could access a USB attached hard drive as /dev/rsd0c if I needed too.

It does work.

I used to use this method back in the days of Win95 to allow my programs to copy and back up floppy disks sector-by sector.

Cheers,
Adam

Huh! I had no idea. Thanks Brynet! (PS. It doesn't say WinNT ... it says ALL Win32 versions.) I am now going to bet that is how Norton Diskedit does all the magic that I find so surprising. -- And, of course, one more gaping security hole in Windoze ....

I don't know how a *NIX could be any easier than that!
It's just the difference between being documented and undocumented.

Maybe now I can write a utility of my own to modify my disk images without having to exit to DOS ....

bewing wrote:(PS. It doesn't say WinNT ... it says ALL Win32 versions.)

That was an assumption I made, in the QEMU document it claims that method isn't supported by Windows 98 and ME, so I assumed it was an NT exclusive thing.

My bad, still, gotta love Google.

If you use the \\.\<dev> method, it is supported by 98/ME. That's the Win32 subsystem's raw device referencing. The \Device\PhysicalDriveN method is the NT core referencing, so that only works on NT 3.1+ (Maybe OS/2? Who knows, I lost my OS/2 2.1 disks forever ago, but I guess it's not important.)

Sadly, bochs doesn't seem to open the "file" correctly, to make the \\.\ thing work directly. It gives a "cannot open" error. Maybe I'll file an upgrade suggestion with the bochs guys. In the meantime, I'm thinking of using \\.\ as the basis of a dll, to make "raw disks" available to me and bochs.

Ooops. Damn. Just checked the bochs documentation, and their dll access method isn't going to help me either. So I guess I've gotta run with Combuster's cygwin suggestion!

... Either that ... or modify the bochs source, maybe .... Hmmmm .....

Crap. The cygwin method that Combuster suggested only works on WinNT or XP (maybe Vista -- but access to physical drives on vista has been curtailed). Cygwin will return a -1 if you try to open /dev/sdX on anything else.