Old code creating a screen fails with new Salflibc.dll

I use FTN95 extensively for engineering numerical analysis, but have not used ClearWin since developing a rather simple graphics program in 2009. In that respect, I am a novice in the extreme.

The following code to create a window still worked okay when compiled with Salflibc.dll (29 April 2019), but that executable failed when run with Salflibc.dll (3 Nov 2019). I recompiled with the new Salflibc, but this also fails.

RESULT = WINIO@('%CA@&',WINDOWH) ! RESULT = WINIO@('%SY[3D]&') ! RESULT = WINIO@('%ww[no_border]&') ! RESULT = WINIO@('%es&') ! RESULT = WINIO@('%WW%PV&') ! RESULT = WINIO@('%sp&',50L,10L) ! ! User- options on the menu line (triggering Call-back functions): ! RES2 = WINIO@('%mn[&File[&Print,|,&BMP file,|,&PCX file,|,E&xit]]&', & & DESKJ,BMP_FILE,PCX_FILE,'EXIT') ! RES2 = WINIO@('%mn[&Back,&Next]&',back,next) ! RES2 = WINIO@('%mn[&Help[&About GraphTun]]&',ABOUT) ! RES2 = WINIO@('%`GR[GREY,METAFILE_RESIZE]&', NXPIXEL,NYPIXEL,HANDSCRN) ! RESULT = WINIO@('%LW', IWIN1) ! RETURN

Each WINIO@ instruction before the last returns the result -1. Then the %LW instruction causes fails and displays a failure message entitled: Call_StackStatus Exception 0xC000041D 'Unknown'

The first two of many lines in the failure window are : 76e21b7b 648025CA0F0000FE ANDB FS:[00000FCA],0xFE +00000 76e21b83 817C2404CDABBADC CMP [ESP+0x4],0xDCBAABCD +00008 Such lines are meaningless to me, but perhaps someone will recognise something.

I will gladly provide any other information on request. In the meantime, is this enough to give any a clue to the likely cause?

If this code is within a subprogram then IWIN1 must not be a local variable. For example, you could give it the SAVE attribute.

Greetings Paul - and thanks for such a rapid response.

IWIN1 is declared in a module. I did not include declarations in the post, but could do so if desired. However, the whole program has worked for 15 years (except for a revision needed when the default for colours changed from RGB some years ago). Now it fails. The code must include something that Salflibc no longer allows, but I have no idea how to search for it.

Just in case... in response to a suggestion from Robert C, I now use 'USE MSWIN' instead of CALL <INCLUDE.INS>.

Alan

Can you provide a working program that illustrates this failure. If necessary, zip up your code and provide a link via DropBox or similar.

That sounds like a wonderful offer, Paul.

I would be very happy indeed to provide everything, including:

1. All the source code files files
2. Two batch files that are used to create an executable (one for compilation; another for linking)
3. A sample data file to drag and drop onto resulting executables
4. A .screenshot showing what the output looks like with the previous executables and the 2019 Salflibc.dll

However, is this what you are suggesting? It sounds too good to be true. Alan

Yes. If you can't create a small demonstrator then send it all.

True thanks, Paul. I shall try first to create a shorter demo.

Paul For security reasons, I have forwarded a link by email. Alan

Alan

The basic problem relates somehow to METAFILE_RESIZE. If you leave it out the it's basically OK.

Do you need it? I would need more time to work out what is going wrong.

Some other details...

1. FNTNAME in g_infont.f95 has too few characters (try 128 say).
2. HANDSCRN in g_module_glo.f95 should be a 32 bit integer.
3. You do not need to initialise IWIN1. It is initialised by ClearWin+.

Dear Paul Wow. That was quick.

1. I can live without METAFILE_RESIZE until the problem is fixed - and that should NOT be regarded as an urgent matter. I'll simply tell users that I will reintroduce the facility 'sometime'.
2. Thank you for the detailed supplementary comments. Very helpful. NB: I used INTEGER TYPE 7 so that it is possible to compile with either 32 or 64 without changing the code. That suggestion is in your Help documents.

Hopefully, I'll confirm later today that all now works fine. First = dental appointment.

Alan

I have now located and fixed the bug in ClearWin+ that raises the exception but this resizing mechanism no longer works, at least not for me. The image is erased and not redrawn.

There is an alternative user_resize but it requires more work from the programmer.

I will log this as a bug that needs fixing.

The 32 bit integer that I mentioned is 32 bits for both Win32 and x64.

This failure to redraw the image has now been fixed for the next release of ClearWin+.

Paul Sad to say, I cannot report success. I have removed the METAFILE_RESIZE instruction and implemented the changes you indicated. The %LW instruction now sets IWIN1=-1, but returns a RESULT of '0' and the subsequent CALL DRAW_FILLED_RECTANGLE (in the subroutine G_PAGE) fails, stating that there is no graphics window open. Do you have any other thoughts about what I might try? (Sorry) Alan

Alan

I may need to send your code back. I might have made other changes. I tested for x64 and not Win32. I used Plato directly rather than your batch files. If I have time I will check again tomorrow.

Paul Thanks yet again. I am happy to wait. Although obviously important for me, this is NOT urgent. Alan

Alan

I had made one other change.:

The subroutine G_INIT_GLO was defined with no arguments but called with two. So I changed line 29 in the file g_injob.f95.

This ought to be flagged as a compile time error so perhaps you could check your batch files.

Using Plato and the ClearWin+ that has been fixed, your program runs fine for me (Win32 and x64) including resizing the displayed graphs.

Incidentally Plato did not exactly perform as it should so this exercise has given me something to fix in Plato.

Paul

1. In the code that I zipped to you, there are no arguments in either location - so I infer that this flags a change that you have made.
2. Probably, everything would resolve itself if you send your working version version of the complete program to me - as provisionally suggested a few posts ago. I would first check that it works here too - and then, for my own education, explore what changes have been made. Alan

Alan

I have gone back to your zip archive and I have run your batch files. The resulting exe runs OK without any changes but I am using the ClearWin+ with the fix for metafile_resize.

I would expect your code to run successfully if metafile_resize is removed.

Here is the result of a grep for G_INIT_GLO...

C:\GraphTun>grep -S G_INIT_GLO *.f95 .\input\G_INJOB.f95: CALL G_INIT_GLO(NDAT,NTOKEN) .\input\G_INPUT.f95: CALL G_INIT_GLO .\modules\G_MODULE_GLO.f95: SUBROUTINE G_INIT_GLO

G_INJOB.f95 does not appear in your batch files and this accounts for my confusion.

Paul

I do apologise for the confusion caused by the existence of G_INJOB. Its use was discontinued ages ago, but I had not noticed that the file still existed.

METAFILE_RESIZE had already been removed when I posted at 5:35 on Wednesday. Nothing has been changed since then, but I have recompiled and rerun, just in case. The same failure occurs.

The instruction: RESULT = WINIO@('%LW', IWIN1) still returns 'RESULT = 0' and 'IWIN1 = -1'

Then, in G_PAGE, the call to DRAW_FILLED_RECTANGLE@ fails, triggering the failure message: 'No graphics window open'

Would it be useful for one of us to send to the other the current version of the source code? However, I am uncomfortable with you spending time on my problem at a weekend. Monday would be plenty soon enough.

Thanks, as ever Alan

Alan

A RESULT value of zero is normal in this context.

SELECT_GRAPHICS_OBJECT@ takes a 32 bit integer value supplied by the programmer. I can see that you have set this to 1. The function returns the value 1 on success. Calling it as a subroutine (as you have done) ought to be OK but you could check this.

I think that's all I can do on this issue. For me it also works for 64 bits so you could try adding /64 to the FTN95 command line to see what happens but remember to leave out the metafile_resize option in

  RES2    = WINIO@('%`GR[GREY,METAFILE_RESIZE]&', NXPIXEL,NYPIXEL,HANDSCRN)