May be I'm a bit to old, to understand, but here is my question: I've 3 *.obj files, which I've to link against msvcrt.dll. The assembler ml64 did his job, by the way uasm64, too. But I've the impression
it's more and more a compiler, not an assembler. So, anyway. Now comes the linker.
With that command line generates golink an EXE-file which makes what it has to do: golink /console /fo ex1.exe /entry main main.obj asmio.obj ex1.obj msvcrt.dll
That's the otput:
GoLink.Exe Version 1.0.3.1 Copyright Jeremy Gordon 2002-2020 info@goprog.com
Output file: ex1.exe
Format: X64 Size: 7,168 bytes
Now the same with MS link: \masm32\bin64\link.exe /OUT:ex1.exe /SUBSYSTEM:CONSOLE /MACHINE:X64 /ENTRY:main /nologo /LARGEADDRESSAWARE main.obj asmio.obj ex1.obj msvcrt.dll
That's the output:
LINK : fatal error LNK1181: cannot open input file 'msvcrt.dll'
That is a bit strange, because msvcrt.dll is inside the bin64 directory and golink can find it. What's wrong here?
Gunther
Quote from: Gunther on January 28, 2021, 07:38:24 PM
May be I'm a bit to old, to understand, but here is my question: I've 3 *.obj files, which I've to link against msvcrt.dll. The assembler ml64 did his job, by the way uasm64, too. But I've the impression
it's more and more a compiler, not an assembler. So, anyway. Now comes the linker.
With that command line generates golink an EXE-file which makes what it has to do: golink /console /fo ex1.exe /entry main main.obj asmio.obj ex1.obj msvcrt.dll
That's the otput:
GoLink.Exe Version 1.0.3.1 Copyright Jeremy Gordon 2002-2020 info@goprog.com
Output file: ex1.exe
Format: X64 Size: 7,168 bytes
Now the same with MS link: \masm32\bin64\link.exe /OUT:ex1.exe /SUBSYSTEM:CONSOLE /MACHINE:X64 /ENTRY:main /nologo /LARGEADDRESSAWARE main.obj asmio.obj ex1.obj msvcrt.dll
That's the output:
LINK : fatal error LNK1181: cannot open input file 'msvcrt.dll'
That is a bit strange, because msvcrt.dll is inside the bin64 directory and golink can find it. What's wrong here?
Gunther
Hi Gunther,
I think it's because you should link against msvcrt.lib instead of the dll. I have never linked a program against a dll. On Windows, for every DLL, there is a LIB file. DLL files are for the loader stage and lib files are for the linker stage. I don't know why it worked with golink because I don't know that linker, but on Windows, I don't think it's possible to link against dll files.
Have a nice day!
Guille
Link is more and more demanding with the versions of the libraries.
Try to use only one windows sdk and it's standard libraries, don't use the standard (kernel32.lib,....) libraries provided with masm32 or masm64.
The msvcrt.lib provided by masm32 or 64 could also don't search the good libraries or dll
Best results are given by the use of the link and the libraries of the same sdk windows.
The best way to solve the problems and know what is it,is to use /VERBOSE of link.
You wil have the full list of what is searched by link.
Gunther,
The libraries to use are the ones provided. I don't know much about Jeremy Gordon's GoLink but I know that it does something differently when it accesses a DLL directly to get the function address in the DLL.
The include file for msvcrt uses this format.
externdef __imp__setsystime:PPROC
vc__setsystime equ <__imp__setsystime>
and the function name that you call is,
vc__setsystime
The matching library is msvcrt.lib.
As both of these files are included in the masm64rt.inc file, all you need to do is call the "vc__setsystime". The "vc_" prefix is to prevent name clashes with MASM reserve words.
Guille,
Quote
I think it's because you should link against msvcrt.lib instead of the dll. I have never linked a program against a dll. On Windows, for every DLL, there is a LIB file. DLL files are for the loader stage and lib files are for the linker stage.
That was my first approach, too. But it came:
LINK : fatal error LNK1181: cannot open input file 'msvcrt.lib'So, that doesn't help.
Gunther
Steve,
thank you for your hint. Works fine now with the vc prefix.
Gunther
Hi DebugBSD,
QuoteI don't know why it worked with golink because I don't know that linker, but on Windows, I don't think it's possible to link against dll files.
GoLink links against DLLs and it does not use import libraries.
Erol,
Quote from: Vortex on January 29, 2021, 03:45:52 AM
GoLink links against DLLs and it does not use import libraries.
yes of course, see my first post. I hope, you're doing well.
Gunther
That's only for information purposes. My question about the linker problem is solved.
I have experimented a bit and made some remarkable observations. Both MS link and GoLink work very well.
However, the resulting EXE with GoLink is about 40% smaller. This surprises me a bit. Of course this is nothing
compared to the usual binary clumps produced by compilers.
Gunther
Without knowledge of libraries what are linked , executable can be bloated.
With several compilers is also possible to make small programs, if someone knows what they are doing. Runtime libraries are usually big.
I use C compilers, so i know something about those.
Gunther,
The 64 bit linker from Pelle's C also works very well with 64 bit MASM. It builds slightly smaller, about 1 section and is typical with Pelle's tools, its very up to date. Occasionally one of the crapheap AV scanners produce a false positive on an exe built with Pelle's linker but it no fault of Pelle's linker.
Quote from: TimoVJL on January 29, 2021, 01:51:42 PM
Without knowledge of libraries what are linked , executable can be bloated.
It's the usual VC run time library (msvcrt.lib); nothing special.
Quote from: TimoVJL on January 29, 2021, 01:51:42 PM
Runtime libraries are usually big.
Not necessarily. The msvcrt.lib has a size of 131 KB; that's not so large.
Quote from: TimoVJL on January 29, 2021, 01:51:42 PM
I use C compilers, so i know something about those.
I'm using several C compilers, too. Thanks for your reply and the thoughts you put into it.
Gunther
Steve,
Quote from: hutch-- on January 29, 2021, 02:07:09 PM
The 64 bit linker from Pelle's C also works very well with 64 bit MASM. It builds slightly smaller, about 1 section and is typical with Pelle's tools, its very up to date. Occasionally one of the crapheap AV scanners produce a false positive on an exe built with Pelle's linker but it no fault of Pelle's linker.
Yes, PoLink. I'll try it. It's always good to have multiple options. And yes, those rotten virus scanners ... It's a long, sad story.
Gunther
masm32 msvcrt.lib is for msvcrt.dll and that is a good thing, as msvcrt is part of Windows NT OS.
masm32 msvcrt.lib don't add additional stuff, but from Visual C++ can, as it has also a static functions for main, wmain, etc....
MS link have an option -nocoffgrpinfo to use.
a map-file gives info of linking, so use -map
Timo,
Quote from: TimoVJL on January 29, 2021, 02:14:57 PM
masm32 msvcrt.lib is for msvcrt.dll and that is a good thing, as msvcrt is part of Windows NT OS.
masm32 msvcrt.lib don't add additional stuff, but from Visual C++ can, as it has also a static functions for main, wmain, etc....
I know. We had a lot discussion over the years about the run time library, especially the point, that it is not so easy to print REAL10 numbers in the windows world. You can check the discussion for example here (http://www.masmforum.com/board/index.php?topic=14790.0) or here (http://masm32.com/board/index.php?topic=3915.msg41176#msg41176) or with interesting results here (http://masm32.com/board/index.php?topic=1767.msg17933#msg17933).
You could in the last link inspect the source of LongC64.zip. As you can see, I can tell you a lot about the run time library, because I'm deeply immersed in this issue.
Gunther
long double is compiler specific, so not supported widely.
https://en.m.wikipedia.org/wiki/Long_double
If you need higher precision that the default 64 bit in Win64 via SSE2, you can still use the old x87 80 bit FP code and as MMX is now redundant being surpassed by SSE, you don't have to mess around with preserving MMX registers as they don't normally get used.
I gather there are specialised libraries for very large numbers but I don't really know much about them.
Timo,
Quote from: TimoVJL on January 29, 2021, 03:16:45 PM
long double is compiler specific, so not supported widely.
https://en.m.wikipedia.org/wiki/Long_double
did you check the source and the running EXE in the ZIP archive LongC64.zip? If not, please make the effort. You can find it here (http://masm32.com/board/index.php?topic=1767.msg17933#msg17933) under the first post.
Gunther
Quote from: hutch-- on January 29, 2021, 03:22:49 PM
If you need higher precision that the default 64 bit in Win64 via SSE2, you can still use the old x87 80 bit FP code and as MMX is now redundant being surpassed by SSE, you don't have to mess around with preserving MMX registers as they don't normally get used.
I gather there are specialised libraries for very large numbers but I don't really know much about them.
Sure. We have discussed this at length over the years.
Gunther
Hi Gunther,
Nice to see you back here in the forum. Thanks, I am doing fine.
Erol,
Quote from: Vortex on January 29, 2021, 07:47:06 PM
Nice to see you back here in the forum. Thanks, I am doing fine.
You're welcome. I feel a bit rusty, but it works.
Gunther