We haven't talked a lot about encapping in Ren-C. But it was at one point written.
I decided to dust it off and bring it up to date. Then I put together a test using the new Ren-C cross-platform GitHub Action. Here you can see encapping working on Linux, Windows, and Mac!
https://github.com/metaeducation/ren-c-encap/actions/runs/695309137
The tests are pretty simple.
-
One of them just gives a spec of a filename and a binary blob to put in the executable. Then it makes sure that can be extracted back verbatim.
-
Another adds actual script code, with a %main.reb. This triggers a convention that the de-encapped code will run such a named script. The test captures the output of running the generated executable and makes sure it printed "Hello Encap".
Why Not Scrap The Encap?
I've been trying to get rid of things that aren't a focus...especially when it comes to C extensions and complex build dependencies that aren't worth their cost.
Encap--however--is entirely usermode code. This means it makes a really good case study for BINARY! parsing. It's exercising the system on a complex real problem.
I'm hoping that the design of UPARSE can be informed from this, because it really showed some weaknesses of binary parsing.
It's On A Stronger Foundation Than Rebol2 Encap
What Rebol2 did was just append data blindly to the end of an executable. That's not a "legitimate" approach; compared to actually understanding the file format (PE on Windows, ELF on Linux, Mach-O on Mac) and injecting a resource in the approved fashion.
When you just append data, a lot of tools and OS checkers will think your file is just corrupt...because it doesn't match the size in the header. A program like strip (which usually gets rid of debug symbols and the like) would just discard it. If you use a tool like a resource editor or an EXE compressor to fiddle with the binary, it could give you an error or throw it away.
(Unfortunately OS X doesn't really have a good way to move around sections of Mach-O executables, so appending is the only choice there.)
(More complex tests should demonstrate the encapping surviving various manipulations...such as resource editing and executable compression. They should also be able to delete and replace the payloads in already-encapped executables.)
A Good Start, But Would Need More Work
When you encap a folder into the executable, it gets zipped up. Right now what happens is that the block of unzipped data is put into system/options/encap and you have to poke around in that block manually.
It would be nice if your script could see that folder as its "current directory"... kind of like the storage scheme. cc: @rgchris If the contents of the ZIP are large you might want it to only expand individual files on-demand. This might suggest being built more generally on a "ZIP file scheme", which can still work if that ZIP file is embedded in a byte range of an EXE file.
The basic invocation of the script is only a placeholder. It doesn't get command line arguments, for instance. And since I'm hacking on the module system on another branch, I'm going to get that sorted out before worrying too much about it.