Why does an ANY data type in API call StringFromGuid2() not give me a fixed GUID?

[CarlBarnes]

@anon77170705

The compiler and the linker can produce the correct thunking code to call Functions from External DLLs regardless presence of the DLL attribute in the prototype. The difference between presence of the DLL(1) and the absence of the DLL attribute is how corresponding thunking code is organized.

You would certain know more than I would on what happens in the compiled code. I agree with what you said. An External Function works with or without the DLL(1). I’m asking is with DLL(1) better?

My understanding is DLL(1) is like Microsoft __declspec(dllimport). Is Clarion DLL(1) different?

A number of web sources say it is best to specify dllimport / DLL(1) on External Functions then the Compiler can write the best code. Without DLL(1) the Linker has to fix it by adding a thunk stub which means extra code each call. And the little extra thunk code in the DLL.

---

Import into an application using __declspec(dllimport)

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

---

Index to the series on DLL imports and exports

Calling an imported function, the naive way … without __declspec(dllimport) … The compiler would generate a normal call instruction, leaving the linker to resolve the external. The linker then sees that the external is really an imported function, and, uh-oh, the direct call needs to be converted to an indirect call. But the linker can’t rewrite the code generated by the compiler. What’s a linker to do? The solution is to insert another level of indirection.

How a less naive compiler calls an imported function If a function is declared with the dllimport declaration specifier (Clarion DLL(1)), this instructs the C/C++ compiler that the function in question is an imported function rather than a normal function with external linkage. With this additional information, the compiler generates slightly different code when it needs to reference an imported function, since the compiler is aware of the special way imported functions are implemented. First, there is no need for the stub function any more, because the compiler can generate the special call instruction inline.

---

@anon77170705

If the function has the DLL attribute in the prototype, incorrect parameter of DLL (0 if function is in some DLL and 1 if library with function is to be linked locally) can cause GPF on attempt to call this function at run time.

Its good to know the Clarion Compiler will not fix a wrong DLL(1). I don’t think I’ve ever had the problem. Ray Chen in What happens when you get dllimport wrong? … I think … says the VS C/C++ Compiler will fix that problem by creating a Fake Import but it sounds like a big mess.

---

Note that DLL(1) is mandatory on Data declared that is in an External DLL. The same for Microsoft:

However, you must use __declspec(dllimport) for the importing executable to access the DLL’s public data symbols and objects.