Table Of Contents
|1.||31�Dec�2000�-�3�Dec�2001||(27 posts)||COM macros and preprocessor|
|2.||1�Jan�2001�-�3�Jan�2001||(12 posts)||Another libc2.x and dl-library issue|
|3.||28�Dec�2000�-�2�Jan�2001||(11 posts)||Revisiting Wine application database|
|4.||6�Jan�2001||(4 posts)||CDROMs handling|
IntroductionThis is the 77th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).
Mailing List Stats For This Week
We looked at 128 posts in 488K.
There were 45 different contributors. 24 posted more than once. 21 posted last week too.
The top posters of the week were:
1. COM macros and preprocessor
31�Dec�2000�-�3�Dec�2001 (27 posts) Archive Link: "compilation error on uuid.c"
People: James Juran,�James Juran reported errors while compiling Wine with Red Hat 7.0 gcc (2.96) compiler. After some testings, it turned out that a recent patch was mis-interpreted by the pre-processor. The definition and the implementation of the COM virtual tables in Wine is done using a set of macros. Some cases are somewhat difficult: some methods in those vtables have the same name as a regular API function (
GetClassInfoare the two known examples). But, as Windows, some APIs are present under two forms (Ansi and Unicode); in that case two functions are defined (one is suffixed with A for Ansi, the other one for W for Wide (aka Unicode) (for example
fooW). Then a macro foo is defined either as
fooA) if the manifest constant
UNICODEis defined (resp. not defined). This behavior is mostly implemented for the sake of Winelib programs. For the Wine internal code, the suffixed version only are supposed to be called. To enforce this rule, the headers turn the foo macro (while compiling Wine) into a dummy identificator to catch the error. The COM macros in order to be in sync will all this did some tricks:
bar) have to be implemented as a function whose name is the concatenation of a prefix (
fn) with the name of the method (in this example
GetObjectthe prefixing with fn was done before expanding
GetObjectinto its error identifier
fn, but this would lead to changing more than 1500 COM definitions, which was overkill
fnprefix in the COM methods definition. This was doable if the
#undef:ined, removing some of the compilation time coherency tests for those APIs (the error shall be caught at link time).
2. Another libc2.x and dl-library issue
1�Jan�2001�-�3�Jan�2001 (12 posts) Archive Link: "libc2.2 pthread segfault"
People: Andreas Mohr,�,�James AbbatielloAndreas Mohr reported a segmentation fault at startup. This seemed to occur right after he upgraded Debian libc6 2.2-6 to libc6 2.2-8. After some testings, the same type of errors with dlopen as already worked around before (BROKEN KCREF) stroke once again. James Abbatiello proposed another patch (in the same vein as the one he already wrote for the previous issue), except that in the current case the dl error code had to be cleared before calling any dl functions. However, after some testings Andi found out Debian libc6 2.2-8 to cause lots of issues to his notebook, and wondered if the patch against a poor libc version was needed. As of today, no patch has been applied. Since Debian libc6 2.2-9 fixes this very issue (read works correctly without this patch), it's very likely Wine will never be compatible with 2.2-8. Anyone using this libc version is requested to upgrade.
3. Revisiting Wine application database
28�Dec�2000�-�2�Jan�2001 (11 posts) Archive Link: "[LONG :-)] Some ramblings about the Wine Application Database"
People: Lionel Ulmer,�Francois Gouget,�Jonathonm Griffiths,�Jeremy White,�,�Jon GriffithsLionel Ulmer started a long thread by posting a long proposal revisiting the internals of Wine's application database. It's the database containing the test results from existing Windows applications against the different Wine versions. Here are the main parts;
4. CDROMs handling
6�Jan�2001 (4 posts) Archive Link: "CDROM_GetLabel return code"
People: Ryan Cuming,�Andreas Mohr,�Ryan Cumming proposed a patch to the CD ROM label handling:
~/.wine/configfile. Before going further, a quick reminder on CD. CD can be of various forms. The most known are the CD Audios (which contain music) and CD containing data (using the ISO 9660 format). Under Linux, the second type requires to be mounted, and if the iso 9660 file system is supported in the OS, content of the CD can be read as any device (hard disk...). The first type can be read by CD Audio players. CD can also be mixed: they contain both audio tracks and binary data. This latter format is not properly handled in Wine because of the duality of accesses which are cannot be easily intertwined. In some cases, Wine is not able to get the label from an ISO 9660 drive. To cope with that, the user can add a default label to the Wine's config file which will be returned in that case (of course, it's not an universal solution because the label changes with every CD, and the entry in the configuration file is linked to the CD ROM device, not the CD ROM itself). Going back to Ryan's patch, Andreas Mohr completely agreed on Ryan's proposal (the old code setting an empty string in case of failure wasn't correct). However Andi suggested to always have a default value for the label (like
"[Drive E]"in the case the user didn't set up a default label in the
~/.wine/config file). Later on, Ryan proposed again his patch, returning a blank string if no default label has been set. Ryan also proposed
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.