July 2004 - Wine-devel - list.winehq.org

daily wine cvs source snapshots?
by Jeroen Janssen 22 Jul '04

22 Jul '04

Hello, I was wondering since: 1) wine uses CVS (and not svn with httpwebdav) and 2) CVS doesn't go through the firewall at my work (and possible also not for other people) Would it be possible to have daily cvs snapshots (cvs export) of the wine HEAD tree? This makes tracking the latest HEAD possible for people that can't use CVS to access the repository. I know that the CVS repository itself is available, but that sounds a bit overkill to me. best regards, Jeroen Janssen

3 3

Re: devenum
by Marcelo Duarte 22 Jul '04

22 Jul '04

Ivan Leo Puoti wrote: > English resources moved to En.rc, language neutral resources moved to Xx.rc, > and italian resources added in It.rc > Licence: LGPL > > Ivan. Ivan, Why you do not leave the neutral resources in the main archive? Greetings, Marcelo

1 0

COM outproc & CFProxy unhandled interface for IRunnableObject
by Jeroen Janssen 22 Jul '04

22 Jul '04

Hello, I'm trying to run 2 programs: 1) is a COM server program 2) is a COM client program Now, program 2) tries to access a COM component from 1) (outproc). It seems some marshalling is being done, but eventually I get: fixme:ole:CFProxy_QueryInterface Unhandled interface: {00000126-0000-0000-c000-000000000046} This interface seems to be IRunnableObject. Now I'm not exactly sure how this is supposed to work, or even if this is the reason why my test currently fails. I can provide more logging/info if I know what exactly to provide. Note that I tried a small outproc client/server test that seems to go ok without this error, so the 'basic' outproc mechanism seems to work ok. Can someone provide more information on how wine deals with Outproc COM? On a side note, what are the main differences in COM implementation between wine and winex (if I understand correctly, Transgaming rewrote the COM implemenation for winex in order to better support the InstallShield installer?). Best regards, Jeroen Janssen

3 3

tests: safe MAPI init
by Ferenc Wagner 22 Jul '04

22 Jul '04

Hi (and sorry for the broken post), the mapi32 tests call scInitMapiUtil, which pops up an alert box saying something like (translating it) "Your default mailer application isn't capable of this operation, please ensure that Outlook is configured as the default mailer." This brings the tests to a halt, and even after clicking OK one gets 65536 failures bumping the logs above 5 MB. As a side note, most of the mapi tests are very careful about calling every function through a pointer acquired by GetProcAddr(), still the test executable is linked with -lmapi32. Does it make any sense? From winetest's perspective it isn't worth much, if a test can't run it's skipped altogether. Does it take care about different mapi versions? There are no recent reports on test.winehq.org/data, so something is obviously wrong. I'd be interested in hearing about people running Chris' winrash service. What happens if you run winetest directly? Don't forget to supply you tag with the -t option! Basically, winetest's own message boxes are OK, system message boxes are a problem. Thanks, Feri.

2 4

tests: safe MAPI init
by Ferenc Wagner 22 Jul '04

22 Jul '04

Hi, the mapi32 tests call scInitMapiUtil, which pops up an alert box

1 0

Serial port patch in 20040716
by Scott Snell 22 Jul '04

22 Jul '04

I installed 20040716 from an rpm and although most of it worked very well I had issues with the serial port. It would send out some characters at the start but I couldnt read any characters. After reading the thread "General serial communications issues" I found Eric Pouech's patch. I downloaded the source for 20040716 and applied the patch. I had to add #define for FD_FLAG_AVIALABLE in several files to get the project to compile. Unfortunately it doesnt solve my problem. Is there a particular version of the source I should apply the patch to? Does anyone have a patch for 20040716 source? Am I missing something fundamental with setting up serial ports? ta scott.

1 0

Localization status
by Marcelo Duarte 22 Jul '04

22 Jul '04

Hi, I modified a tool that Vincent Béron made and thus we can have the status of the translation of some languages. Case somebody wants that I add others I inform me. We can see that some languages are well complete, as the Portuguese ;) file:///home/mduarte/wine/tools/trans_html/index.html <cid:part1.03040507.04030402(a)bol.com.br>

1 0

Localization status
by DTM Informática 22 Jul '04

22 Jul '04

Hi, I modified a tool that Vincent Béron made and thus we can have the status of the translation of some languages. Case somebody wants that I add others I inform me. We can see that some languages are well complete, as the Portuguese ;) file:///home/mduarte/wine/tools/trans_html/index.html <cid:part1.04060404.05090008(a)bol.com.br>

1 0

Re: Avoid BadMatch Error
by Alexandre Julliard 22 Jul '04

22 Jul '04

Philip Dicke <Philip.Dicke(a)raytheon.com> writes: > Sometimes, when converting from a disabled pixmap for an icon in > x11drv/bitblt.c, an area is requested using XGetImage that is larger then > the actual drawable. This causes a X BadMatch error and wine immediately > exits. The submitted patch avoids this error by checking the size of the > requested area and the size of the drawable in BITBLT_GetSrcArea. That should not happen, the drawable size must have been taken into account when computing visRectSrc already. You'll need to find out why visRectSrc doesn't contain the proper size in your case. -- Alexandre Julliard julliard(a)winehq.org

1 0

pthread_mutex in a winelib dll called from a win32 application
by Shachar Shemesh 22 Jul '04

22 Jul '04

Hi all, Are there any restrictions in synchronizing wine generated threads (generated through the win32 api) using the pthreads library native calls? I have an app that is experiencing extremely slow performance (operation takes 17 seconds on native windows, over 3 minutes on Wine). One idea for solving this problem was to switch some of the synchronization operations over to native pthreads (it's using wine as part of a migration to Linux process). The problem is that when I try to call pthread_mutex_init, pthread_mutex_lock and friends, I get quite a few deadlocks, and even when not deadlocking, it still takes over 42 seconds. When doing the same without the mutexes (I'm locking write access to a pipe - I'm not sure it's even necessary, and it is working without the lock too), wine performs at 21-26 seconds. I don't think that obtaining a posix mutex should have such harsh effect on performance. Is it at all ok to try and synchronize threads created with "CreateThread" using posix constructs? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

5 7