%ss and browse_for_folder@ under 64bit

Sorry, but for all options, the result is 0.

  winapp 

  program memorystat
  use mswin
  implicit none 

  integer*4 a,i
integer*8 memorystatus

  a=winio@('%ca[Meldung]&')
do i=1,7
    memorystatus=GlobalMemoryStatus@(i)
  a=winio@('%nli= %wd option= %wd&',i,memorystatus)
enddo
  a=winio@('%2nl%cn%9`bt[OK]')

  end

What is my error? Thanks Chemie

PS: in case of __ALLOCATE$ and __DEALLOCATE@ I had an old version of clearwin64.dll on my pc.

You need to declare the return type of GlobalMemoryStatus@

program memorystat 
integer i
integer*8 GlobalMemoryStatus@ 
do i=1,7 
print*, GlobalMemoryStatus@(i)
enddo 
end 

Thanks, now it works.

But, could it be, that allocate works only with integer4, and I could not allocate memory up to 2GB (the highest value of integer4)? The testprogramm stops at 2GB.

  winapp 

  program alloctest
  use mswin
  implicit none 

  integer*8 aerror
integer*8 i,ihmio 
  integer*1, dimension(:), allocatable :: arr

ihmio=100000000

  do i= 1,200
  allocate(arr(i*ihmio),stat=aerror)
  print*, i,i*ihmio
  if (aerror.gt.0) goto 1
  deallocate(arr)
  enddo

1 end

Thanks Chemie

Yes you have found a bug. It is fixed now and I will see if we can release an interim clearwin64.dll for you.

Quoted from PaulLaidler Yes you have found a bug. It is fixed now and I will see if we can release an interim clearwin64.dll for you.

Thanks for fixing the bug. In this context (integer8 ←-> integer4) I can't present big integer*8 values with %wd of winio@. The presentation gives fault values. Chemie

Yes, %wd is for integer*4 values. I will make a note of this limitation.

John

There is a bug in the current release that limits ALLOCATE to 2GB. This has been fixed for the next release. Also there may be an interim release of the relevant DLLs in order to keep things moving.

Previously (with 32 bit applications) the whole address space was limited to 2GB. For the moment (for 64 bit applications) a single ALLOCATE is limited to 2GB so I am not that surprised that the bug has not been spotted before.

I think, the problem is only that in the current release, ALLOCATE is limited to 2GB. When the numeric value is > 2GB, ALLOCATE sees only the last 32 bit, this will be a negativ value (e.g. in the range of 2GB to 4 GB) and a positiv value (e.g. in the range of 4GB to 6GB). Therefore somtimes the error will be 0 and other times 1.

How I can get the interim clearwin64.dll?

In the case of %wd with integer8 I can write the integer8 value to a string, and present the string with %ws. This works.

Chemie

I have tested recent releases and the allocate size problem is only with Ver. 8.05.0

I have written a program that tests large memory allocation. You may find it an interesting test. You may also want to change the parameter max_gb before trying to run it.

https://www.dropbox.com/s/zlc8sm0iyqlem8b/alloc_test.f90?dl=0

Paul,

Is it possible to release a version 8.05.1 or 8.06.0 to fix the problem with allocate, as it is a key capability with Ver 8.x ?

John

Here is a link for downloading an interim release of the various DLLs.

Please make sure that you backup your existing DLLs before installing and testing the new ones.

https://www.dropbox.com/s/2sn929jqilhgmp8/newDLLs.zip?dl=0

Quoted from PaulLaidler Here is a link for downloading an interim release of the various DLLs.

Please make sure that you backup your existing DLLs before installing and testing the new ones.

https://www.dropbox.com/s/2sn929jqilhgmp8/newDLLs.zip?dl=0

Paul, thanks for the interim release of the various DLLs. I have tested the allocation and found no errors. But now, I have problems with display_dib_block@, when I use large arrays. Are there some limitations for the size of pictures? To illustrate my problem, I have written a test program, first I allocate a small picture und display the upper left in red and the lower right corner in green colour. In the second part, I allocate a large picture and display also the upper left corner, this goes well, but when I display the lower right corner, the program crashes. Here is the testprogram: winapp

  program dibblocktest
  use mswin
  implicit none 

integer*4 a,i,j,ii,jj,i1,i2,i3,xsize,ysize,xpic,ypic,picctrl,aerror
integer*4 func,mode,errcode

  character*1, dimension(:,:,:), allocatable :: picture

func=0
  mode=0
  errcode=0
i1=1
  i2=2
i3=3
xpic=1000
  ypic=1000

  a=winio@('%ca[Picture]&')
  a=winio@('%gr&',xpic,ypic)
  a=winio@('%lw',picctrl)

! create and allocate a small picture xsize=5000 ysize=5000 allocate(picture(i3,xsize,ysize),stat=aerror) if (aerror.ne.0) goto 1

! create and display a small red picture (upper left corner) do i=1,xpic do j=1,ypic picture(i1,i,j)=char(255) picture(i2,i,j)=char(0) picture(i3,i,j)=char(0) enddo enddo call display_dib_block@(i1,i1,picture,xsize,ysize,i1,i1,xpic,ypic,func,mode,errcode)

call sleep@(2.0)

! create and display a small green picture (lower right corner) do i=1,xpic ii=xsize-xpic+i do j=1,ypic jj=ysize-ypic+j picture(i1,ii,jj)=char(0) picture(i2,ii,jj)=char(255) picture(i3,ii,jj)=char(0) enddo enddo call display_dib_block@(i1,i1,picture,xsize,ysize,xsize-xpic,ysize-ypic,xpic,ypic,func,mode,errcode)

call sleep@(2.0)
  deallocate(picture)

! create and allocate a large picture ( ca. 7 gb) xsize=50000 ysize=50000 allocate(picture(i3,xsize,ysize),stat=aerror) if (aerror.ne.0) goto 1

! create and display the upper left corner of the large picture do i=1,xpic do j=1,ypic picture(i1,i,j)=char(255) picture(i2,i,j)=char(0) picture(i3,i,j)=char(0) enddo enddo call display_dib_block@(i1,i1,picture,xsize,ysize,i1,i1,xpic,ypic,func,mode,errcode)

call sleep@(2.0)

! create and display the lower right corner of the large picture ! this display fails, I don't know why, it is the same code as with the small picture do i=1,xpic ii=xsize-xpic+i do j=1,ypic jj=ysize-ypic+j picture(i1,ii,jj)=char(0) picture(i2,ii,jj)=char(255) picture(i3,ii,jj)=char(0) enddo enddo call display_dib_block@(i1,i1,picture,xsize,ysize,xsize-xpic,ysize-ypic,xpic,ypic,func,mode,errcode) deallocate(picture)

1 end

Have I made an error? Thanks Chemie

Chemie,

I think I found some minor problems: integer*8 picctrl call display_dib_block@ (xpos,ypos where top corner is 0,0 and also array offset could be 0,0

However the main problem does exist. I tried to see what size failed: picture must be less than 2gb.

program dibblock
   use mswin 
   implicit none 
  
   integer*4 a, xpic,ypic, xsize,ysize, i
   integer*8 picctrl
  !
   xpic   = 1000 
   ypic   = 800 
  !
   a = winio@('%ca[Picture]&') 
   a = winio@('%gr&', xpic,ypic) 
   a = winio@('%lw', picctrl) 
  !
  ! create and allocate a small picture 
   do i = 5000, 50000, 2500
     xsize=i 
     ysize=i
     call dibblocktest ( xsize,ysize )
   end do
!
 end 

 subroutine dibblocktest  ( xsize,ysize )
   use mswin 
   implicit none 
   integer*4 xsize,ysize
!
   integer*4 a,i,j,ii,jj,i1,i2,i3,xpic,ypic,xpos,ypos
   integer*4 func,mode,errcode, aerror 
!
   character*1, allocatable :: picture(:,:,:)
!
   func   = 0 
   mode   = 0 
   errcode= 0 
   i1     = 1 
   i2     = 2 
   i3     = 3 
!
   xpic   = 1000 - 200
   ypic   = 800  - 200
!
   write (*,*) 'create and allocate a picture'
   write (*,*) xsize,' by',ysize
   allocate ( picture(i3,xsize,ysize), stat=aerror) 
   if (aerror.ne.0) then
     write (*,*) 'error allocating array : stat=',aerror
     return
   else
     write (*,*) size(picture)/1024./1024.,' mb'
   end if
!  
   write (*,*) 'create and display a small red picture (upper left corner)' 
   do i=1,xpic 
     do j=1,ypic 
       picture(i1,i,j) = char(255) 
       picture(i2,i,j) = char(0) 
       picture(i3,i,j) = char(0) 
     enddo 
   enddo 
   xpos = 0
   ypos = 0
   call display_dib_block@ (xpos,ypos, picture,xsize,ysize, i1,i1, xpic,ypic, func,mode,errcode) 
   call sleep@(0.5) 
!  
   write (*,*) 'create and display a small green picture (lower right corner) '
   do i=1,xpic 
     ii=xsize-xpic+i 
     do j=1,ypic 
       jj=ysize-ypic+j 
       picture(i1,ii,jj) = char(0) 
       picture(i2,ii,jj) = char(255) 
       picture(i3,ii,jj) = char(0) 
     enddo 
   enddo 
   xpos = 200
   ypos = 200
   call display_dib_block@ (xpos,ypos, picture,xsize,ysize, xsize-xpic,ysize-ypic, xpic,ypic, func,mode,errcode) 
   call sleep@(0.5) 
!
   deallocate (picture) 
   write (*,*) 'end of test', func,mode,errcode
   write (*,*) ' '
!
  end subroutine dibblocktest

John, thank you for testing display_dib_block@. I have tested with xpos,ypos = 0 and 1, but the effects are the same. When you replace in your testprogram the i-loop (do i = 5000,50000,2500) e.g.(there are many combinations of xsiz and ysize, which give the same results) by xsize=49152 and ysize= 65536 the program don't crashes, but the lower right corner is black instead of green.

With the 64bit compiler I can now allocate large pictures (I have tried up to 14 gb, my pc has 16 gb ram) but I can't display them correct, when they are greater than 2gb. Sometimes (depending of the size) there will be wrong colours, sometimes there is a crash. This is (for me) the status now. When I can allocate such large pictures, I want also to display them. Perhaps, you have a solution for this problem. Many Thanks Chemie

I have looked at this and I think that the error is in the program. I am guessing that the %gr pixel sizes (wxh) should be the same values as those used to allocate 'picture'.

You increase the size to (50000, 50000) and then pass (49000,49000) to display_dib_block@ as position coordinates. I am guessing that you are writing to memory that has not been allocated by Clearwin+.

The control variable associated with %lw can be integer*4. It's not a Windows handle.

Paul, I don't understand display_dib_block@. I have copied the lower right corner (Position(49000,49000) to a fixed picturearray(1000,1000) and display this array with display_dib_block@, all is well. That means, allocation is good, I can write to the array and read from the array, correctly. My Question: why I can't display an arbitrary part from a large picturearry? For the upper left corner it is going well, why not for the lower right corner? What is the error in the program? Thanks for your help. Chemie

OK. I have looked at this in more detail and yes you are right again. An internal calculation in display_dib_block@ is giving an integer overflow. I have fixed this and I will let you know when I have uploaded a new set of DLLs.

Here is a link to download a new set of DLLs. Please remember to keep a backup of the original release.

https://www.dropbox.com/s/iuq2riwhfzahbl7/newDLLs1.zip?dl=0

Quoted from PaulLaidler Here is a link to download a new set of DLLs. Please remember to keep a backup of the original release.

https://www.dropbox.com/s/iuq2riwhfzahbl7/newDLLs1.zip?dl=0

Paul, thank you for the new set of DLLs. Now it is working, I have loaded, allocated and displayed a 13,5 gb picture. All is well. Thanks Chemie

Paul, perhaps I have found another problem with large (>2gb) files. When I try to read such a *.bmp file with get_dib_block@, I get a crash. With a *.jpg File, the file was read, but the colours are not correct, I think, with other values of width and deepth there will be also a crash. Could it be, that there is the same error as with display_dib_block@? It is no problem for me (but perhaps for others), because I have my own bmpread-procedure and jpg-files I can transform in bmp-files.

Thanks Chemie