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 0x0000: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 ->0000 (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

Reply via email to