All- We at Freedom Scientific have been pleased to participate with the
other AT vendors in the joint effort to produce the driver chaining
specification described below. Freedom Scientific is currently working
with the Sample Code and we have begun the process of implementation
into JAWS, Connect Outloud, and MAGic Products. It is our intention to
roll this out to our customers as soon as the work and testing are
completed. Our objective is to include this in all future releases but
at the same time to insure backwards compatibility. In the event you
still maintain earlier versions of JAWS on your systems.

For a very good description of the joint effort undertaken and an even
better communication describing the reasons and importance of this
effort, please read below, the recent write up authored by Doug Geoffray
and shared with the GW Micro List early this week.

Sincerely,
Eric

Eric Damery
Vice President Product Management Software
Freedom Scientific, BLV Group
www.freedomscientific.com
800-444-4443

Date: Tue, 12 Feb 2002 11:11:00 -0500
From: Doug Geoffray <
geoffray@g...>

Subject: co-existence problems. Where are we and where are we going?
To:
gw-info@g...

PLEASE NOTE: The following contains important technical information.
Please
read through this information very carefully. If you have any questions,
please contact our support department at 260-489-3671, or e-mail us at
support@g...

After reading several messages on several lists there seems to be great
confusion as to why many adaptive software applications, in particular
screen readers and screen magnifiers, don't always work when installed
on a
single machine. I hope that this message will clear up much of this
mystery.

There has been a longstanding problem of adaptive applications
co-existing
peacefully in Windows 95, 98, and ME. We have addressed this problem to
a
certain degree or at least to a tolerable degree. Windows 2K and
Windows
XP are built on a different code base and, as a result, these two
versions
of the operating system, have greatly increased the number of
co-existence
problems. The reason is simple--there is only one way to get to the
necessary screen information for screen enlargers and screen readers and
even general market applications from Windows 2K and Windows XP.
Currently
Microsoft has no sanctioned method for how to get this necessary screen
information from these versions of their operating systems. As a
result,
all software developers have to hack their own approach to the problem.
The
good news is, as soon as the sanctioned method is available, and do read
on, the co-existence problem will be solved.

In order to get the necessary screen information developers need to hook
into the normal video screen. In other words, create their own video
driver so the operating system will pass all information to it before
passing the information to the real video driver, which of course
displays
the information on the screen. As I said, because there is no
sanctioned
method of patching your own video driver into the chain, we (i.e. GW
Micro,
Freedom Scientific, AI Squared, Dolphin, etc.) all start hacking it in
one
way or another.

First things first, what do I mean when I say: "get the necessary screen
information?" When something goes to the screen in a PC system it just
goes
to a video driver (usually the one installed with the system's video
card)
and something gets displayed on the screen. Now however, let's say you
install application X. In order for it to either display something to
the
screen and/or to "see" what is being displayed on the screen, it has to
hook itself into the chain. This process gets repeated with each new
installation of an application. By the time application Y gets
installed,
the necessary screen information first goes to application Y who will
get
its needed information and, if well-behaved, passes enough of the
original
information on to application X and then on to the initial video driver
installed with the hardware. Assuming of course that both applications'
X
and Y video drivers don't disturb the information so much that any
other
of the video drivers fail. In any case, it is not good to make
assumptions
with reference to video drivers.

Putting a video driver in the chain is difficult. As you can now also
imagine it is doubly difficult to get the information needed to make, in
our case, a screen reader work and, at the same time, pass information
to
the next video driver. In other words, to be a well-behaved application.
Bottom line, if application X installs with its video driver and
application Y installs its video driver, there is a good chance that the
two new video drivers will not co-exist.

Assuming for a moment that they do co-exist, another problem comes into
play given the fact that the video chain now consists of three video
drivers (application X's, application Y's and of course the hardware
video
card's driver). The more video drivers installed, the more chance for a
co-existence problem and/or an application to not be well-behaved. Or
for
another potential co-existence problem to be introduced.

Let's say after you installed application X and you installed
application Y
you uninstall application X. OUCH! Because application X doesn't know
you
installed another application with a video driver after it, it patches
the
video chain back the way it was when it was first installed. This will
either destroy your entire video chain or, at the very least block out
application Y.

To deal with this latter problem we at GW Micro have stated that if you
install applications it is VERY important that you uninstall them in
reverse order. This will keep the video chain going. So if you install
application X and then install application Y. You must uninstall
application Y and then uninstall application X. If you do it the other
way, you may break your system so it boots up in VGA mode meaning your
video chain is all messed up or at least break application Y.

Not only is installing and uninstalling a problem to consider, but it
also
is essential to upgrade your software applications from time to time.
You
would think just replacing existing application files with newer
versions
would just work. And in many cases that is probably true but not
always.

Let's get specific and start with a fresh system. Let's say you install
Window-Eyes. Everything is working well. Then you install JFW and
again
both applications are working well. Now you upgrade your copy of
Window-Eyes. At this point your system could be very unstable or at
best,
you don't see the improvements as a result of the upgrade. What could
have
happened?

I explained earlier there is no standard way of putting one's own video
driver in the chain. The current approach for JFW is to put itself in
the
chain but to also rename the existing video driver. A video driver is
simply a file on disk. So in Window-Eyes' case, instead of our
installed
video driver (GWMVID.DLL) it is now called something else because JFW
renamed it. So when you upgrade Window-Eyes, it will put the updated
video
driver (GWMVID.DLL) in the right place but the system won't be using it
because it is using the renamed version that JFW created when it was
installed.

Have I confused you enough? I have not seen this video driver renaming
with any other application besides JFW. With the beta copies of
Window-Eyes Professional we have taken a friendlier approach, as have
other
applications I've seen. But I guess when you are talking chaining video
drivers, "friendlier" is a relative term.

GW Micro has worked with Freedom scientific so at least Window-Eyes and
JFW
can co-exist. We have actually modified the Window-Eyes video driver to
test to see if JFW is installed before us so we can make sure JFW gets
what
it needs. However, you still have this renaming problem I described
above.

I think I have described enough of the things that can and probably will
go
wrong with how things work today. Obviously this can't continue to go
on
this way.

What's the solution? What can be done to insure video drivers co-exist
without creating any problems for users? How can applications be better
behaved?

GW Micro and a few other adaptive vendors have gotten together to work
on
what we call the driver chaining specification. The ONLY way
applications
that need to install their own video driver can ever co-exist is if they
all agree to certain standards. This is not only true with adaptive
software but also general market software like PC Anywhere and other
similar software. After several weeks we have developed such a
standard.
Of course none of the problems I have described will be solved unless
ALL
developers use this standard in their applications. If just one
application doesn't use this specification, we are all right back at
square
one. As a result, we wanted to make sure we have the full support of
Microsoft behind us and they have stepped up to the plate nicely.

Microsoft will push this standard to all markets including the adaptive
market and the general market. The specification will be made available
through MSDN, which is a major tool/reference for all developers.

Not only did a specification have to be written, a sample of the
specification had to be written for developers to follow. I'm happy to
announce that Microsoft has contracted GW Micro to create this sample
code
that will be made available to the world. Not only did GW Micro have
the
willingness to create such a driver but the requisite knowledge. We are
pleased that Microsoft trusted GW Micro in this extremely important
venture.

The complete driver chaining specification should be complete in the
next
couple of months. At this point it is up to the application developers
as
to when they will implement this specification into their existing
applications. Obviously GW Micro will implement this in Window-Eyes as
soon as possible. Also, realizing the general market doesn't move as
quickly on issues like this we have built into the specification to
automatically handle applications like PC Anywhere, Carbon Copy,
LapLink,
Timbuktu, and Control It. The developers of these applications should
still implement the specifications in the future but at least in the
short
term, they will co-exist with other software written to take advantage
of
the new specification.

So while my very long message points out the gloom of today it also
forecasts the sunshine of tomorrow. I wish this all could have been
considered and developed way before today but it wasn't. So we must
step
back and do it right. Which is what GW Micro, other adaptive venders
and
Microsoft are currently doing.

We all appreciate your patience during this specification development
and
implementation. Believe me, it will be worth it in the end.

Regards,
Doug

Doug Geoffray
GW Micro, Inc.
Voice 260-489-3671
Fax 260-489-2608
http://www.gwmicro.com

Scott Meyers
Marketing Director
Freedom Scientific Inc.
Blind/Low Vision Group
11800 31st Court N.
St. Petersburg, FL 33716
PH: (727)803-8000 ext. 1131; (800)444-4443
Fax:(727) 803-8001
email:
ScottM@F...
Check out our website! www.FreedomScientific.com

Hands-On Technolog(eye)s
touching the internet
mailto:[log in to unmask]
voice: 301.949.7599
http://members.home.com/poehlman1/