--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
> [ ] Yes, allow 3rd-party distribution of the OS through the #ros-xdcc
> channel and ROS-XDCC-001 bot. (support and encourage this distribution)
>
> [X] Yes, allow 3rd-party distribution of the OS, but it must clearly
> distance itself from officially supported releases (tolerate but do not
> support this distribution)
Yes but only if they are using a binary published by reactos.org or a core ReactOS developer such
as Thomas's nightly builds. If they are not doing so then my vote is no. At the first offence we
should warn them and then at the 2nd offence we should deny the use of the ReactOS name
> [ ] No, only sourceforge and other official ReactOS distribution points
> should be used.
We cannot stop distrabution of the OS. Only the use of the name.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
Hi Royce,
royce(a)svn.reactos.com wrote:
> -Wall -Werror and fix warnings
>
>
> Updated files:
> trunk/reactos/tools/widl/Makefile
> trunk/reactos/tools/widl/hash.c
> trunk/reactos/tools/widl/write_msft.c
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
More crazy Linux port problems, in /reactos/tools/widl,
write_msft.c: In function `ctl2_write_chunk':
write_msft.c:2189: warning: implicit declaration of function `write'
write_msft.c:2190: warning: implicit declaration of function `close'
write_msft.c: In function `save_all_changes':
write_msft.c:2284: warning: implicit declaration of function `creat'
make: *** [write_msft.o] Error 1
It works when removing -Werror -Wall from the Makefile. BTW io.h
is in the /usr/mingw32/include directory.
Thanks,
James
hbirr(a)svn.reactos.com wrote:
>Use only one access to the spinlock in the assertion, because the value may change between two access' on smp machines.
>
>
You implementation is better, no doubt, but it wouldn't have mattered to
read it twice or more. I mean, it's re-read again down in the
InterlockedExchange call, there's a possibility it might have been
changed in the meantime as well. But it really wouldn't matter ;)
Best Regards,
Thomas
Hello,
Retransmission of this message sent to Harmut , to Ros-Dev list
following error in the mail address of Ros list
---------------------------------------------
Harmut ,
I do not know if this commit is related to the Bug #512 ( Colinux fails
to load in MM/MDL ) but more debug messages are displayed now.
I have updated Bugzilla with these debug messages.
Best regards
Gerard
Subject:
[ros-svn] [hbirr] 13963: Lock the kernel address space instead the
process' one, if the pages are located in kernel space.
From:
<hbirr(a)svn.reactos.com>
Date:
Sat, 12 Mar 2005 10:14:38 +0100
To:
<ros-svn(a)reactos.com>
Lock the kernel address space instead the process' one, if the pages are
located in kernel space.
Unlock the address space on error.
Hi,
--- Eric Kohl <eric.kohl(a)t-online.de> wrote:
> I read the wine-devel list archive a few days ago and relized that
> Alexandre rejected the last patch. I want to split the last patch into
> more 'atomic' parts tomorrow. Is that OK?
Sure thats what I was going to do next. I am going through SVN right now and extracting each
atomic commit and manually applying them to my winehq tree. I can send each patch from each atomic
commit but its going to take me quite a while to resolve conflicts.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
weiden(a)svn.reactos.com wrote:
>Thomas Weidenmueller <w3seek(a)reactos.com>
>- Fix various security structures and constants
>- Add code to capture quality of service structures and ACLs
>- Secure buffer access in NtQueryInformationToken, NtSetInformationToken, NtNotifyChangeDirectoryFile and NtQueryDirectoryFile
>
>
For the sake of review/auditing, it should be important to mention this
is yet-another-alex_devel_branch-merge. Thomas wrote 100% of it, I'm
just mentionning this as a progress report and historical/bookkeeping
reason.
Best regards,
Alex Ionescu
To clarify i mean OS X and perhaps even os 9. I know about darwin but i was wondering if there was an os x clone out there. Reactos is a version of windows as this clone will be an open-source version of os x or os 9.
>
> From: "Klemens Friedl" <klemens_friedl(a)gmx.net>
> Date: 2005/03/12 Sat AM 10:42:17 EST
> To: ReactOS Development List <ros-dev(a)reactos.com>
> Subject: Re: [ros-dev] Mac OS X clone???
>
> > I was wondering if there was a project that would be doing a binary
> > compatible OS X system. What reactos does for windows maybe this project
> can do
> > for OS X. I was just wondering. I know that pearpc emulates a ppc
> processor,
> > but wether or not a full os exists is the question. I know also that some
> > versions of linux exist for ppc.
>
> Do you mean MacOS X?
>
> Darwin has been the open-source OS technology underlying Apple's Mac OS X
> operating system, with all development being managed and hosted by Apple:
> -> http://developer.apple.com/darwin/
> -> http://www.opendarwin.org/
>
>
>
> -- Klemens Friedl
>
> --
> SMS bei wichtigen e-mails und Ihre Gedanken sind frei ...
> Alle Infos zur SMS-Benachrichtigung: http://www.gmx.net/de/go/sms
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
>
Hi Eric,
How much more work is going to be needed in WIDL? There are quite a lot of changes and I have
fallen behind on merging to Winehq.
Thanks
Steven
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
> >
> > [ ] Yes, do allow miscelanea branches
> >
> > [ ] No, don't allow miscelanea branches
> >
> > [X] Clearly define feature vs mscelanea branches.
I don't mind Alex having a remote branch to be able to maintain
a public backup of his work. In fact I think all of the ReactOS
developers should have public branches but I think that anytime
a feature is implemented in a remote branch and another developer
is blocked by said feature then the remote branch has to be merged
with the trunk. For people like me that contribute little or no code
other than minor bugfixes this may be overkill.
This whole problem is that much of the development switched to his branch
when it should have been merged to the trunk. Alex has admitted this and I
think we have reached a middle ground.
Thanks
Steven
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs