linking & linkers 32-bit PE (obj=COFF)

[hutch--]

Even though i have used Microsoft linkers for years, they are a bit patchy from time to time and i have had the odd program squark a problem which went away when I used POLINK. I discovered POLINK when Vortex posted it here once and it can almost exclusively deliver a file that is a section smaller (512 bytes) but more importantly, it has a tidier MZ / PE header which is built to later PE specs. I have been very pleased with Pelle's tools to this extent that he keeps them up to the latest specifications in object modules and file formats.

The linker out of VC2005 appears to be a better tool than many of the earlier ones.

[Gustav]

> polink writes MZ/PE header better, without any odd marks, while MS link dont (I told - "%Rich%":) BUT (!) polink
> marks import section as WRITEABLE(!), not only INITIALIZED and READABLE and merge it automatically with
> <.data?> section while MS link with <.const> which is more correct i think since import table are filled (written) with
> addresses by windows only and should be protected.

But this is no protection at all, since an app can easily change the protection attributes with VirtualProtect(). Some will even regard the MS protection as an annoyance.

Besides MS link and PoLink there is also Open Watcoms WLINK, which is very good for linking mixed (OMF - COFF) object modules, and it produces a very informative map file, but regretably has a very strange command line syntax.

[lingo]

A lot of emotional people here
who forget about  thousands  of programmers worldwide
who are "testing" MS linker every working day.... :lol

[PBrennick]

lingo,
Good, you have a lot of people to ask then, you had better get busy.  ::)

Paul

[lingo]

"You can program so there is no reason why you cannot do those tests yourself."
"Good, you have a lot of people to ask then, you had better get busy. "

... and people who cannot control themselves too... :naughty:

[PBrennick]

 :lol

[hutch--]

I am a prgmatist, smaller = better with a linker's output and POLINK usually delivers smaller output. Linkers have never been Microsoft's strong point, in days of old, OptLink used to kick ass against a Microsoft linker and I suggest that specialised tools do much the same these days.

[GregL]

One issue I've found with POLINK is that it does not make .PDB files. (Maybe a licensing issue?)

Pelle explained once that POLINK doesn't support .PDB files because it is a proprietary format that is mostly undocumented and Microsoft keeps changing it with each new release of Visual Studio. I don't blame him for not supporting it.  :bg 

Like you said, POLINK supports the CodeView and/or COFF formats which is plenty good enough.

[PBrennick]

I think it needs to be pointed out that this was a meaningful issue in the old days when sector sizes on storage media was smaller.  Today, these savings in file sizes is only meaningful when the file is in memory.  The reported file size of a file in storage, especially an assembly file where this hit is really noticable is no where near the size in space that it actually consumes in the media.  Remember that files are stored in fixed size blocks and this whole thread has very little meaning except for the self satisfaction of what it appears you are achieving.

Paul

[asmfan]

PBrennick, i cannot agree with U. according to your logic we should say that assembly programming is out-of-date while there are such fast processors and 500GB HDDs...
using assembly we try to make the fastest, smallest, cleanest and just ...est (i mean coolest;) programms. that is why i started this thread - to find the most effective linker, that doesnt put any meta-data on its own

[PBrennick]

Agreeing with me is unimportant.  It is still true.  Everything is stored by sector size.  I only program in assembly so I have know idea what you are talking about.  :bg

Paul