deomsh

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.

@Wunderbar98 Thanks! I just tested your Unix-suggestion, but doesn't seem to make any difference (see the print-screen below). Only the odd er even number of double-quotes seems to count in echo %a% > (md)0x3000+1. First part: variable with odd number of double-quotes inside single-quotes. Second part: variable with even number of double-quotes inside single-quotes But at least I learned a single-quote is 27h Jaclaz' solution to use write seems to work (see second print-screen). Only termination is different, without 0D 0A, but can be added if needed.

My problem is to identify an odd number of quote-signs inside a variable, with the purpose to get rid of them with help of (md). Quotes are only used on the FATCOPY.G4B command-line in case of spaces in PATH and /or FILE. So only used in case of LFN's. An example is in the picture below. Last five lines are normal copy-output, first three / four lines after fatcopy are written to screen for clarification. If only two outside quotes are used, they are already removed by the %~1-readout of PATH (in the example DEVICE is root and FILE is not specified). But if each directory in PATH is surrounded by quotes, an odd number of quote-signs remains in the variable %sdir% after the readout. In this case the echo %sdir% > (md)0x3000+1 line is written to screen only, together with a part of my 'dirty' workaround: if exist sdir && set /a succeed=0 # %mdmem% is normally 0x3000 if exist sdir && echo -n > (md)%mdmem%+1 if exist sdir && echo %sdir% > (md)%mdmem%+1 && set /a succeed=1 if exist sdir && if %succeed%==0 && set sdir=%sdir%" if exist sdir && echo %sdir% > (md)%mdmem%+1 && set /a succeed=1 if exist sdir && if %succeed%==0 && echo && echo Use of qoutes is not valid && goto :eov set quotes= # " = 22 hex if exist sdir && cat --locate=\x22 (md)%mdmem%+1 > nul echo %@retval% | set quotes= if exist sdir && if %quotes%>=1 && set quotes= && setlocal && set file=%sdir% && call :noquotes if exist sdir && endlocal && set sdir=%file% && set file= set quotes= Once the variable containing quote-signs is written to (md)0x3000+1 I call following sub-routine to remove the quote-signs: :noquotes set seekbyt= # " = 22hex cat --locate=\x22 --number=1 (md)%mdmem%+1 | set seekbyt= #%mdmem% is normally 0x3000 if not exist seekbyt && cat (md)%mdmem%+1 | set file= && 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 Afterwards I use set sdir=%file% to get the source directory without quote-signs. Third / fourth line in the picture above is after replacing all spaces in PATH by ls-spaces ("\ "), needed for proper operation. Everything is working as needed, only the echo of my dirty workaround bothers me, and because of its non-specific character. Thanks for your solution to use write to write a variable to (md). I did some first tests and I think my problem is solved, but I have to rewrite some parts of my batch-file, because even set file=%sdir% && call :noquotes is not working if the variable contains an odd number of quote-signs.

I solved my problem using quotes & spaces on the FATCOPY.G4B command-line. It appears that outside-quotes are removed if %~d1 / %~p1 / %~nx1 are used to read out DEVICE1 / PATH1 / FILE1 etcetera. So different from GRUB4DOS commands like ls, where a quote-sign before a DEVICE gives an error. To avoid undesirable results because of remaing spaces in variables, all I had to do was an earlier call to my subroutine that changes normal spaces the the GRUB4DOS "\ "-spaces representation. If quotes are used around PATH and /or FILE (or -superflous- even around DEVICE) things became more complicated if only one quote-sign is left after the readout (or three). It appears that a variable containing an odd number of quotes, regardless their position inside the variable, can not be written into memory with echo %var% > (md)0xMMMM+1. In this case the whole command-line is echo'd on screen, nothing happens further. I found a sort of workaround to add one quote-sign to the variable if this happens, but I am not fully satisfied, because the workaround in fact doesn't detect an odd number of quotes in the variable, only that writing a variable to (md) didn't happen. Also quotes can't be detected by %var:~s,n% , although they are counted by echo %@retval% after set var=%var% Any ideas?

What about the 77.72 drivers? Should work with a GF6800.

If you have a modem/router, there will be a hardware firewall onboard. About Links: once setting are saved, history will be saved too. Can be browsed with "g" and up/down arrows. My 1900x1200 LCD needs aspect calibration: ratio 0,87 with 1600x1200 video mode.

While in Win9x there many Windows browsers usable, for Windows 3.1 this is not true. In my experience best is Netscape 3.04, but browsing is only more or less comfortable with a webproxy like proxycrime.com. I tested Links 2.21 for dos in a Windows 3.1 MS-DOS window, and I think this is possibly an asset for Windows 3.1 browsing. Also the video possibilities are great. While using a XGA 640x480 16 colors driver, inside Links for dos 1600x1200x16M32 (full color!) is no problem with the right video card /monitor. DPMI is delivered by Windows, if mouse-services are a problem a compatible mouse driver can be loaded in Real mode before Windows is booted (in my case CTMOUSE.EXE is not compatible with Windows 3.1, but LMOUSE.COM gave no problems with my USB-legacy mouse). Links for dos can also be used as a viewer for htm (I assume html = htm in 8+3 Short File Names), jpg, png, gif, but NOT bmp. With FileManager the neccesary associations with LINKS.BAT can be made (LINKS.PIF gives LINKS working in text-mode only for me). To get this result I am using following LINKS.BAT in my system: C:\DOS\LINKS\LINKS221.EXE -mode 1600x1200x16M32 %1 LINKS.BAT is most convenient placed in the Windows directory. LINKS.PIF can be made and edited (seems not critical). If used, better disable Alt+Enter and Alt+Tab (Switching to other programs works for me only if Links video-mode is exactly equal to Windows video-mode). I was surprised that a real packet driver (RTSPKT.COM for my RTL8139 NIC) together with WINPKT.COM is working in a Windows 3.1 MS-DOS window, this after the problems with Win9x.