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.
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 (a
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
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 t
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 g
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
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
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;
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 th
> 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
> +++ dl
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*
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
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
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
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.
>
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
> 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 devel
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 unco
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 els
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_c
> 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 com
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.
>
>
>
>
>
> 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.
> 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 t
> 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.
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
> 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
> 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
> 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:-).
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
==
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
==
31 matches
Mail list logo
