polink compatability

[KeepingRealBusy]

How compatable is polink to, lets say from MASM 9.0. LINK?

Dave.

[hutch--]

PoLink is usually more up to date than the current available Microsoft linkers.

[Vortex]

Hi KeepingRealBusy,

Polink is my preferred linker and it links all my MS COFF object modules produced by ml.exe

[KeepingRealBusy]

Vortex,

I was wondering about the command line differences, but I do not use windows, strictly link with kernel32.lib. It appears that the options I use for LINK should also work for POLINK: "LINK /nologo debug.obj file.obj files.obj kernel32.lib /SUBSYSTEM:CONSOLE /DEBUG /MAP /OUT:files.exe".

I'll give it a try. I need something since my installed Visual Studio 2008 on my Windows 7 system does not link things that linked on Windows XP.

Dave.

[KeepingRealBusy]

Hi KeepingRealBusy,

Polink is my preferred linker and it links all my MS COFF object modules produced by ml.exe

Vortex,

So much for compatibility. I have attached the POLINK errors and the make file.

Dave

[KeepingRealBusy]

Polink is my preferred linker and it links all my MS COFF object modules produced by ml.exe

The main source of errors appears to be that it is treating all symbols as global, when, in fact, they are local symbols within a formal procedure. I am not sure why it cannot find the standard WinowsAPI symbols in the system32.lib.

Dave.

[Vortex]

I never had a serious problem with Polink. It works fine for me. Can you link the same object module(s) with MS link?

[japheth]

I know this problem because it also occured in jwlink.

the background is: "usually" the COFF symbol table contains only global symbols. However, if you enable symbolic debugging info with -Zi, masm will also write "static" symbols into this table. Those static symbols must not be used by the linker to resolve references, their purpose is just for better debugging support.

Obviously polink does not ignore those static symbols. Also, if you happen to have 2 static symbols with identical names, polink will throw the error mentioned previously.

example

Code Select Expand

.386
.model flat, stdcall

ExitProcess proto :dword

.code
start:
invoke ExitProcess, 0

p1 proc
label1:           ;1. instance of "label1"
ret
p1 endp

p2 proc
label1:           ;2. instance of "label1"
ret
p2 endp

end start


So this is definitely a polink bug.

[KeepingRealBusy]

Japheth,

Thank you for the info. I will disable the -zi and try again. Any clue why it can't find the Windows links?

Dave.

[KeepingRealBusy]

Japheth,

No luck. The static symbols ARE multiply defined, by my design.

I guess I will have to abandon polink and try to get LINK to not complain about a wrong version for MSPDBxx.DLL (xx is 80 or 90).

Dave.

[KeepingRealBusy]

Japheth,

Is jwlink compatible with LINK?

Dave.

[KeepingRealBusy]

I never had a serious problem with Polink. It works fine for me. Can you link the same object module(s) with MS link?

Vortex,

The reason I am looking for a new linker is that Visual Studio 2008 LINK keeps coming up with an error of a bad MSPDB90DLL Version when I try to do a .bat ML and LINK. I have been unamle to link anything.

Dave.

[Ryan]

Do you use the "Visual Studio Command Prompt"?

The linker error might be related to an incomplete path.

http://social.msdn.microsoft.com/Forums/en-US/Vsexpressinstall/thread/2a3c57c5-de79-43e6-9769-35043f732d68/

[jj2007]

Google for LNK1101. There is no easy solution other than using the old 6.14 linker that comes with Masm32.

My version is C:\...\Microsoft Visual Studio 9.0\Common7\IDE\mspdb80.dll, 193024 bytes of 7 Nov 2007 - and it doesn't work :(

[KeepingRealBusy]

Ryan,

You were right.

After much thrashing around and several boots, I managed to get LINK from Visual Studio 2008 (MASM 9.0) to execute and I am left with one linking error.

Assembling: dbgfiles.asm
dbgdebug.obj : error LNK2019: unresolved external symbol _SetConsoleMaximumWindowSize@8 referenced i
n function _SetConsoleMaximumWindowSizes@8
dbgfiles.exe : fatal error LNK1120: 1 unresolved externals

I had talked to MS Documentation Support years ago about the lack of documentation for this API in the MSDN documentation, and they researched it and said that the API was unsupported and would go away some time in the future. That time, I guess, is now. I will have to delete the usage of this and re-assemble dbgdebug.asm and then assemble all of the rest of my .asm modules that depend on it.

One thing I found about BCDEdit, it will change the store and subsequent  calls to BCDEdit would show the changed value, but if you brought up another CMD window and tried to use the new setting, it was missing. Just like AUTOEXEC.BAT, you need to boot the system so that this new path is used for all subsequent CMD windows. It also helps if you spell the path name correctly (I accidentally used "Program File(x86)" instead of "Program Files (x86)"

Dave