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