Re: hhctrl.ocx: Parse HTML entities in the table of contents.
--- On Wed, 16/4/08, Tomasz Jezierski - Tefnet <[EMAIL PROTECTED]> wrote: > If you won't find entity in table and change ampersand > to another char, > you won't get infinite loop, but I'm not sure what > will happen if you > have & in help, that might trigger loop too. Do you > know any free > software in which I can craft such chm files? I don't know about "free", but the microsoft htmlhelp workshop is available for download... and you might be able to do something like that with it. It is also a good source of information, BTW. Comes with an htmlhelp API reference. (I installed it under wine last week). BTW, I keep forgetting - what is the policy about contributing code after reading MSDN and official microsoft documentation available for download such as this? I think MSDN is okay, butactual source files (including include headers) is not? ___ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/
Re: [PATCH] [WinHelp]: fix regression introduced by Dmitry's Win64 warning fixes
> > > This won't work on 64-bit. If the hash really needs to be signed (why?) > you need some extra casts. signed comparison is needed below for finding the key in the btree currently, most of the navigation in hlp files is broken because of this patch A+ > -- > Alexandre Julliard > [EMAIL PROTECTED] > > > -- -- Eric Pouech
Re: dinput: Implement DIPROP_KEYNAME property for keyboard device
Sergey Khodych wrote: >> No, there are 2 separate implementations - one ascii another unicode. During >> the object creation one would specify either ascii or unicode RIID. > > Objects IDirectInputDevice8W and IDirectInputDevice8A has function > GetProperty. This function get struct of type DIPROPSTRING as > input/output parameter in our case . This struct has output field wsz of > type WCHAR[ MAX_PATH ] and other input fields not depends of charset. > So type of returned data will be WCHAR[ MAX_PATH ] in both case. > So objects IDirectInputDevice8W and IDirectInputDevice8A has the same > implementation of function GetProperty and this implementation is for > Unicode in both case. > > I'd like to see a test for this. So far I have not seen a case when ascii and unicode COM objects return the same exact unicode structure with unicode text. And we also seen number of cases when even SDK was wrong. Not even talking about MSDN. Vitaliy
Re: dinput/tests: Add test to show dinput does not use user defined data format for keyboard.
Sergey Khodych wrote: > > +hr = IDirectInputDevice_GetDeviceState(pKeyboard, sizeof(custom_state), > custom_state); > +ok(SUCCEEDED(hr), "IDirectInputDevice_GetDeviceState(4,) failed: %s\n", > DXGetErrorString8(hr)); > +hr = IDirectInputDevice_GetDeviceState(pKeyboard, sizeof(kbd_state), > kbd_state); > +ok(hr == DIERR_INVALIDPARAM, "IDirectInputDevice_GetDeviceState(256,) > should have failed: %s\n", DXGetErrorString8(hr)); When you add tests that fail on Wine, you need to add todo_wine at front of them so "make test" will still succeed. Vitaliy.
Re: dinput: Implement DIPROP_KEYNAME property for keyboard device
> No, there are 2 separate implementations - one ascii another unicode. During > the object creation one would specify either ascii or unicode RIID. Objects IDirectInputDevice8W and IDirectInputDevice8A has function GetProperty. This function get struct of type DIPROPSTRING as input/output parameter in our case . This struct has output field wsz of type WCHAR[ MAX_PATH ] and other input fields not depends of charset. So type of returned data will be WCHAR[ MAX_PATH ] in both case. So objects IDirectInputDevice8W and IDirectInputDevice8A has the same implementation of function GetProperty and this implementation is for Unicode in both case.
Re: msxml3: Implement transformNode (try 3)
"Alistair Leslie-Hughes" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi, > Corrected issue with tests > > Changelog: > msxml3: Implement transformNode > > Best Regards > Alistair Leslie-Hughes > Anything wrong with this patch? Best Regards Alistair Leslie-Hughes
Re: dlls/fusion/assembly.c -- no-op error checks
On Wed, 16 Apr 2008, James Hawkins wrote: > Beat ya to the punch :) Better twice than not at all, to paraphrase a German saying. :-) Gerald
Re: fusion: Explicitly check for -1 for a missing table
James Hawkins wrote: > It works just fine. -1 is 4294967295 in ULONG (32bit), which is > exactly the same as offset on error (because we assigned it -1, but > the representation in memory is the same). Then use ~0 so that the purpose is clearer. Adding a define for this value would probably further increase readability of the code. > We do this several other > places in the code base. They should be changed too. -- Rob Shearman
Re: dlls/fusion/assembly.c -- no-op error checks
On Wed, Apr 16, 2008 at 12:47 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > On Wed, 16 Apr 2008, James Hawkins wrote: > > The offsets are explicity set to -1 on line 242, so the check needs to > > be for -1. It won't work at all otherwise. > > Thanks, James! I was looking for this, but must have missed it somehow. > I'm glad I Cc:d you. :-) > > Please find the real fix below. > Beat ya to the punch :) http://winehq.org/pipermail/wine-patches/2008-April/053446.html -- James Hawkins
Re: fusion: Explicitly check for -1 for a missing table
On Wed, Apr 16, 2008 at 11:51 AM, Marcus Meissner <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 16, 2008 at 11:48:31AM -0500, James Hawkins wrote: > > Hi, > > > > Changelog: > > * Explicitly check for -1 for a missing table. > > > > dlls/fusion/assembly.c |4 ++-- > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > > -- > > James Hawkins > > > diff --git a/dlls/fusion/assembly.c b/dlls/fusion/assembly.c > > index 024e611..eee889a 100644 > > --- a/dlls/fusion/assembly.c > > +++ b/dlls/fusion/assembly.c > > @@ -416,7 +416,7 @@ HRESULT assembly_get_name(ASSEMBLY *assembly, LPSTR > *name) > > ULONG offset; > > > > offset = assembly->tables[0x20].offset; /* FIXME: add constants */ > > -if (offset < 0) > > +if (offset == -1) > > return E_FAIL; > > > > asmtbl = (ASSEMBLYTABLE *)assembly_data_offset(assembly, offset); > > @@ -527,7 +527,7 @@ HRESULT assembly_get_pubkey_token(ASSEMBLY *assembly, > LPSTR *token) > > *token = NULL; > > > > offset = assembly->tables[0x20].offset; /* FIXME: add constants */ > > -if (offset < 0) > > +if (offset == -1) > > return E_FAIL; > > You should make offset "signed", or pass errors down in another way. > This will not work this way. > It works just fine. -1 is 4294967295 in ULONG (32bit), which is exactly the same as offset on error (because we assigned it -1, but the representation in memory is the same). We do this several other places in the code base. -- James Hawkins
Re: fusion: Explicitly check for -1 for a missing table
On Wed, Apr 16, 2008 at 11:48:31AM -0500, James Hawkins wrote: > Hi, > > Changelog: > * Explicitly check for -1 for a missing table. > > dlls/fusion/assembly.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > -- > James Hawkins > diff --git a/dlls/fusion/assembly.c b/dlls/fusion/assembly.c > index 024e611..eee889a 100644 > --- a/dlls/fusion/assembly.c > +++ b/dlls/fusion/assembly.c > @@ -416,7 +416,7 @@ HRESULT assembly_get_name(ASSEMBLY *assembly, LPSTR *name) > ULONG offset; > > offset = assembly->tables[0x20].offset; /* FIXME: add constants */ > -if (offset < 0) > +if (offset == -1) > return E_FAIL; > > asmtbl = (ASSEMBLYTABLE *)assembly_data_offset(assembly, offset); > @@ -527,7 +527,7 @@ HRESULT assembly_get_pubkey_token(ASSEMBLY *assembly, > LPSTR *token) > *token = NULL; > > offset = assembly->tables[0x20].offset; /* FIXME: add constants */ > -if (offset < 0) > +if (offset == -1) > return E_FAIL; You should make offset "signed", or pass errors down in another way. This will not work this way. Ciao, Marcus
Re: dlls/fusion/assembly.c -- no-op error checks
On Wed, Apr 16, 2008 at 9:28 AM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > Both offset and tables[].offset are of unsigned types, so these two > checks for errors will never trigger. > The offsets are explicity set to -1 on line 242, so the check needs to be for -1. It won't work at all otherwise. -- James Hawkins
Re: .NET 2.0 problematic DLL loading.
Stefan Dösinger <[EMAIL PROTECTED]> wrote:Many applications behave that way, and we create fake .DLL files in system32. They are real PE files from their file header, but they do not contain the implementation. When an app tries to LoadLibrary this DLL we load the builtin one instead So we just have to add the needed DLLs to the fake DLL list. We don't add one there without an application requiring it, because it makes it harder to install MS library packages. E.g. the IE6 installer fails unless the user deletes a bunch of those faked DLLs first The other problem was that it also failed attempting to find l_intl.nls. And is this list of fake DLLs application specific? Since I'm not sure what dlls all .NET 2.0 applications are going to try to search for, would we add all the DLLs that are central to windows? The program that I am using that relies on .NET requires (imm32, lz32, iphlpapi, & l_intl.nls), before it runs into an unimplemented RAS function. - Get the name you always wanted with the new y7mail email address.
Re: Including Mono within a Wine package - should Wine expect this?
Stephan Hermann skrev: > When there are people interested in going a hard way of fixing todays > situation in debian/ubuntu and other distris, please let's do it > , sane and with a plan. There's already work going on to try to get a better solution into Debian lenny. There's a new "ia32-libs-tools" package about to enter Debian unstable, which would make it possible to replace the big ia32-libs package with more fine-grained individual ia32-lib* packages. (It may not be true multiarch, but still a lot better than the current situation.)
imm32: Implement the ImmSetConversionStatus.
Tested with "MS IME 2002(imekr61.ime)", "MS IME
2003(imekr70.ime)", and "Saenaru(saenaru.ime, Korean Free IME)".
---
dlls/imm32/imm.c | 29 -
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c
index c03d6fd..6fb73d2 100644
--- a/dlls/imm32/imm.c
+++ b/dlls/imm32/imm.c
@@ -1761,16 +1761,27 @@ BOOL WINAPI ImmSetCompositionWindow(
BOOL WINAPI ImmSetConversionStatus(
HIMC hIMC, DWORD fdwConversion, DWORD fdwSentence)
{
- static int shown = 0;
+BOOL bConversion = TRUE;
+BOOL bSentence = TRUE;
+InputContextData *data = (InputContextData*)hIMC;
- if (!shown) {
- FIXME("(%p, %d, %d): stub\n",
- hIMC, fdwConversion, fdwSentence
- );
- shown = 1;
- }
- SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
- return FALSE;
+TRACE("%p %d %d\n", hIMC, fdwConversion, fdwSentence);
+
+if (!data)
+return FALSE;
+
+if ( fdwConversion != data->IMC.fdwConversion )
+{
+data->IMC.fdwConversion = fdwConversion;
+bConversion = ImmNotifyIME(hIMC, NI_CONTEXTUPDATED, 0, IMC_SETCONVERSIONMODE);
+}
+if ( fdwSentence != data->IMC.fdwSentence )
+{
+data->IMC.fdwSentence = fdwSentence;
+bSentence = ImmNotifyIME(hIMC, NI_CONTEXTUPDATED, 0, IMC_SETSENTENCEMODE);
+}
+
+return ( bConversion && bSentence );
}
/***
Re: Including Mono within a Wine package - should Wine expect this?
On Wed, 16 Apr 2008 06:52:49 -0700 Scott Ritchie <[EMAIL PROTECTED]> wrote: > Ove Kaaven wrote: > > Debian's ia32-libs package isn't an example of a whole lot. It grabs > > compiled binaries from the official Debian archive, and nowhere > > else. It isn't built on a 32-bit system. If ia32-libs had contained > > binaries that could not be built 100% automatically using Debian's > > official archive (and only the official archive), it probably > > wouldn't have gotten into Debian. Besides, ia32-libs is not meant > > to be a long-lived package, it'll go away eventually. > > > > We've been saying that for 3 years now, and we've only become MORE > dependent on ia32-libs in the process. The chief culprit, of course, > is Wine, and Wine's need to run 32 bit applications isn't going away > soon. > > Really, what Debian (and Ubuntu) need is to replace the contents of > the ia32-libs package with proper 32 versions of package (sorta like > how lib32asound and lib32z1 are now). Fixing that, however, is a bit > beyond the scope of the wine-devel list ;) The real problem with multi-arch libs is, that it's hard to maintain inside debian packages at all...not that it's difficult to compile on amd64 with -m32 , but regarding the different ways of debian/rules writing with all different maintainer ways to write Makefiles for accomplishing this tasks is the most difficult thing. When there are people interested in going a hard way of fixing todays situation in debian/ubuntu and other distris, please let's do it , sane and with a plan. Regards, \sh
Re: Trouble in compiling Wine 0.9.57 and 0.9.58 on Solaris 10 08/07
Stefan Dösinger wrote:
Am Sonntag, 13. April 2008 22:28:16 schrieb Rolf Kalbermatter:
Following link might give some details about Sun Solaris support of
infinintes
and also ideas how to solve that problem.
Yes, that would work. Any build system guru who could implement that? I think
it is not a good idea to put that into wined3d
Well, we have only one isinf call in Wine so I think it isn't worst of
creating Wine special isinf implementation. Instead I propose emulate
isinf via finite() and isnand() (both coming from ieeefp.h).
Petr
diff --git a/configure b/configure
index 01fdf19..23d8891 100755
--- a/configure
+++ b/configure
@@ -16977,6 +16977,154 @@ fi
done
+
+for ac_func in isinf
+do
+as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh`
+{ echo "$as_me:$LINENO: checking for $ac_func" >&5
+echo $ECHO_N "checking for $ac_func... $ECHO_C" >&6; }
+if { as_var=$as_ac_var; eval "test \"\${$as_var+set}\" = set"; }; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+ cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+/* Define $ac_func to an innocuous variant, in case declares $ac_func.
+ For example, HP-UX 11i declares gettimeofday. */
+#define $ac_func innocuous_$ac_func
+
+/* System header to define __stub macros and hopefully few prototypes,
+which can conflict with char $ac_func (); below.
+Prefer to if __STDC__ is defined, since
+ exists even on freestanding compilers. */
+
+#ifdef __STDC__
+# include
+#else
+# include
+#endif
+
+#undef $ac_func
+
+/* Override any GCC internal prototype to avoid an error.
+ Use char because int might match the return type of a GCC
+ builtin and then its argument prototype would still apply. */
+#ifdef __cplusplus
+extern "C"
+#endif
+char $ac_func ();
+/* The GNU C library defines this for functions which it implements
+to always fail with ENOSYS. Some functions are actually named
+something starting with __ and the normal name is an alias. */
+#if defined __stub_$ac_func || defined __stub___$ac_func
+choke me
+#endif
+
+int
+main ()
+{
+return $ac_func ();
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (ac_try="$ac_link"
+case "(($ac_try" in
+ *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+esac
+eval "echo \"\$as_me:$LINENO: $ac_try_echo\"") >&5
+ (eval "$ac_link") 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } && {
+ test -z "$ac_c_werror_flag" ||
+ test ! -s conftest.err
+ } && test -s conftest$ac_exeext &&
+ $as_test_x conftest$ac_exeext; then
+ eval "$as_ac_var=yes"
+else
+ echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ eval "$as_ac_var=no"
+fi
+
+rm -f core conftest.err conftest.$ac_objext conftest_ipa8_conftest.oo \
+ conftest$ac_exeext conftest.$ac_ext
+fi
+ac_res=`eval echo '${'$as_ac_var'}'`
+ { echo "$as_me:$LINENO: result: $ac_res" >&5
+echo "${ECHO_T}$ac_res" >&6; }
+if test `eval echo '${'$as_ac_var'}'` = yes; then
+ cat >>confdefs.h <<_ACEOF
+#define `echo "HAVE_$ac_func" | $as_tr_cpp` 1
+_ACEOF
+
+else
+ { echo "$as_me:$LINENO: checking for isinf with " >&5
+echo $ECHO_N "checking for isinf with ... $ECHO_C" >&6; }
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+#include
+int
+main ()
+{
+float f = 0.0; isinf(f)
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (ac_try="$ac_link"
+case "(($ac_try" in
+ *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+ *) ac_try_echo=$ac_try;;
+esac
+eval "echo \"\$as_me:$LINENO: $ac_try_echo\"") >&5
+ (eval "$ac_link") 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } && {
+ test -z "$ac_c_werror_flag" ||
+ test ! -s conftest.err
+ } && test -s conftest$ac_exeext &&
+ $as_test_x conftest$ac_exeext; then
+ { echo "$as_me:$LINENO: result: yes" >&5
+echo "${ECHO_T}yes" >&6; }
+
+cat >>confdefs.h <<\_ACEOF
+#define HAVE_ISINF 1
+_ACEOF
+
+else
+ echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ { echo "$as_me:$LINENO: result: no" >&5
+echo "${ECHO_T}no" >&6; }
+fi
+
+rm -f core conftest.err conftest.$ac_objext conftest_ipa8_conftest.oo \
+ conftest$ac_exeext conftest.$ac_ext
+fi
+done
+
+
if test "$ac_cv_func_dlopen" = no
then
{ echo "$as_me:$LINENO: checking for dlopen in -ldl" >&5
diff --git a/configure.ac b/configure.ac
index b5c4bf2..2d932d7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1406,6 +1406,12 @@ AC_CHECK_FUNCS(\
waitpid \
)
+dnl Check for isinf
+AC_CHECK_FUN
Re: .NET 2.0 problematic DLL loading.
Am Mittwoch, 16. April 2008 16:43:13 schrieb Rhys McGuckin: > There are two possible ways currently that I can think of, which would > potentially solve this problem: 1. Have symbolic links within the system > directory (I find this to be bad method, for multiple reasons) 2. Have some > interception of the searching for files located within the system32, to > include all of built-in dlls. Many applications behave that way, and we create fake .DLL files in system32. They are real PE files from their file header, but they do not contain the implementation. When an app tries to LoadLibrary this DLL we load the builtin one instead So we just have to add the needed DLLs to the fake DLL list. We don't add one there without an application requiring it, because it makes it harder to install MS library packages. E.g. the IE6 installer fails unless the user deletes a bunch of those faked DLLs first
Re: Strange waveOutGetDevCaps calls in winmm/tests/wave.c
> The CapsA test doesn't fail, probably since winmm wraps CapsA calls with > CapsW calls and then does memcpy. In either case, calling > waveOutGetDevCaps sith size=4 is not valid, as far as I can tell. > Theoretically, it might be in the future, though, if some small caps > structure is invented. I suggest that these tests are removed altogether: Sounds reasonable to me; please send to wine-patches. --Juan
.NET 2.0 problematic DLL loading.
In reference to bug #11973, I've the following observation. Using the native .NET 2.0 installed via winetricks, I located what is potentially a problem with the method that .NET is using to locate the DLLs that it wishes to load. The problem seems to be that .NET is attempting to locate the various DLL's it is going to use, by searching various directory paths. Once this does not occur (by placing a native DLL into the windows/system32 path) it causing a crash further down. It doesn't seem to utilize the LoadLibrary initially to locate but another function (from memory I think it NtCreateFile). With the native DLL in place it starts to process properly, at least until it runs into other files not located (as stated above). I believe that .NET 2.0 is assuming that the files are located within the directory path (this may be so that it can independently utilize application supplied DLL files - I read that WinXP supposedly uses this policy to reduce problems with DLL dependencies). This of course, totally by-passes the built-in DLL files (which should be located using this method, except that they do not exist in the paths .NET searches). There are two possible ways currently that I can think of, which would potentially solve this problem: 1. Have symbolic links within the system directory (I find this to be bad method, for multiple reasons) 2. Have some interception of the searching for files located within the system32, to include all of built-in dlls. Unfortunately, since I don't know a huge amount about Wine yet, I have no idea on how to code the second one, and I think having a patch for this, may solve quite a few problems that currently exist with using .NET based programs. - Get the name you always wanted with the new y7mail email address.
Re: Help with configure option
Alistair Leslie-Hughes wrote: > I need to add an option, HAS_TEXTCONCAT_BUG to the configure script > to check for a bug in libxml. What file(s) do I have to change? > > The file attached is an example to test for this issue. (returns -1 if > the error exists) The trouble is that because msxml3 links to a shared library, the library that the configure check is done against isn't necessarily the version that is used at runtime. (Think .debs for multiple distros and versions of those distros.) Therefore, you may have to do the check at runtime. Where that check is implemented depends on what you need to do when you discover the buggy version is in use. -- Rob Shearman
Re: Including Mono within a Wine package - should Wine expect this?
Ove Kaaven wrote: > Debian's ia32-libs package isn't an example of a whole lot. It grabs > compiled binaries from the official Debian archive, and nowhere else. It > isn't built on a 32-bit system. If ia32-libs had contained binaries that > could not be built 100% automatically using Debian's official archive > (and only the official archive), it probably wouldn't have gotten into > Debian. Besides, ia32-libs is not meant to be a long-lived package, > it'll go away eventually. > We've been saying that for 3 years now, and we've only become MORE dependent on ia32-libs in the process. The chief culprit, of course, is Wine, and Wine's need to run 32 bit applications isn't going away soon. Really, what Debian (and Ubuntu) need is to replace the contents of the ia32-libs package with proper 32 versions of package (sorta like how lib32asound and lib32z1 are now). Fixing that, however, is a bit beyond the scope of the wine-devel list ;) Thanks, Scott Ritchie
Re: [Fwd: Bug#476232: winebuild fails to build for powerpc]
Ove Kaaven <[EMAIL PROTECTED]> writes:
> @@ -368,7 +368,7 @@ void BuildSpec32File( DLLSPEC *spec )
> else
> {
> output( "\n\t.section \".init\",\"ax\"\n" );
> -output( "\tjmp 1f\n" );
> +output( "\t%s 1f\n", get_asm_branch_mnemonic() );
> output( "__wine_spec_pe_header:\n" );
> output( "\t.skip %u\n", 65536 + page_size );
> output( "1:\n" );
I don't think it makes sense to add functions that return specific asm
mnemonics, there's no guarantee that all platforms would use a single
jump instruction here. You should add a switch the way it is done for
instance in output_asm_constructor().
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [PATCH] [WinHelp]: fix regression introduced by Dmitry's Win64 warning fixes
Eric Pouech <[EMAIL PROTECTED]> writes:
> index 8181469..bf942a4 100644
> --- a/programs/winhelp/hlpfile.c
> +++ b/programs/winhelp/hlpfile.c
> @@ -158,8 +158,8 @@ HLPFILE_PAGE *HLPFILE_PageByOffset(HLPFILE* hlpfile, LONG
> offset)
> static int comp_PageByHash(void *p, const void *key,
> int leaf, void** next)
> {
> -ULONG_PTR lKey = (LONG_PTR)key;
> -ULONG_PTR lTest = GET_UINT(p, 0);
> +LONG_PTR lKey = (LONG_PTR)key;
> +LONG_PTR lTest = GET_UINT(p, 0);
This won't work on 64-bit. If the hash really needs to be signed (why?)
you need some extra casts.
--
Alexandre Julliard
[EMAIL PROTECTED]
Strange waveOutGetDevCaps calls in winmm/tests/wave.c
winmm/tests/wave.c currently contains: rc=waveOutGetDevCapsA(device,&capsA,4); ok(rc==MMSYSERR_NOERROR, "waveOutGetDevCapsA(%s): MMSYSERR_NOERROR expected, got %s\n", dev_name(device),wave_out_error(rc)); rc=waveOutGetDevCapsW(device,&capsW,4); ok(rc==MMSYSERR_NOERROR || rc==MMSYSERR_NOTSUPPORTED, "waveOutGetDevCapsW(%s): MMSYSERR_NOERROR or MMSYSERR_NOTSUPPORTED " "expected, got %s\n",dev_name(device),wave_out_error(rc)); This seems wrong to me; the last argument should be the size of the WAVEOUTCAPS structure, and there are no such structures that have size 4. The CapsW test fails with our sound driver (tlsnd) as well as Microsofts Terminal Services driver (rdpsnd). The CapsA test doesn't fail, probably since winmm wraps CapsA calls with CapsW calls and then does memcpy. In either case, calling waveOutGetDevCaps sith size=4 is not valid, as far as I can tell. Theoretically, it might be in the future, though, if some small caps structure is invented. I suggest that these tests are removed altogether: --- wave.c 29 Feb 2008 12:18:36 - 1.67 +++ wave.c 16 Apr 2008 12:03:44 - @@ -853,16 +853,6 @@ "expected, got %s\n",dev_name(device),wave_out_error(rc)); } -rc=waveOutGetDevCapsA(device,&capsA,4); -ok(rc==MMSYSERR_NOERROR, - "waveOutGetDevCapsA(%s): MMSYSERR_NOERROR expected, got %s\n", - dev_name(device),wave_out_error(rc)); - -rc=waveOutGetDevCapsW(device,&capsW,4); -ok(rc==MMSYSERR_NOERROR || rc==MMSYSERR_NOTSUPPORTED, - "waveOutGetDevCapsW(%s): MMSYSERR_NOERROR or MMSYSERR_NOTSUPPORTED " - "expected, got %s\n",dev_name(device),wave_out_error(rc)); - nameA=NULL; rc=waveOutMessage((HWAVEOUT)device, DRV_QUERYDEVICEINTERFACESIZE, (DWORD_PTR)&size, 0); Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00
Re: IMM / IME work
Wonderful! I am glad you have this working for you as well. I think this will make it much easier to test and greatly improve our IME support in WINE. -aric ByeongSik Jeon wrote: > Aric Stewart wrote: >> I have tested with windows ATOK20 (a popular Japanese IME) and >> successfully had text processing in a fully IME aware application. > Great > > I have tested with "MS IME 2002(imekr61.ime)", "MS IME > 2003(imekr70.ime)", and "Saenaru(saenaru.ime)" [1]. > These all are works with next two patches. > > Default conversion mode toggle key of Korean IME is Hangul( == XK_Hangul > == VK_Hangul). > > Regards... > > Thanks. > > [1] Saenaru, Korean Free IME, http://kldp.net/projects/saenaru/ > http://kldp.net/frs/download.php/4353/Saenaru-1.0.1.exe > > INSTALL & SETUP > $ wine Saenaru-1.0.1.exe > $ regedit wine_saenaru.reg > > Conversion mode toggle key: Shift+Space(by wine_saenaru.reg) or > Hangul(default) > >
Re: Including Mono within a Wine package - should Wine expect this?
Hi, I am almost complete with implementing mixed-mode support for Mono only some code cleanup is remaining. Note that however this still will not support MSVCRT becuase that assumes that is running on .NET Framework. Also note that applications using unmanaged API (COM interfaces and DLL exports) of .NET Framework will not be compatible with Mono because those APIs are not implemented by Mono. If my patch will be accepted you will see the changes in SVN trunk of Mono. > From: "Dan Kegel" <[EMAIL PROTECTED]> >> On Sun, Apr 13, 2008 at 11:14 PM, Roderick Colenbrander >> <[EMAIL PROTECTED]> wrote: >>> What we really need is mono's windows.forms to be layered on top of >>> gdi32 and user32 for windows controls like buttons, textboxes and so on >>> .. As lots of programs do overrides using native dlls on them, so that's >>> why it should be real windows controls with a wndproc. >>> >>> Ironically the current situation is for a part our own issue. Years ago >>> Mono's windows.forms used winelib. They moved to a managed >>> implementation because they had wine integration issues and we weren't >>> that cooperative. Further they didn't like the 2d performance much >>> (likely due to the lack of a dib engine ..). They might be reluctant to >>> Wine. >> >> Yup. We have to really get our act together, then undoing the fork >> might make sense. Undoing the fork is not that easy because the current System.Windows.Forms uses it's own rendering engine and low level parts have been completely rewritten to support platform independent rendering and message processing. It supports low level WndProc functionality but I don't know how much is it compatible with Microsoft's implementation. Kornél
Re: hhctrl.ocx: Parse HTML entities in the table of contents.
Dnia 16-04-2008, śro o godzinie 00:49 +, Hin-Tak Leung pisze:
>
>
> --- On Tue, 15/4/08, Tomasz Jezierski - Tefnet <[EMAIL PROTECTED]> wrote:
>
> > While reading this patch I found another bug:
> >
> > +if (i ==
> > sizeof(char_refs)/sizeof(char_refs[0]))
> > +{
> > +FIXME("character entity %s not
> > found\n",
> > debugstr_wn(start + 1, p - start - 1));
> > +continue;
> > +}
> >
> > I think *start should be changed to another char in that
> > case, because
> > if we will not change it, we will fall into infinite loop
> > like it
> > happens with help file in GPSTRACK from bug #6801.
>
> I have experience the infinite loop myself, but I haven't quite checked
> where it is - it happens if the table is incomplete and the code
> encounters an html entity that's not mentioned in the table. I encountered it
> when I tried to view some help pages containing german ¨aute; 's
> in another help file I happened to have around.
> (gpstrack is about french accented characters.)
>
If you won't find entity in table and change ampersand to another char,
you won't get infinite loop, but I'm not sure what will happen if you
have & in help, that might trigger loop too. Do you know any free
software in which I can craft such chm files?
