Wine 1.3 packaged for Ubuntu, must be installed explicitly

2010-08-07 Thread Scott Ritchie
I have added a new series of Wine 1.3 packages to the Wine PPA:
https://launchpad.net/~ubuntu-wine/+archive/ppa

These are for 10.04 (Lucid) only and must be explicitly installed:

sudo apt-get install wine1.3

Users who simply install the wine or wine1.2 packages (as in, all
existing users) will instead get the stable Wine 1.2 release, which is
still packaged there.

Thanks,
Scott Ritchie




Re: user32: Don't crash for unknown button styles

2010-08-07 Thread André Hentschel
Am 06.08.2010 20:44, schrieb Nikolay Sivov:
  On 8/6/2010 22:22, André Hentschel wrote:
 got that case with an MFC application which had a 3state radiobutton
 with buttonstyle 15(decimal)
 with this fix everything is fine as the painting of the button is
 handled elsewhere, without that fix it crashes as it reads bad data
 behind the array.

 ---
   dlls/user32/button.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/dlls/user32/button.c b/dlls/user32/button.c
 index 54d54dc..4f629f0 100644
 --- a/dlls/user32/button.c
 +++ b/dlls/user32/button.c
 @@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG
 window_style )
   /* paint a button of any type */
   static inline void paint_button( HWND hwnd, LONG style, UINT action )
   {
 -if (btnPaintFunc[style]  IsWindowVisible(hwnd))
 +if (style= MAX_BTN_TYPE  btnPaintFunc[style] 
 IsWindowVisible(hwnd))
   {
   HDC hdc = GetDC( hwnd );
   btnPaintFunc[style]( hwnd, hdc, action );
 This needs a test to see what happens visually for style 0xf, maybe we
 need just to duplicate an entry in paint function table; also while
 you're at it:
 
 static inline UINT get_button_type( LONG window_style )
 {
 return (window_style  0x0f);
 }
 
 here BS_TYPEMASK should be used instead of 0xf.
 
Ok ill do. Also it was a 3state checkbox not a radiobutton. Further i
made a typo in my oneline patch :)
But i am still not sure if we really should paint in that case
(unless some peoble come up with invisible checkboxes),
because in my case the dialog style was that ms office 2007 style,
so mfc or the app handled the paint. if we would have drawn something
it would have make it worse.


-- 

Best Regards, André Hentschel




Re: [PATCH] quartz: implement AsyncReader_FindPin

2010-08-07 Thread David Adam
Hi,

what about if ppPin is NULL?
I think that this patch needs test cases to prove that it is correct?

David

2010/8/6 Anton Khirnov wys...@gmail.com

 ---
  dlls/quartz/filesource.c |   32 ++--
  1 files changed, 30 insertions(+), 2 deletions(-)

 diff --git a/dlls/quartz/filesource.c b/dlls/quartz/filesource.c
 index 110415d..00a91c8 100644
 --- a/dlls/quartz/filesource.c
 +++ b/dlls/quartz/filesource.c
 @@ -548,9 +548,37 @@ static HRESULT WINAPI AsyncReader_EnumPins(IBaseFilter
 * iface, IEnumPins **ppEn

  static HRESULT WINAPI AsyncReader_FindPin(IBaseFilter * iface, LPCWSTR Id,
 IPin **ppPin)
  {
 -FIXME((%s, %p)\n, debugstr_w(Id), ppPin);
 +IEnumPins *enumpins;
 +HRESULT hr;

 -return E_NOTIMPL;
 +hr = AsyncReader_EnumPins(iface, enumpins);
 +if (FAILED(hr))
 +return S_FALSE;
 +
 +while (hr == S_OK) {
 +IPin  *pin;
 +LPWSTR pinname;
 +
 +hr = IEnumPins_Next(enumpins, 1, pin, NULL);
 +if (FAILED(hr))
 +break;
 +
 +hr = IPin_QueryId(pin, pinname);
 +if (SUCCEEDED(hr)) {
 +if (!strcmpW(pinname, Id)) {
 +*ppPin = pin;
 +IPin_AddRef(*ppPin);
 +CoTaskMemFree(pinname);
 +break;
 +}
 +CoTaskMemFree(pinname);
 +}
 +}
 +
 +IEnumPins_Release(enumpins);
 +if (SUCCEEDED(hr))
 +return S_OK;
 +return S_FALSE;
  }

  static HRESULT WINAPI AsyncReader_QueryFilterInfo(IBaseFilter * iface,
 FILTER_INFO *pInfo)
 --
 1.7.1







Re: user32: Don't crash for unknown button styles

2010-08-07 Thread Nikolay Sivov

 On 8/7/2010 15:54, André Hentschel wrote:

Am 06.08.2010 20:44, schrieb Nikolay Sivov:

  On 8/6/2010 22:22, André Hentschel wrote:

got that case with an MFC application which had a 3state radiobutton
with buttonstyle 15(decimal)
with this fix everything is fine as the painting of the button is
handled elsewhere, without that fix it crashes as it reads bad data
behind the array.

---
   dlls/user32/button.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/dlls/user32/button.c b/dlls/user32/button.c
index 54d54dc..4f629f0 100644
--- a/dlls/user32/button.c
+++ b/dlls/user32/button.c
@@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG
window_style )
   /* paint a button of any type */
   static inline void paint_button( HWND hwnd, LONG style, UINT action )
   {
-if (btnPaintFunc[style]   IsWindowVisible(hwnd))
+if (style= MAX_BTN_TYPE   btnPaintFunc[style]
IsWindowVisible(hwnd))
   {
   HDC hdc = GetDC( hwnd );
   btnPaintFunc[style]( hwnd, hdc, action );

This needs a test to see what happens visually for style 0xf, maybe we
need just to duplicate an entry in paint function table; also while
you're at it:

static inline UINT get_button_type( LONG window_style )
{
 return (window_style  0x0f);
}

here BS_TYPEMASK should be used instead of 0xf.


Ok ill do. Also it was a 3state checkbox not a radiobutton. Further i
made a typo in my oneline patch :)
But i am still not sure if we really should paint in that case
(unless some peoble come up with invisible checkboxes),
because in my case the dialog style was that ms office 2007 style,
so mfc or the app handled the paint. if we would have drawn something
it would have make it worse.
All I mean is that you need a small test app that creates button 
directly without any mfc wrappers or anything.
Probably such style is even not accepted by control, or replaced with 
some other style.


If style is not accepted or replaced this should go directly to button 
tests, if it's accepted we need visually guess how it works and add a 
handler.





Re: user32: Don't crash for unknown button styles

2010-08-07 Thread André Hentschel
Am 07.08.2010 14:06, schrieb Nikolay Sivov:
  On 8/7/2010 15:54, André Hentschel wrote:
 Am 06.08.2010 20:44, schrieb Nikolay Sivov:
   On 8/6/2010 22:22, André Hentschel wrote:
 got that case with an MFC application which had a 3state radiobutton
 with buttonstyle 15(decimal)
 with this fix everything is fine as the painting of the button is
 handled elsewhere, without that fix it crashes as it reads bad data
 behind the array.
 This needs a test to see what happens visually for style 0xf, maybe we
 need just to duplicate an entry in paint function table; also while
 you're at it:

 static inline UINT get_button_type( LONG window_style )
 {
  return (window_style  0x0f);
 }

 here BS_TYPEMASK should be used instead of 0xf.

 Ok ill do. Also it was a 3state checkbox not a radiobutton. Further i
 made a typo in my oneline patch :)
 But i am still not sure if we really should paint in that case
 (unless some peoble come up with invisible checkboxes),
 because in my case the dialog style was that ms office 2007 style,
 so mfc or the app handled the paint. if we would have drawn something
 it would have make it worse.
 All I mean is that you need a small test app that creates button
 directly without any mfc wrappers or anything.
 Probably such style is even not accepted by control, or replaced with
 some other style.
 
 If style is not accepted or replaced this should go directly to button
 tests, if it's accepted we need visually guess how it works and add a
 handler.
Ok i see.

-- 

Best Regards, André Hentschel




Re: Configuring with -Werror

2010-08-07 Thread André Hentschel
 Configuring with -Werror used to work a while back for me; now that
 -Wno-unused-result has been fixed I gave it another try and got this:
 
 configure: libxrandr 32-bit development files not found, XRandr won't
 be supported.
 configure: WARNING: Old Mesa headers detected. Consider upgrading your
 Mesa libraries.
 OpenGL and Direct3D won't be supported.
 configure: WARNING: No sound system was found. Windows applications
 will be silent.
 
 After a quick investigation, turns out many configure checks produce
 warnings; patch below hacks around it, but I've never dealt with
 configure before and apparently fixes need to go in configure.ac --
 anyone wants to give it a proper shot?

Sorry for the noise on wine-patches, this should have been gone here...

Patch looks ok, but that should only be changed in configure.ac...
And the chance to get that in is not very high because AJ not always
suppports different compilerflags.

-- 

Best Regards, André Hentschel




Re: user32: Don't crash for unknown button styles

2010-08-07 Thread André Hentschel
Am 07.08.2010 14:06, schrieb Nikolay Sivov:
  On 8/7/2010 15:54, André Hentschel wrote:
 Am 06.08.2010 20:44, schrieb Nikolay Sivov:
   On 8/6/2010 22:22, André Hentschel wrote:
 got that case with an MFC application which had a 3state radiobutton
 with buttonstyle 15(decimal)
 with this fix everything is fine as the painting of the button is
 handled elsewhere, without that fix it crashes as it reads bad data
 behind the array.

 ---
dlls/user32/button.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/dlls/user32/button.c b/dlls/user32/button.c
 index 54d54dc..4f629f0 100644
 --- a/dlls/user32/button.c
 +++ b/dlls/user32/button.c
 @@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG
 window_style )
/* paint a button of any type */
static inline void paint_button( HWND hwnd, LONG style, UINT
 action )
{
 -if (btnPaintFunc[style]   IsWindowVisible(hwnd))
 +if (style= MAX_BTN_TYPE   btnPaintFunc[style]
 IsWindowVisible(hwnd))
{
HDC hdc = GetDC( hwnd );
btnPaintFunc[style]( hwnd, hdc, action );
 This needs a test to see what happens visually for style 0xf, maybe we
 need just to duplicate an entry in paint function table; also while
 you're at it:

 static inline UINT get_button_type( LONG window_style )
 {
  return (window_style  0x0f);
 }

 here BS_TYPEMASK should be used instead of 0xf.

 Ok ill do. Also it was a 3state checkbox not a radiobutton. Further i
 made a typo in my oneline patch :)
 But i am still not sure if we really should paint in that case
 (unless some peoble come up with invisible checkboxes),
 because in my case the dialog style was that ms office 2007 style,
 so mfc or the app handled the paint. if we would have drawn something
 it would have make it worse.
 All I mean is that you need a small test app that creates button
 directly without any mfc wrappers or anything.
 Probably such style is even not accepted by control, or replaced with
 some other style.
 
 If style is not accepted or replaced this should go directly to button
 tests, if it's accepted we need visually guess how it works and add a
 handler.
i tested it on win7_x64 and it gets invisible after some dialog interaction, 
style gets accepted and is not replaced.
So my initial patch was mostly correct.

-- 

Best Regards, André Hentschel




Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 4)

2010-08-07 Thread testbot
Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=4344

Your paranoid android.


=== W98SE (32 bit dsurface) ===
No test summary line found




Re: [PATCH 2/5] ddraw/tests: New visual back buffer flipping tests. (try 4)

2010-08-07 Thread testbot
Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=4345

Your paranoid android.


=== W2KPROSP4 (32 bit visual) ===
visual.c:2970: Test failed: IDirectDraw_CreateSurface returned: 80070057
visual.c:2986: Test failed: IDirectDraw_CreateSurface returned: 88760091




Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 4)

2010-08-07 Thread testbot
Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=4348

Your paranoid android.


=== W2KPROSP4 (32 bit visual) ===
visual.c:2970: Test failed: IDirectDraw_CreateSurface returned: 80070057
visual.c:2986: Test failed: IDirectDraw_CreateSurface returned: 88760091

=== W98SE (32 bit dsurface) ===
No test summary line found




Re: Should we expect Liberation fonts to be installed?

2010-08-07 Thread Scott Ritchie
On 08/03/2010 01:57 PM, Scott Ritchie wrote:
 I was looking through our fairly large collection of open font bugs and
 realized that things might be a lot simpler if we took some opinionated
 positions and just declared certain fonts to be dependencies and
 expected all packagers to provide them.
 
 This is similar to bundling our own Tahoma, except much less work.
 
 
 This bug, for instance, prevents Photoshop from working unless there is
 an Arial font installed: http://bugs.winehq.org/show_bug.cgi?id=9623
 
 Wine doesn't seem to respect system-level fontconfig aliases, so even
 though Liberation Sans is installed on the system Photoshop won't try to
 use it in place of Arial.
 
 But if however we assumed that Liberation Sans was installed, we could
 make things much better: a link/substitution for Arial-Liberation Sans
 could be provided in our own registry (and similarly for Times New Roman
 and Courier).  An alternative is to simply symlink to the Liberation
 Fonts in /usr/share/wine/fonts as though they were our own shipped fonts
 (like Tahoma).
 
 This would make Photoshop think Arial was present and keep it
 functional.  Ideally the real Arial would be displayed if it was
 installed (eg through winetricks corefonts or by installing the
 distro-provided corefonts package).
 
 
 A related question is whether to show Arial in the list of fonts (eg
 notepad) when we're actually just providing a substituted Arial.  My
 inclination says no, however I'm not sure how it works internally and
 what an application would expect.
 

Assuming for a moment this is a good idea, what's the best
implementation?  My inclination is to say some registry font links, but
I'm not completely familiar with how that works.

Will font links in the registry be ignored when the real font is present?

Thanks,
Scott Ritchie




Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5)

2010-08-07 Thread testbot
Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=4352

Your paranoid android.


=== W98SE (32 bit dsurface) ===
No test summary line found




Re: gdi32: use usp10 to optionally generate glyphs for bidi strings

2010-08-07 Thread Shachar Shemesh

Alexandre Julliard wrote:

Which of course demonstrates that gdi32 calls usp10 on native too. Maybe
it does it indirectly through lpk.dll, but the end result is the same,
you have a dependency on usp10.

  
I know I'm coming a bit late into the discussion, but just for the 
record, this is how Windows does it (as of Windows 2000):


   * GDI has a soft dependency on LPK.DLL. It tries to load it using
 LoadLibrary.
   * If it succeeds, and if there are no breakout flags, each call to
 ExtTextOut is redirected to the LPK version of that same call
   * LPK links with uniscribe for the actual BiDi processing, and also
 with GDI for the actual rendering of the result. Yes, this means a
 circular dependency.
   * The breakout flags are ETO_IGNORELANGUAGE and ETO_GLYPH_INDEX. If
 these are passed, GDI handles the request itself, without
 forwarding it to LPK. This prevents the infinite recursion that
 might, otherwise, happen.

I believe the reason for this twisted design is twofold. First, in 
Windows 2000, CTL (complex text layout) was an optional component, to be 
installed by a checkbox in the regional settings dialog. This meant that 
the entire LPK dll could just be dropped in, along with some fonts, and 
the system would start supporting BiDi. The second reason is because 
BiDi is a rather multi-layered process. With BiDi, support for multi 
line rendering (as done by DrawText in User32) requires some fairly 
complex processing before the text could be passed off to ExtTextOut for 
actual rendering. This way, all the BiDi code could be placed in one place.


Another reason, I believe, for this separation is that pre-Windows 2000 
(and more importantly, pre-uniscribe) Windows still had BiDi code, which 
was scattered all over the place, and which became obsolete (for one 
example - GetCharacterPlacement, which supposedly does BiDi, has no 
mechanism to choose the paragraph direction, without which no BiDi 
processing makes sense. The MSDN docs even explicitly state it is obsolete).


I believe the best route forward is to use an LPK *like* DLL. Not LPK 
itself, as that would require of us to reverse engineer a whole set of 
APIs that no one but us even call, but another DLL, injected into the 
dependency order at the same location, carrying a similar functionality. 
I would suggest winelpk.dll as the name, but that is, of course, 
entirely open.


Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com




Re: Right-To-Left (RTL) languages and Wine

2010-08-07 Thread Shachar Shemesh

Paul Vriens wrote:

Hi,

I've been in talks with a Hebrew translator for some time now and I'd 
like to have Wine being able to start doing more RTL stuff.


I'm looking for example at http://bugs.winehq.org/show_bug.cgi?id=1158

If I run an English winmine.exe on an Arabic box (thanks to the 
testbot) the main window will shows as normal LTR window layout with 
the menu's left justified as well.


So eventhough the locale is set to Arabic it doesn't turn 'everything' 
into RTL.


If we don't change the resource files for the RTL languages, that same 
logic will give us LTR Wine applications or am I wrong here?


An English app running on a Hebrew Windows does not automatically get 
entirely reversed. There are two parts to this question, and I believe 
that Wine should handle those parts differently.


One part are the Windows decorations - close button, minimize, maximize, 
etc. Under Windows, if an application is reversed, so are these. I 
believe Wine should not attempt to replicate this behavior for the 
following reasons:


   * It is a broken design decision. Its implications are that on the
 same desktop, some windows have their close button on the left,
 others on the right. In my experience, this does nothing to
 enhance the user's experience.
   * It is difficult to implement. The decorations on Wine windows are
 drawn by the X window manager. We would have to convince each
 window manager to reverse the window decorations on our say so. I
 am not aware of such an API existing, which means lots and lots
 and lots of bugs.
   * As an aggregate of the above two - the window decorations are,
 today, not defined by Wine to be part of the windows experience,
 and as such, if the Windows behavior is broken, we need not
 replicate it.

The other part is the actual content of the window. Here there is a need 
to support exactly what Windows is doing, as that is the API. As a side 
note, I'll add that I think that is broken too. Mirroring should not be 
done automatically, and reading the MSDN article that Dmitry references 
just shows how many ways it can, indeed, break. That said, Wine did 
commit to being bug-compatible with Windows, so that part should, 
*eventually*, be implemented.


I do agree with Alexandre that there are many things more pressing on 
the BiDi front to handle.


Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com