Re: [PATCH 4/5] ddraw/tests: Port the depth blit test to ddraw2

2012-01-29 Thread Stefan Dösinger
Am Montag, 23. Januar 2012, 13:48:03 schrieb Henri Verbeet:
> It probably makes sense to just skip this call and add a todo_wine for
> the failing tests. Also, if all that's needed for this is setting
> WINED3D_RS_LIGHTING in IDirect3DDeviceImpl_2_DrawPrimitive(), I think
> that should be ok to go in before 1.4.
I've sent the patch with todo_wine for now. A proper fix might be as simple as 
a SetRenderState call in the device2::draw* thunks, but I don't feel 
comfortable about it without some tests. I'm not sure if I'll have the time 
for that.

Someone(Octavian? I lost the IRC logs) was working on a lot of tests for this. 
Maybe he wants to resume his work.


signature.asc
Description: This is a digitally signed message part.



Re: dinput: Support INFINITE as number of effect iterations (try 2)

2012-01-29 Thread Marcel Hasler
2012/1/29 Vitaliy Margolen :
> On 01/28/2012 05:56 PM, Marcel Hasler wrote:
>>
>> According to the DirectX reference, IDirectInputEffect::Start accepts
>> INFINITE (aka -1) for the number of iterations. However, passing -1 to
>> Linux via input_event results in no effect being played at all. This
>> patch sets the number of iterations to the maximum signed value
>> allowed if INFINITE is passed.
>>
>> This fixes bug 29712.
>>
>> This patch supersedes patch 83233. It does the same thing but adds a
>> comment and should be easier to understand.
>
>
> In general looks good. Would be nice to point out that linux/input.h says
> that any durations should not exceed 0x7fff as a maximum value.
>
> Please don't make code "easier to read" by adding needless if / else. Your
> first patch was fine.
>
> Vitaliy.

Thanks for your feedback.

I just had another look at linux/input.h and realized I made a
mistake. The member 'value' is actually declared __s32, so it really
should be 0x7fff. Is there any predefined constant that could be
used for this, rather than using a literal? This is what the code
looks like at the moment:

/* Linux doesn't accept INFINITE, use the maximum __s32 value instead */
event.value = (dwIterations == INFINITE) ? 0x7fff : dwIterations;

The limit 0x7fff mentioned in input.h doesn't concern the number of
iterations, just durations. I couldn't find anything on an upper limit
for 'value'. I've tested 0x7fff and it works just fine.

Marcel




Re: user32: Only call SetWindowPos() in UpdateLayeredWindowIndirect() if needed. (try 2)

2012-01-29 Thread Dmitry Timoshkov
Adam Martinson  wrote:

> Fixes bug 26924.

Please add the tests.

-- 
Dmitry.




Re: kernel32: Add LCMapStringEx implementation and test it reusing tests from LCMapStringW

2012-01-29 Thread Dmitry Timoshkov
André Hentschel  wrote:

> +/* Locale name special values */
> +#define LOCALE_NAME_INVARIANT   L""
> +#define LOCALE_NAME_MAX_LENGTH  85
> +#define LOCALE_NAME_SYSTEM_DEFAULT  L"!sys-default-locale"
> +#define LOCALE_NAME_USER_DEFAULTNULL

Have a look how unicode constants are defined in other header files,
the above version can't work in Wine.

Also just duplicating LCMapString tests is not a very good idea, it would be
better to find a way to share the test data.

-- 
Dmitry.




Re: Best way to overlay a filesystem for a Wine app?

2012-01-29 Thread Dan Kegel
On Sun, Jan 29, 2012 at 3:58 PM, Scott Ritchie  wrote:
>> - rely on the system's update manager to pull updated versions of the
>> package from the repository
>
> This may not be a fast-enough option for some apps, such as online games
> that need to keep everyone in version sync.  Even in an ideal case where
> the company was 100% behind the Ubuntu package and kept it in sync with
> their release process, there is still no current way for the Windows app
> to tell Apt to update its package.

In those cases, you would make the files updated by the game's launcher
be read/write instead of read only symlinks.

> wouldn't a
> unionfs-fuse overlay be simpler and cleaner than this since you wouldn't
> have to worry about the app-specific stuff at all?

Yes.  My experiences were in the context of making a single portable
(in the old sense of the word) binary to run on all sorts of distros,
even old ones with no union filesystem support at all, so we had to
use symlinks.
And my impression is that filesystem unions aren't quite ready for
prime time.  LWN has had a lot of articles about that (most recently last June?
http://lwn.net/Articles/447650/ )  But perhaps you are only targeting the
most recent Ubuntu, and have found that it includes a usable union
mount of some sort.

When I try to script things that use fuse filesystems, I seem to need to
add mystery "sleep 1" statements after issuing mount commands, which
isn't exactly trust-inspiring.  But maybe some other part of the system
I was using was causing the delay.

>> (Picasa also went further and bundled a snapshot of wine, too, and
>> modified the app slightly to display unix paths, which required adding
>> one little extension to wine.  I'm sure the wine patch is around if
>> someone wants it.
>
> This patch would be interesting if you could dig it up.

I don't see it standalone anywhere, but the source tarball used is linked
to from http://code.google.com/opensource/wine.html, and the extension
was probably kernel32.wine_get_unix_real_name().

> I don't know if
> Alexandre would accept it, but ideally it would be part of Wine and
> turned on via an environment variable or command line switch.

I doubt he would accept it.  (Heck, he probably wrote it.)
- Dan




Re: Best way to overlay a filesystem for a Wine app?

2012-01-29 Thread Scott Ritchie
On 01/29/2012 02:38 PM, Dan Kegel wrote:
> Hi Scott,
> I agree with what Vrit said.
> 
> Here's what I recall learning from helping package Picasa:
> - don't package the installer

Right, run the installer and use the contents of the result as the
packaged files.

> - rely on the system's update manager to pull updated versions of the
> package from the repository

This may not be a fast-enough option for some apps, such as online games
that need to keep everyone in version sync.  Even in an ideal case where
the company was 100% behind the Ubuntu package and kept it in sync with
their release process, there is still no current way for the Windows app
to tell Apt to update its package.

> - install everything read-only into /opt/companyname/appname
> - start the app using a shell script that creates a wineprefix on 1st run
> - The wineprefix should have real directories (so the app can create
> files in Program Files, ugh), should symlink to all the readonly files
> in /opt, and have real copies of any files that can't be read-only
> As Vrit said, the script that creates the wineprefix is very
> app-specific, but once you write one, it's probably easy to write the
> next one.

Perhaps I'm speaking from inexperience with either, but wouldn't a
unionfs-fuse overlay be simpler and cleaner than this since you wouldn't
have to worry about the app-specific stuff at all?

> - If you are running your own repo, you should put exactly one app per
> repo.  Otherwise you run into trouble because Canonical would want to
> review all the apps in the repo every time you update any one of them.
> 

This is already how apps work in the App Store - commercial apps get
their own repos, if they require payment then it's a private launchpad
PPA, and the user gets a unique access key when they buy it.

> So no overlay filesystem needed, symlinks should usually suffice.
> 
> (Picasa also went further and bundled a snapshot of wine, too, and
> modified the app slightly to display unix paths, which required adding
> one little extension to wine.  I'm sure the wine patch is around if
> someone wants it.  And since it was in a non-ubuntu repo, it had to do
> a strange song and dance to avoid autoupdates being disabled when the
> user upgraded to a new version of ubuntu.  This was considered safe
> because picasa was fairly well self-contained and maintained, and was
> unlikely to break on system updates.)

This patch would be interesting if you could dig it up.  I don't know if
Alexandre would accept it, but ideally it would be part of Wine and
turned on via an environment variable or command line switch.

> 
> In case you want to look at picasa's scripts, the download page seems
> to be gone, but the repo seems to still be there:
> 
> http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_i386.deb
> http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_amd64.deb
> 4ecf30186ce76430a7791cee2608f47e07b015e6  picasa_3.0-current_amd64.deb
> fe8e83b29a10b5d663e87861d85512faea036c06  picasa_3.0-current_i386.deb
> 
> Still installs and runs ok on 11.10.

Thanks!

Thanks,
Scott Ritchie




Re: patch msvcrt.dll file.c MSVCRT_tmpfile() open_flags --> stream_flags

2012-01-29 Thread Vitaliy Margolen

On 01/29/2012 07:25 AM, fred wrote:

Hi Wine-Team

A old bugfix on my system



You need to fix at least these issues with your e-mail:
- One e-mail per patch.
- All patches needs to be submitted using git format-patch..
- You have to specify your full name in From: address

For more details see: http://wiki.winehq.org/SubmittingPatches

Vitaliy.




Re: dinput: Support INFINITE as number of effect iterations (try 2)

2012-01-29 Thread Vitaliy Margolen

On 01/28/2012 05:56 PM, Marcel Hasler wrote:

According to the DirectX reference, IDirectInputEffect::Start accepts
INFINITE (aka -1) for the number of iterations. However, passing -1 to
Linux via input_event results in no effect being played at all. This
patch sets the number of iterations to the maximum signed value
allowed if INFINITE is passed.

This fixes bug 29712.

This patch supersedes patch 83233. It does the same thing but adds a
comment and should be easier to understand.


In general looks good. Would be nice to point out that linux/input.h says 
that any durations should not exceed 0x7fff as a maximum value.


Please don't make code "easier to read" by adding needless if / else. Your 
first patch was fine.


Vitaliy.




re: Best way to overlay a filesystem for a Wine app?

2012-01-29 Thread Dan Kegel
Hi Scott,
I agree with what Vrit said.

Here's what I recall learning from helping package Picasa:
- don't package the installer
- rely on the system's update manager to pull updated versions of the
package from the repository
- install everything read-only into /opt/companyname/appname
- start the app using a shell script that creates a wineprefix on 1st run
- The wineprefix should have real directories (so the app can create
files in Program Files, ugh), should symlink to all the readonly files
in /opt, and have real copies of any files that can't be read-only
As Vrit said, the script that creates the wineprefix is very
app-specific, but once you write one, it's probably easy to write the
next one.
- If you are running your own repo, you should put exactly one app per
repo.  Otherwise you run into trouble because Canonical would want to
review all the apps in the repo every time you update any one of them.

So no overlay filesystem needed, symlinks should usually suffice.

(Picasa also went further and bundled a snapshot of wine, too, and
modified the app slightly to display unix paths, which required adding
one little extension to wine.  I'm sure the wine patch is around if
someone wants it.  And since it was in a non-ubuntu repo, it had to do
a strange song and dance to avoid autoupdates being disabled when the
user upgraded to a new version of ubuntu.  This was considered safe
because picasa was fairly well self-contained and maintained, and was
unlikely to break on system updates.)

In case you want to look at picasa's scripts, the download page seems
to be gone, but the repo seems to still be there:

http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_i386.deb
http://dl.google.com/linux/deb/pool/non-free/p/picasa/picasa_3.0-current_amd64.deb
4ecf30186ce76430a7791cee2608f47e07b015e6  picasa_3.0-current_amd64.deb
fe8e83b29a10b5d663e87861d85512faea036c06  picasa_3.0-current_i386.deb

Still installs and runs ok on 11.10.




Re: [po]updated korean resource(2012-1-28)

2012-01-29 Thread Frédéric Delanoy
2012/1/28 Hwang YunSong(황윤성) 

>
> fuzzy sections tranlated
>
>   http://www.dreamwiz.com/
>
> 
>
>
You should send your patch in plain text format (as all mails to wine-devel
/ wine-patches).
Also, you shouldn't specify a date in the patch subject line (Change
PO-Revision-Date in the po file instead for instance)
so "[po]updated korean resource(2012-1-28)" should be sthg like "po: Update
Korean translation" to conform to naming conventions (see
http://wiki.winehq.org/SubmittingPatches).

Frédéric



Re: HRBlock error. Sure would like to do my taxes on Linux using Wine.

2012-01-29 Thread Matijn Woudt
On Sat, Jan 28, 2012 at 2:12 AM, Ken Stephens  wrote:
>
> I get the following error when trying to load HRBlock software:
>
>
>
> [kens@atlas HRBlock2011]$ wine tcauto.exe
> err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make 
> sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in 
> the winbind package of your distribution.

Have you even looked at your output log? It seems that this might be
the problem.
Other than that, this list is for Wine development, not for any bugs.
Try bugzilla for that [1].

- Matijn

[1] http://bugs.winehq.org




Re: HRBlock error. Sure would like to do my taxes on Linux using Wine.

2012-01-29 Thread L. Rahyen
Please do not post messages like that to wine-devel. Post it to 
wine-users 
mailing list instead.




Re: HRBlock error. Sure would like to do my taxes on Linux using Wine.

2012-01-29 Thread Nikolay Sivov

On 1/28/2012 04:12, Ken Stephens wrote:

I get the following error when trying to load HRBlock software:

This is a developers list, please use bugs.winehq.org to report problems.




HRBlock error. Sure would like to do my taxes on Linux using Wine.

2012-01-29 Thread Ken Stephens

  
  
I get the following error when trying to load HRBlock software:




[kens@atlas HRBlock2011]$ wine tcauto.exe 
err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is
outdated. Make sure that ntlm_auth >= 3.0.25 is in your path.
Usually, you can find it in the winbind package of your
distribution.
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 32
channels, pretending there's only 2 channels
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 1
channels, pretending there's only 2 channels
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 1
channels, pretending there's only 2 channels
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 1
channels, pretending there's only 2 channels
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 1
channels, pretending there's only 2 channels
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 32
channels, pretending there's only 2 channels
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 1
channels, pretending there's only 2 channels
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 1
channels, pretending there's only 2 channels
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 1
channels, pretending there's only 2 channels
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 1
channels, pretending there's only 2 channels
fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 1
channels, pretending there's only 2 channels
err:ole:CoGetClassObject class
{96749377-3391-11d2-9ee3-00c04f797396} not registered
err:ole:CoGetClassObject class
{96749377-3391-11d2-9ee3-00c04f797396} not registered
err:ole:create_server class {96749377-3391-11d2-9ee3-00c04f797396}
not registered
fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported
err:ole:CoGetClassObject no class object
{96749377-3391-11d2-9ee3-00c04f797396} could be created for context
0x17
fixme:win:EnumDisplayDevicesW ((null),0,0x32f70c,0x), stub!
fixme:wininet:CommitUrlCacheEntryInternal entry already in cache -
don't know what to do!
fixme:urlmon:InternetBindInfo_GetBindString not supported string
type 12
fixme:wininet:CommitUrlCacheEntryInternal entry already in cache -
don't know what to do!
fixme:wininet:CommitUrlCacheEntryInternal entry already in cache -
don't know what to do!
fixme:wininet:CommitUrlCacheEntryInternal entry already in cache -
don't know what to do!
fixme:wininet:CommitUrlCacheEntryInternal entry already in cache -
don't know what to do!
fixme:wininet:InternetLockRequestFile STUB
fixme:wininet:CommitUrlCacheEntryInternal entry already in cache -
don't know what to do!
Application tried to create a window, but no driver could be loaded.
Unknown error (0).
[kens@atlas HRBlock2011]$ err:ntdll:RtlDeleteResource Deleting
active MRSW lock (0x111bf4), expect failure
err:ntdll:RtlDeleteResource Deleting active MRSW lock (0x1124fc),
expect failure

[kens@atlas HRBlock2011]$ 

-- 
  Ken Stephens, SV Aventura, Portland, OR
  




Re: kernel32: add a stub for LCMapStringEx (try 2)

2012-01-29 Thread Vitaliy Margolen

On 01/29/2012 10:54 AM, Dmitry Timoshkov wrote:

Austin English  wrote:


Forgot the include changes.


Forwarding it to LCMapString would be much better.



Also could we please stop adding stubs before the release? It seems every 
new stub dll opens up another can of worms (or should I say bugs). If we 
looking to stabilize Wine it's sure is the wrong way to do it.


- Vitaliy




Re: kernel32: add a stub for LCMapStringEx (try 2)

2012-01-29 Thread Dmitry Timoshkov
Austin English  wrote:

> Forgot the include changes.

Forwarding it to LCMapString would be much better.

-- 
Dmitry.