deomsh

Try adding to SYSTEM.INI [386enh] MinTimeSlice=100 (on my system 100 is max. Default=20, you can also increase in steps of 10). Reboot required!

Thanks for the explanation, i will contact Steve. In the meantime I tested GOTOERR.G4B on four machines, no differences (two real chipsets and the two VBOX-chipsets). Also the Grub4Dos-version just before 20160315 has the "old" behavior. For the time being an easy solution is to insert an errorcheck off line if needed. On the sunny side: FATCOPY.G4B is (almost?) "errorcheck-on-proof", and I have had unlimited opportunities to find out tricks to live with this problem.

I tested call/goto :eof with following batch-file ------------------------------------------------ GOTOERR.G4B ------------------------------------------------ !BAT # Testing errorcheck status with call&goto :eof debug 1 errorcheck off errorcheck status call :checkerr errorcheck status errorcheck off errorcheck status goto :end #---------------------------- # Sub-routine checkerr #---------------------------- :checkerr errorcheck status goto :eof #---------------------------- # End of sub-routine checkerr #---------------------------- :end errorcheck status ------------------------------------------------ Same results, after each goto-statement errorcheck is switched on (with version grub4dos-0.4.6a-2020-01-12 too) But it could to be related to issue #102: https://github.com/chenall/grub4dos/issues/102 With a Grub4Dos version before this issue was raised, GOTOERR.G4B gives this result: And after the issue (something is mentioned in the bug file of following version): The bug *thing* I found is here, but I can't interpret it: https://github.com/chenall/grub4dos/commit/b90a412f5fb78aa23d12c3fb9b0eb74c4751fbfb Also I am not sure if it is directly related to issue #102.

About errorcheck, I found something strange. It seems that during the run-time of a g4b-batchfile, errorcheck is switched on after a goto-statement. I made a small test-batch: --------------------------------------------------------- TESTERR.G4B --------------------------------------------------------- !BAT # Testing errorcheck status while running a g4b-batchfile debug 1 errorcheck off errorcheck status goto :end :end errorcheck status --------------------------------------------------------- The result: see the picture. Is this normal behaviour? I am using Grub4Dos v0.4.6a 2019-09-09.

I saw the EXT3 byte, but the link was still helpfull because I realized I had to search for a hex value to indentify EXT2 or EXT3 (or EXT4), than I found the signature very fast with google. Thanks for remembering. In my batch-file errorckeck IS off, but during my endless testing on the command-line I didn't take notice of the errorcheck status. Since FATCOPY.G4B restores the original status of debug, errorcheck and pager I had to count for that. Stupid but true. The links are interesting. I am afraid I will have test again all supported filesytems separate, especially the different FAT-types.

@Wunderbar98 & @jaclaz Thanks for contributing to my EXT2/3 question. My problem was far more simple, but I didn't make myself clear. I ment the EXT2/3 signature only. I found 0xEF53 in sector 3, in an article somewhere. It seems to also the main signature for EXT4, which is supported by Grub4Dos 0.4.6a (according to rmprepusb) So I added finding this signature (\x53\xEF) in the source DEVICE to FATCOPY.G4B and everything is fine now. I found the EXFAT signature too, but still have to test this filesystem. Not the empty directories are bothering me, but to distinguish them from zero-byte files. Else ALL zero-byte files will become directories on the target. That's why I ruled them out, unless the /e switch is used. If I use ls on an empty directory, ls highlights the empty directory "emptydir", but gives Error 15 if I try to open the directory. With cat --length=0 Error 2 in case of "emptydir" and, IF debug is on Filesize 0x0 is read out for "zerobyte.fil". Somehow I couldn't get rid of Error 2 (or Error 15 too with cat --length (fd0)/zerobyt/emptydir/ ), which was a big problem because copying is interrupted by a Grub4Dos error. My problem was I couldn't sent Grub4Dos error messages to NUL. But today I found a way to identify a zero-byte file independent of an empty directory. Piping NOT redirecting to nul did the trick, finds filesize only if debug is on. Now I can drop all special "empty directory"-lines in my batch file. A small preview of (forthcoming) version 0.3 (I added a small file because an empty source directory is refused by FATCOPY.G4Bwas just a typo, "zerobyt" instead of "zerobyte").

@jaclaz About EXT2: today I did some more tests, there are two different issues. First issue: Grub4Dos ls doesn't highlight directories in case of EXT2. Because opening a directory on EXT2 with ls and copying from that directory didn't work for me, I thought ls was the culprit. But the problem lies elsewhere. Today I vaguely remembered EXT2 is fully case-sensitive, while FAT and NTFS are in fact not. In the picture below I illustrated this with a NTFS (hd2,0) and an EXT2 (hd3,0) partition. Line 1-3: root of (hd2,0) with ls, copying from NTFS with FAT is case-insensitive. Line 7-8: root of (hd3,0) with ls, copying from EXT2 with FAT is case-sensitive. Same for viewing a directory, NTFS in line 13-14 and EXT2: lines 16-22 With a few changes FATCOPY.G4B can be adjusted to EXT2, as long source path/file are written in the right case. One of my changes in version 0.2: "Added visibility of omitted directories during file-only copying (without /s), especially to improve the DIR capabilities of Copy trial mode" will identify directories on EXT2 too (but not if they are empty!). Great news for the Linux community See picture below of copying with version 0.2 but with adjustments for EXT2 (line 8, second "omit"). Although I find a way to identify empty directories on the target (always FAT), on the source this still doesn't seem to be possible with help of ls (my FAT directory-parser has no problems in this respect, but can only be used on FAT volumes. Redirecting the ls error message never worked for me. Any idea's? About NTFS and the average (Grub4Dos-as-an-OS) user... Good point, I will try to add some silent skip's and adding a /$-switch for the non-average user. A question about EXT: is there an easy-going way to identify EXT2/3? Is there something specific in a sector anywhere? I can't find anything, not on the internet and not with CAT. But I have never been a serious Linux user.

FATCOPY.G4B 0.2 I wondered since FAT could copy from ISO-9660/UDF, if NTFS would be possible too. Experiments in this direction gave no problems, so i added NTFS to the list of admissible filesystems (source device only!). See picture below. Just out of curiosity I tried EXT2. Although copying with FAT is possible, the LS directory-parser doesn't open directories, so I left EXT2 out. See picture below. I made FATCOPY.G4B version 0.2 - with following changes: Copy from NTFS (with auto-switching to LS directory-parser (switch /ls can be left out) Added filesize copied in the output message after copying a single file FAT error handling in case of making (sub)directories too (will end copying!) More understandable error message if the (sub)directory to make already exists as a filename Three bugs fixed Better alignment of messages Added visibility of omitted directories during file-only copying (without /s), especially to improve the DIR capabilities of Copy trial mode. See picture below. As the picture above shows, the NTFS meta-files and the $MFT will be copied too (if >= 1 byte). If not wanted: files containing $ can easily omitted with the /x-switch: /x:-$ In case of directories I didn't made such a switch. I saw no use, but I will think about it. I don't know how big the NTFS directory $Extend can grow. FATCOPY2.ZIP

FATUTILS I: FATCOPY.G4B This tool is an extension of Grubutil FAT. My Grub4Dos batch-file is based on CopyFF.BAT. The originator of the file seems to be Chenall (18 Februari 2012 - 01:52 AM): http://reboot.pro/topic/16288-question-mount-a-folder-as-a-drive-in-ram/page-2 . Further I have used the Command Primer, the Tutorials 71, 21 and 65 on rmprepusb and the e-book of Steve6375 "Getting started with Grub4Dos." I took special attention to verification, apart from typo's in the switches, especially existence and filesystem of Source and Target Devices are checked. I restored the Error messages of FAT; I found no other way to check if he Target Device has not enough free space. I will paste the HELP-part to give an idea of the possibilities of FATCOPY.G4B. The file is far too big, the download is at the end below. ------------------------------------------------------------------------------- grub>FATCOPY.G4B HELP ------------------------------------------------------------------------------- fatcopy.g4b DEVICE1/PATH1/FILE1 DEVICE2/PATH2/FILE2 switches fatcopy.g4b HELP (this screen) Copy files on DEVICE1 to DEVICE2; if omitted DEVICE1/DEVICE2: from root Copy from/to hidden FAT-partitions ! File-names 8+3 only! 0-byte files are not copied. LFN copied as SFN (default) Arguments space-separated! Lower/Uppercase free - except DEVICE1 and/or DEVICE2 More convenient => insmod (bd)/fatutils/fatcopy.g4b copy (source) DEVICE1 = (fd#) & (hd#,#) & (0x#) & (#); with ISO/UDF (CD/DVD too!) (target) DEVICE2 = (fd#) & (hd#,#) & (0x#) & (#); FAT only /PATH1/ = source directory => without DEVICE1 => on root (PATH1/ too) /PATH2/ = target directory => without DEVICE2 => on root (PATH2/ too) if PATH2 does not exist, all PATH2 directories will be created FILE1 = copy specified file => on root without DEVICE1 and/or /PATH1/ FILE1 accepts wildcard: * in Name / Extension (NOT: ? ) Without FILE1 full directory will be copied (*.* is NOT needed) FILE2 = copy/rename FILE1 to FILE2 => on root without DEVICE2 and/or /PATH2/ File versions: Grubutil FAT 15/02/2015 and Grub4Dos 0.4.6a 09/09/2019 Found not compatible with Grub4Dos 0.4.5b / Grub4Dos 0.4.5c Grubutil FAT needed, searched in (bd) or ()/ (=root) or /grub/ or /grubutil/ General Switches: [/d] [/[-]o] [/p] [/q] [/v] [/t] [/x:[-]~] [/w:n] /d = set PATH2 == PATH1 /[-]o = [never]overwrite files BTW: [-] means choice, type /-o ! /p = pause after each screen /q = quiet copying: error messages & last file-count message only* /v = verify with message of status - not with /t (try /v if copying stops) /t = trial without actual copying (can used as simple DIR) /x:[-]~ = only SFN-equivalent of LFN/real shortened LFN will [not] be copied** /w:n = waiting time making directory: n=0 - n=t seconds (default = auto) * default verbose copying: mkdir & copy & output messages too ** instead of ~ ONE other character can be used too (special feature) FAT Directory Parser Switches: [[/s] [/a:[-]darsh] [/m:x]] * /s = copy subdirectories (LFN to SFN) too. With /a:d directory-tree only /a:[-]d[-]a[-]r[-]s[-]h = [not] copy files/directories with attribute(s)** /m:x = changes (md)-startsector in use (default=min x=3000 uses 0x3000-0x3FFF) * default - no copying of ISO-9660 & UDF! If found will auto-switch to /ls-mode * about max 35 000 files AND max 3 000 subdirectories in one directory ** attributes are not copied by FAT - all copied files get archive-attribute LS Directory Parser Switches: [[/ls] [/s] [/e]] * /ls = ls-based directory parsing - can copy from ISO-9660 (NOT Joliet) & UDF /s = copy subdirectories (try /x:| to make directory-tree) /e = copy empty subdirectories (zero-byte file will become subdirectory!) * shows skipped 'dirty' LFN (NO copying of LFN as shortened SFN) * about max 10 000 files OR max 10 000 subdirectories in one directory ------------------------------------------------------------------------------- FATCOPY.G4B.ZIP

There no Windows 98 driver. HDA2.DLL, the driver mentioned in this thread is a Windows 3x driver. Use in Windows 98 is experimental. HDAICOUT.HDA is a file used by HDA2.DLL to give certain presets to the High Definition Audio Codec.

This is really great! Works perfectly with a 2880KB floppy image in Virtual Box 6.018. Thanks a lot! Only drawback: editing a g4b-file is more addictive now than using EDIT.COM on a (slow) USB-pendrive. A few month ago I tested Grub4dos with VBox, chainloader /io.sys didn't work. This time no problems, whatsoever.

It was more ment as a warning. The creator of copyFF.bat is absolutely a genius. I did some more tests, using my old MSYS USB1.1 16MB pendrive. It appears that fat mkfs and fat mkfile are not fully-fully safe. But 'a picture paints a thousand words', so here they are: http://imgur.com/a/5cZHjdG

I was mistaken, copyFF.bat is parsed too. But it's VERY dangerous, I run the file accidently without arguments and found the FAT of my (USB-)rootdrive rewritten, probably by the fat mkfs line in copyFF.bat Luckily I made a full backup just before testing copyFF.g4b. Better add some sort of validation.

Thanks for the links, command --set-ext=.g4b in MENU.LST just before commandline saves time during testing (in my case the "4" easily becomes a "r"). In the post from 18 October 2013 - 01:27 PM you asked for an EDIT tool in Grub4Dos. Exists such a tool? Would be great, testing / correcting a longer Grub4Dos batch-file is very time consuming without.

Yes, I have red the comments. Sadly enough I didn't solve the issues. Reason: there are no issues (except not copying LFN), at least not with grub4dos-0.4.6a-2019-09-09. Only thing I changed: renaming copyFF.bat to copyFF.g4b to make batch file working. I used following commands: (fd1) because of my real floppy drive (fd0); and only enough space on (hd0,5) for the iso: From Grub4Dos Command-line: grub> --------------------------------- map (hd0,5)/WXPhome.ISO (0xff) map --hook copyff.g4b (fd1) 0x1A0000 /I386 map --floppies=2 root (fd1) --------------------------------- To be sure: this is the content of my copyFF.g4b ---------------------------------------------------------------------------------------- copyFF.g4b ---------------------------------------------------------------------------------------- !BAT # Usage call (bd)/copyff.bat (fd0) 0x1A0000 /I386 # 1st param - e.g. (fd0) or (fd1) = virtual drive to create in memory must be fd0 or fd1 # 2nd param - e.g. 0x1A0000 - size of virtual drive # 3rd param (optiona) - e.g. /I386 - subfolder to start copy from debug off errorcheck off # initialise filecounter # write 0x60000 0 # stop 'hit Q to continue' messages pager off #512MB = 0x100000 #850MB = 0x1A0000 #1GB = 0x200000 set FD=%1 map --mem (md)0x300+%2 %FD% map --hook insmod (bd)/fat debug on clear echo Copy (0xff) contents to virtual drive %1 (size=%2), starting at %3... fat mkfs %FD% if NOT "%3"=="" fat mkdir %FD%%%3 debug -1 pause --wait=3 debug off root (0xff) set cd=%3 call :cpa echo Finished! goto :eof :cpa clear echo Copying files in folder: %cd% ::Change source root root (0xff)%cd%/ ls | call :copyfiles echo Finished folder %cd% goto :eof :copyfiles if "%1"=="" goto :eof ::If is a directory cat --length=0 /%1 || goto :sub-dir ::copy file echo %cd%/%1 fat copy /%1 %FD%%%cd%/ > nul || echo Error: %cd%/%1 # Filecount printed # debug on # calc *0x60000++ # debug off shift goto :copyfiles :sub-dir setlocal fat mkdir %FD%%%cd%/%1 set cd=%cd%/%1 call :cpa endlocal shift goto :copyfiles ---------------------------------------------------------------------------------------- Here are the results (pictures taken by daylight AND my first IMGUR experience EVER). Still only 20KB left on my msfn account......... https://imgur.com/gallery/g8Awwwf Enjoy!

I discovered problems while copying from a Grub4Dos command-line to rd2hdf16.g4b/rd2hdf32.g4b based memdrives , map --rd-base is still not high enough. I am working on a copy-tool using Grubutil fat to copy to FAT-devices. My copy-part is based on COPYFF.BAT I found on https://www.rmprepusb.com/tutorials/grubutils - I hope that's not a problem. First I tested on USB drives only, which gave no real problems. Lately i started testing copying to Grub4Dos (rd) to (hd) mapped devices. It appeared that even 42MB wasn't 'good'. Copying stopped at about 400 files and fat dir gave out of memory errors afterwards. On https://www.rmprepusb.com/tutorials/grub4dos/grub4dos-internal-variables-and-functions I found, (md)-related, using above 50MB the Grub4Dos memory area 'to be ultra safe!'. Also wenv/insmod is mentioned loading files above the 32MB memory area. With map --rd-base set to 50MB all copy problems while using Grub4Dos, where gone. Even copying a directory containing 5,000 files. Updates of both files: in the posts of February, 27 and March, 11

Thanks for the report. Interesting, especcially in case of rom-dos 7.1. It's sad that there is no free evaluation version, in the past there should have been one. I will take look in my archives. About size-differences: MS-Smartdrive can become really big too, depending on cache-size and size of Read-Ahead Buffer. See for documentation the start of this thread. I have tested R. Loew's second patch on 240GB logical partitions, on two different 500GB Sata Hard disk's, with mixed results. Write-behind caching was always a no-go, as expected. With SMARTDRV /X I had on one disk same results you already mentioned. But to the other disk I could copy 60GB in MS-DOS without problems (the partition had about 125GB files before I started copying). Only with minimum Read-Ahead buffer of 16KB (to me /B:32768 or higher makes more sense because of the 32KB cluster-size - but not sure about that). A side-note about SCANDISK.EXE (not SCANDSKW.EXE in Windows!). Can run out of memory, if errors are found on big partitions. I cured this by using SCANDISK /custom and set SCANDISK.INI to make no log file. Also it's good to set "delete lost clusters", because of available filenames for CHK-files.

Thanks for testing Which version of SMARTDRV.EXE did you use?

I asked for a link and a legal way to get access to this file. I spend in between two ours reading about Vista beta versions, but I found no way to get this file. I have never been a beta tester, and all (pre-)Vista betas will be not accessible to me. But I have Windows XP/7/10, is there a 'similar' version I can test?

Good question, in the TBPLUS-package there are two SMARTDRV.EXE versions, (30-04-10 and 11-06-18). They are both different from the MS-2000 version. I will test soon!

'Officially' partitions > 128GiB are not supported by Smartdrive. Did you try the /X switch? This is the Read-caching mode, so no Write-caching. It would be of interest to try loading SMARTDRV /X /B:57344 and than giving DIR /S

A fresh installation is always good for testing purposes, and I believe: best vanilla as possible. Did you use any unofficial service packs?

Nice, you're lucky with such a board. But doesn't seem SATA to me, in Windows drives will NOT run in MS-DOS Compatibility Mode. I took a look to the 815T chipset, P-III isn't it? I found boards that has ICH2-Southbridge with a 100MB burst mode. I doubt BIOS-hacks are possible (and as far as I know MSFN wouldn't like that on their forum). In this thread I used copy speeds in MS-DOS as a sort of benchmark to compare with Windows' MS-DOS Compatibility Mode. I am not aware of good speed-testers in MS-DOS. In all my tests I copied the same 496MB file between two hard disks and recorded the time with my sons stopwatch.

I am more than happy to attempt this despite the great danger you mentioned So, I am modifying the Kstub822 file to include these stubs Although I can not test on WinME, messing around with stubs shouldn't be needed in case of MPC-HC 1.7.5 and with SHLWAPI.DLL from IE5.5 or higher. The unresolved dependencies I showed you are harmless in my case. Please delete stubs in core.ini and try again. The right registration of Jumper's UXTHEME.DLL is more important, together with the right way to substitute MSVCRT.DLL

I was trying to help a member with problems regarding MPC-HC 1.7.5, which took several ours to revitalize old installations. I can't test in between other MSVCRT.DLL substitutes or discuss them from schratch. If you ask for help I am willing to test, but I need LEGAL access to the file-version mentioned. BTW I don't possess Vista.