deomsh

Hmm. Code 10 gives no clue I'm afraid. If there are no conflicts seen in the original 'Basic configuration' you can try following. 1) Check if there is any NOIDE-entry in your registry. Remove! More details here: https://www.techrepublic.com/article/solve-ms-dos-compatibility-mode-problems-on-pci-ide-controllers-with-these-troubleshooting-tips/ 2) Write down ALL what is showed in the Basic configuration. Probably only IRQ's and Input/Output (I/O) addresses. 3) Then change to your working 'Configuration'. Compare the two configurations and write down the values NOT used in the working configuration. 4) Go to Properties of Computer (still inside Device Manager) and open the tab 'Reserve Resources'. Reserve the Resources from the Basic configuration that are NOT used in your working configuration. Probably only I/O-addresses. After next boot Windows will be forced to use other, available, Resources. 5) Reboot and pray. BTW I'm not sure if this procedure must be done in Normal mode or in Safe mode. Personally I never needed it. Just an idea based on 'PC HULP', a Dutch translation of a German book from Andreas Voss and Thorsten Konetzko (publisher Easy Computing).

This is not clear to me. Has the CD-DRIVE a yellow exclamation mark, or (parts of) the Controller? Maybe a picture would be helpfull. From the Resources tab too. Are there any Error Codes in Device Manager, or IRQ or I/O conflicts?

First about your second question. During Setup, most vxd's of a certain class are 'bound together' in one file: VMM32.VXD (in %windir%\SYSTEM). The directory 'VMM32' can be fully empty! Sometimes Setup will copy one or more vxd's to the VMM32-directory. If an updated vxd is needed, it can be copied to this directory. Such vxd's are loaded during boot instead of their counterparts in VMM32.VXD! In your case IOS.VXD will already have been in the VMM32-folder. I have seen this in Windows 98SE installations on my own motherboards too. BTW be aware there are other types of vxd's too. You can find them in %windir%\SYSTEM and in %windir%\SYSTEM\IOSUBSYS. About ESDI_506.PDR: I don't expect anything in this direction. But feel free to try. My opinion: do not use the unofficial 48-bit updates if you are using HCDP and SATA RLOEW-updates who patch ESDI_506.PDR. On my boards I had bad experiences. As lender of last resort an Unofficial Service Pack can be used. To stay at the safe side, I would suggest OLD 98 SE SP2 2.1a Stable, NOT the 3.xx versions. I am not against them, but reinstalling Windows will not overwrite all updated files. If one wanted to get rid of them, sometimes FORMAT C: is the best option (apart from installation in a new Windows directory with a different name, like 'Win98SE').

You can try the 4.10.2225 versions (both files!). Extract them with 7z in Safe Mode and copy to %windir%\SYSTEM\VMM32 I would suggest to try CONFIGMG.VXD first. You can find many updates and unoffical service packs here: http://www.mdgx.com/web.htm

Hmm.. What version numbers have CONFIMG.VXD and IOS.VXD?

It is a well known 'secret' if Windows' SETUP can't find CD/DVD drives having MS-DOS drivers in CONFIG.SYS/AUTOEXEC.BAT can be helpfull. In one of your previous post's I found you are using SHSUCDX in AUTOEXEC.BAT. As far as I know SETUP will search for MSCDEX. Afterwards MSCDEX will be REM'd out by Windows SETUP. In your case such a line would look (something) like this: C:\WINDOWS\COMMAND\MSCDEX.EXE /D:IDE-CD Don't know if this will be helpfull, just an idea that came up to my mind.

About vcache: On 'low' memory systems (below 512 MB) there should be no need to set vcache entries * (unless there are stability problems!). In general above 512MB maxfilecache should be set. RLOEW gave as a rule of thumb: minimum 1/24 of total memory. He saw no need to set minfilecache. * Edit: although Q181862 prescribes that below 512 MB maxfilecache should be set to 70% of RAM! My experiments, reported in my thread SMARTDRIVE REVISITED.... https://msfn.org/board/topic/176877-smartdrive-revisited-sata-drives-in-msdos-compatibility-mode/page/2/ of December 8, 2018, suggests if minfilecache is NOT set, it's still there and set internally by Windows. The value depends on total memory (not fully lineair!). So minfilecache is only needed if maxfilecache is set BELOW the internal value if minfilecache. About CONFIG.SYS: FILES, BUFFERS and STACKS are MS-DOS-related, should not affect Windows performance. In case of MS-DOS windows, the number of FILES in each VM can be increased with SYSTEM.INI entry PerVMFiles. Also there is MinSPs to increase spare stack pages. See: http://www.mdgx.com/lastweek.htm

Sorry for the confusion, I forgot you switched to the 'normal' IDE-Controller. But I ment the IDE-Controller in general, not the identification from your Intel-inf file (driver of the Primary will in both cases be ESDI-506.PDR I presume). I was hoping de-activating the controller would help to overcome MS-DOS Compatibility Mode and connect <somehow> your AHCI-Controller to your hard-drive.

Did you try to disable the Ultra ATA controller? Setting connections to 'none'.

If you really have only ONE harddrive (the one you showed in a picture earlier), I do not understand the 'Intel ICH8M Ultra ATA Storage Controllers' entry. The AHCI-controller looks 'good'. Just a wild guess: search in your in INF-folder for the phrase 'Intel ICH8M....' and rename the INF-file (with extension 'BAK' or whatever you like). Then remove 'Intel ICH8M Ultra ATA Storage Controllers' in Device Manager and reboot. B.T.W. If the other Intel-devices are mentioned in the same INF-file, remove them too before reboot.

Nice SMARTDRIVE make such a big difference. Just curious if maximun Read-Ahead buffer gives more improvement: SMARTDRIVE /L /B:57344 (buffer forced in Low Memory is normally faster, but will cost more 'low mem' of course).

During the final tests of FATLSDIR.G4B I found NTFS to be very slow. Especially a problem if parsing directories with many files, or if searching for a file or a directory. After some changes I couldn't get any faster. See following comparisons made with LOOPTEST.G4B (working version, unpublished). Performance of FAT16 is best, FAT32 'good' too. EXFAT already much slower (different filesize!), but NTFS is really bad. I think the bottleneck is the speed of raw cat --length=0 FILE - indispensable to identify directories and used to get file-size too. With help of LOOPTEST.G4B is tried to reproduce the behavior if this internal Grub4Dos command. The story is a bit complicated, because LOOPTEST.G4B has one command-line only, so all variables are set to one fixed value. Following print-screen shows my approach, using some magic (and some patience to get a 'working' command-line. Watch use of '#' instead of %^% ! First command is FATLSDIR.G4B, showing first 5 files to test with cat. By chance I had numbered files, used in earlier tests. After deleting all variables, the third command is LOOPTEST.G4B, with ONE Grub4Dos command-line to execute (too long to fit on the screen). Fourth command shows the variables 'fed' during the looptest to Grub4Dos for execution. Also final values of the three variables, changed after each single test-loop. The time of 1000 executions of the Grub4Dos command-line is almost the same as the difference between FAT and NTFS (see second print-screen above). I tested the difference between cat and raw cat too, without conclusive results. 'Raw' seems a little bit faster, but access-time to a file in VBOX 6 has a considerable variation, about 6.5%. To me it seems that the other commands used, can't be of much influence on speed. See last print screen (showing 'middle-part' of the command-lines too). BTW after last command value of 'size' is no longer file-size. So my question is if the slow file-access in case of NTFS is by default, or if there are faster solutions with Grub4Dos to get the size of a file? Edit I did some more test 'in the wild' on a 500GB sata HD/SSD hybrid disk. This time there where sometimes long looptests with FAT32/FAT16 too, so I can not rule out hardware /dataset related issues. For now I will skip these experiments.

Thanks @RainyShadow, but I asked that earlier, before he switched to RLoew's AHCI-driver, BIOS should be in AHCI-mode now. According to the earlier picture of Device Manager there are TWO harddisk controllers and ONE standard IDE 55 disk and ONE Primary controller with yellow exclamation mark. I would like to see a new picture, of the current configuration. Devices viewed by Connection, with all harddisk connections visible.

Your story is vague for me. Please show full CONFIG.SYS and AUTOEXEC.BAT. Is the C-drive IDE?

I am a bit out of idea's, except that reinstalling with SETUP /p i is worth a try. If I red your posts correctly, you used the /p j-switch so far.

Hmm. Are there any SATA-options in the BIOS? If yes, is SATA set to IDE-mode (=ATA, not AHCI)?

I had the same problem. Not fully sure about it, but it seems that the SATA patch needs a decent Microsoft version of ESDI_506.PDR. Most easy is to extract the original version from the CD-cab, replace the new version in IOSUBSYS, delete the backups. Then run in Real mode MS-DOS first RLOEW's High Capacity Disk Patch, and second the SATA Patch.

Hmm. Maybe its better to use your USB-FLOPPY to copy the content of the WIN98-directory (as its named on the original CD) to a directory on your harddrive, let's say C:\WIN98 (commands: md C:\WIN98 and copy D:\WIN98\*.* C:\WIN98 -if 'D:' is your CD-station). Then remove the USB-FLOPPY and reboot to your harddrive in MS-DOS-mode. Go to your installation-directory with command: cd C:\WIN98 and run setup again. Afterwards you can try if you can get access to your USB-FLOPPY from Windows.

@kannalo I hope you don't have Windows ME, is more complicated because HDATSR.EXE can't be used. If: in SYSTEM.INI [drivers] wavehda=hda2.dll is written (file must be in C:\WINDOWS\SYSTEM); in AUTOEXEC.BAT the line HDATSR.EXE is present (and file in C:\WINDOWS), than the installation succeeded.

@kannalo First of all: what are the specs of your machine? Which type of motherboard (or laptop), which HDA-codec? Please give as much details as you can find. And what message gave Windows during the crash?

If you boot from USB-FLOPPY, the BIOS will use USB-Legacy mode, so MS-DOS will have access to the USB-FLOPPY without a driver. During setup Windows 98SE will install its own USB-driver. As soon this driver is 'active' the USB bus will 'reset', and (still needed) access to the USB-FLOPPY will be lost.

Thanks, I will try So far I relied heavily on Imgburn for ISO's and on my CD/DVD-collection. I had a bad time testing ISO's because I tried a new version of Grub4Dos too, which gave problems with UDF. Maybe it's good to run some new tests. I saw that in between 'mkisofs' evolved to CDRTOOLS-3.02a10-win-x86_64 (following an old link in your post). Luckily I possess Windows 10 64-bit. I hope the command-line will accept your script. My script changes nothing on the source-side, I rely on what 'ls' is able to read, and on 'fat' or 'dd' for copying. I started my script to be able to copy a full directory, it only evolved a little bit. Case comes only into play while writing a source-directory and/or source-file and with my use of wildcards. So far I found real case-sensitivity only necessary on Linux File Systems, although as soon UDF is detected my script set case-sensitivity too. Personally I'm not so fond of case-sensitivity, and my switch /nocase can be used in most cases. On the first print-screen is one of my tests to cope with case-sensitivity on ReIsEr2Fs (I see I forgot a '/', but due my new processing of source and target -this time- without consequences). The switch /nocase can be seen in action in the next print-screen. Unless a given file is copied, the case of the output shown is identical to the redirected output of 'ls' (or should be, unless I made a mistake). The target is a different thing of course, 'fat' will deliver uppercase only (in this case not identical to the shown output - I am not sure if I changed this in my final version 0.3, but it's not a serious matter).

FATTOOLS: FATCOPY.G4B VERSION 0.3 I worked for a long time on version 3, which resulted in many changes and new features too. Sadly the size of the script more than doubled. Download is at the end of this post. Updates: Improved switch /d to add source-directory to a given target-directory instead of to the root only. Changing of base memory-address with optional third argument on the FATCOPY.G4B command-line instead by switch. Addresses 0x0000-0x2999 and 0x4000-0xD460 will be refused. The switch /ls is auto-set if a related switch is used, /ls is only needed if switching to 'ls' directory-parsing on a FAT-source. Copy from NTFS: ‘$’-directories/files are copied only with the switch /$, ment for (self-declared) experts only. Separation of empty directories / zero-byte files not problematic anymore, except for NTFS-source (switch /e for 'always seen as directory' needed on NTFS only). Improved error-detection on the FATCOPY.G4B command-line. Improved verify-function with crc32 instead of file-size. Right detection of file-size if copying 2GB-4GB files (with cat --length=0 FILE, %@retval% is limited to 0x7FFFFFFF). After detecting the right free space ('fat' is buggy on FAT32-partitions above 4GB), 'fatmini' is used as workaround (mandatory as soon a FAT32-target > 4GB is detected). All file-investigating functions now 'raw' (for right handling of LNK-files - thanks to Jaclaz). Earlier added visibility of omitted directories/files will be undone if using a '*'-wildcard (with '*.*' too). Less error statistics to reduce number of variables (number of errors during making directories maintained). Reduced statistics after finishing copying a directory (in case of switch /s). New features: Copy from EXT2/3/4 added, my earlier problems seems to be related to the Windows EXT2-driver, with real EXT2/3/4-partitions there are no problems anymore. The ‘lost+found’ directory is only seen/copied with the switch /l+f. Copy from EXFAT, ReIsErFs and ReIsEr2Fs added (ReIsErFs untested). Copy from UDF ('ls' directory-parsing seems to be limited to Mode 1 UDF 2.01). Copying-mode switches to 'case-sensitive' if a case-sensitive File System is detected. Can be undone with switch /nocase (target is FAT only, so not case-sensitive. 8+3 file-names identical except for case, can not both be copied without renaming before). Separate copy engine using (raw) 'dd' for files that can't be copied by 'fat' ('fat mkfile' is still needed to make empty target-files with same size). Copy files with File Number Suffix, like Joliet. One file-number only [not]copied possible with switch /filenum:[-]number (1-32767). Incremental copying, uses crc32. Overwriting without notice if source-file has been changed (switch /i). Ignore chosen extensions during copying with switch /noext:ext (number limited - in theory - by size of one variable, so about 125 extensions, including semicolon-separator). Copying of Long File Names (LFN) to their Short File Name (SFN) counterpart (switch /lfn). SFN is NOT red from source File System, but generated according to Microsoft MS-DOS/Win9x specification. Highest number shown AFTER tilde in case of files with identical SFN's: 65535 in one directory (no generation of NTFS-method of numbering). Char '!' and space added to the list of forbidden characters. Wildcard '*' can be used AFTER max 16 chars of the name-part and AFTER max 6 chars of the extension-part of a LFN. Source-length supported: 511 chars (target still 255 chars). Saving of LFN's if switch /lfn:@ is used. Original LFN of 'SFN~num.ext' is saved as text to 'SFN@num.ext' in case of files and to 'SFN#num.ext' in case of directories (maximum 255 chars, maximum 32767 'SFN~num.ext'-files and files containing a LFN both, in one directory). Overwritten if LFN on source is changed and if no new 'SFN~num.ext' is made (source- and target-LFN are shown before dialog). Automatic generation of new 'SFN~num.ext' if needed, with switch /i. Existing 'SFN@num.ext' and 'SFN#num.ext' auto-saved if the corresponding 'SFN~num.ext'-file is copied, or 'SFN~num.ext'-directory is made (function can be undone with /x:@ in case of files, or with /x:-@ altogether). Includes statistics related to number of 'saved' LFN's, after finish copying. On the FATCOPY.G4B command-line both source and target accepts LFN's, if containing spaces or '=' always between "double quotes" (first one also possible before DEVICE). Quote-handling uses 'write' to overcome problems if an odd number of quotes remains after parsing of the command-line (thanks to Jaclaz!). Escaped 'ls'-spaces ('\ ') not shown in output during copying ('write' unexpected removes the escape-char when writing a variable with '\ ' and leaves the space). Fully compatible to copying from a root containing spaces, earlier set with 'ls'-spaces (no quotes if using Grub4Dos directly!), and source or target starts with '/' - representing the actual root ('ls' can't!). Full path to FATCOPY.G4B must be given, or set before. With switch /lfn compatible to at least Mode 1 Joliet level 1/level X and ISO9660 level 2/level X. Some highlights To make this post not too long, only a few print-screens of the capabilities of FATCOPY.G4B v0.3 will be given. Command-line is showed at the bottom, if applicable (‘pager on’ doesn’t show commands). First print-screen shows the verify-switch in action during copying my original Windows 98 SE CD. ‘Verify’ tries three times before giving up (the showed first two files where the only one not copied, third file was copied). Only needed on very slow or ‘bad’ media. Second print-screen shows copying of an ISO9660-Joliet DVD, semicolon and File Suffix Number are simply cut-off before ‘dd’ is used to copy them. Only on a FAT-source ‘fat’ will read-out the corresponding SFN, but ‘ls’ can’t. Besides: now same result as MS-DOS for SFN’s. LFN's can be copied too with switch /lfn[:@] (no switches used here). Third print-screen shows the switch /lfn in action. But if the first six chars of SFN are equal, this is more or less a blind process, although the dialog gives four options. Fourth and fifth print-screen shows the ‘:@’-addition to the switch /lfn in action, and give my solution to the so called ‘Micros~1/Micros~2’ problem, and with switch /i fully automatic. Incremental copying if a new source file exists can be seen on print-screen five. Sixth print-screen shows preservation of earlier saved LFN’s if tilded’ SFN’s are copied. Seventh print-screen shows the last output-lines after copying a full drive with use of /lfn:@ and /noext:ext to exclude some file-types (in this case together at least 1,2GB). The final result is showed in print-screen eight. Copying is still maximum 21-23 directories deep, but this limit seems (partly?) dependent too on length of names involved (the error that will come up with next directory-level is: ‘FAULT: <<<<<<<<<<SYSTETM STATCK RUNOUT>>>>>>>>>’ and is generated by GRUB.EXE, not by FAT). Last print-screen shows inspection with (still forthcoming) FATLSDIR.G4B after copying LFN’s with originally 255 chars, and same error with depth of 2+21 directories. Remaining problems Read-only files on the target will not be overwritten or deleted by ‘fat’ (by ‘fatmini’ neither). ‘fat’ directory-parsing allows not-copying files with certain attributes, but ‘ls’ directory-parsing can’t. Since there seems to be no such a program like ATTRIB.EXE for Grub4Dos, in this case the overwrite-dialog has to be used for each file to be sure. Luckily most read-only files resides on the root of a FAT partition. So after processing the root, the overwrite dialog gives each time the options ‘A’ (overwrite all) and ‘S’ (overwrite never) too, and one can be chosen if desired. Download FATCOPY3.ZIP The zip contains a SFV-file with the crc32-value of FATCOPY.G4B too. FATCOPY3.ZIP

I did some more tests in Real mode. First I tried 4DOS as command-interpreter, but 4DOS gave with a much lower number of files in a directory already an 'out of memory' error. Second I used a Freedos bootdisk in VBOX 6. Freedos had no problems with more than 32 767 files in a directory (see print-screen). So at least I can check my test-outcomes in Real mode inside VBOX 6.

Thanks a lot, nice info. I did a large Google-search on '0x7FFF' and 'MS-DOS', but no results. I also checked MS-DOS 7.1 in Real mode on another machine, same limit of DIR: 32 767 files. But Windows 98SE seems not to be affected, both Explorer and DIR in a MS-DOS Windows gave the right number of files (in the meantime 40 000 ). See the print-screens. But on the other hand: Total Commander (v 9.22a) complained there where 'too many files' after opening the directory above, and showed afterwards 32 699 files only.