wine-devel July 2013

wine-devel@winehq.org

63 participants
129 discussions

Bug 24018 which appears to be a showstopper for running Cygwin on Wine
by Alan W. Irwin 05 Jul '13

05 Jul '13

Andrey Turkin has stated at http://bugs.winehq.org/show_bug.cgi?id=24018 that this is really a Cygwin bug. I frankly don't understand the technical details but his current test (an infinite loop with Cygwin fork calls) may need some beefing up to convince the Cygwin developers they have introduced a regression. The reason why I mention a Cygwin regression is the winetricks script mentions bug 24018 and works around it by downloading an old version of the Cygwin installer. I haven't tried that myself yet, but if that workaround still works, then this is evidence that the issue is a Cygwin regression which is an important consideration when reporting this issue to the Cygwin developers. Andrey Turkin was asked at http://bugs.winehq.org/show_bug.cgi?id=24018 to report the issue to Cygwin, but my search of the Cygwin mailing list archive didn't find any post from him and only found one extremely casual (an aside to a completely different thread) mention (http://sourceware.org/ml/cygwin/2013-06/msg00471.html) from a different wine developer of bug 24018 with no response to that mention. I currently have no experience with Cygwin and my only real interest in Cygwin on Wine is it theoretically provides an alternative build platform to my present successful work with the combination of MinGW, MSYS, and Wine as a Windows build platform. But I haven't even been able to get started with Cygwin on Wine because of this showstopping bug. Therefore, I am mentioning the situation here in the hope that some wine developer on this list with some knowledge of Cygwin will take the responsibility of making a proper bug report to the Cygwin mailing list (which according to http://cygwin.com/problems.html is the correct place to report Cygwin bugs) including the evidence that the issue is a Cygwin regression (assuming investigation of older Cygwin versions with Turkin's test supports that conclusion). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________

7 26

Re: po: Update Simplified Chinese translation. (newer)
by Qian Hong 05 Jul '13

05 Jul '13

Hi Andrew, While discussing the translation of 'Voice output device' and 'Voice input device' in winecfg, Jactry and I have no idea what does 'voice' mean here. Voice could be translated to both '声音‘ and '语音' in Chinese, the former means all kinds of sound, the latter means human voice only, which one is more accurate? I know you've subscribed wine-devel, I CC'ed you because you are the original contributor to the 'voice input device' related code. Thanks a lot! On Fri, Jul 5, 2013 at 9:53 PM, Jactry Zeng <jactry92(a)gmail.com> wrote: > Please ignore the first patch, I modify some in this one. > Thanks advice from Qian Hong. > > > -- Regards, Qian Hong - http://www.winehq.org

3 3

Re: [PATCH] windowscodecs/tests: Fix a test failure [newwtb and other]
by Dmitry Timoshkov 05 Jul '13

05 Jul '13

Detlef Riekenberg <wine.dev(a)web.de> wrote: > - /* global palette */ > + /* global palette. This succeed since win7sp1 with platform update / win8 */ This comment is not helpful. > hr = IWICBitmapDecoder_CopyPalette(decoder, palette); > - ok(hr == WINCODEC_ERR_FRAMEMISSING, > - "expected WINCODEC_ERR_FRAMEMISSING, got %#x\n", hr); > + ok((hr == S_OK) || (hr == WINCODEC_ERR_FRAMEMISSING), > + "expected S_OK or WINCODEC_ERR_FRAMEMISSING, got %#x\n", hr); One of test results should be marked as broken, and in the S_OK case the resulting palette should be tested and released. I'd guess that newer version should be taken as a model to follow, and Wine implementation should be fixed appropriately. -- Dmitry.

1 0

po: Revert Japanese shell path name updates.
by Akihiro Sagawa 04 Jul '13

04 Jul '13

Could you revert recent Japanese translation updates[1] or commit attached patch? As I mention in the last mail[2], patch 91758[3] has some issues, especially when retrieving shell path names. Although path names are not localized in Japanese Windows Vista (and its successors), they are (mistakenly?) included in the last commit. To prove this, I submitted a job to winetestbot [4]. However, new winetestbot seems to be stuck. Alternatively, I attach my Japanese Windows 7 result. The line which begins shellpath.c:443 is my additional output. You can see that all path names are not translated. [1] http://source.winehq.org/git/wine.git/commit/0fb9de61a5026ac6cf16bc3385c382… [2] http://www.winehq.org/pipermail/wine-devel/2013-June/100377.html [3] http://source.winehq.org/patches/data/97158 [4] https://newtestbot.winehq.org/JobDetails.pl?Key=1432 --- po/ja.po | 63 +++++++++++++++++++++++++++++++------------------------------- 1 file changed, 31 insertions(+), 32 deletions(-)

3 3

RFC: Three dots or Unicode ellipsis character
by Francois Gouget 04 Jul '13

04 Jul '13

Wine uses three dots (...) rather than the Unicode ellipsis character (…) except in the Czech and Taiwanese translations that use the Unicode ellipsis character. I think we should be consistent but the question is which to use. I looked at the Windows interface guidelines and they don't have anything to say on this. http://msdn.microsoft.com/en-us/library/windows/desktop/aa974176.aspx#punct… http://msdn.microsoft.com/en-us/library/windows/desktop/aa511453.aspx#ellip… Looking at what other platforms do, the Apple interface guidelines recommend using the Unicode ellipsis character saying assistive technologies need it. The GNOME and KDE guidelines don't have an official position but seem to use the Unicode character anyway: http://simos.info/blog/archives/17 So should we go with the flow and switch to using ellipsis characters or should we stick with three dots? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 145 = 1! + 4! + 5!

3 3

Possible help or direction to build Win to Linux pass through device - resent
by Pavel Pisa 04 Jul '13

04 Jul '13

Hello all Wine developers, [the second attempt to send, is the list subscribers only?] the firs I would like to express my respect to the work done. Now to one of our application, we maintain open-source chromatographic software CHROMuLAN https://sourceforge.net/projects/chromulan/ Unfortunately, it is written in Delphi (version 6 used) and we have not resources to port it to run native on Linux even that Linux is for last 18 years our main development platform for embedded hardware design and development. Our long term is to port application to Lazarus/FPC or even rewrite in in Qt but that is not option now. Fortunately, the CHROMuLAN application runs quite well under latest Wine version. But we have problem with access to the data acquisition hardware. The devices are connected to computer through special protocol (uLAN) RS-485 network. We have drivers for Linux (the firs platform), Windows (even 64-bit tested) and other targets. All for PCI, RS-232/485 converters and PCI RS-485 addon cards. Whole stack even runs under ReactOS in QEMU now. But Wine is more pleasant solution when someone uses Linux as his/her main desktop system. https://sourceforge.net/projects/ulan/ Problem is that I loke to provide driver API to the Wine application. The real windows driver is KMD/WMD "ul_wdm.sys" which is registered as "\\\\.\\UL_DRV" by IoCreateDevice and IoCreateSymbolicLink. Driver provides some context per each open and then read, write and iocts are used. We have exactly the same drive for Linux (x86, 64-bit, MIPS, ARM, PowerPC) with same functionality but Linux IOCTLs numbers are built different way and there are some slight differences caused by differences in Win API IOCTLs processing and Windows does not support poll equivalent for devices too. I have studied Wine and wineserver more times and have not found how to achieve provision of the Linux driver to the Wine application. Or more or less found that there would be problem because wineserver seems to deliver only IOCTLs events. But I was not sure so I have finally proven that by trial. I have written DLL/SYS as a driver supporting all required IRP_MJ_xxx and IOCTLs in the style of KMD/WMD driver and implemented functions as calling to the Linux "/dev/ulan" operation equivalents. But it really does not work. Only IOCTLs are delivered to the ul_drv.sys and even that fails because open context is not setup. Pointer irpStack->FileObject is filled with 0x66666666. You can find my attempt at http://cmp.felk.cvut.cz/~pisa/ulan/wine/ Now to the questions, Is there some mechanism in Wine which I could use? Is there chance to do that as little intrusive (i.e. DLL) that it can be acceptable for Wine mainline? It seems that serial port device somehow solves similar problem but is seems to be hardwired to wineserv. As for my case, it is possible that read and write to the open /dev/ulan file are done directly from context of application if it receives Linux filehandle into wine/dlls/ntdll/file.c . If the new FD_TYPE_ (FD_TYPE_SERIAL) is defined then all processing can be done in Linux native NTDLL. Even IOCTLs translation because they are really straightforward (like wine-git/dlls/ntdll/serial.c does in COMM_DeviceIoControl). But such solution seems intrusive to me. On the other hand the structure struct object_ops in wine/wine/server/object.h seems to provide all operations. Can I use some registration in the server to solve access? I am missing something? Is there some suggestion which approach to take? Some reasonable simple solution is preferred because if projects takes too much time it would even more postpone possibility to start real application porting. Thanks for each possible advice, Pavel -- Pavel Pisa e-mail: pisa(a)cmp.felk.cvut.cz www: http://cmp.felk.cvut.cz/~pisa university: http://dce.fel.cvut.cz/ company: http://www.pikron.com/

3 5

Re: kernel/tests: Test behaviour of TPIDRURW register with threads on ARMv7
by Dmitry Timoshkov 04 Jul '13

04 Jul '13

André Hentschel <nerv(a)dawncrow.de> wrote: > +#if defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) || defined(__ARM_ARCH_7R__) > +static inline void set_tpidrurw(DWORD tpidrurw) > +{ > + __asm__ volatile ("mcr p15, 0, %0, c13, c0, 2" : : "r" (tpidrurw)); > +} > + > +static inline DWORD get_tpidrurw(void) > +{ > + DWORD tpidrurw = 0; > + __asm__ volatile ("mrc p15, 0, %0, c13, c0, 2" : "=r" (tpidrurw)); > + return tpidrurw; > +} This code is gcc specific and for instance won't compile with PSDK compiler. It either needs to be protected or replaced with hex/binary form. -- Dmitry.

1 0

Re: msxml3/tests: Add additional conformance tests to the xpath tests (try 2)
by Alexandre Julliard 03 Jul '13

03 Jul '13

John Chadwick <johnwchadwick(a)gmail.com> writes: > This patch adds additional xpath tests to the msxml3 tests. Following > Nikolay Sivov's advice, these provide a wide range of new tests, two > of which currently fail in Wine (for reasons previously described.) > These are now marked 'todo' in a much cleaner way. It doesn't work here: ../../../tools/runtest -q -P wine -M msxml3.dll -T ../../.. -p msxml3_test.exe.so domdoc.c && touch domdoc.ok domdoc.c:4468: Test succeeded inside todo block: query=ancestor-or-self::node(), invalid node list: D1 E2.D1, expected D1 E2.D1 domdoc.c:4468: Test succeeded inside todo block: query=(//a[1])[last()], invalid node list: E1.E4.E2.D1, expected E1.E4.E2.D1 make: *** [domdoc.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Fwd: Re: RFC: Three dots or Unicode ellipsis character
by Michael Stefaniuc 03 Jul '13

03 Jul '13

-------- Original Message -------- Subject: Re: RFC: Three dots or Unicode ellipsis character Date: Wed, 03 Jul 2013 19:32:15 +0200 From: Michael Stefaniuc <mstefani(a)redhat.com> To: Francois Gouget <fgouget(a)free.fr> On 07/03/2013 04:45 PM, Francois Gouget wrote: > > Wine uses three dots (...) rather than the Unicode ellipsis character > (…) except in the Czech and Taiwanese translations that use the Unicode > ellipsis character. > > I think we should be consistent but the question is which to use. > > > I looked at the Windows interface guidelines and they don't have > anything to say on this. > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa974176.aspx#punct… > http://msdn.microsoft.com/en-us/library/windows/desktop/aa511453.aspx#ellip… > > Looking at what other platforms do, the Apple interface guidelines > recommend using the Unicode ellipsis character saying assistive > technologies need it. The GNOME and KDE guidelines don't have an > official position but seem to use the Unicode character anyway: > > http://simos.info/blog/archives/17 > > > So should we go with the flow and switch to using ellipsis characters or > should we stick with three dots? How will the substitution work in the W2A case? bye michael

1 0

Windows RT Applications finally can run in Wine/ARM with upcoming Linux releases
by André Hentschel 03 Jul '13

03 Jul '13

Hi, Wanted to let you know that the patch that allows that just got committed in Linus tree: [1] This means that Kernel 3.11 will have everything to run applications ported to Windows RT. A good list of such applications and libraries can be found at [2]. See [3] & [4] for more information on the Wine side. [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a… [2] http://forum.xda-developers.com/showthread.php?p=36534446 [3] http://bugs.winehq.org/show_bug.cgi?id=31322 [4] http://bugs.winehq.org/show_bug.cgi?id=31308

1 0

Jump to page:

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 July 2013