Hello,
Just a thought for future releases. I see that Window Eyes uses a
system service which I assume is responsible for launching the Window
Eyes executable under various conditions such as launching Window Eyes
at the longon screen or launching it when you log in to your account and
insuring that the process does launch under these conditions, (yes, I'm
that much of a boring nerd that I go through my system services list
from time to time). So just a thought for maybe a way of improving
reliability.
-- Firstly, I found that sometimes it was useful to give a process
priority over others to insure that Windows gives it more attention in
its whole sequence of event-handling. So if you have a sluggish program
that might be in turn causing Window Eyes to be sluggish because Windows
is giving them both equal priority, if Window Eyes was set to have a
high priority then perhaps this wouldn't happen. I can't test this
normally because Window Eyes is being launched by the service which is
running from the system account, so Window Task Manager won't let me
change this on the fly. I have not tried terminating the Window Eyes
process and then launching it from my account so that I can change this
value. Perhaps this would cause system instability, but maybe it's
something that someone in development at GW-Micro could play with,
because if it's successful I assume it's a simple way to make Window
Eyes more responsive without having to modify the program code at all,
just giving it more power over Windows itself. I assume that when a
service calls another executable it would have the power to call it at a
high priority status rather than normal priority. When I used to work
at a call center and yes that was using the evil shark from the deep, a
trick I discovered when Jaws was being sluggish with some of those
terribly-designed bloteware call center apps was to go in to task
manager there and bump the process for Jaws up to high priority.
Magically Jaws seemed to lose a lot of its sluggishness when something
was holding it up. I don't know of a way to call an executable from a
service at high priority, but I suspect you guys at GW-Micro do or could
figure it out. I would suggest that there be an option in the Window
Eyes control panel to turn this feature on or off, maybe under startup
options or something?
-- Secondly, I wonder if it wouldn't be possible to have the
service detect if the Window Eyes process suddenly crashes and if so
reload it automatically? Many decent antivirus programs do this to
prevent malware from terminating them. I would suggest that if you call
up the Window Eyes control Panel and shut it down that way, then that
tells the service through some background process that it's safe to let
the process go down without calling it back up, but if for example if
the worst does happen and Window Eyes does freeze or crash and burn, the
user could have a hotkey defined to terminate the process and the
service would call it back automatically and reliably. I have set up a
way to terminate a specific process using a utility from PSTools called
PSKill.exe which I then assigned to a batch file with a shortcut in my
start menu or desktop, and then assign a startup key sequence to that
shortcut, so that when I press say control-alt-r, pskill terminates the
process in question for me without the need of the task manager, and in
99% of most cases will work on a locked up screen reader that isn't
speaking. This works almost all the time unless the rest of the system
is completely hosed and needs a restart. I'm sure a more professional
solution could be implemented into Window Eyes through a third party
utility executable (obviously not Window Eyes.exe) but some other
process which could have a start menu icon under the Tools folder in the
Window Eyes folder. I would assume a third executable is needed simply
because if the wineyes.exe process is hanging it won't be able to
terminate itself at the request of a hotkey. I noticed that someone
wrote an app to do something like this, however in a situation where the
process which handles apps isn't working, that app isn't likely to be
able to do anything, thus why it has to be third-party.
Obviously, hopefully such a setup is not and hopefully never is
needed, but unfortunately reality doesn't always work the way paper or
ideal lab conditions do. I know there's nothing worse than having your
screen reader suddenly go silent (and no I'm not pointing fingers at
Window Eyes with this, but all of them, because they potencially all can
crash and burn at some point or another), but just as a blind person to
others, I'm sure you can all understand what I mean about how difficult
this can be? For the sighted amongst us, imagine your screen just
suddenly going blank and you can't get it back without restarting or
going through some "blind" process of key-sequences (no insult
intended), to get it to flicker back on? Most sighted people will take
their computer in to their local tech (or do it themselves if they know
how) under such a situation if that happened to them, but a computer
tech or the smartest of computer geeks is not likely to troubleshoot
screen reader freezes, unless they're a screen reader developer. To date
I know of no Windows screen reader which has such a feature as the two
I've described here, however Apple had it in Voiceover from the start.
Yes I have a mac and yes Voiceover does die at times but it just recalls
itself immediately. No Voiceover is certainly not perfect either, but
this is one thing it has going for it that Windows screen readers
don't. Window Eyes could be the first to take such a feature for
itself, and with its arrangement of a separate service controling its
Window Eyes process, it is in an ideal situation to make it happen with
very little modification, I would think.
Just another of my crazy ideas,
Cory
If you reply to this message it will be delivered to the original sender only.
If your reply would benefit others on the list and your message is related to
GW Micro, then please consider sending your message to [email protected] so
the entire list will receive it.
GW-Info messages are archived at http://www.gwmicro.com/gwinfo. You can manage
your list subscription at http://www.gwmicro.com/listserv.
