Speaking of stacks....

John S:

1. Rudnei's example code, in four pieces, at https://forums.silverfrost.com/Forum/Topic/3333&highlight=winio

2. Your example code, in two pieces, at http://forums.silverfrost.com/viewtopic.php?t=3769&highlight=npcplex2v2a2test3

3. DanRRight's example code, in two pieces at https://forums.silverfrost.com/Forum/Topic/3367&highlight=module+allsubsbremms, after fixing the bugs in it

In fact, you can pick any code that contains WINIO@ calls. The bug is perfectly reproducible and simple in nature. It is also easy to work-around, pending a proper fix from Silverfrost. After n calls to WINIO@, add CALL ADJESP(n). The fix-up is done in assembler code, given below, which can be assembled using NASM (obtained from https://www.nasm.us/ ), and linked to your FTN95 code with SLINK.

If you are a victim of stack-anxiety, you can add CALL ADJESP(1) after every call to WINIO@.

; call adjesp(n) -- add 4*n to esp
; 
; nasm.exe -f win32 adjesp.asm
;
global _ADJESP
SECTION .text

_ADJESP:
    pop eax ; return address
    pop ecx ; arg, contains number of 32-bit words to 'pop'
    mov ecx, [ecx]; count of 32-bit words to pop
    lea esp, [esp + 4*ecx - 4]; -4 since caller will pop arg
    jmp eax

Paul, it seems to scan C:\Windows\System32\OpenGL32.dll. It is listed in the linker map. That doesn't mean, however, that those routines are actually there. On my laptop, there are two different Opengl32.dll files, two very different sizes, and date/time stamps within a couple of hours of each other. All in the Windows folder under various sub-folders.

Still looking.

The two opengl32.dll files, if in windows\system32 and windows\syswow64, are 64 and 32 bit versions, so only one of them will be used with one of your programs. The one in system32 will be used in a 64-bit program.

It is possible to have an import library (for a DLL) that was produced from an earlier version of the DLL, so that there is a mismatch in the externals named in the two. The fact that some symbols are not in the DLL will be noticed when an attempt is made to load the DLL and access the routine; not at link time.

mecej4

Many thanks for this report. The ESP adjustment for 32 bit calls to winio@ has been corrected for the next release of FTN95 (the adjustment was correct for FTN90 and apparently overlooked when porting to FTN95).

I aim to provide an interim version of FTN95 available shortly for those who would like to test recent fixes.

The incorrect ESP adjustment is unlikely to cause a stack overflow because calls to winio@ require runtime user interaction and so will always be limited in number.

It is very pleasant to see such a rapid resolution of a rather complicated compiler bug compounded by usage errors. Thanks, Paul.

I think that at this point there are no unanswered questions relating to stack corruption caused by calls to WINIO@ or OpenGL routines. It would be reassuring to have Bill Horger confirm this, after he corrects his full application program to use the correct OpenGL module (OPENGL, not OPENGL$).

The stack will still lose 4 bytes/WINIO@ call but, as Paul has noted, this should not lead to noticeable errors. This defect, too, will be removed in the interim release of the compiler, and Bill Horger will probably be one of the first users to employ that release.

I have looked at files with the name opengl$.mod.

On my machine I have a file with this name (perhaps from an old installation) in Silverfrost\FTN95\include. This was compiled with 32 bit FTN95 and no longer serves any purpose (I suspect that this file was never released).

Also I have a file with this name in SilverFrost\FTN95\include\gFortran. This was compiled with 64 bit gFortran and is for use with 64 bit gFortran (my understanding is that, for 64 bits, STDCALL is no longer distinct from CDECL so the source code is correct).

Paul, thanks for taking a look at the includes.

Resolved: Routine names missing at link time. I have tried to replicate the issue with the routine names not linking to the executable. I have tried this on two different platforms, and cannot replicate. I am convinced it was my error, although I may never know the root cause.

In regards to the winio@ ESP issues, I agree that the likelihood of having a stack corruption is very small as to be infinitesimal. The only stack issues of this magnitude that I have had occur have been when the ESP register is affected for tens to hundreds of thousands of times.

mejec4, thanks for your efforts on previous version of FTN95! For me, most of my winio@ calls are in subroutines, and ESP gets restored to the proper value upon return, so the issues does not 'propagate' for me.

And, Paul, thanks for providing the fix!

When you have a product that is mature, it gets harder and harder to find bugs. I know in my own code, I had a minor bug that lay dormant for 20+ years, only to rear its head when I used the routine in a new context. These are tough to find without user provided information. This forum, and these people, are really good at drilling down to find these!

Thanks to you all! Proceeding with OpenGL!