New subject: Open Sound System porting

22 Sep 2007

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 &lt;aleksey(a)reactos.org&gt; 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