Re: #1 winhttp: Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
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 find an app that depends on winhttp specific behavior of callbacks. It'd be not only an ugly hack, but also unneeded code complication. Jacek
Re: #1 winhttp: Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
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 INTERNET_OPTION_CALLBACK_WINHTTP if we find an app that depends on winhttp specific behavior of callbacks. It'd be not only an ugly hack, but also unneeded code complication. Alright then. The pretty solution IMHO, is to create a third DLL, which both wininet and winhttp use. (Derive from.) That's how you usually refactor code. regards, Jakob
Re: #1 winhttp: Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
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: ret =
HTTP_QUERY_CONTENT_TYPE; break;
...
+switch (option)
+{
+case WINHTTP_OPTION_CALLBACK: opt =
INTERNET_OPTION_CALLBACK; break;
+case WINHTTP_OPTION_CONNECT_TIMEOUT:opt =
INTERNET_OPTION_CONNECT_TIMEOUT; break;
Probably a simple lookup table for both mappings above is enough since
WINHTTP_QUERY_xxx and WINHTTP_OPTION_xxx values a sequential (perhaps
excepting some reserved/undocumented ones).
--
Dmitry.
Re: #1 winhttp: Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
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 functionality you have implemented. I haven't seen a convincing argument for code duplication yet. 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 find an app that depends on winhttp specific behavior of callbacks. -Hans
Re: #1 winhttp: Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
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 top of wininet functions.
There are also issues with different error codes being returned as well
as different callbacks
(http://msdn2.microsoft.com/en-us/library/aa383917.aspx).
--
Rob Shearman
Re: #1 winhttp: Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
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? Could it not add the required headers to the request? There are also issues with different error codes being returned as well as different callbacks (http://msdn2.microsoft.com/en-us/library/aa383917.aspx). Well, error codes can be translated in wrappers and WINHTTP_STATUS_CALLBACK has the same prototype as INTERNET_STATUS_CALLBACK, although it's not called for the same set of events. 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. -Hans
Re: #1 winhttp: Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
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 the remaining 5% of winhttp, we'll have to reimplement it properly, what will be a real pain. 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 functionality you have implemented. Jacek
