Dear specialists, Does somebody of you know, if Wine support API functions which could be used by very simple focusable object based screen reader? This screen reader would react on key events and other internal WIne events such as if dialog window have been displaied. Screen reader should send textual content of focusable objects such as buttons, comboboxes, dialog windows, menu items to speech output. Because screen reader which I would like to develop can not use Microsoft components including Microsoft C run-times, SAPI5, 4 or newest Windows 10 speech kit, there is only possibility to develop integrated speech engine from scrath. Or ask you how complex would be for you to develop software bridge between Wine and speech-dispatcher speech server. This software bridge would introduce simple Speech functions and procedures, which would allow developers to send textual data to active speech engine by using Speech-dispatcher speech server. FOr beginning, I would like to know, if Wine contain some USER32.dll and other API calls, which are able to get text information from object which have focus. Sure, screen reader, which I would like to develop will be very simple. It will never be comparable with NVDA, Jaws or with other complex screen readers for Windows. I would like to only develop at least simple focus and event based screen reader, which will be able to use with simple Win 32 apps such as notepad, integrated explorer.exe with Wine, with MP3directcut for Windows, ETC. Because screen reader can not use libraries from Microsoft, I Am aware, that my goal will never produce screen reader which will be able to support object hiearchi browsing inside active Window. Very important question is, if Wine contain APi calls to detect object class name, which will be detected from object, which have focus. Without this routine, my dream will be never possible. Last question. Does integrated Windows PE routines support machine code instructions, which have been generated by Free Basic compiler for Windows? Because I do not know, if generated machine code hhave not been specifically prepared for original Microsoft Windows so if compiled apps, which would run normally from original Windows will not cause random crashes and stability issues when running it with Wine. I can not use programming languages from Microsoft. There are 3 Basic language compiler from other teams than from Microsoft. Power Basic, Free Basic and Pure Basic. BUt Pure Basic is commercial, Power Basic is commercial and Free Basic is The onlyone free Basic compiler, which generates .exe apps which do not depend on Microsoft .dlls as default. I have old time experience with various screen readers. When Windows 3.11 have been developed, two very smart C++ ddevelopers in our country have developed screen readers for Windows 3.11. It did not used mSAA. Screen reader had its internal speech engine which had nothing to do with Speech API, because in 1994 there was no such routines from Microsoft. Screen reader have reacted on keyboard events, it spoken lines of text from editable fields, text of dialog windows, menu items. So do you think, that APi calls which are available inside WIne now can allow Me to develop such focusable object based screen reader? Or it is paradox situation, that WIndows 3.11 16 Bit version from 1994 have allowed that and modern Wine do not allow it? Really, I do not write about Windows 95. It was really Windows FOR WORKGROUPS 3.11 AND ITS 16 BIT VERSION, NOT Win32. Thank you very much for yours kind acces to my questions. I will intrude you as little as possible, I know, that you are very overloaded. I need to know, if my dream can come true or no.
Hello Janusz,
I'm not entirely sure what you're asking, but Wine does currently support many core windowing APIs, including e.g. GetFocus(), GetForegroundWindow(), GetWindowText(), GetClassName(), etc., which seems to be what you're looking for.
As for compilers, note that Wine isn't emulating anything at the machine code level. The loader should be capable of loading any binary that Windows can load, and there's no known reason that any given compiler would be an exception to this. If it's not, please file a bug at https://bugs.winehq.org/.
ἔρρωσο, Zeb
On 7/5/19 1:23 PM, Mgr. Janusz Chmiel wrote:
Dear specialists, Does somebody of you know, if Wine support API functions which could be used by very simple focusable object based screen reader? This screen reader would react on key events and other internal WIne events such as if dialog window have been displaied. Screen reader should send textual content of focusable objects such as buttons, comboboxes, dialog windows, menu items to speech output. Because screen reader which I would like to develop can not use Microsoft components including Microsoft C run-times, SAPI5, 4 or newest Windows 10 speech kit, there is only possibility to develop integrated speech engine from scrath. Or ask you how complex would be for you to develop software bridge between Wine and speech-dispatcher speech server. This software bridge would introduce simple Speech functions and procedures, which would allow developers to send textual data to active speech engine by using Speech-dispatcher speech server. FOr beginning, I would like to know, if Wine contain some USER32.dll and other API calls, which are able to get text information from object which have focus. Sure, screen reader, which I would like to develop will be very simple. It will never be comparable with NVDA, Jaws or with other complex screen readers for Windows. I would like to only develop at least simple focus and event based screen reader, which will be able to use with simple Win 32 apps such as notepad, integrated explorer.exe with Wine, with MP3directcut for Windows, ETC. Because screen reader can not use libraries from Microsoft, I Am aware, that my goal will never produce screen reader which will be able to support object hiearchi browsing inside active Window. Very important question is, if Wine contain APi calls to detect object class name, which will be detected from object, which have focus. Without this routine, my dream will be never possible. Last question. Does integrated Windows PE routines support machine code instructions, which have been generated by Free Basic compiler for Windows? Because I do not know, if generated machine code hhave not been specifically prepared for original Microsoft Windows so if compiled apps, which would run normally from original Windows will not cause random crashes and stability issues when running it with Wine. I can not use programming languages from Microsoft. There are 3 Basic language compiler from other teams than from Microsoft. Power Basic, Free Basic and Pure Basic. BUt Pure Basic is commercial, Power Basic is commercial and Free Basic is The onlyone free Basic compiler, which generates .exe apps which do not depend on Microsoft .dlls as default. I have old time experience with various screen readers. When Windows 3.11 have been developed, two very smart C++ ddevelopers in our country have developed screen readers for Windows 3.11. It did not used mSAA. Screen reader had its internal speech engine which had nothing to do with Speech API, because in 1994 there was no such routines from Microsoft. Screen reader have reacted on keyboard events, it spoken lines of text from editable fields, text of dialog windows, menu items. So do you think, that APi calls which are available inside WIne now can allow Me to develop such focusable object based screen reader? Or it is paradox situation, that WIndows 3.11 16 Bit version from 1994 have allowed that and modern Wine do not allow it? Really, I do not write about Windows 95. It was really Windows FOR WORKGROUPS 3.11 AND ITS 16 BIT VERSION, NOT Win32. Thank you very much for yours kind acces to my questions. I will intrude you as little as possible, I know, that you are very overloaded. I need to know, if my dream can come true or no.
-
Mgr. Janusz Chmiel -
Zebediah Figura