Closed MX9000 closed 1 year ago
Running install.com from floppy disks with the -debug
option
LOG: 26965116 DEBUG EXEC:Parsing command line: install
LOG: 26965119 EXEC:Execute install.COM 0
LOG: 26965119 FILES:file open command 0 file install.COM
LOG: 26965119 DEBUG DOSMISC:DOS_AllocateMemory(blocks=0x0048) = 0x07ca-0x0811
LOG: 26965119 DEBUG DOSMISC:DOS_AllocateMemory(blocks=0x97ec) = 0x0813-0x9ffe
LOG: 26965153 DEBUG DOSMISC:DOS_ResizeMemory(seg=0x0813) blocks=0x06d3
LOG: 26965354 FILES:file open command 0 file RESOURCE.CFG
LOG: 26984218 MISC:MPU-401:Reset FF
LOG: 26984293 SBLASTER:Unhandled write to SB Port 22A
LOG: 27049857 SBLASTER:DSP:Reset
LOG: 27052329 DEBUG DOSMISC:DOS_AllocateMemory(blocks=0x0200) = 0x0ee7-0x10e6
LOG: 27052388 INT10:Set Video Mode 3
LOG: 27052388 MOUSE:New video mode is the same as the old
LOG: 27052945 FILES:file search attributes 8 name A:STELLAR7. ??
LOG: 27052945 DOSMISC:DIRCACHE: Set volume label to STELLAR7 1
LOG: 27052945 FCB:DOS:0x11 FCB-FindFirst used, result:al=0
LOG: 27055354 VGA:h total 100 end 80 blank ( 80/ 98) retrace ( 85/ 97)
LOG: 27055354 VGA:v total 449 end 400 blank (407/442) retrace (412/414)
LOG: 27055354 VGA:VGA refresh rate is now, 70.087
LOG: 27055354 VGA:screen: 1.333, scanfield: 1.312, scan: 1.016, vratio: 1.800
LOG: 27055354 VGA:h total 0.03178 (31.47kHz) blank(0.02542/0.03114) retrace(0.02701/0.03082)
LOG: 27055354 VGA:v total 14.26806 (70.09Hz) blank(12.93341/14.04562) retrace(13.09230/13.15585)
LOG: 27055354 VGA:video clock: 28.32MHz mode M_TEXT
LOG: 44959993 DEBUG DOSMISC:DOS_AllocateMemory(blocks=0x8f17) = 0x10e8-0x9ffe
LOG: 44961151 FILES:file search attributes 8 name A:STELLAR7. 1
LOG: 44961151 DOSMISC:DIRCACHE: Set volume label to STELLAR7 1
LOG: 44961151 FCB:DOS:0x11 FCB-FindFirst used, result:al=255
LOG: 44961176 FILES:file search attributes 2 name A:STELLAR7. 1
LOG: 44961176 FCB:DOS:0x11 FCB-FindFirst used, result:al=255
LOG: 57836949 FILES:file search attributes 8 name A:STELLAR7. 1
LOG: 57836949 DOSMISC:DIRCACHE: Set volume label to STELLAR7 1
LOG: 57836949 FCB:DOS:0x11 FCB-FindFirst used, result:al=255
LOG: 57836974 FILES:file search attributes 2 name A:STELLAR7. 1
LOG: 57836974 FCB:DOS:0x11 FCB-FindFirst used, result:al=255
I dug into this a little bit. There's two primary volume searches for the stellar7 installer.
It looks for STELLAR7?? at startup to determine if either install floppy is currently in the drive (this is part of how it determines if it should show you the "copy to HD" label.)
See: LOG: 27052945 FILES:file search attributes 8 name A:STELLAR7. ??
Later, it looks for the expected floppy during the copy, searching for STELLAR7 1.
See: LOG: 44961151 FILES:file search attributes 8 name A:STELLAR7. 1
Due to the special case handling for volume labels in the int21 find fcb handlers it hits a couple different bugs that fail this comparison.
First: The input pattern gets munged by DOS_DTA::GetSearchParams to insert the period you see in the logs. However fatDrive::FindNextInternal has a number of special case handlers to skip adding periods to the find_name results when it's looking at a volume label. (e.g LOG: 27052945 DOSMISC:DIRCACHE: Set volume label to STELLAR7 1)
Second: WildFileCmp is actually written with the expectation that the find_name passed in will have a period to re-split the name into 8+3 for comparison. The obvious issue here is that you'd only ever get a comparison for the early part of the volume name, but because WildFileCmp supports 9.3 for the wildcard (presumably to allow for patterns like FILENAME.EXT) if you do the naive thing and just fix-up GetSearchParams to leave the period out of volume attribute searches you'll actually fail earlier in the process because you end up with the comparison of STELLAR7 <--> STELLAR7? which fails.
Without really playing with the actual DOS bios and looking into some of the edge cases it's hard to know what behavior is really expected to ensure 100% compatibility. But to just fix this particular case with minimal changes, I think the simplest thing is probably to fix up GetSearchParams to not insert a period for volume attribute searches and then branch to LWildFileCmp for the comparison to avoid the 8 character filename limits when comparing volume labels. This is a bit of an abuse of the LFN functionality, but the underlying wild_match is internal to drives.cpp and neither valid input should contain periods anyway.
This will clearly change the behavior of some potential requests-- but seems ?unlikely? to break existing compatibility.
Prior text was not quite correct. There's some weirdness in how the installer expects to wildcard/match the volume label. As far as I can infer from the behavior it wants the standard whitespace trimming to happen as if the input was 8.3, even though volume labels are allowed to have spaces in the middle of their 11 characters.
Put up a diff that seems to work for this case, but might want to test against any other known uses of volume label matching just in case something weird got broken.
Code of Conduct & Contributing Guidelines
Have you checked that no other similar bug report(s) already exists?
What operating system(s) this bug have occurred on?
Windows 10 Pro 21H2 64 bit
What version(s) of DOSBox-X have this bug?
0.83.20 SDL2 64 bit VSbuild
Describe the bug
Trying to install the game from these floppy disk images (https://archive.org/details/002647-Stellar7) the INSTALL.COM installer keeps asking for the disk with volume label "STELLAR7 1" that is already mounted in drive A.
If I extract all the files from the two floppy disk images into one folder and mount it as drive A, the installation is successful but in the logging console there are several INT 21h related errors. In DOSBox 0.74-3 if I try to mount the floppy disk image, the INSTALL.COM program can't even find the hard disk: the installation option is missing from the menu.
Expected behavior
The INSTALL.COM program should copy the game files on the hard disk.
Steps to reproduce the behaviour
Used configuration
Emulator log
Additional context
No response