World: r3wp

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.

Sunanda, that is what I was afraid of.  Without such a list I doubt 
that I could convert.  I'll just have keep and use my old version 
of the SDKI for encapping this script.

Thank all of you guys for your comments.

How it dies? Is it screaming? :-)

It just lies down on its back, vomits out some meaningless error 
messages (perhaps confessing past sins), then quits breathing. Doesn't 
even blink an eye.  Then I click a button and it completely disappears, 
buried somewhere on my hard drive.  I dig it up and try to revive 
it, but it is hopeless....at least for now. :>) I'm trying to get 
over it, but it is hard.

Sunanda: well, porting the Detective (which is 700k of uncompressed 
rebol code) from view 1.2 to 1.3 required only removing a patch for 
a bug in 1.2. everything else works without any change.

Oldes, I have to eat some words. 2.6.2 encaps the script. But when 
I run the encapped script I get this error message:

Misplaced item: "imanXw"
** Script Error: Cannot use path on word!
value
** Near: insert tail funds fb/1
** Press enter to quit...

Does that help you, or Gabriele or someone know what is wrong?

If %view.r from the old SDK is included instead of %view.r from the 
new SDK, the script runs but gives the following error message:

Misplaced item: "imanXw"
Misplaced item: "Quit"
Misplaced item: [
    (write %session-time.txt (session-time
 + (difference now/precise time-start)))
    (write %exchange-rate.txt exchange-rat
e/text)
    quit
]