September 2008 - Wine-Devel

What broken in ubuntu Wine packages?
by Vitaliy Margolen Sept. 23, 2008

Sept. 23, 2008

Almost all bugs that come from Ubuntu users don't have usable backtraces. Instead they have this: Process of pid=0008 has terminated No process loaded, cannot execute 'echo Modules:' Cannot get info on module while no process is loaded Needless to say this doesn't help with troubleshooting the problem. Does anyone have a clue what might be the problem? Vitaliy.

6 12

Re: gdi32: "StretchDIBits" with value of zero for "xSrc" and "ySrc"
by Juan Lang Sept. 23, 2008

Sept. 23, 2008

Hi Mathias, + * mkosch (2008/09/22) Please don't put such comments in source files, the source files aren't a changelog. + hProcessHeap = GetProcessHeap(); + assert(hProcessHeap != NULL); This assert is pointless, GetProcessHeap cannot reasonably fail. And more generally.. + assert(hDC != NULL); dont' use assert() in the tests, especially for conditions such as this which have nothing to do with the function you're testing. These will only fail in out-of-memory type situations, and many other things will fail before your particular test. So either assume that such basic functions will succeed, or use ok to check them if there's some reasonable probability they may fail, or use a combination of skip and return if one fails. Just please don't use so many asserts in the tests. + // Initializing random number generator: In the first place, such a comment is unnecessary, is it's quite clear what the following line does. In the second place, C++-style comments are not allowed in Wine source. --Juan

4 4

Re: wine.inf.in: create default key App Paths (and key for IEXPLORE)
by Louis. Lenders Sept. 23, 2008

Sept. 23, 2008

----- Original Message ---- From: Alexandre Julliard <julliard(a)winehq.org> "Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> writes: > Hi, the key HKLM//Software\\Microsoft\\Windows\\CurrentVersion\\App Paths is needed by LexWare installer (bug http://bugs.winehq.org/show_bug.cgi?id=15347) > > This patch creates that key by default, but also creates the key for IEXPLORE along the way, needed to fix http://bugs.winehq.org/show_bug.cgi?id=7257. The key is present on a default winxp installation > > btw, was there anything wrong with this patch: > http://www.winehq.org/pipermail/wine-patches/attachments/20080918/e269df3c/… ? >Yes, it doesn't match the Windows definitions. And this patch doesn't >either. You really need to pay more attention to what you are doing. honestly, i'm trying to be as careful as i can. But I see an extra semi-colon crawled in in the patch for the registry key for App Paths. Is that what you meant with 'doesn't match Windows definitions'? Or is there something more wrong? As for the patch for MsiSetExternalUIRecord , i compared again with de definition at http://msdn.microsoft.com/en-us/library/aa370385(VS.85).aspx, but i don't see a problem there. Also i matched the definition for InstalluiHandlerRecord to the definition of InstalluiHandler in wine's msi.h, as that seemed more consistent to me. I'm happy to fix up any patch , if only i knew what was wrong with them... louis

2 1

Re: [4/5] wined3d: Merge pshader_hw_map2gl() and vshader_hw_map2gl()
by Ivan Gyurdiev Sept. 23, 2008

Sept. 23, 2008

> This isn't the prettiest way to merge those functions, but it's a start Will you be cleaning this up further to get rid of the huge if-else ? I think at least all the MOV-specific stuff should go in its own instr. function. Ivan

2 1

Re: wine.inf.in: create default key App Paths (and key for IEXPLORE)
by Alexandre Julliard Sept. 23, 2008

Sept. 23, 2008

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> writes: > Hi, the key HKLM//Software\\Microsoft\\Windows\\CurrentVersion\\App Paths is needed by LexWare installer (bug http://bugs.winehq.org/show_bug.cgi?id=15347) > > This patch creates that key by default, but also creates the key for IEXPLORE along the way, needed to fix http://bugs.winehq.org/show_bug.cgi?id=7257. The key is present on a default winxp installation > > btw, was there anything wrong with this patch: > http://www.winehq.org/pipermail/wine-patches/attachments/20080918/e269df3c/… ? Yes, it doesn't match the Windows definitions. And this patch doesn't either. You really need to pay more attention to what you are doing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Jacek Caban : jscript: Added with statement implementation.
by Michael Stefaniuc Sept. 23, 2008

Sept. 23, 2008

Hello Jacek, this patch introduces a gcc warning: dlls/jscript/engine.c:954: warning: empty body in an if-statement Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: dfb867af56f4b15986482deef588d33d2458b101 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=dfb867af56f4b15986482deef… > > Author: Jacek Caban <jacek(a)codeweavers.com> > Date: Fri Sep 19 00:43:53 2008 +0200 > > jscript: Added with statement implementation. > > --- > > dlls/jscript/engine.c | 44 +++++++++++++++++++++++++++++++++++++++++--- > dlls/jscript/tests/lang.js | 4 ++++ > 2 files changed, 45 insertions(+), 3 deletions(-) > > diff --git a/dlls/jscript/engine.c b/dlls/jscript/engine.c > index f4b065f..b89d808 100644 > --- a/dlls/jscript/engine.c > +++ b/dlls/jscript/engine.c > @@ -924,12 +924,50 @@ HRESULT return_statement_eval(exec_ctx_t *ctx, statement_t *_stat, return_type_t > return S_OK; > } > > -HRESULT with_statement_eval(exec_ctx_t *ctx, statement_t *stat, return_type_t *rt, VARIANT *ret) > +/* ECMA-262 3rd Edition 12.10 */ > +HRESULT with_statement_eval(exec_ctx_t *ctx, statement_t *_stat, return_type_t *rt, VARIANT *ret) > { > - FIXME("\n"); > - return E_NOTIMPL; > + with_statement_t *stat = (with_statement_t*)_stat; > + exprval_t exprval; > + IDispatch *disp; > + DispatchEx *obj; > + VARIANT val; > + HRESULT hres; > + > + TRACE("\n"); > + > + hres = expr_eval(ctx, stat->expr, 0, &rt->ei, &exprval); > + if(FAILED(hres)) > + return hres; > + > + hres = exprval_to_value(ctx->parser->script, &exprval, &rt->ei, &val); > + exprval_release(&exprval); > + if(FAILED(hres)) > + return hres; > + > + hres = to_object(ctx, &val, &disp); > + VariantClear(&val); > + if(FAILED(hres)) > + return hres; > + > + obj = iface_to_jsdisp((IUnknown*)disp); > + IDispatch_Release(disp); > + if(!obj) { > + FIXME("disp id not jsdisp\n"); > + return E_NOTIMPL; > + } > + > + hres = scope_push(ctx->scope_chain, obj, &ctx->scope_chain); > + jsdisp_release(obj); > + if(FAILED(hres)); Not sure if the if should be just removed or the two statements swapped and become if(FAILED(hres)) jsdisp_release(obj); > + > + hres = stat_eval(ctx, stat->statement, rt, ret); > + > + scope_pop(&ctx->scope_chain); > + return hres; > } > > +/* ECMA-262 3rd Edition 12.12 */ > HRESULT labelled_statement_eval(exec_ctx_t *ctx, statement_t *stat, return_type_t *rt, VARIANT *ret) > { > FIXME("\n"); bye michael

1 0

[Fwd: gdi32: "StretchDIBits" with value of zero for "xSrc" and "ySrc"]
by James McKenzie Sept. 22, 2008

Sept. 22, 2008

+ /* This might not work for values of "dwRop" much different than "SRCCOPY". + * Further testing is required. + * mkosch (2008/09/22) + */ Add a test case for this if it is possible and test it, if possible. Then you will know if it works/does not work. James McKenzie >From da2f416c33348ef059e0c3958392d5231b6fd774 Mon Sep 17 00:00:00 2001 From: Mathias Kosch <info(a)mkosch.de> Date: Tue, 23 Sep 2008 01:36:34 +0200 Subject: gdi32: "StretchDIBits" with value of zero for "xSrc" and "ySrc" This patch fixes Bug#13344. The function "StretchDIBits" behaves odd in case of "top-down" bitmaps with values of zero for "xSrc" and "ySrc". Tests using Windows Server 2003 shew that in this particular case the source rectangle is selected starting at the upper left corner of the bitmap. In all other cases the rectangle is aligned to the bottom of the bitmap. I provided a test case which tests several combinations, especially those with some of the values set to zero. (Some additional cosmetic corrections have been applied to the test case.) It passes under "Windows Server 2003 R2 SP2" and Wine 1.1.5 (only) with this path applied. --- dlls/gdi32/dib.c | 20 +++- dlls/gdi32/tests/Makefile.in | 1 + dlls/gdi32/tests/dib.c | 238 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 257 insertions(+), 2 deletions(-) create mode 100644 dlls/gdi32/tests/dib.c diff --git a/dlls/gdi32/dib.c b/dlls/gdi32/dib.c index 440857d..a59a02e 100644 --- a/dlls/gdi32/dib.c +++ b/dlls/gdi32/dib.c @@ -212,6 +212,7 @@ INT WINAPI StretchDIBits(HDC hdc, INT xDst, INT yDst, INT widthDst, DWORD compr, size; HBITMAP hBitmap; BOOL fastpath = FALSE; + int ySrcAdjusted; release_dc_ptr( dc ); @@ -227,6 +228,16 @@ INT WINAPI StretchDIBits(HDC hdc, INT xDst, INT yDst, INT widthDst, return 0; } + /* Computation of source coordinates behaves different in case of "top down" + bitmaps and values of zero for "xSrc" and "ySrc": */ + if (height < 0) + { + height = -height; /* Positive from now on. */ + ySrcAdjusted = ((xSrc) || (ySrc)) ? height - heightSrc - ySrc : 0; + } + else + ySrcAdjusted = height - heightSrc - ySrc; + hBitmap = GetCurrentObject(hdc, OBJ_BITMAP); if (xDst == 0 && yDst == 0 && xSrc == 0 && ySrc == 0 && @@ -286,8 +297,13 @@ INT WINAPI StretchDIBits(HDC hdc, INT xDst, INT yDst, INT widthDst, * ericP (2000/09/09) */ + /* This might not work for values of "dwRop" much different than "SRCCOPY". + * Further testing is required. + * mkosch (2008/09/22) + */ + /* copy existing bitmap from destination dc */ - StretchBlt( hdcMem, xSrc, abs(height) - heightSrc - ySrc, + StretchBlt( hdcMem, xSrc, ySrcAdjusted, widthSrc, heightSrc, hdc, xDst, yDst, widthDst, heightDst, dwRop ); } @@ -297,7 +313,7 @@ INT WINAPI StretchDIBits(HDC hdc, INT xDst, INT yDst, INT widthDst, /* Origin for DIBitmap may be bottom left (positive biHeight) or top left (negative biHeight) */ if (ret) StretchBlt( hdc, xDst, yDst, widthDst, heightDst, - hdcMem, xSrc, abs(height) - heightSrc - ySrc, + hdcMem, xSrc, ySrcAdjusted, widthSrc, heightSrc, dwRop ); if(hpal) SelectPalette(hdcMem, hpal, FALSE); diff --git a/dlls/gdi32/tests/Makefile.in b/dlls/gdi32/tests/Makefile.in index 866615c..86c931b 100644 --- a/dlls/gdi32/tests/Makefile.in +++ b/dlls/gdi32/tests/Makefile.in @@ -10,6 +10,7 @@ CTESTS = \ brush.c \ clipping.c \ dc.c \ + dib.c \ font.c \ gdiobj.c \ generated.c \ diff --git a/dlls/gdi32/tests/dib.c b/dlls/gdi32/tests/dib.c new file mode 100644 index 0000000..130bf23 --- /dev/null +++ b/dlls/gdi32/tests/dib.c @@ -0,0 +1,238 @@ +/* + * Unit tests for dib functions + * + * Copyright (c) 2008 Mathias Kosch + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include <assert.h> +#include <stdarg.h> +#include <time.h> + +#include "windef.h" +#include "winbase.h" +#include "wingdi.h" +#include "winuser.h" + +#include "wine/test.h" + + +static void test_StretchDIBits_internal(int xSrc, int ySrc, + int xDest, int yDest, int nWidth, int nHeight, BOOL bTopDown) +{ + BOOL bMatching; + int x, y, nResult; + int nBitmapWidth, nBitmapHeight, nNewBitmapWidth, nNewBitmapHeight; + ULONG i, nSize; + RGBTRIPLE *pBitmapData, *pNewBitmapData, *pStartLine, *pNewStartLine; + BITMAPINFO bmi, bmiNew; + HANDLE hProcessHeap; + HDC hDC, hMemDC; + HBITMAP hBitmap, hOldBitmap; + + + hProcessHeap = GetProcessHeap(); + assert(hProcessHeap != NULL); + + /* Compute bitmap widths and heights. The should be multiples of 4. */ + nBitmapWidth = ((nWidth+xSrc+37) | 3)+1; + nBitmapHeight = ((nHeight+ySrc+43) | 3)+1; + nNewBitmapWidth = ((nWidth+xDest+103) | 3)+1; + nNewBitmapHeight = ((nHeight+yDest+57) | 3)+1; + + /* Creating bitmap structure for bitmap: */ + bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); + bmi.bmiHeader.biWidth = nBitmapWidth; + bmi.bmiHeader.biHeight = nBitmapHeight; + bmi.bmiHeader.biPlanes = 1; + bmi.bmiHeader.biBitCount = 24; + bmi.bmiHeader.biCompression = BI_RGB; + bmi.bmiHeader.biSizeImage = 0; + bmi.bmiHeader.biXPelsPerMeter = 0; + bmi.bmiHeader.biYPelsPerMeter = 0; + bmi.bmiHeader.biClrUsed = 0; + bmi.bmiHeader.biClrImportant = 0; + if (bTopDown) + bmi.bmiHeader.biHeight = -bmi.bmiHeader.biHeight; + + /* Creating bitmap structure for new bitmap: */ + bmiNew.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); + bmiNew.bmiHeader.biWidth = nNewBitmapWidth; + bmiNew.bmiHeader.biHeight = nNewBitmapHeight; + bmiNew.bmiHeader.biPlanes = 1; + bmiNew.bmiHeader.biBitCount = 24; + bmiNew.bmiHeader.biCompression = BI_RGB; + bmiNew.bmiHeader.biSizeImage = 0; + bmiNew.bmiHeader.biXPelsPerMeter = 0; + bmiNew.bmiHeader.biYPelsPerMeter = 0; + bmiNew.bmiHeader.biClrUsed = 0; + bmiNew.bmiHeader.biClrImportant = 0; + if (bTopDown) + bmiNew.bmiHeader.biHeight = -bmiNew.bmiHeader.biHeight; + + /* Creating device context. */ + hDC = GetDC(NULL); + assert(hDC != NULL); + hMemDC = CreateCompatibleDC(hDC); + assert(hMemDC != NULL); + hBitmap = CreateCompatibleBitmap(hDC, nNewBitmapWidth, nNewBitmapHeight); + assert(hBitmap != NULL); + hOldBitmap = (HBITMAP)SelectObject(hMemDC, hBitmap); + assert(hOldBitmap != NULL); + + /* Allocating storage for bitmap data */ + pBitmapData = (RGBTRIPLE*)HeapAlloc(hProcessHeap, 0, + nBitmapWidth*nBitmapHeight*sizeof(RGBTRIPLE)); + assert(pBitmapData != NULL); + pNewBitmapData = (RGBTRIPLE*)HeapAlloc(hProcessHeap, 0, + nNewBitmapWidth*nNewBitmapHeight*sizeof(RGBTRIPLE)); + assert(pNewBitmapData != NULL); + + /* Initializing bitmap with random color data: */ + nSize = nBitmapWidth*nBitmapHeight; + for (i = 0; i < nSize; i++) + { + pBitmapData[i].rgbtBlue = rand(); + pBitmapData[i].rgbtGreen = rand(); + pBitmapData[i].rgbtRed = rand(); + } + + /* Drawing bitmap data as "bottom up" bitmap into first dc: */ + nResult = StretchDIBits(hMemDC, xDest, yDest, nWidth, nHeight, xSrc, ySrc, + nWidth, nHeight, pBitmapData, &bmi, DIB_RGB_COLORS, SRCCOPY); + assert(nResult != 0); + + /* Retrieving bitmap data: */ + nResult = GetDIBits(hMemDC, hBitmap, 0, nNewBitmapHeight, pNewBitmapData, + &bmiNew, DIB_RGB_COLORS); + assert(nResult != 0); + + /* Computing starting lines for comparision. "StretchDIBits" + seems to behave odd in case "xSrc" an "ySrc" is 0. */ + if (bTopDown) + { + pStartLine = pBitmapData; + if ((xSrc) || (ySrc)) + pStartLine += (nBitmapHeight-nHeight-ySrc)*nBitmapWidth; + pNewStartLine = pNewBitmapData + yDest*nNewBitmapWidth; + } + else + { + pStartLine = pBitmapData + (nHeight+ySrc-1)*nBitmapWidth; + pNewStartLine = pNewBitmapData + + (nNewBitmapHeight-yDest-1)*nNewBitmapWidth; + } + + /* Comparing bitmap data with supposed data. */ + bMatching = TRUE; + for (y = 0; y < nHeight; y++) + { + for (x = 0; x < nWidth; x++) + { + if ((pStartLine[x+xSrc].rgbtBlue != pNewStartLine[x+xDest].rgbtBlue) || + (pStartLine[x+xSrc].rgbtGreen != pNewStartLine[x+xDest].rgbtGreen) || + (pStartLine[x+xSrc].rgbtRed != pNewStartLine[x+xDest].rgbtRed)) + { + bMatching = FALSE; + break; + } + } + + if (bTopDown) + { + pStartLine += nBitmapWidth; + pNewStartLine += nNewBitmapWidth; + } + else + { + pStartLine -= nBitmapWidth; + pNewStartLine -= nNewBitmapWidth; + } + } + + ok(bMatching != FALSE, "Bitmap data not matching. [bTopDown=%s," + " StretchDIBits(hMemDC, %d, %d, %d, %d, %d, %d, %d, %d," + " pBitmapData, &bmi, DIB_RGB_COLORS, SRCCOPY)]\n", + (bTopDown) ? "true" : "false", + xDest, yDest, nWidth, nHeight, xSrc, ySrc, nWidth, nHeight); + + SelectObject(hMemDC, hOldBitmap); + DeleteObject(hBitmap); + DeleteDC(hMemDC); + HeapFree(hProcessHeap, 0, pNewBitmapData); + HeapFree(hProcessHeap, 0, pBitmapData); +} + + +static void test_StretchDIBits() +{ + test_StretchDIBits_internal(33, 61, 103, 227, 663, 459, FALSE); + test_StretchDIBits_internal(33, 61, 103, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 61, 103, 227, 663, 459, FALSE); + test_StretchDIBits_internal(0, 61, 103, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 0, 103, 227, 663, 459, FALSE); + test_StretchDIBits_internal(33, 0, 103, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 0, 103, 227, 663, 459, FALSE); + test_StretchDIBits_internal(0, 0, 103, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 61, 0, 227, 663, 459, FALSE); + test_StretchDIBits_internal(33, 61, 0, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 61, 0, 227, 663, 459, FALSE); + test_StretchDIBits_internal(0, 61, 0, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 0, 0, 227, 663, 459, FALSE); + test_StretchDIBits_internal(33, 0, 0, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 0, 0, 227, 663, 459, FALSE); + test_StretchDIBits_internal(0, 0, 0, 227, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 61, 103, 0, 663, 459, FALSE); + test_StretchDIBits_internal(33, 61, 103, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 61, 103, 0, 663, 459, FALSE); + test_StretchDIBits_internal(0, 61, 103, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 0, 103, 0, 663, 459, FALSE); + test_StretchDIBits_internal(33, 0, 103, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 0, 103, 0, 663, 459, FALSE); + test_StretchDIBits_internal(0, 0, 103, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 61, 0, 0, 663, 459, FALSE); + test_StretchDIBits_internal(33, 61, 0, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 61, 0, 0, 663, 459, FALSE); + test_StretchDIBits_internal(0, 61, 0, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(33, 0, 0, 0, 663, 459, FALSE); + test_StretchDIBits_internal(33, 0, 0, 0, 663, 459, TRUE); + + test_StretchDIBits_internal(0, 0, 0, 0, 663, 459, FALSE); + test_Str

1 0

Re: configure.ac: add -Werror to default compiler options
by Rob Shearman Sept. 22, 2008

Sept. 22, 2008

2008/9/18 Austin English <austinenglish(a)gmail.com>: > Should help avoid bugs like bug 15266 and promote more proper, portable code. > Tried compiling Wine with -Werror, got a few interesting results. First one: > > austin(a)austin-desktop:~/wine-git/dlls/jscript$ make > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT > -fPIC -Wall -Werror -pipe -fno-strict-aliasing -Wdeclaration-after-statement > -Wwrite-strings -Wpointer-arith -g -O2 -o engine.o engine.c > cc1: warnings being treated as errors > engine.c: In function 'var_statement_eval': > engine.c:500: warning: 'hres' is used uninitialized in this function Or it could just be that they had a different compiler version to you and so the warning didn't appear for them. This is the trouble with using -Werror in an uncontrolled environment - a developer using one version of the compiler could commit code that compiles cleanly for them, but not for another developer using a different compiler version and so stop them from being able to build Wine. That's fine if we want to do it, but we have to consider whether it is worth the hassle for whatever increase in quality we get from it. -- Rob Shearman

4 3

re: msvcrt: scanf fix a typo
by Dan Kegel Sept. 22, 2008

Sept. 22, 2008

Here's the gcc error: > scanf.c:66: warning: unknown conversion type character `P' in format I'm not a programmer, but I play one on TV. And here's what I came up with in five minutes of typing and not enough thinking: That particular error depends on gcc knowing intimate details of sscanf. Unless we teach gcc about the particular sscanf we're implementing, it's likely to give false errors. It could be that the line #include <stdio.h> at the top of that file is introducing a conflict. See http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Function-Attributes.html#Functi… for the function attributes used to teach gcc about scanf-like format arguments. This may be an example of the problem Juan was anticipating, where people rush to provide fixes to problems that they don't fully understand, just to try to get rid of gcc warnings :-( - Dan

6 15

Re: wine.inf.in: create default key App Paths (and key for IEXPLORE)
by Michael Karcher Sept. 22, 2008

Sept. 22, 2008

Am Montag, den 22.09.2008, 15:42 +0000 schrieb Louis. Lenders: > btw, was there anything wrong with this patch: > http://www.winehq.org/pipermail/wine-patches/attachments/20080918/e269df3c/… ? As you were already told, IIRC, please do not link attachment, but mails. In this case: http://www.winehq.org/pipermail/wine-patches/2008-September/061760.html In that patch, you are definitely missing the prototype for MsiSetExternalUIRecord in msi.h. I didn't notice any further problems. Regards, Michael Karcher

1 0