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
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
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;
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
+++
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
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.,
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
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
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.
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
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.
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
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
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.
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?
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:-).
18 matches
Mail list logo
