wine-devel April 2006

wine-devel@winehq.org

176 participants
334 discussions

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

Things That Doesn't Work Too Well With DxGrab=Yes (tm)
by Molle Bestefich 14 Apr '06

14 Apr '06

Hi. Hope I do not spam too much. Things That Doesn't Work Too Well With DxGrab=Yes (tm) ============================================= 1.) Grabbing isn't disabled when I switch to the KDE menu with CTRL-ESC. (I was trying to start ksnapshot.) 2.) Grabbing isn't disabled when I switch (to ksnapshot) with ALT-TAB. 3.) Grabbing isn't disabled when I start the Campaign Editor in Starcraft, which is a separate application launched in windowed mode in maximized state. Even though the Campaign Editor correctly gets focus, the mouse is still caught in the rectangle where Starcraft used to be, plus some keyboard and all mouse input doesn't work. The MS-Windows solution is to minimize fullscreen applications and let the mouse roam freely when the fullscreen app loose focus. Also, MS-Windows switches back to the user's preferred resolution when a fullscreen application looses focus, which is nice. I'm not sure what the best solution for Wine is, but the current one isn't it ;-). I'll open a bug on this unless anyone think that's a bad idea? There's already bug 888, but that's about an entirely different approach which I think is less useful.

1 0

tasklet - sfd2ttf - eliminate dependency on FontForge (for anybody who's interested)
by Mike McCormack 14 Apr '06

14 Apr '06

Hi, Wine's build time dependency on FontForge is causing a bit of a problem, as can be seen by browsing the wine-devel archives for the last month. I propose that a small sfd2ttf utility be written and used instead of FontForge to eliminate the dependency, and make everybody a little happier. George Williams, the author of FontForge, is happy for us to use his code under LGPL, providing that we give the correct attributions. He'd probably like to sign off on the final code though. Alexandre agrees with the idea of an sfd2ttf utility, and is likely to accept it into the Wine tree, provided that is small enough (read 1/2 files) and is appropriately cut down. As I'm busy with my day job at the moment, we're only missing somebody to write it. Any volunteers? Mike

5 10

Re: advpack: Document RegisterOCX
by James Hawkins 14 Apr '06

14 Apr '06

On 4/13/06, James Hawkins <truiken(a)gmail.com> wrote: > > Changelog: > * Document RegisterOCX. > Ignore this patch, a couple of things are wrong with it; I'll resend a fixed patch. -- James Hawkins

1 0

← Newer
1
...
17
18
19
20
21
22
23
...
34
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2006