Link step is not finding WIN32API calls

This is bizarre, because Plato links fine in testing mode, but not in my link steps.

I decided to isolate my modified STDCALL for FindWindowA in the following manner:

	integer function find_window_new(abcd)
	STDCALL FINDWINDOW_static 'FindWindowA' (STRING,REF):INTEGER(7)
	character*(*):: abcd
	find_window_new = FINDWINDOW_static(abcd,core4(0))
	return
	end

However, after I compile and link (this link step has not changed in over a year), I get:

WARNING the following symbols are missing: (F:\CMASTERF95\RELEASE\WIN32\CFUNC\FIND_WINDOW_NEW.OBJ) FindWindowA f:\CMASTERF95\RELEASE\WIN32\C-MASTER.lib (/9775 ) (F:\CMASTERF95\RELEASE\WIN32\CFUNC\FIND_WINDOW_NEW.OBJ)

As a test, I put in a USE MSWIN into the code AND the standard FINDWINDOW() function call; still get that FindWindowA is an unresolved symbol. I also placed a different API call in this routine, then BOTH symbols were not found.

My compile parameters are the same for all modules. For my little routine, they are listed below.

Silverfrost FTN95/Win32 Ver 8.70.0 FIND_WINDOW_NEW.FOR Sun Dec 13 07:20:04 2020

Compiler used [C:\Program Files (x86)\Silverfrost\FTN95\FTN95.exe] Salflibc path [C:\Program Files (x86)\Silverfrost\FTN95\salflibc.dll] Salflibc version [22.11.17.16] Compiler options in effect: BINARY;CFPP;DUMP;ERROR_NUMBERS;FPP;HARDFAIL;IGNORE;IMPLICIT_NONE; LIST;NO_COMMENT;PERSIST;SAVE;UNLIMITED_ERRORS;WIDE_SOURCE;XREF;ZEROISE;

My link steps are all similar. Here are the parameters for my link. My little routine is in $(LIBRARY_CMASTER)

Salflibc path [C:\Program Files (x86)\Silverfrost\FTN95\salflibc.dll] Salflibc version [22.11.17.16] Compiler options in effect: BINARY;CFPP;DUMP;ERROR_NUMBERS;FPP;HARDFAIL;IGNORE;IMPLICIT_NONE; LIST;NO_COMMENT;PERSIST;SAVE;UNLIMITED_ERRORS;WIDE_SOURCE;XREF;ZEROISE;

My link steps are all similar. Here are the parameters for my link. My little routine is in $(LIBRARY_CMASTER)

[quote:eb3c6ed07a]$(LINKER) \((DESTINATION)\\CMAIN.obj cmain_resources.\)(SRC_EXTENT) $(DESTINATION)\CFUNC\GUSER.obj $(LIBRARY_CMASTER) $(PROJ4LIB) \((PDFSUPPORT) /file:\)(C_MASTER) -MAP:$(DESTINATION)\C-Master.MAP

I have never had to include any other system libraries in the link steps, so am befuddled by the failure to find this symbol.

In PLATO, whether I include this small routine with its small MAIN or separate it into a different compilation, it compiles, links, and runs just fine.

I also tried adding a findwindow() call in my main in an effort to make sure the symbol was found and loaded. In the link step, it still calls out that FindWindowA is missing in my small routine, not my main.

In digging deeper, it appears that my STDCALL creates a symbol reference that is just a bit different than it should need. Source followed by the external reference text part of the object file.

	integer function find_window_new(abcd)
	USE MSWIN
	STDCALL FW_STATIC 'FindWindowA' (STRING,REF):INTEGER(7)
	CHARACTER*(*):: ABCD
	FIND_WINDOW_NEW = FW_STATIC(ABCD,CORE4(0))
	RETURN
10	CONTINUE
	FIND_WINDOW_NEW = FINDWINDOW(ABCD,ABCD)
	END

_FIND_WINDOW_NEW _GET_CSTRING# _FindWindowA ___adjust_stack_f ___CONTROL_WORD _FindWindowA@8 _MAKE_CSTRING#

In looking at the Plato session that does not seem to have the problem, the symbol I suspected ('FindWindowA@8') is present in Plato, but NOT FindWindowA.

So, I am wondering why the STDCALL in my OTHER code generates a different (?) symbol name for the same function call?

The Plato file called 'Buildlog' will tell you what command line options have been used by Plato. The FTN95 command line option /LIST also has a list of options use. You can also use /ECHO_OPTIONS.

STDCALL only relates to 32 bits.

Referring back to the first post, the options for my compile are there, and below is what Plato is echoing.

[Current options] BINARY;CFPP;ERROR_NUMBERS;EXPLIST;FPP;LIST;NO_BANNER; SAVE;UNLIMITED_ERRORS;VS7;WIDE_SOURCE;

The only significant difference I can see is my standard compile does not include /VS7.

N.B. When I added this to the compile, I no longer got any output from the compiler (i.e. each routine listed as it was compiled).

Also, the symbol still cannot be found.

Bill,

Can you check the environment variables, especiallypath, that PLATO is using vs those for your batch (?) build. These would need to be checked at build time, not run time.

I am not totally familiar with the settings that PLATO use in the registry. I do have multiple versions of PLATO available and they can have different responses, which I have always assumed were due to different environment and registry (and possibly other?) settings.

John,

What is not making sense is why the STDCALL instance is generating different code than USE MSWIN. Might be the environment, but don't know what to look for. ALL the environment stuff looks fine. If Plato is using an option that I am not, it is unclear how to find it since I used the tools to get the options listed for both my compile steps as well as Plato.

If you can offer additional insights, please do so!

Bill

Bill

For 32 bits, the actual call is to FindWindowA@8 and this is for both

FINDWINDOW 'FindWindowA' (INSTRING,INSTRING)

and

FINDWINDOW 'FindWindowA' (STRING,REF)

because the number of bytes (which is 8) is the same either way.

For 64 bits, STDCALL does not apply, there is no decoration, and the actual call is to FindWindowA.

You can see the details by using /EXPLIST with FTN95 and /MAP with the linker.

Paul, I do see that, and thanks for the tips.

What I am not understanding is why, when I code the interface statement, I don't get the same function reference to FindWindowA@8 both with the USE MSWIN and my STDCALL. Something is being treated differently between the MOD file I am USEing and the STDCALL I'm trying to use.

In poking around further, it appears that any WIN32 API calls I 'modify' using STDCALL (even if it matches win32api.ins) all fail to compile with my build, while in Plato, they succeed.

I have examined the options looking for something that differs from the PLATO compile. I can find none.

All the STDCALL's I make to my own DLL seem to work just fine.

I am still at a loss to explain why the compiler (8.70) produces different results for the same input.

I find that I really need to be able to look for a class of window and close them all. This is when the program encounters an error and needs to terminate. And needs to close all open windows.

Unfortunately, since my FIND_WINDOW_NEW function cannot work (yet), I have to go to 'C'. Unfortunately, I am unclear as to how to specify a SYSTEM DLL as a link component from the command line using SLINK.

I tried adding the path to the system DLL USER32.dll that should contain FindWindowA, but no joy.

Bill

If you can send me some sample code then I will try to reproduce your problem.

Paul

Paul, the code I posted on 13 December has this problem, but not when I have the code in Plato with FTN95 V8.70. The problem manifests when I do a separate compile with FTN95 V8.70. Which baffles me.

My compile step (in my build) is:

FTN95.exe find_new_window.for /DUMP /UNLIMITED_ERRORS /no_comment /listfind_window_new.lis /ignore 242 /ignore 767 /ignore 520 /ignore 21 /ignore 179 /ignore 1031 /ignore 197 /ignore 1088 /IGNORE 1225 /ERROR_NUMBERS /persist /SAVE /FPP /CFPP /zeroise /no_quit /wide_source /IMPLICIT_NONE /xref find_window_new.xrf

while in Plato it is:

FTN95.EXE 'Z:\FPStackFault\FIND_WINDOW_NEW.for' /NO_BANNER /VS7 /DELETE_OBJ_ON_ERROR /ERROR_NUMBERS /UNLIMITED_ERRORS /SAVE /ZEROISE /IMPLICIT_NONE /WIDE_SOURCE /DUMP /EXPLIST /LIST /XREF /FPP /CFPP /echo_options /no_comment /persist /dump /hardfail /no_banner /BINARY 'Release\Win32\FIND_WINDOW_NEW.obj'

Yes, there are differences, but I cannot see what missing or included option is causing the differences in the compile. I hope you can find it.

When I put the build outside of Plato, and compile/link and run, the code compiles and works fine. I have no idea why it does not compile 'properly' in my makefile.

Here's the code again:

	winapp
	PROGRAM MAIN
	use mswin
	use iso_fortran_env
        INTEGER(7):: I
        integer(7),external:: find_new_window
        print *,'compiler version=',COMPILER_VERSION()
        i=find_new_window('SalfordClass')
        print *,'Handle=',i
        end
	integer(7) function find_new_window(abcd)
	STDCALL FINDWINDOW_static 'FindWindowA' (STRING,REF):INTEGER(7)
	character*(*):: abcd
	find_new_window = findwindow_static(abcd,core4(0))
10	continue
	return
	end

and the Compile/Link (separated)

FTN95.exe forumtesting.for /DUMP /UNLIMITED_ERRORS /no_comment /list find_window_new.lis /ignore 242 /ignore 767 /ignore 520 /ignore 21 /ignore 179 /ignore 1031 /ignore 197 /ignore 1088 /IGNORE 1225 /ERROR_NUMBERS /persist /SAVE /FPP /CFPP /zeroise /no_quit /wide_source /IMPLICIT_NONE /xref find_window_new.xrf slink.exe -OUT:'ForumTesting.exe' forumtesting.obj

Well, I didn't expect this. If I add the statement to my separately compiled routine of:

WINAPP

it compiles/links fine.

What might have happened: As I was beginning to transition to 64-bit, my makefile underwent some changes. One of which was the removal of the /WINDOWS as a command line option. Which has the same effect, If I remember correctly.

Bill

I don't understand why the linking could not find FindWindowA. Is it possible that SLINK is not able to scan the standard API DLLs? Something to do with the PATH environment in your DOS box?

You will need WINAPP (or its equivalent) in your sample because SalfordClass is the registered class for the old style ClearWin window and that is what you are using for the PRINT statement in your code.

ClearWin+ (with the +) and winio@ statements use SalfordDialog by default. Old style ClearWin (without the +) uses SalfordClass for the output window.

If you run your sample app as a console app then FindWindow (in any form) will return zero (or whatever i was before the call) because there are no apps running with SalfordClass as the registered class.

Yeah, I don't understand it either.

I don't know why WINAPP on this routine (specifically) allows the external reference to be generated properly, but it certainly does.

I will experiment (as time permits) to see if my STDCALL's for my own DLL routines get a different name applied to them when WINAPP is present at compile time. That is mostly of curiosity, as the programs that actually use my (current only) DLL are NOT windows applications.

For now though, I consider the matter closed and the attribution of fault is to 'User Error'.

That said, I learned something new today, so today is a good day!