would You try to implement The Microsoft Active Accessibility standarts to The Reactos?

[Mgr. Janusz Chmiel]

Dear core developers of Reactos,

    I Am very nicely surpriced by The fact, that so complex project like developing new
operating system from scratch based on Windows XP kernel and API functions calls exists. I
tried to install The Reactos and i can tell You, that even visually impaired user can
install Reactos to The empty computer harddrive without need to even make unattended
installation. I was able to successfully install Reactos operating system to my computer.

    I Am now solving issue, how to install The driver for my sound cart when many
functions of Reactos are for now only accessible with mouse. So please, if Reactos device
manager is reporting, That The sound device is working correctly, but only multimedia
adapter list item is presenting my Soundmax integrated digital audio sound cart, it do not
means, that Reactos can automatically use this eevice without need to add The driver?

I tried to install The driver by using The setup program provided with The driver, i
unfortunately have got a error message, that setup has occurred an error and must be
closed. Please check, if another instance of setup is not active.

By using add new hardware wizard, could i install The driver by specifiing The exact
location for this driver?

It is The WDM based driver for Soundmax digital integrated audio, which is build in The
motherboard of The IBM Thinkpat 2668. 

I would like to know, if Microsoft Active accessibility standards could be implemented on
The future during developing Reactos. I found out, that oleacc.dll is being presented and
is The part of The Reactos installation. But i do not know, if You could implement MSAA
standarts, because knowing The API functions and The object methods and properties will
not be probably enough to ensure, that MSAA standarts would work.

I would like to test some screen reader, which is based on using API calls and by using
MSAA calls, but i do not know, if it is implemented.

My problems is now to add sound cart driver to test this.
I Am advanced user with some advanced system administration knowledge, i know Windows
operating systems starting with Windows for Workgroups 3.11 to Windows XP Professional. I
can use Linux distributions to copy some needed files to The partition, where Reactos has
been installed. I can even find necessary debug logs and send them as AN E-mails by using
Linux distribution.

Linux distro could help me in The situations, when Reactos can not give me some feetback.

Installing sound driver manually by using registry editor is not easy task and i can not
perform it without screen reader support.

I Am surpriced by The stability of Reactos. Eventhough some API calls are not awailable
for now, The kernel is very stable and i have never got some crash dialog Window informing
me, that application has crashed, sorry for any problems.

If You would try to think about implementation of MSAA, many visually impaired users would
be very very glad because of it.

And later, what about triing to implement some hod keys for controlling The user interface
and for controlling The Explorer?

Thank you very much, i Am ready for debugging and testing The Reactos.

PS:

I have never able to install and run Windows XP so quickly, without using Nlite program,
which is able to modifi setup.sif file and some other files on Windows XP installation CD,
i would never been able to perform The installation of commercial Windows XP myself. Only
with Reactos, i could perform this without stress and without need to use some other
external utility.

I AM also very very glad, that Reactos is even able to work as a live CD.

And here are some links for downloading freeware or opensource screen readers, which are
fully compatible with Windows Xp and are not based on Display chaining manager DCM, which
is too complex to implement even on future for You. Those screen readers are based on
using API calls and on using MSAA standarts.

Unfortunately, NVDA will not work, because some important libraryes are not The part of
The installation of Reactos. It is probably wrong idea triing to mix original libraries
from Microsoft with Yours operating system, because i think, that it could cause some
confuses and often crashes.

Because i can really constructively cooperate with You, i will send You The list of
libraryes, on which NVDA screen reader is depend on.

And here is The direct link for downloading latest stable version of NVDA, which do not
have to be installed, You can only unzip it and place it on some directory on Yours
Reactos installation.



http://www.nvda-project.org/download/releases/nvda_2009.1_portable.exe

I Am recommending You to join to The NVDA development mailing list. YOu will need to have
YOur sound drivers properly configured. NVDA screen reader is by The default triing to
load included Espeak speech synthesizer, which is The part of NVDA package. This speech
synthesizer is written by using Microsoft Visual C++ express 2005, and The original source
code of this speech synthesizer variant for WIndows has been modified so this synthesizer
is not working like The SAPI5 compatible speech synthesizer, but like a Activex library,
which can be called from NVDA.

Espeak will very probably depend on wdmaud.drv and NVDA is also using winmm.dll library.

The list of dlls, which NVDA is using will be sended on The separate E-mail.

PS:

Please, try to allow visually impaired computer users to use freeware and fully functional
operating system, which is based on standarts of WIndows XP and 2003. If MSAA standarts
are too complex to develope from scrath for You to prevent random crashes while using
Yours future new dlls, which would come out from this standarts, i will understand it. You
are working on very, very complex project while using legally obtained technical
information from various sources.

PS:

I know, that it is not possible to use products, which are developed by Microsoft on other
operating system, that on original operating system from Microsoft, so triing to donwload
WIndows Internet Explorer 8.0 and triing to use it with Reactos will probably not be
legal.

But if it is so, never mind. There is Mozilla Firefox WEB browser, which is working with
NVDA screen reader very nicely, and also Opera WEB browser is able to provide some
accessibility support for visually impaired computer users.

And Openoffice ORG is also working very nicely.

But for now, i would atleast like to try, if NVDA can speak atleast somethink or if many
API calls are not presented.

Thank You for cooperation with me.

With kindness regards.

Janusz Chmiel

[victor martinez]

Dear ReactOS User,


First of all i am very glad to see that people is finding ReactOS useful and indeed
winning some battles to Windows (at least in the Installation).We have indeed a full
unattended setup, so it can get installed just pressing a Key(of course installing with
default values).

When I was introducing ReactOS at Imaginatica Event (with Kjk,Elhoir and Myrjala) one guy
asked us about impaired support. Really ReactOS should support any app designed for
Windows, but of course it is just the theory.As i said, since that question, i got
interested in finding a GPL project for improving accesibility and i found the project you
linked us: NVDA screen reader.

I managed to install it in VirtualBox+AC97 driver included in our Rapps application. When
i tried the first time our sound support was too green(i am talking about one year ago)
and it failed. But in Octuber i recheck and i heard something!!I heard a ClonClonClin,
which means NVDA is ready, but 1 second later i heard a ClinClinClon,which means an error
has happened and the app was closed.

I was really interested in this comboproject: ReactOS+NVDA, since in Spain we have a quite
interesting organization for impaired people called ONCE, www.once.es, which pays and
supports (finantially)this kind of initiatives.So maybe we could find a mutual agreement:
ReactOS improves its Kernel Sound support(to support NVDA) and ONCE wins an OpenSource OS
with high accesibility.
Alternatively this initiative can be sent to Google Summer of Code (Gsoc),so janderwald or
any other developer interested can win a little of money thanks to his wonderful work.

After finishing my exams i will retest this App in ROS and (why not?) in Arwinss too ;)



 		 	   		  
_________________________________________________________________
¿Aún sin la última versión de Internet Explorer 8? ¡Actualízate gratis!
http://www.vivelive.com/internetexplorer8

[Jose Catena]

Hi,

 

I'm being asked about the msvc build and decided to answer in the list to
keep you all informed on the status.

 

Today I submitted a non working update to my branch:

svn://svn.reactos.org/reactos/branches/jcatena-branch

useful for reference for those interested in msc builds.

 

Before I got a svn branch where to commit, I got ntoskrnl built by msvc9 and
booting to desktop, 

Based on build 44678. This is not synchable with svn, but I have put it in
my server if someone wants to take a look:

ftp://diwaves.com/reactos/ntos_44678_local.zip

 

After I got a svn branch, I started to make the same happen without changing

so much. Unfortunately this was in the middle of the trap handling rewrite.

This is being done in a really weird, unportable, hackish and unefficient
way,

and I had a lot of problems to have the port booting. Finally, after much
more

work than expected, I got the port working but with some weird temporary

hacking I didn't like, and then wanted to sync with more current version,

only to find that the trap handlers were substantially changed again, in an

even more unportable way. So instead of keep debugging and hacking a code
that

i would pretty much drop at the end, I started rewriting it yesterday and I

expect to have it working in less than a week. This will save efforts at the
end.

 

Initially I wanted to commit only a working branch, but since it's taking
time

and other devs may benefit from what's done even if it is not complete,

i decided to have the working not synchable version based on 44678 available

at my server, and the non booting svn branch r45369 commited.

 

I recommend taking a look at platf.h and cpu-c.h, these files contain
platform

and compiler dependent definitions and macros, that make most inline
assembly

and compiler conditionals elsewhere unnecessary.

 

Hope you find this useful.

 

Jose Catena

DIGIWAVES S.L.

[Ros Arm]

Hello,

Would you care to comment on "unefficient" regarding the trap rewrite, please?
The code is more efficient than previous assembly code, and more finely tuned than
Windows' own code, which wasn't updated since 1989 when it was first designed (and
is full of non-pairing, hazardous operations that were efficient only on a 486).

I also resent the hackish statement.

Perhaps GCC Extended Assembly is hard to understand? I would be happy to walk you through
it.

Finally, in any team project, it is efficient to subscribe to SVN notifications and keep
track of the project status. This way it would've been clear that a trap rewrite was
in progress, and we could have worked together.

-r

>   Hi,
>  
>   
>  
>  I'm being asked about the msvc build and decided to answer in the list to
>  keep you all informed on the status.
>  
>   
>  
>  Today I submitted a non working update to my branch:
>  
>  svn://svn.reactos.org/reactos/branches/jcatena-branch
>  
>  useful for reference for those interested in msc builds.
>  
>   
>  
>  Before I got a svn branch where to commit, I got ntoskrnl built by msvc9 and
>  booting to desktop, 
>  
>  Based on build 44678. This is not synchable with svn, but I have put it in
>  my server if someone wants to take a look:
>  
>  ftp://diwaves.com/reactos/ntos_44678_local.zip
>  
>   
>  
>  After I got a svn branch, I started to make the same happen without changing
>  
>  so much. Unfortunately this was in the middle of the trap handling rewrite.
>  
>  This is being done in a really weird, unportable, hackish and unefficient
>  way,
>  
>  and I had a lot of problems to have the port booting. Finally, after much
>  more
>  
>  work than expected, I got the port working but with some weird temporary
>  
>  hacking I didn't like, and then wanted to sync with more current version,
>  
>  only to find that the trap handlers were substantially changed again, in an
>  
>  even more unportable way. So instead of keep debugging and hacking a code
>  that
>  
>  i would pretty much drop at the end, I started rewriting it yesterday and I
>  
>  expect to have it working in less than a week. This will save efforts at the
>  end.
>  
>   
>  
>  Initially I wanted to commit only a working branch, but since it's taking
>  time
>  
>  and other devs may benefit from what's done even if it is not complete,
>  
>  i decided to have the working not synchable version based on 44678 available
>  
>  at my server, and the non booting svn branch r45369 commited.
>  
>   
>  
>  I recommend taking a look at platf.h and cpu-c.h, these files contain
>  platform
>  
>  and compiler dependent definitions and macros, that make most inline
>  assembly
>  
>  and compiler conditionals elsewhere unnecessary.
>  
>   
>  
>  Hope you find this useful.
>  
>   
>  
>  Jose Catena
>  
>  DIGIWAVES S.L.
>  
>   
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Jose Catena]

Hi,

Don't feel offended, the port to c is a very good thing and indeed better in
the most part than the previous asm implementation. I value your work very
much.
But there are some aspects badly implemented:
1) It is not possible to write a good stub in an inline function nor in a
regular macro due to c preprocessor limitations. Your implementation trust
the optimizer to remove constant conditionals, but it does not work as well
as you may think. Have you seen the generated code? It has a lot of
unnecessary branching. I have implemented it as an x-macro, where I can use
the preprocessor to select the options to be generated and it does not
generate any run time conditional branching.
2) You have added many inline assembly parts in several files that should be
kept as portable as possible. These things are better put together in
architecture dependent files/directories. Furthermore, most are unnecessary,
my single trap stub in a single x-macro replaces most of your inlines. 
3) Since the pointer to the trap frame is passed to handlers, why do you
pass as extra parameters information that is already there? Access to
members of the KTRAP_FRAME is just as fast as access to local variables or
parameters, but saves on additional copies and allow more efficient register
usage. Furthermore using regparam(3) for functions called from inline
assembly, when actually only one param was needed, was really a very bad
idea. And you pass the same parameters to child handlers in cascade, again
and again. This is very unefficient. Today I simplified the syscall and
fastsyscall handlers removing a lot unnecessary parameter copying and
cascading, saving a lot of cycles and memory, while making it much easier to
read and understand.
4) Why did you resort to code patching to encode the PKINTERRUPT parameter,
instead of generating a static variable named together with the stub, for
example? Wasn't it hackish? I hope you understand that you won't save even a
cycle that way, so why to use such an unportable and complex method?
 
The worst thing is the indiscriminate and spread use of inline assembly and
compiler specific features. Please think in placing such things in platform
specific includes and try to make them as general and reusable as possible,
instead of making the code base very difficult to port and maintain.

Please take this as constructive criticism and not as any personal offense.
We all can always learn better if we can accept criticism.
 
Jose Catena
DIGIWAVES S.L.

[Ros Arm]

Hi Jose,

I think there are some misunderstandings regarding the GCC code base I would like to clear
up inline.

>   Hi,
>  
>  Don't feel offended, the port to c is a very good thing and indeed better in
>  the most part than the previous asm implementation. I value your work very
>  much.
>  But there are some aspects badly implemented:
>  1) It is not possible to write a good stub in an inline function nor in a
>  regular macro due to c preprocessor limitations. Your implementation trust
>  the optimizer to remove constant conditionals, but it does not work as well
>  as you may think. Have you seen the generated code? It has a lot of
>  unnecessary branching.  
I look at the generated code almost every build, so yes I have seen it. The optimizer is
working correctly and there are no unnecessary branches. All the branch checks in
functions such as KiExitTrap are removed and the correct inline code is generated in all
callers. If you are seeing a different result, something is wrong with your compiler or
build settings.

>   I have implemented it as an x-macro, where I can use
>  the preprocessor to select the options to be generated and it does not
>  generate any run time conditional branching. 
That is another solution, however mine works just as well, as I can show with objdump.

>   2) You have added many inline assembly parts in
> several files that should be
>  kept as portable as possible. These things are better put together in
>  architecture dependent files/directories. Furthermore, most are unnecessary,
>  my single trap stub in a single x-macro replaces most of your inlines.  
I have merged all entry ASM code into one stub, but I have yet to merge the exit ASM Code
into one stub as well, so it is true there are too many similar functions for now. Yes,
trap_x needs to go to i386. But these are not "inefficiencies", it's the
result of a WIP.

>   3) Since the pointer to the trap frame is passed to
> handlers, why do you
>  pass as extra parameters information that is already there? Access to
>  members of the KTRAP_FRAME is just as fast as access to local variables or
>  parameters, but saves on additional copies and allow more efficient register
>  usage. 
If you are talking about the case where EFLAGS is being passed, there is a large comment
explaining why this is done. Perhaps you could try reading it, and understanding the
problems of segmentation even in a flat model.

I am not aware of any cases where extra parameters are being passed, other than for
specific inline helper functions, in which your argument does not exist due to the fact
the register usage has already been optimized by analyzing the inline and caller function,
so this is more efficient than re-reading the field from the trap frame.

>   Furthermore using regparam(3) for functions called
> from inline
>  assembly, when actually only one param was needed, was really a very bad
>  idea.  
You'll have to show an example, but I think you are once again misunderstanding inline
functions. Finally, I don't know if you are unaware of regparm(3), but using only one
parameter has no negative side-effects (if this is really the case). In this case, only
one register will be used. It is not as if the other 2 registers are "lost".

>   And you pass the same parameters to child handlers in
> cascade, again
>  and again. This is very unefficient.  
I have no idea what you are talking about, other than specific inline cases where there is
no "cascade" since the code is flat. Perhaps you'd care to have some
examples.

>   Today I simplified the syscall and
>  fastsyscall handlers removing a lot unnecessary parameter copying and
>  cascading, saving a lot of cycles and memory, while making it much easier to
>  read and understand. 
If those are the handlers you are referring to, they are all inlined, making your argument
moot. There is no cascade or register passing.

>   4) Why did you resort to code patching to encode the
> PKINTERRUPT parameter,
>  instead of generating a static variable named together with the stub, for
>  example? Wasn't it hackish? I hope you understand that you won't save even a
>  cycle that way, so why to use such an unportable and complex method? 
This is the code that Windows implements as well and is documented to function as such in
multiple places. Also, I do not see how a "Static variable named together with the
stub" would work. No it was not hackish, it's an efficient design that ReactOS
must further emulate due to the fact it is documented and code depends on this model.
Again the comments explain this, if you wouldn't mind reading them.

>    
>  The worst thing is the indiscriminate and spread use of inline assembly and
>  compiler specific features. Please think in placing such things in platform
>  specific includes and try to make them as general and reusable as possible,
>  instead of making the code base very difficult to port and maintain. 
Perhaps you would like to go back to the 5000+ lines of GCC-only, i386-only assembly. Now
the only parts remaining with ASM code number less than 50 lines, while the rest of the
code is portable. In fact the whole point was to re-use a lot of this code in the ARM
port.

>   
>  Please take this as constructive criticism and not as any personal offense.
>  We all can always learn better if we can accept criticism. 
Likewise,
-r

>    
>  Jose Catena
>  DIGIWAVES S.L.
>  
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Jose Catena]

Hi,

 

Sorry, I placed the old nonsychable but working version in a restricted
folder, correct downloadable link is:

http://diwaves.com/reactos/ntos_44678_local.zip

 

 

Jose Catena

DIGIWAVES S.L.