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 …
[View More]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
__________________________
[View Less]
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 …
[View More]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
[View Less]
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, …
[View More]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.
[View Less]
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 …
[View More]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!
[View Less]
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 …
[View More]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/
[View Less]
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 …
[View More]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
[View Less]
-------- 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 …
[View More]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
[View Less]