shermanp wrote:
That's alright, I've found a way of doing it using the method suggested here. Simple, and doesn't require compile time or run time checking. And since the only purpose is to read/write a one-time footer, performance is hardly an issue either.

I think I've got the VHD footer reading working. The next step is to figure out what I need to store where to get the info into the config file etc. That looks like it's part of the HdSizeDlg stuff. I shall persevere with it...

If I want to implement creating VHD's (which I do), I've discovered another little spanner in the works -- UUID. For whatever reasons, most implementations of UUID generation (in C) appear to use OS calls. So what the heck to do with MinGW? Where's a nice portable C (not C++) library for generating a valid UUID? Or do we just fake it for the purposes of creating a VHD file?

But to those interested, yes, I am making progress. I'm just trying to wrap my head around the wxWidgets stuff.

(As an aside, working with C makes me that much more appreciative of higher level languages!)

Sherman, Sarah, thanks a lot.

I didn't even actually intend this as a "request" (I don't really get the idea of requests, within the scope of something that is being given away for free), just a feature suggestion from some one who uses PCem literally every single day.

I wish I was more familiar with the toolchain and libraries used by you guys so that I could contribute myself, this is definitely one of those things that I would have enjoyed developing!

I've been thinking about VHD support for PCem for a while. Having never contributed any code to PCem before, it looked like adding VHD support wouldn't be too difficult, so I finally decided to have a go.

I have tested the newly implemented VHD support in how many scenarios as possible without a hitch. Old VHDs created under Virtualbox and Hyper-V were mounted and operated normally, and vice-versa PCem-made VHDs mount just fine everywhere else.

I have tested the newly implemented VHD support in how many scenarios as possible without a hitch. Old VHDs created under Virtualbox and Hyper-V were mounted and operated normally, and vice-versa PCem-made VHDs mount just fine everywhere else.

Great thanks to Sherman, Sarah, and everyone who was involved.

Thanks for testing. No promises, but I've been thinking about how one might implement support for dynamic VHD's. The format itself doesn't look to difficult, it's whether or not I have the skills to implement it that I'm not too sure about...

The other option is to use an external library, but there doesn't appear to be much in the way of a standalone C library. There's a library called libvhdi, but that is labeled 'alpha', and I don't really know how stable and feature complete it is. Also, attempting my own implementation sounds like it could be an interesting problem to solve.

@xXLuckyXx : The answer is actually in that screenshot. 20GB disk (as seen by Windows 98 in PCem), sizing around 250MB on physical disk.

Shermanp did already implement fixed-size VHD support (which is almost a raw image with some headers), but he is currently implementing, with success, dynamic-sized disks.

What it means to all of us is that we will have have X amount of virtual hard drives on your disk, and the file sizes will be a lot less than the physical size (assuming a common disk usage, where you don't fill it up)

So it's like VirtualBox. Virtualbox has Fixed size (if it is 20gb it will take 20gb immediately) and Dynamically allocated (it starts with 0mb and it will take more space when more files/applications are added but it won't shrink the size if those files/applications get deleted but it won't take more than allocated - 20gb)

But OS in VirtualBox works faster if it has Fixed size. Does that mean PCem will lose some of it's performance when having Dynamically allocated hard disk?

Yes, potentially. But I don't think there will be too much in it. The format stores data in (typically) 2MB blocks. When a read or write occurs, it will, in most cases, be constrained to a single block, and performance should be almost as good as a raw image. There are two areas when performance gets degraded: 1. Read/write across data blocks 2. Write to a sparse (unallocated) block.

I haven't done any benchmarks yet, but my gut feeling is that modern hard disks are faster than any HDD emulated by PCem would have been anyway.

In case anyone in this thread missed it, I have updated my patch in the patches subforum to add support for dynamic VHD's

Tested as much as I could, and encountered no issues. Fiddled with mounting the pcem-made VHD in Hyper-V machines, or even directly under Windows, and viceversa (VHDs made in Hyper-V mounted under PCem), and all works flawlessly.
Thanks!

Tested as much as I could, and encountered no issues. Fiddled with mounting the pcem-made VHD in Hyper-V machines, or even directly under Windows, and viceversa (VHDs made in Hyper-V mounted under PCem), and all works flawlessly.
Thanks!

Thanks for testing it. Glad to hear that you haven't found any issues so far.

Couldn't mount my larger VHDs beyond 32gb though but i'm surprised at the dynamic vhd support in this early, which is very handy for fresh setup.

Yeah, unfortunately, ~32GB is the maximum size limit. More specifically, it's 65535 cylinders * 16 heads * 63 sectors/track. Basically, the limitation is because the VHD format can't support more than 65535 cylinders (it's stored as a 16 bit int), and PCem doesn't support anything higher than 63 sectors/track. I figure for most setups, that 30GB will be plenty.

The only thing that MIGHT work is to cheat. Store more than 63 spt in the VHD, and convert them to cylinders at runtime. I don't know enough about hard disk geometry to know it if that would go horribly wrong. Especially since one of the main points to adding VHD support in the first place is interoperability with other software (eg. Windows)

Let's see, 65,535 cylinders, 16 heads and 63 sectors per track, that's actually, 66,059,280 sectors for a maximum total of 33,822,351,360 bytes or almost 31.5 GB which is plenty for a successful Windows 95 OSR2 installation.