Re: Trying Battle for Wesnoth in Wine.
Le vendredi 5 avril 2013 03:54:51, Tae Wong a écrit : > You haven’t tried Battle for Wesnoth latest version in Wine on Ubuntu > so you have uploaded the about.cfg file to MediaFire which contains > over 1000 lines and some un-terminated quoted strings in many names. > Check it here (http://www.mediafire.com/?mbw9y2i834z2k7r)! Swear at > error message (Quoted string not terminated) whilst you fix the > un-terminated quoted strings. Are you sure this is the right mailing list ? I do not find any "about.cfg" file in wine, please check where that file is comming from. Also check from upstream server and latest release that you can reproduce the issue. There are little chances wesnoth team actually ever uploaded anything to that service, usually such sites feed themselves, so it will help you tell where to direct your report. A patch is certainly welcomed by the project the file belongs to. Telling people to fix their stuff is just rude and has a lot of chances of getting you ignored. Lastly, unless you are doing some sort of dogfood session for wine, native Linux version of wesnoth exists (and chances are Ubuntu already packages it). -- Vincent Pelletier
Re: wineapploader in wine64
Le jeudi 16 février 2012 21:27:37, Austin English a écrit : > Most people use `wineserver -k` for that. Woops, missed your reply. The problem with wineserver is, with debian packages, that it's not available through PATH (http://packages.debian.org/sid/amd64/libwine-unstable/filelist : /usr/lib32/wine-unstable/wineserver). But I take note anyway, as I usually build wine myself than use distro packages. -- Vincent Pelletier
Build failure after interrupted first build
Hi. I got a failure building wine, where wrc would fail on utils.c:xmalloc's "assert(size > 0)". This came from a po/*.mo file being present but empty because a first build got interrupted (^C). Just in case either someone here can figure out a one-liner fix for this, or if it helps the next person encountering that behaviour. Regards, -- Vincent Pelletier
Re: wineapploader in wine64
Le jeudi 16 février 2012 20:57:10, Alexandre Julliard a écrit : > (besides, there shouldn't be any reason to run wineboot by hand). FWIW, on wine (32bits) I use "wineboot -ks" to get rid of a crashing app (stuck eating cpu, or just willing to stay). -- Vincent Pelletier
PVS-Studio run against ReactOS: (at least) one bug in wine git
Hi. Reading this page about a PVS-Studio run against ReactOS: http://www.viva64.com/en/a/0076/ I looked up in wine's repository the ones mentioned in the article. There are more in the full output: http://www.viva64.com/external-pictures/txt/PVS-Studio-vs-ReactOS-en-unicode.txt I found only one error still present: strcmpW without use of return value is still present, dlls/msdmo/dmoreg.c:620 I guess wcscpy (or so) was intended. Cc'ed Ulrich Czekalla, as "git blame" brings his name up (...from 2003 !). Regards, -- Vincent Pelletier
[mshtml] Crash in World of Warcrash launcher
Hi. Runing the latest WoW Launcher, I get the following traceback: Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7d30 ESP:0032e404 EBP:0032e474 EFLAGS:00010213( R- -- I -A- -C) EAX:0001 EBX:7d3f22bc ECX: EDX: ESI: EDI:0281f518 Stack dump: 0x0032e404: 0032e474 038f3338 0032e430 0x0032e414: 6a00410b 038f3338 0032e450 0x0032e424: 038f3368 038f3338 0032e470 0x0032e434: 0281f518 cbc0cbd8 0281f518 0032e480 0x0032e444: 6a617b40 0281f518 6ab94f64 0032e490 0x0032e454: 038f3338 000f 000e 7ef7bee5 Backtrace: =>0 0x7d30 doc_insert_script+0x30(window=0x2738378, nsscript=(nil)) [/home/vincent/git/wine/dlls/mshtml/script.c:757] in mshtml (0x0032e474) 1 0x7d36ec96 run_insert_script+0xb5(doc=0x7d36e63e, script_iface=0x3849830, parser_iface=0x38f3368) [/home/vincent/git/wine/dlls/mshtml/mutation.c:338] in mshtml (0x03849830) 2 0x0032e550 (0x0384a9e8) 3 0x0002 (0x7d3f0a28) 4 0x7d36e7d0 in mshtml (+0x6e7cf) (0x7d36fbc0) 5 0x0010 (0xb94cec83) 0x7d30 doc_insert_script+0x30 [/home/vincent/git/wine/dlls/mshtml/script.c:757] in mshtml: movl 0x0(%esi), %eax 757 nsres = nsIDOMHTMLScriptElement_GetType(nsscript, &val_str); Bisecting find this commit: dc96c688d397eb4ef1392ee6a98f3eb6b176dc56 is the first bad commit commit dc96c688d397eb4ef1392ee6a98f3eb6b176dc56 Author: Jacek Caban Date: Tue Mar 15 13:45:46 2011 +0100 mshtml: Notify parser about script evaluation. :04 04 56e26373e5d368d9c991936e12bbf6572b51a1c8 b047f9b40a63e482b477254952737e9e9cd4aded M dlls I don't know if it's a regression in wine by itself, or if WoW Launcher just happens to trigger the failure now (I haven't ran it in some months). -- Vincent Pelletier
Re: ntdll: Remove more path trailing chars.
Le vendredi 08 avril 2011 13:05:18, joerg-cyril.hoe...@t-systems.com a écrit : > It means tests never fail on native, which renders the test useless. That's exactly my point. I started writing a mail to describe just what you said, with the extra data that on wine, test will verify something decided upon test writing. It just won't be compared to any windows version. I'm (somehow) glad to hear it's not the only test which has problems with just NT. > Any other means to detect NT *that is relevant for your test* is fine, i.e. > don't query the DLL version or use some function outside of your test > domain. > Typical detectors are different GetLastError() values. I'll check what error this triggers on NT, and fallback on the code you wrote above. As I don't have access to an NT machine, I sent an account request for the test bot. Regards, -- Vincent Pelletier
Re: ntdll: Remove more path trailing chars.
Hi. Le samedi 02 avril 2011 09:16:53, Nikolay Sivov a écrit : > Please use table for test data and put your macro body in a loop. Done locally (indeed nicer). I have one more thing to figure out before posting again: how to deal with the NT4 failures testbot detected[1]. Those tests are boolean, so I doubt an "ok(pass || fail /* NT4 */)" makes any sense. I saw that it is discouraged (forbidden ?) to depend on OS version in tests, so I will avoid that path unless asked to follow it. I've been advised on IRC to use "broken()", but I don't see how to use it for such boolean case (in my understanding it has a meaning if different error status a returned by different windows versions, not between a success and an error status). [1] http://testbot.winehq.org/JobDetails.pl?Key=10288#k201 Regards, -- Vincent Pelletier
Re: kernel32: add test for FindFirstFileA with a path ending with "/>"
Le samedi 02 avril 2011 00:18:16, Austin English a écrit : > Your patch changelog is misleading. You're not just adding tests, but > fixing the bug. Either send the tests as a single patch and the fix > separately(and removing any todo_wine()'s that it fixes) or change the > summary to describe the fix. Woops, indeed. This, and I should rebase to remote before sending. -- Vincent Pelletier
[RFC] dinput: Length can actually be 0.
(Sorry for sending to wine-patches initially, it was intended for wnie-devel.)
This fixes force feedback devices slamming for 10ms at full strength, as
attack is an absolute value, not a factor of effect level.
Daniel Remenak told me that 0-length envelopes (attack and/or fade, not sure
which combination) cause the effect to be not played (possibly played with 0-
level) on devices using the Linux iforce driver. This is the reason of the
comment in the code.
But to other drivers, such as hid-ff, this code causes the device to jump as
full strength, which was reported (to me directly) for example when playing
"Live for Speed"[1] with a steering wheel having strong force feedback
(Logitech G27).
My question: Is it acceptable to risk some regression for iforce driver (until
bug is identified) to fix other devices ?
I guess iforce devices also suffer from the too-strong attack/fade effect.
[1] http://www.lfs.net (demo available, I didn't try it)
---
dlls/dinput/effect_linuxinput.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c
index fbc5994..0154f49 100644
--- a/dlls/dinput/effect_linuxinput.c
+++ b/dlls/dinput/effect_linuxinput.c
@@ -606,13 +606,12 @@ static HRESULT WINAPI
LinuxInputEffectImpl_SetParameters(
else env = NULL;
if (peff->lpEnvelope == NULL) {
- /* if this type had an envelope, reset it
-* note that length can never be zero, so we set it to something
minuscule */
+ /* if this type had an envelope, reset it */
if (env) {
- env->attack_length = 0x10;
- env->attack_level = 0x7FFF;
- env->fade_length = 0x10;
- env->fade_level = 0x7FFF;
+ env->attack_length = 0;
+ env->attack_level = 0;
+ env->fade_length = 0;
+ env->fade_level = 0;
}
} else {
/* did we get passed an envelope for a type that doesn't even have
one? */
--
1.7.4.1
RFC [PATCH] ddraw: Prevent refcount underflow
Hi.
Attached patch fixes a problem with Beetle Crazy Cup's VideoSetup.exe, which
hangs at exit because some code tries to free ddraw surface on which a
refcount underflow happened earlier in the execution.
Executing it with winedbg shows that the first call causing the underflow is
triggered from game's binary:
Stopped on breakpoint 3 at 0x7ed494fc ddraw1_Release+0x2c
[/home/vincent/git/wine/dlls/ddraw/ddraw.c:476] in ddraw
476 ULONG ref = InterlockedDecrement(&ddraw->ref1);
Wine-dbg>print ddraw->ref1
0
Wine-dbg>bt
Backtrace:
=>0 0x7ed494fc ddraw1_Release+0x2c(iface=0x129e10)
[/home/vincent/git/wine/dlls/ddraw/ddraw.c:476] in ddraw (0x0033fd24)
1 0x00401d2c in videosetup (+0x1d2b) (0x0033fd5c)
2 0x0040342b in videosetup (+0x342a) (0x0033fd84)
3 0x004034f5 in videosetup (+0x34f4) (0x0033fda0)
4 0x00402f65 in videosetup (+0x2f64) (0x0033fe04)
5 0x00404a4e in videosetup (+0x4a4d) (0x0033fe90)
6 0x7b8565bc call_process_entry+0xb() in kernel32 (0x0033fea8)
7 0x7b8565bc call_process_entry+0xb() in kernel32 (0x0033fee8)
8 0x7b858a9b start_process+0x5a(peb=0x536430)
[/home/vincent/git/wine/dlls/kernel32/process.c:994] in kernel32 (0x0033fef8)
9 0x7bc715f0 call_thread_func+0xb() in ntdll (0x0033ffc8)
10 0x7bc717c0 call_thread_entry_point+0x6f(entry=0x7b858a40, arg=0x7ffdf000)
[/home/vincent/git/wine/dlls/ntdll/signal_i386.c:2473] in ntdll (0x0033ffe8)
11 0x7bc4cefa start_process+0x29(kernel_start=0x7b858a40)
[/home/vincent/git/wine/dlls/ntdll/loader.c:2610] in ntdll (0x)
Points on which I would like opinions:
- getting rid of the magic number
- need to check after InterlockedDecrement (in doubt I did, but the code is
much less readable this way)
- couldn't it actually hide a refcount problem in wine ?
- if not, then would it be good to extend to other refcounts aswell or include
in [a local wrapper for] InterlockedDecrement ?
Regards,
---
dlls/ddraw/ddraw.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c
index f3ebade..39738d5 100644
--- a/dlls/ddraw/ddraw.c
+++ b/dlls/ddraw/ddraw.c
@@ -475,7 +475,11 @@ static ULONG WINAPI ddraw1_Release(IDirectDraw *iface)
IDirectDrawImpl *ddraw = ddraw_from_ddraw1(iface);
ULONG ref = InterlockedDecrement(&ddraw->ref1);
-TRACE("%p decreasing refcount to %u.\n", ddraw, ref);
+if (ref == 4294967295U) {
+InterlockedIncrement(&ddraw->ref1);
+WARN("%p NOT decreasing refcount.\n", ddraw);
+} else
+TRACE("%p decreasing refcount to %u.\n", ddraw, ref);
if (!ref && !InterlockedDecrement(&ddraw->numIfaces))
ddraw_destroy(ddraw);
Re: [PATCH] ntdll: Reimplement qsort() using generic mergesort
Le dimanche 09 mai 2010 13:09:47, Marcus Meissner a écrit : > As __cdecl (for the compare function) is not the UNIX cdecl in Win64 > anymore, we need to reimplement sort to call the right comparator > functions. Not that it's important, but that reminded me of this: http://docs.python.org/library/ctypes.html#callback-functions (scroll a bit for qsort example on windows vs. linux) It would be interesting (though probably futile) to see how this code behaves. -- Vincent Pelletier
Re: RFC kernel32: add test for FindFirstFileA with a path ending with "/>"
Le dimanche 09 mai 2010 11:05:55, Stefan Leichter a écrit : > Failing tests on wine needs to be marked with the todo_wine macro Yes, but as I said in my first mail I would prefer to get hints on how this should be fixed. I know nothing about path handling in wine, if it turns out to be trivial to fix I would like to include it in the patch. -- Vincent Pelletier
Re: RFC kernel32: add test for FindFirstFileA with a path ending with "/>"
Le samedi 08 mai 2010 18:14:49, Vincent Pelletier a écrit :
> This test passes on win2k & winxp, fails on wine.
Bug opened for this issue:
http://bugs.winehq.org/show_bug.cgi?id=22635
Updated patch, with (too ?) many more test cases.
Interesting URLs:
http://msdn.microsoft.com/en-
us/library/aa365247%28VS.85%29.aspx#naming_conventions
http://msdn.microsoft.com/en-us/library/aa364418%28VS.85%29.aspx
(especially "Bug?!" comment)
--
Vincent Pelletier
From 110ee20580c7eeb6035edc45cc13bfe6e4f87daf Mon Sep 17 00:00:00 2001
Message-Id: <110ee20580c7eeb6035edc45cc13bfe6e4f87daf.1273393410.git.plr.vinc...@gmail.com>
From: Vincent Pelletier
Date: Sat, 8 May 2010 17:52:47 +0200
Subject: [PATCH] kernel32: add test for FindFirstFileA with a path ending with "/>"
To: wine-patches
Reply-To: wine-devel
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1.7.0.4"
This is a multi-part message in MIME format.
--1.7.0.4
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
This test passes on win2k, fails on wine.
That failure causes cdkey problems in "Earth 2160" as sold on GOG.com:
Once the installation is finished, the installers generates a registry key
value based (among other things) on the ctime of installed directory.
Looked-up path has a spurious "/>" trail, causing the registry key to be
incorrect and the game rejects it.
---
dlls/kernel32/tests/file.c | 85
1 files changed, 85 insertions(+), 0 deletions(-)
--1.7.0.4
Content-Type: text/x-patch; name="0001-kernel32-add-test-for-FindFirstFileA-with-a-path-end.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline; filename="0001-kernel32-add-test-for-FindFirstFileA-with-a-path-end.patch"
diff --git a/dlls/kernel32/tests/file.c b/dlls/kernel32/tests/file.c
index b6f066e..541c70d 100644
--- a/dlls/kernel32/tests/file.c
+++ b/dlls/kernel32/tests/file.c
@@ -2084,6 +2084,91 @@ static void test_FindFirstFileA(void)
err = GetLastError();
ok ( handle == INVALID_HANDLE_VALUE, "FindFirstFile on %s should Fail\n", buffer2 );
ok ( err == ERROR_PATH_NOT_FOUND, "Bad Error number %d\n", err );
+
+/* try FindFirstFileA on "test-dir" with forbidden chars */
+CreateDirectoryA("test-dir", NULL);
+_lclose(_lcreat("test-file", 0));
+
+#define test_FindFirstFileA_with(x, y) { \
+handle = FindFirstFileA(x, &data);\
+if (y) { \
+ok ( handle != INVALID_HANDLE_VALUE, "FindFirstFile on "x" should succeed\n");\
+ok ( FindClose(handle) == TRUE, "Failed to close handle "x"\n"); \
+} else { \
+ok ( handle == INVALID_HANDLE_VALUE, "FindFirstFile on "x" should fail\n");\
+} \
+}
+
+/* Disallowed chars being ignored: */
+test_FindFirstFileA_with("test-dir/>", 1);
+test_FindFirstFileA_with("test-dir/<", 1);
+test_FindFirstFileA_with("test-dir/\"", 1);
+test_FindFirstFileA_with("test-dir<>", 1);
+test_FindFirstFileA_with("test-dir<<", 1);
+test_FindFirstFileA_with("test-dir<\"", 1);
+test_FindFirstFileA_with("test-dir>>", 1);
+test_FindFirstFileA_with("test-dir><", 1);
+test_FindFirstFileA_with("test-dir>\"", 1);
+test_FindFirstFileA_with("test-dir\">", 1);
+test_FindFirstFileA_with("test-dir\"<", 1);
+test_FindFirstFileA_with("test-dir\"\"", 1);
+test_FindFirstFileA_with("test-dir\\<", 1);
+test_FindFirstFileA_with("test-dir\\>", 1);
+test_FindFirstFileA_with("test-dir\\\"", 1);
+/* But forward & back slashes are not tolerated on a file */
+test_FindFirstFileA_with("test-file/>", 0);
+test_FindFirstFileA_with("test-file/<", 0);
+test_FindFirstFileA_with("test-file/\"", 0);
+test_FindFirstFileA_with("test-file<>", 1);
+test_FindFirstFileA_with("test-file<<", 1);
+test_FindFirstFileA_with("test-file<\"", 1);
+test_FindFirstFileA_with("test-file>>", 1);
+test_FindFirstFileA_with("test-file><", 1);
+test_FindFirstFileA_with("test-file>\"", 1);
+test_FindFirstFileA_with("test-file\">", 1);
+test_FindFirstFileA_with("test-file\"<", 1);
+test_FindFirstFileA_with("test-file\"\"", 1);
+test_FindFirstFileA_with("test-file\\<", 0);
+test_FindFirstFileA_with("test-file\\>&quo
RFC kernel32: add test for FindFirstFileA with a path ending with "/>"
This test passes on win2k & winxp, fails on wine.
That failure causes cdkey verification problems in "Earth 2160" as sold on
GOG.com:
Once the installation is finished, the installers generates a registry key
value based (among other things) on the ctime of installed directory.
Looked-up path has trailing "/>", causing the registry key to be incorrect and
the game rejects it.
I have no idea how to solve this error at the moment, nor the whole set of
acceptable path trails. Please advise me if you have insight on this, and I'll
see if I can fix it. This is the reason why I didn't add a todo_wine in the
test.
---
dlls/kernel32/tests/file.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/dlls/kernel32/tests/file.c b/dlls/kernel32/tests/file.c
index b6f066e..d5b04ba 100644
--- a/dlls/kernel32/tests/file.c
+++ b/dlls/kernel32/tests/file.c
@@ -2084,6 +2084,13 @@ static void test_FindFirstFileA(void)
err = GetLastError();
ok ( handle == INVALID_HANDLE_VALUE, "FindFirstFile on %s should Fail\n", buffer2 );
ok ( err == ERROR_PATH_NOT_FOUND, "Bad Error number %d\n", err );
+
+/* try FindFirstFileA on "test-dir/>" */
+CreateDirectoryA("test-dir", NULL);
+handle = FindFirstFileA("test-dir/>", &data);
+ok ( handle != INVALID_HANDLE_VALUE, "FindFirstFile on test-dir/> should succeed\n");
+ok ( FindClose(handle) == TRUE, "Failed to close handle test-dir/>\n");
+RemoveDirectoryA("test-dir");
}
static void test_FindNextFileA(void)
Re: new wisotool 20100424: new verbs 3dmark2000, 3dmark2001, 3dmark03, 3dmark05, 3dmark06, baldursgate2, gta_vc, pcmark04, pcmark05, unigine_heaven
Patch updated.
Notes:
- Download urls and AHK scripts are *all* tested as of this patch (~5 hours to
install everything).
- BAT scripts are *not* tested.
Remaining issues:
- url escaping when posting login & password (I'll work on this next)
- possibly BAT scripting mistakes (verb definition)
- possibly a yet unidentified auth bug which affected Dan Kegel
- missing BAT scripts for bundles (not sure what to do for those)
Changelog:
- add cookie support in "download" (required as GOG.com requires auth
to download games)
- add download support for gog verbs
- Refresh against current svn head
- _load_gog: added install_dir parameter (needed by a few games)
- double all "\" meant to be literal backslashes
- fix download path for verbs:
ut2004_gog
abes_oddysee_gog
abes_exoddus_gog
descent_1_2_gog
- add verbs:
descent_3_gog
psychonauts_gog
ut_goty_gog
unreal_gold_gog
unreal_2_se_gog
battle_chess_gog
earth_2150_trilogy_gog
earth_2160_gog
empire_earth_gold_gog
earthworm_jim_1_2_gog
shogo_gog
settlers_2_gold_gog
robinson_requiem_collection_gog
redneck_rampage_gog
praetorians_gog
perimeter_gog
painkiller_black_gog
operation_flashpoint_goty_gog
neighbours_from_hell_compilation_gog
mdk_gog
mdk2_gog
ground_control_2_gog
ghost_master_gog
freespace_gog
freespace_2_gog
flatout_gog
earthworm_jim_3d_gog
fallout_gog
fallout_2_gog
fallout_tactics_gog
--
Vincent Pelletier
Index: wisotool
===
--- wisotool (révision 1220)
+++ wisotool (copie de travail)
@@ -340,7 +340,7 @@
}
# Download a file
-# Usage: package url [sha1sum [filename]]
+# Usage: package url [sha1sum [filename [cookie jar]]]
# Caches downloads in wisotoolcache/$package
download() {
if [ "$4"x != ""x ]
@@ -371,11 +371,11 @@
# [*] --read-timeout is useful on the adobe server that doesn't
# close the connection unless you tell it to (control-C or closing
# the socket)
- try wget -O "$file" -nd -c --read-timeout=300 --retry-connrefused --header "Accept-Encoding: gzip,deflate" "$2"
+ try wget -O "$file" -nd -c --read-timeout=300 --retry-connrefused --header "Accept-Encoding: gzip,deflate" ${5:+--load-cookies "$5"} "$2"
else
# curl doesn't get filename from the location given by the server!
# fortunately, we know it
- try curl -L -o "$file" -C - --header "Accept-Encoding: gzip,deflate" "$2"
+ try curl -L -o "$file" -C - --header "Accept-Encoding: gzip,deflate" ${5:+--cookie "$5"} "$2"
fi
# Need to decompress .exe's that are compressed, else cygwin fails
# Only affects cygwin, so don't barf if 'file' not installed
@@ -2182,7 +2182,7 @@
#
# Generic GOG.com installer
-# Usage: game_id game_title [other_files [reader_control [run_command [download_id
+# Usage: game_id game_title [other_files [reader_control [run_command [download_id [install_dir]
# game_id
# Used for main installer name and download url.
# game_title
@@ -2197,6 +2197,8 @@
# Used for bat script, relative to installation path.
# download_id
# For games which download url doesn't match their game_id
+# install_dir
+# If different from game_title
_load_gog()
{
# TODO: support SHA1 checks ? (installer verifies files)
@@ -2209,8 +2211,21 @@
reader_control="$4"
run_command="$5"
download_id="$6"
+install_dir="$7"
+if [ "$download_id"x = ""x ]
+then
+download_id="$game_id"
+fi
+if [ "$install_dir"x = ""x ]
+then
+install_dir="$game_title"
+fi
+
installer_path="$WISOTOOL_CACHE/$PACKAGE"
+mkdir -p "$installer_path"
+auth_path="$WISOTOOL_CACHE/gog_auth"
+mkdir -p "$auth_path"
installer="setup_$game_id.exe"
cookie="$auth_path/cookie.txt"
@@ -2220,7 +2235,32 @@
file_path="$installer_path/$file"
if ! test -s "$file_path"
then
-die "Please download $file to $installer_path"
+if ! test -f "$cookie"
+then
+login_file="$auth_path/login.txt"
+password_file="$auth_path/password.txt"
+if ! test -f "$login_file" -a -f "$password_file"
+then
+die "Please put your GOG.com login in '$login_file' and password in '$password_file' or
Re: new wisotool 20100424: new verbs 3dmark2000, 3dmark2001, 3dmark03, 3dmark05, 3dmark06, baldursgate2, gta_vc, pcmark04, pcmark05, unigine_heaven
Le jeudi 29 avril 2010 12:57:49, Vincent Pelletier a écrit :
> Le mercredi 28 avril 2010 09:13:24, Vincent Pelletier a écrit :
> > I'm trying to add support for GOG.com installers.
>
> Please review attached patch.
Patch updated.
Now tested on windows (...though not all games) from auth cookie creation to
bat script execution (test case: duke nukem 3d).
Curl tested (downloading and auth cookie generation).
Incremental changelog (skip to "Changelog" to just know what it does):
- changed cookie support in download so it take a filename as parameter, not a
chunk of HTTP headers
- fixed download url for duke nukem 3d, as it is different from game id
- removed (expanded) AHK marcos, as advised by Austin English on IRC
- auth cookie generation (you now only need your login & password, the rest is
automatic)
- fix duke nukem 3d and far cry to disable foxit reader installation (and
prune references to adobe in the source)
- add support for evil genius
- consider an empty file as non-existent (re-download it)
note: it didn't appear to have expected effect... I'll doublecheck after a
good night of sleep
Changelog:
- add cookie support in "download" (required as GOG.com requires auth
to download games)
- add generic automation for gog installer
(based on http://www.jrsoftware.org/isinfo.php)
- Add support for:
duke nukem 3d
duke nukem manhattan project
ut2004
abe's oddisee
abe's exoddus
beyond good and evil
far cry
descent 1 & 2 (single package)
evil genius
Updated "please review":
- _load_gog parameters. They are ugly IMO, because many are optional. But I
don't see how to do better (especially, how to extend them to include
optional SHA1 values).
- posix-ish scripting (only tested with bash)
Regards,
--
Vincent Pelletier
Index: wisotool
===
--- wisotool (révision 1206)
+++ wisotool (copie de travail)
@@ -340,7 +340,7 @@
}
# Download a file
-# Usage: package url [sha1sum [filename]]
+# Usage: package url [sha1sum [filename [cookie jar]]]
# Caches downloads in wisotoolcache/$package
download() {
if [ "$4"x != ""x ]
@@ -366,11 +366,11 @@
# [*] --read-timeout is useful on the adobe server that doesn't
# close the connection unless you tell it to (control-C or closing
# the socket)
- try wget -O "$file" -nd -c --read-timeout=300 --retry-connrefused --header "Accept-Encoding: gzip,deflate" "$2"
+ try wget -O "$file" -nd -c --read-timeout=300 --retry-connrefused --header "Accept-Encoding: gzip,deflate" ${5:+--load-cookies "$5"} "$2"
else
# curl doesn't get filename from the location given by the server!
# fortunately, we know it
- try curl -L -o "$file" -C - --header "Accept-Encoding: gzip,deflate" "$2"
+ try curl -L -o "$file" -C - --header "Accept-Encoding: gzip,deflate" ${5:+--cookie "$5"} "$2"
fi
# Need to decompress .exe's that are compressed, else cygwin fails
# Only affects cygwin, so don't barf if 'file' not installed
@@ -2177,6 +2177,186 @@
#
+# Generic GOG.com installer
+# Usage: game_id game_title [other_files [reader_control [run_command [download_id
+# game_id
+# Used for main installer name and download url.
+# game_title
+# Used for AutoHotKey and installation path in bat script.
+# other_files
+# Extra installer files, in one string, space-separated.
+# reader_control
+# If set, the control id of the configuration pannel checkbox controling
+# Adobe Reader installation.
+# Some games don't have it, some games do with different ids.
+# run_command
+# Used for bat script, relative to installation path.
+# download_id
+# For games which download url doesn't match their game_id
+_load_gog()
+{
+# TODO: support SHA1 checks ? (installer verifies files)
+load_autohotkey
+
+game_id="$1"
+game_title="$2"
+other_files="$3"
+reader_control="$4"
+run_command="$5"
+download_id="$6"
+
+if [ "$download_id"x == ""x ]
+then
+download_id="$game_id"
+fi
+
+installer_path="$WISOTOOL_CACHE/gog"
+mkdir -p "$installer_path"
+auth_path="$WISOTOOL_CACHE/gog_auth"
+mkdir -p "$auth_path"
+installer="setup_$game_id.exe"
+cookie="$auth_path/cookie.txt"
+
+file_id=0
+for file in $installer $other_files
+do
+file_path="$installer_path/$file&qu
Re: new wisotool 20100424: new verbs 3dmark2000, 3dmark2001, 3dmark03, 3dmark05, 3dmark06, baldursgate2, gta_vc, pcmark04, pcmark05, unigine_heaven
Le mercredi 28 avril 2010 09:13:24, Vincent Pelletier a écrit :
> I'm trying to add support for GOG.com installers.
Please review attached patch.
I can add more games to it, but now that I validated 8 cases (with/without
adobe installer, with multiple installer files, with various command lines) I
would prefer to have my scripting reviewed before expanding more.
Note: I can split the patch if needed.
Changelog:
- add basic cookie support in "download" (required as GOG.com requires auth to
download games)
- add CONTROL_WAIT_VISIBLE ahk generic macro
- add CHECKBOX_SET ahk generic macro
- add generic automation for gog installer
(based on http://www.jrsoftware.org/isinfo.php)
- Add support for:
duke nukem 3d
duke nukem manhattan project
ut2004
abe's oddisee
abe's exoddus
beyond good and evil
far cry
descent 1 & 2 (single package)
Especially, please review:
- if there would be an easier-to-use way to pass cookies to wget/curl
(cookie.txt format seems overcomplex, and not supported for export in my
iceweasel: debian sid)
- if cookie works properly with curl (manpage says it should, not tested)
- _load_gog parameters. They are ugly IMO, because many are optional. But I
don't see how to do better (especially, how to extend them to include
optional SHA1 values).
- bat scripting (untested)
- posix-ish scripting (not tested outside linux with bash)
--
Vincent Pelletier
Index: wisotool
===
--- wisotool (révision 1191)
+++ wisotool (copie de travail)
@@ -337,7 +337,7 @@
}
# Download a file
-# Usage: package url [sha1sum [filename]]
+# Usage: package url [sha1sum [filename [cookies]]]
# Caches downloads in wisotoolcache/$package
download() {
if [ "$4"x != ""x ]
@@ -363,11 +363,11 @@
# [*] --read-timeout is useful on the adobe server that doesn't
# close the connection unless you tell it to (control-C or closing
# the socket)
- try wget -O "$file" -nd -c --read-timeout=300 --retry-connrefused --header "Accept-Encoding: gzip,deflate" "$2"
+ try wget -O "$file" -nd -c --read-timeout=300 --retry-connrefused --header "Accept-Encoding: gzip,deflate" ${5:+--header "Cookie: $5"} "$2"
else
# curl doesn't get filename from the location given by the server!
# fortunately, we know it
- try curl -L -o "$file" -C - --header "Accept-Encoding: gzip,deflate" "$2"
+ try curl -L -o "$file" -C - --header "Accept-Encoding: gzip,deflate" ${5:+--header "Cookie: $5"} "$2"
fi
# Need to decompress .exe's that are compressed, else cygwin fails
# Only affects cygwin, so don't barf if 'file' not installed
@@ -652,6 +652,27 @@
}
}
+
+ CONTROL_WAIT_VISIBLE(control, loops=10)
+{
+Loop, %loops%
+{
+ControlGet, visible, Visible,, %control%
+if (visible)
+{
+break
+}
+Sleep, 1000
+}
+}
+
+ CHECKBOX_SET(checkbox, state)
+{
+ControlGet, current_state, Checked,, %checkbox%
+if (state != current_state) {
+ControlClick, %checkbox%
+}
+}
__EOF__
cat helper_tmp | tr ';' '\012' | sed "s/\$/
@@ -2056,6 +2077,137 @@
#
+# Generic GOG.com installer
+# Usage: game_id game_title [other_files [adobe_control [run_command]]]
+# game_id
+# Used for main installer name and download url.
+# game_title
+# Used for AutoHotKey and installation path in bat script.
+# other_files
+# Extra installer files, in one string, space-separated.
+# adobe_control
+# If set, the control id of the configuration pannel checkbox controling
+# Adobe Reader installation.
+# Some games don't have it, some games do with different ids.
+# run_command
+# Used for bat script, relative to installation path.
+_load_gog() {
+# TODO: support SHA1 checks ? (installer verifies files)
+# TODO: test with windows
+load_autohotkey
+
+game_id="$1"
+game_title="$2"
+other_files="$3"
+adobe_control="$4"
+run_command="$5"
+
+installer_path="$WISOTOOL_CACHE/gog"
+installer="setup_$game_id.exe"
+cookie="$installer_path/auth.txt"
+
+file_id=0
+for file in $installer $other_files
+do
+file_path="$installer_path/$file"
+if ! test -f "$file_path"
+then
+if test -f "$cookie"
+then
+download "gog" "https://www.gog.com/en/download/game/$game_id/$file_id"; "" "$file"
Re: new wisotool 20100424: new verbs 3dmark2000, 3dmark2001, 3dmark03, 3dmark05, 3dmark06, baldursgate2, gta_vc, pcmark04, pcmark05, unigine_heaven
Le dimanche 25 avril 2010 01:44:03, Dan Kegel a écrit : > You can read more about it at > http://wiki.winehq.org/wisotool Nice tool. I'm trying to add support for GOG.com installers. At the moment, I can install setup_duke3d.exe unattended (I only used it as it is the smallest installer I have from GOG). I have problems supporting GOG installers which install Adobe Reader (aside from the reported crash, I'm still trying to find an elegant way to disable its installation). I should send a patch soon. On the iso & copy protection topic: It is possible to generate bin + toc images from cds with cdrdao[1] and to mount them with fuseiso[2]. This *might* improve copy protection support. No idea on how portable nor how efficient it can be. [1] Something along the lines of cdrdao read-cd --driver generic-mmc-raw --read-raw --device /dev/xxx \ foo.toc Maybe with --read-subchan too. [2] http://fuse.sourceforge.net/wiki/index.php/FuseIso -- Vincent Pelletier
Re: [7/9] msi: Implement the UnregisterMIMEInfo standard action.
Le vendredi 02 avril 2010 10:40:07, Hans Leidekker a écrit : > +MSI_RecordSetStringW( uirow, 2, mime->Extension->Extension ); I have a segfault on this line when executing GOG.com embedded Adobe Reader installer (as of duke_nukem_manhattan_project.exe, SHA1SUM 98e6056472368867d302f5dc00c6a317de96e713 at least): wine: Unhandled page fault on read access to 0x0008 at address 0x7ecf3750 (thread 0042), starting debugger... Unhandled exception: page fault on read access to 0x0008 in 32-bit code (0x7ecf3750). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7ecf3750 ESP:0033f8e0 EBP:0033f938 EFLAGS:00010202( R- -- I - - - ) EAX: EBX:7ed72e80 ECX: EDX: ESI:005630d8 EDI:00563028 Stack dump: 0x0033f8e0: 0002 7ed7f4f8 7ed5dfc6 7ed5ddeb 0x0033f8f0: f76df7e1 7ed2e89b 7ed72e80 0x0033f900: 00131f00 0055eae0 7ed5ddeb 7ed5dfc6 0x0033f910: 7ed5dfa0 00563370 7ed5df60 00131f60 0x0033f920: 7ed7f4b8 7ed7f4b8 7ecf34fb 7ed72e80 0x0033f930: 00522dc0 0044 0033f998 7ecda25e Backtrace: =>0 0x7ecf3750 ACTION_UnregisterMIMEInfo+0x260(package=0x131f00) [/home/vincent/git/wine/dlls/msi/classes.c:1516] in msi (0x0033f998) 1 0x7ecda25e ACTION_HandleStandardAction+0x1dd(package=, action="UnregisterMIMEInfo", rc=0x33f9cc, force=0x0001) [/home/vincent/git/wine/dlls/msi/action.c:7089] in msi (0x0033f9e8) Note: of-by-one line count, as I added a WARN to log mime->Extension value, which confirms the problem (3rd line): warn:msi:ACTION_UnregisterMIMEInfo Unregistering MIME type L"application/pdf" warn:msi:ACTION_UnregisterMIMEInfo Failed to delete MIME key 2 warn:msi:ACTION_UnregisterMIMEInfo mime->Extension = (nil) I believe the mime->InstallMe condition is too relaxed, as it does check mime- >Extension, but with || (reindented code, for wordwrap): > + mime->InstallMe = (mime->InstallMe || > +(mime->Class && mime->Class->Installed) || > + (mime->Extension && mime->Extension->Installed)); Regards, -- Vincent Pelletier
Re: font-shape/font-query related regression in wine 1.1.28
Le dimanche 23 août 2009 21:02:33, Hin-Tak Leung a écrit : > I don't know why a german translation would affect my environment > (LANG=en_GB.utf8) and setting LANG=C does not fix the problem. I just yesterday found a similar fix for a segfaulting "wine iexplore" on a japanese environment kde. The best I could reach with japanese locale was a "HTML" followed by squares (the one when a glyph is missing) before the segfault - probably japanese localisation of "html rendering disabled". Switching to LC_ALL=C cures the crash. Originaly, the crash was in WoW launcher (which uses web rendering for part of its window). -- Vincent Pelletier
Re: Fully automated bisecting with "git bisect run" [LWN.net]
On Wed, Feb 11, 2009 at 7:06 AM, Ben Klein wrote:
> If I understand this correctly, this is only useful when the
> regression is something that can be tested without human interaction.
> This makes it virtually useless for Wine, as most regressions involve
> loss of functionality some application.
How hard would it be to create some record/replay feature in wine ?
As ("If" ?) any user interaction has to go through wine code, there is
potentially enough data to reproduce anything, if collected.
Of course, just as Selenium and selenium scenario generators (like
http://seleniumhq.org/projects/ide/ ), it's probably not enough to
just record user action and replay it, there must be some filtering
done to make the test more robust.
Another use for such system would be (just like Selenium) automated
testing. That could ease app maintainer life, I guess.
Sure, this is non-trivial to write, probably quite intrusive (I have
no knowledge of the code involved) and maybe non-trivial to use...
--
Vincent Pelletier
Re: [try2] dinput: joydevs[id].name (EVIOCGNAME) is product name, joydevs[id].device is a path
Le Monday 09 February 2009 22:22:02 Vincent Pelletier, vous avez écrit : > Same patch as first proposed on wine-devel, no reaction so I guess it's > correct. Miss. Was to be posted on wine-patches. (I resent it there already) -- Vincent Pelletier
[try2] dinput: joydevs[id].name (EVIOCGNAME) is product name, joydevs[id].device is a path
Le Saturday 07 February 2009 14:16:15 Vincent Pelletier, vous avez écrit :
> If not, please tell me and I will extend the patch to generate a "Joystick
> %i" name, or maybe put joydevs[id].name in both fields.
Same patch as first proposed on wine-devel, no reaction so I guess it's
correct.
--
Vincent Pelletier
From 6fb680f0f630144a2b6e131af1d68921543dcf25 Mon Sep 17 00:00:00 2001
From: Vincent Pelletier
Date: Sun, 8 Feb 2009 11:28:22 +0100
Subject: dinput: joydevs[id].name (EVIOCGNAME) is product name,
joydevs[id].device is a path.
---
dlls/dinput/joystick_linuxinput.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/dlls/dinput/joystick_linuxinput.c
b/dlls/dinput/joystick_linuxinput.c
index c24ade9..c3c657c 100644
--- a/dlls/dinput/joystick_linuxinput.c
+++ b/dlls/dinput/joystick_linuxinput.c
@@ -152,6 +152,7 @@ static const IDirectInputDevice8WVtbl JoystickWvt;
struct JoyDev {
char *device;
char *name;
+ char *instance_name;
GUID guid;
int has_ff;
@@ -290,6 +291,12 @@ static void find_joydevs(void)
else
joydev.name = joydev.device;
+if (snprintf(buf, MAX_PATH, "%s evdev%d", joydev.name, i) >= 0 &&
+(joydev.instance_name = HeapAlloc(GetProcessHeap(), 0, strlen(buf)
+ 1)))
+strcpy(joydev.instance_name, buf);
+else
+joydev.instance_name = joydev.name;
+
joydev.guid = DInput_Wine_Joystick_Base_GUID;
joydev.guid.Data3 += have_joydevs;
@@ -361,8 +368,8 @@ static void
fill_joystick_dideviceinstanceA(LPDIDEVICEINSTANCEA lpddi, DWORD ver
else
lpddi->dwDevType = DIDEVTYPE_JOYSTICK | (DIDEVTYPEJOYSTICK_TRADITIONAL
<< 8);
-strcpy(lpddi->tszInstanceName, joydevs[id].name);
-strcpy(lpddi->tszProductName, joydevs[id].device);
+strcpy(lpddi->tszInstanceName, joydevs[id].instance_name);
+strcpy(lpddi->tszProductName, joydevs[id].name);
}
static void fill_joystick_dideviceinstanceW(LPDIDEVICEINSTANCEW lpddi, DWORD
version, int id)
@@ -382,8 +389,8 @@ static void
fill_joystick_dideviceinstanceW(LPDIDEVICEINSTANCEW lpddi, DWORD ver
else
lpddi->dwDevType = DIDEVTYPE_JOYSTICK | (DIDEVTYPEJOYSTICK_TRADITIONAL
<< 8);
-MultiByteToWideChar(CP_ACP, 0, joydevs[id].name, -1,
lpddi->tszInstanceName, MAX_PATH);
-MultiByteToWideChar(CP_ACP, 0, joydevs[id].device, -1,
lpddi->tszProductName, MAX_PATH);
+MultiByteToWideChar(CP_ACP, 0, joydevs[id].instance_name, -1,
lpddi->tszInstanceName, MAX_PATH);
+MultiByteToWideChar(CP_ACP, 0, joydevs[id].name, -1,
lpddi->tszProductName, MAX_PATH);
}
static BOOL joydev_enum_deviceA(DWORD dwDevType, DWORD dwFlags,
LPDIDEVICEINSTANCEA lpddi, DWORD version, int id)
--
1.5.6.5
Re: dinput: joydevs[id].name (EVIOCGNAME) is product name, joydevs[id].device is a path
Le Saturday 07 February 2009 19:25:56 Vitaliy Margolen, vous avez écrit :
> So I'd suggest copying name into both places.
Ok.
> And append "evdev?" at the end so we can tell how it's handled.
See attached patch.
First version I locally wrote only stored an additional int in joydev, but:
- maybe it's not a good idea to compute the concatenation on each
fill_joystick_dideviceinstance[AW] call
- ...I just don't know how to append to a widechar string (MSDN list of
widechar funcs)
--
Vincent Pelletier
From 6fb680f0f630144a2b6e131af1d68921543dcf25 Mon Sep 17 00:00:00 2001
From: Vincent Pelletier
Date: Sun, 8 Feb 2009 11:28:22 +0100
Subject: dinput: joydevs[id].name (EVIOCGNAME) is product name,
joydevs[id].device is a path.
---
dlls/dinput/joystick_linuxinput.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/dlls/dinput/joystick_linuxinput.c
b/dlls/dinput/joystick_linuxinput.c
index c24ade9..c3c657c 100644
--- a/dlls/dinput/joystick_linuxinput.c
+++ b/dlls/dinput/joystick_linuxinput.c
@@ -152,6 +152,7 @@ static const IDirectInputDevice8WVtbl JoystickWvt;
struct JoyDev {
char *device;
char *name;
+ char *instance_name;
GUID guid;
int has_ff;
@@ -290,6 +291,12 @@ static void find_joydevs(void)
else
joydev.name = joydev.device;
+if (snprintf(buf, MAX_PATH, "%s evdev%d", joydev.name, i) >= 0 &&
+(joydev.instance_name = HeapAlloc(GetProcessHeap(), 0, strlen(buf)
+ 1)))
+strcpy(joydev.instance_name, buf);
+else
+joydev.instance_name = joydev.name;
+
joydev.guid = DInput_Wine_Joystick_Base_GUID;
joydev.guid.Data3 += have_joydevs;
@@ -361,8 +368,8 @@ static void
fill_joystick_dideviceinstanceA(LPDIDEVICEINSTANCEA lpddi, DWORD ver
else
lpddi->dwDevType = DIDEVTYPE_JOYSTICK | (DIDEVTYPEJOYSTICK_TRADITIONAL
<< 8);
-strcpy(lpddi->tszInstanceName, joydevs[id].name);
-strcpy(lpddi->tszProductName, joydevs[id].device);
+strcpy(lpddi->tszInstanceName, joydevs[id].instance_name);
+strcpy(lpddi->tszProductName, joydevs[id].name);
}
static void fill_joystick_dideviceinstanceW(LPDIDEVICEINSTANCEW lpddi, DWORD
version, int id)
@@ -382,8 +389,8 @@ static void
fill_joystick_dideviceinstanceW(LPDIDEVICEINSTANCEW lpddi, DWORD ver
else
lpddi->dwDevType = DIDEVTYPE_JOYSTICK | (DIDEVTYPEJOYSTICK_TRADITIONAL
<< 8);
-MultiByteToWideChar(CP_ACP, 0, joydevs[id].name, -1,
lpddi->tszInstanceName, MAX_PATH);
-MultiByteToWideChar(CP_ACP, 0, joydevs[id].device, -1,
lpddi->tszProductName, MAX_PATH);
+MultiByteToWideChar(CP_ACP, 0, joydevs[id].instance_name, -1,
lpddi->tszInstanceName, MAX_PATH);
+MultiByteToWideChar(CP_ACP, 0, joydevs[id].name, -1,
lpddi->tszProductName, MAX_PATH);
}
static BOOL joydev_enum_deviceA(DWORD dwDevType, DWORD dwFlags,
LPDIDEVICEINSTANCEA lpddi, DWORD version, int id)
--
1.5.6.5
Re: dinput: Move gain support from effect to device
Le Friday 30 January 2009 02:58:34 Vitaliy Margolen, vous avez écrit :
> First why do you typecase DWORD to (int) to assign to DWORD? Second DWORD
> will always be > 0. If you want to check it against limit then just check
> it being <= 1 otherwise return error.
[...]
> You should use MulDiv instead because this can be optimized out by compiler
> into something that won't be as accurate.
I store internaly as a DWORD because of those accuracy problems.
Thanks for pointing out this function, attached patch is now more homogeneous
with existing code, and does not do any casting magic.
> You should be checking This->base.acquired instead of fd.
Right, fixed.
Also fixed in test:
- test vs. message incoherent
- typo in test message
--
Vincent Pelletier
From f7be6c024d7e888e5abc4a52100abd15ff16ff3e Mon Sep 17 00:00:00 2001
From: Vincent Pelletier
Date: Thu, 29 Jan 2009 21:26:30 +0100
Subject: Add support for device gain.
Remove support for effect gain, since it incorrectly used device gain,
and there is no effect gain available on Linux.
Add test for device gain.
---
dlls/dinput/effect_linuxinput.c | 10 ++
dlls/dinput/joystick_linuxinput.c | 37 +--
dlls/dinput/tests/joystick.c | 60 +
3 files changed, 97 insertions(+), 10 deletions(-)
diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c
index 155d800..b309af9 100644
--- a/dlls/dinput/effect_linuxinput.c
+++ b/dlls/dinput/effect_linuxinput.c
@@ -512,12 +512,6 @@ static HRESULT WINAPI LinuxInputEffectImpl_Start(
}
event.type = EV_FF;
-
-event.code = FF_GAIN;
-event.value = This->gain;
-if (write(*(This->fd), &event, sizeof(event)) == -1)
- FIXME("Failed setting gain. Error: %d \"%s\".\n", errno,
strerror(errno));
-
event.code = This->effect.id;
event.value = dwIterations;
if (write(*(This->fd), &event, sizeof(event)) == -1) {
@@ -627,8 +621,10 @@ static HRESULT WINAPI LinuxInputEffectImpl_SetParameters(
/* Gain and Sample Period settings are not supported by the linux
* event system */
-if (dwFlags & DIEP_GAIN)
+if (dwFlags & DIEP_GAIN) {
This->gain = 0x * peff->dwGain / 1;
+ TRACE("Effect gain requested but no effect gain functionality
present.\n");
+}
if (dwFlags & DIEP_SAMPLEPERIOD)
TRACE("Sample period requested but no sample period functionality
present.\n");
diff --git a/dlls/dinput/joystick_linuxinput.c
b/dlls/dinput/joystick_linuxinput.c
index e1b92f7..c24ade9 100644
--- a/dlls/dinput/joystick_linuxinput.c
+++ b/dlls/dinput/joystick_linuxinput.c
@@ -194,6 +194,7 @@ struct JoystickImpl
struct list ff_effects;
int ff_state;
int ff_autocenter;
+ int ff_gain;
};
static void fake_current_js_state(JoystickImpl *ji);
@@ -461,6 +462,7 @@ static JoystickImpl *alloc_device(REFGUID rguid, const void
*jvt, IDirectInputIm
Instead, track it with ff_autocenter, and assume it's initialy
enabled. */
newDevice->ff_autocenter = 1;
+newDevice->ff_gain = 0x;
InitializeCriticalSection(&newDevice->base.crit);
newDevice->base.crit.DebugInfo->Spare[0] = (DWORD_PTR)(__FILE__ ":
JoystickImpl*->base.crit");
@@ -670,12 +672,16 @@ static HRESULT WINAPI
JoystickAImpl_Acquire(LPDIRECTINPUTDEVICE8A iface)
}
else
{
+struct input_event event;
+
+event.type = EV_FF;
+event.code = FF_GAIN;
+event.value = This->ff_gain;
+if (write(This->joyfd, &event, sizeof(event)) == -1)
+ERR("Failed to set gain (%i): %d %s\n", This->ff_gain, errno,
strerror(errno));
if (!This->ff_autocenter)
{
-struct input_event event;
-
/* Disable autocenter. */
-event.type = EV_FF;
event.code = FF_AUTOCENTER;
event.value = 0;
if (write(This->joyfd, &event, sizeof(event)) == -1)
@@ -974,6 +980,23 @@ static HRESULT WINAPI
JoystickAImpl_SetProperty(LPDIRECTINPUTDEVICE8A iface,
fake_current_js_state(This);
break;
}
+case (DWORD_PTR)DIPROP_FFGAIN: {
+ LPCDIPROPDWORD pd = (LPCDIPROPDWORD)ph;
+
+ TRACE("DIPROP_FFGAIN(%d)\n", pd->dwData);
+ This->ff_gain = MulDiv(pd->dwData, 0x, 1);
+ if (This->base.acquired) {
+/* Update immediately. */
+struct input_event event;
+
+event.type = EV_FF;
+event.code = FF_GAIN;
+event.value = This->ff_gain;
+if (write(This->joyfd, &event, sizeof(event)) == -1)
+ ERR("Failed to set gain (%i):
Re: msadp32.acm : block align and adpcm extra data
Le Thursday 22 January 2009 16:25:42 Stefano Guidoni, vous avez écrit : > This patch solves bug 7385: > Function ADPCM_StreamSize must return a > buffer size, which is a multiple of block align. > This buffer size is > calculated taking into account input-blockalign, output-blockalign and > adpcm-samplesperblock. Hi. Excuse me for contacting you directly, but that patch didn't enter the source tree, because of the "while" loops. I've been trying for hours to guess by trial and (tons of) error the right formula not involving any "magic" number (besides 7, which is the number of bytes per channel in adpcm block header afaik), but I could not reach the right result: after ~ten seconds, the result of my computation diverges from yours, and audio starts repeating/skipping. Probably operation rounding errors. and/or integer overflows. Could you explain me how you reached that formula ? Mainly, I don't understand why there is no trace of the number of samples per seconds, nor why you multiply a plock align with another block align in the denominator of source size computation when source is adpcm. By advance, many thanks for enlightening me. -- Vincent Pelletier
Re: winejoystick.drv: Implement POV support
On Sun, Jan 18, 2009 at 5:01 AM, Austin English wrote: > Minor, but shouldn't that be 'case 17: /* Hat 0 Y */' Right. Actualy, I originally "stacked" all 4 supported hat definitions (times 2 axes, so 8 "case" lines), so I chose to only write what changed of previous line (makes the pattern more visible, I think). I removed the 6 other lines since windows API supports just one POV per joystick, and it would probably be more confusing thant anything else. Also, I realised after sending the patch that there is a very similar code to translate 2 axes to POV angles in dinput code, but with fewer C lines. Should I resend my patch with that code instead ? On another side note, I localy solved a force-feedback problem in dinput code: linux kernel checks, when modifying/deleting a force feedback effect, that it was uploaded using the same file descriptor. But, at least for MS Flight Sim 2000, the controler can be released after an effect has been sent, and before it gets updated again. My local fix is just to never close the descriptor (and also prevent opening it when it's already opened), but that's too bad to be sent. I gave a quick think at making the close conditional to the number of registered FF effects, but there doesn't seem to be any code to empty the FF list, so it does not look to be a good solution. Has anyone a better idea ? -- Vincent Pelletier
Re: wined3d: Do not treat oversized textures as failure
Le Sunday 28 December 2008 20:20:43 Vincent Pelletier, vous avez écrit : > I discussed with Thunderbird on IRC right after sending last reply. I > noticed that I was not using latest intel driver, so I'm building them atm > to give it a try. (Debian sid is quite outdated these days, because of work > on next stable, I even have to rebuild the kernel) With 2.5.1 version: GL_MAX_TEXTURE_SIZE = 2048 I reverted the patch on my local tree, and the game works fine. Maybe wine should warn for broken drivers when GL_MAX_TEXTURE_SIZE is below 1024 or something... So after all, it seems to be a non-bug. My bad. -- Vincent Pelletier
Re: wined3d: Do not treat oversized textures as failure
Le Sunday 28 December 2008 18:11:15, vous avez écrit : > Wow, that is small. Even my pretty old radeon 9000 supports 2048x2048 > textures... > > I recommend to check the max texture size on Windows(does the game work on > this card on Windows?). I'd say there's some driver problem here, 512x512 > sounds way too small for any semi-recent card. I discussed with Thunderbird on IRC right after sending last reply. I noticed that I was not using latest intel driver, so I'm building them atm to give it a try. (Debian sid is quite outdated these days, because of work on next stable, I even have to rebuild the kernel) As for windows, I don't know. I'll certainly try if the rebuild does nothing. -- Vincent Pelletier
Re: wined3d: Do not treat oversized textures as failure
Le Sunday 28 December 2008 16:53:44, vous avez écrit : > This patch is wrong; You can't use oversized surfaces for 3D texturing > because the driver doesn't support the given size. So it seems fixing the crash I get requires to make CreateSurface fail when texture is marked as oversized (currently it passes through D3DCB_CreateSurface return value, which is WINED3D_OK), and fixing the leaks. When CreateSurface returns an error, game menu stays on noticeably longer (but notover 3 seconds or so). As it still crashed, I suspected a leak so I artificially made oversized texture be accepted (to have it freed correctly). > What is the texture size limit on your card, and what texture size does the > game try to use? It tries to create a 1024x1024 texture, and my card (Intel 945GM) is limited to 512x512: glxinfo -l | grep GL_MAX_TEXTURE_SIZE GL_MAX_TEXTURE_SIZE = 512 -- Vincent Pelletier
Re: [RFC] wined3d: Avoid triggering OPENGL errors when setting point size
Le Friday 26 December 2008 22:35:18 Vincent Pelletier, vous avez écrit : > I'm not sure where to add it. I've added some line in > d3d9/tests/visual.c:pointsize_test (attached too). As I wrote that > test to succeed on wine and did not run it on any windows version, I > would be happy if someone could try it. > Note that this patch also contains a change from fix explained below > (I'm not used to git enough yet to split patches...). Patch regenerated without mipmap test change. -- Vincent Pelletier diff --git a/dlls/d3d9/tests/visual.c b/dlls/d3d9/tests/visual.c index 9bcb42f..ed883f2 100644 --- a/dlls/d3d9/tests/visual.c +++ b/dlls/d3d9/tests/visual.c @@ -8340,6 +8340,7 @@ static void pointsize_test(IDirect3DDevice9 *device) 448,64, 0.1, 512,64, 0.1, 576,64, 0.1, +640,64, 0.1, }; /* Transforms the coordinate system [-1.0;1.0]x[-1.0;1.0] to [0.0;0.0]x[640.0;480.0]. Z is untouched */ @@ -8456,6 +8457,12 @@ static void pointsize_test(IDirect3DDevice9 *device) hr = IDirect3DDevice9_SetRenderState(device, D3DRS_POINTSIZE_MIN, *((DWORD *) (&ptsizemin_orig))); ok(hr == D3D_OK, "IDirect3DDevice9_SetRenderState failed, hr=%08x\n", hr); +ptsize = 0.0; +hr = IDirect3DDevice9_SetRenderState(device, D3DRS_POINTSIZE, *((DWORD *) (&ptsize))); +ok(hr == D3D_OK, "IDirect3DDevice9_SetRenderState failed, hr=%08x\n", hr); +hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_POINTLIST, 1, &vertices[27], sizeof(float) * 3); +ok(hr == D3D_OK, "IDirect3DDevice9_DrawPrimitiveUP failed, hr=%08x\n", hr); + hr = IDirect3DDevice9_EndScene(device); ok(hr == D3D_OK, "IDirect3DDevice9_EndScene failed hr=%08x\n", hr); } @@ -8554,6 +8561,13 @@ static void pointsize_test(IDirect3DDevice9 *device) color = getPixelColor(device, 576+4, 64+4); ok(color == 0x00ff, "pSize: Pixel (448+4),(64+4) has color 0x%08x, expected 0x00ff\n", color); +color = getPixelColor(device, 640-1, 64-1); +ok(color == 0x00ff, "pSize: Pixel (640-1),(64-1) has color 0x%08x, expected 0x00ff\n", color); +color = getPixelColor(device, 640-0, 64-0); +ok(color == 0x00ff, "pSize: Pixel (640-0),(64-0) has color 0x%08x, expected 0x00ff\n", color); +color = getPixelColor(device, 640+1, 64+1); +ok(color == 0x00ff, "pSize: Pixel (640+1),(64+1) has color 0x%08x, expected 0x00ff\n", color); + hr = IDirect3DDevice9_SetRenderState(device, D3DRS_POINTSIZE, *((DWORD *) (&ptsize_orig))); ok(hr == D3D_OK, "IDirect3DDevice9_SetRenderState failed hr=%08x\n", hr); hr = IDirect3DDevice9_SetTransform(device, D3DTS_PROJECTION, &identity);
Re: wined3d: Do not treat oversized textures as failure
Le Sunday 28 December 2008 16:21:25 Vincent Pelletier, vous avez écrit : > Attached patch is enough to cure the failure in "Operation Flashpoint" when > its menu is displayed on my little i945GM card. It also fixes mipmap test in d3d9/tests/visual.c, removing the need for a patch I sent earlier which purpose was to skip mipmap test when texture allocation fails. Some other notes on IWineD3DDeviceImpl_CreateTexture: If oversize is treated as an error and return value is changed to some error code, there seems to be a memory leak: it crashes happens after a rouhly constant number of frames are rendered, but this time hr has a non-null value in IWineD3DDeviceImpl_CreateTexture. -- Vincent Pelletier
wined3d: Do not treat oversized textures as failure
Hi.
Attached patch is enough to cure the failure in "Operation Flashpoint" when
its menu is displayed on my little i945GM card.
As the oversised case is (was) explicitely treated as a failure, I think there
is some reasone for it. Does someone remember what it is for ?
Regards,
--
Vincent Pelletier
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index 36fbcba..549badc 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -869,7 +869,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_CreateTexture(IWineD3DDevice *iface, U
{
/* use the callback to create the texture surface */
hr = D3DCB_CreateSurface(This->parent, parent, tmpW, tmpH, Format, Usage, Pool, i, WINED3DCUBEMAP_FACE_POSITIVE_X, &object->surfaces[i],NULL);
-if (hr!= WINED3D_OK || ( (IWineD3DSurfaceImpl *) object->surfaces[i])->Flags & SFLAG_OVERSIZE) {
+if (hr!= WINED3D_OK) {
FIXME("Failed to create surface %p\n", object);
/* clean up */
object->surfaces[i] = NULL;
Re: wined3d: Make WARN about oversized texture output surface and texture sizes
Le Sunday 28 December 2008 15:46:46 Henri Verbeet, vous avez écrit :
> pow2Height and pow2Width are unsigned, so you'd want to use %u there.
Done, thanks.
Also, git didn't commit half of the change (I'm too used to subversion
commiting files in the state they are when changelog is saved...). They are
in attached patch.
--
Vincent Pelletier
From d02d16f5469f699a8b36f1104219c0abbd23bc4e Mon Sep 17 00:00:00 2001
From: Vincent Pelletier
Date: Sun, 28 Dec 2008 14:50:09 +0100
Subject: Make WARN about oversized texture output surface and texture size.
---
dlls/wined3d/surface.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index 67097ac..a306f2c 100644
--- a/dlls/wined3d/surface.c
+++ b/dlls/wined3d/surface.c
@@ -3865,7 +3865,7 @@ static HRESULT WINAPI IWineD3DSurfaceImpl_PrivateSetup(IWineD3DSurface *iface) {
3:WARN and return WINED3DERR_NOTAVAILABLE;
4: Create the surface, but allow it to be used only for DirectDraw Blts. Some apps(e.g. Swat 3) create textures with a Height of 16 and a Width > 3000 and blt 16x16 letter areas from them to the render target.
*/
-WARN("(%p) Creating an oversized surface\n", This);
+WARN("(%p) Creating an oversized surface: %ux%u (texture is %ux%u)\n", This, This->pow2Width, This->pow2Height, This->currentDesc.Width, This->currentDesc.Height);
This->Flags |= SFLAG_OVERSIZE;
/* This will be initialized on the first blt */
--
1.5.6.5
Re: [RFC] wined3d: Avoid triggering OPENGL errors when setting point size
Le Friday 26 December 2008 22:35:18 Vincent Pelletier, vous avez écrit :
> As I guess IWineD3DDeviceImpl_CreateTexture should then return a
> failure code, I patched it and made the test give up if texture
> allocation failed. (patch attached)
Updated to test previous return code, instead of accessing a list behin
potentially NULL pointer.
--
Vincent Pelletier
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index 36fbcba..e87af6f 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -871,6 +871,8 @@ static HRESULT WINAPI IWineD3DDeviceImpl_CreateTexture(IWineD3DDevice *iface, U
hr = D3DCB_CreateSurface(This->parent, parent, tmpW, tmpH, Format, Usage, Pool, i, WINED3DCUBEMAP_FACE_POSITIVE_X, &object->surfaces[i],NULL);
if (hr!= WINED3D_OK || ( (IWineD3DSurfaceImpl *) object->surfaces[i])->Flags & SFLAG_OVERSIZE) {
FIXME("Failed to create surface %p\n", object);
+if (hr == WINED3D_OK)
+hr = WINED3DERR_OUTOFVIDEOMEMORY;
/* clean up */
object->surfaces[i] = NULL;
IWineD3DTexture_Release((IWineD3DTexture *)object);
Re: Wine bugs e-mails/spoofing warnings
Le Friday 26 December 2008 22:40:28 Austin English, vous avez écrit : > Anyone else on gmail seeing this? It doesn't happen on all e-mails, > only once every couple days (I've got digest mode enabled): I don't have this message, probably because I didn't set any filter. But I don't receive any message I send to the list, although the option is enabled in my subscription, and although I (obviously) do receive messages of others. -- Vincent Pelletier
Re: [RFC] wined3d: Avoid triggering OPENGL errors when setting point size
Woops, re-sending to list this time...
On Wed, Dec 24, 2008 at 4:01 PM, Stefan Dösinger
wrote:
> I think henri sent a reply. He recommended to clamp the new pointsize
> instead of leaving the old one set.
Found it. Wasn't subscribed here at that time (only to -patches).
New version of previous patch is attached.
> Of course a test would be interesting too, to see how windows behaves here.
I'm not sure where to add it. I've added some line in
d3d9/tests/visual.c:pointsize_test (attached too). As I wrote that
test to succeed on wine and did not run it on any windows version, I
would be happy if someone could try it.
Note that this patch also contains a change from fix explained below
(I'm not used to git enough yet to split patches...).
Also, runing that test I had an unrelated failure in
autogen_mipmap_test because texture creation failed in
IWineD3DDeviceImpl_CreateTexture due to SFLAG_OVERSIZE being set at
D3DCB_CreateSurface return.
As I guess IWineD3DDeviceImpl_CreateTexture should then return a
failure code, I patched it and made the test give up if texture
allocation failed. (patch attached)
I'm not sure if I chose the right error code. From MSDN, it can return:
D3DERR_INVALIDCALL, D3DERR_OUTOFVIDEOMEMORY, E_OUTOFMEMORY
If this change is OK, I will submit it separately from pointsize clamping.
--
Vincent Pelletier
diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c
index e4c819d..74a883e 100644
--- a/dlls/wined3d/state.c
+++ b/dlls/wined3d/state.c
@@ -1482,6 +1482,13 @@ static void state_pscale(DWORD state, IWineD3DStateBlockImpl *stateblock, WineD3
att[0] = A.f / scaleFactor;
att[1] = B.f / scaleFactor;
att[2] = C.f / scaleFactor;
+} else {
+/* Scalling is disabled, but we must still clamp pointSize. */
+if(pointSize.f < GL_LIMITS(pointsizemin)) {
+pointSize.f = GL_LIMITS(pointsizemin);
+} else if(pointSize.f > GL_LIMITS(pointsize)) {
+pointSize.f = GL_LIMITS(pointsize);
+}
}
if(GL_SUPPORT(ARB_POINT_PARAMETERS)) {
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index 36fbcba..45e5d2c 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -871,6 +871,8 @@ static HRESULT WINAPI IWineD3DDeviceImpl_CreateTexture(IWineD3DDevice *iface, U
hr = D3DCB_CreateSurface(This->parent, parent, tmpW, tmpH, Format, Usage, Pool, i, WINED3DCUBEMAP_FACE_POSITIVE_X, &object->surfaces[i],NULL);
if (hr!= WINED3D_OK || ( (IWineD3DSurfaceImpl *) object->surfaces[i])->Flags & SFLAG_OVERSIZE) {
FIXME("Failed to create surface %p\n", object);
+if (( (IWineD3DSurfaceImpl *) object->surfaces[i])->Flags & SFLAG_OVERSIZE)
+hr = WINED3DERR_OUTOFVIDEOMEMORY;
/* clean up */
object->surfaces[i] = NULL;
IWineD3DTexture_Release((IWineD3DTexture *)object);
diff --git a/dlls/d3d9/tests/visual.c b/dlls/d3d9/tests/visual.c
index 9bcb42f..5556038 100644
--- a/dlls/d3d9/tests/visual.c
+++ b/dlls/d3d9/tests/visual.c
@@ -4188,6 +4188,10 @@ static void autogen_mipmap_test(IDirect3DDevice9 *device)
hr = IDirect3DDevice9_CreateTexture(device, 1024, 1024, 0, D3DUSAGE_AUTOGENMIPMAP,
D3DFMT_X8R8G8B8, D3DPOOL_MANAGED, &texture, 0);
ok(hr == D3D_OK, "IDirect3DDevice9_CreateTexture returned %08x\n", hr);
+if(hr != D3D_OK) {
+skip("Unable to create texture in mipmap test.\n");
+return;
+}
hr = IDirect3DTexture9_GetSurfaceLevel(texture, 0, &surface);
ok(hr == D3D_OK, "IDirect3DTexture9_GetSurfaceLevel returned %08x\n", hr);
@@ -8340,6 +8344,7 @@ static void pointsize_test(IDirect3DDevice9 *device)
448,64, 0.1,
512,64, 0.1,
576,64, 0.1,
+640,64, 0.1,
};
/* Transforms the coordinate system [-1.0;1.0]x[-1.0;1.0] to [0.0;0.0]x[640.0;480.0]. Z is untouched */
@@ -8456,6 +8461,12 @@ static void pointsize_test(IDirect3DDevice9 *device)
hr = IDirect3DDevice9_SetRenderState(device, D3DRS_POINTSIZE_MIN, *((DWORD *) (&ptsizemin_orig)));
ok(hr == D3D_OK, "IDirect3DDevice9_SetRenderState failed, hr=%08x\n", hr);
+ptsize = 0.0;
+hr = IDirect3DDevice9_SetRenderState(device, D3DRS_POINTSIZE, *((DWORD *) (&ptsize)));
+ok(hr == D3D_OK, "IDirect3DDevice9_SetRenderState failed, hr=%08x\n", hr);
+hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_POINTLIST, 1, &vertices[27], sizeof(float) * 3);
+ok(hr == D3D_OK, "IDirect3DDevice9_DrawPrimitiveUP failed, hr=%08x\n", hr);
+
hr = IDirect3DDevice9_EndScene(device);
ok(hr == D3D_OK, "IDirect3DDevice9_EndScene failed hr=%08x\n", hr);
}
@@ -8554,6 +8565,13 @@ static void pointsize_test
[RFC] wined3d: Avoid triggering OPENGL errors when setting point size
(Resent, originally sent to -patches... Sorry)
If WINED3DRS_POINTSCALEENABLE is false and WINED3DRS_POINTSIZE render state is
set to an invalid size, glPointSize will fail.
This happens in "Black & White 2", causing log/stderr to be flooded with
opengl errors.
I'm not sure if this should be fixed here, or when setting state value.
Also, maybe it should be avoided to double-check against opengl bounds when
WINED3DRS_POINTSCALEENABLE is true.
I would be happy to get some feedback on that patch.
--
Vincent Pelletier
diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c
index e4c819d..c494f56 100644
--- a/dlls/wined3d/state.c
+++ b/dlls/wined3d/state.c
@@ -1495,8 +1495,10 @@ static void state_pscale(DWORD state, IWineD3DStateBlockImpl *stateblock, WineD3
WARN("POINT_PARAMETERS not supported in this version of opengl\n");
}
-glPointSize(pointSize.f);
-checkGLcall("glPointSize(...);");
+if (pointSize.f < GL_LIMITS(pointsize) && GL_LIMITS(pointsizemin) < pointSize.f) {
+glPointSize(pointSize.f);
+checkGLcall("glPointSize(...);");
+}
}
static void state_colorwrite(DWORD state, IWineD3DStateBlockImpl *stateblock, WineD3DContext *context) {
Fix build when valgrind header is present but does not define VALGRIND_MAKE_WRITABLE
Fixes gcc error: signal_i386.o: In function `setup_exception': /home/vincent/git/wine/dlls/ntdll/signal_i386.c:940: undefined reference to `VALGRIND_MAKE_WRITABLE' collect2: ld returned 1 exit status Others uses of this constant are already checked this way. diff --git a/dlls/ntdll/signal_i386.c b/dlls/ntdll/signal_i386.c index 993936e..148c3a5 100644 --- a/dlls/ntdll/signal_i386.c +++ b/dlls/ntdll/signal_i386.c @@ -936,7 +936,7 @@ static EXCEPTION_RECORD *setup_exception( SIGCONTEXT *sigcontext, raise_func fun } stack--; /* push the stack_layout structure */ -#ifdef HAVE_VALGRIND_MEMCHECK_H +#ifdef VALGRIND_MAKE_WRITABLE VALGRIND_MAKE_WRITABLE(stack, sizeof(*stack)); #endif stack->ret_addr = (void *)0xdeadbabe; /* raise_func must not return */
Re: PATCH wine/controls/button.c paint_button() : "style" range checking
Mike Hearn wrote: The last thing we want is for logs to become even more unwieldy though, they are already large enough. Hum, right. Nevermind :$ :).
Re: PATCH wine/controls/button.c paint_button() : "style" range checking
Alexandre Julliard wrote: If you really want an assertion you should use assert(), at least then it can be compiled out. And if it's a condition that can legitimately happen, then it has to be handled properly, just adding an ERR doesn't improve anything. In this case I guess it's conceivable that the app would change the style to an invalid one, so it needs to be handled. I wanted to make it somewhat friendlier than a simple message & exit. Or I may missunderstand what assert does... At least, it could be used as a security against that "random code execution", and at most it could help devs tracking bugs. Btw, I suggest adding the source path (relative to wine's root of course) & function name in every error message, at least when run in trace mode. (I can take care of it if necessary.)
wine/controls/button.c (get_button_text) : potential memory leak
In get_button_text, the returned handle must be freed by caller (->
memory leak if it forgots about it).
That could be solved using something like :
/* BEGIN */
/* in button.c */
inline static void get_button_text(HWND hwnd, WCHAR *out, INT max_len)
{
INT len = MIN(GetWindowTextLengthW( hwnd ), max_len);
GetWindowTextW( hwnd, buffer, len + 1 );
}
/* everywhere needed */
#define MAX_BUTTON_TEXT_LEN 255 /* just as an example */
caller_func(HWND hwnd)
{
WCHAR button_text[MAX_BUTTON_TEXT_LEN]; /* can also be dynamicaly
allocated of course */
get_button_text(hwnd, button_text, MAX_BUTTON_TEXT_LEN);
/* do something with gathered string */
}
/* END */
So, why wouldn't I do it myself ? Because I'm getting lost in sources
:). I only crawl wine code for only 48 hours now... So about 5 hours of
effective crawling.
Vincent Pelletier
regedit : exporting keys
I'm curently working on #824 bug (\0 character is added to REG_MULTI_SZ registry values) and while hunting it I found that regedit uses it's own function to write to a file instead of using the RegSaveKey API. Although it shouldn't solve the bug, it should be interesting to use the API. I also got 2 bugs with the export function : - the "save as" window got a square shape, not a rectangle (right side cuted, down one too downward) - regedit always exports the whole hive, not only subkeys & values Vincent Pelletier
