ppgrainbow Posted September 23, 2017 Author Share Posted September 23, 2017 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? (or something loosely related to it). Anyway, this has become (actually it was since the start, but I failed to recognize it 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 More sharing options...
rloew Posted September 23, 2017 Share Posted September 23, 2017 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 More sharing options...
ppgrainbow Posted September 24, 2017 Author Share Posted September 24, 2017 (edited) 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 September 24, 2017 by ppgrainbow Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now