Our Withe Paper on http://www.reactos.org/xhtml/en/dev_whitepaper.html says
> The original target for ReactOS, with regards to driver and application
> compatibility, was Microsoft Windows NT 4.0. Since then, Microsoft
> Windows 2000 and Windows XP have been released. Microsoft Windows 2000
> and Windows XP are both descendants of Windows NT. As such we can
> gradually shift our compatibility target without worrying about the
> architecture changing too much. In fact, internally, Windows 2000
> reports version information as Windows 5.0 and Windows XP as Windows
> 5.1. The ReactOS team have decided to maintain Windows NT 4.0 as the
> official compatibility target. This is because most of the resources,
> articles and books on Windows NT/2000/XP technology are written for
> Windows NT 4.0. This does not mean that features present in later
> versions of Windows NT based operating systems will not be implemented
> in ReactOS.
Since we changed the reported version to Windows 2000, i'd say that is
not true anymore is it ?
Maarten Bosma
Hi,
as you may know rbuild uses its own XML reading routines independent
from any existing XML parser. This means there is missing some
functionality we could get using a "real" XML parser:
- no real syntax and hierarchy check of XML data
- no UTF-8 support
I am working on integrating Expat (the XML parser used for example in
ROS Explorer) into rbuild. This is currently only an experiment just
for fun - independent from ReactOS. I may use this rbuild derived
build system for some private projects. Is there any interest to
include Expat into the ReactOS version of rbuild?
Regards,
Martin
Reverse engineering.
USA states clear rules.
A person who pulls appear the code cannot take part in creating the new
code or device. Ie Document how it work.
This rule does not change where ever you are.
Reverse engineering cases have been fort and lost in most countries
because developer not been able that they did not copy X section of code
directly from what they were Reverse engineering. Ie since the code
matched close enough it was pick since they had seen inside the program
they copied and then tried to hide it. USA method prevents this. The
coder never saw inside the program so it must be a fluke.
Legal or not is not the issue it if you can prove that you have not
breached copyright in a court of law.
Digital Millennium Copyright Act (DMCA) Has never been tested in a court
of law. Australian Government had something simpler for about two
months since then fair use clauses have been added allowing reverse
engineering and other methods of bypass with restrictions of course you
cannot set out with the reason bar to break DRM but setting out to
bypass to allow legal backups or for compatibility is fine or to bypass
some other forms of stupidity. Ie region codes fall into stupidity. I
by a legal copy of something bring it home then cannot play it that is
stupidity. DRM is not allowed to create trade barriers if so it illegal
so completely open to attack.
Simple example provide it.
Completely Open Source Player. Linux kernel ...
Only part closed kinda was a public key.
The license on the key was a killer.
[quote]
You here by agree to use only approved software on any machine that is
use with this public key. No existing or third party data allowed on
the playing device along with the public key except for approved
software and file created by approved software as part of approved
software operation.
[/quote]
Now a pirate that does not care about the license does not have to
format their computer to watch the video. Law abiding person has to.
Note approved software only contains a player not a converter. Pirate
is free do what they like and law abiding is hurt majorly. The addon's
in Australia would allow above to be got around legally.
Just give this to your government. They realize there is a flaw in the
DMCA and its not friendly.
We have a mess. Fighting over what rules apply here apply there solve
nothing. Laws that have not been to court may or may not hold.
Lets take a really good look at the source tree.
-Insert new version of externally source sections.
Leave documentation so next update of this section is simpler.
Note my Zlib patch posted to ros-dev is a requirement 1.1.4 has known
security problems. Most likely there are more.
-Locate sections that need documentation written.
Rbuild is one of these things that needs documentation for new
developers. It confused the heck out of me. I am not a documentation
writer. I woffle to much and suffer from dislexer so sometime
documentation I can read no one else can(yes it can pass a grammar and
spell checker).
-Find features that external libs need added to improve them inside
Reactos to produce a better Reactos.
Mesa could do with a opengl version change option. Ie no hardware accel
and low processor user drop it back to version 1.2 opengl. Ie
adjustable 1.2 takes a lot less process to render than 1.5.
Developers could work on adding these features while main tree is
completing audit. Developers with nothing to do get upset.
I guess most of the developers in Reactos that this first time they have
had to handle a Audit. Key to handling a Audit effectively is not to
remain frozen at the same point in time. But to move forward in the
process of Auditing. If have access to external developers get them
working on parts that will be required in future as soon as able
normally requiring feature requests.
Peter Dolding
Allow me to just put it this way, reverse engineering IS illegal,
HOWEVER even Microsoft reverse-engingeers stuff that they want to know
how it works and to write drivers/etc for, so I still don't see the
point of why anyone would have a problem, it's not like ReactOS is the
first to utilize reverse-engineering practices to learn something, and
secondly I'd like to point out by the information I have studied,
ReactOS DOESN'T have Windows source code in it (at least by the
current facts, no) it was suspected that so due to a certain crash
that looked similar in terms of debugging very identicle to Windows.
--
-David W. Eckert
Get zlib 1.2.3 extact to a directory. Apply patch to that directory
with normal bzcat zlibreactos.diff.bz2 | patch -p1
Read the README.ROS please edit as required. Me English don't mix.
Made attempt at instructions for next updater of that section. I don't
mind if it gets deleted if my English is to bad.
When happy delete the old zlib dir and replace with the zlib 1.2.3
directory.
If liked update to svn. As far as I can see it give no problems with
Reactos 0.2.9. After in svn no need to audit if you look closely their
is only one minor change other than that is zlib-1.2.3. Clean code.
Peter Dolding
Forwarded from ros-translate to ros-dev
_____
From: mailman-bounces(a)reactos.org [mailto:mailman-bounces@reactos.org] On
Behalf Of banglasoft
Sent: Friday, February 10, 2006 03:06
To: ros-translate-owner(a)reactos.org
Subject: hi we have translated the explorer of React OS ...........
hi gvg and other React OS developers,
we have translated the React OS explorer in bangla. here is a screen shot
attached with this mail. now we r looking forward to hearing from u people.
if u give us the permition than we will translate the whole React OS. we
think if some one translate the React OS in Bangla then this definitely will
be a grate improvement for the React OS. React OS will be more femous then
windows OS amoung the bangla speaking people.
we r waiting for u r reply.
-banglasoft.
Carlo J. Calica wrote:
> I don't remember reading that on this list. The public
> allegations were:
> wide spread "questionable" reverse engineering practices, and
> devs looking
> at leaked code.
There were many allegations thrown about. One of the first places for
something to appear was our own forums in which the post was titled
something along the lines of "ReactOS contains MS leaked source code" (I
don't remember the exact wording). I picked that one because it was
completely untrue and unfounded. I was just using it as an example of how
something untrue can escalate into something damaging.
>
> > Now, if this mail was received privately, we could have
> dealt with the
> > issue internally and avoided all this mess. Development would have
> > continued whilst we resolved any potential issues. For the
> community and
> > the project as a whole, which would you consider to be the
> better option?
> >
> Pretending issues don't exist won't make them go away. The resolution
> shouldn't change if discussed in private or public.
I never once said they would. I don't know where you got that from.
The way something is handled can vary greatly dependant on the
circumstances, but that doesn't avoid the fact that the issue remains and
must be dealt with.
> Maybe development
> could have continued during a code review, but then the code
> review would
> take much longer and may never be completed. There might
> never have been
> the clarification on reverse engineering techniques. As a
> potential user
> and project proponent, I am VERY happy with the whistle
> blowing and the
> public response. ReactOS IS stronger after this setback.
> Now you have a
> good IP policy that is defensible.
We don't have a valid IP Policy at the moment.
I also fail to see how a project on the edge of closing and divided
developers is stronger.
> PLEASE reconsider the private list. Failing that, members of
> the list, move
> public topics here. We DO appreciate it. It IS for the good of the
> project.
Public topics are _not_ discussed on the private list. In all honesty, very
little is discussed on the private list.
This is just another example of something being blown out of proportion.
Developers have been having private discussions since the project started
about 8 years ago, however they are few and far between. It's just that now
instead of using private emails exclusively, a mailing list has been set up
for convenience. Nothing has changed.
I'm sure members of the community who are non-developers also do the same. I
don't ask that they discuss their issues on the public mailing list either.
> Don't feel the need to respond. I just wanted to provide an alternate
> viewpoint. This topic is very much opinion. I doubt you'll
> be able to
> change mine and I may be unable to change yours. I am nothing but an
> interested observer, you owe me nothing. Thanks for hearing me out.
All views are fully welcome, and valid. This project belongs to everyone.
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Rick Langschultz wrote:
> Creating a private mailing list
> not available to the community restricts information from getting to
> developers that want to continue to develop reactos, whether they
> commit or not.
The private mailing list has nothing to do with development and certainly
contains no information that could be deemed useful towards the development
of ROS.
It's just somewhere developers can discuss sensitive issues without worrying
about setting a an exponential bomb off.
All projects have their problems. It's much better for both the project and
community as a whole if these problems aren't broadcast worldwide. We used
to use personal emails or MSN, this just takes over that role making it
easier and quicker.
I'll give you an example, take the recent allegations of leaked MS source
code in the ReactOS repository. These allegations completely were untrue,
however as soon as this found it's way onto the public mailing list, drastic
and maybe over reactive actions were taken.
This email has single handidly stopped all development of ReactOS for the
past 2 weeks and has the potential of holding the project up for a year or
two. It's safe to say the project has been in trouble of dying off
completely.
Now, if this mail was received privately, we could have dealt with the issue
internally and avoided all this mess. Development would have continued
whilst we resolved any potential issues. For the community and the project
as a whole, which would you consider to be the better option?
All projects have their problems, you just never hear about them because
they aren't made public. There is nothing to be gained by hanging out your
dirty linen in public.
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Subject: Which way you would like ReactOS to go?
Proposed by: fireball
Days of discussion: 7
Days of voting: 7
Proposal: Two plans for further development are being proposed, Plan
A - "current", Plan B - "proposed"
Rationale: -
Further information is available in the Votings forum.
Note to readers: Only developers can take part in the voting.
Thanks,
Aleksey Bragin.