deomsh

@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.

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 print-screen): I can't find anything about this number in combination with DIR. Is this a known limitation of DIR in MS-DOS 7.1, or otherwise? BTW: SCANDISK.EXE found no errors on both (FAT32)-drives after copying, so FAT did a nice job. Thank you Chenall.

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 because UMB´s can notable slowdown read/write operations. So DOS=HIGH,UMB,NOAUTO is also needed (if a Upper Memory-manager is installed, of cause). Further it´s a good idea to experiment with number of buffers and with all combinations of double buffering (for details see my thread ´SMARTDRIVE Revisited´ on MSFN). It would be interesting if there is still such a notable difference in download speed with following entrances in CONFIG.SYS: DOS=HIGH,UMB,NOAUTO BUFFERS=10 INSTALLHIGH [station:][path]SMARTDRV.EXE /X /L /V /B:57344 Smartdrive can loaded in AUTOEXEC.BAT instead, with LH [drive:][path]SMARTDRV.EXE /X /L /V /B:57344 At the moment I have no time for experimenting.

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 of the '/s /b'-switches combination of DIR in MS-DOS surprised me (can't remember I've used it before), so I added this combination to FATLSDIR.G4B. Even empty directories are shown in the short DIR-way, (fd0)/FATLSDIR/SUBDIR1 is the example. See second print-screen. If DEVICE is used too, everything is as before. See last print-screen. Watch the sort order: directories first in both cases, empty directories are given one time only with '/s /b'.

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 / files are removed too. I will think about it, at least there is the /b-switch now (´/B´ can be used too, all switches are case-insensitive). BTW: The /s-switch is already in use, same output like DIR /s. I added the ´/s /q´-output to both print-screens as an illustration of the output of a whole drive without showing directories or files (sadly the first ´/´ is still needed to represent the root, without I ran into trouble if switches are in use). Directory-output directly above the files can be removed too, but I will have to think a while about the consequences for rewriting my batch if /s is in use in conjunction with /b. The /ls-switch is only explicitly needed to show full LFN´s on a FAT volume. On all other supported file-systems there is auto-switching to LS-mode (last print-screen above). I haven´t decided yet if its better to show this message in standard-mode, or hide it and add a switch.

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 development-time on my Android smartphone, the time-base is very unstable, even in the ´whole second´ range. VBox 6 is better, but still unstable. Which is sad because of the productivity with ImDisk and the nice print-screens VBox is able to produce. I got my best results on a ASUS H61E board with Intel i3 (3,3 GHz) and DDR3 1333 memory (and I had to go back to GRAB.G4B. ). BTW: all new test are done on the H61E-board, Grub4Dos is started from real-mode MS-DOS 7.1. So results can not be compared with the earlier tests in Vbox 6 (running under Windows 10 with AMD Bulldozer / DDR3 1666)! This time I want to show my tests about the influence of insmod first, other comparisons will be done later. It´s also a very short introduction to the possibilities of the new version of LOOPTEST.G4B. The command-line of LOOPTEST.G4B has been changed a bit, to give room for arguments of a test G4B-file, besides other changes. I compared MIDWAY.G4B and the cleaned version (three lines where not needed) with Short File Name MIDWAY#3.G4B. First I tested all files on a SATA flash drive, this is (hd0,0) on the first two print-screens. To compensate for internal delays in LOOPTEST.G4B I made a BIAS-variable. Further is variable 'myvar' set outside LOOPTEST.G4B (universal solution, names of input and output variable can be set on the command-line of LOOPTEST.G4B, and echoing can be done once, before and after the loops). The results without and with insmod are different, the variations in load-time seems to be bigger than the runtime-differences. On the next print-screen the same test on my slowest device, a very old 16MB M-SYS USB1.1 flash drive (my first one!). Same results as with the SATA flash drive, but the insmod-tests seems to be very stable in the range of ±1 millisecond in both tests. To minimize load-time instability, I did the same test on a Grub4Dos memdrive. The first two print-screens show the making of the memdrive. They are also a preview of my (forthcoming) utilities FATDEL.G4B and FATLSDIR.G4B. FATCOPY.G4B is showed with use of wildcard ´*´. FAT cannot delete read-only files, so they will remain (until someone make a Grub4Dos ´attrib´-utility). The last two print-screens show tests with number of digits set to three (by setting needed number decimals - rounding down). First test-cycle with 1000 tests does use ALMOST the same BIAS as earlier (the BIAS set during this test is slightly different; influenced by instabilities in the time-base and in the possibilities to divide the whole seconds. Without and with the use of insmod all differences are in the range of 42-43 milliseconds. I expanded the test to 10000, 100000 and 1000000 loops, always three digits only (last print-screen). Without and with the use of insmod all differences are still in the range of 42-43 units, applicable to the different tests (0.01, 0.1 and 1 second respectively). All in all, it seems to me that testing with insmod will give the ´right´, and the most stable differences. So next tests will be only with insmod, also to become independent of the device in use.

Sleeping widget is ONE widget that will be powered up if set in HDACFG.INI. Normally the DAC. So according to the datasheet I found: widget $03. Volume widget is the widget with Master OUTPUT volume. Can be the DAC, a mixer or a PIN-widget. The AD1981HD has no Master volume on the DAC, nor on Mixer 0E, as far I can judge. Each PIN-complex seems to have its own Master volume (named 'GAM' in the Functional Block Diagram and named 'LO' in Table 17). So there ar four possibilities: 1) Mono-out = widget $07 2) HP-out = widget $06 3) Line-out = widget $05 4) Rear-mic = widget $18 (if set to Output). Output widget is always a DAC (ment is output from digital HD-audio link to a DAC). So in your case widget $03. Further: Mixer 0E doesn't seem neccesary to me, unless you want to mix analog inputs to your analog output (Line-in, Mic or CD). All right, I've tried that version in the past. Maybe you can be so kind to upload your VDMSound config-file? Will be of interest for me.

Congratulations. When I started with HDA.DLL I had to make my own journey. Don't understand, you mean your laptop volume buttons? Great! Once I tried VDMSound with HDA.DLL to play Prince of Persia in a MS-DOS window. Only sounds where working for me, but not midi. How did you managed the midi part? 1. I don't think the controller is involved, must be somewhere in the source code of HDA2.DLL. It's included, so you can take a look. Although I possess Delphi 2, I never came further than compiling HDA2.DLL 2. Can't help you with Judas. I vaguely remember posts on Dos forums with the same wish (Vogons?), but it seemed to be impossible unless Judas is rewritten to a driver (or TSR?). But I'm afraid such a journey will take many years.

8 bits = 1 byte (old, not S.I. !). Verbs use hexadecimal values for addressing and for payload of the commands (values of set/get commands are given by Intel's High Definition Audio Specification ) In a verb "41" means: 4 * 16^1 + 1 = 65. But datasheets use bit-values. 4 lower bits [27-24] calculated as such: 0001 = 0 * 2^3 + 0 * 2^2 + 0 * 2^1 + 1 * 2^0 = 1 4 higher bits [31-28] calculated as such: 0100 = 0 * 2^3 + 1 * 2^2 + 0 * 2^1 + 0 * 2^0 = 4 Lower and higher bits together gives "41" in hex. The reverse is also easygoing, but not needed if the datasheet is available. 4 bits: highest number = 15 = F in hex, so 8 bits gives hexadecimal numbers from 00 up to FF (0-255 decimal), but counting to fifteen is all what's needed (most at the time).

Still AGP4x? I remembered Dxdiag has an AGP-button.

Nice, also the now needed correction of variable seekbyt with variable ocount. Hmm. If I was a programmer (which I am not), I would say that MIDWAY.G4B call´s the cat-subroutine in GRUB4DOS (if fully optimized) the number of qoutes - 1 less, compared to WDDQUOTE.G4B. But let´s test (screen-writing and the set myvar-line commented out in all batches except LOOPTEST.G4B): Because of the ±1 digit resolution, I raised the number of tests to 500.000 to get a measurable difference: Your ´midway´ seems to be slower than needed: I thought you would have had this in mind? !BAT setlocal set /A mdmem=0x3000 > nul set myvar="something" with space and two spaces aND "" quotes" set myvarnq= set myoffsets= echo -n > (md)%mdmem%+1 write (md)%mdmem%+1 %myvar%\0 > nul cat --locate=\x22 (md)%mdmem%+1 | set myoffsets= #cat --locate=\x22 --replace=\x00 (md)%mdmem%+1 #cat (md)%mdmem%+1 | set myvarnq=%myvarnq% set /a ocount=0 > nul if not ""=="%myoffsets%" call :noquotes2 %myoffsets% set myvar goto :eof :noquotes2 set seekbyt=%1 > nul if not exist seekbyt && cat (md)%mdmem%+1 | set myvarnq= && goto :eof set /A seekbyt=0x%seekbyt%-%ocount% > nul set /A "skipbyt=%seekbyt%+1" > nul dd if=(md)%mdmem%+1 of=(md)%mdmem%+1 bs=1 skip=%skipbyt% seek=%seekbyt% > nul shift set /a ocount=%ocount%+1 > nul goto :noquotes2 Gives following results: Seems to be faster than, or as fast as your earlier tokenize-approach (±1 digit). What´s your ´conclusion´ about speed of cat vs dd?

HELP while posting you already came with something new. To be continued.

Sounds logical, here are the tests. To raise the number of qoutes I invented a user who wants to be sure: every word, and every space between quotes. I changed myvar a bit, so the second double-qoute character is after the 16th position. Indeed, difference has become huge. With a high number of qoutes my dd-approach is much slower then your tokenize-approach. But sometimes weakness is strength: the number of characters to cut-out is virtual unlimited with the dd-approach. Print-screen's this time in reverse order. Watch the last word in myvar and myvarnq: The tokenize-approach seems to have a limit I first didn't understand, until I saw the memory-addresses (somehow I counted with two hex digits memory - but that's max 255 of cause) + one space - : In a real filesystem this number of qoutes will of cause (almost) never exist, but there may be other uses. Yep, same reason why I am using insmod. In the mean time I counted the difference between two tests of quote-removing approaches, without or with insmod is approximately the same number of seconds (always ±1 second, because of the use of %@time% ! See print-screen´s in my post of last Monday 11:43).

I do not understand why my dd-approach should loop more times than number of quotes in the variable. Each quote needs one :noquotes-loop (unless you mean inside the dd-command because I set bs=1). However, see the print-screens Because 50.000 tests gave only a small difference (last digit is ±1 second), I raised the number of tests to 500.000 So the ´statement´ in variable myvarnq still holds approximately. With ONE double-quote character in myvar (instead of five), the calculated difference will be around ½ second per 50.000 runs.

Speed is your ultimate goal, but what about your problem of max AGP4x? What is shown by the 77.72 Geforce Display property tab?

I didn´t ment it being a problem, only that two more double-quote characters has to be removed. See first print-screen. BTW I changed variable to an example which can easily led to an odd number of quotes on the FATCOPY.G4b command-line (latest double-quote character AFTER last slash). First run is your original Function13-batch, in the second run myvar is set between extra double-quotes, third run is the batch with my dd-approach, but already including your write (md)%mdmem%+1 %myvar%\0 I'm impressed, cat --skip=%start% (md)%mdmem%+1 | set myvarnq=%myvarnq% is a great idea! It's working nice. I made a small timing-batch. Variable myvar is centralized (in the four called batch-files above temporarily commented out) and writing to screen in LOOPTEST.G4B only. I took out a part of my FATCOPY.G4B-timer, so don't use around midnight. I gave the four different approaches to remove double-quotes some nice names. WDDQUOTE.G4B is my dd-approach, but with your use of write and also your use of cat --locate=\x22 (md)%mdmem%+1 > nul || goto :eof to locate a double-quote character, used to run /not run the sub-routine (instead of mine - which is more complicated). Your three batches are in historical order. ---------------------------------------------------------------------------------------------------- looptest.g4b ---------------------------------------------------------------------------------------------------- !BAT set=* debug off pager off set testg4b=%1 if not exist testg4b && echo && echo command-line: looptest.g4b FILE.G4B NUMBER && echo && goto :eof set /a numtest=%2 > nul if not exist numtest && echo && echo command-line: looptest.g4b FILE.G4B NUMBER && echo && goto :eof if %numtest%==0 && echo && echo command-line: looptest.g4b FILE.G4B NUMBER && echo && goto :eof set myvar="something" with space and two spaces aND "" quotes" #set "myvar=something with space and two spaces aND quotes" if exist myvar && echo myvar: %myvar% set time0=%@time% set /a loopnums=0 > nul :testloop if %loopnums%>=%numtest% goto :timing set /a loopnums=%loopnums% + 1 > nul set myvarnq= setlocal && call %testg4b% endlocal && set myvarnq=%myvarnq% goto :testloop :timing set time1=%@time% set /a "timesec0=%time0:~0,2% * 3600 + %time0:~3,2% * 60 + %time0:~6,2%" > nul set /a "timesec1=%time1:~0,2% * 3600 + %time1:~3,2% * 60 + %time1:~6,2%" > nul set /a "copytime=%timesec1% - %timesec0%" > nul echo myvarnq: %myvarnq% echo Test time: %copytime% seconds <=> Number of tests run: %loopnums% echo ---------------------------------------------------------------------------------------------------- --------------------------------------------------------------------- wddquote.g4b --------------------------------------------------------------------- !BAT #set myvar="something" with space and two spaces aND "" quotes" set /A mdmem=0x3000 > nul echo -n > (md)%mdmem%+1 write (md)%mdmem%+1 %myvar%\0 cat --locate=\x22 (md)%mdmem%+1 > nul || goto :eof call :noquotes goto :eof :noquotes set seekbyt= cat --locate=\x22 --number=1 (md)%mdmem%+1 | set seekbyt= if not exist seekbyt && cat (md)%mdmem%+1 | set myvarnq= && goto :eof set seekbyt=0x%seekbyt% set /A seekbyt=%seekbyt% set /A "skipbyt=%seekbyt% + 1" dd if=(md)%mdmem%+1 of=(md)%mdmem%+1 bs=1 skip=%skipbyt% seek=%seekbyt% goto :noquotes ----------------------------------------------------------------------------------------------------- ---------------------------------------------------------------- de_quote.g4b ---------------------------------------------------------------- !BAT #set myvar="something" with space and two spaces aND "" quotes" set myvar=%myvar% echo %@retval% | set myvarl= set myvarnq= set /a counter=0 > nul call :de_quote goto :eof :de_quote call set thischar=%^myvar:~%counter%,1%: set /a counter=%counter%+1 > nul if not \%thischar%==\": set myvarnq=%myvarnq%%%thischar:~0,1% if ":"=="%thischar:~0,1%" set myvarnq=%myvarnq:~0,-1% if %counter%==%myvarl% goto :eof goto :de_quote ---------------------------------------------------------------- ---------------------------------------------------------------- function13.g4b ---------------------------------------------------------------- !BAT set /A mdmem=0x3000 > nul set /A myskip=0x600000 > nul #set myvar="something" with space and two spaces aND "" quotes" echo -n > (md)%mdmem%+1 write (md)%mdmem%+1 %myvar%\0 > nul cat --locate=\x22 --replace=: (md)%mdmem%+1 set myvar= call :Function13 set myvarnq=%myvar% goto :eof :Function13 call Fn.13 %myskip% ":" set /A myskip=%@retval% > nul cat --skip=%myskip% (md)0+0x3001 | set mytoken=: set /A myskip=%myskip%+%@retval% > nul set myvar=%myvar%%%mytoken:~1% call Fn.11 %myskip% ":" && goto :Function13 goto :eof ---------------------------------------------------------------- ---------------------------------------------------------------- tokenize.g4b ---------------------------------------------------------------- !BAT set /A mdmem=0x3000 > nul set /A myskip=0x600000 > nul #set myvar="something" with space and two spaces aND "" quotes" set myvarnq= set myoffets= echo -n > (md)%mdmem%+1 write (md)%mdmem%+1 %myvar%\0 > nul cat --locate=\x22 (md)%mdmem%+1 | set myoffsets= cat --locate=\x22 --replace=\x00 (md)%mdmem%+1 cat (md)%mdmem%+1 | set myvarnq=%myvarnq% if not ""=="%myoffsets%" call :tokenize %myoffsets% goto :eof :tokenize set /A start=0x%1+1 > nul cat --skip=%start% (md)%mdmem%+1 | set myvarnq=%myvarnq% if not ""=="%2" shift && goto :tokenize goto :eof ---------------------------------------------------------------- Tests are all run in VBox 6.0.18 r136238. First print-screen below is testing while each batch-file has to be read from disk, so each run again. I also tried loading the four batches with insmod (using insmod with LOOPTEST.G4B was only about one second faster). Load-order or loading all batches at once made no difference. And the Winner is: tokenize.g4b , your last creation. But the dd-approach doesn't seem so bad in terms of speed, only 3 seconds slower, although I don't understand why this is a constant number if using /not using insmod. BTW: I only used dd in FATCOPY.G4b because I had no better idea to solve my problems of cutting out /inserting characters in a variable. Never because of speed.

Interesting, but I will have to study the used Fn calls to understand more of it. Your latest approach seems to work, but only if the variable begins and end with a double-quote character! In my dd-approach this is not needed (and remaining double-quotes if used on the FATCOPY.G4B command-line will be not at begin or end of the variable containing the source path). Are there more precise timing possibities with GRUB4DOS? My timer in FATCOPY.G4B has a minimum of whole seconds, which is far to much for comparisons needed here.

@jaclaz Thanks a lot I am VERY happy to have a working example with call expanding %^var:~s,n% with a loop! I've red everything about it in Steve's documents I could find, but still didn't grasp the whole 'thing'. In my understanding of your batch-file the double-quote character " can be evaluated with if %var%== if between two 'supported' characters. I believe the colon you included in set thischar=%^myvar:%counter%,1%: is needed because of the spaces. But I found out the colon can be left outside if double-qoutes are used during setting thischar, then if not \%thischar%:==\" : is always working (and will the line if ":"=="%thischar:~0,1%" set myvarnq=%myvarnq:~0,-1% be unnecessary). To fit in one print-screen I changed 'something' in myvar too. Also substituting spaces with the needed ls-spaces ("\ ") is easygoing with your approach expanding variables with call. But I think your idea to use write to get even a variable containing an odd number of double-quotes into (md), together with my use of dd will be a bit faster. Only a fistful of spaces need to be cut out, instead rewriting the whole variable. Or am I wrong?

Of cause, but my idea was IF the 77.72 driver gave better performance than with the 8x.xx drivers (both for your 6800), it could be worthwile to 'dig deeper' with the 7xxx AGP cards on Win98 regarding drivers /Registry.