Personally I would rather see an executable installer also and save any
batch installers for a floppy distro, A batch would be perfect for a
setting where every byte counts.
But this is Jim's project and what Jim wants, Jim gets. lol :)
On 10/26/2015 10:13 AM, JAYDEN CHARBONNEAU wrote:
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 <mailto:jer...@shidel.net>> wrote:
> On Oct 26, 2015, at 7:49 AM, Eric Auer <e.a...@jpberlin.de
<mailto: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
<mailto:Freedos-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
<mailto: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
