Somewhere back in the threads,I suggested an EXE installer.It can be made into one relatively small file,rather than 87 2KB batch files.Batch could be used more for setting up the extra features EX. Post install,ask the user if they want to install extra packages
On Mon, Oct 26, 2015 at 8:42 AM, Jerome E. Shidel Jr. <jer...@shidel.net> wrote: > > > On Oct 26, 2015, at 7:49 AM, Eric Auer <e.a...@jpberlin.de> wrote: > > > > > > Hi Jerome, > > > >> EN\STAGE300.DEF for the welcome screen. > >> EN\STAGE400.DEF for partitioning screens. > >> EN\FDINS100.DEF > > > > If you ask me, this is too much pain for too little performance. > > Going through some text, even if it is a few kilobytes, should > > be zero problem for the performance of a command like VECHO. On > > the other hand, you do of course want to cache the virtual floppy > > from which the installer boots on 32 bit systems! Actually this > > is IMPLICIT if you use MEMDISK: This is a bootable ramdisk based > > on the Linux boot infrastructure and menu. Obviously it works on > > 32 bit systems only and takes roughly 1 1/2 MB of RAM for usual > > floppy size but if you can boot from CD/DVD at all, it is VERY > > likely that this amount of RAM is nothing to worry about :-) > > The installer uses caching. So, that is why I’m going to see how > it performs using only 3 main language files. So far, nearly all > of the stage text is in one file and there is no noticeable performance > loss. :) > > > > > If, on the other hand, you want to boot from physical floppy, I > > strongly recommend caching. If you want to support ancient 16 bit > > computers, you do NOT want to use batch files as installer at all > > but instead one small EXE which keeps most data in RAM, simply > > because uncached floppy for access to multiple files is too slow. > > > > Not up to me. But, an Executable installer is super-easy to create > compared to a batch based one. > > > > > > > I agree that NAMES for strings are nicer than NUMBERS. I think > > the reason was that numbers have better performance if you cache > > the messages in a table in RAM when one program shows various > > messages in each invocation. As this is not the case for VECHO > > (which shows at most a few messages each time) it is perfectly > > fine to give messages names :-) Also it helps with readability, > > you have a point there :-) > > Actually, using the NUMBER system is probably only due to two > factors. I will assume that it was based on trying to reduce memory > consumption and file size. “1.42” is much smaller than “FORMAT_DRIVE?” > If not to squeeze bytes, it just seems like laziness to me. With a little > creativity, string lookups can be as fast or even faster than number > lookups. > > > > > > > > > Again, I think you should not worry about "locking" vecho to one > > single language file. You could actually try some combination in > > which %LANG% and %NLSPATH% are shared with other tools, but one > > part of the name is changeable by some option. Example: > > > > VECHO /NLS:1,HELLO ... > > > > could use the X:\DOS\NLS\VECHO1.EN file where 1 stands for stage 1 > > and where NLSPATH contains X:\DOS\NLS and LANG has the value EN :-) > > The HELLO here is the name of the string to pick from VECHO1.EN ... > > > > > > > >>> Why 256? Message files in theory support arbitrary line lengths :-) > >> > >> I felt that 127/96 is a little restrictive. Especially, when you start > throwing > >> in multiple text color changes an such things. So, I picked 256. :) > > > > Any buffer which has a fixed size is inviting troubles if you end > > up using more than that size. Supporting ANY size is often nicer. > > Maybe, but since the screen is limited to 80 character width normally, > 256 leaves lots of room for color changing and stuff. Don’t forget > that DOS limits the command-line to 127 characters. Basically, it > doubles that. Also, there is no reason multiple vecho /n commands > cannot be issued to keep writing on the same line. > > > > > In your example, you support any input line length, but parse text > > into a separate buffer, truncating too long text. Instead, try to > > directly use the data of the input file, keeping the ability to use > > any line length all the way including output line length... :-) > > I though about it for about 2 seconds. But, I don’t the the time to > do it anytime in the near future. Maybe, version 2.0 of V8. :) > > > > > Note that COM files do not HAVE to allocate memory, because they > > simply get all the memory which is available in their memory block > > by default when they start. Simply check the size of your block to > > see how much memory you have: Do not rely on the size being always > > at least 64 kB, for example. Yet, you often have more, not less. > > Yes, vchoice allocates memory. But, doing it depends on the memory > manager not the com file. So, vchoice tries to get some memory and > if it succeeds it will use it to preserve colors and stuff in the choice > options. > If it cannot allocate memory, it switches to dumb mode and strips out > any pretty colors. > > Basically, when using COM files and standard DOS memory allocation > routines, > some memory managers line (JEMMEX) will let it allocate additional memory. > Others, like HIMEMX report only 4 paragraphs of free memory available. A > paragraph being 16 bytes and any attempt to allocate some useful memory > fails. > > > > > Cheers, Eric > > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Freedos-devel mailing list > > Freedos-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-devel > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel >
------------------------------------------------------------------------------
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
