79 replies to this topic

[Wonko the Sane]

re.

write --offset=32284 --bytes=4 (hd0,4)/windows311flat.raw \x3F\x00\x00\x00

 

I think if you use bytes=x then it expects bytes, otherwise it expects 32-bit value, try maybe...

 

write --offset=32284 (hd0,4)/windows311flat.raw 0x3f

 

would write 4 bytes.

No, the issue is that it writes the 0x3F as string.

 

And since it seems like noone is anymore trusting me on my word attached the usual .gif.

 

Wonko

Attached Thumbnails

• 

[steve6375]

Sorry, my mistake

 

write 0x60000 0x55aa  works and writes 00 00 00 3f

write (md)0x300+1 0x55aa writes 6 bytes

 

I have reported an issue and asked for help text to be clarified.

https://github.com/c...4dos/issues/171

[Wonko the Sane]

Sorry, my mistake
 
write 0x60000 0x55aa  works and writes 00 00 00 3f
write (md)0x300+1 0x55aa writes 6 bytes
 
I have reported an issue and asked for help text to be clarified.
https://github.com/c...4dos/issues/171

Well, if you issue the command:

write 0x60000 0x55aa 

and the result is that 00 00 00 3F is written, then there is a problem.
 

 

Wonko

[MichaelWeaser]

I am having no luck with getting wfw 3.11 working with partition made by partnow , and I followed Wonko the Sane's instructions exactly. I mounted with partnow (hd0,1) 0x06 (hd0,0)4064+201537 , Should be correct on the left because of how the disk.raw file with wfw 3.11 installed is 5052+201600 when I use blocklist. I also made the partition (hd0,0) hidden , this makes the (hd0,1) partition the main C: which should make it bootable with ms-dos , when I do chainloader (hd0,1)/io.sys , it works successfully and it says it will boot MS-DOS, but when I type in boot this blinks _ and it won't boot at all just freezes at _ blinking. I am sure there is nothing with the wfw 3.11 disk image.

 

Also another question for Wonko the Sane. I am thinking I am wrong about what partnow does , I thought it made a new partition for (hd0) and than mounted a image file to it virtually like mounting an image with map , but I am sure I am wrong about this  , I now believe partnow makes a new partition and writes a image to (hd0) directly . I found this out after rebooting and (hd0,1) was still there and it had the contents of the windows 3.1 disk it in.

[Wonko the Sane]

The command is partnew (not partnow).

 

If the file extents of the file (hd0,0)/disk.raw (from blocklist command) is (hd0,0)5052+201600 you need to operate as follows.

The output of blocklist is:

(<partition>)<offset>+<length>

partition is (hd0,0)

offset is 5052

length is 201600

 

Now you need to ADD to  <offset> the number of "hidden sectors" or "sectors before" in the image (or if you prefer the offset to the PBR inside the image) and to SUBTRACT from <length> the same.

In the case of 63 "sectors before" (which is the default if the image was partitioned under DOS) you will have:

newoffset=5052+63= 5115

newlegth=21600-63=201537

 

You can verify that you got the right offset by running the command:

cat --hex (hd0,0)5115+1

that should show the PBR, beginning with an EB3C90 jump, and ending with 55AA.

 

If you run:

cat --hex --length=32 (hd0,0)5115+1

you should see the first two 16-byte rows of the PBR, of which the last four bytes are the "hidden sectors" or "sectors before", normally "3F 00 00 00"= 0x0000003F=0x3F=63

 

Then you ran the partnew command, which syntax is:

partnew (<partition>) <parttype> <begin> <length>

or

partnew (<partition>) <parttype> <contiguous extent>

 

partition is (hd0,1) , i.e. second slot in the partition table of first disk

parttype is 0x06 

begin is the partition and the new offset, i.e. (hd0,0)5115

length is the new length 201537

(hd0,0)5115+201537 is the contiguous extent

 

the command line that becomes:

partnew (hd0,1) 0x06 (hd0,0)5115+201537

 

The blinking cursor is typical of an issue with the bootsector/wrong offset, unless you made a typo in the above post, you have made some wrong calculations and used a wrong offset, try again.

It is also possible that during your attempts some field/byte in the bootsector was accidentally changed.

Since you had the image working with --mem mapping, try it again as follows:

map --mem (hd0,0)/disk.raw (hd0)

map --hook

root (hd0,0)

chainloader +1

boot

 

Wonko

[MichaelWeaser]

The command is partnew (not partnow).

 

If the file extents of the file (hd0,0)/disk.raw (from blocklist command) is (hd0,0)5052+201600 you need to operate as follows.

The output of blocklist is:

(<partition>)<offset>+<length>

partition is (hd0,0)

offset is 5052

length is 201600

 

Now you need to ADD to  <offset> the number of "hidden sectors" or "sectors before" in the image (or if you prefer the offset to the PBR inside the image) and to SUBTRACT from <length> the same.

In the case of 63 "sectors before" (which is the default if the image was partitioned under DOS) you will have:

newoffset=5052+63= 5115

newlegth=21600-63=201537

 

You can verify that you got the right offset by running the command:

cat --hex (hd0,0)5115+1

that should show the PBR, beginning with an EB3C90 jump, and ending with 55AA.

 

If you run:

cat --hex --length=32 (hd0,0)5115+1

you should see the first two 16-byte rows of the PBR, of which the last four bytes are the "hidden sectors" or "sectors before", normally "3F 00 00 00"= 0x0000003F=0x3F=63

 

Then you ran the partnew command, which syntax is:

partnew (<partition>) <parttype> <begin> <length>

 

partition is (hd0,1) , i.e. second slot in the partition table of first disk

parttype is 0x06 

begin is the partition and the new offset, i.e. (hd0,0)5115

length is the new length 201537

 

there is no "+" sign in the command line that becomes:

partnew (hd0,1) 0x06 (hd0,0)5115 201537

 

The blinking cursor is typical of an issue with the bootsector/wrong offset, unless you made a typo in the above post, you have made some wrong calculations and used a wrong offset, try again.

It is also possible that during your attempts some field/byte in the bootsector was accidentally changed.

Since you had the image working with --mem mapping, try it again as follows:

map --mem (hd0,0)/disk.raw (hd0)

map --hook

root (hd0,0)

chainloader +1

boot

 

Wonko

 

Yes I typoed a bit. 

 

I meant to say when I do blocklist /disk.raw, it says the file is 4001+201600, so the 4064 and 201537 is correct for the partnew command. I try to boot it it still does the _ blinking , but a copy of disk.raw file that isn't edited by partnew , still boots fine with : 

 

map --mem (hd0,0)/disk.raw (hd0)

map --hook

root (hd0,0)

chainloader +1

boot

 

So either there is something wrong with the file , or the 63 sectors before isn't correct for the image? 

[Wonko the Sane]

So either there is something wrong with the file , or the 63 sectors before isn't correct for the image? 

 

Yep, check with:

cat --hex --skip=446 --length=66 (hd0,0)/disk.raw

or:

map --mem (hd0,0)/disk.raw (hd0)

map --hook

cat --hex --skip=446 (hd0)0+1

 

This will print out the contents of the partition table of the image.

the first eight bytes are status, partition id and chs values, the last two sets of four bytes are the LBA addresses, the first 4 are offset to the PBR, the second set are length, example:

80 01 01 00 06 0F 3F 4E 3F 00 00 00 D1 36 01 00

 

3F 00 00 00=0x0000003F=63

D1 36 01 00=0x000136D1=79569

 

Wonko

[MichaelWeaser]

Yep, check with:

cat --hex --skip=446 --length=66 (hd0,0)/disk.raw

or:

map --mem (hd0,0)/disk.raw (hd0)

map --hook

cat --hex --skip=446 (hd0)0+1

 

This will print out the contents of the partition table of the image.

the first eight bytes are status, partition id and chs values, the last two sets of four bytes are the LBA addresses, the first 4 are offset to the PBR, the second set are length, example:

80 01 01 00 06 0F 3F 4E 3F 00 00 00 D1 36 01 00

 

3F 00 00 00=0x0000003F=63

D1 36 01 00=0x000136D1=79569

 

Wonko

 

Ok , it seems to be correct, so I don't still know what is wrong. 

 

[Wonko the Sane]

Good, not only you have the 63 sectors before but the 0x00031341 confirms the length of 21537 sectors.

 

Check the PBR

cat --hex --skip=32256 --length=32 (hd0,0)/disk.raw

 

Then try again, make a new copy of the disk.raw from the original (the one that works with --mem mapping), just to exclude some corruption due t previously executed commands, be very careful, maybe i was just a typo in the commands you issued.

 

Wonko

[MichaelWeaser]

Good, not only you have the 63 sectors before but the 0x00031341 confirms the length of 21537 sectors.

 

Check the PBR

cat --hex --skip=32256 --length=32 (hd0,0)/disk.raw

 

Then try again, make a new copy of the disk.raw from the original (the one that works with --mem mapping), just to exclude some corruption due t previously executed commands, be very careful, maybe i was just a typo in the commands you issued.

 

Wonko

 

The PBR looks fine.  the copy I have that isn't edited by partnew , it does the same thing when I try it again with partnew. Also I found out with the image edited by partnew  and not the original copy , it boots with map --mem (hd0,0)/disk.raw (hd0,0), as well as the unedited image. 

 

[Wonko the Sane]

The PBR looks fine.  the copy I have that isn't edited by partnew , it does the same thing when I try it again with partnew. Also I found out with the image edited by partnew  and not the original copy , it boots with map --mem (hd0,0)/disk.raw (hd0,0), as well as the unedited image. 

 

You cannot map to (hd0,0) AFAIK/AFAICR, I believe it is exactly the same as map --mem (hd0,0)/disk.raw (hd0).

 

Whether it boots or not, may depend from what you are booting, and if the thing is mapped to memory behaviour may change (the image is - I believe - patched in memory), in theory and generically (but it may depend on OS).

If you:

root (hd0,0)

chainloader +1 <- i.e chainloading the bootsector

boot

it shouldn't boot (because the offset in the PBR is needed).

 

If you:

root (hd0,0)

chainloader /io.sys <- or anyway chainloading the loader bypassing the bootsector

boot

it may boot fine (because the PBR is bypassed).

 

But the screenshot you posted is NOT ok.

The sectors before in that are 0x0000101F i.e. 4127

 

You stated that the blocklist command gave you 4001+201600, so the correct values for the partnew command are 4064 and 201537, while evidently you used 4127 in the partnew command for offset.

 

Can you post the EXACT partnew command you are issuing?

 

Wonko

Edited by Wonko the Sane, 21 March 2018 - 10:52 AM.
Barking up the wrong tree

[MichaelWeaser]

You cannot map to (hd0,0) AFAIK/AFAICR, I believe it is exactly the same as map --mem (hd0,0)/disk.raw (hd0).

 

Whether it boots or not, may depend from what you are booting, and if the thing is mapped to memory behaviour may change (the image is - I believe - patched in memory), in theory and generically (but it may depend on OS).

If you:

root (hd0,0)

chainloader +1 <- i.e chainloading the bootsector

boot

it shouldn't boot (because the offset in the PBR is needed).

 

If you:

root (hd0,0)

chainloader /io.sys <- or anyway chainloading the loader bypassing the bootsector

boot

it may boot fine (because the PBR is bypassed).

 

But the screenshot you posted is NOT ok.

The sectors before in that are 0x0000101F i.e. 4127

 

You stated that the blocklist command gave you 4001+201600, so the correct values for the partnew command are 4064 and 201537, while evidently you used 4127 in the partnew command for offset.

 

Can you post the EXACT partnew command you are issuing?

 

Wonko

 

No I never used 4127 as the offet for partnew, you are right its 4064 and 201537 and  that is what I am using......

 

The command I am using is Partnew (hd0,2) 0x06 (hd0,0)4064+201537. Don't know how the number is 4127 when I am 100% sure I am using 4064, Hopefully the issue is caused by a bug in the lastest grub , I am using the latest grub version released march 15th, of this year.

[Wonko the Sane]

There have been a few reports of newish (2018) builds having some "queer" behaviour.

 

For the sake of the experiment, try using the same (intentionally) old build I am using:

http://grub4dos.chen....6a-2017-08-30/

 

Or try using:

partnew (hd0,2) 0x06 (hd0,0)4001+201600

in your current version, maybe there has been a change and the 63 value is auto-calculated (but it sounds strange to me ).

 

Wonko

Edited by Wonko the Sane, 21 March 2018 - 10:51 AM.
Barking up the wrong tree

[MichaelWeaser]

There have been a few reports of newish (2018) builds having some "queer" behaviour.

 

For the sake of the experiment, try using the same (intentionally) old build I am using:

http://grub4dos.chen....6a-2017-08-30/

 

Or try using:

partnew (hd0,2) 0x06 (hd0,0)4001+201600

in your current version, maybe there has been a change and the 63 value is auto-calculated (but it sounds strange to me ).

 

Wonko

on the new grub4dos 2018 version - partnew (hd0,2) 0x06 (hd0,0)4001+201600 , of course it doesn't work 

 

even using the grub that you are using, still the same issue, I am thinking there is something wrong with my image........????? even though it boots fine when not using it with partnew? 

 

 

[Wonko the Sane]

That is something strange.

 

I take back the note about the 4127 (additional 63 sectors before?. : my bad, now that I see the sequence of commands together it was OK.

 

The last two screenshots you posted are fine , the hidden sectors are correctly changed from 0x3F (63 relative to the beginning of the image) to 0x2FF (767, i.e. 704, offset of the beginning of the file relative to the beginning of the partition (hd0,0) +63, offset of the partition (hd0,0) from the MBR of the whole disk).

 

I don't think it can be the image, everything seems fine, the bootsector is found ok and patched ok.

 

Maybe it is the specific virtualbox version?

 

Or the way you are setting it that makes a difference?

 

What are you using as "outer image", a .vmdk image?

 

Since the issue seems like being only the DOS booting (till now) I can make a quick DOS only image so that you can try it.

 

Give me some time and I'll post a tested small image.

 

Wonko

 

p.s.: attached.

It contains a .vmdk and a grub4dos floppy image to be used for booting.

It has a (hd0,0) type 0x14 containing a TestDOS.raw image which has been already partnewed to (hd0,1) of type 0x04.

The TestDOS.raw contains only io.sys, command com, msdos.sys and drvspace.bin

Attached Files

•  OuterDos.zip   976.13KB   294 downloads

[MichaelWeaser]

That is something strange.

 

I take back the note about the 4127 (additional 63 sectors before?. : my bad, now that I see the sequence of commands together it was OK.

 

The last two screenshots you posted are fine , the hidden sectors are correctly changed from 0x3F (63 relative to the beginning of the image) to 0x2FF (767, i.e. 704, offset of the beginning of the file relative to the beginning of the partition (hd0,0) +63, offset of the partition (hd0,0) from the MBR of the whole disk).

 

I don't think it can be the image, everything seems fine, the bootsector is found ok and patched ok.

 

Maybe it is the specific virtualbox version?

 

Or the way you are setting it that makes a difference?

 

What are you using as "outer image", a .vmdk image?

 

Since the issue seems like being only the DOS booting (till now) I can make a quick DOS only image so that you can try it.

 

Give me some time and I'll post a tested small image.

 

Wonko

 

p.s.: attached.

It contains a .vmdk and a grub4dos floppy image to be used for booting.

It has a (hd0,0) type 0x14 containing a TestDOS.raw image which has been already partnewed to (hd0,1) of type 0x04.

The TestDOS.raw contains only io.sys, command com, msdos.sys and drvspace.bin

Yup your image totally works fine for me, I know you had a (hd0,1) already on (hd0) which was from partnew command, so I deleted the partition and redid the partnew command myself to see if I can get it to work , it works for me . Now its time to figure out why my image refuses to boot. 99% sure it has something to do with my image, maybe it has to with my VHD?  . I am going to make a new set of images and not use a VHD image this time. Time to go to diagnose my problem

[MichaelWeaser]

Wonko the Sane , I found the problem...... and it involves VHDs I think..... If I use a raw image and a VMDK descriptor file with my disk.raw in it and not a VHD image with my disk.raw image it works and boots fine with partnew. VHDs must not like a partition added to it using partnew. Why do you think VHD's cause the problem with a partnew created partition?

[Wonko the Sane]

Maybe your .vhd image is "Dynamically allocated" (as opposed to "Fixed Size")?

 

For the record only, and besides this current "strange" issue, "dynamically allocated" is one among the most silly provisions IMHO.

 

It makes a lot of sense (like "sparse" files) if you want to quickly test something so big that you don't have enough space on current online storage, and - to a certain extent - it is "smart" for copying (though an empty "fixed size" image/file compresses very well as a .zip or .7z archive), but otherwise it is only a possible avenue for troubles.

 

I mean, if you fill the dynamic image, it will expand, eventually up to the max size (and then it will occupy the same space as the fixed size one), and if you don't fill it, it means that you don't need such a large image and you can do with a smaller "fixed size" one.

 

A .vhd of the "fixed size" type should be just fine, in itself it is just a RAW image with a single sector appended.

 

It is also possible that *somehow* Virtualbox specifically mounts somehow differently a "fixed size" .vmdk (i.e. a monolithic flat) from how it mounts a "fixed size" .vhd, but I don't think so.

 

Wonko

[MichaelWeaser]

Maybe your .vhd image is "Dynamically allocated" (as opposed to "Fixed Size")?

 

For the record only, and besides this current "strange" issue, "dynamically allocated" is one among the most silly provisions IMHO.

 

It makes a lot of sense (like "sparse" files) if you want to quickly test something so big that you don't have enough space on current online storage, and - to a certain extent - it is "smart" for copying (though an empty "fixed size" image/file compresses very well as a .zip or .7z archive), but otherwise it is only a possible avenue for troubles.

 

I mean, if you fill the dynamic image, it will expand, eventually up to the max size (and then it will occupy the same space as the fixed size one), and if you don't fill it, it means that you don't need such a large image and you can do with a smaller "fixed size" one.

 

A .vhd of the "fixed size" type should be just fine, in itself it is just a RAW image with a single sector appended.

 

It is also possible that *somehow* Virtualbox specifically mounts somehow differently a "fixed size" .vmdk (i.e. a monolithic flat) from how it mounts a "fixed size" .vhd, but I don't think so.

 

Wonko

I looked at my original VHD, it is indeed a fixed size VHD, but also I remember it was a 1GB disk, and with a little bit of messing around , I think a large sized VHD possibly don't work correctly with partnew? for the windows 3.1 raw disk image, its about a 100MB disk image , so I made a  new 150MB VHD with the windows 3.1 disk image in it and with partnew it worked flawlessly and booted. I checked to see if a 1GB VHD might cause an issue, I think it does, making a 1GB VHD, adding the 100MB windows 3.1 image , and partnew command, going to boot it just blinks at _, so my suspicion is there is an issue with large sized VHDs and partnew??? I need to check this issue out with large sized raw images and a VMDK descriptor file, if I can replicate the same issues with VHDs. 

[MichaelWeaser]

Wonko the Sane , 

 

Little update , I tried to replicate the issue with a 1GB large raw file and The same thing that happens with a VHD, I can replicate exactly. Mount a 1GB image raw image with VMDK descriptor, with the 100MB windows 3.1 raw image in it, use partnew (hd0,1) 0x06 (hd0,0)xxx+xxxxx , use chainloader, use the command boot and it gets stuck with _ . Possible bug with partnew and high capacity disks? 

Edited by MichaelWeaser, 21 March 2018 - 05:12 PM.

[Wonko the Sane]

I looked at my original VHD, it is indeed a fixed size VHD, but also I remember it was a 1GB disk, and with a little bit of messing around , I think a large sized VHD possibly don't work correctly with partnew? for the windows 3.1 raw disk image, its about a 100MB disk image , so I made a  new 150MB VHD with the windows 3.1 disk image in it and with partnew it worked flawlessly and booted. I checked to see if a 1GB VHD might cause an issue, I think it does, making a 1GB VHD, adding the 100MB windows 3.1 image , and partnew command, going to boot it just blinks at _, so my suspicion is there is an issue with large sized VHDs and partnew??? I need to check this issue out with large sized raw images and a VMDK descriptor file, if I can replicate the same issues with VHDs. 

Maybe the issue is connected with the 504/528 MB "first" CHS limit:

http://www.pcguide.c...izeMB504-c.html

 

A BIOS would normally see anything smaller than that limit as having a H/S geometry of 16/63 and anything bigger than that as having a 255/63.

 

Check (issuing the geometry command like "geometry (hd0)" ) if the disk (the "main" one) is seen as 16/63 or as 255/63.

 

DOS, AFAICR, uses CHS (and not LBA) for booting, that could be the issue.

 

The "inner image" bootsector has definitely 16 heads, whilst the "outer image" possibly has 255.

 

So the partnew command did correct the "sectors before" (which is essentially a LBA field) but did nothing with the filesystem geometry, that doesn't match, and MS-DOS is "sensible" to that[1].

 

The field "heads" in the PBR is at relative offset 0x1A, it is 0x0010 (i.e. 16) in the screenshot you posted at #35.

 

You could try, after having created the new partition entry on your original, "large" VHD, to change it to 0x00FF (255).

 

Wonko

 

[1] Most later systems simply ignore the CHS and use LBA only, but a similar issue happens/happened with NT bootsectors for FAT32 and NTFS, JFYI:

https://web.archive....ic=21702&st=129

 

since NT systems do not use CHS for booting, the bootsector won't boot, but bypassing it invoking NTLDR worked.

[karyonix]

Does geometry (hd0) after hook match geometry of inner image when DOS/Windows partition was created ?

map command has --heads=number and --sectors-per-track=number parameters you may try when you map the inner image.

[MichaelWeaser]

Maybe the issue is connected with the 504/528 MB "first" CHS limit:

http://www.pcguide.c...izeMB504-c.html

 

A BIOS would normally see anything smaller than that limit as having a H/S geometry of 16/63 and anything bigger than that as having a 255/63.

 

Check (issuing the geometry command like "geometry (hd0)" ) if the disk (the "main" one) is seen as 16/63 or as 255/63.

 

DOS, AFAICR, uses CHS (and not LBA) for booting, that could be the issue.

 

The "inner image" bootsector has definitely 16 heads, whilst the "outer image" possibly has 255.

 

So the partnew command did correct the "sectors before" (which is essentially a LBA field) but did nothing with the filesystem geometry, that doesn't match, and MS-DOS is "sensible" to that[1].

 

The field "heads" in the PBR is at relative offset 0x1A, it is 0x0010 (i.e. 16) in the screenshot you posted at #35.

 

You could try, after having created the new partition entry on your original, "large" VHD, to change it to 0x00FF (255).

 

Wonko

 

[1] Most later systems simply ignore the CHS and use LBA only, but a similar issue happens/happened with NT bootsectors for FAT32 and NTFS, JFYI:

https://web.archive....ic=21702&st=129

 

since NT systems do not use CHS for booting, the bootsector won't boot, but bypassing it invoking NTLDR worked.

You said to change the heads from 16 to 255 and so I did and yes it does work, now it boots ms-dos on (hd0,1) on a 1GB sized disk. So the 1st CHS Limit is the cause.

[Wonko the Sane]

Does geometry (hd0) after hook match geometry of inner image when DOS/Windows partition was created ?

map command has --heads=number and --sectors-per-track=number parameters you may try when you map the inner image.

There isn't a map command till now, but that could be a good idea  , though most probably (cannot really say) the map command will work fine for the MS-DOS BUT will re-introduce the Windows 3.11 issue (which I confirmed while having both the "inner" and "outer" image with the same 16/63 geometry).

 

If you prefer, the partnew was introduced as a workaround for Windows 3.11booting issue, and it was introduced to replace the map command (that worked for MS-DOS but didn't for Windows 3.11).

 

Results till now:

map --mem <- BOTH MS-DOS and Windows 3.11 work <- tested by both Wonko and Michael

 

map (on same geometry) <- MS-DOS works but Windows 3.11 doesn't <- tested by Wonko

map (on mismatching geometry)  <- MS-DOS works but Windows 3.11 doesn't <- tested by Michael

 

partnew (on same geometry) <- BOTH MS-DOS and Windows 3.11 work <- tested by Wonko

partnew (on mismatching geometry) <- MS-DOS doesn't work <- tested by Michael

partnew (on mismatching geometry) with additional correction of heads <- <- BOTH MS-DOS and Windows 3.11 work <- tested by Michael

 

You said to change the heads from 16 to 255 and so I did and yes it does work, now it boots ms-dos on (hd0,1) on a 1GB sized disk. So the 1st CHS Limit is the cause.

Good.

We are now at an almost normal improbability level of two to the power of two hundred and seventy-six thousand to one against and falling, and we will be restoring normality just as soon as we are sure what is normal anyway.  . 

Wonko

[MichaelWeaser]

Of course it's kinda false that windows 3.1 will not work with map (hd0,0)/xxx.raw (hdx) , In standard mode it works fine , it's caused by 386 enhanced mode. The way that grub4dos virtualizes things probably is what causes the problem when windows is attempted to run in 386 enhanced mode. Probably Microsoft had to disable a few things in 386 enhanced mode from standard mode when windows 3.1x ran in enhanced mode, maybe to keep it more secure , less buggy. So I am 99% sure that grub4dos needs something from the standard mode ( original 286 protected mode) and because its not there in 386 enhanced mode , Windows 3.1 in enhanced mode won't work with grub4dos.

 

standard mode is the original protected mode introduced in the 286.

386 enhanced mode is the same protected mode but intel added stuff when they introduced the 386. 

 

what versions of windows 3.1 supports which mode ?

 

standard mode - all versions except windows for workgroups 3.11 , so that is 3.1, 3.11, and the first version of windows for workgroups 3.1 

386 enhanced mode - all versions 

 

Why doesn't Windows for workgroups 3.11 no longer support standard mode. the original windows for workgroups 3.1 , Microsoft found it to be buggy when you ran networking in standard mode , so when it got released standard mode worked but networking support was totally disabled when it ran. So when it got updated and windows for workgroups 3.11 was released microsoft decided to only allow it to run in 386 enhanced mode and wouldn't allow it to go into standard mode.