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).
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
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
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
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
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
On Monday 06 August 2007 20:08:44 Jacek Caban wrote:
Then why do you want to add hacks instead of proper implementation?
Have a look at the attached snapshot of my work on winhttp. It includes an implementation of WinHttpSetCredentials (basic authentication only for now) and tests to show that it works. It duplicates a minimal amount of code from wininet (HTTP_EncodeBase64 basically, which is already duplicated in Wine). The implementation depends on a bugfix in wininet which is included as well, with a test of course.
It'd be not only an ugly hack, but also unneeded code complication.
Please be more specific than that.
-Hans
"Hans Leidekker" hans@it.vu.nl 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 Timoshkov -
Hans Leidekker -
Jacek Caban -
Jakob Eriksson -
Robert Shearman