World: r3wp

I do not know how resources are used or done, but afaict, encap does 
not really compile anything.  It just appends encrypted source code 
to the binary, which is read back directly like a file (probably 
using a preset skip value).

The resources are a data store in the exe or dll where they put stuff 
like the icons, version info, bitmaps and such. You can put arbitrary 
data in resources, including encrypted binary data like that which 
encap turns scripts into before appending onto the interpreter. It 
would be just as easy to put the script in a resource, and then the 
program could always find it without needing the full pathname to 
the program file.

The suggestion about DLLs in resources was more for the proposed 
plugin architecture. The approach used by BackOrifice would work 
quite well here. Just because some people used the program as a hacking 
tool, doesn't mean that it didn't do some things well.

but that would need RT to actually link module code to a loader... 
which they don't do AFAIK.  basically making encap a real linker. 
 I'd rather just have a rebol.o module and perform encapping myself 
using a linker from whatever language I use (even python ;-).  Obviously 
if RT supplied a simple to use encap-like mini compiler/linker. then 
I'd surely use it out of the box.. until iI encountered issue like 
all of those I am having  with current toolset.

right now, it seems as if  all encap does is: 


save %your-script.exe append  Load/binary enface.exe compress load/binary 
your-script.r 


preprocessing just really adds more lines to your-script.r itself.. 
it adds nothing to the binary side of things like the resources which 
you describe.


My guess is that the main() of the enface checks to see if its file 
size is larger than it should and in such a case does:

do to-string decompress skip load/binary argv[0]  base-encap-size


other wise handling the args, finding a script to load, and letting 
extra args flow through to the loaded script.


this way the same binary works for both encapped and core SDK  binaries.

but that is just all assumption, based on all I have accumulated 
in the last week, both using it, finding limitations, and the feedback 
from people here and within what I could find on the net.

I think we are talking about different OSes here - you are clearly 
talking about Linux and I am talking about Windows. Linux likely 
may have something similar to resources in their executables, and 
I think it has a way to determine the (or at least a) location of 
the running executable, so there should be a platform-specific solution 
there too.

nope... talking about windows.

Gabriele admitted that the encapped app, has to re-read the encaped.exe 
file itslef to find data inside of it...

but it should be done like you explain, I agree.

Yup. That's why I suggested resources - that's how Windows solves 
the same problem.

but for that, the encapped app has to be linked by a real linker 
no?

Nope, just a resource editor, and those just call Windows APIs that 
Encap can call.

The linking loader you mentioned is the code from BackOrifice I suggested 
looking at. It only makes sense when you are putting DLLs in resources 
- regular data can be just extracted using Windows APIs.

ok, so Encap would need a new main() which loads from the resources...

WinMain, but yes.

Or at least some internal native function that loads from the resources, 
and then perhaps unsets itself.

seems like not much work on RT side, since they have C sources... 
 maybe we should bug RT about it...

Sounds good to me. At least Gabriele reads this group - perhaps he 
can relay the ideas.

I mean, if its a one hour job from within... Carl and friends might 
say "bah, why not..."

Carl did promise a 1.3.3 release before R3

maybe that could get pushed in too.  it seems to me like a very easy 
fix...

Hey, they're doing all sorts of stuff for R3, this sounds like a 
good idea too

are you aware if rebcode is available within the SDK ?

It is not. It's not even finished, or stable for that matter.

arggghhh  :-)   I was doing wishfull thinking.  I really hope RT 
starts closing loose ends.  it seems to just be creating more and 
more.

I know the feeling.

bye, got to go get some zzzzzz  thanks for the chat  :-)

sleep too :-)

The resource APIs should make it easy, but you can also work against 
PE (Protable Executable) format files directly, editing resource 
tables and such. I wrote a resource compiler in VB a long time ago, 
and did quite a bit of research when writing a resource browser for 
PE files as well.

everyone, I just discovered the reason 'CALL hangs (wihtin SDK or 
straight within rebol/view 1.3.2)

if you do not have the console open, the moment CALL would print 
out something, it gets lost in stdout hell.

so, basically you should always do:


print " " to make sure you have a rebol console window up (or print 
to stdout if using cgi option in view or SDK) otherwise, call hangs 
indefinitely, occupying 100% of your cpu!

(or use Gabriele's async-call  ;-)

(or dockimbel's async-call)

really? that is a very old bug, i had to do that in view 1.2.10, 
but i thought it was fixed in the newer sdk.

maybe it's still in rambo... (if not, please add it max)

will do

there is a similar post, I'll add my specificity and refer to the 
other within mine.

Am I right that  REBOL/Encap 1.2.0.3.1 does not include the round 
function?

What do I have to change in my scripts so they will work with current 
version of encap?

As far as I know the SDK is a version or two behind -- so no round 
(or maybe you have an out of date SDK)
Technically: all you need to do is copy
  source round
  source mod
from a later version of REBOL to your application
Licensing: is that permissable? You may need to ask RTmod: func [
    "Compute a nonnegative remainder of A divided by B."
    [catch]
    a [number! money! time!]
    b [number! money! time!] "Must be nonzero."
    /local r
][
    all [negative? r: a // b r: r + b]
    a: abs a
    either all [a + r = (a + b) positive? r + r - b] [r - b] [r]
]

Oops -- that answers the question "how to gte round to work with 
current SDK"
Your question was the other way around :-(
Plus I cat'npaste'ed too much in my reply

There are more current versions of the SDK that support all of the 
latest toys.

Encap/Face 1.2.0 is a little old - current is 1.3.2, just like with 
View. This is part of the 2.6.2 SDK, available for download for a 
while now.

I also have 2.6.2, but I'm working on a script written several years 
ago, using 1.2.0.3.1, and it won't encap with 2.6.2.

What do I have to change in my script to make it encap with 2.6.2?

Nobody can say as nobody know what script you are talking about and 
what problem you have:-)

More to the point, there is no published list of incompatibilties 
between diffeent versions of REBOL (not that I know of anyway).

Old scripts break in newer versions of REBOL. Some say that is an 
advantage of the language. For the rest of us, it's (at best) an 
annoyance.

Oldes, the script is a double-entry fund accounting package. The 
problem is 2.6.2 dies trying to encap it.