February 2007 - Wine-Devel - list.winehq.org

Re: [Bug 6689] Created links do not reflect WINEPREFIX used
by Lei Zhang Feb. 5, 2007

Feb. 5, 2007

Setting the Exec= line in a .desktop file to: WINEPREFIX=foo wine bar worked in KDE. In Gnome, it works if "run from the terminal" is set. Unfortunately the Freedesktop spec for desktop entries does not specify a way to add environment variables. So yes, it looks like we'll need a wrapper script, or perhaps add a --prefix option to Wine? On 1/27/07, Wine Bugs <wine-bugs(a)winehq.org> wrote: > http://bugs.winehq.org/show_bug.cgi?id=6689 > > > > > > ------- Additional Comments From vitaliy(a)kievinfo.com 2007-28-01 01:49 ------- > This is not going to work - it's not standard compliant. And I think it won't > work on Gnome either. The only way this can be fixed atm is using some wrapper > script. > > -- > Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > >

4 4

Re: [msvcrt] properly align struct _stati64's st_size
by Dmitry Timoshkov Feb. 5, 2007

Feb. 5, 2007

"Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > In wine's struct _stati64, st_size has an offset of 20 bytes from the > beginning of the struct, unlike mingw's and Window's 24. This breaks > Java 1.4.x pretty badly, it dies on startup complaining about a > truncated class file (#2953). Using #include <pshpack8.h> and #include > <pshpop8.h> around the struct didn't help, so a padding field was used > instead. Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to align the Size field help? #include <pshpack8.h> typedef struct _WIN32_STREAM_ID { DWORD dwStreamId; DWORD dwStreamAttributes; LARGE_INTEGER DECLSPEC_ALIGN(8) Size; DWORD dwStreamNameSize; WCHAR cStreamName[ANYSIZE_ARRAY]; } WIN32_STREAM_ID, *LPWIN32_STREAM_ID; #include <poppack.h> > +static void test_stat( void ) > +{ > + int offset = offsetof(struct _stati64, st_size); > + ok(offset == 24, "struct _stati64's st_size is misaligned, got %d, expected 24\n", offset); > +} This should be a part of auto generated header tests. Have a look at dlls/*/tests/generated.c files. -- Dmitry.

3 6

Re: Synchronize code page 20127 table with Windows one
by Robert Shearman Feb. 5, 2007

Feb. 5, 2007

Dmitry Timoshkov wrote: > The problem is that our translation table for code page 20127 is different from > what Windows has, and the ansi_buf get mangled. Attached patch synchronizes our > code page 20127 table with Windows one and fixes the bug. If you change a codepage from a unicode.org mapping then you need to add the changed .TXT file you generated it from to the build tree and update cpmap.pl to use it. -- Rob Shearman

3 2

Re: [try3]: user32/tests: add tests for WM_SETICON - what's wrong?
by Kirill K. Smirnov Feb. 5, 2007

Feb. 5, 2007

Hi, I've asked before: What's wrong with them? Maybe, unnecessary PeekMessage in tests??? http://www.winehq.org/pipermail/wine-patches/2007-January/035044.html http://www.winehq.org/pipermail/wine-patches/2007-January/035043.html Please, answer! Do not ignore! -- Kirill

1 0

help in debugging
by Ioannis Nousias Feb. 5, 2007

Feb. 5, 2007

Hello Wine developers, I've decided to see what causes floAt's Mobile Agent[1] to fail with wine I checked the wine developers' cheatsheet to help me debug the application, but I'm lost. The application installs but with some error: "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll Unable to register the DLL/OCX: LoadLibrary failed; code 126 Module not found." I click "ignore" and the installation continues. When I try to execute the installed binary "MobileAgent.exe" it fails. I invoke it like this: WINEDEBUG=+seh,+relay WINEPREFIX=/tmp/winetemp wine MobileAgent.exe no error messages are produce by the app itself. on wine's debug log I see the following, just before winedbg starts: 0009:Ret kernel32.SetEvent() retval=00000001 ret=00410759 trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 trace:seh:call_stack_handlers calling handler at 0x477d9a code=eedfade flags=1 0009:Call ntdll.RtlUnwind(0034feb8,0040427c,0034f140,00000000) ret=0040427c 0009: eax=0034f140 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b flags= 00200246 trace:seh:__regs_RtlUnwind code=eedfade flags=3 trace:seh:__regs_RtlUnwind calling handler at 0x60178400 code=eedfade flags=3 trace:seh:__regs_RtlUnwind handler at 0x60178400 returned 1 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0040427c 0009: eax=00000000 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b flags= 00200246 trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 trace:seh:call_stack_handlers calling handler at 0x69ff49 code=eedfade flags=1 trace:seh:call_stack_handlers handler at 0x69ff49 returned 1 trace:seh:call_stack_handlers calling handler at 0x4046b8 code=eedfade flags=1 0009:Call kernel32.UnhandledExceptionFilter(0034ec90) ret=004046dc wine: Unhandled exception 0x0eedfade at address 0x0000:0x6024daa0 (thread 0009), starting debugger... trace:seh:start_debugger Starting debugger "winedbg --auto 8 228" this is not the first "trace:seh". Relatively early in the call stack there is this: 000b:Call user32.SetDeskWallPaper(code=c0000005 flags=0 addr=0x601b044b trace:seh:raise_exception info[0]=00000000 trace:seh:raise_exception info[1]=ffffffff trace:seh:raise_exception eax=ffffffff ebx=6011999c ecx=00000003 edx=0000ffff esi=00000000 edi=ffffffff trace:seh:raise_exception ebp=00117b98 esp=0034f61c cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010206 trace:seh:call_stack_handlers calling handler at 0x602b5540 code=c0000005 flags=0 trace:seh:__regs_RtlUnwind code=c0000005 flags=2 trace:seh:__regs_RtlUnwind calling handler at 0x602b5400 code=c0000005 flags=2 trace:seh:__regs_RtlUnwind handler at 0x602b5400 returned 1 ffffffff (invalid)) ret=6033e95f which looks suspicious to me. Am I on the right track? Unfortunately I'm not familiar with windows API or wine's underlying architecture. I need some guidance please :) I'm an experienced C/C++ programmer. thanks -Ioannis [1] http://fma.sourceforge.net/index2.htm

3 5

comctl32 kibitzers wanted
by Dan Kegel Feb. 5, 2007

Feb. 5, 2007

I and Lei Zhang, with some help from James Hawkins, are leading a group of 13 UCLA students who are writing conformance tests for comctl32. Each student picked one control, and is now busily writing getter/setter tests. In the coming few weeks we'll also try more interesting tests, like verifying that the right messages are sent in the right order. If you're interested in helping the students in any way (reviewing code before it hits wine-patches, offering suggestions on how to test tricky bits, or whatever), please let me know and I can add you to the project's mailing list. Thanks, Dan

2 1

Re: shell32: shlfileop tests: avoid buffer overflows for paths
by James Hawkins Feb. 5, 2007

Feb. 5, 2007

On 2/4/07, Mikołaj Zalewski <mikolaj(a)zalewski.pl> wrote: > These buffers can contain multiple paths and set_curr_dir_path can make > the paths long resulting in a buffer overflow. > > From 36e05f3140e57bad2af790c56073799d23f7ef60 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Miko=C5=82aj_Zalewski?= <mikolaj(a)zalewski.pl> > Date: Thu, 25 Jan 2007 12:17:11 +0100 > Subject: [PATCH] shell32: shlfileop tests: avoid buffer overflows for paths > > --- > dlls/shell32/tests/shlfileop.c | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/shell32/tests/shlfileop.c b/dlls/shell32/tests/shlfileop.c > index b363c5e..23aaeba 100644 > --- a/dlls/shell32/tests/shlfileop.c > +++ b/dlls/shell32/tests/shlfileop.c > @@ -329,8 +329,8 @@ static void test_delete(void) > static void test_rename(void) > { > SHFILEOPSTRUCTA shfo, shfo2; > - CHAR from[MAX_PATH]; > - CHAR to[MAX_PATH]; > + CHAR from[5*MAX_PATH]; > + CHAR to[5*MAX_PATH]; > DWORD retval; > > shfo.hwnd = NULL; > This is really hacky. If this is fixed, it needs to be fixed properly. -- James Hawkins

2 1

Detect screen resolution change errors
by Francois Gouget Feb. 4, 2007

Feb. 4, 2007

When I run the dlls/d3d9/device conformance test on Windows in VMware, I get a trace telling me that IDirect3D9_CreateDevice() failed and returned 0x8876086c. This seems to be because Windows has trouble changing the screen resolution when running in VMware (though it's perfectly capable of doing it when I go through the control panel). But when I run the test in Wine I'm getting a test failure because: * IDirect3D9_CreateDevice() did not change the screen resolution * but it returned success so that the screen size checks fail That's because XRandR fails to change the resolution (for whatever reason, it's irrelevant here). Wine detects that but does not report the information to the upper layers. So I have made a couple of patches: * the first one detects when XRandR, XVidMode or some low level routine fails to change the screen resolution, and propagates this so ChangeDisplaySettingsEx() returns an error * the second one modifies IWineD3DDeviceImpl_CreateAdditionalSwapChain() so it detects when ChangeDisplaySettingsEx() propagates that error upstream too Now the dlls/d3d9/device test succeeds on my machine (all while loudly complaining something is wrong): [...] err:xrandr:X11DRV_XRandR_SetCurrentMode Resolution change not successful -- perhaps display has changed? fixme:d3d9:IDirect3DDevice9Impl_CreateAdditionalSwapChain (0x1c4358) call to IWineD3DDevice_CreateAdditionalSwapChain failed fixme:d3d9:IDirect3D9Impl_CreateDevice (0x171448) D3D Initialization failed for WineD3DDevice 0x174ee8 device.c:741:could not create device, IDirect3D9_CreateDevice returned 0x8876086c device.c: 245 tests executed (0 marked as todo, 0 failures), 0 skipped. I have attached the relevant patches. Does this look ok to the DirectX gurus? -- Francois Gouget fgouget(a)codeweavers.com

3 5

Re: [lostwages] Update download-deb page with better information, error fixes
by Detlef Riekenberg Feb. 4, 2007

Feb. 4, 2007

On Di, 2007-01-30 at 01:09 -0800, Scott Ritchie wrote: > + > +<p>While there is currently no Wine package explicitly designed for > the 64-bit version > +of Ubuntu, there are several hacks that can be used to install the > 32-bit package > +into the 64-bit distribution and have it function normally. See > +<a href="https://wiki.ubuntu.com/I386WineInAmd64">this page on the > Ubuntu wiki</a> > +for more details.</p> IMHO, a link to our own Wiki should be placed on the download-deb page http://wiki.winehq.org/WineOn64bit#head-56206e8bc74083807ffe06ccb471d3f964c… And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and https://help.ubuntu.com/community/WineForAMD64 The provided automatic installation script includes the sidenet-script. Please include a BIG WARNING, that this is never supported by winehq and the users need a clean wine, before they ask for help on #winehq or wine-users(a)winehq.org You mention sidenet on that page: "If you followed the manual instructions you need to install the Sidenet script" This is wrong. Please remove that line! Even, when the sidenet-script might help some users to run an app, "you need to install the Sidenet script" is wrong! -- By by ... Detlef

3 7

Re: [msvcrt] properly align struct _stati64's st_size
by Francois Gouget Feb. 3, 2007

Feb. 3, 2007

On Sat, 3 Feb 2007, Damjan Jovanovic wrote: [...] > * Added padding so that struct _stati64's st_size has an offset of 24 > bytes from the beginning of the struct like it should. Does the st_size field get the right offset when using Wine's header with the Windows compiler? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

1 0