http://bugs.winehq.com/show_bug.cgi?id=780
*** shadow/780 Sun Jun 9 22:40:28 2002
--- shadow/780.tmp.12881 Sun Jun 9 22:40:44 2002
***************
*** 13,18 ****
--- 13,19 ----
+----------------------------------------------------------------------------+
| Milestone: TargetMilestone: --- |
| URL: |
+ | Dependencies: OtherBugsDependingOnThis: 395 |
+============================================================================+
| DESCRIPTION |
Eric Pouech is currently working on an Alsa 0.5 module. However he said that
http://bugs.winehq.com/show_bug.cgi?id=780
*** shadow/780 Sun Jun 9 22:40:10 2002
--- shadow/780.tmp.12839 Sun Jun 9 22:40:10 2002
***************
*** 0 ****
--- 1,29 ----
+ +============================================================================+
+ | Implement an Alsa 0.9 sound module |
+ +----------------------------------------------------------------------------+
+ | Bug #: 780 Product: Wine |
+ | Status: UNCONFIRMED Version: unspecified |
+ | Resolution: Platform: |
+ | Severity: normal OS/Version: All |
+ | Priority: P1 Component: wine-multimedia |
+ +----------------------------------------------------------------------------+
+ | Assigned To: wine-bugs(a)winehq.com |
+ | Reported By: fgouget(a)codeweavers.com |
+ | CC list: Cc: |
+ +----------------------------------------------------------------------------+
+ | Milestone: TargetMilestone: --- |
+ | URL: |
+ +============================================================================+
+ | DESCRIPTION |
+ Eric Pouech is currently working on an Alsa 0.5 module. However he said that
+ Alsa 0.9 is so different that we would need a separate module to support it. Or
+ if it's not a completely separate module it would in any case take quite a bit
+ of work to also support Alsa 0.9. So I'm creating a new task.
+
+ References:
+ * bug 324 - Implement an Alsa 0.5 sound module
+ http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=324
+ * 2002/04/19 - Marco Pietrobono - ALSA driver
+ http://www.winehq.com/hypermail/wine-devel/2002/04/0349.html
+ * 2002/06/06 - Marco Pietrobono - Re: How big is the Direct3D stuff?
+ http://www.winehq.com/hypermail/wine-devel/2002/06/0108.html
\ No newline at end of file
http://bugs.winehq.com/show_bug.cgi?id=778
*** shadow/778 Sun Jun 9 15:24:39 2002
--- shadow/778.tmp.12600 Sun Jun 9 22:35:08 2002
***************
*** 2,8 ****
| Compiler warnings for wine-20020605 |
+----------------------------------------------------------------------------+
| Bug #: 778 Product: Wine |
! | Status: UNCONFIRMED Version: unspecified |
| Resolution: Platform: |
| Severity: normal OS/Version: All |
| Priority: P1 Component: wine-binary |
--- 2,8 ----
| Compiler warnings for wine-20020605 |
+----------------------------------------------------------------------------+
| Bug #: 778 Product: Wine |
! | Status: NEW Version: unspecified |
| Resolution: Platform: |
| Severity: normal OS/Version: All |
| Priority: P1 Component: wine-binary |
***************
*** 48,50 ****
--- 48,104 ----
dlls/oleaut32/variant.c:4647: warning: unsigned value < 0 is always 0
dlls/wininet/internet.c:855: warning: unsigned value < 0 is always 0
dlls/wininet/internet.c:903: warning: unsigned value < 0 is always 0
+
+ ------- Additional Comments From vberon(a)mecano.gme.usherb.ca 2002-06-09 22:35 -------
+ Not familiar with a bunch of those files, but here's what I'm sure of:
+
+ files/file.c:135: warning: unsigned value < 0 is always 0
+ Sent a mail to Martin Wilck for him to check it.
+
+ dlls/ntdll/reg.c:229: warning: unsigned value < 0 is always 0
+ The max is always bypassed. The three types involved are two size_t and a ULONG
+ Not familiar with the functionality. No patch yet from me.
+
+ dlls/gdi/freetype.c:712: warning: unsigned value < 0 is always 0
+ dlls/shlwapi/ordinal.c:2458: warning: unsigned value < 0 is always 0
+ dlls/shlwapi/ordinal.c:2473: warning: unsigned value < 0 is always 0
+ dlls/shlwapi/shlwapi_main.c:63: warning: unsigned value >= 0 is always 1
+ Comparison of a DWORD < 0, or DWORD >= 0. A value of -1 indicates failure. No
+ patch yet from me. Probably some type changes needed, or a cast.
+
+ dlls/ole32/hglobalstream.c:614: warning: unsigned value < 0 is always 0
+ Involves LARGE_INTEGER arithmetics. Test probably broken, but no proof yet.
+
+ dlls/shlwapi/ordinal.c:1163: warning: unsigned value < 0 is always 0
+ Not sure which function is really called (hence, no clue about the validity of
+ the construction).
+
+ dlls/oleaut32/typelib.c:4586: warning: unsigned value >= 0 is always 1
+ dlls/oleaut32/typelib.c:4819: warning: unsigned value >= 0 is always 1
+ UINT verified for >= 0. Might be removable, not sure. No patch yet from me.
+
+ dlls/comctl32/listview.c:1835: warning: unsigned value >= 0 is always 1
+ dlls/comctl32/listview.c:1838: warning: unsigned value >= 0 is always 1
+ Addition of a DWORD and an int gives an unsigned int. Patch submitted to
+ wine-patches.
+
+ dlls/x11drv/winpos.c:1405: warning: unsigned value >= 0 is always 1
+ BAD!!! Continuation condition of a for is always 1. Patch submitted to wine-patches.
+
+ dlls/advapi32/crypt.c:845: warning: unsigned value < 0 is always 0
+ dlls/advapi32/crypt.c:1132: warning: unsigned value < 0 is always 0
+ controls/button.c:201: warning: unsigned value < 0 is always 0
+ dlls/ole32/oleobj.c:291: warning: unsigned value < 0 is always 0
+ dlls/ole32/oleobj.c:650: warning: unsigned value < 0 is always 0
+ dlls/oleaut32/variant.c:3935: warning: unsigned value < 0 is always 0
+ Comparison of a DWORD or UINT parameter < 0. Seems the specific test can be
+ safely removed. Patch submitted to wine-patches.
+
+ dlls/oleaut32/variant.c:4035: warning: unsigned value < 0 is always 0
+ dlls/oleaut32/variant.c:4647: warning: unsigned value < 0 is always 0
+ dlls/wininet/internet.c:855: warning: unsigned value < 0 is always 0
+ dlls/wininet/internet.c:903: warning: unsigned value < 0 is always 0
+ Type wasn't suited for the task. Patch submitted to wine-patches.
+
+ I don't take ownership of this bug, as I'm not familiar enough with the balance
+ of the various issues.
\ No newline at end of file
http://bugs.winehq.com/show_bug.cgi?id=508
*** shadow/508 Sun Jun 9 11:50:13 2002
--- shadow/508.tmp.4845 Sun Jun 9 19:36:39 2002
***************
*** 33,35 ****
--- 33,47 ----
whole slew of traces to fix: %d -> %p.
IOW, lots of work to do.
+
+
+ ------- Additional Comments From fgouget(a)codeweavers.com 2002-06-09 19:36 -------
+ Some further elements of the plan: the plan is to first make progress on the
+ compilation errors by changing the code that uses HANDLES as indexes so that it
+ (hopefully) works in both STRICT and non-STRICT mode. To make it easier to work
+ the idea would be to further disable the %d/%p mismatch warning by disabling
+ them, by locally (i.e. not in CVS) redefining __WINE_PRINTF_ATTR in
+ 'include/wine/debug.h'.
+ Once Wine compiles with a void* HANDLE, then we can write a perl script that
+ parses the compilation log and automatically fixes the %d/%p warnings. Then
+ Alexandre can make one huge CVS commit.
http://bugs.winehq.com/show_bug.cgi?id=778
*** shadow/778 Sun Jun 9 15:24:39 2002
--- shadow/778.tmp.26524 Sun Jun 9 15:24:39 2002
***************
*** 0 ****
--- 1,50 ----
+ +============================================================================+
+ | Compiler warnings for wine-20020605 |
+ +----------------------------------------------------------------------------+
+ | Bug #: 778 Product: Wine |
+ | Status: UNCONFIRMED Version: unspecified |
+ | Resolution: Platform: |
+ | Severity: normal OS/Version: All |
+ | Priority: P1 Component: wine-binary |
+ +----------------------------------------------------------------------------+
+ | Assigned To: wine-bugs(a)winehq.com |
+ | Reported By: tenthumbs(a)cybernex.net |
+ | CC list: Cc: |
+ +----------------------------------------------------------------------------+
+ | Milestone: TargetMilestone: --- |
+ | URL: |
+ +============================================================================+
+ | DESCRIPTION |
+ I used gcc -W and these warnigns turned up. Most of them are of the form
+ unsigned foo;
+ if (foo < 0) report _error;
+ Gcc is "smart" and knows unsigned values can never be negative so the test is
+ false, the error clause becomes unreachable code and gcc eliminates it when
+ optimizing. Not good.
+
+ I'm sure the component is wrong so someone fix it.
+
+ The list:
+ files/file.c:135: warning: unsigned value < 0 is always 0
+ dlls/ntdll/reg.c:229: warning: unsigned value < 0 is always 0
+ dlls/advapi32/crypt.c:845: warning: unsigned value < 0 is always 0
+ dlls/advapi32/crypt.c:1132: warning: unsigned value < 0 is always 0
+ dlls/gdi/freetype.c:712: warning: unsigned value < 0 is always 0
+ controls/button.c:201: warning: unsigned value < 0 is always 0
+ dlls/x11drv/winpos.c:1405: warning: unsigned value >= 0 is always 1
+ dlls/comctl32/listview.c:1835: warning: unsigned value >= 0 is always 1
+ dlls/comctl32/listview.c:1838: warning: unsigned value >= 0 is always 1
+ dlls/ole32/hglobalstream.c:614: warning: unsigned value < 0 is always 0
+ dlls/ole32/oleobj.c:291: warning: unsigned value < 0 is always 0
+ dlls/ole32/oleobj.c:650: warning: unsigned value < 0 is always 0
+ dlls/shlwapi/ordinal.c:1163: warning: unsigned value < 0 is always 0
+ dlls/shlwapi/ordinal.c:2458: warning: unsigned value < 0 is always 0
+ dlls/shlwapi/ordinal.c:2473: warning: unsigned value < 0 is always 0
+ dlls/shlwapi/shlwapi_main.c:63: warning: unsigned value >= 0 is always 1
+ dlls/oleaut32/typelib.c:4586: warning: unsigned value >= 0 is always 1
+ dlls/oleaut32/typelib.c:4819: warning: unsigned value >= 0 is always 1
+ dlls/oleaut32/variant.c:3935: warning: unsigned value < 0 is always 0
+ dlls/oleaut32/variant.c:4035: warning: unsigned value < 0 is always 0
+ dlls/oleaut32/variant.c:4647: warning: unsigned value < 0 is always 0
+ dlls/wininet/internet.c:855: warning: unsigned value < 0 is always 0
+ dlls/wininet/internet.c:903: warning: unsigned value < 0 is always 0
\ No newline at end of file
http://bugs.winehq.com/show_bug.cgi?id=467
*** shadow/467 Sat Jun 1 17:18:34 2002
--- shadow/467.tmp.18617 Sun Jun 9 12:38:01 2002
***************
*** 301,303 ****
--- 301,307 ----
Ricardo can you try to install from CVS as we can work on the bug better if this
is the case.
+
+ ------- Additional Comments From centi_riccardo(a)libero.it 2002-06-09 12:38 -------
+ Created an attachment (id=171)
+ ME AGAIN
http://bugs.winehq.com/show_bug.cgi?id=508
*** shadow/508 Wed Mar 20 07:45:21 2002
--- shadow/508.tmp.16052 Sun Jun 9 11:50:13 2002
***************
*** 7,13 ****
| Severity: normal OS/Version: All |
| Priority: P1 Component: wine-winelib |
+----------------------------------------------------------------------------+
! | Assigned To: bugs(a)codeweavers.com |
| Reported By: fgouget(a)codeweavers.com |
| CC list: Cc: |
+----------------------------------------------------------------------------+
--- 7,13 ----
| Severity: normal OS/Version: All |
| Priority: P1 Component: wine-winelib |
+----------------------------------------------------------------------------+
! | Assigned To: wine-bugs(a)winehq.com |
| Reported By: fgouget(a)codeweavers.com |
| CC list: Cc: |
+----------------------------------------------------------------------------+
***************
*** 18,20 ****
--- 18,35 ----
| DESCRIPTION |
See bug 90 for instructions.
Approximate number of references: 1219
+
+ ------- Additional Comments From fgouget(a)codeweavers.com 2002-06-09 11:50 -------
+ This is the blocking target right now.
+ The problem is that many other handles are being assigned to a HANDLE variable.
+ So these assignements cannot be done without a cast as they otherwise generate a
+ warning.
+ So the idea is to convert HANDLE, and hence all other handle types to void*.
+ Thus assignments will be doable between them without casts. Then we can continue
+ converting individual handles to strict mode, i.e. to pointer types other than
+ void*.
+ There are a number of compilation errors to fix to make Wine compile with a
+ void* for handles: cases where a handle is used as an index. Then there is a
+ whole slew of traces to fix: %d -> %p.
+ IOW, lots of work to do.
+
http://bugs.winehq.com/show_bug.cgi?id=514
*** shadow/514 Thu May 30 15:05:22 2002
--- shadow/514.tmp.12356 Sun Jun 9 03:31:35 2002
***************
*** 2358,2360 ****
--- 2358,2367 ----
******************************************************
I mean - did you try the installation before with older Wine and whether it worked?
+
+ ------- Additional Comments From fgouget(a)codeweavers.com 2002-06-09 03:31 -------
+ __CxxFrameHandler: I have also seen this kind of traces quite a few times
+ myself. I am not sure however whether it was the cause or the symptom of the
+ problem.
+ Regardless, because it keeps comming back it may be interesting to actually
+ implement it right (if one finds documentation for it).
http://bugs.winehq.com/show_bug.cgi?id=410
*** shadow/410 Wed May 29 15:07:43 2002
--- shadow/410.tmp.31188 Sat Jun 8 21:50:13 2002
***************
*** 2,8 ****
| Sound stuck at 48000Hz |
+----------------------------------------------------------------------------+
| Bug #: 410 Product: Wine |
! | Status: UNCONFIRMED Version: unspecified |
| Resolution: Platform: |
| Severity: normal OS/Version: All |
| Priority: P1 Component: wine-directx |
--- 2,8 ----
| Sound stuck at 48000Hz |
+----------------------------------------------------------------------------+
| Bug #: 410 Product: Wine |
! | Status: RESOLVED Version: unspecified |
| Resolution: Platform: |
| Severity: normal OS/Version: All |
| Priority: P1 Component: wine-directx |
***************
*** 29,31 ****
--- 29,47 ----
Try to reproduce the problem with recent Wine build.
If the problem still exists, please provide details how to reproduce it, which
application you run, do you see the same problem with Linux native applications?
+
+ ------- Additional Comments From tony_lambregts(a)telusplanet.net 2002-06-08 21:50 -------
+ according to offline post by the reporter this is not a wine bug so marking as
+ RESOLVED
+ -----------------------------------------------------
+ Nope problem not fixed.
+ But the problem occurs in every Linux app except those that can mix as 48khz.
+
+ Also poblem in some apps such as HL -> sound is very crackled, but according to
+ some other buglists it is because data isn't send fast enough.. or let's say
+ data is sent at 22Khz, but soundcard accepts data at 48Khz...
+
+ Not a wine problem.
+
+ sorry for troubling you.
+ -----------
\ No newline at end of file