The MASM Forum

Projects => Poasm => Pelle's C compiler and tools => Topic started by: KeepingRealBusy on August 04, 2012, 09:29:51 AM

Title: polink compatability
Post by: KeepingRealBusy on August 04, 2012, 09:29:51 AM
How compatable is polink to, lets say from MASM 9.0. LINK?

Dave.
Title: Re: polink compatability
Post by: hutch-- on August 06, 2012, 04:18:43 PM
PoLink is usually more up to date than the current available Microsoft linkers.
Title: Re: polink compatability
Post by: Vortex 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
Title: Re: polink compatability
Post by: KeepingRealBusy 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.
Title: Re: polink compatability
Post by: KeepingRealBusy on August 07, 2012, 09:29:00 AM
Quote from: Vortex 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

Vortex,

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

Dave
Title: Re: polink compatability
Post by: KeepingRealBusy on August 07, 2012, 12:59:37 PM
Quote from: Vortex on August 07, 2012, 04:32:43 AM
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.
Title: Re: polink compatability
Post by: Vortex 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?
Title: Re: polink compatability
Post by: japheth 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
.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.
Title: Re: polink compatability
Post by: KeepingRealBusy 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.
Title: Re: polink compatability
Post by: KeepingRealBusy 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.
Title: Re: polink compatability
Post by: KeepingRealBusy on August 08, 2012, 06:20:35 AM
Japheth,

Is jwlink compatible with LINK?

Dave.
Title: Re: polink compatability
Post by: KeepingRealBusy on August 08, 2012, 06:24:02 AM
Quote from: Vortex 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?

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.
Title: Re: polink compatability
Post by: Ryan 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/ (http://social.msdn.microsoft.com/Forums/en-US/Vsexpressinstall/thread/2a3c57c5-de79-43e6-9769-35043f732d68/)
Title: Re: polink compatability
Post by: jj2007 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 :(
Title: Re: polink compatability
Post by: KeepingRealBusy 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
Title: Re: polink compatability
Post by: KeepingRealBusy on August 08, 2012, 08:53:52 AM
Quote from: jj2007 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 :(

JJ, my version from the Visual Studio 2008 is the same: 11/7/2007/ 9:AM 189 KB. Are you sure that the path is correct? Bring up a CMD prompt and type "path". You should see "C:\...\Microsoft Visual Studio 9.0\Common7\IDE\" in the path. The directory should be "Program Files" for XP, and "Program Files (x86)" for Windows 7

Dave
Title: Re: polink compatability
Post by: jj2007 on August 08, 2012, 09:24:15 AM
Actually, I don't use paths; instead, I copy the dlls into \masm32\bin - and right now I tested it again, and it works fine with various assembler/linker combinations ::)
Title: Re: polink compatability
Post by: KeepingRealBusy on August 08, 2012, 01:06:59 PM
jj,

You can do that with some entities, but not mspdb80.dll. I tried to do that by copying it to my tools directory and got the "wrong version". You must use the path for this one.

Dave.
Title: Re: polink compatability
Post by: jj2007 on August 08, 2012, 03:15:34 PM
Ok, thanks for the hint. Will try to remember it when the LNK1101 pops up the next time - right now I can't reproduce it. But I have seen it, dear friends from Redmond :icon_mrgreen:
Title: Re: polink compatability
Post by: KeepingRealBusy on August 09, 2012, 12:40:51 AM
JJ,

I searched for mspdb80.dll in the registry, not there. Then I searched for mspdb80.dll in explorer. I found two version, different sizes, in Visual Studio, apparently one is a 64 bit version and the other a 32 bit version, and guess which one is first - the wrong one.

When I execute I use a 32 bit .exe to kick off a 32 bit CMD window to execute the makeit.bat, so I have to have the 32 bit version.

Dave.
Title: Re: polink compatability
Post by: Ghandi on August 17, 2012, 04:30:22 AM
You can take the newer Link.exe and ancilliary files, put them into the MASM bin folder and use them just like older ML.exe/Link.exe.

The issues thrown about MSPDBxx.dll are caused when the copy is done incomplete, you need ALL of the files used. You can avoid this by not linking with debugging information but that is pointless, easier to just copy the right files the first time and be done with it.

I am currently preparing for work, otherwise i would compile a list of the files needed, i'm using ML.exe and Link.exe from Visual Studio 2010 so i can have a play with AVX code, not just relying on macros to insert bytes to accomplish it.

HR,
Ghandi
Title: Re: polink compatability
Post by: KeepingRealBusy on August 17, 2012, 07:58:35 AM
Ghandi,

Thank you for the reply. I will await your list.

I have ML and LINK working now, and have my PATH problem worked out. All seems to work correctly now, at least for 32 bit compiles. Now I need to dabble in 64 bit for a while. Wish me luck!

Many of my 32 bit executables (.exe's) I brought from my windows XP system will not run on Windows 7. I may have to go the route of a VM and install XP to really be satisfied.

Dave.