Making dll in assembler in VS 2013 - c++

When I try to make a dll files i got error:
1>asselib.def : error LNK2001: unresolved external symbol MyProc
1>C:\Users\el bandito\Documents\Visual Studio 2013\Projects\testy\asselib\Debug\asselib.lib : fatal error LNK1120: 1 unresolved externals
How project looks like:
-I selected new project -> win32 project -> DLL, export symbols
-sourcefile -> add new item -> asselib.asm
.486
.model flat, stdcall
.code
MyProc proc x: DWORD, y: DWORD
ret
MyProc endp
end
-sourcefile -> add new item -> asselib.def
LIBRARY "asselib"
EXPORTS
MyProc
-project -> build customization -> masm
-project -> properties -> linker -> input -> Module Def File, asselib.def

I recall you have to explicitly declare the procedure as external.
PUBLIC MyProc
MyProc proc x: DWORD, y: DWORD
ret 8
MyProc endp
Also, the stdcall convention assumes callee cleans the stack. That means ret 8 instead of ret.

Related

Fix MASM 8086 Linker: error LNK2019: unresolved external symbol _putchar

I'm working in Microsoft Visual Studios 2017 with 32-bit 8086 MASM. This exact code worked for me before, but now for some reason it won't build anymore. Here is the error message I'm getting:
error LNK2019: unresolved external symbol _putchar referenced in function _main
error LNK2019: unresolved external symbol _exit referenced in function _main
fatal error LNK1120: 2 unresolved externals
I was seeing messages like this before, but they went away after I went to debug -> options -> symbols and then checked the box for "Microsoft Symbol Servers"
One thing that did change is that my internet connection keeps dropping out. Could that cause it to have trouble accessing the symbol servers?
If it's not the internet connection, I'm out of ideas. I've been all over this site and tried everything I can find.
.586
option casemap :none
.Model FLAT, C
.DATA
array DWORD 44h, 61h, 6Eh, 69h, 65h, 6Ch, 0 ;Array storing 'Daniel' in Ascii
.CODE
includelib MSVCRT
extrn putchar:near
extrn exit:near
main PROC
mov esi, 0 ;Set esi to 0
printChar:
mov eax, array[esi] ;Load the array value at index esi into eax
push eax ;Push the value in eax onto the stack
call putchar ;Print character
inc esi ;increment esi
mov eax, array[esi] ;eax was emptied when we pushed the contents onto the stack, so we need to refill it.
cmp eax, 0
je endProgram ;End program if eax equals 0
jmp printChar ;Otherwise, continue the loop
endProgram:
call exit
main ENDP
END

SuperBible 6th edition sb6_d32.lib not found?

I'm learning OpenGL using superbible 6th edition and while compiling this code:
#include <iostream>
#include "sb6.h"
class my_application : public sb6::application
{
public:
void render(double currentTime)
{
static const GLfloat red[] = { 1.0f,0.0f,0.0f,1.0f };
glClearBufferfv(GL_COLOR, 0, red);
}
};
DECLARE_MAIN(my_application);
I'm getting a linking errors saying cannot open sb6_d32.lib
I searched the entire sb6 directory there is no sb6_d32.lib file available for it to open so that i can link it? Am i missing something?
Edit: 2 Unresolved externals
Severity Code Description Project File Line Suppression State
Error LNK2019 unresolved external symbol _main referenced in function "int __cdecl invoke_main(void)" (?invoke_main##YAHXZ) OpenGL_learning E:\C++\Learning\OpenGL\OpenGL_learning\OpenGL_learning\MSVCRTD.lib(exe_main.obj) 1
Severity Code Description Project File Line Suppression State
Error LNK2019 unresolved external symbol __imp____iob_func referenced in function __glfwPlatformOpenWindow OpenGL_learning E:\C++\Learning\OpenGL\OpenGL_learning\OpenGL_learning\GLFW_d32.lib(win32_window.obj) 1
You have to build it first. See HOWTOBUILD.txt file in your examples folder root:
Windows / Microsoft Visual Studio 2010:
Project files are included in the source archive for Visual Studio
2010. These will work with Professional (all tiers) and Express editions. Newer versions of Visual Studio should import them just
fine, but this is not extensively tested. Simply open the sb6.sln file
in Visual Studio and hit build (F7). Evertything will build and you'll
end up with binaries in the 'bin' directory.
Update: Unresolved externals.
LNK2019 unresolved external symbol _main referenced in
function "int __cdecl invoke_main(void)" (?invoke_main##YAHXZ)
Lets see DECLARE_MAIN macro implementation in the sb6.h:
#if defined _WIN32
#define DECLARE_MAIN(a) \
sb6::application *app = 0; \
int CALLBACK WinMain(HINSTANCE hInstance, \
HINSTANCE hPrevInstance, \
LPSTR lpCmdLine, \
int nCmdShow) \
{ \
a *app = new a; \
app->run(app); \
delete app; \
return 0; \
}
If you want to use this macro, your program should be compiled as windows application (/SYBSYSTEM:WINDOWS), you are creating console application which is not supported. Change subsystem in your project settings (Linker/System).
LNK2019 unresolved external symbol __imp____iob_func
referenced in function __glfwPlatformOpenWindow
See this for the ways to solve that problem. In short you have to recompile all used static libraries with your version of Visual Studio.

Linking VS2010 with Assimp

I have been trying to get assimp working with VS2010. I have seen many questions similar to this but I just can't get it to work. Read the installation tutorials here http://assimp.sourceforge.net/lib_html/install.html and still can't get it to work.
This is what I did for VS2010 project setup:
All Configurations -> Configuration Properties -> VC++ Directories -> Library Directories ADDED
C:\assimp--3.0.1270-sdk\lib\assimp_release-dll_x64
All Configurations -> Configuration Properties -> VC++ Directories -> Include Directories ADDED
C:\assimp--3.0.1270-sdk\include
All Configurations -> Configuration Properties -> C++ -> General -> Additional Include Directories ADDED
C:\assimp--3.0.1270-sdk\include
All Configurations -> Configuration Properties -> Linker -> Input -> Additional Dependencies ADDED assimp.lib
When i write following code:
#include <assimp/Importer.hpp> // C++ importer interface
#include <assimp/scene.h> // Output data structure
#include <assimp/postprocess.h> // Post processing flags
Assimp::Importer importer;
This is the error I get:
Error 2 error LNK2019: unresolved external symbol "public: __thiscall Assimp::Importer::Importer(void)" (??0Importer#Assimp##QAE#XZ) referenced in function "void __cdecl `dynamic initializer for 'importer''(void)" (??__Eimporter##YAXXZ) C:\Users\Martin Liu\documents\visual studio 2010\Projects\MyGame\MyGame\Game.obj MyGame
Error 3 error LNK2019: unresolved external symbol "public: __thiscall Assimp::Importer::~Importer(void)" (??1Importer#Assimp##QAE#XZ) referenced in function "void __cdecl `dynamic atexit destructor for 'importer''(void)" (??__Fimporter##YAXXZ) C:\Users\Martin Liu\documents\visual studio 2010\Projects\MyGame\MyGame\Game.obj MyGame
Any help would be appreciated
Make sure your application's bitness matches your libraries' one. E.g. you can't link against x64 libraries if your project is 32 bit.
You can check this out by right-clicking in your project and choosing "properties" and then "Configuration Manager" button.

DLL LNK2019 error (unresolved external error __imp)

Well i basically inherited a bunch of code that i was told to fix because it used to work a few months ago but it doesn't at the moment. The program itself seems to be riddled with linking errors and i was able to fix some of them. However I have run across a LNK2019 unresolved external _imp error where some function utilized in the main is not resolved. due to the "_imp" i am assuming that it is a problem related to importing from .dll or .lib files.
First of all i have three .lib files which i believe am importing them correctly into VS2010 and i have configured the platform to be 64x. There is also .dll files that correspond with the .lib files. The .h file that contains the declaration for these error ridden functions contain something like
ILAPI void ILAPIENTRY ilDeleteImage(const ILuint Num);
unfortunately i would be guessing that the definition is defined in the .dll file which i did not write myself so i am unsure. But since this is code that worked before i believe that i am getting this error because the linker can't find the definition rather than def/decl not matching reason.
when i hover over the ILAPI it states: "ILAPI __declspec(dllimport)"
My current guess is that the program imports the .lib files and the .lib files use the .dll files to get the definition of the functions. I believe that i am importing the .lib files since the compiler no longer keeps on telling me that it can't find specific .lib files. However i am concerned that it may not be connecting the the .dll files. I am some what unsure. I have opened the .lib files and the .lib files contain the names of the functions that are giving errors. I have also used the dependency walker program to look at my DLL files and it has been giving me some of the following errors:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Based on other peoples comments i feel like i can ignore the 2nd error. But i am unsure of the first error. I am also unsure if that would be the root cause of the problem. It may or may not be.
I have also looked inside the .lib files using VS cmd and dependency walker and it seems like the names of the functions that can't be found are listed in one of the .lib and .dll.
In terms of configuration I am running on release mode x64 platform.
I have added "DevIL.lib ILU.lib ILUT.lib " library functions in the proj -> prop -> linker -> commandline. I have also added the path for linker -> general -> additional library directory. I have also tried messing with input additional dependency but it has no effect. The .lib and .dll files are put in the same directory as well. In the proj property configuration i do not mention .dll anywhere (am i supposed to? I've tried in various locations but just creates more error) I understand that there are a ton of posts regarding link 2019 error but i have not had good luck so far in my search for my particular problem. I would appreciate any suggestions, comment, or a link where i may find a clue as in to why this is occuring
here is the linker command from log:
here is the linker command from the build log itself:
Link:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\link.exe /ERRORREPORT:PROMPT /OUT:"x64\Release\dff.exe" /VERBOSE /INCREMENTAL /NOLOGO
/LIBPATH:C:\Users\Sub2\Desktop\dff\x64\Release /MANIFEST
/ManifestFile:"x64\Release\dff.exe.intermediate.manifest"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG
/PDB:"C:\Users\Sub2\Desktop\dff\x64\Release\dff.pdb"
/SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /TLBID:1 /DYNAMICBASE /NXCOMPAT
/IMPLIB:"x64\Release\dff.lib" /MACHINE:X64
x64\Release\dff.exe.embed.manifest.res
x64\Release\acquisition.obj
x64\Release\azmemutil.obj
x64\Release\dff.obj
x64\Release\fft.obj
x64\Release\FocusMeasure.obj
x64\Release\ge.obj
x64\Release\stdafx.obj DevIL.lib ILU.lib ILUT.lib
1>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' specification
// This is from Win32's <wingdi.h> and <winnt.h>
#if defined(__LCC__)
#define ILAPI __stdcall
#elif defined(_WIN32) //changed 20031221 to fix bug 840421
#ifdef IL_STATIC_LIB
#define ILAPI
#else
#ifdef _IL_BUILD_LIBRARY
#define ILAPI __declspec(dllexport)
#else
#define ILAPI __declspec(dllimport)
#endif
#endif
#elif __APPLE__
#define ILAPI extern
#else
#define ILAPI
#endif
Also:
#define ILAPIENTRY __stdcall
build log info when it gets close to error:
Found KERNEL32_NULL_THUNK_DATA
Referenced in kernel32.lib(KERNEL32.dll)
Loaded kernel32.lib(KERNEL32.dll)
Searching C:\Users\Sub2\Desktop\dff\x64\Release\DevIL.lib:
Searching C:\Users\Sub2\Desktop\dff\x64\Release\ILU.lib:
Searching C:\Users\Sub2\Desktop\dff\x64\Release\ILUT.lib:
Searching C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64\MSVCRT.lib:
Searching C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64\OLDNAMES.lib:
Searching C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64\msvcprt.lib:
Finished searching libraries
Finished pass 1
Invoking CVTRES.EXE:
/machine:amd64
/verbose
/out:"C:\Users\Sub2\AppData\Local\Temp\lnk92ED.tmp"
/readonly
"x64\Release\dff.exe.embed.manifest.res"
Microsoft (R) Windows Resource To Object Converter Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
adding resource. type:MANIFEST, name:1, language:0x0409, flags:0x30, size:2
1>dff.obj : error LNK2019: unresolved external symbol __imp_iluGetImageInfo referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_iluImageParameter referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilDeleteImages referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilSaveImage referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_iluFlipImage referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_iluScale referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilTexImage referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilCopyPixels referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilGetError referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilLoadImage referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilBindImage referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilGenImages referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilInit referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilGetInteger referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilEnable referenced in function main
1>dff.obj : error LNK2019: unresolved external symbol __imp_ilOriginFunc referenced in function main
1>x64\Release\dff.exe : fatal error LNK1120: 16 unresolved externals
1>Done Building Project "C:\Users\Sub2\Desktop\dff\dff.vcxproj" (rebuild target(s)) -- FAILED.
Build FAILED.
Just in case i have also tried writing #define _IL_BUILD_LIBRARY but has no effect.
I'm adding an answer here to summarize a bit on the above comments, the probable root cause and finding a solution to the unresolved errors. I'll preface this by saying linkers tend to be dumb low level tools. If the symbols referenced in the object files don't match exactly with the library then the build process bails out with those unresolved errors. Therefore, the author of the dll library and clients using it will need to put in some effort to ensure the symbols agree.
Root Causes
Unresolved errors are usually caused by one of the follow:
Neither the project nor the libraries linked against implement the function for that symbol.
The libraries actually do implement the function but under a differing reference symbol.
The headers for the library aren't preprocessed or decorated correctly thereby causing #2.
The Hunt
Base on what the OP described the dll libraries linked against exposes a C API. It is unclear what calling convention is being followed by the library in question. The exported names in the dll contain plain undecorated function names suggesting a __cdecl convention. The provided corresponding headers, OTOH has a function like:
ILAPI void ILAPIENTRY ilDeleteImage(const ILuint Num);
which expands into this after preprocessing:
__declspec(dllimport) void __stdcall ilDeleteImage(const ILuint Num);
From this you can conclude three possible scenarios:
The unresolved functions follow a __cdecl convention and the provided headers are wrong.
The unresolved functions follow a __stdcall convention and the exported dll names are wrong.
The functions follow __stdcall but are undecorated to look like __cdecl in the dll. This suggest that a .def file might have been used to build the dll in question.
A Sad State of Affair
Unfortunately, the function call convention followed in a win32 dll is in a confusing state of affairs. There's nothing in the language standard, C or C++, that addresses this ABI issue. See my other answer here. The toolchain vendor is free to decorate the names however they like but typcially for __cdecl functions it's plain undecorated or with a prefixed leading _ underscore.
WinAPI functions you find, like in kernel32.dll user32.dll gdi32.dll etc. are also undecorated but yet follow __stdcall. However, MSVC itself decorates __stdcall with a trailing ampersand with total bytes of the parameters(eg. ilDeleteImage#4) thus contributing to the confusion. To override how LINK decorates the functions, you have to provide a .def file that specifies the new name alias. See here for more details.
Finding the Real Convention
Assuming you don't have access to the source used to build the dll, there are two approachs I can think of to identify the real convention used.
Create a minimal test application that calls into the dll functions as if it uses __cdecl and see if it crashes and burns. This is the easier more straightforward method and you don't have to understand assembly to do it.
Second approach, you do the same but insert assembly breakpoints into your test application and run it through the debugger doing single step instructions. Make sure to choose a dll function taking at least one parameter. For example:
// pullin dll headers
// etc..
int main()
{
__asm int 3;
ilDeleteImage(0xdecafbad);
}
This will break and give control back to the debugger right before the dll function call. From here single step at the assembly level until you reach ilDeleteImage's function prologue.
; function prologue
push ebp
mov ebp, esp
; function implemention
; more opcodes here
; ...
; function epilogue
mov esp, ebp
pop ebp
ret 0x8
Check what form of ret is being used on function return. The number argument following the ret mnemonic indicates how much to increment the esp stack pointer. Any number >0 suggestes a __stdcall function. The hypothical disassembly above shows a __stdcall function freeing 8 bytes on the stack which also hints that this function takes 2 arguments.
I had this compile error while building a project using external static libraries, QDBM and PCRE:
_main.obj : error LNK2001: unresolved external symbol __imp__dpversion
_main.obj : error LNK2001: unresolved external symbol __imp__regcomp
I had correctly configured these external projects to build static libraries, but I had forgotten to define the correct preprocessor defines in my own code, which used these libraries, to enable static linking.
So when they imported the headers from QDBM and PCRE, they added a __declspec(dllimport) that shouldn't be there (for static linking), so they were trying to import symbols from DLLs that didn't exist.
I added the missing preprocessor defines to my build system, which fixed the error:
-DQDBM_STATIC -DPCRE_STATIC
Which meant adding the following lines to my CMakeLists.txt file:
# Tell QDBM not to build itself as a DLL, because we want to link statically to it.
target_compile_definitions(qdbm PUBLIC -DQDBM_STATIC)
target_compile_definitions(lib_common PUBLIC -DPCRE_STATIC)

visual programming

sir i have written a simple program to display a message box in visual c++ 2008 but the problem is that when i run this code a dialog box shows that "your project is out of date would you like to build it"
when i press yes it shows error
so what is the problem???
the code is here
#include <Windows.h> /* The standard "windows.h" inclusion */
int WINAPI WinMain( HINSTANCE hInstance, /* A handle to the current instance of the application. */
HINSTANCE hPrevInstance, /* A handle to the previous instance of the application. */
LPSTR lpCmdLine, /* The command line for the application, excluding the program name. */
int nCmdShow) /* Controls how the window is to be shown. */
{
/* Call to the MessageBox function */
MessageBox(NULL, "Hello, Windows API!", "Hello", MB_OK);
/* WinMain returns 0 if we exit before we enter message loop, more on that to come */
return 0;
}
Whenever i run this in visuall c++ 2008 it says project out of date, do u want to build so i click yes but then it cant
down the bottom it says
1>Linking...
1>MSVCRTD.lib(crtexe.obj) : error LNK2001: unresolved external symbol _main
1>C:\Documents and Settings**\My Documents\Visual Studio 2008\Projects\msg\Debug\msg.exe : fatal error LNK1120: 1 unresolved externals
1>Build log was saved at "file://c:\Documents and Settings**\My Documents\Visual Studio 2008\Projects\msg\msg\Debug\BuildLog.htm"
1>Wrath Lands - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
VS creates UNICODE projects by default so macros like MessageBox evaluates to MessageBoxW which expects LPCWSTR arguments and not LPCSTR. Try change to: MessageBox(NULL, _T("Hello, Windows API!"), _T("Hello"), MB_OK);
The error message error LNK2001: unresolved external symbol _main is important. It looks like you've created a console project but there is no main() function defined, hence the linker error.
When you create a new Visual Studio project as a Win32 Console Application it assumes the entry point to your program will be the normal C/C++ main() function and it links with the C/C++ library startup code. If you instead create a Win32 Project it assumes the entry point will be WinMain() and links with Windows application startup code.
To avoid this problem you should begin with a Win32 Project. To fix it after the fact you could try going into Project Properties -> Linker -> System and change the SubSystem option from Console (/SUBSYSTEM:CONSOLE) to Windows (/SUBSYSTEM:WINDOWS). Note that there may be other settings that should be changed as well so I suggest you just start fresh with a new Win32 Project instead.