Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4

2004-11-19 Thread Bart Oldeman
On Thu, 18 Nov 2004, Arkady V.Belousov wrote: Of course, qsort() if very fast algo (except some specific cases, when it is O(N^2)), but why to do _any_ extra action, when unnecessary? :) Especially, I suggest, (most) linkers do own sorting anyway? I think even bubble sort would be fast

Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4

2004-11-19 Thread Arkady V.Belousov
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

Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4

2004-11-19 Thread Bart Oldeman
On Sat, 20 Nov 2004, Arkady V.Belousov wrote: Yes, and then now may be reduced code duplication in asmsupt.asm (which generated both for transient and resident portion). only for Borland C. For Watcom they are not duplicated (only one CS: there). And anyway it's only a small amount of

Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4

2004-11-18 Thread Bart Oldeman
On Thu, 18 Nov 2004, Arkady V.Belousov wrote: Small optimization: because BC doesn't knows, that exit() doesn't returns, better to insert explicit return 0; after exit() or return error code through return (remaining error handling for main()). For BC, this allows to join common tails.

Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4

2004-11-18 Thread Arkady V.Belousov
Hi! 18--2004 21:21 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: Small optimization: because BC doesn't knows, that exit() doesn't BO I don't think optimizing exeflat.exe's size is very important though ;) Sure. :) But why not make more optimal code from scratch in any

Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4

2004-11-18 Thread tom ehlert
Hello Arkady, Small optimization: because BC doesn't knows, that exit() doesn't BO I don't think optimizing exeflat.exe's size is very important though ;) Sure. :) But why not make more optimal code from scratch in any case, without thinking will this code often used? And why not

Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4

2004-11-18 Thread Arkady V.Belousov
Hi! 18--2004 11:24 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov [EMAIL PROTECTED]: te And why not leave *existing* code as is - without wasting mental and te ethernet bandwidth on it ? This is not (yet) existing, this is _new_ code. Especially, I suggest, (most) linkers do

[Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4

2004-11-17 Thread Arkady V.Belousov
Hi! 17--2004 18:01 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG +++ exeflat.c 17 Nov 2004 18:01:54 - 1.9.2.4 LG +int exeflat(int UPX, const char *srcfile, const char *dstfile, LG +const char *start, short *silentSegments, short silentcount) LG