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

2004-11-20 Thread Arkady V.Belousov
Hi! 20-Ноя-2004 20:50 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: >> troubles, like was issued with RTL-multiplcation functions from OW. BO> That was a different problem. Watcom generated NEAR calls to these BO> functions. Relocation wouldn't help. This point is moot now with one

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 co

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

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-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) li

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 wh

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 i

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 tai

[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)