Ok, I've managed to get a debug 3.2.0 install set up on my system, and
the stuff I'm finding is a bit on the bizarre side. Essentially all I
did was set break points on all of the methods of orxscript.cpp and
trace all of the calls between the scripting host and the Rexx
scripting engine. Initially, things look pretty good. When running
the simpleorexx.wsf sample, the script engine initializes, and is
asked to parse the fragment of ooRexx code in the file that looks like
this:
Say This is GetScriptEngineInfo()
Ver = Accessing the version info from Rexx yields
ScriptEngineMajorVersion().
Ver = Ver||ScriptEngineMinorVersion().ScriptEngineBuildVersion()
Say Ver
WScript~Echo(Done!)
The code for parsing this file is truly strange. It first calls
RexxStart on a second thread to actually run this code, and uses one
of those private APIs to grab the names of the ::ROUTINES PUBLIC
contained in the file. These function names are recorded, I believe,
as globally available routines that can be called from other script
contexts. Then another undocumented API is called to convert this
into a callable script. This is very strange, but we can accomplish
all of this using the routine/package classes in 4.0.
Then it gets a little strange. There is a call to the
OrxScript::SetScriptState() method to set the state to UNINITIALIZED.
This has the following comment at the code that is executed.
case SCRIPTSTATE_UNINITIALIZED:
// IIS (ASP server) sets the engine from STARTED to UNINITIALIZED
// from what I remember from the documentation, this is ILLEGAL
// it may be a shortcut way of rerunning a script, but only Microsoft
// knows exactly what is intended to happen in this scenario
// returning this error causes the webserver to shut down the engine
// and create a new instance again...
hResult = E_UNEXPECTED;
break;
Well, this does exactly what the comment says it does. The script
engine instance is shut down, then a second instance is initialized.
This one handles a different sequence of calls. This time, a number
of calls are made to AddNamedItem() passing in items with names like
WScript. These are obviously the global objects that the script
host exposes. Then the ParseScriptText() method is called again to
reparse the same script fragment that was used with the first instance
of the engine. This time, the fragment is run after being parsed, and
a couple of special (and undocumented exits) come into play. The
first exit handles NOVALUE events, and will check for items that were
added via AddNamedItem() on references to uninitialized variables.
This is the magic that allows WScript to be a valid variable name when
the script runs. When the fragment completes, the termination exit is
used to capture all of the variable names and register them as global
names in the environment as well.
I think I need to do some more tracing with a more complicated example
that has multiple fragments so I understand the interactions between
fragments, but this is what I've discovered so far.
Right now, I have some obvious questions:
1) Is this how the variable model should be handled, or should
imported/exported variables be handled explicitly? For example,
Rony's suggestion of a .host environment entry might make some sense
rather than using the somewhat strange implicit model. These variable
names as currently handled appear only visible for the toplevel
fragments, and are not propagated to call ::routines included in the
fragments. Using the special accessor would allow a single visibility
model.
2) Somewhat related is the question of what variables/routines get
made visible to the outside worldand it would be nice to apply
this to object instances too. This is really item 1A) really, rather
than a separate item.
Rick
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
