PCem

Hi, first and foremost thanks for PCEm: the feeling of having my first PC ever up and running is so genuine that it's giving me the chills.

Quick question: is there a reason why for hard disks the IMG format was chosen over VHD? Is support for VHD eventually planned?

Thanks

resle wrote:Hi, first and foremost thanks for PCEm: the feeling of having my first PC ever up and running is so genuine that it's giving me the chills.

Quick question: is there a reason why for hard disks the IMG format was chosen over VHD? Is support for VHD eventually planned?

Thanks

You can convert VHD to img very easily I think.

nerd73 wrote:

resle wrote:Hi, first and foremost thanks for PCEm: the feeling of having my first PC ever up and running is so genuine that it's giving me the chills.

Quick question: is there a reason why for hard disks the IMG format was chosen over VHD? Is support for VHD eventually planned?

Thanks

You can convert VHD to img very easily I think.

True but VHDs have the advantage that on Windows 8 and onward, they're mountable and hence editable without the need for tools of any kind. They're seen by the OS just as a physical hdd.

I didn't support the VHD format because I'd never heard of it! Just had a look at the specification, looks like the fixed size format shouldn't be too difficult to support.

VHD was used in VirtualPC as well and Windows 7 can also mount them in its disk manager, and I think WinImage can dump whole drives to VHD

Used in VirtualBox, too, which is able to use them even as they are mounted under Windows - effectively creating the perfect way of swapping files from the virtual to the real environment and vice-versa.

Hope you'll give VHD a shot, Tom

Using those utilities like WinImage instead.

leilei wrote:VHD was used in VirtualPC as well and Windows 7 can also mount them in its disk manager, and I think WinImage can dump whole drives to VHD

What's notable is that VHDs were first used under Connectix Virtual PC under older versions of MacOS. The first version of Connectix Virtual PC was designed for Windows NT 4.0 and Windows 98 respectively. I don't have Windows 7, but VHD images can be mounted using ImDisk.

resle wrote:Used in VirtualBox, too, which is able to use them even as they are mounted under Windows - effectively creating the perfect way of swapping files from the virtual to the real environment and vice-versa.

That sounds like an effective way to get disk corruption in VHD.

I don't know: I have been doing the above for almost 5 years now, with no issue..

As reliability and ease of use for moving large amounts of data I would rather have VHD, but being stuck at a 8GB limit for now I think IMG is fine. As we increase the HDD limit it might be nice to have easier access to the image from the host system. Either by this or networking the emulator and the host for file transfers directly (If there is a way for this right now let me know I am just assuming there is not because I have yet to see any news about it).

In theory, you should be able to use a build with SA1988's NE2000 emulation patched in to do exactly what you describe with no major difficulty. I haven't waded into networking at all, but plenty of people here seem to have gotten it to work, which should be sufficient to set up any kind of file transfer system you'd like.

And I think it is something that is wanted enough that it will be inevitable and I am fully willing to wait for it to happen. Just like all the other future goodies I dream of coming out. I still think eventual VHD support would still be a good idea and one I don't think is as inevitable.

Hi Sarah, I know this is an old thread, but have you had any further thoughts on adding official VHD support to PCEM?

Even though it's not a supported format, fixed VHD disks already "work" with PCem, although there's no guarantees that there are no issues (there are probably slight disk size calculation errors)

Looking at the specifications from MS, basic support for fixed VHD seems to be as simple as treating the file as an IMG file, but ignoring the last 512 bytes, although the footer does contain CHS info that could be useful.

Fixed VHD creation support looks to be not much more complex than generating a footer and appending it to the image.

I would look into doing it myself, but I'm not quite sure where I would need to start: 'allegro-gui-hdconf.c' looks a likely candidate, but I'm not sure if any of the "disc" code would also need updating.

- shermap: The "disc" stuff is for floppies. The hard disk images are handled separately by every single hard disk controller, so there's quite a few files you'd need to change.

I was searching where to post this, so it is for here. i had virtual machine on vbox i linux and annoying fact that i could not get fallout screen to fill whole screen as vbox will display small 640 "full screen" on 1366 screen. so i thought , well PCem should handle fallout easy, but i didn fell like to creating new disk for PCem and installing win98, so i just renamed 2GB .vhd image to .img and attached it to PCem, PCem launcher found automatically disk geometry , and 430vx found and boot up with no problems, ha ha ? i wonder does it work both ways? ill try but i doubt, but if so, then .vhd appears to behave in same way as .img.

so yeah, i did rename it to original .vhd and vbox runs win no probs, then that very .vhd image created by vbox i did again rename to .img and run on PCem , no probs. Then i left that img and try to mount it in vbox without renaming that file, although vbox 4.1 in linux have no .img option so i chose "show all files" and select that .img, and it accept it no probs, and now i can run one img file in PCem and vbox at the same time. cool. But each time i start win then of course few drivers must reinstall as they are different machines. so whats the problem? whats the difference if .vhd after renaming to .img runs in PCem and in vbox?
i wonder , does .img created by PCem run in vbox , same way?
Will see later, but now i did checked one more thing, PCem have only .img option but after choosing "show all files" i can select .vhd and PCem accept it without a word and it boot up without even rename the file.
I used 2GB vhd file from vbox and PCem get it as S63 H16 Cyl.4214 size 2074mb.
So what are really the differences between .img and .vhd?

The only difference between the IMG files that PCEM creates (they are raw disk images), and (fixed) VHD files is that VHD files have a 512 byte footer appended to the end of the file.

My only worry with using VHD files with PCEM is if PCEM decides to write some data at the very end of the disk image. It could potentially overwrite the footer.

aha, thanks, so only if i use the vhd extensively in PCem it might get unusable by Vbox, i tried original PCem .img in vbox, and it could not get storage format from the file.
conclusion? .vhd can be used by PCem with caution.
I wonder, could anyone of you guys try to "teach" PCem to do not write on this last 512 bytes? only if PCem could read each time proper geometry from .vhd.
Ill try to fill this disk to full in PCem and see what Vbox will say.

so Vbox didnt accept the small 256MB img file created by PCem, so I did fill up the 2GB disk to full under DOS and place it in Vbox, it still accept the disk but it was:
FATAL : Could not read from the boot medium! system halted.
So yeah, probably that was footer fault. Still , you can use .vhd with OS created in Vbox in PCem, but not other way around, at lest in my case on 2GB fixed .vhd .

A really good feature that would help to install new files into the emulator could be the ability to have an emulated drive linked to a specific folder into a host drive.
That would be a huge help, since what I do now to inject files into the emulated HD is to open the virtual HD with WinImage, but this is big pain...
What do you think Sarah?

SarahWalker wrote: ↑Tue 24 Feb, 2015 6:36 pm I didn't support the VHD format because I'd never heard of it! Just had a look at the specification, looks like the fixed size format shouldn't be too difficult to support.

Sarah, I was wondering if you have given more consideration to this, as much as I know that the new dynarec will probably occupy close to 100% of the efforts for V15.
Omarsis' suggestion is also good, I think there's a lot of people out there who are keeping double copies of their DOS collections, one in an image - for use with PCem, and one as a plain directory, for use with DOSBox.

Generally speaking, I think HDD management is one of the main adoption barriers for non-sophisticated users, would be nice to take that down.

Sorry, there's always a huge number of other things that need doing, so this request keeps slipping.

Does anyone else fancy implementing it? It shouldn't need any real knowledge of the emulator code - all the hard disc image code is abstracted into hdd_file.c so shouldn't need to touch much other code.

SarahWalker wrote: ↑Tue 29 May, 2018 4:53 pm Sorry, there's always a huge number of other things that need doing, so this request keeps slipping.

Does anyone else fancy implementing it? It shouldn't need any real knowledge of the emulator code - all the hard disc image code is abstracted into hdd_file.c so shouldn't need to touch much other code.

Actually, looking at hdd_file.c, I don't see anything that requires changing there. VHD (fixed) is simply a raw disk image with a 512 byte footer. The afore mentioned code seems to work purely with CHS.

What might need changing is the code that calculates CHS (VHD stores this information, so can be read instead of calculated). If I can find the source files, I'll take a stab, although I'm not overly confident with C.

EDIT: It's going to be buried in the WX code isn't it....?

Ugh... wx-config.c is not... pleasant.

Unfortunately, that seems to be the file one would need to modify to add VHD support. I shall see if I can figure out what needs to be added.

I _think_ that you need to modify hd_file() - if the image is a VHD, then skip the call to check_hd_type() and HdSizeDlg, and instead load the CHS data from the VHD footer.

Sarah, is there an endian function floating around in PCem already (that doesn't rely on networking support)?

The VHD footer stores it's values in big endian, which I will need to handle in some manner.

Not that I can think of I'm afraid.

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!)

And initial VHD support has been implemented. See => viewtopic.php?f=4&t=3044