Author Topic: polink compatability  (Read 11881 times)

KeepingRealBusy

  • Member
  • ***
  • Posts: 426
polink compatability
« on: August 04, 2012, 09:29:51 AM »
How compatable is polink to, lets say from MASM 9.0. LINK?

Dave.

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 6500
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: polink compatability
« Reply #1 on: August 06, 2012, 04:18:43 PM »
PoLink is usually more up to date than the current available Microsoft linkers.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

Vortex

  • Moderator
  • Member
  • *****
  • Posts: 1977
Re: polink compatability
« Reply #2 on: August 07, 2012, 04:32:43 AM »
Hi KeepingRealBusy,

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

KeepingRealBusy

  • Member
  • ***
  • Posts: 426
Re: polink compatability
« Reply #3 on: August 07, 2012, 07:51:37 AM »
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

  • Member
  • ***
  • Posts: 426
Re: polink compatability
« Reply #4 on: August 07, 2012, 09:29:00 AM »
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

  • Member
  • ***
  • Posts: 426
Re: polink compatability
« Reply #5 on: August 07, 2012, 12:59:37 PM »
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

  • Moderator
  • Member
  • *****
  • Posts: 1977
Re: polink compatability
« Reply #6 on: August 08, 2012, 03:30:58 AM »
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

  • Guest
Re: polink compatability
« Reply #7 on: August 08, 2012, 05:03:50 AM »

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]
.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

  • Member
  • ***
  • Posts: 426
Re: polink compatability
« Reply #8 on: August 08, 2012, 06:08:37 AM »
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

  • Member
  • ***
  • Posts: 426
Re: polink compatability
« Reply #9 on: August 08, 2012, 06:19:18 AM »
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

  • Member
  • ***
  • Posts: 426
Re: polink compatability
« Reply #10 on: August 08, 2012, 06:20:35 AM »
Japheth,

Is jwlink compatible with LINK?

Dave.

KeepingRealBusy

  • Member
  • ***
  • Posts: 426
Re: polink compatability
« Reply #11 on: August 08, 2012, 06:24:02 AM »
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

  • Guest
Re: polink compatability
« Reply #12 on: August 08, 2012, 06:35:37 AM »
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

  • Member
  • *****
  • Posts: 9589
  • Assembler is fun ;-)
    • MasmBasic
Re: polink compatability
« Reply #13 on: August 08, 2012, 06:46:25 AM »
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

  • Member
  • ***
  • Posts: 426
Re: polink compatability
« Reply #14 on: August 08, 2012, 08:35:48 AM »
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