Open aca18d opened 5 months ago
I just tried to install Win95 RTM (aka "Release To Manufacturing", which was the original release) version, and the install worked fine.
This is on a Linux host using DOSBox-X SDL2 (nightly) and the English version of Win95 RTM. I don't see this "Call E0 unhandled" message. But based on previous cases where we have seen this E0 message, this seems like it may have had something to do with disk emulation. What type of Win9x HDD and CD setup are you using? Are you using any virtual folder mounts?
I created a standard 2 Gb fat16 image disk mounted as C and copied the WIN95 folder inside a Linux folder, mounted as D.
Exactly I did:
mount D cdinst_w95 mount E /mnt/sr0 IMGMAKE w95hd.img -t hd_2gig -fat 16 IMGMOUNT C w95hd.img XCOPY E:\WIN95 D:\WIN95 /I /E D: CD \WIN95 SETUP
I also remenber that installing, for example, MS Office English version on Windows 95 Italian version caused tons of problems, maybe because of something related to the language translation.
That is likely where the problem is, please unmount D: and E: before starting the installer. Copy the Win95 folder to the C: drive instead. That, or make D: an image, instead of a host folder mount.
Thank you so much. Making D: as an image didn't work. Copying the Win95 folder on C: worked instead.
Thank you so much. Making D: as an image didn't work. Copying the Win95 folder on C: worked instead.
Is Windows 95 using the INT 21h call that returns which drive is the boot drive?
Maybe it's time to provide an option to control which drive (C: or D:) is returned as the boot drive.
Is Windows 95 using the INT 21h call that returns which drive is the boot drive?
Maybe it's time to provide an option to control which drive (C: or D:) is returned as the boot drive. Oh, I'm not so skilled, I'd need to know how to check that INT 21h. :)
Thank you so much. Making D: as an image didn't work. Copying the Win95 folder on C: worked instead.
Is Windows 95 using the INT 21h call that returns which drive is the boot drive?
Maybe it's time to provide an option to control which drive (C: or D:) is returned as the boot drive.
That may well be the issue, as it happens quite late during the first phase of SETUP, but just prior to the first reboot. I'm not sure having an option to control the boot drive is the best solution, or if that would even solve the issue. But from an automated perspective, in this case only one drive was an image mount, and therefore only one drive could be the boot drive. In the case where multiple images are mounted, it could obviously be more tricky to automatically select the boot drive...
Describe the bug
Installation stops at 73% file copying (last phase).
Steps to reproduce the behaviour
Follow the installation procedure.
Expected behavior
And there it stops. Installation broken.
What operating system(s) this bug have occurred on?
Windows 95 first version OEM (Italian) - older than OSR1
What version(s) of DOSBox-X have this bug?
Either 2023.10.06 and 2024.03.01
Used configuration
Output log
Additional information
Built with "build-debug-sdl2".
Have you checked that no similar bug report(s) exist?
Code of Conduct & Contributing Guidelines