Hi,
I wanted to extend my thanks to ReactOS developers. I have used the
ReactOS source code on several occasions to help develop and debug
drivers intended for Microsoft Windows (WDM NT). I also used it to help
diagnose a hardware problem.
The Vista Windows Driver Kit sometimes include sample driver code
that will not work on systems newer than Windows 2003. I think I
actually used OpenRCE.org to help figure this out, but ReactOS does a
better job of letting me follow kernel level function logic.
The new PREfast annotations are also poorly documented but I don't
expect ReactOS will help with that. Perhaps its drivers could help
though.
One computer we had was bug checking (BSoD) with an NMI error with
Windows XP. Microsoft's documentation on this was poor and sometimes
misleading. Many other web sites provided incomplete (mostly just
inquiries), or misleading information (speculation that the wrong
hardware was at fault). With WinDBG, a search engine, and the ReactOS
source code, I managed to find what hardware was generating the bug
check. I then looked up the specifications from Intel and got quite a
bit of a better understanding.
I vaguely recall Walter Oney's WDM driver book provides a stub driver
which will help newer Windows drivers run on older versions of Windows
(although it's not redistributable and is documented as a workaround he
doesn't want others to use). Pointers to this may help ReactOS driver
developers.
Making sure source code is easy to search with Google is very useful. I
see that Google's source code search seems to search ReactOS, and
there's some Doxygen documentation that can be searched. Unfortunately
SVN or even other current source code seemingly cannot be searched without
using alternate methods (such as downloading and searching offline).
Ideally, something like lxr would be available for ReactOS, and through
Google. I also have the same wish for the most recent version of the
Linux kernel (Google doesn't seem to index lxr).
Having more sample driver code (even third party) would certainly be
useful.
I'd like to sell companies on using ReactOS, but there seems to be a
real anti production use message widely conveyed. I feel ReactOS is far
more stable than is given credit. That said, it would be nice if even
just some basic core part of ReactOS was stabilised (not even at a
Desktop user level). By "stabilised", I mean if people could test and
testify certain kinds of qualified stability (e.g. Version q ran x days,
but it was only doing y and had z hardware). Also it would be nice to
have even more information about changes to ReactOS that have/might make
things likely to break (bugcheck, freeze, not behave...). At least one
of the recent newsletters helped with that.
I'd love to use ReactOS to replace simple Windows XP Embedded images
(with many drivers and features stripped out).
Once again, thanks for all the ReactOS efforts. I'm sure I do not yet
fully appreciate the resources available to me because of ReactOS, but
the ones I've found have been extremely useful.
Drew Daniels
Resume: http://www.boxheap.net/ddaniels/resume.html
Hi,
Someone from the forum has written a replacement for winecalc and asks,
if we would want to use it. I think it deserves some attention:
http://www.reactos.org/forum/viewtopic.php?t=3585
- The code is smaller than winecalc.
- It seems to (almost, see below) work correctly as far as I have tested
(type 2+3*4 in winecalc and you will get 12 as result....)
- brackets are working (not implemented in winecalc)
- inv is working (not implemented in winecalc)
- It looks a little better than winecalc
"bugs" found so far:
- there's an issue with foucs, that is put on a button when switching to
another app
- grad calculates with 200 instead of 400 = 360°
- modulo and hyp seem unimplemented
- you can't use and, xor, ... in dec mode
Greetings,
Timo
This breaks the very beginnings of the compile process.
WBR,
Aleksey Bragin.
On Mar 20, 2007, at 11:12 PM, janderwald(a)svn.reactos.org wrote:
> Author: janderwald
> Date: Tue Mar 20 23:12:10 2007
> New Revision: 26147
>
> URL: http://svn.reactos.org/svn/reactos?rev=26147&view=rev
> Log:
> - fix makefiles to depend on TOOLS_OUT_ value than directly
> hardcoding it to $(OUTPUT)
>
Hi,
I am from Berlin, Germany and really interested in joining the ROS
project as a developer.
I started as proposed with digging into the code a little bit and wrote
some patches. So my first question is, which developer (with svn write
access) do i have to contact so that he can help my to review and
(hopefully) apply some of my patches?
Second thing is that i read that you are already planning a complete
rewrite of the explorer code. I would really like to be a part of the
explorer project but others are also welcome.
If you have any idea how to start just let me know.
With best regards,
Tim Taubert
Hi,
I tried to build the ReactOS main trunk, but I've run into some problems.
'make all' fails with the message:
mkdir: cannot create directory
`obj-i386\\lib\\inflib_host': No such file or directory
Up until now, I've got the 'trunk' directory from SVN (using TortoiseSVN), I
exported the sources to a directory in the ros Build Environment (I was
asked for that directory on install) and attempted to build from there. I
also looked at the Makefile and set the '-mi' flag (ROS_RBUILDFLAGS = -mi),
but that didn't help.
Just for the record, I'm building on a WinXP SP2, using ReactOS Build
Environment 0.3.5b2. I also tried the 0.3.4 version, but I run into the same
issues.
Do you have any ideas?
Thanks,
Radu
>Sorry for waiting until now to reply.
It's all good. : )
>What do you think?
I think we should convert to BE, but not away from PE-COFF. There are too
many differences between them, and while it would be less work in the short
term to switch to ELF, in the long term, implementing all of the features of
PE would be very troublesome. Not the least concern is that information
such as import data and file headers aren't even mapped into a process's
address space with ELF. As I understand it, when you get an IHANDLE to a
linked in DLL it's just a pointer to the mapped in PE file header. I'm sure
there are programs that require this on a source level to run (which, for
quite some time will be the only thing that affects us on the PowerPC side
of things).
That being said, a proper pe-powerpcbe target in gcc should then be the
first priority. Binutils already more or less properly creates pe-powercbe
files (with what I assume are your patches on the wiki, and a little
monkeying to make sure that the MZ header and PE signature are always
written as little-endian regardless of the target architecture). What kind
of issues had you had on the EABI side of things, and what was your plan in
more detail for emulating the features of PE in ELF?
Also how much progress had you made in the port up to now?
~Tristan Miller
(monocasa)
Dear friends,
We are 3 undergrad comp sc. and IT students from India. We have some coding
experience but have never worked for the Open Source Community as
developers. Yet we have always admired the concept and used FLOSS stuff like
GNU/Linux.
We came across ReactOS project and got really interested in it. We really
want to contribute to the development of React OS and since we are new in
Open Source development, we would require your guidance and support in stuff
like understanding the code, building the build environment etc.
Among other shortfalls that we have, we haven't programmed much on Windows
platform (almost always Linux ie) and hence know little about the Windows
API. But we are eager to learn and can definitely learn parts of the API as
long as you can guide us.
We humbly request you to guide us and give us some problems so that we can
try and support this community. A lot is left to be done in ReactOS and it
would be great being a part of such a project.
Also we are better at writing C codes than reading them ( like almost
everyone ;) ) and hence would request you to give us some problems that we
can write from stratch rather than bug fixing that would require reading all
codes.
But we are ready to contribute in any way you feel we can as developers and
support this community.
Regards
Arko Provo Mukherjee
Abhishek Biswas
Biswanath Banik
Hi Guys
I have recently discovered ReactOS through my research for Linuxforums.org,
I have written an article on ReactOS, which should show up online in the
near future. Basically I like your work and I would be keen to contribute
some of my (unfortunately limited) time and skills to your project. I cant
code but I can write ok.
Could I be of any use to you guys?
Cheers
Sam
--
Did you know that if you play a Windows XP cd backwards, you
will hear the voice of Satan?
That's nothing! If you play it forward, it'll install Windows XP.
Hey,
Sorry, having problems with internet or else I'd ask this on IRC. I was
curious as to why the emphasis on little-endian mode in powerpc. Mac G5's
don't even have le-mode, and it definitely seems that (although im not
totally sure, as theres not much info out in the wild yet) that the XBox360
lacks le-mode as well. Also, on the processors that support le-mode, it
seems in all cases (although theres probably some embedded guy that I'm
missing : P) that do support it, it's selectable at the minimum at the
user/supervisor level with only a bit of work. Perhaps eventually a
thunking layer (maybe a part of NTVDM, would it need to be that complex?)
that would translate the calls from le usermode to a be kernel could be
written, allowing one to run NT-PPC applications that are out there. We
wouldn't be able to load drivers (or any le kernel code), but are there
actually any PPC drivers out in the wild? Plus, it seems that it would
definitely be a good thing for the kernel source to be tested on multiple
endians as early as possible in its development to ease porting later on.
~ Tristan Miller
(monocasa)
