Hello,
I'd just like to do a remark about ReactOS apps, dlls, which be translated. When a dev change something to the interface, or the core app, it could be great to update EVERY language file (*.rc) and not only some of them (or even worse : only english one). It does not take many times to do (I know because I've already done that), and for a translator that's quite easier to see what has changed without having to compare his language file and the english one. And most of all, it avoids uncomplete, or outdated language files. Finally, for end-user, that's better : that's even better to have English string instead of nothing (I mean blank string).
Thanks,
Pierre Schweitzer, French Language Maintainer
On Sep 22, 2007, at 10:19 PM, João Jerónimo wrote:
> The point of a possible 3rd party audit is raising the legal
> credibility of
> the ReactOS project by ensuring that no tainted code is left in the
> source
> tree, right?
The word "tainted" is actually quite wrong, and is being misused
everywhere.
A tea was tainted by polonium in a not-so-recent accident in the UK.
ReactOS is not a tea, and we have no "polonium" commiters.
There will be a WineConf event in 1 or 2 weeks, and they say they are
going to clear up the legal situation around Wine, around SFLC audit
and around requirements to the developers, whose code may be commited
to the tree.
When they do it, I would be very glad to know those requirements, and
enforce them on ReactOS developers, so that we are on the common ground.
>
> Well, if the project is going to wait until more modules stabilize,
> won't
> this stabilization process obfuscate most of the tainted source
> code, and
> make them hard to find?
Your mind is ahead of you. "Taint obfuscated code", "Obfuscate
tainted code", ...
Your question is obfuscated and may be tainted, I won't answer it.
WBR,
Aleksey Bragin.
Please stop rumouring this topic. I clearly said "if there are strong
circumstances, in future, only then we will think about doing 3rd
party audit, and only from agreement of all devs". That's 3 or 4
years away from now, if such legal problems ever happen.
Also noone ever said SFLC is taking up copyrights to themselves. At
least it's first time I hear this.
I just grepped Wine source code base for word "SFLC" - doesn't appear
anywhere. Also, open up any of Wine's source code file, you'll see
"Copyright 200x Person's Name".
And again, I didn't suggest SFLC or FSF or whoever. Time will show
who and if we need, and who and if agrees to.
WBR,
Aleksey Bragin.
On Sep 24, 2007, at 2:58 PM, Magnus Olsen wrote:
> It seam u fall into he SFLC traps they are trying push doing the
> audlt of
> ros from a 3 part project
> of ros, and we shall obay theirs rules it mean all api that is not
> document
> in msdn shall be remove
> and so on. That mean 80% of ntoskrnl will go away, for around 80% of
> ntoskrnl are not in msdn
> 80% of win32k will go aways, for thuse api are not in msdn, then
> shall we
> not talk about audio
> no audio system and so on.
>
> that mean no ros, if we play after SLFC and we need also write
> papper give
> up our copyright to
> them. no thanks
Well-well, please calm down, we had enough flamewars, a new one is
not necessary.
No decisions are made, and no decisions are going to be made without
agreement with all our developers.
WBR,
Aleksey Bragin.
On Sep 23, 2007, at 3:40 PM, Ged wrote:
> James Tabor wrote:
>>
>> Wine is the Pot calling the kettle BLACK! Bunch of RE coders using
>> smoke and
>> mirrors when it comes to case testing! It's a easy out!
>>
>
> I agree with Aleksey, we must adopt their way of working in the
> hope of
> rebuilding the bridges and additionally improving our credability
> within
> the open source world. If this means offering ourselves to an external
> audit, then so be it. We can't be a hobbiest project forever if we aim
> to bring ReactOS to the public sector as a viable alternative to
> Windows.
>
>
> Ged.
Thanks for all the replies so far.
I find it quite insane that MSDN compares ioctl to DeviceIoControl. Whilst
they achieve
the same results, the actual parameters used etc. are entirely different.
I'm not sure if Steven's suggestion would work (ie, use ws2_32) since, to
my knowledge,
that particular implementation is specific to sockets.
Probably the best way around this then, would be to make an ioctl wrapper
that takes the
OSS-specific IOCTL codes, and translates them into custom NT IOCTL codes.
The wrapper
would take things like structures being passed via the ioctl and send them
via
DeviceIoControl instead.
It does seem like a fair amount of work but if an appropriate "wrapper" is
created, it
could work...
Original Message:
-----------------
From: King InuYasha ngompa13(a)gmail.com
Date: Sat, 22 Sep 2007 10:28:50 -0500
To: ros-dev(a)reactos.org
Subject: Re: [ros-dev] Open Sound System porting
Couldn't the source be patched to use DeviceIOControl instead of ioctl?
According to MSDN about porting from UNIX to Win32, ioctl maps directly to
DeviceIOControl, so it could be possible to simply change all the instances
of ioctl to DeviceIOControl...
On 9/22/07, Aleksey Bragin <aleksey(a)reactos.org> wrote:
>
> I didn't thoroughly look through the OSS source code, but if it has
> some kind of platform-independent design in mind, then I would really
> recommend porting, and porting with as minimal changes to the
> original source code required (you probably are going to need a
> wrapper-library, for ioctls at least, plus NT-specific parts).
>
> I may help too, because of the usb stack wrapping I did a while ago.
>
>
> WBR,
> Aleksey Bragin.
>
> >
> > I've been in touch with the guy that ported OSS to Haiku (open-
> > source BeOS)
> > after some
> > discussion with the folks over at #winehackers to get some help
> > with audio
> > development.
> >
> > Anyway, basically the idea so far is to use OSS as a "fall-back" audio
> > driver
> > implementation. So unless there is a "better" driver installed (ie an
> > official one for
> > an audio device), ReactOS can use an Open Sound System driver instead.
> >
> > The result? There will at least be sound functionality.
> >
> > OSS is designed to be mostly platform-independent. By rewriting a
> > few of
> > the core
> > modules, the entire set of drivers will be able to work with whatever
> > platform you
> > desire.
> >
> > This can be implemented on top of the existing MME API architecture
> > for the
> > moment, and
> > can later be translated to use the WDM audio framework.
> >
> > Anyway, having stuck the OSS code into my local ReactOS source
> > tree, I'm
> > trying to
> > figure out how to get it to compile using rbuild. The first hurdle
> > I have
> > come across is
> > that there is extensive use of ioctl. Indeed it seems that most
> > ports of
> > OSS work on
> > platforms based on Posix (Unix?)
> >
> > So my main question at this time is how to handle this? The calls in
> > question appear to
> > be documented inside a file called "soundcard.h" in the OSS sources
> > however
> > this just
> > seems to be definitions for the ioctl codes. So I suspect a
> > majority of the
> > drivers are
> > calling ioctl.
> >
> > Therefore, I figure the best way around this is probably to provide
> > a fake
> > ioctl that
> > provides the expected functionality, and make this wrap
> > DeviceIoControl
> > with something
> > that can translate the ioctl parameters into whatever...
> >
> > The only other way I see around this is to rewrite all calls to
> > ioctl, and
> > rewrite the
> > IOCTL codes with NT-style ones.
> >
> > Thoughts/ideas?
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
--------------------------------------------------------------------
mail2web.com What can On Demand Business Solutions do for you?
http://link.mail2web.com/Business/SharePoint
4Front.
Apparently it's "better".
Original Message:
-----------------
From: King InuYasha ngompa13(a)gmail.com
Date: Sat, 22 Sep 2007 16:32:11 -0500
To: reactos-development(a)silverblade.co.uk, ros-dev(a)reactos.org
Subject: Re: [ros-dev] Open Sound System porting
Which OSS implementation are you looking at? The OSS/Free one, or the OSS
one from 4Front?
On 9/22/07, reactos-development(a)silverblade.co.uk <
reactos-development(a)silverblade.co.uk> wrote:
>
> Thanks for all the replies so far.
>
> I find it quite insane that MSDN compares ioctl to DeviceIoControl. Whilst
> they achieve
> the same results, the actual parameters used etc. are entirely different.
>
> I'm not sure if Steven's suggestion would work (ie, use ws2_32) since, to
> my knowledge,
> that particular implementation is specific to sockets.
>
> Probably the best way around this then, would be to make an ioctl wrapper
> that takes the
> OSS-specific IOCTL codes, and translates them into custom NT IOCTL codes.
> The wrapper
> would take things like structures being passed via the ioctl and send them
> via
> DeviceIoControl instead.
>
> It does seem like a fair amount of work but if an appropriate "wrapper" is
> created, it
> could work...
>
>
> Original Message:
> -----------------
> From: King InuYasha ngompa13(a)gmail.com
> Date: Sat, 22 Sep 2007 10:28:50 -0500
> To: ros-dev(a)reactos.org
> Subject: Re: [ros-dev] Open Sound System porting
>
>
> Couldn't the source be patched to use DeviceIOControl instead of ioctl?
> According to MSDN about porting from UNIX to Win32, ioctl maps directly to
> DeviceIOControl, so it could be possible to simply change all the
> instances
> of ioctl to DeviceIOControl...
>
> On 9/22/07, Aleksey Bragin <aleksey(a)reactos.org> wrote:
> >
> > I didn't thoroughly look through the OSS source code, but if it has
> > some kind of platform-independent design in mind, then I would really
> > recommend porting, and porting with as minimal changes to the
> > original source code required (you probably are going to need a
> > wrapper-library, for ioctls at least, plus NT-specific parts).
> >
> > I may help too, because of the usb stack wrapping I did a while ago.
> >
> >
> > WBR,
> > Aleksey Bragin.
> >
> > >
> > > I've been in touch with the guy that ported OSS to Haiku (open-
> > > source BeOS)
> > > after some
> > > discussion with the folks over at #winehackers to get some help
> > > with audio
> > > development.
> > >
> > > Anyway, basically the idea so far is to use OSS as a "fall-back" audio
> > > driver
> > > implementation. So unless there is a "better" driver installed (ie an
> > > official one for
> > > an audio device), ReactOS can use an Open Sound System driver instead.
> > >
> > > The result? There will at least be sound functionality.
> > >
> > > OSS is designed to be mostly platform-independent. By rewriting a
> > > few of
> > > the core
> > > modules, the entire set of drivers will be able to work with whatever
> > > platform you
> > > desire.
> > >
> > > This can be implemented on top of the existing MME API architecture
> > > for the
> > > moment, and
> > > can later be translated to use the WDM audio framework.
> > >
> > > Anyway, having stuck the OSS code into my local ReactOS source
> > > tree, I'm
> > > trying to
> > > figure out how to get it to compile using rbuild. The first hurdle
> > > I have
> > > come across is
> > > that there is extensive use of ioctl. Indeed it seems that most
> > > ports of
> > > OSS work on
> > > platforms based on Posix (Unix?)
> > >
> > > So my main question at this time is how to handle this? The calls in
> > > question appear to
> > > be documented inside a file called "soundcard.h" in the OSS sources
> > > however
> > > this just
> > > seems to be definitions for the ioctl codes. So I suspect a
> > > majority of the
> > > drivers are
> > > calling ioctl.
> > >
> > > Therefore, I figure the best way around this is probably to provide
> > > a fake
> > > ioctl that
> > > provides the expected functionality, and make this wrap
> > > DeviceIoControl
> > > with something
> > > that can translate the ioctl parameters into whatever...
> > >
> > > The only other way I see around this is to rewrite all calls to
> > > ioctl, and
> > > rewrite the
> > > IOCTL codes with NT-style ones.
> > >
> > > Thoughts/ideas?
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
>
>
> --------------------------------------------------------------------
> mail2web.com What can On Demand Business Solutions do for you?
> http://link.mail2web.com/Business/SharePoint
>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://link.mail2web.com/mail2web
Hello,
I recently asked Klemens to remove audit progress bar from the
frontpage. Some wonder: why? The simple answer is obvious: Audit
doesn't have anything to do with end-users, testers, or patch-
submitters of the project.
Audit is an effort run by ReactOS Development Team, and has only one
goal: Reduce possible legal problems in future, when, and if, ReactOS
starts to have commercial appliances.
The process with file locking-unlocking is only the top of the
iceberg, there is a huge amount of work to be done in order to
maintain solid legal base for all our code. It can't be measured with
a single progressbar, nor it needs to. It can't be done only with the
help of ReactOS Development Team, a third party code reviewer is a
must. We plan that too, but for later time, when there are more
stable modules in ReactOS.
Legal base consists of a number of factors: authorship and sources of
the code and their legality, availability of documentation for
certain interfaces and algorithms, development of test cases showing
internal behaviour of certain API functions, licensing issues, 3rd
party code reviewing process results, etc, etc, etc.
I think it's rather clear to see that measuring all the above factors
in a single percentage number can't sound serious for a project, nor
can it be a real value of cleannes of the project.
The respective Audit wikipage needs to be updated too WRT this email.
Also please note, our audit process results are fully seen via SVN
commits, so there is no hiding involved.
With the best regards,
Aleksey Bragin.
I didn't thoroughly look through the OSS source code, but if it has
some kind of platform-independent design in mind, then I would really
recommend porting, and porting with as minimal changes to the
original source code required (you probably are going to need a
wrapper-library, for ioctls at least, plus NT-specific parts).
I may help too, because of the usb stack wrapping I did a while ago.
WBR,
Aleksey Bragin.
>
> I've been in touch with the guy that ported OSS to Haiku (open-
> source BeOS)
> after some
> discussion with the folks over at #winehackers to get some help
> with audio
> development.
>
> Anyway, basically the idea so far is to use OSS as a "fall-back" audio
> driver
> implementation. So unless there is a "better" driver installed (ie an
> official one for
> an audio device), ReactOS can use an Open Sound System driver instead.
>
> The result? There will at least be sound functionality.
>
> OSS is designed to be mostly platform-independent. By rewriting a
> few of
> the core
> modules, the entire set of drivers will be able to work with whatever
> platform you
> desire.
>
> This can be implemented on top of the existing MME API architecture
> for the
> moment, and
> can later be translated to use the WDM audio framework.
>
> Anyway, having stuck the OSS code into my local ReactOS source
> tree, I'm
> trying to
> figure out how to get it to compile using rbuild. The first hurdle
> I have
> come across is
> that there is extensive use of ioctl. Indeed it seems that most
> ports of
> OSS work on
> platforms based on Posix (Unix?)
>
> So my main question at this time is how to handle this? The calls in
> question appear to
> be documented inside a file called "soundcard.h" in the OSS sources
> however
> this just
> seems to be definitions for the ioctl codes. So I suspect a
> majority of the
> drivers are
> calling ioctl.
>
> Therefore, I figure the best way around this is probably to provide
> a fake
> ioctl that
> provides the expected functionality, and make this wrap
> DeviceIoControl
> with something
> that can translate the ioctl parameters into whatever...
>
> The only other way I see around this is to rewrite all calls to
> ioctl, and
> rewrite the
> IOCTL codes with NT-style ones.
>
> Thoughts/ideas?
David, what does a kernel-dev have to do with rbuild?
Also, recent massive commits to the rbuild itself, and to
various .rbuild files hardly prove your "rbuild is an umaintained
piece of ... stuff" theory. It's, by the least measure, offensive to
Herve's (and there were a few different patches submitted by various
authors submitted) work he's been doing with rbuild.
Or what is a "maintained rbuild", by your definition? How more should
it be maintained? Note: not improved (we have a number of
improvements pending to be implemented in it), but *maintained*.
Another thing is completely wrong and counter-productive: irc is a
wrong place for such question, since not all devs are there all the
time.
Now, back to the actual question.
The biggest difference between ntoskrnl and HAL is that the first is
as machine-independent as possible (still including some dependent
code, but it's conditionally included), while the latter is actually
very hardware dependent, so it does not make sense to unite x86 and
PowerPC HALs, because they are going to contain just simply different
source code.
With the best regards,
Aleksey Bragin.
On Sep 21, 2007, at 8:11 PM, David Hinz wrote:
>
> Marc Piulachs schrieb:
>> Does anyone agree with me on this? Maybe I’m missing something
>> here but
>> I would like to improve it.
>
> I don't think you will have much luck getting an answer, as afaik
> rbuild
> is currently more or less unmaintained and our kernel-dev left the
> project.
>
> Maybe arty or hpoussin do have an oppinion regarding your question,
> but
> they seem to be rather busy most of the time...
>
> Have you tried asking on irc? Most devs hang out there...
>
> Greets,
>
> David Hinz
