r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[SDK]

Maxim
22-Sep-2006
[762]
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).
BrianH
22-Sep-2006
[763x2]
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.
Maxim
22-Sep-2006
[765x3]
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.
BrianH
23-Sep-2006
[768]
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.
Maxim
23-Sep-2006
[769x3]
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.
BrianH
23-Sep-2006
[772]
Yup. That's why I suggested resources - that's how Windows solves 
the same problem.
Maxim
23-Sep-2006
[773]
but for that, the encapped app has to be linked by a real linker 
no?
BrianH
23-Sep-2006
[774x2]
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.
Maxim
23-Sep-2006
[776]
ok, so Encap would need a new main() which loads from the resources...
BrianH
23-Sep-2006
[777x2]
WinMain, but yes.
Or at least some internal native function that loads from the resources, 
and then perhaps unsets itself.
Maxim
23-Sep-2006
[779]
seems like not much work on RT side, since they have C sources... 
 maybe we should bug RT about it...
BrianH
23-Sep-2006
[780]
Sounds good to me. At least Gabriele reads this group - perhaps he 
can relay the ideas.
Maxim
23-Sep-2006
[781x3]
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...
BrianH
23-Sep-2006
[784]
Hey, they're doing all sorts of stuff for R3, this sounds like a 
good idea too
Maxim
23-Sep-2006
[785]
are you aware if rebcode is available within the SDK ?
BrianH
23-Sep-2006
[786]
It is not. It's not even finished, or stable for that matter.
Maxim
23-Sep-2006
[787]
arggghhh  :-)   I was doing wishfull thinking.  I really hope RT 
starts closing loose ends.  it seems to just be creating more and 
more.
BrianH
23-Sep-2006
[788]
I know the feeling.
Maxim
23-Sep-2006
[789]
bye, got to go get some zzzzzz  thanks for the chat  :-)
BrianH
23-Sep-2006
[790]
sleep too :-)
Gregg
23-Sep-2006
[791]
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.
Maxim
28-Sep-2006
[792x5]
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)
Gabriele
29-Sep-2006
[797x2]
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)
Maxim
29-Sep-2006
[799x2]
will do
there is a similar post, I'll add my specificity and refer to the 
other within mine.
Louis
14-Oct-2006
[801x2]
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?
Sunanda
14-Oct-2006
[803x2]
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
BrianH
14-Oct-2006
[805x2]
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.
Louis
14-Oct-2006
[807x2]
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?
Oldes
15-Oct-2006
[809]
Nobody can say as nobody know what script you are talking about and 
what problem you have:-)
Sunanda
15-Oct-2006
[810]
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.
Louis
15-Oct-2006
[811]
Oldes, the script is a double-entry fund accounting package. The 
problem is 2.6.2 dies trying to encap it.