While testing a game with current gecko, I saw the error
wine: Call from 0x7bc4ad90 to unimplemented function msvcrt.dll._snwprintf_s,
aborting
The game needed a native msvcrt, so I had installed one with winetricks,
and it didn't export that function.
So it seems that new gecko is incompatible with old msvcrt,
and using native msvcrt as a workaround for bugs in wine's
version is going to be harder than it used to be.
Time to fix more of them msvcrt bugs, I guess...
And/or find a more up to date msvcrt.dll for winetricks.
On 04/29/2011 01:31 AM, Marcus Meissner wrote:
> ---
> dlls/dinput/device_private.h | 148 +++++++++++++++++++++---------------------
> 1 files changed, 74 insertions(+), 74 deletions(-)
What exactly is this supposed to to? This is inside header file, everything
declared in it is internal to dinput. Why do we need some extra declarations
on it?
Vitaliy.
Hallo,
i currently digg in comctl32 to find why my app fails. I found that
string conversation AtoW in some places silently fails. The problem is
that the destination for string is just a fresh pointer (not NULL).
Str_SetPtrAtoW check if it is NULL pointer and if not it trys to
ReAlloc. There was no Alloc before so ReAlloc returns NULL. Because
there is no other checks, Str_SetPtrAtoW just go back without converting
the string.
Here is affected code:
dlls/comctl32/comctl32undoc.c:999
> BOOL Str_SetPtrAtoW (LPWSTR *lppDest, LPCSTR lpSrc)
> {
> TRACE("(%p %s)\n", lppDest, lpSrc);
>
> if (lpSrc) {
> INT len = MultiByteToWideChar(CP_ACP,0,lpSrc,-1,NULL,0);
> LPWSTR ptr = ReAlloc (*lppDest, len*sizeof(WCHAR));
>
> if (!ptr) {
> ERR("last error %x\n", GetLastError());
> return FALSE;
> }
> MultiByteToWideChar(CP_ACP,0,lpSrc,-1,ptr,len);
> *lppDest = ptr;
> }
> else {
> Free (*lppDest);
> *lppDest = NULL;
> }
>
> return TRUE;
> }
The question is, is it appropriate reaction of ReAlloc and if it so, may be it make more sense to do this:
--- a/dlls/comctl32/comctl32undoc.c
+++ b/dlls/comctl32/comctl32undoc.c
@@ -998,18 +998,26 @@ INT Str_GetPtrAtoW (LPCSTR lpSrc, LPWSTR lpDest, INT nMaxLen)
*/
BOOL Str_SetPtrAtoW (LPWSTR *lppDest, LPCSTR lpSrc)
{
- TRACE("(%p %s)\n", lppDest, lpSrc);
+ TRACE("(%p, %s)\n", *lppDest, debugstr_a(lpSrc));
if (lpSrc) {
+ if (*lppDest) {
+ Free (*lppDest);
+ *lppDest = NULL;
+ }
INT len = MultiByteToWideChar(CP_ACP,0,lpSrc,-1,NULL,0);
- LPWSTR ptr = ReAlloc (*lppDest, len*sizeof(WCHAR));
+ LPWSTR ptr = Alloc (len*sizeof(WCHAR));
- if (!ptr)
+ if (!ptr) {
+ ERR("Can't allocait memory size: %u,"
+ " for string %s.\n", len*sizeof(WCHAR), lpSrc);
return FALSE;
+ }
MultiByteToWideChar(CP_ACP,0,lpSrc,-1,ptr,len);
*lppDest = ptr;
}
else {
+ TRACE("lpSrc = NULL, nothing to convert.\n");
Free (*lppDest);
*lppDest = NULL;
}
--
Regards,
Alexey
On 30 April 2011 01:23, John Edmonds <pocketcookies2(a)gmail.com> wrote:
> @@ -6559,6 +6559,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_Reset(IWineD3DDevice *iface,
> {
> ERR("Failed to acquire focus window, hr %#x.\n", hr);
> wined3d_swapchain_decref(swapchain);
> + This->filter_messages = filter;
> return hr;
> }
This patch looks right in principle. Note that if you're running into
this code you probably have problems elsewhere though.
Austin wrote:
> Fixes http://bugs.winehq.org/show_bug.cgi?id=19816
That bug is "Add implementation of MSVBVM60". I don't think
a stub fixes it.
What apps benefit from having a stub?
- Dan
Kai Wasserbäch wrote:
>as bug #19762 is open for some time now, fully bisected, the solution applied for
>several versions in my Debian packages ([0]) without reports about breakage, I
>hearby propose the reversion of commit 67631163.
http://bugs.winehq.org/show_bug.cgi?id=19762#c21
That commit is another example of a commit that introduced a regression
while fixing another regression in another app. This does not prove that
commit wrong, however, the burden is now on you (us) to prove it in order to change git.
It's not an impossible task. Even code that seemed to be backed by
tests in Wine was changed when the tests were proven wrong/incomplete.
For a start, it may be worth testing that other app and see
if it still needs that commit in current Wine. Does anybody know the
bug number of that other app's original issue?
Finally, are there any tests that support either behavior?
Regards,
Jörg Höhle
On 29 April 2011 12:29, Kai Wasserbäch <curan(a)debian.org> wrote:
> several versions in my Debian packages ([0]) without reports about breakage, I
> hearby propose the reversion of commit 67631163. Wylda tried to reach the
I don't think reverting that commit is the right thing to do, it's
just going to break something else instead.
> + shader_addline(buffer, "TEMP TB;\n");
Which shader instruction uses this? Afair vertex shaders should only use TA,
but there's no proper infrastructure that manages that.
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=10627
Your paranoid android.
=== WINEBUILD (build) ===
Patch failed to apply
Hi Frédéric,
Le 29 avril 2011 00:16, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit :
> #: winerror.mc:441
> msgid "No more search handles\n"
> -msgstr "Il n'y a plus de descripteurs de recherche\n"
> +msgstr "Il n'y a plus de descripteur de recherche\n"
This one isn't correct. There's not only one handle when available but
many so it should take an 's' in the negative form too.
Thanks for your work !
--
Nicolas Le Cam