Two answers/questions from yesterdays and todays digests
bob at yarrabee.net.au
Thu Nov 8 02:20:36 CST 2001
>Date: Tue, 06 Nov 2001 12:53:56 -0500
>From: Roger Fujii <rmf at lookhere.com>
>To: wine-devel at winehq.com
>Subject: queries on internals....
>ok... getting reasonable output, but now I have some
>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 at rhlx01.fht-esslingen.de>
> To: Francois Gouget <fgouget at free.fr>
> Cc: Martin Wilck <Martin.Wilck at fujitsu-siemens.com>,
> wine-devel mailing list <wine-devel at winehq.com>
> Subject: Re: [EXPERIMENTAL PATCH]: Winsock2
> Reply-To: andi at 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
More information about the wine-devel