the 4Front licensing FAQ about the GPLd version seems questionable...
On 9/22/07, reactos-development(a)silverblade.co.uk <
reactos-development(a)silverblade.co.uk> wrote:
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
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev