79 replies to this topic

[Wonko the Sane]

Yep, you are correct, we were talking (and tested) Windows 3.11 (for Workgroups), I think there were (even at the time) very few installs of "pure" Windows 3.11, probably only those that got it from MS as an udate to Windows 3.1

 

BUT I am not at all convinced that the 3.11 (for Workgroups) not working is directly connected with protected or enhanced or real mode, as a matter of fact I believe that it is *something else* particularly the "curious" change in the label of the "duplicate" volume makes me think that it is *something else*.

 

I mean, later versions, such as Windows 95/98 should work (at least they worked with earlier 0.4.4 and 0.4.5 versions of grub4dos via the map (or the map --in-situ) commands, and definitely they use protected/enhanced mode.

 

 

Wonko

[MichaelWeaser]

Yep, you are correct, we were talking (and tested) Windows 3.11 (for Workgroups), I think there were (even at the time) very few installs of "pure" Windows 3.11, probably only those that got it from MS as an udate to Windows 3.1

 

BUT I am not at all convinced that the 3.11 (for Workgroups) not working is directly connected with protected or enhanced or real mode, as a matter of fact I believe that it is *something else* particularly the "curious" change in the label of the "duplicate" volume makes me think that it is *something else*.

 

I mean, later versions, such as Windows 95/98 should work (at least they worked with earlier 0.4.4 and 0.4.5 versions of grub4dos via the map (or the map --in-situ) commands, and definitely they use protected/enhanced mode.

 

 

Wonko

Its only one of my theories that *It* could be caused by that, since how does in 386 enhanced mode , that any version of windows 3.1x will not load and gets that kernel/protected mode error , but if it is loaded in standard mode it will load fine and no kernel/protected mode error. You could be right with the change in label of the "duplicate" volume , but the question but why does it only happen when in 386 enhanced mode?? and not in standard mode, It doesn't make any sense for me. Let talk about --in-situ, I have tried mapping a windows 98 image and I could never get it to boot when mapped directly, when I use the command when it attempts to boot it just blinks at _.  But in the readme it says it allows you to map a logical partition as a primary partition as in map --in-situ (hd0,4)+1 (hd0), haven't got the command working yet. TinyBit told me it could work with with windows 3.1 if it's just the partition image without the MBR track, its at post #4. I could never figure out how to just have the partition image without the MBR.

[Wonko the Sane]

 But in the readme it says it allows you to map a logical partition as a primary partition as in map --in-situ (hd0,4)+1 (hd0), haven't got the command working yet. TinyBit told me it could work with with windows 3.1 if it's just the partition image without the MBR track, its at post #4. I could never figure out how to just have the partition image without the MBR.

 

No, it doesn't work with Windows 3.11, I tested it.

But it did work (I tested it a long time ago) with Windows 98.

When you do:

map --in-situ (hd0,4)+1 (hd0)

you are mapping (--in-situ) an extent that is already a volume

With an image off a whole hard disk that would be the same extent you use for partnew (i.e. the blocklist with 63 sectors added at the beginning and 63 sectors removed at the length).

 

Mind you it is possible that with Windows 9x it worked as a logical volume inside extended while - for whatever reasons - mapping the modified blocklist extent doesn't.

 

I believe that - again for *whatever* reasons Windows 3.11 does a direct disk  access of some kind and since the MBR partition table is "emulated" it doesnt like it, whilst with partnew since the "real" MBR partition table is modified, it works.

 

If you want to experiment with a "real" image without the first 63 sectors you simply do a dd copy of the RAW image skipping over the first few sectors.

 

If you are OK with dd it would be:

dd if=original.raw skip=63 bs=512 of=volume.raw

 

Or you can use partcopy:

http://www.virtualob...gs/partcopy.htm

 

or any similar tool, you want everything but the first 63 sectors or 63*512=32256 bytes., I am particularly keen to use (in windows) the dsfok dsfo tool:

http://members.ozema...ware/index.html

because it is minimal and just works.

dsfo original.raw 32256 0 volume.raw

 

Wonko 

[MichaelWeaser]

I believe that - again for *whatever* reasons Windows 3.11 does a direct disk  access of some kind and since the MBR partition table is "emulated" it doesnt like it, whilst with partnew since the "real" MBR partition table is modified, it works.

 

 

Hmm, This gets me thinking , In memory can't you check the drive and check to see the difference in the MBR? You might be able to figure out the problem. than you could maybe edit it or something? If it's the emulated MBR that is causing the problem, it could be an easy fix. 

[Wonko the Sane]

Hmm, This gets me thinking , In memory can't you check the drive and check to see the difference in the MBR? You might be able to figure out the problem. than you could maybe edit it or something? If it's the emulated MBR that is causing the problem, it could be an easy fix. 

Yes and no.

 

Meaning that the BIOS routines (that grub4dos and dos use) are "tricked" by the grub4dos mapping or re-mapping, but a direct disk access using other methods may not be masked.

 

Until you are in grub4dos or dos you are seeing an "altered" reality, if/when some other methods are used  the "real" situation may appear.

 

When everything is memory mapped probably it works because the whole pohysicaldrive is "completely" emulated.

 

The error about krnl386 not found is unfortunately the same to the one occurring if krnl386 is not found for other reasons (like a missing krnl386 in \Windows\System) that has been reported by "real" 3.11 users and was probably due to a number of different reasons.

 

There is still "hope" however for the map --in-situ

 

It seems like the map --in-situ creates a 0x0E type of partition (that MS-DOS 6.x cannot understand), I must try with a DOS 7.x + Win 3.11

 

Wonko

[Wonko the Sane]

There is still "hope" however for the map --in-situ 

 

It seems like the map --in-situ creates a 0x0E type of partition (that MS-DOS 6.x cannot understand), I must try with a DOS 7.x + Win 3.11

Yep, confirmed 

I quickly sys-ed the image from a Win98 floppy (with a patched io.sys):

https://msfn.org/boa...&comment=964141

using the patch by Ralf Buschmann

 

So the issue is that the map --in-situ creates a 0x0E partiton (as opposed to a 0x06).

 

Maybe tinybit   will have an idea how to change the 0x0E to 0x06 (in order to use the plainer DOS 6.22)?

 

Wonko

EDIT: attached animated gif.

Attached Thumbnails

• 

[MichaelWeaser]

Yep, confirmed 

I quickly sys-ed the image from a Win98 floppy (with a patched io.sys):

https://msfn.org/boa...&comment=964141

using the patch by Ralf Buschmann

 

So the issue is that the map --in-situ creates a 0x0E partiton (as opposed to a 0x06).

 

Maybe tinybit   will have an idea how to change the 0x0E to 0x06 (in order to use the plainer DOS 6.22)?

 

Wonko

EDIT: attached animated gif.

 

hmmmm.... I was thinking to use parttype which can change the partition ID, But it doesn't work..... when I do parttype 0x06 it says it set the it from 0x0E to 0x06 successfully when I do a geometry on the disk, it still says its 0x0E. So parttype only works on real hard drives?

[MichaelWeaser]

Wonko the Sane a little update for using parttype : 

 

If you do Map --unsafe-boot --in-situ (hd0,0)xxxx+xxxx (hd0), Parttype kinda works but in a very very very unsuspecting way. when you use parttype 0x06 to change the partition ID, it does something very odd , when you use the map command when the disk image becomes (hd0,0) and the (hd0,0) before the mapping becomes (hd0,1) , this is the odd part when you do parttype 0x06 to the mapped (hd0,0) it doesn't actually change the partition Id in (hd0,0) , the ID stays at 0x0E, but what it does is makes a new partition as in (hd0,3) . So Parttype does not change the Id of (hd0,0) instead it makes another partition of (hd0,3) with the exact contents of (hd0,0) plus the changed ID to 0x06. Oh and another odd thing when you reboot the partition that was (hd0,3) , it becomes a real partition and it contains the contents of the disk image , and if you add something to the  created partition it does get added to the raw image in (hd0,0). It's like using the partnew command , but not being used in this case. 

[Wonko the Sane]

Yep, with --in-situ (loosely) the whole MBR is "replaced" in such a way that it isn't available via parttype or write (but - unlike "plain" mapping - it is "fully available" to the booting DOS).
Of course the thingy is *somewhere* in memory.
There are tens of "advanced tricks" that one can play, but of course that is -by definition - advanced and we need support by tinyibit or some other good grub4dos developer.
I'll check if within the addresses that Steve6375 patiently collected there is one for the map --in-situ but I don't recall to have ever seen one.
 
In a perfect world a possible evolution of grub4dos could allow having a value assigned to --map-in-situ, *like*:
map --in-situ=0x06
 

Wonko

[MichaelWeaser]

 

In a perfect world a possible evolution of grub4dos could allow having a value assigned to --map-in-situ, *like*:

map --in-situ=0x06

 

 

 

 

Another Idea would be an assigned of an LBA partition ID or CHS partition ID as --in-situ=LBA or --in-situ=CHS. I know that 0x0E is fat16 LBA ID, and that 0x06 is a CHS ID . Which ms-dos 6.x only will recognize CHS partition ID's, So the --in-situ=CHS is a good idea as well. Your idea is also great as well, maybe that can be a option as well , to set an exact partition ID. 

[tinybit]

Yep, confirmed
I quickly sys-ed the image from a Win98 floppy (with a patched io.sys):
https://msfn.org/boa...&comment=964141
using the patch by Ralf Buschmann

So the issue is that the map --in-situ creates a 0x0E partiton (as opposed to a 0x06).

Maybe tinybit will have an idea how to change the 0x0E to 0x06 (in order to use the plainer DOS 6.22)?


Wonko
EDIT: attached animated gif.

good solusion. Now that you have this workaround, I think the problem could remains unsolved state. Emm... I really mean it is hard work continuing the development of grub4dos.

See this code in builtins.c:

if (in_situ)
	bios_drive_map[j].to_cylinder = (in_situ_flags << 8) | (
		filesystem_type == 1 ? 0x0E /* FAT12 */ :
		filesystem_type == 2 ? 0x0E /* FAT16 */ :
		filesystem_type == 3 ? 0x0C /* FAT32 */ :
		filesystem_type == 4 ? 0x07 /* NTFS */  :
		/*filesystem_type == 5 ?*/ 0x83 /* EXT2 */
		);

and this code in asm.S:
 

/* if in situ, TO_C holds the partition type:
  * 0x07(NTFS), 0x0C(FAT32), 0x0E(FAT12/16), 0x83(EXT2/3)
  */
movb %cs:4(%bp), %al /* TO_C */
stosl /* DI=BX+0x1c6 */

[MichaelWeaser]

 

good solusion. Now that you have this workaround, I think the problem could remains unsolved state. Emm... I really mean it is hard work continuing the development of grub4dos.

 

see this code in asm.S:

 

 /* if in situ, TO_C holds the partition type:
  * 0x07(NTFS), 0x0C(FAT32), 0x0E(FAT12/16), 0x83(EXT2/3)
  */
movb %cs:4(%bp), %al /* TO_C */
stosl /* DI=BX+0x1c6 */

 

I am thinking to put a request on the github page for grub4dos, under issues, to see if it could be added to be able to change the partition ID to what you want to use or something like what said above about --in-situ=CHS or --in-situ=LBA

[tinybit]

I don't think it is worth continuing the development of grub4dos. I suggest you simply compile a special version for your situation.

[Wonko the Sane]

Now that you have this workaround, I think the problem could remains unsolved state.

Actually I would have expected you for providing a workaround.
 
Besides recompiling (which is one limited solution) and besides having (in a next version) an optional PartID parameter to --in-situ (which would be an actual possible "final" solution), I would have expected a way to patch *wherever* the map --in-situ creates the "fake" MBR the single byte (from 0xE to 0x6).
I mean, that partition entry must exist *somewhere* and I don't see how - one way or the other - it cannot be changed, if not by parttype, by write.

 

Your idea is also great as well, maybe that can be a option as well , to set an exact partition ID.

Yes, I thought about the CHS vs. LBA parameter, but it is IMHO more limited, while providing as an option a given partition ID is more flexible, let's say that for *whatever* reasons someone *needs* a partition ID of (say) 0xA8 or 0xAB, it would be a sort of "overrule", good for all.

 

Wonko

[tinybit]

Actually I would have expected you for providing a workaround.
 
Besides recompiling (which is one limited solution) and besides having (in a next version) an optional PartID parameter to --in-situ (which would be an actual possible "final" solution), I would have expected a way to patch *wherever* the map --in-situ creates the "fake" MBR the single byte (from 0xE to 0x6).
I mean, that partition entry must exist *somewhere* and I don't see how - one way or the other - it cannot be changed, if not by parttype, by write.

 
Yes, I thought about the CHS vs. LBA parameter, but it is IMHO more limited, while providing as an option a given partition ID is more flexible, let's say that for *whatever* reasons someone *needs* a partition ID of (say) 0xA8 or 0xAB, it would be a sort of "overrule", good for all.

 

Wonko

According to this:

if (in_situ)
    bios_drive_map[j].to_cylinder = (in_situ_flags << 8) | (
        filesystem_type == 1 ? 0x0E /* FAT12 */ :
        filesystem_type == 2 ? 0x0E /* FAT16 */ :
        filesystem_type == 3 ? 0x0C /* FAT32 */ :
        filesystem_type == 4 ? 0x07 /* NTFS */ :
        /*filesystem_type == 5 ?*/ 0x83 /* EXT2 */
        );

the "0x0E" byte is at the lower byte of TO_C of the in-situ mapping slot. It should be shown by map --status.

 

Try these steps:

 

1. Get the INT13 Segment:offset value from the interrupt vector table.

2. Notice the hooked_drive_map which starts at Segment:0020. Each slot occupies 24 bytes.

    The in-situ slot will have the highest bit set for TO_S. Notice the comment and code in builtins.c:

//    unsigned char to_sector;    /* max sector of the TO drive */
                    /* bit 7: in-situ */
                    /* bit 6: fake-write or safe-boot */

 

  if (in_situ)
    bios_drive_map[i].to_sector |= 0x80;

 

3. Find the needed in-situ slot in hooked_drive_map, change the lower byte of TO_C from 0x0E to 0x06.

4. done

[MichaelWeaser]

Wonko the Sane, I have good news I changed the source code so that with --in-situ a fat16 partition now gets a 0x06 partition ID , and it 100% boots windows 3.1x loads fine. 

[Wonko the Sane]

Wonko the Sane, I have good news I changed the source code so that with --in-situ a fat16 partition now gets a 0x06 partition ID , and it 100% boots windows 3.1x loads fine.

Yep, that was expected, good.
 

Try these steps:
 
1. Get the INT13 Segment:offset value from the interrupt vector table.
2. Notice the hooked_drive_map which starts at Segment:0020. Each slot occupies 24 bytes.
    The in-situ slot will have the highest bit set for TO_S. Notice the comment and code in builtins.c:
 

//    unsigned char to_sector;    /* max sector of the TO drive */
                    /* bit 7: in-situ */
                    /* bit 6: fake-write or safe-boot */

 
 

  if (in_situ)
    bios_drive_map[i].to_sector |= 0x80;

 
3. Find the needed in-situ slot in hooked_drive_map, change the lower byte of TO_C from 0x0E to 0x06.
4. done

 

I will need some added explanations  .
1. How?
2. How do I access (cat --hex?) Segment:0020?
3. As above?
4. Ok.

 

Wonko

 

Attached Thumbnails

• 

[tinybit]

Yep, that was expected, good.
 

I will need some added explanations  .
1. How?
2. How do I access (cat --hex?) Segment:0020?
3. As above?
4. Ok.

 

Wonko

 cat --hex (md)+1 shows the Interrupt Vector Table. Google for "Interrupt Vector Table" to gain detailed explanation.

4 byte value at offset 0x4C is the vector for INT 0x13. Lower 2 byte integer is the Offset. Higher 2 byte integer is the Segment.

For a hooked map, the Offset should be 0x100. We need the Segment value. Suppose Segment=0x9EC0, The base memory address of this segment will be 0x9EC00. You can get its contents by cat --hex.

 

0x9EC00 / 0x200 =  0x4F6

 

So you may

 

cat --hex (md)0x4F6+1

 

Then Notice the offset 0x20 where the mapping slots start.

 

You can use the write command to change a byte value that is interested, e.g., from 0x0E to 0x06.

[Wonko the Sane]

Ok , thanks a lot

 

cat --hex --skip=0x4C --length=2 (md)+1

is 0x0100

 

cat --hex --skip=0x4E --length=2 (md)+1

is 0x9D00

 

Here I shift left (that should be like mutiplying by 16)

 

0x9D000/0x200=0x4E8 (643072/512=1256)

 

cat --hex --skip=0x20 --length=16 (md)0x4E8+1

 

 

cat --hex --skip=0x24 --length=1 (md)0x4E8+1

is 0x0E

 

write --offset=0x24 --bytes=1 (md)0x4E8+1 \x06

 

 

cat --hex --skip=0x24 --length=1 (md)0x4E8+1

is 0x06

 

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

 

shows the corrected partition type

 

Wonko

[tinybit]

Ok , thanks a lot

 

cat --hex --skip=0x4C --length=2 (md)+1

is 0x0100

 

cat --hex --skip=0x4E --length=2 (md)+1

is 0x9D00

 

Here I shift left (that should be like mutiplying by 16)

 

0x9D000/0x200=0x4E8 (643072/512=1256)

 

cat --hex --skip=0x20 --length=16 (md)0x4E8+1

 

 

cat --hex --skip=0x24 --length=1 (md)0x4E8+1

is 0x0E

 

write --offset=0x24 --bytes=1 (md)0x4E8+1 \x06

 

 

cat --hex --skip=0x24 --length=1 (md)0x4E8+1

is 0x06

 

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

 

shows the corrected partition type

 

Wonko

Also note that, a mapping slot is in-situ if and only if the highest bit of TO_S is 1.

[Wonko the Sane]

Ok, primitive and rudimental, but it seemingly works.
 
The assumptions are that the volume mapped --in-situ is the first entry in map --status and that it is mapped to (hd0).
 
Given the "extremely niche" nature of the batch, I don't believe that it is worth the effort to add error checking and/or make provisions for multiple mappings, etc.
 
Here it is (also attached just in case the stupid board sftware botches it):

!BAT
# Small batch to change the partition ID of a volume mapped with the --in-situ option
# thanks to tinybit, see: 
# http://reboot.pro/topic/21732-windows-for-workgroups-311-grub4dos-and-protected-mode/
# the idea is that the mapped --in-situ volume is on the FIRST line of the map --status
# AND that it is mapped to (hd0)

debug 0
if "%1"=="" goto :error1
set newpart=%1
set newpart=%newpart:~-2,2%
set newpart
setlocal

#the interrupt vector table is on (md)0+1
#2 bytes at offset 0x4C are offset
#we need the segment which is a 2 byte value at offset 0x4E
cat --hex --skip=0x4E --length=2 (md)0+1 | set segment=

#then to get the sector we need to shift left
set mdsector=0x%segment:~13,2%%%segment:~10,2%%0


#and divide by block size
set /A mdsector=%mdsector%/512

set mdsector

#with this info we get the current partID
cat --hex --skip=0x24 --length=1 (md)%mdsector%+1 | set partID=

echo Current Part ID is 0x%partID:~10,2%
echo 
echo Do you really want to change it to 0x%newpart%?
set /p confirm=type y or n (for yes or no) : 
if /i not "%confirm%"=="y" goto :eof

write --offset=0x24 --bytes=1 (md)%mdsector%+1 \x%newpart%

#let's check the current partID (the new value just written)
cat --hex --skip=0x24 --length=1 (md)%mdsector%+1 | set partID=
echo 
echo Current Part ID is now 0x%partID:~10,2%

#let's check the actual partition table
cat --hex --skip=446 --length=16 (hd0)0+1

goto :eof
:error1
echo You must call this batch providing a parameter in the form of the hex number
echo of the partition ID that you want to set for the mapped --in-situ volume
echo Example:
echo chgpartID 0x06

Wonko

Attached Files

•  chgpartID.zip   936bytes   305 downloads

[MichaelWeaser]

Ok, primitive and rudimental, but it seemingly works.

 

The assumptions are that the volume mapped --in-situ is the first entry in map --status and that it is mapped to (hd0).

 

Given the "extremely niche" nature of the batch, I don't believe that it is worth the effort to add error checking and/or make provisions for multiple mappings, etc.

 

Here it is (also attached just in case the stupid board sftware botches it):

!BAT
# Small batch to change the partition ID of a volume mapped with the --in-situ option
# thanks to tinybit, see: 
# http://reboot.pro/topic/21732-windows-for-workgroups-311-grub4dos-and-protected-mode/
# the idea is that the mapped --in-situ volume is on the FIRST line of the map --status
# AND that it is mapped to (hd0)

debug 0
if "%1"=="" goto :error1
set newpart=%1
set newpart=%newpart:~-2,2%
set newpart
setlocal

#the interrupt vector table is on (md)0+1
#2 bytes at offset 0x4C are offset
#we need the segment which is a 2 byte value at offset 0x4E
cat --hex --skip=0x4E --length=2 (md)0+1 | set segment=

#then to get the sector we need to shift left
set mdsector=0x%segment:~13,2%%%segment:~10,2%%0


#and divide by block size
set /A mdsector=%mdsector%/512

set mdsector

#with this info we get the current partID
cat --hex --skip=0x24 --length=1 (md)%mdsector%+1 | set partID=

echo Current Part ID is 0x%partID:~10,2%
echo 
echo Do you really want to change it to 0x%newpart%?
set /p confirm=type y or n (for yes or no) : 
if /i not "%confirm%"=="y" goto :eof

write --offset=0x24 --bytes=1 (md)%mdsector%+1 \x%newpart%

#let's check the current partID (the new value just written)
cat --hex --skip=0x24 --length=1 (md)%mdsector%+1 | set partID=
echo 
echo Current Part ID is now 0x%partID:~10,2%

#let's check the actual partition table
cat --hex --skip=446 --length=16 (hd0)0+1

goto :eof
:error1
echo You must call this batch providing a parameter in the form of the hex number
echo of the partition ID that you want to set for the mapped --in-situ volume
echo Example:
echo chgpartID 0x06

Wonko

 

How do do you use this script ? 

 

also a Little update ,  On Github I did a request to be able to change the partition ID of --in-situ , there is going to be a --in-situ=CHS option in the future, they haven't responded about changing it to any ID with =0x00 yet.

Edited by MichaelWeaser, 24 March 2018 - 05:26 PM.

[Wonko the Sane]

How do do you use this script ? 

 

also a Little update ,  On Github I did a request to be able to change the partition ID of --in-situ , there is going to be a --in-situ=CHS option in the future, they haven't responded about changing it to any ID with =0x00 yet.

You just put it where your grub4dos is and run it from grub4dos prompt.

i.e. you first run your:

map --in-situ (hdx,y)m+n (hd0)

map --hook 

commands, then you run:

/chgpartID 0x06

 

and then you continue with

root (hd0,0)

chainloader /io.sys

boot

 

you can of course invoke it from the menu.lst entry, optionally removing the "confirmation" check and/or some of the output.

 

As a matter of fact, since it doesn't use grub4dos batch "specific" sintax (excluding the goto commands) it can be also translated to "plainer" menu.lst entry contents, there are two philosophies about this, I personally prefer to have simple or as simple as possible menu.lst's and call from them external batches, some people prefers to have an endless number of commands, even very complex ones, inside menu.lst entries.

 

To be fair, if you know where your towel is, having this kind of stuff inside menu.lst (or however in a config file) may be convenient because you can use on them the built-in line edit of grub4dos) but for either simple "fixed" scripts or for more complex ones I still prefer the external batch script form.

 

Wonko

[steve6375]

@MW

I thought YaYa had already provided a new grldr which understands the suggested  --in-situ=CHS  switch?

Have you tested it and fed back to him your findings?

 

Is =0xhh really necessary since no one has ever found a need for it and it only DOS would be sensitive to the type number anyway so that should be covered by =CHS (assuming the CHS switch would use either 6 or B rather than C or E)?

[MichaelWeaser]

@MW
I thought YaYa had already provided a new grldr which understands the suggested  --in-situ=CHS  switch?
Have you tested it and fed back to him your findings?
 
Is =0xhh really necessary since no one has ever found a need for it and it only DOS would be sensitive to the type number anyway so that should be covered by =CHS (assuming the CHS switch would use either 6 or B rather than C or E)?

Wonko the sane wanted that option of =0x00 for any partition ID. And yes =CHS works fine.