@dir$ equivalent in Compiled program

[Flatlander]

Thank you Richard.

[mavison]

After some experimentation today, I settled on the following...

Code: Select all

IF @cmd$="-C" THEN X%=10 ELSE X%=12 
data$ = LEFT$(@dir$,LEN @dir$-X%)

which removes the 12 characters of the directory holding the interpreted source,
or the 10 characters of the directory holding the compiled exe from a zip, when called from a command file with

Code: Select all

start /B %~dp0<CompiledDir>/<AppName>.exe -C

This was tested and working fine for me for what I wanted to do ... but then I read your message about the 1.40b change, so I installed that, re-compiled and re-tested, expecting to have to make a minor change to my code.

The result from running the interpreter from your IDE was unchanged, as expected.
The re-compiled version still behaved the same as 1.40a - and I did check the running version was 1.40b with *HELP!
With the -C parameter in place as above, the value of @cmd$ was just "-C" in 1.40b, as it had been in 1.40a.

Note that without the -C parm, @cmd$ is null, so perhaps the -C is appended to the null?
Is running it from a compile-to-zip regarded as not compiled (with a @cmd$ value) but interpreted (with a numm @cmd$)?
So I am not sure about your change, or have I misunderstood again?

Did you notice that I said earlier that

Code: Select all

REM!Exefile name.zip

was displayed as name.exe in the Create Application Bundle window, requiring me to remember to do a manual change to zip every time!

[Richard Russell]

This was tested and working fine for me for what I wanted to do ... but then I read your message about the 1.40b change, so I installed that, re-compiled and re-tested, expecting to have to make a minor change to my code.

I'm slightly confused. I thought you had switched to compiling to a .zip bundle rather than a standalone .exe, in which case the 1.40a -> 1.40b change won't have had any impact since only the latter is affected. As far as I'm aware there isn't, and never has been, an issue with the way @cmd$ behaves when 'compiled' to a .zip (in Windows or Linux).

I said earlier that

Code: Select all

REM!Exefile name.zip

was displayed as name.exe in the Create Application Bundle window

Yes, that's by design because the different desktop platforms (Windows, MacOS, Linux) use different bundle extensions, so if you specify one in the REM!Exefile directive it is ignored and replaced by whatever is appropriate for the platform. The only exception is when building a 'web bundle' when specifying a .bbb extension in the REM!Exefile is significant.

The reason it's possible to build a .zip in Windows is that this was the only option available until version 1.36a so I didn't want to remove the facility entirely. But it's not made easy, because (until the @cmd$ issue was identified) I knew of no reason why anybody should be encouraged to do so. Now that issue's hopefully been resolved, there is again no reason.

[mavison]

Yes, I am now using compile to zip, but your post above about the change did not indicate that it only affected compile to exe. And the docs say of @cmd$:

The variable @cmd$ allows an executable created with the Compile utility to access the command line

which does not differentiate between exe and zip compiles.

Regarding REM!Exefile bundlefile, the docs do say:

If you specify .zip in Windows, a Zip archive will be created rather than the default standalone executable.

which implies that specifying zip will not be ignored!
I do still want to use a zip file, as it also avoids the problems with multiple temporary registry keys. Can I suggest it would be useful if zip behaved as documented, and not ignored? Otherwise the docs could be clarified!

Thanks for your help with this. Despite these issues, I always find BBC BASIC easy to use.

[Richard Russell]

your post above about the change did not indicate that it only affected compile to exe.

It was implied, since it was in response to your report that @cmd$ did not work when compiling to a .exe, which led you to change to using a .zip instead, whereupon it did work. Since only the .exe exhibited the fault only the .exe needed fixing, and only the .exe was changed.

And the docs say of @cmd$:
The variable @cmd$ allows an executable created with the Compile utility to access the command line
which does not differentiate between exe and zip compiles.

The documentation describes what should work, not what does work! By definition, a bug is something that does not work as documented (otherwise it's a 'feature') therefore the bug related to the non-working of @cmd$ when compiled to a .exe, which I was not aware of until you drew my attention to it, is not mentioned in the docs.

I do still want to use a zip file, as it also avoids the problems with multiple temporary registry keys. Can I suggest it would be useful if zip behaved as documented, and not ignored? Otherwise the docs could be clarified!

I will correct the docs in that regard. If I make any change to the code (which is unlikely, given my illness) it will probably be to remove the capability of creating a .zip in Windows, because this is an anomaly that is inconsistent with how it works on any other platform. BBC BASIC for Windows does not support creating a zip.

As far as the registry keys are concerned, is this really a "problem'"? The HKEY_CURRENT_USER portion of my registry is over 12 Mbytes as it is, so I don't imagine these entries are bloating it to any great extent. Presumably Microsoft is aware of the issue and seemingly isn't concerned about it, in which case I'm not either!

What would be helpful is to identify what aspect of the program is causing the Program Compatibility Assistant to create the entries. If it's something in the manifest which it is taking exception to, it may be possible to make a change to avoid it. Unfortunately I don't know how to find out.

[Richard Russell]

What would be helpful is to identify what aspect of the program is causing the Program Compatibility Assistant to create the entries. If it's something in the manifest which it is taking exception to, it may be possible to make a change to avoid it. Unfortunately I don't know how to find out.

I have confirmed that the manifest does contain the supportedOS value for Windows 10 and Windows 11 {8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}, so it's not that:

Code: Select all

<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
 <application> 
  <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> 
  <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
  <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
  <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
  <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
 </application> 
</compatibility>

I also cannot see any relevant events listed in the Windows logs, which is apparently where manifest errors may appear. So I'm none the wiser.

[Richard Russell]

As far as the registry keys are concerned, is this really a "problem'"?

Something else I find puzzling about this is that the application which the end-user actually runs is (for example) myprog.exe stored somewhere other than %temp%. That is the program which the user can change the compatibility settings for in its Properties, and running it presumably doesn't directly result in any 'unwanted' registry entries being generated.

On the other hand the file bbcsdl.exe which is in %temp%, and indeed is in a different sub-directory of %temp% each time, is run as a spawned process. As a result I wouldn't have expected it to trigger the Program Compatibility Assistant, since the end-user doesn't have any control over its individual compatibility settings anyway.

A (non-BBC BASIC) application could conceivably spawn dozens of sub-processes, surely they are not each individually going to create PCA entries in the Registry? Something is happening here that I don't understand.

[Richard Russell]

The HKEY_CURRENT_USER portion of my registry is over 12 Mbytes as it is, so I don't imagine these entries are bloating it to any great extent.

I've double-checked and running a BBCSDL program 'compiled' to an exe is not creating an additional registry entry here. I had 43 such entries initially; I then ran three compiled BBCSDL programs and afterwards I still had 43 such entries.

I then deleted all those 43 entries from the registry and ran a compiled BBCSDL program. Afterwards there were still no relevant registry entries.

So here, anyway, this does not appear to be a problem. The question remains of where those 43 entries came from originally, but they may well correspond to occasions when an application crashed and didn't terminate correctly.

I would also add that the temporary directories created in %temp% are all of the form BBCxxxx.tmp where xxxx corresponds to a 4-digit hexadecimal number. Therefore there can never be more than 65536 such directories, setting an upper limit to the theoretical maximum amount of registry bloat that could be caused.

N.B. The 'compiled' BBCSDL applications that I ran were all signed. I don't suppose that is relevant, but I would always recommend signing executables anyway for security reasons.

[mavison]

It is very strange that the registry problem I am seeing, you are not.

I am running on Windows 11 Home 64bit 23H2, and with an Admin user, in case that is relevant.

My test program is...

Code: Select all

   10 REM variables
   20 ON ERROR PRINT REPORT$ ERL: END
   30
   40 REM!Exefile variables.zip
   50
   60 *HELP
   70 PRINT'"@dir$="@dir$
   80 PRINT "@lib$="@lib$
   90 PRINT "@usr$="@usr$
  100 PRINT "@cmd$="@cmd$
  110 INPUT'"Press Return to end" A$
  120 END

If I compile that to an exe and double-click it to run it, I get

Code: Select all

BBC BASIC for Win32 version 1.40b

@dir$=C:\Users\xxxx\AppData\Local\Temp\BBC4A51.tmp\
@lib$=C:\Users\xxxx\AppData\Local\Temp\BBC4A51.tmp\lib\
@usr$=C:\Users\xxxx\AppData\Roaming\BBCBasic\
@cmd$=C:\Users\xxxx\AppData\Local\Temp\BBC4A51.tmp\variables.bbc

Press Return to end

While that is still running, a newly started regedit finds two items with BBC4A51 in their name, for ApplicationCompany and FriendlyAppName, and CCleaner can find no Registry problems.

If I then press Return and close the window, another newly started regedit still finds the two entries, and CCleaner finds two Missing MUI Reference issues for the two entries as follows...

Code: Select all

[HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache]
"C:\\Users\\xxxx\\AppData\\Local\\Temp\\BBC4A51.tmp\\bbcsdl.exe.FriendlyAppName"="BBC BASIC for SDL 2.0"
[HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache]
"C:\\Users\\xxxx\\AppData\\Local\\Temp\\BBC4A51.tmp\\bbcsdl.exe.ApplicationCompany"="R. T. Russell"

and they still exist after a Windows restart.

What on earth could be going on here that is different to your tests?

Until this is resolved, I will use a zip-compiled program, though my code also now caters for exe-compiled, as that seems to be where I should be going.

Note that my variables.exe is not signed, as I have not (yet) jumped over that big hurdle.

[Richard Russell]

It is very strange that the registry problem I am seeing, you are not.

In your original report you quoted two different areas of the registry:

Code: Select all

HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache
HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Store

It's the latter - the keys created by the Program Compatibility Assistant (PCA) - that I have been referring to in connection with the manifest etc. The former, which you now seem to be concentrating on, are considered to be of forensic value in analysing malware, for example, so it's not surprising that they are not deleted after the program is removed.

Until this is resolved, I will use a zip-compiled program

There is nothing to "resolve". This is Windows working normally, the registry entries are harmless, ignore them. You wouldn't even have known that they were there had you not run a Registry Cleaner tool! Even the theoretical maximum of 65536 such entries wouldn't bloat the registry hugely, a few Megabytes at most.

There's a pertinent comment under the question What is MUI CACHE here: "If you ever think your Registry needs to be cleaned, repaired, boosted, tuned-up, cured, tweaked, fixed, or optimized, it doesn't"!

I consider this 'case closed'.