Free screen reader for Wine

Questions about Wine on Linux
Post Reply
Posts: 2
Joined: Fri Jul 05, 2019 6:20 am

Free screen reader for Wine

Post by januszchmiel » Fri Jul 05, 2019 7:53 am

Dear specialists,
The aim of this thread is to ask core developers of Wine as much developer information as possible to develop free screen reader for Wine. This screen reader must:
1. Must be 100 % legal so it can not depend on Microsoft components. It must be usable only by using modules and libraries which have been distributed and build by Wine developers.
2. Screen reader can not be based on MSAA, because it is Microsoft product.
It can not be based on SAPI or other Microsoft standard to access speech engines.
So I have The following series of questions.
1. Does Wine support API calls, which can return text information from object such as dialog, menu item, editable field, ETC? So functions from User32.dll.
Does WINE support Wdmaud.drv so reliably, so I could create speech module, which will know, if some audio sample have been allready plaied or no? Or this complex algorithm do not work in Wine?
Screen reader will not support object browsing, because without MSAA, it will not be possible to create object database.
So screen reader will be focus and events based.
Must support detection of key strokes
Must support various events such as.
If start menu have been recalled.
And it must be capable to fetch texts from dialog windows.
Ut must react on all focusable objects, which return textual information.

Which programming language should I use?
Does Wine support apps, which have been compiled by using Power Basic, Free Basic or Pure Basic?
By other words, does Wine support .exe programs which have been created by using Assembly language?
Since Free Basic, Power Basic and Pure basic generates .exe by using Assembly language instructions. And I do not know, if compilers do not create some machine code, which have been specially prepared to work with original Microsoft Windows and if it will not cause some chaos because of The assumptions of compiler developers, that app will use Microsoft Windows exclusively.
I will be glad to create simple engine, I AM not big company, so without intonation. I can not use Microsoft libraryes to be sure, that screen reader will be legal across The globe and it will be usable by visually impaired individuals with no need to have issues with powerful company because of licensing issues.
By other words, screen reader will never be so professional like Jaws, Supernova. It will not support display model, object database browsing. It aim will be to provideonly basic screen reader such as CS-VOICE. This program have been created by two advanced programmers in our country in 1994. It have been created for Windows 3.11. But so old APIS are very probably not supported by Wine. engine And Windows 3.11 apps have been 16 Bits. And it would had to involve MFC libraries from Microsoft. So I must really begin from scratch.
I can not use Visual Basic 6.0, because it also uses Big .dll from Microsoft to interpret .exe code compiled by Visual Basic compiler.
So The most important is, if WINE support API calls to get text info from focusable objects and if is it possible to use audio feetback calls, if some audio sample have been already played or not.

User avatar
Posts: 12689
Joined: Tue Mar 25, 2008 10:30 pm

Re: Free screen reader for Wine

Post by dimesio » Fri Jul 05, 2019 9:40 am

It would be better to ask this on the wine-devel mailing list; developers rarely read the user's forum.

Posts: 2
Joined: Fri Jul 05, 2019 6:20 am

Re: Free screen reader for Wine

Post by januszchmiel » Fri Jul 05, 2019 12:30 pm

So lets get start.
I suggest if somebody of The core developers could try The API call, which can read textual content of Windows start menu, which can be recalled by pressing Windows key. The result would be stored on the plain ascii file and I will intensively press keys to determine, if there will be crash or no. Yes, routine would had to also detect The fact, that user pressed Windows key first and that user have pressed arrow keys. I do not want to use Autohodkey, because I AM Afraid, that it depend on some C run time libraryes from Microsoft. So I would really rather to use Free Basic, since Powerbasic is commercial and old version, which have been offered several years ago for free will not be easy for users to find it. Next complex problem. Is it possible to get information about current object class name, which have focus, or this technique is also only MSAA routine and there is no equivalent available inside Wine code?

The most important question is, if Wine APi functions allow to get textual content of AN focusable object such as. Explorer.exe and shell32.dll generated name of desktop item, drive item, start menu item, etc.
If there is no function or procedure to perform this task or if Wine will display similar warning with error, which have been also generated by Windows 3.11 such as app have made unallowed operation and it have been terminated. I Am asking and pleasing you to disable those conditions inside Wine core. Or you could create new APi sub routine, procedure, which would inform Wine core about The fact, that app will call APi functions not because of wrong intentions, but because it is call from screen reader. Windows 7 and newer uses screen reader flag for such tasks, and in this case, Windows kernel and memory management engine do not classify some specific API calls as an illegal access to apps memory segments or as a un allowed operation.
If Wine core will not block some specific screen readers programmers API functions calls as default and if some APi functions exist, it would be really very nice to know about them.
Sure, as I have allready stated At The beginning of my first forum message, I do not assume so comfort API support like MSAA standard introduced. So user will not be able to get text from whole window, user will not be able to browse app window by object hierarchy. If Wine do not support API functions or procedures for my dream, let Me know and moderators can remove this thread.
I do not assume, that it would be easy to construct complex software bridge between Wine and Speech-dispatcher. So special Wine speech engine API would allow screen reader to send text data to active speech engine by using Speech-dispatcher, which run on Linux as speech server.
I AM afraid, that it would be too complex task to make such stable software modules.
Thank you very much for yours time and for yours kind access to my plea.
Many modern screen readers strictly depend on specific oleacc.dll calls and UIautomation calls. So it is really not possible to simple port them to Wine.

Post Reply