How to declare functions in a header file that are defined in a DLL

You posted this under "Best Practices".

Well the "best practice" is, by hook or by crook, get the actual documentation for the DLL.

As mentioned already, it makes absolutely no sense to use a DLL and not know what the functions are, what they do, what parameters to pass, etc. I would say it's even dangerous to use a DLL blindly like this. For example, what if those functions alter the file system or registry in some way, and you had no idea this is what was being done?

If all you have is the DLL, how will you know how to use it? How will you know which functions to call? How will you know what they do? How will you know what arguments to pass them? How will you know what they return? Any library needs to come with documentation. And it should also come with a header file to declare its functions. How are you in a situation where you have a DLL but no documentation or header?

@XJDHDR you said "I only have the DLL itself, no headers, SDK or anything like that", which implies you also don't have any documentation explaining the nature of the DLL functions or how they were declared when the DLL was compiled. To call a DLL function at compile time, you MUST know how it was originally declared, either in an existing header file, or from adaquate documentation to write such a header file. Preferably that info should come from the DLL author, otherwise you need to obtain it from other sources. YOU CANNOT reliably use a DLL that you know nothing about.

@XJDHDR "There's this little thing called "reverse engineering" that gives you all of that info." - sure, if you have the skills needed to pull that off. Which you clearly do not, and you did not ask about that in your question. To accomplish what you want, you would need to disassemble the DLL to extract its raw machine code, and then analyze that machine code to translate it into something that works in the context of the language you are coding in. Do you know how to read assembly code for multiple cpu platforms? Or how cpu registers and call stacks work? Or how calling conventions work in the cpu? Teaching reverse engineering skills is beyond the scope of Stack Overflow. There is a whole other Reverse Engineering StackExchange site, and entire books, on this topic.

@XJDHDR "The question is about how to declare DLL functions, not how to figure out what a function does." You can't declare a DLL function if you don't know what its original signature was when the DLL was compiled. If you need to reverse engineer that knowledge, knock yourself out. You will have to do it by hand, there are no tools to do it 100% automatically for you. But tools like IDA can get you close. If a function has a simple signature, it probably won't take you very long to figure it out. But if the signature is more complex then it's going to take a lot of work to figure things out. Sometimes that requires figuring out what the function actually does in order to understand what parameters it takes in and what values it returns.

Can you explain what exactly you find low-quality or off-topic in the comments you mentioned ?
They seem quite relevant to me.

If you're so 'shocked' by a comment then please reply to it directly instead of posting empty, pointless gripes.

A canonical way to declare dll-imported symbols is to use declspec(dllimport). https://learn.microsoft.com/en-us/cpp/build/importing-into-an-application-using-declspec-dllimport says:

Using declspec(dllimport) is optional on function declarations, but the compiler produces more efficient code if you use this keyword

Use case of dllimport in VisualStudio explains why is using that declspec makes code more efficient. Altough likely that is no longer the case with modern compilers compiling in LTO mode. So you should get optimal performance when doing a release build with or without declspec.

A long time ago, when I was using Borland C++ 5.5, there was an utility called "implib.exe" that was able to produce the .lib corresponding to a dll. Maybe you can find this utiility sonewhere on the net. Here is the doc : https://docwiki.embarcadero.com/RADStudio/Athens/en/IMPLIB.EXE,theImportLibraryToolforWin32

How do you know that I (and by extension anyone else who has this same question) don't know any of those things? I don't recall saying anything along those lines.

Also, please re-read the question. The question is about how to declare DLL functions, not how to identify them.

Don't have an answer. Just wanted to say that I'm shocked at the low-quality off-topic comments that many people posted on your question. Especially by Remy Lebeau. I had to double-check that I didn't accidentally visit Reddit.

I wish that I could do more than downvote.

There's this little thing called "reverse engineering" that gives you all of that info.

Please re-read my question. The question is about how to declare DLL functions, not how to figure out what a function does.

Also, even if we assume that I don't know any of this. What about the other people who might read this because they have a similar question and do know those things? Do they not deserve an answer?

Why? This question is relevant for both languages.

My current problem is that I only have the DLL itself, no headers

If you had stopped right there, then the comments concerning how you will know what these functions actually do and the parameters to pass would more than likely had never occurred.

It is this: SDK or anything like that

that started the ball rolling to a place that you more than likely didn't expect.

If you had documentation, then creating function definitions from what has been documented is straightforward. A four byte integer is int32t, an ANSI, modifiable character buffer is a char *, an unmodifiable one is const char *, wide character is wchart*, etc.

The documentation would have also stated whether the function is stdcall, cdecl or some other calling convention, etc.

stdcall int FriendlyName1(int arg1, int arg2);

Assuming 1) you have no documentation or 2) you have no sample usage of the DLL's functions, if the DLL is 32-bit, what if arg1 and arg2 are to be treated as pointer values and not just plain integers? Or what if it is an 8-byte integer and not two 4-byte integers?

Don't tag both C and C++. Pick one that you actually use.

The programming languages are very distinct and answers will be distinct. Read the tag wiki c and c++.

Ah, Borland C++ 5.5. Better, simpler times!

Please explain how anything in Andrey Turkin's answer changes based on whether it's C or C++.

Which you clearly do not,

Irrational Ipse Dixit fallacy: You have no evidence whatsoever proving this. None! Nada! Zilch! in fact...

Straw Man fallacy: What you are preaching is objectively wrong, as you would have known if you had done some fact-checking beforehand.

and you did not ask about that in your question.

Well duh! I didn't ask about it because it has nothing to do with my question. As I've already pointed out.

Teaching reverse engineering skills is beyond the scope of Stack Overflow.

Moving the Goalposts: I challenge you to quote the exact part of my question where I asked anyone to teach me reverse engineering, or even mentioned it. You won't be able to, as you yourself already admitted above.

Here's a pro-tip in future: Scroll up and read Andrey Turkin's reply. That is an example of what you people should have posted. Not the off-topic nonsense that people like you have polluted this question with.

On top of more off-topic nonsense, this again is why it's important to do some fact-checking before you start making claims. Everything you're trying to "teach" me about reverse engineering is what I already know.