Re: Unloading KSTACK. Integrating BATCOMP
- From: Jaelani <jaejunks@xxxxxxxxxxxxxx>
- Date: Tue, 28 Oct 2008 09:29:42 -0700 (PDT)
On Oct 24, 10:24 pm, Luchezar Georgiev <lu...@xxxxxxxxx> wrote:
Luchezar Georgiev пишет:
While I do this (it may take a while), could you please look at
KSTACK.ASM, and let me know your opinion on adding a "unload from
memory" option to it?
Jaelani, the above remains in force, due to the reasons outlined below.
I did not actually look at the code, which I presume is used to create
the KSTACK.COM module. Conceptually, it makes sense to unload it when
no longer required. However, it is such a small unit that it is
probably not worth the trouble. In fact, the total 4DOS footprint
might be reduced if it were integrated into 4DOS.COM - the code to
make sure KSTACK.COM is loaded, and to find where it is loaded, would
no longer be needed.
Unfortunately, as enticing this idea might be, we have to reject it. The
reason is that 4DOS doesn't stay resident in memory all the time whereas
KSTACK must be. If we want to integrate it into 4DOS we must place it in
the resident portion which is currently about 5K, increasing its size by
30%, which is unacceptable. But BATCOMP can still be integrated in 4DOS.
Regards,
Lucho
That's strange... The KSTACK in 4DOS 7.90 uses only 1.5KB.
Adding an unload feature is possible with a little restriction. e.g.
whether the buffer is not yet empty.
For KSTACK unload feature... IMO, additional tasks are required in
order to avoid memory "hole" creation (free memory fragment) since it
only uses standard TSR procedures. Since the "hole" is quite small,
some programs may not be able to use it and thus, makes it a useless
free memory block.
The additional tasks involves:
- Checking whether the current buffer is empty or not, when being
unloaded. Deny unload request if it's not yet empty. May increase TSR
size by 20-30 bytes.
- Move itself to the highest free memory area (base or upper), when
being loaded. No TSR size increase required.
Also, a reduced memory consumption may be possible in current KSTACK
version. Probably about 256 bytes.
The unload feature can increase TSR size about 10-20 bytes.
As for BATCOMP integration, unfortunately I'm yet to understand how
4DOS works internally. Don't have the time to study it yet.
.
- Follow-Ups:
- Re: Unloading KSTACK. Integrating BATCOMP
- From: Luchezar Georgiev
- Re: Unloading KSTACK. Integrating BATCOMP
- References:
- Re: EDISCRN.INC reconstruction, TPCRT problem
- From: Jaelani
- Re: EDISCRN.INC reconstruction, TPCRT problem
- From: Luchezar Georgiev
- Re: EDISCRN.INC reconstruction, TPCRT problem
- From: Jaelani
- Re: EDISCRN.INC reconstruction
- From: Luchezar Georgiev
- More source code reconstructions
- From: Jaelani
- Re: More source code reconstructions
- From: Luchezar Georgiev
- Re: Unload KSTACK from memory?
- From: Luchezar Georgiev
- Re: Unload KSTACK from memory?
- From: Steve Fabian
- Re: STARTUPM.LIB and SASJP.LIB source code. Integrating KSTACK and BATCOMP
- From: Luchezar Georgiev
- Re: Unloading KSTACK. Integrating BATCOMP
- From: Luchezar Georgiev
- Re: EDISCRN.INC reconstruction, TPCRT problem
- Prev by Date: Re: _4INST.BTM
- Next by Date: Re: Unloading KSTACK. Integrating BATCOMP
- Previous by thread: Re: Unloading KSTACK. Integrating BATCOMP
- Next by thread: Re: Unloading KSTACK. Integrating BATCOMP
- Index(es):
Relevant Pages
|
Loading