From the other side....

Tue Feb 12 16:37:30 EST 2002

Hi

I thought that some of you would be interested in the following post:

(Message inbox:10)
To:      "Access-Uk at Yahoogroups. Com" <access-uk at yahoogroups.com>,
	 "Dolphin at Topica. Com" <dolphin at topica.com>, mar.hill at dolphinuk.co.uk
From:    Martin Roberts <martin at mproberts.co.uk>
Subject: FW: co-existence problems. Where are we and where are we going?
Date:    Tue, 12 Feb 2002 17:45:49 -0800

part       text/plain                 10K
[7mPress <return> to show content...[27mPlease get through this, it's an interesting read for all who are using
win2k or xp, or who plan too.

Nice one GW!

-----Original Message-----
From: postmaster [mailto:postmaster at gwmicro.com]On Behalf Of Doug
Geoffray
Sent: 12 February 2002 08:16
Subject: co-existence problems. Where are we and where are we going?

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 at gwmicro.com.

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

============================================================
============================================================

==^================================================================

Gena
______________________________________________________________________
Please Note:
All html messages are automatically deleted as they are considered to be a 
security risk.

Announcing Blindness Advocacy and Self-Help Online [BASHOnline]
www.bashonline.org you can join the mailing list by sending a message to: 
bashonline-subscribe at yahoogroups.com

Personal site:  www.gena-j.net

Contact Info:  MSN ID: gena1959uk at hotmail.com (No mail to this address
please) it will not be read:  ICQ ID:  144169465: