Issue with new 6.13a variables?

[hellomike]

Most probably I'm missing something but I need some explanation why the following doesn't work.

First I have this program:

Code: Select all

      PRINT @vdu.o.x%
      PRINT @char.x%
      END

Running it prints two values. All is well.

Then I have the following program that executes the previous program (called 'NewProg.bbc') through OSCLI() like

Code: Select all

      OSCLI("""C:\Program Files (x86)\BBC BASIC for Windows\bbcwrun6.exe"" NewProg.bbc")
      END

This time only the @vdu.o.x% values prints but trying to print the @char.x% value fails.

Code: Select all

               0
      No such variable
      >

I'm sure this can be explained but currently not by me.
Thanks

[RichardRussell]

I'm sure this can be explained but currently not by me.

Nor by me! When I attempt to reproduce exactly the steps you described, I get a different result:

Code: Select all

         0
         8
>

In other words where you get 'No such variable' I get '8' (which seems to be a valid value for @char.x%). So I'm as mystified as you are and I would be interested to learn what others get when they also attempt to reproduce your finding.

Incidentally what happens if you 'compile' newprog.bbc to an EXE? That is effectively doing the same thing, but instead of executing the Run Time Engine via OSCLI it is embedding it in an executable. Does that also give 'No such variable'? Here I get '0' and '8' again.

A useful 'sanity check' would be to add a *HELP to your test program just to confirm for sure that you're running the v6.13a RTE:

Code: Select all

      *help
      PRINT @vdu.o.x%
      PRINT @char.x%
      END

[hellomike]

Yes, adding '*HELP' indeed explains it Richard. When running in the IDE, it is version 6.13a.
I also added '*HELP' in the calling program.

The calling program reports 6.13a and the output in the 2nd window, from the called program reports 6.12a.

Both sources are in the same directory.

So I guess bbcwrun6.exe in "C:\Program Files (x86)\BBC BASIC for Windows\bbcwrun6.exe" is the previous runtime version.
Not sure what caused that as I upgraded 6.12a to 6.13a as per instructions on your site.

I'll probably try to completely remove and then install BB4W from scratch and then upgrade it to 6.13a.

Regards

Mike

[RichardRussell]

So I guess bbcwrun6.exe in "C:\Program Files (x86)\BBC BASIC for Windows\bbcwrun6.exe" is the previous runtime version.

Can you check the time stamps on bbcwin6.exe and bbcwrun6.exe, they should be the same. The only situation I can think of in which one could be upgraded but not the other is if bbcwrun6.exe was 'locked' when the upgrade process was run, for example because it was in use at the time (that's why installers almost invariably say to close all running applications first). But it's still strange.

I'll probably try to completely remove and then install BB4W from scratch and then upgrade it to 6.13a.

Please try just repeating the upgrade, I'd like to discover if it's broken.

[hellomike]

Once again you were on the right track Richard! Throughout the day I have a program active which I hardly notice anymore!
I ran 'upgrade.exe' again with this program active and this is the DIR afterwards:

Code: Select all

 Directory of C:\Program Files (x86)\BBC BASIC for Windows

04-04-2020  09:35    <DIR>          .
04-04-2020  09:35    <DIR>          ..
04-04-2020  09:35    <DIR>          ADDINS
30-08-2014  21:11            11.264 APLIB.DLL
22-01-2000  14:50               766 BBCHELP.ICO
04-04-2017  22:30           295.977 bbctutor.chm
15-03-2020  15:09         1.059.061 bbcwin.chm
01-01-2009  13:11           313.856 bbcwin.exe
04-04-2020  09:35           423.568 bbcwin6.exe
01-01-2009  13:11            83.456 bbcwrun.exe
04-04-2020  09:35            83.456 BBCWRUN.NEW
17-01-2020  20:37            83.456 bbcwrun6.exe
27-12-2014  16:33             1.227 bbcwrun6.exe.manifest
12-03-2020  15:15             1.634 COPYRITE.TXT
04-04-2020  09:35    <DIR>          EXAMPLES
04-04-2020  09:35    <DIR>          LIB
12-03-2020  15:14             1.565 LICENCE.TXT
12-03-2020  15:14               916 README.TXT
06-06-2010  14:58            68.499 synBB4W.exe
06-06-2010  13:45             7.246 synBB4W.html
05-07-2006  19:15            24.725 synBB4W.zip
04-04-2020  09:35           107.807 unins000.dat
04-04-2020  09:35           712.336 unins000.exe
04-04-2020  09:35            10.425 unins000.msg
02-03-2002  03:04            15.836 WINIO.CHM
02-03-2002  01:22            49.152 WINIO.DLL
02-03-2002  00:21             4.944 WINIO.SYS
02-03-2002  01:14             5.174 WINIO.VXD
17-03-2001  17:23            45.056 WINIOV1.DLL
04-07-2000  01:28             4.596 WINIOV1.SYS
17-03-2001  17:26             7.574 WINIOV1.TXT
              26 File(s)      3.423.572 bytes
               5 Dir(s)  453.449.293.824 bytes free

Then I ran 'upgrade.exe' once again with no active program running resulting in this DIR afterwards:

Code: Select all

 Directory of C:\Program Files (x86)\BBC BASIC for Windows

04-04-2020  09:38    <DIR>          .
04-04-2020  09:38    <DIR>          ..
04-04-2020  09:38    <DIR>          ADDINS
30-08-2014  21:11            11.264 APLIB.DLL
22-01-2000  14:50               766 BBCHELP.ICO
04-04-2017  22:30           295.977 bbctutor.chm
15-03-2020  15:09         1.059.061 bbcwin.chm
01-01-2009  13:11           313.856 bbcwin.exe
04-04-2020  09:38           423.568 bbcwin6.exe
01-01-2009  13:11            83.456 bbcwrun.exe
04-04-2020  09:38            83.456 bbcwrun6.exe
27-12-2014  16:33             1.227 bbcwrun6.exe.manifest
12-03-2020  15:15             1.634 COPYRITE.TXT
04-04-2020  09:38    <DIR>          EXAMPLES
04-04-2020  09:38    <DIR>          LIB
12-03-2020  15:14             1.565 LICENCE.TXT
12-03-2020  15:14               916 README.TXT
06-06-2010  14:58            68.499 synBB4W.exe
06-06-2010  13:45             7.246 synBB4W.html
05-07-2006  19:15            24.725 synBB4W.zip
04-04-2020  09:38           138.721 unins000.dat
04-04-2020  09:38           712.336 unins000.exe
04-04-2020  09:38            10.425 unins000.msg
02-03-2002  03:04            15.836 WINIO.CHM
02-03-2002  01:22            49.152 WINIO.DLL
02-03-2002  00:21             4.944 WINIO.SYS
02-03-2002  01:14             5.174 WINIO.VXD
17-03-2001  17:23            45.056 WINIOV1.DLL
04-07-2000  01:28             4.596 WINIOV1.SYS
17-03-2001  17:26             7.574 WINIOV1.TXT
              25 File(s)      3.371.030 bytes
               5 Dir(s)  453.447.622.656 bytes free

I did note that 'BBCWRUN.NEW' file but didn't pay enough attention to it as it clearly implies something isn't right.
All is well again and it was, as I predicted, entirely my own fault.

Kind regards,

Mike

[RichardRussell]

Throughout the day I have a program active which I hardly notice anymore!

So how come this program is locking bbcwrun6.exe? Are you running it using the Run Time Engine rather than 'compiling' it to an executable, and if so why? A standalone EXE ought not to have any impact on bbcwrun6.exe or the upgrade process, whether running or not.

All is well again and it was, as I predicted, entirely my own fault.

I'm a little surprised you received no warning that anything was wrong, but I may have decided that it was difficult to deliver one in a useful way via the Inno Setup installer (the upgrade process hasn't changed for many years).

[hellomike]

For the BB4W programs that I use frequently I have a (compiled) launcher app that starts them using the OSCLI mentioned.

Code: Select all

      .......
      BB4WEXE$="""C:\Program Files (x86)\BBC BASIC for Windows\bbcwrun6.exe"" "
      BB4WIDE$="""C:\Program Files (x86)\BBC BASIC for Windows\bbcwin6.exe"" "
      .......
      IF INKEY(-1) Cmd$=BB4WIDE$ ELSE Cmd$=BB4WEXE$
      OSCLI(Cmd$ + $Path%(Item%-1) + ";")
      .......
      QUIT

When I'm finished with the program I close it. Often I also need to make slight changes in parameters before running and I'm too lazy to make a UI for all of them so I do it in the IDE and run it and then close it without saving the change. Therefor storing and running them compiled would not work for me.

Indeed, for that one program that stays active most of the day I could make an exception.

No, the upgrade process did not give a warning.

[RichardRussell]

For the BB4W programs that I use frequently I have a (compiled) launcher app that starts them using the OSCLI mentioned.

Do you ever run two or more of them at once (from the same launcher session)? I expect the answer is yes, but if not you could probably execute them using CHAIN prog$ or CALL prog$, in other words utilise the interpreter within the launcher app rather than bbcwrun6.exe.

Often I also need to make slight changes in parameters before running and I'm too lazy to make a UI for all of them

There is a halfway house: compile them and pass the parameters in the command line (and pick them up in @cmd$). That requires some work, but nothing like as much as adding a UI.

[hellomike]

The sources are not all in the same directory. I seem to remember that in order to make @dir$ point to the right current directory for each program, CHAIN or CALL didn't work as @dir$ keep pointing to the launcher app or even no path in case of the @lib$ system variable.

Only launching 'bbcwrun6.exe' afresh make @dir$ en @lib$ point to the proper path for each program. The launcher app gets the absolute paths from a flat TXT file.

I hope that makes sense.

Mike

[RichardRussell]

CHAIN or CALL didn't work as @dir$ keep pointing to the launcher app

True enough, but if there was no way around that touchide.bbc couldn't work, as it relies on being able to CHAIN a program - which might be anywhere - with @dir$ correctly set (there is no 'run time engine' on Android or iOS that it could call)! So, faced with that challenge (and being lazy), my approach would be to copy the relevant code from touchide:

Code: Select all

      $PTR(@dir$) = dir$ : !(^@dir$+4) = LEN(dir$)

Not exactly 'legitimate' code, by any means, but it works (and it's 64-bit clean).

There are of course other issues associated with using CHAIN to run a program, in such a way that the program can't tell it is being run any differently from usual (e.g. ensuring that A% to Z% are all zero) but nothing particularly difficult.