deomsh

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 co

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

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.

While (still) testing FATCOPY.G4B version 3, I found a strange result after copying 36 000 files to a directory (testing in VBOX 6). FATCOPY counted the right number of files / copy-size. After I mounted the VHD Windows reported happily the same result (and even the type of files I used, not the filename and the method of numbering of course!). See first print-screen: MS-DOS saw only 32 767 files with DIR /W, in the same directory (see second print-screen): To be sure it was not related to the /W-switch, I checked the source directory I used without /W (see third pri

Hmm. SMARTDRV.EXE cannot speed up write operations ´as such´ for unique files like a download, so a slowdown is possible because of the ´overhead´ Smartdrive needs. In my experience ´best´ is to disable writing from the cache of Smartdrive with the /X-switch, and speed up reading operations with maximum Read-ahead buffer. In Windows 3.1 MS-Smartdrive documentation I found that the max Read-ahead buffer is 57344 bytes, works with later versions too. Also: if SMARTDRV.EXE is loaded high, the Read-ahead buffer should be in conventional memory, same for BUFFERS in CONFIG.SYS. This b

Thanks for all your ideas. I worked on the problem. As far as I can see, I can maintain my beloved /-switches with a few modifications and a sub-routine to split up %@root% in DEVICE and /PATH. I believe the only file-representations that are NOT possible anymore are filenames same as switches AND on the root, represented by '/'. But without preceding '/' there seems to be no problems. See the first print-screen. Even file-names starting with '-' are possible (unless '+', '-' is not a forbidden character in MS-DOS). Also my problems with '/s' are solved, The output o

Thanks for the information, so that will not be an option for me. There is no internal reference to the filename, so the user can do what he or she wants, regarding renaming. The FATLSDIR.G4B HELP gives following suggestion: ´More convenient => insmod (bd)/fatutils/fatlsdir.g4b dir´ (say FATLSDIR.G4B is in that directory). So you prefer an output like DIR /B in MS-DOS (Dutch version)? For now I added the /b-switch (both print-screens below). First print-screen shows the output of the FAT-based directory-parser, second one the LS-based on a NTFS-volume. Total size

Thanks! FATLSDIR.G4B is not finished, but the appearance is important, especially for a DIR-program. I made some changes in between. Better, or would you prefer the MS-DOS DIR-format? BTW: the FAT-based directory-parser gives date and time of files, so that's (relatively) easy. I managed to add filesize if the LS-directory parser is in use, ment for LFN and for other file-systems. Is it possible to get date and time of those files too?

Sorry for the delay, but during testing smaller differences I got inconsistent results. If one test-time is ±1 second, differences can be ±2 seconds, so ranges overlap easily (apart from load-time variations). I don´t like the ever longer time needed to do tests, so I made a new version of LOOPTEST.G4B. This took much more time than I expected, but nevertheless: I had a great time. I managed to get a relatively stable time base and some semi-floating point operations to produce decimals. The stability depends upon the (virtual) hardware used. Although I owe LimboX86 much for dev