Re: .EXE -> .ASM -> .EXE


santosh wrote:
are bad; you're
operating under a serious misconception here.

I think they've been "scarred" by seeing certain statically linked
C/C++ executables. When you ask for static linking, sometimes the
entire libc is linked with your program resulting in a 800 kB hello
world demo. Similarly heavy use of templates can blow up a C++
executable to a megabyte or more.

That won't change with what they're trying to do, though. If a library
routine calls code in another library routine, which calls code in
another library routine, ..., etc., then you wind up bringing all the
code into your application. This is particularly troublesome with OOP
code, where the VMT often references every method/function in the
class, even if the code doesn't actually use it. Of course, this is not
the fault of the library, but of the original class design and a
"LibScanner" program won't solve this problem.

Of course runtime linking solves the problem...

That makes the size of the executable smaller, and allows other apps to
share the library in memory, but fundamentally you've still got to have
all the code in memory when the app runs.
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: .EXE -> .ASM -> .EXE
    ... C/C++ executables. ... another library routine, ..., etc., then you wind up bringing all the ... all the code in memory when the app runs. ... Yes, but with shared libraries, only one copy of the code needs to ...
    (alt.lang.asm)
  • Re: Is Greenspun enough?
    ... Most OSes memory map executables directly from the file ... > On most CPUs today the cost of executing code from a dirty page is ... code vectors are allocated immediately ...
    (comp.lang.lisp)
  • Re: help me understand memory and processes
    ... > exasctly equal to the amount of memory consumed by only one copy. ... If a process is running many times (many executables) ... almost none of the DATA-part can be shared, ... And now, if I should tell, how much memory does your java really need ...
    (comp.os.linux.misc)
  • Re: Why sticky bit on executables?
    ... non-sticky'ed executables, once they were run... ... No need with the Virtual Memory we have today. ... memory and not have to swap things out to get real contiguous ... set - eg the most used files such as sh, vi, and others, to reside ...
    (comp.unix.sco.misc)
  • Re: Memory management/File IO related problem.
    ... This is not free memory that's taken away. ... I/O), and if they're not, they aren't hurting anything ... this behavior is one of the main reasons why Solaris ... executables are simply pushed out of RAM ...
    (comp.unix.solaris)