- wine-devel - winehq.org

PulseAudio driver
by Stéphan Kochen 18 Jul '07

18 Jul '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, I've been working on a PulseAudio driver for Wine for a couple of days now. It was suggested I should drop a note on to wine-devel, so here I am. :) I also cc'd pulseaudio-discuss. (And subscribed to both.) I personally use PulseAudio for everything on my desktop already, but support in Wine was lacking. PulseAudio provides lots of compatibility with other APIs, like OSS, ALSA and ESD. I only managed to get OSS emulation working to a reasonable extent with Wine. I decided it would be a fun project to write a native PulseAudio driver instead. Right now I'm trying to get very basic output working, without real support for DirectSound. Using the winmm_test.exe.so testcase from Wine I already managed to produce beeps using my driver, which is pretty cool for just a couple of days work. :) If anyone feels like a chat, I read both these lists now and will try to respond. I can also be found on Freenode in #winehackers and #pulseaudio as 'stephank'. - -- Stéphan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGEOThcFUq0gzqDwQRAr5mAKCn2PenC5f8iUKEywPe2c8J6s3bogCdH6qv 3JCaQX5OIBwMV9znBXYKJh4= =gQT3 -----END PGP SIGNATURE-----

2 1

Stencil fbo attachments
by Stefan Dösinger 18 Jul '07

18 Jul '07

Hi Henri, Apparently I have debugged Splinter Cell in a wrong direction. The depth copy can hardly be the problem because splinter cell renders everything offscreen, except the final composition and the HUD. I think the problem is the lack of a stencil attachment to our fbos. Implementing them looks rather simple - just adjust the internal format of D24S8 to the packed depth stencil format and set the same texture for depth and stencil attachments. However, I think I remember that you tried that before and it failed for some reason. There are two extensions, GL_NV_packed_depth_stencil and GL_EXT_packed_depth_stencil, whereas the NV one is the only one supported on my nvidia card and the EXT one the only one supported on my ATI card(on macos). The EXT one seems to be the only one that is written with fbos in mind. fglrx does not support either extension. As a fallback a combined depth stencil surface could contain an extra 8 bit gl texture(luminance, or GL_RED, or whatever) and just use it as a separate stencil buffer. We just have to watch out when locking the texture, and using such a surface for texuring will be tricky. (Stencil texture? Is that possible even? The EXT_packed_stencil extension says yes).

3 11

Re: [advapi32/service] Test for duplicate displayname
by James Hawkins 18 Jul '07

18 Jul '07

On 7/17/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > Another test that shows that windows checks if the displayname already exists. > > Changelog > Test for duplicate displayname > > Cheers, > + /* To find an existing displayname we check the 'Spooler' service. Although the registry doesn't show DisplayName on NT4, this call That's a really long comment at 136 cols. There are other really long lines in the rest of the patch too. -- James Hawkins

2 3

System font choice...
by Dan Kegel 18 Jul '07

18 Jul '07

A user complained that with wine-0.9.41, the font chosen by Winefile looks bad: https://bugs.launchpad.net/ubuntu/+source/wine/+bug/69569/comments/4 http://launchpadlibrarian.net/8517354/Screenshot-Wine%20File.png I'm guessing it's because vgasys.fon was chosen as the system font: trace:font:WineEngCreateFontInstance Chosen: L"System" L"Regular" (/usr/bin/../lib/../share/wine/fonts/vgasys.fon:0) What's the suggested way to choose a different font? I did 'sudo apt-get install msttcorefonts', didn't change anything. - Dan

2 2

Re: [PATCH 1/6] urlmon/tests: Expand framework to allow todo_wine'd tests and differences between Windows versions.
by Alexandre Julliard 18 Jul '07

18 Jul '07

Misha Koshelev <mk144210(a)bcm.edu> writes: > #define CHECK_EXPECT(func) \ > do { \ > - ok(expect_ ##func, "unexpected call " #func "\n"); \ > - expect_ ## func = FALSE; \ > + if (!expect_ ##func && wine_allow_ ##func) \ > + { \ > + todo_wine ok(expect_ ##func, "unexpected call " #func "\n"); \ > + wine_allow_ ##func = FALSE; \ > + } \ > + else \ > + { \ > + ok(expect_ ##func, "unexpected call " #func "\n"); \ > + expect_ ## func = FALSE; \ > + } \ > called_ ## func = TRUE; \ > }while(0) This is becoming really ugly. You should fix this to use normal C code instead of macros. -- Alexandre Julliard julliard(a)winehq.org

1 0

winedbg no longer working
by James Hawkins 18 Jul '07

18 Jul '07

Hi, Can someone else verify with git that winedbg no longer works? $ winedbg winecfg WineDbg starting on pid 000a Wine-dbg>c Exception c0000005 Wine-dbg>q wine: Unhandled page fault on read access to 0x0000005c at address 0x7e5ac5d2 (thread 0009), starting debugger... Can't attach process 0008: error 87 Thanks, James Hawkins

3 2

Re: winex11.drv: draw dashed lines for extended pens
by Alexandre Julliard 17 Jul '07

17 Jul '07

"Evan Stade" <estade(a)gmail.com> writes: > I'm only pretty sure this patch is correct. Specifically, note that > there are now HeapAlloc()s in X11DRV_SelectPen that rely on > X11DRV_SelectPen being called again to free. So what is supposed to > happen is that X11DRV_SelectPen called with some dash style will free > the last "dashes" array, and possibly allocate a new one. So this > method requires DeleteDC to call something along the lines of > > SelectObject( hdc, GetStockObject(BLACK_PEN) ); The dash array is always small, there's no reason to allocate it on the heap, you can store an array in the pen object. Also there shouldn't be any need to store the 'ext' flag if you take it into account when building the array. > +#define COPY_DASHDATA(ext, name) \ > + if(ext){ \ > + physDev->pen.dash_len = sizeof(EXTPEN_##name)/sizeof(*EXTPEN_##name); \ > + physDev->pen.dashes = HeapAlloc(GetProcessHeap(), 0, physDev->pen.dash_len); \ > + memcpy(physDev->pen.dashes, EXTPEN_##name, physDev->pen.dash_len);} \ > + else { \ > + physDev->pen.dash_len = sizeof(PEN_##name)/sizeof(*PEN_##name); \ > + physDev->pen.dashes = HeapAlloc(GetProcessHeap(), 0, physDev->pen.dash_len);\ > + memcpy(physDev->pen.dashes, PEN_##name, physDev->pen.dash_len);} > + That macro is ugly, please avoid it. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Make visible mdi client window before as Switch Maximized MDI Children test will be activated. [try2]
by Dmitry Timoshkov 17 Jul '07

17 Jul '07

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > /* test for switch maximized MDI children */ > + ShowWindow(mdi_client, SW_SHOW); > trace("creating maximized visible MDI child window 1(Switch test)\n"); > mdi_child = CreateWindowExA(WS_EX_MDICHILD, "MDI_child_class", "MDI child", > WS_CHILD | WS_VISIBLE | WS_MAXIMIZEBOX | WS_MAXIMIZE, Did you run the test under Windows after this change? For me this test doesn't pass under up to date XP neither in current, nor in new state. -- Dmitry.

2 11

Re: [PATCH 1/2] winepath: add option to output paths in the current Windows ANSI code page
by Alexandre Julliard 16 Jul '07

16 Jul '07

"Lei Zhang" <thestig(a)google.com> writes: > It's occasionally useful to be able to get the Windows path in the > Windows ANSI code page, so I added the --ansi command option to > winepath. The ansi code page is not supposed to leak out of a process. What do you need this for? -- Alexandre Julliard julliard(a)winehq.org

2 2

How should the win16 test suite be arranged?
by Dan Kegel 16 Jul '07

16 Jul '07

So we're collecting the existing win16 tests, updating and fixing them, and will post them to wine-patches sometime soon. At first, the test harness is going to be trivial: a top-level batch file to build all the tests with openwatcom c compiler (it's free, but not quite free enough to make it into debian), and another top-level batch file to run all the tests. (We'll also provide a batch file to install open watcom.) Given that not many developers will bother installing openwatcom just to be able to compile the win16 tests, I suspect that might be enough of a test harness for now. Objections? - Dan

2 4

SUBLANG Rules
by Colin Finck 16 Jul '07

16 Jul '07

Hello, The Wiki page at http://wiki.winehq.org/SublangNeutral says that specific SUBLANGs should be used for the languages Chinese, Norwegian and Portuguese. This is okay if you always have a translation specifically for every sublanguage of these languages, but we might run into problems if a translation for one of these sublanguages does not exist. For example if we have a translation for LANG_PORTUGUESE, SUBLANG_PORTUGUESE_BRAZILIAN, but don't have a translation for SUBLANG_PORTUGUESE_PORTUGAL and the user set his locale to "Portuguese (Portugal)", he will see the English translation, although we have a Brazilian Portuguese translation. If we would use SUBLANG_NEUTRAL here, the same translation would be used for both Portuguese variants. The question is now: What are the preferences of these users? Would it be better for them if they see the Brazilian Portuguese translation or the English one? The same goes for Chinese and Norwegian users, if we only have one translation for these languages. It would be nice if some native Chinese, Norwegian and Portuguese speakers could share their opinion about this. Best regards, Colin Finck

4 5

Re: programs/net: Add russian resources
by Dmitry Timoshkov 16 Jul '07

16 Jul '07

"Konstantin Kondratyuk" <kondratyuk(a)etersoft.ru> wrote: > Changelog: > add russian resources in programs/net Did you test this translation? You are using KOI8-R which won't work properly in russian resources. -- Dmitry.

2 1

Re: [RFC] winex11.drv: Prepare ChoosePixelFormat() for code rewrite.
by Vitaliy Margolen 16 Jul '07

16 Jul '07

Tomas Carnecky wrote: > This partial rewrite aims at cleaning up the pixelformat code. Windows > sometimes advertises one or more almost identical and completely > compatible pixelformats. These pixelformats differ in attributes like > color-bits, but I suspect the driver developers do that only to work > around buggy applications that don't follow the spec. > This rewrite will also simplify the pixelformat code by removing > redundant blocks and moving the core functionality to a few main functions. > > This is the first patch that simplifies ChoosePixelFormat() by > converting the PFD structure to a list of WGL attributes and then using > a function to choose the pixelformat. This function doesn't do anything > as we support only one pixelformat, but this function will be shared > with wglChoosePixelFormat() once the infrastructure for that is in place. > > I also have a second patch that converts DescribePixelFormat() to use > the same approach, eg. querying the pixelformat attributes using a WGL > attribute list and then copying the values back the the PFD structure. > > --- Few notes: You constructed the array of some attributes which you never use. You don't check if those attributes match anything - the part you removed. When app will ask for something that can't be supported your code will return it to the app - which is plain wrong. And being picky - you using tabs for indentation, please use 4 spaces instead, and no tabs. Vitaliy

2 1

Re: [Resend PATCH 2/2] gdi32: Do not fill in the color tableiflpvBits is NULL
by Dmitry Timoshkov 14 Jul '07

14 Jul '07

"Jeremy White" <jwhite(a)codeweavers.com> wrote: > p.s. While I'm coming clean, *another* failure on my part > was to fail to credit Huw; this is mostly his insight. > I provided the clue, and the hopeless failure to get a clean patch in :-/. Since you are going to resend the patch anyway please add a missing HeapFree call to the test. -- Dmitry.

1 0

Re: programs/winefontcfg: Add winefontcfg (try 3)
by Dan Kegel 14 Jul '07

14 Jul '07

All in all the app looks like it's coming along nicely. I apologize for catching so few problems in each pass, but we'll get there. Is there a way you can get the path to the currently running instance instead of hardcoding it? Then it would work even if winefontcfg isn't on the PATH. + static const WCHAR cmdstr[] = { + 'w', 'i', 'n', 'e', 'f', 'o', 'n', 't', 'c', 'f', 'g', '.', 'e', 'x', 'e', '.', 's', 'o', ' ', You're still using nonstandard C; you can't have initializers on nonstatic arrays. This is the third time I have pointed this out; you should look to make sure you don't do this anywhere in the program. You should make sure the app can build with visual C 6 if you haven't lately, too. +static void TabSelChanged(HWND hTab) +{ + int tab[NUMTAB][MAXOBJPERTAB] = { Say, why is hwndTab static here? I bet that's a cut and paste error: +static HWND InitTab(HWND hdlg, HFONT hf) +{ + static HWND hwndTab; Looks like variable reuse abuse here; maybe you should have a more mnemonic name for the return value of wcstolong: + j = wcstolong(buf); It might be nice to have comments identifying the big hunks of the program, e.g. if all the code for one tab was grouped under a comment with the name of the tab. - Dan

1 1

Should Wine move to LGPL 3?
by Tom Wickline 14 Jul '07

14 Jul '07

Hello, I was wondering if there are any plans in place for Wine to move to the newly revised LGPL 3 licence before the release of 1.0? http://www.gnu.org/licenses/lgpl.html Cheers, Tom Wickline -- Microsoft's patent protection scheme is the equivalent of bailing water with a sieve.

11 12

Re: Should Wine move to LGPL 3?
by Ian Macfarlane 13 Jul '07

13 Jul '07

I've been meaning to ask about this since (L)GPL3 was released. The version 3 of the (L)GPL license has numerous benefits: - It's much more legally sound in the rest of the world (IMO one of the most important factors about the new license) - numerous reasons for this e.g. referencing WIPO rather than US laws. - It has an explicit patent agreement (really an extension of the above - (L)GPLv2 has an implicit patent agreement, but this is only valid in the US) - this means that people who contribute to and/or distribute WINE cannot sue WINE (or WINE users) for patent infringement. - It is compatible with the Apache 2.0 license, meaning that there is an even bigger pool of source code to draw from. - It helps ensure that companies cannot prevent people from modifying the source code by providing them explicit legal rights to change the code in these circumstances, and requiring information to allow users to change it. - For LGPL only, It makes 100% sure that GPL+linking exception and LGPL can be combined legally in all jurisdictions by merging them (which is essentially the only real difference, barring slightly different wording in the v2.1 of LGPL vs v2. of GPL) - It prevents patent agreements where only some people are protected. - It provides a mechanism for first-time accidental violations to be 'cured' more easily - ... and lots of other minor changes to improve the validity of the legal status of the license. There are some points not directly related to the license itself that might be of interest: - Samba has decided to become GPL3+ only, as they want the added protections provided by the license. WINE and Samba seem like projects that may potentially wish to share code (a very quick search brings up articles like this http://www.winehq.org/?issue=272), and if WINE sticks to supporting GPLv2+ rather than GPLv3+, then WINE will no longer be able to integrate Samba code. - Solaris may go GPLv3, another potentially useful repository of code to draw from that would not be possible under GPLv2. So as you can see, (L)GPL version 3 has a lot of benefits. It also has broad support (excluding Linus of course, who I must point out objects only to a single clause in the license that can be resolved by adding an extra permission, as GPLv3 permits), including strong corporate backing (e.g. IBM, Red Hat, MySQL, Sun, even Novell). As one of the projects that Microsoft would most like to destroy, the added protections in this updated version of the license would seem even more valuable. Kind regards, Ian Macfarlane ps: As a last note to Damjan - all GPL versions have been considered both radical and political when they were released. In retrospect, the protections that they provided have been considered invaluable.

4 3

compile wine version 0.9.41
by Renato Astorino 13 Jul '07

13 Jul '07

Dears, As requested in the result of it configures it follows the menssagem: configure: WARNING: io.h: present but cannot be compiled configure: WARNING: io.h: check for missing prerequisite headers? configure: WARNING: io.h: see the Autoconf documentation configure: WARNING: io.h: section "Present But Cannot Be Compiled" configure: WARNING: io.h: proceeding with the preprocessor's result configure: WARNING: io.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## the executed command: #./configure --with-PACKAGE=yes --with-x --disable-win16 #make depend make[1]: Entering directory `/mnt/hd_ext/Softwares/wine-0.9.41/tools' gcc -c -I. -I. -I../include -I../include -I/usr/local/include/freetype2 -I/usr/local/include -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o makedep.o makedep.c In file included from ../include/wine/port.h:42, from makedep.c:23: /usr/local/include/io.h:69: error: expected specifier-qualifier-list before 'TAILQ_ENTRY' /usr/local/include/io.h:75: error: field 'ihdr_queue' has incomplete type /usr/local/include/io.h:76: error: field 'ihdr_parent' has incomplete type /usr/local/include/io.h:120: error: field 'io_ev' has incomplete type make[1]: *** [makedep.o] Error 1 make[1]: Leaving directory `/mnt/hd_ext/Softwares/wine-0.9.41/tools' make: *** [tools/makedep] Error 2 I am using the distribution Slackware 12.0 regards, Renato Astorino _________________________________________________________________ Verificador de Segurança do Windows Live OneCare: combata já vírus e outras ameaças! http://onecare.live.com/site/pt-br/default.htm

1 0

Re: [Resend PATCH 2/2] gdi32: Do not fill in the color table if lpvBits is NULL
by H. Verbeet 13 Jul '07

13 Jul '07

On 13/07/07, Jeremy White <jwhite(a)codeweavers.com> wrote: > --- > dlls/gdi32/dib.c | 14 +++++++++++--- > 1 files changed, 11 insertions(+), 3 deletions(-) > The patch mixes tabs and spaces. Also, in general, I don't think we should include text from MSDN.

2 1

unsuspected success in tests/monthcal?
by Marcus Meissner 13 Jul '07

13 Jul '07

Hi, For some days I now get unexpected successes in dlls/comctl32/tests/monthcal.c. ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so monthcal.c && touch monthcal.ok err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000000 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 monthcal.c:818: Test succeeded inside todo block: Expected 131073, got 131073 make[2]: *** [monthcal.ok] Error 1 Does anyone else see them too? Ciao, Marcus

3 2

Re: [msi/tests] Remove the whole directory after the test
by James Hawkins 13 Jul '07

13 Jul '07

On 7/13/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > RemoveDirectory only removes empty directories. > > Changelog > Remove the whole directory after the test > No, this is wrong. The line above, CreateDirectory("msitest\\msitest", NULL); is what needs to be removed. -- James Hawkins

2 1

Re: winedump: Cast-qual warnings fix
by Alexandre Julliard 13 Jul '07

13 Jul '07

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > + const char *iter, *base_type, *catch_unsigned; > + union > + { > + const char *constant; > + char *nonconst; > + } type_str; That's not better than simply casting const away, it's just hiding the problem from the compiler. -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: programs/winefontcfg: Add winefontcfg (try 3)
by Paul Vriens 13 Jul '07

13 Jul '07

Nigel Liang wrote: > Hi, > > Some changes suggested by Dan. > > Changelist: > - Initialize non-static local arrays at runtime or make them static > - Use CompareStringW to do case-insensitive comparison > - Initialize some static variables before use and clear them after > - Rename a global variable > - Move some hard-coded strings into En.rc > - Got rid of some magic numbers in the code > - Use 4 space indentation > > -Nigel > > > ------------------------------------------------------------------------ > > Hi, You leak several registry handles in failure cases, for example in GetFilenameFromFacename: + if (lRet != ERROR_SUCCESS) { + WINE_TRACE("RegQueryValueExW facename: %s, returned: %ld\n", + wine_dbgstr_w(facename), lRet); + return 1; + } or ClearFontLinkRegistry: + if (lReturn != ERROR_SUCCESS) { + WINE_TRACE("RegSetValueExW returned: %ld\n", lReturn); + return 1; + } and a few more. Cheers, Paul.

1 0

Proposal to phase out *winehq.com email addresses
by Duane Clark 13 Jul '07

13 Jul '07

Due to the rather large amount of spam sent to the *winehq.com email addresses (as opposed to *winehq.org), I would like to phase them out. I will state up front that this proposal benefits only me or any future moderator. Since I have been doing that for about 6 years now, hopefully I'll get a bit of sympathy ;) A cursory inspection of postings to this list show that almost everyone already posts to *winehq.org. I would propose that for a few weeks, I'll simply keep track of where people are posting to, and send private emails to the very few who post to .com. Once everyone is posting to the .org address, I'll implement a filter in mailman that simply drops the others. I have already done this as a test on the announce, bugs, and cvs lists, and this eliminates about half of the spam. And while I am at it, anyone who wants to help with the moderation and is willing to stick with it for the long term, let me know.

5 6

Missing dependency at debian packages.
by Marcelo Boveto Shima 12 Jul '07

12 Jul '07

Hello Karl! I added lots of missing dependency on the debian packages. Would be nice to have the binary updated. This should fix lots of rsvg missing dependency. Regards Marcelo Shima

1 1

Re: dinput: Convert IDirectInput into multi-interface object.
by Stefan Dösinger 12 Jul '07

12 Jul '07

Am Donnerstag, 12. Juli 2007 06:51 schrieb Vitaliy Margolen: > Fixes bug 5920. > --- > dlls/dinput/dinput_main.c | 467 > +++++++++++++++++++++++++++--------------- dlls/dinput/dinput_private.h | > 6 +- > 2 files changed, 311 insertions(+), 162 deletions(-) Did you test which interfaces can be QueryInterfaced from which interface? In theory all interfaces should be queryable from all interfaces, but in practise Microsoft violates their own COM rules in ddraw, so I'd expect them to do so in other DirectX DLLs. In DDraw we do not(yet) implement the restrictions, but we have some todo_wine tests to document it.

2 1

ANNOUNCE: Wine/Mono Regression Test Suite
by Matt Jones 11 Jul '07

11 Jul '07

Hi Everyone - I'm working on getting mono to run happily under wine, thus opening wine (& linux) up to a much larger range of .NET applications. Unfortunately, mono-under-wine fails in rather cryptic ways at the moment, so I've found that running the mono regression test suite has given me a better idea of how to approach debugging mono/wine. Double unfortunately, running the mono regression test suite on linux, windows & wine presents a large series of interesting problems. So I've developed a python driver for the tests that spits out some html highlighting interesting test results and unifies the testing method on all three platforms. The code is available at [1] There is a git repository at [2] The scripts can generate static html pages for tests run, which are available at: [3] (you can download the entire set of gzipped pages from [4]) Many of the tests fail as a result of bug 8757, which causes mono to lock up while running a GC cycle. For now the scripts kill test cases after 5 minutes, but I've also included patches against wine to prevent the lockup (horrible hacks - disable modal message boxes & the debugbreak function). If you want to save time when running the tests, you can apply these patches in a git branch and test against that. The tests are designed to require little-to-no user interaction - after an initial linux & windows test run are performed (sample test data at [5]), an automated update script (nightly-update.sh) can be called to automatically update wine, run the tests and publish the results. Feedback is greatly appreciated - the tests are very temperamental, so it wouldn't surprise me at all if things break on other machines (I've tested pretty extensively and documented any non-automated actions necessary, but I want to make sure I didn't miss anything.) Thanks, Matt Jones [1] http://mhjones.org/wine/wine-tests/wine-test-reader.tar.gz [2] http://mhjones.org/wine/wine-tests/wine-test-reader.git [3] http://mhjones.org/wine/wine-tests/htmltest/index.py.html [4] http://mhjones.org/wine/wine-tests/htmltest.tar.gz [5] http://mhjones.org/wine/wine-tests/test-runs-example.tar.bz2

1 0

Re: shlwapi: Use publicly defined structure DATABLOCK_HEADER instead of redefining it locally
by James Hawkins 11 Jul '07

11 Jul '07

On 7/11/07, Thomas Weidenmueller <wine-patches(a)reactsoft.com> wrote: > Update the datablock list code to use the DATABLOCK_HEADER structure > defined in shlobj.h rather than re-defining it locally. > > - Thomas > > > You forgot the patch. -- James Hawkins

1 0

Re: winex11.drv: send proper file path for drag and drop
by Damjan Jovanovic 11 Jul '07

11 Jul '07

On 7/11/07, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > Drag and drop currently sends the file path as "\path\to\file" which > does not work properly for some applications. This patch converts the > file path to a proper Windows file path, i.e. z:\path\to\file. > I'm not sure we should even be trying to do anything special with the "text/plain" MIME type like extract a file list: that would generate WM_DROPFILES when you drag text into an application. My patch (http://www.winehq.org/pipermail/wine-cvs/2007-June/033705.html) that's already in wine 0.9.40 sends WM_DROPFILES on "text/uri-list" like the X file drag spec says. You're probably seeing the badly formed paths because both my code and the old code are both building CF_HDROP formats, and X11DRV_XDND_SendDropFiles just uses the first one in the list. So, the old code needs to go... Damjan

2 1

Performance testing experiences
by Stefan Dösinger 11 Jul '07

11 Jul '07

Hi, In the past days I've been actively hacking on automated performance testing. I have test scripts for Half Life 2, 3Dmark2000 and 3dmark2001 and a small z buffer test app. I am playing around with UT2004 and I want to take a look at plain old unreal tornament. I have the tests running on my old laptop and my amd 64 box. I want to extend that to my mac too. To collect some experience I've built a quick and dirty server "app", consisting of 200 lines of php, to get a better idea about what I want. Failed bechmark attempts are Half Life 1 and the codecreatures engine benchmark. Both failed because I did not find a way to write the results to a file. In HL1 this may work by marking a bit of text with the right mouse coords and copying it to clipboard. With codecreatures we're out of luck, unless we use OCR. Final Fantasy XI has the same problem, but I knew that already. My server side graphs can be seen here: http://84.112.174.163/~stefan/ The amd64/ and laptop/ folders contain folders for each test, which contains a result.php which calls gnuplot to generate graphs and build a formatted table. It's all highly inflexible and not meant as a permanent solution. Adding a new test or a new computer means major copypaste and find / replace work. Some problems I've come accross are recording cxtest scripts, which just does not work for games that need 3D in VNC. So I've written them by hand. Games for a big part also resist controllabiliy with the wait_window script. Some games just create their only window when they are started, and then take another X secounds to really start up and react to clicks or keypresses. wait_window causes a 1 secound X server freeze every few secounds, which invalidates benchmark results. For this reason I have put a sleep into the 3DMark2000 test script to freeze cxtest while the benchmark is running. Another problem is that the performance can be quite different from run to run with the same wine version. I'm not sure what causes this, but I will try to run the tests with everything else shut down. Failing that, we can still run all tests repeatadely and find an average result.

1 0

bug triaging
by James Hawkins 11 Jul '07

11 Jul '07

Hi, > ------- Additional Comment #3 From Austin English 2007-07-08 21:16 ------- > > Works fine in wine 0.9.40. > > > ------- Additional Comment #4 From Lei Zhang 2007-07-08 21:32 ------- > > Works here as well with wine 0.9.40 and a clean .wine directory. Ok folks, if you run an installer and it works for you, there's a pretty good chance that the bug has been fixed since the original report, especially if more than one person verifies that it's fixed. Go ahead and marked them fixed, and if the user is still experiencing the problem, they can always reopen the bug. -- James Hawkins

4 5

Re: msi: Add tests for adding properties with a transform during an install
by Paul Vriens 11 Jul '07

11 Jul '07

James Hawkins wrote: > Hi, > > Changelog: > * Add tests for adding properties with a transform during an install. > > dlls/msi/tests/install.c | 235 > ++++++++++++++++++++++++++++++++++++++++++++++ > include/msiquery.h | 5 + > 2 files changed, 240 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Hi James, this patch doesn't compile for me: install.o: In function `generate_transform': install.c:(.text+0x91ff): undefined reference to `MsiCreateTransformSummaryInfoA' collect2: ld returned 1 exit status winegcc: gcc failed. make: *** [msi_test.exe.so] Error 2 Is this because MsiCreateTransformSummaryInfo is a stub? Cheers, Paul.

1 0

re: Direct3D Game test framework
by Dan Kegel 11 Jul '07

11 Jul '07

Michal Okresa wrote: >We (people around CxTest) think that extending CxTest is better approach >to achieve your goals rather than writing new application or modifying >existing. It could be done with smaller effort (in opposite of >AutoHotkey, AutoIt, ...) because CxTest is specialised for testing Wine >and CrossOver and it can deal with wine's specifics. I agree that CxTest has many good features, and that any tests we write should run under CxTest. However, I think it's useful and important for us to write tests that can easily be run with no complicated CxTest installation. I also think it's useful and important for us to be able to run our tests on Windows. That's why I started yawt; it's a single python source file that runs automated tests written in AutoHotkey (and a little python). It runs perfectly well on both Windows and Wine, and my goal is to make yawt plug in to CxTest so yawt tests can still easily be run on Windows or Linux standalone, *or* be run from inside the CxTest machinery. I'm sure there will always be some tests that are better written directly in CxTest, but I'm going to try to push yawt forward, too. With luck we'll have the two test systems working well together in a month or two. - Dan

2 2

configure complains about liblcms not being there
by Paul Vriens 11 Jul '07

11 Jul '07

Hi, Since the last patches to configure.ac and friends (I haven't seen the warnings before) I get: configure: liblcms development files not found. Wine will be built without Color Management support. (mscms.dll) It look like configure is checking for the availability of lcms.h: configure:6948: checking lcms.h usability configure:6965: gcc -m32 -c -Wcast-qual conftest.c >&5 configure:6971: $? = 0 configure:6985: result: yes configure:6989: checking lcms.h presence configure:7004: gcc -m32 -E conftest.c configure:7010: $? = 0 configure:7024: result: yes configure:7057: checking for lcms.h configure:7065: result: yes configure:6948: checking lcms/lcms.h usability configure:6965: gcc -m32 -c -Wcast-qual conftest.c >&5 conftest.c:65:23: error: lcms/lcms.h: No such file or directory Mine is at /usr/include/lcms.h (and it's found). Shouldn't that be enough to satisfy configure? I doubt anyone will have both. My version for lcms: lcms-1.16-3 lcms-devel-1.16-3 Any idea? Cheers, Paul.

4 6

Re: kernel32:tests:path.c Add test for GetShortPathNameW [try3]
by Alexandre Julliard 11 Jul '07

11 Jul '07

Anatoly Lyutin <vostok(a)etersoft.ru> writes: > + if ( GetThreadLocale() == CyrLCID ) > + { > + /* Create directory with Cyrillic long name */ > + helper_GetShortPathNameW( pathRL ); > + > + /* Create directory with Cyrillic short name */ > + helper_GetShortPathNameW( pathRS ); > + } > + else > + skip( "Not Cyrillic locale.Test skipped.\n" ); There's nothing specific about the Cyrillic locale in GetShortPathName; the only thing that could possibly matter is the file system encoding, but that's not the same thing. What are you trying to test here? -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: [1/10] gdiplus: moved two helpers to gdiplus.c
by Alexandre Julliard 11 Jul '07

11 Jul '07

"Evan Stade" <estade(a)gmail.com> writes: > +inline INT roundr(REAL x) > +{ > + return (INT) floorf(x + 0.5); > +} > + > +inline REAL deg2rad(REAL degrees) > +{ > + return M_PI * degrees / 180.0; > +} If you want them to be inlined they should be defined in the header file. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel: use VirtualAlloc in GlobalAlloc16 to make such memory executable
by Alexandre Julliard 11 Jul '07

11 Jul '07

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > This patch is not enough to run Win16 programs on NX protected > systems as there is also some code placed in the UMB by > winedos/himem.c. I have a patch that makes the DOS area executable > (see bug #8744) but I will have to look if that's what Windows > does. In the mean time I'd like to know if there are some comments > about this patch. It's extremely wasteful, most GlobalAlloc blocks are fairly small. What you should do is allocate them from an executable heap instead of the default process heap. -- Alexandre Julliard julliard(a)winehq.org

1 0

Fw: shell32: implementation of SheGetDirA/W and SheChangeDirA/W
by Martin Fuchs 11 Jul '07

11 Jul '07

Hi, any hint why this patch was not yet applied? Regards, Martin On 13.05.2007 19:04:25 Martin Fuchs wrote: Changelog: implement SheGetDirA/W and SheChangeDirA/W in shell32 This functions are needed for the good old winfile.exe of NT4. Index: dlls/shell32/shlfileop.c =================================================================== ... -- Martin Fuchs fuchs.martin(a)gmail.com

1 0

Font changes?
by Andrew Talbot 10 Jul '07

10 Jul '07

I thought it useful to mention that if the rendering of your fonts has changed significantly (in the development build) since 4 July 2007, you might need to install the 32-bit development package for libXrender. -- Andy.

1 0

Error compiling Wine (current GIT)
by Paul Vriens 10 Jul '07

10 Jul '07

Hi, 'make depend && make' fails for me: make[2]: Entering directory `/wine/wine-git/dlls/gdiplus/tests' ../../../tools/makedep -C. -S../../.. -T../../.. brush.c graphicspath.c pen.c math.h: No such file or directory math.h was first included from graphicspath.c:24 make[2]: [Makefile] Error 1 (ignored) ../../../tools/makedep -C. -S../../.. -T../../.. brush.c graphicspath.c pen.c math.h: No such file or directory math.h was first included from graphicspath.c:24 make[2]: *** [depend] Error 1 make[2]: Leaving directory `/wine/wine-git/dlls/gdiplus/tests' make[1]: *** [gdiplus/tests/__depend__] Error 2 make[1]: Leaving directory `/wine/wine-git/dlls' make: *** [dlls/__depend__] Error 2 Following patch fixes the compile for me, but I'm not sure it's correct: diff --git a/dlls/gdiplus/tests/graphicspath.c b/dlls/gdiplus/tests/graphicspath.c index f7cfedb..d71aab8 100644 --- a/dlls/gdiplus/tests/graphicspath.c +++ b/dlls/gdiplus/tests/graphicspath.c @@ -21,7 +21,7 @@ #include "windows.h" #include "gdiplus.h" #include "wine/test.h" -#include "math.h" +#include "msvcrt/math.h" #define expect(expected, got) ok(got == expected, "Expected %.8x, got %.8x\n", expected, got) #define POINT_TYPE_MAX_LEN (75) Cheers, Paul.

2 1

Re: [kernel32] CreateProcess should always specify the child's current directory
by James Hawkins 10 Jul '07

10 Jul '07

On 7/9/07, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > This fixes an unusual bug where an older Winzip self-extracting > archive starts the executable just extracted in the wrong current > directory. > > Changelog: > * CreateProcess should always specify the child's current directory. > Tests would be nice. -- James Hawkins

1 0

Re[2]: EV_RXFLAG emulation
by Valentine Sinitsyn 10 Jul '07

10 Jul '07

Hi, UB> The problem with EV_RXFLAG is, that the UNIX spec doesn't know it (to my UB> knowledge). So most if not all kernel level drivers don't implement it. So UB> we have to workaround or propose a kernel driver change. Yeah, that's was what I wrote in the second item of the list (actually, for my own internal developments, I've just implemented missing ioctl() in the Linux TTY driver but I'm almost sure the change wouldn't get accepted upstream). The question is - what's a best way (in design terms: buffer serial I/O in ntdll/serial.c, at the server level etc - there are many ways to do the same thing and nearly all of them would probably work) to workaround the problem and I'm kindly asking someone with a decent knowledge of the Wine architecture at the whole to comment on my idea. UB> As the latter is probably harder then to write code that Alexandre accepts, UB> try to implement you proposal in a clean way. Start with adding test for the UB> test suite, that really run on the different Win Flavours. Than implement UB> your idea that make wine succeed in the test, and your test run on wine. That's a tough part - it implies that I must have those different Windows versions. UB> Otherwise, in 2000 Ove Karven did some implementation for EV_RXFLAG UB> http://source.winehq.org/source/misc/comm.c?v=wine20001002 UB> The code probably got lost in the move to handle devices in the server. Thanks, I saw this one. The idea is somewhat close to mine although implementation is different - I need to look further into it. Regards, Valentine Sinitsyn

1 0

working on urlmon HttpProtocol implementation
by Misha Koshelev 10 Jul '07

10 Jul '07

Just wanted to let y'all know (so hopefully I'm not duplicating any effort) I'm working on an HttpProtocol implementation for urlmon (Vector NTI has a bug that requires POST to work for url monikers, and I don't want to submit patches to a function that has _hack at the end of it :) ). Right now I have an implementation that conforms to Jacek's somewhat extensive tests already in dlls/urlmon/tests/protocol.c and also has the same error functionality as native per my tests (I would change wininet functions that native calls to return NULL and see what native urlmon returns). Now I will try out some other flags (Jacek's tests are very extensive, but only test ASYNC with PULLDATA etc.) to see what else I need to do. Anyway, hopefully I'll submit some patches within a week or a few. Misha

2 4

Call for win16 tests
by Dan Kegel 10 Jul '07

10 Jul '07

As Andreas Mohr pointed out a while back, http://www.winehq.org/pipermail/wine-devel/2005-August/039602.html we really need a win16 test suite to make sure our win16 support doesn't rot. As far as I know, nobody's managed to get win16 tests into the tree, presumably because the build process or maybe stdio for win16 tests hasn't been figured out. So I've asked intern Jennifer Lai to try to merge all the win16 tests people have posted over the years together, and demonstrate how to build them using openwatcom. I've only found three submitted 16 bit tests so far: http://www.winehq.org/pipermail/wine-devel/2006-November/052479.html http://www.winehq.org/pipermail/wine-patches/2004-October/013267.html http://www.winehq.org/pipermail/wine-patches/2004-October/013268.html Anyone know of any more? (e.g. Andreas, could you send us the trove of 16 bit tests you were talking about?) Thanks, Dan

3 3

Re: color fix
by H. Verbeet 09 Jul '07

09 Jul '07

On 09/07/07, Kovács András <andras(a)csevego.net> wrote: > Hi, > > This will fix Beyond Good & Evil color (bgr<=>rgb) problem. > Based on stefand's suggestion. > What is the actual problem that this patch fixes?

1 0

Re: #2 kernel32: Implement GetTickCount64.
by Alexandre Julliard 09 Jul '07

09 Jul '07

Hans Leidekker <hans(a)it.vu.nl> writes: > --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -178,6 +178,7 @@ > # @ stub NtGetDevicePowerState > @ stub NtGetPlugPlayEvent > @ stdcall NtGetTickCount() > +@ stdcall NtGetTickCount64() > # @ stub NtGetWriteWatch Windows doesn't have NtGetTickCount64(). -- Alexandre Julliard julliard(a)winehq.org

1 0

Mapping of access rights (advapi32/service)
by Paul Vriens 09 Jul '07

09 Jul '07

Hi, While adding some more tests I've found that we lack mapping between some generic access rights and specific service access rights. An example is GENERIC_ALL that should map to SC_MANAGER_ALL_ACCESS. Should this mapping be done in advapi32/service.c? Would it be OK to create a specific function that does this mapping/translation? The functions makes senses as we have several functions that need this mapping. Cheers, Paul.

2 2

Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try6]
by Alexandre Julliard 09 Jul '07

09 Jul '07

"Evan Stade" <estade(a)gmail.com> writes: > +static const path_test_t polydraw_path[] = { > + {0, 0, 6, 0, 0}, /*0*/ > + {10, 10, 2, 0, 0}, /*1*/ > + {10, 15, 3, 0, 0}, /*2*/ > + {100, 100, 6, 0, 0}, /*3*/ > + {95, 95, 2, 0, 0}, /*4*/ > + {10, 10, 2, 0, 0}, /*5*/ > + {10, 15, 3, 0, 0}, /*6*/ > + {100, 100, 6, 0, 1}, /*7*/ > + {15, 15, 2, 0, 1}, /*8*/ > + {100, 100, 6, 0, 1}, /*9*/ > + {30, 30, 4, 0, 1}, /*10*/ > + {30, 35, 4, 0, 1}, /*11*/ > + {35, 35, 4, 0, 1}, /*12*/ > + {45, 50, 2, 0, 0}, /*13*/ > + {35, 35, 6, 0, 0}, /*14*/ > + {50, 55, 2, 0, 0}, /*15*/ > + {45, 50, 2, 0, 0}, /*16*/ > + {35, 35, 6, 0, 0}, /*17*/ > + {60, 60, 2, 0, 0}, /*18*/ > + {60, 65, 2, 0, 0}, /*19*/ > + }; You still need to use symbolic constants here, like Misha suggested. Note: you shouldn't wait for me to tell you that, the point of a public review is that everybody can comment on a patch, and you are expected to take these comments into account. In fact if I see that someone has commented on a patch already, usually I don't bother to review it, I just wait for you to resubmit an improved version. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: 0001 Add 2 idl files for d3d10
by Stefan Dösinger 09 Jul '07

09 Jul '07

Am Montag, 9. Juli 2007 12:52 schrieb Kovács András: > Hi, > > 0001-Add-2-idl-files-for-d3d10.txt I checked those .idl files yesterday, and they looked good to me. dxgitype.idl isn't complete, it just contains two types needed by d3d10.idl . That said, I didn't check every single letter against typos, but I didn't see any big mistakes that would make our libs binary incompatible.

1 1

Re: 0001 Add 2 idl files for d3d10
by Christoph Frick 09 Jul '07

09 Jul '07

On Mon, Jul 09, 2007 at 12:52:43PM +0200, Kovács András wrote: > ... > +#define D3D10_VS_OUTPUT_REGISTER_COUNT ( 16 ) > +#define D3D10_WHQL_CONTEXT_COUNT_FOR_RESOURCE_LIMIT ( 10 ) > +#define D3D10_WHQL_DRAWINDEXED_INDEX_COUNT_2_TO_EXP ( 25 ) > +#defineD3D10_WHQL_DRAW_VERTEX_COUNT_2_TO_EXP ( 25 ) here is a space missing?

1 0

Re: programs: Add extrac32 (empty program)
by James Hawkins 09 Jul '07

09 Jul '07

On 7/6/07, Anatoly Lyutin <vostok(a)etersoft.ru> wrote: > Yesterday I post a first version of extrac32. I expected that this > version would be filled with bugs but I thought that would be better to > apply this version because it contains some binding parts (add this > program in configure.ac and etc). And improve this program by patches > after. That is why I answered thus to Kirill K. Smirnov but I wrote > equivocally and James Hawkins had not understand me. > > I really sorry for it and I decided to post this patch that add an empty > program. It will be nice if this would be applied because would be more > conveniently to make patches that will add functionality and fix bugs. > > Changelog: > Add extract32. > +C_SRCS = \ + extrac32.c \ + parsecmd.c Where is parsecmd.c? -- James Hawkins

2 3

appdb problem: deleting test data?
by Dan Kegel 09 Jul '07

09 Jul '07

How does one delete just one test report? There's a 'delete version' button but no 'delete test data' button, and clicking on 'edit' for the test data also doesn't offer a way to delete the test data.

2 1

Re: [PATCH 1/2] urlmon/tests: Add tests for ObtainUserAgentString.
by James Hawkins 09 Jul '07

09 Jul '07

On 7/8/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > Tested on Win98 and WinXP. if (1)'s for wine page faults are removed in the second patch of the set. > I don't know whether Julliard will accept these patches as they are, but the policy about disabling blocks of tests because they fail on Wine is that it's not allowed. I know the second patch fixes this, but if that is the case, why don't you just send the fixes patch first, then the tests second? -- James Hawkins

1 0

EV_RXFLAG emulation
by Valentine Sinitsyn 09 Jul '07

09 Jul '07

Hi all, I spent the last couple of days trying to run one program in Wine. The program (Easy Wireless Net, end-user tool to control many CDMA modems, if you are interested in) extensively use EV_RXFLAG event which is currently unimplemented in Wine. I've made a simplest implementation possible (fire EV_RXLAG every time you have something in the serial port input buffer - all the messages come in once anyway) and it worked just fine with the aforementioned program, so I have two questions now: 1. Would the patch with such "implementation" for EV_RXFLAG be accepted to the mainline Wine (my take is having some sort of support for the feature is always better that not having support at all) ? 2. Of course, a proper implementation of the feature is desirable - i.e. one should look after EventChar in WaitCommEvent (ntdll/serial.c:wait_for_event(), to be precise) but unfortunately this lead to a trouble (I guess it's the reason why EV_RXFLAG is still unimplemented): you need to "peek" into a buffer or read the data twice: first time in WaitCommEvent to look for eventchar, and second - in NtReadFile to actually obtain the data. And of course, it's not possible, so some sort of buffering must be implemented. Alas, WINE's architecture doesn't imply any buffering between Unix and Windows layer as Developer's Guide states. My proposed solution is to read data in serial.c:wait_comm_event() and store it somewhere; then, in NtReadFile() one should check whether fd corresponds to serial file and, if so, look in the corresponding buffer before doing actual read. Does this fit nicely into WINE's design ? Or there are some other (more correct) approaches to perform this task? Thank you in advance. Regards, Valentine

1 0

Rude hack fixes Run Time Error 445:Object Doesn't Support This Action
by David Anderson 08 Jul '07

08 Jul '07

The following rudely changed function: static HRESULT WINAPI WebBrowser_put_RegisterAsBrowser(IWebBrowser2 *iface, VARIANT_BOOL bRegister) { WebBrowser *This = WEBBROWSER_THIS(iface); FIXME("(%p)->(%x)\n", This, bRegister); TRACE("dadebug fake return\n"); /* My rude addition. */ return S_OK; /* My rude addition */ return E_NOTIMPL; } in wine/dlls/shdocvw/webbrowser.c works around wine bug 5183. For me. The app I use to run the test is a VB app written by a friend (not commercial software). I have no idea what the above function is really supposed to do nor any idea how to even find out. I really don't want a web browser running out of VB anyway :-) Note that a couple years ago the app in question worked. But stopped with Run-time error "445":Object doesn't support this action (oleaut32) at some point. If anyone could make a suggestion of something *meaningful* I could do about this that would be great. What if the above simply returned S_OK with a FIXME instead of E_NOTIMPL??? Would that be an acceptable hack for the official source? David Anderson

2 1

RE: #2 kernel32: Implement GetTickCount64.
by Rolf Kalbermatter 08 Jul '07

08 Jul '07

Hans Leidekker wrote: >Changelog > Implement GetTickCount64. .... >--- a/dlls/kernel32/kernel_main.c >+++ b/dlls/kernel32/kernel_main.c >@@ -256,3 +256,11 @@ DWORD WINAPI GetTickCount(void) > { > return NtGetTickCount(); > } Is there a particular reason not to call NtGetTickCount64() directly here as is also done in NtGetTickCount(). On a side note: I wonder if older C compiler versions will simply do the right coercion from ULONGLONG to DWORD in these cases. Rolf Kalbermatter

2 1

DungeonSiege works!
by Robert Hurst 08 Jul '07

08 Jul '07

Finally running at full speed, see my post at http://appdb.winehq.org/appview.php?iVersionId=1017 But there is only 1 little 'cleanup' that would make this game perfect... its mouse pointer is clean, but the square it occupies is generally filled with a corrupted texture. I own two copies of the game, the original 1.0 and the latest Legends of Arianna 1.11 version. I can send a NOCD copy of it to a d3d developer, for debugging purposes, if that helps any. Send instructions, and it shall be done. Not as important as the mouse pointer, but the loading and saving of sessions is horribly slow, though improved as of 0.9.39. I wonder why? Thanks for 'resurrecting' a lot of abandoned Windows software for the community.

1 0

winealsa/dsound: Testers asked for capture patch
by Maarten Lankhorst 08 Jul '07

08 Jul '07

Since apparantly counter strike goes 2 fps or so when alsa is used and capture is enabled, I was looking to see if that can be speed up,. Since I don't have that game I cannot do it myself, so can someone test attached patch and see if that fixes performance problems? Maarten >From 7593fcf19ba306d0024048e7a49e87b7c8d5c318 Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> Date: Thu, 5 Jul 2007 00:41:59 +0200 Subject: [PATCH] winealsa: Increase performance of wavein getposition --- dlls/winealsa.drv/wavein.c | 12 +++--------- 1 files changed, 3 insertions(+), 9 deletions(-) diff --git a/dlls/winealsa.drv/wavein.c b/dlls/winealsa.drv/wavein.c index 5d731eb..412edd2 100644 --- a/dlls/winealsa.drv/wavein.c +++ b/dlls/winealsa.drv/wavein.c @@ -154,7 +154,7 @@ static DWORD CALLBACK widRecorder(LPVOID pmt) DWORD frames_per_period; wwi->state = WINE_WS_STOPPED; - wwi->dwTotalRecorded = 0; + InterlockedExchange((LONG*)&wwi->dwTotalRecorded, 0); wwi->lpQueuePtr = NULL; SetEvent(wwi->hStartUpEvent); @@ -198,7 +198,7 @@ static DWORD CALLBACK widRecorder(LPVOID pmt) { /* update number of bytes recorded in current buffer and by this device */ lpWaveHdr->dwBytesRecorded += bytesRead; - wwi->dwTotalRecorded += bytesRead; + InterlockedExchangeAdd((LONG*)&wwi->dwTotalRecorded, bytesRead); /* buffer is full. notify client */ if (lpWaveHdr->dwBytesRecorded == lpWaveHdr->dwBufferLength) @@ -247,7 +247,7 @@ static DWORD CALLBACK widRecorder(LPVOID pmt) /* update number of bytes recorded in current buffer and by this device */ lpWaveHdr->dwBytesRecorded += dwToCopy; - wwi->dwTotalRecorded += dwToCopy; + InterlockedExchangeAdd((LONG*)&wwi->dwTotalRecorded, dwToCopy); bytesRead -= dwToCopy; pOffset += dwToCopy; @@ -385,10 +385,6 @@ static DWORD CALLBACK widRecorder(LPVOID pmt) HeapFree(GetProcessHeap(), 0, buffer); ExitThread(0); /* shouldn't go here */ - case WINE_WM_UPDATE: - SetEvent(ev); - break; - default: FIXME("unknown message %d\n", msg); break; @@ -784,8 +780,6 @@ static DWORD widGetPosition(WORD wDevID, LPMMTIME lpTime, DWORD uSize) } wwi = &WInDev[wDevID]; - ALSA_AddRingMessage(&wwi->msgRing, WINE_WM_UPDATE, 0, TRUE); - return ALSA_bytes_to_mmtime(lpTime, wwi->dwTotalRecorded, &wwi->format); } -- 1.4.4.2

2 2

re: Rude hack fixes Run Time Error 445:Object Doesn't Support This Action
by Dan Kegel 08 Jul '07

08 Jul '07

Dave wrote: >The following rudely changed function: >static HRESULT WINAPI WebBrowser_put_RegisterAsBrowser(... >works around wine bug 5183. For me. >The app I use to run the test is a VB app written by a friend Can you throw together a minimal test in VB and attach it with source and binary to bug 5183? - Dan

1 0

Re: [5/5] WineD3D: Implement high order patches
by H. Verbeet 07 Jul '07

07 Jul '07

On 06/07/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > The right list this time > I realize this has already been committed, but is there no way to split tesselate_rectpatch() up a bit into smaller functions? It's rather huge at the moment.

3 2

Re: Paul Vriens : kernel32/tests 2/2: Use skip for not implemented function.
by Michael Stefaniuc 07 Jul '07

07 Jul '07

This patch introduced a lot of dead code. Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 35edd40f33ba8dce6d2c39fda46c6b5045947c1c > URL: http://source.winehq.org/git/wine.git/?a=commit;h=35edd40f33ba8dce6d2c39fda… > > Author: Paul Vriens <paul.vriens.wine(a)gmail.com> > Date: Thu Jul 5 16:35:10 2007 +0200 > > kernel32/tests 2/2: Use skip for not implemented function. > > --- > > dlls/kernel32/tests/profile.c | 24 +++++++++++++++--------- > 1 files changed, 15 insertions(+), 9 deletions(-) > > diff --git a/dlls/kernel32/tests/profile.c b/dlls/kernel32/tests/profile.c > index 4824ce8..b875134 100644 > --- a/dlls/kernel32/tests/profile.c > +++ b/dlls/kernel32/tests/profile.c > @@ -227,31 +227,37 @@ static void test_profile_sections_names(void) > ok( ret == 25, "expected return size 25, got %d\n", ret ); > ok( buf[ret+1] == 0 && buf[ret] == 0, "returned buffer not terminated with double-null\n" ); > > + /* Tests on nonexistent file */ > + memset(buf, 0xcc, sizeof(buf)); > + ret = GetPrivateProfileSectionNamesA( buf, 10, ".\\not_here.ini" ); > + ok( ret == 0, "expected return size 0, got %d\n", ret ); > + ok( buf[0] == 0, "returned buffer not terminated with null\n" ); > + ok( buf[1] != 0, "returned buffer terminated with double-null\n" ); > > /* Test with sufficiently large buffer */ > + SetLastError(0xdeadbeef); > ret = GetPrivateProfileSectionNamesW( bufW, 29, testfile3W ); Looks like some if () is missing here. The skip and return are therefor called unconditionally. Smatch is rightfully complaining about dead code after the return. > + { > + skip("GetPrivateProfileSectionNamesW is not implemented\n"); > + DeleteFileA( testfile3 ); > + return; > + } bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

winealsa/dsound: Testers asked for capture patch
by ling weak 07 Jul '07

07 Jul '07

Sorry, I couldn't notice any improvements using that patch. For your information: >From wine-0.9.36 to .39 graphics and sound were very choppy. As of wine-0.9.40 video is still stuck at 4fps but audio plays stutter-free. I think this was caused by your remixing-patch.

1 0

programs: Add extrac32
by Kirill K. Smirnov 07 Jul '07

07 Jul '07

> +int PASCAL wWinMain ( HINSTANCE hInstance, HINSTANCE prev, LPWSTR cmdline, int show ) Sorry for asking this too late, but what's the point to use WinMain in pure console application? 'cmd' and 'xcopy' use wmain. -- Kirill

2 1

Re: [1/2] gdiplus: rendering of linecaps [try2]
by Laurent Vromman 07 Jul '07

07 Jul '07

Why do you use M_PI / 2.0 or M_PI / 4.0 and not directly M_PI_2 and M_PI_4? Laurent Evan Stade a écrit : > Hi, > > [try2] Removed non-portable constructs. > > Changelog: > * added helpers that render line caps > * added end cap drawing for GdipDrawLineI > > dlls/gdiplus/graphics.c | 220 > ++++++++++++++++++++++++++++++++++++++++++++++- > dlls/gdiplus/pen.c | 5 - > 2 files changed, 217 insertions(+), 8 deletions(-) > > ------------------------------------------------------------------------ > > diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c > index 4765e33..6c40aec 100644 > --- a/dlls/gdiplus/graphics.c > +++ b/dlls/gdiplus/graphics.c > @@ -27,8 +27,11 @@ #include "gdiplus.h" > #include "gdiplus_private.h" > #include "wine/debug.h" > > -/* looks-right constant */ > +WINE_DEFAULT_DEBUG_CHANNEL(gdiplus); > + > +/* looks-right constants */ > #define TENSION_CONST (0.3) > +#define ANCHOR_WIDTH (2.0) > > static inline INT roundr(REAL x) > { > @@ -108,6 +111,212 @@ static void calc_curve_bezier_endp(REAL > *y = roundr(tension * (yadj - yend) + yend); > } > > +/* Draws the linecap the specified color and size on the hdc. The linecap is in > + * direction of the line from x1, y1 to x2, y2 and is anchored on x2, y2. */ > +static void draw_cap(HDC hdc, COLORREF color, GpLineCap cap, REAL size, > + REAL x1, REAL y1, REAL x2, REAL y2) > +{ > + HGDIOBJ oldbrush, oldpen; > + HBRUSH brush; > + HPEN pen; > + POINT pt[4]; > + REAL theta, dsmall, dbig, dx, dy, invert; > + > + if(x2 != x1) > + theta = atan((y2 - y1) / (x2 - x1)); > + else if(y2 != y1){ > + theta = M_PI / 2.0 * (y2 > y1 ? 1.0 : -1.0); > + } > + else > + return; > + > + invert = ((x2 - x1) >= 0.0 ? 1.0 : -1.0); > + brush = CreateSolidBrush(color); > + pen = CreatePen(PS_SOLID, 1, color); > + oldbrush = SelectObject(hdc, brush); > + oldpen = SelectObject(hdc, pen); > + > + switch(cap){ > + case LineCapFlat: > + break; > + case LineCapSquare: > + case LineCapSquareAnchor: > + case LineCapDiamondAnchor: > + size = size * (cap & LineCapNoAnchor ? ANCHOR_WIDTH : 1.0) / 2.0; > + if(cap == LineCapDiamondAnchor){ > + dsmall = cos(theta + M_PI / 2.0) * size; > + dbig = sin(theta + M_PI / 2.0) * size; > + } > + else{ > + dsmall = cos(theta + M_PI / 4.0) * size; > + dbig = sin(theta + M_PI / 4.0) * size; > + } > + > + /* calculating the latter points from the earlier points makes them > + * look a little better because of rounding issues */ > + pt[0].x = roundr(x2 - dsmall); > + pt[1].x = roundr(((REAL)pt[0].x) + dbig + dsmall); > + > + pt[0].y = roundr(y2 - dbig); > + pt[3].y = roundr(((REAL)pt[0].y) + dsmall + dbig); > + > + pt[1].y = roundr(y2 - dsmall); > + pt[2].y = roundr(dbig + dsmall + ((REAL)pt[1].y)); > + > + pt[3].x = roundr(x2 - dbig); > + pt[2].x = roundr(((REAL)pt[3].x) + dsmall + dbig); > + > + Polygon(hdc, pt, 4); > + > + break; > + case LineCapArrowAnchor: > + size = size * 4.0 / sqrt(3.0); > + > + dx = cos(M_PI / 6.0 + theta) * size * invert; > + dy = sin(M_PI / 6.0 + theta) * size * invert; > + > + pt[0].x = roundr(x2 - dx); > + pt[0].y = roundr(y2 - dy); > + > + dx = cos(- M_PI / 6.0 + theta) * size * invert; > + dy = sin(- M_PI / 6.0 + theta) * size * invert; > + > + pt[1].x = roundr(x2 - dx); > + pt[1].y = roundr(y2 - dy); > + > + pt[2].x = roundr(x2); > + pt[2].y = roundr(y2); > + > + Polygon(hdc, pt, 3); > + > + break; > + case LineCapRoundAnchor: > + dx = dy = ANCHOR_WIDTH * size / 2.0; > + > + x2 = (REAL) roundr(x2 - dx); > + y2 = (REAL) roundr(y2 - dy); > + > + Ellipse(hdc, (INT) x2, (INT) y2, roundr(x2 + 2.0 * dx), > + roundr(y2 + 2.0 * dy)); > + break; > + case LineCapTriangle: > + size = size / 2.0; > + dx = cos(M_PI / 2.0 + theta) * size; > + dy = sin(M_PI / 2.0 + theta) * size; > + > + /* Using roundr here can make the triangle float off the end of the > + * line. */ > + pt[0].x = ((x2 - x1) >= 0 ? floor(x2 - dx) : ceil(x2 - dx)); > + pt[0].y = ((y2 - y1) >= 0 ? floor(y2 - dy) : ceil(y2 - dy)); > + pt[1].x = roundr(pt[0].x + 2.0 * dx); > + pt[1].y = roundr(pt[0].y + 2.0 * dy); > + > + dx = cos(theta) * size * invert; > + dy = sin(theta) * size * invert; > + > + pt[2].x = roundr(x2 + dx); > + pt[2].y = roundr(y2 + dy); > + > + Polygon(hdc, pt, 3); > + > + break; > + case LineCapRound: > + dx = -cos(M_PI / 2.0 + theta) * size * invert; > + dy = -sin(M_PI / 2.0 + theta) * size * invert; > + > + pt[0].x = ((x2 - x1) >= 0 ? floor(x2 - dx) : ceil(x2 - dx)); > + pt[0].y = ((y2 - y1) >= 0 ? floor(y2 - dy) : ceil(y2 - dy)); > + pt[1].x = roundr(pt[0].x + 2.0 * dx); > + pt[1].y = roundr(pt[0].y + 2.0 * dy); > + > + dx = dy = size / 2.0; > + > + x2 = (REAL) roundr(x2 - dx); > + y2 = (REAL) roundr(y2 - dy); > + > + Pie(hdc, (INT) x2, (INT) y2, roundr(x2 + 2.0 * dx), > + roundr(y2 + 2.0 * dy), pt[0].x, pt[0].y, pt[1].x, pt[1].y); > + break; > + case LineCapCustom: > + FIXME("line cap not implemented\n"); > + default: > + break; > + } > + > + SelectObject(hdc, oldbrush); > + SelectObject(hdc, oldpen); > + DeleteObject(brush); > + DeleteObject(pen); > +} > + > +/* Shortens the line by the given percent by changing x2, y2. > + * If percent is > 1.0 then the line will change direction. */ > +static void shorten_line_percent(REAL x1, REAL y1, REAL *x2, REAL *y2, REAL percent) > +{ > + REAL dist, theta, dx, dy; > + > + if((y1 == *y2) && (x1 == *x2)) > + return; > + > + dist = sqrt((*x2 - x1) * (*x2 - x1) + (*y2 - y1) * (*y2 - y1)) * percent; > + theta = (*x2 == x1 ? M_PI / 2.0 : atan((*y2 - y1) / (*x2 - x1))); > + dx = cos(theta) * dist; > + dy = sin(theta) * dist; > + > + *x2 = *x2 + fabs(dx) * (*x2 > x1 ? -1.0 : 1.0); > + *y2 = *y2 + fabs(dy) * (*y2 > y1 ? -1.0 : 1.0); > +} > + > +/* Shortens the line by the given amount by changing x2, y2. > + * If the amount is greater than the distance, the line will become length 0. */ > +static void shorten_line_amt(REAL x1, REAL y1, REAL *x2, REAL *y2, REAL amt) > +{ > + REAL dx, dy, percent; > + > + dx = *x2 - x1; > + dy = *y2 - y1; > + if(dx == 0 && dy == 0) > + return; > + > + percent = amt / sqrt(dx * dx + dy * dy); > + if(percent >= 1.0){ > + *x2 = x1; > + *y2 = y1; > + return; > + } > + > + shorten_line_percent(x1, y1, x2, y2, percent); > +} > + > +/* Draws lines between the given points, and if caps is true then draws an endcap > + * at the end of the last line. FIXME: Startcaps not implemented. */ > +static void draw_polyline(HDC hdc, GpPen *pen, GDIPCONST GpPointF * pt, > + INT count, BOOL caps) > +{ > + POINT *pti = GdipAlloc(count * sizeof(POINT)); > + REAL x = pt[count - 1].X, y = pt[count - 1].Y; > + INT i; > + > + if(caps){ > + if(pen->endcap == LineCapArrowAnchor) > + shorten_line_amt(pt[count-2].X, pt[count-2].Y, &x, &y, pen->width); > + > + draw_cap(hdc, pen->color, pen->endcap, pen->width, pt[count-2].X, > + pt[count-2].Y, pt[count - 1].X, pt[count - 1].Y); > + } > + > + for(i = 0; i < count - 1; i ++){ > + pti[i].x = roundr(pt[i].X); > + pti[i].y = roundr(pt[i].Y); > + } > + > + pti[i].x = roundr(x); > + pti[i].y = roundr(y); > + > + Polyline(hdc, pti, count); > + GdipFree(pti); > +} > + > GpStatus WINGDIPAPI GdipCreateFromHDC(HDC hdc, GpGraphics **graphics) > { > if(hdc == NULL) > @@ -248,16 +457,21 @@ GpStatus WINGDIPAPI GdipDrawLineI(GpGrap > INT y1, INT x2, INT y2) > { > INT save_state; > + GpPointF pt[2]; > > if(!pen || !graphics) > return InvalidParameter; > > + pt[0].X = (REAL)x1; > + pt[0].Y = (REAL)y1; > + pt[1].X = (REAL)x2; > + pt[1].Y = (REAL)y2; > + > save_state = SaveDC(graphics->hdc); > EndPath(graphics->hdc); > SelectObject(graphics->hdc, pen->gdipen); > > - MoveToEx(graphics->hdc, x1, y1, NULL); > - LineTo(graphics->hdc, x2, y2); > + draw_polyline(graphics->hdc, pen, pt, 2, TRUE); > > RestoreDC(graphics->hdc, save_state); > > diff --git a/dlls/gdiplus/pen.c b/dlls/gdiplus/pen.c > index 0fcbb69..52515d5 100644 > --- a/dlls/gdiplus/pen.c > +++ b/dlls/gdiplus/pen.c > @@ -77,11 +77,6 @@ GpStatus WINGDIPAPI GdipSetPenEndCap(GpP > { > if(!pen) return InvalidParameter; > > - if(cap != LineCapFlat){ > - FIXME("Not implemented for non-flat EndCap\n"); > - return NotImplemented; > - } > - > pen->endcap = cap; > > return Ok; > > ------------------------------------------------------------------------ > > >

1 0

Wine tests failing on Linux
by Michael Stefaniuc 06 Jul '07

06 Jul '07

Hello! I was showing a little bit of schadenfreude on #winehackers that Alexandre has now failing Wine tests on his brand new computer. So I thought to do a full run of the Wine tests on my machine and report the errors. Maybe Alexandre will fix this bugs too ;) while at it. Test setup: - 3 GHz P4 with HT enabled - FC6 up2date box, self baked kernel (2.6.20.14 SMP) - GeForce FX 5200 with NVidia binary driver 1.0-9746 - EMU10k1 SB Live sound card - Out of source tree build wine and installed (make install). Running the tests: make testclean rm -rf ~/.wine wineprefixcreate make test When a test fails, run it a second time and if it still fails manually touch the offending *.ok file and run make test again. While make test was running I didn't touch the keyboard or the mouse. Results: Not as bad as I thought: "officially" only 3 files with failing tests. But there is one test that crashes, winedebug is run automatically, does a backtrace and returns with return code 0 thus make won't detect it as error: /home/michi/work/wine/tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p mshtml_test.exe.so /home/michi/work/wine/dlls/mshtml/tests/dom.c && touch dom.ok Could not load Mozilla. HTML rendering will be disabled. wine: Unhandled page fault on read access to 0x00000000 at address 0x604e9914 (thread 0023), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x604e9914). ... Backtrace: =>1 0x604e9914 test_doc_elem+0xd4(doc=0x165468) [/home/michi/work/wine/dlls/mshtml/tests/dom.c:66] in mshtml_test (0x0033fdf8) ... The "normal" test failures: /home/michi/work/wine/tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so /home/michi/work/wine/dlls/comctl32/tests/monthcal.c && touch monthcal.ok monthcal.c:773: Test succeeded inside todo block: Expected 65536, got 65536 make[2]: *** [monthcal.ok] Error 1 /home/michi/work/wine/tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so /home/michi/work/wine/dlls/gdi32/tests/font.c && touch font.ok font.c:1574: Test failed: A: tmDefaultChar for Goha-Tibeb Zemen 20 != 0x1f font.c:1574: Test failed: A: tmDefaultChar for Lucida Sans Typewriter ff != 0x1f font.c:1574: Test failed: A: tmDefaultChar for Lucida Sans Typewriter ff != 0x1f font.c:1574: Test failed: A: tmDefaultChar for Lucida Sans Typewriter ff != 0x1f font.c:1574: Test failed: A: tmDefaultChar for Lucida Sans Typewriter ff != 0x1f font.c:1574: Test failed: A: tmDefaultChar for Lucida Sans Typewriter ff != 0x1f font.c:1574: Test failed: A: tmDefaultChar for Lucida Sans Typewriter ff != 0x1f font.c:1574: Test failed: A: tmDefaultChar for Lucida Sans Typewriter ff != 0x1f font.c:1574: Test failed: A: tmDefaultChar for Lucida Sans Typewriter ff != 0x1f font.c:1574: Test failed: A: tmDefaultChar for Lucida Sans Typewriter ff != 0x1f make[2]: *** [font.ok] Error 10 /home/michi/work/wine/tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so /home/michi/work/wine/dlls/user32/tests/msg.c && touch msg.ok msg.c:5878: Test failed: Alt+MouseButton press/release: the msg 0x0104 was expected, but got msg 0x0021 instead msg.c:5878: Test failed: Alt+MouseButton press/release: the msg 0x0104 was expected, but got msg 0x0021 instead msg.c:5878: Test failed: Alt+MouseButton press/release: the msg 0x0201 was expected, but got msg 0x0104 instead msg.c:5878: Test failed: Alt+MouseButton press/release: the msg 0x0201 was expected, but got msg 0x0104 instead msg.c:5878: Test failed: Alt+MouseButton press/release: the msg 0x0202 was expected, but got msg 0x0201 instead msg.c:5878: Test failed: Alt+MouseButton press/release: the msg 0x0202 was expected, but got msg 0x0201 instead msg.c:5878: Test failed: Alt+MouseButton press/release: the msg 0x0105 was expected, but got msg 0x0202 instead msg.c:5878: Test failed: Alt+MouseButton press/release: the msg 0x0105 was expected, but got msg 0x0202 instead msg.c:5878: Test failed: Alt+MouseButton press/release: the msg sequence is not complete: expected 0000 - actual 0105 make[2]: *** [msg.ok] Error 9 bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Dead links in the source
by Detlef Riekenberg 06 Jul '07

06 Jul '07

On Fr, 2007-07-06 at 18:33 +0200, Stefan Dösinger wrote: > -/* Implementation details at http://developer.nvidia.com/attach/6494 > -and > -http://oss.sgi.com/projects/ogl-sample/registry/NV/evaluators.txt > -hmm.. no longer supported use > -OpenGL evaluators or tessellate surfaces within your application. > -*/ > - > -/* > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c… */ That Patch stopped one line to early. The URL is dead What is the general advise for links? Many links to msdn.microsoft.com are dead. Total: detlef@p4:~/wine.cvs/src$ grep http:// dlls/*/* | wc -l 195 detlef@p4:~/wine.cvs/src$ grep msdn.microsoft.com dlls/*/* | wc -l 75 Should we remove or update the old links? (I prefer: remove) IMHO, a nice Janatorial Project -- By by ... Detlef

2 1

Re: crypt32: implement CryptSIPLoad (resend)
by Alexandre Julliard 06 Jul '07

06 Jul '07

"Juan Lang" <juan.lang(a)gmail.com> writes: > Hi, any feedback on this one, please? You should use module handles to identify dlls, not file names. You can use GetModuleHandle to find out if a dll is loaded already. -- Alexandre Julliard julliard(a)winehq.org

2 4

Random X errors caused by recent cursor patch
by Vitaly N. Zadunaisky 06 Jul '07

06 Jul '07

Subject: Using Win32 apllication under wine. Using wine for running win32 applications we met the problem. The origin error is: X Error of failed request: BadPixmap (invalid Pixmap parameter) Major opcode of failed request: 54 (X_FreePixmap) Resource id in failed request: 0x2a029f9 Serial number of failed request: 105496 Current serial number in output stream: 107860 After this error application crashes. The error appears when menu items is selected for some action. ------------------------------------------------------------------------------------- The patch described in http://www.winehq.org/pipermail/wine-devel/2007-April/055637.html apparently helps us. Great thanks! But it's still not fixed in current release 0.9.40, as I can understand. ------------------------------------------------------------------------------------- Good luck. good-bye. Yours faithfully Vitaly

2 1

[5/5] WineD3D: Implement high order patches
by Stefan Dösinger 06 Jul '07

06 Jul '07

1 0

Re: programs:extrac32: Add new program (Extrac32.exe) (Pre alpha version :)) [try2]
by Detlef Riekenberg 06 Jul '07

06 Jul '07

On Do, 2007-07-05 at 20:00 +0400, Anatoly Lyutin wrote: > --- programs/Makefile.in 18 May 2007 13:05:27 -0000 1.65 > +++ programs/Makefile.in 4 Jul 2007 15:47:09 -0000 > --- Makefile.in 21 Jun 2007 14:49:30 -0000 1.243 > +++ Makefile.in 4 Jul 2007 15:45:57 -0000 > --- configure.ac 4 Jul 2007 11:58:41 -0000 1.679 > +++ configure.ac 4 Jul 2007 15:45:29 -0000 Please do not include any autogenerated code. The files are updated by "tools/make_makefiles", when Alexandre commit your Patch. This prevent conflicting Patches, when another Program is added at the same Time. Thanks -- By by ... Detlef

1 0

programs:extrac32 Add new program (Extrac32.exe) (Pre alpha version :))
by Kirill K. Smirnov 06 Jul '07

06 Jul '07

Hi, > +MODULE = EXTRAC32.exe It is very unusual to have upper-case name of exe file > WriteConsole(GetStdHandle(STD_OUTPUT_HANDLE),"Run Wine Extrac32. \n",strlen("Run Wine Extrac32.\n"),NULL,NULL); The utility is compiled as UNICODE (EXTRADEFS = -DUNICODE), thus WriteConsoleW is used, but here MultiByte string is passed. As expected, it does not work. Moreover, if output is redirected to file, it does not work, since WriteConsole can be used only with real console. msvcrt printf is better from this point of view, but it does not suit us, see bug #8598 and bug #8554. Currenly working solution is implemented in cmd.exe (and msdn recommends this: http://msdn2.microsoft.com/en-us/library/ms687401.aspx) -- Kirill

3 3

Issue(s) when running winetest on Windows
by Paul Vriens 06 Jul '07

06 Jul '07

Hi, I've had several cases in the last weeks where I run a wintest on Windows and it was submitted. It however never showed up on tests.winehq.org. Currently there's no error reporting on that box for the tests page creation (will look into that if time permits). The one reason I've found so far it that sometimes the results file contains: msvcrt:file start dlls/msvcrt/tests/file.c 1.48 file: 3 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 2 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 2 tests executed (0 marked as todo, 0 failures), 0 skipped. msvcrt:file done (0) file: 373 tests executed (0 marked as todo, 0 failures), 0 skipped. instead of the correct: msvcrt:file start dlls/msvcrt/tests/file.c 1.48 file: 3 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 2 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 2 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 373 tests executed (0 marked as todo, 0 failures), 0 skipped. msvcrt:file done (0) And this is the only reason I've found for this particular test. So now before submitting the results I check the results file and change the contents accordingly. (I didn't make a list yet on which platforms it occurs). The current dissect expects a 'start' line, right after a 'done' line and bails out if this isn't the case. Can anybody thinks of reasons why some of these lines come after the 'done' line? Or better yet, why lines are not always in the correct order? I do find some spurious entries every now and then that should have belonged to a different tests. The only reason I can think of so far is when a test creates a new process and somethings goes wrong there. Cheers, Paul.

1 0

crosstest target missing dependency on idl headers
by John Klehm 06 Jul '07

06 Jul '07

Hello, Just thought I'd mention that the crosstest target is missing dependencies on headers generated from .idl files. The ones that come up for me are tmarshal.h(oleaut32) and server.h (rpcrt4). Thanks to Hans Leidekker for helping me find my way on this. So as of right now here is how the process works: >From a clean source dir: ./configure make crosstest => error: missing tmarshal.h make -C dlls/oleaut32/tests => errors out as well but it builds tmarshal.h make crosstest => error: missing server.h make -C dlls/rpcrt4/tests => errors out as well but builds server.h make crosstest => suceeds Maybe this will be helpful to someone else who found it slightly confusing. John

1 0

appdb not working
by Stefan Leichter 05 Jul '07

05 Jul '07

Hello, is anyone else getting the error message "Fatal error: type of variable cw is not recognized." when browsing http://appdb.winehq.org/ with konquerror? My system is debian etch (kde 3.5.5). The main page of the appdb is working well with iceweasel (mozilla). The problem started after the downtime on last weekend for me. Bye Stefan

5 4

re: Direct3D Game test framework
by Dan Kegel 05 Jul '07

05 Jul '07

Martin wrote: > on YAWT homepage, I read: > "YAWT can be used either standalone, or as part of the > cxtest.org automated regression test suite for Wine" > > You mean, it can generate result emails which can be parsed by CxTest server? I mean that it should be trivial to wrap a Yawt test into a cxtest script... Lei's got this on his todo list, part of the work will be making sure the yawt test results feed smoothly into cxtest (which we haven't looked at yet, really).

1 0

access restrictions / sandbox
by Ioannis Nousias 05 Jul '07

05 Jul '07

Hello wine developers, I'm running Wine on Linux. Is there a way to restrict wine from accessing some folders and/or resources? Ideally have Wine restraint in its WINEPREFIX directory and configure what resources it could access (like network for instance). I've seen few talks on having a 'sandbox' that date back to 2002 and most conclusions suggest that access restrictions should be made on the host OS. If that's the case, any tips on how one could do that in Linux would be appreciated. Thanks. -Ioannis

4 4

Re: [kernel32/tests 1/2] Don't crash on win98
by Vitaliy Margolen 05 Jul '07

05 Jul '07

Paul Vriens wrote: > Hi, > > Test crashes on win98. > > Changelog > Don't crash on win98 > > Cheers, > > Paul. > As I recall some programs do this and it works. And those programs strictly require w2k+ to work. Should we use a version check here instead? Vitaliy.

2 2

Re: gdi32: Using a bitmap font as the sans serif fallback is a very bad idea.
by Vitaliy Margolen 05 Jul '07

05 Jul '07

Huw Davies wrote: > --- > dlls/gdi32/freetype.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > You reverting this patch: commit 69a23a608eea59624b2f37ab424e0f42b3da5baf Author: Dmitry Timoshkov <dmitry(a)codeweavers.com> Date: Thu Feb 23 20:33:06 2006 +0800 gdi: Use "MS Sans Serif" as default sans serif font, not Arial. Any reasons why? Also AFAIK native does not use Arial for any part of the interface. Vitaliy.

2 2

Re: programs:extrac32 Add new program (Extrac32.exe) (Pre alpha version :))
by Vitaliy Margolen 05 Jul '07

05 Jul '07

Anatoly Lyutin wrote: > This program (EXTRAC32.exe) needed for extract *.cab files. Some Win > programs use EXTARC32.exe for inner functions and often impossible to > change unpacker. I test this EXTRAC32.exe for one program (Russian > office program) and it works! > > I shall be glad for all comments which will help to make this program > better. > +static BOOL ExtCmp( const WCHAR str1[], const WCHAR str2[] ) Any reason you are not using strcmpW? > +LRESULT WINAPI ExtCabCallback ( IN PVOID pMyInstallData, > + IN UINT Notification, > + IN UINT Param1, > + IN UINT Param2 ) > +{ What do you need the "IN" here for? It's the useless domain of some parts of PSDK. Please use one format of indentation, if (), function( p1, p2, p3 ), etc. It's hard to impossible to read your code with at least 5-10 different variations of both some times IN ONE LINE! > + case SPFILENOTIFY_NEEDNEWCABINET: // Unexpected. > + lRetVal = NO_ERROR; > + break; > + } Do not use c++ comment stile. This part is completely useless - you set lRetVal = NO_ERROR; above already. Same type of mistake all over the place. > +++ programs/extrac32/parsecmd.c 2007-07-04 16:12:38 +0400 What do you need a whole separate file for? It has only one function! > + for(i=0;i<strlenW(cmdline);i++) > + { > + if( ((cmdline[i] == ' ')||(cmdline[i] == '\t') )&&(!bCav)&&((i!=0)&&(cmdline[i-1]!=' ')&&(cmdline[i-1]!='\t')) ) > + { This will never be true with i == 0, so you might as well start from i = 1. > + if( (cmdline[strlenW(cmdline)-1] != ' ')&&(cmdline[strlenW(cmdline)-1] != '\t') ) > + (*argc)++; What if cmdline is ""? What will be be checking here? Also you really should combine this with the previous for() loop. > + if(cmdline[i] == '\"') You don't need to escape double-quote here. Vitaliy.

2 1

Re: msi [2/13]: Handle remote calls to MsiDoAction
by Robert Shearman 05 Jul '07

05 Jul '07

James Hawkins wrote: > > package = msihandle2msiinfo( hInstall, MSIHANDLETYPE_PACKAGE ); > if (!package) > - return ERROR_INVALID_HANDLE; > + { > + HRESULT hr; > + IWineMsiRemotePackage *remote_package; > + > + remote_package = (IWineMsiRemotePackage *)msi_get_remote( hInstall ); > + if (!remote_package) > + return ERROR_INVALID_HANDLE; > + > + hr = IWineMsiRemotePackage_DoAction( remote_package, (BSTR *)szAction ); > BSTR * is the same level of indirection as LPWSTR *, which is not what you want. Also note that in general you can convert from BSTR to LPWSTR, but not LPWSTR to BSTR (as LPWSTR don't have the string length secretly stashed away before the string starts). The same applies to some of your other patches too. > + > + IWineMsiRemotePackage_Release( remote_package ); > + > + if (FAILED(hr)) > + { > + if (HRESULT_FACILITY(hr) == FACILITY_WIN32) > + return HRESULT_CODE(hr); > + > + return ERROR_FUNCTION_FAILED; > + } > + > + return ERROR_SUCCESS; > + } > > ret = ACTION_PerformUIAction( package, szAction, -1 ); > msiobj_release( &package->hdr ); > -- Rob Shearman

1 0

About stdlib.h system()
by Zhongli Xu 05 Jul '07

05 Jul '07

Hi all, I tried to call another .exe file in my own exe file by using the system() API. But the return value of system() is -1 and errno is set to ENOENT. It indicates that the another exe file is not found. So I copy the another exe to the fake directory: C:\windoes\system32, since wine always find the exe file there. And I also set the environment variable "System" and "Path" in the key HOST_CURRENT_USER/Environment thru regedit. But still, wine couldn't find the another exe. Any help is welcomed. Milo Xu

4 4

[PATCH] winspool.drv: Fallback to the first found printer as default printer [try 2]
by Pedro Araujo Chaves Jr. 04 Jul '07

04 Jul '07

--- dlls/winspool.drv/info.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) Detlef Riekenberg wrote: > > Sorry, I misinterpreted the Patch because of the subject. > > I'm fine with your Patch, when you fix your typo: > > > + if (hadprinter & !haddefault) > > + WINSPOOL_SetDefaultPrinter(dests[0].name, dests[i].name, TRUE); > > With greetings from Copy and Paste: [i] => [0] > > > For the subject, I suggest to include "Fallback": > winspool.drv: Fallback to the first found printer as default printer Thank you for your comments, and sorry for the typo and the ambiguous subject… - Pedro.

1 0

Re: [try4 3/3] gdi32: added PATH_PolyDraw
by Misha Koshelev 04 Jul '07

04 Jul '07

> If either part of an if-else statement is compound, then fully-bracketed > syntax (as it is known) is considered good style by some (for example, see > the Indian Hill Style and Coding Standard): it may make problem detection > easier. > > -- > Andy. Ah, ok. Never mind about this stylistic comment then. Misha

1 0

CreateJobObject (kernel32) and friends
by Donald Gordon 04 Jul '07

04 Jul '07

Hi I'm trying to get Visual C++'s vcbuild (builds project files from the command line) running under Wine, but it seems to need CreateJobObject (and I'm guessing the other job object functions), which doesn't appear to be implemented yet. Is implementing this something that would be doable by someone new to the Wine code? Or does someone have most of an implementation of this lying around uncommitted already? thanks donald

2 2

re: CreateJobObject (kernel32) and friends
by Dan Kegel 04 Jul '07

04 Jul '07

don wrote: > I'm trying to get Visual C++'s vcbuild (builds > project files from the command line) running > under Wine, but it seems to need CreateJobObject Which version of Visual C++ is this?

3 3

Re: [PATCH] WINSPOOL.DRV: Choose first printer found as the default
by Detlef Riekenberg 04 Jul '07

04 Jul '07

On Di, 2007-07-03 at 14:06 -0300, Pedro Araujo Chaves Jr. wrote: > # [PATCH] WINSPOOL.DRV: Choose first printer found as the default Why do you think, that you need this? Different default Printers (CUPS and Wine) confuse most Users. > -- By by ... Detlef

2 2

[try4 3/3] gdi32: added PATH_PolyDraw
by Misha Koshelev 04 Jul '07

04 Jul '07

> + else if((types[i] & ~PT_CLOSEFIGURE) == PT_LINETO){ > + PATH_LineTo(dc, pts[i].x, pts[i].y); > + } > + if(!((i + 2 < cbPoints) && (types[i + 1] == PT_BEZIERTO) > + && ((types[i + 2] & ~PT_CLOSEFIGURE) == PT_BEZIERTO))){ > + goto err; > + } > + else{ > + goto err; > + } On a more stylistic note, any reason for all these single line if statements that have their contents enclosed in {}'s? (i.e., instead of: if (a) { call_b(); } why not just: if (a) call_b(); If anything, this adds one unnecessary line with the single } after the statement itself, and seems unnecessary to me. Misha

2 1

Re: [try4 3/3] gdi32: added PATH_PolyDraw
by Misha Koshelev 04 Jul '07

04 Jul '07

> @@ -835,6 +835,10 @@ BOOL WINAPI PolyDraw(HDC hdc, const POIN > result = dc->funcs->pPolyDraw( dc->physDev, lppt, lpbTypes, cCount ); > goto end; > } > + if( PATH_IsPathOpen( dc->path ) ){ > + result = PATH_PolyDraw(dc, lppt, lpbTypes, cCount); > + goto end; > + } I believe the correct order here is: --- if( PATH_IsPathOpen( dc->path )) result = PATH_PolyDraw(dc, lppt, lpbTypes, cCount); else if (dc->funcs->pPolyDraw) result = dc->funcs->pPolyDraw( dc->physDev, lppt, lpbTypes, cCount ); else{ Non-path open case here result = TRUE; } end: GDI_ReleaseObj( hdc ); return result; --- The reason is that BeginPath either calls pBeginPath, in which case the gdi driver handles the path calls, or it sets path state to PATH_Open, which means we will be handling the path ourselves and we then do not call any of the gdi driver's pFunc functions while we are in the path (also if you look at most of the other functions in painting.c they are implemented in this way). Also, if you do the if ... else's like I showed above, you can avoid all the goto's except the ones in the non-path open case in case of failure. Misha

1 0

Re: [advapi32] Create a standard Wine list to keep track of the service handles
by Paul Vriens 04 Jul '07

04 Jul '07

On 7/3/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > This patch makes sure we can check if a service handle is valid. With this patch > the tests I've sent previously will pass. If this one is accepted I'll resent > the corrected tests. > > Changelog > Create a standard Wine list to keep track of the service handles > > Cheers, > > Paul. > > > Hi, I'm assuming this patch was not up to standard. What do I need to change to get this thing on the road? Is it way to much overkill? Should I go a different path for these handle checks? Cheers, Paul.

1 0

dsound: Disable property sets if hardware doesn't support it
by Maarten Lankhorst 04 Jul '07

04 Jul '07

2007/7/4, Robert Reif <reif(a)earthlink.net>: > This patch: > http://www.winehq.org/pipermail/wine-patches/2007-June/039942.html > causes RightMark3DSound.exe > (http://audio.rightmark.org/products/rm3ds.shtml) to crash. > > It appears that the code always expects a property set interface to > succeed and > crashes on a NULL pointer when it doesn't. > > Reverting this patch lets the program run. I'm trying to find wether it's a caps/flags issue or wether that patch is bad, not sure yet. I cant look today yet, but it seems that returning that is not entirely invalid, since testsuite for propset sort of allows it to fail, so perhaps it's something else. I'll try to take a look after I'm done with exams. Maarten

1 0

Re: secur32: Don't free the password in InitializeSecurityContextW to enable the credentials handle to be re-used in further InitializeSecurityContextW calls.
by Kai Blin 04 Jul '07

04 Jul '07

Is that possible in Windows or is this a hack to work around a missing credentials cache? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

2 2

Re: ole32: Constify some variables (2 of 2) (Resend)
by Alexandre Julliard 04 Jul '07

04 Jul '07

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > What is wrong with this patch, please? gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_OLE32_ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o storage32.o storage32.c storage32.c:3498: error: conflicting types for ‘StorageImpl_WriteBigBlock’ storage32.c:94: error: previous declaration of ‘StorageImpl_WriteBigBlock’ was here make[2]: *** [storage32.o] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Ubuntu starting to support windows autorun.inf on cd-rom insertion!
by Dan Kegel 04 Jul '07

04 Jul '07

Check this out. Hanusz Leszek just posted a patch implementing part of https://wiki.ubuntu.com/autorun It's at http://launchpadlibrarian.net/8292130/gnome-volume-manager-autorun-inf-02.p… Are we ready for prime time, kids? :-)

5 7

How to make your machine crash when running Wine
by gslink 04 Jul '07

04 Jul '07

If you are using the Nvidia drivers posted on the Nvidia web site then you MUST reinstall these drivers whenever you update ANY of the X-server software. If you replace the kernel you will be forced to reinstall the drivers but just replacing the X-server or the open GL code does not do this. Not reinstalling drivers when video code is replaced usually causes problems. It seems like every time RH updates any video code but does not upgrade the kernel at the same time there are complaints that Wine causes machines to crash. This is the reason.

4 3

Re: dsound: Disable property sets if hardware doesn't support it
by Robert Reif 04 Jul '07

04 Jul '07

This patch: http://www.winehq.org/pipermail/wine-patches/2007-June/039942.html causes RightMark3DSound.exe (http://audio.rightmark.org/products/rm3ds.shtml) to crash. It appears that the code always expects a property set interface to succeed and crashes on a NULL pointer when it doesn't. Reverting this patch lets the program run.

1 0

Parallels Wine DLLs
by Stefan Dösinger 03 Jul '07

03 Jul '07

Hi All! I need your help with testing here: You may have noticed the buzz about Wine DLLs in Parallels Desktop for Mac last weekend. Yesterday Parallels has sent me their modified Wine source, or at least what they claim to be. (http://84.112.174.163/~stefan/WineD3D-0.9.36-Parallels.zip). Can those with a Parallels for Mac license test the rebuilt binaries? The thing is, the modifications in the source does not match the Integration into Windows I have seen in the original Parallels distribution. I don't think thats a malicious attempt to hide something, but rather that they sent us their current development version instead of the Parallels 3.0 version. The new libs do not link dynamically any more against their opengl icd, instead they do lazy linking, which makes compiling the libs easier. Also I think in the old version, the app still talked to microsoft's DLLs, which passed everything through to our dlls. In the source, the apps talk to our dlls, which have an option to pass things through to the original DLLs. I have so far no reason to believe that there are any other changes between the source and the original builds, but I want to be sure. Yes, its technically still a LGPL violation, but IMHO not a huge deal(as compared to not giving the source out at all). Since we can't look into the original shipped DLLs, we'll have to test if the source code works as well as the original DLLs. Steven Edwards has compiled them, and I've uploaded the binaries to http://84.112.174.163/~stefan/parawine.tar.bz2. As a first note, he compiled them using mingw, not using MSVC, so that may cause problems. If I understand the code correctly, installation should work as follows: (Perhaps don't test in a production VM, test in a seperate test VM). Rename the existing C:\windows\system32\d3d8.dll to d3d8.sav, same for d3d8.dll and d3d9.dll and ddrawex.dll and wined3d.dll(no backup needed here). Then put the DLLs from the archive above into C:\windows\system32, perhaps reboot(to be sure) and test your games. I saw that ddraw.dll did not build, so perhaps someone with Microsoft Visual Studio can try to rebuild the DLLs? What to look for? Do the D3D games work at all? Do some games stop to work although they worked before? Do some games work although they didn't work before? Thanks for testing, Stefan PS: I hope there is someone with a Parallels license on this list :-/

3 5

illegal characters in file names
by Lei Zhang 03 Jul '07

03 Jul '07

Hi, I noticed a mismatch between the list of illegal characters in file names between Wine and Windows. On Wine the list of characters is: /:<>| and on Windows, it is: \/:*?"<>| Is this intentional or something we should fix? - Lei

6 7

Re: winealsa.drv: Tell the user how big his period size is.
by Maarten Lankhorst 03 Jul '07

03 Jul '07

I would rather have that it's only reported in case of period size = 1024 (default dmix) and as a WARN that says 'use 512' instead, since dmix apparantly doesn't always work well with 256 after all on my other pc. Maarten

1 0

Wine and C99 inline incompatibility
by Zephiris 03 Jul '07

03 Jul '07

I haven't seen this addressed and couldn't get an answer out of anyone on IRC. GCC defines 'extern inline' very differently from other compilers and C99. inline isn't actually guaranteed to inline (obviously), but 'extern inline' on GCC never defines a global function. References to the function are either inlined, or passed to another global function. In definition blocks that include things like InterlockedExchange, GCC's behavior of extern inline is relied on heavily, specifically that it'll (effectively) never conflict with another definition, and never define a symbol. Specifically, this appears to conflict with, say, when InterlockedExchange is actually defined later in the source file. Even if 'extern inline' is replaced by 'static inline', that's a problem. For that particular case, for instance, I tried to work around by only exporting separate extern declaration if _KERNEL32_ is defined, otherwise define the static inline part, since InterlockedExchange needs to be exported. But not so amusingly, the tools (loader, programs, etc) don't export __WINESRC__, so can't bring in the inlined definitions. I'm not quite sure how the GCC version of thing gets around that, as the extern inline versions aren't exported, and the tools don't depend on -kernel32. There are, of course, a few ways to get around that. Either #if __STDC_VERSION__ >= 199901L has to be used (which would entail all compilers going for specific C99 compliance only apparently), or compiler-specific blocks, or both, but it appears as if either __WINESRC_ needs to be defined for tools/server/etc as well, or they need to depend on kernel32, with no inline blocks defined for these things. There are a few other GCC-isms used that are incompatible with basically everything else, but this appears to be the great big ugly one. If I've missed something, or there's another option, let me know, but it's been nasty trying to work around this one at all, since trying to simply forcibly define __WINESRC__ for the rest would probably doom any patch. And before anyone asks, part of the reason this is coming up is because GCC apparently doesn't produce the most debuggable code on Solaris. But besides that, less explicit dependence on GCC for things where there's no functional difference would be a good thing, no? ^^; [ Reference: http://blogs.sun.com/x86be/entry/gcc_style_asm_inlining_support http://www.greenend.org.uk/rjk/2003/03/inline.html http://developer.apple.com/documentation/developertools/gcc-4.0.1/gcc/Inlin… ]

3 3

[Resubmit]: Added wrapper dll for ct-api(CardTerminal API)
by Christian Eggers 03 Jul '07

03 Jul '07

Hello, possibly my previous patch got lost :-) If anything is wrong with the patch, please let me know. regards Christian ------- Weitergeleitete Nachricht / Forwarded message ------- Hello, I've made the suggested changes and prepared a new patch (sorry for the long time of waiting). In the meantime I got some additional feedback from other users of this DLL, hence I added a searchlist for different possible low-level libraries which might be extended in future. regards Christian > On 5/6/07, Christian Eggers <ceggers(a)gmx.de> wrote: > > Hello, > > > > this wrapper dll permits access to chipcard readers which provides a ct-api (CardTerminal > > It looks really good. A couple of quick comments for future patches. > Please use a standard LGPL license header in your patch for the > header, don't use C++ comments and you don't have to add a Changelog > entry. Alexandre's patch tools automatically adds it from your > email/changeset. > > [...] > > I forgot to mention the inclusion of config.h and port.h should come > before other headers in your source. > > Thanks > Steven Der folgende Teil dieser Nachricht enthält einen Anhang im sogenannten Internet MIME Nachrichtenformat. Wenn Sie Pegasus Mail oder ein beliebiges anderes MIME-kompatibles Email-System verwenden, sollte Sie den Anhang mit Ihrem Email-System speichern oder anzeigen können. Anderenfalls fragen Sie Ihren Administrator. The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- Datei Information/File information ----------- Datei/File: 0001-Added-wrapper-dll-for-ct-api-CardTerminal-API.txt Datum/Date: 3 Jul 2007, 17:15 Größe/Size: 11150 bytes. Typ/Type: Text

1 0

oleaut32: Constify some variables
by Andrew Talbot 03 Jul '07

03 Jul '07

Rob Shearman wrote: >> -static OLEFontImpl* OLEFontImpl_Construct(LPFONTDESC fontDesc); >> +static OLEFontImpl* OLEFontImpl_Construct(const FONTDESC *fontDesc); >> static void OLEFontImpl_Destroy(OLEFontImpl* fontDesc); >> static ULONG WINAPI OLEFontImpl_AddRef(IFont* iface); >Even if the compiler allows this, it does not make sense. Why would a >constructor not want to modify the object it is constructing? If I'm not mistaken, the input parameter points to the template from which it is copying, rather than the object it is constructing, in this case. -- Andy. [Sorry. I sent this without a subject line, just now.]

1 0

(no subject)
by Andrew Talbot 03 Jul '07

03 Jul '07

Rob Shearman wrote: >> -static OLEFontImpl* OLEFontImpl_Construct(LPFONTDESC fontDesc); >> +static OLEFontImpl* OLEFontImpl_Construct(const FONTDESC *fontDesc); >> static void OLEFontImpl_Destroy(OLEFontImpl* fontDesc); >> static ULONG WINAPI OLEFontImpl_AddRef(IFont* iface); >Even if the compiler allows this, it does not make sense. Why would a >constructor not want to modify the object it is constructing? If I'm not mistaken, the input parameter points to the template from which it is copying, rather than the object it is constructing, in this case. -- Andy.

1 0

[advapi32] Create a standard Wine list for the service handles
by Paul Vriens 03 Jul '07

03 Jul '07

Hi, I've attached a possible solution for checking the validity of the service handle before using it. Can somebody please comment on this? Do I need to protect the list with a CriticalSection? Is this overkill? Cheers, Paul.

2 2

Parallels Wine dlls rebuilt with mingw for your testing
by Steven Edwards 03 Jul '07

03 Jul '07

Hi, I expect if any ofyou are interested you've already talked to Stefan about the code drop from Parallels he is reviewing. I did a build of the drop with Mingw and was able to build everything except ddraw.dll. If anyone is interested in the binary and makefiles, I've forwarded the information on to Stefan with directions on how to build and a rather hackish patch. He said he would post the mingw package sometime later today. Thanks -- 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

3 2

request to change appdb message
by Louis. Lenders 03 Jul '07

03 Jul '07

Hi, since a few weeks the following message is displayed when you try to submit test results into appdb: Please DO NOT include crash or Wine debug output. Instead report the crash as a bug in the Wine bugzilla at http://bugs.winehq.org. We ask that you use bugzilla because developers do not monitor the AppDB for bugs. I'm not that happy with this message for a few reasons: 1. Most testers will not attach this to a bug, either because there isn't an entry for the app in bugzilla, or they don't bother to do so. 2. There are crashes like these that users attach: wine app.exe err:module:import_dll Library MSVBVM60.DLL (which is needed by L"C:\\app.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" failed, status c0000135 We don't want users to attach these things in bugzilla, we'd rather point them what to do in the email-field. If users don't attach crashes anymore to the testresults , i cannot by no means see anymore if a testresult is valid or not. I'd rather see something like: Please DO include crash or Wine debug output here, and report the crash as a bug in the Wine bugzilla at http://bugs.winehq.org. Any comments? --------------------------------- Yahoo! Answers - Get better answers from someone who knows. Tryit now.

6 12

ole32: Parameter question
by Andrew Talbot 02 Jul '07

02 Jul '07

Hi, In ole32/ifs.c:RemoveMemoryLocation(), should the parameter be a LPVOID *, or should it be just a LPVOID (or LPCVOID, to be more precise)? I want to constify it, but I'm uncertain if its current depth of indirection is correct. Thanks, -- Andy.

2 1

Re: oleaut32: Constify some variables
by Robert Shearman 02 Jul '07

02 Jul '07

Andrew Talbot wrote: > -static OLEFontImpl* OLEFontImpl_Construct(LPFONTDESC fontDesc); > +static OLEFontImpl* OLEFontImpl_Construct(const FONTDESC *fontDesc); > static void OLEFontImpl_Destroy(OLEFontImpl* fontDesc); > static ULONG WINAPI OLEFontImpl_AddRef(IFont* iface); Even if the compiler allows this, it does not make sense. Why would a constructor not want to modify the object it is constructing? -- Rob Shearman

1 0

Re: [4/5] WineD3D: Offscreen rendering from foreign threads
by Stefan Dösinger 02 Jul '07

02 Jul '07

Am Montag, 2. Juli 2007 17:46 schrieb Stefan Dösinger: Do not apply this patch yet, it has some problems. Patch 5 should still apply though

1 0

Crosscompile failures for gdiplus
by Paul Vriens 02 Jul '07

02 Jul '07

Hi, Ever since gdiplus tests (roughly 2 weeks ago) got added to Wine we have crosscompile failures: i386-mingw32-gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -Wcast-qual -o brush.cross.o brush.c brush.c:1: warning: -fPIC ignored for target (all code is position independent) i386-mingw32-gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -Wcast-qual -o pen.cross.o pen.c pen.c:1: warning: -fPIC ignored for target (all code is position independent) ../../../tools/make_ctests -o testlist.c brush.c pen.c i386-mingw32-gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -Wcast-qual -o testlist.cross.o testlist.c testlist.c:1: warning: -fPIC ignored for target (all code is position independent) i386-mingw32-gcc brush.cross.o pen.cross.o testlist.cross.o -o gdiplus_crosstest.exe -lgdiplus -lkernel32 /usr/local/lib/gcc/i386-mingw32/3.4.5/../../../../i386-mingw32/bin/ld: cannot find -lgdiplus collect2: ld returned 1 exit status make: *** [gdiplus_crosstest.exe] Error 1 Does anybody feel up to fixing MingW so we will have a new winetest executable soon? No new one since June 12 on http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ . Cheers, Paul.

3 2

Re: msi [6/10]: pcchValue represents the length of szValue in TCHARS, not bytes
by Alexandre Julliard 02 Jul '07

02 Jul '07

"James Hawkins" <truiken(a)gmail.com> writes: > @@ -341,10 +341,15 @@ UINT WINAPI MsiSourceListGetInfoW( LPCWS > } > else if (strcmpW(INSTALLPROPERTY_PACKAGENAMEW, szProperty)==0) > { > + *pcchValue = *pcchValue * sizeof(WCHAR); > rc = RegQueryValueExW(sourcekey, INSTALLPROPERTY_PACKAGENAMEW, 0, 0, > - (LPBYTE)szValue, pcchValue); > + (LPBYTE)szValue, pcchValue); > if (rc != ERROR_SUCCESS && rc != ERROR_MORE_DATA) > rc = ERROR_SUCCESS; > + if (*pcchValue) > + *pcchValue = (*pcchValue - 1) / sizeof(WCHAR); > + if (szValue) > + szValue[*pcchValue] = '\0'; You shouldn't use the results if the registry function failed. Also there isn't much point in checking pcchValue for NULL since you accessed it already. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [1/5] WineD3D: rsq and rcp use the .w component if no swizzle is given
by Alexandre Julliard 02 Jul '07

02 Jul '07

Stefan Dösinger <stefan(a)codeweavers.com> writes: > Updates the comment why the shader comment is needed - tests showed that the > shaders have to have a minimal size on windows. If the comment is only needed for size then you could use some padding instead of the actual string. If the string is needed then you should declare it as a string and copy it, not as an array of DWORDs, that will be a pain to maintain or grep. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [advapi32/tests #2] Add tests for OpenServiceA
by James Hawkins 02 Jul '07

02 Jul '07

On 7/2/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > I've added some tests for OpenServiceA. Some of them crash on Wine, but I've > opted to let them in (inside an if(0) though). The crashes happen because we > assume that when a handle is not NULL it's correct. > The policy for crashing tests is that you need to fix the bug that causes the tests to crash either before you send in the test patch or in the same patch as the tests. if(0) is only for tests that crash on Windows. -- James Hawkins

2 1

WineHQ screenshots link
by Alexander Nicolaysen Sørnes 02 Jul '07

02 Jul '07

Currently the Screenshots link on the WineHQ site points to a page with 9 screenshots and some links, while there are 3992 screenshots in the AppDB. Would anyone object to me changing the link to point to the AppDB instead? Alexander N. Sørnes

4 3

Re: [2/2] gdi32: fixed PolyDraw for open path case [try3]
by Alexandre Julliard 02 Jul '07

02 Jul '07

"Evan Stade" <estade(a)gmail.com> writes: > @@ -838,6 +838,65 @@ BOOL WINAPI PolyDraw(HDC hdc, const POIN > } > GDI_ReleaseObj( hdc ); > > + if( PATH_IsPathOpen( dc->path ) ){ > + lastmove.x = orig_pos.x = dc->CursPosX; > + lastmove.y = orig_pos.y = dc->CursPosY; Accessing the DC after GDI_ReleaseObj is not allowed. The code was doing that already so it's not your bug, but it would be good to fix it while you're at it. Also like Misha said you should put the open path case in a separate path function. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [winex11.drv] text/plain is CF_TEXT
by Alexandre Julliard 02 Jul '07

02 Jul '07

"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes: > The text/plain MIME type is exactly the same as CF_TEXT - both have > \r\n line endings so calling X11DRV_XDND_UnixToDos is wrong. It would probably be better to make X11DRV_XDND_UnixToDos cope with both formats, that should be easy. -- Alexandre Julliard julliard(a)winehq.org

1 0

wine 0.9.39: Calysto v1.4 NULL dereference reports
by Domagoj Babic 02 Jul '07

02 Jul '07

Hello, I finally found time to go through Calysto reports for wine. Here are the warnings related to applications. For libraries, since Calysto doesn't know the calling context, any parameter ptr dereference without checking is considered a bug. We can go over those warnings later if anyone is really interested. Here we go: --------------------------------------------------------------- wine 0.9.39: Calysto: ??/11 [Please replace ?? with the number of reports that require some corrective action, adding assertion is considered a corrective action. For every report, leave + if requires corrective action, replace with - if it's definitely false positive, and replace with ? if unknown. For false positives, please provide explanations. For ?, please ask what's unclear. If you discover new bugs that Calysto should have caught, please mention that as well.] *** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_fnt2bdf.bc *** Possible NULL-ptr deref (vc32): @/work/benchmarks/SOURCES/wine-0.9.39/tools/fnt2bdf.c:91 + main (fnt2bdf.c:548) calls return_data_value (@572), passing it a pointer to &(pTInfo->type_id), which return_data_value dereferences (@91). pTInfo aliases (lpdata+2), and lpdata was initialized with a call to get_resource_table (@561), which can set it to NULL (either if malloc (@534) returns NULL, or if it is set explicitly to NULL (@540)). *** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_makedep.bc *** Possible NULL-ptr deref (vc796): @/work/benchmarks/SOURCES/wine-0.9.39/tools/makedep.c:196 + Ptr p xmalloc-ed (makedep.c:187) dereferenced. Note that although xmalloc checks pointer (util.c:31), report(R_FATAL, "msg") does not exit, but only reports the msg and returns, so p (NULL) will be still dereferenced. *** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_sfnt2fnt.bc *** Possible NULL-ptr deref (vc47): @/work/benchmarks/SOURCES/wine-0.9.39/tools/sfnt2fnt.c:240 + malloc-ed ptr eblc dereferenced without checking Possible NULL-ptr deref (vc58): @/work/benchmarks/SOURCES/wine-0.9.39/tools/sfnt2fnt.c:321 + malloc-ed ptr dfCharTable dereferenced without checking Possible NULL-ptr deref (vc61): @/work/benchmarks/SOURCES/wine-0.9.39/tools/sfnt2fnt.c:338 + ptr os2, returned by function FT_Get_Sfnt_Table dereferenced without checking - I couldn't find the source of that function. *** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_winebuild_winebuild.bc *** Possible NULL-ptr deref (vc5400): @/work/benchmarks/SOURCES/wine-0.9.39/tools/winebuild/import.c:108 + seems that table->names can be NULL (or unitialized) at this line if the test @102 is false, and in the following call chain: main -> parse_options -> add_extra_ld_symbol -> add_name Possible NULL-ptr deref (vc5868): @/work/benchmarks/SOURCES/wine-0.9.39/tools/winebuild/import.c:362 + seems that ignore_symbols.names can be NULL if test @359 is true. *** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_winedump_winedump.bc *** Possible NULL-ptr deref (vc11598): @/work/benchmarks/SOURCES/wine-0.9.39/tools/winedump/main.c:334 + malloc-ed ptr buf dereferenced without checking Possible NULL-ptr deref (vc5636): @/work/benchmarks/SOURCES/wine-0.9.39/tools/winedump/debug.c:687 + malloc-ed ptr stabbuff dereferenced without checking *** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_winegcc_winegcc.bc *** Possible NULL-ptr deref (vc978): @/work/benchmarks/SOURCES/wine-0.9.39/tools/winegcc/winegcc.c:467 + ptr output_file, returned from strdup, dereferenced without checking. strdup can return NULL. Possible NULL-ptr deref (vc1013): @/work/benchmarks/SOURCES/wine-0.9.39/tools/winegcc/utils.c:118 + starray_dup (utils.c:136) initializes dup with strarray_alloc(). strarray_alloc also sets dup->base to NULL. Then strarray_dup calls strarray_add (@142), passing it a pointer to dup. If the test in strarray_add (@113) fails, the function dereferences dup->base directly. --------------------------------------------------------------- Feedback will be appreciated. I can't do another round of checking before Aug 1, as I'm travelling. At that point Calysto will have more knowledge about clib functions, hopefully resulting in more bugs being reported. Regards, -- Domagoj Babic http://www.domagoj.info/ http://www.calysto.org/

4 7

Re: ws2_32: Dont tell users to run Wine as root when sockets not creatable
by Kai Blin 01 Jul '07

01 Jul '07

On Saturday 30 June 2007 01:48:06 Ben Hodgetts (Enverex) wrote: > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index 90fa9b0..5984790 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -3767,9 +3767,11 @@ SOCKET WINAPI WSASocketW(int af, int type, int > protocol, > if (GetLastError() == WSAEACCES) /* raw socket denied */ > { > if (type == SOCK_RAW) > - MESSAGE("WARNING: Trying to create a socket of type > SOCK_RAW, will fail unless running as root\n"); Your mail client mangled the long lines. Please make sure to actually attach the patch before sending. git-format-patch does that when given the --attach parameter. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

2 2

Re: [PATCH] check for overflow of the textures areas.
by H. Verbeet 01 Jul '07

01 Jul '07

Native D3D actually seems to allow this, and just corrupts the memory. If we're going to do these checks, we should simply return WINED3D_OK, and possibly print a TRACE or WARN. (See eg. IWineD3DDeviceImpl_SetTextureStageState).

1 0

Re: mshtml: Implement HTMLDocument_QueryInterface for IHTMLDOMNode, IHTMLElement and IHTMLElement2.
by Jacek Caban 01 Jul '07

01 Jul '07

Hi, I've just sent a test showing that native doesn't implement these interfaces so we shouldn't either. It's strange because IDL declaration says something else. And BTW. your patch violates COM QueryInterface rules (not that MS always respects these rules...). Thanks, Jacek

2 4

The: "Wine Status - ChangeLog"
by Tomas.Zijdemans＠student.uib.no 30 Jun '07

30 Jun '07

This page has been dead since October 1. Since I'm not producing code for the Wine project, this is an area I'd like to contribute to. (I'm already taking screenshots of the API status page to see what happens from release to release :)) Is there some WineHQ folks here that would be willing to give me accsess? Regards.

3 2

Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]
by Koshelev, Misha Vladislavo 30 Jun '07

30 Jun '07

On 6/27/07, Evan Stade <estade at gmail.com> wrote: > Hi, > > [try2] The patch I sent yesterday was not properly todo_wined. Also, > this test is a bit more extensive (about twice as many points drawn). > It uses various point-type combination (even non-sensical ones such as > PT_LINETO | PT_MOVETO) to test the exact logic of PolyDraw with an > open path. > > changelog: > * added polydraw test to path testing (5 more todo_wines) > > dlls/gdi32/tests/path.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 70 insertions(+), 0 deletions(-) > > -- > Evan Stade > > Also, I'd add a PT_MOVETO into your first PolyDraw call so you can tell whether PT_CLOSEFIGURE adds a PT_MOVETO to orig_pos or lastmove, as the current version does not differentiate this. Misha

3 2

Announcing WineConf 2007
by Mike Hearn 29 Jun '07

29 Jun '07

Yes, it's true! The moment you've all been waiting for! On 6th/7th October, once more Wine hackers from around the world will meet to eat, drink, make merry, and discuss the finer details of reimplementing the Windows API. This year it's Googles turn to host it, and it'll be at the engineering office in Zurich. You too can chill out with these awesome froods by signing up for the wineconf mailing list, and surfing over to: http://wiki.winehq.org/WineConf2007 ... which is currently a bit sparse but will populate nearer the time. Fascinating talks! Interesting people! Hackfests galore ... and maybe even fondue! 6th/7th October. Be there or be square.

2 1

Re: Add combobox in winecfg:theme.c
by Vitaly Lipatov 29 Jun '07

29 Jun '07

В сообщении от 16 июня 2007 Yaroslav Skorokhodov написал(a): > Changelog > Add combobox for select base font size There was improvement allows select size of the base font (dpi actually) in LogPixel registry entry. It is useful thing (default font size is too small on 17" monitors). What's wrong with the patch? http://www.winehq.org/pipermail/wine-patches/2007-June/040496.html -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

1 0

Something wrong with my two patches?
by Markus Gömmel 29 Jun '07

29 Jun '07

On 21 and 22 June I submitted two small patches (for comctl32/datetime.c and user32/msgbox.c). Both should be ok, but definitly the first one (datetime.c)... Something wrong with them or only some normal delay in putting them into git? My last small patch went into git within 2 days... Only a question Thanks and regards Markus Gömmel m.goemmel(a)compulab.de

2 1

make test in winsock segfaulting after patch 4c5b55a0f8...
by Kai Blin 29 Jun '07

29 Jun '07

The following commit breaks the winsock test for me. commit 4c5b55a0f82e83793814a21eadec8b50d48751f3 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Jun 4 18:16:48 2007 +0200 server: Run async I/O APCs from the SIGUSR1 handler. I have attached the backtrace. This is currently stopping me from confirming if my WSAStringToAddress patch is correct. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 1

WinXP winsock test broken by commit e39dca6af6c87a30ab1d907c0468de2602a6e442
by Kai Blin 29 Jun '07

29 Jun '07

The tests added in patch commit e39dca6af6c87a30ab1d907c0468de2602a6e442 Author: Damjan Jovanovic <damjan.jov(a)gmail.com> Date: Thu Mar 22 08:03:28 2007 +0200 ws2_32: WSASendTo should always re-enable the FD_WRITE event. break the ws2_32 sock.c tests on WinXP SP2. sock.c:1832: Test failed: WaitForSingleObject failed, error 258 I'm afraid I don't really know what's going wrong there. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

3 2

Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]
by Misha Koshelev 29 Jun '07

29 Jun '07

On 6/27/07, Evan Stade <estade at gmail.com> wrote: > Hi, > > [try2] The patch I sent yesterday was not properly todo_wined. Also, > this test is a bit more extensive (about twice as many points drawn). > It uses various point-type combination (even non-sensical ones such as > PT_LINETO | PT_MOVETO) to test the exact logic of PolyDraw with an > open path. > > changelog: > * added polydraw test to path testing (5 more todo_wines) > > dlls/gdi32/tests/path.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 70 insertions(+), 0 deletions(-) > > -- > Evan Stade > > Also, the attached (much shorter) diff makes all your tests conform on wine for me. I am a little confused as to where the non-open-path part of your PolyDraw patch came from (maybe I am missing something). Misha

1 0

Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]
by Misha Koshelev 29 Jun '07

29 Jun '07

On 6/27/07, Evan Stade <estade at gmail.com> wrote: > Hi, > > [try2] The patch I sent yesterday was not properly todo_wined. Also, > this test is a bit more extensive (about twice as many points drawn). > It uses various point-type combination (even non-sensical ones such as > PT_LINETO | PT_MOVETO) to test the exact logic of PolyDraw with an > open path. > > changelog: > * added polydraw test to path testing (5 more todo_wines) > > dlls/gdi32/tests/path.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 70 insertions(+), 0 deletions(-) > > -- > Evan Stade > > Well I am obviously not Alexandre but I'll hazard a guess. I don't think my advice/style comments which I sent yesterday kept the patch out, but the second patch definitely looks like it might have kept the patchset out. Specifically, a gem from gdi_private.h: /* It should not be necessary to access the contents of the GdiPath * structure directly; if you find that the exported functions don't * allow you to do what you want, then please place a new exported * function that does this job in path.c. */ Now I would almost be willing to bet money on the fact that Alexandre would want you to split your second patch up into a PATH_PolyDraw and your non-path case, then the PolyDraw in painting.c would go something like: if(PATH_IsPathOpen(dc->path)) ret = PATH_PolyDraw(dc, ...); else if(dc->funcs->pPolyDraw) ret = dc->funcs->pPolyDraw(dc->physDev, ...); else { /* Stuff to do in case of no open path */ } GDI_ReleaseObj(hdc); return ret; --- Misha p.s. Also your BYTE polydraw_tps should be static (minor point). p.p.s. Just to satisfy my anal retentiveness, and to make the test patch look nicer, if you end up resubmitting anyway you might as well put this in (note I changed some of your 1's to 2's because technically a 2 means an entry is completely skipped in wine, and a 1 means it is present in wine but does not quite match, although in this case either one will get you a successful todo_wine so it doesn't really matter): static const path_test_t polydraw_path[] = { {300, 300, PT_MOVETO, 0, 0}, /* 0 */ {150, 200, PT_LINETO, 0, 0}, /* 1 */ {200, 150, PT_LINETO | PT_CLOSEFIGURE, 0, 0}, /* 2 */ {300, 300, PT_MOVETO, 0, 1}, /* 3 */ {300, 300, PT_LINETO, 0, 0}, /* 4 */ {400, 300, PT_LINETO, 0, 0}, /* 5 */ {400, 350, PT_LINETO, 0, 0}, /* 6 */ {50, 100, PT_MOVETO, 0, 0}, /* 7 */ {100, 50, PT_LINETO, 0, 0}, /* 8 */ {400, 250, PT_LINETO, 0, 0}, /* 9 */ {500, 300, PT_LINETO, 0, 0}, /* 10 */ {500, 350, PT_LINETO, 0, 0}, /* 11 */ {350, 400, PT_MOVETO, 0, 2}, /* 12 */ {600, 200, PT_LINETO, 0, 2}, /* 13 */ {500, 150, PT_LINETO, 0, 0}, /* 14 */ {500, 350, PT_MOVETO, 0, 2}, /* 15 */ {500, 150, PT_LINETO, 0, 2}, /* 16 */ {100, 200, PT_LINETO, 0, 0}, /* 17 */ {400, 150, PT_LINETO, 0, 0}, /* 18 */ {400, 350, PT_LINETO, 0, 0}}; /* 19 */

1 0

Re: msi [1/10]: Implement MsiSourceListGetInfoA
by James Hawkins 29 Jun '07

29 Jun '07

On 6/28/07, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > Correctly handled pcchValue. > > Changelog: > * Implement MsiSourceListGetInfoA. > Please disregard this series. -- James Hawkins

1 0

shelllink patches
by Misha Koshelev 29 Jun '07

29 Jun '07

Btw, in case it was not clear from the patches themselves, without these patches out shelllinks for non-executables currently point to the application that is assigned to open them (e.g., notepad), rather than to the actual file as on native. Misha

1 0

Re: msi 1: Implement MsiSourceListGetInfoA [try2]
by Alexandre Julliard 28 Jun '07

28 Jun '07

"James Hawkins" <truiken(a)gmail.com> writes: > + ret = MsiSourceListGetInfoW(product, usersid, dwContext, dwOptions, > + property, value, pcchValue); > + if (ret == ERROR_SUCCESS) > + WideCharToMultiByte(CP_ACP, 0, value, -1, szValue, *pcchValue, NULL, NULL); The handling of pcchValue is wrong, you need a separate variable for the W size, and you need to set *pcchValue to the correct A size. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]
by Evan Stade 28 Jun '07

28 Jun '07

On 6/27/07, Evan Stade <estade(a)gmail.com> wrote: > Hi, > > [try2] The patch I sent yesterday was not properly todo_wined. Also, > this test is a bit more extensive (about twice as many points drawn). > It uses various point-type combination (even non-sensical ones such as > PT_LINETO | PT_MOVETO) to test the exact logic of PolyDraw with an > open path. > > changelog: > * added polydraw test to path testing (5 more todo_wines) > > dlls/gdi32/tests/path.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 70 insertions(+), 0 deletions(-) > > -- > Evan Stade > > sorry for the post on wine-patches. How can I improve this test? -- Evan Stade

1 0

Re: wincrypt: add missing defines
by Mounir IDRASSI 28 Jun '07

28 Jun '07

You forgot the attachement... Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Juan Lang wrote: > --Juan > > > > ____________________________________________________________________________________ > Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. > http://autos.yahoo.com/carfinder/ > > > > >

2 1

Wine networking broke on Debian Sid
by Ben Hodgetts (Enverex) 28 Jun '07

28 Jun '07

Just to make this clear before starting this is a Sid issue (as far as I can tell) not a Wine issue. Anyway, to the point. Networking is broken on Debian Sid and has been for at least a week. I can't find out what has changed in Sid for it to stop working but basically anyone running Wine on Sid wont be able to use any form of network access. Firefox wont work, games wont be able to access servers or anything else, Gecko wont work, etc. This is using GIT, not the distros own packages. I tried using the x86_64 package for Ubuntu 7.04 (because no x86_64 package exists for Debian) and Wine acted exactly the same way with a clean .wine so it's not related to any build time issues. I reset to 0.9.34 in GIT and built that to make sure it wasn't anything that has changed in Wine itself and the issue continued, so it's not something that's changed in Wine. Although using an earlier version of Wine gives a "Winehq.com could not be found, please check the address and try again". Current Wine (or rather Gecko) doesn't bother giving you an error message. Could this be the work of the removal of an unspoken Wine dependency or something more sinister? All native apps still work perfectly which is what makes this such a hard thing to track down. I just thought I'd throw this out there in-case any of you are using Sid and wondering what the the hell happened to Wine. Log attached for completeness. Ben H.

1 0

Re: cabinent: add a comment about parm passing
by James Hawkins 28 Jun '07

28 Jun '07

On 6/27/07, Jeff Latimer <lats(a)yless4u.com.au> wrote: > Coverity CID 43 Forward_Null is false. This adds a comment explaining > the NULL pass is ok. > Why do we need a comment for that? -- James Hawkins

3 2

Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]
by Misha Koshelev 28 Jun '07

28 Jun '07

> +static const path_test_t polydraw_path[] = { > + {300, 300, 6, 0, 0}, /*0*/ > + {150, 200, 2, 0, 0}, /*1*/ > + {200, 150, 3, 0, 0}, /*2*/ > + {300, 300, 6, 0, 1}, /*3*/ > + {300, 300, 2, 0, 0}, /*4*/ > + {400, 300, 2, 0, 0}, /*5*/ > + {400, 350, 2, 0, 0}, /*6*/ > + {50, 100, 6, 0, 0}, /*7*/ > + {100, 50, 2, 0, 0}, /*8*/ > + {400, 250, 2, 0, 0}, /*9*/ > + {500, 300, 2, 0, 0}, /*10*/ > + {500, 350, 2, 0, 0}, /*11*/ > + {350, 400, 6, 0, 1}, /*12*/ > + {600, 200, 2, 0, 1}, /*13*/ > + {500, 150, 2, 0, 1}, /*14*/ > + {500, 350, 6, 0, 0}, /*15*/ > + {500, 150, 2, 0, 0}, /*16*/ > + {100, 200, 2, 0, 0}, /*17*/ > + {400, 150, 2, 0, 0}, /*18*/ > + {400, 350, 2, 0, 0} /*19*/ > + }; This is not major, but just thought I'd point out that if you do a set WINETEST_DEBUG=3 on Windows and then call ok_path in your test (you can just do a 0 size when you first make the test for this), you'll get the following output, which seems like it would be both faster to produce and nicer-looking (get the actual PT_'s rather than a number): static const path_test_t polydraw_path[] = { {300, 300, PT_MOVETO, 0, 0}, /* 0 */ {150, 200, PT_LINETO, 0, 0}, /* 1 */ {200, 150, PT_LINETO | PT_CLOSEFIGURE, 0, 0}, /* 2 */ {300, 300, PT_MOVETO, 0, 0}, /* 3 */ {300, 300, PT_LINETO, 0, 0}, /* 4 */ {400, 300, PT_LINETO, 0, 0}, /* 5 */ {400, 350, PT_LINETO, 0, 0}, /* 6 */ {50, 100, PT_MOVETO, 0, 0}, /* 7 */ {100, 50, PT_LINETO, 0, 0}, /* 8 */ {400, 250, PT_LINETO, 0, 0}, /* 9 */ {500, 300, PT_LINETO, 0, 0}, /* 10 */ {500, 350, PT_LINETO, 0, 0}, /* 11 */ {350, 400, PT_MOVETO, 0, 0}, /* 12 */ {600, 200, PT_LINETO, 0, 0}, /* 13 */ {500, 150, PT_LINETO, 0, 0}, /* 14 */ {500, 350, PT_MOVETO, 0, 0}, /* 15 */ {500, 150, PT_LINETO, 0, 0}, /* 16 */ {100, 200, PT_LINETO, 0, 0}, /* 17 */ {400, 150, PT_LINETO, 0, 0}, /* 18 */ {400, 350, PT_LINETO, 0, 0}}; /* 19 */ Hope this helps. Misha

1 0

mozilla control download problems?
by Dan Kegel 27 Jun '07

27 Jun '07

Say, I just saw a repeatable mozilla download failure. Here's a summary of the tcpdump log. Is this a known problem? - Dan

2 1

Re: Problem with patch "dsound: Simplify mixing by removing remixing support, and fix its waveout breakage"
by Maarten Lankhorst 27 Jun '07

27 Jun '07

Chris Rankin schreef: > Hi, > > This patch has killed the sound on World of Warcraft. Instead, I now get silence and a stream of > errors like this: > Don't #if 0 out the code there Change it to something like this: if (pmix > This->buflen) WARN("Mixing further ahead then buffer is long\n");

2 1

Re: Worms world party install - 0x80040706 object reference not set
by James Hawkins 27 Jun '07

27 Jun '07

On 6/27/07, Peter <swjawa(a)gmail.com> wrote: > 2007/6/27, James Hawkins <truiken(a)gmail.com>: > > On 6/27/07, Peter <swjawa(a)gmail.com> wrote: > > > When I try to install worms world party I get a message when 6%: > > > Unhandled Exception [_] [X] > > > Error Number: 0x80040706 > > > Description: Object reference not set > > > > > > Setup will now terminate > > > [OK] > > > > > > http://consumer.installshield.com/kb.asp?id=q110641 > > > This site says to update InstallShield engine, but that's the solution > > > for windows. > > > > > > > Why would it not be the solution for Wine? > > > > -- > > James Hawkins > > > Yes it works now. > Thanks. > Please reply-all so everyone can know the results. -- James Hawkins

1 0

RE: [advapi32/service #2] Don't rely blindly on type
by Rolf Kalbermatter 27 Jun '07

27 Jun '07

Hi Paul, >On Wine, type is unchanged in a failure case for RegQueryValueExW. This means the >previous code relied on the returned type of the previous last succeeded call, huh? You are right that there is a problem with the existing code at some places. But changing - if( ( r == ERROR_SUCCESS ) || ( type == REG_DWORD ) ) + if( ( r == ERROR_SUCCESS ) && ( type == REG_DWORD ) ) should be enough. Since the funtion returned with success the type must be valid now. Rolf Kalbermatter

1 0

Worms world party install - 0x80040706 object reference not set
by Peter 27 Jun '07

27 Jun '07

When I try to install worms world party I get a message when 6%: Unhandled Exception [_] [X] Error Number: 0x80040706 Description: Object reference not set Setup will now terminate [OK] http://consumer.installshield.com/kb.asp?id=q110641 This site says to update InstallShield engine, but that's the solution for windows.

4 3

Move of the Bugzilla CVS to Git
by Jan Zerebecki 27 Jun '07

27 Jun '07

I hereby announce that with the upgrade of Bugzilla we will use Git for what the "bugzilla" cvs module is currently used (if nothing unforeseen prevents this). This can be seen as a test for also moving our other remaining CVS modules. Anyone who has a problem with this should speak up now. Btw. the idea is to upgrade the server to "Sarge" shortly before the Bugzilla upgrade. Jan

5 5

Re: user32,wined3d: move refresh rate fallback to catch all cases
by Erik Inge Bolsø 27 Jun '07

27 Jun '07

On 25/06/07, H. Verbeet wrote: >On 24/06/07, Erik Inge Bolsø <knan-wine at anduin.net> wrote: >> --- >> dlls/user32/sysparams.c | 13 ++++++++++++- >> dlls/wined3d/device.c | 10 +--------- >> 2 files changed, 13 insertions(+), 10 deletions(-) >> >What was the reason for writing this? See the comments on http://appdb.winehq.org/appview.php?iVersionId=5618 ... essentially, I have a game that's hardcoded to request 1024x768x50hz, which is not available on my monitor, and the existing fallback to any available refresh rate in wined3d didn't catch it. Haven't traced the exact sequence of calls - but figured that since there was an existing refresh rate fallback coded, I'd move that a step instead of duplicating. I can try to trace it down and duplicate the fallback, if that would be a preferable solution. -- Erik

3 2

Re: user32:painting.c Add comment to function.[try2]
by Robert Shearman 27 Jun '07

27 Jun '07

Anatoly Lyutin wrote: > /*********************************************************************** > * LockWindowUpdate (USER32.@) > + * > + * Enables or disables choosen window. > This isn't quite correct. LockWindowUpdate prevents or allows painting to the window. It doesn't prevent user input, which is what "disable" suggests (c.f. EnableWindow). -- Rob Shearman

1 0

Re: [advapi32/tests] Add some service related tests
by Paul Vriens 27 Jun '07

27 Jun '07

On 6/26/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > While playing with native crypt32/wintrust I added a service (CryptSvc) to the > registry (seems needed for native and XP+). With a full trace I get some crashes > which made me start to write some tests for services. (Rolf Kalbermatter was > already busy with services stuff, but said he doesn't have the time currently). > > Changelog > Add some service related tests > > Cheers, > > Paul. > Ignore this one. I'll come up with something else as I've started fixing things first. Cheers, Paul.

1 1

Re: [PATCH try2 2/2] winemenubuilder: Wait for application icons to be created instead of adding a RunOnce entry that may never run.
by Hans Leidekker 27 Jun '07

27 Jun '07

On Wednesday 27 June 2007, Misha Koshelev wrote: + /* Now watch the directory for our path to be created */ + if ((*handles = FindFirstChangeNotificationW(dir, subtree, FILE_NOTIFY_CHANGE_FILE_NAME)) == + INVALID_HANDLE_VALUE) I'm not sure if file change notifications are the right solution here but since they are only supported on Linux you should at least keep the run once key as a fallback strategy. -Hans

4 3

Re: [3/3] gdi32: improved PolyDraw
by Alexandre Julliard 27 Jun '07

27 Jun '07

"Evan Stade" <estade(a)gmail.com> writes: > + for( i = dc->path.numEntriesUsed-1; i >= 0; i-- ){ > + if(dc->path.pFlags[i] == PT_MOVETO){ > + lastmove = dc->path.pPoints[i]; > + break; > + } > + } > + if(i < 0){ > + lastmove.x = 0; > + lastmove.y = 0; > + } This can't work, i is unsigned. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msi [2/6]: Add the IWineMsiRemotePackage interface
by Alexandre Julliard 27 Jun '07

27 Jun '07

"James Hawkins" <truiken(a)gmail.com> writes: > +interface IWineMsiRemotePackage : IUnknown > +{ > + HRESULT SetMsiHandle( [in] ULONG_PTR handle ); > + HRESULT GetActiveDatabase( [out] ULONG_PTR handle ); > + HRESULT GetProperty( [in] BSTR *property, [out] BSTR *value, [out] ULONG_PTR size ); Why are you using ULONG_PTR instead of the proper pointer types for out parameters? -- Alexandre Julliard julliard(a)winehq.org

1 0

GDI/GDI+ creating paths
by Evan Stade 27 Jun '07

27 Jun '07

Hi, I was talking with Julliard about the implementation of paths in GDI+. He suggested that the right way to do it was to build paths directly (i.e. not calling into GDI). I'm not sure why calling into GDI is undesirable. There are several reasons I'd like to use GDI paths: * GDI and GDI+ paths seem to behave exactly the same way * this implementation of GDI+ calls into GDI for drawing, so it seems natural to rely on GDI to create paths as well. * unless we take rendering completely out of the hands of GDI, we need GDI to draw paths for us because of line joins. It seems strange to me to draw shapes and draw paths with GDI, but not to create paths with GDI. * path.c in gdi32 is 2000 lines, and re-implementing it seems overkill I don't see any drawbacks of calling into GDI to make paths, other than a slight performance decrease introduced by an extra level of indirection. Can anyone suggest another reason why this approach is flawed? -- Evan Stade

2 2

Re: [SPAM] Problem with patch "dsound: Simplify mixing by removing remixing support, and fix its waveout breakage"
by Alex Villacís Lasso 27 Jun '07

27 Jun '07

Chris Rankin escribió: > Hi, > > This patch has killed the sound on World of Warcraft. Instead, I now get silence and a stream of > errors like this: > > err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition! > err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition! > err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition! > err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition! > err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition! > err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition! > err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition! > err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition! > err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition! > err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition! > err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition! > err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition! > err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition! > > The following change makes the sound work again without error messages, but there is still a brief > burst of sound/noise before the music starts properly: > > $ cvswine diff dlls/dsound/buffer.c > Index: dlls/dsound/buffer.c > =================================================================== > RCS file: /home/wine/wine/dlls/dsound/buffer.c,v > retrieving revision 1.70 > diff -u -r1.70 buffer.c > --- dlls/dsound/buffer.c 22 Jun 2007 12:37:22 -0000 1.70 > +++ dlls/dsound/buffer.c 25 Jun 2007 19:08:34 -0000 > @@ -442,15 +442,15 @@ > pmix *= This->pwfx->nBlockAlign; > > TRACE("this back-offset=%d\n", pmix); > - > +#if 0 > /* sanity */ > if(pmix > This->buflen){ > ERR("Bad length in CalcPlayPosition!\n"); > return 0; > } > - > +#endif > /* subtract from our last mixed position */ > - if (bplay < pmix) bplay += This->buflen; /* wraparound */ > + while (bplay < pmix) bplay += This->buflen; /* wraparound */ > bplay -= pmix; > > /* check for lead-in */ > > > Cheers, > Chris > > > > > > > ___________________________________________________________ > New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. > http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk > > You might try the patch with the title "DSOUND: recover from mismatch between time spanned by primary buffer being longer than the one spanned by secondary buffer", which I sent along with some other patches today. It looks somewhat similar to the one you sent. Alex Villacís Lasso -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

2 1

Writing tests in Wine.
by Anatoly Lyutin 26 Jun '07

26 Jun '07

Hi all! When I analyzed Wine test codes today I do not understand how to interpret result of tests.That is why I refer to community. I can not find any full documentation for writing tests at WineHq. I have some points which I do not understand: 1. Why some tests are running in Win not fall if expected and obtained messages are not coincide. ex (user32:msg:test_mdi_messages:Win2k3): msg.c:2716:mdi frame: 00090362, 0086, 00000000, 00000000 msg.c:2716:mdi frame: 00090362, 0002, 00000000, 00000000 msg.c:2716:mdi frame: 00090362, 0082, 00000000, 00000000 msg.c:3302:expected 0004 - actual 0004 msg.c:3302:expected 0046 - actual 0046 msg.c:3302:expected 8003 - actual 0047 msg.c:3302:expected 0086 - actual 0047 msg.c:3302:expected 0047 - actual 0047 msg.c:3302:expected 0086 - actual 0086 msg.c:3302:expected 0006 - actual 0002 msg.c:3302:expected 001c - actual 0002 msg.c:3302:expected 8003 - actual 0002 msg.c:3302:expected 8001 - actual 0002 msg.c:3302:expected 0002 - actual 0002 msg.c:3302:expected 0082 - actual 0082 Why does not this fail?(ok_sequence(WmDestroyMDIframeSeq, "Destroy MDI frame window", FALSE);) 2. How I can write test for different OS Windows? Some tests run successfully in win2k3 but fail in XP, that is why this test can not be validated by HQ. 3.What does it mean :{ HCBT_SETFOCUS, hook }? What does this hook in some tests make fail in Win2k3 if it was included? Thank you for attention. -- Best regards Anatoly Lyutin.

2 1

Re: winefile: Use the msvcrt provided _tsplitpath instead of reimplementing it.
by Alexandre Julliard 26 Jun '07

26 Jun '07

Michael Stefaniuc <mstefani(a)redhat.de> writes: > Actually i wanted to just remove the wide character constants out of > splitpath.c but then i have seen that the file can be removed completely. > I checked the history but didn't find a clue why a separate > implementation might have been usefull. splitpath.c appeared with the > initial import of the winefile source code. Winefile cannot import msvcrt because it has support for accessing Unix files too. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: please help me with filling a bug concerning WM_ERASEBKGND
by Juan Lang 26 Jun '07

26 Jun '07

Hi, if you've done a reasonable job searching for a dup and haven't found one, go ahead and file a new bug. Bugs can be closed or linked where appropriate. > is this http://bugs.winehq.org/show_bug.cgi?id=6006 ? > Il try to compile latest git with patches from that bug before filling > new one. I think these may very well be related, but (IMO) they should be different bugs. A bug should describe the problem, not the fix. If a patch for one fixes the other, great! --Juan ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&…

1 0

Slackware 11: After Wine update applications crash if WINEDEBUG not set
by Victor 26 Jun '07

26 Jun '07

Hello! I didn't get an answer for this in wine-user, so I've decided to ask this question here. After upgrading wine (from 0.9.37 to 0.9.38 or from 0.9.38 to 0.9.39 - I'm not sure) many graphical applications started crashing if WINEDEBUG+=all or WINEDEBUG+=relay not set. Among those applications are Postal 1, Kiosaky's Cashflow 101, .kkreiger and probably more. I'm not sure if this is a bug in Wine or a problem in my system, because uninstalling and downgrading (even to 0.9.34) didn't help - problem now exists in other versions as well. Applications crash in a "windows way" - with access violation at address 0x7XXXXXXX. Here is a beginning of output produced by trying to start .kkreiger (avaliable at http://www.theprodukkt.com/): --begin-- Unhandled page fault on read access to 0xffffffff at address 0x7d66c9ce (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0xffffffff in 32-bit code ?0x7d66c9ce). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7d66c9ce ESP:0033e8a8 EBP:00009f80 EFLAGS:00210246( - 00 -RIZP1) EAX:0033e8c8 EBX:7d68a000 ECX:00000000 EDX:00000000 ESI:01000000 EDI:00001f80 Stack dump: 0x0033e8a8: 0033e8c8 00000000 00000000 b7fd6ff8 0x0033e8b8: 7d72aaa9 7d72aaa9 0033ec18 00001f80 0x0033e8c8: 00000000 00000000 00000000 00000000 0x0033e8d8: 00000000 00000000 00000000 00000000 0x0033e8e8: 00000000 00000000 00000000 00000000 0x0033e8f8: 00000000 00000000 00000000 00000000 Backtrace: =>1 0x7d66c9ce (0x00009f80) 2 0x00000000 (0x00000000) 0x7d66c9ce: --end-- But it works fine if started as WINEDEBUG=+relay wine wine pno001.exe &>/dev/null This application worked fine before and didn't need those flags. Kyosaky's Cashflow 101 crashes with a windows message box which says "Unhandled exceptionL c0000005 At address: 7ce2f9ce". but works fine if started with WINEDEBUG=+relay same thing with Postal 1. There are also problems with an Alien vs Predator 2 game and some other apps that enumerate D3D display modes: if program has a listbox where videomodes can be selected, this box will contain no strings (alien vs. predator, ragnarok online, some other apps), if WINEDEBUG+=all is not set. Can these problems be connected with those crashes? System configuration: Slackware 11 linux with 2.6.17.13 kernel on AMD Sempron 2800+ processor with GeForce 7100GS and 512Mb ram. Any pointers how can I figure out what's wrong? Thanks. With best regards, Victor Eremin.

2 3

re: How to make your machine crash when running Wine
by Dan Kegel 26 Jun '07

26 Jun '07

There's a similar discussion going on here: http://www.linuxforums.org/forum/wine/96022-wine-hard-system-freeze-new-pos… --- snip --- i had the same problem. I use wine with Ubuntu Daper on Core T7200 Duo Laptop. I moved from the kernel 2.6.15-28-386 to 2.6.15-28-686 and wine starts to freeze. * moving from nvidia to vesa-driver -> no luck * set Hyperthreading-kernelswitch ht=on to ht=off -> no luck After moving back to 2.6.15-28-386 it worked again. The workaround ist to use the 386-kernel. (Linux version 2.6.15-28-386 (buildd@terranova) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #1 PREEMPT Thu May 10 09:45:43 UTC 2007) PS: I used wine_0.9.39~winehq0~ubuntu~6.06-1_i386.deb and wine_0.9.9-0ubuntu2_i386.deb --- snip ---

1 0

Using Rx Controls (Delphi) [resend]
by Anatoly Lyutin 26 Jun '07

26 Jun '07

-- Best regards Anatoly Lyutin.

1 0

Re: msi [1/6]: Add support for remote handles
by Alexandre Julliard 26 Jun '07

26 Jun '07

"James Hawkins" <truiken(a)gmail.com> writes: > @@ -215,18 +282,28 @@ UINT WINAPI MsiCloseHandle(MSIHANDLE han > > EnterCriticalSection( &MSI_handle_cs ); > > - info = msihandle2msiinfo(handle, 0); > - if( !info ) > - goto out; > - > - if( info->magic != MSIHANDLE_MAGIC ) > + unk = msi_get_remote( handle ); > + if (unk) > + IUnknown_Release( unk ); > + else > { It seems to me you are leaking the object here, the handle entry holds a ref to it too. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: About stdlib.h system()
by Kirill K. Smirnov 26 Jun '07

26 Jun '07

I've tried MSVC 6.0 and MSVC 2003. All the same - it works. Please, check your sources. I have no idea where the bug can be. > Yes, the mingw-gcc case works. > But I use the Visual C++ 7.0 to compile. It still fails. > > On 6/26/07, Kirill K. Smirnov <lich(a)math.spbu.ru> wrote: > > Hi, > > > > I've tried to reproduce, but failed: > > > > a.c: > > #include <stdio.h> > > #include <stdlib.h> > > > > int main(void) > > { > > system("qqq.exe"); > > return 0; > > } > > > > > > $ mingw-gcc -mconsole -mno-cygwin a.c > > $ wine a.exe > > > > It works. > > > > $ mingw-gcc a.c > > $ wine a.exe > > > > It works too. > > > > Executable qqq.exe exists in ~/.wine/drive_c/windows directory. > > > > -- > > Kirill

1 0

About stdlib.h system()
by Kirill K. Smirnov 26 Jun '07

26 Jun '07

Hi, I've tried to reproduce, but failed: a.c: #include <stdio.h> #include <stdlib.h> int main(void) { system("qqq.exe"); return 0; } $ mingw-gcc -mconsole -mno-cygwin a.c $ wine a.exe It works. $ mingw-gcc a.c $ wine a.exe It works too. Executable qqq.exe exists in ~/.wine/drive_c/windows directory. -- Kirill

2 1

please help me with filling a bug concerning WM_ERASEBKGND
by RusH 26 Jun '07

26 Jun '07

searching bugzilla for WM_ERASEBKGND returns lots of bugs, but I have no idea if mine is there http://bugs.winehq.org/buglist.cgi?query_format=&short_desc_type=allwordssu… The bug is weird. Running uTorrent (latest beta ) http://download.utorrent.com/beta/utorrent-1.7-beta-2899.uncompressed.exe with wine set to emulate XP is fine, but when you set it to Windows 98 or lower wine stops sending WM_ERASEBKGND (or/and breaks WM_PAINT). background surfaces are not repainted and remain black. is this http://bugs.winehq.org/show_bug.cgi?id=6006 ? Il try to compile latest git with patches from that bug before filling new one. -- Who logs in to gdm? Not I, said the duck.

1 0

user32 patch unaccepted
by Clinton Stimpson 26 Jun '07

26 Jun '07

Was there anything wrong with this patch, that it didn't get accepted? <http://www.winehq.org/pipermail/wine-patches/2007-March/037272.html> It limits update regions to the nearest clipping parent window. Thanks Clinton Stimpson

1 0

Re: gdi32: Multi-character character constants aren't portable as their behaviour is compiler dependent according to the C standard. Found by sparse.
by James Hawkins 25 Jun '07

25 Jun '07

On 6/25/07, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > I have no way to test this patch as i don't have a Mac. > > bye > michael > --- > dlls/gdi32/freetype.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c > index 424fb3d..bcf16ae 100644 > --- a/dlls/gdi32/freetype.c > +++ b/dlls/gdi32/freetype.c > @@ -590,6 +590,7 @@ static char **expand_mac_font(const char *path) > unsigned short *num_faces_ptr, num_faces, face; > AsscEntry *assoc; > Handle fond; > + ResType fond_res = 0x464f4e44 /* 'FOND' */; > > fond = Get1IndResource('FOND', idx); > if(!fond) break; Did you mean to replace 'FOND' in the Get1IndResource call with fond_res? > @@ -605,6 +606,7 @@ static char **expand_mac_font(const char *path) > for(face = 0; face < num_faces; face++, assoc++) > { > Handle sfnt; > + ResType sfnt_res = 0x73666e74 /* 'sfnt' */ > unsigned short size, font_id; > char *output; > > @@ -617,7 +619,7 @@ static char **expand_mac_font(const char *path) > } > > TRACE("trying to load sfnt id %04x\n", font_id); > - sfnt = GetResource('sfnt', font_id); > + sfnt = GetResource(sfnt_res, font_id); > if(!sfnt) > { > TRACE("can't get sfnt resource %04x\n", font_id); > -- > 1.5.0.6 > -- James Hawkins

1 0

re: WIDL: Implement support for explicit user handles
by Dan Kegel 25 Jun '07

25 Jun '07

Eric wrote: > This patch implements support for explicit user handles. Say, could you add a test for that? I think Dan H. usually adds tests to rpcrt4 whenever he adds a feature to widl. cf. http://source.winehq.org/git/?p=wine.git&a=search&st=author&s=dsh - Dan

1 0

Re: [5/5] WineD3D: Implement mipmap auto generation
by Stefan Dösinger 25 Jun '07

25 Jun '07

Am Montag, 25. Juni 2007 14:42 schrieb Stefan Dösinger: > I have no application that needs this, so this is an untested per-msdn > implementation. Do not apply this patch yet. It's missing some check in LoadTexture to not upload sublevels manually if autogen is on

1 0

Re: [3/5] WineD3D: rsq and rcp use the .w component if no swizzle is given
by H. Verbeet 25 Jun '07

25 Jun '07

On 25/06/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > + 0x0009fffe, 0x58443344, 0x68532038, /* No idea about that stuff, */ > + 0x72656461, 0x73734120, 0x6c626d65, /* vsa.exe generated it */ > + 0x56207265, 0x69737265, 0x30206e6f, /* And without it windows complains*/ > + 0x0031392e, That looks pretty bad, imo.

2 1

Re: mshtml #14: Added more QueryInterface tests.
by Detlef Riekenberg 25 Jun '07

25 Jun '07

On So, 2007-06-24 at 21:10 +0200, Jacek Caban wrote: > + ok(qi == NULL, "runnable=%p, ezpected NULL\n", qi) The Patch is in the Tree, but I suggest to change: "ezpected" to "expected" in several Places. Thanks, with greetings from Copy and Paste -- By by ... Detlef

2 1

Making the wiki FAQ live
by Scott Ritchie 25 Jun '07

25 Jun '07

So, about a month ago we discussed the idea of replacing the documentation FAQ with one based in the wiki. Nothing was done, but the general consensus seemed to be to wait and see if the wiki approach worked out better. Since that time, the Wiki FAQ has been updated by 7 people other than myself. We've removed most of the cruft, and taken the FAQ from an unhelpful mess to something a user actually should read. Meanwhile, the original FAQ has been unchanged. It's not done, but I think it's time to take it live and make the wiki FAQ our official FAQ, and then remove the old one from the documentation build. Based on the past month alone, I think it's fairly safe to say that it's easier to maintain, update, and keep relevant this way. I've already sent a patch for lostwages to wine-devel. Thanks, Scott Ritchie

3 3

re: VST wrapper
by Dan Kegel 25 Jun '07

25 Jun '07

Hi N8, > [How can I write a shared library that uses Wine and > can be called from a non-winelib app?] This is a somewhat frequently asked question. As Stephan explained, wine's code requires that the process have been set up somewhat specially. This is taken care of by the sources in the loader subdirectory. In a perfect world, some of that code would move into the operating system's process loader... then one could mix and match win32 and unix calls more easily. Anyway, knowing about the code in that directory is key to understanding why what you ask is hard, and in finding a workaround. - Dan

2 1

Re: [3/5] WineD3D: rsq and rcp use the .w component if no swizzle is given
by Frank Richter 25 Jun '07

25 Jun '07

On 25.06.2007 16:03, H. Verbeet wrote: > On 25/06/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> + 0x0009fffe, 0x58443344, 0x68532038, /* No >> idea about that stuff, */ >> + 0x72656461, 0x73734120, 0x6c626d65, /* >> vsa.exe generated it */ >> + 0x56207265, 0x69737265, 0x30206e6f, /* And >> without it windows complains*/ >> + 0x0031392e, > That looks pretty bad, imo. FWIW, that comment reads "D3DX8 Shader Assembler Version 0.91". -f.r.

1 0

configure:2479: error: C compiler cannot create executables
by jens＠jens 25 Jun '07

25 Jun '07

This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Wine configure 0.9.39, which was generated by GNU Autoconf 2.61. Invocation command line was $ ./configure --prefix=/opt/wine --with-x ## --------- ## ## Platform. ## ## --------- ## hostname = jens uname -m = x86_64 uname -r = 2.6.20-15-generic uname -s = Linux uname -v = #2 SMP Sun Apr 15 06:17:24 UTC 2007 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/sbin PATH: /usr/bin PATH: /sbin PATH: /bin PATH: /usr/games ## ----------- ## ## Core tests. ## ## ----------- ## configure:1888: checking build system type configure:1906: result: x86_64-unknown-linux-gnu configure:1928: checking host system type configure:1943: result: x86_64-unknown-linux-gnu configure:2008: checking whether make sets $(MAKE) configure:2029: result: yes configure:2086: checking for gcc configure:2113: result: gcc -m32 configure:2351: checking for C compiler version configure:2358: gcc -m32 --version >&5 gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2361: $? = 0 configure:2368: gcc -m32 -v >&5 Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) configure:2371: $? = 0 configure:2378: gcc -m32 -V >&5 gcc: '-V' must come at the start of the command line configure:2381: $? = 1 configure:2404: checking for C compiler default output file name configure:2431: gcc -m32 /usr/lib32 conftest.c >&5 /usr/bin/ld: /usr/lib32: No such file: File format not recognized collect2: ld returned 1 exit status configure:2434: $? = 1 configure:2472: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "0.9.39" | #define PACKAGE_STRING "Wine 0.9.39" | #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2479: error: C compiler cannot create executables See `config.log' for more details. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=x86_64-unknown-linux-gnu ac_cv_env_CCC_set= ac_cv_env_CCC_value= ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set= ac_cv_env_CXX_value= ac_cv_env_LDFLAGS_set=set ac_cv_env_LDFLAGS_value=/usr/lib32 ac_cv_env_LIBS_set= ac_cv_env_LIBS_value= ac_cv_env_XMKMF_set= ac_cv_env_XMKMF_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_host=x86_64-unknown-linux-gnu ac_cv_prog_ac_ct_CC='gcc -m32' ac_cv_prog_make_make_set=yes ## ----------------- ## ## Output variables. ## ## ----------------- ## ALSALIBS='' AR='' AS='as --32' AUDIOIOLIBS='' BISON='' BUILTINFLAG='' CARBONLIB='' CC='gcc -m32' CFLAGS='' COREAUDIO='' COREFOUNDATIONLIB='' CPP='' CPPBIN='' CPPFLAGS='' CROSSCC='' CROSSTEST='' CROSSWINDRES='' CRTLIBS='' CXX='' CXXFLAGS='' DEFS='' DEPENDENCIES='' DISKARBITRATIONLIB='' DLLEXT='' DLLFLAGS='' DLLTOOL='' DLLWRAP='' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='' ESDCONFIG='' ESDINCL='' ESDLIBS='' EXEEXT='' EXTRACFLAGS='' EXTRA_BINARIES='' FLEX='' FONTFORGE='' FONTSSUBDIRS='' FREETYPEINCL='' FREETYPELIBS='' GLU32FILES='' GPHOTO2INCL='' GPHOTO2LIBS='' GREP='' HALINCL='' ICULIBS='' IMPLIBEXT='' INSTALL_DATA='' INSTALL_PROGRAM='' INSTALL_SCRIPT='' IOKITLIB='' LCMSLIBS='' LD='ld -m elf_i386' LDAPLIBS='' LDCONFIG='' LDD='' LDDLLFLAGS='' LDEXECFLAGS='' LDFLAGS='/usr/lib32' LDPATH='' LDSHARED='' LIBDL='' LIBEXT='' LIBOBJS='' LIBPOLL='' LIBPTHREAD='' LIBS='' LIBWINE_LDFLAGS='' LINT='' LINTFLAGS='' LN='' LN_S='' LTLIBOBJS='' MAIN_BINARY='' MINGWAR='' NASLIBS='' OBJEXT='' OPENGLFILES='' OPENGL_LIBS='' PACKAGE_BUGREPORT='wine-devel(a)winehq.org' PACKAGE_NAME='Wine' PACKAGE_STRING='Wine 0.9.39' PACKAGE_TARNAME='wine' PACKAGE_VERSION='0.9.39' PATH_SEPARATOR=':' PKG_CONFIG='' PRELINK='' QUARTZFILES='' RANLIB='' RESOLVLIBS='' SANEINCL='' SET_MAKE='' SHELL='/bin/bash' SOCKETLIBS='' STRIP='' TOOLSDIR='' WIN16_FILES='$(WIN16_FILES)' WIN16_INSTALL='$(WIN16_INSTALL)' WINDRES='' XFILES='' XLIB='' XMKMF='' XML2INCL='' XML2LIBS='' XSLTINCL='' XSLTLIBS='' X_CFLAGS='' X_EXTRA_LIBS='' X_LIBS='' X_PRE_LIBS='' ac_ct_AS='' ac_ct_CC='gcc -m32' ac_ct_CXX='' bindir='${exec_prefix}/bin' build='x86_64-unknown-linux-gnu' build_alias='' build_cpu='x86_64' build_os='linux-gnu' build_vendor='unknown' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' dvidir='${docdir}' exec_prefix='NONE' ft_devel2='' ft_devel='' gphoto2_devel='' gphoto2port_devel='' host='x86_64-unknown-linux-gnu' host_alias='' host_cpu='i386' host_os='linux-gnu' host_vendor='unknown' htmldir='${docdir}' includedir='${prefix}/include' infodir='${datarootdir}/info' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='${datarootdir}/man' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='/opt/wine' program_transform_name='s,x,x,' psdir='${docdir}' sane_devel='' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='' ## ------------------- ## ## File substitutions. ## ## ------------------- ## MAKE_DLL_RULES='' MAKE_IMPLIB_RULES='' MAKE_PROG_RULES='' MAKE_RULES='' MAKE_TEST_RULES='' ## ----------- ## ## confdefs.h. ## ## ----------- ## #define PACKAGE_NAME "Wine" #define PACKAGE_TARNAME "wine" #define PACKAGE_VERSION "0.9.39" #define PACKAGE_STRING "Wine 0.9.39" #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" configure: exit 77

3 2

Re: [Bug 8787] Manhunt: Video goes all black and haywire after intro movies.
by James Hawkins 25 Jun '07

25 Jun '07

On 6/24/07, joe b <goce_jeb(a)yahoo.com> wrote: > Game will not install under wine though. That's why I had to install under > the windows partition. > > You can't file a bug report for a game you run from a Windows partition. It's not supported by Wine, mostly because we can't reproduce any bugs this way. If you can't install the game in Wine, then please open a bug report for that. -- James Hawkins

1 0

Re: user32,wined3d: move refresh rate fallback to catch all cases
by H. Verbeet 25 Jun '07

25 Jun '07

On 24/06/07, Erik Inge Bolsø <knan-wine(a)anduin.net> wrote: > --- > dlls/user32/sysparams.c | 13 ++++++++++++- > dlls/wined3d/device.c | 10 +--------- > 2 files changed, 13 insertions(+), 10 deletions(-) > What was the reason for writing this?

1 0

Re: mshtml: Implement HTMLElement_get_children.
by Jacek Caban 25 Jun '07

25 Jun '07

Hi, > + elem_vector buf = {NULL, 0, 8}; > + > + TRACE("(%p)->(%p)\n", This, p); > + > + buf.buf = mshtml_alloc(buf.size*sizeof(HTMLElement**)); elem_vector is a self-resizable table, but in this case you know the size while creating it from nsIDOMNodeList::GetLength. I'd suggest to use it here during creation of buf to avoid useless memory reallocations. Thanks, Jacek

2 1

Re: WIDL: Implement support for explicit user handles
by Robert Shearman 25 Jun '07

25 Jun '07

Eric Kohl wrote: > This patch implements support for explicit user handles. Looks good, but one small nit-pick: Microsoft calls these "generic" handles instead of user handles. It would be good if you could rename the relevant bits to match this. Thanks, -- Rob Shearman

1 0

VST wrapper
by Nathaniel Gray 25 Jun '07

25 Jun '07

Hi, I'm interested in the goal of using Windows VST/VSTi audio plugins on my Intel Mac in OS X. I found the fst project, did some porting, and managed to get a few VSTs to work, which had me pretty stoked. Thanks to the FST folks and the Wine team for making this possible! On the other hand, I'd rather have the option of running the plugins in-process with my DAW software instead of as separate processes connected by JACK. I can imagine a super-thin layer of code that just translates calls between the plugin and the host and allows the plugin to access the Win32 API. In case I'm being unclear, here's how it breaks down. There's a host application that's native OS X and knows nothing about Wine. I'd like to write a plugin that, when it's loaded, will load a windows dll. The host will call into the plugin, which will call into the dll. The dll will make upcalls to the plugin, which will in turn call up to the host. The dll will probably be running a windows gui as well and making calls to various windows APIs. So is this possible? I'm pretty new to Wine and Windows programming so forgive me if the answer to this question is obvious. I've seen plenty of examples of how to build and run .exes that are windows programs from the ground up, but I've never seen wine used as part of a plugin. If it's possible, can you point me to any examples? What are the relevant parts of Wine I should look at? Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

2 1

Re: VST wrapper
by Nathaniel Gray 25 Jun '07

25 Jun '07

By the way, please CC me with replies. I'm not set up to receive mail from the list. Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

2 1

fix for wine < 0.9.24 segfault on startup
by Damjan Jovanovic 25 Jun '07

25 Jun '07

Hi On Ubuntu 7.04, versions of wine before around 0.9.24 die on startup with an undebuggable segmentation fault. After this bug stopped me from doing 2 regression tests, I decided to reverse regression test for the fix to the bug, and I found that the patch at http://www.winehq.org/pipermail/wine-cvs/2006-November/027508.html allows earlier versions of wine to run successfully. Thought this might be helpful to others Damjan

1 0

WIDL: Implement support for explicit user handles
by Eric Kohl 24 Jun '07

24 Jun '07

This patch implements support for explicit user handles. Regards Eric Kohl ChangeLog: Implement support for explicit user handles. diff --git a/tools/widl/client.c b/tools/widl/client.c index 86ead20..6a84e94 100644 --- a/tools/widl/client.c +++ b/tools/widl/client.c @@ -89,12 +89,14 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) { const var_t *def = func->def; const var_t* explicit_handle_var; + const var_t* explicit_user_handle_var; /* check for a defined binding handle */ explicit_handle_var = get_explicit_handle_var(func); + explicit_user_handle_var = get_explicit_user_handle_var(func); if (explicit_handle) { - if (!explicit_handle_var) + if (!explicit_handle_var && !explicit_user_handle_var) { error("%s() does not define an explicit binding handle!\n", def->name); return; @@ -102,7 +104,7 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) } else if (implicit_handle) { - if (explicit_handle_var) + if (explicit_handle_var || explicit_user_handle_var) { error("%s() must not define a binding handle!\n", def->name); return; @@ -167,6 +169,19 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) print_client("_Handle = %s;\n", explicit_handle_var->name); fprintf(client, "\n"); } + else if (explicit_user_handle_var) + { + print_client("_Handle = %s_bind(%s);\n", + explicit_user_handle_var->type->name, + explicit_user_handle_var->name); + print_client("if (_Handle == 0)\n"); + print_client("{\n"); + indent++; + print_client("RpcRaiseException(RPC_S_INVALID_BINDING);\n"); + indent--; + print_client("}\n"); + fprintf(client, "\n"); + } write_remoting_arguments(client, indent, func, PASS_IN, PHASE_BUFFERSIZE); @@ -240,6 +255,19 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) print_client("NdrFreeBuffer((PMIDL_STUB_MESSAGE)&_StubMsg);\n"); + if (explicit_user_handle_var) + { + fprintf(client, "\n"); + print_client("if (_Handle)\n"); + print_client("{\n"); + indent++; + print_client("%s_unbind(%s, _Handle);\n", + explicit_user_handle_var->type->name, + explicit_user_handle_var->name); + indent--; + print_client("}\n"); + } + indent--; print_client("}\n"); print_client("RpcEndFinally\n"); diff --git a/tools/widl/header.c b/tools/widl/header.c index 6f2da32..1119542 100644 --- a/tools/widl/header.c +++ b/tools/widl/header.c @@ -463,6 +463,21 @@ const var_t* get_explicit_handle_var(const func_t* func) return NULL; } +const var_t* get_explicit_user_handle_var(const func_t* func) +{ + const var_t* var; + + if (!func->args) + return NULL; + + LIST_FOR_EACH_ENTRY( var, func->args, const var_t, entry ) + if ((var->type->type != RPC_FC_BIND_PRIMITIVE) && + is_attr(var->type->attrs, ATTR_HANDLE)) + return var; + + return NULL; +} + int has_out_arg_or_return(const func_t *func) { const var_t *var; @@ -480,6 +495,40 @@ int has_out_arg_or_return(const func_t *func) return 0; } +static struct list user_handle_list = LIST_INIT(user_handle_list); + +struct user_handle +{ + struct list entry; + char name[1]; +}; + +void add_user_handle(type_t *type) +{ + struct user_handle *uh; + + if (is_attr(type->attrs, ATTR_HANDLE)) + { + uh = (struct user_handle *)xmalloc(sizeof(struct user_handle) + strlen(type->name)); + if (uh) + { + strcpy(uh->name, type->name); + list_add_tail(&user_handle_list, &uh->entry); + } + } +} + +void write_user_handles(void) +{ + const struct user_handle *uh; + + LIST_FOR_EACH_ENTRY(uh, &user_handle_list, struct user_handle, entry) + { + fprintf(header, "handle_t __RPC_USER %s_bind(%s);\n", uh->name, uh->name); + fprintf(header, "void __RPC_USER %s_unbind(%s, handle_t);\n", uh->name, uh->name); + } +} + /********** INTERFACES **********/ @@ -710,6 +759,7 @@ static void write_function_protos(const type_t *iface) const char *implicit_handle = get_attrp(iface->attrs, ATTR_IMPLICIT_HANDLE); int explicit_handle = is_attr(iface->attrs, ATTR_EXPLICIT_HANDLE); const var_t* explicit_handle_var; + const var_t* explicit_user_handle_var; const func_t *cur; int prefixes_differ = strcmp(prefix_client, prefix_server); @@ -720,13 +770,19 @@ static void write_function_protos(const type_t *iface) /* check for a defined binding handle */ explicit_handle_var = get_explicit_handle_var(cur); - if (explicit_handle) { - if (!explicit_handle_var) { + explicit_user_handle_var = get_explicit_user_handle_var(cur); + if (explicit_handle) + { + if (!explicit_handle_var && !explicit_user_handle_var) + { error("%s() does not define an explicit binding handle!\n", def->name); return; } - } else if (implicit_handle) { - if (explicit_handle_var) { + } + else if (implicit_handle) + { + if (explicit_handle_var || explicit_user_handle_var) + { error("%s() must not define a binding handle!\n", def->name); return; } diff --git a/tools/widl/header.h b/tools/widl/header.h index 54655a2..7a6508b 100644 --- a/tools/widl/header.h +++ b/tools/widl/header.h @@ -53,9 +53,12 @@ extern void write_externdef(const var_t *v); extern void write_library(const char *name, const attr_list_t *attr); extern void write_user_types(void); extern const var_t* get_explicit_handle_var(const func_t* func); +extern const var_t* get_explicit_user_handle_var(const func_t* func); extern int has_out_arg_or_return(const func_t *func); extern void write_guid(FILE *f, const char *guid_prefix, const char *name, const UUID *uuid); +extern void add_user_handle(type_t *type); +extern void write_user_handles(void); static inline int last_ptr(const type_t *type) { diff --git a/tools/widl/parser.y b/tools/widl/parser.y index 4933c43..a6df42d 100644 --- a/tools/widl/parser.y +++ b/tools/widl/parser.y @@ -1932,7 +1932,10 @@ static void process_typedefs(pident_list_t *pidents) type_t *type = find_type(var->name, 0); if (! parse_only && do_header) + { write_typedef(type); + add_user_handle(type); + } if (in_typelib && type->attrs) add_typelib_entry(type); diff --git a/tools/widl/server.c b/tools/widl/server.c index fd94c9a..2e261e5 100644 --- a/tools/widl/server.c +++ b/tools/widl/server.c @@ -61,6 +61,7 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) const func_t *func; const var_t *var; const var_t* explicit_handle_var; + const var_t* explicit_user_handle_var; if (!iface->funcs) return; LIST_FOR_EACH_ENTRY( func, iface->funcs, const func_t, entry ) @@ -69,9 +70,10 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) /* check for a defined binding handle */ explicit_handle_var = get_explicit_handle_var(func); + explicit_user_handle_var = get_explicit_user_handle_var(func); if (explicit_handle) { - if (!explicit_handle_var) + if (!explicit_handle_var && !explicit_user_handle_var) { error("%s() does not define an explicit binding handle!\n", def->name); return; @@ -79,7 +81,7 @@ static void write_function_stubs(type_t *iface, unsigned int *proc_offset) } else if (implicit_handle) { - if (explicit_handle_var) + if (explicit_handle_var || explicit_user_handle_var) { error("%s() must not define a binding handle!\n", def->name); return; diff --git a/tools/widl/widl.c b/tools/widl/widl.c index 21657b6..0af449d 100644 --- a/tools/widl/widl.c +++ b/tools/widl/widl.c @@ -409,6 +409,7 @@ int main(int argc,char *argv[]) if(do_header) { fprintf(header, "/* Begin additional prototypes for all interfaces */\n"); fprintf(header, "\n"); + write_user_handles(); write_user_types(); fprintf(header, "\n"); fprintf(header, "/* End additional prototypes */\n");

1 0

wine menus
by Damjan Jovanovic 24 Jun '07

24 Jun '07

Hi At the moment, wine builds fd.o menus by calling winemenubuilder and wineshelllink when shell32's IPersistFile_fnSave is invoked. This both misses menus copied directly into the menu directory without calling IPersistFile_fnSave, and provides no way to remove the menus when the app is uninstalled. Wine also keeps .lnk files in ~/.wine/drive_c/windows/profiles/<user>/Start Menu/ just like Windows does, and those .lnk files seem like a much better representation of the menus that should appear on the system, because they are also deleted when an app is uninstalled. Is it possible to add a new utility, or patch an existing utility like wineboot, to synchronize between wine's .lnk files in the windows directory and the fd.o menus, instead of using winemenubuilder/wineshelllink? Would a patch that does that be okay? Thank you Damjan

7 9

Re: msi: Fix use of uninitialized variable (Coverity) (Try 3)
by James Hawkins 24 Jun '07

24 Jun '07

On 6/23/07, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > [Reverting to "Plan A":] > This patch should fix Coverity bug CID-562. Additionally, I have pinpointed > another suspected use-before-initialization bug, for future consideration. > > -- Andy. > --- > Changelog: > msi: Fix use of uninitialized variable (Coverity). > > diff -urN a/dlls/msi/action.c b/dlls/msi/action.c > --- a/dlls/msi/action.c 2007-06-18 17:52:27.000000000 +0100 > +++ b/dlls/msi/action.c 2007-06-23 22:19:03.000000000 +0100 > @@ -4668,7 +4668,7 @@ > > res = env_set_flags(&name, &deformatted, &flags); > if (res != ERROR_SUCCESS) > - goto done; > + goto done2; > > value = deformatted; > > @@ -4676,8 +4676,14 @@ > root = HKEY_LOCAL_MACHINE; > > res = RegOpenKeyExW(root, environment, 0, KEY_ALL_ACCESS, &env); > + /* > + * FIXME: RegCloseKey() should not be called with an invalid handle. > + * So should we simply "goto done2" here, if res != EXIT_SUCCESS, > + * or does RegOpenKeyEx() have any failure modes in which "env" does > + * get initialized? > + */ > if (res != ERROR_SUCCESS) > - goto done; > + goto done1; > > if (flags & ENV_ACT_REMOVE) > FIXME("Not removing environment variable on uninstall!\n"); > @@ -4686,14 +4692,14 @@ > res = RegQueryValueExW(env, name, NULL, &type, NULL, &size); > if ((res != ERROR_SUCCESS && res != ERROR_FILE_NOT_FOUND) || > (res == ERROR_SUCCESS && type != REG_SZ)) > - goto done; > + goto done1; > > if (res != ERROR_FILE_NOT_FOUND) > { > if (flags & ENV_ACT_SETABSENT) > { > res = ERROR_SUCCESS; > - goto done; > + goto done1; > } > > data = msi_alloc(size); > @@ -4705,12 +4711,12 @@ > > res = RegQueryValueExW(env, name, NULL, &type, (LPVOID)data, &size); > if (res != ERROR_SUCCESS) > - goto done; > + goto done1; > > if (flags & ENV_ACT_REMOVEMATCH && (!value || !lstrcmpW(data, value))) > { > res = RegDeleteKeyW(env, name); > - goto done; > + goto done1; > } > > size = (lstrlenW(value) + 1 + size) * sizeof(WCHAR); > @@ -4719,7 +4725,7 @@ > if (!newval) > { > res = ERROR_OUTOFMEMORY; > - goto done; > + goto done1; > } > > if (!(flags & ENV_MOD_MASK)) > @@ -4749,7 +4755,7 @@ > if (!newval) > { > res = ERROR_OUTOFMEMORY; > - goto done; > + goto done1; > } > > lstrcpyW(newval, value); > @@ -4758,8 +4764,9 @@ > TRACE("setting %s to %s\n", debugstr_w(name), debugstr_w(newval)); > res = RegSetValueExW(env, name, 0, type, (LPVOID)newval, size); > > -done: > +done1: > RegCloseKey(env); > +done2: > msi_free(deformatted); > msi_free(data); > msi_free(newval); > This is uglier than the other patch. The only change needed in this entire function is to set env to NULL initially. There's nothing wrong with calling RegCloseKey(NULL-var) and it's done everywhere in the code base. -- James Hawkins

1 0

Re: msi: Fix use of uninitialized variable (Coverity) (Try 2)
by James Hawkins 24 Jun '07

24 Jun '07

On 6/23/07, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > This patch should fix Coverity bug CID-562. > > -- Andy. > --- > Changelog: > msi: Fix use of uninitialized variable (Coverity). > > diff -urN a/dlls/msi/action.c b/dlls/msi/action.c > --- a/dlls/msi/action.c 2007-06-18 17:52:27.000000000 +0100 > +++ b/dlls/msi/action.c 2007-06-23 17:08:55.000000000 +0100 > @@ -4648,7 +4648,7 @@ > LPWSTR deformatted, ptr; > DWORD flags, type, size; > LONG res; > - HKEY env, root = HKEY_CURRENT_USER; > + HKEY env = NULL, root = HKEY_CURRENT_USER; > > static const WCHAR environment[] = > {'S','y','s','t','e','m','\\', > @@ -4759,7 +4759,7 @@ > res = RegSetValueExW(env, name, 0, type, (LPVOID)newval, size); > > done: > - RegCloseKey(env); > + if (env) RegCloseKey(env); > msi_free(deformatted); > msi_free(data); > msi_free(newval); > Please don't check env for NULL; RegCloseKey will just fail harmlessly if env is NULL. We spent a lot of time removing such checks. -- James Hawkins

4 3

Bugzilla mails and people replying to wine-bugs@winehq.com
by Tom Spear 23 Jun '07

23 Jun '07

Just curious how trivial it would be to add a note to the bugzilla mail template saying to post replies to comments in the bug? Something like the following: A bug you are watching, Bug #(bug number), has a new comment. To reply to this comment, click (bug link). Then the rest of the email as it currently appears. I'm asking because I have received several replies to the list recently, and once wine reaches 1.0, I'm sure many more people will join the list and do the same. I don't want comments to be lost due to them not being posted in the proper place, as everyone's input on a bug is important. -- Thanks Tom

3 3

Wine on SkyOS
by Tom Wickline 23 Jun '07

23 Jun '07

Hello All, Looks as if SkyOS will soon support Wine! Internals - Many kernel updates like LDT support (required by Wine), updated signal handling, pthread support, and overall additional POSIX compatibility enhancements. http://www.skyos.org/?q=node/605 Tom

3 2

Re: msi: Fix use of uninitialized variable (Coverity)
by Paul Vriens 23 Jun '07

23 Jun '07

Andrew Talbot wrote: > This patch should fix Coverity bug CID-562. Additionally, I have pinpointed > another suspected use-before-initialization bug, for future consideration. > > -- Andy. > --- > Changelog: > msi: Fix use of uninitialized variable (Coverity). > Wouldn't it be easier to set env to NULL when declaring it and do a: if (env) RegCloseKey(env); Cheers, Paul.

2 1

RegOpenKeyExW() Question
by Andrew Talbot 23 Jun '07

23 Jun '07

Hi, I want to patch msi:action.c:ITERATE_WriteEnvironmentString() so that it only calls RegCloseKey(env), in the cleanup, if "env" has been initialized (to fix Coverity report CID-562). I can bypass the call to RegCloseKey() for any early exit that occurs prior to calling RegOpenKeyExW(), and I can include the call to RegCloseKey() for exits that occur after a successful call to RegOpenKeyExW(). However, the problem, for me, is what to do if the call to RegOpenKeyExW() fails: does the occurrence of this initialization depend on the reason for failure. In other words, do I need something like the following code to cater for the reason failure occurred? res = RegOpenKeyExW(root, environment, 0, KEY_ALL_ACCESS, &env); if (res != ERROR_SUCCESS) if (res == ERROR_INVALID_HANDLE || res == RtlNtStatusToDosError(STATUS_BUFFER_OVERFLOW || res == RtlNtStatusToDosError(STATUS_INVALID_PARAMETER)) goto done2; else goto done1; ... done1: RegCloseKey(env); done2: ... Or will the following code suffice? res = RegOpenKeyExW(root, environment, 0, KEY_ALL_ACCESS, &env); if (res != ERROR_SUCCESS) goto done2; ... done1: RegCloseKey(env); done2: ... Thanks, -- Andy.

2 2

gdiplus: graphics tests [try2]
by Misha Koshelev 22 Jun '07

22 Jun '07

> Am Freitag, 15. Juni 2007 22:02 schrieb Jan Zerebecki: > > On Fri, Jun 15, 2007 at 01:36:09PM +0200, Alexandre Julliard wrote: > > > "Evan Stade" <estade at gmail.com> writes: > > > > +static const INT drawline_bmp1[192] = > > > > +{0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xf > > > >fffffff, > > > > > > I don't think we want to do that sort of thing. We can't guarantee > > > that the results will be exact pixel for pixel, and we don't really > > > care. And even if we did, hardcoding the image in the source this way > > > is unmaintainable. > > > > > > If you want to check the results, you should write an app that draws > > > various things and check it visually against Windows, but I don't > > > think that's something that can be part of the regression test suite. > > May I suggest something like enclosing your gdiplus function calls in a regression test in a BeginPath(hdc) and EndPath(hdc) and then using GetPath to check that the paths created by your functions conform to those on native (you can take a look at what I am using right now in dlls/gdi/tests/path.c and some expansions here http://www.winehq.org/pipermail/wine-patches/2007-June/040679.html). I have found that it seems to be a good way to test at least the gdi functions without having to compare the visual result pixel by pixel while still being able to test the basic drawing primitives that are being used (btw you have to give the x&y coords +/- 1 or 2 when checking them b/c of floating point rounding diffs). The only downside for using this kind of framework would be that if anything changes in gdi32's path implementation it would affect your tests, but I think no matter what you do for a graphics regression tests for gdiplus changes in gdi32 would affect it. Just wanted to throw the idea out as I think a good conformance test is worth its weight in gold. Misha

2 2

Re: winealsa.drv: Fix missing unlock on the error path. Found by Smatch.
by Maarten Lankhorst 22 Jun '07

22 Jun '07

That fix is correct, This->pcm is only ever changed inside the critical section Thanks, Maarten 2007/6/22, Michael Stefaniuc <mstefani(a)redhat.de>: > Maarten, > > is this the right fix or can the lock be moved below the > if (!This->pcm) > check? > > bye > michael > --- > dlls/winealsa.drv/dsoutput.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/winealsa.drv/dsoutput.c b/dlls/winealsa.drv/dsoutput.c > index 57b8968..9fc5020 100644 > --- a/dlls/winealsa.drv/dsoutput.c > +++ b/dlls/winealsa.drv/dsoutput.c > @@ -459,6 +459,7 @@ static HRESULT WINAPI IDsDriverBufferImpl_GetPosition(PIDSDRIVERBUFFER iface, > if (!This->pcm) > { > FIXME("Bad pointer for pcm: %p\n", This->pcm); > + LeaveCriticalSection(&This->pcm_crst); > return DSERR_GENERIC; > } > > -- > 1.5.0.6 >

1 0

Failing assertion in dsound test, please confirm
by Alex Villacís Lasso 22 Jun '07

22 Jun '07

I am experiencing a failing assertion in a dsound test. Could you please confirm if it is just me (and then it would be a configuration issue), or if anybody else is experiencing failing assertions: [alex@srv64 tests]$ WINETEST_INTERACTIVE=1 wine dsound_test.exe.so dsound ALSA lib conf.c:3939:(snd_config_expand) Unknown parameters 0 ALSA lib control.c:910:(snd_ctl_open_noupdate) Invalid CTL default:0 fixme:wave:ALSA_AddCaptureDevice Add support for DSCapture dsound.c:973:DLL Version: 5.3.1.904 dsound.c:180:Testing IDirectSound fixme:dsalsa:SetFormat Your alsa dmix period size is excessively high, unfortunately this is alsa default, try decreasing it to 512 or 256 (but double the amount of periods) if possible fixme:ole:CoCreateInstance no instance created for interface {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} of class {47d4d946-62e8-11cf-93bc-444553540000}, hres is 0x80004002 err:ole:CoGetClassObject class {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} not registered err:ole:CoGetClassObject no class object {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} could be created for context 0x1 dsound.c:938:*** Testing Primary Sound Driver - winealsa.drv *** dsound.c:475:Playing a 5 seconds reference tone at the current volume. dsound.c:478:(the current volume is -4651 according to DirectSound) dsound.c:480:All subsequent tones should be identical to this one. dsound.c:481:Listen for stutter, changes in pitch, volume, etc. ds3d.c:400:Requested format tag=0x0001 11025x16x2 avg.B/s=44100 align=4 ds3d.c:403:Got tag=0x0001 48000x16x2 avg.B/s=192000 align=4 ds3d.c:453: Playing 5 second 440Hz tone at 48000x16x2 dsound.c:582:Requested primary format tag=0x0001 8000x8x1 avg.B/s=8000 align=1 dsound.c:586:Got tag=0x0001 48000x8x1 avg.B/s=48000 align=1 dsound.c:607: Testing a primary buffer at 48000x8x1 with a secondary buffer at 11025x16x2 ds3d.c:453: Playing 1 second 440Hz tone at 11025x16x2 dsound.c:582:Requested primary format tag=0x0001 8000x8x2 avg.B/s=16000 align=2 dsound.c:586:Got tag=0x0001 48000x8x2 avg.B/s=96000 align=2 dsound.c:607: Testing a primary buffer at 48000x8x2 with a secondary buffer at 11025x16x2 ds3d.c:453: Playing 1 second 440Hz tone at 11025x16x2 dsound.c:582:Requested primary format tag=0x0001 8000x16x1 avg.B/s=16000 align=2 dsound.c:586:Got tag=0x0001 48000x16x1 avg.B/s=96000 align=2 dsound.c:607: Testing a primary buffer at 48000x16x1 with a secondary buffer at 11025x16x2 ds3d.c:453: Playing 1 second 440Hz tone at 11025x16x2 dsound.c:582:Requested primary format tag=0x0001 8000x16x2 avg.B/s=32000 align=4 dsound.c:586:Got tag=0x0001 48000x16x2 avg.B/s=192000 align=4 dsound.c:607: Testing a primary buffer at 48000x16x2 with a secondary buffer at 11025x16x2 ds3d.c:453: Playing 1 second 440Hz tone at 11025x16x2 mixer.c:823: DSOUND_PerformMix: La declaración `device->playpos < device->buflen' no se cumple. wine: Assertion failed at address 0x600007f2 (thread 000f), starting debugger... dsound.c:582:Requested primary format tag=0x0001 11025x8x1 avg.B/s=11025 align=1 dsound.c:586:Got tag=0x0001 48000x8x1 avg.B/s=48000 align=1 dsound.c:607: Testing a primary buffer at 48000x8x1 with a secondary buffer at 11025x16x2 Unhandled exception: assertion failed in 32-bit code (0x600007f2). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:600007f2 ESP:7ed516cc EBP:7ed516d8 EFLAGS:00000202( - 00 - - I1) EAX:00000000 EBX:00002cd3 ECX:00002cd5 EDX:00000006 ESI:7ed51778 EDI:60298ff4 Stack dump: 0x7ed516cc: 60171fa0 60298ff4 7ed52b90 7ed51804 0x7ed516dc: 601738b1 00000006 7ed51778 00000000 0x7ed516ec: 00000068 7cae1278 00000000 00000000 0x7ed516fc: 601ae37d 7ed5173c 7cae1278 7cae12dc 0x7ed5170c: 7ed51814 60298ff4 00000062 7cae1278 0x7ed5171c: 7ed517e8 601a7d3b 7cae1278 00000062 Backtrace: =>1 0x600007f2 (0x7ed516d8) 2 0x601738b1 (0x7ed51804) 3 0x6016b3ce (0x7ed51848) 4 0x608bdfe8 DSOUND_timer+0x2108(timerID=0x1, msg=0x0, dwUser=0x167688, dw1=0x0, dw2=0x0) [/home/alex/install/wine-0.9.39-build/dlls/dsound/mixer.c:554] in dsound (0x7ed519b8) 5 0x60910b96 TIME_MMSysTimeThread+0x2e6(arg=0x0) [/home/alex/install/wine-0.9.39-build/dlls/winmm/time.c:181] in winmm (0x7ed51a18) 6 0x7bc5d19e call_thread_entry_point+0xe() in ntdll (0x7ed51a28) 7 0x7bc5de72 call_thread_func+0x42(rtl_func=<register EDI not in topmost frame>, arg=<register ESI not in topmost frame>) [/home/alex/install/wine-0.9.39-build/dlls/ntdll/thread.c:404] in ntdll (0x7ed51ac8) 8 0x7bc5e10f in ntdll (+0x4e10f) (0x7ed523c8) 9 0x601362fb (0x7ed524b8) 10 0x6021993e (0x00000000) 0x600007f2: ret Modules: Module Address Debug info Name (66 modules) ELF 24d000- 2bd000 Deferred libgl.so.1 ELF 24d000- 2bd000 Deferred libgl.so.1 ELF 43e000- 45b000 Deferred ld-linux.so.2 ELF 45d000- 5b1000 Deferred libc.so.6 ELF 5b3000- 5dc000 Deferred libm.so.6 ELF 5de000- 5e3000 Deferred libdl.so.2 ELF 5fa000- 612000 Deferred libpthread.so.0 ELF 614000- 619000 Deferred libxxf86vm.so.1 ELF 640000- 645000 Deferred libxfixes.so.3 ELF 6b5000- 6bb000 Deferred libxdmcp.so.6 ELF 6bd000- 7bf000 Deferred libx11.so.6 ELF 802000- 805000 Deferred libxau.so.6 ELF 80c000- 81c000 Deferred libxext.so.6 ELF 8aa000- 8cb000 Deferred libexpat.so.0 ELF 926000- 92f000 Deferred libxrender.so.1 ELF a84000- a8e000 Deferred libxcursor.so.1 ELF a98000- b22000 Deferred libfreetype.so.6 ELF b24000- b53000 Deferred libfontconfig.so.1 ELF bbb000- bc6000 Deferred libdrm.so.2 ELF cef000- cf6000 Deferred libxrandr.so.2 ELF dfa000- dfd000 Deferred libxinerama.so.1 ELF 5cf0000- 5dce000 Deferred libasound.so.2 ELF 65f6000- 65ff000 Deferred libsm.so.6 ELF 6601000- 661b000 Deferred libice.so.6 ELF 6001d000-60131000 Deferred libwine.so.1 ELF 602cb000-6032b000 Deferred dsound_test<elf> \-PE 602e0000-6032b000 \ dsound_test ELF 6032b000-60371000 Deferred advapi32<elf> \-PE 60340000-60371000 \ advapi32 ELF 60371000-604ab000 Deferred user32<elf> \-PE 60390000-604ab000 \ user32 ELF 604ab000-60541000 Deferred gdi32<elf> \-PE 604c0000-60541000 \ gdi32 ELF 60541000-60597000 Deferred rpcrt4<elf> \-PE 60550000-60597000 \ rpcrt4 ELF 60597000-605b5000 Deferred iphlpapi<elf> \-PE 605a0000-605b5000 \ iphlpapi ELF 605c9000-605e2000 Deferred version<elf> \-PE 605d0000-605e2000 \ version ELF 60892000-608db000 Dwarf dsound<elf> \-PE 608a0000-608db000 \ dsound ELF 608db000-60968000 Dwarf winmm<elf> \-PE 608f0000-60968000 \ winmm ELF 60a46000-60a5e000 Deferred msacm32<elf> \-PE 60a50000-60a5e000 \ msacm32 ELF 60a5e000-60a84000 Deferred msacm32<elf> \-PE 60a70000-60a84000 \ msacm32 ELF 61d5f000-61d74000 Deferred midimap<elf> \-PE 61d70000-61d74000 \ midimap ELF 6a741000-6a74d000 Deferred libnss_files.so.2 ELF 6d8a4000-6d8d6000 Deferred winealsa<elf> \-PE 6d8b0000-6d8d6000 \ winealsa ELF 7525e000-752ec000 Deferred winex11<elf> \-PE 75270000-752ec000 \ winex11 ELF 757d6000-757ea000 Deferred lz32<elf> \-PE 757e0000-757ea000 \ lz32 ELF 77861000-7787e000 Deferred imm32<elf> \-PE 77870000-7787e000 \ imm32 ELF 79cd4000-79cd7000 Deferred iso8859-1.so ELF 79d6e000-79e0b000 Deferred ole32<elf> \-PE 79d80000-79e0b000 \ ole32 ELF 7b800000-7b924000 Deferred kernel32<elf> \-PE 7b820000-7b924000 \ kernel32 ELF 7bc00000-7bc96000 Dwarf ntdll<elf> \-PE 7bc10000-7bc96000 \ ntdll ELF 7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000010 00000012 0 00000011 0 0000000d (D) Z:\home\alex\install\wine-0.9.39-build\dlls\dsound\tests\dsound_test.exe 0000000f 15 <== 0000000e 0 -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

2 1

Re: How to make your machine crash when running Wine
by gslink 22 Jun '07

22 Jun '07

Most of the people here are probably smarter than to fall into this trap but I recently had several customers who did. Most of the time openGL just refuses to run but a couple of months ago RH did put out an update to some of the X code that did cause the machine to crash with Wine if you didn't replace the Nvidia driver. The customers were running some things under Wine that used hardware acceleration. If they had used hardware acceleration outside of Wine the machine would have crashed too. This is not a Wine problem but it is likely to be a source of regular complaints.

1 0

Re: dpnhpast: Add stub for DirectPlayNATHelpCreate
by Detlef Riekenberg 22 Jun '07

22 Jun '07

On Fr, 2007-06-22 at 04:39 +0200, Alexander Nicolaysen Sørnes wrote: > +HRESULT WINAPI DirectPlayNATHelpCreate(const LPGUID pIId, void ** > ppvInterface) > { > - /* @stub in .spec */ > + FIXME("stub"); > + return E_FAIL; > } > -#endif The FIXME is missing the newline and it would be useful to dump the Parameters in the FIXME. -- By by ... Detlef

1 0

Re: [3/7] gdiplus: GdipReAlloc
by Alexandre Julliard 22 Jun '07

22 Jun '07

"Evan Stade" <estade(a)gmail.com> writes: > This is only declared privately because it is not a function provided > by the dll. It follows the exported-function naming scheme however, > because it's a counterpart to GdipFree and GdipAlloc. Please don't do that, it's confusing. If there's no GdipReAlloc just use HeapReAlloc directly. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: [1/2] oleaut32: add PNG loading [try2]
by Dan Kegel 22 Jun '07

22 Jun '07

Alexandre wrote: >> How can I improve this patch such that it will be accepted? > >The biggest problem is that the libpng versioning scheme is broken, so >we can't find the proper soname. This will need some more configure >magic. Looking at http://www.libpng.org/pub/png/libpng.html and http://www.linux-foundation.org/en/LibPng and /usr/include/png.h I get the impression that the libpng versioning scheme was cleaned up for the 1.2 series over four years ago. So perhaps we could just change configure.ac to check PNG_LIBPNG_VER_MAJOR and make sure it's exactly 1, and check PNG_LIBPNG_VER_MINOR and make sure it's 2 or greater. That would let us avoid the old broken libpng's, wouldn't it? - Dan

2 1

Re: [PATCH try2 4/4] gdi32: Call pMoveTo if available when emulating ArcTo/PolylineTo/PolyBezierTo.
by Alexandre Julliard 22 Jun '07

22 Jun '07

Misha Koshelev <mk144210(a)bcm.edu> writes: > This sends proper position information to the GDI driver when we are emulating these functions. I don't think I agree with this one. If the driver needs to update the position then it should implement ArcTo etc. since it may need to distinguish that from an explicit MoveTo. Or if the generic implementation is really good enough in all cases then we shouldn't export a driver entry point at all. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: PATCH - implement LockWorkStation using xdg-screensaver on Linux
by Hans Leidekker 21 Jun '07

21 Jun '07

On Tuesday 19 June 2007 20:08:50 Steven Edwards wrote: > Patch by Hans Leidekker It's your idea so you should get the credit. I was just helping out with the implementation. > This could be expanded for other platforms that use xdg stuff by > changing the #ifdef. I added the #ifdef to also deal with the MacOS > case. There will allways be Linux distributions that don't install the xdg tools by default, and it's not inconceivable that they will be supported on MacOS one day. So I think it's better to just try to run xdg-screensaver, warn when it fails, but ignore the error. From reading MSDN this is consistent with the semantics of LockWorkStation. I also think it's better to not lock the entire desktop when Wine runs in a virtual desktop. I remember looking for a way to know whether we are running in desktop mode and found this snippet from PaintDesktop(): HWND hwnd = GetDesktopWindow(); /* check for an owning thread; otherwise don't paint anything (non-desktop mode) */ if (GetWindowThreadProcessId( hwnd, NULL )) ... I copied it but somehow it didn't work for me. -Hans

5 5

re: NULL ptr dereferences found with Calysto static checker
by Dan Kegel 21 Jun '07

21 Jun '07

Domagoj wrote: > I've ran my static checker Calysto on Wine v0.9.35 and got > 78 bug reports:... > If you are interested in the reports, please: > 1) read > http://www.cs.ubc.ca/~babic/index_calysto_community.htm > 2) if the conditions are acceptable, let me know where to > send the reports. The conditions look very minimal, we should be fine with them. A check once a month should be fine. Just send the results to wine-devel(a)winehq.org. (There's some chance we'll ask you to switch to sending them somewhere else, but that will do initially.) For the moment just put the calysto.org link in the mail. Once it's clear the results are useful, somebody will link to calysto at least from our wiki. Say, whatever happened to Coverity's scans of Wine? I just logged in to the Wine results at http://scan.coverity.com, and the last scan seems to have been last July. Did they set up a new, private site for us? Paul V., do you know? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

9 11

Coverity status
by Paul Vriens 21 Jun '07

21 Jun '07

Hi, I've been in contact with Coverity. People currently listed as Wine contacts are: - Jan Zerebecki - Paul Vriens The main page is changed so it reflects the new scan site http://scan2.coverity.com:7479 and there has just been a new run! Coverity is very busy setting up some proper communication channels and some means for the contacts to do some kind of user administration (limited of course). Apart from that a lot of the current manual tasks will be automated (like the counters on the page where Wine is listed http://scan.coverity.com/rung1.html). Cheers, Paul.

1 0

Re: winmm: Specify the arguments of the function in the function pointer
by Alexandre Julliard 21 Jun '07

21 Jun '07

Michael Stefaniuc <mstefani(a)redhat.de> writes: > @@ -114,10 +114,10 @@ static BOOL MMDRV_GetDescription32(const char* fname, char* buf, int buflen) > DWORD dw; > BOOL ret = FALSE; > UINT u; > - FARPROC pGetFileVersionInfoSizeA; > - FARPROC pGetFileVersionInfoA; > - FARPROC pVerQueryValueA; > - HMODULE hmodule = 0; > + DWORD (WINAPI *pGetFileVersionInfoSizeA)(LPCSTR,LPDWORD); > + BOOL (WINAPI *pGetFileVersionInfoA)(LPCSTR,DWORD,DWORD,LPVOID); > + BOOL (WINAPI *pVerQueryValueA)(LPCVOID,LPCSTR,LPVOID*,UINT*); > + HMODULE hmodule = 0; It may have been done that way because local WINAPI pointers crash on old versions of gcc. But that whole function should probably be removed, dumping version info doesn't belong in winmm. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] oleaut32: add PNG loading [try2]
by Evan Stade 21 Jun '07

21 Jun '07

On 6/19/07, Evan Stade <estade(a)gmail.com> wrote: > Hi, > > Try2: This time the rowsize is correctly aligned (on 4-byte > boundaries) and palette-mode PNGs are allowed as well as RGB-mode > PNGs. > > Changelog: > *added support to decode some PNG files > *added check for png.h / dynamic loading of libpng.so > > configure.ac | 2 > dlls/oleaut32/olepicture.c | 205 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 207 insertions(+), 0 deletions(-) > > -- > Evan Stade > > Hi, How can I improve this patch such that it will be accepted? -- Evan Stade

2 1

Re: shell32: Make SHGetDesktopFolder use a cached instance of IShellFolder
by Alexandre Julliard 21 Jun '07

21 Jun '07

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > + sf = LocalAlloc( LMEM_ZEROINIT, sizeof (IGenericSFImpl) ); > + if (!sf) > + return E_OUTOFMEMORY; > + > + if (InterlockedCompareExchangePointer((void *)&cached_sf, sf, NULL) != NULL) > + LocalFree( sf ); /* some other thread already been here */ > + else > + { > + sf->ref = 0; > + sf->lpVtbl = &vt_MCFldr_ShellFolder2; > + sf->pidlRoot = _ILCreateDesktop(); /* my qualified pidl */ > + sf->sPathTarget = SHAlloc( (lstrlenW(szMyPath) + 1)*sizeof(WCHAR) ); > + lstrcpyW( sf->sPathTarget, szMyPath ); > + } > + } You need to initialize the object completely before storing it as cached entry. -- Alexandre Julliard julliard(a)winehq.org

1 0

ntdll: Constify some variables (1 of 2)
by Andrew Talbot 21 Jun '07

21 Jun '07

Please ignore this patch. Thanks, -- Andy.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel