Hans Leidekker wrote:
I haven't seen a convincing argument for code duplication yet.
Then why do you want to add hacks instead of proper implementation?
We may
even be able to achieve 100% by extending wininet a bit. E.g. we could
add a Wine internal INTERNET_OPTION_CALLBACK_WINHTTP if we
Jacek Caban wrote:
Hans Leidekker wrote:
I haven't seen a convincing argument for code duplication yet.
Then why do you want to add hacks instead of proper implementation?
We may
even be able to achieve 100% by extending wininet a bit. E.g. we could
add a Wine internal
Hans Leidekker [EMAIL PROTECTED] wrote:
+static DWORD map_info_level(DWORD level)
+{
+DWORD ret = 0;
+
+switch (level QUERY_HEADER_MASK)
+{
+case WINHTTP_QUERY_MIME_VERSION: ret =
HTTP_QUERY_MIME_VERSION; break;
+case WINHTTP_QUERY_CONTENT_TYPE:
On Thursday 02 August 2007, Jacek Caban wrote:
I agree that such a big code duplication is ugly, but that's the
way to go. We may separate the common code to different files in wininet
and keep them in sync with winhttp. This way it shouldn't be too hard to
implement most of the
Hans Leidekker wrote:
Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
We shouldn't be implementing winhttp on top of wininet as there are
functions such as WinHttpSetCredentials
(http://msdn2.microsoft.com/en-us/library/Aa384112.aspx) that can't be
implemented
On Thursday 02 August 2007 20:19:52 Robert Shearman wrote:
We shouldn't be implementing winhttp on top of wininet as there are
functions such as WinHttpSetCredentials
(http://msdn2.microsoft.com/en-us/library/Aa384112.aspx) that can't be
implemented on top of wininet functions.
Why not?
Hans Leidekker wrote:
We should be able to implement more than 95% of this dll by wrapping/forwarding
to wininet. That's better than many other dlls in Wine and we're already seeing
regressions in apps trying to use our stub winhttp.
And when we'll find an app (I'm sure we will) that uses
