July 2011 - Wine-Devel - list.winehq.org

Re: urlmon: Fix various typos/misspellings

by Frédéric Delanoy

2011/7/22 Dan Kegel <dank(a)kegel.com>: > Hi Frédéric, > >>-/* List of 3 character top level domain names Windows seems to recognize. >>+/* List of 3 characters top level domain names Windows seems to recognize. > > That change is incorrect. In English, 'character' should be singular there. > (This occurs twice in your patch.) Interesting. Could you pls give me pointers explaining this peculiar English grammar rule? Frédéric

July 22, 2011

re: urlmon: Fix various typos/misspellings

by Dan Kegel

Hi Frédéric, >-/* List of 3 character top level domain names Windows seems to recognize. >+/* List of 3 characters top level domain names Windows seems to recognize. That change is incorrect. In English, 'character' should be singular there. (This occurs twice in your patch.) The other changes seem ok. - Dan

July 22, 2011

Re: [1/3] configure.ac: fix libpthread detection on Haiku

by André Hentschel

Am 22.07.2011 10:25, schrieb Alexandre Julliard: > Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > >> Changelog: >> * configure.ac: fix libpthread detection on Haiku >> >> Haiku has a single library, libroot.so, for all POSIX functions. There >> is no separate libc, libm, libpthread, etc. > > I'd suggest to file bugs with Haiku, they should provide compatibility > libraries, that stuff is very much standard. > They mark those bugs as invalid: http://dev.haiku-os.org/ticket/3805 There are much more places where you can read they won't add compatibility libraries, one reason is that it's not in the POSIX standard. see also http://ports.haiku-files.org/wiki/CommonProblems -- Best Regards, André Hentschel

July 22, 2011

Re: [PATCH 1/3] programs: Add rule for cross-building modules.

by Octavian Voicu

On Fri, Jul 22, 2011 at 5:55 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > No, it won't work anyway. You'd need to duplicate all the rules for the > test resources too, and I don't want to have to make the build process > even more of a mess. The existing crosstest hacks are already bad > enough. I guess I didn't think of that -- the .res files I used have the normal tests, not the cross-built ones. Sorry for the noise. Octavian

July 22, 2011

Re: [PATCH 1/3] programs: Add rule for cross-building modules.

by Alexandre Julliard

Octavian Voicu <octavian.voicu(a)gmail.com> writes: > I think it is very useful to be able to compile winetest by using make > crosstest, and the fact that notepad also works is just a bonus (you > would have to do make notepad_cross.exe manually anyway). > > Would a specific rule (just for winetest) be better? No, it won't work anyway. You'd need to duplicate all the rules for the test resources too, and I don't want to have to make the build process even more of a mess. The existing crosstest hacks are already bad enough. -- Alexandre Julliard julliard(a)winehq.org

July 22, 2011

Re: [2/3] winhttp: Implement IWinHttpRequest::get_ResponseBody.

by Jacek Caban

On 07/22/11 16:32, Hans Leidekker wrote: > On Fri, 2011-07-22 at 16:16 +0200, Jacek Caban wrote: > >> The caller is responsible for freeing the result, so it will destroy >> your internal data. I think you should create an array here and not use >> it to store the data internally. > How do you know that the caller is responsible for freeing this > property? That's how out and retval values work in OLE automation, you wouldn't be able to control their life time otherwise. As a test, you may add VariantClear call in your tests and see how things will work. > It seems wasteful to duplicate this potentially large buffer. I agree, but we can't redesign the API. Jacek

July 22, 2011

Re: [PATCH 1/3] programs: Add rule for cross-building modules.

by Octavian Voicu

On Fri, Jul 22, 2011 at 5:29 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > There's a reason for that. Tests are very limited in what they are > allowed to use from Wine, but programs aren't. In particular you can't > use any of the portability routines or configure check for cross > builds. You really need a separate build tree to cross-compile programs. I noticed that most programs don't work, but winetest is a special case and it shouldn't need winelib. I opted to write a generic rule for that, but this doesn't affect programs that cannot be built like this, as those targets are not used (unless you run them manually). I think it is very useful to be able to compile winetest by using make crosstest, and the fact that notepad also works is just a bonus (you would have to do make notepad_cross.exe manually anyway). Would a specific rule (just for winetest) be better? Octavian

July 22, 2011

Re: [2/3] winhttp: Implement IWinHttpRequest::get_ResponseBody.

by Hans Leidekker

On Fri, 2011-07-22 at 16:16 +0200, Jacek Caban wrote: > The caller is responsible for freeing the result, so it will destroy > your internal data. I think you should create an array here and not use > it to store the data internally. How do you know that the caller is responsible for freeing this property? It seems wasteful to duplicate this potentially large buffer.

July 22, 2011

Re: [PATCH 1/3] programs: Add rule for cross-building modules.

by Alexandre Julliard

Octavian Voicu <octavian.voicu(a)gmail.com> writes: > Allows cross-building modules similar to how tests are cross-built. > > For each module, a MODULE_cross.exe target is added to cross-build the module. > No other targets are affected. > > Cross-building doesn't work if the module uses libwine or the associated > includes. Currently only notepad_cross.exe can be built using this method, > but next patch makes it possible to also build winetest_cross.exe. > > [I always found it annoying that make crosstest only builds executables for > individual tests. This patch series makes it also build an executable for > winetest.] There's a reason for that. Tests are very limited in what they are allowed to use from Wine, but programs aren't. In particular you can't use any of the portability routines or configure check for cross builds. You really need a separate build tree to cross-compile programs. -- Alexandre Julliard julliard(a)winehq.org

July 22, 2011

Re: [2/3] winhttp: Implement IWinHttpRequest::get_ResponseBody.

by Jacek Caban

Hi Hans, On 07/22/11 16:00, Hans Leidekker wrote: > --- > dlls/winhttp/request.c | 13 +++++++++++-- > dlls/winhttp/tests/winhttp.c | 9 ++++++++- > 2 files changed, 19 insertions(+), 3 deletions(-) > > diff --git a/dlls/winhttp/request.c b/dlls/winhttp/request.c > index 0c4c726..a73be22 100644 > --- a/dlls/winhttp/request.c > +++ b/dlls/winhttp/request.c > @@ -2747,8 +2747,17 @@ static HRESULT WINAPI winhttp_request_get_ResponseBody( > IWinHttpRequest *iface, > VARIANT *body ) > { > - FIXME("\n"); > - return E_NOTIMPL; > + struct winhttp_request *request = impl_from_IWinHttpRequest( iface ); > + DWORD err; > + > + TRACE("%p, %p\n", request, body); > + > + if ((err = request_read_body( request, INFINITE ))) return HRESULT_FROM_WIN32( err ); > + > + VariantInit( body ); > + V_VT( body ) = VT_ARRAY|VT_UI1; > + V_ARRAY( body ) = request->buffer; The caller is responsible for freeing the result, so it will destroy your internal data. I think you should create an array here and not use it to store the data internally. Also VariantInit call is not needed if you set both type and value of variant. Jacek

July 22, 2011