Re: configure: Disable gstreamer support if headers are not compatible with build environment. (try 2)
El 02/08/11 17:38, Octavian Voicu escribió: When building a 32-bit wine in a 64-bit build environment with default glib headers (gstreamer uses glib.h), glib 64-bit types (such as gint64 and guint64) are not properly defined, causing many compiler warnings and most likely a broken winegstreamer.dll. Although both gstreamer and glib are included in the ia32-libs package (on Ubuntu, and possibly others), the lack of a proper glibconfig.h makes the gstreamer headers unusable for 32-bit builds. My build system is a Fedora 14 x86_64, and I am affected by this. What is really happening is that, on my 64-bit system, both glib2-devel.i686 and glib2-devel.x86_64 are installed: [alex@srv64 wine-build]$ rpm -qf /usr/lib64/glib-2.0/include/glibconfig.h glib2-devel-2.26.0-2.fc14.x86_64 [alex@srv64 wine-build]$ rpm -qf /usr/lib/glib-2.0/include/glibconfig.h glib2-devel-2.26.0-2.fc14.i686 [alex@srv64 wine-build]$ Instead of shipping a single header file that uses compiler or preprocessor defines, like /usr/include/stdint.h, glib2 ships two include files, one for each architecture. The pkg-config --cflags option does not handle the concept of an architecture-dependent include file correctly (or at all), so it ends up reporting the 64-bit header even for the 32-bit build. The 32-bit header defined gint64 as signed long long, but it is defined as signed long in the 64 bit header. Therefore the bug. A workaround I am testing is to force PKG_CONFIG_PATH to the 32-bit directory for the configure and make steps: [alex@srv64 wine-build]$ pkg-config --cflags gstreamer-app-0.10 -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 [alex@srv64 wine-build]$ PKG_CONFIG_PATH=/usr/lib/pkgconfig pkg-config --cflags gstreamer-app-0.10 -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 [alex@srv64 wine-build]$ Is there any standard/known way of automating this?
Re: [2/2] oledb32/tests: Add the XP+ behaviour and mark it as todo_wine
El 10/11/10 15:02, André Hentschel escribió: That's the behaviour of XP and up: http://test.winehq.org/data/tests/oledb32:convert.html It's tricky to fix in Wine as you really don't know how much space you have in dst and assuming space breaks other tests. --- dlls/oledb32/tests/convert.c | 11 --- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/dlls/oledb32/tests/convert.c b/dlls/oledb32/tests/convert.c index b9ef71f..cdae859 100644 --- a/dlls/oledb32/tests/convert.c +++ b/dlls/oledb32/tests/convert.c @@ -1469,10 +1469,15 @@ static void test_converttostr(void) memset(dst, 0xcc, sizeof(dst)); dst_len = 0x1234; hr = IDataConvert_DataConvert(convert, DBTYPE_I2, DBTYPE_STR, 0,dst_len, src, dst, 0, 0,dst_status, 0, 0, 0); -ok(hr == DB_E_ERRORSOCCURRED, got %08x\n, hr); -ok(dst_status == DBSTATUS_E_DATAOVERFLOW, got %08x\n, dst_status); +todo_wine ok(hr == S_OK || + broken(hr == DB_E_ERRORSOCCURRED /* Win9x, WinMe, NT4 and 2k */), + got %08x\n, hr); +todo_wine ok(dst_status == DBSTATUS_S_OK || + broken(dst_status == DBSTATUS_E_DATAOVERFLOW /* Win9x, WinMe, NT4 and 2k */), + got %08x\n, dst_status); ok(dst_len == 4, got %d\n, dst_len); -ok(dst[0] == (char)0xcc, got %02x\n, dst[0]); +todo_wine ok(dst[0] == '4' || + broken(dst[0] == (char)0xcc /* Win9x, WinMe, NT4 and 2k */), got %02x\n, dst[0]); *(short *)src = 4321; memset(dst, 0xcc, sizeof(dst)); Weird. When I wrote that test, the WinXP-SP2 virtual machine did return DB_E_ERRORSOCCURRED/DBSTATUS_E_DATAOVERFLOW on this condition (available space equal to zero), and did not touch the output buffer in the process. In my opinion, Win9x behavior is actually OK, and the behavior you observe is the one that should be flagged as broken. It is hard to imagine the newer behavior (apparently assume unbounded output buffer if reported space is zero) as more correct than the Win9x behavior. I think this should be treated the same as your 1/2 patch, which flags the behavior as Vista-only brokenness.
Trouble compiling Wine tests with Cygwin
I have a VB6 application that requires oledb32 to convert from DBTYPE_VARIANT to DBTYPE_BYTES, and fails with builtin oledb32 since conversions to DBTYPE_BYTES are unimplemented. I set up a VirtualBox VM with Windows XP and the latest Cygwin in order to add a oledb32 test to show me what should be done for these conversions to DBTYPE_BYTES. However, I have trouble when running make test on dlls/oledb32/tests. I get the following: ../../../tools/winegcc/winegcc -B../../../tools/winebuild --sysroot=../../.. convert.o marshal.o convert_i.o testlist.o -o oledb32_test.exe ../../../libs/port/libwine_port.a -loleaut32 -lole32 -luser32 -lgdi32 -ladvapi32 -lkernel32 oledb32_test.BkIKxE.s: Assembler messages: oledb32_test.BkIKxE.s:5: Error: junk at end of line, first unrecognized character is `' oledb32_test.BkIKxE.s:14: Error: unknown pseudo-op: `.hidden' oledb32_test.BkIKxE.s:69: Error: unknown pseudo-op: `.hidden' oledb32_test.BkIKxE.s:74: Error: junk at end of line, first unrecognized character is `' oledb32_test.BkIKxE.s:76: Error: junk at end of line, first unrecognized character is `-' winebuild: /usr/bin/as.exe failed with status 256 winegcc: ../../../tools/winebuild/winebuild.exe failed make: *** [oledb32_test.exe] Error 2 This is the version of as that comes with the latest cygwin: GNU assembler (GNU Binutils) 2.19.51.20090704 Copyright 2008 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `i686-cygwin'. I have searched in www.winehq.org but could not find anything relevant on my problem. I have also tried to save the assembler file by using -Wb,--save-temps but I cannot make it work.
Re: Trouble compiling Wine tests with Cygwin
El 22/02/10 12:41, Austin English escribió: On Mon, Feb 22, 2010 at 11:03 AM, Alex Villacís Lasso a_villa...@palosanto.com wrote: I have a VB6 application that requires oledb32 to convert from DBTYPE_VARIANT to DBTYPE_BYTES, and fails with builtin oledb32 since conversions to DBTYPE_BYTES are unimplemented. I set up a VirtualBox VM with Windows XP and the latest Cygwin in order to add a oledb32 test to show me what should be done for these conversions to DBTYPE_BYTES. However, I have trouble when running make test on dlls/oledb32/tests. I get the following: It's not quite the answer to your question, but why not use mingw on your native OS and run the mingw created exe on windows? Thanks. I will try that. However, the Cygwin-on-Windows method used to work, and I have tried some test patches with it, so it is surprising for me that it does not work anymore.
Re: winemp3.acm: link to system libmpg123.so
Aric Stewart escribió: --- configure.ac | 12 + dlls/winemp3.acm/Makefile.in | 11 +- dlls/winemp3.acm/common.c | 261 --- dlls/winemp3.acm/dct64_i386.c | 329 dlls/winemp3.acm/decode_i386.c | 164 dlls/winemp3.acm/huffman.h | 346 - dlls/winemp3.acm/interface.c | 254 --- dlls/winemp3.acm/l2tables.h| 175 - dlls/winemp3.acm/layer1.c | 159 dlls/winemp3.acm/layer2.c | 301 dlls/winemp3.acm/layer3.c | 1613 dlls/winemp3.acm/mpegl3.c | 119 ++-- dlls/winemp3.acm/mpg123.h | 166 dlls/winemp3.acm/mpglib.h | 69 -- dlls/winemp3.acm/tabinit.c | 95 --- 15 files changed, 81 insertions(+), 3993 deletions(-) delete mode 100644 dlls/winemp3.acm/common.c delete mode 100644 dlls/winemp3.acm/dct64_i386.c delete mode 100644 dlls/winemp3.acm/decode_i386.c delete mode 100644 dlls/winemp3.acm/huffman.h delete mode 100644 dlls/winemp3.acm/interface.c delete mode 100644 dlls/winemp3.acm/l2tables.h delete mode 100644 dlls/winemp3.acm/layer1.c delete mode 100644 dlls/winemp3.acm/layer2.c delete mode 100644 dlls/winemp3.acm/layer3.c delete mode 100644 dlls/winemp3.acm/mpg123.h delete mode 100644 dlls/winemp3.acm/mpglib.h delete mode 100644 dlls/winemp3.acm/tabinit.c The libmpg123 library is not shipped in any rpmfusion repository for Fedora 10, and possibly for other distros. This means anyone who wants mp3 support would need to install libmpg123 from source. However, rpmfusion for Fedora 10 has libmad, lame and twolame. -- perl -e '$x=2.3;printf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: winemp3.acm: link to system libmpg123.so
Rosanne DiMesio escribió: On Wed, 19 Aug 2009 15:48:10 -0500 Alex Villacís Lasso a_villa...@palosanto.com wrote: The libmpg123 library is not shipped in any rpmfusion repository for Fedora 10, and possibly for other distros. This means anyone who wants mp3 support would need to install libmpg123 from source. However, rpmfusion for Fedora 10 has libmad, lame and twolame. According to rpmfind, libmpg123.so is included in the xmms-mp3 plugin packages in the rpmfusion free repository. http://rpmfind.net/linux/rpm2html/search.php?query=libmpg123.sosubmit=Search+...system=arch= Sorry, not usable. The patch needs not only the libmpg123.so file, but also the header files required for building a program that links against it. -- perl -e '$x=2.3;printf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: How do I actually write a testcase for a 16-bit API ?
Dmitry Timoshkov escribió:
Alex Villacís Lasso a_villa...@palosanto.com wrote:
I recently filed http://bugs.winehq.org/show_bug.cgi?id=18734 in
which I showed that DlgDirList is behaving incorrectly for 16-bit
apps. I also included a test program compiled with the Watcom C
compiler, as well as a patch. Then a comment appeared saying that it
should be possible to create a testcase for this API.
By creating a test I meant to have a test for 32-bit behaviour first,
then compare it with 16-bit one.
The 32-bit test is already in place in current git, and shows that the
behavior is compliant for 32-bit apps. It is at
dlls/user32/tests/listbox.c. Lines 1189 through 1219 show that
DDL_DRIVES alone implies DDL_EXCLUSIVE. Lines 1231 through 1263 show
that DDL_DRIVES|DDL_DIRECTORY does *not* imply DDL_EXCLUSIVE.
I am taking issue with lines 617 through 619 of dlls/user32/dialog16.c:
/**
* DlgDirList (USER.100)
*/
INT16 WINAPI DlgDirList16( HWND16 hDlg, LPSTR spec, INT16 idLBox,
INT16 idStatic, UINT16 attrib )
{
/* according to Win16 docs, DDL_DRIVES should make DDL_EXCLUSIVE
* be set automatically (this is different in Win32, and
* DIALOG_DlgDirList sends Win32 messages to the control,
* so do it here) */
if (attrib DDL_DRIVES) attrib |= DDL_EXCLUSIVE;
return DlgDirListA( WIN_Handle32(hDlg), spec, idLBox, idStatic,
attrib );
}
If a 16-bit test were placed in the testsuite, it would show that the
current implementation (attrib DDL_DRIVES) is incorrect, as
demonstrated by my test program. It should be attrib == DDL_DRIVES
instead. The program so far shows that the flag behavior is identical
for 16-bit and 32-bit calls.
--
perl -e '$x=2.3;printf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
How do I actually write a testcase for a 16-bit API ?
I recently filed http://bugs.winehq.org/show_bug.cgi?id=18734 in which I showed that DlgDirList is behaving incorrectly for 16-bit apps. I also included a test program compiled with the Watcom C compiler, as well as a patch. Then a comment appeared saying that it should be possible to create a testcase for this API. So I tried. At first, I thought that since this was a 16-bit API, I should be adding -Wb,--subsystem,win16 to the Makefile. However, this results in the linker complaining that it cannot find WinMain16. So I removed it. Also, I had undefined link-time references to SendMessage16 and similar (because I want everything to go through the 16-bit APIs, else the whole point of the test is lost), so I had to manually add them to the spec files for kernel32 and user32. But after doing this and getting a test program, an attempt to create the window out of the registered class fails and triggers an assertion. I have no examples of previous 16-bit tests (as opposed to 16-bit Wine dlls) to draw upon, so I don't know how to proceed correctly to test a 16-bit API in a way that convinces everyone that the patch is correct. What do you think of this? -- perl -e '$x=2.3;printf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: How do I actually write a testcase for a 16-bit API ?
Austin English escribió: On Mon, Jun 8, 2009 at 2:46 PM, Alex Villacís Lassoa_villa...@palosanto.com wrote: I recently filed http://bugs.winehq.org/show_bug.cgi?id=18734 in which I showed that DlgDirList is behaving incorrectly for 16-bit apps. I also included a test program compiled with the Watcom C compiler, as well as a patch. Then a comment appeared saying that it should be possible to create a testcase for this API. So I tried. At first, I thought that since this was a 16-bit API, I should be adding -Wb,--subsystem,win16 to the Makefile. However, this results in the linker complaining that it cannot find WinMain16. So I removed it. Also, I had undefined link-time references to SendMessage16 and similar (because I want everything to go through the 16-bit APIs, else the whole point of the test is lost), so I had to manually add them to the spec files for kernel32 and user32. But after doing this and getting a test program, an attempt to create the window out of the registered class fails and triggers an assertion. I have no examples of previous 16-bit tests (as opposed to 16-bit Wine dlls) to draw upon, so I don't know how to proceed correctly to test a 16-bit API in a way that convinces everyone that the patch is correct. What do you think of this? http://www.winehq.org/pipermail/wine-devel/2007-July/058084.html http://www.winehq.org/pipermail/wine-devel/2007-July/057917.html http://win16test.googlecode.com/ I downloaded the tests from win16test.googlecode.com , but the tarball already has a small backlog of patches that have not yet been integrated into Wine (checked with patch --dry-run). Why? I could make a patch to the testsuite from win16test.googlecode.com, but will this help at all on getting the fix integrated into Wine? -- perl -e '$x=2.3;printf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: A proposal for increased security in wine - respecting previously expressed needs
Guillaume SH escribió:
Hi wine community,
I took some time for reflexion following the thread A step in the wrong
direction, in an ocean of steps in the right direction and to the
explanations some of you kindly exposed to me.
As a follow-up I am making a proposal.
A - The proposal
A1 - The core proposal
All function callable from outside wine should implement, as the first
task they perform(1), a sanity parameter check. This check
hasn't to be systematic, only really used parameters should be checked
and only checks assuring those parameters can be safely used
the way they are in the function implementation (or in a function
called by it). Other check are superfluous and must be discarded.
So to decline the proposal operationally, I will take an example(2) :
BOOL WINAPI GetOverlappedResult(HANDLE hFile, LPOVERLAPPED
lpOverlapped, [...])
if ( lpOverlapped == NULL )
{
#Call the function ExitWineCleanlyAndAdvertiseUser
}
This call being justified by the statement, following some lines later :
status = lpOverlapped-Internal;
The function ExitWineCleanlyAndAdvertiseUser being something like that :
Result to be determined ExitWineCleanlyAndAdvertiseUser Parameters to
be determined
#1 - Advertise user outputting a message, for example : The
application you used present a defect. Using it directly expose you to some
security issue and indirectly expose others users to some other
security issue.
#2 - Cleanly release all still allocated resources
#3 - Cleanly exit wine
A2 - offering flexibility
As I have understood that wine community is willing to be able to run
all applications written for a Windows platform,
even those relying on the worse behaviours of windows, I will propose
too to add a registry key for the purpose of enabling / disabling
wine safe mode.
In this case it would make sense that safe mode is the default, with
possibility to fall-back to unsafe mode when needed.
B - Advantages / Drawbacks to the proposal
Drawback of this solution I can think of are :
1 - It is contrary to the current consensus
2 - It implies a lot of work (even if this can be done bit by bit over a
long period time, direction is what matters here)
3 - Detailed implementation of what I presented may very well not be as
simple as I imagine, or even impossible
4 - Maybe all the reasons have not been expressed in the previous
thread, thus not considered here
5 - It can go against the interest of the author of those apps relying
on Windows's bad behaviors (large firms for example)
6 - It doesn't cover all security issue in wine and it doesn't cover at
all security issue in the calling app
7 - Performance drop-down may be expected (0,01%, 0,1%, 1%, more ? I
don't know how to evaluate)
Advantage of this solution I can think of are :
1 - Top-notch level of service to user : I can be informed when I use an
unsafe software !
2 - Encouragement to software industry : I must provide some clean and
safe software or wine can judge me unsafe (=promoting best-practices)
3 - Wine is better from it, so people will have a better opinion of wine
4 - Goal reached by wine are far beyond Windows behaviours on free-OS
platform
5 - Wine is safer so more people will want to use it and to promote its
usage
I think I will go no further than this proposal, so I leave the rest to you,
from simply ignoring it to demonstrate me than I'm wrong or applying a
variation,
Guillaume
(1) TRACE, variable declaration or other task may come before though
(2) Please don't argue about the coding style, I am not a technical expert
(unlike you) and it would be off-topic
I think I remember a discussion about a particular bug in which some
version of an installer (InstallShield?) refused to work correctly
because the wine version of one API call was checking a pointer
parameter against NULL and returning an error code instead of crashing.
If I recall correctly, it turned out that the installer *expected* the
crash, and depended on the fault handler executing some code for its
correct operation. So the NULL check was removed, the API now crashes
with the invalid pointer (exactly like native) and that installer now
works correctly. Maybe somebody who was involved in the actual fix can
dig up a pointer to the relevant thread.
How would your proposal work in this case? Instead of the installer
working normally (from the point of view of the user), wine now would
show an unexpected popup with some message. Most probably the user won't
read the message. Instead, he or she will complain that wine now has a
regression and refuses to install program XYZ.
Regarding encouraging best practices, this won't work for the zillion
Windows programs already written for Windows that people might want to
try
Re: richedit: do not read actual scrollbar state for scrollbar update, use internal state instead
Alex Villacís Lasso escribió: This is supposed to be a fix for bug #12311 . This bug involves a recursive message loop where the application forces visibility of scrollbars for the richedit control, which causes a WM_SIZE that triggers an update of the window size and re-hiding of the scrollbar. However, just after exiting the richedit winproc, the app forces visibility again, which again triggers a WM_SIZE, and so on. Native is oblivious to the fact that an external agent is messing with the scrollbar visibility, and is therefore unaffected by recursion. This patch attempts to fix this behavior in builtin and test for it. I have tried to test it on WinXP-SP2 and Win98, but testing on other platforms is helpful too. Changelog: * Use internal copy of scrollbar state instead of directly reading state from scrollbars, just as native does. * Tests for ability to externally modify scrollbars. * Test for behavior that caused recursion until builtin richedit was fixed. Nobody has commented on this patch. Is this the wrong strategy to solve the problem? Or are tests failing in some other platform? Copy of patch at bug #12311 with downloadable app to test. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
richedit: do not read actual scrollbar state for scrollbar update, use internal state instead
This is supposed to be a fix for bug #12311 . This bug involves a
recursive message loop where the application forces visibility of
scrollbars for the richedit control, which causes a WM_SIZE that
triggers an update of the window size and re-hiding of the scrollbar.
However, just after exiting the richedit winproc, the app forces
visibility again, which again triggers a WM_SIZE, and so on. Native is
oblivious to the fact that an external agent is messing with the
scrollbar visibility, and is therefore unaffected by recursion. This
patch attempts to fix this behavior in builtin and test for it. I have
tried to test it on WinXP-SP2 and Win98, but testing on other platforms
is helpful too.
Changelog:
* Use internal copy of scrollbar state instead of directly reading state
from scrollbars, just as native does.
* Tests for ability to externally modify scrollbars.
* Test for behavior that caused recursion until builtin richedit was fixed.
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
From b245faf80aa1b535b107a42ed5303f500d28eef0 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Alex=20Villac=C3=ADs=20Lasso?= [EMAIL PROTECTED]
Date: Mon, 30 Jun 2008 00:13:53 -0500
Subject: [PATCH] richedit: do not read actual scrollbar state for scrollbar update, use internal state instead.
Some applications have never heard of ES_DISABLENOSCROLL and attempt to force scrollbars to be always shown (with ShowScrollBar() or similar) when otherwise richedit would hide them. If richedit attempts to wrestle control back, a recursive loop of requests can result if app overrides WM_SIZE behavior. Apparently native never reads the scrollbar state, and operates from some sort of internal state, so that scrollbars can be modified externally without native trying to wrestle back control. This is confirmed by attached tests. An exception: EM_SCROLL will restore visibility to a scrollbar that was forcibly hidden.
---
dlls/riched20/editor.c | 21 ++
dlls/riched20/editstr.h |3 +
dlls/riched20/paint.c| 36 ++-
dlls/riched20/tests/editor.c | 794 ++
4 files changed, 844 insertions(+), 10 deletions(-)
diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c
index 28850f9..bff1642 100644
--- a/dlls/riched20/editor.c
+++ b/dlls/riched20/editor.c
@@ -1704,6 +1704,13 @@ ME_TextEditor *ME_MakeEditor(HWND hWnd) {
ed-notified_cr.cpMin = ed-notified_cr.cpMax = 0;
+ /* Default vertical scrollbar information */
+ ed-vert_si.cbSize = sizeof(SCROLLINFO);
+ ed-vert_si.nMin = 0;
+ ed-vert_si.nMax = 0;
+ ed-vert_si.nPage = 0;
+ ed-vert_si.nPos = 0;
+
return ed;
}
@@ -2948,15 +2955,29 @@ static LRESULT RichEditWndProc_common(HWND hWnd, UINT msg, WPARAM wParam,
return (wParam = 0x4) ? 0 : MAKELONG( pt.x, pt.y );
}
case WM_CREATE:
+ {
+SCROLLINFO si;
+
GetClientRect(hWnd, editor-rcFormat);
if (GetWindowLongW(hWnd, GWL_STYLE) WS_HSCROLL)
{ /* Squelch the default horizontal scrollbar it would make */
ShowScrollBar(editor-hWnd, SB_HORZ, FALSE);
}
+
+si.cbSize = sizeof(si);
+si.fMask = SIF_PAGE | SIF_RANGE;
+if (GetWindowLongW(hWnd, GWL_STYLE) ES_DISABLENOSCROLL)
+ si.fMask |= SIF_DISABLENOSCROLL;
+si.nMax = (si.fMask SIF_DISABLENOSCROLL) ? 1 : 0;
+si.nMin = 0;
+si.nPage = 0;
+SetScrollInfo(hWnd, SB_VERT, si, TRUE);
+
ME_CommitUndo(editor);
ME_WrapMarkedParagraphs(editor);
ME_MoveCaret(editor);
return 0;
+ }
case WM_DESTROY:
ME_DestroyEditor(editor);
SetWindowLongPtrW(hWnd, 0, 0);
diff --git a/dlls/riched20/editstr.h b/dlls/riched20/editstr.h
index d54edbf..9aac087 100644
--- a/dlls/riched20/editstr.h
+++ b/dlls/riched20/editstr.h
@@ -335,6 +335,9 @@ typedef struct tagME_TextEditor
/* Track previous notified selection */
CHARRANGE notified_cr;
+
+ /* Cache previously set vertical scrollbar info */
+ SCROLLINFO vert_si;
} ME_TextEditor;
typedef struct tagME_Context
diff --git a/dlls/riched20/paint.c b/dlls/riched20/paint.c
index 95befbc..f073aa7 100644
--- a/dlls/riched20/paint.c
+++ b/dlls/riched20/paint.c
@@ -640,6 +640,7 @@ void ME_Scroll(ME_TextEditor *editor, int value, int type)
ME_Repaint(editor);
}
+ editor-vert_si.nMax = 0;
ME_UpdateScrollBar(editor);
}
@@ -662,6 +663,14 @@ void ME_Scroll(ME_TextEditor *editor, int value, int type)
bScrollBarWasVisible = ME_GetYScrollVisible(editor);
bScrollBarWillBeVisible = editor-nHeight editor-sizeWindow.cy;
+ si.fMask = SIF_PAGE | SIF_RANGE;
+ if (GetWindowLongW(hWnd, GWL_STYLE) ES_DISABLENOSCROLL)
+si.fMask |= SIF_DISABLENOSCROLL;
+ if ((si.fMask SIF_DISABLENOSCROLL))
+ {
+bScrollBarWillBeVisible = TRUE;
+ }
+
if (bScrollBarWasVisible != bScrollBarWillBeVisible)
{
ShowScrollBar(hWnd, SB_VERT, bScrollBarWillBeVisible);
@@ -669,17 +678,27 @@ void ME_Scroll(ME_TextEditor *editor, int value, int type)
user32: Add additional tests for scroll state, make them pass under Wine
This patch adds a few tests for scrollbar behavior in Windows. It shows
that if the window was created with at least WS_VSCROLL or WS_HSCROLL
styles, WinXP returns default information for scrollbar range, but Win98
returns an error, until first initialized. This error does not change if
styles are set or cleared before initializing ranges. On both versions,
setting either scrollbar range automatically initializes both if
required (Wine still returned error for the other scrollbar - fix
included). I have tried to test this on Win98 and WinXP-SP2, but maybe
other versions are different. Could you please test this patch? Also, is
it OK to tell apart Win9x vs. WinXP behavior in the way it is done in
this patch? Once either behavior is identified, it is consistent on all
future tests, as shown by the tests. Wine fixed to implement Win98 behavior.
Changelog:
* Document and test differences between WinXP and Win98 scrollbar behavior
* Make tests pass under Wine (Win98 behavior)
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
From b76e90dbc6905daf76ec0df957bc93965f22464a Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Alex=20Villac=C3=ADs=20Lasso?= [EMAIL PROTECTED]
Date: Sun, 29 Jun 2008 12:40:10 -0500
Subject: [PATCH] user32: Add additional tests for scroll state, make them pass under Wine.
---
dlls/user32/scroll.c | 36 +--
dlls/user32/tests/scroll.c | 273
2 files changed, 300 insertions(+), 9 deletions(-)
diff --git a/dlls/user32/scroll.c b/dlls/user32/scroll.c
index ddfacd6..e116357 100644
--- a/dlls/user32/scroll.c
+++ b/dlls/user32/scroll.c
@@ -140,6 +140,22 @@ static inline BOOL SCROLL_ScrollInfoValid( LPCSCROLLINFO info )
info-cbSize != sizeof(*info) - sizeof(info-nTrackPos)));
}
+static SCROLLBAR_INFO *SCROLL_AllocateInternalInfo(void)
+{
+SCROLLBAR_INFO *infoPtr;
+
+infoPtr = HeapAlloc( GetProcessHeap(), 0, sizeof(SCROLLBAR_INFO) );
+if (infoPtr)
+{
+/* Set default values */
+infoPtr-minVal = infoPtr-curVal = infoPtr-page = 0;
+/* From MSDN: max for a standard scroll bar is 100 by default. */
+infoPtr-maxVal = 100;
+/* Scroll bar is enabled by default after create */
+infoPtr-flags = ESB_ENABLE_BOTH;
+}
+return infoPtr;
+}
/***
* SCROLL_GetInternalInfo
@@ -166,16 +182,18 @@ static SCROLLBAR_INFO *SCROLL_GetInternalInfo( HWND hwnd, INT nBar, BOOL alloc )
{
if (nBar != SB_HORZ nBar != SB_VERT)
WARN(Cannot initialize nBar=%d\n,nBar);
-else if ((infoPtr = HeapAlloc( GetProcessHeap(), 0, sizeof(SCROLLBAR_INFO) )))
+else if ((infoPtr = SCROLL_AllocateInternalInfo()) != NULL)
{
-/* Set default values */
-infoPtr-minVal = infoPtr-curVal = infoPtr-page = 0;
-/* From MSDN: max for a standard scroll bar is 100 by default. */
-infoPtr-maxVal = 100;
-/* Scroll bar is enabled by default after create */
-infoPtr-flags = ESB_ENABLE_BOTH;
-if (nBar == SB_HORZ) wndPtr-pHScroll = infoPtr;
-else wndPtr-pVScroll = infoPtr;
+if (nBar == SB_HORZ)
+{
+wndPtr-pHScroll = infoPtr;
+if (!wndPtr-pVScroll) wndPtr-pVScroll = SCROLL_AllocateInternalInfo();
+}
+else
+{
+wndPtr-pVScroll = infoPtr;
+if (!wndPtr-pHScroll) wndPtr-pHScroll = SCROLL_AllocateInternalInfo();
+}
}
}
WIN_ReleasePtr( wndPtr );
diff --git a/dlls/user32/tests/scroll.c b/dlls/user32/tests/scroll.c
index 3bc407a..7b388ca 100644
--- a/dlls/user32/tests/scroll.c
+++ b/dlls/user32/tests/scroll.c
@@ -127,6 +127,219 @@ static void scrollbar_test3(void)
}
+static void scrollbar_test4(int fnBar, BOOL hBarEnabled, BOOL vBarEnabled)
+{
+SCROLLINFO si;
+LRESULT r;
+BOOL r2;
+BOOL behavior_winxp = FALSE;
+BOOL behavior_win98 = FALSE;
+
+r = GetWindowLongA(hMainWnd, GWL_STYLE);
+ok(((r WS_HSCROLL) != 0) == hBarEnabled,
+Unexpected WS_HSCROLL style, found %d expected %d\n,
+((r WS_HSCROLL) != 0), hBarEnabled);
+ok(((r WS_VSCROLL) != 0) == vBarEnabled,
+Unexpected WS_VSCROLL style, found %d expected %d\n,
+((r WS_VSCROLL) != 0), vBarEnabled);
+
+trace(Testing bar type %d with initial style (%d,%d)\n, fnBar, hBarEnabled, vBarEnabled);
+
+si.cbSize = sizeof(si);
+si.fMask = SIF_RANGE | SIF_PAGE | SIF_POS;
+si.nMin = si.nMax = si.nPos = si.nPage = 0xdeadbeef;
+SetLastError(0xdeadbeef);
+r2 = GetScrollInfo(hMainWnd, fnBar, si);
+r = GetLastError();
+if (!(hBarEnabled || vBarEnabled)) {
+ok(!r2, GetScrollInfo incorrectly succeeded\n);
+ok(( r == ERROR_NO_SCROLLBARS /* WinXP */
+|| r ==
Re: user32: Add additional tests for scroll state, make them pass under Wine
Why in the world would you implement Win98 behavior over WinXP,
especially since the WinXP behavior is more logical and (probably,
haven't looked) stated on msdn?
I did not implement Win98 behavior - it was already implemented that way
in Wine, except for one difference that was found and changed to be
consistent. Having said that, I agree that it is better to implement the
WinXP behavior. I will do that in a future patch.
Reece Dunn escribió:
2008/6/30 James Hawkins [EMAIL PROTECTED]:
On Mon, Jun 30, 2008 at 3:34 PM, Alex Villacís Lasso
[EMAIL PROTECTED] wrote:
...
+ok(si.nMin == 0xdeadbeef, si.nMin == 0x%x, expected
0xdeadbeef\n, si.nMin);
+ok(si.nMax == 0xdeadbeef, si.nMax == 0x%x, expected
0xdeadbeef\n, si.nMax);
+ok(si.nPos == 0xdeadbeef, si.nPos == 0x%x, expected
0xdeadbeef\n, si.nPos);
+ok(si.nPage == 0xdeadbeef, si.nPage == 0x%x, expected
0xdeadbeef\n, si.nPage);
+
+if (r == ERROR_NO_SCROLLBARS) behavior_winxp = TRUE;
+if (r == 0xdeadbeef) behavior_win98 = TRUE;
+} else {
+if (r2) {
+ok(si.nMin == 0, si.nMin == %d, expected 0\n, si.nMin);
+ok(si.nMax == 100, si.nMax == %d, expected 100\n, si.nMax);
+ok(si.nPos == 0, si.nPos == %d, expected 0\n, si.nPos);
+ok(si.nPage == 0, si.nPage == %d, expected 0\n, si.nPage);
+
+behavior_winxp = TRUE;
+} else {
+ok(r == 0xdeadbeef, GetScrollInfo failed, error is %ld
(0x%08lx) expected 0xdeadbeef\n, r, r);
+
+behavior_win98 = TRUE;
+}
+}
This is seriously complex (in a bad way). I think you've tried to
factor too much into one function. You don't need to set and check
the version, just test for both cases that are expected, like all the
other tests:
ok(si.nMin == 0 ||
si.nMin == 0xdeadbeef, si.nMin == 0x%x, expected 0 or
0xdeadbeef\n, si.nMin);
Francois Gouget also implemented a broken() method so you can get Wine
to do the right thing, something like:
ok(si.nMin == 0 /* XP */ ||
broken(si.nMin == 0xdeadbeef) /* 98 */ ,
si.nMin == 0x%x, expected 0 or 0xdeadbeef\n, si.nMin);
- Reece
Thanks for the reminder. I will use it.
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: Some conformance tests a bit slow under Valgrind
Dan Kegel escribió: Under Valgrind, on my nice fast e7200 system, the entire suite of tests takes about three hours to run. The slowest ten percent of the tests take over a third of the runtime. riched20's editor.c in particular spends way too long (I think) on test_EM_AUTOURLDETECT. The min, median, and max times to run a test are 10 seconds, 19 seconds, and 15 minutes. 15:44.05elapsed riched20.dll editor.c 6:35.94elapsed d3d9.dll visual.c 5:45.43elapsed shell32.dll shlexec.c 3:28.98elapsed kernel32.dll process.c 2:49.85elapsed winmm.dll wave.c 2:32.18elapsed kernel32.dll debugger.c 2:14.41elapsed gdiplus.dll font.c 1:44.54elapsed dsound.dll capture.c 1:29.51elapsed mshtml.dll dom.c ... 0:18.84elapsed shlwapi.dll path.c 0:18.83elapsed rpcrt4.dll cstub.c ... 0:09.92elapsed ntdll.dll path.c 0:09.92elapsed msvcrt.dll data.c I guess I'm not complaining, but perhaps we could tone down test_EM_AUTOURLDETECT a bit. I agree that the tests could be toned down. I am open to suggestions on what kind of toning down should be implemented. Personally, I would keep full testing for WM_SETTEXT, but use just one valid URL for the rest of the messages (WM_CHAR, EM_SETTEXTEX, EM_REPLACESEL). All of the known delimiters should still be tested in full. Also, there should be a way to re-enable full testing for all cases, maybe through an enviroment variable. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: richedit: Implemented EM_STOPGROUPTYPING, fixed undo grouping (with tests)
James McKenzie escribió: This patch has the corresponding test. Could you please send a patch (one or more) that would test the behaviors fixed by the previous patches? This will make it more likely for AJ to accept the patches, and will also prevent someone (such as myself) from accidentally breaking fixed behavior with further changes. Alex: You are talking about fixing things. I was fixing EM_FONTRANGE before 1.0 as it breaks several things. Are you looking to pick this up as one of the things you are going to fix? James McKenzie I am assuming you meant EM_FORMATRANGE, since a MSDN search for EM_FONTRANGE yielded nothing, but Google yielded an old patch by you for EM_FORMATRANGE. I was not planning to tackle EM_FORMATRANGE for the moment. My plans involving riched20 in Wine (barring the fixing of any more regressions) were to prepare a patch to tone down the EM_AUTOURLDETECT tests, then to take a look at the valgrind report from Dan Kegel, then to investigate and prepare tests for the scrollbar recursion problem for bug #12311, and finally to investigate horizontal scrolling support in richedit, which is apparently completely unimplemented (not a single call to SetScrollInfo(SB_HORZ), for example). Does this help? -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
richedit: fix failing EM_GETCHARFORMAT test on all platforms
Default richedit font (System) in Windows causes native richedit to report CFM_BOLD as always set, regardless of selection, or previous calls to EM_SETCHARFORMAT. Switch to Courier New in order to see that richedit really sets the CFM_BOLD attribute in the correct selection. This fix was successful in removing failure in WinXP-SP2 (real machine) and in Win98 (QEMU virtual machine). However, could you please test on other platforms (win2k, win2k3, Vista) to see whether it removes the failure there too? I want to be extra sure that this test actually passes on all platforms. Changelog: * Fix failing EM_GETCHARFORMAT test on all platforms -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);' From a36e56af7080219ab6f762da210af2d81edd7a27 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Alex=20Villac=C3=ADs=20Lasso?= [EMAIL PROTECTED] Date: Wed, 25 Jun 2008 01:22:00 -0500 Subject: [PATCH] richedit: fix failing EM_GETCHARFORMAT test on all platforms. Default richedit font (System) in Windows causes richedit to report CFM_BOLD as always set. Switch to Courier New in order to see that richedit really sets the CFM_BOLD attribute in the correct selection. --- dlls/riched20/tests/editor.c | 32 ++-- 1 files changed, 30 insertions(+), 2 deletions(-) diff --git a/dlls/riched20/tests/editor.c b/dlls/riched20/tests/editor.c index bbdba4d..553db86 100644 --- a/dlls/riched20/tests/editor.c +++ b/dlls/riched20/tests/editor.c @@ -657,6 +657,27 @@ static void test_EM_SETCHARFORMAT(void) hwndRichEdit = new_richedit(NULL); SendMessage(hwndRichEdit, WM_SETTEXT, 0, (LPARAM)wine); +/* Need to set a TrueType font to get consistent CFM_BOLD results */ +memset(cf2, 0, sizeof(CHARFORMAT2)); +cf2.cbSize = sizeof(CHARFORMAT2); +cf2.dwMask = CFM_FACE|CFM_WEIGHT; +cf2.dwEffects = 0; +strcpy(cf2.szFaceName, Courier New); +cf2.wWeight = FW_DONTCARE; +SendMessage(hwndRichEdit, EM_SETCHARFORMAT, SCF_ALL, (LPARAM) cf2); + +memset(cf2, 0, sizeof(CHARFORMAT2)); +cf2.cbSize = sizeof(CHARFORMAT2); +SendMessage(hwndRichEdit, EM_SETSEL, 0, 4); +SendMessage(hwndRichEdit, EM_GETCHARFORMAT, SCF_SELECTION, (LPARAM) cf2); +ok tested_effects[i] == CFE_SUBSCRIPT || tested_effects[i] == CFE_SUPERSCRIPT) + (cf2.dwMask CFM_SUPERSCRIPT) == CFM_SUPERSCRIPT) + || + (cf2.dwMask tested_effects[i]) == tested_effects[i]), +%d, cf2.dwMask == 0x%08x expected mask 0x%08x\n, i, cf2.dwMask, tested_effects[i]); +ok((cf2.dwEffects tested_effects[i]) == 0, +%d, cf2.dwEffects == 0x%08x expected effect 0x%08x clear\n, i, cf2.dwEffects, tested_effects[i]); + memset(cf2, 0, sizeof(CHARFORMAT2)); cf2.cbSize = sizeof(CHARFORMAT2); cf2.dwMask = tested_effects[i]; @@ -699,8 +720,6 @@ static void test_EM_SETCHARFORMAT(void) || (cf2.dwMask tested_effects[i]) == 0), %d, cf2.dwMask == 0x%08x expected mask 0x%08x clear\n, i, cf2.dwMask, tested_effects[i]); -ok((cf2.dwEffects tested_effects[i]) == 0, -%d, cf2.dwEffects == 0x%08x expected effect 0x%08x clear\n, i, cf2.dwEffects, tested_effects[i]); DestroyWindow(hwndRichEdit); } @@ -710,6 +729,15 @@ static void test_EM_SETCHARFORMAT(void) hwndRichEdit = new_richedit(NULL); SendMessage(hwndRichEdit, WM_SETTEXT, 0, (LPARAM)wine); +/* Need to set a TrueType font to get consistent CFM_BOLD results */ +memset(cf2, 0, sizeof(CHARFORMAT2)); +cf2.cbSize = sizeof(CHARFORMAT2); +cf2.dwMask = CFM_FACE|CFM_WEIGHT; +cf2.dwEffects = 0; +strcpy(cf2.szFaceName, Courier New); +cf2.wWeight = FW_DONTCARE; +SendMessage(hwndRichEdit, EM_SETCHARFORMAT, SCF_ALL, (LPARAM) cf2); + memset(cf2, 0, sizeof(CHARFORMAT2)); cf2.cbSize = sizeof(CHARFORMAT2); cf2.dwMask = tested_effects[i]; -- 1.5.4.1
New scroll test, help in figuring out Win9x (Was: Re: new failing tests)
James Hawkins escribió:
Hi Alex,
The following commit introduces several windows test failures across
the board in riched20:
commit 0e9ed5c10e3ac6b253712037f0b30046a5656239
Author: Alex Villacís Lasso [EMAIL PROTECTED]
Date: Sun May 11 09:54:58 2008 -0500
richedit: Empty text should result in a scroll range of 0. Tests
for this behavior.
Please take a look at the test results and either fix the tests or
send in a patch to remove them.
http://test.winehq.org
Thanks,
James Hawkins
I am trying to debug the cause of this. However, I have run into a
strange problem.
The root cause of the failing tests is that GetScrollInfo() is failing
when applied to the newly created richedit window. On Windows XP-SP2 it
fails and sets GetLastError() to ERROR_NO_SCROLLBARS. On Win9x, it
fails, but leaves the last error unset. To figure out the behavior of
the richedit scrollbars, I decided to add a test for the standard
scrollbars on a generic window, so that I have a standard to compare the
richedit windows against.
The result of this is the attached patch. What I can deduce is the
following: on window creation, the scrollbars are set to a range of 0 to
100 with page 0 and position 0, but attempts to read such ranges will
fail if the window lacks both the WS_VSCROLL and the WS_HSCROLL styles -
until a range is explicitly assigned to either scrollbar, in which it
suddenly becomes readable for both. As it stands, this test passes on
WinXP-SP2 (but not in Wine). The problem is that, on Win9x only, it
seems that the styles WS_VSCROLL and WS_HSCROLL are not being set even
when requested in the CreateWindowExA(). The end result is that on Win9x
(but not on WinXP-SP2), the following failure appears
Unexpected WS_HSCROLL style, found 0 expected 1
or
Unexpected WS_VSCROLL style, found 0 expected 1
I refuse to believe this to be a genuine difference between Win9x and
WinXP-SP2, but I cannot figure out yet what I am doing wrong. Do you
have any ideas?
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
diff --git a/dlls/user32/tests/scroll.c b/dlls/user32/tests/scroll.c
index 3bc407a..03eea9b 100644
--- a/dlls/user32/tests/scroll.c
+++ b/dlls/user32/tests/scroll.c
@@ -127,6 +127,191 @@ static void scrollbar_test3(void)
}
+static void scrollbar_test4(int fnBar, BOOL hBarEnabled, BOOL vBarEnabled)
+{
+SCROLLINFO si;
+LRESULT r;
+BOOL r2;
+
+trace(Testing bar type %d with initial style (%d,%d)\n, fnBar, hBarEnabled, vBarEnabled);
+
+r = GetWindowLongW(hMainWnd, GWL_STYLE);
+ok(((r WS_HSCROLL) != 0) == hBarEnabled,
+Unexpected WS_HSCROLL style, found %d expected %d\n,
+((r WS_HSCROLL) != 0), hBarEnabled);
+ok(((r WS_VSCROLL) != 0) == vBarEnabled,
+Unexpected WS_VSCROLL style, found %d expected %d\n,
+((r WS_VSCROLL) != 0), vBarEnabled);
+hBarEnabled = ((r WS_HSCROLL) != 0);
+vBarEnabled = ((r WS_VSCROLL) != 0);
+
+si.cbSize = sizeof(si);
+si.fMask = SIF_RANGE | SIF_PAGE | SIF_POS;
+si.nMin = si.nMax = si.nPos = si.nPage = 0xdeadbeef;
+SetLastError(0xdeadbeef);
+r2 = GetScrollInfo(hMainWnd, fnBar, si);
+r = GetLastError();
+if (!(hBarEnabled || vBarEnabled)) {
+ok(!r2, GetScrollInfo incorrectly succeeded\n);
+ok( r == ERROR_NO_SCROLLBARS /* WinXP */
+|| r == 0xdeadbeef /* Win98 */,
+GetLastError returned 0x%08lx expected 0x%08x (ERROR_NO_SCROLLBARS) or 0xdeadbeef\n,
+r, ERROR_NO_SCROLLBARS);
+ok(si.nMin == 0xdeadbeef, si.nMin == 0x%x, expected 0xdeadbeef\n, si.nMin);
+ok(si.nMax == 0xdeadbeef, si.nMax == 0x%x, expected 0xdeadbeef\n, si.nMax);
+ok(si.nPos == 0xdeadbeef, si.nPos == 0x%x, expected 0xdeadbeef\n, si.nPos);
+ok(si.nPage == 0xdeadbeef, si.nPage == 0x%x, expected 0xdeadbeef\n, si.nPage);
+} else {
+ok(r2, GetScrollInfo failed, error is %ld (0x%08lx)\n, r, r);
+ok(si.nMin == 0, si.nMin == %d, expected 0\n, si.nMin);
+ok(si.nMax == 100, si.nMax == %d, expected 100\n, si.nMax);
+ok(si.nPos == 0, si.nPos == %d, expected 0\n, si.nPos);
+ok(si.nPage == 0, si.nPage == %d, expected 0\n, si.nPage);
+}
+
+/* Merely removing the style has no effect on success of GetScrollInfo() */
+SetWindowLongW(hMainWnd, GWL_STYLE, r ~(WS_HSCROLL|WS_VSCROLL));
+si.cbSize = sizeof(si);
+si.fMask = SIF_RANGE | SIF_PAGE | SIF_POS;
+si.nMin = si.nMax = si.nPos = si.nPage = 0xdeadbeef;
+SetLastError(0xdeadbeef);
+r2 = GetScrollInfo(hMainWnd, fnBar, si);
+r = GetLastError();
+if (!(hBarEnabled || vBarEnabled)) {
+ok(!r2, GetScrollInfo incorrectly succeeded\n);
+ok( r == ERROR_NO_SCROLLBARS /* WinXP */
+|| r == 0xdeadbeef /* Win98 */,
+GetLastError returned 0x%08lx expected 0x%08x (ERROR_NO_SCROLLBARS) or 0xdeadbeef\n,
+r, ERROR_NO_SCROLLBARS);
+
Re: new failing tests
James Hawkins escribió: Hi Alex, The following commit introduces several windows test failures across the board in riched20: commit 0e9ed5c10e3ac6b253712037f0b30046a5656239 Author: Alex Villacís Lasso [EMAIL PROTECTED] Date: Sun May 11 09:54:58 2008 -0500 richedit: Empty text should result in a scroll range of 0. Tests for this behavior. Please take a look at the test results and either fix the tests or send in a patch to remove them. http://test.winehq.org Thanks, James Hawkins Hmmm... I have been doing some tests at home that suggest that native richedit never reads the actual scrollbar state (with either GetScrollInfo or GetScrollBarInfo), but caches it instead, and that when the text does not need to be scrolled, the native behavior is to hide the scrollbar, not set it to zero (so the previous scroll range of the hidden scrollbar is still externally readable). The values on win9x seem bogus, so it seems that either native leaves the scrollbars uninitialized until first use, or GetScrollInfo is failing on the richedit window. I will look into it. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: richedit: (9/8) EM_POSFROMCHAR tests
Alex Villacís Lasso escribió: Found while debugging #13864 . While it does not solve the bug, it is worthwhile to get this out of the way. EM_POSFROMCHAR can return the position of the requested character through either a pointer to a POINTL through wParam, or through the result value. When using the pointer method, native returns 0, builtin returns MAKELONG(x,y) (just like the return method). Builtin should choose one or the other, but not both at the same time. Changelog: * When returning position through wParam pointer, EM_POSFROMCHAR must return 0 as LRESULT. * Add tests for EM_POSFROMCHAR for 1.0 and 2.0. Was there something wrong with this patch? -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: richedit: Implemented EM_STOPGROUPTYPING, fixed undo grouping (with tests)
Dylan Smith escribió: EM_STOPGROUPTYPING simply ends the undo coalescing transaction. The remarks for this message on MSDN explains what events stops group typing, which led me to adding the delete key to the actions that stop group typing. The tests that are included with this patch verify the correctness of the changes. This patch depends on a previous patch I submitted, which has an email subject [6/44] richedit: Implemented undo coalescing to group typing events, and was submitted on June 17. --- dlls/riched20/editor.c | 12 ++-- dlls/riched20/tests/editor.c | 40 2 files changed, 50 insertions(+), 2 deletions(-) This patch has the corresponding test. Could you please send a patch (one or more) that would test the behaviors fixed by the previous patches? This will make it more likely for AJ to accept the patches, and will also prevent someone (such as myself) from accidentally breaking fixed behavior with further changes. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: [updated] winecfg: Added Windows registration information setting
Filipe Ferreira escribió: This is a combination of both patches from my earlier submission. The reason I made them separate was because I am unable to test other languages besides English. Though, if anyone could tell me how to run wine under a different language, I would test them. Find out the corresponding language and country code for the particular country and language combination you want to test, then run like this in a terminal: LANG=ja_JP.UTF-8 winecfg The above example runs winecfg with Japanese resources. It is what I used to run Japanese dating sims under Wine (just to test DirectSound and msacm32 support - I hereby disclaim any implied or explicit assertion of knowledge of the Japanese language). -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
About code freeze...
Wine 1.0 is out! Great! Does this mean we are now out of code freeze? I have a bunch of richedit patches I submitted previously but were held up because of the code freeze. Is it time to submit them again? -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
richedit: text that does not need scrollbar should also result in a scroll range of 0. Tests for this behavior. Try 2.
Alex Villacís Lasso escribió:
Eric Pouech escribió:
Alex Villacís Lasso a écrit :
Even though the code freeze is still in effect, I post this so that
it will be reviewed. For more information, see bug #12311.
Changelog:
* richedit: empty text should result in a scroll range of 0.
* Tests for this behavior.
what I don't understand is why the height of an empty doc is not zero
(I had similar issues with the height of a doc where we
systematically get one row too much). I believe this root cause
should be fixed instead of the band aid your patch is providing
A+
The height of the document is irrelevant. Instead, if the actual
height is less than the height of the client area, the scrollbar
should also be set to zero, as shown by tests included in the attached
patch. Empty text is just one special case.
Changelog:
* Text that does not need to be scrolled should also result in a
scroll range of zero
* Tests for this behavior
The previous version resulted in a misassignment of the range when scrollbars
forced visible but scroll range makes scrollbar visible. This version fixes it.
Changelog:
* Text that does not need to be scrolled should also result in a scroll
range of zero
* Tests for this behavior
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
diff --git a/dlls/riched20/paint.c b/dlls/riched20/paint.c
index 7bb1a01..1cddf58 100644
--- a/dlls/riched20/paint.c
+++ b/dlls/riched20/paint.c
@@ -689,15 +689,10 @@ void ME_Scroll(ME_TextEditor *editor, int value, int type)
si.nMin = 0;
- if (ME_GetTextLength(editor) 0)
+ if (editor-nTotalLength editor-sizeWindow.cy)
{
si.nMax = editor-nTotalLength;
si.nPage = editor-sizeWindow.cy;
-if (bForcedVisible)
-{
- TRACE(Setting page to max to preserve scrollbar...\n);
- si.nPage = si.nMax;
-}
} else {
si.nMax = si.nPage = 0;
if (bForcedVisible)
diff --git a/dlls/riched20/tests/editor.c b/dlls/riched20/tests/editor.c
index c17cc40..7d9bf42 100644
--- a/dlls/riched20/tests/editor.c
+++ b/dlls/riched20/tests/editor.c
@@ -1930,6 +1930,15 @@ static void test_EM_SCROLL(void)
/* test a richedit box containing a single line of text */
SendMessage(hwndRichEdit, WM_SETTEXT, 0, (LPARAM) a);/* one line of text */
+ memset(si, 0, sizeof(si));
+ si.cbSize = sizeof(si);
+ si.fMask = SIF_RANGE | SIF_PAGE | SIF_POS;
+ GetScrollInfo(hwndRichEdit, SB_VERT, si);
+ ok(si.nMin == 0, si.nMin == %d, expected 0\n, si.nMin);
+ ok(si.nMax == 0, si.nMax == %d, expected 0\n, si.nMax);
+ ok(si.nPos == 0, si.nPos == %d, expected 0\n, si.nPos);
+ ok(si.nPage == 0, si.nPage == %d, expected 0\n, si.nPage);
+
expr = 0x0001;
for (i = 0; i 4; i++) {
static const int cmd[4] = { SB_PAGEDOWN, SB_PAGEUP, SB_LINEDOWN, SB_LINEUP };
richedit: text that does not need scrollbar should also result in a scroll range of 0. Tests for this behavior.
Eric Pouech escribió:
Alex Villacís Lasso a écrit :
Even though the code freeze is still in effect, I post this so that it
will be reviewed. For more information, see bug #12311.
Changelog:
* richedit: empty text should result in a scroll range of 0.
* Tests for this behavior.
what I don't understand is why the height of an empty doc is not zero (I
had similar issues with the height of a doc where we systematically get
one row too much). I believe this root cause should be fixed instead of
the band aid your patch is providing
A+
The height of the document is irrelevant. Instead, if the actual height
is less than the height of the client area, the scrollbar should also be
set to zero, as shown by tests included in the attached patch. Empty
text is just one special case.
Changelog:
* Text that does not need to be scrolled should also result in a scroll
range of zero
* Tests for this behavior
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
diff -ur wine-orig/dlls/riched20/paint.c wine-build/dlls/riched20/paint.c
--- wine-orig/dlls/riched20/paint.c 2008-05-14 16:18:24.0 -0500
+++ wine-build/dlls/riched20/paint.c 2008-05-14 16:25:44.0 -0500
@@ -689,7 +689,7 @@
si.nMin = 0;
- if (ME_GetTextLength(editor) 0)
+ if (editor-nTotalLength editor-sizeWindow.cy)
{
si.nMax = editor-nTotalLength;
si.nPage = editor-sizeWindow.cy;
diff -ur wine-orig/dlls/riched20/tests/editor.c wine-build/dlls/riched20/tests/editor.c
--- wine-orig/dlls/riched20/tests/editor.c 2008-05-14 16:18:24.0 -0500
+++ wine-build/dlls/riched20/tests/editor.c 2008-05-14 16:20:27.0 -0500
@@ -1930,6 +1930,15 @@
/* test a richedit box containing a single line of text */
SendMessage(hwndRichEdit, WM_SETTEXT, 0, (LPARAM) a);/* one line of text */
+ memset(si, 0, sizeof(si));
+ si.cbSize = sizeof(si);
+ si.fMask = SIF_RANGE | SIF_PAGE | SIF_POS;
+ GetScrollInfo(hwndRichEdit, SB_VERT, si);
+ ok(si.nMin == 0, si.nMin == %d, expected 0\n, si.nMin);
+ ok(si.nMax == 0, si.nMax == %d, expected 0\n, si.nMax);
+ ok(si.nPos == 0, si.nPos == %d, expected 0\n, si.nPos);
+ ok(si.nPage == 0, si.nPage == %d, expected 0\n, si.nPage);
+
expr = 0x0001;
for (i = 0; i 4; i++) {
static const int cmd[4] = { SB_PAGEDOWN, SB_PAGEUP, SB_LINEDOWN, SB_LINEUP };
quartz: regression: Assertion failed at pin.c:1236
The patch: 3066116f76c0c44950fde3552485b37dce24d1f8 quartz: Clean up pullpin code. causes a regression in a test application I have. I see the following message in the console: pin.c:1236: PullPin_Init: La declaración `pCustomRequest' no se cumple. And I get an Automation error in a message box. This, every time I try to load an AVI file in a Windows Media Control. Reversing the patch gets rid of the error. I believe this patch was to be followed by a cleanup of code to ensure that no users of PullPin_Init pass a NULL pCustomRequest. However, this parameter gets passed as NULL from parser.c:92, which in turn gets it from avisplit.c, mpegsplit.c and waveparser.c, all of them with NULL as the value for the parameter. Was there supposed to be any follow-up patch for this? Why was it not committed? -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: richedit: add tests for EM_FINDTEXT in 1.0 emulation, make them pass under Wine
Alex Villacís Lasso escribió: EM_FINDTEXT and EM_FINDTEXTEX have different rules for interpreting ranges for 1.0 and 2.0 modes: In 1.0 emulation cpMin cpMax is invalid and always fails. In 1.0 emulation, search is always done between cpMin and cpMax, even backwards search. In 1.0 emulation, cpMax == -1 assumes FR_DOWN, even if not set. This goes a long way towards resolving richedit search problems in bug #709. Changelog: * Add tests for EM_FINDTEXT in 1.0 emulation, make them pass under Wine My bad, it is bug #4144 that is being addressed with this patch. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: Alex Villacís Lasso : uxtheme: Speed up UXTHEME_SizedBlt in the ST_T ILE by building an appropriately-sized me mory bitmap out of the tile instead of iterating with UXTHEME_Blt () directly
Frank Richter escribio': On 22.04.2008 13:47, Alexandre Julliard wrote: uxtheme: Speed up UXTHEME_SizedBlt in the ST_TILE by building an appropriately-sized memory bitmap out of the tile instead of iterating with UXTHEME_Blt() directly. But does that keep the alpha channel intact? -f.r. I directed my themes to the ones on the WinXP partition, and saw no difference after the patch, other than the increase in speed. However, this might not be a proper test case. I used CreateCompatibleDC out of the source HDC, and CreateCompatibleBitmap in the same way. If these operations preserve the alpha channel, and BitBlt(SRCCOPY) does too, the patch as a whole should be correct. Have you seen a theme that uses alpha and breaks with my patch? -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: installing wine into linux ubuntu
stephen cooper escribió: ref. Linux Format DVD 104 April 2008From: stephen cooper ([EMAIL PROTECTED]) I am new to Linux.I have just installed Linux UBUNTU 7.1 (gutsy) onto my computer with no problems. I want to install wine.I have written the source code onto my hard disc. (using tar ) When I run ./configure (.tools/wineinstall) I get an error - C compiler cannot create executables. I am including the output from the config.log for wine installation below. PLEASE ADVISE ME. Stephen Cooper. This file contains any messages produced by compilers whilerunning configure, to aid debugging if configure makes a mistake. It was created by Wine configure 0.9.54, which wasgenerated by GNU Autoconf 2.61. Invocation command line was It's good you are trying to build Wine. However, you need to install the appropriate development packages for Ubuntu first. Plain Ubuntu as installed from disks does not ship with enough tools to build any program in C. Also, most recent wine version as of this writing is 0.9.59, so you are already a few versions behind. You might want to try suscribing to the wine-users mailing list first. That mailing list is more appropriate for people who are starting with Wine and Linux than wine-devel. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: WINEX11.DRV: workaround for unstable window state while handling MapNotify (fixes bug 12196)
Alex Villacís Lasso escribió: The attached patch seems to fix this issue for me. It issues X11DRV_MapNotify when it detects that the window is still marked as iconic on a transition from IconicState to NormalState. Please comment on this. See bug #12196 for full discussion. Changelog: * Workaround for unstable window state when handling MapNotify at window restore after minimize. Issue extra X11DRV_MapNotify call when PropertyNotify detects still-iconic window on IconicState-NormalState transition. Is this patch incorrect? Nobody has commented on it, and it has not been applied either. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: winex11.drv: Don't add owned windows to the taskbar
Dmitry Timoshkov escribió: Alex Villacís Lasso [EMAIL PROTECTED] wrote: The problem with IDA is that the button you see in the Windows task bar does not belong to the main IDA window, it belongs to a zero sized visible window with the same caption. Since it's zero sized Wine doesn't map it all. So, while formally it's a regression, technically it's not: main IDA window has never been added to the task bar before my patch. This all can be easily discovered with spy++ and a simple test app. This also affects many, if not all, VB6 applications (and possibly many Delphi applications). Personally, I consider this a rather serious regression and propose backing out of commit cb3ff54789c652b02d852f40db71cafd9fd67ca9 as a fix. BTW, this reminds me of bug 1598. If the explanation of the bug for IDA above is correct, then the buggy behavior of not assigning minimize/maximize buttons to the window that appears in the panel is sort of consistent with this regression. Maybe the behavior should be that visible windows owned by an invisible window should get mapped in the panel. 1598 is closed as fixed, and I have no idea how missing minimize/maximize buttons are related to owned windows, and why you think that it's somehow related to the visibility of an owner. What you need to be fixed is making a zero sized window with WS_VISIBLE style set mapped, but X11/WMs doesn't handle that gracefully. Bug 1598 (even if closed and fixed) is relevant because it was also triggered by having an invisible owner window, as my own analysis in comment #16 suggested. This bug (1598) also made the window button disappear from the taskbar, with the same application that now exhibited the regression. I was just preparing a patch to fix this very issue over the weekend, but it seems Jacek Caban beat me to it. I am currently recompiling my tree to test the patch. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: winex11.drv: Don't add owned windows to the taskbar
Dmitry Timoshkov escribio': Alexander Dorofeyev [EMAIL PROTECTED] wrote: There's a regression in IDA Pro disassembler. Nothing is added to the taskbar at all, furthermore, when you are starting debugger, before there was a window appearing that asks pass control to the application or not. Now it's not appearing, and can't be found because there's nothing on the taskbar, which is pretty bad because the app doesn't respond to any other input at that moment. Minimizing the main window makes the app disappear altogether, so it's pretty unusable. The problem with IDA is that the button you see in the Windows task bar does not belong to the main IDA window, it belongs to a zero sized visible window with the same caption. Since it's zero sized Wine doesn't map it all. So, while formally it's a regression, technically it's not: main IDA window has never been added to the task bar before my patch. This all can be easily discovered with spy++ and a simple test app. This also affects many, if not all, VB6 applications (and possibly many Delphi applications). Personally, I consider this a rather serious regression and propose backing out of commit cb3ff54789c652b02d852f40db71cafd9fd67ca9 as a fix. BTW, this reminds me of bug 1598. If the explanation of the bug for IDA above is correct, then the buggy behavior of not assigning minimize/maximize buttons to the window that appears in the panel is sort of consistent with this regression. Maybe the behavior should be that visible windows owned by an invisible window should get mapped in the panel. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: question for dumps
Juan Carlos Montes escribió: I dont like change the source to use all versions of wine... but... I'll try make a debugger to dump the memory. So... thanks a lot. Stefan Dösinger escribió: Am Dienstag, 22. Januar 2008 16:19:54 schrieb Juan Carlos Montes: Hi all, I need dump the data using the debug log. trace:winsock:WSASendTo socket 00f8, wsabuf 0x34e1e0, nbufs 1, flags 0, to (nil), tolen 0, ovl (nil), func (nil) if have this one, can i dump the data in 0x34e1e0 with another option in debug, or i need change the source? You have to change the source, or attach a debugger and read the memory I think. Could you please explain *why* you need to peek into the buffer data? Is there a mismatch between what the app intends to send to the socket and the actual wire contents of the packet? Do you have a bug opened for whatever issue the app is experiencing? It seems strange that you mention making this change for *all* versions of Wine, unless I have misunderstood your comment, or somehow you are interested in dumping the data for a reason other than debugging Wine itself. BTW: se habla español (fuera de la lista de discusión). -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: GDI32: GetSystemPaletteEntries should fill with default palette in non-palette video mode (with tests)
Alex Villacís Lasso escribió: Patches originally by Alexander Dorofeyev [EMAIL PROTECTED]. This patch tries to fix bug #201 (igowin shows black squares instead of proper transparency). It was sent back in October, but there was no feedback back then. So I am resending a rediff against current git. Changelog: * GetSystemPaletteEntries() should fill entries with default 20-color system palette when called in a non-palette video mode. * Tests for above behavior. Any feedback on this patch? -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: USER32: win16 applications should not see long filenames returned from dialog control (try 4)
Alex Villacís Lasso escribió: I hope this version addresses the fact DlgDirSelect does not modify the last error code, and therefore cannot be used to distinguish between a valid and an invalid file. Changelog: * Applications should not see long filenames returned from dialog control This patch has not been applied, and has not been commented on either. Is there something wrong with it? -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: RICHED20: fix test failure in test_WM_PASTE
Alex Villacís Lasso escribió: At last! I finally found the way to make native riched20 actually obey keystrokes involving Ctrl and some other key. It seems that native riched20 checks the actual keyboard state during WM_KEYDOWN processing, and won't process keystrokes if the keyboard state does not match the messages being sent. However, with keybd_event(), native riched20 can be fooled into accepting simulated keystrokes. Changelog: * Native riched20 won't obey simple WM_CHAR or WM_KEYDOWN/WM_KEYUP messages when processing Ctrl-Key keystrokes. Use keybd_event() instead. Fixes one test failure in Win98 and WinXP-SP2. * Add more through tests to test_WM_PASTE, to check that text is actually being modified in intermediate steps. Fixes false test success in Win98 and WinXP-SP2. Additional tests pass under Win98, WinXP-SP2 and Wine. Was there something wrong with this patch? Two other patches of mine for riched20 have been committed, but not this one. As it currently stands, it removes the last test failure and also fixes a false test success in WinXP-SP2. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: [SPAM] Re: USER32: win16 applications should not see long filenames returned from dialog control (try 2)
Juan Lang escribió: What do you think about this version? Better, but still not correct: +ret = DlgDirSelectExA( WIN_Handle32(hwnd), buffer, MAX_PATH, id ); +if (GetLastError() == 0) GetShortPathNameA(buffer, str, len); You shouldn't check GetLastError() for whether DlgDirSelectExA succeeded. Rather, just check ret. You have the same problem in DlgDirSelectComboBoxEx16. --Juan Sorry, but I have to object. According to the documentation in MSDN, DlgDirSelectExA returns nonzero when the current selection is a directory name, and zero when it is not. However, plain filenames do not qualify as directory names, so DlgDirSelectExA won't return nonzero on them either. I checked on wine's implementation just to be sure. So checking ret will not tell apart a case of failure from a case of a plain filename being returned. That is why I need to zero out the last error and check against it after return. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: Cleanup of riched20 tests - request for help on test_WM_PASTE
Alex Villacís Lasso escribió: I am currently trying to clean up the riched20 tests that are failing in WinXP. While doing this, I have encountered the following problem: on the function test_WM_PASTE() (at line 1959 of dlls/riched20/tests/editor.c in current git), the test is supposed to feed simulated keystrokes corresponding to Ctrl-C, Ctrl-V, and so on, supposedly to test copy and paste features via the keyboard. The problem is that the verification at line 1989 fails on WinXP, because the text on the control has not been modified - the control seems to disregard simulated WM_CHAR messages of the Ctrl-keystroke variety. The test at line 1977 succeeds accidentally, because the sequence of Ctrl-C, Ctrl-V, Ctrl-Z that is being tested is equivalent to not modifying the control text at all. A more through test would be to send WM_GETTEXT messages after each step to ensure that the text is actually being modified, but the bigger problem is how to make the control obey the keystrokes in the first place. If I place a message loop right before the DestroyWindow() call, I can send keystrokes manually and they work as expected. Only simulated WM_CHAR messages are being discarded. I have tried changing the SendMessage() calls into PostMessage() calls (since Visual Studio's Spy++ shows that WM_CHAR messages were posted, not sent), but to no avail. I have also tried placing message loops between messages, with no luck. I have even tried to simulate the WM_KEYDOWN and WM_KEYUP messages with parameters exactly as seen by Spy++, but this does not work either. So I am asking for help. What could be going wrong with this test? How can I feed the expected keystrokes so that the test works as expected? Has this test ever worked before? It fails in both WinXP (real machine) and inside a QEMU session running Win98. (All tests on WinXP were compiled with CygWin) Any thoughts on this? Do I need to supply more information in order to diagnose the problem? -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Cleanup of riched20 tests - request for help on test_WM_PASTE
I am currently trying to clean up the riched20 tests that are failing in WinXP. While doing this, I have encountered the following problem: on the function test_WM_PASTE() (at line 1959 of dlls/riched20/tests/editor.c in current git), the test is supposed to feed simulated keystrokes corresponding to Ctrl-C, Ctrl-V, and so on, supposedly to test copy and paste features via the keyboard. The problem is that the verification at line 1989 fails on WinXP, because the text on the control has not been modified - the control seems to disregard simulated WM_CHAR messages of the Ctrl-keystroke variety. The test at line 1977 succeeds accidentally, because the sequence of Ctrl-C, Ctrl-V, Ctrl-Z that is being tested is equivalent to not modifying the control text at all. A more through test would be to send WM_GETTEXT messages after each step to ensure that the text is actually being modified, but the bigger problem is how to make the control obey the keystrokes in the first place. If I place a message loop right before the DestroyWindow() call, I can send keystrokes manually and they work as expected. Only simulated WM_CHAR messages are being discarded. I have tried changing the SendMessage() calls into PostMessage() calls (since Visual Studio's Spy++ shows that WM_CHAR messages were posted, not sent), but to no avail. I have also tried placing message loops between messages, with no luck. I have even tried to simulate the WM_KEYDOWN and WM_KEYUP messages with parameters exactly as seen by Spy++, but this does not work either. So I am asking for help. What could be going wrong with this test? How can I feed the expected keystrokes so that the test works as expected? Has this test ever worked before? It fails in both WinXP (real machine) and inside a QEMU session running Win98. (All tests on WinXP were compiled with CygWin) -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: Bug in dlls/oleaut32/tests/vartype.c?
Gerald Pfeifer escribió:
On Mon, 15 Oct 2007, Gerald Pfeifer wrote:
dlls/oleaut32/tests/vartype.c has the following snippet of code:
+ f = -1e-400;/* deliberately cause underflow */
+ hres = pVarBstrFromR4(f, lcid, 0, bstr);
+ ok(hres == S_OK, got hres 0x%08lx\n, hres);
+ if (bstr)
+ {
+todo_wine ok(memcmp(bstr, szZero, sizeof(szZero)) == 0, negative
zero (got %s)\n, wtoascii(bstr));
+ }
which was added in
revision 1.27
Alex Villacís Lasso [EMAIL PROTECTED]
Test for behavior of negative underflow formatting.
This doesn't seem to work as intended, because it is a floating point
*constant* which current versions of GCC simply truncate to 0.0.
The following patch tries to address this.
Gerald
ChangeLog:
Avoid truncation of floating point calculation at compile-time.
Index: dlls/oleaut32/tests/vartype.c
===
RCS file: /home/wine/wine/dlls/oleaut32/tests/vartype.c,v
retrieving revision 1.51
diff -u -3 -p -r1.51 vartype.c
--- dlls/oleaut32/tests/vartype.c 20 Aug 2007 12:43:49 - 1.51
+++ dlls/oleaut32/tests/vartype.c 29 Oct 2007 22:40:24 -
@@ -4727,6 +4727,7 @@ static void test_VarBstrFromR4(void)
HRESULT hres;
BSTR bstr = NULL;
+ const float flarge=1e20;
float f;
CHECKPTR(VarBstrFromR4);
@@ -4747,7 +4748,7 @@ static void test_VarBstrFromR4(void)
}
}
- f = -1e-400;/* deliberately cause underflow */
+ f = (-1 / flarge ) / flarge;/* deliberately cause underflow */
hres = pVarBstrFromR4(f, lcid, 0, bstr);
ok(hres == S_OK, got hres 0x%08x\n, hres);
if (bstr)
Sorry to object, but which version of exactly which compiler optimizes
away the negative sign?
Consider the following program:
#include stdio.h
#include stdlib.h
union x
{
float f;
unsigned char b[4];
};
int main(void)
{
union x u;
u.f = -1e-400;
printf(Value as float is %f\n, u.f);
printf(Value as bytes is %02x %02x %02x %02x\n, u.b[0], u.b[1],
u.b[2], u.b[3]);
return 0;
}
On my machine (i386 architecture, Fedora 7, gcc 4.1.2 20070925 (Red Hat
4.1.2-27)), the output is as follows:
[EMAIL PROTECTED] cpp]$ gcc -O2 -Wall test_underflow.c -o test_underflow
[EMAIL PROTECTED] cpp]$ ./test_underflow
Value as float is -0.00
Value as bytes is 00 00 00 80
[EMAIL PROTECTED] cpp]$
What compiler are you using? Which version? What is the output of said
compiler on the test program?
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Regression at #9443 - caused by winex11: Force a window to managed mode when it is activated
Alexandre Julliard escribió: Module: wine Branch: master Commit: f48eb1581dfe176043cbca5c46400c0f86eb5552 URL: http://source.winehq.org/git/wine.git/?a=commit;h=f48eb1581dfe176043cbca5c46400c0f86eb5552 Author: Alexandre Julliard [EMAIL PROTECTED] Date: Mon Aug 20 22:06:50 2007 +0200 winex11: Force a window to managed mode when it is activated. --- This patch causes a regression in Visual Basic apps that display a drop-down combo - the drop-down is displayed behind the dialog instead of over it. Details and URL of demostration at http://bugs.winehq.org/show_bug.cgi?id=9443 . Just discovered it minutes ago. Reversing this patch fixes the regression. This is one of a series of patches on winex11 committed on August 20. Since they did not pass through wine-patches, I don't really know what are they supposed to fix. This is keeping me from simply submitting a reversal of this patch to wine-patches. Could somebody be so kind as to explain? Alex Villacís Lasso -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: Using pthread_create within Wine
Phil Lodwick escribió: Greetings, I have a proprietary library that has both Windows and Linux ports. The Windows DLL has problems running on Wine, so I have created a builtin version of this DLL in Wine. This has worked fine, except for one function that basically creates a new thread and fires back events to the calling Window application. I believe I have traced this down to the Linux version of the library creating the new thread with pthread_create. Could you please elaborate on what kind of problems you have when trying to use the Windows version of your library under Wine? Is there any particular reason you do not want to build a pure Linux application that links in the Linux library, therefore bypassing Wine entirely? Your explanation sounds as if you do not have access to the source code of the library, and you are therefore trying to use libraryfile.a to link into a Wine .so file. Is this correct? If so, is the Windows version of the library a .lib file, or a .dll file? Am I right to guess your Linux version of the library resides in a .a file, not a .so file ? If your library is really a .lib file, then what happens if you build (under Windows) a .dll file which links in your .lib file, and then build a test program that exercises the newly created .dll file? Does it work correctly in Windows? Just to check, your library might not support being loaded as dynamic code. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: Poll: where do you have certs installed?
Juan Lang escribió: Could some of you check where you have, say, OpenSSL's CA certificates installed, and email me what distro you're running, and the path? E.g., I'm running Goobuntu, and I have them installed in /etc/ssl/certs/ca-certificates.crt. Thanks, --Juan My certificates are at /etc/pki/tls/certs/ca-bundle.crt (Fedora 7, openssl-0.9.8b-14.fc7) -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: [SPAM] Problem with patch dsound: Simplify mixing by removing remixing support, and fix its waveout breakage
Chris Rankin escribió:
Hi,
This patch has killed the sound on World of Warcraft. Instead, I now get
silence and a stream of
errors like this:
err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition!
err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition!
err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition!
err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition!
err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition!
err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition!
err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition!
err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition!
err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition!
err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition!
err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition!
err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition!
err:dsound:DSOUND_CalcPlayPosition Bad length in CalcPlayPosition!
The following change makes the sound work again without error messages, but
there is still a brief
burst of sound/noise before the music starts properly:
$ cvswine diff dlls/dsound/buffer.c
Index: dlls/dsound/buffer.c
===
RCS file: /home/wine/wine/dlls/dsound/buffer.c,v
retrieving revision 1.70
diff -u -r1.70 buffer.c
--- dlls/dsound/buffer.c22 Jun 2007 12:37:22 - 1.70
+++ dlls/dsound/buffer.c25 Jun 2007 19:08:34 -
@@ -442,15 +442,15 @@
pmix *= This-pwfx-nBlockAlign;
TRACE(this back-offset=%d\n, pmix);
-
+#if 0
/* sanity */
if(pmix This-buflen){
ERR(Bad length in CalcPlayPosition!\n);
return 0;
}
-
+#endif
/* subtract from our last mixed position */
- if (bplay pmix) bplay += This-buflen; /* wraparound */
+ while (bplay pmix) bplay += This-buflen; /* wraparound */
bplay -= pmix;
/* check for lead-in */
Cheers,
Chris
___
New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes.
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk
You might try the patch with the title DSOUND: recover from mismatch
between time spanned by primary buffer being longer than the one spanned
by secondary buffer, which I sent along with some other patches today.
It looks somewhat similar to the one you sent.
Alex Villacís Lasso
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Failing assertion in dsound test, please confirm
I am experiencing a failing assertion in a dsound test. Could you please
confirm if it is just me (and then it would be a configuration issue),
or if anybody else is experiencing failing assertions:
[EMAIL PROTECTED] tests]$ WINETEST_INTERACTIVE=1 wine dsound_test.exe.so dsound
ALSA lib conf.c:3939:(snd_config_expand) Unknown parameters 0
ALSA lib control.c:910:(snd_ctl_open_noupdate) Invalid CTL default:0
fixme:wave:ALSA_AddCaptureDevice Add support for DSCapture
dsound.c:973:DLL Version: 5.3.1.904
dsound.c:180:Testing IDirectSound
fixme:dsalsa:SetFormat Your alsa dmix period size is excessively high,
unfortunately this is alsa default, try decreasing it to 512 or 256 (but
double the amount of periods) if possible
fixme:ole:CoCreateInstance no instance created for interface
{11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} of class
{47d4d946-62e8-11cf-93bc-44455354}, hres is 0x80004002
err:ole:CoGetClassObject class {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca}
not registered
err:ole:CoGetClassObject no class object
{11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} could be created for context 0x1
dsound.c:938:*** Testing Primary Sound Driver - winealsa.drv ***
dsound.c:475:Playing a 5 seconds reference tone at the current volume.
dsound.c:478:(the current volume is -4651 according to DirectSound)
dsound.c:480:All subsequent tones should be identical to this one.
dsound.c:481:Listen for stutter, changes in pitch, volume, etc.
ds3d.c:400:Requested format tag=0x0001 11025x16x2 avg.B/s=44100 align=4
ds3d.c:403:Got tag=0x0001 48000x16x2 avg.B/s=192000 align=4
ds3d.c:453:Playing 5 second 440Hz tone at 48000x16x2
dsound.c:582:Requested primary format tag=0x0001 8000x8x1 avg.B/s=8000
align=1
dsound.c:586:Got tag=0x0001 48000x8x1 avg.B/s=48000 align=1
dsound.c:607: Testing a primary buffer at 48000x8x1 with a secondary
buffer at 11025x16x2
ds3d.c:453:Playing 1 second 440Hz tone at 11025x16x2
dsound.c:582:Requested primary format tag=0x0001 8000x8x2 avg.B/s=16000
align=2
dsound.c:586:Got tag=0x0001 48000x8x2 avg.B/s=96000 align=2
dsound.c:607: Testing a primary buffer at 48000x8x2 with a secondary
buffer at 11025x16x2
ds3d.c:453:Playing 1 second 440Hz tone at 11025x16x2
dsound.c:582:Requested primary format tag=0x0001 8000x16x1 avg.B/s=16000
align=2
dsound.c:586:Got tag=0x0001 48000x16x1 avg.B/s=96000 align=2
dsound.c:607: Testing a primary buffer at 48000x16x1 with a secondary
buffer at 11025x16x2
ds3d.c:453:Playing 1 second 440Hz tone at 11025x16x2
dsound.c:582:Requested primary format tag=0x0001 8000x16x2 avg.B/s=32000
align=4
dsound.c:586:Got tag=0x0001 48000x16x2 avg.B/s=192000 align=4
dsound.c:607: Testing a primary buffer at 48000x16x2 with a secondary
buffer at 11025x16x2
ds3d.c:453:Playing 1 second 440Hz tone at 11025x16x2
mixer.c:823: DSOUND_PerformMix: La declaración `device-playpos
device-buflen' no se cumple.
wine: Assertion failed at address 0x67f2 (thread 000f), starting
debugger...
dsound.c:582:Requested primary format tag=0x0001 11025x8x1 avg.B/s=11025
align=1
dsound.c:586:Got tag=0x0001 48000x8x1 avg.B/s=48000 align=1
dsound.c:607: Testing a primary buffer at 48000x8x1 with a secondary
buffer at 11025x16x2
Unhandled exception: assertion failed in 32-bit code (0x67f2).
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
EIP:67f2 ESP:7ed516cc EBP:7ed516d8 EFLAGS:0202( - 00 - - I1)
EAX: EBX:2cd3 ECX:2cd5 EDX:0006
ESI:7ed51778 EDI:60298ff4
Stack dump:
0x7ed516cc: 60171fa0 60298ff4 7ed52b90 7ed51804
0x7ed516dc: 601738b1 0006 7ed51778
0x7ed516ec: 0068 7cae1278
0x7ed516fc: 601ae37d 7ed5173c 7cae1278 7cae12dc
0x7ed5170c: 7ed51814 60298ff4 0062 7cae1278
0x7ed5171c: 7ed517e8 601a7d3b 7cae1278 0062
Backtrace:
=1 0x67f2 (0x7ed516d8)
2 0x601738b1 (0x7ed51804)
3 0x6016b3ce (0x7ed51848)
4 0x608bdfe8 DSOUND_timer+0x2108(timerID=0x1, msg=0x0,
dwUser=0x167688, dw1=0x0, dw2=0x0)
[/home/alex/install/wine-0.9.39-build/dlls/dsound/mixer.c:554] in dsound
(0x7ed519b8)
5 0x60910b96 TIME_MMSysTimeThread+0x2e6(arg=0x0)
[/home/alex/install/wine-0.9.39-build/dlls/winmm/time.c:181] in winmm
(0x7ed51a18)
6 0x7bc5d19e call_thread_entry_point+0xe() in ntdll (0x7ed51a28)
7 0x7bc5de72 call_thread_func+0x42(rtl_func=register EDI not in
topmost frame, arg=register ESI not in topmost frame)
[/home/alex/install/wine-0.9.39-build/dlls/ntdll/thread.c:404] in ntdll
(0x7ed51ac8)
8 0x7bc5e10f in ntdll (+0x4e10f) (0x7ed523c8)
9 0x601362fb (0x7ed524b8)
10 0x6021993e (0x)
0x67f2: ret
Modules:
Module Address Debug info Name (66 modules)
ELF 24d000- 2bd000 Deferredlibgl.so.1
ELF 24d000- 2bd000 Deferredlibgl.so.1
ELF 43e000- 45b000 Deferredld-linux.so.2
ELF 45d000- 5b1000 Deferredlibc.so.6
ELF 5b3000- 5dc000 Deferredlibm.so.6
ELF 5de000-
On stuttering audio in quartz/DirectShow
Upon checking the source code of dlls/quartz I found out about the method SetSyncSource defined in the IBaseFilter interface: dsoundrender.c:static HRESULT WINAPI DSoundRender_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) filesource.c:static HRESULT WINAPI AsyncReader_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) filtergraph.c:static HRESULT WINAPI MediaFilter_SetSyncSource(IMediaFilter *iface, IReferenceClock *pClock) parser.c:static HRESULT WINAPI Parser_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) transform.c:static HRESULT WINAPI TransformFilter_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) videorenderer.c:static HRESULT WINAPI VideoRenderer_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) In particular, I see the following two things about sync sources: 1) I see no effort on part of filtergraph.c to add a sync source when simply asked to render a file 2) Even if it did, current implementation of videorenderer.c does nothing with its sync source So I have a couple of questions: 1) Am I right to assume that a sync source might be used to synchronize and (if necessary) drop frames at the videorenderer in order to maintain synchronization and avoid stuttering? 2) Could the sttutering really be solved by implementing the using and passing of a synchronization source (systemclock.c) in file rendering? If so, then the migration to DirectDraw would become just an optimization to increase the frame rate. Alex Villacís Lasso -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
QUARTZ: Patch 1 - Fix video rendering sizing/positioning bugs (try 2)
Alexandre Julliard escribió:
[EMAIL PROTECTED] writes:
+case WM_SIZE:
+TRACE(WM_SIZE %d %d\n, LOWORD(lParam), HIWORD(lParam));
+SetWindowPos(hwnd, NULL, pVideoRenderer-WindowPos.left,
pVideoRenderer-WindowPos.top, LOWORD(lParam), HIWORD(lParam), SWP_NOZORDER);
Why do you want to resize a window that has just been resized?
You are right. The extra SetWindowPos() is unnecessary and a result of
copy/paste from WM_SIZING. Here is a new patch without the extra call.
BTW, please ignore for now the second patch that moves the blitting to
the message loop. There is another bug in quartz that freezes playback
after a few frames with certain AVI files. I am trying to chase it down
right now. The bug report is at bug #8740 in bugzilla. The first patch
has no effect on this bug, but the second one makes it harder for me to
search for the root cause of the problem.
This patch is one that I should send anyway, before even thinking of
reimplementing video rendering in quartz.dll with DirectDraw.
Current video sink has bugs relating to window sizing and position.
One of the causes of this is that the windowproc does not handle the
WM_SIZE message, and there are cases where WM_SIZE is sent without any
WM_SIZING message (for example, when creating the window in the first
place). This leads to the video frame not being resized to the window
size in my test program (which resizes the frame correctly with native
quartz).
Another cause of problems is the code in VideoRenderer_SendSampleData
that comes after the comment:
/* Compute the size of the whole window so the client area size matches
video one */
This code moves around the window and resizes it, ignoring the values
specified in This-WindowPos, and then updates This-WindowPos with new
values. The net effect of this is that (in my test program) the frame
is not centered in the control canvas, as it should be, but instead it is
left-aligned. The rendering code has no business overriding size or position
of WindowPos outside the getter/setter methods. The fix is to SetWindowPos()
based on WindowPos, without modifying it.
One problem uncovered by this patch is that (at least on my computer) the
StretchDIBits() function causes the final frame to have a corruption in the
form of tiles formed by vertical and horizontal lines of corrupted pixels
whenever the destination rectangle is smaller than the frame size. I don't
yet know what is causing this corruption, since the shrinking code in
winex11drv seems to be correct. You can use my test program and any .AVI file
to verify this. This problem is independent of pixel bit depth, but the
spacing of the tiles is dependent of the size of the destination frame.
Changelog:
* Handle WM_SIZE in order to update blitting size in all cases
* Do not override WindowPos in rendering code
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
--- wine-0.9.39-cvs/dlls/quartz/videorenderer.c 2007-05-17 10:25:02.0 -0500
+++ wine-0.9.39-build/dlls/quartz/videorenderer.c 2007-06-19 11:11:34.0 -0500
@@ -126,6 +126,20 @@
/* TRACE(WM_SIZING %d %d %d %d\n, lprect-left, lprect-top, lprect-right, lprect-bottom); */
SetWindowPos(hwnd, NULL, lprect-left, lprect-top, lprect-right - lprect-left, lprect-bottom - lprect-top, SWP_NOZORDER);
GetClientRect(hwnd, pVideoRenderer-DestRect);
+TRACE(WM_SIZING: DestRect=(%d,%d),(%d,%d)\n,
+pVideoRenderer-DestRect.left,
+pVideoRenderer-DestRect.top,
+pVideoRenderer-DestRect.right - pVideoRenderer-DestRect.left,
+pVideoRenderer-DestRect.bottom - pVideoRenderer-DestRect.top);
+return TRUE;
+case WM_SIZE:
+TRACE(WM_SIZE %d %d\n, LOWORD(lParam), HIWORD(lParam));
+GetClientRect(hwnd, pVideoRenderer-DestRect);
+TRACE(WM_SIZING: DestRect=(%d,%d),(%d,%d)\n,
+pVideoRenderer-DestRect.left,
+pVideoRenderer-DestRect.top,
+pVideoRenderer-DestRect.right - pVideoRenderer-DestRect.left,
+pVideoRenderer-DestRect.bottom - pVideoRenderer-DestRect.top);
return TRUE;
default:
return DefWindowProcA(hwnd, uMsg, wParam, lParam);
@@ -305,18 +319,14 @@
if (!This-init)
{
-/* Compute the size of the whole window so the client area size matches video one */
-RECT wrect, crect;
-int h, v;
-GetWindowRect(This-hWnd, wrect);
-GetClientRect(This-hWnd, crect);
-h = (wrect.right - wrect.left) - (crect.right - crect.left);
-v = (wrect.bottom - wrect.top) - (crect.bottom - crect.top);
-SetWindowPos(This-hWnd, NULL, 0, 0, width + h +20, height + v+20, SWP_NOZORDER|SWP_NOMOVE);
-This-WindowPos.left = 0;
-This-WindowPos.top = 0;
-This-WindowPos.right =
Seeking advice for rewrite of dlls/quartz/videorenderer.c using DirectDraw
From a time till now, I am using a test application in Visual Basic in order to test progress in quartz. The code for the application (along with a precompiled EXE) can be found at the following address: http://www.palosanto.com/~a_villacis/WMediaTest.tar.bz2 One of the things I dislike about the current quartz implementation is that when a large AVI video file (say, 640x480) is played with the test application, the sound stutters (in both ALSA and OSS) while the frames are being updated. This occurs with the builtin quartz.dll, but not with native (WinXP) quartz. From what I can deduce from WINEDEBUG=+tid,+quartz , it seems that builtin feeds video and audio in the same thread. In addition, dlls/quartz/videorenderer.c uses StretchDIBits() in order to write one frame of video into the output window. Apparently StretchDIBits() is slow enough in my machine that it cannot complete by the next sound sample. Therefore the stuttering. I made a little patch to move the video rendering in videorender.c into a separate thread, in order to allow it to drop frames. However this does not completely eliminate the stuttering audio. I am now thinking about rewriting the video rendering with DirectDraw. It seems that native quartz.dll uses DirectDraw, not GDI, to display video frames into the output window. One thing I am worried about is the pixel format of the surfaces. The video data is 32bpp, but the output window uses my X config at 16bpp. However, nowhere in the ddraw trace of native quartz I can find any reference to a CreateSurface with 32bpp. It seems that native quartz does the depth conversion itself. The question is this: if I create a 32 bpp surface (in order to lock it and write the 32 bpp frame data into it), can I then blit it into a 16 bpp output window and somehow let DirectDraw take care of the depth conversion? If so, can this be any faster than writing the depth conversion myself? Alex Villacís Lasso -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: [SPAM] Re: Seeking advice for rewrite of dlls/quartz/videorenderer.c using DirectDraw
Stefan Dösinger escribió: Hi, I am now thinking about rewriting the video rendering with DirectDraw. It seems that native quartz.dll uses DirectDraw, not GDI, to display video frames into the output window. DirectDraw sounds like the right way to implement quartz video output, but performance wise I am concerned about the performance of our current directdraw implementation. DirectDraw is implemented in software, on top of gdi, so you end up with just one more abstraction layer in between. Our DDraw code basically has the capability to use opengl for hardware acceleration, but its far from complete. One thing I am worried about is the pixel format of the surfaces. The video data is 32bpp, but the output window uses my X config at 16bpp. However, nowhere in the ddraw trace of native quartz I can find any reference to a CreateSurface with 32bpp. It seems that native quartz does the depth conversion itself. The question is this: if I create a 32 bpp surface (in order to lock it and write the 32 bpp frame data into it), can I then blit it into a 16 bpp output window and somehow let DirectDraw take care of the depth conversion? If so, can this be any faster than writing the depth conversion myself? You cannot create a 16 bit front buffer on a 32 bit desktop, except if you switch to exclusive mode(and thus fullscreen). The really proper way to handle this is to create an overlay surface in your video's input format and overlay the primary(= the screen) with it. The issue with this is that wine does not support overlay surfaces yet. There is an overlay implementation via Xv in CodeWeaver's Picasa wine tree(downloadable at www.google.com). I was about to integrate it into wine, but some problems with accessing Xv from wined3d arised, and the overall idea was to wait for the wined3d using WGL instead of GLX efforts, which somehow froze with the windowed GL rendering problems. The other idea would be to create a Direct3D device(with the back buffer beeing automatically in desktop bit depth), + a few(dynamic) textures in the video's format and size. Then upload the video into the textures and draw quads on the back buffer, then flip. This way the opengl hardware does the color conversion and filtering for you. The drawback is that you need hardware acceleration. Obviously, if you can use Direct3D, and Direct3D uses OpenGL, you could use OpenGL directly, which saves you a not really cheap layer and gets you more control over opengl. The advantage of using Direct3D would be that an Overlay path and a Direct3D path could share some code, but I don't know how much. Maybe I forgot to explain. My test application was run with WINEDLLOVERRIDES=quartz=n in order to use the native quartz.dll . With this, audio does not stutter. The explanation about the DirectDraw implementation in Wine being based on top of GDI does not explain how native quartz manages to play smoothly while builtin quartz stutters *when both are run under Wine*. Maybe the real trick is that native quartz does the 32bpp - 16 bpp conversion in a way that is faster than the one made by StretchDIBits(). If this is correct, then I should implement my own depth conversion as part of the rewrite and then use DirectDraw to blit the resulting frame into the output. What do you think? -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: wine + visual basic
Joshua Masiko escribió:
hello,
I got your email addresses off the wine bug database at
http://bugs.winehq.org/show_bug.cgi?id=6638.
I'm looking at moving a custom Visual Basic 6 windows application to
linux +
wine.
However I cannot find any good step by step documentation on how to do
this.
I have SUSE 10, wine 0.9.29.
I tried a simple test case which throws an error ActiveX can't create
object
dim cn as adodb.connection
set cn=new adodb.connection 'error on this statement
Can u give me any pointers on what i need in order to run a visual basic
application which
uses an ODBC DSN (postresql) and ADO=2.5 successfully.
I intend to publish a detailed step by step howto on this topic for other
potential wine users if successfull
The very first step is to ensure ADO is actually installed in the Wine
directory. Usually the MSVB6 installer for the application (created with
the Package and Deployment Wizard) takes care of this, but installing
MDAC 2.x works too (I have installed MDAC 2.8). Wine currently provides
no replacements for ADO libraries or objects, so doing either of these
options is mandatory.
It seems that you are trying to connect via ADO and ODBC. You should
first have an Unix ODBC driver installed, since the ODBC support in Wine
is simply a pass-through layer to the Unix ODBC support in the system.
If you are compiling Wine from sources, you should (for example) have
*both* unixODBC and unixODBC-devel RPM packages installed (or the
equivalent bundles in SUSE). Otherwise, Wine will be compiled without
ODBC support. You should then create (in unixODBC, not Wine) an ODBC
data source for your database of choice, and verify (/usr/bin/isql) that
you can actually connect and read data from it before trying to do
anything from within Wine.
Also, please note that Wine (currently) only supports as much ODBC as
the underlying ODBC support does. In particular, the following syntax:
Set oConexion = New ADODB.Connection
...
oConexion.Open ConnectionString:=Driver={Microsoft Access Driver
(*.mdb)};DBQ=...
in which the driver is specified within curly braces, is *NOT* supported
under Wine, nor is any variation of this method. You must specify a data
source that appears in your ODBC configuration file in /etc/odbc.ini .
Of course, you might just bypass the ODBC layer and do something like this:
Set oConexion = New ADODB.Connection
...
oConexion.Provider = Microsoft.Jet.OLEDB.4.0
oConexion.Properties(Jet OLEDB:Database Password) =
somepassword
oConexion.Open ConnectionString:=App.Path \ DATABASE_FILE
This method works as long as all the corresponding providers (which are
also ActiveX objects) are correctly registered. In this way, no ODBC
code is involved and the Windows code directly manages the database
connection. However, all the necessary providers and drivers must be
installed by your application installer (again, the Packaging and
Deployment Wizard should take care of these dependencies).
Hope this helps.
Alex Villacís Lasso
--
perl -e '$x = 2.4; print sprintf(%.0f + %.0f = %.0f\n, $x, $x, $x + $x);'
Re: msacm32: Fix greater than vs. less than typo in comparison. (Coverity)
Kai Blin escribió:
---
dlls/msacm32/driver.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dlls/msacm32/driver.c b/dlls/msacm32/driver.c
index d4ad644..06e6614 100644
--- a/dlls/msacm32/driver.c
+++ b/dlls/msacm32/driver.c
@@ -430,7 +430,7 @@ LRESULT WINAPI acmDriverMessage(HACMDRIV
/* This verification is required because DRVCONFIGINFO is 12
bytes
long, yet native msacm reports a 16-byte structure to
codecs.
*/
-if (iStructSize sizeof(DRVCONFIGINFO)) iStructSize =
sizeof(DRVCONFIGINFO);
+if (iStructSize sizeof(DRVCONFIGINFO)) iStructSize =
sizeof(DRVCONFIGINFO);
pConfigInfo = HeapAlloc(MSACM_hHeap, 0, iStructSize);
if (!pConfigInfo) {
ERR(OOM while supplying DRVCONFIGINFO for DRV_CONFIGURE, using
NULL\n);
This is not a typo, but rather an unnecessary verification, from when I
didn't know the true size of a DRVCONFIGINFO. The struct size should be
*exactly 16 bytes*, even though only the first 12 bytes are used. This
patch might even introduce a bug, where the struct info assumed by the
codec to be 16 bytes when only 12 are allocated, and some smart-ass
codec tries to use the last 4 bytes of the struct for its own purposes,
which with this patch are now past the end of the allocated array. A
more correct patch would fix the comment to indicate that exactly 16
bytes are allocated for a 12-byte struct, and remove the conditional
assignment altogether.
Alex Villacís Lasso
--
perl -e '$x = 2.4; print sprintf(%.0f + %.0f = %.0f\n, $x, $x, $x + $x);'
Re: [SPAM] Re: Looking for sound testers
Neil Skrypuch escribió: On Thursday, December 28, 2006 10:04, Maarten Lankhorst wrote: Hi all, I've forward ported the old patches of Davin McCall (dsound.patch). With them I have no more sound underruns etc, I'm therefore looking for other people to test them as well. I'm welcoming comments on how it works and possible issues with it. I also attached my patch to alsa, I'm aware of the things I need to fix for that, but I thought it might be good to test dsound with winealsa, to see if other things still need to be fixed. Cheers, Maarten I've given this a spin with Icewind Dale, and while it does seem to remove the underrun issues (at least I don't see them spit out anymore), the sound still stutters and crackles just as much as before. - Neil With both ALSA and dsound patches applied, the tests hang when trying to play from a 96000Hz buffer. Enabling direct access for the winealsa driver works around this. -- perl -e '$x = 2.4; print sprintf(%.0f + %.0f = %.0f\n, $x, $x, $x + $x);'
Re: oleaut32: Fix failing VarMod tests in WinXP, fix VarMod(VT_DECIMAL) in Wine
Robert Shearman escribió: [EMAIL PROTECTED] wrote: In a preparation for a possible implementation of IDispatch tests in oleaut32, I decided to clean up the failing tests in Windows XP: Great, thanks for fixing this. I was about to do this myself. It's about time we get the number of failing tests on XP as close to zero as possible. BTW, in case nobody knows, the BOOL-BSTR conversion is localized in WinXP (so that in Spanish locales, conversion to strings gives Verdadero, not True as tested). Apparently it is *not* localized in Win98SE. I don't have any other Windows versions available, but this means at least two test failures on non-English versions of WinXP. Does this mean that a comparison to a specific string is pointless and should be removed? -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.
Re: oleaut32: preliminary support for VT_DISPATCH as parameters to VarAdd (and other 2-operand operations) (try 2) (RESEND)
Alexandre Julliard escribió:
Alex Villacís Lasso [EMAIL PROTECTED] writes:
+#define HANDLE_DISPATCH(left, right) \
+if ((V_VT(param_left) VT_TYPEMASK) == VT_DISPATCH \
+(V_VT(param_right) VT_TYPEMASK) != VT_NULL) \
+{\
+HRESULT hres;\
+left = tempLeft;\
+hres = VARIANT_FetchDispatchValue(param_left, left);\
+if (!SUCCEEDED(hres)) return hres;\
+}\
+if ((V_VT(param_right) VT_TYPEMASK) == VT_DISPATCH \
+(V_VT(param_left) VT_TYPEMASK) != VT_NULL)\
+{\
+HRESULT hres;\
+right = tempRight;\
+hres = VARIANT_FetchDispatchValue(param_right, right);\
+if (!SUCCEEDED(hres)) return hres;\
+}
This macro is quite ugly. Also I don't see why you check the other
variant against VT_NULL first, aren't there cases where you still need
the other value?
If I remove the check for VT_NULL on the other variant, I get this test
failure:
../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p
oleaut32_test.exe.so vartest.c touch vartest.ok
fixme:variant:VarMod Could not convert left type 4096 to 20? rc ==
0x80020008
fixme:variant:VarMod Could not convert left type 8192 to 20? rc ==
0x80020008
fixme:variant:VarMod Could not convert left type 16384 to 20? rc ==
0x80020008
vartest.c:4910: Test failed: VarAdd: 1|0x0, 9|0x0: expected S_OK, vt 1,
got 0x80020005 vt 0
vartest.c:4910: Test failed: VarAdd: 9|0x0, 1|0x0: expected S_OK, vt 1,
got 0x80020005 vt 0
make: *** [vartest.ok] Error 2
This happens because for VarAdd, VT_NULL + VT_DISPATCH should succeed
and give VT_NULL as a result, but the patch fetches the result value of
the VT_DISPATCH before doing anything else. For null VT_DISPATCHs like
the ones the test feeds the function, this causes the fetch to fail
before the code for handling VT_NULLs is reached.
--
The following cryptic message was allegedly found in the inner edge of a Windows
XP installation CD:
4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420
7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074
6865206461726B6E6573732062696E64207468656D2E0A
It is rumored that only a true Unix Wizard can decypher this mysterious message,
which supposedly encodes the true nature and purpose of the software.
oleaut32: bypass conversion to string in R4/R8 - DECIMAL conversion (RESEND)
Alex Villacís Lasso escribió:
Alexandre Julliard escribió:
Alex Villacís Lasso [EMAIL PROTECTED] writes:
This patch added the setlocale(LC_ALL, ) line to
dlls/kernel32/locale.c . The oleaut32 tests for vartype.c have been
failing since that time on non-English locales. I see now that setting
the locale around calls of sprintfW() is not thread-safe. However, I
think there is no big problem on going through a string in order to
convert a floating-point number into a DECIMAL, since otherwise, we
would need to implement our own bit-splicer for floating-point
numbers. As long as the starting locale for sprintfW() is known to be
the LC_NUMERIC=C, all other parsing should work as before the MacOS
patch. Therefore I propose the attached patch. This patch simply sets
setlocale(LC_NUMERIC, C) at the end of LOCALE_Init() in
dlls/kernel32/locale.c in order to guarantee that sprintfW will always
use periods as decimal separators.
I put this in for now, but oleaut32 should really be fixed, we can't
force the whole process to format number in English just because
oleaut32 is broken. It doesn't matter too much for Wine itself, but
any Unix library that we load should be able to behave properly
according to the locale that the user has selected.
Well, here is an attempt to fix part of the breakage in oleaut32 that
ties it to LC_NUMERIC being C. This patch decomposes floats and
doubles into the component bitfields, then copies the values into
DECIMAL structures and manipulates them to get the corresponding
DECIMAL value. This removes the step of converting the floating-point
number into a string and therefore eliminates two uses of sprintfW on
floats. This particular patch passes all tests, but I am not really
sure about the rounding - I might be overdoing it. Please comment.
Changelog:
* Remove uses of sprintfW to convert floats into DECIMAL by directly
parsing the floating-point representation.
Alex Villacís Lasso
Resending since there was no response since Monday.
--
The following cryptic message was allegedly found in the inner edge of a Windows
XP installation CD:
4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420
7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074
6865206461726B6E6573732062696E64207468656D2E0A
It is rumored that only a true Unix Wizard can decypher this mysterious message,
which supposedly encodes the true nature and purpose of the software.
--- wine-0.9.27-cvs/dlls/oleaut32/vartype.c 2006-12-07 13:38:15.0 -0500
+++ wine-0.9.27-cvs-patch/dlls/oleaut32/vartype.c 2006-12-10 16:30:02.0 -0500
@@ -4143,6 +4143,21 @@
#define LOCALE_EN_US (MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_US),SORT_DEFAULT))
+/* internal representation of the value stored in a DECIMAL. The bytes are
+ stored from LSB at index 0 to MSB at index 11
+ */
+typedef struct DECIMAL_internal
+{
+DWORD bitsnum[3]; /* 96 significant bits, unsigned */
+unsigned char scale; /* number scaled * 10 ^ -(scale) */
+unsigned int sign : 1; /* 0 - positive, 1 - negative */
+} VARIANT_DI;
+
+static HRESULT VARIANT_DI_FromR4(float source, VARIANT_DI * dest);
+static HRESULT VARIANT_DI_FromR8(double source, VARIANT_DI * dest);
+static void VARIANT_DIFromDec(const DECIMAL * from, VARIANT_DI * to);
+static void VARIANT_DecFromDI(VARIANT_DI * from, DECIMAL * to);
+
/
* VarDecFromR4 (OLEAUT32.193)
*
@@ -4157,10 +4172,12 @@
*/
HRESULT WINAPI VarDecFromR4(FLOAT fltIn, DECIMAL* pDecOut)
{
- WCHAR buff[256];
-
- sprintfW( buff, szFloatFormatW, fltIn );
- return VarDecFromStr(buff, LOCALE_EN_US, LOCALE_NOUSEROVERRIDE, pDecOut);
+ VARIANT_DI di;
+ HRESULT hres;
+
+ hres = VARIANT_DI_FromR4(fltIn, di);
+ if (hres == S_OK) VARIANT_DecFromDI(di, pDecOut);
+ return hres;
}
/
@@ -4177,10 +4194,12 @@
*/
HRESULT WINAPI VarDecFromR8(double dblIn, DECIMAL* pDecOut)
{
- WCHAR buff[256];
-
- sprintfW( buff, szDoubleFormatW, dblIn );
- return VarDecFromStr(buff, LOCALE_EN_US, LOCALE_NOUSEROVERRIDE, pDecOut);
+ VARIANT_DI di;
+ HRESULT hres;
+
+ hres = VARIANT_DI_FromR8(dblIn, di);
+ if (hres == S_OK) VARIANT_DecFromDI(di, pDecOut);
+ return hres;
}
/
@@ -4596,16 +4615,6 @@
return hRet;
}
-/* internal representation of the value stored in a DECIMAL. The bytes are
- stored from LSB at index 0 to MSB at index 11
- */
-typedef struct DECIMAL_internal
-{
-DWORD bitsnum[3]; /* 96 significant bits, unsigned */
-unsigned char scale; /* number scaled * 10 ^ -(scale) */
-unsigned int sign : 1; /* 0 - positive, 1 - negative */
-} VARIANT_DI;
-
/* translate from external DECIMAL format into an internal representation */
static void VARIANT_DIFromDec(const
oleaut32:
Alexandre Julliard escribió:
Alex Villacís Lasso [EMAIL PROTECTED] writes:
This patch added the setlocale(LC_ALL, ) line to
dlls/kernel32/locale.c . The oleaut32 tests for vartype.c have been
failing since that time on non-English locales. I see now that setting
the locale around calls of sprintfW() is not thread-safe. However, I
think there is no big problem on going through a string in order to
convert a floating-point number into a DECIMAL, since otherwise, we
would need to implement our own bit-splicer for floating-point
numbers. As long as the starting locale for sprintfW() is known to be
the LC_NUMERIC=C, all other parsing should work as before the MacOS
patch. Therefore I propose the attached patch. This patch simply sets
setlocale(LC_NUMERIC, C) at the end of LOCALE_Init() in
dlls/kernel32/locale.c in order to guarantee that sprintfW will always
use periods as decimal separators.
I put this in for now, but oleaut32 should really be fixed, we can't
force the whole process to format number in English just because
oleaut32 is broken. It doesn't matter too much for Wine itself, but
any Unix library that we load should be able to behave properly
according to the locale that the user has selected.
Well, here is an attempt to fix part of the breakage in oleaut32 that
ties it to LC_NUMERIC being C. This patch decomposes floats and
doubles into the component bitfields, then copies the values into
DECIMAL structures and manipulates them to get the corresponding DECIMAL
value. This removes the step of converting the floating-point number
into a string and therefore eliminates two uses of sprintfW on floats.
This particular patch passes all tests, but I am not really sure about
the rounding - I might be overdoing it. Please comment.
Changelog:
* Remove uses of sprintfW to convert floats into DECIMAL by directly
parsing the floating-point representation.
Alex Villacís Lasso
--
The following cryptic message was allegedly found in the inner edge of a Windows
XP installation CD:
4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420
7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074
6865206461726B6E6573732062696E64207468656D2E0A
It is rumored that only a true Unix Wizard can decypher this mysterious message,
which supposedly encodes the true nature and purpose of the software.
--- wine-0.9.27-cvs/dlls/oleaut32/vartype.c 2006-12-07 13:38:15.0 -0500
+++ wine-0.9.27-cvs-patch/dlls/oleaut32/vartype.c 2006-12-10 16:30:02.0 -0500
@@ -4143,6 +4143,21 @@
#define LOCALE_EN_US (MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_US),SORT_DEFAULT))
+/* internal representation of the value stored in a DECIMAL. The bytes are
+ stored from LSB at index 0 to MSB at index 11
+ */
+typedef struct DECIMAL_internal
+{
+DWORD bitsnum[3]; /* 96 significant bits, unsigned */
+unsigned char scale; /* number scaled * 10 ^ -(scale) */
+unsigned int sign : 1; /* 0 - positive, 1 - negative */
+} VARIANT_DI;
+
+static HRESULT VARIANT_DI_FromR4(float source, VARIANT_DI * dest);
+static HRESULT VARIANT_DI_FromR8(double source, VARIANT_DI * dest);
+static void VARIANT_DIFromDec(const DECIMAL * from, VARIANT_DI * to);
+static void VARIANT_DecFromDI(VARIANT_DI * from, DECIMAL * to);
+
/
* VarDecFromR4 (OLEAUT32.193)
*
@@ -4157,10 +4172,12 @@
*/
HRESULT WINAPI VarDecFromR4(FLOAT fltIn, DECIMAL* pDecOut)
{
- WCHAR buff[256];
-
- sprintfW( buff, szFloatFormatW, fltIn );
- return VarDecFromStr(buff, LOCALE_EN_US, LOCALE_NOUSEROVERRIDE, pDecOut);
+ VARIANT_DI di;
+ HRESULT hres;
+
+ hres = VARIANT_DI_FromR4(fltIn, di);
+ if (hres == S_OK) VARIANT_DecFromDI(di, pDecOut);
+ return hres;
}
/
@@ -4177,10 +4194,12 @@
*/
HRESULT WINAPI VarDecFromR8(double dblIn, DECIMAL* pDecOut)
{
- WCHAR buff[256];
-
- sprintfW( buff, szDoubleFormatW, dblIn );
- return VarDecFromStr(buff, LOCALE_EN_US, LOCALE_NOUSEROVERRIDE, pDecOut);
+ VARIANT_DI di;
+ HRESULT hres;
+
+ hres = VARIANT_DI_FromR8(dblIn, di);
+ if (hres == S_OK) VARIANT_DecFromDI(di, pDecOut);
+ return hres;
}
/
@@ -4596,16 +4615,6 @@
return hRet;
}
-/* internal representation of the value stored in a DECIMAL. The bytes are
- stored from LSB at index 0 to MSB at index 11
- */
-typedef struct DECIMAL_internal
-{
-DWORD bitsnum[3]; /* 96 significant bits, unsigned */
-unsigned char scale; /* number scaled * 10 ^ -(scale) */
-unsigned int sign : 1; /* 0 - positive, 1 - negative */
-} VARIANT_DI;
-
/* translate from external DECIMAL format into an internal representation */
static void VARIANT_DIFromDec(const DECIMAL * from, VARIANT_DI * to)
{
@@ -5190,6 +5199,284 @@
return r_overflow
oleaut32: preliminary support for VT_DISPATCH as parameters to VarAdd (and other 2-operand operations) (RESEND)
This is a preliminary patch to add support for VT_DISPATCH as parameters
to VarAdd and other arithmetic operations with variants. The tests still
pass in the sense that null VT_DISPATCH as issued by the tests are
still rejected. I post this in the hope that it will be reviewed while I
prepare a test case.
Changelog:
* Add support for receiving of VT_DISPATCH parameters in several
operator functions by fetching the result value, then reissuing the same
operation on result data.
--
The following cryptic message was allegedly found in the inner edge of a Windows
XP installation CD:
4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420
7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074
6865206461726B6E6573732062696E64207468656D2E0A
It is rumored that only a true Unix Wizard can decypher this mysterious message,
which supposedly encodes the true nature and purpose of the software.
--- wine-0.9.25-cvs/dlls/oleaut32/variant.c 2006-11-08 15:27:23.0 -0500
+++ wine-0.9.25-cvs-patch/dlls/oleaut32/variant.c 2006-11-18 22:39:11.0 -0500
@@ -2856,6 +2856,40 @@
#undef _VARCMP
}
+static HRESULT VARIANT_InvokeDispatchOp(LPVARIANT left, LPVARIANT right,
+LPVARIANT result, HRESULT WINAPI (* pOperatorFunc)(LPVARIANT, LPVARIANT, LPVARIANT))
+{
+HRESULT hres;
+VARIANT leftVar, rightVar;
+LPVARIANT leftResult, rightResult;
+static DISPPARAMS emptyParams = { NULL, NULL, 0, 0 };
+
+if ((V_VT(left) VT_TYPEMASK) == VT_DISPATCH) {
+leftResult = leftVar;
+if (NULL == V_DISPATCH(left)) return DISP_E_TYPEMISMATCH;
+hres = IDispatch_Invoke(V_DISPATCH(left), DISPID_VALUE, IID_NULL,
+LOCALE_USER_DEFAULT, DISPATCH_PROPERTYGET, emptyParams, leftResult,
+NULL, NULL);
+if (!SUCCEEDED(hres)) return hres;
+} else {
+leftResult = left;
+}
+if ((V_VT(right) VT_TYPEMASK) == VT_DISPATCH) {
+rightResult = rightVar;
+if (NULL == V_DISPATCH(right)) return DISP_E_TYPEMISMATCH;
+hres = IDispatch_Invoke(V_DISPATCH(right), DISPID_VALUE, IID_NULL,
+LOCALE_USER_DEFAULT, DISPATCH_PROPERTYGET, emptyParams, rightResult,
+NULL, NULL);
+if (!SUCCEEDED(hres)) return hres;
+} else {
+rightResult = right;
+}
+hres = pOperatorFunc(leftResult, rightResult, result);
+if (leftResult != left) VariantClear(leftResult);
+if (rightResult != right) VariantClear(rightResult);
+return hres;
+}
+
/**
* VarAnd [OLEAUT32.142]
*
@@ -2884,6 +2918,13 @@
TRACE((%p-(%s%s),%p-(%s%s),%p)\n, left, debugstr_VT(left),
debugstr_VF(left), right, debugstr_VT(right), debugstr_VF(right), result);
+/* Handle VT_DISPATCH by recursively calling op on result of IDispatch_Invoke */
+if (((V_VT(left) VT_TYPEMASK) == VT_DISPATCH ||
+(V_VT(right) VT_TYPEMASK) == VT_DISPATCH)
+(V_VT(left) VT_TYPEMASK) != VT_NULL
+(V_VT(right) VT_TYPEMASK) != VT_NULL)
+return VARIANT_InvokeDispatchOp(left, right, result, VarAnd);
+
leftvt = V_VT(left)VT_TYPEMASK;
rightvt = V_VT(right)VT_TYPEMASK;
leftExtraFlags = V_VT(left)(~VT_TYPEMASK);
@@ -3114,6 +3155,13 @@
debugstr_VF(left), right, debugstr_VT(right), debugstr_VF(right),
result);
+/* Handle VT_DISPATCH by recursively calling op on result of IDispatch_Invoke */
+if (((V_VT(left) VT_TYPEMASK) == VT_DISPATCH ||
+(V_VT(right) VT_TYPEMASK) == VT_DISPATCH)
+(V_VT(left) VT_TYPEMASK) != VT_NULL
+(V_VT(right) VT_TYPEMASK) != VT_NULL)
+return VARIANT_InvokeDispatchOp(left, right, result, VarAdd);
+
VariantInit(lv);
VariantInit(rv);
VariantInit(tv);
@@ -3304,6 +3352,13 @@
debugstr_VF(left), right, debugstr_VT(right), debugstr_VF(right),
result);
+/* Handle VT_DISPATCH by recursively calling op on result of IDispatch_Invoke */
+if (((V_VT(left) VT_TYPEMASK) == VT_DISPATCH ||
+(V_VT(right) VT_TYPEMASK) == VT_DISPATCH)
+(V_VT(left) VT_TYPEMASK) != VT_NULL
+(V_VT(right) VT_TYPEMASK) != VT_NULL)
+return VARIANT_InvokeDispatchOp(left, right, result, VarMul);
+
VariantInit(lv);
VariantInit(rv);
VariantInit(tv);
@@ -3453,6 +3508,13 @@
TRACE((%p-(%s%s),%p-(%s%s),%p)\n, left, debugstr_VT(left),
debugstr_VF(left), right, debugstr_VT(right), debugstr_VF(right), result);
+/* Handle VT_DISPATCH by recursively calling op on result of IDispatch_Invoke */
+if (((V_VT(left) VT_TYPEMASK) == VT_DISPATCH ||
+(V_VT(right) VT_TYPEMASK) == VT_DISPATCH)
+(V_VT(left) VT_TYPEMASK) != VT_NULL
+(V_VT(right) VT_TYPEMASK) != VT_NULL)
+return VARIANT_InvokeDispatchOp(left, right, result, VarDiv);
+
/* Native
oleaut32: implement underscore-prefix overload (was Re: oleaut32: ITypeInfo_fnInvoke behavior on PARAMFLAG_FOPT without PARAMFLAG_FHASDEFAULT)
Alex Villacís Lasso escribió:
Robert Shearman escribió:
[EMAIL PROTECTED] wrote:
In a tax app written in Visual Basic/ADO, I found the following
problem:
In dlls/oleaut32/typelib.c, in function ITypeInfo_fnInvoke(), the
following code is found (around line 5569).
VARIANTARG *missing_arg = INVBUF_GET_MISSING_ARG_ARRAY(buffer,
func_desc-cParams);
V_VT(arg) = VT_VARIANT | VT_BYREF;
V_VARIANTREF(arg) = missing_arg[i];
V_VT(V_VARIANTREF(arg)) = VT_ERROR;
V_ERROR(V_VARIANTREF(arg)) = DISP_E_PARAMNOTFOUND;
This code runs when a parameter is found that has the PARAMFLAG_FIN and
PARAMFLAG_FOPT flags, but not the PARAMFLAG_FHASDEFAULT flag. As far
as I
understand, this code is supposed to supply a variant that might
hold an
output value. However, in the Append method of the Fields object within
the Recordset object of Microsoft ADODB 2.7, the following
declaration is
found:
trace:ole:ITypeInfo_fnInvoke invoking:
LAppend(5)
parm0: LName
parm1: LType
parm2: LDefinedSize
parm3: LAttrib
parm4: LFieldValue
memid is 0003
Param 0:
tdesc.vartype 8 (VT_BSTR)
u.paramdesc.wParamFlags PARAMFLAG_FIN
u.paramdesc.lpex (nil)
Param 1:
tdesc.vartype 29 (VT_USERDEFINED ref = 2bc)
u.paramdesc.wParamFlags PARAMFLAG_FIN
u.paramdesc.lpex (nil)
Param 2:
tdesc.vartype 29 (VT_USERDEFINED ref = 1c84)
u.paramdesc.wParamFlags PARAMFLAG_FIN PARAMFLAG_FOPT
PARAMFLAG_FHASDEFAULT
u.paramdesc.lpex 0x199868
Param 3:
tdesc.vartype 29 (VT_USERDEFINED ref = 320)
u.paramdesc.wParamFlags PARAMFLAG_FIN PARAMFLAG_FOPT
PARAMFLAG_FHASDEFAULT
u.paramdesc.lpex 0x1998d0
Param 4:
tdesc.vartype 12 (VT_VARIANT)
u.paramdesc.wParamFlags PARAMFLAG_FIN PARAMFLAG_FOPT
u.paramdesc.lpex (nil)
funckind: 1 (pure virtual)
invkind: 1 (func)
callconv: 4 (stdcall)
oVft: 52
cParamsOpt: 1
wFlags: 0
elemdescFunc (return value type):
tdesc.vartype 25 (VT_HRESULT)
u.paramdesc.wParamFlags PARAMFLAGS_NONE
u.paramdesc.lpex (nil)
helpstring: (null)
entry (ordinal): 0x
The implementation of the method in Microsoft ADODB 2.7 last parameter
(FieldValue) absolutely refuses to accept a VT_VARIANT | VT_BYREF
variant.
This result is not dependent of the type of variant pointed to by the
first-level variant - changing VT_ERROR to VT_EMPTY has no effect.
Only by
passing a VT_EMPTY instead of a VT_VARIANT | VT_BYREF can the
application
proceed normally. All oleaut32 tests still pass. Please comment if
this is
an appropriate fix for this issue.
Changelog:
* (PARAMFLAG_FIN | PARAMFLAG_FOPT) ~PARAMFLAG_FHASDEFAULT should
result
in a default parameter of VT_EMPTY, not a VT_VARIANT | VT_BYREF in
ITypeInfo_fnInvoke
I don't believe this is fix is correct. See the tests not included in
Wine yet here:
http://www.winehq.org/pipermail/wine-patches/2006-August/029511.html
In particular, this code:
+HRESULT WINAPI Widget_DoSomething(
+IWidget __RPC_FAR * iface,
+/* [in] */ double number,
+/* [out] */ BSTR *str1,
+/* [defaultvalue][in] */ BSTR str2,
+/* [optional][in] */ VARIANT __RPC_FAR *opt)
+{
+static const WCHAR szString[] = { 'S','t','r','i','n','g',0 };
+trace(DoSomething()\n);
+
+ok(number == 3.141, number(%f) != 3.141\n, number);
+ok(*str2 == '\0', str2(%s) != \\\n, wine_dbgstr_w(str2));
+ok(V_VT(opt) == VT_ERROR, V_VT(opt) should be VT_ERROR instead
of 0x%x\n, V_VT(opt));
+ok(V_ERROR(opt) == DISP_E_PARAMNOTFOUND, V_ERROR(opt) should
be DISP_E_PARAMNOTFOUND instead of 0x%08lx\n, V_ERROR(opt));
+*str1 = SysAllocString(szString);
+
+return S_FALSE;
+}
Bug http://bugs.winehq.org/show_bug.cgi?id=6638 was opened for this
problem. I have reasons to believe that this is a case of
(undocumented?) overloading with builtin oleaut32 calling the wrong
version of a method. The bug report has a full explanation of this,
and the reasons why I arrived at the overloading theory. However I
need an OLE Automation expert to verify my hypothesis. Please comment
on this (especially from the Codeweavers people).
Here is a patch that implements my hunch. This patch fixes the problem
on both my test app at bug #6638 and the tax app I try to run.
Changelog:
* When there are not enough actual parameters for invoking, look for a
possible overload with underscore prefix before trying the original
function.
--
The following cryptic message was allegedly found in the inner edge of a Windows
XP installation CD:
4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420
7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074
6865206461726B6E6573732062696E64207468656D2E0A
It is rumored that only a true Unix Wizard can decypher this mysterious message,
which supposedly encodes the true nature and purpose of the software.
Subdirectorios comunes: wine-0.9.25-cvs/dlls
Re: oleaut32: implement underscore-prefix overload (was Re: oleaut32: ITypeInfo_fnInvoke behavior on PARAMFLAG_FOPT without PARAMFLAG_FHASDEFAULT)
Robert Shearman escribió:
Alex Villacís Lasso wrote:
Here is a patch that implements my hunch. This patch fixes the
problem on both my test app at bug #6638 and the tax app I try to run.
There are a lot of wrong ways to fix the particular bug you are
looking at, but only one right way. If you have a doubt, then you
should write a test program.
Anyway, does the attached patch fix the test app for you?
diff --git a/dlls/oleaut32/typelib.c b/dlls/oleaut32/typelib.c
index a12deb1..263d2c2 100644
--- a/dlls/oleaut32/typelib.c
+++ b/dlls/oleaut32/typelib.c
@@ -5562,11 +5562,15 @@ static HRESULT WINAPI ITypeInfo_fnInvoke
}
else
{
-VARIANTARG *missing_arg =
INVBUF_GET_MISSING_ARG_ARRAY(buffer, func_desc-cParams);
-V_VT(arg) = VT_VARIANT | VT_BYREF;
-V_VARIANTREF(arg) = missing_arg[i];
-V_VT(V_VARIANTREF(arg)) = VT_ERROR;
-V_ERROR(V_VARIANTREF(arg)) = DISP_E_PARAMNOTFOUND;
+if (rgvt[i] == (VT_VARIANT | VT_BYREF))
+{
+VARIANTARG *missing_arg =
INVBUF_GET_MISSING_ARG_ARRAY(buffer, func_desc-cParams);
+V_VT(arg) = VT_VARIANT | VT_BYREF;
+V_VARIANTREF(arg) = missing_arg[i];
+arg = missing_arg[i];
+}
+V_VT(arg) = VT_ERROR;
+V_ERROR(arg) = DISP_E_PARAMNOTFOUND;
}
}
else
Yes, it does fix the bug. Thanks! So, was it only a coincidence that the
failing case was an Append procedure in a class that also had an _Append
procedure?
--
The following cryptic message was allegedly found in the inner edge of a Windows
XP installation CD:
4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420
7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074
6865206461726B6E6573732062696E64207468656D2E0A
It is rumored that only a true Unix Wizard can decypher this mysterious message,
which supposedly encodes the true nature and purpose of the software.
Re: Re: oleaut32: ITypeInfo_fnInvoke behavior on PARAMFLAG_FOPT without PARAMFLAG_FHASDEFAULT
Robert Shearman escribió:
[EMAIL PROTECTED] wrote:
In a tax app written in Visual Basic/ADO, I found the following problem:
In dlls/oleaut32/typelib.c, in function ITypeInfo_fnInvoke(), the
following code is found (around line 5569).
VARIANTARG *missing_arg = INVBUF_GET_MISSING_ARG_ARRAY(buffer,
func_desc-cParams);
V_VT(arg) = VT_VARIANT | VT_BYREF;
V_VARIANTREF(arg) = missing_arg[i];
V_VT(V_VARIANTREF(arg)) = VT_ERROR;
V_ERROR(V_VARIANTREF(arg)) = DISP_E_PARAMNOTFOUND;
This code runs when a parameter is found that has the PARAMFLAG_FIN and
PARAMFLAG_FOPT flags, but not the PARAMFLAG_FHASDEFAULT flag. As far
as I
understand, this code is supposed to supply a variant that might hold an
output value. However, in the Append method of the Fields object within
the Recordset object of Microsoft ADODB 2.7, the following
declaration is
found:
trace:ole:ITypeInfo_fnInvoke invoking:
LAppend(5)
parm0: LName
parm1: LType
parm2: LDefinedSize
parm3: LAttrib
parm4: LFieldValue
memid is 0003
Param 0:
tdesc.vartype 8 (VT_BSTR)
u.paramdesc.wParamFlags PARAMFLAG_FIN
u.paramdesc.lpex (nil)
Param 1:
tdesc.vartype 29 (VT_USERDEFINED ref = 2bc)
u.paramdesc.wParamFlags PARAMFLAG_FIN
u.paramdesc.lpex (nil)
Param 2:
tdesc.vartype 29 (VT_USERDEFINED ref = 1c84)
u.paramdesc.wParamFlags PARAMFLAG_FIN PARAMFLAG_FOPT
PARAMFLAG_FHASDEFAULT
u.paramdesc.lpex 0x199868
Param 3:
tdesc.vartype 29 (VT_USERDEFINED ref = 320)
u.paramdesc.wParamFlags PARAMFLAG_FIN PARAMFLAG_FOPT
PARAMFLAG_FHASDEFAULT
u.paramdesc.lpex 0x1998d0
Param 4:
tdesc.vartype 12 (VT_VARIANT)
u.paramdesc.wParamFlags PARAMFLAG_FIN PARAMFLAG_FOPT
u.paramdesc.lpex (nil)
funckind: 1 (pure virtual)
invkind: 1 (func)
callconv: 4 (stdcall)
oVft: 52
cParamsOpt: 1
wFlags: 0
elemdescFunc (return value type):
tdesc.vartype 25 (VT_HRESULT)
u.paramdesc.wParamFlags PARAMFLAGS_NONE
u.paramdesc.lpex (nil)
helpstring: (null)
entry (ordinal): 0x
The implementation of the method in Microsoft ADODB 2.7 last parameter
(FieldValue) absolutely refuses to accept a VT_VARIANT | VT_BYREF
variant.
This result is not dependent of the type of variant pointed to by the
first-level variant - changing VT_ERROR to VT_EMPTY has no effect.
Only by
passing a VT_EMPTY instead of a VT_VARIANT | VT_BYREF can the
application
proceed normally. All oleaut32 tests still pass. Please comment if
this is
an appropriate fix for this issue.
Changelog:
* (PARAMFLAG_FIN | PARAMFLAG_FOPT) ~PARAMFLAG_FHASDEFAULT should
result
in a default parameter of VT_EMPTY, not a VT_VARIANT | VT_BYREF in
ITypeInfo_fnInvoke
I don't believe this is fix is correct. See the tests not included in
Wine yet here:
http://www.winehq.org/pipermail/wine-patches/2006-August/029511.html
In particular, this code:
+HRESULT WINAPI Widget_DoSomething(
+IWidget __RPC_FAR * iface,
+/* [in] */ double number,
+/* [out] */ BSTR *str1,
+/* [defaultvalue][in] */ BSTR str2,
+/* [optional][in] */ VARIANT __RPC_FAR *opt)
+{
+static const WCHAR szString[] = { 'S','t','r','i','n','g',0 };
+trace(DoSomething()\n);
+
+ok(number == 3.141, number(%f) != 3.141\n, number);
+ok(*str2 == '\0', str2(%s) != \\\n, wine_dbgstr_w(str2));
+ok(V_VT(opt) == VT_ERROR, V_VT(opt) should be VT_ERROR instead
of 0x%x\n, V_VT(opt));
+ok(V_ERROR(opt) == DISP_E_PARAMNOTFOUND, V_ERROR(opt) should be
DISP_E_PARAMNOTFOUND instead of 0x%08lx\n, V_ERROR(opt));
+*str1 = SysAllocString(szString);
+
+return S_FALSE;
+}
Bug http://bugs.winehq.org/show_bug.cgi?id=6638 was opened for this
problem. I have reasons to believe that this is a case of
(undocumented?) overloading with builtin oleaut32 calling the wrong
version of a method. The bug report has a full explanation of this, and
the reasons why I arrived at the overloading theory. However I need an
OLE Automation expert to verify my hypothesis. Please comment on this
(especially from the Codeweavers people).
--
The following cryptic message was allegedly found in the inner edge of a Windows
XP installation CD:
4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420
7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074
6865206461726B6E6573732062696E64207468656D2E0A
It is rumored that only a true Unix Wizard can decypher this mysterious message,
which supposedly encodes the true nature and purpose of the software.
Re: gdi32: Remove call to CreateCompatibleDC() from GetDIBits() implementation (try 1)
Alex Villacís Lasso escribió: Alex Villacís Lasso escribió: Huw Davies escribió: On Fri, Oct 20, 2006 at 05:49:09PM -0500, Alex Villacís Lasso wrote: This is the first attempt at a patch that will fix the debug assertion when icons are rendered into metafiles (triggered by Enterprise Architect 6.5, and possibly others). This patch simply removes mentions of memdc, created by a call to CreateCompatibleDC(), and redirects calls to GetDIBColorTable() to use the original DC instead of memdc. Intends to fix bug #6439. Now with patch. This can't work, since the bitmap needs to be selected into the dc for GetDIBColorTable to succeed and you're not allow to call GetDIBits with the bitmap selected into the dc... Huw. Please correct me if the details of my understanding are wrong in any way. The problem is that in the wine implementation, the palette is *not* stored anywhere inside the returned HBITMAP from CreateDIBSection(). Instead, the HDC used by CreateDIBSection must implement the pCreateDIBSection (this already leads to loss of palette information if it doesn't, for example in enhmfdrv), and then pCreateDIBSection is called, and somehow associates the HBITMAP with the actual implementation (in winex11drv, an XContext is used to save the pointer to a X_PHYSBITMAP, indexed by the HBITMAP). The method of getting to the palette information given an arbitrary DIB HBITMAP is private to the driver, and the functions contained in the BITMAPOBJ structure are not enough - a PHYSDEV is also required, usually provided by the DC. Million dollar question: what happens in the current implementation if a DIB created with a reference DC that saves the palette with method A is used with GetDIBits() and a reference HDC that expects a PHYSDEV with a different method B of saving the palette? Also, how do we get the palette information from GetDIBits() if the reference HDC does not support pGetDIBColorTable()? Given that, I thought of a few solutions to get the palette information from a DIB without CreateCompatibleDC(): - Select the HBITMAP into the reference DC inside the implementation of GetDIBits(), then call GetDIBColorTable() on the reference DC. Although the HBITMAP should not be selected into the reference DC before calling GetDIBits(), MSDN says nothing about GetDIBits() itself selecting the bitmap into the reference DC. - Add a new field to BITMAPOBJ with the PHYSDEV from the reference DC. Then, the corresponding function pGetDIBColorTable could be called with the proper parameters without the need of a new DC. Palette information is still lost if reference DC of CreateDIBSection does not support pCreateDIBSection(). - Add a new field to BITMAPOBJ for the sole purpose of storing a copy of the DIB palette when calling CreateDIBSection(), and use it for GetDIBits(). Requires synchronization when calling SetDIBColorTable(), and possibly in other places, and also a rewrite of GetDIBColorTable(). However, this has the advantage that no palette information will be lost when creating a DIB section with a reference DC that does not implement pCreateDIBsection. The best method IMHO. What do you think of these suggestions? Any comments are welcome. Alex Villacís Lasso Here is a patch that implements option 3 described above. Changelog: * Store a copy of the DIB palette when creating a dibsection, and use it to remove the need to use CreateCompatibleDC() in GetDIBits() function. Any comment on this patch (whether it needs cleaning up or anything else)? -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.
Re: gdi32: Remove call to CreateCompatibleDC() from GetDIBits() implementation (try 1)
Huw Davies escribió: On Fri, Oct 20, 2006 at 05:49:09PM -0500, Alex Villacís Lasso wrote: This is the first attempt at a patch that will fix the debug assertion when icons are rendered into metafiles (triggered by Enterprise Architect 6.5, and possibly others). This patch simply removes mentions of memdc, created by a call to CreateCompatibleDC(), and redirects calls to GetDIBColorTable() to use the original DC instead of memdc. Intends to fix bug #6439. Now with patch. This can't work, since the bitmap needs to be selected into the dc for GetDIBColorTable to succeed and you're not allow to call GetDIBits with the bitmap selected into the dc... Huw. Please correct me if the details of my understanding are wrong in any way. The problem is that in the wine implementation, the palette is *not* stored anywhere inside the returned HBITMAP from CreateDIBSection(). Instead, the HDC used by CreateDIBSection must implement the pCreateDIBSection (this already leads to loss of palette information if it doesn't, for example in enhmfdrv), and then pCreateDIBSection is called, and somehow associates the HBITMAP with the actual implementation (in winex11drv, an XContext is used to save the pointer to a X_PHYSBITMAP, indexed by the HBITMAP). The method of getting to the palette information given an arbitrary DIB HBITMAP is private to the driver, and the functions contained in the BITMAPOBJ structure are not enough - a PHYSDEV is also required, usually provided by the DC. Million dollar question: what happens in the current implementation if a DIB created with a reference DC that saves the palette with method A is used with GetDIBits() and a reference HDC that expects a PHYSDEV with a different method B of saving the palette? Also, how do we get the palette information from GetDIBits() if the reference HDC does not support pGetDIBColorTable()? Given that, I thought of a few solutions to get the palette information from a DIB without CreateCompatibleDC(): - Select the HBITMAP into the reference DC inside the implementation of GetDIBits(), then call GetDIBColorTable() on the reference DC. Although the HBITMAP should not be selected into the reference DC before calling GetDIBits(), MSDN says nothing about GetDIBits() itself selecting the bitmap into the reference DC. - Add a new field to BITMAPOBJ with the PHYSDEV from the reference DC. Then, the corresponding function pGetDIBColorTable could be called with the proper parameters without the need of a new DC. Palette information is still lost if reference DC of CreateDIBSection does not support pCreateDIBSection(). - Add a new field to BITMAPOBJ for the sole purpose of storing a copy of the DIB palette when calling CreateDIBSection(), and use it for GetDIBits(). Requires synchronization when calling SetDIBColorTable(), and possibly in other places, and also a rewrite of GetDIBColorTable(). However, this has the advantage that no palette information will be lost when creating a DIB section with a reference DC that does not implement pCreateDIBsection. The best method IMHO. What do you think of these suggestions? Any comments are welcome. Alex Villacís Lasso -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.
Re: Bug #6439: requesting explanation of GDI_CheckNotLock in order to fix
Vitaliy Margolen escribió: Alex Villacís Lasso wrote: I would like to draw attention to bug #6439 Why that bug in particular? Can we pick any other? Yes, you can: http://bugs.winehq.org/buglist.cgi?query_format=short_desc_type=allwordssubstrshort_desc=long_desc_type=substringlong_desc=_CheckNotSysLevelbug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=changedin=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Bug+Numberfield0-0-0=nooptype0-0-0=noopvalue0-0-0= This search lists 11 (unfixed) bugs that mention _CheckNotSysLevel. Sorry if I sounded like a newbie, but the question was made in order to avoid sending a patch that would be immediately rejected with your fix is incorrect, this should be fixed in xyz way at foo.c ... The only users of _CheckNotSysLevel in the Wine tree are dlls/user and dll/gdi . In dlls/user the pattern seems to be to use USER_Lock() and USER_Unlock() in strict pairs to protect blocks of code and not call any other functions that use USER_CheckNotLock(). In dlls/gdi the lock is taken once every time a reference to a GDI object is requested, but the rule about not calling other functions that check GDI_CheckNotLock() can be violated (at least in my bug) on the rendering of a metafile, as shown by the sequence: (App tries to draw an icon into a metafile) DrawIconEx calls into StretchBlt (dlls/gdi/bitblt.c:140) StretchBlt calls DC_GetDCUpdate, then DC_GetDCPtr . Both of these functions increment the GDI lock, so it ends up with a lock count of (at least) 2. (dlls/gdi/bitblt.c:148) With lock held, StretchBlt calls into dcDst-funcs-pStretchBlt. Since this is a metafile, it calls into EMFDRV_StretchBlt (dlls/gdi/enhmfdrv/bitblt.c:186) EMFDRV_StretchBlt delegates to EMFDRV_BitBlockTransfer (dlls/gdi/enhmfdrv/bitblt.c:163) EMFDRV_BitBlockTransfer calls into GetDIBits -- possible source of bug? (dlls/gdi/dib.c:556) GetDIBits calls CreateCompatibleDC with the source HDC (dlls/gdi/dc.c:728) CreateCompatibleDC() calls into GDI_CheckNotLock unconditionally. But StretchBlt already raised the lock count -- debug assertion. So, when metafiles are involved, this sequence of calls triggers the debug assertion in CreateCompatibleDC(). Since I don't really see the point of having the assertion in CreateCompatibleDC(), I was planning to send a patch to simply remove the assertion. However, the assertion must be there for a reason (debug a deadlock, maybe), so I thought I would check with others with more experience in GDI. If this assertion has to stay, then the metafile functions should be reworked to remove calls to GetDIBits or any other GDI calls that check the assertion. In fact, any GDI call that uses CreateDC[AW], CreateCompatibleDC or DeleteDC must not be called with the GDI lock held, because of the debug assertion. -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.
Bug #6439: requesting explanation of GDI_CheckNotLock in order to fix
I would like to draw attention to bug #6439 (http://bugs.winehq.org/show_bug.cgi?id=6439) in which Enterprise Architect 6.5 (trial version at http://www.sparxsystems.com.au/bin/easetup.exe) crashes with a debug assertion on _CheckNotSysLevel, as detailed in the bug report. From the winedbg trace, the inmediate cause of this debug assertion is the call of GDI_CheckNotLock() at the very start of CreateCompatibleDC(), when the stack of callers in the same thread have already taken references to GDI objects via GDI_GetObjPtr(). The basic question is: why is _CheckNotSysLevel required at CreateCompatibleDC()? What kind of damage might be caused by the removal of the check (in CreateCompatibleDC() and DeleteDC())? On Enterprise Architect, the removal of the assertions allow the app to load the sample file (EAExample.eap) correctly without crashing, and everything appears to work normally. -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.
ping about bug #1598
Has there been any discussion or progress on how to fix bug #1598 about Delphi/VisualBasic applications not having minimize/maximize decorations (http://bugs.winehq.org/show_bug.cgi?id=1598)? According to one of the comments, the window management code would not be touched before 0.9 . However wine is already in beta status and the bug remains unfixed. Should this be fixed in the wine side, or the metacity side? -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.
Re: Wine and HeidiSQL
Ansgar Becker escribió: Hi there, I'm Ansgar Becker, the main-author of HeidiSQL. I saw that HeidiSQL is in your appdb! very cool ;) http://appdb.winehq.org/appview.php?iAppId=3326 However, some of the buttons on HeidiSQL's main-toolbar are twisted. I'm not a C programmer, so I'm a bit lost in Wine... but I can fix it in HeidiSQL. The only thing is, how to properly detect if I'm running under Wine? Any help would be appreciated! Greetings and thanks a lot! Ansgar The proper fix is not for HeidiSQL to detect Wine, but for Wine to be fixed so HeidiSQL displays buttons correctly. Hmm... I see HeidiSQL is a Borland Delphi (Pascal) app. Is it also subject to the same bug under GNOME/Metacity as the one described in http://bugs.winehq.org/show_bug.cgi?id=1598 (KDE is unaffected)? Maybe you should file a bug report on the button issue, and (if affected) add yourself as watcher of bug #1598. BTW, what wine version are you using (latest CVS is 0.9.22). Alex Villacís Lasso -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.
Re: KERNEL: honor additional DLL search paths under HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths
Vitaliy Margolen escribió: Alex Villacís Lasso wrote: Mike McCormack escribió: Alex Villacís Lasso wrote: Changelog: * Check under HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\\EXENAME.EXE for additional directory locations to search for DLLs. Fixes Dreamweaver MX 6.0. This change is incorrect. The App Pathes key is checked by ShellExecute, not by CreateProcess. Try running wine start exename.exe Mike [EMAIL PROTECTED] Dreamweaver MX]$ wine start Dreamweaver.exe LC:\\Archivos de programa\\Macromedia\\Dreamweaver MX\\Configuration\\JSExtensions\\DWEMLaunch.dll) not found Dreamweaver still can't find the DLL without my patch, even with the start command, as demonstrated in the previous trace. Did you mean that my patch *should* have placed the check in ShellExecute? Does cmd.exe from Windows XP use CreateProcess or ShellExecute? I plan to install DreamWeaver MX 6 inside a virtual machine, to check actual behavior. If cmd.exe uses CreateProcess and your statement is correct, then the error message should also appear when Dreamweaver.exe is executed from the command line. You have to run it from other directory. Actually from _any_ directory but the one that exe is in. Don't ask me - ask m$ why they came up with this sort of stuff. Btw it will fail on win exactly the same way. Vitaliy [EMAIL PROTECTED] ~]$ pwd /home/alex [EMAIL PROTECTED] ~]$ wine start C:\\Archivos de programa\\Macromedia\\Dreamweaver MX\\Dreamweaver.exe fixme:exec:SHELL_execute flags ignored: 0x0500 [EMAIL PROTECTED] ~]$ fixme:ole:CoRegisterMessageFilter message filter has been registered, but will not be used fixme:system:SystemParametersInfoW Unimplemented action: 65 (SPI_SETSOUNDSENTRY)fixme:shell:SHGetFileInfoW set icon to shell size, stub fixme:shell:SHGetFileInfoW set icon to shell size, stub err:x11drv:X11DRV_CreateWindow invalid window height -2 err:x11drv:X11DRV_CreateWindow invalid window height -4 err:x11drv:X11DRV_CreateWindow invalid window height -2 err:x11drv:X11DRV_CreateWindow invalid window height -2 fixme:imm:ImmReleaseContext (0x101cc, 0x159a10): stub err:module:import_dll Library Gemstone.dll (which is needed by LC:\\Archivos de programa\\Macromedia\\Dreamweaver MX\\Configuration\\JSExtensions\\DWEMLaunch.dll) not found If my home directory is not considered being outside the Dreamweaver directory, I don't know what is. So, I should assume ShellExecute has code that duplicates the functionality I tried to add with my patch? Then I need to see why it is not working. Alex Villacís Lasso -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.
Re: How to report code errors?
Andrew Talbot escribió: How should one report minor code errors that don't necessarily produce known bad behaviour? To give a concrete example, in msacm32:driver.c acmDriverPriority(), formal parameter dwPriority is of type DWORD, which is unsigned, but it contains a line that reads: if (dwPriority 0) dwPriority = -1; ... which can never happen. Bugzilla seems inappropriate, so does wine-devel. If Coverity has abandoned us, would it be worth having a web/wiki page for posting any such code anomalies, so that the knowledgable might consider fixing them? Thanks, -- Andy. From windowssdk.msdn.microsoft.com: /dwPriority/ New priority for a global ACM driver identifier. A zero value specifies that the priority of the driver identifier should remain unchanged. A value of 1 specifies that the driver should be placed as the highest search priority driver. A value of - 1 specifies that the driver should be placed as the lowest search priority driver. Priorities are used only for global drivers. So -1 is actually a documented value for dwPriority. However, you are right in that a DWORD (a typedef for an unsigned long) won't ever return true for a comparison such as dwPriority 0. I will prepare a patch shortly. The wine-devel list might be actually a good place to post code anomalies, as illustrated by the fact that it caught my attention (because I put that code in the first place :-) ). Alex Villacís Lasso -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.
Re: Strange behavior in debugging of bug #5245, looking for comments
Louis Lenders wrote: Alex Villacís Lasso a_villacis at palosanto.com writes: Robert Shearman wrote: Alex Villacís Lasso wrote: Last weekend, I was trying to trace down bug #5245 (Run-Time error '6' overflow in terragen). With current CVS, the bug manifests itself with an Overflow dialog when starting up Terragen. However, this bug does *not* go away with a native oleaut32.dll (taken from win98), Isn't this just a bug in msvcrt? WINEDLLOVERRIDES=msvrt=n wine Terragen.exe works fine Confirmed, using native MSVCRT.DLL from Windows 98 fixes the bug. Now there is somewhere to look. Possibly the floating point behavior of wine's msvcrt.dll (math.c) differs from native, or else some flags are modified and not restored correctly. Need more tests to pinpoint the root cause (_matherr() ??). Alex Villacís Lasso
Strange behavior in debugging of bug #5245, looking for comments
Last weekend, I was trying to trace down bug #5245 (Run-Time error '6' overflow in terragen). With current CVS, the bug manifests itself with an Overflow dialog when starting up Terragen. However, this bug does *not* go away with a native oleaut32.dll (taken from win98), so this does not seem like an OLE bug. When running the program with the debugger, the underlying exception trapped before displaying the dialog reads inexact float result, with a backtrace that comes out of the bowels of msvbvm60.dll (weird - NOT inside Terragen.exe, and NOT inside Terragen.dll). However, if the user types pass at the debugger prompt, the dialog box does not appear, and the program continues normally. The exception occurs again whenever a File Open dialog is dismissed, and again, typing pass lets the program run normally. Several questions: - Can programs that execute floating-point instructions get the inexact float result exception without any explicit setup, or do they have to call some API in order to enable this notification? If so, is it described in MSDN? - Is the described behavior normal for the pass command? I was expecting the command to make the app show the Overflow dialog and then exit. Alex Villacís Lasso
Re: Strange behavior in debugging of bug #5245, looking for comments
Robert Shearman wrote: Alex Villacís Lasso wrote: Last weekend, I was trying to trace down bug #5245 (Run-Time error '6' overflow in terragen). With current CVS, the bug manifests itself with an Overflow dialog when starting up Terragen. However, this bug does *not* go away with a native oleaut32.dll (taken from win98), so this does not seem like an OLE bug. When running the program with the debugger, the underlying exception trapped before displaying the dialog reads inexact float result, with a backtrace that comes out of the bowels of msvbvm60.dll (weird - NOT inside Terragen.exe, and NOT inside Terragen.dll). However, if the user types pass at the debugger prompt, the dialog box does not appear, and the program continues normally. The exception occurs again whenever a File Open dialog is dismissed, and again, typing pass lets the program run normally. Several questions: - Can programs that execute floating-point instructions get the inexact float result exception without any explicit setup, or do they have to call some API in order to enable this notification? If so, is it described in MSDN? I believe it is an exception code raised by VB itself, not the result of a floating point operation. I've seen it before and it usually means that something unexpected happened under the covers in the VB runtime. However, I would have expected it to be a bug inside oleaut32, but that appears not to be the case here. Have you tried running with native ole32 and rpcrt4 as well to see if the bug disappears? I will try that when I get home. I remember that I even tried disassembling the code a few instructions before the addresses indicated in the stack trace, and I saw a FIMUL 0x0(%esi) as the source of the exception, in the code of msvbvm60.dll. - Is the described behavior normal for the pass command? I was expecting the command to make the app show the Overflow dialog and then exit. I don't think so. It should have the same behaviour as when running. Is this, therefore, a bug in the debugger? Alex Villacís Lasso
FIXED: Running siap and modules under wine, first steps
Maximiliano Curia wrote: On Monday 26 September 2005 15:00, Alex Villacís Lasso wrote: --- wine-20050830-cvs/dlls/oleaut32/typelib.c 2005-09-21 10:39:22.0 -0500 +++ wine-20050830-cvs-patch/dlls/oleaut32/typelib.c 2005-09-24 20:34:32.0 -0500 This patch executes the create interface code when typekind == TKIND_DISPATCH and wTypeFlags has TYPEFLAG_FDISPATCHABLE, regardless of the value of hRefType, in addition to the previous condition. I backported this patch to the version 20050310. If you are willing to let the test application available I could check the successfullness. --- wine-20050830-cvs/dlls/ole32/defaulthandler.c2005-09-23 10:51:36.0 -0500 +++ wine-20050830-cvs-patch/dlls/ole32/defaulthandler.c2005-09-25 19:19:31.0 -0500 @@ -1422,7 +1422,7 @@ * This is necessary because it's the only time the non-delegating * IUnknown pointer can be returned to the outside. */ - if (pUnkOuter IsEqualIID(IID_IUnknown, riid)) + if (pUnkOuter !IsEqualIID(IID_IUnknown, riid)) return CLASS_E_NOAGGREGATION; /* IsEqualIID was introduced after the version 20050310 that I'm using, and it seem that the: if ( (pUnkOuter!=NULL) (memcmp(IID_IUnknown, riid, sizeof(IID_IUnknown)) != 0) ) was replaced wrongly replaced. The (pUnkOuter !IsEqualIID(IID_IUnknown, riid)), should have the same efect as the previous code. Mr. Maximiliano Curia, could you please indicate where to get sample modules for SIAP? The default installer doesn't seem to come with any modules inside. Of course, this might be yet another Wine bug, so please confirm. Yes, of course, they are in: http://www.afip.gov.ar/seccion_rg.asp#programas The most used are: ftp://www.afip.gov.ar/iva40/iva_v4r1.exe (Taxes) ftp://www.afip.gov.ar/sijyp25/sijyp.25r0.exe (Pensions) Although, there are different programs for different activities (and I use 12 of these programs), these two are used by most of them. As of 2006-06-09, the CVS snapshot of Wine seems to run SIAP correctly. No crashes at all. Could you please be so kind as to test with the *most recent CVS snapshot* and confirm? Alex Villacís Lasso
Re: Wine 1.0 Tasks
Dan Kegel wrote: What other bugs should be fixed before 1.0? Let's nominate a few bugs to add to the 1.0 task list, discuss them a bit, and see what Alexandre thinks. For instance: I'd like one goal of 1.0 to be make Windows developers take Wine seriously. To achieve that, I think 1.0 has to support at least some Microsoft development tools well, including their IDEs and debuggers. It's probably unreasonable to require 1.0 to support .NET, so maybe supporting the last pre-.NET versions of Visual C++ (6.2?) and Visual Basic (6.0?) would be a good goal. And I don't think it's that unreasonable anymore; Wine is pretty close to being able to do that. What do y'all think? - Dan People who manage to compile VB apps under Wine with VB6 are likely to stumble upon this bug (at least under GNOME/Metacity): Bug 1598 - delphi 3 - managed - missing minimize/maximize buttons http://bugs.winehq.org/show_bug.cgi?id=1598 In addition, if anyone tries to use DBGRID32.OCX, they will surely hit this bug: Bug 3846 - Wine can't run Roderick Colenbrander's DBGRID32.OCX VB test apps yet http://bugs.winehq.org/show_bug.cgi?id=3846 Alex Villacís Lasso
Re: Anyone actively working on ITypeInfo_fnInvoke and VariantChangeType?
Bill Medland wrote: before I start trying to get up to speed on it. Congratulations. My company's program now gets somewhere with the builtin ole dlls (thanks to fixes in the out-of-process COM) so I am interested in trying to get it to work completely with them (especially since the native ones no longer work) What I have just fallen over is some VB that calls a method that results in ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT| VT_BYREF from VT_I2. So I changed the VB and ended up with ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT| VT_BYREF from VT_VARIANT|VT_BYREF. Now it seems to me that it ought at least to handle the second case, but that probably demonstrates that I don't know what I am talking about. Anyway; if someone is already working on that sort of thing then there is probably little point in me trying to learn it all. However if no-one is then I guess I will start trying to learn it. Comments? You might be interested in this bug report: http://bugs.winehq.org/show_bug.cgi?id=4370 Alex Villacís Lasso
Re: OLEAUT32: bug 4502 - request for comment before trying to fix
Robert Shearman wrote: The fix is to do the following in the conversion loop in ITypeInfo::Invoke: if (rgvt[i] == VT_VARIANT) VariantCopy(rgvarg[i], src_arg); else if ((rgvt[i] VT_BYREF) !V_ISBYREF(src_arg)) ... I don't have time to put this into patch form and test it, but hopefully someone else will. I tried this on the test app. It did not work. Sure, the code reaches the DispCallFunc call, but then the actual code from inside the control fails the call. It seems that the type of the variant is not adequate for the parameter. Visual Basic shows a message: Application-defined or user defined error. It seems that I will have to wait until I code enough of a test case for a *successful* ITypeInfo::Invoke() (there are two tests of failing calls, but none of a successful one), so that I can see what native OLEAUT32.DLL is sending as the parameter. Unless somebody else beats me on this. Alex Villacís Lasso
OLEAUT32: bug 4502 - request for comment before trying to fix
I would like to draw attention to bug 4502. This bug can cause any VB
application to crash when the DatePicker control is used, and an attempt
is made to assign a date value in VB code. Even though I found this bug
while testing an application I wrote, this might not be specific to this
application. It is only recently that I have some time to dedicate to
this bug, but I would like somebody to comment on this.
When the sample application is run with WINEDEBUG=ole,variant, the
failing invocation looks like this:
trace:ole:ITypeInfo_fnInvoke
(0x7fdd5440)(0x7fd9f61c,id=20,flags=0x0004,0x7fa3ee8c,(nil),0x7fa3ee6c,0x7fa3ee9c)
trace:ole:dump_DispParms args=1 named args=1
trace:ole:dump_Variant 0x7fa3eef4-{VT_DATE(38788,0x7fa3ec7c)
trace:variant:VarUdateFromDate (38788,0x,0x7fa3ec36)
trace:ole:dump_Variant ,2006/03/12 00:00:00}
trace:ole:ITypeInfo_fnInvoke invoking:
LValue(1)
parm0: LValue
memid is 0014
Param 0:
tdesc.vartype 12 (VT_VARIANT)
u.paramdesc.wParamFlags PARAMFLAG_FIN
u.paramdesc.lpex (nil)
funckind: 1 (pure virtual)
invkind: 4 (property put)
callconv: 4 (stdcall)
oVft: 224
cParamsOpt: 0
wFlags: 3c
elemdescFunc (return value type):
tdesc.vartype 25 (VT_HRESULT)
u.paramdesc.wParamFlags PARAMFLAGS_NONE
u.paramdesc.lpex (nil)
helpstring: LReturns/sets the current date.
entry: (null)
trace:ole:ITypeInfo_fnInvoke changing args
trace:ole:dump_Variant 0x7fa3eef4-{VT_DATE(38788,0x7fa3ec7c)
trace:variant:VarUdateFromDate (38788,0x,0x7fa3ec36)
trace:ole:dump_Variant ,2006/03/12 00:00:00}
trace:variant:VariantChangeTypeEx
(0x7fdd5520-(VT_DATE),0x7fa3eef4-(VT_DATE),0x0400,0x,VT_VARIANT)
trace:variant:VariantClear (0x7fa3ec40-(VT_EMPTY))
trace:variant:VariantClear (0x7fa3ec30-(VT_EMPTY))
trace:variant:VariantCopyInd (0x7fa3ec30-(VT_EMPTY),0x7fa3eef4-(VT_DATE))
trace:variant:VariantCopy (0x7fa3ec30-(VT_EMPTY),0x7fa3eef4-(VT_DATE))
trace:variant:VariantClear (0x7fa3ec30-(VT_EMPTY))
trace:variant:VARIANT_Coerce
(0x7fa3ec40-(VT_EMPTY),0x0400,0x,0x7fa3ec30-(VT_DATE),VT_VARIANT)
trace:variant:VariantClear (0x7fa3ec40-(VT_EMPTY))
trace:variant:VariantClear (0x7fa3ec30-(VT_DATE))
trace:variant:VariantChangeTypeEx returning 0x80020005,
0x7fdd5520-(VT_DATE)
err:ole:ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT from
VT_DATE
trace:ole:ITypeInfo_fnInvoke -- 0x80020005
The Property Put seems to be declared as taking one VT_VARIANT
parameter, and the VB code supplies a VT_DATE value. Therefore, an
attempt is made to coerce VT_DATE -- VT_VARIANT. However,
VariantChangeTypeEx() does not support conversion of *any* kind of
variant into VT_VARIANT, so the call fails, and this brings down the
application. I was on half a mind to add the VT_VARIANT conversion to
VariantChangeTypeEx() myself, but then I checked the tests for this
operation, and it seems that the absence of support for VT_VARIANT is
actually expected (unless I am misreading the code). Therefore, one of
the following two things is happening:
1) There is some error in the reading of the typelib, since a Property
Put should not have a VT_VARIANT parameter in the first place.
2) ITypeInfo::Invoke should do the VT_VARIANT conversion itself,
precisely because VariantChangeTypeEx() won't do it.
I am inclined to the second option, but I want to hear some comment
before attempting to create a patch.
Alex Villacís Lasso
Re: OLEAUT32: bug 4502 - request for comment before trying to fix
Alex Villacís Lasso wrote:
I would like to draw attention to bug 4502. This bug can cause any VB
application to crash when the DatePicker control is used, and an
attempt is made to assign a date value in VB code. Even though I found
this bug while testing an application I wrote, this might not be
specific to this application. It is only recently that I have some
time to dedicate to this bug, but I would like somebody to comment on
this.
When the sample application is run with WINEDEBUG=ole,variant, the
failing invocation looks like this:
trace:ole:ITypeInfo_fnInvoke
(0x7fdd5440)(0x7fd9f61c,id=20,flags=0x0004,0x7fa3ee8c,(nil),0x7fa3ee6c,0x7fa3ee9c)
trace:ole:dump_DispParms args=1 named args=1
trace:ole:dump_Variant 0x7fa3eef4-{VT_DATE(38788,0x7fa3ec7c)
trace:variant:VarUdateFromDate (38788,0x,0x7fa3ec36)
trace:ole:dump_Variant ,2006/03/12 00:00:00}
trace:ole:ITypeInfo_fnInvoke invoking:
LValue(1)
parm0: LValue
memid is 0014
Param 0:
tdesc.vartype 12 (VT_VARIANT)
u.paramdesc.wParamFlags PARAMFLAG_FIN
u.paramdesc.lpex (nil)
funckind: 1 (pure virtual)
invkind: 4 (property put)
callconv: 4 (stdcall)
oVft: 224
cParamsOpt: 0
wFlags: 3c
elemdescFunc (return value type):
tdesc.vartype 25 (VT_HRESULT)
u.paramdesc.wParamFlags PARAMFLAGS_NONE
u.paramdesc.lpex (nil)
helpstring: LReturns/sets the current date.
entry: (null)
trace:ole:ITypeInfo_fnInvoke changing args
trace:ole:dump_Variant 0x7fa3eef4-{VT_DATE(38788,0x7fa3ec7c)
trace:variant:VarUdateFromDate (38788,0x,0x7fa3ec36)
trace:ole:dump_Variant ,2006/03/12 00:00:00}
trace:variant:VariantChangeTypeEx
(0x7fdd5520-(VT_DATE),0x7fa3eef4-(VT_DATE),0x0400,0x,VT_VARIANT)
trace:variant:VariantClear (0x7fa3ec40-(VT_EMPTY))
trace:variant:VariantClear (0x7fa3ec30-(VT_EMPTY))
trace:variant:VariantCopyInd
(0x7fa3ec30-(VT_EMPTY),0x7fa3eef4-(VT_DATE))
trace:variant:VariantCopy (0x7fa3ec30-(VT_EMPTY),0x7fa3eef4-(VT_DATE))
trace:variant:VariantClear (0x7fa3ec30-(VT_EMPTY))
trace:variant:VARIANT_Coerce
(0x7fa3ec40-(VT_EMPTY),0x0400,0x,0x7fa3ec30-(VT_DATE),VT_VARIANT)
trace:variant:VariantClear (0x7fa3ec40-(VT_EMPTY))
trace:variant:VariantClear (0x7fa3ec30-(VT_DATE))
trace:variant:VariantChangeTypeEx returning 0x80020005,
0x7fdd5520-(VT_DATE)
err:ole:ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT
from VT_DATE
trace:ole:ITypeInfo_fnInvoke -- 0x80020005
The Property Put seems to be declared as taking one VT_VARIANT
parameter, and the VB code supplies a VT_DATE value. Therefore, an
attempt is made to coerce VT_DATE -- VT_VARIANT. However,
VariantChangeTypeEx() does not support conversion of *any* kind of
variant into VT_VARIANT, so the call fails, and this brings down the
application. I was on half a mind to add the VT_VARIANT conversion to
VariantChangeTypeEx() myself, but then I checked the tests for this
operation, and it seems that the absence of support for VT_VARIANT is
actually expected (unless I am misreading the code). Therefore, one of
the following two things is happening:
1) There is some error in the reading of the typelib, since a Property
Put should not have a VT_VARIANT parameter in the first place.
2) ITypeInfo::Invoke should do the VT_VARIANT conversion itself,
precisely because VariantChangeTypeEx() won't do it.
I am inclined to the second option, but I want to hear some comment
before attempting to create a patch.
Alex Villacís Lasso
After some digging, I found that bugs 4370 and 4573 seem to expose the
same problem. The root cause (in bug 4370) seems to be a patch by Robert
Shearman that rewrites ITypeInfo::Invoke to use VariantChangeTypeEx
(commit at
http://source.winehq.org/git/?p=wine.git;a=commit;h=8cf5373f60aca5345a0c55df2711a9f0b73b8133).
Saved me the trouble of the regression testing.
Alex Villacís Lasso
Re: OLEAUT32: Fix regression in OLEFontImpl_Clone
Alex Villacís Lasso wrote:
Lately, all VB6 applications crash on exit. This weekend, I found the
cause. Apparently the VB6 runtime creates a standard OLEFont object,
and then calls IFont::clone() on it to get a second object. At exit,
the VB6 runtime disposes of both objects. However, the recent OLEFont
changes introduced a bug in which the cloning fails to clone the
connection points associated with the object. Therefore the dispose of
one of the objects frees the connection points, and the dispose of the
second object crashes on attempt to dispose an already-freed object.
Changelog:
* Create new empty connection points on clone of OLEFont
Alex Villacís Lasso
--- wine-0.9.8-cvs/dlls/oleaut32/olefont.c 2006-02-14 10:38:35.0
-0500
+++ wine-0.9.8-cvs-patch/dlls/oleaut32/olefont.c2006-02-18
18:40:01.0 -0500
@@ -1113,6 +1113,19 @@
/* The cloned object starts with a reference count of 1 */
newObject-ref = 1;
+ /* We need to clone the connection points too. */
+ /* FIXME: should we just add a reference to the (shared) connection points?
*/
+ newObject-pPropertyNotifyCP = NULL;
+ newObject-pFontEventsCP = NULL;
+ CreateConnectionPoint((IUnknown*)newObject, IID_IPropertyNotifySink,
newObject-pPropertyNotifyCP);
+ CreateConnectionPoint((IUnknown*)newObject, IID_IFontEventsDisp,
newObject-pFontEventsCP);
+
+ if (!newObject-pPropertyNotifyCP || !newObject-pFontEventsCP)
+ {
+OLEFontImpl_Destroy(newObject);
+return E_OUTOFMEMORY;
+ }
+
*ppfont = (IFont*)newObject;
return S_OK;
Is there anything wrong with this patch? Not applied, and nobody has
commented on it either.
Alex Villacís Lasso
WINEMP3: increase factor from 4 to 12 in MPEG3_StreamSize
This is a summary of what I have been doing with winemp3 over the weekend.
First, the idea of a GStreamer wrapper for wine is a no-go because 1)
would not solve the jittering problem (more on this later), 2) I have
not found yet a streaming source for raw memory buffers (as opposed to
file/network streaming), 3) although GStreamer is LGPL, some of the
codecs might be proprietary, and this might cause legal problems later on.
I fired the ACMAPP.EXE demo program from MSDN (the one I used to improve
the msacm implementation), and noticed that MP3-encoded WAV files play
almost normally with this app. This means that the codec itself is not
the problem - the most likely source is the (odd?) use of msacm by
dsound, which is in turn invoked by native quartz.dll. Before reaching
this conclusion, I found that ACMAPP.EXE played the files without
jittering, but it stopped playing a few moments before the end of the
song. How much before depends on the actual length of the song but this
was annoying enough to be worth investigating. For example, one sample
song stopped playing 30 seconds before the actual end. However,
according to the app, playback was already at the end of the song.
It turns out that mpglib has a queue of undecoded data in its decoding
structure. On every call to the decodeMP3() function of mpglib, the
caller specifies either a buffer of new data, or NULL to use the
remaining data from a previous invocation. The buffer grows and shrinks
dynamically with the amount of unencoded data passed by the caller. What
was going on was the following:
- Caller (winmm) computes required output buffer for encoded input
buffer. This uses acmStreamSize, which in turn invokes MPEG3_StreamSize.
- MPEG3_StreamSize return a factor 4X for the size of the output buffer
(in my tests, a 2333-byte encoded buffer expands into (at most) 9332
bytes of output, or so reports winemp3).
- winmm happily calls acmStreamConvert() with a 2333 source buffer and a
9332 destination buffer.
- mpglib decodes as much as it can into the 9332-byte buffer. However,
in almost all cases, 9332 bytes is not enough to decode 2333 bytes of
MP3 data. This is important to note, because it means a non-trivial
amount of the MP3 data remains in the mpglib queue.
- acmStreamConvert() is called over and over, with a 2333 source buffer
and a 9332 destination buffer. The output buffer is always too small, so
the undecoded data in the mpglib buffers accumulates.
- winmm sends the last encoded buffer. Supposedly this means that
decoding is complete, but it isn't, because mpglib has a backlog of
undecoded data which has not been played. However, winmm stops there,
and the user notices the cut in the middle of the song.
In the same situation, L3CODECA.ACM reports a non-integer factor for the
output buffer, a little under 12X. Therefore L3CODECA.ACM always has
enough space to consume the full source buffer and therefore does not
cut the song in the middle.
The ideal solution would be to dynamically compute the expansion factor
based on the input and output bitrates. The attached patch raises the
expansion factor instead to 12X to ensure that mpglib can always decode
all the input data without running out of output space.
Changelog:
* Increase size factor from 4 to 12 in MPEG_StreamSize, otherwise mpglib
buffer queue grows
* Add TRACE of mpglib buffer queue for conversion.
Alex Villacís Lasso
diff -ur wine-0.9.7-cvs/dlls/msacm/winemp3/mpegl3.c wine-0.9.7-cvs-patch/dlls/msacm/winemp3/mpegl3.c
--- wine-0.9.7-cvs/dlls/msacm/winemp3/mpegl3.c 2005-11-28 15:57:27.0 -0500
+++ wine-0.9.7-cvs-patch/dlls/msacm/winemp3/mpegl3.c 2006-02-12 21:18:28.0 -0500
@@ -142,6 +142,17 @@
dst[1] = HIBYTE(s);
}
+static DWORD get_num_buffered_bytes(struct mpstr *mp)
+{
+DWORD numBuff = 0;
+struct buf * p = mp-tail;
+while (p) {
+numBuff += p-size - p-pos;
+p = p-next;
+}
+return numBuff;
+}
+
static void mp3_horse(PACMDRVSTREAMINSTANCE adsi,
const unsigned char* src, LPDWORD nsrc,
unsigned char* dst, LPDWORD ndst)
@@ -149,8 +160,13 @@
AcmMpeg3Data* amd = (AcmMpeg3Data*)adsi-dwDriver;
int size, ret;
DWORD dpos = 0;
+DWORD buffered_before;
+DWORD buffered_during;
+DWORD buffered_after;
+buffered_before = get_num_buffered_bytes(amd-mp);
ret = decodeMP3(amd-mp, src, *nsrc, dst, *ndst, size);
+buffered_during = get_num_buffered_bytes(amd-mp);
if (ret != MP3_OK)
{
*ndst = *nsrc = 0;
@@ -163,6 +179,9 @@
dst + dpos, *ndst - dpos, size);
} while (ret == MP3_OK);
*ndst = dpos;
+
+buffered_after = get_num_buffered_bytes(amd-mp);
+TRACE(before %ld put %ld during %ld after %ld\n, buffered_before, *nsrc, buffered_during, buffered_after);
}
Re: MSACM: winemp3 codec crashes on seek, (no longer) reimplement with libmad?
Alex Villacís Lasso wrote: Eric Pouech wrote: Alex Villacís Lasso wrote: Eric Pouech wrote: Are there any issues I should take into account before trying this? first of all, are we sure that the issue comes from the decoder itself (and not some wine wrapper around it) ? I performed the following test: with the sample VB application, I modified the winemp3 code to write the input buffer (mp3) and the decoded output buffer (PCM) at the end of separate files. Then I played the mp3 samples file. This one plays correctly (rules out mangling of input buffers). The output file has quirks, but plays a little better than the output from the VB application (no delays), which suggest that there are some timing issues with the winemp3 code, or that the output duration, as reported by winemp3, is slightly incorrect. or simply, that the sequence of: - getting mp3 encoded data - pushing them to the decoder for decoding - pushing the decoded data to the speaker runs slower than the expected pace... which doesn't blame only step2, or the decoder itself. for example, putting the decoder in a separate thread would greatly improve, or using smaller packets in step 1. I also ran tests with a different movie which uses the Indeo codecs (native) for decoding. This one runs smoothly (with audio AND video). In my opinion, this is additional evidence that the winemp3 codec is at fault (especially since my sample movie uses a not-installed DivX video codec which therefore does not consume any CPU, as it is running in audio-only mode). The native Indeo codec also does not crash on seek. On a side note, is there anybody in the list with experience with GStreamer programming? The base GStreamer framework is LGPL, so it *might* be legally possible to write a GStreamer wrapper for wine. Of course, there might be an architecture difference that makes this impossible, so any feedback will be appreciated. Alex Villacís Lasso Some more tests. I downloaded the latest version of mpglib, and compared it against the wine fork. Aside from extra spaces and an one-time-only initialization in the wine code, the current mpglib code is almost identical to the wine fork. However, the standalone mpglib decodes the extracted samples correctly. This means that there is something about the Wine environment that disturbs mpglib enough so that decoding no longer works correctly. I also noticed that mpglib uses malloc() and free() from glibc even inside the wine copy (one malloc()/free() pair per sample block to be decoded). Could this be causing some interference (especially since the wine architecture decodes in a separate thread)? Maybe it is worth it to use HeapAlloc()/HeapFree() instead. Alex Villacís Lasso
Re: MSACM: winemp3 codec crashes on seek, reimplement with libmad?
Eric Pouech wrote: Are there any issues I should take into account before trying this? first of all, are we sure that the issue comes from the decoder itself (and not some wine wrapper around it) ? I performed the following test: with the sample VB application, I modified the winemp3 code to write the input buffer (mp3) and the decoded output buffer (PCM) at the end of separate files. Then I played the mp3 samples file. This one plays correctly (rules out mangling of input buffers). The output file has quirks, but plays a little better than the output from the VB application (no delays), which suggest that there are some timing issues with the winemp3 code, or that the output duration, as reported by winemp3, is slightly incorrect. the second issue is that MAD is GPL... hence we cannot use it A+ Too bad. I was thinking about adding a configure check for libmad and linking to it, but then this would still disallow mixing the code. BTW, when was the winemp3 code forked form mpg123? Maybe it is high time for somebody (me?) to do a resync with the latest version of mpglib. Alex Villacís Lasso
Re: MSACM: winemp3 codec crashes on seek, (no longer) reimplement with libmad?
Eric Pouech wrote: Alex Villacís Lasso wrote: Eric Pouech wrote: Are there any issues I should take into account before trying this? first of all, are we sure that the issue comes from the decoder itself (and not some wine wrapper around it) ? I performed the following test: with the sample VB application, I modified the winemp3 code to write the input buffer (mp3) and the decoded output buffer (PCM) at the end of separate files. Then I played the mp3 samples file. This one plays correctly (rules out mangling of input buffers). The output file has quirks, but plays a little better than the output from the VB application (no delays), which suggest that there are some timing issues with the winemp3 code, or that the output duration, as reported by winemp3, is slightly incorrect. or simply, that the sequence of: - getting mp3 encoded data - pushing them to the decoder for decoding - pushing the decoded data to the speaker runs slower than the expected pace... which doesn't blame only step2, or the decoder itself. for example, putting the decoder in a separate thread would greatly improve, or using smaller packets in step 1. I also ran tests with a different movie which uses the Indeo codecs (native) for decoding. This one runs smoothly (with audio AND video). In my opinion, this is additional evidence that the winemp3 codec is at fault (especially since my sample movie uses a not-installed DivX video codec which therefore does not consume any CPU, as it is running in audio-only mode). The native Indeo codec also does not crash on seek. On a side note, is there anybody in the list with experience with GStreamer programming? The base GStreamer framework is LGPL, so it *might* be legally possible to write a GStreamer wrapper for wine. Of course, there might be an architecture difference that makes this impossible, so any feedback will be appreciated. Alex Villacís Lasso
MSACM: winemp3 codec crashes on seek, reimplement with libmad?
I was trying to exercise the winemp3 builtin codec using a Visual Basic control that essentially implements the Windows Media Player look (MSDXM.OCX). After specifying native quartz.dll for this app, I tested a few AVIs with mp3-encoded soundtracks. What I can notice is that the sound has very annoying jitters, and in addition, it crashes on a seek. Some people have noticed the jitters too (http://bugs.winehq.org/show_bug.cgi?id=3853). However, rather than trying to fix the wine fork of mpeglib, I was toying with the idea of reimplementing the codec as a libmad (GPL) wrapper. Are there any issues I should take into account before trying this? Alex Villacís Lasso
Re: OLEAUT32: add additional condition for creation of interface
Robert Shearman wrote:
Alex Villacís Lasso wrote:
diff -ur wine-0.9.6-cvs/dlls/oleaut32/typelib.c
wine-0.9.6-cvs-patch/dlls/oleaut32/typelib.c
--- wine-0.9.6-cvs/dlls/oleaut32/typelib.c2006-01-16
16:08:20.0 -0500
+++ wine-0.9.6-cvs-patch/dlls/oleaut32/typelib.c2006-01-24
21:53:48.0 -0500
@@ -5567,10 +5567,31 @@
ITypeInfo_AddRef(*ppTInfo);
result = S_OK;
}
-else if (hRefType == -1
-(((ITypeInfoImpl*) This)-TypeAttr.typekind == TKIND_DISPATCH)
-(((ITypeInfoImpl*) This)-TypeAttr.wTypeFlags TYPEFLAG_FDUAL))
+else if (
+(
+hRefType == -1
+(This-TypeAttr.typekind == TKIND_DISPATCH)
+(This-TypeAttr.wTypeFlags TYPEFLAG_FDUAL)
+)
+||
+(
+(This-TypeAttr.typekind == TKIND_DISPATCH)
+(This-TypeAttr.wTypeFlags TYPEFLAG_FDISPATCHABLE)
+)
+)
{
+ /* Report whether we are here because of the DBGRID32.OCX fix */
+ if (!(
+hRefType == -1
+(This-TypeAttr.typekind == TKIND_DISPATCH)
+(This-TypeAttr.wTypeFlags TYPEFLAG_FDUAL)
+ ))
+ {
+FIXME(ignoring hRefType = %d, TYPEFLAG_FDISPATCHABLE is
%s\n, +hRefType,
+(This-TypeAttr.wTypeFlags TYPEFLAG_FDISPATCHABLE) ?
set : not set);
+ } +
/* when we meet a DUAL dispinterface, we must create the interface
* version of it.
*/
This doesn't look right to me. We need tests for this situation that
will tell us whether we are adding a dirty hack or whether this
behaviour is correct. I can send you a test suite I have already built
for typelibs if you want to add to it.
Please do so. I do not think this is right either (even if DBGRID32.OCX
runs with it), and I would especially like to see cases where this patch
causes regressions. Maybe your test suite shows some of them already.
@@ -5598,8 +5619,47 @@
if(pRefType-reference == hRefType)
break;
}
-if(!pRefType)
- FIXME(Can't find pRefType for ref %lx\n, hRefType);
+if(!pRefType) {
+static const char * descTKIND[TKIND_MAX] = {
+TKIND_ENUM,
+TKIND_RECORD,
+TKIND_MODULE,
+TKIND_INTERFACE,
+TKIND_DISPATCH,
+TKIND_COCLASS,
+TKIND_ALIAS,
+TKIND_UNION,+};
+static const char * descTypeFlags[15] = {
+TYPEFLAG_FAPPOBJECT,
+TYPEFLAG_FCANCREATE,
+TYPEFLAG_FLICENSED,
+TYPEFLAG_FPREDECLID,
+TYPEFLAG_FHIDDEN,
+TYPEFLAG_FCONTROL,
+TYPEFLAG_FDUAL,
+TYPEFLAG_FNONEXTENSIBLE,
+TYPEFLAG_FOLEAUTOMATION,
+TYPEFLAG_FRESTRICTED,
+TYPEFLAG_FAGGREGATABLE,
+TYPEFLAG_FREPLACEABLE,
+TYPEFLAG_FDISPATCHABLE,
+TYPEFLAG_FREVERSEBIND,
+TYPEFLAG_FPROXY,
+};
+int i;
+
+FIXME(Can't find pRefType for ref %lx\n, hRefType);
+FIXME(\ttypekind is %s\n,
descTKIND[This-TypeAttr.typekind]);
+FIXME(\twTypeFlags are:);
+for (i = 0; i 15; i++) {
+if (This-TypeAttr.wTypeFlags (1 i))
+FIXME( %s, descTypeFlags[i]);
+}
+if (This-TypeAttr.wTypeFlags 0x8000)
+FIXME( %08x, This-TypeAttr.wTypeFlags 0x8000);
+FIXME(\n);
+}
if(pRefType hRefType != -1) {
ITypeLib *pTLib = NULL;
This clutters the code too much. There are already functions for
dumping the typelib that would work here instead, although I think
they don't use the FIXME channel.
So, which are they? I would like especially to dump the typelib of
DBGRID32.OCX and compare it with other (working) ActiveX controls, to
look for differences.
Alex Villacís Lasso
Re: StretchDIBits function problem.
Cyril Margorin wrote: Hello, I've discovered, that using of GetDIBits after StretchDIBits doesn't return correct data. More then - all pixels that it returns are black. In attachment the test function. Changelog: Cyril Margorin [EMAIL PROTECTED] add test of StretchDIBits()/GetDIBits() bunch to gdi/test/bitmap.c -- Cyril Margorin Do you know whether this test is related to this bug? - http://bugs.winehq.org/show_bug.cgi?id=201 Alex Villacís Lasso
Re: DINPUT: Enforce single mouse acquire
Dmitry Timoshkov wrote:
On Wed, 2006-01-25 at 17:32 -0500, Alex Villacís Lasso wrote:
+if (This == NULL) {
+ERR(mouse hook called with no current lock!\n);
+return 0;
+}
+
if (code != HC_ACTION) return CallNextHookEx( This-hook, code,
wparam, lparam );
You need to call CallNextHookEx in any case, otherwise it might break
other hooks in the chain. Probably just add a check for This being NULL
in the same place as the code checks for HC_ACTION.
The problem is that if (This == NULL), then This-hook cannot be
evaluated (for CallNextHookEx) without generating a segmentation fault.
This is the very situation the patch is trying to prevent.
Alex Villacís Lasso
Re: DINPUT: Enforce single mouse acquire
Dmitry Timoshkov wrote: On Wed, 2006-01-25 at 17:55 -0500, Alex Villacís Lasso wrote: The problem is that if (This == NULL), then This-hook cannot be evaluated (for CallNextHookEx) without generating a segmentation fault. This is the very situation the patch is trying to prevent. Sorry for not spotting it earlier. 'This' can't be NULL, that's an impossible situation. You need to debug it and find out why hook proc is being called without This-hook being set. I already did. The scenario is as follows: 1) Start Fate/Stay Night (current_lock starts as NULL) 2) Mouse gets acquired (current_lock becomes valid), and mouse function gets hooked 3) User selects About dialog. 3) About dialog attempts a second (nested) mouse acquire, which (before my patch) succeeds because there is no check on whether current_lock is already set. Again, current_lock is assigned (overwriting the previous value), and the mouse function gets hooked (again). Notice that the mouse function is now hooked twice. 4) User dismisses the About dialog. Second acquire is released. The current_lock pointer gets set to NULL, and the second instance of the mouse function gets unhooked, but the first instance (the one hooked at program startup) remains hooked, now with current_lock == NULL. 5) Mouse event happens. Function hook gets called, and tries to use the NULL pointer. Instant segmentation fault. The easiest way out of this (the one the patch implements) is to disallow nested acquires. It is a little more complicated if DirectInput actually requires support for nested acquires (why? I have only one mouse...) Alex Villacís Lasso
Re: DINPUT: Enforce single mouse acquire
Dmitry Timoshkov wrote: On Wed, 2006-01-25 at 18:19 -0500, Alex Villacís Lasso wrote: The easiest way out of this (the one the patch implements) is to disallow nested acquires. It is a little more complicated if DirectInput actually requires support for nested acquires (why? I have only one mouse...) But if you disallow nested acquires the check for This being NULL in the hook proc should not be needed, right? Good point. But it doesn't hurt either. This might be changed into an assertion, since that is what the hook expects. What do you think? Alex Villacís Lasso
Re: wine 0.9.5 - segmentation fault with some apps
[EMAIL PROTECTED] wrote:
Alex,
Thanks for the reply.
I am going to wait for a pre built (RPM package) for wine-0.9.6
because if I compile I think I can introduce too many variables.
Anyway, I am goig to report your sugestions with wine 0.9.5 and,
ASAP, with wine-0.9.6.
That might be a problem. It would be better if you could compile the
latest snapshot, or even better, the latest CVS, from scratch. This
would enable you to test any patches I (or somebody else) might send to
try and fix the problem.
Where can somebody download the application?
It is a commercial package. It can not be downloaded. Sorry
Is there a bug report for this application (bugs.winehq.org)?
No. If you guys wish I can do it (just going to wait for wine-0.9.6)
Please file the bug anyway. Then you can refer to the bug ID for future
discussion.
I also noticed I can do something like:
WINEDUBUG=+all winebdg user.exe
Are you interested in the output of the above? Winedbg does not segfault.
It freezes.
It should be WINEDEBUG=+all, not WINEDUBUG... might be the problem.
Your stack trace is missing the callback on where inside
wine the fault occurred.
I am sending, attached, all the trace . it is not too big but
I can notice there are some entries like:
__wine_exception_handler ntdll.dll.1009 .
I meant the stack trace (the one that is supposed to be generated on an
unhandled exception, and which contains information on which function
called which one, all the way to the point where the exception
occurred), not the debug trace (the one enabled by WINEDEBUG). However,
the debug trace was useful by itself.
The last lines of your trace show the following:
0009:Call ntdll.RtlImageNtHeader() ret=7fce61da
0009: *killed* exit_code=0
This is bad - RtlImageNtHeader should be supplied a non-NULL pointer,
and somebody passed it a NULL one instead. In addition, it seems there
is an issue with the exception handling in RtlImageNtHeader
From dlls/ntdll/loader.c:
/***
* RtlImageNtHeader (NTDLL.@)
*/
PIMAGE_NT_HEADERS WINAPI RtlImageNtHeader(HMODULE hModule)
{
IMAGE_NT_HEADERS *ret;
__TRY
{
IMAGE_DOS_HEADER *dos = (IMAGE_DOS_HEADER *)hModule;
ret = NULL;
if (dos-e_magic == IMAGE_DOS_SIGNATURE)
{
ret = (IMAGE_NT_HEADERS *)((char *)dos + dos-e_lfanew);
if (ret-Signature != IMAGE_NT_SIGNATURE) ret = NULL;
}
}
__EXCEPT_PAGE_FAULT
{
return NULL;
}
__ENDTRY
return ret;
}
The exception handler is supposed to return NULL in case of a page fault
(such as trying to access a NULL pointer, as is your case). However, I
think I saw a discussion somewhere in wine-devel that advised *not* to
return from inside an __EXCEPT clause of an exception handler in Wine
(most probably because __ENDTRY needs to run in order to clean up). If
this is true, then RtlImageNtHeader is violating this rule. Your
segmentation fault might be the expected result of a violation of the
return rule. Could anybody in wine-devel speak up to confirm or refute
this observation about exception handlers?
This, of course, does not address the actual issue of passing a NULL
pointer to RtlImageNtHeader(). I could make a set of patches to add
TRACEs to all functions with uses of RtlImageNtHeader(), but you need to
be able to apply the patches for them to be actually of use.
Alex Villacís Lasso
Re: wine 0.9.5 - segmentation fault with some apps
[EMAIL PROTECTED] wrote: Hi all, I have already posted this message at the wine-users list (sorry for the cross posting but I think this subject is related to devel people instead of users). I am trying to install ARS V4.5.1, from Remedy, using wine-0.9.5 for Mandriva (RPM built by Ivan). My Mandriva is 2006. If I try to run the installer (called user.exe) wine segfaults immediately. So I run WINEDEBUG=+all wine user.exe just to get more information. Follows the end of the output just before the segfault: -- 8 -- 0009:trace:virtual:VIRTUAL_SetProt 0x7fbf5000-0x7fbf5fff c-rWx 0009:trace:virtual:VIRTUAL_DumpView View: 0x7fb2 - 0x7fc3 (system) 0009:trace:virtual:VIRTUAL_DumpView 0x7fb2 - 0x7fc3 c-rWx 0009:trace:module:load_builtin_callback loaded user32.dll 0x7fd84868 0x7fb2 0009: load_dll( handle=(nil), base=0x7fb2, size=1179648, dbg_offset=0, dbg_size=0, name=0x7fd84890, filename=Lc:\\windows\\system32\\user32.dll ) 0009: load_dll() = 0 0009:trace:heap:RtlAllocateHeap (0x7fd8,000a,15f0): returning 0x7fd865a0 0009:Call ntdll.RtlAllocateHeap(7fd8,,001a) ret=7fce4f5f 0009:trace:heap:RtlAllocateHeap (0x7fd8,0002,001a): returning 0x7fd84908 0009:Ret ntdll.RtlAllocateHeap() retval=7fd84908 ret=7fce4f5f 0009:trace:nls:WideCharToMultiByte cp 0 Luser.exe - (null) 0009:Call ntdll.RtlAllocateHeap(7fd8,,0011) ret=7fce4fb4 0009:trace:heap:RtlAllocateHeap (0x7fd8,0002,0011): returning 0x7fd84930 0009:Ret ntdll.RtlAllocateHeap() retval=7fd84930 ret=7fce4fb4 0009:trace:nls:WideCharToMultiByte cp 0 Luser.exe - user.exe 0009:Call ntdll.RtlAllocateHeap(7fd8,,0012) ret=7fce526d 0009:trace:heap:RtlAllocateHeap (0x7fd8,0002,0012): returning 0x7fd84a08 0009:Ret ntdll.RtlAllocateHeap() retval=7fd84a08 ret=7fce526d 0009:Call ntdll.RtlImageNtHeader() ret=7fce61da 0009: *killed* exit_code=0 Segmentation Fault - 8 - I have ARS Remedy versions V3.0, V4.5.1, V5.1 and V5.1.2. The segfault problem happens with V4.5.1 and V5.1. Version 5.1.2 installs but has a different problem (it complains about permission even if I am the owner of the files and directories 8-P. I have checked and the owner has all permissions). Version 3.0 is too old and also complains (I do not remember right now what is the complaint). Please CC me because I am only subscribed at wine-users. Any clue/sugestions? More information? Thanks. - Ulisses de Sousa Penna Analista Consultor - Banco do Brasil Fone: +55-61-3310-6320 Fax: +55-61-3310-6435 - Wine 0.9.6 just came out, could you please try that instead? Where can somebody download the application? Is there a bug report for this application (bugs.winehq.org)? Just in case, are you installing on a VFAT partition, or on a ext2/ext3 partition? Have you tried running the installer under winedbg (winedbg user.exe, then type cont at the debug prompt to pass control to the application)? Your stack trace is missing the callback on where inside wine the fault occurred. Alex Villacís Lasso
Re: MSACM: return failure rather than assert with nAvgBytesPerSec == 0
Alex Villacís Lasso wrote:
This check is necessary until local codec loading is in CVS. Failure
scenario fixed is: app instructs to load local ACM codec, fails,
doesn't notice failure, requests codec info, fails, again doesn't
notice failure, submits zeroed structure to PCM converter --
assertion failed.
Changelog:
* Check for nAvgBytesPerSec == 0 in PCM converter instead of allowing
assertion to fail.
Alex Villacís Lasso
--- wine-0.9.5-cvs/dlls/msacm/pcmconverter.c2005-11-28 15:57:25.0
-0500
+++ wine-0.9.5-cvs-patch/dlls/msacm/pcmconverter.c 2006-01-09
21:17:07.0 -0500
@@ -945,12 +945,20 @@
switch (adss-fdwSize) {
case ACM_STREAMSIZEF_DESTINATION:
/* cbDstLength = cbSrcLength */
+ if (!adsi-pwfxDst-nAvgBytesPerSec) {
+ ERR(adsi-pwfxDst-nAvgBytesPerSec == %lu\n,
adsi-pwfxDst-nAvgBytesPerSec);
+ return MMSYSERR_INVALPARAM;
+ }
adss-cbSrcLength = PCM_round(adss-cbDstLength dstMask,
adsi-pwfxSrc-nAvgBytesPerSec,
adsi-pwfxDst-nAvgBytesPerSec) srcMask;
break;
case ACM_STREAMSIZEF_SOURCE:
/* cbSrcLength = cbDstLength */
+ if (!adsi-pwfxSrc-nAvgBytesPerSec) {
+ ERR(adsi-pwfxSrc-nAvgBytesPerSec == %lu\n,
adsi-pwfxSrc-nAvgBytesPerSec);
+ return MMSYSERR_INVALPARAM;
+ }
adss-cbDstLength = PCM_round(adss-cbSrcLength srcMask,
adsi-pwfxDst-nAvgBytesPerSec,
adsi-pwfxSrc-nAvgBytesPerSec)
dstMask;
Any comment on this patch?
Alex Villacís Lasso
Re: MSACM: implement acmDriverPriority with driver priority/enabled saving
Alex Villacís Lasso wrote: This patch implements acmDriverPriority(), including saving the priority order and the enabled/disabled status of each global driver to HKCU\\Software\\Microsoft\\Multimedia\\Audio Compression Manager\\Priority v4.00 . Also included the foundation for broadcast notifications on driver priority reorder, including a counter instead of a BOOL flag for deferred notifications (as requested by Eric Pouech). Changelog: * Implementation of acmDriverPriority() with registry saving * Foundation for notification broadcasts with support for deferred notification. Alex Villacís Lasso Any comments on this patch? Alex Villacís Lasso
RFC: implementation of driver functionality in msacm (RESEND)
(resent because previous attempt never appeared in wine-devel) This patch is the preliminary result of some work I have been doing in order to add missing functionality to builtin msacm32.dll. I am submitting this to wine-devel rather than wine-patches, and in one big patch rather than several because I would like comments on some choices I made while adding features. The following is the list of features added by the patch: * Implementation of acmDriverAddW(), and delegation of acmDriverAddA() to acmDriverAddW() * Working implementation of modes of operation of acmDriverAdd[AW]: add driver by new registry entry (ACM_DRIVERADDF_NAME), add (local) driver by combination of hModule/acmDriverProc (ACM_DRIVERADDF_FUNCTION), add notification window for event broadcasts (ACM_DRIVERADDF_NOTIFYHWND) * Implementation of broadcasts to notification windows on driver add/remove, enabling/disabling, and priority changes * Fix for implementation quirks of acmDriverMessage() in order to allow native codecs to display configuration dialogs * Working implementation of acmDriverPriority(), with support of delayed notification broadcasts (for one process only). Includes saving new priorities and enabled status to registry * Loading of codec priorities and enabled status from registry * Support for ACM_METRIC_DRIVER_SUPPORT in acmMetrics() I must note that in order to provide support for acmDriverAddW() in ACM_DRIVERADDF_FUNCTION mode, it is necessary to treat an application-supplied module with an application-supplied driverProc as a full-blown winmm driver. Therefore, the patch includes a new procedure in winmm called wineAddDriver(), that instructs winmm to build a hDrvr from a supplied hModule/driverProc pair, rather than loading both from a DLL, as OpenDriver() does. This allows the rest of the code to continue using SendDriverMessage() as usual. Alex Villacís Lasso wine-msacm-acmDriver.patch.gz Description: GNU Zip compressed data
Re: RFC: implementation of driver functionality in msacm (RESEND)
Eric Pouech wrote: * Implementation of broadcasts to notification windows on driver add/remove, enabling/disabling, and priority changes - MSDN seems to state that differed notification is actually a counter, not a simple boolean (whereas enable/disable is a boolean) I have just read the MSDN web page, and I see no remark that suggests that deferred notification should behave as a counter instead of a simple on/off flag. Or maybe I am reading the page incorrectly... * Fix for implementation quirks of acmDriverMessage() in order to allow native codecs to display configuration dialogs this seems rather hackish. did you actually tested this on Windows ? Moreover, the size bits look especially suspicious. Where did you get the 16 value from ? I tested the native msacm32.dll from Windows 98 SE on Wine, and it reported a 16-byte struct size to the winemp3 codec. Since the goal was to allow native codecs no reason at all for not displaying the configuration dialog, I decided to use that size, even when the structure size in Wine is only 12 bytes. * Working implementation of acmDriverPriority(), with support of delayed notification broadcasts (for one process only). Includes saving new priorities and enabled status to registry * Loading of codec priorities and enabled status from registry * Support for ACM_METRIC_DRIVER_SUPPORT in acmMetrics() I must note that in order to provide support for acmDriverAddW() in ACM_DRIVERADDF_FUNCTION mode, it is necessary to treat an application-supplied module with an application-supplied driverProc as a full-blown winmm driver. Therefore, the patch includes a new procedure in winmm called wineAddDriver(), that instructs winmm to build a hDrvr from a supplied hModule/driverProc pair, rather than loading both from a DLL, as OpenDriver() does. This allows the rest of the code to continue using SendDriverMessage() as usual. this shouldn't be done that way, but rather by reimplementing senddrivermessage in msacm32 That was the very thing I didn't want to do. So, while we are at it, should it be reimplemented for all codecs, or just the ones supplied by the application? Native msacm32 seems to relay to winmm for registered codecs, since I can see calls to SendDriverMessage(). Alex Villacís Lasso
Re: RFC: implementation of driver functionality in msacm (RESEND)
Eric Pouech wrote:
Alex Villacís Lasso wrote:
Eric Pouech wrote:
* Implementation of broadcasts to notification windows on driver
add/remove, enabling/disabling, and priority changes
- MSDN seems to state that differed notification is actually a
counter, not a simple boolean (whereas enable/disable is a boolean)
I have just read the MSDN web page, and I see no remark that suggests
that deferred notification should behave as a counter instead of a
simple on/off flag. Or maybe I am reading the page incorrectly...
well...
ACM_DRIVERPRIORITYF_END Calling task wants to reenable change
notification broadcasts. An application must call acmDriverPriority
with ACM_DRIVERPRIORITYF_END for each successful call with the
ACM_DRIVERPRIORITYF_BEGIN flag. Note that hadid must be NULL,
dwPriority must be zero, and only the ACM_DRIVERPRIORITYF_END flag can
be set.
... then I need new glasses :-)
* Fix for implementation quirks of acmDriverMessage() in order to
allow native codecs to display configuration dialogs
this seems rather hackish. did you actually tested this on Windows ?
Moreover, the size bits look especially suspicious. Where did you
get the 16 value from ?
I tested the native msacm32.dll from Windows 98 SE on Wine, and it
reported a 16-byte struct size to the winemp3 codec.
how do you know it's a 16 byte struct? there's nothing in the passed
information that tells you it's 16 bytes AFAICS
Yes, there is:
(begin MSDN quote)
DRV_CONFIGURE
Directs the installable driver to display its configuration dialog box
and let the user specify new settings for the given installable driver
instance.
*Parameters*
/dwDriverId/
Identifier of the installable driver. This is the same value previously
returned by the driver from the *DRV_OPEN*
http://msdn.microsoft.com/library/en-us/multimed/htm/_win32_drv_open.asp
message.
/hdrvr/
Handle of the installable driver instance.
/lParam1/
Handle of the parent window. This window is used as the parent window
for the configuration dialog box.
/lParam2/
Address of a *DRVCONFIGINFO*
http://msdn.microsoft.com/library/en-us/multimed/htm/_win32_drvconfiginfo_str.asp
structure or NULL. If the structure is given, it contains the names of
the registry key and value associated with the driver.
DRVCONFIGINFO
Contains the registry key and value names associated with the
installable driver.
|typedef struct tagDRVCONFIGINFO {
DWORD dwDCISize;
LPCWSTR lpszDCISectionName;
LPCWSTR lpszDCIAliasName;
} DRVCONFIGINFO;
|
*Members*
*dwDCISize*
Size of the structure, in bytes.
*lpszDCISectionName*
Address of a null-terminated, wide-character string specifying the name
of the registry key associated with the driver.
*lpszDCIAliasName*
Address of a null-terminated, wide-character string specifying the name
of the registry value associated with the driver.
(end MSDN quote)
I examined the DRVCONFIGINFO structure prepared by native msacm32.dll to
codecs, in particular the dwDCISize field. Even when the sum of all
fields in the structure declaration yields 12 bytes, dwDCISize holds a
value of 16 when supplied by native msacm32.dll. So, I used the same
value in order to mimic native as close as possible.
Alex Villacís Lasso
RFC: implementation of driver functionality in msacm
This patch is the preliminary result of some work I have been doing in
order to add missing functionality to builtin msacm32.dll. I am
submitting this to wine-devel rather than wine-patches, and in one big
patch rather than several because I would like comments on some choices
I made while adding features. The following is the list of features
added by the patch:
* Implementation of acmDriverAddW(), and delegation of acmDriverAddA()
to acmDriverAddW()
* Working implementation of modes of operation of acmDriverAdd[AW]: add
driver by new registry entry (ACM_DRIVERADDF_NAME), add (local) driver
by combination of hModule/acmDriverProc (ACM_DRIVERADDF_FUNCTION), add
notification window for event broadcasts (ACM_DRIVERADDF_NOTIFYHWND)
* Implementation of broadcasts to notification windows on driver
add/remove, enabling/disabling, and priority changes
* Fix for implementation quirks of acmDriverMessage() in order to allow
native codecs to display configuration dialogs
* Working implementation of acmDriverPriority(), with support of delayed
notification broadcasts (for one process only). Includes saving new
priorities and enabled status to registry
* Loading of codec priorities and enabled status from registry
* Support for ACM_METRIC_DRIVER_SUPPORT in acmMetrics()
I must note that in order to provide support for acmDriverAddW() in
ACM_DRIVERADDF_FUNCTION mode, it is necessary to treat an
application-supplied module with an application-supplied driverProc as a
full-blown winmm driver. Therefore, the patch includes a new procedure
in winmm called wineAddDriver(), that instructs winmm to build a hDrvr
from a supplied hModule/driverProc pair, rather than loading both from a
DLL, as OpenDriver() does. This allows the rest of the code to continue
using SendDriverMessage() as usual.
Alex Villacís Lasso
diff -ur wine-0.9.5-cvs/dlls/msacm/driver.c wine-0.9.5-cvs-patch/dlls/msacm/driver.c
--- wine-0.9.5-cvs/dlls/msacm/driver.c 2005-12-20 10:17:52.0 -0500
+++ wine-0.9.5-cvs-patch/dlls/msacm/driver.c 2006-01-09 21:59:49.0 -0500
@@ -40,6 +40,7 @@
#include msacmdrv.h
#include wineacm.h
#include wine/debug.h
+#include wine/unicode.h
WINE_DEFAULT_DEBUG_CHANNEL(msacm);
@@ -49,6 +50,10 @@
MMRESULT WINAPI acmDriverAddA(PHACMDRIVERID phadid, HINSTANCE hinstModule,
LPARAM lParam, DWORD dwPriority, DWORD fdwAdd)
{
+MMRESULT resultW;
+WCHAR * driverW = NULL;
+LPARAM lParamW = lParam;
+
TRACE((%p, %p, %08lx, %08lx, %08lx)\n,
phadid, hinstModule, lParam, dwPriority, fdwAdd);
@@ -72,30 +77,100 @@
return MMSYSERR_INVALFLAG;
}
-/* FIXME: in fact, should GetModuleFileName(hinstModule) and do a
- * LoadDriver on it, to be sure we can call SendDriverMessage on the
- * hDrvr handle.
- */
-*phadid = (HACMDRIVERID) MSACM_RegisterDriver(NULL, NULL, hinstModule);
-
-/* FIXME: lParam, dwPriority and fdwAdd ignored */
+/* A-W translation of name */
+if ((fdwAdd ACM_DRIVERADDF_TYPEMASK) == ACM_DRIVERADDF_NAME) {
+unsigned long len = strlen((LPSTR)lParam) + 1;
+driverW = HeapAlloc(MSACM_hHeap, 0, len * sizeof(WCHAR));
+if (!driverW) return MMSYSERR_NOMEM;
+MultiByteToWideChar(CP_ACP, 0, (LPSTR)lParam, -1, driverW, len);
+lParamW = (LPARAM)driverW;
+}
-return MMSYSERR_NOERROR;
-}
+resultW = acmDriverAddW(phadid, hinstModule, lParamW, dwPriority, fdwAdd);
+if ((WCHAR *)lParamW != NULL) HeapFree(MSACM_hHeap, 0, driverW);
+return resultW;
+}
/***
* acmDriverAddW (MSACM32.@)
- * FIXME
- * Not implemented
+ *
*/
MMRESULT WINAPI acmDriverAddW(PHACMDRIVERID phadid, HINSTANCE hinstModule,
LPARAM lParam, DWORD dwPriority, DWORD fdwAdd)
{
-FIXME((%p, %p, %ld, %ld, %ld): stub\n,
- phadid, hinstModule, lParam, dwPriority, fdwAdd);
+TRACE((%p, %p, %08lx, %08lx, %08lx)\n,
+ phadid, hinstModule, lParam, dwPriority, fdwAdd);
+
+if (!phadid) {
+WARN(invalid parameter\n);
+ return MMSYSERR_INVALPARAM;
+}
+
+/* Check if any unknown flags */
+if (fdwAdd
+ ~(ACM_DRIVERADDF_FUNCTION|ACM_DRIVERADDF_NOTIFYHWND|
+ ACM_DRIVERADDF_GLOBAL)) {
+WARN(invalid flag\n);
+ return MMSYSERR_INVALFLAG;
+}
-SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
-return MMSYSERR_ERROR;
+/* Check if any incompatible flags */
+if ((fdwAdd ACM_DRIVERADDF_FUNCTION)
+ (fdwAdd ACM_DRIVERADDF_NOTIFYHWND)) {
+WARN(invalid flag\n);
+ return MMSYSERR_INVALFLAG;
+}
+
+switch (fdwAdd ACM_DRIVERADDF_TYPEMASK) {
+case ACM_DRIVERADDF_NAME:
+/*
+hInstModule (unused)
+lParam name of value in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32
+dwPriority (unused, set to 0)
+ */
+*phadid = (HACMDRIVERID)
Re: run jboss with a mde file as source
Curro Amores wrote: hi: i want to run jboss in linux and connect to an Ms Access odbc source. Hmm... I would think twice before trying to run a J2EE application that reads data from an MS Access database, regardless of operating system. Have you considered how well Access scales for many users? How about locking between different simultaneous users? In addition, JBoss runs on Java, and Java is supposed to be cross-platform. You might want to take the extra step of porting your database to another DBMS, such as MySQL, PostgreSQL, or even Oracle (if you have the $$$). If your DBMS must be all-Microsoft, you can still prepare a SQL-Server and connect to it from Linux with FreeTDS (http://www.freetds.org/) and ODBC. I think it doesnt exist odbc driver for Access in Linux. I Have read something about ODBC-ODBC but i think it is for accessing a mde file in a windows machine from linux. In a limited sense, there is a way: MDB Tools (http://mdbtools.sourceforge.net/). However, SQL/ODBC support is read-only, last time I checked, and in addition, the emphasis is on getting data out of MDBs in order to put it in another DBMS, not to use MDBs in a daily basis. I have created the bridge with ODBC in wine (using the control pane with winetools) Then i have tried to run jboss windows version (run.bat) with wcmd but i got a message that run.jar file cant not be found. That is because it is looking for a java.exe, the Windows version of java. Do i have to install java windows version with wine? yes I have tried as well but the installation crashes Any idea? If, after what I said about thinking it twice, you *still* need to make a Windows version of Java run a J2EE with MS-Access inside Wine, then you might need to 1) install MDAC manually, not via winetools, and 2) file a bug report with a crash log when installing the Windows version of Java in Wine. thanks Alex Villacís Lasso
What is the proper value for ACM_DRIVERADDF_NAME?
I am working on a set of patches for msacm, and I want to add support for ACM_DRIVERADDF_NAME. The problem is that Wine does not have a definition for this value, which is supposed to be used in acmDriverAdd[AW]. It does not appear in any header of MSVC either. I searched MSDN and Google, and it does not appear either. MSDN mentions its use, but does not mention its specific value. Has anybody seen the value for this definition, and if so, can you please forward it to me? Thanks in advance. BTW, what happened to the two MSACM patches sent in December 28? Alex Villacís Lasso
Re: What is the proper value for ACM_DRIVERADDF_NAME?
Dmitry Timoshkov wrote: Alex Villacís Lasso [EMAIL PROTECTED] wrote: I am working on a set of patches for msacm, and I want to add support for ACM_DRIVERADDF_NAME. The problem is that Wine does not have a definition for this value, which is supposed to be used in acmDriverAdd[AW]. It does not appear in any header of MSVC either. I searched MSDN and Google, and it does not appear either. MSDN mentions its use, but does not mention its specific value. Has anybody seen the value for this definition, and if so, can you please forward it to me? Platform SDK defines ACM_DRIVERADDF_* flags as the following: #define ACM_DRIVERADDF_NAME 0x0001 #define ACM_DRIVERADDF_FUNCTION 0x0003 #define ACM_DRIVERADDF_NOTIFYHWND 0x0004 #define ACM_DRIVERADDF_TYPEMASK 0x0007 #define ACM_DRIVERADDF_LOCAL0x #define ACM_DRIVERADDF_GLOBAL 0x0008 I must therefore conclude that my MSVC installation is years and years out of date... thanks! Alex Villacís Lasso
Re: MSACM: initialize some ACMSTREAMHEADER fields for the sake of native codecs
Eric Pouech wrote: Alex Villacís Lasso wrote: The ACMAPP sample application from MSDN reveals this annoying bug in playback: with a native ACM codec (such as the Ogg Vorbis one bundled with some Japanese RPGs), builtin msacm will successfully tell the codec to decode the first two frames of compressed audio, and then the sound will loop on these two frames. What is really happening is that winmm is using double-buffering, and reusing the ACMSTREAMHEADER structures for playback, and acmStreamConvert simply passes the structures into the codec, without clearing cb[Src|Dst]LengthUsed (here is the bug) which was set in the previous call to acmStreamConvert on that ACMSTREAMHEADER. The native codec *expects* these fields to be set to 0, and refuses to decode otherwise. well, you should check who is supposed to clear those flags between msacm or winmm (I suppose wavemap). A+ Native msacm (WINEDLLOVERRIDES=msacm32=n) works correctly (no loops) with native codecs in wine. This suggests that msacm is doing the clearing, since it is using the same builtin winmm. Alex Villacís Lasso
