DLL import problem (split topic)

[Yuri]

This topic was split from GoAsm and "side by side assembly" - Donkey

However, there is a problem with this when using GoAsm, it requires that all imports are done directly from the DLL and it hasn't read the manifest ! So to get around this you have to copy the DLL from the folder and paste it into your project folder.

Maybe this is what happened just yesterday and forced me to recognize there is some problem. A program that I had built under Windows 7 failed to launch on Windows XP, because the entry point of a kernel32 function was not found. After I rebuilt the program, it could run. However, now I am on W7 and the program is running without complaints about kernel32. So now I'm uncertain about what it was.

If we have to find and copy all needed DLL's in the project folder, does it mean that the LINKFILES define should be abandoned? Because it might link to some DLL behind the scenes and leave us unaware of that.

[donkey]

LINKFILES only specifies the DLL in which to find the function you explicitly use in your code, any other linking was done when the DLL you are calling was built and there is no way that either the headers nor GoAsm can control that nor should it affect the run of your program if the original (root) function was present on both machines. Also, if the header has DLLs specified that are not used they are not added to the PE by GoAsm, they are only search hints after all. So, there is no behind the scenes linking of any DLL's either by the header project or GoAsm.

[Yuri]

I meant that with LINKFILES I don't have to know in what system  DLL is the function I am using in my code. As a result —> I may not know that I am using that DLL —> I don't copy it to the project folder —> and my program gets linked to the one residing in System32. This didn't bother me before, so I left it behind the scenes. But now I see that I have to track down every used DLL and ensure that its correct version lies in the project folder.

[donkey]

Hi Yuri,

Yes, but I don't see how that can be helped by GoAsm, it is after all a versioning problem and would exist no matter what language or assembler you were using, in some cases such as MASM32 it would be more prone to this problem since it does no versioning at all. I could go through the API and lock those functions that are not available to a particular OS but that would be a huge task and impossible to automate. For example it is possible to use the following:

#IF WINVER <= NTDDI_WINXP
    #DEFINE GetFileInformationByHandleEx GetFileInformationByHandleEx_NotAvailable
#ENDIF

That would result in the following error message when you try to assemble it.

Error!
The following symbol was not defined in the object file or files:-
GetFileInformationByHandleEx_NotAvailable
Output file not made

But as I said it would be a huge rewrite, not something I am particularly inclined to do right now. Though I can search the web and see if I can find a list of functions exported by name for each version of Shell32, Kernel32, User32 and maybe Gdi32 and work on at least ensuring that those are trapped, that should keep the list below 2000 or so. Do you think this would be an adequate solution to your problem ?

Edgar

[BlackVortex]

That's a crapload of work, don't burn yourself out on this   :dazzled:

[donkey]

That's a crapload of work, don't burn yourself out on this   :dazzled:

Can't be done anyway, a quick search and I didn't find any fast way to do it. I won't crawl through the docs at MSDN to check each function so it'll have to be done the old way, read the docs and make sure the function is available for your minimum target OS. Though if somebody wants to tackle it Geoff Chappel is a good place to start.

[Yuri]

Do you think this would be an adequate solution to your problem ?

Surely not, regarding the amount of work. My initial post wasn't a feature request but just a question. After reading your info about manifests and recalling what happened yesterday, I realized that using LINKFILES the way I was used to could get me into trouble, that's all.

I thought that it might be better to go back to listing all the DLL's in a GoLink command file as I did earlier. Thus I will know for sure what I am using.

[donkey]

Hi Yuri,

After thinking about it I have decided to do it for some files as they are problematic when dealing with multiple versions, especially kernel32.dll which has hundreds of exports and the versions vary widely. Since I already have the exports sorted by DLL version for Kernel32, shwapi, shell32, and comctl32 I will do those files, user32 is way too big. My current idea is for a versions.h file and a switch (CHECKAPI or some such) that will generate an error when you attempt to use a function that is not available on the versions you specify (or are defaulted to by WINVER). Should be ready in a couple of days...

Edgar

[Yuri]

Only if it's your own intention. Remember that I haven't asked for that, I was just discussing the topic. The incident with my program was not about a DLL lacking a function. The function (RegQueryValueExW if I recall right) is present on both systems. However, there was a complaint about its entry point not found on XP. I simply recompiled the program and it ran. I just wondered whether or not this could be related to the version problem. My knowledge of how imports work is very vague, so I may be talking nonsense, of course.

[Yuri]

Ah, I see what's wrong. On W7, that function is exported by both kernel32 and advapi32, while on XP only by the latter. That's why I didn't have to rebuild the program back under W7.

[donkey]

Hi Yuri,

Well, I have been thinking about it since the project began and its something I wanted to do. For the DLL import issue you are having just put the following before Windows.h, it will tell GoAsm to search advapi32.dll for the import first:

#dynamiclinkfile advapi32.dll
#include windows.h

That should allow the program to run on both systems. I have a number of virtual machines all with GoAsm on them and tend to build on the platform I want it to run on then test on newer ones.

Edgar

[donkey]

Hi Yuri,

I have completed the api filters for shell32, comctl32 and shlwapi to test with. I have included the new file API_filter.h as well as a modified windows.h and windef.h, just replace the existing files in the headers folder. The changes to windows.h and windef.h are completely backward compatible so should have no affect on any other header files or projects. To activate api filtering use the following switch before including windows.h

#DEFINE FILTERAPI

Edgar

[Yuri]

Thanks, Edgar! I tested with several functions and yes, they were reported unavailable. Will keep on using it and see how it works.