|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Dec 13, 2020 3:55 pm Post subject: 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:
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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Dec 13, 2020 5:22 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7929 Location: Salford, UK
|
Posted: Mon Dec 14, 2020 9:55 am Post subject: |
|
|
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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Dec 14, 2020 4:37 pm Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Tue Dec 15, 2020 1:08 am Post subject: |
|
|
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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Tue Dec 15, 2020 4:53 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7929 Location: Salford, UK
|
Posted: Mon Dec 21, 2020 12:12 pm Post subject: |
|
|
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 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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Dec 21, 2020 2:50 pm Post subject: |
|
|
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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Dec 28, 2020 8:58 pm Post subject: |
|
|
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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Tue Dec 29, 2020 6:27 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7929 Location: Salford, UK
|
Posted: Tue Dec 29, 2020 10:53 am Post subject: |
|
|
Bill
If you can send me some sample code then I will try to reproduce your problem.
Paul |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Tue Dec 29, 2020 3:34 pm Post subject: |
|
|
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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Tue Dec 29, 2020 4:08 pm Post subject: |
|
|
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 |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Tue Dec 29, 2020 4:42 pm Post subject: |
|
|
Well, I didn't expect this. If I add the statement to my separately compiled routine of:
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7929 Location: Salford, UK
|
Posted: Tue Dec 29, 2020 6:24 pm Post subject: |
|
|
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 |
|
|
|
|
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
|