World: r3wp

I was apparently DO'ing a binary. Sorry, must be tired :-)

the windows sdk 2.7.5 distribution is lacking encmdface.exe

Feedback sent to RT.

and the latest encmdface in the download directory is from 2004

does anyone have problems starting encap in Wine? it keeps complaining 
that the license key is missing, but it's stored in the same dir 
as encap.exe

technicalities were the trouble, but it works now.

This is probably a Gregg question: You know that ftpgadget package? 
How do I compile that thing? I think I've tried just about every 
.exe in the SDK (2.6.2) and I think maybe I need to "do" some of 
those sources but there some trick to those as well. It's time just 
to consult the experts. Thanks in advance.

James;  Gregg is away till the 9th; there may be a delay in response

Thanks!

when I start an encapsulated binary with call and within that binary 
call yet another encapsulated binary (this is an installation process, 
hence the cascading execution), the second time, I get a:

PROGRAM ERROR: Invalid encapsulated program data.


is this a security issue? because when the binary is run from Explorer 
it runs fine.

the error is not listed in SDK docs...

solved by entering the full path to the executable when doing the 
call.

unless the data is actually invalid (ie never runs), that error usually 
means that rebol is not able to locate itself to load the script 
to run. ie. yourapp.exe must be able to read the yourapp.exe file 
in order to load the rebol script.

I get the same problem sometimes with 'launch

which is the encapped program starting up another instance of itself.

James, maybe Edgar will jump in. I was responsible for helping to 
get the source on REBOL.org, but I don't think I've ever tried to 
build it here.

OK, thanks.

Funny thing: on my linux VPS the SDK : /Base /Pro work. Rebcmd gives 
the following error:

/rebcmd: error while loading shared libraries: libstdc++-libc6.2-2.so.3: 
cannot open shared object file

Any advice/thoughts know solutions?

(I think Pro suffices anyway though. It has encryption and FastCGI 
on board)

Nevermind.... fixed it with a locate query and a symbolic link

That's why I preferr a static link, simple, works and hd space is 
cheap.

Question: if I put the SDK in my PATH on win32 and start rebpro from 
an different location, it complains that the license.key can't be 
found. Can I put it somewhere so that I can run /Pro etc from any 
location?

I haven't figured out a way.

Yes, just put the license.key file into the directory where the SDK 
tools are.

I did that, but sya there arein sdk\tools

Then I cal from c:\temp rebpro and I geta license not found....

I straced my rebpro (Linux) and it looks in the home directory and 
the current working dir for the key.  It does not seem to check the 
dir where the actual binary is launched from.


Same for REBOL/View 1.3.2.  Can't say how the lookup may work for 
the Windows side; strace fails creating a rebol process under cygwin. 
 Someone might try holodeck.


I can't say I'm a huge fan of leaving a copy of the key in my home 
dir, but no more chasing that tail around on the Dev box at least. 
 :)

Linux is not the problem, windows is :(

Does enface return a value for use in .cmd scripts?  I wish to run 
a cmd script that enfaces a rebol script, and if sucessful, then 
to run the encapped program

something like this

if enface.exe myscript.r  -o myscript.exe [
 myscript.exe
]

but using the cmd shell syntax

I don't think so Graham. Normally I do it all from REBOL and wait 
for the output file to appear.

When I launch an encapped script (.exe) from AltME, I get it run 
from a parent parent .. directory, like the root of the world, rather 
than the directory the .exe is in, but with .r I get the real current 
directory.  Is there a way to get the real directory easily from 
the encapped script (.exe)?

Try system/options/path.

Or failing that, first split-path system/options/boot ; they should 
be the same.

yes, first one fails, so I have to split-path on the second.  Thanks.

I was just guessing :)

I had to do some conditionals to make it operate the same as a script 
vs. .exe but I think I have that working.

How does the first one fail? What does system/options/path turn out 
to be?

The Script.r works from current directory, no monkey-shines (if I 
use system/options/boot then it uses the diretory where View is) 
encapped script.exe uses


change-dir first split-path system/options/boot ;so it then thinks 
it's in the same folder as the script.r which in fact is actually 
is.

...comes from studying script.r (religious joke)

Which folder do you need? The system/options/path is supposed to 
be the current directory from which you started the script. Is that 
the case with a encapped script?

(remember I am launching it from AltME...so there is an extra level 
of cornfusion)

It seems to think it is in the altme-root of the world.

so systems/options/path was not the same even though they were synce'd 
in the same AltME files/folder

I suspect that AltME is starting applications from its current directory 
(the root dir of the world), while starting documents from their 
directory. A REBOL script is just a document as far as AltME is concerned.

In that case the script.r was right, but the script.exe was giving 
the C:/program files/alme/worlds/gop-gasflation/   instead of  C:/program 
files/alme/worlds/gop-gasflation/files/folder

Yeah, so we have to blame both.

I suspect that applications are started using call and scripts with 
shellexecute.