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 :-) 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. 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 :-) 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. 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... :-) 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. Cheers, Eric ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
