forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Link step is not finding WIN32API calls
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
wahorger



Joined: 13 Oct 2014
Posts: 920
Location: Morrison, CO, USA

PostPosted: Sun Dec 13, 2020 3:55 pm    Post subject: Link step is not finding WIN32API calls Reply with quote

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:

Code:
   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:

Quote:
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.

Quote:
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)

Quote:
$(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.
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 920
Location: Morrison, CO, USA

PostPosted: Sun Dec 13, 2020 5:22 pm    Post subject: Reply with quote

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.

Code:
   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


Quote:

_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?
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6688
Location: Salford, UK

PostPosted: Mon Dec 14, 2020 9:55 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 920
Location: Morrison, CO, USA

PostPosted: Mon Dec 14, 2020 4:37 pm    Post subject: Reply with quote

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

Quote:
[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.
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 2252
Location: Sydney

PostPosted: Tue Dec 15, 2020 1:08 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 920
Location: Morrison, CO, USA

PostPosted: Tue Dec 15, 2020 4:53 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6688
Location: Salford, UK

PostPosted: Mon Dec 21, 2020 12:12 pm    Post subject: Reply with quote

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 Cool 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.
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 920
Location: Morrison, CO, USA

PostPosted: Mon Dec 21, 2020 2:50 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 920
Location: Morrison, CO, USA

PostPosted: Mon Dec 28, 2020 8:58 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 920
Location: Morrison, CO, USA

PostPosted: Tue Dec 29, 2020 6:27 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6688
Location: Salford, UK

PostPosted: Tue Dec 29, 2020 10:53 am    Post subject: Reply with quote

Bill

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

Paul
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 920
Location: Morrison, CO, USA

PostPosted: Tue Dec 29, 2020 3:34 pm    Post subject: Reply with quote

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:
Quote:
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:
Quote:
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.
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 920
Location: Morrison, CO, USA

PostPosted: Tue Dec 29, 2020 4:08 pm    Post subject: Reply with quote

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:
Code:
   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)
Quote:
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
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 920
Location: Morrison, CO, USA

PostPosted: Tue Dec 29, 2020 4:42 pm    Post subject: Reply with quote

Well, I didn't expect this. If I add the statement to my separately compiled routine of:
Code:
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.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6688
Location: Salford, UK

PostPosted: Tue Dec 29, 2020 6:24 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group