further problems with FTN 8.10

Hi, unfortunately the reading discrepancy of png-files are not corrected from version 8.05 to 8.10. Here is my testprogram once more:

  winapp
program pngtest
use mswin
implicit none

integer*4 xsize,ysize,a,imagectrl,picsizex,picsizey,urlmode
integer*4 func,mode,nbbp,urlerror,sizeerrcode,allocerror,blockerrcode,displayerrcode

character*255 filename,url
  character*1, dimension(:,:,:), allocatable :: picture

xsize=1200
  ysize=900

urlmode=1
url='http://tile.openstreetmap.org/15/16515/12525.png'
filename='test.png'
call read_url@(url,filename,urlmode,urlerror)
  
  a=winio@('%ca[test]&')
  a=winio@('%gr&',xsize,ysize)
  a=winio@('%lw',imagectrl)

a=use_gdiplus_image_files@(1)
call get_dib_size@(filename,picsizex,picsizey,nbbp,sizeerrcode)

allocate(picture(3,picsizex,picsizey),stat=allocerror)

call get_dib_block@(filename,picture,picsizex,picsizey,0,0,picsizex,picsizey,0,0,blockerrcode)
call display_dib_block@(0,0,picture,picsizex,picsizey,0,0,picsizex,picsizey,func,mode,displayerrcode)
  
  a=winio@('%ca[Result]&')
  a=winio@('%nlUrl_error: %wd&',urlerror)
  a=winio@('%nlImagesize: %wd   %wd&',picsizex,picsizey)      
  a=winio@('%nlGet_dib_size_error: %wd&',sizeerrcode)
  a=winio@('%nlAlloc_error: %wd&',allocerror) 
  a=winio@('%nlGet_dib_block_error: %wd&',blockerrcode)
  a=winio@('%nlDisplay_dib_block_error: %wd&',displayerrcode)
  a=winio@('%2nl%cn%9`bt[OK]')

end

The png-file is readed and displayed correct, but the errorcodes are on my PC sometimes not correct. My results are:

URL_error: 0; correct Imagesize: 256x256; correct Get_dib_size_error: 2; (read error) [color=red:b19a95c7de]not[/color:b19a95c7de] correct Alloc_error: 0; correct Get_dib_block_error: 1; [color=red:b19a95c7de]not[/color:b19a95c7de] correct; error 1 is not listed Display_dib_block_error: 0; correct

This is not a severe problem, because the png-file is displayed correctly. But when I ask for the readerror and display an errormessage, this will bot be correct.

Thanks Chemie

This has been fixed for the next release of the DLLs.

Hi Paul, now, I have problems with command_line. When I use it, I can't write values in a file, as demonstated here:

  winapp 

  program comline
  use mswin
  implicit none

  integer*4 a,itexlcom

  character*129 comdatei
itexlcom=0
  comdatei=' '

  call command_line(comdatei)
  itexlcom=len_trim(comdatei)  

  a=winio@('%ca[Result]&')
  a=winio@('%nlitexlcom: %wd  datei: %ws&',itexlcom,comdatei)
  a=winio@('%2nl%cn%9`bt[OK]')

  open(39,file='testcomline.dat',access='append')
  write(39,*) 'Test ',itexlcom,' ',comdatei
  close(39)

  end

The winio@ display is ok, but the write statment crashes, when I open any file with comline.exe. Can you Help? Thanks Chemie

Which versions of the runtime DLLs do you use? I ask because I ran your program without problems in 32- and 64-bit modes and ran into no errors. After each run from the command line with a specified argument, that argument was appended to the output file.

The salflibc.dll and salflibc64.dll used on my PC have modification dates of May 5 and May 4 2017, respectively.

I used the DLLs from newDLLs11.zip (18.6.2017) or newDLLs12.zip (1.8.2017). The crash occures only, when I choose in the Explorer one file, right mouse click on it and open with... (here I have choosed the comline.exe). With 32bit mode, there is no crash, but the file testcomline.dat is not created, with the 64bit mode, the program crashes. Using cmd.exe and typing comline.exe 'any filename', all is ok. Chemie

It works OK for me.

If it is failing at write(39,*) ... then add iostat to open(39,...) and look at the iostat value.

When I rearange the outputs like

  open(39,file='testcomline.dat',access='append',iostat=io)

  a=winio@('%ca[Result]&')
  a=winio@('%nliostat: %wd  datei: %ws&',io,comdatei)
  a=winio@('%2nl%cn%9`bt[OK]')

  write(39,*) 'Test ',itexlcom,' ',comdatei
  close(39)

I get io=10002 and the details are:

Silverfrost 64-bit exception report on E:\GPS\TestProgs\comline.EXE Tue Aug 15 17:20:27 2017

Unit has neither been OPENed nor preconnected at address 1c0081b1

Within file comline.EXE in COMLINE in line 26, at address 1f4

RAX = 000000000000005e RBX = 000000000000005e RCX = 000000000000005e RDX = 0000000000000000 RBP = 000000001c000000 RSI = 000000000000005e RDI = 0000000000000001 RSP = 000000000240f890 R8 = ffff80044662a887 R9 = 000000001c03263c R10 = 000000000000009b R11 = 000000000240f5b0 R12 = 0000000000000000 R13 = 0000000000000001 R14 = 000000000000001b R15 = 0000000000000081

1c0081b1) int 9

What is the meaning of io=10002? Thanks Chemie

When you right click on the data file in Windows Explorer and open it with your compiled comline.exe, the PATH is the Windows path, which may not be the same as the PATH in effect when you open a command window configured for FTN95.

On my PC, when I tried to follow your procedure to run the program from Windows Explorer, an attempt was made to load a different salflibc64.dll than the one in the FTN95 directory. You may have similar conflicts.

Another possibility is that the file to which you want to append is already open in some other program such as an editor or a command window. I obtained a similar register dump to the one that you showed and a stop on INT 9 when I ran the program, set the output file to read-only, and attempted to run the program again.

Either fix the Windows path so that the correct DLL gets loaded, or see if you can avoid running the program from Windows Explorer.

I have had a quick look and it appears that the iostate value 10002 is 10000 for 'system error' and 2 for 'the system cannot find the file specified'.

So you should provide the full path of the file or use some other way to make it 'visible' when the executable is running.

Is it too ridiculous to suggest that perhaps on first run, the file has to already exist? Is the problem fixed with STATUS='UNKNOWN' ?

What is FTN95's default if STATUS isn't given? Might it be STATUS='OLD'?

I would suspect that comline.exe is still running, ie the process has not been closed and the file is still opened. Run task manager.

I think, the problem is solved. I have tried all your proposions:

STATUS='UNKNOWN' don't help I have only one salflibc64.dll (in the FTN95 dirctory) comline.exe is not still running

Using the full path for testcomline.dat ie in my case 'e:\gps\testprogs\testcomline.dat ' gives the IOSTAT=0 and all is ok.

Thanks you for your help Chemie

Chemie,

If you want to get the right path for a particular file, then you can use

   CALL GET_PROGRAM_NAME@ (PNAME)

where PNAME is a text string. Use LEN_TRIM to get rid of trailing blanks, and then cut off your program name (as in 'PROG.EXE'). That leaves you with the path. If you want some other file in the same folder, then just add it to the path. Then you haven't hard-coded the path.

Eddie