clearwin_string@ and clrwin

This post has arisen out of the one about virtual memory but I'm starting a new thread because I don't want it to get lost in the mix.

I have been trying to answer my own question about USE of clrwin by commenting out the 'use clrwin' statement and instead adding in explicit definitions of the various Salford @-functions - yes, there were one or two more than just winio@ 😮 but not I think enough to justify 280 MB :p . (At the moment, the answer appears to be that it makes no difference). In the process of doing this, I came across what appears to be a bug (two actually). After slashing and burning the code this is what I am left with:

  program mainpr
  use callbacks
  iomain = winio@ ('%ti[icadam][]', ui_popup)
  stop
  end program mainpr

  module callbacks

! use clrwin character*256 clearwin_string@ external clearwin_string@ contains ! integer function ui_popup () character (len = 256) treason ui_popup = 2 treason = clearwin_string@ ('CALLBACK_REASON') return end function ui_popup ! end module callbacks

When I try to build this code fragment, Mr Plato complains as follows:

WARNING the following symbols are missing: CALLBACKS!CLEARWIN_STRING# E:\rest\techy\ftn95 bugs\missing symbol\CheckMate\Win32\callba.obj (E:\REST\TECHY\FTN95 BUGS\MISSING SYMBOL\CALLBA.F95)

And sure enough, if I run the executable, it bombs out the first time it needs to use clearwin_string@. However, if I comment out the two lines that define clearwin_string@ and uncomment out the 'use clrwin' line instead - no problem.

Am I being Monday-braindead here or is FTN95 doing something it shouldn't? Andy

Try declaring clearwin_string@ in the function rather than in the module header.

I already did, and it works. Begging the question, why does 'use clrwin' in the module header work?

My guess is that the equivalent in the module header requires an interface of some kind. To find out exactly why would take me some time to sort out and you have something that works and is cost effective.....

The alternative is to create your own module like clrwin but based on a subset of the corresponding Salford include file.

OK, OK! It appears there's no virtual memory benefit to be had by explicit declaration of only the @ functions required, rather than USE of clrwin, so it's an academic issue anyway, unless it's a symptom of a bigger issue. I only mentioned it because other @ functions (e.g. winio@, window_update@) do work in the module header as I would expect.

I'm more interested in a) why the applications I create have such a phenomenal virtual memory footprint and b) whether it might have any implications for installation on machines with minimal physical memory. If the answer to b) is yes, then the answer to a) becomes very interesting. Since I remain to be convinced that there is a logical reason why my little apps need to be hooked into two to three times as much of the OS as e.g. Lotus Notes, I am assuming that it does not and that this is an issue that could usefully be looked into.

Sorry but I do not know the answer to your question. Maybe someone else can help.