Jump to content











Photo
- - - - -

Getting Windows 95 to install and boot from VHD mapped by GRUB4DOS

win95 vhd --in-situ

  • Please log in to reply
20 replies to this topic

#1 ppgrainbow

ppgrainbow

    Member

  • Members
  • 70 posts

Posted 05 October 2020 - 08:08 AM

I'm currently using the latest revision of GRUB4DOS 0.4.6a (2020-08-09) under Virtual PC 2007 and with the usage of the --in-situ command, I've been trying to get original release of Windows 95 to install and boot from VHD.

The size of the VHD is 504 MB (FAT16 formatted), 1,024 cylinders, 16 heads and 63 sectors per track for a total of 1,032,192 sectors. Here is the part of my menu to install and boot Windows 95 in a VHD.

find --set-root /WIN95/BOOT.VHD
map --in-situ --heads-16 --sectors-per-track=63 (hd1,6)/WIN95/BOOT.VHD (hd0)
map --hook
map --harddrives=1
map --floppies=1
root (hd0,0)
chainloader /IO.SYS

When I try to boot from the BOOT.VHD file located on HD1,6 (drive K), I get this output:

Autodetect number-of-heads failed. Use the specified 16
 
Autodetect sectors-per-track failed. Use the specified 63

Error 17:(http//grub4dos.chenall.net/e/17)
         Cannot mount selected partition

I was lucky to set up the VHD using FDISK and format the drive, but I can't seem to proceed any further. I tried to follow this topic, "Can I install Windows 98 to IMG/VHD disk mapped by GRUB4DOS?", but it wasn't too much of a help.

 

Do you have any idea what I'm doing wrong here?


Edited by ppgrainbow, 05 October 2020 - 08:17 AM.


#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 October 2020 - 08:45 AM

You should NEVER use a pre-made menu.lst when experimenting, use command line instead.

 

For *some* reasons the grub4dos is not seeing a proper partition.

The (hd1,6) is correct?

 

If you use:

find --set-root /WIN95/BOOT.VHD

then you should issue a command with relative path (you already established root) and not an abolute one:

map --in-situ  /WIN95/BOOT.VHD (hd0)

map --hook

then:

geometry (hd0)

 

If you get gibberish/error, it means that somehow the map --in-situ did not create a proper partition table in the "virtual" MBR.

 

Then, check the source, 

cat --hex --length=512 /WIN95/BOOT.VHD

does it look like a FAT16 bootsector? :dubbio:

Or does it look as a MBR?

 

The idea of map --in-situ is to create on-the-fly a virtual MBR to be able to boot a volume, very likely your .VHD is already a partitioned device (normally .vhd's are disk images, not volume/partition images), so you shouldn't use --in-situ, but the normal map:

find --set-root /WIN95/BOOT.VHD

map  /WIN95/BOOT.VHD (hd0)

geometry (hd0)

root (hd0,0)

chainloader /io.sys

boot

 

:duff:

Wonko



#3 ppgrainbow

ppgrainbow

    Member

  • Members
  • 70 posts

Posted 05 October 2020 - 06:55 PM

Partition (hd1,6) is correct which is where GRUB4DOS resides.

I've added geometry (hd0) like you asked.

I had to add --heads=16 --sectors-per-track=63 as GRUB4DOS is trying to ask for the CHS geometry of the hard disk image. Without it, I'll end up getting a error that "heads" and "sectors per track" need to be added.

But when you suggested that I should use the normal map without the --in-situ option, all I get it a blinking cursor: https://imgur.com/a/R0fk4o9

Checking the source of the /WIN95/BOOT.VHD file using cat --hex --length=512 (hd1,6)/WIN95/BOOT.VHD, here's the output: https://imgur.com/a/wWxscue

The OEM string is MSWIN4.0 which starts at sector 63.

 

Any other ideas? :frusty:



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 October 2020 - 08:26 AM

Side note: Why do people use imgur? (for some reasons I cannot see them without an insane workaround).

 

Can you please (in the future) attach those images or post them on a more "normal" host, *like*:

 

https://www.4shared.com/

 

Anyway, good :).

 

As said the map --in-situ is to be used when the target is a volume, not a partitioned device, i.e. when the bootsector is the first sector.

 

The blinking cursor is usually connected to a mismatch of either geometry (head/sectors) or CHS and LBA, either only in the MBR or between the MBR and the bootsector.

The MBR partition table entry 

0E	80	0	1	1	1022	15	63	 	63	1032129

is "wrong", the 1022 should be 1023 (or the LBA numsectors should be 1031121) :dubbio:

 

The partition type is 0E (LBA mapped) so the Window 95 needs to be OSR 2 (or you can change it to 06, i.e. FAT16 CHS mapped)

 

The size of the .vhd file should be 1 sector more, i.e.63+1032129+1= 1032193*512=528482816, can you confirm this?

 

I need the output of 

cat --hex --length=512 --skip=32256 /WIN95/BOOT.VHD

i.e. the bootsector to check if the heads/sectors are right in there.

 

So the queston is now how (EXACTLY) did you create the image and partitioned/formatted it?

 

There must be something in the procedure that creates the problem.

 

:duff:

Wonko



#5 ppgrainbow

ppgrainbow

    Member

  • Members
  • 70 posts

Posted 06 October 2020 - 05:12 PM

First off, I'm accessing imgur on SeaMonkey 2.53.4 (which is based on Firefox 60 ESR). SeaMonkey 2.49.5 was based on Firefox 52 ESR and unfortunately, I don't think that I could properly see the images under that unsupported browser...so, I will upload it to 4Shared. :)

I used cat --hex --length=512 --skip=32256 (hd1,6)/WIN95/BOOT.VHD and I got the results here:

https://www.4shared....ea/output2.html

The screenshot shows that the drive is FAT16 formatted and the OEM string is MSWIN4.0 starting on 7E00. MSWIN4.0 refers to the original release of Windows 95 and Windows 95 OSR1..so the LBA mapped partition type is 06. The string WINBOOT.SYS ends on 7FF0.

I can confirm that size of the BOOT.VHD hard disk image is 1,032,193 sectors or 528,482,816 bytes. If the 63 sector offset is present, then the maximum number of sectors is 1,032,129 or 528,450,048 bytes. The first partition of the MBR always start on sector 63.

So, how was the hard disk image created? Simple, I used the Virtual PC 2007 to create the temporary "win95" vm then:

1. Use the Virtual Disk Wizard to create a 504 MB hard disk image doing the following:

A. Create a new virtual disk.
B. Create a virtual hard disk.
C. Enter the name of the virtual hard disk location by typing "E:\BOOT.VHD".
D. In Virtual Hard Disk options, select "Fixed size".
E. Enter the virtual hard disk size to 504 MB. Upon creating the virtual hard disk, click Next. Once that's done, the virtual hard drive is created successfully.

2. I also setup the hard disk image by doing the following:

A. In the Boot section of the BIOS Setup Utility, in the Boot Device Priority, select "Floppy Drive" as the first boot device. I inserted the Windows 95 boot diskette image, hit Exit Saving Changes. When it says, "Save configuration changes and exit now?", I click OK.

B. from the MS-DOS prompt, type FDISK and create a DOS partition. Where it says, "Do you wish to use the maximum available size for a Primary DOS Partition and make the partition active (Y/N)", I select Y and confirm this.

C. Then when I'm done, I have to restart the machine from the floppy diskette by selecting Action > Control + Alt + Delete.

D. After the reboot is complete, I have to type in FORMAT C: /S /U to format the hard disk. Once the formatting is completed, the usable formatted hard disk capacity is 528,171,008 bytes or 1,031,584 sectors.

UPDATE: I ran the GRUB4DOS command line used the geometry command to print out information regarding (hd0), (hd1) and (hd2). Here is the output for (hd1):

drive 0x81 (LBA), C/H/S=1823/255/63, Sector Count/Size16434495/512
   Partition num: 0, Filesystem is fat16, partition type 0x06
   Partition num: 4, Filesystem is fat16, partition type 0x06
   Partition num: 5, Filesystem is fat16, partition type 0x06
   Partition num: 6, active.  Filesystem is fat16, partition type 0x06

I also entered the blocklist notation my entering "blocklist (hd1,6)/WIN95/BOOT.VHD" and the output sectors for mapping is: (hd1,6)28247+1932193

 

If for some reason, you need to request additional information including step-by-step screenshots, please let me know. :)


Edited by ppgrainbow, 06 October 2020 - 05:45 PM.


#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 October 2020 - 11:28 AM

The bootsector data seems fine 0x10=16 0xBF=63 and 0x000FBFC1=1032129

 

The mismatch is seemingly only this one:

(1022+1)*(15+1)*63=1031184 

63+1032129=1032192

 

But also the entry in the partition table is now 0x0E while it should be 0x06. 

 

The command you should run on command line are:

 

find --set-root /WIN95/BOOT.VHD
root <- this should output (hd1,6)
map /WIN95/BOOT.VHD (hd0)

map --hook
geometry (hd0)

 

The output should be *like*:

 

drive 0x80 (LBA), C/H/S=1024/16/63, Sector Count/Size1032192/512
Partition num: 0, Filesystem is fat16, partition type 0x0E

 

I wonder how the issue is originated, if the floppy is MDOS 7.0 from OSR 1 it should know nothing about 0x0E (or maybe in Windows 95 OSR1 there was already FAT 16 LBA mapped and only FAT32, both CHS and LBA mapped were missing :unsure: ), and in any case the CHS<->LBA should be balanced.

 

Anyway, try doing the following:

 

find --set-root /WIN95/BOOT.VHD
root <- this should output (hd1,6)
map --heads=16 --sectors-per-track=63 /WIN95/BOOT.VHD (hd0)

map --hook
geometry (hd0) <- and take note of the result

cat --hex --skip=446 --length=16 (hd0)0+1 <- this should output the contents of the first entry in the partition table, currently :"80 01 01 00 0E 0F FF FE 3F 00 00 00 C1 BF 0F 00"
partnew --active (hd0,0) 0x06 63 1032129 <- this should create a new entry, overwriting the old one, with the CHS value automatically translated from the LBA ones

geometry (hd0) <- and take note of the result

cat --hex --skip=446 --length=16 (hd0)0+1 <- this should result in "80 01 01 00 06 0F FF FF 3F 00 00 00 C1 BF 0F 00"

root (hd0,0)

chainloader /io.sys

boot

 

What happens?

Try also (after rebooting)

 

find --set-root /WIN95/BOOT.VHD
map --heads=16 --sectors-per-track=63 /WIN95/BOOT.VHD (hd0)

map --hook
rootnoverify (hd0)

chainloader (hd0)63+1

boot

 

 

find --set-root /WIN95/BOOT.VHD
map --heads=16 --sectors-per-track=63 /WIN95/BOOT.VHD (hd0)

map --hook
root (hd0,0)

chainloader (hd0,0)0+1

boot

 

 

find --set-root /WIN95/BOOT.VHD
map --heads=16 --sectors-per-track=63 /WIN95/BOOT.VHD (hd0)

map --hook
rootnoverify (hd0)

chainloader (hd0)0+1

boot

 

:duff:

Wonko



#7 ppgrainbow

ppgrainbow

    Member

  • Members
  • 70 posts

Posted 07 October 2020 - 09:22 PM

Okay, I entered "cat --hex --skip=446 --length=16 (hd0)0+1" in the GRUB4DOS commandline the output shows the following:

000001BE: 80 01 01 00 06 FE 3F FE 3F 00 00 00 00 82 3E 00

The partition ID 06 correctly indicates that it is a FAT16 partition.

I have entered the following that you suggested:

find --set-root /WIN95/BOOT.VHD
root (hd1,6)
map --heads=16 --sectors-per-track=63 /WIN95/BOOT.VHD (hd0)
map --hook
geometry (hd0)
cat --hex --skip=446 --length=16 (hd0)0+1
partnew --active (hd0,0) 0x06 63 1032129
geometry (hd0)
cat --hex --skip=446 --length=16 (hd0)0+1
root (hd0,0)
chainloader /io.sys
boot

And I still got a blinking cursor and it resulted in data corruption of drive D (hd1,0). :(

I wouldn't be shocked to see this eventually happen this way. But, it's a good thing that I have backed up my hard disk images in case anything goes horribly wrong or if massive data corruption occurs. :)


Here are some other attempts that I made:

Attempt #1

find --set-root /WIN95/BOOT.VHD
map --heads=16 --sectors-per-track=63 /WIN95/BOOT.VHD (hd0)
map --hook
rootnoverify (hd0)
chainloader (hd0)63+1
boot

The first attempt failed, I wound up with a the following:

Error 43: The BPB hidden_sectors should no be zero for a hard-disk partition boot sector.

Attempt #2

find --set-root /WIN95/BOOT.VHD
map --heads=16 --sectors-per-track=63 /WIN95/BOOT.VHD (hd0)
map --hook
root (hd0,0)
chainloader (hd0,0)0+1
boot

The second attempt was a partial success! :) I can start Windows 95 from the hard disk image without problems. The Windows 95 installation completed without problems.

 

However, when I attempt to continue the Windows 95 Setup from the hard disk image, I get this error message:

While initalizing device IOS:
Error: An I/O subsystem driver failed to load.
Either a file in the .\iosubsys subdirectory is correct,
or the system is low on memory.

This doesn't sound too good when I tried to successfully install Windows 95 inside a VHD under GRUB4DOS.

Is there any idea how this can be fixed? :frusty:


Edited by ppgrainbow, 07 October 2020 - 09:27 PM.


#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 October 2020 - 01:14 PM

Only for the record, I never suggested:



find --set-root /WIN95/BOOT.VHD
root (hd1,6)

Actually I explicitly told you how that makes no sense whatsoever, you have to make up your mind:

Hey, grub4dos, please go look for where /WIN95/BOOT.VHD is and establish root to that volume, no, wait, nevermind, establish root to (hd1,6).

(no harm done, of course but unneeded/mutually exclusive)

 

This, as well, makes no sense whatsoever:

 

 

Okay, I entered "cat --hex --skip=446 --length=16 (hd0)0+1" in the GRUB4DOS commandline the output shows the following:





000001BE: 80 01 01 00 06 FE 3F FE 3F 00 00 00 00 82 3E 00

The partition ID 06 correctly indicates that it is a FAT16 partition.

That (hd0) is ANOTHER disk, 0x003E8200 is NOT  0x000FBFC1 (it is decimal 4096512 :w00t:).

 

If you don't report the output of the geometry (hd0) it is difficult for me to "guess" if the proposed fix did anything, the " <- and take note of the result" was meant as " <- and take note of the result AND post it" ;).

As well " <- this should output the contents of the first entry in the partition table, currently :" and "<- this should result in " implies AND report if it is not EXACTLY like that. 

 

Somehow you must have made a typo, or a command did not go through or there is a queer configuration issue as there is no way the (hd1) can be affected by the suggested set of commands.

 

The error 43: is not "good" :dubbio: as the partnew command is supposed to make a new partition entry AND correct the sectors before in the BPB. 

 

You can check that, however (63*512+28=32284)

cat --hex --skip=32284 --length=4 (hd1,6)//WIN95/BOOT.VHD

or:

map (hd1,6)//WIN95/BOOT.VHD (hd0)

map --hook

cat --hex --skip=28 --length=4 (hd0,0)

 

But again, what I need to understand (hopefully) the issue and (even more hopefully)  provide a solution are the EXACT reports of the output of the EXACT commands I suggested.

 

Let's try again (from a fresh boot/re-boot to grubdos):



find --set-root /WIN95/BOOT.VHD
root <- PLEASE POST THE OUTPUT OF THIS COMMAND
map --heads=16 --sectors-per-track=63 /WIN95/BOOT.VHD (hd0) <-PLEASE POST THE OUTPUT OF THIS COMMAND (IF ANY)

map --hook
geometry (hd0) <- PLEASE POST THE OUTPUT OF THIS COMMAND

cat --hex --skip=446 --length=16 (hd0)0+1 <- PLEASE POST THE OUTPUT OF THIS COMMAND
partnew --active (hd0,0) 0x06 63 1032129 <- PLEASE POST THE OUTPUT OF THIS COMMAND (IF ANY)

geometry (hd0) <- PLEASE POST THE OUTPUT OF THIS COMMAND
cat --hex --skip=446 --length=16 (hd0)0+1 <- PLEASE POST THE OUTPUT OF THIS COMMAND
root (hd0,0) <-PLEASE POST THE OUTPUT OF THIS COMMAND (IF ANY)
cat --hex --length=48 (hd0,0)0+1 <-PLEASE POST THE OUTPUT OF THIS COMMAND

ALL the boot targets:



rootnoverify (hd0)
chainloader (hd0)0+1
root (hd0,0)
chainloader (hd0,0)0+1
root (hd0,0)
chainloader /io.sys

should work the same if everything is ok.

 

:duff:

Wonko



#9 ppgrainbow

ppgrainbow

    Member

  • Members
  • 70 posts

Posted 08 October 2020 - 11:14 PM

Oops!

Hang on a minute, I will post the output of the following commands using the GRUB4DOS commandline:

1. find --set-root /WIN95/BOOT.VHD

The result is:

 (hd1,6)

2. root

The result is:

(hd1,6) Filesystem type is fat16, partition type 0x06

3. map --heads=16 --sectors-per-track=63 /WIN95/BOOT.VHD (hd0)

The result is:
 

info: total_sectors calculated from partition table(1032192) is less than the number of sectors in the while desk image(1032193)

probed C/H/S = 1024/16/63, probed total sectors=1032192

 
4. geometry (hd0)

The result is:

drive 0x80(LBA: C/H/S=1025/16/63, Sector Count/Size=1032193/512
   Partition num: 0, active.  Filesystem type is fat16, partition type 0x06

5. cat --hex -skip=446 --length=16 (hd0)0+1

The result is:

000001BE: 80 01 01 00 06 0F FF FF 3F 00 00 00 C1 BF 0F 00

6. partnew --active (hd0,0) 0x06 63 (1032129)

No output of this command is given. However, upon the next reboot - the primary partition on the second hard drive (hd1,0) may experience data corruption. Therefore, it's a good thing that I had mad a backup of the second hard disk image. :)

7. geometry (hd0)

The result is:

drive 0x80(LBA: C/H/S=1025/16/63, Sector Count/Size=1032193/512
   Partition num: 0, active.  Filesystem type is fat16, partition type 0x06

8. cat --hext --skip=446 --length=16 (hd0)0+1

The result is:

000001BE: 80 01 01 00 06 0F FF FF 3F 00 00 00 C1 BF 0F 00

I apoligise if I failed to make since, but (hd0) was the first partition prior to mounting (hd1,6)/WIN95/BOOT.VHD as (hd0). After (hd1,6)/WIN95/BOOT.VHD, the value is reported as 0x000FBFC1, F in red, FB in blue and C1 in green.

9. root (hd0,0)

The result is:

Filesystem type is fat16, partition type 0x06

10. cat --hex --length=48 (hd0,0)0+1

The result is:

00000000: EB 3E 90 4D 53 57 49 4E 24 2E 30 00 02 10 01 00
00000010: 02 00 02 00 00 F8 FC 00 3F 00 10 00 3F 00 00 00
00000020: C1 BF 0F 00 B0 00 29 E8 11 19 25 4E 4F 20 4E 41

The OEM string MSWIN4.0 (4D 53 57 49 4E 34 2E 30) is located on between 0x00000003 and byte 0x0000000A...at the beginning of the drive.

Now, what should I do next, Wonko?


Edited by ppgrainbow, 08 October 2020 - 11:17 PM.


#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 October 2020 - 08:58 AM

Between #3 and #4 you did run a "map --hook", right?

in #6 the command is.

partnew --active (hd0,0) 0x06 63 1032129

not:

partnew --active (hd0,0) 0x06 63 (1032129)

(no brackets around LBA num)

 

But anyway the geometry and partition data in the MBR are fine, they were probably already fixed by a previous run.

 

About the bootsector data, something is "wrong", possibly typos?

The OEM from your data is "MSWIN$.0" the 0x24 is $, maybe it is actually 0x34 (4).

A well disk number is B0 (should be 80).

 

Rest of data seems fine:

FAT16 Boot structure:

Position: 0x00000000

JMP instruction:               '0xEB 0x3E 0x90'
OEM:                           'MSWIN$.0'
Bytes per Sector:              '0x0200' (512 dec)
Sectors per cluster:           '0x10' (16 dec)
Reserved Sectors:              '0x0001' (1 dec)
Number of FATs:                '0x02'
Max root entries:              '0x0200' (512 dec)
Small sectors:                 '0x0000' (0 dec)
Media type:                    '0xF8'
Sectors per FAT:               '0x00FC' (252 dec)
Sectors per track:             '0x003F' (63 dec)
Number of heads:               '0x0010' (16 dec)
Hidden sectors:                '0x0000003F' (63 dec)
Large sectors:                 '0x000FBFC1' (1032129 dec)
Disk number:                   '0xB0'
Current head (not used):       '0x00'
NT signature:                  '0x29' (41 dec)
Volume serial number:          '0x251911E8' (622399976 dec)

so, it should work just fine.

 

It is still possible that the FAT filesystem was created when *something* in the partition table was not correct, so you should now re-format the volume.

 

Easiest would be with a Windows 95 bootable floppy, *like*:

find --set-root /WIN95/BOOT.VHD

map /WIN95/BOOT.VHD (hd0)

map --hook

find --set-root /my95floppy.img

map /my95floppy.img (fd0)

map --hook

root (fd0)

chainloader /io.sys

boot

 

You should be at the DOS

A:>

prompt.

now run FDISK to check that the first disk is the right one and you have the C: driveletter assigned to it

 

then run 

A:>FORMAT C: /S

 

reboot, then *any* of these:

 

find --set-root /WIN95/BOOT.VHD

map /WIN95/BOOT.VHD (hd0)

map --hook

root (hd0,0)

chainloader /io.sys

boot

 

 

find --set-root /WIN95/BOOT.VHD

map /WIN95/BOOT.VHD (hd0)

map --hook

root (hd0,0)

chainloader +1

boot

 

 

find --set-root /WIN95/BOOT.VHD

map /WIN95/BOOT.VHD (hd0)

map --hook

rootnoverify (hd0)

chainloader +1

boot

 

should all bring you to the DOS

C: >

prompt.

 

The first chainloads the IO.SYS bypassing BOTH the MBR and bootsector code.

The second chainloads the bootsector code bypassing the MBR code.

The third chainloads the MBR code.

 

You can also try without re-formatting, transferring the DOS from floppy with the SYS command.

 

:duff:

Wonko



#11 ppgrainbow

ppgrainbow

    Member

  • Members
  • 70 posts

Posted 09 October 2020 - 10:40 AM

All right. As for #6, that's correct. However, I didn't want to include the parenthesis between the "1032129" value part...so if I made a mistake and can't edit my comment, then I must apologise for that.

 

Anyways, I'm gonna try booting from a Windows 95 floppy disk image and see how this goes and get back to you as soon as possible when I update my comment. :)

 

UPDATE 1: Okay, I managed to boot from a floppy diskette image FLOPPY.IMG located in the WIN95 directory on drive K (hd1,6) with the following

find --set-root /WIN95/BOOT.VHD
map --heads=16 --sectors-per-track=63 /WIN95/BOOT.VHD (hd0)
map --hook
find --set-root /WIN95/FLOPPY.IMG
map --hook
rootnoverify (fd0)
map --harddrives=1
chainloader (fd0)0+1
boot

The results were a success. I re-setup the hard disk image and formatted the hard disk image. I'm now going to try to re-install Windows 95 again and post a update to see how far I will get.

 

UPDATE 2: I got as far as re-installing Windows 95 by copying the installation directory (X:\WIN95) to the C:\SETUP, got through re-installing Windows 95, but after rebooting, when I got through the second part of Windows setup and got the following again:

While initializing device IOS:
Error: An I/O subsystem driver failed to load.
Either a file in the .\iosubsys subdirectory is corrupt
or the system is low on memory.

Now, I'm seem to be stuck here. What now? :( :frusty:

 

I might have to check GRUB4DOS on Github to see if I can try to get this issue resolved.


Edited by ppgrainbow, 09 October 2020 - 11:29 AM.


#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 October 2020 - 02:00 PM

Well, grub4dos "ends" the moment you get to the A:> or C:> DOS prompt, so that this error:



While initializing device IOS:
Error: An I/O subsystem driver failed to load.
Either a file in the .\iosubsys subdirectory is corrupt
or the system is low on memory.

is "past" grub4dos and related to the Windows 95.

 

Or to the BIOS.

 

Of course you can never say that for sure as the message is as often happens vague enough

 

Have you tried setting in System.ini:

 

[vcache]
maxfilecache=6144

 

https://www.dell.com...ror/td-p/319016.

 

And AGAIN, your "Update 1" misses the:

map /Win95/floppy.img (fd0)

line, that you actually issued, otherwise (fd0) is non existant or is a real floppy and NOT the /Win95/floppy.img

 

 

:duff:

Wonko



#13 ppgrainbow

ppgrainbow

    Member

  • Members
  • 70 posts

Posted 09 October 2020 - 05:09 PM

I tried adding the line in the SYSTEM.INI file:

 

[vcache]
maxfilecache=6144

 

...and I'm afraid that it made no difference and I still got an error that the I/O subsystem driver failed to load and that the \IOSUBSYS sub-directory is either corrupt or low on memory. :(

 

I forgot to mention map/WIN95/FLOPPY.IMG (fd0) and I did put it there when I set up Windows 95 from the floppy disk image.



#14 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 October 2020 - 06:05 PM

Check processor speed, try Fix95CPU.ISO:

https://forums.virtu...php?f=2&t=82787

even if it is not one of the two "usual" ones:

https://msfn.org/boa...u-limit-broken/

 

Maybe it is the specific Windows 95 version (a, b, c or OSR1, 2, 2.5) that makes a difference? :unsure:

 

:duff:

Wonko



#15 ppgrainbow

ppgrainbow

    Member

  • Members
  • 70 posts

Posted 10 October 2020 - 05:00 AM

I used the Fix Win95 CPU path on the floppy diskette image,  from the \W95RTM and \W95BOTH directories and I still got that I/O subsystem driver failing to load.

 

I guess that I'm gonna have to find other ways to get Windows 95 to install successfully from a VHD in GRUB4DOS. Any other options? I'm stumped here :(

 

If for some reason, I cannot get Windows 95 VHD to work install and operate properly in GRUB4DOS, I may have to give up.


Edited by ppgrainbow, 10 October 2020 - 05:01 AM.


#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 10 October 2020 - 07:58 AM

You should try another VM, VPC2007 has issues with Windows 95 (besides and before grub4dos), as a matter of fact Windows 95 is (was) not officially supported

 

I.e. it could be an incompatibility between the specific Win95 version and  VPC2007, one between it and the version of grub4dos, one between the version of grub4dos and Win95 and VPC2007.

 

Since you need not any "fancy" commands in grub4dos you can also try using the oldest suitable version, the 0.4.4 2009-10-16:

http://reboot.pro/to...16641-grub4dos/

http://reboot.pro/fi...e/175-grub4dos/

 

:duff:

Wonko



#17 ppgrainbow

ppgrainbow

    Member

  • Members
  • 70 posts

Posted 10 October 2020 - 08:24 AM

Thank you for the suggestion. I'm not too happy to say that GRUB4DOS hasn't been updated since August 9, 2020 with newer features and yet I'm surprised that the latest revision of GRUB4DOS *does* work under Virtual PC 2007. :)

 

While Windows 95 (and older versions of Windows) are not officially supported under Virtual PC 2007, the OSes should function as is.

 

As far as I know, I should use the --mem command to load a hard disk image into RAM. However, the consequences are that the changes will be lost after reboot.



#18 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 02 November 2020 - 01:47 PM

Why --in-situ ?

 

Basically, grub4dos mapped drives might be unrecognized/unseen by Win9x. If Win9x does not mount a volume, then all files on the volume will not be accessible.

 

If we use the --in-situ option to map a HD partition (logical volume) to a (primary) partition of a virtual HD, then, after Win9x gains control in protected-mode, we expect Windows could find (and mount) the real HD partition (logical volume) and so all the files should be accessible in protected mode. So we expect we could in some way avoid the Blue Screen that is caused by unmountable boot partition.

 

I recommend you use --in-situ on a partition, not on an VHD image file. At least you should first try it on a partition (logical volume). If all goes well on partitions, next, you may try it on VHD files.

 

And, --in-situ with --heads and --sectors-per-track ...... emm, you want to change the real geometry of your machine to a different one? Yes, in real-mode DOS or grub4dos environment, the map could work. But how about Windows protected mode? Work or not work. It is not sure. It is unknown. Grub4dos has no sophisticated protected-mode driver for the mapped real-mode virtual drives.

 

Finally, Win9x needs a driver like firadisk or winvblock or svbus.



#19 Elmis

Elmis
  • Members
  • 5 posts
  •  
    Latvia

Posted 02 November 2020 - 10:43 PM

I'm sorry for the late answer in this thread - direct Windows 95 (Chicago 4.00.116 – Win95A) installation into a VHD directly mapped with Grub4Dos for me was a very difficult experiment.

The bad news is that these old O/Ss for a long time I could not directly (without using “map –-mem” option) boot from VHDs placed even on a USB-Sticks, which, in worst case, do not need any additional drivers at all (Hard Drive Bible” 1996.p.83-87).  Booted from a directly mapped VHD, O/S freezes after a couple of seconds (nice Logo) without reporting any errors.  The utilities (Fdisk, Format) included in these old O/S are unsuitable even for formatting a USB-Stick larger than 2014MiB (from DOS no drive letter was assigned to the volume larger than exactly 2014MiB, instead, Win-98SE makes about 2048MiB FAT16 partitions) and most earlier Fdisk versions (Chicago - 116) generally freeze with a non flickering cursor (on a real PC) and also makes crazy virtual PC2007.  Even O/S loading from a floppy disk without a boot sector is not possible (“chainloader /io.sys” option does not work in this case).  Also unsuccessful (using the “–in-situ” option) was an attempt to load O/S installed in VHD with 16-Heads geometry from USB-Sticks with different (32-64-128-Heads) geometry. It is also well known that these old O/Ss were created with an errors made by programmers: "All versions of MS-DOS (including MS-DOS 7 [Windows 95]) have a bug which prevents booting on hard disks with 256 heads (FFh), so many modern  BIOSes provide mappings with at most 255 (FEh) heads. "  [INTER61 Copyright © 1989-2000 by Ralf Brown].

In past hard drives have jumpers (16/15-Heads), so for installing Windows 95A (15-Heads jumper setting) hard drives geometry was, I think (maybe, wrongly), no more than 240-Heads.

 

Now the good news - all the early versions of Windows_95 (Chicago_4.00.116 – Windows_95A) without any silly messages I managed to install into a VHD placed on a 2GB-SDHC memory card on a PC (P5G41T-M LX V2 + 4GB RAM + DualCore E2160). 495MiB (16-Heads) USB-Stick on SK6201AA controller also works excellent. The “problem” with the large amount of PCs RAM (for O/S installing) is fictitious and does not correspond to reality - you do not need to mechanically change anything, because the amount of RAM can be specified even before installing O/S in the corresponding files created by yourself for both - Normal and Safe modes.  The O/S requirements for the frequency (say, no more than 2 GHz) of the central processor is not a problem even for a more than 10-year-old PC - the operating frequency of the CPU on a good PC can be easily changed (in my experiment, from 1.2 GHz to 2.25 GHz – all O/S I have installed with 2.25GHz setting without any problem). The operating system “Chicago 4.00.116” has only historical value (on a real PC is useable only Safe Mode), and there is an acute problem for necessary drivers not only for a real PC, but even for PC2007.  A VHDs “O/S from Chicago_4.00.116 + all versions, what I can download, to Windows_95A included” installed on a real PC perfectly boots in a virtual machine PC2007SP1 and vice versa (driver correction is necessary using O/S Safe Mode).

I'm not even sure that early versions of Win95 are generally designed for such a giant hard disk as 1024*16*63 (on PC2007 utilities from corresponding O/S “sees” less cylinders or even wrongly tries to formant VHD with 32-Heads geometry), so I created a 625*16*63 “VhdTool.exe /create Chicago.vhd 322560000” VHD, formatted it from pure DOS with less capricious utilities included in IBM-PC-DOS-5.  The 2GB SDHC memory card was formatted from DOS using Win98-SE boot disk utilities and was formatted with 16-Heads geometry (it is also possible using G4D). For a complete description of the experiment, I probably need about 20 A4 paper sheets.

Therefore, only the conclusion: <<Chicago_4.00.116 – Windows_95A (on a some PCs) can also be easily installed into a VHD directly mapped with Grub4Dos, but the old O/Ss are more demanding on the size and geometry of hard disk>>.



#20 Elmis

Elmis
  • Members
  • 5 posts
  •  
    Latvia

Posted 02 November 2020 - 10:44 PM

I'm sorry for the late answer in this thread - direct Windows 95 (Chicago 4.00.116 – Win95A) installation into a VHD directly mapped with Grub4Dos for me was a very difficult experiment.

The bad news is that these old O/Ss for a long time I could not directly (without using “map –-mem” option) boot from VHDs placed even on a USB-Sticks, which, in worst case, do not need any additional drivers at all (Hard Drive Bible” 1996.p.83-87).  Booted from a directly mapped VHD, O/S freezes after a couple of seconds (nice Logo) without reporting any errors.  The utilities (Fdisk, Format) included in these old O/S are unsuitable even for formatting a USB-Stick larger than 2014MiB (from DOS no drive letter was assigned to the volume larger than exactly 2014MiB, instead, Win-98SE makes about 2048MiB FAT16 partitions) and most earlier Fdisk versions (Chicago - 116) generally freeze with a non flickering cursor (on a real PC) and also makes crazy virtual PC2007.  Even O/S loading from a floppy disk without a boot sector is not possible (“chainloader /io.sys” option does not work in this case).  Also unsuccessful (using the “–in-situ” option) was an attempt to load O/S installed in VHD with 16-Heads geometry from USB-Sticks with different (32-64-128-Heads) geometry. It is also well known that these old O/Ss were created with an errors made by programmers: "All versions of MS-DOS (including MS-DOS 7 [Windows 95]) have a bug which prevents booting on hard disks with 256 heads (FFh), so many modern  BIOSes provide mappings with at most 255 (FEh) heads. "  [INTER61 Copyright © 1989-2000 by Ralf Brown].

In past hard drives have jumpers (16/15-Heads), so for installing Windows 95A (15-Heads jumper setting) hard drives geometry was, I think (maybe, wrongly), no more than 240-Heads.

 

Now the good news - all the early versions of Windows_95 (Chicago_4.00.116 – Windows_95A) without any silly messages I managed to install into a VHD placed on a 2GB-SDHC memory card on a PC (P5G41T-M LX V2 + 4GB RAM + DualCore E2160). 495MiB (16-Heads) USB-Stick on SK6201AA controller also works excellent. The “problem” with the large amount of PCs RAM (for O/S installing) is fictitious and does not correspond to reality - you do not need to mechanically change anything, because the amount of RAM can be specified even before installing O/S in the corresponding files created by yourself for both - Normal and Safe modes.  The O/S requirements for the frequency (say, no more than 2 GHz) of the central processor is not a problem even for a more than 10-year-old PC - the operating frequency of the CPU on a good PC can be easily changed (in my experiment, from 1.2 GHz to 2.25 GHz – all O/S I have installed with 2.25GHz setting without any problem). The operating system “Chicago 4.00.116” has only historical value (on a real PC is useable only Safe Mode), and there is an acute problem for necessary drivers not only for a real PC, but even for PC2007.  A VHDs “O/S from Chicago_4.00.116 + all versions, what I can download, to Windows_95A included” installed on a real PC perfectly boots in a virtual machine PC2007SP1 and vice versa (driver correction is necessary using O/S Safe Mode).

I'm not even sure that early versions of Win95 are generally designed for such a giant hard disk as 1024*16*63 (on PC2007 utilities from corresponding O/S “sees” less cylinders or even wrongly tries to formant VHD with 32-Heads geometry), so I created a 625*16*63 “VhdTool.exe /create Chicago.vhd 322560000” VHD, formatted it from pure DOS with less capricious utilities included in IBM-PC-DOS-5.  The 2GB SDHC memory card was formatted from DOS using Win98-SE boot disk utilities and was formatted with 16-Heads geometry (it is also possible using G4D). For a complete description of the experiment, I probably need about 20 A4 paper sheets.

Therefore, only the conclusion: <<Chicago_4.00.116 – Windows_95A (on a some PCs) can also be easily installed into a VHD directly mapped with Grub4Dos, but the old O/Ss are more demanding on the size and geometry of hard disk>>.



#21 Elmis

Elmis
  • Members
  • 5 posts
  •  
    Latvia

Posted 02 November 2020 - 10:46 PM

I'm sorry for the late answer in this thread - direct Windows 95 (Chicago 4.00.116 – Win95A) installation into a VHD directly mapped with Grub4Dos for me was a very difficult experiment.

The bad news is that these old O/Ss for a long time I could not directly (without using “map –-mem” option) boot from VHDs placed even on a USB-Sticks, which, in worst case, do not need any additional drivers at all („Hard Drive Bible” 1996.p.83-87).  Booted from a directly mapped VHD, O/S freezes after a couple of seconds (nice Logo) without reporting any errors.  The utilities (Fdisk, Format) included in these old O/S are unsuitable even for formatting a USB-Stick larger than 2014MiB (from DOS no drive letter was assigned to the volume larger than exactly 2014MiB, instead, Win-98SE makes about 2048MiB FAT16 partitions) and most earlier Fdisk versions (Chicago - 116) generally freeze with a non flickering cursor (on a real PC) and also makes crazy virtual PC2007.  Even O/S loading from a floppy disk without a boot sector is not possible (“chainloader /io.sys” option does not work in this case).  Also unsuccessful (using the “–in-situ” option) was an attempt to load O/S installed in VHD with 16-Heads geometry from USB-Sticks with different (32-64-128-Heads) geometry. It is also well known that these old O/Ss were created with an errors made by programmers: "All versions of MS-DOS (including MS-DOS 7 [Windows 95]) have a bug which prevents booting on hard disks with 256 heads (FFh), so many modern  BIOSes provide mappings with at most 255 (FEh) heads. "  [INTER61 Copyright © 1989-2000 by Ralf Brown].

In past hard drives have jumpers (16/15-Heads), so for installing Windows 95A (15-Heads jumper setting) hard drives geometry was, I think (maybe, wrongly), no more than 240-Heads.

 

Now the good news - all the early versions of Windows_95 (Chicago_4.00.116 – Windows_95A) without any silly messages I managed to install into a VHD placed on a 2GB-SDHC memory card on a PC (P5G41T-M LX V2 + 4GB RAM + DualCore E2160). 495MiB (16-Heads) USB-Stick on SK6201AA controller also works excellent. The “problem” with the large amount of PCs RAM (for O/S installing) is fictitious and does not correspond to reality - you do not need to mechanically change anything, because the amount of RAM can be specified even before installing O/S in the corresponding files created by yourself for both - Normal and Safe modes.  The O/S requirements for the frequency (say, no more than 2 GHz) of the central processor is not a problem even for a more than 10-year-old PC - the operating frequency of the CPU on a good PC can be easily changed (in my experiment, from 1.2 GHz to 2.25 GHz – all O/S I have installed with 2.25GHz setting without any problem). The operating system “Chicago 4.00.116” has only historical value (on a real PC is useable only Safe Mode), and there is an acute problem for necessary drivers not only for a real PC, but even for PC2007.  A VHDs “O/S from Chicago_4.00.116 + all versions, what I can download, to Windows_95A included” installed on a real PC perfectly boots in a virtual machine PC2007SP1 and vice versa (driver correction is necessary using O/S Safe Mode).

I'm not even sure that early versions of Win95 are generally designed for such a giant hard disk as 1024*16*63 (on PC2007 utilities from corresponding O/S “sees” less cylinders or even wrongly tries to formant VHD with 32-Heads geometry), so I created a 625*16*63 “VhdTool.exe /create Chicago.vhd 322560000” VHD, formatted it from pure DOS with less capricious utilities included in IBM-PC-DOS-5.  The 2GB SDHC memory card was formatted from DOS using Win98-SE boot disk utilities and was formatted with 16-Heads geometry (it is also possible using G4D). For a complete description of the experiment, I probably need about 20 A4 paper sheets.

Therefore, only the conclusion: <<Chicago_4.00.116 – Windows_95A (on a some PCs) can also be easily installed into a VHD directly mapped with Grub4Dos, but the old O/Ss are more demanding on the size and geometry of hard disk>>.







Also tagged with one or more of these keywords: win95, vhd, --in-situ

2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users