June 2009 - Wine-Devel - list.winehq.org

Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
by chris ahrendt June 6, 2009

June 6, 2009

On 06/05/2009 09:16 PM, Austin English wrote: > On Fri, Jun 5, 2009 at 8:03 PM, chris ahrendt<celticht32(a)yahoo.com> wrote: > >> On 06/05/2009 08:15 PM, Austin English wrote: >> >>> On Fri, Jun 5, 2009 at 7:11 PM, chris ahrendt<celticht32(a)yahoo.com> wrote: >>> >>> >>>> Tried it several times.. and different iterations of the registry keys >>>> (you will find them attached) and both cases it fails the same way any >>>> of the d3d tests will fail or the machine locks up. >>>> >>>> >>> >> ???????? >> > Use that attached .reg file. > > > Which one I attached two and neither of them worked at all.. Chris

1 0

Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
by chris ahrendt June 6, 2009

June 6, 2009

Tried it several times.. and different iterations of the registry keys (you will find them attached) and both cases it fails the same way any of the d3d tests will fail or the machine locks up.

2 1

Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
by chris ahrendt June 5, 2009

June 5, 2009

On 06/05/2009 05:10 PM, Roderick Colenbrander wrote: > Check the useful registry keys page at wiki.winehq.org (it is > Direct3D/OffscreenRenderingMethod) > > Roderick > > On Fri, Jun 5, 2009 at 10:41 PM, chris ahrendt<celticht32(a)yahoo.com> wrote: > >> On 06/05/2009 04:32 PM, Roderick Colenbrander wrote: >> >>> As of Wine 1.1.23 wined3d made FBOs the default offscreen rendering >>> method. If you are using a non-nvidia card (those in general have >>> buggier drivers) that could explain all the failures. Setting >>> OffscreenRenderingMethod to backbuffer restores the old behavior. >>> >>> Roderick >>> >>> On Fri, Jun 5, 2009 at 10:04 PM, chris ahrendt<celticht32(a)yahoo.com> wrote: >>> >>> >>>> Something majorly changed and is wrong with the latest GIT tree. >>>> Between the comits yesterday and today 90% of the tests get exceptions >>>> or fail. >>>> All of the d3d tests get a process exception and fail with a dialog box. >>>> >>>> >>>> Ideas? >>>> >>>> Chris >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> where do I set that? >> >> >> >> >> >> >> >> >> > > Added the registry key and no go... still failure... Chris

1 0

Re: Alexandre Julliard : winegcc: Create a stub main to work around the lack of Unicode support in Mingw.
by Steven Edwards June 5, 2009

June 5, 2009

On Fri, Jun 5, 2009 at 9:56 AM, Alexandre Julliard<julliard(a)winehq.org> wrote: > winegcc: Create a stub main to work around the lack of Unicode support in Mingw. Thank you. The mingw developers policy opposing adding this entry point baffles me. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

Re: Latest Git build 7aeffc442cc1 for Wine 1.1.23
by chris ahrendt June 5, 2009

June 5, 2009

On 06/05/2009 04:32 PM, Roderick Colenbrander wrote: > As of Wine 1.1.23 wined3d made FBOs the default offscreen rendering > method. If you are using a non-nvidia card (those in general have > buggier drivers) that could explain all the failures. Setting > OffscreenRenderingMethod to backbuffer restores the old behavior. > > Roderick > > On Fri, Jun 5, 2009 at 10:04 PM, chris ahrendt<celticht32(a)yahoo.com> wrote: > >> Something majorly changed and is wrong with the latest GIT tree. >> Between the comits yesterday and today 90% of the tests get exceptions >> or fail. >> All of the d3d tests get a process exception and fail with a dialog box. >> >> >> Ideas? >> >> Chris >> >> >> >> >> >> >> >> >> >> >> > > where do I set that?

2 1

Latest Git build 7aeffc442cc1 for Wine 1.1.23
by chris ahrendt June 5, 2009

June 5, 2009

Something majorly changed and is wrong with the latest GIT tree. Between the comits yesterday and today 90% of the tests get exceptions or fail. All of the d3d tests get a process exception and fail with a dialog box. Ideas? Chris

2 1

Regression in "ntdll: Free old memory"
by Niklas Hambüchen June 5, 2009

June 5, 2009

There is something wrong with commit 13a33b73c349530b17347d3ec6a1f5bb268cc917 (ntdll: Free old memory block when reallocating to a large block.). Having this this patch applied (as it is in wine-1.1.22), some applications show a strange behavior, for example Guild Wars does not start up (it keeps "repairing" on and on). git revert 13a33b73c349530b17347d3ec6a1f5bb268cc917 does the trick, but most probably this is not the solution. The regression test was: 13a33b73c349530b17347d3ec6a1f5bb268cc917 is first bad commit commit 13a33b73c349530b17347d3ec6a1f5bb268cc917 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Sat May 16 11:33:06 2009 +0200 ntdll: Free old memory block when reallocating to a large block. :040000 040000 e210ab3f16dee6da3a6b6b34d375737b103d5951 25abcf5a437d9a494593e654553dd2797066f616 M dlls Thank you!

2 2

Re: mpr: Added an implementation of test cases
by Stefan Leichter June 5, 2009

June 5, 2009

Am Friday 05 June 2009 17:27:32 schrieb Vitaly Perov: You need to check if GetProcAddress succeeded. If GetProcAddress failed call win_skip and don't try to execute WNetGetUniversalNameW -- Stefan

2 1

Re: [08/10] wined3d: Use FBOs for offscreen rendering by default.
by paulo lesgaz June 5, 2009

June 5, 2009

The point is that the tests are uncorrect: Here is I obtain in a real windows Vista box: http://test.winehq.org/data/8d0cb61bc7760c4ab254c3a5bb751bded3a6f4ed/vista_… visual.c:183: Driver string: "nvd3dum.dll" visual.c:184: Description string: "NVIDIA GeForce Go 7600" visual.c:185: Device name string: "\\.\DISPLAY1" visual.c:186: Driver version 7.15.11.7692 visual.c:8868: Tests skipped: D3DFMT_R16F textures not supported visual.c:7572: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests visual.c:9690: Test failed: Input 0xff000000: Got color 0x00008700 for pixel 2/1, expected 0x004bff1c, format D3DFMT_UYVY visual.c:9690: Test failed: Input 0x0000ff00: Got color 0x004bff1c for pixel 2/1, expected 0x00008700, format D3DFMT_UYVY visual.c:9690: Test failed: Input 0xffff0000: Got color 0x00b30000 for pixel 2/1, expected 0x00ffd01c, format D3DFMT_UYVY visual.c:9690: Test failed: Input 0xff0000ff: Got color 0x000030e1 for pixel 2/1, expected 0x004bffff, format D3DFMT_UYVY visual.c:9690: Test failed: Input 0x00ffff00: Got color 0x00ffd01c for pixel 2/1, expected 0x00b30000, format D3DFMT_UYVY visual.c:9690: Test failed: Input 0x0000ffff: Got color 0x004bffff for pixel 2/1, expected 0x000030e1, format D3DFMT_UYVY visual.c:9690: Test failed: Input 0xffff00ff: Got color 0x00b300e1 for pixel 2/1, expected 0x00ff79ff, format D3DFMT_UYVY visual.c:9686: Test failed: Input 0x00000000: Got color 0x00000000 for pixel 1/1, expected 0x00008700, format D3DFMT_YUY2 visual.c:9690: Test failed: Input 0x00000000: Got color 0x00000000 for pixel 2/1, expected 0x00008700, format D3DFMT_YUY2 visual.c:9686: Test failed: Input 0xff000000: Got color 0x00000000 for pixel 1/1, expected 0x00b30000, format D3DFMT_YUY2 visual.c:9690: Test failed: Input 0xff000000: Got color 0x00000000 for pixel 2/1, expected 0x00b30000, format D3DFMT_YUY2 visual.c:9686: Test failed: Input 0x00ff0000: Got color 0x00000000 for pixel 1/1, expected 0x00008700, format D3DFMT_YUY2 visual.c:9690: Test failed: Input 0x00ff0000: Got color 0x00000000 for pixel 2/1, expected 0x004bff1c, format D3DFMT_YUY2 visual.c:9686: Test failed: Input 0x0000ff00: Got color 0x00000000 for pixel 1/1, expected 0x000030e1, format D3DFMT_YUY2 visual.c:9690: Test failed: Input 0x0000ff00: Got color 0x00000000 for pixel 2/1, expected 0x000030e1, format D3DFMT_YUY2 visual.c:9686: Test failed: Input 0x000000ff: Got color 0x00000000 for pixel 1/1, expected 0x004bff1c, format D3DFMT_YUY2 visual.c:9690: Test failed: Input 0x000000ff: Got color 0x00000000 for pixel 2/1, expected 0x00008700, format D3DFMT_YUY2 visual.c:9686: Test failed: Input 0xffff0000: Got color 0x00000000 for pixel 1/1, expected 0x00b30000, format D3DFMT_YUY2 visual.c:9690: Test failed: Input 0xffff0000: Got color 0x00000000 for pixel 2/1, expected 0x00ffd01c, format D3DFMT_YUY2 So, something is wrong in wined3d implementation. David --- En date de : Ven 5.6.09, Alexandre Julliard <julliard(a)winehq.org> a écrit : De: Alexandre Julliard <julliard(a)winehq.org> Objet: Re: [08/10] wined3d: Use FBOs for offscreen rendering by default. À: "Henri Verbeet" <hverbeet(a)codeweavers.com> Cc: wine-devel(a)winehq.org Date: Vendredi 5 Juin 2009, 14h38 Henri Verbeet <hverbeet(a)codeweavers.com> writes: > Alexandre Julliard wrote: >> It doesn't work here: >> >> ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok >> visual.c:7572: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests >> visual.c:9686: Test failed: Input 0x00000000: Got color 0x00000000 for pixel 1/1, expected 0x00008700, format D3DFMT_UYVY >> visual.c:9690: Test failed: Input 0x00000000: Got color 0x00000000 for pixel 2/1, expected 0x00008700, format D3DFMT_UYVY >> visual.c:9686: Test failed: Input 0xff000000: Got color 0x00000000 for pixel 1/1, expected 0x00008700, format D3DFMT_UYVY >> visual.c:9690: Test failed: Input 0xff000000: Got color 0x00000000 for pixel 2/1, expected 0x004bff1c, format D3DFMT_UYVY >> visual.c:9686: Test failed: Input 0x00ff0000: Got color 0x00000000 for pixel 1/1, expected 0x00b30000, format D3DFMT_UYVY >> visual.c:9690: Test failed: Input 0x00ff0000: Got color 0x00ffffff for pixel 2/1, expected 0x00b30000, format D3DFMT_UYVY >> visual.c:9686: Test failed: Input 0x0000ff00: Got color 0x00000000 for pixel 1/1, expected 0x004bff1c, format D3DFMT_UYVY >> [...many more...] >> make: *** [visual.ok] Error 72 >> > Does the attached patch make it any better? Yes, that fixes it. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [2/5] msi: Initialize some variables.
by Austin English June 5, 2009

June 5, 2009

On Thu, Jun 4, 2009 at 3:12 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > > diff --git a/dlls/msi/registry.c b/dlls/msi/registry.c > index 3ba34d1..f22c01f 100644 > --- a/dlls/msi/registry.c > +++ b/dlls/msi/registry.c > @@ -1822,7 +1822,7 @@ static UINT msi_check_product_patches(LPCWSTR prodcode, LPCWSTR usersid, > LPWSTR patch, LPWSTR targetprod, MSIINSTALLCONTEXT *targetctx, > LPWSTR targetsid, DWORD *sidsize, LPWSTR *transforms) > { > - MSIPATCHSTATE state; > + MSIPATCHSTATE state = MSIPATCHSTATE_INVALID; > LPWSTR ptr, patches = NULL; > HKEY prod, patchkey = 0; > HKEY localprod = 0, localpatch = 0; > diff --git a/dlls/msi/tests/package.c b/dlls/msi/tests/package.c > index a9eef76..3263ec1 100644 > --- a/dlls/msi/tests/package.c > +++ b/dlls/msi/tests/package.c > @@ -939,6 +939,7 @@ static void test_settargetpath(void) > sz = sizeof tempdir - 1; > r = MsiGetTargetPath( hpkg, "TARGETDIR", tempdir, &sz ); > sprintf( file, "%srootfile.txt", tempdir ); > + buffer[0] = 0; > query_file_path( hpkg, "[#RootFile]", buffer ); > ok( r == ERROR_SUCCESS, "failed to get target path: %d\n", r); > ok( !lstrcmp(buffer, file), "Expected %s, got %s\n", file, buffer ); > @@ -11057,8 +11058,8 @@ static void test_access(void) > > static void test_emptypackage(void) > { > - MSIHANDLE hpkg, hdb, hsuminfo; > - MSIHANDLE hview, hrec; > + MSIHANDLE hpkg = 0, hdb = 0, hsuminfo = 0; > + MSIHANDLE hview = 0, hrec = 0; > MSICONDITION condition; > CHAR buffer[MAX_PATH]; > DWORD size; > > > Howdy Hans, One of your recent msi patches (I suspect this one), causes several hundred failures/succeeding todo's on my previously passing box. Could you have a look: http://test.winehq.org/data/1a0a47d60c337ca096c26da291adf82e49770f34/wine_a… -- -Austin

2 2

Re: [3/3] wininet: Add missing empty line to end of headers list
by Alexandre Julliard June 5, 2009

June 5, 2009

Jason Green <jave27(a)gmail.com> writes: > @@ -4265,6 +4265,24 @@ static INT HTTP_GetResponseHeaders(LPWININETHTTPREQW lpwhr, BOOL clear) > } > }while(1); > > + /* make sure the response header is terminated with an empty line. Some apps really > + truly care about that empty line being there for some reason. If it's not present, > + just add it to the header. */ > + if (cchRawHeaders >= 4 && > + (strcmpW(&lpszRawHeaders[cchRawHeaders - 4], szCrLf) || > + strcmpW(&lpszRawHeaders[cchRawHeaders - 2], szCrLf))) > + { This check doesn't seem necessary, I don't see how you could already have an empty line in the buffer since we only store valid headers. -- Alexandre Julliard julliard(a)winehq.org

2 2

Implementation of User32.PrintWindow - Try 2
by Josselin Bardet June 5, 2009

June 5, 2009

Hi Second proposition patch for User32.PrintWindows Regards Jos

1 0

Implementation of the User32.PrintWindow
by Josselin Bardet June 5, 2009

June 5, 2009

Hi, As next of the discussion on the bug 18772 (http://bugs.winehq.org/show_bug.cgi?id=18772) I send here the implemenation for User32.PrintWindow function I've tested it with an application that was crashing because of this unimplemented function. Regards Jos

2 4

Re: [08/10] wined3d: Use FBOs for offscreen rendering by default.
by Alexandre Julliard June 5, 2009

June 5, 2009

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > From f8dd196de73ca81019b01f3fdae56b47985e63b6 Mon Sep 17 00:00:00 2001 > From: Henri Verbeet <hverbeet(a)codeweavers.com> > Date: Fri, 5 Jun 2009 10:10:48 +0200 > Subject: wined3d: Use FBOs for offscreen rendering by default. It doesn't work here: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:7572: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests visual.c:9686: Test failed: Input 0x00000000: Got color 0x00000000 for pixel 1/1, expected 0x00008700, format D3DFMT_UYVY visual.c:9690: Test failed: Input 0x00000000: Got color 0x00000000 for pixel 2/1, expected 0x00008700, format D3DFMT_UYVY visual.c:9686: Test failed: Input 0xff000000: Got color 0x00000000 for pixel 1/1, expected 0x00008700, format D3DFMT_UYVY visual.c:9690: Test failed: Input 0xff000000: Got color 0x00000000 for pixel 2/1, expected 0x004bff1c, format D3DFMT_UYVY visual.c:9686: Test failed: Input 0x00ff0000: Got color 0x00000000 for pixel 1/1, expected 0x00b30000, format D3DFMT_UYVY visual.c:9690: Test failed: Input 0x00ff0000: Got color 0x00ffffff for pixel 2/1, expected 0x00b30000, format D3DFMT_UYVY visual.c:9686: Test failed: Input 0x0000ff00: Got color 0x00000000 for pixel 1/1, expected 0x004bff1c, format D3DFMT_UYVY [...many more...] make: *** [visual.ok] Error 72 -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: try3 [1/2] kernel32/tests: Fix tests to pass on Win9x and WinME
by Alexandre Julliard June 5, 2009

June 5, 2009

Guy Albertelli <galberte(a)neo.rr.com> writes: > Changelog > - Fix new tests for CreateFileA to pass on Win9x and WinME > - Fix tests for when GetVolumeNameForVolumeMountPointA fails. Please send separate changes as separate patches. > @@ -829,13 +830,17 @@ static void test_CreateFileA(void) > } > /* otherwise validate results with expectations */ > else if (p[i].todo_flag) > - todo_wine ok((hFile == INVALID_HANDLE_VALUE && p[i].err == GetLastError()) || > + todo_wine ok( > + (hFile == INVALID_HANDLE_VALUE && (p[i].err == GetLastError() || > + (p[i].err2 == -1 ? TRUE : p[i].err2 == GetLastError()))) || Please don't use -1 for DWORD values. Also your check will make the test useless for cases that have only one possible error. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: mlang/tests: Fix failures with IE 5.5 and below
by Paul Vriens June 5, 2009

June 5, 2009

Detlef Riekenberg wrote: > On Mi, 2009-06-03 at 10:50 +0200, Paul Vriens wrote: >> This patch introduces test failures on what seems: >> >> - all Win95 boxes >> - some Win98 boxes >> - some W2K boxes > >> Could you have a look? > > Here is a fix. > > Hi Detlef, Is there no way to have a broken() in here: + /* IE <6.0 guess 0x412 (ko) from "kok" */ + if (lcid_table[i].alternate_lcid && (lcid_table[i].lcid != -1)) { + ok(ret == S_OK || ret == S_FALSE, + "#%02d: HRESULT 0x%x (expected S_OK or S_FALSE)\n", i, ret); and the same a bit further down? -- Cheers, Paul.

1 0

Re: gdiplus: Stub for GdipCreateBitmapFromDirectDrawSurface
by Alexandre Julliard June 5, 2009

June 5, 2009

Andrew Eikum <andrew(a)brightnightgames.com> writes: > diff --git a/include/gdiplusflat.h b/include/gdiplusflat.h > index 501e6ed..4ba329f 100644 > --- a/include/gdiplusflat.h > +++ b/include/gdiplusflat.h > @@ -27,6 +27,8 @@ > extern "C" { > #endif > > +#include <ddraw.h> gdiplusflat.h is not supposed to depend on ddraw.h. -- Alexandre Julliard julliard(a)winehq.org

2 1

Implementation of the User32.PrintWindow
by Josselin Bardet June 4, 2009

June 4, 2009

Hi, As next of the discussion on the bug 18772 (http://bugs.winehq.org/show_bug.cgi?id=18772) I send here the implemenation for User32.PrintWindow function I've tested it with an application that was crashing because of this unimplemented function. Regards Jos

1 0

Today's git may have a problem -- install takes forever then crashes
by Susan Cragin June 4, 2009

June 4, 2009

Today's git starts the installation of DNS very-very slowly. Then takes forever. I thought finally it was going to install but then it crashes at/near the end. Tail of log below. fixme:ole:CoCreateInstance no instance created for interface {d94a9b75-516c-41ec-8163-f1ac8ab03b29} of class {fff2d28f-e4ee-44d9-8104-8e71556757f6}, hres is 0xc0000005 wine: Unhandled page fault on read access to 0x00000000 at address 0x412f7d (thread 007d), starting debugger... susan(a)ubuntu:~/DNS$ Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00412f7d). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:00412f7d ESP:0033fb00 EBP:0033fe6c EFLAGS:00210212( R- -- I -A- - ) EAX:00000000 EBX:00000000 ECX:00000000 EDX:00000000 ESI:00475908 EDI:0046f754 Stack dump: 0x0033fb00: 001300fc 00000004 0044a687 00000000 0x0033fb10: 7b8c5ff4 0012fa88 0033fb38 7ffdf000 0x0033fb20: 7e1cfff4 00000001 7e1bc63b 7e1cfff4 0x0033fb30: 00000001 7e190000 0033fb78 7e1b1ff7 0x0033fb40: 00000003 7e1d7928 7e1c9207 7e1c7822 0x0033fb50: 7e190000 00000001 00000000 00000000 Backtrace: =>0 0x00412f7d in agent (+0x12f7d) (0x0033fe6c) 1 0x0044a767 in agent (+0x4a767) (0x0033fef8) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value szNlsKeyName (a) 2 0x7b8778ef start_process+0xdf(arg=(nil)) [/home/susan/wine/dlls/kernel32/process.c:941] in kernel32 (0x0033ffe8) 0x00412f7d: movl 0x0(%eax),%ecx Modules: Module Address Debug info Name (69 modules) PE 400000- 491000 Export agent ELF 7b800000-7b962000 Dwarf kernel32<elf> \-PE 7b820000-7b962000 \ kernel32 ELF 7bc00000-7bcb9000 Deferred ntdll<elf> \-PE 7bc10000-7bcb9000 \ ntdll ELF 7bf00000-7bf04000 Deferred <wine-loader> ELF 7e15e000-7e182000 Deferred mpr<elf> \-PE 7e160000-7e182000 \ mpr ELF 7e182000-7e1d8000 Deferred wininet<elf> \-PE 7e190000-7e1d8000 \ wininet ELF 7e226000-7e25a000 Deferred uxtheme<elf> \-PE 7e230000-7e25a000 \ uxtheme ELF 7e25a000-7e265000 Deferred libxcursor.so.1 ELF 7e265000-7e26b000 Deferred libxfixes.so.3 ELF 7e26b000-7e26f000 Deferred libxcomposite.so.1 ELF 7e26f000-7e278000 Deferred libxrandr.so.2 ELF 7e278000-7e282000 Deferred libxrender.so.1 ELF 7e282000-7e288000 Deferred libxxf86vm.so.1 ELF 7e288000-7e28b000 Deferred libxinerama.so.1 ELF 7e28b000-7e2ad000 Deferred imm32<elf> \-PE 7e290000-7e2ad000 \ imm32 ELF 7e2ad000-7e2b2000 Deferred libxdmcp.so.6 ELF 7e2b2000-7e2d0000 Deferred libxcb.so.1 ELF 7e2d0000-7e2d4000 Deferred libxau.so.6 ELF 7e2d4000-7e2d9000 Deferred libuuid.so.1 ELF 7e2d9000-7e409000 Deferred libx11.so.6 ELF 7e409000-7e419000 Deferred libxext.so.6 ELF 7e419000-7e434000 Deferred libice.so.6 ELF 7e434000-7e43d000 Deferred libsm.so.6 ELF 7e44d000-7e4ef000 Deferred winex11<elf> \-PE 7e460000-7e4ef000 \ winex11 ELF 7e51c000-7e543000 Deferred libexpat.so.1 ELF 7e543000-7e570000 Deferred libfontconfig.so.1 ELF 7e580000-7e596000 Deferred libz.so.1 ELF 7e596000-7e615000 Deferred libfreetype.so.6 ELF 7e615000-7e629000 Deferred lz32<elf> \-PE 7e620000-7e629000 \ lz32 ELF 7e629000-7e644000 Deferred version<elf> \-PE 7e630000-7e644000 \ version ELF 7e644000-7e73b000 Deferred oleaut32<elf> \-PE 7e660000-7e73b000 \ oleaut32 ELF 7e73b000-7e7ad000 Deferred rpcrt4<elf> \-PE 7e750000-7e7ad000 \ rpcrt4 ELF 7e7ad000-7e8bd000 Deferred ole32<elf> \-PE 7e7d0000-7e8bd000 \ ole32 ELF 7e8bd000-7e98b000 Deferred comctl32<elf> \-PE 7e8d0000-7e98b000 \ comctl32 ELF 7e98b000-7e9ee000 Deferred shlwapi<elf> \-PE 7e9a0000-7e9ee000 \ shlwapi ELF 7e9ee000-7eb83000 Deferred shell32<elf> \-PE 7ea00000-7eb83000 \ shell32 ELF 7eb83000-7ec2e000 Deferred gdi32<elf> \-PE 7eb90000-7ec2e000 \ gdi32 ELF 7ec2e000-7ed8a000 Deferred user32<elf> \-PE 7ec50000-7ed8a000 \ user32 ELF 7ed8a000-7ee14000 Deferred crypt32<elf> \-PE 7ed90000-7ee14000 \ crypt32 ELF 7ee14000-7ee6e000 Deferred advapi32<elf> \-PE 7ee20000-7ee6e000 \ advapi32 ELF 7ee6e000-7ee87000 Deferred libnsl.so.1 ELF 7ee87000-7ee90000 Deferred libnss_compat.so.2 ELF 7efca000-7eff0000 Deferred libm.so.6 ELF 7eff4000-7f000000 Deferred libnss_files.so.2 ELF b7c40000-b7c4b000 Deferred libnss_nis.so.2 ELF b7c4d000-b7c51000 Deferred libdl.so.2 ELF b7c51000-b7db4000 Deferred libc.so.6 ELF b7db5000-b7dce000 Deferred libpthread.so.0 ELF b7dde000-b7f1b000 Deferred libwine.so.1 ELF b7f1d000-b7f3b000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000c 00000012 0 0000000e 0 0000000d 0 0000000f 00000015 0 00000014 0 00000011 0 00000010 0 00000016 00000017 0 0000007c 0000002c 0 0000008b 0 00000093 0 0000008f 0 00000088 0 00000082 0 00000083 0 00000081 0 0000007f 0 00000096 0000007b 0 0000008c (D) C:\Program Files\Common Files\InstallShield\UpdateService\agent.exe 0000000b 0 0000008d 0 0000007d 0 <== Backtrace: =>0 0x00412f7d in agent (+0x12f7d) (0x0033fe6c) 1 0x0044a767 in agent (+0x4a767) (0x0033fef8) 2 0x7b8778ef start_process+0xdf(arg=(nil)) [/home/susan/wine/dlls/kernel32/process.c:941] in kernel32 (0x0033ffe8) susan(a)ubuntu:~/DNS$

1 0

re: wine question
by Dan Kegel June 4, 2009

June 4, 2009

Anna wrote: > I am trying to call Win32 Dll (that is built in VS 2003) from C++ > Linux application ( in Ubuntu ) through wine shared object without > rebuild the application with wine. Sorry, it's not generally possible to use Windows libraries inside a Linux program directly with Wine. Wine is jealous, and wants control of the whole program right from the start. Your main options are: 1) write a small Windows program that uses the DLL, run it via Wine, and talk to it from the Linux program using sockets and/or shared memory 2) run the Windows version of the app altogether in Wine There are ways to do what you want directly without Wine, but only for very restricted types of DLLs that do not make any Windows system calls. What does the DLL do? - Dan

1 0

[RESEND] mountmgr.sys: implement forced setting of fixed/local disk
by Ben Klein June 4, 2009

June 4, 2009

define_unix_drive in mountmgr.c includes all cases used in query_unix_drive except the DRIVE_FIXED == DEVICE_HARDDISK_VOL mapping. This patch fixes 17618 where setting the drive type to "Local disk" in winecfg does not save the change to the registry. I've CC'd wine-devel in the hope of getting some feedback this time. This is the 3rd or 4th time I've submitted this patch.

2 3

Re: (resend, 2nd) kernel32: Implement QueryFullProcessImageNameA (2nd try)
by Alexandre Julliard June 4, 2009

June 4, 2009

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > /****************************************************************** > + * QueryFullProcessImageNameA (KERNEL32.@) > + */ > +BOOL WINAPI QueryFullProcessImageNameA(HANDLE hProcess, DWORD dwFlags, LPSTR lpExeName, PDWORD pdwSize) > +{ > + BOOL retval; > + DWORD pdwSizeW = *pdwSize; > + LPWSTR lpExeNameW = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, *pdwSize * sizeof(WCHAR)); > + > + retval = QueryFullProcessImageNameW(hProcess, dwFlags, lpExeNameW, &pdwSizeW); > + > + if(retval) { > + if(lpExeName) > + *pdwSize = FILE_name_WtoA(lpExeNameW, pdwSizeW, lpExeName, *pdwSize); > + else { > + /* this is a difference between the acsii and the unicode version (vista) > + * the unicode version crashes when the size is big enough to hold the result > + * ascii version throughs an error > + */ > + retval = FALSE; > + SetLastError(ERROR_INVALID_PARAMETER); > + } > + } I'd expect that error to be a side effect of WideCharToMultiByte, which is most likely what you want to use here. Also you have to handle buffer overflows correctly, with test cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: jscript: Fix DateConstr_value (with one argument) implementation (3/9)
by Alexandre Julliard June 4, 2009

June 4, 2009

Piotr Caban <piotr.caban(a)gmail.com> writes: > + FILETIME ft_now, ft_epoch; > + SYSTEMTIME st_epoch; > + DOUBLE time_now, time_epoch; > + > + memset(&st_epoch, 0, sizeof(SYSTEMTIME)); > + st_epoch.wYear = 1970; > + st_epoch.wMonth = 1; > + st_epoch.wDay = 1; > + SystemTimeToFileTime(&st_epoch, &ft_epoch); > + > + GetSystemTimeAsFileTime(&ft_now); > > - GetSystemTimeAsFileTime(&time); > + time_now = (DOUBLE)ft_now.dwHighDateTime/10000*UINT_MAX > + + (DOUBLE)ft_now.dwLowDateTime/10000; > + time_epoch = (DOUBLE)ft_epoch.dwHighDateTime/10000*UINT_MAX > + + (DOUBLE)ft_epoch.dwLowDateTime/10000; This is not correct, you need a <<32. Also there's no reason to use doubles for the computation, and you shouldn't have to use SystemTimeToFileTime for the epoch, it can be a constant. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32/tests: Add tests for message sequence of window destruction at thread exit.
by Paul Vriens June 4, 2009

June 4, 2009

Hi Alexandre, I assume you've already seen the test failures on some boxes. Looks like the WmExitThreadSeq sequence is not always the same. -- Cheers, Paul.

1 0

Re: (try2) [1/2] kernel32/tests: Add tests for CreateFile errors and opening volumes
by Paul Vriens June 4, 2009

June 4, 2009

Guy Albertelli wrote: > Changelog: > - Add tests to verify error codes returned for certain error cases. > - Also add tests for opening volumes and handle the case where we do > not have the rights to access the volume. > --- > dlls/kernel32/tests/file.c | 326 +++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 324 insertions(+), 2 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi Guy, The newly added tests introduce some failures on Win9x and WinME. Could you have a look? -- Cheers, Paul.

2 1