Well, that proves there is still someone at the helm. I haven't communicated with RT regarding the SDK since last year.

Yes, there is someone there at the other end.  BTW, using 2.7.8 fixed all my issues.
yes quite a few bugs fixed in 2.7.8   :-)

When I run an encapped executable, I get the "Not enough memory" error. I remember seeing this before, but is it related to being unable to unpack the encapped source?
rebooting windows helped.
I haven't seen that in so long that I don't remember possible causes. I think there are values that cause problems when encapped, and also certain encap header values that can trigger it.

serialized values get corrupted when encapped... which is why I had to rebuild my own prebol engine from scratch.  I also wrapp my main source within a string, to be sure that the encap app doesn't corrupt my code.
Thanks Max.
(forgot to mention that I just just DO that string, which is the whole encapped source.  basically equivalent to just running the script.)
so my script, once assembled looks like this:
rebol [ ... ]   ; put what you want in the header
#include mezz/...   ; whatever mezz code I need.
do { ... } ; the whole script, including results of my own extensive pre-processing toolchain
Henrik, that's usually (but not necessarily always) because of DECOMPRESS. REBOL just takes the last four bytes (IIRC) of the binary as the original size, and tries to allocate that much memory.
so, if REBOL can't find the encapped data correctly, the binary passed to DECOMPRESS will be wrong and is likely to cause that.
Gabriele, yes I realize that now. I was simply wondering why one had to reboot windows in order to fix the problem.
larger contiguous memory areas

well, the question is why was rebol failing at loading the encapped data.

Are there any reported problems with enface.exe hanging, when trying to build a source file, where ENCAP: "" exists in the header?

continuing from ~chit chat group...
guys... some of my code doesn't run when pre-processed.   I never use encap to pre-process it, I always run pre-rebol manually.  The result of this doesn't execute without errors.  
My version of pre-rebol even had MOLD replaced with MOLD/ALL and that created new bugs.   only using my string version of pre-processor, has the original code been able to be linked into one source without having execution bugs.
I also had to workaround the encap issue which automatically calls a pre-process on my linked file .
Why is everyone trying to tell me I'm not having these issues.  
I'm simply letting you guys know that block-based pre-processors mangle the data in some cases, and that string-based pre-propressing is safer (and much more flexible).    Note that my pre-processor uses load/next when it finds some keywords.
The prebol preprocessor was designed to use MOLD. Just switching it to use MOLD/all isn't enough, you have to design it to use MOLD/all, the way Ladislav's include is. Also, even if you make your own MOLD/all safe prebol, the encapper still runs your code through the non-safe regular prebol as part of the encapping process, so it doesn't help. It is definitely possible to make a complex MOLD/all safe preprocessor, but I can't be sure that is what you did. The fact that you had bugs created by your preprocessor suggests not.
my preprocessor wraps the code into a string so that the encapper's internal prebol can't touch it.
in effect the result of my engine is listed just above in the Sept 2 post  :-)

Last message posted 49 weeks ago.