1. Bind features
First of all, Rod's problem with 'altering' or 'removing' code because it
effects the program size, can be discarded.
If you want your programs to run on machines with so little memory, why bind
in the first place ? (duh)
Secondly, now I think of it, bind could even do a lot of optimizations, and
inline routines with less that X-number of statements.
Routine-id can cause problems when 'inlining' and 'removing' un-used
routines, however for each file routine-id is not used, all *local* routines
can be removed. All un-used identifers should have issued a warning anyway.
(why not for *all* identifers, during the bind-proccesing, proposing the
simple question:
"Routine my_routine is not used throughout the whole program, do you want it
to remain ? (y/n)"
Also, about the binder/shrouder: for editors and alike, why not keep the
core in a library, shrouded, and the command-line interface as a dos32
program ? (a simple interface that just used the core-library to shroud and
bind program files)
What I would also like (I know, some one else could write as well, but
standarizing *this* makes sence), is a library routine that parses Euphoria
code. You need it for the binder/shrouder anyway. The library could even
offer a simple interpretation routine (not to hard to implement). Yes, off
course it would run slower than when the interpreter executes it itself, but
at least its something. (I don't see Robert implementing dynamic loading of
include files, or even better, 'virtual programs').
And when the parser-code of the binder/shrouder is moved to a standard
Euphoria include, a simple analizing tool can be made fairly easy as well.
Also, why not have *ONLY* the part of the binder/shrouder that encrypts in
encrypted form (together with the tokinzer: just the output-library), while
have the rest remain open source code, so we can add new features to the
binder ourselves, such as excluding certain include files (configuration
files as Eu-includes), incorporation resource-files (David's creation), etc.
We could even add simple optimizers. (for example, for the
xvcxc[23][23][32][423] type of repeated statement: speeding the source code
up by using dummies often complicates the code as well)
Ideas anyone ?
Ralf N.
nieuwen at xs4all.nl
UIN: 9389920
PS. Irv: No france beach for me this year, my own rainy country must do, for
now, anyway.
2. Re: Bind features
- Posted by Scott Murray <FaIkon1313 at AOL.COM>
Jun 28, 1999
-
Last edited Jun 29, 1999
>From: Ralf N.
>What I would also like (I know, some one else could write as well, but
>standarizing *this* makes sence), is a library routine that parses Euphoria
>code. You need it for the binder/shrouder anyway. The library could even
>offer a simple interpretation routine (not to hard to implement). Yes, off
>course it would run slower than when the interpreter executes it itself, but
>at least its something. (I don't see Robert implementing dynamic loading of
>include files, or even better, 'virtual programs').
I would also like to see this. It would be a great starting point for
making/emulating scripting languages in Euphoria and for making multi-line
pre-processors.
3. Re: Bind features
Ralf Nieuwenhuijsen wrote:
>First of all, Rod's problem with 'altering' or 'removing' code because it
>effects the program size, can be discarded.
>If you want your programs to run on machines with so little memory, why bind
>in the first place ? (duh)
???
I'm not sure I'm understanding you correctly here, Ralf. Are you saying
a bound program takes up much more space in RAM than the interpreter and
the unbound source would together?
>Secondly, now I think of it, bind could even do a lot of optimizations, and
>inline routines with less that X-number of statements.
>
>Routine-id can cause problems when 'inlining' and 'removing' un-used
>routines, however for each file routine-id is not used, all *local* routines
>can be removed. All un-used identifers should have issued a warning anyway.
I've thought about the merits of inlining; especially in cases where
the routine is a function consisting of:
function x (...)
return <expression>
end function
the speed gains might be great (I'm constantly amazed at how relatively
low the overhead is for a routine call in Euphoria.) Of course, there's
still the routine_id problem (except for the local exception you described).
But another problem also comes to mind: error tracing. Pure, clean inlining
would mean that if your routine had an error, it would be very difficult to
track it to your routine. And if you included extra code, identifiers, etc.
to keep track of the fact that an "inlined" routine is being executed, and
what it's name is, you lose much of the advantage of inlining the code to
begin with.
>Also, about the binder/shrouder: for editors and alike, why not keep the
>core in a library, shrouded, and the command-line interface as a dos32
>program ? (a simple interface that just used the core-library to shroud and
>bind program files)
Well, if I were the one writing Euphoria, I don't think I'd want any of it
to be open source... *especially* parts of the binder, if that's what I
plan on using as an incentive to get people to register. Even making just
the main interface and parser freely available would seem like giving too
much away.
Granted, I'd be interested in examining the code (NOT in modifying it), but
I think the chance of any of us ever doing that is close to nil.
Rod Jackson
4. Re: Bind features
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Jun 29, 1999
-
Last edited Jun 30, 1999
> Ralf Nieuwenhuijsen wrote:
> >First of all, Rod's problem with 'altering' or 'removing' code because it
> >effects the program size, can be discarded.
> >If you want your programs to run on machines with so little memory, why
bind
> >in the first place ? (duh)
I'm assuming you were talking about conventional memory (where the
executable has to remain in)
If you talking about the type of program that would easily exceed extended
memory in program size, you might not be able to have it launch as an bound
program in the first place.
> I'm not sure I'm understanding you correctly here, Ralf. Are you saying
> a bound program takes up much more space in RAM than the interpreter and
> the unbound source would together?
No, the storage method however differs. Nevertheless, binding is not meant
for the very low-end systems.
I mean, I don't know any 286, without extended memory but with a 2.1 gig
harddrive, do you ?
I just can't really come up with any 'real-life' example where you really
want to a) bind, b) have unused constants remain for c) memory issues.
> >Secondly, now I think of it, bind could even do a lot of optimizations,
and
> >inline routines with less that X-number of statements.
> >
> >Routine-id can cause problems when 'inlining' and 'removing' un-used
> >routines, however for each file routine-id is not used, all *local*
routines
> >can be removed. All un-used identifers should have issued a warning
anyway.
>
> I've thought about the merits of inlining; especially in cases where
> the routine is a function consisting of:
>
> function x (...)
> return <expression>
> end function
>
> the speed gains might be great (I'm constantly amazed at how relatively
> low the overhead is for a routine call in Euphoria.) Of course, there's
> still the routine_id problem (except for the local exception you
described).
Problem ? If its small enough to inline everywhere, you can easily keep the
original routine in source code, so routine-id works correctly.
> But another problem also comes to mind: error tracing. Pure, clean
inlining
> would mean that if your routine had an error, it would be very difficult
to
> track it to your routine. And if you included extra code, identifiers,
etc.
> to keep track of the fact that an "inlined" routine is being executed, and
> what it's name is, you lose much of the advantage of inlining the code to
> begin with.
You bind you programs when you are developping and debugging them ?
A lot of programs will crash, when bound, with the 300-statement thingie,
since bind uses the pd-version of the interpreter, rather than the
registered version. (logically)
> >Also, about the binder/shrouder: for editors and alike, why not keep the
> >core in a library, shrouded, and the command-line interface as a dos32
> >program ? (a simple interface that just used the core-library to shroud
and
> >bind program files)
>
> Well, if I were the one writing Euphoria, I don't think I'd want any of it
> to be open source... *especially* parts of the binder, if that's what I
> plan on using as an incentive to get people to register. Even making just
> the main interface and parser freely available would seem like giving too
> much away.
Why ? It can only be used BY euphoria programs. Its not giving away C-code
to parse Euphoria programs, it giving away Euphoria code to parse Euphoria
code. Who would benefit ? Euphoria coders, the people that pay Robert's
bill. It sounds logical to me.
> Granted, I'd be interested in examining the code (NOT in modifying it),
but
> I think the chance of any of us ever doing that is close to nil.
Rod, the binder is an shrouded Euphoria code. It is shrouded so we can't see
the (optional) encryption code, so we can't crack it.
All other parts of tools in Eu-code are fully open-source and even well
commented.
Guess, Robert is less paranoid than you assume.
Ralf
5. Re: Bind features
Message below SNIPPED but not taken out of context.
I like the idea of an inline feature and I agree with the idea
of Leaving the original routine there for the purpose of routine_id()
calls. I definately suggest that the inline feature be an option
that can be selected during the binding/shrouding process.
It be an option for the following reason. If inline is off it
would be easier to detect where the problem arose in the code.
Obviously either the inline should be limited to a number of
statements. About 10-20 statements should be more than reasonable.
Also there could be an inline trigger so that only certain code
is inlined. Of course inline would be default set to without.
with inline
function sign(object input)
return ((input > 0) - (0 > input))
end function
without inline
Lucius L. Hilley III
lhilley at cdc.net
+----------+--------------+--------------+
| Hollow | ICQ: 9638898 | AIM: LLHIII |
| Horse +--------------+--------------+
| Software | http://www.cdc.net/~lhilley |
+----------+-----------------------------+
> ---------------------- Information from the mail
header -----------------------
> Poster: Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
> Subject: Re: Bind features
> --------------------------------------------------------------------------
-----
>
> >
> > I've thought about the merits of inlining; especially in cases where
> > the routine is a function consisting of:
> >
> > function x (...)
> > return <expression>
> > end function
> >
> > the speed gains might be great (I'm constantly amazed at how relatively
> > low the overhead is for a routine call in Euphoria.) Of course, there's
> > still the routine_id problem (except for the local exception you
> described).
>
> Problem ? If its small enough to inline everywhere, you can easily keep
the
> original routine in source code, so routine-id works correctly.
>
> > But another problem also comes to mind: error tracing. Pure, clean
> inlining
> > would mean that if your routine had an error, it would be very difficult
> to
> > track it to your routine. And if you included extra code, identifiers,
> etc.
> > to keep track of the fact that an "inlined" routine is being executed,
and
> > what it's name is, you lose much of the advantage of inlining the code
to
> > begin with.
>
> You bind you programs when you are developping and debugging them ?
> A lot of programs will crash, when bound, with the 300-statement thingie,
> since bind uses the pd-version of the interpreter, rather than the
> registered version. (logically)
>
> Guess, Robert is less paranoid than you assume.
>
> Ralf
>
6. Re: Bind features
Ralf Nieuwenhuijsen wrote:
>I just can't really come up with any 'real-life' example where you really
>want to a) bind, b) have unused constants remain for c) memory issues.
As a long-term goal, I'd like to make a game of some sort in Euphoria. I
have a few ideas I've been developing toward that goal. I've seen a few
Euphoria games already, and like with most other games, it's not uncommon
for these games to have many associated bitmap, sound, etc. files. Obviously,
I would expect mine to have associated files. Lately however, I've been
thinking through the benefits of putting some of the file data directly into
the source code, as constants.
If this is done, these files could wind up making large in-memory sequences,
either individually or in total. If the sequence(s) is/are used in primarily
one location in the program, which I comment out during testing/debugging,
I think I'd like any memory taken up by those constants to remain "occupied".
Would I seriously bind under this kind of condition, while still testing
and with the temporary comment still in place? Yes, I would....
It's not exactly an everyday scenario (you might not even consider it
"real-life"), but I wouldn't be in a hurry to dismiss it. Not that it matters;
letting the code removal be optional makes it a moot point.
>> >Secondly, now I think of it, bind could even do a lot of optimizations,
>and
>> >inline routines with less that X-number of statements.
>> >
>> >Routine-id can cause problems when 'inlining' and 'removing' un-used
>> >routines, however for each file routine-id is not used, all *local*
>routines
>> >can be removed. All un-used identifers should have issued a warning
>anyway.
>>
>> I've thought about the merits of inlining; especially in cases where
>> the routine is a function consisting of:
>>
>> function x (...)
>> return <expression>
>> end function
>>
>> the speed gains might be great (I'm constantly amazed at how relatively
>> low the overhead is for a routine call in Euphoria.) Of course, there's
>> still the routine_id problem (except for the local exception you
>described).
>
>Problem ? If its small enough to inline everywhere, you can easily keep the
>original routine in source code, so routine-id works correctly.
Mmm, interesting. I'm somewhat wary of that soulution, but rather
than wade through nagging quibbles (and considering I don't have an
alternative), I'll say it sounds like the simplest and most feasible
approach.
>> But another problem also comes to mind: error tracing. Pure, clean
>inlining
>> would mean that if your routine had an error, it would be very difficult
>to
>> track it to your routine. And if you included extra code, identifiers,
>etc.
>> to keep track of the fact that an "inlined" routine is being executed, and
>> what it's name is, you lose much of the advantage of inlining the code to
>> begin with.
>
>You bind you programs when you are developping and debugging them ?
>A lot of programs will crash, when bound, with the 300-statement thingie,
>since bind uses the pd-version of the interpreter, rather than the
>registered version. (logically)
Actually, if I were writing a program of such magnitude or value that I
intended to only distribute the bound version, I would *definitely* bind
and test things out periodically.
But yes, I also see your point. I'm so used to the registered version
that I've forgotten what it's like to hit that 300-statement limit.
Note: I'm not saying we should throw away the idea of inlining,
especially as a bind option. I was, however, thinking of problems that
might need to be addressed.
>> >Also, about the binder/shrouder: for editors and alike, why not keep the
>> >core in a library, shrouded, and the command-line interface as a dos32
>> >program ? (a simple interface that just used the core-library to shroud
>and
>> >bind program files)
>>
>> Well, if I were the one writing Euphoria, I don't think I'd want any of it
>> to be open source... *especially* parts of the binder, if that's what I
>> plan on using as an incentive to get people to register. Even making just
>> the main interface and parser freely available would seem like giving too
>> much away.
>
>Why ? It can only be used BY euphoria programs. Its not giving away C-code
>to parse Euphoria programs, it giving away Euphoria code to parse Euphoria
>code. Who would benefit ? Euphoria coders, the people that pay Robert's
>bill. It sounds logical to me.
Since my instinct would be to write a Euphoria parser in Euphoria using a
similar algorithm as in the C source, I'd probably be very wary of releasing
the parser, assuming the C algorithm wasn't open.
Clarification: by "any of it" I mean the C source code, and any important
Euphoria source code (read: the binder). I don't count example code (with
the possible exception of the editor), standard library routines like in
sort.e, etc.
>> Granted, I'd be interested in examining the code (NOT in modifying it),
>but
>> I think the chance of any of us ever doing that is close to nil.
>
>Rod, the binder is an shrouded Euphoria code. It is shrouded so we can't see
>the (optional) encryption code, so we can't crack it.
>All other parts of tools in Eu-code are fully open-source and even well
>commented.
>
>Guess, Robert is less paranoid than you assume.
As it stands, Rob hasn't seen fit to make Euphoria open-source (otherwise
we'd have the C code for the interpreter already, and we would be getting
it for Linux.) I definitely wouldn't mind if he made it so in the future,
but right now that doesn't seem likely.
Rob also hasn't seen fit to make the binder open-source. Encryption security
is an obvious reason not to, but considering its value even apart from that,
he might have still shrouded the program had there been no encryption option.
Or he might not have; Rob would have to respond to this thread himself for us
to know. I would still have shrouded it. That being so, if we never see parts
of the binder code available, I wouldn't be surprised. If we do, I'll be both
surprised and extremely interested. 
Rod Jackson
7. Re: Bind features
> Ralf Nieuwenhuijsen wrote:
> >I just can't really come up with any 'real-life' example where you really
> >want to a) bind, b) have unused constants remain for c) memory issues.
>
> As a long-term goal, I'd like to make a game of some sort in Euphoria. I
> have a few ideas I've been developing toward that goal. I've seen a few
> Euphoria games already, and like with most other games, it's not uncommon
> for these games to have many associated bitmap, sound, etc. files.
Obviously,
> I would expect mine to have associated files. Lately however, I've been
> thinking through the benefits of putting some of the file data directly
into
> the source code, as constants.
Be warned with constants, they are in memory twice. Once in your source, and
once in the allocated memory for that constant. However, fortunately,
Euphoria, being one-pass will remove the memory the constant is using the
first time it reads the constant decleration. However, this is, when the
program is *not* bound. Otherwise, the executable is loaded, as a whole,
into the memory by the operating system.
Like I said, why bind, when memory is such an issue. You're much better off
using David's resource memory and a seperate resource file, if you do like
your game to be an executable.
> If this is done, these files could wind up making large in-memory
sequences,
> either individually or in total. If the sequence(s) is/are used in
primarily
> one location in the program, which I comment out during testing/debugging,
> I think I'd like any memory taken up by those constants to remain
"occupied".
So, why not insert a dummy statement, so the binder does not remove them.
Something like:
object dummy
dummy = my_unused_object
Btw, being totally unused, is very rare, for things of this size.
The 'removal' is better applied upon *routines* and associated comments that
are part of libraries included, but not used by the program at all.
> Would I seriously bind under this kind of condition, while still testing
> and with the temporary comment still in place? Yes, I would....
Yes, to check the amount of memory. A simple calculation would do as well,
but, true I see a very rare case.
> It's not exactly an everyday scenario (you might not even consider it
> "real-life"), but I wouldn't be in a hurry to dismiss it. Not that it
matters;
> letting the code removal be optional makes it a moot point.
Optional. Precizely why I at least want the front-end of the binder, which
might not be more than a few library calls, open-source. Also, for better
integration with development enviroments, for example.
> Mmm, interesting. I'm somewhat wary of that soulution, but rather
> than wade through nagging quibbles (and considering I don't have an
> alternative), I'll say it sounds like the simplest and most feasible
> approach.
Wary ? Actually, inlining should only occur in certain routines and not all
routines.
Sometimes, inlining could *slow* down the program rather than *speeding* it
up.
Something to do wiht cache-sizes, I suppose.
But below a minimum and above a maximum size of statements, inline should
speed it up.
> >> But another problem also comes to mind: error tracing. Pure, clean
> >inlining
> >> would mean that if your routine had an error, it would be very
difficult
> >to
> >> track it to your routine. And if you included extra code, identifiers,
> >etc.
> >> to keep track of the fact that an "inlined" routine is being executed,
and
> >> what it's name is, you lose much of the advantage of inlining the code
to
> >> begin with.
> >
> >You bind you programs when you are developping and debugging them ?
> >A lot of programs will crash, when bound, with the 300-statement thingie,
> >since bind uses the pd-version of the interpreter, rather than the
> >registered version. (logically)
>
> Actually, if I were writing a program of such magnitude or value that I
> intended to only distribute the bound version, I would *definitely* bind
> and test things out periodically.
That's not my point. The error-messages you were refering to do not apply to
bind.
Btw, the error message, can't make any sense anyway, since all identifers
are 'tokinezed' as well.
You wouldn't know which variables it is about.
Short and simple: if my routine had an error, euphoria does not need to
know it was inlined, it would not see the difference with the real code, and
thus, you do not loose the advantage. You run the code again, unshrouded,
unbound and you get a clean, fresh, normal, human-readable error-message.
> Note: I'm not saying we should throw away the idea of inlining,
> especially as a bind option. I was, however, thinking of problems that
> might need to be addressed.
The problem already existed: error messages from bound programs are hard to
decipher.
> >> >Also, about the binder/shrouder: for editors and alike, why not keep
the
> >> >core in a library, shrouded, and the command-line interface as a dos32
> >> >program ? (a simple interface that just used the core-library to
shroud
> >and
> >> >bind program files)
> >>
> >> Well, if I were the one writing Euphoria, I don't think I'd want any of
it
> >> to be open source... *especially* parts of the binder, if that's what I
> >> plan on using as an incentive to get people to register. Even making
just
> >> the main interface and parser freely available would seem like giving
too
> >> much away.
> >
> >Why ? It can only be used BY euphoria programs. Its not giving away
C-code
> >to parse Euphoria programs, it giving away Euphoria code to parse
Euphoria
> >code. Who would benefit ? Euphoria coders, the people that pay Robert's
> >bill. It sounds logical to me.
>
> Since my instinct would be to write a Euphoria parser in Euphoria using a
> similar algorithm as in the C source, I'd probably be very wary of
releasing
> the parser, assuming the C algorithm wasn't open.
Again, the only reason the binder/shrouded itself has been shrouded, is to
sheal the encryption routines.
Many other tools (take a look in your /bin directory) are fully coded.
You really think, Euphoria's power comes from its parsing routines ?
The parsing routines, my guess, in the binder, aren't even close to those in
the interpreter.
Why ? Because they 1) are for different purposes. 2) are written, and
optimized for different languages 3) are/will-be one-pass/2-pass.
Whatever it is, its Robert's choice, but I, for one, would love to see some
standard parsing routines that return Euphoria code in some structured
sequence, as a standard Euphoria library. (shrouded or not
> Clarification: by "any of it" I mean the C source code, and any important
> Euphoria source code (read: the binder). I don't count example code (with
> the possible exception of the editor), standard library routines like in
> sort.e, etc.
I didn't count example code either. Go have a look at your /bin directory.
> >> Granted, I'd be interested in examining the code (NOT in modifying it),
> >but
> >> I think the chance of any of us ever doing that is close to nil.
> >
> >Rod, the binder is an shrouded Euphoria code. It is shrouded so we can't
see
> >the (optional) encryption code, so we can't crack it.
> >All other parts of tools in Eu-code are fully open-source and even well
> >commented.
> >
> >Guess, Robert is less paranoid than you assume.
>
> As it stands, Rob hasn't seen fit to make Euphoria open-source (otherwise
> we'd have the C code for the interpreter already, and we would be getting
> it for Linux.) I definitely wouldn't mind if he made it so in the future,
> but right now that doesn't seem likely.
I wasn't talking about open-source. I can completely understand his choice.
All I ask for, is when he develops his new parsing routines, in Euphoria
code, for the binder (the 2-pass parser), why not make them as generic as
possible and available as include files. (shrouded or not).
And have the front-end of the binder open-source, which may just look like:
------- bind.ex
include bind.e -- shrouded file
puts (fh, bind ( encrypt ( shroud ( the_code ) ) ) )
-------------
Nothing given away here, yet it can be integrated much easier with
development tools and such.
> Rob also hasn't seen fit to make the binder open-source. Encryption
security
> is an obvious reason not to, but considering its value even apart from
that,
> he might have still shrouded the program had there been no encryption
option.
> Or he might not have; Rob would have to respond to this thread himself for
us
> to know. I would still have shrouded it. That being so, if we never see
parts
> of the binder code available, I wouldn't be surprised. If we do, I'll be
both
> surprised and extremely interested.
You obviously missed my point, what I wanted, and more precizely _why_ I
wanted it it that way.
I couldn't care less about open-source, I detest C-code and I don't intent
to copy Euphoria.
Ralf
8. Re: Bind features
Well, I've finally compiled my Pretender demo under Llama, using my own
version of shroud. In addition to creating unique identifiers for non-core
identifiers, it also resolves strings in the routine_id function.
For some reason, Euphoria doesn't like any 'with' commands (trace/etc. or
magic numbers). Once they were removed from the file, I could bind it up
just fine. It leaves the 'core' routines alone, so you get code that looks
like:
procedure id_34( sequence id_35, integer id_36 )
puts( 1, "%d", id_35 )
id_36 += 23
end procedure
id_37 = routine_id( "id_34" )
I need to add a command line interface to it, and clean it up a bit. It's
not especially clever - the code for handling global vs. local binding will
raise the hair on your neck, but it seems to work fine.
If people are interested, I'll send it off to Robert, probably later
tomorrow. I don't think he'll have any objections to posting it, but I could
be wrong. There aren't any trade secrets involved, since the description of
how shroud is fairly well known. As you can see, it doesn't encode any of
the 'core' routines ('puts' is left as 'puts', etc.). I'm not sure how
useful it is, since Robert is going to fix bind/shroud anyway.
-- David Cuny
9. Re: Bind features
Ralf Nieuwenhuijsen wrote:
>Be warned with constants, they are in memory twice. Once in your source, and
>once in the allocated memory for that constant. However, fortunately,
>Euphoria, being one-pass will remove the memory the constant is using the
>first time it reads the constant decleration. However, this is, when the
>program is *not* bound. Otherwise, the executable is loaded, as a whole,
>into the memory by the operating system.
Ah, I did not realize that. Thanks; this does kill most benefits...
>> As it stands, Rob hasn't seen fit to make Euphoria open-source (otherwise
>> we'd have the C code for the interpreter already, and we would be getting
>> it for Linux.) I definitely wouldn't mind if he made it so in the future,
>> but right now that doesn't seem likely.
>
>I wasn't talking about open-source. I can completely understand his choice.
>All I ask for, is when he develops his new parsing routines, in Euphoria
>code, for the binder (the 2-pass parser), why not make them as generic as
>possible and available as include files. (shrouded or not).
>
>And have the front-end of the binder open-source, which may just look like:
>
>------- bind.ex
>
>include bind.e -- shrouded file
>
>puts (fh, bind ( encrypt ( shroud ( the_code ) ) ) )
>
>-------------
>
>Nothing given away here, yet it can be integrated much easier with
>development tools and such.
I understand now. That does seem harmless, even if the encrypt() function
wasn't made available (otherwise you'd be able to encrypt anything you
wanted, making cracking it much easier.)
But it also seems to give others a liscense to include the bind library in
their code, and sell it or give it away (or some variant of it) on their
own. I assume there would be restrictions against that if this ever came
about.
Rod Jackson
10. Re: Bind features
Ralf writes:
> A lot of programs will crash, when bound, with the
> 300-statement thingie, since bind uses the pd-version of
> the interpreter, rather than the registered version. (logically)
Registered users of bind (which in 2.1 is all users of bind)
do not have a 300 limit in their bound .exe files.
Ralf writes:
> Be warned with constants, they are in memory twice.
> Once in your source, and once in the allocated memory for
> that constant. However, fortunately, Euphoria, being one-pass
> will remove the memory the constant is using the first time it
> reads the constant decleration. However, this is, when the
> program is *not* bound. Otherwise, the executable is loaded,
> as a whole, into the memory by the operating system.
1. After processing a constant declaration, all the data and
code used in calculating the constants value is freed. e.g.
constant SIZE=10+100-22*foobar({1,2,3,4,5})
Some intermediate code and temporary data is
generated to evaluate this expression, but it's all freed up
after it runs, leaving just the final result in memory.
This is true of any statement that executes at
the "top-level", outside of a routine.
2. Whether bound or not, the operating system only
loads the Euphoria interpreter into memory. It is then
up to Euphoria to open a file (the same .exe file, in the case
of a bound executable) and read in your Euphoria program.
As a quick test, I added 40 Mb of garbage onto the end of
a bound .exe file. It had no effect of the speed of running the
.exe. Obviously, the operating system was not trying to load
the 40 Mb of garbage into the 32 Mb of memory on the machine.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
11. Re: Bind features
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Jun 30, 1999
-
Last edited Jul 01, 1999
> 1. After processing a constant declaration, all the data and
> code used in calculating the constants value is freed. e.g.
>
> constant SIZE=10+100-22*foobar({1,2,3,4,5})
Robert, wouldn't you above example, not generate 1) the four bytes needed to
store the value *and* 2) the fourthy two bytes to store the code that
calculates the constant.
I mean:
constant my_string = "Hello, world"
Is in the code, in the memory of the interpreter, even before it is
executed.
Therefor it is in memory twice, unlike information loaded from a resource
file.
> 2. Whether bound or not, the operating system only
> loads the Euphoria interpreter into memory. It is then
> up to Euphoria to open a file (the same .exe file, in the case
> of a bound executable) and read in your Euphoria program.
> As a quick test, I added 40 Mb of garbage onto the end of
> a bound .exe file. It had no effect of the speed of running the
> .exe. Obviously, the operating system was not trying to load
> the 40 Mb of garbage into the 32 Mb of memory on the machine.
Really ? I can remember all kinds of 'program does not fit in memory' errors
on my old 286.
Trying to free-up conventional memory, unloading device drivers, etc.
It were not errors generated by the program I believe, rather by the OS.
I trust your word though, it does suprises me. Is the executable information
load-on-demand ?
Which would almost appear as if the OS is interpreting the executable file,
rather than the chipset, which was my guess.
Ralf N.
12. Re: Bind features
.COM files are completely loaded into memory. You must have more memory
than the size of the file to load a .COM file.
.EXE files are NOT loaded into memory. The header to a .EXE file is
loaded. The header then tells the file offset of the program code and
how large that code is. One could write a program, compile it, and then
attach a huge bitmap to the end of the program and not effect in any
way the amount of the code that is loaded into memory. This means that
unused data at the end of a .EXE file won't require more memory for the
program to be loaded. Just may Hard Drive space for it to reside.
Lucius L. Hilley III
lhilley at cdc.net
+----------+--------------+--------------+
| Hollow | ICQ: 9638898 | AIM: LLHIII |
| Horse +--------------+--------------+
| Software | http://www.cdc.net/~lhilley |
+----------+-----------------------------+
> ---------------------- Information from the mail
header -----------------------
> Poster: Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
> Subject: Re: Bind features
> --------------------------------------------------------------------------
-----
>
> > 1. After processing a constant declaration, all the data and
> > code used in calculating the constants value is freed. e.g.
> >
> > constant SIZE=10+100-22*foobar({1,2,3,4,5})
>
> Robert, wouldn't you above example, not generate 1) the four bytes needed
to
> store the value *and* 2) the fourthy two bytes to store the code that
> calculates the constant.
>
> I mean:
>
> constant my_string = "Hello, world"
>
> Is in the code, in the memory of the interpreter, even before it is
> executed.
> Therefor it is in memory twice, unlike information loaded from a resource
> file.
>
> > 2. Whether bound or not, the operating system only
> > loads the Euphoria interpreter into memory. It is then
> > up to Euphoria to open a file (the same .exe file, in the case
> > of a bound executable) and read in your Euphoria program.
> > As a quick test, I added 40 Mb of garbage onto the end of
> > a bound .exe file. It had no effect of the speed of running the
> > .exe. Obviously, the operating system was not trying to load
> > the 40 Mb of garbage into the 32 Mb of memory on the machine.
>
> Really ? I can remember all kinds of 'program does not fit in memory'
errors
> on my old 286.
> Trying to free-up conventional memory, unloading device drivers, etc.
> It were not errors generated by the program I believe, rather by the OS.
>
> I trust your word though, it does suprises me. Is the executable
information
> load-on-demand ?
> Which would almost appear as if the OS is interpreting the executable
file,
> rather than the chipset, which was my guess.
>
> Ralf N.
>
13. Re: Bind features
- Posted by Bernie Ryan <bwryan at PCOM.NET>
Jun 30, 1999
-
Last edited Jul 01, 1999
>> Lucius L. Hilley III You Wrote:
>> .COM files are completely loaded into memory. You must have more memory
>> than the size of the file to load a .COM file.
.COM are loaded into memory to run at offset 100H and the only extra memory
required is for the PSP which is 256 bytes.
>> .EXE files are NOT loaded into memory. The header to a .EXE file is
>> loaded. The header then tells the file offset of the program code and
>> how large that code is. One could write a program, compile it, and then
>> attach a huge bitmap to the end of the program and not effect in any
>> way the amount of the code that is loaded into memory. This means that
>> unused data at the end of a .EXE file won't require more memory for the
>> program to be loaded. Just may Hard Drive space for it to reside.
This is not correct.
When an EXE file is loaded into memory it can be located anywhere in
memory. The loader will look at the header which contains the size and
offsets required to load it. It then loads it into memory at the
available memory location correcting and fixing the offsets to match that
location.
The .COM file is fixed to run at one location the EXE is RELOCATABLE
to run in any location in memory. BUT the both are LOADED INTO MEMORY.
Bernie
14. Re: Bind features
Ralf writes:
> Robert Craig writes:
>> 1. After processing a constant declaration, all the data and
>> code used in calculating the constants value is freed. e.g.
>>
>> constant SIZE=10+100-22*foobar({1,2,3,4,5})
> Robert, wouldn't you above example, not generate 1) the four
> bytes needed to store the value *and* 2) the fourthy two bytes
> to store the code that calculates the constant.
No, the code is generated, executed, and then discarded, since
it will never have to be executed again. The same is true for
all "top-level" code. (I'm not sure where you got the value "42"
- wasn't that the answer to the "meaning of life" in some
Monty Python movie?)
> I mean:
> constant my_string = "Hello, world"
> Is in the code, in the memory of the interpreter, even before
> it is executed. Therefor it is in memory twice, unlike
> information loaded from a resource file.
Euphoria reads the source statement from your .ex file,
makes an internal sequence for "Hello, world", assigns it
to my_string, and then the source statement and any code
are discarded, leaving just my_string pointing to a single
copy of "Hello, world".
If you specify "with trace", then Euphoria will retain the
source statements in memory, so you can see them on the
trace screen, but normally each line of source code is discarded
as soon as the next line of source is read in from the source file.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
15. Re: Bind features
Robert Craig wrote:
>
> all "top-level" code. (I'm not sure where you got the value "42"
> - wasn't that the answer to the "meaning of life" in some
> Monty Python movie?)
In the Douglas Addams series HitchHickers_Guide_To_The_Galaxy the
computer Earth found the Answer to the question to be 42, but it took
the computer Soooo Long to get the Answer that it forgot what the
original Question was.....Something to do with the meaning of Life.
--
+ + + Rev. Ferlin Scarborough - Centreville, Alabama - USA
email: ferlin at sandw.net
email: ferlin at email.com
16. Re: Bind features
Bernie Ryan wrote:
>
> >> Lucius L. Hilley III You Wrote:
> <SNIP>
> The .COM file is fixed to run at one location the EXE is RELOCATABLE
> to run in any location in memory. BUT the both are LOADED INTO MEMORY.
>
> Bernie
---------------------------------
A .COM file will also run anywhere. If you change the boot parameters,
DOS
will then load programs at a different place in memory but the .COM
program
will still run without re-compiling.
17. Re: Bind features
J. Yazel you wrote:
>> A .COM file will also run anywhere. If you change the boot parameters,
>> DOS will then load programs at a different place in memory but the .COM
>> program will still run without re-compiling.
There is no way that I know of changing boot parameters in DOS. Command.com
will always load a COM file at 100H. If you wish to load it at a different
location you have to load the program using the EXEC DOS function. Then
run it from the parent program that loaded it.
Bernie
18. Re: Bind features
- Posted by Joe Otto <jotto at NETZERO.NET>
Jul 01, 1999
-
Last edited Jul 02, 1999
Okay, somebody's got to step in and straighten this out. DOS doesn't EVER
load anything in a fixed place except for a couple of cryptic options
available to gurus for loading device drivers, TSRs, and such.
Both COM and EXE files are relocatable. The primary difference is as
follows:
The COM file format is a relic from CP/M, which ran on the 8080 with a
total memory space of 64KB. Due to this fact COM files are restricted to
64KB in size, which just happens to be the size of a single segment in the
8086 architecture. Because of the shortage of available memory, when CP/M
loaded a COM file it would overwrite the operating system memory with the
program. Therefore CP/M had to reserve a little memory (100H bytes) for
O/S overhead and to reload itself when the program completed. Thus, the
100H address referred to earlier is the *offset* into the segment wherever
DOS chooses to load the file. Since, in the 8086 architecture, the segment
is shifted left 4 bits before it's used in an address calculation, a new
segment starts every 16 bytes, and DOS can load a COM file virtually
anywhere in conventional memory (or upper memory under certain
circumstances). Under DOS the usage of the reserved 100H bytes has
changed, but it's still required since all COM files are based on a 100H
load offset.
The EXE file format allows programs larger than 64KB in size due to
"fixups" that DOS does after it loads the file but before it executes it.
It's been much too long for me to remember all the details, but it
involves a fixup map generated by the linker that tells the DOS loader to
go to an address and insert the current segment, then move to another
address and insert the next segment, etc. It's a long tedious process that
makes me happy I never had to write a loader for such a screwed up
segmented architecture as the 8086... :)
Btw, before anyone comes back with "I have COM files on my hard drive
bigger than 64KB" let me explain... Back when the EXE format was a baby,
Microsoft worked out a convoluted way (meaning I never even tried to figure
it out) to put more than 64KB in the COM file, then have the program do its
own fixups after it started executing. I don't think they ever released
the specs on the actual procedure, and I believe it's still very much
Microsoft proprietary.
Sorry for boring you to tears...
Joe
-----Original Message-----
From: Bernie Ryan [SMTP:bwryan at PCOM.NET]
Sent: Thursday, July 01, 1999 4:17 PM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: Re: Bind features
J. Yazel you wrote:
>> A .COM file will also run anywhere. If you change the boot parameters,
>> DOS will then load programs at a different place in memory but the .COM
>> program will still run without re-compiling.
There is no way that I know of changing boot parameters in DOS. Command.com
will always load a COM file at 100H. If you wish to load it at a different
location you have to load the program using the EXEC DOS function. Then
run it from the parent program that loaded it.
Bernie
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
19. Re: Bind features
- Posted by Jason Gade <jgade at PCEZ.COM>
Jul 01, 1999
-
Last edited Jul 02, 1999
Maybe I'm missing something, but all of the books I have say that *.COM
*always* loads at $100h. *.EXEs are relocateable.
Originally, the point was made about loading 40mb executables in 32mb space,
it is done with demand paging. Check out the current issue of Linux
Magazine (not Linux Journal -- NEW). I'm sure other OS's use similar
methods.
Of course, DOS used overlays, but that is different. An overlay would
replace a section of code.
Please point to me documentation of *.COMs not loading at $100h.
-----Original Message-----
From: Joe Otto <jotto at NETZERO.NET>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Thursday, July 01, 1999 7:09 PM
Subject: Re: Bind features
>Okay, somebody's got to step in and straighten this out. DOS doesn't EVER
>load anything in a fixed place except for a couple of cryptic options
>available to gurus for loading device drivers, TSRs, and such.
>
>Both COM and EXE files are relocatable. The primary difference is as
>follows:
>
>The COM file format is a relic from CP/M, which ran on the 8080 with a
>total memory space of 64KB. Due to this fact COM files are restricted to
>64KB in size, which just happens to be the size of a single segment in the
>8086 architecture. Because of the shortage of available memory, when CP/M
>loaded a COM file it would overwrite the operating system memory with the
>program. Therefore CP/M had to reserve a little memory (100H bytes) for
>O/S overhead and to reload itself when the program completed. Thus, the
>100H address referred to earlier is the *offset* into the segment wherever
>DOS chooses to load the file. Since, in the 8086 architecture, the segment
>is shifted left 4 bits before it's used in an address calculation, a new
>segment starts every 16 bytes, and DOS can load a COM file virtually
>anywhere in conventional memory (or upper memory under certain
>circumstances). Under DOS the usage of the reserved 100H bytes has
>changed, but it's still required since all COM files are based on a 100H
>load offset.
>
>
20. Re: Bind features
Joe Otto wrote :
>> Okay, somebody's got to step in and straighten this out. DOS doesn't
>> load anything in a fixed place except for a couple of cryptic options
>> available to gurus for loading device drivers, TSRs, and such.
Mr Otto:
You had better go to www.wotsit.org and search and download the description
for COM files and read it.
Bernie
21. Re: Bind features
Thanks for the reference Bernie. I went there, downloaded the file
com.zip, and it reads:
In principle, a COM file is just loaded at offset 100h in the segment
and
then executed.
That's exactly what I was trying to say - sorry if I didn't convey my
thoughts very well. DOS never loads any executable at 0000:0100H - that's
where the BIOS maintains several system variables such as basic system
peripheral information, system time, and the keyboard buffer, etc. DOS
picks a convenient segment (any segment anywhere in memory) and loads the
COM file at offset 100H *within* that segment (xxxx:0100H) - not at
0000:0100H.
Hope this helps...
Joe
-----Original Message-----
From: Bernie Ryan [SMTP:bwryan at PCOM.NET]
Sent: Friday, July 02, 1999 9:49 AM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: Re: Bind features
Joe Otto wrote :
>> Okay, somebody's got to step in and straighten this out. DOS doesn't
>> load anything in a fixed place except for a couple of cryptic options
>> available to gurus for loading device drivers, TSRs, and such.
Mr Otto:
You had better go to www.wotsit.org and search and download the description
for COM files and read it.
Bernie
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
