> On Oct 5, 2015, at 8:14 PM, Eric Auer <[email protected]> wrote: > > > Hi Jerome, > > combining 20 tools of 1-2 kilobytes each into one tool of 10 kB > sounds like a good plan and using "residency" sounds even better: >
Yes and maybe there will be an edition that does that at some point. But, for now that is not what was requested. > Outside the floppy world, each of your tools will use at least > 4 kB because sizes get rounded up to full, often large, clusters. > > Also, having some sort of resident part would allow you to have > some persistent state between tool invocations. This could be a > simple memory area that you can allocate and free. I think it is > not useful to make the whole tool itself stay in RAM for this :-) > > Having resident data will reduce issues with needing SET /P which > has limitations (e.g. using pipes, which in most DOS command.com > variants need temp files on a writeable drive) and is not in the > classic MS DOS version of command.com (in case somebody tries to > use your batch files to upgrade an existing MS DOS install). The only tools that will require set /p support for any usable functionality will be vask (when I get around to making it) and vmath. There are advanced functions in vcursor, vfdutil, vgotoxy, vmode, vstr and vchoice that can be taken advantage of when set /p works. But, for the most part they are not needed or required to accomplish most things. Let’s take vchoice for example. You can fairly easily have a area that vchoice will use for selection. It will by default output your choice as an exit code (errorlevel). No set /p required. However, if lets say you have displayed 20 file names, your batch file does not know what the filenames are since you basically are just listing a directories contents. You want the user to pick one. If you knew what the names were, you could use 20 “if errorlevel n” instructions to set an environment variable you want to pass as an archive name to the zip utility. If you use the /Q option on vchoice that text will be sent to STDOUT. So, you could use basically 1 line to achieve something that is not really possible otherwise. Just, by doing “vchoice /Q | set /p ZARC=“ But, like I said this is an advanced function and would not be needed most of the time. Another example is vfdutil. You can go directly to a drive and path of a filename. changing the current drive and directory by using “vfdutil /c/p %SOMETHING%”. But, if you want to find out what that path is for doing something like listing files there it requires something like this: vfdutil /p %SOMETHING% | set /p FPATH=“ dir %FPATH%\*.* >FILELIST.TXT > > Of course I do not know if ALL instances of SET /P can be avoided > this way, but it would be interesting to hear more about this :-) For the most part, it wouldn’t reduce the need for set /p. The only thing that would really benefit from a resident portion and V8 managing it’s own variables would be in regards to the vmath utility. Pulling information from vgotoxy, doing some calculations in vmath, then passing that to either vgotoxy or vframe, could avoid using set /p if V8 had some way to pass data around other then relying on the shell’s environment. But, mostly, stuff ends up needing to use set /p because it has to talk to other utilities outside of V8. > > Eric > > > > PS: Regarding the block driver discussion, I *guess* that exFAT is > too different from FAT. So a block driver to make it look like FAT > to a DOS kernel would have to trick a lot. Better use CDEX/net API. > > Easier block cases include "compress a FAT diskimage transparently" > as we know from stacker / doublespace / drivespace style drivers :-) > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
