Windows for Workgroups 3.11, grub4dos and protected mode......

I just realized I forgot about something with WFW 3.11 , it requires protected mode to run, so that means mounting a hard drive image with wfw 3.11 with grub4dos , and attempting to boot it will not allow WFW 3.11 to load. I know I tried it.....  windows 3.11 gives a can't find krnl386.exe error , than running it alone it tells about can't run in protected mode. So is there away to get it to work by passing it to a ram disk driver? If it's possible for it to work with a Windows NT based OS the same way, to pass it to a Ram Disk driver, than it might as well work for my problem.

I tried it with the standard windows 3.1, and it seems to work fine and goes into some sort of protected mode?  I know it will go into standard mode and I found out it will go into 386 enhanced mode as well? Isn't standard mode and 386 enhanced mode a type of protected mode? So really should WFW 3.11 be working? I can't figure out why the kernel does a protected mode error, if the standard windows 3.1 works fine.

Actually I was playing with settings and this all has to do with --mem setting in grub4dos , 386 enhanced mode will not work at all on both versions if the drive is mounted directly , if indirectly mounted with --mem it works. So I had to had to be using --mem when I tried standard windows 3.11 since it worked fine with the 386 enhanced mode, oops didn't remember what settings I was trying. But Something I don't get is how does direct mapping work with the standard windows 3.1 in standard mode. Standard mode is a type of protected mode, just like 386 enhanced mode is.

Try the --in-situ option of the map command, like this:

map --in-situ (hd0,4)/Win.img (hd0) # Note that Win.img should be a partition image(without the leading MBR track).
map --hook
chainloader (hd0)+1 # or try chainloader (hd0,0)+1 which is the first sector of Win.img
rootnoverify (hd0)
boot

 

Try the --in-situ option of the map command, like this:

map --in-situ (hd0,4)/Win.img (hd0) # Note that Win.img should be a partition image(without the leading MBR track).
map --hook
chainloader (hd0)+1 # or try chainloader (hd0,0)+1 which is the first sector of Win.img
rootnoverify (hd0)
boot

--in-situ does not work it just blinks this _ when it tries to boot . Can you explain what it is used for?

--in-situ is useful for Win9x.

map --in-situ only virtualize the partition table. This helps the Win9x disk driver to recognize the mapped virtual drive.

The blinking cursor might indicate the MBR boot record is not functioning.

Try with this: chainloader (hd0,0)+1

You might need to fix your boot record in the beginning sector of Win.img.

You can use a floppy.img to boot into DOS.

map --in-situ (hd0,4)/Win.img (hd0) # Note that Win.img should be a partition image(without the leading MBR track).
map (hd0,4)/floppy.img (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
boot

Under DOS, you can start Windows by running win.com.

Also note that Win.img must be contiguous. Confirm it with this grub4dos command:

blocklist (hd0,4)/Win.img

 

--in-situ is useful for Win9x.

 

map --in-situ only virtualize the partition table. This helps the Win9x disk driver to recognize the mapped virtual drive.

 

The blinking cursor might indicate the MBR boot record is not functioning.

 

Try with this: chainloader (hd0,0)+1

 

You might need to fix your boot record in the beginning sector of Win.img.

 

You can use a floppy.img to boot into DOS.

map --in-situ (hd0,4)/Win.img (hd0) # Note that Win.img should be a partition image(without the leading MBR track).
map (hd0,4)/floppy.img (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
boot

Under DOS, you can start Windows by running win.com.

 

Also note that Win.img must be contiguous. Confirm it with this grub4dos command:

blocklist (hd0,4)/Win.img

yup the image contiguous , but it only does the blinking _ when I use --in-situ , and I think the boot record is fine. it's a 386 enhanced mode problem with direct mount with windows 3.11, indirectly mounting --mem works fine. Standard mode works fine with direct mounting , WFW 3.11 of course can't use standard mode, which I am using. If you want to check the image for me, I can pack up the virtual machine for you.

I am sorry. I am afraid I cannot step further.

I am sorry. I am afraid I cannot step further.

that is fine. But 2 questions for you : 

1: When you talk about windows 98 , Does Windows 98 boot fine from a disk image? 

2: where do you get your grub4dos commands from? when you told me about the --in-situ command , I couldn't find anything about it online. I want to know where you can get an entire list of grub commands. But I believe it is in the grub4dos readme, which I never checked.

emm....

1: Several (I mean ten or more) years ago, I booted win98 from a logical partition with map --in-situ (hd0,4)+1 (hd0). I did not test --in-situ with an image file. But I think it should work similarly, since --in-situ does not distinguish between a partition and an image file. EDIT: I am sorry. Win98 could care whether it is a partition or an image file. So the image with --in-situ could fail for win98.

2: Right, the README, also the source code.

emm....

 

1: Several (I mean ten or more) years ago, I booted win98 from a logical partition with map --in-situ (hd0,4)+1 (hd0). I did not test --in-situ with an image file. But I think it should work similarly, since --in-situ does not distinguish between a partition and an image file. EDIT: I am sorry. Win98 could care whether it is a partition or an image file. So the image with --in-situ could fail for win98.

 

2: Right, the README, also the source code.

I am thinking a directly mounted drive will never work with windows 3.1x with 386 enhanced mode , just has to do with how protected mode works with it. But what I don't get is how does standard mode work fine, since protected and 386 enhanced modes are a type of protected mode. Also in both modes it still depends on the bios to read and write the disk, unless you use a optional 32 bit driver . So 386 enhanced mode should be able to read/write a grub4dos mounted image. it's not like how grub4dos doesn't work with windows xp ( unless you use firadisk) since it does not use the bios at all and has its own 32 bit disk driver. Even though indirectly mounting a image into memory, works 100% fine with 386 enhanced mode. Maybe there is a bug in the virtualbox bios , or even in grub4dos , or windows 3.1x 386 enhanced mode that has to do with writes? 

I think there should be differences between enhanced mode and standard mode. The enhanced mode might expect a 32-bit protected-mode driver for the mapped drive.  I guess win98 also use enhanced mode. You may try Win3.x enhanced mode with --in-situ and a real logical partition and see if it could gain a success.

I think there should be differences between enhanced mode and standard mode. The enhanced mode might expect a 32-bit protected-mode driver for the mapped drive.  I guess win98 also use enhanced mode. You may try Win3.x enhanced mode with --in-situ and a real logical partition and see if it could gain a success.

the 32 bit disk driver is 100% optional , also the 32 bit driver only works with a real IDE controller. the 32 bit disk driver is automatically disabled when you install any windows 3.1x. So there should be no reason why it should not work. I am still working why does 386 enhanced mode works fine with you indirectly mount the drive, but it gives a protected mode error when you direct mount the drive. Still trying to find a solution. 

The issue(or problem) might have something to do with an unknown Windows secret. It should have nothing to do with grub4dos. Grub4dos works in real-mode. That is enough.

The issue(or problem) might have something to do with an unknown Windows secret.

Maybe after all there is *some* quirk in grub4dos when mapping an extent (that somehow Windows 3.11 "notices")? 

Anotther test.

Mapping the whole (hd1) to (hd0) works.

Mapping the extent (hd1)0+79632 to (hd0) doesn't.

I would have thought that the results would have been the same.

Wonko

Maybe after all there is *some* quirk in grub4dos when mapping an extent (that somehow Windows 3.11 "notices")? 

 

Anotther test.

Mapping the whole (hd1) to (hd0) works.

Mapping the extent (hd1)0+79632 to (hd0) doesn't.

I would have thought that the results would have been the same.

 

Wonko

Wow that is odd. so the issue as map (hd1)0+79632 (hd0) is the same as attempting to map a windows 3.1 image to hd0,  hooking it and than loading it since you get the same error as with (hd1)0+79632 (hd0) when trying to load windows 3.1x. There has to be some fix to the issue. 

Try once more with --unsafe-boot and see what would happen.

map --unsafe-boot  (hd1)0+NNNNN  (hd0)

map --hook

chainloader (hd0,0)/io.sys

boot

Try once more with --unsafe-boot and see what would happen.

 

map --unsafe-boot  (hd1)0+NNNNN  (hd0)

map --hook

chainloader (hd0,0)/io.sys

boot

No joy.

Maybe *somehow* the Windows 3.11 checks with direct access something and while the plain re-mapping of a hard disk (such as map (hd1) (hd0)) is only "changing order" of the disk, the re-mapping of an extent creates a "virtual" *something* that is not found/accessed.

Something *like* the above would explain why using a new, "real" partition entry made with partnew works just fine.

In any case - provided that a partition table slot is available - making the partnew entry is IMHO a valid workaround, it is not particularly complex (provided that one knows the offset to the PBR inside the image - the "normal" 63 in my example) and can substract that from the blocklist.

Issuing a partnew (hdx,y) 0 0 0 at next boot will reset the whole stuff in the MBR as before and the "corrected by partnew" "Sectors Before" in the PBR of the image can be if needed be set back to the original (63) via the "write" command.

The offset inside the PBR is 0x1C (28) so, 63*512+28=32284:

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

As a side note, it seems like in 2012 or so the sintax of write has changed (and how it has changed it is not clear in the docs  ) the integer (IMHO) 0x0000003F (or 0x3F) is now treated as a string (or maybe I cannot understand how it works now ).

Wonko 

No joy.

Maybe *somehow* the Windows 3.11 checks with direct access something and while the plain re-mapping of a hard disk (such as map (hd1) (hd0)) is only "changing order" of the disk, the re-mapping of an extent creates a "virtual" *something* that is not found/accessed.

Something *like* the above would explain why using a new, "real" partition entry made with partnew works just fine.

 

In any case - provided that a partition table slot is available - making the partnew entry is IMHO a valid workaround, it is not particularly complex (provided that one knows the offset to the PBR inside the image - the "normal" 63 in my example) and can substract that from the blocklist.

 

Issuing a partnew (hdx,y) 0 0 0 at next boot will reset the whole stuff in the MBR as before and the "corrected by partnew" "Sectors Before" in the PBR of the image can be if needed be set back to the original (63) via the "write" command.

The offset inside the PBR is 0x1C (28) so, 63*512+28=32284:

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

 

As a side note, it seems like in 2012 or so the sintax of write has changed (and how it has changed it is not clear in the docs  ) the integer (IMHO) 0x0000003F (or 0x3F) is now treated as a string (or maybe I cannot understand how it works now ).

 

Wonko 

 I am going to need help learning how to use the partnew command with a disk image Like how you did in that gif . I don't fully understand how to use partnew yet since I am still learning how to use grub4dos. I mainly don't understand how to offset the disk image for partnew. I do understand somewhat how partnew works, it it used to put a image or even a different hard drive and mount it to a virtual partition and adds it to the partition table slot in a totally different real hard drive or image. 

The partnew implies that there is an available "slot" in the MBR partition table.

In the example posted in the testrecordpartnew.gif (attached to post #15 above)  I have a "plain DOS" hard disk MBR with a primary partition (which occupies slot (hd0,0) and a an extended partition (whose entry occupies slot (hd0,1)),

The image is in the first (and only) logical volume (hd0,4).

The image is in root and named windows311flat.raw.

Around 0:35 I run a blocklist command on the image file and obtain:

(hd0,4)249+80640

this means that the image is contiguous, starts at an offset of 249 blocks (sectors) and extends for 80640 blocks (sectors).

Since the image is a hard disk image and its first sector is a MBR (whilst the PBR of the only primary partition in it is at offset 63 sectors inside it) I add 63 to the offset and subtract 63 from the extents, I chose to write to the partition slot (hd0,2) but I could have used (hd0,3) as well.

So I issued the command:

partnew (hd0,2) 0x06 (hd0,4)312+80577

which means map to the third slot in the MBR of first hard disk an entry for a primary volume with partition ID 06 (FAT 16 bit MS-DOS) for the extent with (relative) address starting on (hd0,4) (first logical volume on first disk) at offset 312 blocks (sectors) and 80577 blocks (sectors) long.

Note, when you will attempt to repeat on your VM you will see a message by grub4dos stating that a valid PBR has been found and that partnew corrected the number of hidden sectors (or something similar), I haven't it in the .gif because I had already run the partnew command and the sectors before were already corrected into 0x2CC7 (the absolute address of the PBR).

The correction is automatic and allows the PBR to "find itself", i.e. it will work if you chainload it, but since grub4dos can bypass it and directly chainload the io.sys, it is not really needed in this case, but cannot - I believe - be turned off. (this could be a feature request for the future an optional --leave-PBR-alone switch to partnew).

 

I do understand somewhat how partnew works, it it used to put a image or even a different hard drive and mount it to a virtual partition and adds it to the partition table slot in a totally different real hard drive or image. 

No, partnew is "same disk" only, as essentially it is only a (simple, avoiding a lot of calculations) way to write an address in a partition slot, the partition is not in any way "virtual" it is physically written to the MBR partition table. (and this "being real" is most probably the reason why it works in this case)

It goes without saying that you NEED a backup of the original as until you get the hang of it, partnew  is a "dangerous" (though less than write and dd) command that can make in some cases an unbootable system.

Please note how - before and outside the recorded .gif - I have hidden the primary partition in (hd0,0) setting its parttype to 0x11 (was 0x01) so that the newly created partition entry in (hd0,2) is the first primary (on first disk) and have MS-DOS correct bootbility and drive letter assignment.

Wonko

No joy.

Maybe *somehow* the Windows 3.11 checks with direct access something and while the plain re-mapping of a hard disk (such as map (hd1) (hd0)) is only "changing order" of the disk, the re-mapping of an extent creates a "virtual" *something* that is not found/accessed.

Something *like* the above would explain why using a new, "real" partition entry made with partnew works just fine.

 

In any case - provided that a partition table slot is available - making the partnew entry is IMHO a valid workaround, it is not particularly complex (provided that one knows the offset to the PBR inside the image - the "normal" 63 in my example) and can substract that from the blocklist.

 

Issuing a partnew (hdx,y) 0 0 0 at next boot will reset the whole stuff in the MBR as before and the "corrected by partnew" "Sectors Before" in the PBR of the image can be if needed be set back to the original (63) via the "write" command.

The offset inside the PBR is 0x1C (28) so, 63*512+28=32284:

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

 

As a side note, it seems like in 2012 or so the sintax of write has changed (and how it has changed it is not clear in the docs  ) the integer (IMHO) 0x0000003F (or 0x3F) is now treated as a string (or maybe I cannot understand how it works now ).

 

Wonko 

The picture did not show the case of using --unsafe-boot option.

The picture did not show the case of using --safe-boot option.

Yeah that's confusing that he says he did it but the gif doesn't show it, I already tried it. It does the same thing.

The picture did not show the case of using --unsafe-boot option.

Well, you don't trust my word for it?

I mean, it is not like every statement needs to be accompanied by an animated .gif.

Anyway, here is a new .gif with it.

No difference whatsoever.

Maybe a specific grub4dos version matters?

Wonko

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.