Since we have a convention established to use MAIN.PRG as the common entry point for every project, using that as a little bootstrapper is probably a smart idea. Since it's separate from your real code it doesn't really matter what it detects and if it uses OPTION STRICT or not.
If you want to save on rewriting your code, you could try and put in the effort to separate your program into "main code" and "platform code" in separate files. Main code would work everywhere and call to COMMON DEFs in the platform code loaded by the bootstrapper to fill in the gaps.
SB3/SB4 Cross-compatible code
Root / Programming Questions / [.]
AveryCreated:
Programs uploaded the SB servers via SmileBASIC 3 are downloadable by both SB3 and SB4. This means it's currently possible to host programs which can be downloaded, and if doen correctly, RUN on both as well.
There are two ways to go about this.
1: Carefully write the code to use only common command and function syntax, so that the resulting execution is the same on SB3 and SB4
2: Perform a check so the program can determine which version of SmileBASIC it is running on, and have it branch its code accordingly.
The best check I am aware of.
IF #CHKS AND 32 THEN EXEC "PRG:MAIN.SB3" ' Start SB3 code IF #CHKS AND 8 THEN EXEC "PRG:MAIN.SB4" ' Start SB4 Code
Constants:
- #CHKUV, #CHKI, #CHKR, #CHKS, #CHKC, #CHKV have different values in SB3/SB4
- 65536*65536: 4294967296 in SB3 and 0 in SB4 (works with any integer operators when used on constants: in SB3 the value is converted to a float if it overflows, while in SB4 it isn't)
Other fun things:
- VAL("&H1_1") (underscore in hex/bin literals only works in SB4)
Here's the real pain point though: SB3 keys work on SB4, but SB4 keys don't work on SB3. Plus SB3 projects don't show in the SB4 download gallery, so you're hurting the discoverability of your program. It's in your best interest to host two versions of the same project anyway.
Of course, if you follow the design patterns listed above and make the SB3 version first, making the SB4 version gets a whole lot easier. Plus in the case of maintaining two versions you don't really need a bootstrapper, unless you want to load different platform code in the SB3 version or warn people who downloaded it on SB4 that they got the wrong one.
You're just shooting yourself in the foot using only a SB3 key, but starting there makes life pretty easy.