World: r3wp

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.

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.