Mariusz Pluciński <vshader(a)gmail.com> writes:
> +static BOOL GAMEUX_isFileExists(LPCWSTR sFile)
> +{
> + HANDLE hFile;
> +
> + hFile = CreateFileW(sFile, GENERIC_READ, 0,
> + NULL, OPEN_EXISTING, 0, NULL);
> +
> + if(hFile == INVALID_HANDLE_VALUE)
> + return FALSE;
> +
> + CloseHandle(hFile);
> + return TRUE;
> +}
This sort of thing is not a good idea in general, even if it had a more
grammatically correct function name ;-) If you need to load a file you
have to open it anyway, so you can check for errors at that point.
Checking for existence beforehand is only doing duplicate work.
--
Alexandre Julliard
julliard(a)winehq.org
Hello,
I noticed the committed patch "gameux: Add implementation of IGameStatisticsMgr::RemoveGameStatistics." (5cac9d2cb2c020802a56a5b1b28348316f1087ba)
The GAMEUX_getAppIdFromGDFPath() function now ends with:
+ HeapFree(GetProcessHeap(), 0, lpRegistryPath);
+
+ TRACE("found app id: %s, return: %#x\n", debugstr_w(lpApplicationId), hr);
+ return hr;
In most of the error paths, lpRegistryPath is not initialized, so it's pointing to garbage; I think just initializing to NULL should be sufficient;
Similarly, in that case, lpApplicationId is not initialized, so it contains garbage; Tracing will probably print some random stack bytes before hitting a zero byte.
I'm not completely sure what should be done about this issue; I think it should probably only be traced on success, perhaps tracing the error otherwise; Any ideas?
HTH,
Joris
Erich Hoover <ehoover(a)mines.edu> writes:
> + /* Build an X cursor out of all of the frames */
> + if (!(images = pXcursorImagesCreate( nFrames ))) goto cleanup;
> + for (images->nimage = 0; images->nimage < nFrames; images->nimage++)
> + images->images[images->nimage] = imgs[images->nimage];
> wine_tsx11_lock();
> - cursor = pXcursorImageLoadCursor( gdi_display, image );
> - pXcursorImageDestroy( image );
> + cursor = pXcursorImagesLoadCursor( gdi_display, images );
> wine_tsx11_unlock();
> + pXcursorImagesDestroy( images ); /* Note: XcursorImagesDestroy is called on each frame */
The note isn't clear, does it destroy the individual images or not?
Either way your cleanup code needs more work.
> +cleanup:
> + /* Cleanup all of the resources used to obtain the frame data */
> + if (imgs && !cursor)
> + {
> + int i;
> +
> + for (i = 0; i < nFrames; i++)
> + pXcursorImageDestroy( image );
And this can't possibly work.
--
Alexandre Julliard
julliard(a)winehq.org
Adding copypastable backtraces to the crash window might go a long way
to prevent this sort of attachments:
http://bugs2.winehq.org/attachment.cgi?id=31033
Maybe under a "Crash information" link or something similar. It
wouldn't always do the trick (seeing as most of the time the error
only shows in the fixmes, if not the traces), but at least it would
get rid of some completely useless attachments, imho.
Has this been discussed before?
J. Leclanche
Hi,
I've created a small executable on windows which calls
GetFileVersionInfo() and VerQueryValue() to extract VS_VERSION_INFO
from various windows binary files. I want to use this utility under
wine on linux system. Everything works fine for most of the files but
for some older dlls I'm not getting correct version information.
In the wine sources I found some of the functions for previous (16-
bit) version info extraction to be stubs.
I tried replacing version.dll in $HOME/.wine/drive_c/windows/system32
with the one on my windows XP box but nothing happens. I still don't
get complete information.
Is there a way to achieve this.
Thanks,
Kapil.
Hi Reece,
On 9/30/10 12:20 AM, Reece Dunn wrote:
> This addresses a fixme in the jscript code that is currently triggered
> when running the Big Fish Games client, with a test.
if(V_VT(&constr) != VT_DISPATCH) {
- FIXME("throw TypeError\n");
+ hres = throw_type_error(ctx->parser->script, ei, IDS_OBJECT_EXPECTED, NULL);
VariantClear(&constr);
- return E_FAIL;
+ return hres;
It would be cleaner to clear constr before throw_type_error so that you can
return its result directly, without storing it in hres.
exception_test(function() {"test" in null;}, "TypeError", -2146823281);
exception_test(function() {"test" in nullDisp;}, "TypeError", -2146823281);
+exception_test(function() {new null;}, "TypeError", -2146823281);
While you're at this, it would be nice to add a test (and fix) for nullDisp
and test some other types (eg. undefined and number).
Jacek
Alexandre Julliard <julliard(a)winehq.org> wrote:
>Sent: Sep 29, 2010 11:25 AM
>To: Shachar Shemesh <shachar(a)shemesh.biz>
>Cc: Paul Vriens <paul.vriens.wine(a)gmail.com>, "'wine-devel(a)winehq.org'" <wine-devel(a)winehq.org>
>Subject: Re: Right-To-Left (RTL) languages and Wine
>
>Shachar Shemesh <shachar(a)shemesh.biz> writes:
>
>> Did I mention that the automatic mirroring is a broken idea
>> implemented in a broken way already?
>
>What do you consider broken about it?
>
>> Aside from notepad, for which the difference is very small, and most
>> people would regard a default LTR control as the correct behavior
>> anyway, what other applications are you concerned over?
>
>Pretty much all of them. For example, Wordpad has combo boxes in the
>toolbars, those won't be RTL without changing the process layout.
>Winefile and Regedit have treeviews that would need mirroring, etc.
>
And Microsoft Office appears different in RTL rather than LTR. I used to work with someone that had the Arabic version of these programs and it would switch from RTL when typing in Arabic to LTR when typing in a Latin-based language.
As AJ has stated, there is more to do than just 'mirroring' to get RTL into Wine. I remember this was quite difficult to get into OpenOffice.org as well when I was testing it (I think I still have Hebrew and Arabic test files for Writer in OpenDocument (.odt) format.)
James McKenzie
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=5608
Your paranoid android.
=== W98SE (32 bit) ===
No test summary line found
=== WNT4WSSP6 (32 bit) ===
No test summary line found
=== W2KPROSP4 (32 bit) ===
No test summary line found
=== WXPPROSP3 (32 bit) ===
No test summary line found
=== W2K3R2SESP2 (32 bit) ===
No test summary line found
=== WVISTAADM (32 bit) ===
No test summary line found
=== W2K8SE (32 bit) ===
No test summary line found
=== W7PRO (32 bit) ===
No test summary line found
=== W7PROX64 (32 bit) ===
No test summary line found
=== W7PROX64 (64 bit) ===
No test summary line found