Windows 7 changed the folders in c:/users/$USERNAME around a bit.
My Documents is now just a link to the new folder Documents
Application Data is now just a link to the new folder AppData/Roaming
Local Settings is now just a link to the new folder AppData/Local
How is this going to affect Wine? Well-behaved apps that use
CSIDL_PERSONAL to get at "My Documents" or "Documents" will
work regardless, but users or badly behaved apps might start expecting
the shorter directory names sometime. (I always hated the spaces, anyway.)
On 04/22/2011 02:06 PM, EG Galano wrote:
> This fixes jittery mouse movement in Combat Arms. This was introduced
> in commit 79c2e55b5a6331d15788f65a929e9e002c2f8b05
>
> This is likely the same issue discussed here but I don't have a copy
> to test: http://forum.winehq.org/viewtopic.php?t=11759&sid=9d9518057d4c0ef51be8c37d9…
> - if (ret && (prev_x != new_x || prev_y != new_y)) USER_Driver->pSetCursorPos( new_x, new_y );
> + if (ret && (prev_x != new_x && prev_y != new_y)) USER_Driver->pSetCursorPos( new_x, new_y );
Obviously this is wrong. Something else is at fault here.
Vitaliy.
Hi,
In various languages, there are multiple forms/agreements for a
pronoun/adjective. In French, for instance masculine and feminine
forms exist; in other languages (like German IIRC) there's even a
neutral form (other languages may also be more complicated)
while agreements in English are limited, e.g. there's only one form
for masculine/feminine/plural adjectives.
This makes translating short English words problematic.
In my case, I've a problem with the following PO entry
#: comctl32.rc:44 crypt32.rc:198 progman.rc:78 winecfg.rc:76
msgid "None"
According to context, it can be translated (in French) as either
"Aucun" or "Aucune" (agreements on the same word).
Admitedly, it could be translated with "Aucun(e)" but that seems more
like a workaround and feels a bit weird (user shouldn't see partially
incorrect/odd translations because of technical issues)
OTOH, creating a distinct msgcontext for every agreement in every
supported language may be overkill, although the number of affected
msgids is limited.
What's your opinion on how to handle that, folks?
Frédéric Delanoy
NB: This obviously posed no problem before the rc->po migration, since
it was duplicated in different rc files
On 22 April 2011 13:17, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
> + scale = 0;
I thought you cared about the warnings MSVC generates for this kind of thing. :)
Hi guys,
I'd like to instrument wined3d in order to get to the bottom of the two
issues with StarCraft II:
- low FPS when we don't set affinity of all threads on one core
- low FPS when shader level is > MEDIUM
Which kind of function should I instrument?
I've instrumented all the non static in 'context.c', 'buffer.c' and
'device.c', but I guess that I should instrument all the static function
IWineD3DDeviceImpl_* in 'device.c', right?
What kind of functions should I instrument?
Cheers,
Ema
Hi,
I want to try to create some tests for rasapi32.dll.
May I just create some tests and do the implementation
later? For the time being that will mean that
RASAPI32 tests will fail, because of missing code in
rasapi.c. Is that OK? I haven't created DLL-tests yet...
Regards
Gerold
Hi,
I guess the obvious next step is to let wined3d manage the surface creation by
getting rid of the CreateAdditionalSurface mess and let
IWineD3DDeviceParent::CreateSurface handle this.
I guess we should also get rid of the complex_array attachment list and handle
those attachment by querying the wined3d container for the backbuffer or mipmap
sublevel list. And while AddAttachedSurface mostly serves the function of
SetDepthStencilSurface I'm afraid we won't be able to get rid of the manual
attachment list - but we should probably replace it with a wine list(*)
Anyway, thanks for cleaning up this mess. I feel guilty because I should have
done this long ago :-/
Cheers,
Stefan
(*) I think I did that at some point, maybe is was another case of written but
never finished patches. Or maybe I did this with some other surface list...
On Wednesday 20 April 2011 22:09:27 Henri Verbeet wrote:
> ---
> dlls/ddraw/surface.c | 34 ++++++++++++++++++++++++++--------
> 1 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c
> index 16b831a..84082c5 100644
> --- a/dlls/ddraw/surface.c
> +++ b/dlls/ddraw/surface.c
> @@ -180,10 +180,13 @@ static ULONG WINAPI
> ddraw_surface7_AddRef(IDirectDrawSurface7 *iface)
>
> TRACE("%p increasing refcount to %u.\n", This, refCount);
>
> - if (refCount == 1 && This->WineD3DSurface)
> + if (refCount == 1)
> {
> EnterCriticalSection(&ddraw_cs);
> - IWineD3DSurface_AddRef(This->WineD3DSurface);
> + if (This->WineD3DSurface)
> + IWineD3DSurface_AddRef(This->WineD3DSurface);
> + if (This->wined3d_texture)
> + wined3d_texture_incref(This->wined3d_texture);
> LeaveCriticalSection(&ddraw_cs);
> }
>
> @@ -256,9 +259,7 @@ static void
> ddraw_surface_cleanup(IDirectDrawSurfaceImpl *surface)
>
> TRACE("surface %p.\n", surface);
>
> - if (surface->wined3d_texture) /* If it's a texture, destroy the
> wined3d texture. */ -
> wined3d_texture_decref(surface->wined3d_texture);
> - else if (surface->wined3d_swapchain)
> + if (surface->wined3d_swapchain)
> {
> IDirectDrawImpl *ddraw = surface->ddraw;
>
> @@ -388,7 +389,10 @@ static ULONG WINAPI
> ddraw_surface7_Release(IDirectDrawSurface7 *iface)
> LeaveCriticalSection(&ddraw_cs);
> return ref;
> }
> - ddraw_surface_cleanup(This);
> + if (This->wined3d_texture) /* If it's a texture, destroy the
> wined3d texture. */ +
> wined3d_texture_decref(This->wined3d_texture);
> + else
> + ddraw_surface_cleanup(This);
> LeaveCriticalSection(&ddraw_cs);
> }
>
> @@ -3491,6 +3495,20 @@ const struct wined3d_parent_ops
> ddraw_surface_wined3d_parent_ops = ddraw_surface_wined3d_object_destroyed,
> };
>
> +static void STDMETHODCALLTYPE ddraw_texture_wined3d_object_destroyed(void
> *parent) +{
> + IDirectDrawSurfaceImpl *surface = parent;
> +
> + TRACE("surface %p.\n", surface);
> +
> + ddraw_surface_cleanup(surface);
> +}
> +
> +static const struct wined3d_parent_ops ddraw_texture_wined3d_parent_ops =
> +{
> + ddraw_texture_wined3d_object_destroyed,
> +};
> +
> HRESULT ddraw_surface_create_texture(IDirectDrawSurfaceImpl *surface)
> {
> const DDSURFACEDESC2 *desc = &surface->surface_desc;
> @@ -3513,10 +3531,10 @@ HRESULT
> ddraw_surface_create_texture(IDirectDrawSurfaceImpl *surface) format =
> PixelFormat_DD2WineD3D(&surface->surface_desc.u4.ddpfPixelFormat); if
> (desc->ddsCaps.dwCaps2 & DDSCAPS2_CUBEMAP)
> return
> IWineD3DDevice_CreateCubeTexture(surface->ddraw->wineD3DDevice,
> desc->dwWidth, - levels, 0, format, pool, surface,
> &ddraw_null_wined3d_parent_ops, &surface->wined3d_texture); +
> levels, 0, format, pool, surface, &ddraw_texture_wined3d_parent_ops,
> &surface->wined3d_texture); else
> return IWineD3DDevice_CreateTexture(surface->ddraw->wineD3DDevice,
> desc->dwWidth, desc->dwHeight, - levels, 0, format, pool,
> surface, &ddraw_null_wined3d_parent_ops, &surface->wined3d_texture); +
> levels, 0, format, pool, surface,
> &ddraw_texture_wined3d_parent_ops, &surface->wined3d_texture); }
>
> HRESULT ddraw_surface_init(IDirectDrawSurfaceImpl *surface,
> IDirectDrawImpl *ddraw,
Dmitry Timoshkov <dmitry(a)codeweavers.com> writes:
> This patch reverts a part of 61e50e15ba45ad54655f98619f5ef33917033165 and
> fixes the regression reported in the bug 26670.
This will cause spurious task bar entries in many apps.
--
Alexandre Julliard
julliard(a)winehq.org