.MAP & .EXP files - Any better explanations than whats in the help docs?

So hit this problem last year but need to revisit it which is getting #RunDll to call a procedure in a clarion app generated dll.

Got the an app file compiled to a single dll which worked with #RunDll but then no further clarion app dll’s would work! Spent a load of time on it and got no where so left it for another time.

In libmaker there is a lot of extra procedures/functions built into a clarion app generated dll but as #RunDll just does not seem to want to work at all and I really want to get this #RunDll facility to work, I’ve gone the route of producing a single clw which can be compiled through the project system.

So done a simple single clw got it compiled and it works as an exe, now trying to get it to work as a DLL and this is where it fails. I can see the exported procedure in the dll using Libmaker, but as this is supposed to be a standalone dll I’m thinking I might need to link in other clarion functions into the dll?

I havent tried this yet. windows - How do I execute a *.dll file - Stack Overflow

I also wrote a single procedure template that just generates a single file clw for quick code/bug proving rather than use the project system. The #Restrict prevents any further procedures from being added.

Found these posts on the subject of #RunDll
7.1 preliminary release notes - ide / Releases - ClarionHub

FEATURE: new attribute “PASCAL” value for #RUNDLL. The WIN32 attribute is deprecated (its ignored if present) and is replaced with the new attribute “PASCAL”. If parameter string is passed to a function invoked by #RUNDLL with the PASCAL attribute, its address only is passed, i.e. *CSTRING,RAW rather than *CSTRING for #RUNDLL without the PASCAL attribute. If called function is changing value of passed string new value cannot exceed 10000 characters including terminating ‘<0>’.

CHANGE: AppGen now returns a better error message when a fully pathed exe is passed to #RUN or a fully pathed dll is passed to #RUNDLL and the file does not exist

I can see the .map file brings in some of the procedures/functions of clarion dlls into the exe to make it a standalone exe and I can see the addresses for various procs/func and see the entry point for IEXE32_TEXT.

Some of the directives like Code and Data in the .map file I think I read somewhere are OS/2 related which is why they are ignored.

I’ve also been able to find the template code which builds the .exp file
%(LINKNAME(%Procedure & %Prototype))
so I can produce my own working .exp file.

I found this post.
What does CUI mean in the export file? - ide / docs - ClarionHub

.map STACKSIZE doesnt seem to be recognised, but I think the %Rebase template seems to handle that by changing the procedure entry point addresses, although I dont know how that currently works with Windows ASLR moving these around on the fly, maybe windows creates a separate list of entry point addresses thats its moved stuff to, to reduce the chance of scanning known locations.

Any ideas what the stuff in the middle column of .map file means?
2D Code
B Code
2F Code
3C Initialized Data
8 __T_L_S__DAT
0 __T_L_S__DATA_END
0 __T_L_S__BS
0 __T_L_S__BSS_END

I’m guessing the BS and BSS End might mean something like Block Stack, which is something referenced in Siemens programmable controls, but I’m guessing here?

So is there any more info around for the .exp and .map files, or is time to dig out the pctools hex editor?

Edit

The RunDll32 looks alot like #Rundll to run a proc/function from a dll

Interesting article on dll security mentioned here DLL Hijacking | Best Practices to Prevent a Known Weakness of MS-OS (archive.org)

SANS Digital Forensics and Incident Response Blog | Detecting DLL Hijacking on Windows | SANS Institute

Releases · adamkramer/dll_hijack_detect · GitHub