"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:
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
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
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 functi
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 th
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:
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
