December 2008 - Wine-Devel - list.winehq.org

Re: [1/2] mshtml: Rename stucture to avoid name clash
by Alexandre Julliard Dec. 30, 2008

Dec. 30, 2008

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > static HRESULT WINAPI HTMLStyle_QueryInterface(IHTMLStyle *iface, REFIID riid, void **ppv) > { > - HTMLStyle *This = HTMLSTYLE_THIS(iface); > + HStyle *This = HTMLSTYLE_THIS(iface); A name like IHTMLStyleImpl would be a better choice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Henri Verbeet : secur32: Handle SECPKG_ATTR_STREAM_SIZES in schan_QueryContextAttributesW().
by Christian Costa Dec. 30, 2008

Dec. 30, 2008

Hi, Compilation failed here (FC8), I got this error : gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o schannel.o schannel.c schannel.c:61: erreur: ‘gnutls_mac_get_key_size’ undeclared here (not in a function) schannel.c:61: attention : type defaults to ‘int’ in declaration of ‘pgnutls_mac_get_key_size’ schannel.c: In function ‘schan_QueryContextAttributesW’: schannel.c:856: erreur: called object ‘pgnutls_mac_get_key_size’ is not a function make[2]: *** [schannel.o] Erreur 1 Christian Alexandre Julliard a écrit : > Module: wine > Branch: master > Commit: 95fd8762665e65fedf7e2ede43e657f123dc4535 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=95fd8762665e65fedf7e2ede4… > > Author: Henri Verbeet <hverbeet(a)gmail.com> > Date: Sun Dec 28 22:21:35 2008 +0100 > > secur32: Handle SECPKG_ATTR_STREAM_SIZES in schan_QueryContextAttributesW(). > > --- > > dlls/secur32/schannel.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 64 insertions(+), 0 deletions(-) > > diff --git a/dlls/secur32/schannel.c b/dlls/secur32/schannel.c > index df5d56a..ed583d4 100644 > --- a/dlls/secur32/schannel.c > +++ b/dlls/secur32/schannel.c > @@ -48,6 +48,7 @@ MAKE_FUNCPTR(gnutls_alert_get); > MAKE_FUNCPTR(gnutls_alert_get_name); > MAKE_FUNCPTR(gnutls_certificate_allocate_credentials); > MAKE_FUNCPTR(gnutls_certificate_free_credentials); > +MAKE_FUNCPTR(gnutls_cipher_get); > MAKE_FUNCPTR(gnutls_credentials_set); > MAKE_FUNCPTR(gnutls_deinit); > MAKE_FUNCPTR(gnutls_global_deinit); > @@ -56,6 +57,8 @@ MAKE_FUNCPTR(gnutls_global_set_log_function); > MAKE_FUNCPTR(gnutls_global_set_log_level); > MAKE_FUNCPTR(gnutls_handshake); > MAKE_FUNCPTR(gnutls_init); > +MAKE_FUNCPTR(gnutls_mac_get); > +MAKE_FUNCPTR(gnutls_mac_get_key_size); > MAKE_FUNCPTR(gnutls_perror); > MAKE_FUNCPTR(gnutls_set_default_priority); > MAKE_FUNCPTR(gnutls_transport_set_errno); > @@ -800,14 +803,69 @@ static SECURITY_STATUS SEC_ENTRY schan_InitializeSecurityContextA( > return ret; > } > > +static unsigned int schannel_get_cipher_block_size(gnutls_cipher_algorithm_t cipher) > +{ > + const struct > + { > + gnutls_cipher_algorithm_t cipher; > + unsigned int block_size; > + } > + algorithms[] = > + { > + {GNUTLS_CIPHER_3DES_CBC, 8}, > + {GNUTLS_CIPHER_AES_128_CBC, 16}, > + {GNUTLS_CIPHER_AES_256_CBC, 16}, > + {GNUTLS_CIPHER_ARCFOUR_128, 1}, > + {GNUTLS_CIPHER_ARCFOUR_40, 1}, > + {GNUTLS_CIPHER_DES_CBC, 8}, > + {GNUTLS_CIPHER_NULL, 1}, > + {GNUTLS_CIPHER_RC2_40_CBC, 8}, > + }; > + unsigned int i; > + > + for (i = 0; i < sizeof(algorithms) / sizeof(*algorithms); ++i) > + { > + if (algorithms[i].cipher == cipher) > + return algorithms[i].block_size; > + } > + > + FIXME("Unknown cipher %#x, returning 1\n", cipher); > + > + return 1; > +} > + > static SECURITY_STATUS SEC_ENTRY schan_QueryContextAttributesW( > PCtxtHandle context_handle, ULONG attribute, PVOID buffer) > { > + struct schan_context *ctx; > + > TRACE("context_handle %p, attribute %#x, buffer %p\n", > context_handle, attribute, buffer); > > + if (!context_handle) return SEC_E_INVALID_HANDLE; > + ctx = schan_get_object(context_handle->dwLower, SCHAN_HANDLE_CTX); > + > switch(attribute) > { > + case SECPKG_ATTR_STREAM_SIZES: > + { > + SecPkgContext_StreamSizes *stream_sizes = (SecPkgContext_StreamSizes *)buffer; > + gnutls_mac_algorithm_t mac = pgnutls_mac_get(ctx->session); > + size_t mac_size = pgnutls_mac_get_key_size(mac); > + gnutls_cipher_algorithm_t cipher = pgnutls_cipher_get(ctx->session); > + unsigned int block_size = schannel_get_cipher_block_size(cipher); > + > + TRACE("Using %zu mac bytes, block size %u\n", mac_size, block_size); > + > + /* These are defined by the TLS RFC */ > + stream_sizes->cbHeader = 5; > + stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes padding + 1 for padding size */ > + stream_sizes->cbMaximumMessage = 1 << 14; > + stream_sizes->cbBuffers = 4; > + stream_sizes->cbBlockSize = block_size; > + return SEC_E_OK; > + } > + > default: > FIXME("Unhandled attribute %#x\n", attribute); > return SEC_E_UNSUPPORTED_FUNCTION; > @@ -822,6 +880,9 @@ static SECURITY_STATUS SEC_ENTRY schan_QueryContextAttributesA( > > switch(attribute) > { > + case SECPKG_ATTR_STREAM_SIZES: > + return schan_QueryContextAttributesW(context_handle, attribute, buffer); > + > default: > FIXME("Unhandled attribute %#x\n", attribute); > return SEC_E_UNSUPPORTED_FUNCTION; > @@ -961,6 +1022,7 @@ void SECUR32_initSchannelSP(void) > LOAD_FUNCPTR(gnutls_alert_get_name) > LOAD_FUNCPTR(gnutls_certificate_allocate_credentials) > LOAD_FUNCPTR(gnutls_certificate_free_credentials) > + LOAD_FUNCPTR(gnutls_cipher_get) > LOAD_FUNCPTR(gnutls_credentials_set) > LOAD_FUNCPTR(gnutls_deinit) > LOAD_FUNCPTR(gnutls_global_deinit) > @@ -969,6 +1031,8 @@ void SECUR32_initSchannelSP(void) > LOAD_FUNCPTR(gnutls_global_set_log_level) > LOAD_FUNCPTR(gnutls_handshake) > LOAD_FUNCPTR(gnutls_init) > + LOAD_FUNCPTR(gnutls_mac_get) > + LOAD_FUNCPTR(gnutls_mac_get_key_size) > LOAD_FUNCPTR(gnutls_perror) > LOAD_FUNCPTR(gnutls_set_default_priority) > LOAD_FUNCPTR(gnutls_transport_set_errno) > > > > > >

3 3

Re: configure.ac: fix libpng detection on OpenBSD
by Vitaly Lipatov Dec. 30, 2008

Dec. 30, 2008

В сообщении от 29 декабря 2008 Austin English написал(a): > then > - WINE_CHECK_SONAME(png,png_create_read_struct,,,-lm,[[libpng[[0-9]]*]]) > + WINE_CHECK_SONAME(png,png_create_read_struct,,,-lm > -lz,[[libpng[[0-9]]*]]) fi If libpng uses libz, package maintainer have to link it with libz, I do not sure we have to make workaround for libpng packaging bug. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

1 0

re: [PATCH 2/2] mshtml: Wine Gecko 0.9.0 release.
by Dan Kegel Dec. 29, 2008

Dec. 29, 2008

Doesn't build here, did you forget mutation.c? make depend fails with: mutation.c: No such file or directory make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/dank/wine-git/dlls/mshtml'

2 1

Re: oleaut32: Correct the printf placeholder types.
by Austin English Dec. 29, 2008

Dec. 29, 2008

On Mon, Dec 29, 2008 at 2:49 PM, Danny Rawlins <monster.romster(a)gmail.com> wrote: > Fix between unsigned and signed types this is my first wine patch but > you may already know me in irc as <Romster>. > > Also I don't find any -W compiler option to warn against incorrect > placeholders like using a int for a string. > > Thanks to <arethusa> for help, I am still learning C but have patched > many programs. > > Regards, > Danny Rawlins > > > > I think you want to use: CFLAGS="-Wsign-compare" -- -Austin

1 0

Re: [6/6] secur32: Implement schannel DecryptMessage().
by Rob Shearman Dec. 29, 2008

Dec. 29, 2008

Sorry, this should have been in reply to patch [6/6]. 2008/12/29 Henri Verbeet <hverbeet(a)gmail.com>: > 2008/12/29 Rob Shearman <robertshearman(a)gmail.com>: >> 2008/12/28 Henri Verbeet <hverbeet(a)gmail.com>: >>> + while (received < data_size) >>> + { >>> + ret = pgnutls_record_recv(ctx->session, data + received, data_size - received); >>> + if (ret < 0) >>> + { >>> + if (ret == GNUTLS_E_AGAIN) >>> + { >>> + if (!received) >> >> Shouldn't this be "if (received == data_size)"? >> >>> + { >>> + pgnutls_perror(ret); >>> + HeapFree(GetProcessHeap(), 0, data); >>> + TRACE("Returning SEC_E_INCOMPLETE_MESSAGE\n"); >>> + return SEC_E_INCOMPLETE_MESSAGE; >>> + } >>> + break; >>> + } >>> + else >>> + { >>> + pgnutls_perror(ret); >>> + HeapFree(GetProcessHeap(), 0, data); >>> + ERR("Returning SEC_E_INTERNAL_ERROR\n"); >>> + return SEC_E_INTERNAL_ERROR; >>> + } >>> + } >>> + received += ret; >>> + } >> > The idea was to only return SEC_E_INCOMPLETE_MESSAGE if there's less > than one complete TLS record in the buffer, it shouldn't be a problem > to have eg. one complete message plus some bytes from the next one, > setting the buffer size further down is supposed to take care of that. Is it really expected for gnutls_record_recv to return GNUTLS_E_AGAIN on the first call and for the code to have to return that to the caller? That is what the code as it is at the moment does. It seems to me as though you should return SEC_E_INCOMPLETE_MESSAGE if you decrypted all of the data in the supplied buffer, but gnutls still returns GNUTLS_E_AGAIN. That then signals to the app to download more data and call DecryptMessage() again with the new data. -- Rob Shearman

2 1

Re: [5/6] secur32: Implement schannel EncryptMessage().
by Rob Shearman Dec. 29, 2008

Dec. 29, 2008

2008/12/28 Henri Verbeet <hverbeet(a)gmail.com>: > + while (received < data_size) > + { > + ret = pgnutls_record_recv(ctx->session, data + received, data_size - received); > + if (ret < 0) > + { > + if (ret == GNUTLS_E_AGAIN) > + { > + if (!received) Shouldn't this be "if (received == data_size)"? > + { > + pgnutls_perror(ret); > + HeapFree(GetProcessHeap(), 0, data); > + TRACE("Returning SEC_E_INCOMPLETE_MESSAGE\n"); > + return SEC_E_INCOMPLETE_MESSAGE; > + } > + break; > + } > + else > + { > + pgnutls_perror(ret); > + HeapFree(GetProcessHeap(), 0, data); > + ERR("Returning SEC_E_INTERNAL_ERROR\n"); > + return SEC_E_INTERNAL_ERROR; > + } > + } > + received += ret; > + } -- Rob Shearman

2 1

re: New Wine Gecko
by Dan Kegel Dec. 28, 2008

Dec. 28, 2008

Thanks, Jacek, we're really looking forward to it!

1 0

New Wine Gecko
by Jacek Caban Dec. 28, 2008

Dec. 28, 2008

Hi, As there will be a new Gecko release soon, I'd like to give you a good background over what's going on as I feel that there is some misunderstanding on it that I'd like to clarify. I'm sorry for the long mail. First, let me give you a short history of the Gecko package. As we started using Gecko in our MSHTML implementation, we had to provide our own package and an easy way for its installation. I've prepared a package that actually was a temporary solution. It was a SeaMonkey build that had some files manually removed and modified to reduce its size. It was, of course, hacky and ugly but, as there was no urgent need for changing it, we used it for over a year. The next version was built by me. The build process was long and ugly - it needed a Windows installation and MSVC6. Except that I had to try many versions before finding one that worked fine for Wine, as it had both to compile with MSVC6 (back then they were switching to a newer compiler that needed actctx) and work with Wine (there were a few APIs that were not implemented in Wine that they started using). Also, there was the XULRunner project that looked promising but proved to not be good enough for us. I ended up with building the SeaMonkey target and, again, modifying and removing some files afterwards. Now, not only because of CS4 but because we really should follow new Gecko versions as well, the time to release a new package has come. The first decision was to try again by building with MinGW on Windows. I've tried it with limited success and then I found that Mozilla developers have recently worked on building Mozilla with MinGW under Linux (for code analyzers). That was something I hoped to do some day, so I gave it a try and it came out that it works better than compiling on Windows! Also XULRunner project has matured so that we may use it, avoiding other pains from previous packages. But not all is so good. Some changes introduced in the recent Gecko have prevented Wine from working correctly. It was unnoticed for long time because we were using the 1.8 branch, while the newest is 1.9. Because of it, I had to add serious patches (previous build had only minor changes in code) to fix it. I'm working with Mozilla developers to get these patches to official Gecko. We definitely want to avoid maintaining such differences. There are other advantages that will come with the new Gecko. I'm going to make a debug build that seems to work really well on Wine. Although it causes an assert in dbghelp that I didn't look at deeper, for one build I was even able to step through Gecko code with winedbg. Hopefully Valgrind will be happy with it. Also, I'm going to put the code to Git and provide a good building instruction. It's not trivial to build the package, but hopefully with some efforts everyone will be able to succeed with it. In this place I'd like to note: if you're not planning to work on Gecko (I mean not even MSHTML, but Gecko itself), there is no reason to do it. Also I know that some package maintainers would be interested in building it. Please, don't do it! You will realize that it is not possible with a fresh Linux installation without manually setting up environment. Also, due to its complexity, I'm worried about broken builds. I don't really see the reason to do it. If it's a matter of trust policy... well, you've trusted my builds for over three years now, so I'd like to ask you to keep trusting me... Also, I didn't really have a clear idea about version numbering. The first, temporary, package was numbered 0.0.1. The next one was 0.1.0 with plans to release 0.1.x if we'd release a new package on the same code base (there was 0.1.1 candidate that was never released). My plan was to release a package compiled under Linux as 1.0.0, and until then release next 0.x.y builds. Now that we compile the new package on Linux, I still don't like to call it 1.0.0, because of patches needed in our build. I'd prefer to wait with 1.0.0 hoping to fix the difference for next major release. I don't feel strongly about it so if anyone has any suggestion, I'm happy to change the plan. I plan to put Wine Gecko code into a public Git so developing it will be easier. Now releasing a new version should be much easier (as long as we won't find a new blocker, but if we'll find it quicker, it will be easier to fix). I'm happy with releasing the build I've written about a few days ago. I got feedback from Mozilla developer about things we could get to Mozilla tree and I'm going to try to get some patches to Mozilla. That shouldn't delay our release IMO, so I'm going to release tomorrow unless there are any objections. I hope to have another release in a few months that well be closer to main stream Gecko. Please let me know if you have any suggestion or question. Thanks, Jacek

1 0

Implementing dxdiag as student project?
by Dan Kegel Dec. 28, 2008

Dec. 28, 2008

Hi folks, it seems odd to me that Wine doesn't have a tool like dxdiag yet. We often have people complain that graphics aren't working, and we have to ask them to do things like run glxgears as diagnostics. Would it make sense to implement our own dxdiag.exe program? This seems like it might be a fun student project. - Dan

8 19