April 2006 - Wine-devel - list.winehq.org

Re: search for /dev/input/js as well as /dev/js
by Mike McCormack 20 Apr '06

20 Apr '06

Mike Frysinger wrote: > with udev now, joystick nodes are created as /dev/input/js# and /dev/js# no > longer exists ... attached patch will search for /dev/input/js# first and if > that doesnt exist, fall back to /dev/js# You could easily maintain compatibility with Wine and any other application using joysticks simply by adding some symlinks in /dev. That's what my system has, and it's using udev. Mike

7 12

File dialog regression?
by Mike Hearn 20 Apr '06

20 Apr '06

Has anybody else got a problem with no icons appearing in the file dialogs? I just see the generic "blank document" icon - it's as if the shell icons aren't being loaded anymore. My Sherlock-Holmes-esque 6th sense leads me to think that either my setup is borked or the fake stub DLL patch is to blame. thanks -mike

2 1

Re: [usp10] Fix return-codes of ScriptGetFontProperties (resend)
by Joris Huizer 20 Apr '06

20 Apr '06

Paul Vriens wrote: > + /* Now a NULL hdc again */ > + hr = ScriptGetFontProperties(NULL,&psc,&sfp); > + /* Save the psc pointer */ > + old_psc = psc; > + ok( hr == S_OK, "(NULL,&psc,&sfp), expected S_OK, got %08x\n", (unsigned int)hr); > + ok( psc == old_psc, "Expected psc not to be changed, was %p is now %p\n", old_psc, psc); > + ScriptFreeCache(&psc); > + ok( psc == NULL, "Expected psc to be NULL, got %p\n", psc); actually You didn't test anything about psc here, after setting old_psc nothing happens with psc -- save the pointer before calling ScriptGetFontProperties(NULL,&psc,&sfp); HTH, Joris

1 0

Using msvcmon to debug
by Ryan Miller 20 Apr '06

20 Apr '06

Hi, I've been using msvcmon previously to remote debug application in Visual Studio on Wine. It's great to have an IDE to debug Wine with the breakpoints and watch windows and all. I'm now using Crossover Office Pro 5.0.1-1rc2 and msvcmon is no longer working. I'm getting the log message (which is new): epoll_ctl: Operation not permitted Followed by an exception dialog and an abort. I compared the exception address to my app's map file and I'm thinking it's a Wine address/exception. Does anyone else use msvcmon to debug? Any clues where I should start looking? Thanks. Ryan

3 2

x11drv: question about byte-swapping for DIBs
by Eric Frias 20 Apr '06

20 Apr '06

I'm trying to debug a problem in which 24-bit .bmps don't display correctly from a winelib application on a big-endian sparc host when displaying on a little-endian intel PC. In this case, the image is garbled, with most of the colors being wrong and a pattern of vertical stripes over the image. The code passes through convert_888_to_0888_reverse_dst_byteswap which is what mangles the image data. I looked through the other conversion functions, and it seems the corresponding 'src' function (convert_888_to_0888_reverse_src_byteswap) actually does the correct transformation. I don't have a very good grasp of why the conversions are chosen, but it seemed like a likely fix would be to edit dib.c and make the lines in the SetImageBits functions that select the conversion structure look like: #ifdef WORDS_BIGENDIAN const dib_conversions *convs = (bmpImage->byte_order == LSBFirst) ? &dib_normal : &dib_src_byteswap; #else const dib_conversions *convs = (bmpImage->byte_order == LSBFirst) ? &dib_normal : &dib_dst_byteswap; #endif Doing this fixed my problem and didn't seem to cause any others, but I'm wondering whether this fix is correct or if I just got lucky. Can someone who knows this code tell me if this makes logical sense? (If it's correct, there probably needs to be a related patch in the GetImageBits functions, just going in the other direction). Eric

3 4

usp10: Remove the need to pass chars to ScriptPlace
by Jeff L 20 Apr '06

20 Apr '06

This patch uses GetCharABCWidthsI to remove the need to pass chars from ScriptShape to ScriptPlace in the scriptcache work space. Change log: Remove the need to pass chars from ScriptShape to ScriptPlace Jeff Latimer

1 0

Re: Race in rpc__cn_network_receiver()?
by Luke Kenneth Casson Leighton 20 Apr '06

20 Apr '06

On Thu, Apr 20, 2006 at 03:04:21PM +1000, Luke Howard wrote: luke, you are a star: thank you for helping out with this. just for people's information (in case it's not been mentioned here - i must admit i forgot to notify opendce(a)opengroup.org!) about 6-8 months ago i did a coding-spree on freedce, with a view to achieving two, maybe three, major things: 1) porting to win32 (if you use pthreads-win32) 2) using posix final draft (7?) threads not posix draft 4. 3) proving to the people on wine and reactos that they have a hell of a lot of work to do (measured in man-decades) by not using the open group's DCE/RPC reference implementation. here's the gotchas that i encountered, and had to give up: - udp worked, but tcp did not - reactos had some problems at the time with the code behind ipconfig.exe (NetTransportEnum i think it was) - pthreads-win32 was too strictly posix compliant (!) and there is a cancellation exception or something which makes it fail in the dcethreads exception library tests, where linux does not fail (!) maybe this is related to what lukeh is talking about. *shrug*. anyway, the upshot is that freedce/latest-cvs also doesn't work on TCP, and thank you so much people for helping track down why. it's only been ten years so far: hopefully some time within the next decade, freedce will be used for some real MSRPC-related free software projects. l > >In rpc__cn_network_receiver(), rpc__socket_close() is called without an > >exception handler in place. According to IEEE Std 1003.1 (2004), close() > >is a cancellation point, see: > > > >http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html > > > >Given this, a receiver thread could receive a cancel whilst closing the > >socket, which will cause to entire program to abort. (We have seen this > >occur when the RPC server is under load.) > > > >A suggested fix is to move the call to rpc__socket_close() inside the > >TRY/CATCH_ALL block that removes any pending cancels. > > It seems like the real fix is to disable cancellation within > rpc__socket_close(), because in other places the OSF code appears to > assume that this is not a cancellation point. > > Ditto for open(), socket(), etc (but not I/O routines that may block). > > I should note that the Linux dcethreads library does actually disable > cancellation for these calls, however in our own DCE thread library > we opted not to override any system calls to avoid changing semantics > when used by non-DCE code. > > -- Luke > > -- > -- -- lkcl.net - mad free software computer person, visionary and poet. --

1 0

Wine or WINE?
by Ivan Leo Puoti 19 Apr '06

19 Apr '06

I was reading WWN yesterday and read something about Microsoft using the incorrect "WINE" form, I email them about it and they appear willing to fix it. Probably the first example of cooperation from them :-) Ivan.

1 0

SoC Mentor Signup!
by Dan Kegel 19 Apr '06

19 Apr '06

Jeremy White asked earlier for people to volunteer for the review committee. I think anybody who wants to be a SoC mentor should also volunteer for the review committee. And we need a list of mentors soon, so please, if you are interested in helping, email Jeremy as soon as you can. The great thing about being a Wine mentor is the leverage... you get to help Wine without doing all the heavy lifting yourself. And, if you're lucky, the student you mentor will keep on helping the Wine project even after you're done, so it's a gift that keeps on giving... Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: Menus [3/6]: Draw the column separator properly
by Dimi Paun 19 Apr '06

19 Apr '06

On Wed, 2006-04-19 at 21:39 +0200, Michael Kaufmann wrote: > --- menu.c 2006-04-19 21:07:47.000000000 +0200 > +++ menu-new.c 2006-04-19 21:07:44.000000000 +0200 Only top-level patches, please: http://winehq.org/site/sending_patches -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0