rebol/rebol — pull request #157 by hostilefork (2013-09-30 18:48:57+00:00)
Title: Reduce mem/time for boot and tighten up sizes (appears to fix MSVC build)

Rebol's native function specifications ship in the binary, and as they are textual they are compressed with the DEFLATE algorithm from ZLIB.

When trying to run Rebol under VC2010 Express, this decompression code would crash a good bit of the time (but work sometimes(?)). I began to tighten up the boot code to get a handle on what was going on.

The compressed data was munged with a cryptographically weak scrambler called [Cloak() a.k.a. encloak](https://github.com/rebol/rebol/blob/4d9840f8e661e7067472e828ee6ad8dd3008b247/src/core/s-ops.c#L296). Scrambling the compressed textual representation of the Rebol natives represents no advantage I can imagine. It just means a roughly 50K buffer is copied and churned on every boot...rather than just using the constant array as-is. So I removed that.

I also removed some unused options. NON_ENCODED_BOOT which did not have corresponding code in %make-boot.r. There was also an unused ->script field of Boot_Block. Added a precise double check and got rid of the arbitrary boot decompression limit of "200000". Also...if had to make a wild guess about the question posed by Carl in u-compress.c:

output = Make_Binary(size + 20); // (Why 20 extra? -CS)

...I'd think it was related to the 20 byte length of the checksum/secure of "REBOL Version 3.0". Perhaps something to do with the cloaking algorithm at some point in time--expecting the buffer to have at least the cloaking key length of extra space at the end? It certainly seems arbitrary, and not seeing any other 20s I decided to axe it.

After this, I couldn't get the MSVC build to crash on the boot anymore. Don't really see why. Could be a fluke, and maybe it will crash again at some point?