On 9/22/07, reactos-development@silverblade.co.uk <reactos-development@silverblade.co.uk> wrote:

4Front.

Apparently it's "better".

Original Message:
-----------------
From: King InuYasha ngompa13@gmail.com
Date: Sat, 22 Sep 2007 16:32:11 -0500
To: reactos-development@silverblade.co.uk, ros-dev@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@silverblade.co.uk <
reactos-development@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@gmail.com
> Date: Sat, 22 Sep 2007 10:28:50 -0500
> To: ros-dev@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@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@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@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@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev