Two answers/questions from yesterdays and todays digests

[Robert Lunnon]

Answers Now...
> Message: 1
> Date: Tue, 06 Nov 2001 12:53:56 -0500
> From: Roger Fujii <rmf(a)lookhere.com>
> To: wine-devel(a)winehq.com
> Subject: queries on internals....
>
> ok...  getting reasonable output, but now I have some
> questions.
>
> First, it seems like wine can't find the audio codecs,
> though it seems to find the video ones.  Is this a
> to-be-implemented or a bug and any clues on where to look?

Is this in Solaris ?, if so you wiould have to have OSS installed and even 
then I am not sure it would work properly. Investigating audio on Solaris I 
found that ACM was not happy unless the audio driver was available and 
installed properly otherwise it returns Device Busy. I  do have a working 
Waveout Solution for native Solaris based on my libaudioio project.  I've not 
tackled Direct Sound or Wavein yet. As yet this solution is not integrated 
with Wines Build environment so you can't set it up with configure. If you 
are prepared to grub through the relevant mods I can send you a patch kit.
> Message: 1
> Date: Wed, 7 Nov 2001 20:50:11 +0100
> From: Andreas Mohr <andi(a)rhlx01.fht-esslingen.de>
> To: Francois Gouget <fgouget(a)free.fr>
> Cc: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com>,
>   wine-devel mailing list <wine-devel(a)winehq.com>
> Subject: Re: [EXPERIMENTAL PATCH]: Winsock2
> Reply-To: andi(a)rhlx01.fht-esslingen.de
>
> On Wed, Nov 07, 2001 at 10:54:02AM -0800, Francois Gouget wrote:
> > * To answer your question:
> >     /* Code copied largely from WSOCK32_accept() */
> >     /* FIXME: Can we simply call WSOCK32_accept() instead ? */
> >     /* I wasn't sure because of the AsyncSelect stuff at the end,
> >        which presumably should only be called if the connection is
> > accepted */
> >
> > Winsock2 should not call the wsock32 library. It should be the
> > opposite. One of the things on my todo list (but whether I will have
> > time to actually do it is another matter) is to reorganize the winsock
> > libraries so that wsock32 and winsock are together in dlls/wsock32. The
> > reason is that they both implement the winsock1 API except one is 16bit
> > and the other 32bits. Then in dlls/winsock we would be left with just
> > ws2_32 which implements the winsock2 API. So having ws2_32 call to
> > wsock32 is not going in the right direction :-)
>
> Hmm ?
> Sorry, but this directory stuff sounds rather dainbread to me.
> IMHO winsock/wsock32 should be in winsock/, and ws2_32 should be in
> winsock2/ Or, maybe even better, use winsock1/ instead of winsock/.
>
> WTH would you want to do it in a different way ?

Whoever is playing with Winsock can you please ensure that the solutions you 
come up with are not linux centric. There is a lot of code in there that does 
not run on solaris because it grubs around in PROC getting TCP structures. I 
have made a bit of a start in cleaning this up, Here it is, absolutely 
untested non working code, but a start nevertheless, I put this into a 
separate file  and link it with winsock and  wsock32  from a common source, 
these functions replace the helper functions of similar name in the two dll 
subdirectories.