Jump to content

[SOLVED (AS IS)] Windows 95 issues with GRUB4DOS


ppgrainbow

Recommended Posts

11 hours ago, jaclaz said:

@Rloew

The Grub4dos hide command does change the partition ID's in the partition table in the MBR (i.e. adds 0x10 to the "normal" partition ID's), but of course it does so to the actual volumes slots, i.e. primaries and to the various EMBR's, not to the extended partition in itself, so it is possible that this triggers *something*. 

@ppgrainbow

The duplicate ghost drives come from *something* else, not from merely hiding them, as said grub4dos hides them in the "normal" way.

Maybe the issue here? :unsure: (or something loosely related to it).

Anyway, this has become (actually it was since the start, but I failed to recognize it :blushing: at first sight, I am getting older, beside grumpier) clearly a S.E.P.

Have fun. :)

jaclaz

That might be the issue with duplicate drive letters (M, N, O and P) showing up. I think that it could be a bug or design limitation with either the Windows 9x/ME operating systems or GRUB4DOS itself. I'm gonna do a Google search on ghost partitions in Windows 95 for more information.

Link to comment
Share on other sites


In order to swap drives, GRUB4DOS needs to hook INT 13.
If it hides Partitions, or makes any other changes, by modifying the image of the MBR provided rather than changing the actual MBR, Windows will get confused.

I am working on an AHCI Driver, so I have dissected the existing Code. IOS scans the Hard Drives using INT 13 and creates a Checksum for each one.
The Standard Disk Driver scans the Hard Drives using Direct I/O, creates Checksums for each one, then compares them to the list from IOS.
The ones that match are mapped. Unmatched Drives are added as new Drives. If GRUB4DOS changed the Checksum for a MBR Image, it won't match the Checksum from a MBR read by Direct I/O.
This appears to be happening in your case. The Drive didn't match so IOS put it's unmatched Drive and Partitions into compatibility Mode. The same Drive was treated as new and it's Partitions were added as your Ghosts.

I noticed that it appears you are using Virtual PC 2007 Drivers. These may be incompatible with your usage of GRUB4DOS. If possible try the same setup on a different VM.

Link to comment
Share on other sites

41 minutes ago, rloew said:

In order to swap drives, GRUB4DOS needs to hook INT 13.
If it hides Partitions, or makes any other changes, by modifying the image of the MBR provided rather than changing the actual MBR, Windows will get confused.

I am working on an AHCI Driver, so I have dissected the existing Code. IOS scans the Hard Drives using INT 13 and creates a Checksum for each one.
The Standard Disk Driver scans the Hard Drives using Direct I/O, creates Checksums for each one, then compares them to the list from IOS.
The ones that match are mapped. Unmatched Drives are added as new Drives. If GRUB4DOS changed the Checksum for a MBR Image, it won't match the Checksum from a MBR read by Direct I/O.
This appears to be happening in your case. The Drive didn't match so IOS put it's unmatched Drive and Partitions into compatibility Mode. The same Drive was treated as new and it's Partitions were added as your Ghosts.

I noticed that it appears you are using Virtual PC 2007 Drivers. These may be incompatible with your usage of GRUB4DOS. If possible try the same setup on a different VM.

I don't have the Virtual Machine Additions installed on the Windows 95 VM at all.

Now looking at the setup for Windows 95 on the third hard disk, here's where I finally figured something out:

hide (hd0,0)
hide (hd0,4)
hide (hd0,5)
hide (hd0,6)
hide (hd1,0)
hide (hd1,4)
hide (hd1,5)
hide (hd1,6)
unhide (hd2,0)
unhide (hd2,4)
unhide (hd2,5)
unhide (hd2,6)
map (hd0) (hd2)
map (hd2) (hd0)
find --set-root /IO.SYS
map --floppies-1
map --hook
root (hd0,0)
chainloader +1

The result is that prior to booting Windows 95, hard disks hd0 and hd1 go hidden, hd2 are unhidden. But here's the correct caviat, After mapping hd2 as hd0, I have to hook INT13 (map --hook) and after that, I set the root as hd0,0.

However, the ghost partitions M: through P: still showed up and drives C: though F: are still using compatibility mode.

Now checking the IOS.LOG file in the \WINDOWS directory, I found that the MBRINT13.SYS is causing unit numbers 02, 03, 04 and 05 to go through real mode drivers.

I'm baffled on how this can be fixed now. :(

Edited by ppgrainbow
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...