On 4/6/06, Thomas Weidenmueller <w3seek(a)reactos.com> wrote:
> There are several issues with this patch:
>
> > + /* What a strage dance */
> > + struct client_config *config = ifi->client->config;
>
> 1) dhcp crashes for me on the line above.
Strange, it works for me here.
>
> > + char ComputerName [MAX_COMPUTERNAME_LENGTH + 1];
>
> 2) use Unicode, please. Obsolete as described in 4)
I really tire of hearing this. None of the code in dhcp.exe is
unicode right now. I've tried to hack on several pieces of ros only
to be told "USE UNICODE" by another dev. Trying to convert entire
modules has always gone terribly for me.
>
> > + DWORD ComputerNameSize = sizeof ComputerName / sizeof ComputerName[0];
> > +
> > + GetComputerName(ComputerName, & ComputerNameSize);
>
> 3) missing error check, leading to buffer overflow if accessed the
> string in ComputerName
>
> > + /* This never gets freed since it's only called once */
> > + LPSTR lpCompName =
> > + HeapAlloc(GetProcessHeap(), 0, strlen(ComputerName) + 1);
>
> 4) makes the ComputerName buffer on the stack obsolete. Only use the
> dynamic buffer. strlen will likely cause a buffer overflow if the
> computer name was longer than the length of the (obsolete) static buffer
> on the stack, since the static buffer will never be initialized in this
> case.
I'll try to fix this.
>
> > + if (lpCompName !=NULL) {
> > + GetComputerName(lpCompName, & ComputerNameSize);
>
> 5) once again missing error check which may cause buffer overflows in
> the following code
>
> > + /* Send our hostname, some dhcpds use this to update DNS */
> > + config->send_options[DHO_HOST_NAME].data = strlwr(lpCompName);
>
> 6) strlwr is POSIX ;)
Not helpful, suggest something better.
>
> > + config->send_options[DHO_HOST_NAME].len = strlen(ComputerName);
>
> 7) operating on the wrong buffer, may cause buffer overflow due to 5)
>
> > + warn("util.c read_client_conf poorly implemented!");
>
> Indeed :(
>
> Apart from the bugs mentioned in this code, GetComputerNameExA has a few
> bugs: 1) incorrectly returning ERROR_OUTOFMEMORY instead of FALSE and 2)
> not checking the return value of RtlUnicodeStringToAnsiString.
>
> - Thomas
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
WD
--
<Bizzeh> it even has a panda that pops out of your case and mauls
people who ask stupid questions
Thomas Weidenmueller wrote:
> I don't mean to offend anybody with my criticism, I just want to point
> out what could and should be fixed or done differently.
Your criticism is hugely appreciated. That's the whole point of ros-diffs :)
WaxDragon wrote:
> I'll try to fix this.
I'll give you a hand with it tonight if you need one.
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
There are several issues with this patch:
> + /* What a strage dance */
> + struct client_config *config = ifi->client->config;
1) dhcp crashes for me on the line above.
> + char ComputerName [MAX_COMPUTERNAME_LENGTH + 1];
2) use Unicode, please. Obsolete as described in 4)
> + DWORD ComputerNameSize = sizeof ComputerName / sizeof ComputerName[0];
> +
> + GetComputerName(ComputerName, & ComputerNameSize);
3) missing error check, leading to buffer overflow if accessed the
string in ComputerName
> + /* This never gets freed since it's only called once */
> + LPSTR lpCompName =
> + HeapAlloc(GetProcessHeap(), 0, strlen(ComputerName) + 1);
4) makes the ComputerName buffer on the stack obsolete. Only use the
dynamic buffer. strlen will likely cause a buffer overflow if the
computer name was longer than the length of the (obsolete) static buffer
on the stack, since the static buffer will never be initialized in this
case.
> + if (lpCompName !=NULL) {
> + GetComputerName(lpCompName, & ComputerNameSize);
5) once again missing error check which may cause buffer overflows in
the following code
> + /* Send our hostname, some dhcpds use this to update DNS */
> + config->send_options[DHO_HOST_NAME].data = strlwr(lpCompName);
6) strlwr is POSIX ;)
> + config->send_options[DHO_HOST_NAME].len = strlen(ComputerName);
7) operating on the wrong buffer, may cause buffer overflow due to 5)
> + warn("util.c read_client_conf poorly implemented!");
Indeed :(
Apart from the bugs mentioned in this code, GetComputerNameExA has a few
bugs: 1) incorrectly returning ERROR_OUTOFMEMORY instead of FALSE and 2)
not checking the return value of RtlUnicodeStringToAnsiString.
- Thomas
> From: "Murphy, Ged (Bolton)" <MurphyG(a)cmpbatteries.co.uk>
>
> I'm going to have a look at this tonight, but I've had a look
> before and IIRC, I had trouble hunting the bug down.
> It would be good if someone with a bit more experience in
> this area could have a look.
>
> I think Ge was working on this before Christmas,
I was
> so I'm
> hopefully gonna catch up with him tonight via IM, as I'm not
> sure if he's subscribed to ros-dev anymore.
I am, although I don't read every message anymore.
The status of the applet when I worked on it was that the UI was complete
and I was starting to work on transfering the data from the dialog to the
TCP/IP driver (via the DHCP client). That part simply isn't implemented yet.
I don't have any uncommitted code floating around.
Ge
> + DWORD HELMemoryAvilable;
> + This->HELMemoryAvilable = HEL_GRAPHIC_MEMORY_MAX;
> + *free = This->HELMemoryAvilable;
There is a small typo throughout this code
"Available"
:)
************************************************************************
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
aleksey(a)studiocerebral.com wrote:
> Author: tretiakov
> Date: Fri Mar 31 21:47:52 2006
> New Revision: 21429
>
> URL: http://svn.reactos.ru/svn/reactos?rev=21429&view=rev
> Log:
> [AUDIT] msgina is clean.
>
>
What is the reason for these being clean signed off as clean?
Did you speak to the authors? Did you follow the conditions in the wiki?
aleksey(a)studiocerebral.com wrote:
> -reactos/dll/win32/comctl32 # Synced to Wine-0_9_5
> +reactos/dll/win32/comctl32 # Synced to Wine-20060328
The "synchronization" lacks a bunch of changes. Only a few files were
actually synchronized.
- Thomas
> Hey if you wanted to part with the RS/6000 arty might be interested as
> he has been doing a good bit on the powerpc port. His Mac just died
> but he bought one of those nice IBM AIX Laptops that can run NT4 and
> is working on that.
Not quite ready to part with that thing yet. I'm having a house built,
so I'll again have my own office, so I'll be able to hook it and the
Alpha up via KVM on its own desk again. Part of the reason its packed
up now is I'm living in a little tin can of a place in the meantime.
> Yes it does. Would you like me to bring it down to you? Your in the
> South East right?
Yea I'm over in GA.
If the machine has built in USB then that would be very handy to allow
me to do some debugging on prebuilt hardware instead of sticking a
generic USB card in there. I may actually be coming over to SC this
weekend
Laters,
mike
Lol, you still have that Alpha machine. My PWS 433a is still sitting in
my backroom where I wanted a port of ReactOS for so very long, but could
never devote enough time to figuring the technical details out.
Another interesting note is I still have the old RS/6000 that Eric and I
were trying to get ROS to run on PPC too, however its packed up in the
closet below my even older AlphaStation 4/233!
Does your PWS433 have USB? My latest quest has been to hack USB support
for AlphaNT, but thus far its not worked out very well, lol.
Good Luck,
Mike
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org]
On Behalf Of Steven Edwards
Sent: Tuesday, March 14, 2006 2:42 PM
To: ros-dev(a)reactos.org
Subject: [ros-dev] Alpha workstation
Hi,
Is anyone in the US interested in using the Alpha workstation for a
possible port? Its kind of gathering dust here and if no one wants it
I would rather we just sell it and stick the money in to the project
pot.
Hi,
I think ReactOS lacks of testers since WaxDragon is gone. So I had the
following idea: A page which lists all regressions and gives you the
option to report a working / non-working revision and calculates the
range in which it the regression was caused from that data.
I know that bugzilla comments are actually sufficient for this and of
course this system would have to be linked with bugzilla, but I think
that a page where the regressions are listed up would be more motivating
to help testing.
What do you think about it ?
Best regards,
Maarten Bosma
Hello,
A good news: ros-diffs mailing list has just been brought back to life, and
now fully functioning.
In order to see a colourful diff, please go to the url specified in the
email, and to have a plaintext overview - just browse through the email.
Have fun with it,
Aleksey Bragin.
Hi,
Later this spring, Dave Probert's project will finally be complete with
the realease of the WRK to academia, which means that almost any student
such as I, Brandon, Filip, etc will have access to it. What is the WRK?
The WRK (Windows Research Kernel) is Microsoft's answer to Linux/BSD
source code used in classes. It is a special version of the NT Kernel
designed to be used with the CRK (Windows NT Curriculum Kit) based on
Windows Internals 4th Edition. It is a collection of about half a
million lines of kernel code, including almost all of the process
manager, object manager, thread scheduler, and other components
discussed in the book. The PnP Manager, Power Subsystem, Kernel Debugger
however are missing, as well as other specific code. This code is
located in static libraries which are linked in at the end to create a
complete kernel.
What of the license? It is the reason why the WRK is so exciting and
it's taken so long to come out (thank the lawyers). The license allows
viewing, modifying and *creating derived work*, as long as any changes
are also sent back to MS and that copyright is not misattributed.
Additionnally, the license explicitly permits the creation of books or
other reference material, including the presense of code snippets to
better explain something, as well as sharing information in community
forums. All this is allowed for any non-commercial or educational use,
including personal research. The WRK also ships with Virtual PC, the
build environment (similar to how we use QEMU/Dazzle for TinyKRNL) and
full documentation for all the Native APIs.
With such a wonderful thing at our disposal, how will this impact the
kernel audit (postively)? What decisions do we take regarding the WRK?
Do we use it? We can either use it entirely (ReactOS is, IIRC, an
non-commercial research project, unless you still want to "vanquish the
evil MS and sell millions"), but that would mean attributing copyright
to Microsoft which many here would puke at. Alternatively, it can be
used as pure documentation, which gives us all the freedom in the world.
Or, we can be our true anti-MS/MS-bashing arrogants and call the WRK a
heresy that should never be approached or used.
Best regards,
Alex Ionescu
Here are a few of my predictions of the future of the desktop. Having
stepped back from the role of an internet developer in the past year
I have been focusing more on the programming of binary executables.
However, seeing the ever increasing change in desktop technology I am
going to make a prediction of the future of executables in the
operating system.
My prediction is: binary executable software will no longer exist
except for the underlying operating system. Instead the desktop will
be a transparent web environment that will load AJAX applications and
utilize web services to connect online data to desktop data. Also
there will be minimum to no storage locally on the users desktop
system, instead there will be online libraries filled with personal
user data which will be in XML file formats, or other text-file based
formats. This way a user can use a thumb print on the computer to
access their personal data, and email on any computer in the world as
well as in a variety of language formats.
That is my prediction of the future of desktop systems of computer
users.
Can we take this discussion off ros-dev please.
ros-dev is reserved for issues directly related to ReactOS development.
-----Original Message-----
From: Ibrahim Damlaj [mailto:idamlaj@gmail.com]
Sent: 21 March 2006 08:10
To: ReactOS Development List
Subject: Re: [ros-dev] The Future of the Desktop
Good point. However,
I think that the reason that executables are going to be extinct is because
computers are getting faster and faster. Therefore, the performance gain by
using lower-level languages is becoming less and less, which is pushing many
developers these days to use higher level (or interpreted) languages, which
are simpler and faster to program in. Also, by using interpreted languages,
the program does not need to be ported (as long as there is an interpreter
for every platform).
Therefore people tend to program in higher level (interpreted) languages
On 3/21/06, Nate DeSimone <desimn(a)rpi.edu <mailto:desimn@rpi.edu> > wrote:
Thank you for sharing that, however it is off topic.
Rick Langschultz wrote:
> Here are a few of my predictions of the future of the desktop. Having
> stepped back from the role of an internet developer in the past year I
> have been focusing more on the programming of binary executables.
> However, seeing the ever increasing change in desktop technology I am
> going to make a prediction of the future of executables in the
> operating system.
>
> My prediction is: binary executable software will no longer exist
> except for the underlying operating system. Instead the desktop will
> be a transparent web environment that will load AJAX applications and
> utilize web services to connect online data to desktop data. Also
> there will be minimum to no storage locally on the users desktop
> system, instead there will be online libraries filled with personal
> user data which will be in XML file formats, or other text-file based
> formats. This way a user can use a thumb print on the computer to
> access their personal data, and email on any computer in the world as
> well as in a variety of language formats.
>
> That is my prediction of the future of desktop systems of computer users.
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org <mailto:Ros-dev@reactos.org>
> http://www.reactos.org/mailman/listinfo/ros-dev
<http://www.reactos.org/mailman/listinfo/ros-dev>
>
>
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org <mailto:Ros-dev@reactos.org>
http://www.reactos.org/mailman/listinfo/ros-dev
<http://www.reactos.org/mailman/listinfo/ros-dev>
************************************************************************
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
Alex Ionescu wrote:
> Alternatively, it can be
> used as pure documentation, which gives us all the freedom in
> the world.
This would be the preferred method IMO.
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
Hi All,
I have decided to step down as Project Coordinator and would like to
nominate Aleksey Bragin (Fireball) to run things in the interim until
a new one is officially elected. At this time I cannot contribute the
amount of effort needed to run the project during the audit and have
many things going on as well. Fireball, Ged, GreatLord, Art and others
have been doing a good job getting things on track and I think that
given the current state of things we are going in the right direction.
I am just no longer in a position to provide the kind of leadership
needed. Aleksey has been doing a great job, getting the new SVN up,
providing general direction and helping to resolve issues that have
been coming up. He has also been working to establish a Foundation for
the project in Russia and I think it would be best to move our legal
and financial operations there. He will be setting up a donation
system and I will be transfering the existing funds to him as well as
filing the paperwork needed to shutdown US operations.
I do not have the time required to try to continue to support the idea
of a US Foundation at this point and I am not sure I believe we need
it at this point. When I had the idea initially it was my hope that
our progress would be much more rapid and our amount of donations and
support from outside the project would be much higher.
At this point I view my efforts on the project as being a successful
failure. My ultimate goal when joining was to help make a Windows
replacement/clone (call it what you will) and to see it be widely
used. In saying that I believe it must be feature complete and
dependable, both of which have not been meet yet. I believe they will
be at some point but not during my time of being really active.
In trying to reach that ultimate goal I have some short and long terms
plans, most of which have been a success:
US Foundation - (Failure) Goal help raise awareness of the project and
provide assistance and legal representation to developers on the
project. We have a good relationship with the Software Freedom Law
Center and they have been kind enough to offer us advice however in
terms of real legal help given the current state of the project thats
not going to happen any time soon.
Wine Cooperation - (Success) We share quite a lot of code with the
Wine project and although it is hard as hell to get code in to Wine it
has generally been a positive experience. The Wine tree contains
hundreds if not thousands of minor fixes and features contributed by
developers who have worked on both projects. Certain applications such
as Taskmgr and Regedit were re-licensed by us and have been merged in
to the Wine tree.
Samba Cooperation - (Success) We have not fully ported samba however
we have established a very positive relationship with the Samba and
Samba-Tng developers and they seem very open to the idea of porting
Samba to Windows so that in the future when ReactOS is ready it will
provide a drop in solution. Elrond from Samba-tng has provided quite a
bit of help and ported most of Samba-Tng to Windows already.
Raising Awareness about ReactOS - (Success) When I joined no one had
heard of us. Now almost any technical gathering I go to, 50 to 90% of
the people attending are aware of our work. The GNU, Linux and BSD
developers have for the most part changed their attitude regarding our
project, its goals and future.
Other uses of ReactOS - (Success) This has been the most surprising to
me to watch. While we have not reached the ultimate goal we have seen
fruits of our labor. The NDISWrapper teams come to us for questions
which allows many Linux and BSD users to run Windows network card
drivers. The CaptiveNTFS project created a more effective method of
getting data from NTFS on to Linux. Many of the tools we have
developed and ported are now being used in all sorts of places such as
the FreeDOS port of command.com we reimplemented as cmd.exe has been
ported to WinCE/PowerPC. Besides helping the NDISWrapper and Wine
teams from time to time we are more and more becoming a source of
information for educational purposes.
So with all of that being said I am not planning on totally leaving
however I mainly plan to help write regression tests for Wine in my
spare time and hope that it helps ReactOS. I'm happy to help talk to
people on behalf of the project and to help promote it in anyway I
can. I think the next major thing I am going to try to do is visit
Russia during a conference to meet with Fireball again and I am
willing to continue to help mediate issues with Wine that may pop up.
I still plan on hanging on IRC and the mailing list however I don't
know how closely I will follow the list so if you need something email
me directly.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
> [10:24] <+CIA-9> mbosma * r21332 reactos/dll/directx/ddraw/ (7
files): Unlock ddraw dll. Maguns and I were the only authors and neither
of us used
> unclean methods to implement it.
You're kidding right? I might as well unlock /ntoskrnl then.
Best regards,
Alex Ionescu
May I add some midl generated files into svn? (like we do with flex and
bison) Lack of features in widl is a great stopper to ReactOS
development. Actually, I can't do anything with event logging api
because of widl. I want to inplment some rpcss functionality, but widl
stops me from doing this.
Hi,
Is anyone in the US interested in using the Alpha workstation for a
possible port? Its kind of gathering dust here and if no one wants it
I would rather we just sell it and stick the money in to the project
pot.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I've been planning to take over on the wine sync's, but have been waiting
until I've finished setting up the audit process before looking into it.
This is now in place as of a few days ago.
I need to speak to Gé about a few things.
-----Original Message-----
From: Saveliy Tretiakov [mailto:saveliyt@mail.ru]
Sent: 10 March 2006 07:33
To: ReactOS Development List
Subject: [ros-dev] Wine sync
We need a sync with wine :) Who can do it?
Well, maybe I could do it myserlf, but I have very limited internet
access...
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
************************************************************************
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
The following devs currently have a blog account set up.
If any other devs want one setting up, please message me.
Aleksey Bragin
Alex Ionescu
Andrew Munger
Art Yerkes
Casper Hornstrup
Christoph von Wittich
Gé van Geldorp
Ged Murphy
Hervé Poussineau
kjkhyperion
Klemens Friedl
Maarten Bosma
Magnus Olsen
Mike Nordell
Filip Navara
Royce Mitchell III
Steven Edwards
Thomas Weidenmueller
Hi there
Just writing to enquire about the current state of Perl support in ROS
(which I can't find any docs/information on) and to let you know that I
and a few others are about to release a new non-ActiveState Win32
distribution of Perl, that is compiled with MinGW and is able to compile
and install CPAN modules directly, rather than needing ActiveState's PPM
library.
At the moment I'm just weeding out the last Win32 bugs in the component
parts of Bundle::CPAN, and awaiting a upgraded file installer that
supports deleting or overwriting a file that is in use.
With those in we'll release an initial beta, and after that the CPAN
client should handle upgrading of any problems on the way to a
production release.
Would there be any interest in trying it out?
Adam K
Eric Kohl wrote:
> Hi!
Hi Eric
> I just started a three-week vacation and I'm upgrading my
> computer right
> now. My plan is to start porting WIDL this week.
If you get chance to look at StartService too, I'll owe you beer or 3 ;)
> PS: I think the WIDL source can be unlocked because it is
> based on WINE
> and the additional code was written by me, using IDL test
> files and MIDL
> from MSVC6.
I agree. I think we need to draft up a process for unlocking code in the
repository.
The first port of call needs to be confirmation from the author. If the
author confirms clean methods were utilised to write the code, it
automatically fast tracks the audit.
I know Arty has a good process for code which doesn't fall into this
category.
I'll try and get some sort of flowchart onto the wiki tonight.
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
Saveliy Tretiakov wrote:
> > PS: I think the WIDL source can be unlocked because it is based on
> > WINE and the additional code was written by me, using IDL
> test files
> > and MIDL from MSVC6.
>
> It is already unlocked. All code shared with wine is clean by default.
That doesn't necessarily mean it's unlocked.
With the exception of 1 or 2 folders, I locked everything in the repository
regardless of what it was.
Wine stuff will need to be unlocked as and when required.
I think it's best to wait until we have a formal unlocking flowchart before
we unlock any more code.
There have already been 1 or 2 mistakes which we will now have to
back-track.
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
Reminds me... didn't OS/2 have the capability to store both short and
long file names on a FAT16 partiton? How does that go with MS'
patents? Where MS really allowed to file a patent on something that
already existed?
/nitro2k01
On 3/10/06, Rick Langschultz <rlangschultz(a)cox.net> wrote:
> I just have a question about High Performance and Global file systems
> implementation in a ReactOS version? It would be wonderful to cluster
> file systems on ReactOS. Also support for EFS would be great. Any
> plans yet?
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
--
-----BEGIN 2ROT13 MESSAGE-----
The blog of nitro2k01: <http://soundandcomplete.blogspot.com/>
Saliga äro de som kan stava till 2k01! Sniphpha sniphph!
-----END 2ROT13 MESSAGE-----
I just have a question about High Performance and Global file systems
implementation in a ReactOS version? It would be wonderful to cluster
file systems on ReactOS. Also support for EFS would be great. Any
plans yet?
Saveliy Tretiakov wrote:
>
> James Tabor wrote:
>
> > I guess wine isn't taking any patch from ReactOS, even
> something based
> > on a rc file.
>
> Is this really true? Very sad :(
>
No, it isn't true.
There will probably be a reason why the patch wasn't accepted.
Wine have strict guidelines with regards to accepting patches. If a patch
doesn't comply, it is dropped without a reply.
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
art yerkes wrote:
> You need to own the lock first before removing the needs-lock
> property.
> do this like 'svn lock --force foo.c'
If you break the lock first, there is then no problem removing the
svn:needs-lock property as the file is unlocked.
************************************************************************
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
I have now started locking unaudited files in the repository.
A special user called 'audit' has been created to do this lock. There
are two reasons for this:
1. The user who locks the file can still commit without unlocking.
Having a separate user to lock files removes this issue.
2. All developers can have the username and password for locking,
providing a system wide user to lock files. (ask Fireball for the u/n & p/w)
How do you lock files?
I'll list the method for tortoise-svn via the GUI. Die hard cmd line
gurus can adapt it to suit :)
- Firstly, go into your tortoise-svn settings and on the general page,
click 'clean now' for Subversion authentication data. This will remove
your current u/n & p/w
- To 'get a lock' on the file(s), right click the file / directory ,
navigate to tortoise-svn and select 'get lock'. Getting a lock will
trigger svn to contact the server automatically and apply the lock.
- Next pick the file / directory you just locked and right click. Select
file properties and under the subversion tab add 'svn:needs-lock' from
the combo box. Add a '*' for the value, check the recursive box and
click set. This will ensure all locked files which are checked out are
set as read only locally. This is just used as a handy reminder.
- You can now commit the files which will add the svn:needs-lock
property, however ensure that on the commit dialog, the 'keep locks'
checkbox is selected otherwise it will remove the lock you just placed.
Once I've audited the code, how do I unlock the files?
This is done as your regular username, not as the 'audit' user, so you
can clean the 'audit' username / password in the same manner as before
if you opted to save it.
Again, I'll list the tortoise method.
- Right click on the file / directory you want to unlock, navigate to
tortoiseSVN and select 'check for modifications'
- Select the file(s) you want to unlock, right click and select 'break
the lock'. SVN will automatically contact the repo and unlock the files.
- Don't forget to remove the svn:needs-lock property from the files to
ensure they are no longer checked out as read only.
I have so far locked the kernel, however I'm unsure if :
1. we're just gonna lock everything in one go (this would make life easy
to start with) and unlock everything as we deem it to be OK
2. lock only dirs we thing need auditing and unlock once clean.
I personally prefer option 1 as it ensures we don't miss anything, and
would probably be quicker in the long run.
Regards,
Ged.
I downloaded the latest ReactOS SVN today, and I attempted to compile it
with the RosBE. What happened was that the mingw32-make program shows this
message: "makefile.auto:47549: *** missing separator. Stop."... Well, I
figured that I got an incomplete build, so I reran TortoiseSVN and it said
that I had the complete distribution... This should be fixed so that ReactOS
will build, and if anyone is thinking... It occurs in all different building
syntax... all, livecd, bootcd, install, depends, etc. fail with the same
message...
Only WineMine is taken from Wine.
Our Solitaire is a project Steven found and gained the authors permission to
include it.
TaskManager was written by Brian IIRC, for ReactOS.
The notepad icon was taken from notepad2 which is GPL.
It is assumed that anything from other GPL projects is legal and
interchanagble.
If there is a copyright issue, I can change it.
-----Original Message-----
From: theUser BL [mailto:theuserbl@hotmail.com]
Sent: 02 March 2006 12:24
To: ros-dev(a)reactos.org
Subject: [ros-dev] Audit for non-code things?
I have tried out the SVN-Snapshot of ROS 3.0 by EmuandCo:
http://www.reactos.org/forum/viewtopic.php?t=1741#14146
At first, I want to say, that the ReactOS-Explorer looks a lot of nicer. And
some bugs are fixed. Nice work.
Then I have looked at the program-icons.
sol.exe and winefile.exe seems to use icons from old Windows-Versions
(Windows 3.x/95/98/NT4).
And with taskmgr.exe I am not sure, if the icon is from Windows or at own
designed.
All three programs comming from WINE and not from ReactOS. But is legal to
using it?
More woders me the new ReactOS Notepad.
If you click on Help -> About, then there opens a window where stands:
Icon borrowed from Notepad2 - http://www.flos-freeware.ch/notepad2.html
But Notepad2 have borrowed it from Microsofts WindowsXP Notepad.
It is funny to see, how the original creater of the icon, isn't named - but
instead
of it, an other one is named.
But the program notepad++ (http://notepad-plus.sourceforge.net/) is
OpenSource (GPL) and thats icon you could be used.
After that, I looked with Microsofts fontview.exe (the program is part of
every MS-Windows) in the text inside the fonts of ROS.
There are copyrighted fonts by Adobe, Bitstream, IBM, Sun and Transgaming.
And there are some Bitstream fonts in which stands:
Copyright 1990 as an unpublished work by Bitstream Inc. All rights reserved.
Confidential.
Confidential? Unpublished? From where comes then the fonts?
The fonts in which this stand are
c0419bt_.ttf, c0582bt_.ttf, c0583bt_.ttf, c0611bt_.ttf, c0632bt_.ttf,
c0633bt_.ttf,
c0648bt_.ttf and c0649bt_.ttf.
Ok, the Copyright is from 1990 (for 16 years!), but is it legal to use this
fonts?
Instead you could use the following fonts:
http://dejavu.sourceforge.net/http://linuxlibertine.sourceforge.net/http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=Gentium_lin
ux&_sc=1
Greatings
theuserbl
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
************************************************************************
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
Hi everybody!!!!!,
i'm trying to compile ReactOS SVN 0.3 but i'm having problems. I'm
currently using the ReactOS Build Enviroment 0.1-3.4.2 but it is
unable to compile rbuild. In fact the compilation process stops at
linking rbuild.exe.
I have created a directory in my D drive (rossrc) and i have
downloaded from the SVN the sources in d:\rossrc\trunk. So i changed
the directory to d:\rossrc\trunk\reactos and executed mingw32-make.
Then it began compiling the sources and after a while it stops with a
lot of garbage:
[LD] output-i386\tools\rbuild\rbuild.exe
plus lots of errors about undefined resources that i put at the end
of this email.
I currently reinstalled the Build Enviroment hoping that something
was installed wrong o was wrongly configured. But the same results
appeared. I also tried to compile it under the administration
account, because i currently run as user, but there are no changes
whatsoever (just trying to check that it isn't my fault or my
incompetence :P).
I blame the linker for this problem, but i don't know what is wrong
with it, because its a known fact that some versions of binutils dont
work but clearly RosBE has been tested a lot.
thanks in advance,
Logan_V8
PS: Garbage output from the linker
obj-i386\tools\rbuild\backend\msvc\msvcmaker.o: In function
`ZSt11__copy_aux2IPS
sS0_ET0_T_S2_S1_12__false_type':
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_alg
obase.h:(.text$_ZNSt23_Rb_tree_const_iteratorISsEppEi[std::_Rb_tree_const_iterat
or<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > >::ope
rator++(int)]+0x1b): undefined reference to
`std::_Rb_tree_increment(std::_Rb_tr
ee_node_base const*)'
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_alg
obase.h:(.text$_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE9_M_insertEP
St18_Rb_tree_node_baseS7_RKSs[std::_Rb_tree<std::basic_string<char,
std::char_tr
aits<char>, std::allocator<char> >, std::basic_string<char,
std::char_traits<cha
r>, std::allocator<char> >, std::_Identity<std::basic_string<char,
std::char_tra
its<char>, std::allocator<char> > >,
std::less<std::basic_string<char, std::char
_traits<char>, std::allocator<char> > >,
std::allocator<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > >
>::_M_insert(std::_Rb_tree_node
_base*, std::_Rb_tree_node_base*, std::basic_string<char,
std::char_traits<char>
, std::allocator<char> > const&)]+0x99): undefined reference to
`std::_Rb_tree_i
nsert_and_rebalance(bool, std::_Rb_tree_node_base*,
std::_Rb_tree_node_base*, st
d::_Rb_tree_node_base&)'
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_alg
obase.h:(.text$_ZNSt17_Rb_tree_iteratorISsEmmEv[std::_Rb_tree_iterator<std::basi
c_string<char, std::char_traits<char>, std::allocator<char> >
>::operator--()]+0
x13): undefined reference to
`std::_Rb_tree_decrement(std::_Rb_tree_node_base*)'
obj-i386\tools\rbuild\backend\msvc\vcprojmaker.o: In function
`ZNSt24__copy_back
ward_dispatchIPPK10IfableDataS3_11__true_typeE4copyEPKS2_S7_S3_':
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_alg
obase.h:(.text$_ZNSt17_Rb_tree_iteratorISsEppEi[std::_Rb_tree_iterator<std::basi
c_string<char, std::char_traits<char>, std::allocator<char> >
>::operator++(int)
]+0x1b): undefined reference to
`std::_Rb_tree_increment(std::_Rb_tree_node_base
*)'
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_alg
obase.h:(.text$_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE5eraseESt17_
Rb_tree_iteratorISsE[std::_Rb_tree<std::basic_string<char,
std::char_traits<char
> , std::allocator<char> >, std::basic_string<char,
> std::char_traits<char>, std::
allocator<char> >, std::_Identity<std::basic_string<char,
std::char_traits<char>
, std::allocator<char> > >, std::less<std::basic_string<char,
std::char_traits<c
har>, std::allocator<char> > >,
std::allocator<std::basic_string<char, std::char
_traits<char>, std::allocator<char> > >
>::erase(std::_Rb_tree_iterator<std::bas
ic_string<char, std::char_traits<char>, std::allocator<char> >
>)]+0x17): undefi
ned reference to
`std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, st
d::_Rb_tree_node_base&)'
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_alg
obase.h:(.text$_ZNSt17_Rb_tree_iteratorISsEppEv[std::_Rb_tree_iterator<std::basi
c_string<char, std::char_traits<char>, std::allocator<char> >
>::operator++()]+0
x13): undefined reference to
`std::_Rb_tree_increment(std::_Rb_tree_node_base*)'
obj-i386\tools\rbuild\backend\backend.o: In function
`ZNSt8_Rb_treeISsSt4pairIKS
sPN7Backend7FactoryEESt10_Select1stIS5_ESt4lessISsESaIS5_EE8_S_valueEPKSt13_Rb_t
ree_nodeIS5_E':
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ext/new_allo
cator.h:(.text$_ZNSt8_Rb_treeISsSt4pairIKSsPN7Backend7FactoryEESt10_Select1stIS5
_ESt4lessISsESaIS5_EE9_M_insertEPSt18_Rb_tree_node_baseSD_RKS5_[std::_Rb_tree<st
d::basic_string<char, std::char_traits<char>, std::allocator<char> >,
std::pair<
std::basic_string<char, std::char_traits<char>, std::allocator<char>
> const, Ba
ckend::Factory*>, std::_Select1st<std::pair<std::basic_string<char,
std::char_tr
aits<char>, std::allocator<char> > const, Backend::Factory*> >,
std::less<std::b
asic_string<char, std::char_traits<char>, std::allocator<char> > >,
std::allocat
or<std::pair<std::basic_string<char, std::char_traits<char>,
std::allocator<char
> > const, Backend::Factory*> >
> >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_
tree_node_base*, std::pair<std::basic_string<char,
std::char_traits<char>, std::
allocator<char> > const, Backend::Factory*> const&)]+0x99): undefined
reference
to `std::_Rb_tree_insert_and_rebalance(bool,
std::_Rb_tree_node_base*, std::_Rb_
tree_node_base*, std::_Rb_tree_node_base&)'
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ext/new_allo
cator.h:(.text$_ZNSt17_Rb_tree_iteratorISt4pairIKSsPN7Backend7FactoryEEEmmEv[std
::_Rb_tree_iterator<std::pair<std::basic_string<char,
std::char_traits<char>, st
d::allocator<char> > const, Backend::Factory*>
>::operator--()]+0x13): undefined
reference to `std::_Rb_tree_decrement(std::_Rb_tree_node_base*)'
obj-i386\tools\rbuild\automaticdependency.o: In function
`ZNSt8_Rb_treeISsSt4pai
rIKSsP10SourceFileESt10_Select1stIS4_ESt4lessISsESaIS4_EE14_M_create_nodeERKS4_'
:
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_tre
e.h:(.text$_ZNSt17_Rb_tree_iteratorISt4pairIKSsP10SourceFileEEppEi[std::_Rb_tree
_iterator<std::pair<std::basic_string<char, std::char_traits<char>,
std::allocat
or<char> > const, SourceFile*> >::operator++(int)]+0x1b): undefined
reference to
`std::_Rb_tree_increment(std::_Rb_tree_node_base*)'
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_tre
e.h:(.text$_ZNSt8_Rb_treeISsSt4pairIKSsP10SourceFileESt10_Select1stIS4_ESt4lessI
SsESaIS4_EE9_M_insertEPSt18_Rb_tree_node_baseSC_RKS4_[std::_Rb_tree<std::basic_s
tring<char, std::char_traits<char>, std::allocator<char> >,
std::pair<std::basic
_string<char, std::char_traits<char>, std::allocator<char> > const,
SourceFile*>
, std::_Select1st<std::pair<std::basic_string<char,
std::char_traits<char>, std:
:allocator<char> > const, SourceFile*> >,
std::less<std::basic_string<char, std:
:char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::basi
c_string<char, std::char_traits<char>, std::allocator<char> > const,
SourceFile*
> > >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*,
> std::pair<s
td::basic_string<char, std::char_traits<char>, std::allocator<char> >
const, Sou
rceFile*> const&)]+0x99): undefined reference to
`std::_Rb_tree_insert_and_rebal
ance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*,
std::_Rb_tree_nod
e_base&)'
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_tre
e.h:(.text$_ZNSt17_Rb_tree_iteratorISt4pairIKSsP10SourceFileEEmmEv[std::_Rb_tree
_iterator<std::pair<std::basic_string<char, std::char_traits<char>,
std::allocat
or<char> > const, SourceFile*> >::operator--()]+0x13): undefined
reference to `s
td::_Rb_tree_decrement(std::_Rb_tree_node_base*)'
obj-i386\tools\rbuild\directory.o: In function
`ZNSt8_Rb_treeISsSt4pairIKSsP9Dir
ectoryESt10_Select1stIS4_ESt4lessISsESaIS4_EE14_M_create_nodeERKS4_':
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ext/new_allo
cator.h:(.text$_ZNSt17_Rb_tree_iteratorISt4pairIKSsP9DirectoryEEppEv[std::_Rb_tr
ee_iterator<std::pair<std::basic_string<char, std::char_traits<char>,
std::alloc
ator<char> > const, Directory*> >::operator++()]+0x13): undefined
reference to `
std::_Rb_tree_increment(std::_Rb_tree_node_base*)'
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ext/new_allo
cator.h:(.text$_ZNSt8_Rb_treeISsSt4pairIKSsP9DirectoryESt10_Select1stIS4_ESt4les
sISsESaIS4_EE9_M_insertEPSt18_Rb_tree_node_baseSC_RKS4_[std::_Rb_tree<std::basic
_string<char, std::char_traits<char>, std::allocator<char> >,
std::pair<std::bas
ic_string<char, std::char_traits<char>, std::allocator<char> > const,
Directory*
> , std::_Select1st<std::pair<std::basic_string<char,
> std::char_traits<char>, std
::allocator<char> > const, Directory*> >,
std::less<std::basic_string<char, std:
:char_traits<char>, std::allocator<char> > >,
std::allocator<std::pair<std::basi
c_string<char, std::char_traits<char>, std::allocator<char> > const,
Directory*>
> >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*,
std::pair<st
d::basic_string<char, std::char_traits<char>, std::allocator<char> >
const, Dire
ctory*> const&)]+0x99): undefined reference to
`std::_Rb_tree_insert_and_rebalan
ce(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*,
std::_Rb_tree_node_
base&)'
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ext/new_allo
cator.h:(.text$_ZNSt17_Rb_tree_iteratorISt4pairIKSsP9DirectoryEEmmEv[std::_Rb_tr
ee_iterator<std::pair<std::basic_string<char, std::char_traits<char>,
std::alloc
ator<char> > const, Directory*> >::operator--()]+0x13): undefined
reference to `
std::_Rb_tree_decrement(std::_Rb_tree_node_base*)'
obj-i386\tools\rbuild\rbuild.o: In function
`ZNSt3mapISsPN7Backend7FactoryESt4le
ssISsESaISt4pairIKSsS2_EEE3endEv':
D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_map
.h:(.text$_ZNSt17_Rb_tree_iteratorISt4pairIKSsPN7Backend7FactoryEEEppEi[std::_Rb
_tree_iterator<std::pair<std::basic_string<char,
std::char_traits<char>, std::al
locator<char> > const, Backend::Factory*> >::operator++(int)]+0x1b):
undefined r
eference to `std::_Rb_tree_increment(std::_Rb_tree_node_base*)'
obj-i386\tools\ssprintf.o:ssprintf.cpp:(.text$_ZNSbIwSt11char_traitsIwESaIwEE4_R
ep10_M_disposeERKS1_[std::basic_string<wchar_t,
std::char_traits<wchar_t>, std::
allocator<wchar_t> >::_Rep::_M_dispose(std::allocator<wchar_t>
const&)]+0x22): u
ndefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'
collect2: ld returned 1 exit status
mingw32-make: *** [output-i386\tools\rbuild\rbuild.exe] Error 1
--
_______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
I have tried out the SVN-Snapshot of ROS 3.0 by EmuandCo:
http://www.reactos.org/forum/viewtopic.php?t=1741#14146
At first, I want to say, that the ReactOS-Explorer looks a lot of nicer. And
some bugs are fixed. Nice work.
Then I have looked at the program-icons.
sol.exe and winefile.exe seems to use icons from old Windows-Versions
(Windows 3.x/95/98/NT4).
And with taskmgr.exe I am not sure, if the icon is from Windows or at own
designed.
All three programs comming from WINE and not from ReactOS. But is legal to
using it?
More woders me the new ReactOS Notepad.
If you click on Help -> About, then there opens a window where stands:
Icon borrowed from Notepad2 - http://www.flos-freeware.ch/notepad2.html
But Notepad2 have borrowed it from Microsofts WindowsXP Notepad.
It is funny to see, how the original creater of the icon, isn't named - but
instead
of it, an other one is named.
But the program notepad++ (http://notepad-plus.sourceforge.net/) is
OpenSource (GPL) and thats icon you could be used.
After that, I looked with Microsofts fontview.exe (the program is part of
every MS-Windows) in the text inside the fonts of ROS.
There are copyrighted fonts by Adobe, Bitstream, IBM, Sun and Transgaming.
And there are some Bitstream fonts in which stands:
Copyright 1990 as an unpublished work by Bitstream Inc. All rights reserved.
Confidential.
Confidential? Unpublished? From where comes then the fonts?
The fonts in which this stand are
c0419bt_.ttf, c0582bt_.ttf, c0583bt_.ttf, c0611bt_.ttf, c0632bt_.ttf,
c0633bt_.ttf,
c0648bt_.ttf and c0649bt_.ttf.
Ok, the Copyright is from 1990 (for 16 years!), but is it legal to use this
fonts?
Instead you could use the following fonts:
http://dejavu.sourceforge.net/http://linuxlibertine.sourceforge.net/http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=Gentium_li…
Greatings
theuserbl
> From: art yerkes
>
> No we imported X fonts where permitted and used TGMarlett for
> window titles (also permitted, see media/fonts/doc)
Executive summary: There's no problem with the fonts.
Details:
Jason imported helb___.ttf and timr____.ttf in r1877 from OpenOffice (LGPL,
so GPL compatible).
I imported the Bitstream Vera fonts (Vera.ttf, VeraBI.ttf, VeraBd.ttf,
VeraIt.ttf, VeraMoBI.ttf, VeraMoBd.ttf, VeraMoIt.ttf, VeraMono.ttf,
VeraSe.ttf, VeraSeBd.ttf) in r4689. They are covered by the license in
media/fonts/doc/VERA-COPYRIGHT.TXT.
Steven imported TGMarlett.ttf in r9427. The "TG" refers to Trans Gaming. The
font is under a X11 license (see
http://www.transgaming.com/gamefaq.php?specialid=3 under 6.2) which is GPL
compatible.
Art imported some of the X fonts (UTBI____.ttf, UTB_____.ttf, UTI_____.ttf,
UTRG____.ttf, c0419bt_.ttf, c0582bt_.ttf, c0583bt_.ttf, c0611bt_.ttf,
c0632bt_.ttf, c0633bt_.ttf, c0648bt_.ttf, c0649bt_.ttf, cour.ttf, courb.ttf,
courbi.ttf ) in r10143. These are covered by the licenses in
media/fonts/doc/COPYRIGHT.IBM and media/fonts/doc/Copyright.Bitstream.
GvG
ReactOS.Bugzilla(a)reactos.org wrote:
>http://www.reactos.org/bugzilla/show_bug.cgi?id=1327
>
> Summary: Scrambled output from Calculator
> Product: ReactOS Apps (rosapps)
> Version: unspecified
> Platform: x86 Hardware
> OS/Version: ReactOS
> Status: NEW
> Severity: normal
> Priority: P3
> Component: Utilities
> AssignedTo: ros-bugs(a)reactos.org
> ReportedBy: the_real_martian(a)msn.com
> QAContact: ros-bugs(a)reactos.org
>
>
>When using Calculator, it will have outputs such as 308-d or 0770777-ff. This
>happens when it is set to "Dec", not Hex
>
>
>
Does this happen on both ROS and Windows or just ROS? Can you reproduce
it everytime with certain steps? And this isnt really considered ROS
Apps I dont think since Calc.exe is in /reactos.
Brandon
ReactOS.Bugzilla(a)reactos.org wrote:
>http://www.reactos.org/bugzilla/show_bug.cgi?id=1328
>
> Summary: Alt+Tab has no effect
> Product: ReactOS
> Version: 0.2.9
> Platform: x86 Hardware
> OS/Version: ReactOS
> Status: NEW
> Severity: normal
> Priority: P3
> Component: Kernel
> AssignedTo: ros-bugs(a)reactos.org
> ReportedBy: the_real_martian(a)msn.com
> QAContact: ros-bugs(a)reactos.org
>
>
>In Windows, Alt-Tab usually allows switching between open Windows. Alt-Tab has
>no effect in ReactOS
>
>
>
There is a hotkey meta bug please make this a dependency
.
Brandon
ReactOS.Bugzilla(a)reactos.org wrote:
>http://www.reactos.org/bugzilla/show_bug.cgi?id=1326
>
> Summary: Ctrl+Alt+Del has no effect
> Product: ReactOS
> Version: 0.2.9
> Platform: x86 Hardware
> OS/Version: ReactOS
> Status: NEW
> Severity: normal
> Priority: P3
> Component: Kernel
> AssignedTo: ros-bugs(a)reactos.org
> ReportedBy: the_real_martian(a)msn.com
> QAContact: ros-bugs(a)reactos.org
>
>
>When Ctrl+Alt+Del is pressed, there is no effect. This can really get annoying
>if a program is not responding, and you have to right-click the taskbar to open
>Task Manager.
>
>
>
There is a hotkey meta bug please make this a dependency
.
Brandon
I was wondering if there was any plan on implementing Intel's EFI in
the near or distant future. I hear that Intel wants to move away from
BIOS and work more closely with EFI. I know that support for the BIOS
will never totally disappear but EFI is a better architecture in my
opinion.
So here is my request for EFI support in ReactOS.
I had this same problem when developing my bootsector. When I reset the
bootdrive before I jumped to freeldr the problem went away. I think that
the first thing that freeldr needs to is to reset the boot drive before
it moves on.
ReactOS.Bugzilla(a)reactos.org wrote:
> http://www.reactos.org/bugzilla/show_bug.cgi?id=390
>
>
>
>
>
> ------- Additional Comments From simona(a)informatik.tu-muenchen.de 2006-02-25 00:17 CET -------
> got the same problem with the boot cd 2.9 on a travelmate 290.
> shoud be the same hardware and the same crappy "insyde software" bios (v2.0 on
> my chip):
> Press any key to boot from CD <enter>
>
> Failed to read the PVD.
> Press any key
> Failed to read the super block.
> Press any key <enter>
> Failed to read boot sector.
> Press any key <enter>
> Failed to read boot sector.
> Press any key <enter>
> Unable to locate boot parition
>
> Press any key <enter>
> Error opening boot partition for file access. <enter>
>
> Press any key to boot from CD
>
> And so on...
> Notice that one time the any-key message appears without waitig for any key.
>
> And, after the first "round" it waits way shorter for any keypress to boot
> from CD (the time between two dots printed has decreased).
> I experienced this problem with the first LiveCD version i tried (2.0 i
> think).
>
>
Brandon Turner wrote
>
> " B - Sections of ReactOS which require auditing are
> 'locked', that being
> that the source is fully available to download and build, but no
> development work should be undertaken until the said code has
> passed the
> audit. The lock will be removed only when that section of
> code has been
> audited."
>
> I have asked 3-4 times but still havent got an answer as far
> as I can tell. Does the definition of "audit" in the pharse
> mean the code needs to be looked through and documented and
> bad code be marked. Or does it mean all that and the marked
> code needs to be rewritten for it to be considered "audited".
Here is my understanding (although I'm not saying it's correct)
First of all, we must take the authors word on whether something needs
auditing or not.
If a particular author says the code which he wrote is clean, then this
automatically bypasses the audit.
This clears up James' worry about his dll code which he has declared clean.
If an author can't be contacted, it is classes as unknown and must go
through the audit process.
Once we have a list of all code which has not been verified, a new SVN user
is generated and he is used to lock all the code (this is done with a
separate user to avoid certain features of SVN lock)
Any developer is able to remove a lock. Locking the code only really acts as
a reminder that the code has not passed an audit. This code shouldn't be
modified / improved until it has done so. The lock therefore ensures all the
code is audited and nothing is missed. It also acts as an incentive to get
the code audited.
Without the lock, I think it will be conveniently forgotten about.....
Once code has been locked how does it get out of locked status?
I think there are 3 possibilities:
- look through the code looking for anything even remotely strange. (I think
Alex's description which I have linked to the end of this mail makes some
good points). If all the code seems perfectly legitimate, it passes the
audit and the lock is removed.
- If code doesn't seem legitimate, search for documentation. If docs are
found to cater for all the questionable code, the docs are added and the
code passes audit.
- If the code doesn't seem legitimate and docs can't be found, then the code
is deemed dirty and further action must be taken (e.g. part of the code
rewritten, all the code rewritten, docs written, etc). This would have to be
discussed at greater length.
HTH
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
Vote topic : Ensure code auditing is carried out
Start date : 16/02/06
Period : 7 days discussion, 7 days voting
With the success of proposal B in the recent vote and the old repository
reopening for business, we need to discuss ways to ensure the code is
audited and doesn't take a backseat.
Following the correct voting procedure, there will be a 7 day discussion
period, followed by a 7 day voting period.
Until this decision is made, I propose for the repository to be fully
open, with developers being diligent with their actions.
This topic has been discussed somewhat between developers, although not
extensively.
Two viable proposals have so far been put forward and are as follows :
A - The repository is completely open to all development and ReactOS
developers must take it upon themselves to ensure all code is audited.
B - Sections of ReactOS which require auditing are 'locked', that being
that the source is fully available to download and build, but no
development work should be undertaken until the said code has passed the
audit. The lock will be removed only when that section of code has been
audited.
Discussion of these topics and any further proposals should be in reply
to this topic.
How do we feel about having the documentation directory from the casper
tree (the one where audit documentation is being written) moved to
svn://svn.reactos.ru/reactos/trunk/documentation?
--
Discordant is the murmur at such treading down of lovely things while
god's most lordly gift to man is decency of mind. Call that man only
blest who has in sweet tranquility brought his life to close.
If only I could act as such, my hope is good.
-- Aeschylus' Agamemnon (translated by H. W. Smyth)
At
http://www.reactos.org/pipermail/ros-dev/2006-February/007878.html
and on other places there is mentioned, that the way to audit is, to look at
the ReactOS-Source-Code, look if it looks understandable.
The problem is, that is possible, that people disasseble MS-Windows-code and
port then the Assembler-Code in stupid C code.
And - because (not clean room) reverse engineering isn't allowed - all
code, which looks stupd will be eliminated.
That was also discussed in a german forum. There someone have at
http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=9920469&forum_i…
discribed, how a normal C program can be compiled to assebler code and an
other people create stupied C code, where you can see, that it was reverse
engineered.
But in the same forum, someone have mentioned, that there existing
decompiler like Boomerang
http://boomerang.sourceforge.net/
which creates from binary code logical, easy to read C code. (Don't know
before, that something like this exists).
Have a look at
http://boomerang.sourceforge.net/cando.php
I want with this mail only to say, that it would be very hard to find the
reverse engineered code (if there existing one).
Greatings
theuserbl
martinf(a)svn.reactos.org wrote:
> fix build with _ROS_ define
>
>
> Updated files:
> trunk/reactos/base/shell/explorer/shell/mainframe.cpp
>
Hi,
Should you move your changes to the new svn?
Thanks,
James
Through an intriguing article on Slashdot I have read that ipods are
now being used for things other than audio. They are being used to
obtain data from a computer, and computer network obtaining business
documents and such in seconds.
One way to make ReactOS a safer operating environment is to use a
virtual encrypted file system that would restrict the copying of
files to any usb, or network device via an encryption algorithm. So I
propose a VEFS that would restrict this. The VEFS would disallow the
passage of documents to any removable device unless the user has
permission to archive them, which would be the "a" attribute. The
VEFS would make use of two AES encryption algorithms which would
encrypt the file's contents. One being a key another a lock, however
the user must provide a password to unlock and decrypt the files.
This would allow the user to unlock the files, only if they have the
password. This would also allow users to secure their personal and
corporate data.
Any ideas?
Has anyone looked at the Haiku Project lately. There hasn't been much
change in status but I do think the status page has a great graph
that reactos should implement.
http://haiku-os.org/learn.php?
mode=status&haikuusersession=80b7ab5450deadb0c18c136376ee33d0
This is a script you can use to switch your current repository to the
new one. It won't save much dl time at this point, but might help.
It's experimental, and it might claim that some directories 'already
exist'. If so, you have to delete the old version of the directory.
Of course, you'll be able to get your diffs out by doing svn diff on
those directories beforehand.
In any case, use with caution.
run like this
python change-repo.py <reactos-dir> svn://svn.reactos.com/trunk/reactos svn://svn.reactos.ru/reactos/trunk/reactos 97493ccd-5924-5043-b1f5-66cb403b36ce
--
Discordant is the murmur at such treading down of lovely things while
god's most lordly gift to man is decency of mind. Call that man only
blest who has in sweet tranquility brought his life to close.
If only I could act as such, my hope is good.
-- Aeschylus' Agamemnon (translated by H. W. Smyth)
--
Discordant is the murmur at such treading down of lovely things while
god's most lordly gift to man is decency of mind. Call that man only
blest who has in sweet tranquility brought his life to close.
If only I could act as such, my hope is good.
-- Aeschylus' Agamemnon (translated by H. W. Smyth)
Hello!
As for recent changes with SVN repository hosting, the active ReactOS
repository now is being placed on svn://svn.reactos.ru/reactos.
I thought it would be wise not to copy passwords from the old
repository, so
All developers with commit access, please send me your exact matching
svn commit name (though I can look it up easily of course ;-)) and a
password you would like to use in the repository.
Right now there is only directory/files moving operations are going,
without any features being added or deleted until the voting on files-
locks in SVN for non-audited parts will be resolved.
This doesn't touch modules which are clean apriori - like rbuild for
example.
Thank you,
Aleksey Bragin.
At 15:11 17/02/2006 -0000, you wrote:
I apologize for this second intrusion, but i have some difficulties
to really understand this:
>Define 'MS code'. If we're talking about leaked source code, then that is
>true.
But you said elsewhere that there was _no_ leaked source, so that
the only problem should be with your next words:
>If we're talking about small chunks of assembly from dissasembled MS
>binaries, then that is what the audit hopes to uncover and remove. Once the
>audit is complete, we can also say we know this to be true, at the moment we
>don't know.
... and this one sounds strange to me, because i saw several messages
talking in terms of *year* (?!), for the audit.
Well, i just downloaded the ReactOS Sources, and searched for all the
Files having an "__asm__" Statements inside, after having saved in a
dedicated Directory, the folders: bootdata / Drivers / hal / include /
lin / media / modules / ntoskrnl / regtests / services / subsys and
win32api.
I did not considered the other ones because, for example, i suppose
that there can be no "problem" with the [apps] Folder. ;)
The search of the Files with "_asm_" inside shows only around 80 Files
found. Opening several of these Files, shows that the occurencies of
"_asm_" seem to be from 1 to, say, 10. Most usually around 2 or 3. It
also shows that many of these Statements cannot be any problem. Example:
{
__asm__("int $3\n\t" : /* no outputs */ : /* no inputs */)
}
Some other ones, a little bit more significative look like, for
example:
__asm
{
mov edx, Port
mov edi, Buffer
mov ecx, Count
cld
rep ins byte ptr[edi], dx
}
... that do not seem to me big enough for demonstrating anything,
particulary not for a so trivial code... Not considering that most
of the ones i saw, were simple LOCK or INT instructions, and the like,
that do not even diserve a reading.
I did not search inside _all_ files, but i had to search inside many,
(say, 1/3), before i could point out an Asm Routine with more than 10
Instructions...
I stopped there, because i said to me that it was stupid to read that
way, and that i was possibly missing the Files of real interrest for
the Audit. But all i have seen does not explain to me, how it could
ever take one year for proof-reading so few, and so small, "__asm__"
statements.
What am i missing?
Betov.
< http://rosasm.org >
Hi!
I am now very confused.
It seems for me, that the current informations about ReactOS´s situation is
poor. And if there existing informations, they are IMHO contradictorily.
On 27.1.2006 Steven Edwards wrote "Reset, Reboot, Restart, legal issues and
the long road to 0.3"
http://www.reactos.org/xhtml/de/news_page_14.html
In this text there is no word about leaked Windows-code. So it seems, that
the main problem is revers engineering, which is not clean room rev. eng.
One day later a developer says in the forum
http://www.reactos.org/forum/viewtopic.php?p=13239&highlight=#13239
"The biggest problem isn't disassembled code. The fact is that 4 of the
developers have had a copy of the leaked Windows source."
So, the biggest problem is, that some ROS-developer have looked in leaked
code.
He have said that, and nobody have contradicted it.
But at
http://www.reactos.org/archives/public/ros-dev/2006-February/007832.html
a developer says to me
"The leaked source code was never an issue here, that was an escalation of
the mail which was posted on the public list. The rumours which materialized
from that were unfounded and untrue."
and the cvs tree will be completly re-opend.
In an other mail, I don't find it at the moment, anybody says, that there is
still no Microsoft-Code found in ROS. All is clean.
On the following
http://www.reactos.org/pipermail/ros-dev/2006-February/007717.html
a developer says
"I am told that the sources for FreeLdr are all okay, except for the
some of the bootsectors having been pretty much just disassembled from
MS's. Is this true?"
The answer comes from an other developer
http://www.reactos.org/pipermail/ros-dev/2006-February/007722.html
"crashfourit has posted a patch here:"
That means, that it is possible, that MS-bootsector-code have found the way
in ROS, if I understood it right.
And at
http://www.reactos.org/archives/public/ros-general/2006-February/002128.html
somebody cite something where a Codewaever chef says, that in ROS is stolen
code.
I have at the current no links, but I have the feeling, that there existing
a lot of more comments like these, which me all confused very much.
And then ReactOS gives for me more questions then answers.
What does the Audit-process mean?
You have - as somebody says - already seen, that no Windows-Code is in
ReactOS.
But you want with the audit look for code, which are integrated by (not
clean room) reverse engineering.
But how do you want to find it?
The clean room inverse enginering is like re-writing an existing book,
without reading the existing book itself. Only reading review, critiques and
summaries about the book are alowed to read.
But there existing some people who have reverse enginered, but not clean
room. This is like someone, who have completly read the book itself and
tries to write the book what he read then down in mind.
But how do you want to become out, who have read the original book and who
not?
Steve Edwars have written "and the long road to 0.3". Is it still true, that
it needs now longer, until 0.3 comes out? The tree will already be opend.
Does it mean, that 0.3 comes only after the end of the audit-progess out? If
this is true, comes then before the end of the audit other releases out
(0.2.10, 0.2.11, .... etc) ?
You see. I am very confused.
I don't expect that you answer to my mail here.
I only want, that your public clarification,
http://www.reactos.org/archives/public/ros-dev/2006-February/007832.html
Murphy have written "The whole tree will be reopened in the state it was in
before it closed.
More details will follow when this happens.", will really clarify all. So
that no longer confuseness for anyone exists.
Greatings
theuserbl
theUser BL wrote:
> I am now very confused.
I'll try and clear some other areas up for you.
I don't have web access at the moment, so I am only going off what you have
pasted under the links.
> On 27.1.2006 Steven Edwards wrote "Reset, Reboot, Restart,
> legal issues and
> the long road to 0.3"
> http://www.reactos.org/xhtml/de/news_page_14.html
>
> In this text there is no word about leaked Windows-code. So
> it seems, that
> the main problem is revers engineering, which is not clean
> room rev. eng.
Correct.
> One day later a developer says in the forum
> http://www.reactos.org/forum/viewtopic.php?p=13239&highlight=#13239
> "The biggest problem isn't disassembled code. The fact is
> that 4 of the
> developers have had a copy of the leaked Windows source."
>
> So, the biggest problem is, that some ROS-developer have
> looked in leaked
> code.
This isn't much of a problem, the problem is the integrity / validity of our
code.
i.e. how was the information to write the code obtained.
See above.
> But at
> http://www.reactos.org/archives/public/ros-dev/2006-February/0
> 07832.html
> a developer says to me
> "The leaked source code was never an issue here, that was an
> escalation of
> the mail which was posted on the public list. The rumours
> which materialized
> from that were unfounded and untrue."
Correct.
> In an other mail, I don't find it at the moment, anybody
> says, that there is
> still no Microsoft-Code found in ROS. All is clean.
Define 'MS code'. If we're talking about leaked source code, then that is
true.
If we're talking about small chunks of assembly from dissasembled MS
binaries, then that is what the audit hopes to uncover and remove. Once the
audit is complete, we can also say we know this to be true, at the moment we
don't know.
> On the following
> http://www.reactos.org/pipermail/ros-dev/2006-February/007717.html
> a developer says
> "I am told that the sources for FreeLdr are all okay, except for the
> some of the bootsectors having been pretty much just disassembled from
> MS's. Is this true?"
> The answer comes from an other developer
> http://www.reactos.org/pipermail/ros-dev/2006-February/007722.html
> "crashfourit has posted a patch here:"
>
> That means, that it is possible, that MS-bootsector-code have
> found the way
> in ROS, if I understood it right.
This code hasn't been audited yet. It's possible that parts of the
bootsector have been derrived from an MS dissasembly. The audit will reveal
the answer, and it will be rewritten if nessesary.
> And at
> http://www.reactos.org/archives/public/ros-general/2006-Februa
> ry/002128.html
> somebody cite something where a Codewaever chef says, that in
> ROS is stolen
> code.
Incorrect. There is no stolen code in ROS and more than there is stolen code
in Wine.
> And then ReactOS gives for me more questions then answers.
>
> What does the Audit-process mean?
It means all suspect code will be proof-read and documentation must be made
available to prove it's validity.
If not, the will be either rewritten, docs written or removed dependant on
the circumstances.
> You have - as somebody says - already seen, that no
> Windows-Code is in
> ReactOS.
> But you want with the audit look for code, which are
> integrated by (not
> clean room) reverse engineering.
> But how do you want to find it?
Any code that is questionable. i.e. a reason cannot be found as to why it is
included.
I agree it's difficult to tell what is clean room and what it not.
As KJK said, if we don't question it's validity as all appears well, then it
would be up to a 3rd party to proove otherwise.
> Steve Edwars have written "and the long road to 0.3". Is it
> still true, that
> it needs now longer, until 0.3 comes out? The tree will
> already be opend.
> Does it mean, that 0.3 comes only after the end of the
> audit-progess out? If
> this is true, comes then before the end of the audit other
> releases out
> (0.2.10, 0.2.11, .... etc) ?
Decisions on new policies havn't been reached yet.
It's true that it is still a long road. The audit is still going to happen,
it's just that we're doing it in a slightly different way now.
It is hoped that this new method will ensure the project stays alive during
the audit.
> You see. I am very confused.
I hope that cleared some things up for you.
> http://www.reactos.org/archives/public/ros-dev/2006-February/007832.html
> Murphy have written "The whole tree will be reopened in the state it was
in
> before it closed.
> More details will follow when this happens.", will really clarify all. So
> that no longer confuseness for anyone exists.
The current vote will decide the outcome of that. There are currently 2
options.
Read the mail entitled 'Vote: Code Auditing' for more details.
Regards,
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
At 20:21 17/02/2006 +0100, you wrote:
>I think this only applies to the bootsector, wich has asm directly taken
>from disassemblies in it.
Ah. Then it should be the [Boot] sector. I see 5 files in there, with
asm statements. Only one could be a problem, that is named "longhorm.h".
52,000 Bytes long // 105 "_asm__". Outchhhh...
But did not another guy said that there was a possibility of complete
replacement? And, if i miss-undertood, or if not possible, would it
take one year for proof-reading 52,000 bytes of C Source?
>I think what Ged was talking about was disassemblies converted into C.
>And this can be found by looking for typical things of that kind of code:
>- Magical number inside C code. Normally constants are used or the
>numbers are commented or really obvios. But when you don't know why
>there's a constant 0x2342 then you don't really know how to call it. In
>disc.c there's a constant called PARTITION_MAGIC ;-)
>- excessive gotos: You would normally not use any gotos, but it can be
>hard to identify complex structures of for, if, while,... inside asm
>code, so you do it like it's done in asm: with gotos. It doesn't look
>good, but it works.
Ah! C simulating Assembly and hard coded unknown numbers...
OK, i see the problem better, with these points, as long as there is
really a _lot_ of Files with "goto"s inside, and i can imagine how
sorting all of these out, might be a boring task. But this was not,
at all, what was first said.
Thanks for the explanations. Betov.
Which is why I stated a couple weeks ago thaqt politics has NO place in
an engineering project.
At all.
Ever.
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org]
On Behalf Of mf
Sent: Friday, February 17, 2006 1:55 AM
To: ReactOS Development List
Subject: [ros-dev] Re: Vote: code auditing
Brandon Turner wrote:
> That was the orginal plan, and we just voted against it.
>
> Brandon
>
That's the idea with politics, you amend a proposal until the original
purpose of the proposal is completely reverted, and you end up with a
new set of useless silly rules with possible flaws, loopholes etc. If
you can't get people to accept something, just confuse them with even
more proposed rules, preferably vague but essentially the same as what
they originally voted against.
mf
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Murphy, Ged (Bolton) wrote:
> Incorrect. There is no stolen code in ROS and more than there
> is stolen code in Wine.
Sorry, that should read 'There is no stolen code in ROS _any_ more than
there is stolen code in Wine.
************************************************************************
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
theUser BL wrote:
> But at
> http://www.reactos.org/archives/public/ros-dev/2006-February/007832.html
> a developer says to me
> "The leaked source code was never an issue here, that was an escalation of
> the mail which was posted on the public list. The rumours which
materialized
> from that were unfounded and untrue."
> and the cvs tree will be completly re-opend.
IIRC, it was me who said that. What I mean by that is that none of the
leaked Windows source code has ever found it's way into ReactOS. Many people
thought that was the case, but they were wrong.
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
I must agree. Problems can sometimes bring out the best in people and
projects. The fact that there was a minor setback will likely make the
project stronger and btter then ever, even if only by reafirming to the
project by those who have committed the most.
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org]
On Behalf Of mf
Sent: Thursday, February 16, 2006 3:09 AM
To: ReactOS Development List
Subject: [ros-dev] Re: Goodbye Everyone...
Steven Edwards wrote:
> We seem to be a ship that is taking on water.
Gee, if that's the attitude our Project Coordinator, role model and
source of inspiration for the project, is taking, then I don't know what
I should think. Are you just acting this unoptimistic because you feel
like a captain who's almost got mutiny on his hands, or is it some other
reason? From everything I've seen, I'd say things are looking up lately.
But that's just my humble opinion.
mf.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Dann B. Smith wrote:
> Hmmm... Wrong. A strong leadership can prevent the
> politicization of a
> project if handled correctly.
>
> I would like to paraphrase certain scientists here and say that if you
> have to vote on a thing, it isn't science (or engineering).
> And if it's
> science (or engineeirng), it does not (ever) need a vote.
>
> Science and engineering are based on two things: truth and
> workability
> (respectively).
>
> If that maxim can't be followed, the rest of the discussion is moot,
> since the project has already died.
It has nothing to do with Science or engineering.
It's a simple case of people having different ideas and we have to work out
which path to follow.
In a volentary project like this, how else do you propose different views
are solved?
You can't forcefully make someone do something unless you are paying them,
thus a majority vote is the only fair way.
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
Hmmm... Wrong. A strong leadership can prevent the politicization of a
project if handled correctly.
I would like to paraphrase certain scientists here and say that if you
have to vote on a thing, it isn't science (or engineering). And if it's
science (or engineeirng), it does not (ever) need a vote.
Science and engineering are based on two things: truth and workability
(respectively).
If that maxim can't be followed, the rest of the discussion is moot,
since the project has already died.
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org]
On Behalf Of Murphy, Ged (Bolton)
Sent: Thursday, February 16, 2006 4:21 AM
To: 'ReactOS Development List'
Subject: RE: [ros-dev] Goodbye Everyone...
Rick Langschultz wrote
It is inevitable that as a project grows in size and popularity, it also
becomes much more political.
Ged Murphy wrote:
> B - Sections of ReactOS which require auditing are 'locked',
> that being that the source is fully available to download and
> build, but no development work should be undertaken until
> the said code has passed the audit. The lock will be
> removed only when that section of code has been audited.
I am in agreement with proposal B, freezing of un-audited sections. Here
are my reasons:
Firstly I'll elaborate on what a lock does:
Any developer can 'get-a-lock' on a file. Having this lock means only
that developer can commit to that file*. A locked file cannot be
modified, deleted or renamed in the repository by anyone else.
To set a lock on a file, you lock it as per your client syntax and set
the subversion property svn:needs-lock. When this property is set on a
file, a checked out or updated file is made read only locally. (except
for the person who holds the lock*). This acts as a warning that the
file should not be modified. Users of Tortoise will also have a
graphical overlay stating a file is locked.
Locks can be removed by any developer in a process called
breaking-the-lock. (ownership of the lock can also be taken known as
stealing-the-lock, although that's not important for us). The ability to
Break the lock ensures that no one developer has control over the lock.
Anyone can remove a lock at any time.
Users and developers alike will not notice a lock unless they try to
modify locked code, so it would in no way inhibit general usage.
*(a user named 'audit' can be set up to do the initial locking of the
files)
What the lock would do is act as a barrier for any further development
on non-audited code. Code which has not been audited must be deemed as
'tainted' until it has passed an audit.
I do however think that what we deem as tainted can be narrowed down.
All usermode applications along with all Wine libs and many other areas
(to be discussed) will bypass the lock immediately.
Code which has not yet passed the audit should not be improved,
committed to, developed (whatever the phrase). There are 2 good reasons
for this. Firstly, there is a possibility that this code needs to be
removed, so it is a complete waste of a developers time to improve this
code.
Secondly (and most importantly), by freezing this code, it puts more of
an incentive on developers to audit it. e.g. if someone is working on
some code which requires a particular section of un-audited code to be
modified, or exposes a bug in some un-audited code, the developer must
audit the said code in order to fix the problem. Only then will they be
able to take advantage of this with their ReactOS improvement/addition.
If this code wasn't frozen, the chances are, the developer will tweak
the un-audited code and carry on regardless. Thus un-audited code will
tend to take a back seat.
I agree with Gé, in that if some method is not put in place to ensure
our code is audited, people will conveniently forget about it.
Not only must we been seen to be pro-active with the audit for the
general public to see (e.g. osnews, slashdot), but we must also ensure
we do not alienate developers who feel _very_ strongly about the
un-audited code. By reopening the repository, with the addition of
locking un-audited code, I think we can strike a fair compromise for all
parties, and ensure the audit takes place.
Ged.
> The Ros CDs loader might be useful for you too.
This did remind me we can download ros sources without using SVN.
Therefore I have the freeldr installer now,
thanks for all.
If you didnt read the mailing list since some time,
SVN code is being audited and
contains almost nothing atm for *users*.
--- Sarocet <sarocet(a)gmail.com> a écrit :
> Sorry, as you talked about old svn i thought that was your problem.
> Don't know what happened with svn, i have been disconnected of the project
> over a month.
> The data you want is (should be) probably in trunk/reactos/boot/freeldr at
> folders freeldr and install.
> I also see strange no data in branches folder.....
>
> Anyway, i can send you the freeldr folder i have on my svn copy (over a
> month and a half old). I guess better wait until get the new svn before
> updating.
> The Ros CDs loader might be useful for you too.
>
Kind regards,
Sylvain Petreolle (aka Usurp)
--- --- --- --- --- --- --- --- --- --- --- --- ---
Tired of a proprietary Windows on your computer ?
Use free ReactOS instead ( http://www.reactos.org )
http://www.reactos.org/forum/viewtopic.php?t=1697
--
Discordant is the murmur at such treading down of lovely things while
god's most lordly gift to man is decency of mind. Call that man only
blest who has in sweet tranquility brought his life to close.
If only I could act as such, my hope is good.
-- Aeschylus' Agamemnon (translated by H. W. Smyth)
Well, it's been fun, however i believe it is time for me to leave.
ReactOS really has fallen to pieces and it's going to take a long time
(years) to get things back on track. What really annoys me about this
entire thing is that waaay back in the earlier days of ROS (before 0.1)
Things were fun. Nothing worked, but things were fun. Development on
ROS was actually HAPPENING (I know this because I myself was part of
it). Since then things started changing. New developers appeared, a
lot of flame wars were breaking out, etc. I stayed on the list, pitched
in my 2 cents, etc. Though i stopped coding for the most part. Now it
turns out that developers were using dirty room reverse engineering
tactics, or have had access to the source code. I almost left then, but
i figured i'd give it a little bit longer and see what happens. Now I
see a bunch of arguing on the mailing list, ROS development has stopped,
and I'm doubting it'll resume again for a long time, and things have
just pretty well fallen apart. Even IF the audit is completed, ROS will
likely be in pieces. It will NEVER be at the level it was before the audit.
Anyways, I believe it is time to start anew. New project, different
name, different goals.
Until Then,
Bye.
Richard Campbell
ReactOS Developer and Long Time Fan
The vote on choosing a plan for further ReactOS development is now
finished. The results are:
Plan A: 4
Plan B: 14
This means that all points from the Plan B are now in force.
Additional announcement will be made regarding the SVN repository.
For detailed read go to http://www.reactos.org/forum/viewtopic.php?
t=1675
WBR,
Aleksey Bragin.
At 15:01 16/02/2006 -0000, you wrote:
>Sorry, I'm not really sure what your question is.
>
>After being derailed recently, ReactOS is now being put back on the tracks.
>There is finally a clear path starting to emerge for development to restart.
>There will not be a fork, development work will continue on ReactOS.
>
>If any of those don't answer your question, can you try to reword it please.
:))
Don't be sorry: I am used with not being understood, and i am quite
sure that this is not because of my "particular english".
:))
Well, my question has been answered to, by the recent answers to
Hyperion post, and, mind you, if you do not understand what i write,
as a matter of fact, it seems that i understand rather well how the
things are going, because since day one of the "problem", when some
other lurkers fellows of mines were under alarm mode about it, i told
them that "the problem will not take years, but 3 months".
And if you could understand my previous question, you would
prefectly understand, also, how and why i was able to predict
the exact time that it would take, before yourselves, whereas
i do not even write C.
:))
Betov.
< http://rosasm.org >
Juan Rodriguez wrote:
> I totally agree with Hyperion, not to mention that even the
> last version
> was far away from beeing really usable/stable as an os should
> be at least.
> I know there is much work that has been done, but as i recall the
> project was to make an os able of beeing an alternative to windows
> itself, politics and such, are matters that should be
> discusssed after
> the project has taken form, and imho it is not. So lets code and stop
> bitching about politics.
Great, you should join the project and solve all our problems.
I wish we had realised sooner that the answer was so simple.
We could have saved all this mess if we had known the way to avoid issues is
to shut up and continue coding.
************************************************************************
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
... wrote:
> I have seen enough of such scaring horrors, like Anti-GPL, and/or
> Right-Wing guys, contributing to ReactOS, to understand the reasons
> why the true words were not said, but, at this point, i really would
> like to know where the things are going to, and if a dissident Project
> is to be started, the correct political and ethical way, or if the
> same Project is taking a correct path, i would like to see, at least,
> a "White Paper" for it. Having seen volunnteers saying that "using
> GPLed-compatible Dev-Tools was not a necessity" (Hyperion, if i recall
> well), or pure horrors like "In the future we may have collaborations
> with MicroSoft" (Alex, taking publicly the defense of a Neo-Nazi,
> against... me -???!!!...-), for example, are things that made me
> really sea-sick.
>
> Personaly, i am not interrested with knowing if unfair Code was
> implemented or not (knowing of the individual, this is not any
> surprise to me, by the way). What i wish to know is:
>
> Will the political and ethical lessons be understood? Or not?
>
> [By the way, the simple fact of having to ask such a question,
> about such an important GPLed Project, like what ReactOS is,
> is already a pure scandal to me: I shouldn't even have to ask]
Sorry, I'm not really sure what your question is.
After being derailed recently, ReactOS is now being put back on the tracks.
There is finally a clear path starting to emerge for development to restart.
There will not be a fork, development work will continue on ReactOS.
If any of those don't answer your question, can you try to reword it please.
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
theUser BL wrote
> That would be nice.
> If you restore the old cvs-tree, before the Windows-code
> leaked (ca. 7. Feb.
> 2003) and before the people who have readed the code joined
> ReactOS, then
> there existing legal ReactOS-code, which you can published.
No, you misunderstood.
The whole tree will be reopened in the state it was in before it closed.
More details will follow when this happens.
The leaked source code was never an issue here, that was an escalation of
the mail which was posted on the public list. The rumours which materialized
from that were unfounded and untrue.
************************************************************************
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
>The only consolation I can give you is that the old tree will be restored
>somewhere as per the vote. From there auditing should take place.
That would be nice.
If you restore the old cvs-tree, before the Windows-code leaked (ca. 7. Feb.
2003) and before the people who have readed the code joined ReactOS, then
there existing legal ReactOS-code, which you can published.
That is what is needed!
At the moment you have deleted all. There existing no longer any code. The
look at the future is to look behind, which code can be let in and which
not.
But if you publish old code, then there is a point from which on the
ReactOS-developer - like Richard - can again developing forward.
Greatings
theuserbl
At 10:20 16/02/2006 -0000, you wrote:
>It is inevitable that as a project grows in size and popularity, it also
>becomes much more political. [...]
>
>There is no getting away from the fact that politics would eventually
>emerge, it was going to happen some day.
I am a lurker, here. I started a GPLed project -completely outside
ReactOS, but conditioned to the existence of ReactoS- the first day
i heard of the ReactOS Project. In other words, i work _for_ reactOS
Environment, and not _for_ Windows, and along all of these years of
developments (I started in 1998), i always took a particular care of
locking my own work, so that it could not be extended and re-used,
in case the ReactOS Project would collapse.
I am used to not post anything, here, as long as i consider that,
as i do not contribute to anything in the ReactOS developments, i
just have the right to shut-up and thank for having the right for
reading. Nevertheless, with the actual events, it seems to me that,
we -the external lurkers- have natural rights to be informed about
the _real_ political and ethical concerns.
I have seen enough of such scaring horrors, like Anti-GPL, and/or
Right-Wing guys, contributing to ReactOS, to understand the reasons
why the true words were not said, but, at this point, i really would
like to know where the things are going to, and if a dissident Project
is to be started, the correct political and ethical way, or if the
same Project is taking a correct path, i would like to see, at least,
a "White Paper" for it. Having seen volunnteers saying that "using
GPLed-compatible Dev-Tools was not a necessity" (Hyperion, if i recall
well), or pure horrors like "In the future we may have collaborations
with MicroSoft" (Alex, taking publicly the defense of a Neo-Nazi,
against... me -???!!!...-), for example, are things that made me
really sea-sick.
Personaly, i am not interrested with knowing if unfair Code was
implemented or not (knowing of the individual, this is not any
surprise to me, by the way). What i wish to know is:
Will the political and ethical lessons be understood? Or not?
[By the way, the simple fact of having to ask such a question,
about such an important GPLed Project, like what ReactOS is,
is already a pure scandal to me: I shouldn't even have to ask]
Betov.
< http://rosasm.org >
Rick Langschultz wrote
> It seems that many people want to give up the project, which would be
> a total loss of time and energy of those who have spent many hours
> and money on the project.
I agree that it has looked like that on occasions, however I assure you that
is not the case :)
It is inevitable that as a project grows in size and popularity, it also
becomes much more political. There is no avoiding the fact that the ReactOS
of today is a very different environment from what it was. This change leads
to many of the original developers viewing the project of losing the aspect
of fun which it used to have. As a consequence, many are leaving the project
which, is a sad and unfortunate outcome.
There is no getting away from the fact that politics would eventually
emerge, it was going to happen some day. All big project have this barrier
to battle with, and that day has arrived ReactOS too. However with project
growth bringing the unfortunate addition of politics, it also brings the
welcome addition of excitement and maturity. End users now have something to
try out, we even have firefox and thinderbird running now :-D
This level of maturity should ensure the survival of ReactOS, even if there
are huge mountains to climb every so often.
Hope that raises a few spirits, keep your eye on ReactOS this weekend ;)
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
Steven Edwards wrote:
> We seem to be a ship that is taking on water.
We are hopefully about to hit a turning point and put things back on track.
The project has been completely lost and in the dark for the past few weeks,
but we are starting to find the light now.
I'm looking forward to this weekend ;)
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: Freeze every module in svn until it got audited
Proposed by: Maarten Bosma / Art Yerkes
Days of discussion: 7 (started 09.02.2006)
Days of voting: 7 (starting in 24 hours from now - 16.02.2006 20:00 GMT)
Proposal: Do not allow changes to a module until it got audited.
Options: [ ] Accept proposal [ ] Do not accept [ ] Further Discussion
Remarks: I took the first appearance of the idea as beginning of discussion.
Hi people,
Im using Freeldr to boot up my entire system since I tried ReactOS.
I installed it on a diskette in the past and it would be a great thing
if I could migrate it to the hard disk.
Since the old SVN isnt online anymore, I dont have access to the commandline installer.
Do you plan to put it back into the SVN later,
and if not, could you tell me where I can find it ?
Kind regards,
Sylvain Petreolle (aka Usurp)
--- --- --- --- --- --- --- --- --- --- --- --- ---
Tired of a proprietary Windows on your computer ?
Use free ReactOS instead ( http://www.reactos.org )
Perhaps this is now the time to move it to the Swedish servers as suggested
by JvA
-----Original Message-----
From: Ge van Geldorp [mailto:gvg@reactos.org]
Sent: 15 February 2006 11:27
To: 'ReactOS Development List'
Cc: 'Casper Hornstrup'
Subject: [ros-dev] FW: Repository hosting
> -----Original Message-----
> From: Casper Hornstrup [mailto:ch@eudicon.com]
> Sent: 13. februar 2006 18:06
> To: 'ReactOS Development List'
> Subject: Repository hosting
>
> Hi.
>
> I've decided not to host the ReactOS Subversion repository beyond
> March 31st 2006. That gives you up to ~6 weeks to find a new place to
> host it. I will send the repositories (both new and old) to the person
> who will host the repository in the future. Please contact me when you
> want this done.
************************************************************************
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
> -----Original Message-----
> From: Casper Hornstrup [mailto:ch@eudicon.com]
> Sent: 13. februar 2006 18:06
> To: 'ReactOS Development List'
> Subject: Repository hosting
>
> Hi.
>
> I've decided not to host the ReactOS Subversion repository beyond
> March 31st 2006. That gives you up to ~6 weeks to find a new place to
> host it. I will send the repositories (both new and old) to the person
> who will host the repository in the future. Please contact me when you
> want this done.
>
> P.S. Please CC me directly as I'm not subscribed to this list.
>
> Med venlig hilsen / best regards
> Casper Hornstrup
> Chief Executive Officer @ Eudicon
> ch(a)eudicon.com / www.eudicon.com
> (+45) 27 29 36 20
I am writing a file system for personal development use for reactos.
I want to take a poll about what File System features that ReactOS
would like to implement in its distribution. Are there any features
out there that ReactOS developers like to implement in ReactOS. I
want to model the file system on NTFS but i have been looking at
Sun's ZFS and think that it would be a great File System for React...
Another thing... How is the code audit going?
Hi!
I'm probably a non-person to most people here. This is my first foray
into the mailing list as a submitter.
If I may say a few things:
First: No one has a RIGHT to anything. Mailing lists, archives,
whatever. You only have whatever options the originators of IP or code
decide to give.
Second: For a fully open source project, private lists are Bad News.
While they do allow sensitive ideas to be discussed in a more informal
setting, they also give the options to have high-level decisions to be
made without any community support. I've seen it saidf in this list
that the "private" list developers talk abut things that don't affect
other developers. WRONG! Anything that the "primary" developers talk
about affects the entire development community. Otherwise, there's no
reason to duscuss it at all.
Third: While reverse engineering may be legal in Europe, it's only
legal in certain circumstances in the US. Open source projects tend to
be world-wide in scope. Thus, the most restrictive of laws MUST be
applied so that no legal boundaries are crossed. In this case, it looks
like the US has laws that do not exist elsewhere. Likewise, the US has
one of the largest "markets" for software, so the US can't be discounted
unless we wish to develop a Europe-only OS. Thus, no matter what, we
have to follow the restrictive US laws on reverse engineering. Despite
any personal feelings, laws must be upheld.
Fourth: Re: dirty laundry. This is almost a non-starter. Yes, some
things were said that caused a bit of an uproar. Yes, the project is
being held up in some respects. On the other hand, we have enough
people here who care enough to give voice to their opinions AND who care
enough to see the project succeed that the idea that "dirty laundry"
being aired in public being a bad thing is absurd. The results say
otherwise. Politics has NO place in an engineering project. None.
Ever. Don't let the idea of politics creep in and kill an otherwise
wonderful thing.
Fifth: Personal attacks here are without doubt, worthless. This is a
list for developers, coders, and engineers. To call someone's attitude
ridiculous goes right back into my previous statement about politics.
Sixth: I would like to thank you all for reading my post, whether you
agree or not. In the end, I speak for no one but myself, and you can
take what I say however you want.
Dann Smith
Dallas, TX, US
-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org]
On Behalf Of Rick Langschultz
Sent: Wednesday, February 08, 2006 6:27 PM
To: ReactOS Development List
Subject: Re: [ros-dev] What Happened
Don't get me wrong, reactos is a great programming idea. The way some
people do things is not necessarily what the community would want. As a
long term web developer I had an interest in VFS implementation of NTFS
over FAT or other filesystem. 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. Everyone has the right to develop what they think ReactOS needs.
Personally I think ReactOS needs stable Networking, a more stable and
secure filesystem, and service implementation. I also think that
building a universal install disk would be great -- install on PowerPC,
intel, arm, all on one cd would be great. I am not willing to give up on
programming projects so I will continue developing code, but when the
audit is complete I just hope 99% of the community is there to back
ReactOS up...
On Feb 8, 2006, at 4:05 PM, Ged Murphy wrote:
> Rick Langschultz wrote:
>> "The ReactOS(r) project is dedicated to making Free Software
>> available to everyone by providing a ground-up implementation of a
>> Microsoft Windows(r) XP compatible operating system." Why not say I
>> am sorry ReactOS is off limits to you, the community, because people
>> steal, cheat and lie. It is said that good programmers steal code,
>> and great programmers know whose code to steal...
>> Stealing M$ code is obviously not the wisest choice...
>>
>> I will continue to develop my own personal ReactOS code but I don't
>> think I will contribute it to ReactOS. My implementation of the NT
>> VFS over FAT will be rolled into a new project. And be able to be
>> downloaded by ROS developers and community members.
>>
>> Ridiculous...
>
> As is your attitude ...
>
> The ReactOS developers have spent thousands upon thousands of hours
> writing a free operating system for the world to use.
> It has become so large now, that the inner workings are becoming
> business like, and measures must be put into place to deal with this.
> If you can't accept that developers need a place where they can
> discuss topics, have arguments and sort out issues, out of the public
> eye then that's your problem. I'm positive Linux and BSD have
> somewhere where developers can discuss issues, as do most other large
> (and even small) projects Maybe we should take minutes of any
> telephone conversations we have and post those too?
>
> I for one am glad you won't be committing any code. You attitude
> sounds like it would generate more problems than it's worth.
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
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.
Realistically, 3 + + should give a syntax error as it's not a valid
mathematical equation.
Anything generated from this equation is undefined.
I know some calculators use hitting the + button as a trigger to calculate
anything in memory.
Looking at the Windows calculator, it seems to take a number then a operand
as valid syntax to use the previous number as post number.
Thus
'3 +' = 6
'3 -' = 0
'3 *' = 9
Any further operand cancels out the previous.
Thus:
'3 + + + + - - - - * * *' is equivalent to '3 *' = 9
Strange ....
-----Original Message-----
From: Brian [mailto:briandabrain@gmail.com]
Sent: 08 February 2006 23:21
To: ReactOS Development List
Subject: Re: [ros-dev] Bug: The calculator of ROS calculates wrong
just a thought...
shouldn't 3,+,+ in calculator produce 6...
brian
friend of ReactOS
************************************************************************
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
I have a question:
Where is everyone on the list. I have only received a few mailing
list posts in the past couple of days. I know that there has been a
scandle as of late, but does that stop mailing list posting? What is
the deal?
Is it an error of ROS or an error of WINE?
The Wine-Calculator is every time one too high.
3 + 7 = 11 in the calculator and so on.
But it comes already after the "+" or "*" was pressed.
After [3] + [+] there stands 4 in the display.
Or is it an error of QEmu? I don't know.
Only to mentioned it. I know that you have at the moment no time for it,
because you are in progress of oversearching your code.
Greatings
theuserbl
I think the existence of this mailing list has realy been revealed on
ros-dev before.
Maarten Bosma
Ged Murphy wrote:
> Maarten Bosma wrote:
>
>> Rick Langschultz wrote:
>>
>>> I have a question:
>>>
>>> Where is everyone on the list. I have only received a few mailing
list posts in the past couple of days. I know that there has been a
scandle as of late, but does that stop mailing list posting? What is
the deal?
>>
>>
>>
>> I think I can solve that puzzle. Since that scandal we got a private
mailing list just for developers. ;)
>>
>
> I don't think that was meant to be public knowledge. People will
think we have something to hide now.
>
Ged Murphy wrote:
>> good idea - a paint(brush) clone
>> [..]
>
> Yeah, it's a nice idea. :)
> Certainly worth considering.
I don't think that is what ReactOS needs at it's current state. But
that's just my opinion.
> Other thoughts were taking on the cache manager
I have heard that this is one of the hardest part of ReactOS and also
the cache manager rewrite was already done so far. (However I don't know
how much of it will be left after the audit.)
> Keep em coming guys, I have until next Monday to decide.
Maybe some kind of device driver, or a file system driver (for example
Reiser4) although that is told to be hard too.
Another idea of mine would be a web based job system. I think that one
of the main problems of ReactOS is that we just say: "Here is the
source, you can choose a part to work on. Have fun !".
I know that we got Bugzilla, but you have to admit that it has not
really proven to be a good place for new devs to get started. So a
system, which lists tasks sorted by skills needed, would be a solution.
Later such a system could be used for Bounties as well. But I don't know
if it is a good project for you. Actually I just wanted to write down
the idea before I forget about it again.
> Thanks,
> Ged.
>
Maarten Bosma
As I see in ROS 0.2.9 the font in noteopad looks a lot of different to the
font which Microsoft used in its Notepad.
In Win95/98 Microsoft used for Notepad FixedSys as font. In WinXP it used
LucidaConsole.
But what is with FixedSys? Is it completly new created by Microsoft?
I think no.
Have a look at the PC-system font. I mean the VGA-font which you see, if you
start your computer or which you see, when FreeLoader runs.
The PC-system have three standard fonts. The CGA font have 8x8 pixel. The
EGA-font is a little bit bigger and the VGA-font is 8x16 pixel large. Today
you see nearly only the VGA-fonts.
There existing also some OpenSource programs, which draws this fonts on the
screen: QEmu, DosBox, freeBASIC, etc.
And if you compare this font with the Win95/Win98 fixedsys font, you will
see, that letters like "A" and "O" are completly the same.
And the other letters have mostly only the squiggle, curlicue, flourish or
how it is called erased.
If you erase it on letters like "B", "D", "F", "d" and so on, then the most
majority of the letters looks completly like the fixedsys font of
Win95/Win98.
Only the "0" and some other letters looks then different.
In WinXP the FixedSys font looks now different. I think there it is a
completly new creation by Microsoft. It is also smaller (I think 7x14 or so)
then the old fixedsys font.
But I think, if anybody want to create a fixedsys font for ReactOS, then
using the PC-system-fonts and removing the protruded lines, would be a good
basis for the ReactOS fixedsys font.
The fixedsys font is a little bit unique.
It is not a extern TrueType font. It is integrated in the system.
It is also not a vector-graphic font. It exists only in one size. There
existing no bold or italic version of it. And it will not be antialiased.
And if you remove all fonts of the Windows-System, Windows will use the
fixedsys font insted.
Greatings
theuserbl
Hi!
I am not a programmer. So, it can be possible, that my idea is naive.
You write here in the list, that the best would be, to make clean room
reverse enginering, if an API isn't documented.
But why you not disasseble the apps which you want to run on ROS instead of
disassembling Windows?
I see for it two advancements and one disadvancement.
The advancements:
1. If you make clean room rev. eng., then you cut into halves the number of
developer of ROS.
Then only one half programs for the system. The other half writes documents.
But if you disasseble the apps which running on Windows, then you are still
allowed to publish the documentation of the API it used. You are not allowed
to write then an application like that, what you have disassembled. But that
is nothing you want. You want to write an OS, which can execute this app.
And that is (hopefully) allowed.
I don't know, if I am naive, but I think, if you see, that the program used
a function
void WindowsFunctuion (int, int, float);
then you can write little test apps, with different values, to see what
happens. So you don't need to disasseble Windows to look which happens.
2. If you make a clean room rev. eng. the people who write the document can
make a mistake. Discribes the API wrong or not complete, so that the program
which needs it still not runs.
In this case the people who program, must say to the documenter, that he
must do it again or better. But they can not communicate to much about it.
Not to detailed.
But this problem can be solved if you use the programs/drivers for Windows
to disasseble insted of Windows itself.
The only disadvantage I see is, that it can need more time to understand the
code.
If you "only" disassemble Windows, you comprehend the code in any time.
But if you disassemble an app, it is at first the same. But if you have
written the API for ROS and the app runs on ROS, then you must begin by zero
by disassembling the next app, which don't run on ROS. And you must try to
understand the code of this app and so on. So it can be possible, that this
way takes longer, then clean room rev. eng. Windows direct. But I am not
sure.
Greatings
theuserbl
Ge van Geldorp wrote
> > From: Murphy, Ged (Bolton)
> >
> > James Tabor wrote:
> >
> > > We should have Wine synced into the SVN by now. 8^) What is
> > > missing or not?
> >
> > Gé ;)
>
> :)
> I'm still here. AFAIK, we agreed to transfer the Wine DLLs as late as
> possible.
>
> GvG
Yeah, I recall that being the idea.
I think it's more important to get base libs like CTR, kernel32, user32 and
GDI32 in.
Pretty much nothing will build without those, so the Wine dll's would be
useless anyway.
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
James Tabor wrote:
> We should have Wine synced into the SVN by now. 8^)
> What is missing or not?
Gé ;)
Hehe
************************************************************************
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
Aleksey Bragin wrote:
> Hi Pavel,
> currently, only audited SVN server is publically accessible, its URL
> is: svn://svn.reactos.org/audited.
> As for the main svn server, it has been switched off from anonymous
> access, because there were concerns, that it might contain
> copyrighted material. As soon as we clear up the situation,
> it may be
> opened to public access again.
>
> On Feb 8, 2006, at 1:56 PM, Pavel S. Mironchik wrote:
>
> > Hi,
> > I wonder if any anonymous access to reactos svn exists.
> > or could I get login to read svn and track chnages?
For convenience, you can also track changes via the ros-diff mailing list.
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
I know I've asked about this before but - maybe I missed something or
I'm stupid - I never got it working.
I'd like to be able to use distcc when compiling ReactOS, if that's at
all possible.
When I tried, rbuild built using it, but then rbuild went on to just
compile locally.
It'd be great if it can be modified to make it a simple flag to pass to
rbuild or the makefile or something.
For working on small parts it's probably not that beneficial, but it'd
make a complete recompile much faster I think :)
jimtabor(a)svn.reactos.org wrote:
> Add portcls to new branch.
>
>
> Added files:
> trunk/reactos/drivers/sound/multimedia/
> trunk/reactos/drivers/sound/multimedia/portcls/
> trunk/reactos/drivers/sound/multimedia/portcls/portcls.c
> trunk/reactos/drivers/sound/multimedia/portcls/portcls.def
> trunk/reactos/drivers/sound/multimedia/portcls/portcls.h
> trunk/reactos/drivers/sound/multimedia/portcls/portcls.rc
>
This was KISS! All stubs are based from OSR.
http://www.osronline.com/ddkx/stream/pcdesign_78yv.htm
Thanks,
James
I am told that the sources for FreeLdr are all okay, except for the
some of the bootsectors having been pretty much just disassembled from
MS's. Is this true? If so, will someone please copy them over before I die
of impatiance? Its not like we need those bootsectors, anyway. I mean, a
lot of us on IRC have agreed that using GRUB to load FreeLdr is probably
our best bet for now, until someone gets around to customizing boot code
from GRUB or FreeDOS. Anyway, we don't need to worry about that until the
installation CD boots ;-).
--
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
In the course of auditing isapnp, I wrote a test case that proves that
switch(a) {
default:
printf("foo\n");
break;
}
While peculiar, cannot be the product of directly reverse engineering
visual C or gcc output (and likely any other compiler).
Is there a place we want to put such apps?
--
Discordant is the murmur at such treading down of lovely things while
god's most lordly gift to man is decency of mind. Call that man only
blest who has in sweet tranquility brought his life to close.
If only I could act as such, my hope is good.
-- Aeschylus' Agamemnon (translated by H. W. Smyth)
Oh... I thought it might have been some kind of expression describing the feeling of "the project is going to #£€% anyway so why not move to Sweden as well..."
My interpretation might have been biased by the somewhat edgy and often childish attitudes displayed in this thread lately. My opinion is that we HAVE to walk a few extra miles to regain the credability of this project. Even if this means more documentation and restrictions for the devoted practicians of reverse engineering.
/Johannes Olofsson
> Från: James Tabor <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net>
> Till: ReactOS Development List <ros-dev(a)reactos.org>
> Rubrik: Re: [ros-dev] Undocumented APIs
> Datum: Wed, 01 Feb 2006 12:43:42 +0000
> Johannes Olofsson wrote:
> > >
> >
> >>Man! Sweden here we come!
> >>James
> >>
> >
> > ??????????????????????????????????????????????????????????????????
> > Was this some kind of insult?
> > /Johannes
> >
> WHAT?
> NO! There was talk of moving the svn to Sweden.
> James
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> <a
> href=http://www.reactos.org/mailman/listinfo/ros-dev>http://www.reactos.org/
> mailman/listinfo/ros-dev</a>
here is a letter from JvA.
As most people know we have talk to move svn to another place.
Dear ReactOS Crew,
I spoke today with Lysators highest administrator Kalle, and he told me
that there should be no problem what so ever for Lysator to host you.
However, in order for us to host you we need a letter from you where you
ask us to host you, and specify what you want to use the server for.
This letter is needed for bureaucratic reasons.
The root group needs to officially grant you the right to be hosted in
our server hall, and marked as a Lysator-project. What the root group
wants to know is what you intend to use the server for and what ports
you need open in the firewall. The security rules in Lysator strictly
says that only Lysator members are allowed to have administrator/root
accounts on the servers in the server hall. The person who would
administrate your server would be me. People outside Lysator, like the
ReactOS developers, are however allowed to have normal SSH-accounts.
Bandwidth is not a problem. Kalle told me that Lysator has been granted
a secondary gbit-connection if the current one isn't enough. By the way,
the server hall has UPS:es to make sure the servers are online even if
there are would be electrical difficulties.
When you have had a meeting and decided what you want hosted in the
Lysator server hall, send me a letter where you ask us to host you and
I'll give it to Kalle. When you officially have been granted to be
hosted by us, you need to supply us with a server, 1U or 2U. If you
want, I could build it for you here in Linköping if you collect money
and let GreatLord buy the parts. The OS that the server would run would
be Gentoo Linux. I will of course install Apache, SVN, cross-compile GCC
and whatever you need on the server for you.
Best regards,
Fredrik Smedberg (JvA)
Rick Langschultz wrote:
> I think ReactOS should have no Reverse Engineered code within it.
> Reverse Engineering could be bad for the projects publicity and code-base.
> I think that reverse engineering of the Microsoft Code is wrong!!!
> And if programmers within this project want to reverse engineer they
> should start their own projects, with their own names, and use their
> own code. How would you like your product(s) to be stolen?
It's not wrong, and it's not illegal. If Microsoft provided better
documentation for their internal interfaces, then it wouldn't be required.
Without reversing to discover how various parts work, ReactOS would struggle
to make a fully compatable system.
You don't think that writing an operating system to effectively clone the
Windows methodologies is wrong, yet you think that reversing various parts
to discover how it works is. That doesn't make sense to me.
As long as there is no code copying, there is no problem. One person
reverses and documents how something works, another person reads the docs
and reimplements it. It's just like reading a book.
It's no different than dismantling an engine, or a calculator, or a toy to
understand how it works.
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
Sorry about that, It seems like my mail-client automatically used the same style as the original mail I responded to...
Regards
Johannes
> Från: Alex Buell <alex.buell(a)munted.org.uk>
> Till: ReactOS Development List <ros-dev(a)reactos.org>
> Rubrik: Re: [ros-dev] Moving svn to another contrury or not
> Datum: Thu, 2 Feb 2006 14:25:18 +0000
> On Thu, 2 Feb 2006 13:37:24 +0000 (GMT) "Johannes Olofsson"
> <johannes_olofsson(a)spray.se> waved a wand and this message magically
> appeared:
>
> Your message was full of html tags. Can you make sure your mailer uses
> plain text instead of html. Some of us don't use clients that likes
> html, you know.
>
> --
> <a href=http://www.munted.org.uk>http://www.munted.org.uk</a>
> "Honestly, what can I possibly say to get you into my bed?" - Anon.
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> <a
> href=http://www.reactos.org/mailman/listinfo/ros-dev>http://www.reactos.org/
> mailman/listinfo/ros-dev</a>
Hi all,
Steven Edwards wrote at http://www.reactos.org/xhtml/ru/news_page_14.html:
"One final note, this audit of the code is going to take a long time. It
could take years, but it will happen, this project will come out better
than it was before".
Whether means it, what all development will be suspended for the period
of audit? I understand necessity of audit, but I am afraid, that in a
year the urgency of the project will catastrophically fall, and it will
hopelessly lag behind from Microsoft :(.
I want, that ReactOS have survived...
WBR,
DarkHobbit
I'd like to put this amendment to the IP policy to a vote, but first let's
start with the 7 day discussion period.
"If an API or a particular behaviour of an API which is part of the
Windows(R) operating system is not publicly documented by Microsoft, then
the API or the particular behaviour of the API may only be implemented in
ReactOS if there is documentation of published software which depend on the
API or the particular behaviour of the API, and which is not only
distributed with the Windows(R) operating system. The documentation must be
available in the repository."
I argue that the more ReactOS differ from Windows, the harder it will be to
prove that ReactOS is a derivative work of Windows.
Med venlig hilsen / best regards
Casper Hornstrup
Chief Executive Officer @ Eudicon
ch(a)eudicon.com / www.eudicon.com
(+45) 27 29 36 20
Casper Hornstrup wrote:
> "If an API or a particular behaviour of an API which is part of the
> Windows(R) operating system is not publicly documented by
> Microsoft, then
> the API or the particular behaviour of the API may only be
> implemented in
> ReactOS if there is documentation of published software which
> depend on the
> API or the particular behaviour of the API, and which is not only
> distributed with the Windows(R) operating system. The
> documentation must be
> available in the repository."
>
What if a particular API is required for a particular program to work, but
that API is undocumented by both Microsoft and the owner of the said
program?
Also, what about using code from 3rd parties which might contain
undocumented API's, like Wine for instance?
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
art yerkes wrote:
> > Which is of course fine, but since ReactOS has no use for
> it, why commit it?
> > It isn't needed to meet the goals of ReactOS.
> >
> > Casper
>
> I don't agree with this sentiment at all. We've always
> before been proactive
> about implementing at least visible parts of the API to make
> it more likely
> that applications we didn't know about would have a chance to
> work. I think
> that's a reasonable way to work, especially if you're working
> in an area you've
> got a good understanding of.
I completely agree with this. Some of the rules being proposed seem to be a
little over cautious.
This 'shake up' shouldn't put a strangle hold on the project.
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
> Too vague in my book. I request a reformulation. I sort of get what you
> try to indicate, but it's too easy to explain incorrectly and the
> meaning as I understand it doesn't include enough APIs to be of any
> significance to note down in the IP policy. There are also arguments
> against it, like the educational purpose of being able to lecture at
> universities on the subject of NT using ReactOS.
Why would you want to lecture on the subject "alternative ways to implement undocumented APIs that are not used by any 3rd party software"?
/Johannes Olofsson
Hi all.
Would someone be willing to put a flow chart together on moving code
from the main branch to the audited branch.
I think if something like this is put in place, it would ensure everyone
was operating in the same manner.
Pasted from IRC when discussing the audit methodologies:
<GedMurphy> I understand what qualifies for being 'unclean' (which it
seems most of ReactOS will be initially), in which case it should be
placed into the intermediate repository. However it isn't clearly
stated what happens then. If documentation can't be located or test
cases aren't written, how is that code further analized?
<sedwards> If the code is 'unclean' then someone need to mark themselves
down to rewrite it on the audit page
<GedMurphy> but what if it's not unclean, but there is no documentation
for it? Is it automatically deemed to be unclean in that case?
<GedMurphy> e.g. Exception wrote most of the original part of the
network stack. I'm positive this was done in a clean manner, but where
are the docs? Does he still have them? What happens if there aren't any
or they have been lost?
<GedMurphy> does rewriting them automatically mean that code is then ok?
<GedMurphy> senario 2. No docs can be found, but someone writes some. If
that code was ripped from Windows assemblies but we provide docs, that
code might get through. However it doesn't get around the fact that it's
been 'borrowed' from Windows dissasemblies.
<GedMurphy> at what point in the audit is the code checked for
similarities to the Windows counterpart, if at all?
<GedMurphy> This is what I mean by set methodologies. Something should
be laid down, like a flow chart
I would offer to do it, but I think one of our more experienced dev
would make a better job. Maybe someone who has done something like this
before. I was hoping for one to follow for myself to make sure I don't
drop a b*ll*ck :)
Ged.
I agree highly with Alex, I honestly think that ReactOS has lost
complete focus on what their intentions were originally, I think it is
time to go into discussion regarding the re-evaluation of the projects
primary goals are, this is not good if it is left unmanaged, but on
the other hand, it still would be kind of neat for someone to
"re-invent the wheel" Windows NT wouldn't it? ;)
--
-David W. Eckert
Maarten Bosma wrote:
> Why do you want to close all bugs ? Most of them will be
> still vaild
> after the audit. I'd say the better solution is to add them to the
> patch category.
I agree with Steven. This is a good time to restart bugzilla, as it was a
mess.
Many of the bugs are going to be invalid, or giving different results after
the audit.
There will also be many new bugs introduced.
It's easier to just restart it than keep tabs on the old tree.
We should keep better control over it next time.
************************************************************************
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
D. Hazelton wrote:
> Someone mentioned that regedit might be a piece of code which
> is the only one
> to use a function call... All modern windows releases ship
> with two versions
> of regedit, regedit.exe and regedt32.exe - and there have
> been several
> third-party replacements for regedit released.
Win XP and above ship with a new regedit.
Regedit.exe(win98 derivative) and regedt32.exe(crippled version for 2K) have
both been dropped.
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
Dont be silly, all of you, such audit will take at least half a year and reimplementing everything will just destroy the proyect. Use your heads, you are programmers, and you fear there is leaked code, if there is any their assembly it should be similar to the windows one, so be easy: compile reactos, dissasemble it. Then dissasemble windows. Write a tool that compares dissassembled code. And you have ONLY (and is still lots of work) to compare where there are enough coincidences betwen reactos assembly and windows assembly. Once you get to those spots you only have to check if there is a logical conclusion of a sole way of doing something (like clearing a stack) or a copied code.
Why hope for reactos,
Lucio Diaz.
---------------------------------
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
M Bealby wrote:
> Hey all,
Hi Martin
> I have finished my security audit of one of the pieces of code in the
> new svn repository! (/base/services/tcpsvcs/)
>
> In my audit notes I have listed the problems by simple filename:line,
> flaw, description. They are also dated. Is this the same sort of
> documentation you would like in svn and bugzilla too?
I think the best place for this would be bugzilla.
You can group the full audit in one bug.
> On that note, what is happening with bugzilla? I seem to remember
> someone mentioning that someone was going to go through all the bug
> reports and close any that affected non-audited code. Is this
> correct?
I don't know what is happening with bugzilla at the moment. We've lost
WaxDragon now :(
He used to take care of bugzilla, and all other things related to testing.
You don't want the job, do you ?? ;)
> Should I submit my bug report anyway? I'll write something
> noticeable in the summary field so it is obvious it is to do with the
> security audit.
When you submit it, I'll try to get it fixed straight away.
I expect there to be quite a few fixes as I just threw this code together
quickly to give us something to test with. ;)
> Are we going to implement something like Peters /documentation/ patch?
> If so I will put my security auditing notes in there too.
I don't see any reason to store information which is going to be fixed.
Bugzilla
and SVN will take care of the history for us. However if there is general
audit
information in there, then I think is should be treated in the same manner
as the
rest and stored in the respective directory accordingly.
Regards,
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
Hey guys,
at first I was shocked, when I read that you want to audit all code and
will have to rewrite a lot of the old code, but then I realised, that
this is a great chance for making improvements.
Here's one of my ideas:
We could create a completely new setup, that will have a gui (not really
a new idea...).
But the second thing would be to create something similar to debians apt
and debconf.
My idea was to create a new setup, that installs ReactOS in packets,
that would look a bit like this:
A compressed archive (maybe bzip) that contains a folder with all the
files, that need to be installed, one file that contains informations
like e.g. where to put the files (%SYSTEMROOT% or %WINDIR%...) and one
script file that looks a bit like a batch file. Maybe we could add a
file, that contains some questions and hints, that can be interpreted by
different configuration utilities.
That is, what is IN these archives, in addition to this the header of
the file would contain uncompressed information about the dependencies,
so that they are easier to read.
All this would give us some big advantages.
For example we would be able to create different distributions and
repositories.
Companies would be able to have a mirror of our repository and could
additionally have their own repositories, whose files depend on ours.
This would ease deployment in big companies and would be a big advantage
compared to Microsoft, as everything happens completely unattended,
even if you upgrade from ReactOS 1.0 to 3.0.
I'm looking forward to read what you think about my idea.
Greets,
David Hinz
I've made a start with the audit of NTOSKRNL. The page
http://www.reactos.org/wiki/index.php/Ntoskrnl_audit contains a list of all
the public (either exported or syscall) routines of our ntoskrnl.exe, with a
template to fill in the audit metrics which were proposed. I already checked
the documentation status of all routines.
GvG
Hey all,
I have finished my security audit of one of the pieces of code in the
new svn repository! (/base/services/tcpsvcs/)
In my audit notes I have listed the problems by simple filename:line,
flaw, description. They are also dated. Is this the same sort of
documentation you would like in svn and bugzilla too?
On that note, what is happening with bugzilla? I seem to remember
someone mentioning that someone was going to go through all the bug
reports and close any that affected non-audited code. Is this
correct? Should I submit my bug report anyway? I'll write something
noticeable in the summary field so it is obvious it is to do with the
security audit.
Are we going to implement something like Peters /documentation/ patch?
If so I will put my security auditing notes in there too.
Cheers,
Martin
Index: documentation/README
===================================================================
--- documentation/README (revision 0)
+++ documentation/README (revision 0)
@@ -0,0 +1,11 @@
+This is the documentation directory for the ReactOS project.
+
+
+Directory Layout:
+
+api\ : Documentation for various APIs.
+articles\ : Howto's, Articles and related documentation.
+audit\ : Documentation about and gathered by the audit.
+reverse.engineering\ : Clean-Room effort documentation.
+ : _Only_ human language and pseudo-code documentation is allowed here.
+
Just an idea to kick around--
With the recent issues of reverse engineering, and our
new-- extra stern-- IP policy, it appears that
"cleanroom implementation" (US style) is going to be
very strictly adhered to. This raises a few concernes
to me, even though I dont develop code.
1) The developers that decide they will become(Stay)
reverse-engineers are going to have a great deal on
their plate allready. Not only will they have to
decompile proprietary binaries, but they will also
have to make documentation about the functions within
those binaries. Asking them to manage the collective
work of both themselves and other reverse engineers is
asking too much.
2) Implementors are not allowed to have direct
communication with reverse engineers, under US style
CleanRoom implementation practices.
So, I propose a new group classification, with the
purposes of
1) Organizing, catalogueing, and possibly correcting
(For spelling, and other grammaticals) the whitepaper
documentation produced by the reverse engineers.
2) Offering the functional service of communicating
with the reverse engineers any objections, or concerns
the implementors might have. (EG, "XXXX XXXX does XXX
XXX by YYYYY" is not sufficent to explain what is
going on, can I get a better description?", the
documentation manager group would contact the reverse
engineer in question, and ask them to make an adendum
to their documentation to address this issue, and
would then contact the implementor after such
addendum(s) have been completed, and filed.)
This group would thus have responsibilities simmilar
to "Editor", "Librarian", and "Secretary", which is
why I propose the generic name "Documentation
Manager(s)."
If there is allready such a position/group, I withdraw
the proposal. Otherwise, I dont see how we could
really hope to pull this off without dedicated
individuals on this task.
(PS, having "non-Coders" on this taskforce would
probably alleviate any allegations of contamination
between reverse engineers and Implemntors, in that it
is unlikely that the secretary in question would
understand a very technical request to begin with, and
thus be unable to pass on any such complicated
requests in their duties as secretary. It would also
give some really strong enthusiasts something to do--
All you need are clerical and communication skills.)
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Has anyone checked out the Samba 4.0 Tech Preview? I think the NTVFS
folder includes code that allows another FS to act like NTFS. But
take a look and tell me if integration to ReactOS would be a good idea.
Please ignore my last diff; this is an improved version.
This diff sets up a directory (ntdocs) where documention and test cases
and be put.
I sugest that the tree for this dir should mirror the actual code base
for ease of use.
Thanks.
Index: ntdocs/readme.txt
===================================================================
--- ntdocs/readme.txt (revision 0)
+++ ntdocs/readme.txt (revision 0)
@@ -0,0 +1,6 @@
+This directory contains the documentation for Reactos (test cases and the like). Please do NOT put actual code here.
+Just enough to implement it. Only human lanuage and puedo-code is allowed here. If you reversed engeneered, it please keep the policy and DO NOT implement it.
+
+The tree layout for the docs should mirror that of the actual code tree for ease of use.
+
+Thanks.
\ No newline at end of file
I think we need to be more organized in this endeavor.
We need to decided who will look at chuck of code, so that the process
goes faster.
I suggest that we pair up into two person teems whose responsibility is
to decide if a certain group of code it dirty or not. These teems will
then look at their area of code systematicly, deciding if part or alll
of the code they come across is dirty. All the clean code will then be
put into the audited trunk, then the stripped stub of the functions that
were dirty.
> From: chorns(a)svn.reactos.org
>
> Document rbuild
> Property changes on: trunk/reactos/tools/rbuild
> Name: svn:doc
It seems your brain is pre-wired to type "svn:..." after "propset" :-)
GvG
Hello,
Ok here are some proposed ground rules for the audit. Mostly thanks to
Art and Alex. We are still open for debate on this
0. Everyone needs commit all documentation you have reverse enginered
something so that someone else can reimplement it. Filip has some nice
docs at
http://www.volny.cz/xnavara/doc_trash/
There is stuff I posted on the Wiki and Bugzilla. Can someone make a
api-documentation module in svn and commit all this stuff to there?
1. A function is deemed to have been implemented in a non-clean manner if
- "unknown" arguments given values
- functions for which there is NO DOCUMENTATION
- functions with no test cases available either in ReactOS or
somewhere on the internet
- functions with undocumented magic numbers
- functions with excessive gotos
NO DOCUMENTATION means it cannot be found on MSDN, Google,
sysinternals, osronline, any book published by Microsoft Press or any
other publication.
2. The following does not count
- functions of 5 or less lines of code
- functions for which every basic unit corresponds to a clause in the
official documentation
- functions which mimic those implemented in other libraries and that
work similarly
3. Even if the function body is not clean, the prototype can remain.
--
Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I thought it would be a great idea to put all the reversed engineered
documentation in a separate directory in the audited trunk.
Here is the diff to set it up (attachment).
Thanks.
Index: rev_doc/readme.txt
===================================================================
--- rev_doc/readme.txt (revision 0)
+++ rev_doc/readme.txt (revision 0)
@@ -0,0 +1,4 @@
+This directory contains the documentation from reverse engineering. Please do not put actual code here.
+Just enough to implement it. If you reversed engeneered it please keep the policy and do NOT implement it.
+
+Thanks.
\ No newline at end of file
Just a very, very vague question:
When can the public exspect access to a ( surely very leaky ) cleaned up
skeleton of ROS?
I mean that we have a running system, without the unchecked ( unclean )
components, so that people can start working again on the clean code.
For example: We can boot and explorer pops up. Nothing more. So we can
fix bugs in NTOSKRNL, FREELDR and EXPLORER...
Greetings,
Jan Schiefer
Hi,
as the repository is being set up fresh, I think this would be the
best time to correct some problems with the directory layout and file
naming schemes.
The rbuild input files have been named "*.xml". Yes, these files are
XML files. But it's not the best name for them. It would clash with
XML files being used by the built applications itself. So I propose to
rename all those "*.xml" files of the rbuild system to "*.rbld".
What do you think about this idea?
Regards,
Martin
Personally, my main area of interest regarding the recent discussions
has been that of reverse-engineering. But what I'm about to say could
probably be applied to the leaked sources, too (this isn't what I'm here
to discuss, however.)
We all know that some bits of Windows' internals are hidden, often
intentionally, and that some product may make use of certain hidden API
function calls, or may interact with the system components in a way
other than that described in the API reference documentation.
Other times, parameters to API function calls are not clear, or not
documented at all.
As a result, to make something that is compatible with Windows (or at
least MORE compatible), it is necessary to use alternative methods (eg:
reverse engineering) to determine what an undocumented function works,
how it behaves, or to investigate undocumented flags, etc.
For the sake of the project, any reverse-engineering should be done as a
2-man job. It seems the case that people often take it upon themselves
to do both jobs - that of the person looking at the disassembly, and
that of the person writing the code.
This is how I wrote most of WDMAUD.DRV.
I was skeptical about the morals/legality of it at the time, but was
told that it doesn't matter.
As this is all now out in the open, and I've exmained the disassembly of
WDMAUD.DRV, it's probably best that I continue to examine it, and
document my findings, for another developer to implement later.
For other modules, it depends who's comfortable doing disassembling. I'm
happy to write code, and would like to do so. But I haven't the first
clue about kernel-mode debugging so things like the Kernel Streaming
API, I'd probably struggle with.
As for the rest of the project, the impression I get is that, rather
than going through the existing code and auditing it, it might be best
to start over.
This has disgruntled a lot of the major developers.
But don't forget, when the project was in its early days it was focusing
on NT4 compatibility... Not a lot worked, and there was no clear-cut
development policy... Then there was an explosion of activity and we've
been racing forward ever since.
Some may claim we're reinventing the wheel again, but we already *have*
a working kernel and this time round it shouldn't be as difficult as it
was previously, provided we can use our original sources as a reference.
There's all sorts of things that can be implemented from the start
rather than being added on later (maybe translations? - I don't know how
this works but AFAIK this was something that was discussed further along
the development line.) We can focus on the current technology and not
aim low (NT4.)
I just think we need to have people who are good at deciphering
disassembly and producing documentation, and people who can code from
that documentation (or other documentation, of course.)
Anyway, those are my thoughts. If any of it doesn't make sense it's
because I'm tired!
What's the location of the new ReactOS SVN repository?
I tried 'svn co svn://svn.reactos.org', and I got an error saying that
no repository existed at that address, so I'm guessing the location of
the repository has moved.
...
I assume SVN is starting from Scratch?
On 1/27/06, chorns(a)svn.reactos.org <chorns(a)svn.reactos.org> wrote:
> Standard repository layout
>
>
> Added files:
> branches/
> tags/
> trunk/
> vendor/
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-svn
>
--
"I had a handle on life, but then it broke"
Hello,
There has been a lot of talk about possible tainted code in ReactOS
and or developers that had access to leaked Microsoft source code.
This has caused a lot of speculation about the future of the ReactOS
Project. I'm going to try to put those fears to rest and explain what
has been going on and where we are going to go from here.
There was one issue that started this discussion and it related to
clean-room reverse engineering of certain code in ReactOS. Due to the
fact we have developers in many different countries the term reverse
engineering can mean many things to many different people. For us in
the US when you speak of clean-room reverse engineering it means that
one person tears apart the implementation of a device, writes
documentation and another reads that documentation and implements.
Other countries do not require this invisible great wall of
development and allow the same person that disassembles the interface
to also write the replacement implementation.
Because of the confusion this has caused and the possible legal issues
this could lead to we have decided to do the following.
1) Amend our Intellectual Property Policy Statement to reflect
clean-room reverse engineering as meaning the US standard method for
reverse engineering and make that the project requirement
2) Audit the entire source tree and rewrite all code found to have
been implemented not using the US method for reverse Engineering
3) Require all developers contributing major code to accept the terms
of our IP Policy Document via signature.
Now as for the issue of leaked source code, I want to try to put all
fears to rest. We don't know what the legal ramifications are for
someone downloading and having leaked code, as the party that
maintains copyright ownership of that code might still try to claim
Trade Secrecy on information contained in the sources in a court of
law. It is our point of view that the source code leaks of Windows
have been spread to a broad enough audience that it would be
impossible to claim the product is still under Trade Secrecy. Because
of this we are not banning any developer who might have had access to
leaked sources from contributing to ReactOS, however they are being
limited as to what area they can contribute. Copyright law still
applies to all leaked Windows sources and no one in ReactOS may copy
code from a Windows source leak and try to apply it to code in the
ReactOS tree.
We know of four developers who have had access to leaked sources prior
to working on ReactOS and while they no longer have copies of the
source code in question, each of the developers have told us in
private which sections of the sources they were exposed to. As such
the project has amending the IP document as a fourth step of
protection
4) any developer that had access to leaked sources is baned from
contributing code to the project for any of the modules that are the
same as leaked sources they examined.
So to clarify that, lets say someone saw some of the leaked Windows
source code in version.dll, then they would be unable to contribute
code to the ReactOS project for that dll.
It is our hope that a court case will arise and declare Microsoft's
Windows code is no longer under Trade Secret protection so these
developers who did have access to some of the leaked sources will be
free to contribute again to all sections of the project.
One final note, this audit of the code is going to take a long time.
It could take years, but it will happen, this project will come out
better than it was before. I don't believe anything anyone has done
while working on this project was really wrong. Every decision has
three possibilities, being moral, ethical and or legal. Sometimes the
law in itself is unethical and immoral. If people made mistakes and
there was a violation of the law, I question the justice of the law
and or anyone that would try to prosecute any of the developers who
just want the freedom to learn and create a more free system.
--
Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hello,
Sorry for this general email. I have gotten many personal emails about
the current situation and cannot reply to all of them. In short here
is the deal:
There have been allegations about possible copyright and trade secret
violations in the ReactOS Project. Pending a discussion with legal
council, those members with SVN access who were part of private
discussion and online on IRC on Tuesday Jan 24th 2006 decided by
majority vote to suspend operations of public SVN, forum, discussion
and email archive. Anyone with SVN write access who might have missed
any of the discussion is asked to try to be on IRC today at 3PM EST
(-5GMT). We are going to discuss the matter further and decide how to
proceed.
What started out as a question about development methods mushroomed in
to a much larger issue. The question the looms before us is a simple
one. If one or more developers had at any leaked source code in the
past, does it taint us and the entire project in the future? It is my
point of view based on the AT&T Unix case that it does not however
IANAL. It is my hope the matter can be solved via a simple set of
changes in our IP Policy as well as sworn affidavits by major
contributors stating they do not have access to leaked sources and if
they ever did, no longer possess them.
Rest assured that the project will live on. Every developer I have
spoken with wants the project to survive and be a success. In the
meantime we are filtering email discussion on this matter because we
do not want rumor and hearsay to be spread. When the time comes and we
have proper legal advice we will move forward. No one is trying to
hide the truth, but law regarding Copyright, Trade Secret, Patent, etc
differ from one country to another and we are currently exploring what
US law says regarding the situation.
One final note, no one is denying that mistakes could have been made
and or trying to hide it forever and pretend there is nothing going
on. We just simply do not want people to be accused of breaking the
law if they really did not. There is clearly some violation of our
current IP policy, however depending on what the legal council
suggests we will see how we move forward. Many of the core developers
at some point have either violated small sections of it by mistake or
prior to its ratification.
--
Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
IANAL but from what I understand, there are 2 issues with using the leaked
source code.
The first is that it is (C) Microsoft. This can be handled like any other
copyrighted material.
The second is that it could be considered a trade secret. I dont know that
much about trade secret law but AFAIK once something is widely distributed
(like the MS 2000 & NT4 source leaks are), it cant be considered a trade
secret anymore. I think that what the ReactOS team needs need is for a
lawyer skilled in the area of trade secret law to answer the question as to
whether the leaked MS source code is still a trade secret or not. (although
unless an actual lawsuit happens that provides a usable precedent either
with the leaked MS source code or a similar leak elsewhere, getting clear
usable advice one way or the other might not be possible)
If it is not, there is no problem with people who have seen it contributing
to any part of ReactOS (as long as there is no copyright violation). If it
is, then there is need to be more careful about people who have seen it
contributing.
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
Hey devs,
I hope the new rules we established will prevent something similar in
the future and I really hope this project will one day succeed. It's not
going to be an easy task, but it can be done. I wish you all best luck
to succeed.
However, the amount of effort more or less wasted, and personal reasons
made me decide that it's better for me to step back for now until
ReactOS some day reaches this point of maturity again. I basically don't
have the resources and energy to devote so much time, again.
Re-inventing the wheel already is controversial, but I personally can't
do it yet another time.
I've met many very talented people ever since I joined almost three
years ago, so it's very sad for me to leave most of this behind. Even
though there were disagreements occasionally, it was great fun for me to
collaborate and create something unique and outstanding. However, I'm
going to try to stay in touch at least.
I encourage everyone to stay if somehow possible and rebuild ReactOS!
Thanks for everything that was done for me and the countless hours of
fun I had with this project.
Best Regards,
Thomas
I was wondering if NTVFS from the Samba 4.0TP would be able to be
integrated with ReactOS? This might add some support for NTFS over
Fat32 or like file systems...
Inproved the implimentation of NdisWriteConfiguration(), by Crashfourit.
Index: drivers/net/ndis/ndis/config.c
===================================================================
--- drivers/net/ndis/ndis/config.c (revision 21005)
+++ drivers/net/ndis/ndis/config.c (working copy)
@@ -66,6 +66,18 @@
ULONG ParameterType = ParameterValue->ParameterType;
ULONG DataSize;
PVOID Data;
+
+ /*
+ The next few lines of code before teh first if statement are used when
+ ParameterType equals NdisParameterHexInteger or NdisParameterInteger.
+ This is done so that Buff can be used beyond the switch statement.
+ */
+ UNICODE_STRING buff;
+ WCHAR str[25];
+
+ Buff->Length=0;
+ Buff->MaximumLength = sizeof(str) / sizeof(str[0]);
+ Buff->Buffer=str;
if(ParameterType != NdisParameterInteger &&
ParameterType != NdisParameterHexInteger &&
@@ -81,12 +93,29 @@
/* reset parameter type to standard reg types */
switch(ParameterType)
{
- /* TODO: figure out what do do with these; are they different? */
+ /*
+ TODO: figure out what do do with these; are they different?
+ Done by Crashfourit
+ */
case NdisParameterHexInteger:
- case NdisParameterInteger:
- ParameterType = REG_SZ;
- Data = &ParameterValue->ParameterData.IntegerData;
- DataSize = sizeof(ULONG);
+ case NdisParameterInteger:
+ {
+ if (!NT_SUCCESS(RtlIntegerToUnicodeString(
+ ParameterValue->ParameterData.IntegerData,
+ ( ParameterType == NdisParameterHexInteger ) ? 16 : 10,
+ &buff))
+ )
+ {
+ *Status = NDIS_STATUS_FAILURE;
+ return;
+ }
+ else
+ {
+ ParameterType = REG_SZ;
+ Data = &Buff->Buffer;
+ DataSize = Buff->Length;
+ }
+ }
break;
case NdisParameterString:
Hey all,
As my exams are now over I will hopefully be having more free time
available to put into ReactOS security. I would like to perform a
security audit of the code base. I've jotted down a few thoughts and
suggestions of mine below and would appreciate feedback on them.
Methodology
I hope to work on the kernel mode code first, working up through the
layers up to application API level code. I feel this is the best
method because, as it has been mentioned before to me on IRC / email ,
some functions canot check the parameters that are passed down to
lower functions.
I understand the following code to run in kernel mode:
/lib/rtl/
/lib/string/
/lib/kjs/
/lib/freetype/
/lib/pseh/
/hal/
/drivers/
/subsys/win32k/
/ntoskrnl/
If you know of any more please let me know.
I was thinking of checking out an entire svn revision and updating
only after I had checked an entire library. What do other people
think on this?
I will predominatly be working just from the code source, but after
playing around with Doxygen I have found it to be incredibly useful
for quick referencing typedefs and function parameter calls.
What am I looking for?
I am only a single person, so code auditing will be a slow process at
the moment. I wish to check for the following vulnerabilities:
Incorrect null termination.
Buffer overflows.
Premature termination.
Lack of input validation.
Bad calculations.
Off by one / few.
Personally I feel this list of six common vulnerability types should
be enough to thwart the most common of attacks, but if anyone else
feels some other class of vulnerability is missing from the list
please let me know. Obviously if I find any other bugs then they will
be reported as well.
Reporting of errors?
How should I go about reporting the errors? I was previously told to
report all occasions of the incorrect uses of the RtlAllocateHeap
function under the same bug number (no 1110, some still unfixed). Is
this the preferred method for my code auditing results? I would like
to submit the bugs as quickly as possible, so I can keep my working
tree as close to possible to head, but this may mean submitting
multiple bug reports for the same problem. I think that the best
option is to submit similar bugs in the same module under the same
report, but open a new bug if the same vulnerability occurs in another
module. Thoughts?
These are just some of my ideas that are floating around in my head at
the moment. I would welcome all feedback on this matter and I think I
may create a wiki page with the same information on. Again, thoughts
on this would be nice as I haven't really used wiki's before.
Cheers,
Martin
I noticed that the implimentation of NdisReadConfiguration() is slightly
off, so I fixed it. The reason why this was so is located in the diff as
a comment.
Thanks.
Index: drivers/net/ndis/ndis/config.c
===================================================================
--- drivers/net/ndis/ndis/config.c (revision 20999)
+++ drivers/net/ndis/ndis/config.c (working copy)
@@ -493,8 +493,17 @@
str.Buffer = (PWCHAR)KeyInformation->Data;
(*ParameterValue)->ParameterType = ParameterType;
- *Status = RtlUnicodeStringToInteger(&str, 16, &(*ParameterValue)->ParameterData.IntegerData);
+
+ /*
+ If ParameterType is NdisParameterInteger then the base of str is decimal.
+ If ParameterType is NdisParameterHexInteger then the base of str is hexadecimal.
+ */
+ if (ParameterType == NdisParameterInteger)
+ *Status = RtlUnicodeStringToInteger(&str, 10, &(*ParameterValue)->ParameterData.IntegerData);
+ else if (ParameterType == NdisParameterHexInteger)
+ *Status = RtlUnicodeStringToInteger(&str, 16, &(*ParameterValue)->ParameterData.IntegerData);
ExFreePool(KeyInformation);
if(*Status != STATUS_SUCCESS)
Hi folks,
> Delete libjpeg because sedwards and greatlord thought we should wait
with jpeg support until the patent expired. If someone got a different
opinion please take the issue to ros-dev.
>
>
> Deleted files:
> vendor/libjpeg/
I hereby "take the issue to ros-dev", because I have a different
opinion. ReactOS is filled with patented (to more and lesser extent,
ranging from SEH to scrollbars, I kid you not) features, and I believe
it is hypocritical to simply remove one of them. I don't know the
details on the libjpeg patent, but I do know that linux distributions
use libjpeg as well, and I haven't seen them remove it yet. I officially
request a vote to revert this commit.
Thanks for reading,
mf.
Does this mean the ROS is going to die a violent death?
No hope for a real alternative to M$ Windoze?
I am really looking forward to Version # 1.0.0 of ROS in both x86 and PPC.
People we (you devs) need to stick togather. Become a team! People are
counting on YOU!
ROS-PPC + Open Workstation Computing platform. = Power to the People!
If you have to become 90% WinOS compatable then so be it! 90% is better than
0%
XP apps can be ported to ROS.
Maybe GvG and WD will come back if ROS went in this direction.
Port Linux GNU code if you have to. Lets get a new GUI and a Integrated
sound system.
Use a open file system not FAT. Write a translator for FAT.
--
David Johnson
Voice Talent
http://www.davefilms.us
DaveFilms Digital Media - Audio [TM]
Producer , Writer,
Production Director/ Designer
The solution is quite easy, is Harmut believes the
code could have implemented another way, unrelated to
the microsoft way, i propouse that Alex gives him the
documentation and Harmut does write the code.
Either if Harmut manages to make a quite diferent code
for that piece of reactos, or is proved that there is
no other way of writing the code Reactos developers
can be safe about that particular code.
And just an advice, it seems you MUST meet each other
face to face, to know each other (a few beers would
help) and get a working relationship.I believe there
is no need of theatral posts and the such,
disagreements is habitual when there is more that one
person, but flaming, bashing or threatening is not the
solution. Talking is.
Take it easy,
Lucio Diaz.
______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
Gentlemen,
I'd never thought I'd take part in such a debate. Let me comment from a
position of someone who's been folowing this project with great
anticipation and high hopes.
First of all I must say Alex's work and commitment to the project is
outstanding. Maybe it is that he somehow makes his work most visible (I'm
not trying to diminish the great work that all contributors have done).
However the discussion here is about something else. I do not think the
discussion should be going along the lines if things can be done any other
way or not. Also I wouldn't think that what someone called 'intent' is the
most important thing (it maybe would be if it saved lives of people). The
thing here is not about whether Alex understands the code he put into SVN
(extensively) commented.
Let me provide an example here on a bit different level: suppose I like
what a commercial(!) Java (or any other decompilable language) program does
and decide to implement an open-source implementation. Would it be
acceptable if I used decompiler to produce a readable code, study it,
understand it, copy and paste those decompiled sources into my project and
comment it extensively? I do not think so. The argument of understanding
the code is irrelevant in this case as it is irrelevant in ReactOS's case.
Is there so much difference between decompiled Java source code and
disassembled binary (especially when the source has been assembly
probably)?
The issue here is about the method and I believe (and that makes me sad)
the method Alex used was against the law and no good intent can change
that. I think copy-and-paste is illegal under any circumstances (I am
strong oponnent of American patent law). I wish very much that Alex and
Hartmut as well continue to work on this project and we see a day when it
becomes an alternative to Windows. But this case puts the project into big
danger in my opinion.
Just my 2cents.
Best regards
Radovan Skolnik
Recent developments have been quite heated recently, and I would just
like to add in some of my own opinions. If code was directly copied
from Windows then it should be removed. Period. This is against the
aims and charter of this project. If Windows was only disassembled to
gain information on how it works then I think this falls under fair
use. Whether a spec should have been written and another person
implement the spec is a topic which I'm sure will be discussed for a
while to come. This is my point of view on the matter and I will not
discuss it further.
It is unfortunate that WaxDragon is also leaving the project, I'm sure
he will be missed. But people do have lives to lead as well. I'm
sure that in the future I will have to leave the ReactOS project too,
and probably for the same reasons, such as family and work. Ideally I
would like all developers / testers and other contributers to stay
with the project, but I understand that this isn't feasible and I
respect them for what they have contributed during their lifetime with
the project.
I devote some of my spare time to the ReactOS project for two main
reasons:
1. I wish to learn more about operating system development.
2. I wanted to practice my code auditing and security skills on a
project that was of a size that was not too large and mature
(e.g. Linux), while not being so small to be insignificant (various
other home-brew OSs).
Number one is coming along nicely as I'm learning about various topics
such as memory management and how drivers work. Number two is coming
along as well, although much slowly as code auditing a fast moving
project such as this is very time consuming and I have been very busy
lately.
I currently see ReactOS at the same stage of Linux in the mid
nineties. People run it, play with it and contribute to it. The size
of this group of people is not large, but they are usually technically
minded and their number is sufficient for the project to grow and
continue. Development is happening at a fast pace and keeping up can
be time consuming at the moment. Lets not try and loose our drive and
ambition here. You have implemented a fairly significant amount of
the Windows operating system in a relatively short amount of time.
You have contributed code to other projects such as WINE. You have a
large number of applications that can already run on the system. You
have achieved a lot, don't stop now.
I think that ReactOS is at a critical stage in development and once is
becomes a little more stable we will see a large increase in the
number of users beta testing and trying it out. I wish the ReactOS
project to succeed and it is something that I think will occur
eventually.
To all of ReactOS' developers, testers and supporters: You are doing a
great job, don't stop now.
Cheers,
Martin
I hereby resign from the position of Testing Coordinator. Casper,
could you please disable my svn account?
I am leaving for a variety of reasons. First of all, I wish to spend
more of my precious free time with my family. Second, work has become
more demanding of my time. There are many other reasons, including
the way major project issues are handled, and the fact I have not been
able to keep up with the testing and improvements I wished to
implement. This decision has been a long time coming.
It's been great getting to know the ReactOS developers and community,
and have learned a great deal from many of you. I will still stop in
IRC occasionally, and will continue to follow the project.
I think the Testing Coordinator position is a very important position,
and it needs to be filled. I feel that I was able to make a direct
impact on the quality of ReactOS, even though I am not a real
developer. I am willing to provide assistance and information to
anyone who wishes to step up to the position.
KEEP FILING BUGS!
Andrew Munger (WaxDragon)
Hi folks:
I was trying to update mi local mirror and fuond that the SVN server is no
longer the same. Wich is the new Address.
Thanks in advance
Regards
Waldo Alvarez
On 1/16/06, Richard <eek2121(a)comcast.net> wrote:
>
> I think it's time for me to hit up bugzilla, anyways, Firefox setup from
> mozilla.com no longer works, it just dies, and the 'get firefox' link
> results in an access denied in the middle of FF setup.
>
> Every 3rd or 4th boot ROS also does not have a mouse pointer. It may be
> frozen, i can't tell.
>
> Regressions...Regressions...Regressions...
> Richard
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
Hi,
many people mailed to me directly.
Sorry, If I didn't answered all of them.
Sorry if I only answer in the evening (EU). I've a day-job and my WAF
doesn't like ReactOS really.
- Hartmut
I think having to debug Alex's latest breakage (bugcheck at the end of 2nd
stage setup) so I can continue debugging one of his earlier breakages (bug
1263) is asking just a bit too much. I'll go do something non-ReactOS
related for the next couple of days.
GvG
I think it's time for me to hit up bugzilla, anyways, Firefox setup from
mozilla.com no longer works, it just dies, and the 'get firefox' link
results in an access denied in the middle of FF setup.
Every 3rd or 4th boot ROS also does not have a mouse pointer. It may be
frozen, i can't tell.
Regressions...Regressions...Regressions...
Richard
When you click 'view GPL' for second stage setup, a license agreement
comes up for something called Gnomovision. This should not be the
case. I would change it myself but i don't have my svn password handy.
Richard
Hi all,
Can anyone see the problem with this picture? Every time I move the window,
it looks like back behind the window, it gets redrawn.
Thanks,
James
Hi,
it seems we have a little bug in KiFastCallEntry. It is initialized a
trap frame on the stack. It is a trap frame without the v86 segment
registers. ESP points to TSS->ESP0 - sizeof(KTRAP_FRAME) + 16. 16 for
the missing v86 segment register. ESP is compared with
KTHREAD->InitialStack - 0x29c. 0x29c is equal to sizeof(FX_SAVE_AREA) +
sizeof(KTRAP_FRAME). If the compare operation fails, it is called
BadStack which results in a v86 invalid opcode exception. To bypass this
bug, there is added a value of 0x10 to TSS->ESP0 in
Ke386InitThreadWithContext. A friend of me has looked to WinXp. He has
found a piece of code which is an exact copy of BadStack and he has
found a piece of code which looks like this:
_KiFastCallEntry:
...
/* Use the thread's stack */
mov ebp, [esi+KTHREAD_INITIAL_STACK]
...
/* Make space for us on the stack */
sub ebp, 0x29C
/* Write the previous mode */
mov byte ptr [esi+KTHREAD_PREVIOUS_MODE], UserMode
/* Sanity check */
cmp ebp, esp
jnz BadStack
...
- Hartmut
In case you've had you're head in the sand recently I'm sure you must
know about the recent WMF bug found in all recent versions of Windows.
The vulnerable function is in SetAbortProc and can be called from a
malicious WMF file as they include executable code by definition.
Windows automatically runs this a WMF file when previewing /
displaying - including from a web page!
WINE is also vulnerable, and still is. However, from a brief look at
my svn repo I think ReactOS is safe. SetAbortProc is in gdi32.dll,
and our version is well out of sync with WINE. I'm not sure if this
is intentional (I don't know which dll's we share directly), but
whoever implements this function must be very careful.
More info at:
http://www.microsoft.com/technet/security/bulletin/ms06-001.mspx
They also have a patch there so anyone running Windows on their
machine is recommended to patch it immediately.
Cheers,
Martin
ion(a)svn.reactos.org wrote:
> - Fix some nasty context switch bugs:
> * We did not update the KPCR's stacklimit/initialstack with the new thread's stacklimit/initialstack.
> * We always assumed V86 frame bias in KeInitializeThreadContext.
> * We did not properly update ESP0 during context switch, to make space for the NPX frame and V86 bias.
> * We did not update fs:18h to point to the new TEB.
> * We did not clear out GS when switching processes, nor update the TSS's cr3.
> * If a new LDT was being updated, we over-wrote EBP (which was supposed to point to the TSS) by the GDT pointer.
> * We used a push/pop esp0 hack which hid the fact we never updated esp0.
> Modified: trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S
> Modified: trunk/reactos/ntoskrnl/ke/i386/thread.c
>
> ------------------------------------------------------------------------
> *Modified: trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S*
> @@ -114,10 +114,6 @@
>
> *--*/
> .globl @KiSwapContextInternal@0
> @KiSwapContextInternal@0:
>
> -#ifdef KDBG
> - //jmp SaveTrapFrameForKDB
> -SaveTrapFrameForKDB_Return:
> -#endif
>
>
> /* Get the PCR. It's faster to use ebx+offset then fs:offset */
> mov ebx, [fs:KPCR_SELF]
> @@ -132,24 +128,36 @@
>
> cli
>
> /* Save the initial stack in EAX */
>
> - mov eax, [edi+KTHREAD_INITIAL_STACK]
>
> + mov eax, [esi+KTHREAD_INITIAL_STACK]
>
Now eax points to the trap frame of the thread we will switch to.
>
>
> + /* Save the stack limit in ecx */
> + mov ecx, [esi+KTHREAD_STACK_LIMIT]
> +
> + /* Make space for the NPX Frame */
> + sub eax, NPX_FRAME_LENGTH
> +
> + /* Set the KPCR stack values */
> + mov [ebx+KPCR_INITIAL_STACK], eax
> + mov [ebx+KPCR_STACK_LIMIT], ecx
> +
>
> #ifdef CONFIG_SMP
> /* Save FPU state if the thread has used it. */
>
> + mov ecx, [edi+KTHREAD_INITIAL_STACK]
> + sub ecx, NPX_FRAME_LENGTH
>
> mov dword ptr [ebx+KPCR_NPX_THREAD], 0
> test byte ptr [edi+KTHREAD_NPX_STATE], NPX_STATE_DIRTY
> jz 3f
> cmp dword ptr _KeI386FxsrPresent, 0
> je 1f
>
> - fxsave [eax-SIZEOF_FX_SAVE_AREA]
>
> + fxsave [ecx]
>
> jmp 2f
> 1:
>
> - fnsave [eax-SIZEOF_FX_SAVE_AREA]
>
> + fnsave [ecx]
>
> 2:
> mov byte ptr [edi+KTHREAD_NPX_STATE], NPX_STATE_VALID
> 3:
> #endif /* CONFIG_SMP */
>
> -
>
> +
>
> /* Save the stack pointer in this processors TSS */
> mov ebp, [ebx+KPCR_TSS]
>
> @@ -158,12 +166,17 @@
>
> jnz NoAdjust
>
The compare operation uses eax which points to the thread we will switch
to. We must use the trap frame from the thread we will switch from.
> /* Bias esp */
>
> - //sub dword ptr ss:[ebp+KTSS_ESP0], KTRAP_FRAME_V86_GS - KTRAP_FRAME_SS
>
> + sub eax, KTRAP_FRAME_V86_GS - KTRAP_FRAME_SS
>
Eax points to the wrong stack. See above.
>
> NoAdjust:
>
> - /* Push ESP0 Value */
> - push ss:[ebp+KTSS_ESP0]
>
>
>
> + /* Set new ESP0 */
> + mov [ebp+KTSS_ESP0], eax
>
Now, we are using the wrong kernel stack on the next exception.
- Hartmut
Hi all,
WaxDragon gets this,
(lib/setupapi/devinst.c:3167) Flags 0x800000 ignored
(./lib/advapi32/service/scm.c:2035) dwBufSize: 0
(subsys/system/services/rpcserver.c:1759) ScmrStartServiceW() called
(ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was cf)
Entered debugger on last-chance exception number 14 (Page Fault)
Memory at 0xf000e739 could not be written: Page not present.
kdb:> bt
Eip:
<ntoskrnl.exe:65a69 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))>
Frames:
<ntoskrnl.exe:65d92 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))>
<ntoskrnl.exe:62a1f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))>
<ntoskrnl.exe:64cb1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))>
<00000c33>
kdb:>
I get this,
(lib/ntdll/ldr/utils.c:1190) LdrGetExportByName(): failed to find mxdMessage
(lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'msacm.drv'
(Status c0000135)
(lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'midimap.dr
v' (Status c0000135)
(./subsys/win32k/ntuser/class.c:137) Failed to lookup class atom (ClassName 'SHE
LLDLL_DefView')!
(ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was ec)
Entered debugger on last-chance exception number 14 (Page Fault)
Memory at 0xdeadbeef could not be written: Page not present.
kdb:> bt
Eip:
<ntoskrnl.exe:65aa9 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))>
Frames:
<ntoskrnl.exe:65dd2 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))>
<ntoskrnl.exe:62a5f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))>
<ntoskrnl.exe:64cf1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))>
<00003443>
<00000000>
kdb:>
Second reboot it worked after booting linux than reboot warm, third reboot by power on reset,
(ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was ee)
Entered debugger on last-chance exception number 14 (Page Fault)
Memory at 0xdeadbeef could not be written: Page not present.
kdb:> bt
Eip:
<ntoskrnl.exe:65aa9 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))>
Frames:
<ntoskrnl.exe:65dd2 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))>
<ntoskrnl.exe:62a5f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))>
<ntoskrnl.exe:64cf1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))>
<00002eee>
<00000000>
kdb:>
I can repeat this over and over with real hardware,
Thanks,
James
Hey everyone, just a quick question.
Does anyone know of an existing application that will accept a bunch
of header files as input and output a list of function prototypes? It
would really help with my code auditing as I'm spending a long time
assembling them by hand and it takes a long while.
Cheers,
Martin
weiden(a)svn.reactos.org wrote:
> disable starting lsass.exe for now
It seems that rpcrt4.dll has a bug that massively leaks threads in an
rpc server. It seems that it leaks one thread per request.
- Thomas
Hello Ged,
> some new toolbar icons
>
> Updated files:
> trunk/reactos/subsys/system/explorer/res/toolbar.bmp
Please use only toolbar bitmaps with 15 pixels height, not 16 !
Regards,
Martin
Hi,
Does somebody see this error?
- Hartmut
gcc -c hal\halx86\mp\processor_mp.c -o
.\up\obj-i386\hal\halx86\mp\processor_mp.o -Ihal\halx86\include
-Intoskrnl\include -D_DISABLE_TIDENTSSMP -D_NTHAL_ -D__USE_W32API -I.
-Iinclude -Iinclude\reactos -Iinclude\libs -Iinclude\drivers
-Iinclude\subsys -Iinclude\ndk -Iw32api\includ\include\crt
-Iw32api\include\ddk -D_M_IX86 -D_X86_ -D__i386__ -D_REACTOS_ -DDBG
-DKDBG -Wall -Wno-strict-aliasing -ftracer
-momit-leaf-fram-mpreferred-stack-boundary=2 -Wpointer-arith -g -pipe
-Werror -D_SEH_NO_NATIVE_NLG
hal\halx86\mp\mpconfig.c: In function `HaliScanForMPConfigTable':
hal\halx86\mp\mpconfig.c:563: internal compiler error: in
cfg_layout_merge_blocks, at cfgrtl.c:2631
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
_make: *** [.\up\obj-i386\hal\halx86\mp\mpconfig.o] Error 1
_make: *** Waiting for unfinished jobs....
gcc (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Hi all,
I think this is important to share to the discussion. From one of the developers
with FreeDOS, Eric Auer.
Thanks,
James
-------- Original Message --------
Subject: [Freedos-user] re: FAT and other file systems
Date: Fri, 13 Jan 2006 17:16:34 +0100 (MET)
From: Eric Auer <eric(a)coli.uni-sb.de>
Reply-To: freedos-user(a)lists.sourceforge.net
To: freedos-user(a)lists.sourceforge.net
Hi James,
> > And I think it is not more difficult to write HFS or FFS in the kernel
> > of FreeDOS than ReiserFS or XFS or all the other candidates.
I would like to comment this as follows: The Linux kernel modules for
ext3+jbd take 131+59k of memory. Reiserfs takes 243k (243*1000 bytes,
too lazy to convert to units of 1024 bytes). On the other hand, FAT
core takes 38k and you use it with either MSDOS (8k) or VFAT (13k)
implementations. Only the VFAT (long file name enabled) module of
Linux is affected by the 3 MS patents mentioned on the MS homepage.
> There is no way around this, unless someone will write a disclaimer, "Before
> you install FreeDos, do you want to enable Fat32 Patented Features"?
Microsoft WANTS you to believe that they patented FAT32.
Actually they patented their clever but twisted way to store
short and long filenames in the same directory, in a way which
allows LFN-unaware operating systems to use the drive without
getting confused by the LFN data and usually also without
damaging the LFN data either. But you already point that out yourself:
> We are
> facing the same issue with Ros. When I use FreeDos, I use the basic 8.3
> file system, so I don't see that as a major problem. The point here is the
> patent is about LFN, basic 8.3 is not effected.
So the disclaimer would only be displayed when you install the DOSLFN
package: "Install DOSLFN, which might have patent issues?". FreeDOS as
a DOS operating system itself is not affected by that problem. Plus
MS does have a disclaimer about their licensing, too:
http://www.microsoft.com/whdc/hwdev/download/hardware/fatgen103.pdf
which is more than 5 years old by now...
allows you to be compatible to all their FAT (including LFN) stuff
for the purpose of booting, OS installation, diagnosis, firmware,
similar things. They also tell that making/installing operating
systems may use all aspects of FAT. You could see this in a pessimist
way (you are allowed to develop and compile your OS on a LFN enabled
host system) or in a more optimistic way (your operating system
itself is allowed to use LFN because it simply is an operating system).
MS is targetting two groups at the moment: Vendors of USB sticks who
preinstall files on their sticks, and vendors of cams and mp3 players
and similar devices. FreeDOS is neither of those. But I did notice
that my hardware mp3 player does not support LFN. It only shows the
id3 text, if available, as "long song name", and is limited to
showing the SHORT file name as song name otherwise. Looks like
the vendor of the player did not want to pay MS for each device.
Digicams have similar issues - they usually generate filenames
like dsc0815 dot jpg and store all extra "title/name" information
inside the file (jpeg comment, EXIF data...?).
Eric
PS: I assume that you mean ReactOS, the free open WinNT clone,
when you mention Ros. ReactOS without LFN would not be the same...
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Freedos-user mailing list
Freedos-user(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
I'm reading reports of a US patent on FAT.
What's going on and how will this effect us?
The US patent rules are seriously out of control :(
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
Another twist in the tale :
http://www.linux-watch.com/news/NS2809681376.html
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
Hi,
I have manually made a compilation unit and a patch with a 1 line diff
for uuid+shell32 and took my build from 30+ secs down to 9 on gcc.
Alex reported a drop from 22 to 1 on msvc. We need to create a master
source file for each Wine dll like the one attached and add some hacks
for the errors that popup. I have not tested the resulting shell32.dll
but it should work the same. I do not think we can automate generation
of the compilation unit sources for the Wine code due to the hacks we
will need to add like in the attached file.
--
Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi,
I'm not able to install ros from the current trunk on real hardware. At
the end of the second stage setup I see a reset, which seems to be a
triple fault. After the reset, I'm again on the second stage setup.
- Hartmut
Hi,
After applying my user-mode callback patch, I sometimes see a bugcheck
caused by my debugging code. It seems that we do user-mode callbacks
with Kernel APCs disabled (just like we also did them with PreviousMode
== KernelMode, thank God that I had to "break" HEAD to find this huge
bug... but that's another story). The old code "worked" because it did
not check for this serious mistake. Normally, I've noticed that messages
are sent through co_IntSendMessage which is called with KernelApcDisable
== -1. That function calls some unlocking functions and then does the
Callback, which is called with KernelApcDisable == 0, which is good.
However, co_IntSendMessage is sometimes being called from
co_MsqPeekHardwareMessage.
DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable);
WaitObjects[1] = MessageQueue->NewMessages;
WaitObjects[0] = &HardwareMessageQueueLock;
do
{
UserLeaveCo();
WaitStatus = KeWaitForMultipleObjects(2, WaitObjects, WaitAny,
UserRequest,
UserMode, FALSE, NULL, NULL);
UserEnterCo();
DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable);
while (co_MsqDispatchOneSentMessage(MessageQueue))
{
DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable);
}
DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable);
}
while (NT_SUCCESS(WaitStatus) && STATUS_WAIT_0 != WaitStatus);
In this loop, the first KernelApcState is -1. After the wait, it becomes
-2. Now normally there is nothing to dispatch, so the function
continues, and the -2 later becomes a -3 after another lock, then
gradually goes down to -2, then back to -1. So the function enters with
-1 and exits with -1, which is normal. However, if the Message Queue
*does* have a message on it, then co_MsqDispatchOneSentMessage ends up
being called. Remember that after the wait we're now at -2. So that
function will then call co_IntSendMessage at -2, which will lower ir it
to -1 before the callback. But now the callback runs at -1, which means
Kernel APCs are disabled... so we bugcheck.
I have absolutely NO knowledge of Win32k Message Queues/MesssageSending,
but something defintely seems wrong to me here...can anyone help please?
Best regards,
Alex Ionescu
hbirr(a)svn.reactos.org wrote:
> - We cannot access the OwnerTable without locking the resource.
> - The shared waiters may wait also on the semaphore. It makes no sense to boost a waiting thread.
> - The thread header is initialized like KeWaitForSingleObject (?, ?, ?, TRUE, ?). During the boost,
> possible the dispatcher lock is released but the thread block (WaitNext) isn't changed.
>
>
>
> Updated files:
> trunk/reactos/ntoskrnl/ex/resource.c
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-svn
>
>
Oops, I've copied the wrong commit message. The correct is:
- We cannot access the OnerTable without locking the resource.
- The shared waiters may wait also on the semaphore. It makes no sence
to boost a waiting thread.
- The thread header is initialized like KeWaitForSingleObject (?, ?, ?,
TRUE, ?). During the boost,
possible the dispatcher lock is released but the thread block
(WaitNext) isn't changed.
- Hartmut
Hi all,
With real hardware and revision 20802, At the end of first stage and after hitting
the Finish button, I can reproduce this every time too,
KeBugCheck at ./ntoskrnl/mm/marea.c:901
A problem has been detected and ReactOS has been shut down to prevent damage to
your computer.
Technical information:
*** STOP: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000)
Frames:
<ntoskrnl.exe:1676 (./ntoskrnl/ke/bug.c:483 (KeBugCheckEx))>
<ntoskrnl.exe:168d (./ntoskrnl/ke/bug.c:504 (KeBugCheck))>
<ntoskrnl.exe:4342b (./ntoskrnl/mm/marea.c:0 ())>
<ntoskrnl.exe:434c4 (./ntoskrnl/mm/process.c:0 ())>
<ntoskrnl.exe:55c12 (./ntoskrnl/ps/kill.c:200 (PspDeleteThread))>
<ntoskrnl.exe:50cdd (./ntoskrnl/ob/object.c:0 ())>
<ntoskrnl.exe:518ce (./ntoskrnl/ob/handle.c:254 (ObpDeleteHandle))>
<ntoskrnl.exe:51a0b (./ntoskrnl/ob/handle.c:1112 (NtClose))>
<ntoskrnl.exe:6440c (ntoskrnl/ke/i386/syscall.S:372 (KiSystemService))>
<KERNEL32.dll:a697 (./lib/kernel32/misc/handle.c:0 ())>
Entered debugger on embedded INT3 at 0x0008:0x80073b86.
kdb:> bt
Eip:
<ntoskrnl.exe:73b87 (lib/rtl/i386/debug_asm.S:28 (DbgBreakPointWithStatus))>
Frames:
<ntoskrnl.exe:1676 (./ntoskrnl/ke/bug.c:483 (KeBugCheckEx))>
<ntoskrnl.exe:168d (./ntoskrnl/ke/bug.c:504 (KeBugCheck))>
<ntoskrnl.exe:4342b (./ntoskrnl/mm/marea.c:0 ())>
<ntoskrnl.exe:434c4 (./ntoskrnl/mm/process.c:0 ())>
<ntoskrnl.exe:55c12 (./ntoskrnl/ps/kill.c:200 (PspDeleteThread))>
<ntoskrnl.exe:50cdd (./ntoskrnl/ob/object.c:0 ())>
<ntoskrnl.exe:518ce (./ntoskrnl/ob/handle.c:254 (ObpDeleteHandle))>
<ntoskrnl.exe:51a0b (./ntoskrnl/ob/handle.c:1112 (NtClose))>
<ntoskrnl.exe:6440c (ntoskrnl/ke/i386/syscall.S:372 (KiSystemService))>
<KERNEL32.dll:a697 (./lib/kernel32/misc/handle.c:0 ())>
<winlogon.exe:1ae2>
<winlogon.exe:20f6>
<winlogon.exe:339a>
<winlogon.exe:11e7>
<winlogon.exe:1258>
<00000000>
kdb:>
I go into ntoskrnl/mm/marea.c and at line 891 I change DPRINT to DPRINT1, now
the system reboots and runs normal. I even have Abiword running with Winefile.
Thanks,
James
hbirr(a)svn.reactos.org wrote:
> if (!Resource->ActiveCount)
> {
>
>
>- /* Nobody owns it, so let's take control */
>
>
>+ if (Resource->NumberOfSharedWaiters == 0)
>+ {
>+ Owner = &Resource->OwnerThreads[1];
>+ }
>+ else
>+ {
>+ /* Find a free entry */
>+ Owner = ExpFindFreeEntry(Resource, &OldIrql);
>+ if (!Owner) goto TryAcquire;
>+ }
>+
>+ Owner->OwnerThread = Thread;
>+ Owner->OwnerCount = 1;
>
>
> Resource->ActiveCount = 1;
>
>
>- Resource->OwnerThreads[1].OwnerThread = Thread;
>- Resource->OwnerThreads[1].OwnerCount = 1;
>
>
>
> /* Release the lock and return */
> ExReleaseResourceLock(&Resource->SpinLock, OldIrql);
>
>
This change makes no sense. Note that we check for
!Resource->ActiveCount. This, by definition implies that there CANNOT be
any exclusive owner or shared owner. Access to the resource should be
granted instanteously.
Best regards,
Alex Ionescu