The more I've been experimenting with the #INCLUDE command, the more I'm realizing that when you compile to an executable that - well ... you're not.

You can test this quite easily by using my homebrew Pico-8 compiler.

It's very simple.

-- external p8 compiler
-- written by dw817

-- note: you must compile this
-- program to exe in order to
-- use it

cls()
repeat
  flip()
until forever

First, type out this code in the P8 source-code editor. Don't add anything else.
Save it. Run it. Press F7 for a screenshot even though nothing is there.

Now remove those 3-lines of repeat, flip, and until forever.

Go to sprites, mapper, sound, add stuff if you want. You don't have to.

When you're done with that, return to the sourcecode and add just below cls() the line:

#include source.txt

Now save this to a filename as a normal .P8 first. You'll get a warning that "could not #include file: source.txt". But don't worry about that. It worked. Then export as an EXE.

export engine.bin

Now with your normal filer, go inside the directory with the EXE, bring up NOTEPAD++

If you don't know what this is, you should get it. It is quite possibly the most powerful text editor on the planet, and it's 100% free.

https://notepad-plus-plus.org/download/v7.7.1.html

Right, now start typing the source-code you want to have. Could be your own program. If you want sprites, mapper, or sound, you need to have created that above before you compiled to EXE.

Here is a sample program to test:

repeat
for i=0,127 do
  for j=0,127 do
    pset(j,i,rnd(16))
  end--next j
end--next i
flip()
holdframe()
until forever

Now in NOTEPAD++ make sure you are saving LF only, not CRLF or CR which cannot be read in Pico-8.

To do so, click in the menu, Edit, EOL Conversion, and UNIX/OSX Format.

To ensure this is the case, from the menu, click, View, Show Symbol, Show All Characters.

Your custom program should now show an inverted LF to represent carriage-returns.

Save it as the filename, "source.txt" Make sure it is saved right where the EXE is located.

Now, you've saved your source-code which could be anything at all. It's time to test it.

Run the executable.

You will see your program run.

This points out something rather important. When you compile to an EXE it is apparently including the entire P8 system instead of creating an EXE that truly does bind your exact source-code to an actual original executable. otherwise it wouldn't know how to interpret the source text you just gave it. And it does.

Now this is not unknown behavior. Other languages I've programmed in such as Delphi Noetic F-Basic for the Commodore Amiga and GFA-Basic for Windows 3.1 all do this.

GFA was clever to create really tiny executables that worked so long as you had on path the main 3-megabyte DLL runtime library.

And we've seen this in countless interpretive programming languages. Both Integer and Floating Point Basic for the Apple ][ and GWBasic and Q-Basic for DOS.

So the real question now is, is this a security breach ? Possibly. Someone could indeed compile to an executable a blank program like I wrote above and then use an editor like NOTEPAD++ to post to SOURCE.TXT and run the executable each time to see their Pico-8 work executed.

Obviously this does not include the slick sprite, map, sound, and music editor. But it DOES work to compile any source-code at all.

Comments, questions, or kerosene ?

I guess this was overlooked.
Though that means you could allow people to mod your game, even if they don't own pico8.

Exactly, ultrabrite.

I hope ZEP is reading this and actually makes a MERGE type of INCLUDE routine where when you compile to EXE or otherwise any INCLUDES are actually MERGED with your data so you have only one executable that cannot read data files that modify the runtime.

It is still interesting that apparently when you compile to EXE - since you can INCLUDE new source-code, that you are not at all in fact compiling to a true EXE but are attaching the entire PICO-8 runtime engine that has your source-code stuffed in it if even tokenized.

It may mean it's possible, however, to take someone's EXE and find the source-code in it and turn it back to text.

I'll be experimenting with that today.

Confirmed, ultrabrite.

I tested to find the word hello, for instance, in the program, using binary examine data:

PRINT"HELLO WORLD."

And could not find the world WORLD in either data.pod, sdl2.dll or the EXE, "test.exe"

Therefore I believe the source-code that is converted to the executable package is indeed being tokenized and perhaps scrambled for protection at that.

Yet you can still include a text file that has source-code in it. Done with this for now.

It should also be possible to convert everything to a single EXE bypassing the need for the two external files of DATA.pod and SDL2.dll.

Thanks @dw817, this is fixed for 0.1.12d

Flattening includes is currently failing for all exports (gah!) so the work-around is to save as a .p8.png first and then export that.

You're very welcome, ZEP. I've got a few more ideas for the 0.1.12d release so I might roll a few your way.

Appreciate you visiting !