Hi Juan,
--- Juan Lang <[EMAIL PROTECTED]> wrote:
> Yep, in fact the "real" way to do this as far as Wine
> is concerned is to implement SSL in secur32.dll, since
> this is where Windows does it. It looks about like
> this, although as Geoff pointed out to me the API is a
> bit broken. Doing a BI
> Geoff wrote:
> > Or we write our own BIO that wraps up whatever
> > glue is desirable on the wine-side. Worst-case
> > (and it's not that bad an alternative) is that
> > you use a memory-base BIO to encapsulate all I/O
> > and worry about moving data to and from "sockets",
> > whatever they look
Geoff wrote:
Or we write our own BIO that wraps up whatever glue is desirable on the
wine-side. Worst-case (and it's not that bad an alternative) is that you
use a memory-base BIO to encapsulate all I/O and worry about moving data
to and from "sockets", whatever they look like, afterwards.
That'
On April 5, 2004 05:38 pm, Juan Lang wrote:
> I'd be rather nervous about the mixing of OpenSSL with
> the use of Winsock, at least as is. OpenSSL is itself
> using socket read/write calls, and it expects them to
> be the correct ones: in particular, the UNIX ones.
>
> I believe the only way to d
Hans wrote:
> On Monday 05 April 2004 19:24, Alexandre Julliard
> wrote:
> > There's no real reason that we cannot use Unix
> > sockets on Unix and Windows socket on Reactos with
> > the same code, it just needs a bit of header
magic;
> > and this will be useful for Winelib apps too.
>
> Hmm, I'd
On Monday 05 April 2004 19:24, Alexandre Julliard wrote:
> There's no real reason that we cannot use Unix sockets on Unix and
> Windows socket on Reactos with the same code, it just needs a bit of
> header magic; and this will be useful for Winelib apps too.
Hmm, I'd like to agree with that.
> Y
Hans Leidekker <[EMAIL PROTECTED]> writes:
> So, is this a problem? Depends on what's important to you, but I'd
> argue that it's more important for Wine to open up wininet (and
> consequently winsock) to more users and developers. That may eventually
> attract more developers to fix bugs or even
Hi,
I hope that we use Han's patch. It's going to make it easier to
implement thread safety (as we can use WaitForMultipleObjects on the
handles) and will make porting easier for Reactos.
IMO, wininet is not really performance critical, and we can probably
improve things in the winsock layer a
On April 5, 2004 1:57 pm, Mike McCormack wrote:
> IMO, wininet is not really performance critical, and we can probably
> improve things in the winsock layer a bit too.
I second that. Moreover, it seems that it's not that much of a performance
hit (as experienced by the user, 4.1s vs. 4.2s), but ra
On Monday 05 April 2004 05:21, Dimitrie O. Paun wrote:
> > Use #ifdef stuff so that when building on WINE, it uses unix sockets.
>
> We have to be smart about this, having #ifdefs all over the file
> is not acceptable. But from the look of the patch that was just
> posted, it certainly looks like
On April 4, 2004 10:18 pm, Jonathan Wilson wrote:
> Use #ifdef stuff so that when building on WINE, it uses unix sockets.
We have to be smart about this, having #ifdefs all over the file
is not acceptable. But from the look of the patch that was just
posted, it certainly looks like we can achieve
How about this.
Use #ifdef stuff so that when building on WINE, it uses unix sockets.
But when building on win32 (which would include MingW and ReactOS), it uses
winsock.
Hello Hans,
--- Hans Leidekker <[EMAIL PROTECTED]> wrote:
>
> This makes wininet build on MinGW.
>
> Changelog:
> Move to Windows sockets.
>
I asked Alexandre about a patch to move Wininet to Winsock and he said
it took to much of a performance hit to merge. Is there a way we can
bench mark i
13 matches
Mail list logo
