Hi Again:
One final thought:
There might actually be a senario where scripts could step on each other,
internal or external.
That is if I were to open NotePad and there are 2 scripts, perhaps one global
and one an associated script, accessing that process at the same time.
While both scripts are in their own threads they are accessing the same client
process and thus objects in that process may be Vulnerable to unintended
consequences.
Is there something in the way WE handles scripts that would make this
impossible or is it up to the scriptors to ensure this does not happen?
Rick USA
----- Original Message -----
From: RicksPlace
To: [email protected]
Sent: Friday, April 20, 2012 5:54 AM
Subject: Re: WE And Global Scripts And Thread Safety
Hi Guys: Thanks for the info.
What process do the VBS scripts run under?
Is it the WindowEyes Assembly or something else?
A process has it's own space and variables and all that jazz so my external
script won't have to worry about stepping on anything running under the
WindowEyes Process.
I am not so sure about the various VBS apps running concurrently under a
single process but that is not relevant to my external script at hand anyway.
I have found that WE provides a STA model and my script is running in STA
mode by default.
So I am in compliance there.
Marshalling and syncronization are automatically done for com between the
managed process and the OutOfProcess operations.
The only communications between my Process, threads, and any of the Global
Scripts running under the WE Process? would have to be manually provided by the
WE Engine and I dont think it does that.
So, if my understanding is correct I am good to go with either a Global or
a Associated script without having to worry about Cross Process or threading
except within my own Process environment.
Does this sound right guys?
Rick USA
----- Original Message -----
From: Chip Orange
To: [email protected]
Sent: Thursday, April 19, 2012 9:34 PM
Subject: RE: WE And Global Scripts And Thread Safety
Hi Rick,
As Ron mentioned, there is no difference between running a script globally
or not. It's only about when it's started and nothing else. An
application-specific app gets started when the program starts; global apps when
WE starts.
Everybody gets their own thread at a minimum, and if external, their own
process.
Chip
--------------------------------------------------------------------------
From: RicksPlace [mailto:[email protected]]
Sent: Thursday, April 19, 2012 12:21 PM
To: [email protected]
Subject: Re: WE And Global Scripts And Thread Safety
Hi BT: Ya, back in the day I wrote a sort of Space Invaders for the first
version of the IBM PC using Assembler.
Back then we used registers and offsets as well as the basic instruction
set available with the IBM assembler for it's PC.
I have never mucked with machine code after having to do it a little in
school back in the 1960s if I remember.
As I read up on processes, threads and apartments I am finding out more
about the complexity of the Operating System and how it spins off new processes
and the threads associated with a process, marshalling for cross-threading and
cross-process operations and how these states can be set within an applications
program in vb.net or C#.
Prior to this I had only used some of the high-level tools to run threads
in the background.
Now I am doing a little reading about how sta and mta and the various
Threading Class properties and methods impact the operations of a vb.net or
CSharp program.
It does, however, seem that running a script globally is a thing which
might require a solid understanding of the above technicals to avoid some nasty
unintended consiquences for end users.
Anyway, I'll continue reading up on this subject, try some experiments
and see how it relates to a COM server as it were to try and have a solid
working understanding of these critical technicals.
Thanks for the help guys:
Rick USA
----- Original Message -----
From: BT
To: [email protected]
Sent: Thursday, April 19, 2012 9:35 AM
Subject: Re: WE And Global Scripts And Thread Safety
Hi Rick,
Ron explained it in more detail. The process ID still points to the
same window and unless you are monitoring different events, you will get the
same result in both cases. Process ID are kind of like window handles but not
the same entirely.
Ron did a pretty good job in describing it. I use to use all of
this when I wrote a DOS screen reader program, back in the easy days of windows
programming. It worked really great and the Process ID was captured to keep
stacks and such straight forward for calling such things as, Is my screen
reader running?...so it does not get loaded twice into memory.
Windows has just messed up the ease at getting information from the
keyboard and screen mainly because of the layers of children involved...
I wrote the entire screen reader program using the MASM utility and
all done in machine code...
Screen Reader Demo:
http://www.youtube.com/watch?v=W2LyRC99Qx0
Part 2 Of Screen Reader Demo:
http://www.youtube.com/watch?v=uUy8c1jTt9k
Sent: Thursday, April 19, 2012 9:18 AM
Subject: Re: WE And Global Scripts And Thread Safety
Hi Bruce, I dont understand could you flesh out the following?
You wrote:
I think each instance is its own but I may be wrong.
When you talk about instance do you mean thread, script, sub or
method within a script etc...
And do you mean instance in the technical (OOP) sense or as a general
term?
The only conflict is the
process ID which I am sure you are concerned with.
OK, I thought each script passed it's ProcessID for the APP it was
scripting but what about a Global Script?
Are you saying all global scripts run under the same process?
If so does each have it's own thread and, in that case, would local
variables not located inside a sub be Cross-Threaded and thus available and
modifiable by all other scripts running at the same time?
Try and see if your instance is
different, unless you are looking at the same events then that would
create a problem.
I dont understand the above.
How can I look at my instance? Do you mean thread? and, if so, how do
I do that or what tool would be good to use?
Your question about events should be handled, I think, by filtering
messages somehow as is done in Chip's class if I remember so I dont think you
mean script.
Also Rick, the Victory Associates software you were going to
attempt to work
with had a virus inside of it. It is a good thing you did not work
with it.
Phew!
It wouldn't have mattered unless the virus was in the Corporation's
software since I dont think RDP would have transmitted the virus unless I
downloade software from his machine.
In either case I felt bad I couldn't have helped him.
Rick USA
----- Original Message -----
From: BT
To: [email protected]
Sent: Thursday, April 19, 2012 8:12 AM
Subject: Re: WE And Global Scripts And Thread Safety
Hi Rick,
I think each instance is its own but I may be wrong. The only
conflict is the process ID which I am sure you are concerned with. Try and see
if your instance is different, unless you are looking at the same events then
that would create a problem.
Also Rick, the Victory Associates software you were going to
attempt to work with had a virus inside of it. It is a good thing you did not
work with it.
Bruce
Sent: Thursday, April 19, 2012 5:31 AM
Subject: WE And Global Scripts And Thread Safety
Hi Scriptors:
Does a Global Script run in it's own process with independent
threads?
We pass the ProcessID to WE and it can be used for filtering
Windows and Messages
so I am wondering about whether shared (static) variable or data
objects in one Global
script could step on shared (static) objects of the same name and
signature in another
script or Client Application if they are not Windows or Messages.
In other words, are Global Scripts thread safe considering
shared (static) variables
and Data items?
I hope this question makes sense.
I have an external script that worked well when associated with a
particular application but had some problems when I made it a Global Script.
I have since pulled out code that used shared items and have made
everything instance objects but haven't had time to test it yet.
My guess was that I was stepping on my own shared objects since I
used the same objects in another application I was looking at and even in other
global test scripts I still had running since they were more or less useful.
I just would like to know if this is a possibility since
resolving it is my responsibility if that is the case, and yours too as
scriptors.
If each script runs in it's own process independent of each other
and independent of the targeted application this might not be a consideration
but I dont think that is how it works.
WE needs communication among all facets of a session so I am
guessing this conceptual model needs consideration but would like to know the
real deal so I am not guessing.
Rick USA
