Re: Kernel 2.6.9
Paul Rupe wrote: > On Friday November 12 2004 11:48 am, Michael Stefaniuc wrote: > > >>Btw. does wine crash only with Remedy or does winemine crash too? > > > Most apps (winemine included) are ok. When I get home I'll try to find a > downloadable app that reproduces the problem consistently. > > Usually wine just hangs until I kill -9 everything, but this time I managed > to get a stack trace. It looks like a recursive loop: > =>1 0x7759b155 cxx_frame_handler+0x401 in msvcrt (0x77927f90) > 2 0x7759b5c3 in msvcrt (+0xb5c3) (0x77927fb4) > 3 0x77ee7be1 __wine_call_from_32_regs+0xb5 in ntdll (0x7792831c) > 4 0x7759ac79 __CxxFrameHandler+0x5 in msvcrt (0x77928358) > 5 0x77ec63b8 EXC_RtlRaiseException+0x18c in ntdll (0x779283ec) > 6 0x77edf32b raise_segv_exception+0x2f in ntdll (0x77928408) > 7 0x77ee7c50 __wine_call_from_32_restore_regs+0x0 in ntdll (0x779287d4) > ... > 90 0x77edf32b raise_segv_exception+0x2f in ntdll (0x7792f7d8) > Frames 2-7 repeat all the way down to 90. This is after a 'make clean' and > a full rebuild of Wine, btw. > > Does increasing stack size help? For example: Index: dlls/kernel/process.c === RCS file: /var/cvs/wine/dlls/kernel/process.c,v retrieving revision 1.80 diff -u -r1.80 process.c --- dlls/kernel/process.c 30 Oct 2004 02:11:33 - 1.80 +++ dlls/kernel/process.c 15 Nov 2004 11:36:47 - @@ -1183,7 +1183,7 @@ set_library_wargv( __wine_main_argv ); if (!build_command_line( __wine_main_wargv )) goto error; -stack_size = RtlImageNtHeader(peb->ImageBaseAddress)->OptionalHeader.SizeOfStackReserve; +stack_size = 10 * 1024 * 1024; /* allocate main thread stack */ if (!THREAD_InitStack( NtCurrentTeb(), stack_size )) goto error; __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
GetMenuItemInfo by ID differs from the native
GetMenuItemInfo by ID returns the data of a command item if the item belongs to a submenu that has the same ID as the item on windows. Our function will return the information of a submenu in such case. My patch will fix it.
There is also another problem. The value of a menu handle is so little (about 0x80 - according to what I saw) that it’s very possible that a submenu has the same ID as a command item for a submenu’s ID equals to the handle of its submenu by default. Applications like Adobe Audition that use GetMenuItemInfo to retrieve the information of a command item will run into trouble. The conflict seldom or never happens on Windows, because the value there often exceeds 0x. I wonder that if we can solve it by XORing a constant value to the handle.
ChangeLog
controls/menu.c, dlls/user/tests/Makefile.in, dlls/user/tests/menu.c
- Make GetMenuItemInfo by ID return the data of a command item if the item and
the submenu that the item belongs to have the same ID.
- Add a test for menus.
Index: controls/menu.c
===
RCS file: /home/wine/wine/controls/menu.c,v
retrieving revision 1.168
diff -u -r1.168 menu.c
--- controls/menu.c 17 Sep 2003 04:28:29 - 1.168
+++ controls/menu.c 8 Nov 2003 05:53:16 -
@@ -565,12 +565,13 @@
MENUITEM *item = menu->items;
for (i = 0; i < menu->nItems; i++, item++)
{
- if (item->wID == *nPos)
- {
- *nPos = i;
- return item;
+ if (item->wID == *nPos && (item->fType & MF_POPUP) != MF_POPUP)
+ {/* If we find a command item, return it */
+ *nPos = i;
+ return item;
}
- else if (item->fType & MF_POPUP)
+ /* else search the submenu */
+ if (item->fType & MF_POPUP)
{
HMENU hsubmenu = item->hSubMenu;
MENUITEM *subitem = MENU_FindItem( &hsubmenu, nPos, wFlags );
@@ -578,6 +579,11 @@
{
*hmenu = hsubmenu;
return subitem;
+ }
+ if (item->wID == *nPos)
+ {
+ *nPos = i;
+ return item;
}
}
}
Index: dlls/user/tests/Makefile.in
===
RCS file: /home/wine/wine/dlls/user/tests/Makefile.in,v
retrieving revision 1.6
diff -u -r1.6 Makefile.in
--- dlls/user/tests/Makefile.in 28 Oct 2003 00:18:40 - 1.6
+++ dlls/user/tests/Makefile.in 8 Nov 2003 05:53:54 -
@@ -10,6 +10,7 @@
generated.c \
input.c \
listbox.c \
+ menu.c \
msg.c \
sysparams.c \
win.c \
--- /dev/null 2002-08-31 07:31:37.0 +0800
+++ dlls/user/tests/menu.c 2003-11-08 13:17:31.0 +0800
@@ -0,0 +1,422 @@
+/*
+ * Copyright (C) the Wine project
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+
+#include "wine/test.h"
+#include "windef.h"
+#include "winbase.h"
+#include "winuser.h"
+#include "winnls.h"
+
+
+#ifndef array_count
+#define array_count(array) (sizeof(array) / sizeof((array)[0]))
+#endif
+#define MAX_MENU_ITEM_NAME 16
+
+typedef struct MY_MENUITEMTEMPLATE {
+WORD mtOption;
+WORD mtID;
+char mtString[MAX_MENU_ITEM_NAME];
+}MY_MENUITEMTEMPLATE;
+
+const static MY_MENUITEMTEMPLATE theLMI[] = {/* for LoadMenuIndirect */
+{MF_POPUP, 0, "Popup"},
+{MF_END,40001, "Submenu Item"},
+{MF_POPUP | MF_END, 0, "Popup2"},
+{MF_END,40002, "End"}
+};
+
+typedef struct GMBIT_DATA {/* for GetMenuInfo by ID test */
+const MY_MENUITEMTEMPLATE *pItems;/* menu to test */
+int nCount; /* count of menuitems */
+
+DWORD dwItemID; /* which item to get */
+BOOLfSubMenu; /* expect a submenu or command item */
+charszExpected[MAX_MENU_ITEM_NAME]; /* item's name returned by GetMenuInfo */
+}GMBIT_DATA;
+
+/* For testing GetMenuItemInfo by ID */
+const static MY_MENUITEMTEMPLATE theGMI0[] = {
+{MF_SEPARATOR, 0, ""},
+{0, 40001, "
Re: UI bugs hampering porting effort for shaped window
Rob wrote: > Jerry's patch *does* fix the UI issues actually - B1 through B4 - any idea > why it isn't applied to the CVS tree? We have the version out of CVS, which > definately has issues with B1-B4. > I know it fixes B1, B2, and partially B4, but I'm not so sure about B3. WINAMP still has issue B4 even with my patch applied. The patch is a little tricky :-). I intended to place a button on the taskbar for a popup window. M$'s document says application windows and popup windows which not owned will be displayed on the taskbar - When I open the web page today, I found it says a button is placed on the taskbar for a windows that isn't owned without mentioning that it has WS_POPUP style, seems my mistake. As I happened to know that a managed window on WINE is displayed on the taskbar and noticed that WINDOWS wouldn't change a popup window's style to have it displayed on the taskbar, I changed these windows' managed state. But I am not sure that it is the right way to get things work.
Re: UI bugs hampering porting effort for shaped window
Rob wrote: The show stopper bugs are B1, B2, B3, B4 and B5. Issue B5, and B7 can be worked around, so they aren't as critical. B1, B2, B3, and B4 can be fixed by putting a title bar on the application. (See MAKE_IT_LOOK_LIKE_A_NORMAL_APP_AT_STARTUP in winetest.cpp.) - B1. Focus does not appear to be on the application at start-up. We do not receive keyboard messages, though we do receive many other messages, such as mouse-clicks. Clicking on the square labelled "focus:" fixes the problem, by bringing up a message box -- when the message box is dismissed, the application has focus. This appears to be the same problem as that discussed here: http://bugs.winehq.org/show_bug.cgi?id=292 - B2. No task bar item. Patch at http://www.winehq.org/hypermail/wine-patches/2003/09/0268.html can fix these problems.
Re: spec files - syntax and generation
Martin Tröster wrote: How do I find out whether a function uses CDECL instead of STDCALL? I found the information (link lost unfortunately) that entries in the def file like [EMAIL PROTECTED] are called via STDCALL, whereas in case of testfunc2 without any @ specifying the space is CDECL. Is this guess right? If not, how else do I find this out? The most safe one I have known is to disassemble it and look over the output. If the function have no parameters, you can declare it as either CDECL or STDCALL. Suppose it have some parameters and its type is CDECL, you can find: 1. "lret" in the function 2. it will be called in a way like pushl something1 pushl something2 call address of [EMAIL PROTECTED] addl $8, %%esp and for a STDCALL, there are: 1. something that is similar to "lret $8" in the function 2. it will be called in a way like pushl something1 pushl something2 call address of [EMAIL PROTECTED] Thanks again for any help! Cheers, Martin
Re: DMUSIC: fix in dmloader's behavior
Rok Mandeljc wrote: + /* OK, MSDN says that search order is the following: + - current directory (DONE) + - windows search path (FIXME: how do I get that?) Try this : DWORD GetEnvironmentVariable( LPCTSTR lpName, // environment variable name LPTSTR lpBuffer, // buffer for variable value DWORD nSize // size of buffer ); or NTSTATUS WINAPI RtlQueryEnvironmentVariable_U( PWSTR env, PUNICODE_STRING name, PUNICODE_STRING value ); + - loader's search path (DONE) + */
Re: Winealsa: now fixed, interactive tests still ko.
Sylvain Petreolle wrote: > Applying this patch fixes alsa : > [repaired] dlls/winmm/winealsa/audio.c > thanks to Daniel (Tom?) and Jerry. > > Now "Common" tests are ok. > But some interactive tests still fail with winealsa. Duplicating the IDsDriverBufferImpl_SetVolumePan function from WINEOSS to WINEALSA will make it work, for there is nothing related to sound driver. And I wonder if someone has already been trying to implement IDirectSoundImpl_SetCooperativeLevel. > I attached the log. (+wave,+dsound,+dosund3d can be provided if necessary) > > = > Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) > ICQ #170597259 > Say NO to software patents > Dites NON aux brevets logiciels > > "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". > > ___ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.mail.yahoo.com
Re: [janitor] dlls/winmm/wine* -Wwrite-strings cleanup
Dimitrie O. Paun wrote:
Why do we need the static?
Had I pasted more source code, you would have known why.
LONG ALSA_WaveInit(void)
{
snd_pcm_t* h = NULL;
snd_pcm_info_t *info;
snd_pcm_hw_params_t * hw_params;
WINE_WAVEOUT* wwo;
chardevice[] = "hw";
wwo = &WOutDev[0];
/* FIXME: use better values */
wwo->device = device;
We have to keep the memory used by device[] or wwo->device even when we
exit the function, because we'll access it later. Local variables’
memory are supposed to be freed after the function exits.
Re: [janitor] dlls/winmm/wine* -Wwrite-strings cleanup
Dimitrie O. Paun wrote: On October 11, 2003 03:42 am, Jerry Jenkins wrote: > +chardevice[] = "hw"; I think it should be static char device[] = "hw"; Why is that? In fact, I think it shouldn't, if it gets modified during the call, we'll end up passing garbage values on subsequent calls... Actually device[] will and shall not be modified at least up to now. It is introduced by the patch, though I though that we can get rid of the warning by changing the type of device member in structure WINE_WAVEOUT from char * to const char *. If we keep device[], we need the static keyword to make winealsa work.
Re: [janitor] dlls/winmm/wine* -Wwrite-strings cleanup
> Index: dlls/winmm/winealsa/audio.c > === > RCS file: /home/wine/wine/dlls/winmm/winealsa/audio.c,v > retrieving revision 1.20 > diff -u -r1.20 audio.c > --- dlls/winmm/winealsa/audio.c22 Sep 2003 21:13:33 - 1.20 > +++ dlls/winmm/winealsa/audio.c7 Oct 2003 19:52:14 - > @@ -408,11 +408,12 @@ > snd_pcm_info_t *info; > snd_pcm_hw_params_t * hw_params; > WINE_WAVEOUT* wwo; > +char device[] = "hw"; I think it should be static char device[] = "hw"; > > wwo = &WOutDev[0]; > > /* FIXME: use better values */ > -wwo->device = "hw"; > +wwo->device = device; > wwo->caps.wMid = 0x0002; > wwo->caps.wPid = 0x0104; > strcpy(wwo->caps.szPname, "SB16 Wave Out");
Re: All dsound tests fail with winealsa
Sylvain Petreolle wrote:
These logs doesnt show anything brilliant/remarkable to me.
Could this be an uninitialised pointer problem ?
The source I looked over are not so up to data as I expected. After an
update, I find something insteresting:
LONG ALSA_WaveInit(void)
{
snd_pcm_t* h = NULL;
snd_pcm_info_t *info;
snd_pcm_hw_params_t * hw_params;
WINE_WAVEOUT* wwo;
char device[] = "hw";
The last variant should be declared as
static char device[]="hw";
=
Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net)
ICQ #170597259
Say NO to software patents
Dites NON aux brevets logiciels
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Re: All dsound tests fail with winealsa
Yes, they work without problem. I can provide logs/screen copy if needed. It's not necessary. I ask you the question just because that I am not quite familiar with the source :-(. The logs you provided show that dsound or winealsa call alsa-lib with an invalid device name. The line is ALSA lib pcm.c:1908:(snd_pcm_open_noupdate) Unknown PCM ºÝ@ þB [EMAIL PROTECTED] while it should be: Unknown PCM hw. Please check the result of --debugmsg +wave or send it to me, maybe we can find a clue. Note: all of them were compiled from sources (driver, lib, oss compat, tools and utils) Do other programs that will call ALSA APIs such as alsamixer and aplay work properly? = Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: All dsound tests fail with winealsa
Do other programs that will call ALSA APIs such as alsamixer and aplay work properly? Sylvain Petreolle wrote: > After an update to current cvs, dsound test with winealsa is failing. > cature.c is ok (1 test only) but propset.c and dsound.c fail. > > They give the same error at almost every test > ALSA lib pcm.c:1908:(snd_pcm_open_noupdate) Unknown PCM > err:wave:wodOpen Error open: Inappropriate ioctl for device > fixme:dsound:mmErr Unknown MMSYS error 3 > dsound.c:701: Test failed: DirectSoundCreate failed: 0x80004005 > dsound.c:1035: Test failed: DirectSound test failed > > Attached: dsound.results & propset.results. > Results of a rerun with --debugmsg +something available if needed. > > Note : > The same tests run ok if the tests are launched with wineoss and OSS emulation. > > = > Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) > ICQ #170597259 > Say NO to software patents > Dites NON aux brevets logiciels > > "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". > > ___ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.mail.yahoo.com
Re: [janatorial] HeapReAlloc
Dimitrie O. Paun wrote:
> On Wed, 8 Oct 2003, Oleg Prokhorov wrote:
>
> > Change-log:
> > fix wine code depended on
>
> That's cool, but we need to somehow manage this. There are almost
> 300 occurences of memory reallocation, and we need to somehow
> keep track of what was reviwed/fixed etc., otherwise we risk
> missing quite a few...
>
> We should start with a comprehensive list of things that
> need fixing...
>
Maybe we can add a new inline function which likes
inline void *HeapReAllocEx(..., lpMemory, ...)
{
if (lpMemory)...
else ...
}
then
#defineHeapReAllocHeapReAllocEx
in a proper header file.
> --
> Dimi.
>
>
>
>
>
Re: alsa, arts, etc
Modify [WinMM] section in your ~/.wine/config. > how can i get alsa, arts, etc for audio instead of oss? i'm using wine > for cooledit96 and the 3 second delay for oss emulation is quite annoying, > but i'm still very happy to be using cooledit96 under linux. > i'm using wine version 20030813. > > thanks, > dave > > >
Re: winealsa: improve sound quality for IDsDriverImpl
Robert Reif wrote: > I just cut the parts out of a bigger patch and I guess I missed something. > The memory clearing part is the 8 bit hardware buffer bug fix. The locking > is to fix the SetFormat bug. > > The problem is that when the hardware primary buffer format changes > which causes a new buffer to be mmapped, the mixer thread continues > to use the old deleted buffer address. The timer callback gets the > resource shared which doesn't prevent the primary buffer from changing > it's address even with the new locking I tried to add. It's overkill to > have the timer callback get the resource exclusive every time because > format changes almost never happen and the extra locking is only needed > when they do. > Do you mean that the problem occurs only when we change the format? If this bug will cause continuing interval or click noise which I have encountered, your patch is going to be a big help for me. I am really looking forward to having your patch now :-). But take your time; I'll wait until you finish it.
Re: winealsa: improve sound quality for IDsDriverImpl
> Robert Reif wrote: > > > > Here is the patch that addresses the 8 bit mixer problem. I just > > cut it out of an old development tree that had a lot of other mixer > > changes so I doubt it will apply cleanly but it will give you an idea > > of the problem. > > > > This patch and the tests developed for it uncovered the locking > > issues which I have not fixed yet. I hope to submit a real fix for > > all this someday but I hope this partial fix can be of some use > > until then. > > > Seems there are too few EnterCriticalSections to make things better. Hope > you can complete it soon. > > I guess that adding critical sections can synchronize DSOUND, but the > sound driver - playing thread - remains unchanged, it still goes its own > way:-(. > Sorry, here is the missing text. What will happen if the driver access the data we are going to clean or mix? I wish it would never take place.
Re: winealsa: improve sound quality for IDsDriverImpl
Robert Reif wrote: > > Here is the patch that addresses the 8 bit mixer problem. I just > cut it out of an old development tree that had a lot of other mixer > changes so I doubt it will apply cleanly but it will give you an idea > of the problem. > > This patch and the tests developed for it uncovered the locking > issues which I have not fixed yet. I hope to submit a real fix for > all this someday but I hope this partial fix can be of some use > until then. > Seems there are too few EnterCriticalSections to make things better. Hope you can complete it soon. I guess that adding critical sections can synchronize DSOUND, but the sound driver - playing thread - remains unchanged, it still goes its own way:-(.
Re: winealsa: improve sound quality for IDsDriverImpl
sox -c1 -r44100 -sw /usr/share/sounds/pop.wav -tossdsp /dev/audio && wine winamp has the problem, but sox -c1 -r44100 -sb /usr/share/sounds/pop.wav -tossdsp /dev/audio && wine winamp is unbelievably good. How could it be? I should find out if it's something is wrong with my system or something else. Only one of my sound cards suffers from the problem when the format of primary buffer is 22050 samples per second, 8-bit stereo. The other is OK. It appears to be a big challenge for me. And I am a little curious about how many peoples would have such experience. I submitted a new patch, please test it.
Re: winealsa: improve sound quality for IDsDriverImpl
Dimitrie O. Paun wrote: >The best thing to do is to post it here so we can see what we are >talking about... And yes, we all want only the best code for wine :) The code is already submitted in my patch. After thinking twice, I found that the runtime check can be sped up. Calling snd_async_callback_t twice is enough. Because we could commit the whole buffer for the first time, ALSA driver will know the buffer is full. If the buffer will be reallocated, it is the right time for the driver to perform the action. And the new address will be returned next time we call snd_pcm_mmap_begin. We need not wait for the whole buffer to be played once. And I got some new information about the noticeable interval. Seems it's something about the sound data format was not correctly set, for sox -c1 -r44100 -sw /usr/share/sounds/pop.wav -tossdsp /dev/audio && wine winamp has the problem, but sox -c1 -r44100 -sb /usr/share/sounds/pop.wav -tossdsp /dev/audio && wine winamp is unbelievably good. How could it be? I should find out if it's something is wrong with my system or something else. >-- >Dimi.
Re: winealsa: improve sound quality for IDsDriverImpl
> Well I for one am a bit confused. The reason it needs to be a runtime > check is so we can compile Wine on one machine then run it on a totally > different one, and Wine figures out what it can and cannot do on the > fly. If we are altering its behaviour according to the capabilities of > the compiling machine then this is very bad indeed. > I knew. I also want it can be compiled once and run on any other machines. My point is that only the best code should go into the wine, and the test code I have written is not so… :-(. It will give someone many troubles if he wants to do something about the performance. > > >
Re: winealsa: improve sound quality for IDsDriverImpl
Dimitrie O. Paun wrote: > > That's still a compile-time check. A runtime check runs when wine runs... > But the test is really a time-cost task. I won't merge it into WINEALSA if I can't improve it. Does anyone have any suggestions? > > -- > Dimi. > > > >
Re: winealsa: improve sound quality for IDsDriverImpl
> > If the behavior is subject to change, there is no way you can test > that at configure time. This needs to be a run time check. > You're right. So I put some code in configure.ac, try to compile & run it when configure is executed. If everything is OK, a macro will be defined in config.h.
Re: winealsa: improve sound quality for IDsDriverImpl
> Hi Jerry, > > With your patch applied, > I get a write access to a NULL pointer when trying to get sound with > dsound (winmm tests are running ok.) > > Since I was using precompiled RPMs from freshrpms.net when doing the > first try, > I switched to 0.9.7 sources. Same result. > > I attached a trace from a run of > wine dsound_test.exe.so dsound --debugmsg +wave,+dsound,+dsound3d > > Could you have a look on this ? I'll work on it. I noticed that sometimes there are still noticeable intervals. But if I run some OSS programs first like Play /usr/share/sound/KDE_Startup.wav, DSOUND works very well then. After some more investigation, I found that snd_pcm_mmap_commit copys the data as snd_pcm_areas_copy in the origin callback. My patch only decreases the times that the data are copied. I can't figure out why it works after run OSS programs though. > > = > Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) > ICQ #170597259 > Say NO to software patents > Dites NON aux brevets logiciels > > "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". > > ___ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.mail.yahoo.com > > >
Re: interactive dsound tests fail && winealsa problem
> So, what I'm wondering now is: 1) Should I bother finishing it? OSS is > working fine for me again, and if someone else is going to fix the existing ALSA > driver, and 2) if the answer to question 1 is 'yes', then what is the proper > protocol for submitting such a substantial code change. IMO a separate driver > would be less destabilizing (don't run it if you don't want to!), but a little > confusing (two ALSA drivers?). My patch will depend on alsa driver highly. Just a little change to the alsa APIs will make my patch don't work any more. That's also the reason why I want to do some checks. So I think that people (at least me) would be glad to have another choice ... if you do have some time:-). Maybe there are some more smart opinions.
Re: interactive dsound tests fail && winealsa problem
Sylvain Petreolle wrote: > Using latest CVS : > > Enabling dsound interactive tests with WINETEST_INTERACTIVE, > I get many errors like this one, always the same : > > dsound.c:1223: Test failed: MsgWaitForMultipleObjects failed: 0x102 > dsound.c: 42774 tests executed, 0 marked as todo, 80 failures. > > Im using wineoss with OSS compatibility to do these tests. > Kernel : 2.4.20-20.9 > > Using winealsa, the sound produced during the test is awful, full of > noise. I'm trying to improve winealsa's sound quality, and I have found a way. And I think I should make some checks in configure which I am totally unaware of. If everything go smooth, the patch will be sent out within several days. > I get only failed tests due to E_NOTIMPL errors like > > dsound.c:149: Test failed: Lock: 0x80004001
Re: wine-devel digest, Vol 1 #2212 - 10 msgs
> Thanks Jerry, > > your second patch solved the bug 1715 against Wine-20030911. There are still > lots of errorr messages: > err:x11drv:X11DRV_CreateBitmap Trying to make bitmap with planes=1, bpp=4 Maybe there is the same problem. Could you tell me the name of the application you are trying to run? > > but these seem harmless. > > Jarkko Lavinen >
Re: CreateBitmap fails
> Thanks Jerry, > > your second patch solved the bug 1715 against Wine-20030911. There are still > lots of errorr messages: > err:x11drv:X11DRV_CreateBitmap Trying to make bitmap with planes=1, bpp=4 Maybe there is the same problem. Could you tell me the name of the application you are trying to run? > > but these seem harmless. > > Jarkko Lavinen >
Re: alsa/audioio driver regression patch
> Volume and Pan driver requests need to return success > even though they are not implemented. IMHO, reusing the code in wineoss.diff, which is one of your patchs, would be a better choice. And make it work:-).
Re: CreateBitmap fails
Patch for loading bitmaps.
ChangeLog:
* dlls/comctl32/toolar.c
- Create a compatible bitmap of the display, which can be selected into
a device context.
* windows/cursoricon.c
- Loading bitmaps with specified size works now.
Index: dlls/comctl32/toolbar.c
===
RCS file: /home/wine/wine/dlls/comctl32/toolbar.c,v
retrieving revision 1.139
diff -u -r1.139 toolbar.c
--- dlls/comctl32/toolbar.c 17 Sep 2003 20:15:21 - 1.139
+++ dlls/comctl32/toolbar.c 20 Sep 2003 10:40:03 -
@@ -2215,7 +2215,7 @@
/* create new default image list */
TRACE ("creating default image list!\n");
-himlDef = ImageList_Create (infoPtr->nBitmapWidth,
infoPtr->nBitmapHeight,
+himlDef = ImageList_Create (infoPtr->nBitmapWidth,
infoPtr->nBitmapHeight,
ILC_COLOR | ILC_MASK, nButtons, 2);
TOOLBAR_InsertImageList(&infoPtr->himlDef, &infoPtr->cimlDef, himlDef,
0);
infoPtr->himlInt = himlDef;
@@ -2236,7 +2236,7 @@
{
BITMAP bmp;
HBITMAP hOldBitmapBitmap, hOldBitmapLoad;
- HDC hdcImage, hdcBitmap;
+ HDC hdcImage, hdcBitmap, hdcScreen;
/* copy the bitmap before adding it so that the user's bitmap
* doesn't get modified.
@@ -2245,11 +2245,12 @@
hdcImage = CreateCompatibleDC(0);
hdcBitmap = CreateCompatibleDC(0);
+ hdcScreen = GetDC(NULL);
/* create new bitmap */
- hbmLoad = CreateBitmap (bmp.bmWidth, bmp.bmHeight, bmp.bmPlanes,
bmp.bmBitsPixel, NULL);
- hOldBitmapBitmap = SelectObject(hdcBitmap, (HBITMAP)lpAddBmp->nID);
- hOldBitmapLoad = SelectObject(hdcImage, hbmLoad);
+ hbmLoad = CreateCompatibleBitmap (hdcScreen, bmp.bmWidth,
bmp.bmHeight);
+ hOldBitmapBitmap = SelectObject (hdcBitmap,
(HBITMAP)lpAddBmp->nID);
+ hOldBitmapLoad = SelectObject (hdcImage, hbmLoad);
/* Copy the user's image */
BitBlt (hdcImage, 0, 0, bmp.bmWidth, bmp.bmHeight,
@@ -2259,6 +2260,7 @@
SelectObject (hdcBitmap, hOldBitmapBitmap);
DeleteDC (hdcImage);
DeleteDC (hdcBitmap);
+ ReleaseDC (NULL, hdcScreen);
nIndex = ImageList_AddMasked (himlDef, hbmLoad, CLR_DEFAULT);
DeleteObject (hbmLoad);
@@ -3845,7 +3847,7 @@
{
BITMAP bmp;
HBITMAP hOldBitmapBitmap, hOldBitmapLoad, hbmLoad;
- HDC hdcImage, hdcBitmap;
+ HDC hdcImage, hdcBitmap, hdcScreen;
/* copy the bitmap before adding it so that the user's bitmap
* doesn't get modified.
@@ -3854,11 +3856,12 @@
hdcImage = CreateCompatibleDC(0);
hdcBitmap = CreateCompatibleDC(0);
+ hdcScreen = GetDC(NULL);
/* create new bitmap */
- hbmLoad = CreateBitmap (bmp.bmWidth, bmp.bmHeight, bmp.bmPlanes,
bmp.bmBitsPixel, NULL);
- hOldBitmapBitmap = SelectObject(hdcBitmap, hBitmap);
- hOldBitmapLoad = SelectObject(hdcImage, hbmLoad);
+ hbmLoad = CreateCompatibleBitmap (hdcScreen, bmp.bmWidth,
bmp.bmHeight);
+ hOldBitmapBitmap = SelectObject (hdcBitmap, hBitmap);
+ hOldBitmapLoad = SelectObject (hdcImage, hbmLoad);
/* Copy the user's image */
BitBlt (hdcImage, 0, 0, bmp.bmWidth, bmp.bmHeight,
@@ -3868,6 +3871,7 @@
SelectObject (hdcBitmap, hOldBitmapBitmap);
DeleteDC (hdcImage);
DeleteDC (hdcBitmap);
+ ReleaseDC (NULL, hdcScreen);
ImageList_AddMasked (himlDef, hbmLoad, CLR_DEFAULT);
DeleteObject (hbmLoad);
Index: windows/cursoricon.c
===
RCS file: /home/wine/wine/windows/cursoricon.c,v
retrieving revision 1.68
diff -u -r1.68 cursoricon.c
--- windows/cursoricon.c 10 Sep 2003 03:56:47 - 1.68
+++ windows/cursoricon.c 20 Sep 2003 10:40:32 -
@@ -1925,7 +1925,8 @@
/**
* BITMAP_Load
*/
-static HBITMAP BITMAP_Load( HINSTANCE instance,LPCWSTR name, UINT
loadflags )
+static HBITMAP BITMAP_Load( HINSTANCE instance,LPCWSTR name,
+INT width, INT height, UINT loadflags )
{
HBITMAP hbitmap = 0;
HRSRC hRsrc;
@@ -1934,6 +1935,8 @@
BITMAPINFO *info, *fix_info=NULL;
HGLOBAL hFix;
int size;
+BOOLfStretch = FALSE;
+HDC hdcMem =NULL;
if (!(loadflags & LR_LOADFROMFILE))
{
@@ -1953,6 +1956,12 @@
if (!(ptr = map_fileW( name ))) return 0;
info = (BITMAPINFO *)(ptr + sizeof(BITMAPFILEHEADER));
}
+
+if (!width) width = info->bmiHeader.biWidth;
+if (!height) height = info->bmiHeader.biHeight;
+fStretch = (info->bmiHeader.biHeight != height) ||
+ (info->bmiHeader.biWidth != width);
+
size = DIB_BitmapInfoSize(info, DIB_RGB_COLORS);
if ((hFix = GlobalAlloc(0, size))) fix_info=GlobalLock(hFix);
if (fix_info) {
@@ -1965,7 +1974,42 @@
if (screen_dc)
{
char *bits = (char *)info + size;
- if (loadflags & LR_CREATED
Re: CreateBitmap fails
Patch for loading bitmaps.
ChangeLog:
* dlls/comctl32/toolar.c
- Create a compatible bitmap of the display, which can be selected into
a device context.
* windows/cursoricon.c
- Loading bitmaps with specified size works now.
Index: dlls/comctl32/toolbar.c
===
RCS file: /home/wine/wine/dlls/comctl32/toolbar.c,v
retrieving revision 1.139
diff -u -r1.139 toolbar.c
--- dlls/comctl32/toolbar.c 17 Sep 2003 20:15:21 - 1.139
+++ dlls/comctl32/toolbar.c 20 Sep 2003 10:40:03 -
@@ -2215,7 +2215,7 @@
/* create new default image list */
TRACE ("creating default image list!\n");
-himlDef = ImageList_Create (infoPtr->nBitmapWidth,
infoPtr->nBitmapHeight,
+himlDef = ImageList_Create (infoPtr->nBitmapWidth,
infoPtr->nBitmapHeight,
ILC_COLOR | ILC_MASK, nButtons, 2);
TOOLBAR_InsertImageList(&infoPtr->himlDef, &infoPtr->cimlDef, himlDef,
0);
infoPtr->himlInt = himlDef;
@@ -2236,7 +2236,7 @@
{
BITMAP bmp;
HBITMAP hOldBitmapBitmap, hOldBitmapLoad;
- HDC hdcImage, hdcBitmap;
+ HDC hdcImage, hdcBitmap, hdcScreen;
/* copy the bitmap before adding it so that the user's bitmap
* doesn't get modified.
@@ -2245,11 +2245,12 @@
hdcImage = CreateCompatibleDC(0);
hdcBitmap = CreateCompatibleDC(0);
+ hdcScreen = GetDC(NULL);
/* create new bitmap */
- hbmLoad = CreateBitmap (bmp.bmWidth, bmp.bmHeight, bmp.bmPlanes,
bmp.bmBitsPixel, NULL);
- hOldBitmapBitmap = SelectObject(hdcBitmap, (HBITMAP)lpAddBmp->nID);
- hOldBitmapLoad = SelectObject(hdcImage, hbmLoad);
+ hbmLoad = CreateCompatibleBitmap (hdcScreen, bmp.bmWidth,
bmp.bmHeight);
+ hOldBitmapBitmap = SelectObject (hdcBitmap,
(HBITMAP)lpAddBmp->nID);
+ hOldBitmapLoad = SelectObject (hdcImage, hbmLoad);
/* Copy the user's image */
BitBlt (hdcImage, 0, 0, bmp.bmWidth, bmp.bmHeight,
@@ -2259,6 +2260,7 @@
SelectObject (hdcBitmap, hOldBitmapBitmap);
DeleteDC (hdcImage);
DeleteDC (hdcBitmap);
+ ReleaseDC (NULL, hdcScreen);
nIndex = ImageList_AddMasked (himlDef, hbmLoad, CLR_DEFAULT);
DeleteObject (hbmLoad);
@@ -3845,7 +3847,7 @@
{
BITMAP bmp;
HBITMAP hOldBitmapBitmap, hOldBitmapLoad, hbmLoad;
- HDC hdcImage, hdcBitmap;
+ HDC hdcImage, hdcBitmap, hdcScreen;
/* copy the bitmap before adding it so that the user's bitmap
* doesn't get modified.
@@ -3854,11 +3856,12 @@
hdcImage = CreateCompatibleDC(0);
hdcBitmap = CreateCompatibleDC(0);
+ hdcScreen = GetDC(NULL);
/* create new bitmap */
- hbmLoad = CreateBitmap (bmp.bmWidth, bmp.bmHeight, bmp.bmPlanes,
bmp.bmBitsPixel, NULL);
- hOldBitmapBitmap = SelectObject(hdcBitmap, hBitmap);
- hOldBitmapLoad = SelectObject(hdcImage, hbmLoad);
+ hbmLoad = CreateCompatibleBitmap (hdcScreen, bmp.bmWidth,
bmp.bmHeight);
+ hOldBitmapBitmap = SelectObject (hdcBitmap, hBitmap);
+ hOldBitmapLoad = SelectObject (hdcImage, hbmLoad);
/* Copy the user's image */
BitBlt (hdcImage, 0, 0, bmp.bmWidth, bmp.bmHeight,
@@ -3868,6 +3871,7 @@
SelectObject (hdcBitmap, hOldBitmapBitmap);
DeleteDC (hdcImage);
DeleteDC (hdcBitmap);
+ ReleaseDC (NULL, hdcScreen);
ImageList_AddMasked (himlDef, hbmLoad, CLR_DEFAULT);
DeleteObject (hbmLoad);
Index: windows/cursoricon.c
===
RCS file: /home/wine/wine/windows/cursoricon.c,v
retrieving revision 1.68
diff -u -r1.68 cursoricon.c
--- windows/cursoricon.c 10 Sep 2003 03:56:47 - 1.68
+++ windows/cursoricon.c 20 Sep 2003 10:40:32 -
@@ -1925,7 +1925,8 @@
/**
* BITMAP_Load
*/
-static HBITMAP BITMAP_Load( HINSTANCE instance,LPCWSTR name, UINT
loadflags )
+static HBITMAP BITMAP_Load( HINSTANCE instance,LPCWSTR name,
+INT width, INT height, UINT loadflags )
{
HBITMAP hbitmap = 0;
HRSRC hRsrc;
@@ -1934,6 +1935,8 @@
BITMAPINFO *info, *fix_info=NULL;
HGLOBAL hFix;
int size;
+BOOLfStretch = FALSE;
+HDC hdcMem =NULL;
if (!(loadflags & LR_LOADFROMFILE))
{
@@ -1953,6 +1956,12 @@
if (!(ptr = map_fileW( name ))) return 0;
info = (BITMAPINFO *)(ptr + sizeof(BITMAPFILEHEADER));
}
+
+if (!width) width = info->bmiHeader.biWidth;
+if (!height) height = info->bmiHeader.biHeight;
+fStretch = (info->bmiHeader.biHeight != height) ||
+ (info->bmiHeader.biWidth != width);
+
size = DIB_BitmapInfoSize(info, DIB_RGB_COLORS);
if ((hFix = GlobalAlloc(0, size))) fix_info=GlobalLock(hFix);
if (fix_info) {
@@ -1965,7 +1974,42 @@
if (screen_dc)
{
char *bits = (char *)info + size;
- if (loadflags & LR_CREATED
