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