You should mention it in the readme/internal command help. Usually the defaults are mentioned.

Impressing lesson of yours,Mirekluza.Please,be patient to the doubts of a ignorant.
When you said d:d:\dosbox - this dosbox is the program dosbox,a x86 emulator... ,or just a directory you created to have the images?
Running FDISK creates a new partition;if I correctly understood,a permanent change in the real harddisk;like a new hard drive (is that?).And this new "disk" is C: . But I already have a harddisk C: ,where it is all the system things,like win xp prof.sp2,office,dosbox,acrobat and so on.
So,there is no danger that a program,begining with the FORMAT C: /s,goes to the wrong C: ?
Or,is it your wise advice that a ignorant's hands should be far from images?
Thanks in advance.
Best regards

d:\dosbox is just my directory for DOSBOX related things. you can name it as you want.

FDISK makes a new partition. But you must realize that you do not run it on your own physicall disc, but on the hd image (which is represented by one file on your disk (for example c.img or my_disc.img etc.).

Your physical disc and the hard disc image are two completely different things, so you can format/fdisk on a hard disk image as you want without destroying anything on your real disc.
You cannot get to your real physical disc C: when booting another DOS version in DOSBOX. You have access only to a hard disc image with this name (which is represented by one file in reality).
In short: there is no C: like C: . 😀

Mirek

Thanks,Mirekluza,for your quick answer and help.
Best regards,

I come back a few days later, and there's been an explosion of posts 😀 I've registered now as Pan, the guest who posted as Pan and myself are the same person.

MiniMax, I'm sorry about the documentation, I wasn't here and so I didn't see your request. I have now read the documentation, and believe it contains some mistakes.

Examples 3 and 4 show this.

C:\>imgmount c harddisk.img -size 512,63,16,142 -fs fat -t hdd

I believe it should be:

C:\>imgmount 2 harddisk.img -size 512,63,16,142 -fs none -t hdd

The approach currently documentated doesn't work for me, only this replacement.

Other people have reported that MS-DOS 6.22 FDISK works for them. I managed to get an MS-DOS 5.00 boot disk and guess what...

When I'm creating a partition, I get:

run-time error R6003
- integer divide by 0

Standard DOS error, but strange as nobody else gets....

Anybody have any ideas on that front?

Thanks

Pan

About FDISK:
I tried versions MS DOS 5.0/6.0/6.22 without any problems - always creating one primary partition taking the whole free space.
Just remember that rebooting afterwards does not work (crashes or freezes) - when FDISK wants to reboot, end the DOSBOX (by CTRL F9) and start it again (FDISK is already finished).
There is a sample of how it worked for me in DOSBOX Guides forum.

Mirek

Yeah, thanks Mirek. But I don't get that far. As soon as I click on create new partition, I get the error. Really not sure what causes it. I'll give disk explorer a go and see if that works.

I think the boot options in Dosbox are pretty unstable as present. Hopefully it'll get more stable as time goes on.

Pan

I simply can't get it to work. I have now also tried bximage from Bochs, which has been reported to work. Unfortunately I still get the divide by zero error. I think this may be a bug in the Debian version of Dosbox. I'll report it to the package maintainer.

Thanks for all your help.

Pan

I'd like to modify the Wiki documentation to take into account the changes I previously specified. I believe the current documentation is incorrect. Can anybody confirm my findings before I make any changes? I don't want to make the changes and then find they were right to begin with 😀

Thanks

Pan

uhm when speaking about fs fat you allready have a fdisked drive and therefore
imgmount C harddisk.img ......
is correct.

Oops, yes, quite right. It seems the documentation is correct after all. Thanks Qbix 😀

I should add that the problem I was previously suffering with disk images has been resolved. A discussion containing relevant information regarding this issue can be found at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284500.

Regards,

Pan