> On Oct 18, 2015, at 9:10 AM, Eric Auer <[email protected]> wrote: > > > Hi Jerome, > >> Without vecho, multi-color text highlighting won’t be viable. > > You could do this EECHO style, where $ is echoed as ESC char, > making it easy to use ANSI escapes for color. Actually this > feature is also supported in the FreeDOS kernel, but not in > FreeDOS command.com ... Still it could improve compatibility > to use ANSI for colors in your installer :-) >
Using ANSI would not make the installer more compatible. ANSI support needs to be present. Just as vecho needs to be present to use it. Also, for modifying the source and making a color theme, I feel that reading source like this: echo $e[44,0mhello$e[0mbob (Ignore any mistakes I have not used ANSI for years) As opposed to this: vecho /fRed hello /fGray bob vecho does not use ANSI or stdout and cannot be redirected. >> I did think of doing the localization translations inside vecho. > > That would be nice. > >> But, the increase in size to the executable would probably >> negate the benefits of having it internalized to vecho. > > That would be no problem: Remember that clusters are often > very large, so having FEW but MULTIFUNCTIONAL tools will use > less disk space than using many simple tools. Even though if > you only look at what DIR says, you may think the opposite. > I know all about slack space. Size is extremely important when using media with small clusters. Such as a boot floppy. The amount of proportional space wasted on a large drive with large clusters is a lower percentage of waste of the entire drive compares to small drives. But mostly, the super small executable size has more to do with load times from media like floppies. Reloading a 1.2kb program 50 times from an uncached floppy is not nearly as slow as reloading a 3.5kb executable 50 times. But on a large drive, load time will be close to the same and since the drive is much faster the loss in performance from loading multiple programs is not as punishing. > Having grep, cut, tr, ... in one tool could be fun, but if > you support regular expressions, it can make the tool big. > >> For example, at present it will return a total line count, return >> a specific line from a text file, translate a numeric value into >> an ascii character, output a character N times. > > Sounds like many functions in a tiny number of tools, nice :-) Yep. Something like this vstr /r80 /c65 Would dump 80 A's to stdout. Or use /r4096 to do 4k worth. :) > >> Future plans include things like: >> >> returning parts of lines based on delimiters. >> case changing. >> string searching. > > Note that FIND is in FreeDOS BASE anyway. I'm referring to different type of string searching. > >> character stripping and conversion. >> line prefixing and postfixing. > >> Most of the slower stuff is a result of disk I/O from making a >> backup copy of the previous OS and unzipping the new packages. > > Offer upgrades with less backup if you detect FDPKG / FDNPKG > compatible existing DOS. In that case, upgrade will often be > less destructive, making backups less important. You should > still backup config files in that situation, though... > > Also, use caches like the UIDE family or LBACACHE, TICKLE and > CDRCACHE for the CD/DVD itself :-) Be humble with cache size, > to keep compatibility with "low end but can boot from CD" PC. > The "boot floopy" already uses lbacache to boost floppy read performance. :) > Cheers, Eric > > > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
