World: r3wp

doc, did you have kill too? i think that's only on my code, but the 
distinction is so blurred :)

Nope, 'kill support was your code only ; )

well, here is another strange SDK issue.

after encapping, an application works well ONLY if I supply the full 
path to the binary !?!?!?

If I setup the path environment and use an encapped application using 
only the filename, windows resolves the path for me, but I get the 
following error:

PROGRAM ERROR: Invalid encapsulated data

doing more testing, I have figured out that it seems like if the 
app has no "current working dir".  This I achieved by launching it 
through another app in which I have the option of launching with 
or without an explicitely set current working dir .

does this mean I cannot create command-line tools with encap?

encap needs to find itself. if it can not do that, it will not work.

huh?

can you explain more?  cause in the example I am doing... there is 
no dependency on anything external.

say you encap script.r into program.exe

when you run program.exe, rebol start, and it has to load the code 
for script.r, which is embedded into program.exe

the current implementation needs to actually read the file program.exe 
to extract script.r from that

so if it cannot find the program.exe file (i.e., itself), it cannot 
extract the rebol code, and won't work.

but how can it launch itself, and not know where it is... I mean, 
the application actually loads! can't it just use appdir by default?

or is this something only the Shell can provide?

normally it can find itself because the os passes the file path

but, if the os doesn't, then it can't. (that's why, as you say, you 
need to provide a current dir)

is there anything I can do to let XP supply a path when it resolves 
it using the PATH env?

I just wonder why other apps know about the path where DOS prompt 
actually is at, and why encapped apps do not get that info...

python, for example, knows where it is started from and uses current 
prompt  path even though python executable path is resolved from 
path env by OS.

it should get the dos prompt path, but if the program is not there, 
it will fail. i don't know the details, maybe there's just a bug 
in the code.

(rebol may be relying on C's argv[0])

ahhh I think I understand.. actually, my guess is that its BECAUSE 
its using current path.

ie if on linux you run an encapped program under strace or similar 
systems, it will not work (i guess it tries to find the encapped 
data in the strace executable)

since the encapped.exe is not within the current-dir... it fails. 
 hum  I hope this is addressed in R3.  it makes it very hard to create 
system tools.

i have had issues because of this too, so i'll remember to talk about 
it to carl when we get to a r3 sdk :)

thanks :-)

(my guess, is that internally it is doing something like - mixing 
rebol and c - read/binary clean-path argv[0])

(so either argv[0] is a full path, or it must resolve relative to 
current dir)

yeah probably

in R3 the app should actually be compiled from a module stored in 
heap or something... linked on the fly and linked within a rebol.o 
as a string in heap.

i.e. basically storing a mini linker within the encap.exe and storing 
rebol.o and the supplied code as a source.o and linking them directly, 
so that the output would look like it was within rebol mezz code.

and thus loadable without file access.

Can't the script be stored in a resource?

You could even link to DLLs stored in resources - see the source 
of BackOrifice for details.

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.