Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
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.
I don't think optimizing exeflat.exe's size is very important though ;)
LG + qsort(reloc, header.exRelocItems, sizeof(reloc[0]), compReloc);
Why to spend extra time for sorting relocations?
I think it's easier to read the output that way. Tom's idea.
Does qsort() really take a long time for you in exeflat? I find that hard
to believe, for just ~70 relocations.
LG +for (j = 0; j silentcount; j++)
LG + if (segment == silentSegments[j])
LG + {
LG +silentdone++;
LG +goto dontPrint;
LG + }
Never understand this option. (Though, don't try to study its meaning
deeper). The more so, me always annoying tons of some information about some
relocations, which garbaes output after exeflat.
use a larger backscroll buffer. Anyway, seriously:
The -S0x10 -S0x8B is outdated. 0x10 corresponds to segment 0x70 (device
drivers etc) and 0x8B to the DOS data segment at 0xEB. However over the
years some things were made smaller and the DOS data segment seems to be
at 0xCF or 0xD0 depending on compilation options now.
-S0x10 -S0x6F -S0x70
will catch relocations from these segments. The idea to silence these is
that these relocations are harmless because these segments don't move.
Relocations to other segments may be bugs. With the above options you
should get something like
relocation at 0x:0x0021 -01d6 (far jmp to init code in kernel.asm)
relocation at 0x01d6:0x9f2d -0f2f (seg init_tos in kernel.asm)
relocation at 0x01d6:0xa19c - (LowKernelConfig, main.c)
relocation at 0x01d6:0xc21c -01d6 (MoveKernel, FP_SEG(_HMATextEnd, inithma.c)
I checked them and these relocations are all fine. But if a fifth shows up
unexpectedly we may have a bug.
---
UPXOPT seems indeed unnecessary now.
Bart
---
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
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
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 case, without thinking will this code often used? LG + qsort(reloc, header.exRelocItems, sizeof(reloc[0]), compReloc); Why to spend extra time for sorting relocations? BO I think it's easier to read the output that way. Tom's idea. BO Does qsort() really take a long time for you in exeflat? I find that hard BO to believe, for just ~70 relocations. 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? Ok, ok, above questions are not critical and mostly rhetorical. LG +for (j = 0; j silentcount; j++) Never understand this option. (Though, don't try to study its meaning deeper). The more so, me always annoying tons of some information about some relocations, which garbaes output after exeflat. BO use a larger backscroll buffer. Anyway, seriously: BO The -S0x10 -S0x8B is outdated. 0x10 corresponds to segment 0x70 (device BO drivers etc) and 0x8B to the DOS data segment at 0xEB. However over the BO years some things were made smaller and the DOS data segment seems to be BO at 0xCF or 0xD0 depending on compilation options now. ...and different kernel branches. :) BO -S0x10 -S0x6F -S0x70 BO will catch relocations from these segments. The idea to silence these is BO that these relocations are harmless because these segments don't move. BO Relocations to other segments may be bugs. With the above options you Ok, I see. Thank you for exaplanation. BO should get something like BO relocation at 0x:0x0021 -01d6 (far jmp to init code in kernel.asm) BO relocation at 0x01d6:0x9f2d -0f2f (seg init_tos in kernel.asm) BO relocation at 0x01d6:0xa19c - (LowKernelConfig, main.c) BO relocation at 0x01d6:0xc21c -01d6 (MoveKernel, FP_SEG(_HMATextEnd, inithma.c) BO I checked them and these relocations are all fine. But if a fifth shows up BO unexpectedly we may have a bug. 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 --- BO UPXOPT seems indeed unnecessary now. Sure. :) PS: Bart, some time ago you decrease kernel by reordering object files. May you explain what was changed and how you find this? --- 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
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
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 leave *existing* code as is - without wasting mental and ethernet bandwidth on it ? LG + qsort(reloc, header.exRelocItems, sizeof(reloc[0]), compReloc); Why to spend extra time for sorting relocations? BO I think it's easier to read the output that way. Tom's idea. BO Does qsort() really take a long time for you in exeflat? I find that hard BO to believe, for just ~70 relocations. 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? :) it's not unnecessary - else I wouldn't have written it. Especially, I suggest, (most) linkers do own sorting anyway? I call people who 'suggest' somethintg that is plain wrong (and they could have seen that themself) idiots. Ok, ok, above questions are not critical and mostly rhetorical. but give some insight. 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.) if you can write down a simpler and saver method to do that - fine. else - see my bandwidth comment... tom --- 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
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
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 own sorting anyway? te I call people who 'suggest' somethintg that is plain wrong (and they could te have seen that themself) idiots. Sometime I study executables, and seen tables was sorted. (Probably, this was caused by applied exepackers, I not remember such details, but they _was_ sorted). --- 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
[Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.4,1.9.2.5
Hi! 18--2004 11:20 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG (Arkady) Remove -U option as Bart's new EXFLAT now uses XUPX variable directly LG +++ exeflat.c 18 Nov 2004 11:20:04 - 1.9.2.5 LG + upx = getenv(XUPX); LG + compress_sys_file = exeflat((int)upx, argv[1], argv[2], argv[3], LGsilentSegments, silentcount); LG + if (upx == NULL) I think, exeflat (upx != NULL,... should be better - at least, in sense of readability. Also, into config.b should be added comment about usage of XUPX in exeflat.c. --- 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
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel makefile,1.19.2.4,1.19.2.5
Hi! 18--2004 11:20 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG +++ makefile18 Nov 2004 11:20:03 - 1.19.2.5 LG + ..\utils\exeflat kernel.exe $*.sys $(LOADSEG) -S0x10 -S0x8B -^^ As explained by Bart, this value should be changed to reflect real (current) position of FD data segment. --- 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
[Freedos-kernel] Re: [Freedos-cvs] kernel build.bat,1.14.2.4,1.14.2.5 buildall.bat,1.6.2.1,1.6.2.2 clean.bat,1.10.2.1,1.10.2.2 clobber.bat,1.11.2.1,1.11.2.2 config.b,1.12.2.2,1.12.2.3 defaults.bat,1.1.2.3,1.1.2.4 filelist,1.9.2.5,1.9.2.6 makefile,1.2,1.2.2.1
Hi! 18--2004 11:16 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG Modified Files: LG Tag: UNSTABLE LG build.bat buildall.bat clean.bat clobber.bat config.b LG defaults.bat filelist makefile LG Log Message: LG sg This letter looks like bug somewhere (because garbage after Log). --- 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
[Freedos-kernel] Re: [Freedos-cvs] kernel/hdr portab.h,1.31.2.3,1.31.2.4
Hi! 18--2004 11:20 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG Suppress TC++ 1.01 warnings (BC++ 3/4/5 not affected!) and MSC LIB prompt LG +++ portab.h18 Nov 2004 11:20:03 - 1.31.2.4 LG @@ -66,6 +66,14 @@ LG +#if __TURBOC__ 0x400 /* targeted to TC++ 1.0 which is 0x297 (3.1 is 0x410) */ LG +#pragma warn -pia /* possibly incorrect assignment */ LG +#pragma warn -sus /* suspicious pointer conversion */ LG +/* LG + * NOTE: The above enable TC++ to build the kernel, but it's not recommended LG + * for development. Use [Open]Watcom (the best!) or newer Borland compilers! LG + */ LG +#endif May I ask which places cause warnings, which are turned off here (I don't have TCPP1 to check this)? May be better to fix (for example, by adding castings) those places instead turning off warnings at all? --- 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
