Jump to content

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


ppgrainbow

Recommended Posts

The DOS multibooting procedure between DOS, OS/2 and Windows 95 has became a wonderful project of mutibooting between these OSes under Virtual PC 2007.

However, for one OS, I'm running into issues here.

I have Windows 95 installed on the third hard drive. Using GRUB4DOS, I had to hide the MS-DOS hard disk image on (hd0) and the OS/2 Warp hard disk image on (hd1).

I then mapped the third hard disk image where Windows 95 is installed on (hd2) as (hd0) and although the OS work fine, it's showing original drive letters, M, N, O and P as phantom hard drives and drives C, D, E and F using MS-DOS compatiblity mode file system.

Here are some screenshots for proof of this issue:

MNOP_1.thumb.png.d1a50bc9e07a9e6525103f97ffad6029.png

Windows Explorer showing drive letters M, N, O and P as phantom drives.

 

MNOP_2.thumb.png.80dda11b772b3594453a376b99b1beee.png

Device manager listing drive letters M, N, O and P in the current drive letter assignment in System Properties > Disk drives.

 

59c4239a6c3e4_MS-DOSCompatibilityMode.thumb.png.6c48de9a5c5923cb2614a341ddae5990.png

System Properties > Performance reporting drives C, D, E and F using MS-DOS compatibility mode file system.

 

Here is the Windows 95 entry in the GRUB4DOS MENU.LST file

	title Microsoft Windows 95\n\n
find --set-root /IO.SYS
unhide (hd2,0)
unhide (hd2,4)
unhide (hd2,5)
unhide (hd2,6)
root (hd2,0)
savedefault
hide (hd0,0)
hide (hd0,4)
hide (hd0,5)
hide (hd0,6)
hide (hd1,0)
hide (hd1,4)
hide (hd1,5)
hide (hd1,6)
map (hd0) (hd2)
map (hd2) (hd0)
map --floppies=1
chainloader +1

Rather than taking the risk of having to reinstall Windows 95 on the third hard disk image, is there a way how to get rid of drive letters M, N, O and P completely? Hiding drive letters using TweakUI won't help since DOS and Windows File Manager will still see these drives. :(

Edited by ppgrainbow
Link to comment
Share on other sites


Also, when trying to start Windows 95 from the third hard drive using GRUB4DOS, this is the output of what I received when loading the CONFIG.SYS and AUTOEXEC.BAT files:

Error.png.14da249689e17e3c5892fdd98882aeff.png

For some obvious reason, when loading the OS from the second or third hard drive, MS-DOS things that COMMAND.COM is either missing or corrupt.

Here is the current output of my CONFIG.SYS file:

; This device driver is used to install the Virtual PC 2007 Virtual Machine
; guest additions under Microsoft MS-DOS.
DEVICE=C:\VMADD\VMADD386.SYS
	; Set the common system settings.
FILES=50
BUFFERS=10,0
	; Set FCBS vule to 1,0.
FCBS=1,0
	; Set STACKS value to 9,256.
STACKS=9,256
	; Set the LASTDRIVE variable to Z.
LASTDRIVE=Z
	; Turn off the BREAK command.
BREAK=OFF
	; Set Windows 95 to load high and use upper memory blocks automatically.
DOS=HIGH,UMB,AUTO
	; Load the HIMEM device drive, don't test system memory and
; display verbose information.
DEVICE=C:\WINDOWS\HIMEM.SYS /TESTMEM:OFF
	; Load the EMM386 memory manager driver.
DEVICE=C:\WINDOWS\EMM386.EXE NOEMS I=B100-B7FF I=CC00-CFFF I=E600-EFFF FRAME=D000
	; Load the CD-ROM driver in high memory.
DEVICEHIGH=C:\VMADD\CDROM.SYS /D:VPC
	; Load the POWER device driver to conserve power.
DEVICE=C:\WINDOWS\COMMAND\POWER.EXE ADV:MAX
	; Set the size of the environmental space for the 4DOS Command interpreter
; (4DOS.COM) to 2 KB into high memory.
SHELL=C:\4DOS\4DOS.COM C:\4DOS /P

And here is the current output for the AUTOEXEC.BAT file

	:: Turn off ECHO command.
@ECHO OFF
	:: Set the path serach for all common directories.
PATH C:\WINDOWS;C:\WINDOWS\COMMAND
	:: Display the current path at the command prompt.
PROMPT [$P$G]
	:: Set the DOS Virtual Machines Additions path to installed.
SET DOSVMADD13=INSTALLED
	:: Set the Sound Blaster environment.
SET BLASTER=A220 I5 D1 H5 P330 T5
SET MIDI=SYNTH:1 MAP:E
	:: Set temporary directory and timezone.
SET TEMP=C:\WINDOWS\TEMP
SET TZ=PST08PDT
	:: Set the Java path directories for Apple Quicktime.
SET CLASSPATH="C:\Java\QTJava.zip"
SET QTJAVA="C:\Java\QTJava.zip"
	:: Set the following PATH variable for the directories below.
SET PATH=%PATH%;C:\4DOS
SET PATH=%PATH%;C:\NORTON
SET PATH=%PATH%;C:\VMADD
SET PATH=%PATH%;C:\WINDOWS\COMMAND\CWSDPMI
	:: Load the MSCDEX CD-ROM drive and set drive letter to X.
LH MSCDEX /D:VPC /L:X
	:: Load the mouse driver in high memory.
LH MOUSE
	:: Load the folder sharing (FSHARE) utility.
FSHARE
	:: Load the 4DOS KSTACK driver in high memory.
LH KSTACK
	:: Install the 4CLOCK TSR.
4CLOCK

For some obvious reason MS-DOS fails to load the COMMAND.COM file when trying to load drivers from the AUTOEXEC.BAT file, but other than that, Windows 95 loads normally.

Link to comment
Share on other sites

As I tried telling you here:

http://reboot.pro/topic/21586-installing-os2-on-a-second-hard-drive-with-grub4dos/

you are NOT exchanging disks if you do not hook the mapping. 

If you want it more bluntly, try using the grub4dos commands properly, before overcomplicating the matter. 

Dos/Windows 95 want to be booted form the First hard disk, just exchenge (properly) the disks drives.

jaclaz

Link to comment
Share on other sites

Adding the map --hook parameter actually threw a "Non system disk or disk or disk error" message. Pressing the ENTER booted the OS from the third hard disk image as usual. If I remove the --map hook parameter, Windows 95 without any problems.

Look here:

59c5394dce916_CompatiblilityMode.thumb.png.2da9595cfb7371b2cde726814701e55f.png

What I did was to enter the "System Configuration Utility" (msconfig), click Advanced and select "Force Compatibility mode disk access" which will force Windows 95 to use real mode disk access since it is in a dual boot environment with MS-DOS and OS/2.

The result is that drive letters M, N, O and P are now gone! :)

As far as I know trying to mess around with the GRUB4DOS MENU.LST settings corrupted as much as 209 MB of data on the MS-DOS 6.22 partition and had to reinstall DOS! That's one of the reasons why I had to back up data incase something goes wrong.

Edited by ppgrainbow
Link to comment
Share on other sites

Sure, if you just added the map --hook command in that menu.lst, you tried booting from the "wrong disk", you set root BEFORE exchanging disks.

Moreover you first experiment in command line, and then you put it in a menu.lst entry, like:

map (hd0) (hd2)
map (hd2) (hd0)
map --hook
find --set-root /io.sys
root
chainloader /io.sys
boot

The above is not "booting from third disk" (which is AFAIK impossible, as DOS wants to be on first disk, actually on first active partition of first disk, or however whatever gets drive letter C:\, not negotiable), it is booting from third disk remapped to first disk.

What you are probably doing (and that is  philosophically "wrong") is to hide all partitions on first and second disk so that the first partition on third disk becomes C:\.

But without knowing how the disks are partitioned/setup it is hard to say.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

19 minutes ago, jaclaz said:

Sure, if you just added the map --hook command in that menu.lst, you tried booting from the "wrong disk", you set root BEFORE exchanging disks.

Moreover you first experiment in command line, and then you put it in a menu.lst entry, like:


map (hd0) (hd2)
map (hd2) (hd0)
map --hook
find --set-root /io.sys
root
chainloader /io.sys
boot

The above is not "booting from third disk" (which is AFAIK impossible, as DOS wants to be on first disk, actually on first active partition of first disk, or however whatever gets drive letter C:\, not negotiable), it is booting from third disk remapped to first disk.

What you are probably doing (and that is  philosophically "wrong") is to hide all partitions on first and second disk so that the first partition on third disk becomes C:\.

But without knowing how the disks are partitioned/setup it is hard to say.

jaclaz

I tried using your suggestion and when attempting to boot Windows 95 from the third hard disk threw a blinking cursor.

Since Windows 95 is located on the third drive, the root (hd2,0) parameter has to be added before mapping the (hd2) as (hd0) or it won't work at all.

Speaking of Windows 95, I solved my problem by loading the COMMAND.COM interpreter first and then load 4DOS permanently to prevent a missing or corrupt COMMAND.COM interpreter in the CONFIG.SYS file:

SHELL=C:\COMMAND.COM /C C:\4DOS\4DOS.COM C:\4DOS /P

When I'm done with Windows 95, I can go back to MS-DOS on the first hard disk by unhiding (hd0), hiding (hd1) and (hd2) and jump to OS/2 by hiding (hd0), unhiding (hd1) and hiding (hd2).

Link to comment
Share on other sites

Whatever floats your boat is good :)

But you cannot misuse the tool and post an overcomplex workaround (actually you can, of course).

If you detail how EXACTLY your disks are setup, I can probably help you, but you must not misrepresent what you did.

Let's see together the set of commands (to be issued on command line) I posted.

I assumed that the IO.SYS that you want to boot (and the corresponding Windows 95) bothe reside on (hd2,0).

map (hd0) (hd2)

map (hd2) (hd0)

map --hook

At this point (hd0) is (hd2) and (hd2) is (hd0).

find --set-root /io.sys

this will find the first io.sys it can find and set root to that disk partition.

If the io.sys is on (hd2,0) (which is now (hd0,0), the following:

root

will output (hd0,0), so you have the "right" root.

At this point you have two (actually three) possible way to boot the Windows 95 (DOS 7.x):

1) chainloader +1 (this will chainload the bootsector of the current root partition)

2) chainloader /io.sys (this will chainload the io.sys directly, bypassing the bootsector)

3) chainloader (hd0)+1 (this will chainload the MBR of the disk, if there is normal boot code in it, and if the first partition on that disk is active, it will chainload the bootsector, like #1 above).

It is possible (and it may depend on the exact grub4dos version you are using) that the one or the other doesn't work, however.

jaclaz

 

Link to comment
Share on other sites

23 minutes ago, dencorso said:

Or there is more than one unhidden partition having an io.sys...
Then, instead of 
"find --set-root /io.sys",
"root (hd0,0)"
at the same point should work.

Yep :), but without knowing the actual setup it is hard to say, it is also possible that *somehow* there is a "mixed boot", with *some other* io.sys loaded, however the normal search order for grub4dos is;

(hd0,0)

(hd0,1)

(hd0,2)

...

(hd1,0)

(hd1,1)

...

but grub4dos (I believe it depends on versions) can also look on hidden volumes, so it has to be seen what really happens.

 

I inserted the:

root

command in the suggested commands (chich is otherwise unneeded and to be removed when inserting in a menu.lst) exactly to verify that the "right" root is found, but of course that was implying that some feedback would have been provided.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Well, since my crystal ball is again in the shop for tuning, I did my best by interpreting the flight of the birds... although the only birds visible from where I am right now are a bunch of vultures, which usually are not very reliable, as you know. :(

Link to comment
Share on other sites

Thank you so much for the compliment! I'm glad that things are working out as it is. As for attempting to abuse GRUB4DOS, I must of added the setactive or makeactive parameters which might have triggered the data corruption on the first hard disk where MS-DOS 6.22 resides and I apologise for messing up. Better safe than sorry - always backup incase something goes wrong. :)

The latest GRUB4DOS version that I'm using right now is version 0.4.6a 2017-08-30.

The only problem now is that the Windows 95 Device Manager has a yellow exclamation mark next to the floppy and hard disk controllers since I'm only allowing Windows 95 to use real mode disk access.

Link to comment
Share on other sites

When a Protected Mode Storage Driver is loaded, Windows scans every Device found. If it matches an existing DOS detected Device it is mapped. If not, all Partitions on it are added.
DOS detected Partitions that are not mapped remain in "Compatibility Mode".

GRUB4DOS is hiding Partitions from DOS but is not hiding them from Windows. This leads to the "Ghost" Partitions.
Other than altering the Partition IDs to hide them, I do not know how to hide Partitions from Windows.
My RFDISK Multi-Boot Profile setup alters the MBRs dynamically to provide Windows compatibility.

I have intentionally implemented Windows only "Ghost" Partitions in my Terabyte Plus Package to insure that Partitions not supported by the BIOS or DOS are correctly handled.

Link to comment
Share on other sites

The only way to hide "ghost" partitions from Windows 95 is to Force Compatibility mode disk access.

And if I can't afford the Terabyte Plus Package, are there any other tools that will correctly implement Windows only "Ghost" partitions to insure that partitions that are not supported by the BIOS or DOS are correctly handled?

Edited by ppgrainbow
Link to comment
Share on other sites

@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

Link to comment
Share on other sites

12 hours ago, ppgrainbow said:

The only way to hide "ghost" partitions from Windows 95 is to Force Compatibility mode disk access.

And if I can't afford the Terabyte Plus Package, are there any other tools that will correctly implement Windows only "Ghost" partitions to insure that partitions that are not supported by the BIOS or DOS are correctly handled?

I could separate the Windows only Partition support from the rest of the Terabyte Patches to make a less expensive product, but I never saw any reason to do so. The main reason I designed these Partitions is to handle Partitions above the 2TiB limit. A lot of BIOSes do not support them. The only other case I know of is a BIOS that cannot handle more than 137GB, 8GB or one of the other old limitations.

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...