September 2008 - Wine-Devel

Re: imm: Don't crash in ImmConfigureIME when dwMode is IME_CONFIG_REGISTERWORD and lpData is NULL (resend)
by Aric Stewart Sept. 18, 2008

Sept. 18, 2008

Humm, according to MSDN: "If dwMode is set to IME_CONFIG_REGISTERWORD, this parameter must indicate a REGISTERWORD structure." If windows does not crash in this case, then maybe it would involve checking for the non-presence of the parameter and returning the correct error. So it looks like your fix is not quite correct. -aric Juan Lang wrote: > Hi, > anything wrong with this one? > --Juan > > > ------------------------------------------------------------------------ > >

2 1

Patchwatcher problems
by Andrew Fenn Sept. 18, 2008

Sept. 18, 2008

Hi, I just submitted a patch to wine patches (Started implementing the xinput library for xbox 360 joystick support ) and I believe patch watcher failed for a few reasons. 1) Although it applied my patch it didn't build it as ./tools/make_makefiles isn't called so it isn't built? 2) Patch watcher seems to fail because of another patch, perhaps the latest known good build should be tested if the patch fails and then compared with the first failed attempt? Regards, Andrew

1 0

Re: PrintDlgEx [4/7]: Implement hDevMode and hDevNames on output.
by Juan Lang Sept. 18, 2008

Sept. 18, 2008

Hi Gal, + WORD locks; + if ((locks = (GlobalFlags(lppd->hDevMode) & GMEM_LOCKCOUNT))) { + WARN("hDevMode has %d locks on it. Unlocking it now\n", locks); + while(locks--) { + GlobalUnlock(lppd->hDevMode); + TRACE("Now got %d locks\n", locks); This looks funny. The loop may have a race condition if someone else is locking/unlocking it. The following would be simpler, and more importantly, more likely to be correct: WORD locks; while ((locks = (GlobalFlags(lppd->hDevMode) & GMEM_LOCKCOUNT))) { GlobalUnlock(lppd->hDevMode); TRACE("Now got %d locks\n", locks); } The same comment applies to unlocking hDevNames. --Juan

1 0

Re: d3dx9: Add d3dx9effect.h
by Henri Verbeet Sept. 18, 2008

Sept. 18, 2008

2008/9/18 David Adam <david.adam.cnrs(a)gmail.com>: > Hello, > > > + // Pool > > C++ comment is forbidden > 2008/9/18 Busquets Pérez Luis C. <luiscar2001(a)yahoo.es>: > + // Selecting and setting a technique ... > + // Using current technique ... > + // Managing D3D Device ... > + // Logging device calls ... > + // Parameter blocks ... > + // Cloning ... > + // Fast path for setting variables directly in ID3DXEffect Actually, you shouldn't copy those from the Microsoft header in the first place. > +DEFINE_GUID( IID_ID3DXEffect, > +0xb589b04a, 0x293d, 0x4516, 0xaf, 0xb, 0x3d, 0x7d, 0xbc, 0xf5, 0xac, 0x54); That's interesting though, my headers have "0xf6ceb4b3, 0x4e4c, 0x40dd, 0xb8, 0x83, 0x8d, 0x8d, 0xe5, 0xea, 0xc, 0xd5" as the GUID for IID_ID3DXEffect.

1 0

howto fix bug 13462
by Louis. Lenders Sept. 18, 2008

Sept. 18, 2008

Hi, we've been discussing in bug 13462 howto fix that bug, but in short i think we lack knowledge of how this should properly be fixed, and Erich suggested to take this to wine-devel. I did some testing and this is a major bug, preventing the following apps from working: CDBurner XP, XML Notepad2007, Nasa WorldWind, FX_Composer(nvidia), Ninja Trader and probably a lot more .net applications. I fixed up a patch here http://bugs.winehq.org/attachment.cgi?id=15775, that lets the applications start fine, but i haven't got a clue if it's correct, and Erich said it probably isn't correct, so my question is: Does anyone of the developers (on ole32) have suggestions how to fix this bug properly? More info at http://bugs.winehq.org/show_bug.cgi?id=13462

3 4

Re: ntoskrnl: Implement server side of get_device
by Vitaliy Margolen Sept. 18, 2008

Sept. 18, 2008

Peter Dons Tychsen wrote: > Implement server side of get_device to complete the > IoGetDeviceObjectPointer() function. > > /pedro My first question: what will you do with that pointer if that driver is loaded in the separate instance of ntoskrnl? Driver that calls IoGetDeviceObjectPointer will most likely try to dereference the pointer it got back. > +/* locate a device */ > +DECL_HANDLER(get_device) > +{ > + struct unicode_str name; > + get_req_unicode_str( &name ); > + > + /* lookup the device */ > + struct device *device = open_object_dir(NULL, &name, 0, &device_ops); > + if(!device) > + { > + return; > + } > + > + /* fill reply */ > + reply->handle = alloc_handle(current->process, device, req->access, 0);.... > + reply->user_ptr = device->user_ptr; > + You leaking reference to device here. Need release_object( device ); In your patch please include changes to server/protocol.def only and not any other automatically generated files. Make it a separate commit in your tree and just don't send it to wine-patches. Vitaliy

2 3

Re: user32: Stub for LockWorkStation (try 3)
by James Mckenzie Sept. 18, 2008

Sept. 18, 2008

Paul: I'm glad you removed this 'feature' as it would not work at all with Wine on a Mac system. James Mckenzie -----Original Message----- >From: Paul Chitescu <paulc(a)voip.null.ro> >Sent: Sep 17, 2008 8:12 AM >To: Wine Patches <wine-patches(a)winehq.org> >Subject: user32: Stub for LockWorkStation (try 3) > >Changelog: > user32: Stub for LockWorkStation > >Please do not ask for an implementation based on xdg-screensaver as Alexandre >will not accept it. Sorry, Steven.

2 1

Re: d3dx9: Add d3dx9effect.h
by Henri Verbeet Sept. 17, 2008

Sept. 17, 2008

2008/9/17 Busquets Pérez Luis C. <luiscar2001(a)yahoo.es>: > b0VIM 7.1....... > ÿeÑH..M.áL..root > ................ > ................ > ....localhost.lo > caldomain....... > ............/win > e-git/0001--modi > fied-include-d3d > x9.h.patch...... > ................ That's probably not what you meant to attach. Also, it's bad practice to work as root.

1 0

Re: [1/5] wined3d: Clarify a comment
by Henri Verbeet Sept. 17, 2008

Sept. 17, 2008

Ignore this set, I missed an issue with volumes between the 2nd and 3rd patch.

1 0

wineserver assertion failure
by Dan Kegel Sept. 17, 2008

Sept. 17, 2008

Hrm. Saw this after trying the 'nytimes' crash on Google Chrome with yesterday's wine: wineserver: object.c:277: release_object: Assertion `obj->refcount' failed. If it happens again, I'll report more...

2 1

Request for feedback: gdi32/tests antialiasing patch
by Glenn Wurster Sept. 17, 2008

Sept. 17, 2008

Last Thursday I submitted a patch which was silently dropped. I'd be interested if someone could take a look at it and let me know what I'm missing plase. I've included the original patch e-mail for reference. The patch was tested on XP, 98, and Wine. I also ran it through valgrind and it passed patchwatcher without any errors. I've had the conformance test sitting around for a while and believe it's best put in the wine source tree (especially as a conformance test for the new DIB engine). It's a conformance test for a bug I fixed years ago in the Wine source tree: * http://www.winehq.org/pipermail/wine-cvs/2005-January/013584.html * http://www.winehq.org/pipermail/wine-cvs/2005-January/013623.html Thanks for any assistance anyone may be able to provide. Glenn. On Thu, Sep 11, 2008 at 02:59:46PM -0400, Glenn Wurster wrote: > > Changelog: > gdi32/tests: Add font antialiasing tests > > Add tests to ensure that antialiasing is not used even if requested > when we are operating in a palette drawing mode, and that antialiasing > is used when operating in a non-palette mode. > > Changes since attempt 1: > * Clear the bitmap before we write the text to it. > * Document in this e-mail tests performed. > > Tested on XP (sp2), 98, and Wine, also run through Valgrind (did this on > the initial patch as well but forgot to mention that in the e-mail). > > Glenn Wurster. > > --- > dlls/gdi32/tests/font.c | 163 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 163 insertions(+), 0 deletions(-) > diff --git a/dlls/gdi32/tests/font.c b/dlls/gdi32/tests/font.c > index 7d2c036..088d4e6 100644 > --- a/dlls/gdi32/tests/font.c > +++ b/dlls/gdi32/tests/font.c > @@ -2430,6 +2430,168 @@ static void test_orientation(void) > DeleteDC(hdc); > } > > +static void clear_bmp(HDC hdc, int width, int height, COLORREF colour) > +{ > + HBRUSH hbrush, hbrush_old; > + HPEN hpen, hpen_old; > + > + hbrush = CreateSolidBrush(colour); > + ok(hbrush != NULL, "CreateSolidBrush failed.\n"); > + > + hpen = CreatePen(PS_SOLID, 0, colour); > + ok(hpen != NULL, "CreatePen failed.\n"); > + > + hpen_old = SelectObject( hdc, hpen ); > + hbrush_old = SelectObject( hdc, hbrush ); > + ok(hpen_old != NULL, "SelectObject failed.\n"); > + ok(hbrush_old != NULL, "SelectObject failed.\n"); > + > + ok(Rectangle(hdc, 0, 0, width, height), "Rectangle failed.\n"); > + > + SelectObject(hdc, hbrush_old); > + DeleteObject(hbrush); > + SelectObject(hdc, hpen_old); > + DeleteObject(hpen); > +} > + > +static COLORREF check_bmp_colors(HDC hdc, COLORREF * colours, int colorCnt, int width, int height) > +{ > + COLORREF pixel; > + int x, y, z; > + for(y = 0; y < height; y++) > + { > + for(x = 0; x < width; x++) > + { > + pixel = GetPixel(hdc, x, y); > + for(z = 0; z < colorCnt; z++) > + { > + if(pixel == colours[z]) > + break; > + } > + if(z >= colorCnt) > + { > + return pixel; > + } > + } > + } > + return 0; > +} > + > +static void test_antialias(void) > +{ > + PALETTEENTRY paletteEntries[3] = { > + { 0x00, 0x00, 0x00, PC_NOCOLLAPSE }, > + { 0xFF, 0xFF, 0xFF, PC_NOCOLLAPSE }, > + { 0x44, 0x44, 0x44, PC_NOCOLLAPSE } > + }; > + HDC hdc; > + HFONT hfont, old_hfont; > + HPALETTE hpal, old_hpal; > + LOGPALETTE * lpal; > + HBITMAP hbmp, old_hbmp; > + BITMAPINFO * bmi; > + COLORREF colours[3]; > + int cntr; > + COLORREF pixel; > + > + hdc = CreateCompatibleDC(0); > + > + /* Create an antialiased font. We don't really care what the specific font is */ > + hfont = CreateFont(32, 0, 0, 0, FW_REGULAR, FALSE, FALSE, FALSE, ANSI_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, ANTIALIASED_QUALITY, DEFAULT_PITCH | FF_DONTCARE, NULL); > + old_hfont = SelectObject(hdc, hfont); > + ok(old_hfont != NULL, "SelectObject failed.\n"); > + > + /* Set up a palette */ > + lpal = (LOGPALETTE *)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(LOGPALETTE) + 3*sizeof(PALETTEENTRY)); > + lpal->palNumEntries = 3; > + lpal->palVersion = 0x0300; > + lpal->palPalEntry[0] = paletteEntries[0]; > + lpal->palPalEntry[1] = paletteEntries[1]; > + lpal->palPalEntry[2] = paletteEntries[2]; > + hpal = CreatePalette(lpal); > + HeapFree(GetProcessHeap(), 0, lpal); > + old_hpal = SelectPalette(hdc, hpal, FALSE); > + ok(old_hpal != NULL, "SelectPalette failed.\n"); > + > + /* Create an 8bit bitmap to draw into */ > + bmi = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(BITMAPINFO) + 3 * sizeof(RGBQUAD)); > + bmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); > + bmi->bmiHeader.biWidth = 20; > + bmi->bmiHeader.biHeight = -20; > + bmi->bmiHeader.biPlanes = 1; > + bmi->bmiHeader.biBitCount = 8; > + bmi->bmiHeader.biCompression = BI_RGB; > + bmi->bmiHeader.biClrUsed = 3; > + for(cntr = 0; cntr < 3; cntr++) > + { > + bmi->bmiColors[cntr].rgbRed = paletteEntries[cntr].peRed; > + bmi->bmiColors[cntr].rgbGreen = paletteEntries[cntr].peGreen; > + bmi->bmiColors[cntr].rgbBlue = paletteEntries[cntr].peBlue; > + bmi->bmiColors[cntr].rgbReserved = 0; > + colours[cntr] = RGB(paletteEntries[cntr].peRed, paletteEntries[cntr].peGreen, paletteEntries[cntr].peBlue); > + } > + > + hbmp = CreateDIBSection(hdc, bmi, DIB_RGB_COLORS, 0, 0, 0); > + ok(hbmp != NULL, "error=%d\n", GetLastError()); > + old_hbmp = SelectObject(hdc, hbmp); > + ok(old_hbmp != NULL, "error=%d\n", GetLastError()); > + > + HeapFree(GetProcessHeap(), 0, bmi); > + > + /* Set up the text colours */ > + SetTextColor(hdc, RGB(0xFF, 0xFF, 0xFF)); > + SetBkColor(hdc, RGB(0, 0, 0)); > + SetBkMode(hdc, OPAQUE); > + > + /* Draw an 'O' offset to see if antialiasing was > + * used. Antialiasing should be restricted to colours in the > + * palette (if it is done at all). */ > + clear_bmp(hdc, 20, 20, RGB(0, 0, 0)); > + ok(ExtTextOut(hdc, 0, -4, 0, NULL, "O", 1, NULL), "ExtTextOut failed.\n"); > + pixel = check_bmp_colors(hdc, colours, 3, 20, 20); > + ok(pixel == 0, "Found invalid pixel: %x.\n", pixel); > + > + /* Cleanup the palette stuff */ > + SelectPalette(hdc, old_hpal, FALSE); > + DeleteObject(hpal); > + SelectObject(hdc, old_hbmp); > + DeleteObject(hbmp); > + > + /* Create an RGB bitmap to draw into */ > + bmi = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(BITMAPINFO)); > + bmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); > + bmi->bmiHeader.biWidth = 20; > + bmi->bmiHeader.biHeight = -20; > + bmi->bmiHeader.biPlanes = 1; > + bmi->bmiHeader.biBitCount = 32; > + bmi->bmiHeader.biCompression = BI_RGB; > + bmi->bmiHeader.biClrUsed = 0; > + > + hbmp = CreateDIBSection(hdc, bmi, DIB_RGB_COLORS, 0, 0, 0); > + ok(hbmp != NULL, "error=%d\n", GetLastError()); > + old_hbmp = SelectObject(hdc, hbmp); > + ok(old_hbmp != NULL, "error=%d\n", GetLastError()); > + > + HeapFree(GetProcessHeap(), 0, bmi); > + > + /* Draw an 'O' offset to see if antialiasing was used. > + * Antialiasing should be used when we specify an antialiasing > + * font and use a RGB bitmap. */ > + clear_bmp(hdc, 20, 20, RGB(0, 0, 0)); > + ok(ExtTextOut(hdc, 0, -4, 0, NULL, "O", 1, NULL), "ExtTextOut failed.\n"); > + pixel = check_bmp_colors(hdc, colours, 2, 20, 20); > + ok(pixel != 0, "Antialiasing was not used.\n"); > + > + /* Free the bitmap */ > + SelectObject(hdc, old_hbmp); > + DeleteObject(hbmp); > + > + /* Free the rest of our memory */ > + SelectObject(hdc, old_hfont); > + DeleteObject(hfont); > + DeleteDC(hdc); > +} > + > START_TEST(font) > { > init(); > @@ -2449,6 +2611,7 @@ START_TEST(font) > test_GetFontUnicodeRanges(); > test_nonexistent_font(); > test_orientation(); > + test_antialias(); > > /* On Windows Arial has a lot of default charset aliases such as Arial Cyr, > * I'd like to avoid them in this test. >

1 0

Rejected patches needing review.
by Peter Dons Tychsen Sept. 17, 2008

Sept. 17, 2008

Hello. I have a problem loading a specific proprietary driver. I traced the problem to two bugs in: - services - winedevice The two bugs caused the loading to fail. I created and tested two fixes to solve the problem, but both patches were silently rejected. Can some review them before i re-send them? I have looked them over several time, but i do not see a problem with them. The only "problem" is that there are no test cases for these programs, as there is no such place for such. Thanks, /pedro

4 5

Re: [PATCH] pass correct buffersize to LCMapStringW
by Dmitry Timoshkov Sept. 16, 2008

Sept. 16, 2008

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: > diff --git a/dlls/kernel32/tests/locale.c b/dlls/kernel32/tests/locale.c > index f792da2..a49953b 100644 > --- a/dlls/kernel32/tests/locale.c > +++ b/dlls/kernel32/tests/locale.c > @@ -1268,7 +1268,7 @@ static void test_LCMapStringW(void) > /* otherwise src == dst should fail */ > SetLastError(0xdeadbeef); > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY | LCMAP_UPPERCASE, > - buf, 10, buf, sizeof(buf)); > + buf, 10, buf, sizeof(buf)/sizeof(WCHAR)); > ok(GetLastError() == ERROR_INVALID_FLAGS /* NT */ || > GetLastError() == ERROR_INVALID_PARAMETER /* Win9x */, > "unexpected error code %d\n", GetLastError()); > @@ -1276,40 +1276,40 @@ static void test_LCMapStringW(void) > > /* test whether '\0' is always appended */ > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - upper_case, -1, buf, sizeof(buf)); > + upper_case, -1, buf, sizeof(buf)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ret2 = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - upper_case, lstrlenW(upper_case), buf2, sizeof(buf2)); > + upper_case, lstrlenW(upper_case), buf2, sizeof(buf2)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ok(ret == ret2, "lengths of sort keys must be equal\n"); > ok(!lstrcmpA(p_buf, p_buf2), "sort keys must be equal\n"); > > /* test LCMAP_SORTKEY | NORM_IGNORECASE */ > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY | NORM_IGNORECASE, > - upper_case, -1, buf, sizeof(buf)); > + upper_case, -1, buf, sizeof(buf)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ret2 = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - lower_case, -1, buf2, sizeof(buf2)); > + lower_case, -1, buf2, sizeof(buf2)/sizeof(WCHAR)); > ok(ret2, "LCMapStringW must succeed\n"); > ok(ret == ret2, "lengths of sort keys must be equal\n"); > ok(!lstrcmpA(p_buf, p_buf2), "sort keys must be equal\n"); > > /* test LCMAP_SORTKEY | NORM_IGNORENONSPACE */ > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY | NORM_IGNORENONSPACE, > - lower_case, -1, buf, sizeof(buf)); > + lower_case, -1, buf, sizeof(buf)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ret2 = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - lower_case, -1, buf2, sizeof(buf2)); > + lower_case, -1, buf2, sizeof(buf2)/sizeof(WCHAR)); > ok(ret2, "LCMapStringW must succeed\n"); > ok(ret == ret2, "lengths of sort keys must be equal\n"); > ok(!lstrcmpA(p_buf, p_buf2), "sort keys must be equal\n"); > > /* test LCMAP_SORTKEY | NORM_IGNORESYMBOLS */ > ret = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY | NORM_IGNORESYMBOLS, > - lower_case, -1, buf, sizeof(buf)); > + lower_case, -1, buf, sizeof(buf)/sizeof(WCHAR)); > ok(ret, "LCMapStringW must succeed\n"); > ret2 = LCMapStringW(LOCALE_USER_DEFAULT, LCMAP_SORTKEY, > - symbols_stripped, -1, buf2, sizeof(buf2)); > + symbols_stripped, -1, buf2, sizeof(buf2)/sizeof(WCHAR)); > ok(ret2, "LCMapStringW must succeed\n"); > ok(ret == ret2, "lengths of sort keys must be equal\n"); > ok(!lstrcmpA(p_buf, p_buf2), "sort keys must be equal\n"); LCMAP_SORTKEY takes the target buffer size in bytes in both A and W versions. > @@ -1332,7 +1332,7 @@ static void test_LCMapStringW(void) > > /* test srclen = 0 */ > SetLastError(0xdeadbeef); > - ret = LCMapStringW(LOCALE_USER_DEFAULT, 0, upper_case, 0, buf, sizeof(buf)); > + ret = LCMapStringW(LOCALE_USER_DEFAULT, 0, upper_case, 0, buf, sizeof(buf)/sizeof(WCHAR)); > ok(!ret, "LCMapStringW should fail with srclen = 0\n"); > ok(GetLastError() == ERROR_INVALID_PARAMETER, > "unexpected error code %d\n", GetLastError()); The size of the target buffer doesn't matter at all in this case, since the API is supposed to fail due to source length being 0. -- Dmitry.

4 7

Wineconf - final reminder!
by Jeremy White Sept. 16, 2008

Sept. 16, 2008

Folks, Just 11 days until Wineconf. Come celebrate Wine 1.0! http://wiki.winehq.org/WineConf2008 I'll start up a thread for RSVPs and such on the wineconf mailing list. Cheers, Jeremy

1 0

Re: winemenubuilder: eliminate wineshelllink (try 5)
by Alexandre Julliard Sept. 16, 2008

Sept. 16, 2008

"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes: > + do > + { > + line = HeapAlloc(GetProcessHeap(), 0, size); > + if (!line) > + return NULL; > + ret = fgets(line, size, file); > + if (ret != NULL) > + { > + if (strlen(line) < size - 1) > + return line; > + size *= 2; > + } > + HeapFree(GetProcessHeap(), 0, line); > + } while (ret != NULL); This won't do what you want. > + char *line; > + while ((line = next_line(originalMenu)) != NULL) > + { > + if (strstr(line, "<Filename>")) > + { > + if (strstr(line, name)) > + found = TRUE; > + fprintf(tempfile, "%s", line); > + } strstr is not appropriate for comparing file names. Also you are leaking memory here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Fwd: Implementing d3dx9_36.dll.D3DXCreateTexture
by Andrew Fenn Sept. 16, 2008

Sept. 16, 2008

D3DXCheckTextureRequirements has already been implemented and a patch was submitted here: http://www.winehq.org/pipermail/wine-patches/2008-April/053547.html Please check it out. On Tue, Sep 16, 2008 at 2:20 PM, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > For basic operation just forwarding to the d3d9 CreateTexture call should work fine but note the following: > "Internally, D3DXCreateTexture uses D3DXCheckTextureRequirements to adjust the calling parameters. Therefore, calls to D3DXCreateTexture will often succeed where calls to IDirect3DDevice9::CreateTexture would fail." > > As a start I wouldn't add that behavior but add a comment that the function isn't complete and what is missing. I would also print a FIXME about it but only show it once in total (so use a static variable). > > Roderick > >> Hi list, >> >> I'm trying to get a DirectX model viewer[1] to run. Using wine 1.1.4 it >> is possible to lauch because d3dx9_36.dll exists but a method >> (CreateTexture) of it is stubbed out. I started looking for details on >> this and came up with this MSDN link[2]. Looking at the code I found >> that this method is already implemented in the core d3d9 library in >> dlls/d3d9/texture.c. From what I understand a forward to this function >> should be enough to get this method to work since the parameters seem to >> match (except the last parameter in the core d3d9 (HANDLE* >> pSharedHandle) does not exist in the MSDN definition). >> >> Can someone please comment if my thoughts are right here? >> >> Thanks, >> Christoph >> >> [1] http://www.teamxtcgames.com/3d_object_viewer.htm >> [2] http://msdn.microsoft.com/en-us/library/bb172800(VS.85).aspx >> >> > > -- > GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! > http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/61691… > > >

1 0

Implementing d3dx9_36.dll.D3DXCreateTexture
by Christoph Brill Sept. 16, 2008

Sept. 16, 2008

Hi list, I'm trying to get a DirectX model viewer[1] to run. Using wine 1.1.4 it is possible to lauch because d3dx9_36.dll exists but a method (CreateTexture) of it is stubbed out. I started looking for details on this and came up with this MSDN link[2]. Looking at the code I found that this method is already implemented in the core d3d9 library in dlls/d3d9/texture.c. From what I understand a forward to this function should be enough to get this method to work since the parameters seem to match (except the last parameter in the core d3d9 (HANDLE* pSharedHandle) does not exist in the MSDN definition). Can someone please comment if my thoughts are right here? Thanks, Christoph [1] http://www.teamxtcgames.com/3d_object_viewer.htm [2] http://msdn.microsoft.com/en-us/library/bb172800(VS.85).aspx

2 1

Interesting Chromium hacks...er..patches
by Jeremy White Sept. 15, 2008

Sept. 15, 2008

We've had a lot of fun hacking on Chromium these past few weeks. We did have a few things that we rushed along to include in the CrossOver Chromium builds that haven't properly baked here on wine-devel. I thought I'd share them in case anyone else wants to match what we did. First of all, we were working against dev build 21 of Chromium, not Chrome. Note that newer builds of Chromium now work (thanks to a patch by Alexandre), but they're pretty unstable. We got our dev build from here: http://build.chromium.org/buildbot/archives/chromium.tgz We find we have to have both Times and Arial (or replacements in the registry) in order for it to run stably. We have 3 winhttp patches we used that we're going to clean up and get into WineHQ properly, but here they are in raw form: winhttp_reset_content_length.diff fixes a glitch in winhttp on redirects. winhttp_flags.diff fixes a fairly obvious mistake (and turns out to be the gating factor for gmail support) winhttp_cookies.diff is the beginning of a cookie manager; Hans is still working on this one. Also, we used the following ...er...patches: focus.diff (hack by Alexandre, makes single tabs work okay) gdi hack by Huw, makes the map hand on maps.google.com not a blob Cheers, Jeremy

1 0

General Questions
by Scott Lindeneau Sept. 15, 2008

Sept. 15, 2008

I haven't had time to work on the AcceptEx patch since the last time I submitted it to wine-patches. I still cannot reproduce the bug's patchwatcher indicated but I had a few questions regarding the whole process. When I finally get the patches to pass the patchwatcher regression test, is there anyway for me to know what is going on with the patch. Is Juilliard looking at them? Are they rejected? How long does the patch review process take? Is it just Julliard doing them? In regards to the AcceptEx patch in particular: I know that there is extra attention paid to patches that modify the wineserver. Should I spend extra time writing a discussion as to the reasons why I felt the modifications needed to take place within the wineserver? With the AcceptEx patch I kind of just plowed ahead and did what I thought needed to be done to make the functions work. Should I spend more time discussing what I intend to do in the patches with someone else before submitting them? Is someone willing to do this peer review with me? (Note: I don't have a lot of time to program). And lastly: Am I doing anything wrong (in general. not simply in coding)? I don't know how these internet based, user based systems work. I've never tried working with one before. Is there anything else someone wants me to work on? ~Scott

2 1

re: Patchwatcher should ignore AppDB patches
by Dan Kegel Sept. 15, 2008

Sept. 15, 2008

Right, it should ignore those patches. I'm going to add a configurable regular expression to the patch detector to let it do that. (That is, when I get a chance. I'm cranking on native Chrome these days.)

1 0

Patchwatcher should ignore AppDB patches
by Alexander Nicolaysen Sørnes Sept. 15, 2008

Sept. 15, 2008

I just sent a patch for the AppDB, and was told it didn't apply to Wine. That was never the intention, of course. Perhaps it can ignore mails with [AppDB] in the subject line, or patches containing .php files? Alexander N. Sørnes

5 5

Re: kernel32: Implemented GetSystemTimes
by Rob Shearman Sept. 15, 2008

Sept. 15, 2008

2008/9/14 Martin Bailey <martin(a)pcalpha.com>: > +VOID WINAPI GetSystemTimes( > + LPFILETIME lpIdleTime, > + LPFILETIME lpKernelTime, > + LPFILETIME lpUserTime) > +{ > + struct tms tms; > + times(&tms); > + /* FIXME: Calculate based on Idle process time > + if (lpIdleTime) > + TIME_ClockTimeToFileTime(tms.tms_utime+tms.tms_stime,lpIdleTime); > + */ You still have to set lpIdleTime to something, even if it isn't implemented yet, as applications will expect the value to be initialised. -- Rob Shearman

1 0

Re: winemenubuilder: eliminate wineshelllink (try 4)
by Alexandre Julliard Sept. 15, 2008

Sept. 15, 2008

"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes: > + char dir_file_name[MAX_PATH]; > + struct stat st; > + name[i] = 0; > + fprintf(tempfile, " <Menu>\n"); > + fprintf(tempfile, " <Name>%s%s</Name>\n", count ? "" : "wine-", name); > + fprintf(tempfile, " <Directory>%s%s.directory</Directory>\n", count ? "" : "wine-", name); > + snprintf(dir_file_name, sizeof(dir_file_name), "%s/desktop-directories/%s%s.directory", > + xdg_data_dir, count ? "" : "wine-", name); You still have a MAX_PATH buffer here for a Unix file name. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: oleaut32[3/3]: VT_USERDEFINED records are passed by value (with testcase, fixes bug #14639)
by Alexandre Julliard Sept. 15, 2008

Sept. 15, 2008

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > +const MYSTRUCT MYSTRUCT_BYVAL = {0x12345678, 0xdeadbeef98765432ULL}; > +const MYSTRUCT MYSTRUCT_BYPTR = {0x91827364, 0x8877665544332211ULL}; > +const MYSTRUCT MYSTRUCT_ARRAY[5] = { > + {0x1a1b1c1d, 0x1e1f101112131415ULL}, > + {0x2a2b2c2d, 0x2e2f202122232425ULL}, > + {0x3a3b3c3d, 0x3e3f303132333435ULL}, > + {0x4a4b4c4d, 0x4e4f404142434445ULL}, > + {0x5a5b5c5d, 0x5e5f505152535455ULL}, > +}; long long constants are not portable, please avoid them. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shlwapi: Implement SHSendMessageBroadcastW
by Dmitry Timoshkov Sept. 15, 2008

Sept. 15, 2008

"Detlef Riekenberg" <wine.dev(a)web.de> wrote: > inetcpl crash, when setting a new Homepage. > (need URLSubRegQueryA and ParseURLFromOutsideSourceW) > > MSDN documented SHSendMessageBroadcast to be the same as > SendMessage(HWND_BROADCAST,...) Why not implement SHSendMessageBroadcastA at the same time? -- Dmitry.

1 0