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
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
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.
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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.
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:
- 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.
- 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.
- 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.
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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.
-
Jose Catena -
Mgr. Janusz Chmiel -
Ros Arm -
victor martinez