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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxx]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:
