April 2006 - Wine-devel - list.winehq.org

Summer of Code strategy
by Dan Kegel 15 Apr '06

15 Apr '06

Hi everybody! There are two weeks before students can submit Summer of Code proposals. How can we use that time to maximize the number of successful projects this year? The students who already have their own good ideas (whoever they are) will probably succeed; we probably need to provide a set of prefab projects of sorts to give guidance to students who are new to Wine and haven't any idea what to work on. Ideally, each such prefab project would have an active developer (or a close approximation) as project leader and mentor. Are any developers willing and able to come up with a project idea and help mentor/supervise a student to work on it? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

SETI@Home
by Tom Spear 14 Apr '06

14 Apr '06

This is a lil bit off topic, but I thought I would bring it up, since we have users that are trying to run windows BOINC under wine. The wine project has a SETI(a)Home team (has had for some time), so if you run the windows or linux BOINC/SETI(a)Home client, you can join our team and apply your credits towards the project's total. Just go to http://setiathome.berkeley.edu/team_display.php?teamid=38091 and click the Join link. Tom

5 5

Summer of Code 2006 is on!
by Dan Kegel 14 Apr '06

14 Apr '06

I've updated http://wiki.winehq.org/SummerOfCode, but it's a bit short on project ideas. (Somewhat on purpose -- last year, people just copied and pasted our detailed project ideas. This year, lets give fewer details and more ideas... if somebody's really interested, they'll ask for details on wine-devel, and that process will generate fewer boilerplate applications.) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: Change threading defaults on FreeBSD
by Alexandre Julliard 14 Apr '06

14 Apr '06

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > ChangeLog: > On FreeBSD, build wine-pthread in addition to wine-kthread and make > the former the default. If you build both, then you need a way to decide which one will be used. That's not the sort of detail we want to have users worry about. -- Alexandre Julliard julliard(a)winehq.org

2 2

Fwd: [Bug 4051] winecfg crashes when clicking on Audio tab due to arts bugs
by Tom Spear 14 Apr '06

14 Apr '06

---------- Forwarded message ---------- From: Wine Bugs <wine-bugs(a)winehq.org> Date: Apr 14, 2006 7:17 AM Subject: [Bug 4051] winecfg crashes when clicking on Audio tab due to arts bugs To: wine-bugs(a)winehq.org http://bugs.winehq.org/show_bug.cgi?id=4051 ------- Additional Comments From alexander.heinlein(a)web.de 2006-14-04 07:17 ------- Hi. I encounter the same issue. wine wants to access /tmp/ksocket-$USER, but i do not have KDE installed (only KDM) and do not use arts (arts isn't even installed, only some library headers which i can't uninstall because of SDL) or any other soundserver, but hardwaremixing. So i have to manually create the directory /tmp/ksocket-$USER to let the audio tab in winecfg not crash. I tested this with wine 0.9.10 and 0.9.11. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------- Notes from Tom: This should be a fairly trivial fix, all we need to do is check for the existence of the socket file before trying to connect to it, and if it is not there, then skip the arts probe.. Could someone whip up a patch for this? Tom

1 0

DllOverrides
by Rich Gilson 14 Apr '06

14 Apr '06

I'm looking at what is done in Winetools (no, this is not another WineTools discussion ;-) ) as far as the DllOverrides and it has generated a few questions. Here are a couple of lines from the wt-config.reg file: "*"="native, builtin" "*autorun.exe"="native,builtin" "msi"="native, builtin" "odbc32"="native, builtin" Can somebody explain the lines with an *? Does the "*" mean that if the driver, dll, exe in question is not listed in the DllOverrides section, that it defaults to using the native version of the file and, if not available, then tries to find and run a builtin version? In the case of the "*autorun.exe", does it literally me that any .exe file with a name ending in autorun would use a native version first, like a normal wildcard would be used? That wouldn't make sense to me because there is no file that matches that description in my .wine directory,. In fact, the only copy of autorun that I can find on my system is the autorun.exe.so from cxoffice. I would appreciate all the enlightenment I can get on this subject. Thanks. -- -- In a world without fences, who needs Gates?

3 3

Hidden files
by Rich Gilson 14 Apr '06

14 Apr '06

Here's another question that has been spawned by looking through the Winetools code. It touches two files: ~/.wine/.no_debug_window_flag ~/.wine/.no_prelaunch_window_flag Have these been depricated or completely removed, or are they still something that would be used by Wine? If they are still used, is there a list of all such hidden files and what they do? -- -- In a world without fences, who needs Gates?

2 2

Cups printer detection in pre-built packages
by J.R. Oldroyd 14 Apr '06

14 Apr '06

I've been discussing this with the maintainer of the FreeBSD wine port. Right now, detection of libcups.so is done by the configure script at compile time. This means that pre-built packages must either pull in cups as a port dependency in order to always enable printer support, or they must do without printer support. Pulling in cups as a dependency is expensive for those that don't want it, and so cups is disabled for everyone using the FreeBSD binary packages. You need to compile the port if you want cups support. Wouldn't a better detection method be to check at runtime for the presence of a libcups.so (by means of a dlopen()) and enable printers if it's found, or disable them if it's not found? The significance of this would be that a cups dependency is required to build the binary package, but the dependency is optional at runtime. And this means that printers would always work, even from a binary package install. -jr

2 1

[gdi] bug reading/writing metafiles on sparc
by Eric Frias 14 Apr '06

14 Apr '06

Due to little-endian/big-endian differences, winelib on Sparc can't read windows metafiles generated on a PC (or on Wine on x86), and conversely PCs can't read metafiles created on a Sparc. It looks like there are a few ways this could be fixed, and I wanted to make sure we don't go about it the wrong way (and that nobody else is working on it). I think the right thing to do is make the on-disk and in-memory formats always be little-endian. We would only convert the data to big-endian format when it is generated or used. GetMetaFileBitsEx and SetMetaFileBitsEx would return & take the raw data in little-endian format. The implementation we're considering involves: - in PlayMetaFileRecord(), convert endianness of paramters as they're used: LineTo(hdc, (SHORT)mr->rdParm[1], (SHORT)mr->rdParm[0]); becomes LineTo(hdc, (SHORT)convert_word_from_little_endian(mr->rdParm[1]), (SHORT)convert_word_from_little_endian(mr->rdParm[0])); - in MFDRV_MetaParam2(), convert endianness *(mr->rdParm) = param2; becomes *(mr->rdParm) = convert_word_to_little_endian(param2); - some similar conversions necessary for anything that reads/writes the header - anything that calls MFDRV_WriteRecord() would need special handling. These seem to be the functions that embed bitmaps or text in the METARECORD, so we'll have to be selective about what gets converted and what gets written as-is. Is this the right way to go about fixing the problem? Anything we should look out for? Thanks, Eric

2 5

Re: Eliminate dependency on Fontforge
by gslink 14 Apr '06

14 Apr '06

As I see it, Fontforge was never the problem. The problem was that it was necessary to read the code to find out that there even was such a dependency. This was especially true of the Red Hat binaries. There was no notice or documentation that they would use Fontforge. I didn't find out until I started playing with Fontforge and had Wine crash as a result. It doesn't make any difference what the Wine dependencies are if: 1. They are documented. 2. I can find the dependent programs.

1 0