Reverting .exe files to .BBC format

[TerryK]

I have two programs which I wrote some time ago and saved as .exe files when I was using Windows XP. I am now using Windows 7, which does not recognize them. Is there any way I can convert the programs back to .BBC format so that I can access them in BBC Basic?

[guest]

I have two programs which I wrote some time ago and saved as .exe files when I was using Windows XP. I am now using Windows 7, which does not recognize them.

A BB4W executable created on Windows XP (so long as you enabled the 'Use Windows XP (and later) visual styles' option, which is the default) should run on Windows 7, or Windows 10 for that matter; I do it all the time. What kind of error message are you receiving when you try?

[TerryK]

I saved these programs some while ago but don't remember using the 'Use Windows XP (and later) visual styles' option. When I try to open the files in Windows 7 I get a 'File or path not found' message. The files open and run OK on a laptop with Windows XP. I did save a hard copy of one of the programs (much amended and scribbled on) and will attempt to restore it as I would like to run it in BBC Basic to work on it.

TerryK

[guest]

When I try to open the files in Windows 7 I get a 'File or path not found' message.

That's got nothing to do with the version of Windows. Most likely your program tries to access a file that was present on your Windows XP PC but isn't present (at least, not in the same place) on your Windows 7 PC; 're-compiling' your program is extremely unlikely to make any difference, it would almost certainly fail in exactly the same way. Perhaps you can guess what the missing file might be and copy it onto your Windows 7 PC.

For future reference, to make a 'compiled' application genuinely stand-alone you need to ensure that all files referenced by the program (other than standard libraries which come with Windows) are in either @dir$ or @lib$ (or sub-directories thereof), and check that those files are being embedded in the executable. Ideally include REM!Embed directives in the program to specify exactly what files are embedded.

[TerryK]

Many thanks for that. I presume it's not possible to revert a compiled program to its original .BBC format

[guest]

Many thanks for that. I presume it's not possible to revert a compiled program to its original .BBC format

No (at least, not in the default case of the crunch options being enabled and the 'Encrypt and Compress' checkbox being selected). If those options are all disabled when the program is 'compiled' then the BASIC program is incorporated in the EXE unmodified, but that's something one would never normally do.

[TerryK]

Thanks again for your help, guest, Regards.

[KenDown]

Hmmm. I notice the comment that one would never normally NOT compress and encrypt. I must admit that I *always* turn those options off. Perhaps doing so slows down execution or something, but on the other hand it can be very useful in the sort of case "guest" describes. For example, I commonly use the variable file$ to hold a filename. If a compiled program crashes with a "File not found" error, I can simply type PRINTfile$ to discover the expected name of the missing file.

Once or twice it has saved my life to compile the program with line numbers enabled and then, when the ever helpful ERR=0 comes up I can at least type PRINT ERL to get an idea of which line is causing the problem. (Of course, once sorted out, I then recompile without line numbers).

Now you may well point out that if I had done my programming properly I would never encounter errors in my compiled executables and no doubt you are right and I hang my head in shame - but us plodding pedestrian amateurs need all the help we can get!

[KenDown]

Someone has kindly written to me privately to point out that I have completely misunderstood the effect of the 'Encrypt & compress' option. It has NO EFFECT WHATSOEVER on the ability to print the contents of a named variable. The compression and encryption are completely lossless and the program that ends up being run is *identical* to what it would be in the default case of the option being enabled.

Selecting 'Encrypt & compress' makes the executable SMALLER and it makes it much HARDER to reverse-engineer, but has no effect at all on debugging. There is NO DISADVANTAGE (other than not being able to recover the program from an EXE, if you consider that a disadvantage) which is why I said that one would never normally disable it.

What I was thinking of are the *crunch* options, specifically the 'Abbreviate names' option which I would indeed need to disable if I wanted to be able to PRINT a named variable at an immediate prompt. Similarly I might need to disable the 'Concatenate lines' crunch option if I wanted to PRINT ERL. But then the program will run more slowly, and it's better to eliminate bugs whilst still testing the program in the IDE and before 'compiling' to an EXE.

I completely agree on the desirability of eliminating bugs, but alas, I am only human!