Hi!
20-Ноя-2004 18:54 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
>> Hm. I think for simplicity and safety, exeflat should itself move
>> relocation table from executable's header inside executable itself, so that
>> it may be reused by MoveKernel(). This allows to eliminate manual table at
>> kernel.asm:__HMARelocationTableStart.
>> (Yes, I know __HMARelocationTableStart is not plain relocation table,
>> but jump/code table, with jmps and calls to EnableA20. But table from header
>> may be copied (after fixing) into "secondary" table. This allows to make
>> code, which is more relocatable and may make cross-segments calls and
>> accesses. This also solves issues with standard library routines, which may
>> be used both from non-relocatable low code and from relocatable code.)
BO> This is not so easy. Firstly a secondary table would need extra space in
BO> low memory.
...unless it will be placed into transient/initial portion, which
discarded from memory after startup.
BO> There used to be entries to strcpy et al in the table but I
Yes, and then now may be reduced code duplication in asmsupt.asm (which
generated both for transient and resident portion).
BO> removed them later because that part of the table that was useless after
BO> init was still resident.
If you relocation table (RT) will be placed into discardable portion,
then it will not "still resident", And see the difference: RT is not "entry
points table", but table with references to places, which need correction,
if they refers to relocated code.
BO> Secondly it would be quite a bit of effort for very little gain.
1. This gives safety (not need to worry about references from initialization
part to relocatable resident part; of course, reference from resident
portion to transient portion shold be worried).
2. This allows to reduce code (no duplication of same functions, like
strcpy).
BO> Also think about it: we don't know in advance how big
BO> the table will be, it's hard to insert something of arbitrary size in
BO> kernel.sys.
Of course, I think about this. But, because this table (should be)
placed into transient portion, why not _allocate_ oversized table (say,
100-200 items)? Especially, because unused entries will be zero, they will
be very well packed by UPX? I see there only one issue: how to reliably
find in exeflat, where those place (for RT) resides in executable.
BO> And then, where's the simplicity?
Of course, initial efforts to implement are not very easy, but gain is
noticeable. For example, with such relocation you will never encounter
troubles, like was issued with RTL-multiplcation functions from OW. The more
so, now they may be moved from low/nonrelocatable part (in kernel.asm) into
resident part! (Do you remember, how I was try to move Borland's RTL
functions into resident part and forget about relocations?)
>> PS: Bart, some time ago you decrease kernel by reordering object files. May
>> you explain what was changed and how you find this?
BO> Just reordered by placing more or less similar files close together (asm
BO> close to asm, c close to c); that decreased entropy so compression
BO> improved.
Only compression? I remeber something about reduced executable size,
but without words about compression.
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
