search

joncampbell123 / dosbox-x

DOSBox-X fork of the DOSBox project
GNU General Public License v2.0
2.68k stars 381 forks source link

launching windows 98 with win.com [from DOSBox-X shell, without booting into guest OS] not working #1217

Open masaykh opened 5 years ago

masaykh commented 5 years ago

In dosbox.conf ver set to 7.00 But when trying to start windows using win.com - it gives: MSDOS 7.00 or higher is required

To Reproduce Steps to reproduce the behavior:

  1. Install windows 98 into Dosbox
  2. Set VER option in conf file to 7.00
  3. try starting windows using win.com

Expected behavior Windows expected to boot from execution of win.com executable

Environment (please complete the following information):

Additional context In dosbox log files i found the following : 1407276395 ERROR DOSMISC:DOS:INT 2F Unhandled call AX=122E 1407276401 ERROR DOSMISC:DOS:INT 2F Unhandled call AX=122E 1407276408 ERROR DOSMISC:DOS:INT 2F Unhandled call AX=122E 1407276415 ERROR DOSMISC:DOS:INT 2F Unhandled call AX=122E 1407277142 ERROR DOSMISC:DOS:INT 2F Unhandled call AX=122E 1407277185 ERROR DOSMISC:DOS:INT 2F Unhandled call AX=1611 1407277202 ERROR DOSMISC:DOS:INT 2F Unhandled call AX=160A 1407277224 DOSMISC:Call is made for list of lists - let's hope for the best

Allofich commented 5 years ago

If you type ver at the prompt in DOSBox-X, does it show Reported DOS version 7.00?

joncampbell123 commented 5 years ago

Windows 98 uses version 7.10 not 7.0

Windows 95 and Windows 98 support has only been tested so far in the form of BOOTing a disk image with it installed.

I do not yet expect Windows 9x to run directly from the DOSBox-X DOS environment.

masaykh commented 5 years ago

now it is a little bit more interesting:

i set VER to 7.10 and ensured that XMS is enabled

now starting win.com do the following: for few moments it executes scanreg and next switching to VMM32 Onscreen errors are: Registry file not found Memory cache error in XMS

inside the log - we have the following: https://gist.github.com/masaykh/069e5540ac803457b8a4789fed9197ec

and this one: ERROR CPU:Illegal Unhandled Interrupt Called 6 printed endlessly at the end

Support of running win9x from the DOSBox-X DOS environment is in the roadmap?

joncampbell123 commented 5 years ago

That doesn't surprise me, according to RBIL there's an undocumented INT 2Fh call to ask the DOS kernel where the registry is starting with MS-DOS 7.0 (Windows 95). http://www.ctyme.com/intr/rb-4527.htm

I vaguely recall from other sources I don't recall at this time, that Windows 95 changed the HMA area to one with it's own allocation chain instead of just counting downward from the top in an inflexible manner like it used to do. But I'm not entirely sure what the "Memory cache" would be.

Even if Windows 95 did boot, I don't think it calls down to DOS for file access, though it will call down to INT 13h if it can't identify the block device with it's own drivers. Mounting a folder as a drive wouldn't work with that. To my knowledge Windows 95 will not easily run from the DOSBox-X shell, unless I'm wrong.

joncampbell123 commented 5 years ago

Proof of concept DOSLIB code that queries that information:

https://github.com/joncampbell123/doslib2/blob/master/dos/asmexam/w95sysrg.asm

joncampbell123 commented 5 years ago

What I mean is that Windows 95 uses it's own 32-bit FAT driver, even if calling down to the BIOS for disk access, so running Windows 95 from C: when C: is mounted as a folder will likely not work.

It might work if you mount C: from an image file that you installed Windows 95 onto.

masaykh commented 5 years ago

I have Windows 98 in mounted disk image form. It is attached to the dosbox environment through: imgmount c ./win.img -t hdd

jschwartzenberg commented 4 years ago

What I mean is that Windows 95 uses it's own 32-bit FAT driver, even if calling down to the BIOS for disk access, so running Windows 95 from C: when C: is mounted as a folder will likely not work.

Merge/Win4Lin 9x work this way. While Windows 9x has its own driver support, it can fall back to using drives that would otherwise only be available in DOS, even for booting. You do need a way to boot the DOS included with WIndows from a folder to enable this. (Similar to DOSEMU.) That is related to: https://msfn.org/board/topic/109018-windows-98-in-dr-dos/?do=findComment&comment=721209

Wengier commented 4 years ago

The current code already supports the INT 2F call to ask the location of the registry (default: C:\WINDOWS\SYSTEM.DAT), along with support to write Windows 9x bootlogs (in DOSBox-X's log file) etc. In such case if you try to start Windows 98 WIN.COM from the built-in DOSBox-X shell, after a while you will eventually see the message:

Cannot load a device file that is specified in SYSTEM.INI.

The performance of Windows should not be affected without this file. C:\WINDOWS\system\VMM32\IOS.VXD Press a key to continue

After you press some key, the following will eventually show up:

Insufficient memory to initialize Windows

Quit one or more memory-resident programs or remove unnecessary utilities from your CONFIG.SYS and AUTOEXEC.BAT files, and restart your computer.

Press any key to continue...

The system will then quit. If you look at the Windows 9x boot log (as written in DOSBox-X's log file), it will read:

BOOTLOG: Loading Vxd = VMM BOOTLOG: LoadSuccess = VMM BOOTLOG: Loading Vxd = CONFIGMG BOOTLOG: LoadSuccess = CONFIGMG BOOTLOG: Loading Vxd = NTKERN BOOTLOG: LoadSuccess = NTKERN BOOTLOG: Loading Vxd = VWIN32 BOOTLOG: LoadSuccess = VWIN32 BOOTLOG: Loading Vxd = VFBACKUP BOOTLOG: LoadSuccess = VFBACKUP BOOTLOG: Loading Vxd = VCOMM BOOTLOG: LoadSuccess = VCOMM BOOTLOG: Loading Vxd = COMBUFF BOOTLOG: LoadSuccess = COMBUFF BOOTLOG: Loading Vxd = C:\WINDOWS\system\VMM32\IFSMGR.VXD BOOTLOG: LoadSuccess = C:\WINDOWS\system\VMM32\IFSMGR.VXD BOOTLOG: Loading Vxd = C:\WINDOWS\system\VMM32\IOS.VXD BOOTLOG: LoadFailed = C:\WINDOWS\system\VMM32\IOS.VXD BOOTLOG: Loading Vxd = mtrr BOOTLOG: LoadSuccess = mtrr BOOTLOG: Loading Vxd = SPOOLER BOOTLOG: LoadSuccess = SPOOLER BOOTLOG: Loading Vxd = UDF BOOTLOG: LoadSuccess = UDF BOOTLOG: Loading Vxd = VFAT BOOTLOG: LoadSuccess = VFAT BOOTLOG: Loading Vxd = VCACHE BOOTLOG: LoadFailed = VCACHE BOOTLOG: Loading Vxd = VCOND BOOTLOG: LoadSuccess = VCOND BOOTLOG: Loading Vxd = VCDFSD BOOTLOG: LoadSuccess = VCDFSD BOOTLOG: Loading Vxd = VXDLDR BOOTLOG: LoadSuccess = VXDLDR BOOTLOG: Loading Vxd = VDEF BOOTLOG: LoadSuccess = VDEF BOOTLOG: Loading Vxd = VPICD BOOTLOG: LoadSuccess = VPICD BOOTLOG: Loading Vxd = VTD BOOTLOG: LoadSuccess = VTD BOOTLOG: Loading Vxd = REBOOT BOOTLOG: LoadSuccess = REBOOT BOOTLOG: Loading Vxd = VDMAD BOOTLOG: LoadSuccess = VDMAD BOOTLOG: Loading Vxd = VSD BOOTLOG: LoadSuccess = VSD BOOTLOG: Loading Vxd = V86MMGR BOOTLOG: LoadSuccess = V86MMGR BOOTLOG: Loading Vxd = PAGESWAP BOOTLOG: LoadSuccess = PAGESWAP BOOTLOG: Loading Vxd = DOSMGR BOOTLOG: LoadSuccess = DOSMGR BOOTLOG: Loading Vxd = VMPOLL BOOTLOG: LoadSuccess = VMPOLL BOOTLOG: Loading Vxd = SHELL BOOTLOG: LoadSuccess = SHELL BOOTLOG: Loading Vxd = PARITY BOOTLOG: LoadSuccess = PARITY BOOTLOG: Loading Vxd = BIOSXLAT BOOTLOG: LoadSuccess = BIOSXLAT BOOTLOG: Loading Vxd = VMCPD BOOTLOG: LoadSuccess = VMCPD BOOTLOG: Loading Vxd = VTDAPI BOOTLOG: LoadSuccess = VTDAPI BOOTLOG: Loading Vxd = PERF BOOTLOG: LoadSuccess = PERF BOOTLOG: Loading Vxd = C:\WINDOWS\SYSTEM\vrtwd.386 BOOTLOG: LoadSuccess = C:\WINDOWS\SYSTEM\vrtwd.386 BOOTLOG: Loading Vxd = C:\WINDOWS\SYSTEM\vfixd.vxd BOOTLOG: LoadSuccess = C:\WINDOWS\SYSTEM\vfixd.vxd BOOTLOG: Loading Vxd = ebios BOOTLOG: Skipped (not needed) = ebios BOOTLOG: Loading Vxd = vshare BOOTLOG: LoadSuccess = vshare BOOTLOG: Loading Vxd = dynapage BOOTLOG: LoadSuccess = dynapage BOOTLOG: Loading Vxd = vmouse BOOTLOG: LoadSuccess = vmouse BOOTLOG: Loading Vxd = msmouse.vxd BOOTLOG: LoadSuccess = msmouse.vxd BOOTLOG: Loading Vxd = vcd BOOTLOG: LoadSuccess = vcd BOOTLOG: Loading Vxd = vpd BOOTLOG: LoadSuccess = vpd BOOTLOG: Loading Vxd = int13 BOOTLOG: LoadSuccess = int13 BOOTLOG: Loading Vxd = vkd BOOTLOG: LoadSuccess = vkd BOOTLOG: Loading Vxd = vdd BOOTLOG: LoadSuccess = vdd BOOTLOG: Loading Vxd = vflatd BOOTLOG: LoadSuccess = vflatd BOOTLOG: Loading Vxd = EBIOS BOOTLOG: Skipped (not needed) = EBIOS BOOTLOG: Loading Vxd = C:\WINDOWS\system\VMM32\IOS.VXD BOOTLOG: LoadFailed = C:\WINDOWS\system\VMM32\IOS.VXD BOOTLOG: Loading Vxd = VCACHE BOOTLOG: LoadFailed = VCACHE

On the other hand, Windows 98 will boot just fine in DOSBox-X when booting a disk image with it of course.

Wengier commented 4 years ago

I have checked that the reason for the VCACHE loading failure is that it tries to open the device named "IFS$HLP$" as provided by Windows 98's IFSHLP.SYS, but that device cannot be found. Trying to load IFSHLP.SYS with DOSBox-X's built-in DEVICE command before starting WIN.COM will not help in this case, because even though "DEVICE IFSHLP.SYS" seems to succeed, it does not actually create the IFS$HLP$ device within DOSBox-X. Adding a config.sys section to dosbox.conf consisting of DEVICE= commands for the DOSBox-X kernel to load SYS files from as mentioned in Issue #289 should help in such case (IFSHLP.SYS is apparently required during Windows 98's boot process).

Wengier commented 4 years ago

@joncampbell123 I believe this issue is related to the DOS IOCTL function (which has been recently improved) too, because it reveals the fact that DOSBox-X does not support external device drivers that are accessed by their name, such as the device named "IFS$HLP$" as provided by Windows 98's IFSHLP.SYS. Loading IFSHLP.SYS with the built-in DEVICE command will succeed, but trying to open, read from, or write to it via the IOCTL functions will all fail. The IFSHLP.SYS device driver is useful for the WFW 3.11 too for network support, so without this feature it is impossible to enable network support in WFW 3.11 as well if it is run from the DOSBox-X shell.

Wengier commented 4 years ago

I have now opened a separate issue (#1545) for this.

Torinde commented 1 week ago

Related: