Re: cygwin runs!
Dan Kegel wrote: Hey! Cygwin actually installs and runs inside Wine! This is way cool! Last time I've checked there were some nasty problems, and I haven't seen the patches targeting this problem. So satisfying! :) Now, if we can get cygwin to run wine... g -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Version of Windows
This is probably trivial, but I'm having a tough time figuring out the current version of Windows that Wine is mimicking. I have a situation where I need to behave differently if the version is NT (0x0500) versus when it is XP (0x0600). I see the WINVER #define, but that doesn't seem right to me since this must be a runtime variable. Can someone point me at an example of how to tell what the current version of Windows is? Thanks, Chris
Re: Version of Windows
On Wed, Mar 19, 2008 at 1:31 AM, Chris Teague [EMAIL PROTECTED] wrote: This is probably trivial, but I'm having a tough time figuring out the current version of Windows that Wine is mimicking. I have a situation where I need to behave differently if the version is NT (0x0500) versus when it is XP (0x0600). I see the WINVER #define, but that doesn't seem right to me since this must be a runtime variable. Can someone point me at an example of how to tell what the current version of Windows is? Thanks, Chris http://wiki.winehq.org/UsefulRegistryKeys Search for Version
Re: Version of Windows
On Wed, Mar 19, 2008 at 2:02 AM, John Klehm [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 1:31 AM, Chris Teague [EMAIL PROTECTED] wrote: This is probably trivial, but I'm having a tough time figuring out the current version of Windows that Wine is mimicking. I have a situation where I need to behave differently if the version is NT (0x0500) versus when it is XP (0x0600). I see the WINVER #define, but that doesn't seem right to me since this must be a runtime variable. Can someone point me at an example of how to tell what the current version of Windows is? Thanks, Chris http://wiki.winehq.org/UsefulRegistryKeys Search for Version More direct perhaps http://source.winehq.org/git/wine.git/?a=blobdiff;f=tools/wine.inf;h=97a773533ec65020d175416852dae2cc4b6669ee;hp=cf4b7a026962efa47279d6d26a69918b62aaa36d;hb=f629dc4eb6006fbdc3f658d13186b9c7e08b189d;hpb=0e9d02ded40810272f8cf8dfc429f8d07e9e6fb9
Appdb nice urls: best way to test indexing of production data
On my spring break and had some free time so I thought I'd take a shot at implementing nice urls for the appdb that DanK had suggested a while back. I have decent bit of code in place that will interpret the url http://appdb.winehq.org/app/what-you-want-here and then feed the chunks into a hash table and return the match or matches however it goes. However indexing the large amount of data in the production appdb database could take sometime so I was wanting to test it before I sent my code in. I was wondering if there was a way to download the data from the appdb? --John Klehm
Re: winex11.drv: Handle arbitrary length composed input.
On Wed, Mar 19, 2008 at 06:16:36PM +0900, Kusanagi Kouichi wrote:
Fix bug #9838. http://bugs.winehq.org/show_bug.cgi?id=9838
---
dlls/winex11.drv/keyboard.c | 25 -
dlls/winex11.drv/xim.c | 16 ++--
2 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/dlls/winex11.drv/keyboard.c b/dlls/winex11.drv/keyboard.c
index 33640db..386a471 100644
--- a/dlls/winex11.drv/keyboard.c
+++ b/dlls/winex11.drv/keyboard.c
@@ -1365,22 +1365,29 @@ void X11DRV_KeyEvent( HWND hwnd, XEvent *xev )
wine_tsx11_lock();
/* Clients should pass only KeyPress events to XmbLookupString */
if (xic event-type == KeyPress)
+{
ascii_chars = XmbLookupString(xic, event, Str, sizeof(Str), keysym,
status);
+
+if (status == XBufferOverflow)
+{
+char buf[ascii_chars];
You should not use dynamic sized arrays. Use HeapAlloc() to allocate them.
Ciao, Marcus
Re: [2/2] qmgr: Add a stub implementation of IBackgroundCopyJob2.
Dan Hipschman [EMAIL PROTECTED] writes: @@ -93,6 +93,10 @@ typedef struct const IClassFactoryVtbl *lpVtbl; } ClassFactoryImpl; +/* This makes it easier to upgrade to IBackgroundCopyJob3, IBackgroundCopyJob4, + and whatever else MS decides to tack on later. */ +typedef IBackgroundCopyJob2 BITS_IBackgroundCopyJob; Please don't do that, vtable entries should use the correct types, otherwise it will be very confusing. You'll just have to rename them when switching to a newer version of the interface. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [Try 2] A nicer icon for msiexec
Hervÿe9 Chanal [EMAIL PROTECTED] writes: It's a nicer icon for msiexec. From the last submit, several size are now included in the icon file. The icons are generated using a script i submitted to wine-patch a long time ago. The svg source is not in this patch. I can submit it too. Yes, we should include the svg source, and make sure we can rebuild the icons from it. Last time I tried to do that using your script I didn't get good results, the image was all mangled, so we need to look into this further. Can you please resubmit the svg? -- Alexandre Julliard [EMAIL PROTECTED]
Re: [4/22] WineD3D: A shader backend descriptor for the ati fragment shader backend
Am Mittwoch, 19. März 2008 07:46:07 schrieb Ivan Gyurdiev: Why do you need to reroute the shader path through atifs to support an unrelated set of functionality (ffp replacement)? Isn't it possible to have an ffp_backend, and a shader_backend (shader being the d3d shader), and you can implement both differently, with different APIs? Sounds all great and cool, but: How do you handle a case of a d3d vertex shader + fixed function fragment processing using a GLSL shader replacement? An Uber-Shader-Backend that links the shaders together? I can happily drop the strange routing through GLSL and the none shader backend for ATIFS, or with ARB pixel shaders enabled. In that case we'll just don't make use of it on ATI 9500+ cards until we have an ARB or GLSL replacement.
Alexandre Julliard : winex11: Fix bug report address
The Patch points to wine-cvs. Shouldn't it point to wine-devel.
Re: [4/22] WineD3D: A shader backend descriptor for the ati fragment shader backend
Am Mittwoch, 19. März 2008 07:46:07 schrieb Ivan Gyurdiev: The way this patchset is heading is: A (gl shader backend), which implements both d3d shader and ffp pipeline, depending on the circumstances, through a mixed api Yes, that's the only way that will work. The shader backend mutually talks to opengl, we have to design it around the requirements of the opengl (extension) APIs. Trying to stick the shader backend's design to d3d will not work properly All in all we can only have a ffp replacement shader OR a d3d shader active. Some instance has to sort out what is active, and given that in GLSL we'll need to link vertex+fragment+geometry shaders the shader backend is the best place to find that out IMHO
Re: Maarten Lankhorst : winmm: Fix midi deadlock by not holding lock on release .
This has a whiff of the double-checked locking anti-pattern. I can't
see a way where it would really bite us in this case, but that anti-
pattern has several subtleties. So, I just wanted to prompt people to
double-check it (pun acknowledged).
Cheers,
Ken
On Mar 18, 2008, at 7:44 AM, Alexandre Julliard wrote:
Module: wine
Branch: master
Commit: 15907b5035ea7f03b369a0463ab1f6ac2b24704e
URL:
http://source.winehq.org/git/wine.git/?a=commit;h=15907b5035ea7f03b369a0463ab1f6ac2b24704e
Author: Maarten Lankhorst [EMAIL PROTECTED]
Date: Mon Mar 17 13:15:42 2008 -0700
winmm: Fix midi deadlock by not holding lock on release.
---
dlls/winmm/mci.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/dlls/winmm/mci.c b/dlls/winmm/mci.c
index b7b5ac2..c792d18 100644
--- a/dlls/winmm/mci.c
+++ b/dlls/winmm/mci.c
@@ -1767,19 +1767,25 @@ staticDWORD MCI_Close(UINT16 wDevID, DWORD
dwParam, LPMCI_GENERIC_PARMS lpParms
TRACE((%04x, %08X, %p)\n, wDevID, dwParam, lpParms);
if (wDevID == MCI_ALL_DEVICE_ID) {
- LPWINE_MCIDRIVERnext;
-
- EnterCriticalSection(WINMM_cs);
/* FIXME: shall I notify once after all is done, or for
* each of the open drivers ? if the latest, which notif
* to return when only one fails ?
*/
- for (wmd = MciDrivers; wmd; ) {
- next = wmd-lpNext;
- MCI_Close(wmd-wDeviceID, dwParam, lpParms);
- wmd = next;
+ while (MciDrivers) {
+/* Retrieve the device ID under lock, but send the
message without,
+ * the driver might be calling some winmm functions
from another
+ * thread before being fully stopped.
+ */
+EnterCriticalSection(WINMM_cs);
+if (!MciDrivers)
+{
+LeaveCriticalSection(WINMM_cs);
+break;
+}
+wDevID = MciDrivers-wDeviceID;
+LeaveCriticalSection(WINMM_cs);
+MCI_Close(wDevID, dwParam, lpParms);
}
- LeaveCriticalSection(WINMM_cs);
return 0;
}
Re: [4/22] WineD3D: A shader backend descriptor for the ati fragment shader backend
Stefan Dösinger wrote: Am Mittwoch, 19. März 2008 07:46:07 schrieb Ivan Gyurdiev: Why do you need to reroute the shader path through atifs to support an unrelated set of functionality (ffp replacement)? Isn't it possible to have an ffp_backend, and a shader_backend (shader being the d3d shader), and you can implement both differently, with different APIs? Sounds all great and cool, but: How do you handle a case of a d3d vertex shader + fixed function fragment processing using a GLSL shader replacement? An Uber-Shader-Backend that links the shaders together? I can happily drop the strange routing through GLSL and the none shader backend for ATIFS, or with ARB pixel shaders enabled. In that case we'll just don't make use of it on ATI 9500+ cards until we have an ARB or GLSL replacement. I'll get back to you on that later tonight, need to think about this some more - way late for work right now... (thanks to you!) However, yes, I think there needs to be distinction between a standalone shader concept, and a pipeline concept, which is concerned with linking several multifunctional shaders together - your uber-shader-backend. Lack of distinction on this point is causing all this confusion. Ivan
Re: Alexandre Julliard : winex11: Fix bug report address
Groeschel, Volker wrote: The Patch points to wine-cvs. Shouldn't it point to wine-devel. It points to wine-devel. bye michael
Re: Version of Windows
Chris Teague wrote: This is probably trivial, but I'm having a tough time figuring out the current version of Windows that Wine is mimicking. I have a situation where I need to behave differently if the version is NT (0x0500) versus when it is XP (0x0600). I see the WINVER #define, but that doesn't seem right to me since this must be a runtime variable. Can someone point me at an example of how to tell what the current version of Windows is? Thanks, Errm, GetVersion()? If you're a developer for a Windows application it is a much better policy to check for features rather than checking the Windows version, since that feature may be implemented in a later service pack for that version of Windows. -- Rob Shearman
RE: Alexandre Julliard : winex11: Fix bug report address
Groeschel, Volker wrote: The Patch points to wine-cvs. Shouldn't it point to wine-devel. Stefaniuc, Michael wrote: It points to wine-devel. bye michael No, it doesn't. A HREF=http://www.winehq.org/mailman/listinfo/wine-cvs;wine-devel at winehq.org/A
Re: Alexandre Julliard : winex11: Fix bug report address
Groeschel, Volker wrote:
The Patch points to wine-cvs. Shouldn't it point to wine-devel.
Not in the version of the patch I'm looking at:
if (! is_tablet_cursor(target-name, device_type))
{
-WARN(Skipping device %d [name %s|type %s]; not apparently a
tablet cursor type device. If this is wrong, please report to
http://forums.winehq.org\n;,
+WARN(Skipping device %d [name %s|type %s]; not apparently a
tablet cursor type device. If this is wrong, please report it to [EMAIL
PROTECTED],
loop, devices[loop].name, device_type ? device_type :
);
XFree(device_type);
cursor_target --;
--
Rob Shearman
Re: Hardy Heron -- Pulseaudio interferes with non-gnome audio
Wine has two bugs filed for this also: http://bugs.winehq.org/show_bug.cgi?id=10495 http://bugs.winehq.org/show_bug.cgi?id=10910 I am worried that everyone (WINE, ALSA, Pulse, Ubuntu) is not on the same page. Will try cross-posting bug information. Part of the problem seems to be that the most-missed application is Skype, and some are trying to get away with blaming closed-source issues. Tom -- I should include the link to your patch, yes, so that other developers have access to it? Susan Dan -- What do you think? Good idea? -Original Message- From: Tomas Carnecky [EMAIL PROTECTED] Sent: Mar 18, 2008 5:14 PM To: Susan Cragin [EMAIL PROTECTED] Cc: wine-devel@winehq.org Subject: Re: Hardy Heron -- Pulseaudio interferes with non-gnome audio Susan Cragin wrote: The new default pulseaudio in Hardy screws up every program that isn't gnome, delivering terrible sound. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453 Applications that use ALSA should work fine with the alsa pulse plugin - should. Unfortunately the plugin has a few bugs, and the developers (of both pulseaudio and alsa) have been unresponsive in this matter. See - http://www.pulseaudio.org/ticket/198 - https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601 Question -- what does WINE do with pulseaudio? Some suggested to create a native PulseAudio wine driver. That would yield the best results as far as the performance and reliability goes. Unfortunately we'll be stuck with the alsa driver for some time to come, so I tried to do the best to make the alsa pulse plugin to work with wine. I had to patch both the wine alsa driver as well as the alsa pulse plugin and it worked fine for my taste. I submitted the patch to wine-patches: http://www.winehq.org/pipermail/wine-patches/2008-February/050561.html I don't know if the relevant alsa pulse plugin patch is publicly available, I haven't looked at that matter in a long time. Some of the needed patches are probably still in my local repositories. It makes no sense for me to work on this anymore until the developers respond to my questions. http://forum.skype.com/index.php?showtopic=112021 I heard that the skype developers are very interested in getting skype working with pulseaudio, even helped tisting some patches. I have gotten skype to work with pulseaudio, I think if you apply the second patch attached to alsa bug #2601 skype will work. I haven't looked at the code since because apparently nobody from the alsa team is interested in fixing the bug. tom
Re: Alexandre Julliard : winex11: Fix bug report address
Groeschel, Volker wrote: Groeschel, Volker wrote: The Patch points to wine-cvs. Shouldn't it point to wine-devel. Stefaniuc, Michael wrote: It points to wine-devel. No, it doesn't. A HREF=http://www.winehq.org/mailman/listinfo/wine-cvs;wine-devel at winehq.org/A At what are you looking at? The only email in wine-cvs with the Subject Alexandre Julliard : winex11: Fix bug report address is this commit http://source.winehq.org/git/wine.git/?a=commit;h=075df1b609d283c5d0b83a3e1b9bd48e53cb5b74 and the diff http://source.winehq.org/git/wine.git/?a=commitdiff;h=075df1b609d283c5d0b83a3e1b9bd48e53cb5b74;hp=2cab7ff2c7a11563436e014e2affc73987039bf6 shows only this: +WARN(Skipping device %d [name %s|type %s]; not apparently a tablet cursor type device. If this is wrong, please report it to [EMAIL PROTECTED], I cannot see any wine-cvs in there. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich
RE: Alexandre Julliard : winex11: Fix bug report address
I apologize I was not looking in the diff but in the wine-cvs message http://www.winehq.org/pipermail/wine-cvs/2008-March/041392.html There it points to wine-cvs. I don't know where this difference comes from.
RE:RE:: Alexandre Julliard : winex11: Fix bug report address
But wouldn't be http://www.winehq.org/mailman/listinfo/wine-devel better than [EMAIL PROTECTED] I just quote: Note: You should be subscribed to the lists before you post to them, otherwise your posting will be treated as possible spam by the mailing list software.
Re: Alexandre Julliard : winex11: Fix bug report address
Groeschel, Volker wrote: I apologize I was not looking in the diff but in the wine-cvs message http://www.winehq.org/pipermail/wine-cvs/2008-March/041392.html There it points to wine-cvs. I don't know where this difference comes from. The list archives obfuscate email addresses, adds links, etc. It looks like the website is translating [EMAIL PROTECTED] to wine-devel at winehq.org but adds a link to the wrong list archives. Jeremy, do you want a bugzilla entry against the website for that? bye michael
Re: Alexandre Julliard : winex11: Fix bug report address
Groeschel, Volker wrote: I apologize I was not looking in the diff but in the wine-cvs message http://www.winehq.org/pipermail/wine-cvs/2008-March/041392.html There it points to wine-cvs. I don't know where this difference comes from. It's pipermail obfuscating the email addresses. (Same is true if you hover over julliard at winehq.org). -- Cheers, Paul.
Re: : Alexandre Julliard : winex11: Fix bug report address
Groeschel, Volker wrote: But wouldn't be http://www.winehq.org/mailman/listinfo/wine-devel better than [EMAIL PROTECTED] I just quote: Note: You should be subscribed to the lists before you post to them, otherwise your posting will be treated as possible spam by the mailing list software. No, you cannot report it to http://www.winehq.org/mailman/listinfo/wine-devel as that are the read only archives. wine-devel has moderators and the emails from not subscribed people make it through though delayed. For a person reporting an one time problem that is ok to not be subscribed. bye michael
Re: Alexandre Julliard : winex11: Fix bug report address
IMO, a better place to file a bug would be with the mailman devs. My policy is to try to keep with un-patched packages from Debian stable. I can manually fix the archives though. Michael Stefaniuc wrote: Groeschel, Volker wrote: I apologize I was not looking in the diff but in the wine-cvs message http://www.winehq.org/pipermail/wine-cvs/2008-March/041392.html There it points to wine-cvs. I don't know where this difference comes from. The list archives obfuscate email addresses, adds links, etc. It looks like the website is translating [EMAIL PROTECTED] to wine-devel at winehq.org but adds a link to the wrong list archives. Jeremy, do you want a bugzilla entry against the website for that? bye michael
Re: Alexandre Julliard : winex11: Fix bug report address
Jeremy Newman wrote: IMO, a better place to file a bug would be with the mailman devs. My Huh? This looks to me like a configuration problem and not a mailman bug. I doubt that mailman knows on it's own to expand [EMAIL PROTECTED] to: A HREF=http://www.winehq.org/mailman/listinfo/wine-cvs;wine-devel at winehq.org/A bye michael policy is to try to keep with un-patched packages from Debian stable. I can manually fix the archives though. Michael Stefaniuc wrote: Groeschel, Volker wrote: I apologize I was not looking in the diff but in the wine-cvs message http://www.winehq.org/pipermail/wine-cvs/2008-March/041392.html There it points to wine-cvs. I don't know where this difference comes from. The list archives obfuscate email addresses, adds links, etc. It looks like the website is translating [EMAIL PROTECTED] to wine-devel at winehq.org but adds a link to the wrong list archives. Jeremy, do you want a bugzilla entry against the website for that? -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich
Re: winex11drv: Distinguish left and right keys for shift, ctrl and alt. (try 4)
Vitaliy Margolen wrote: This time with lots of tests that exposed number of other problems that were fixed. I could not separate this patch into separate pieces - they all linked together and fixing one problem meant fixing or breaking something else. This especially related to the tests that test everything together as a one black box. There are still few problems remain that could be exposed by tightening tests. --- Anything wrong with this patch? Vitaliy
The Linux/BSD DF kernel bug
So I've just read the following article: GCC 4.3.0 exposes a kernel bug http://lwn.net/SubscriberLink/272048/ecf14f359bcdcd15/ And my question is: could this be relevant to Wine? And I don't mean about GCC 4.3.0 but about MSVC. Here's the core of the issue: The problem revolves around the x86 direction flag (DF), which governs whether block memory operations operate forward through memory or backwards. GCC [...] 4.3.0, assumes that the direction flag has been cleared [...] at the entry of each function, as is specified by the ABI [...] Prior to 4.3, GCC would emit a cld (clear direction flag) opcode before doing inline string or memory operations. So any compiler that not clear the direction flag at the start of each function can cause kernel crashes when running on a buggy Linux or BSD kernel. So the questions are: Does anyone know if MSVC does a cld in the right places? What about other popular compilers used to compile Windows applications? Mac OS X being (loosely) based on the BSD kernels, does it have this issue too? -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY
Re: Hardy Heron -- Pulseaudio interferes with non-gnome audio
On Wed, Mar 19, 2008 at 6:03 AM, Susan Cragin [EMAIL PROTECTED] wrote: Wine has two bugs filed for this also: http://bugs.winehq.org/show_bug.cgi?id=10495 http://bugs.winehq.org/show_bug.cgi?id=10910 I am worried that everyone (WINE, ALSA, Pulse, Ubuntu) is not on the same page. Will try cross-posting bug information. Part of the problem seems to be that the most-missed application is Skype, and some are trying to get away with blaming closed-source issues. Tom -- I should include the link to your patch, yes, so that other developers have access to it? Susan Dan -- What do you think? Good idea? Could be that a wiki page is the best way to provide a central rallying point between two projects on an issue like this. Really, though, the answer is for Wine to have a native pulse audio driver. Maarten said he met somebody in IRC who is almost done with one. I do wish he would decloak... - Dan
Re: The Linux/BSD DF kernel bug
On Wed, 19 Mar 2008, Francois Gouget wrote: [...] So any compiler that not clear the direction flag at the start of each function can cause kernel crashes when running on a buggy Linux or BSD kernel. ^^ remove Sorry, it's just regular application crashes, not kernel crashes. It would still be interesting to know if that can impact Wine. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.
Re: Appdb nice urls: best way to test indexing of production data
On Wed, Mar 19, 2008 at 4:07 AM, John Klehm [EMAIL PROTECTED] wrote: On my spring break and had some free time so I thought I'd take a shot at implementing nice urls for the appdb that DanK had suggested a while back. I have decent bit of code in place that will interpret the url http://appdb.winehq.org/app/what-you-want-here and then feed the chunks into a hash table and return the match or matches however it goes. However indexing the large amount of data in the production appdb database could take sometime so I was wanting to test it before I sent my code in. I was wondering if there was a way to download the data from the appdb? --John Klehm I do this every week for the WWN to generate the status changes. $file = $year$mon$mday.tar.gz; `wget -O appdb/wine-appdb-$file ftp://ftp.winehq.org/pub/wine/wine-appdb-$file `; -- Zachary Goldberg Computer Science Engineering Electrical Captain of Penn Electric Race Team School of Engineering at the University of Pennsylvania
Re: Hardy Heron -- Pulseaudio interferes with non-gnome audio
Dan Kegel [EMAIL PROTECTED] writes: Could be that a wiki page is the best way to provide a central rallying point between two projects on an issue like this. Really, though, the answer is for Wine to have a native pulse audio driver. No, the right answer is to make the Alsa driver work right. We need to stop rushing out to write a new driver every time there's a problem with an existing one, all it leads to is more broken drivers. -- Alexandre Julliard [EMAIL PROTECTED]
Re: winex11drv: Distinguish left and right keys for shift, ctrl and alt. (try 4)
Vitaliy Margolen [EMAIL PROTECTED] writes: Anything wrong with this patch? The message patching inside peek_message looks very wrong, I have a hard time believing that this is really where this should happen. It most likely belongs somewhere like process_keyboard_message. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Appdb nice urls: best way to test indexing of production data
On Wed, Mar 19, 2008 at 10:16 AM, Zachary Goldberg [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 4:07 AM, John Klehm [EMAIL PROTECTED] wrote: I was wondering if there was a way to download the data from the appdb? --John Klehm I do this every week for the WWN to generate the status changes. $file = $year$mon$mday.tar.gz; `wget -O appdb/wine-appdb-$file ftp://ftp.winehq.org/pub/wine/wine-appdb-$file `; Thanks! =)
Re: wine.inf: Add ShowMenuDelay value
Anatoly Lyutin wrote: Changelog: Add ShowMenuDelay value Ops! Right changelog: Changelog: Add MenuShowDelay value. -- Best regards Anatoly Lyutin.
Re: Hardy Heron -- Pulseaudio interferes with non-gnome audio
But wait! There are more! Alsa people tell me they have one for Ekiga. Gnome has one, too. https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3825 http://bugzilla.gnome.org/show_bug.cgi?id=413552 I think a wiki page is a great idea, and I'll set one up later on http://ossri.harvee.org -Original Message- From: Susan Cragin [EMAIL PROTECTED] Sent: Mar 19, 2008 9:03 AM To: Wine Developers wine-devel@winehq.org Cc: Dan Kegel [EMAIL PROTECTED] Subject: Re: Hardy Heron -- Pulseaudio interferes with non-gnome audio Wine has two bugs filed for this also: http://bugs.winehq.org/show_bug.cgi?id=10495 http://bugs.winehq.org/show_bug.cgi?id=10910 I am worried that everyone (WINE, ALSA, Pulse, Ubuntu) is not on the same page. Will try cross-posting bug information. Part of the problem seems to be that the most-missed application is Skype, and some are trying to get away with blaming closed-source issues. Tom -- I should include the link to your patch, yes, so that other developers have access to it? Susan Dan -- What do you think? Good idea? -Original Message- From: Tomas Carnecky [EMAIL PROTECTED] Sent: Mar 18, 2008 5:14 PM To: Susan Cragin [EMAIL PROTECTED] Cc: wine-devel@winehq.org Subject: Re: Hardy Heron -- Pulseaudio interferes with non-gnome audio Susan Cragin wrote: The new default pulseaudio in Hardy screws up every program that isn't gnome, delivering terrible sound. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453 Applications that use ALSA should work fine with the alsa pulse plugin - should. Unfortunately the plugin has a few bugs, and the developers (of both pulseaudio and alsa) have been unresponsive in this matter. See - http://www.pulseaudio.org/ticket/198 - https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601 Question -- what does WINE do with pulseaudio? Some suggested to create a native PulseAudio wine driver. That would yield the best results as far as the performance and reliability goes. Unfortunately we'll be stuck with the alsa driver for some time to come, so I tried to do the best to make the alsa pulse plugin to work with wine. I had to patch both the wine alsa driver as well as the alsa pulse plugin and it worked fine for my taste. I submitted the patch to wine-patches: http://www.winehq.org/pipermail/wine-patches/2008-February/050561.html I don't know if the relevant alsa pulse plugin patch is publicly available, I haven't looked at that matter in a long time. Some of the needed patches are probably still in my local repositories. It makes no sense for me to work on this anymore until the developers respond to my questions. http://forum.skype.com/index.php?showtopic=112021 I heard that the skype developers are very interested in getting skype working with pulseaudio, even helped tisting some patches. I have gotten skype to work with pulseaudio, I think if you apply the second patch attached to alsa bug #2601 skype will work. I haven't looked at the code since because apparently nobody from the alsa team is interested in fixing the bug. tom
Re: SoC page insurrection! Idea details needed, please read.
I'm planning on applying for the FUSE project. I guess there are a lot of possibilities on this area. I have some experience on implementing FUSE filesystems with python and C. I'll post some ideas in a couple of days. On Tue, Mar 18, 2008 at 5:57 PM, Steven Edwards [EMAIL PROTECTED] wrote: On Tue, Mar 18, 2008 at 5:02 PM, Scott Ritchie [EMAIL PROTECTED] wrote: Unfortunately I am unable to sponsor my own idea (Case-insensitive FUSE), since I'm not too involved with Wine's C code. Could someone else please volunteer to mentor the project if it gets accepted by Google? If anyone takes this up, we might see about expanding it to include better support for FUSE iso mounted filesystems. Currently when you use fuse to mount an iso image, you have to manually configure a fake drive letter. It would be nice if we could query the loaded fuse module for a listing of mounted iso images and automatically create fake cdrom devices. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Appdb nice urls: best way to test indexing of production data
I can provide help with integrating the code with the appdb if you have any questions. The real question I've got, since I haven't done it before, is how to get the path the user specified, eg. appdb.winehq.org/vendor/adobe (or whatever), into a php script so we can redirect to the list of applications for the vendor 'adobe'. Chris On Wed, Mar 19, 2008 at 11:31 AM, John Klehm [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 10:16 AM, Zachary Goldberg [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 4:07 AM, John Klehm [EMAIL PROTECTED] wrote: I was wondering if there was a way to download the data from the appdb? --John Klehm I do this every week for the WWN to generate the status changes. $file = $year$mon$mday.tar.gz; `wget -O appdb/wine-appdb-$file ftp://ftp.winehq.org/pub/wine/wine-appdb-$file `; Thanks! =)
Re: Appdb nice urls: best way to test indexing of production data
On Wed, Mar 19, 2008 at 11:55 AM, Chris Morgan [EMAIL PROTECTED] wrote: I can provide help with integrating the code with the appdb if you have any questions. The real question I've got, since I haven't done it before, is how to get the path the user specified, eg. appdb.winehq.org/vendor/adobe (or whatever), into a php script so we can redirect to the list of applications for the vendor 'adobe'. Chris Is $_SERVER[REQUEST_URI]; what your looking for? On Wed, Mar 19, 2008 at 11:31 AM, John Klehm [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 10:16 AM, Zachary Goldberg [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 4:07 AM, John Klehm [EMAIL PROTECTED] wrote: I was wondering if there was a way to download the data from the appdb? --John Klehm I do this every week for the WWN to generate the status changes. $file = $year$mon$mday.tar.gz; `wget -O appdb/wine-appdb-$file ftp://ftp.winehq.org/pub/wine/wine-appdb-$file `; Thanks! =) -- Zachary Goldberg Computer Science Engineering Electrical Captain of Penn Electric Race Team School of Engineering at the University of Pennsylvania
Re: Appdb nice urls: best way to test indexing of production data
Yep, I'm aware of that server parameter. So the idea would be to add code to appdb.winehq.org/index.php and look at REQUEST_URI for a particular format and redirect based on that? That sounds feasible. Chris On Wed, Mar 19, 2008 at 12:01 PM, Zachary Goldberg [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 11:55 AM, Chris Morgan [EMAIL PROTECTED] wrote: I can provide help with integrating the code with the appdb if you have any questions. The real question I've got, since I haven't done it before, is how to get the path the user specified, eg. appdb.winehq.org/vendor/adobe (or whatever), into a php script so we can redirect to the list of applications for the vendor 'adobe'. Chris Is $_SERVER[REQUEST_URI]; what your looking for? On Wed, Mar 19, 2008 at 11:31 AM, John Klehm [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 10:16 AM, Zachary Goldberg [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 4:07 AM, John Klehm [EMAIL PROTECTED] wrote: I was wondering if there was a way to download the data from the appdb? --John Klehm I do this every week for the WWN to generate the status changes. $file = $year$mon$mday.tar.gz; `wget -O appdb/wine-appdb-$file ftp://ftp.winehq.org/pub/wine/wine-appdb-$file `; Thanks! =) -- Zachary Goldberg Computer Science Engineering Electrical Captain of Penn Electric Race Team School of Engineering at the University of Pennsylvania
Re: Appdb nice urls: best way to test indexing of production data
On Wed, Mar 19, 2008 at 10:55 AM, Chris Morgan [EMAIL PROTECTED] wrote: I can provide help with integrating the code with the appdb if you have any questions. The real question I've got, since I haven't done it before, is how to get the path the user specified, eg. appdb.winehq.org/vendor/adobe (or whatever), into a php script so we can redirect to the list of applications for the vendor 'adobe'. Chris Well that did take a bit for me to work out as well here is what is working for me on my apache 2.2.8 You have to have allowoveride Options in the parent conf files and then filename: htdocs/appdb/.htaccess RewriteEngine On Options FollowSymLinks # need this as well as RewriteEngine On to acutally get it going RewriteBase /appdb/ RewriteRule ^app/(.*)$ matchAppByName.php?AppName=$1 This will let you have: $1 is matched by the part of the url that is not matched by http://hostname.com/appb/app/ e.g. appdb/app/adobe-photoshop-cs2 Results in matchAppByName.php?AppName=adobe-photoshop-cs2 I'm not adverse to help with appdb whatever gets it solved more quickly =) Be careful when choosing your rewritebase as its more important than you'd think =P Hope this helps, John
Re: Appdb nice urls: best way to test indexing of production data
On Wed, Mar 19, 2008 at 12:12 PM, John Klehm [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 10:55 AM, Chris Morgan [EMAIL PROTECTED] wrote: I can provide help with integrating the code with the appdb if you have any questions. The real question I've got, since I haven't done it before, is how to get the path the user specified, eg. appdb.winehq.org/vendor/adobe (or whatever), into a php script so we can redirect to the list of applications for the vendor 'adobe'. Chris Well that did take a bit for me to work out as well here is what is working for me on my apache 2.2.8 You have to have allowoveride Options in the parent conf files and then filename: htdocs/appdb/.htaccess RewriteEngine On Options FollowSymLinks # need this as well as RewriteEngine On to acutally get it going RewriteBase /appdb/ RewriteRule ^app/(.*)$ matchAppByName.php?AppName=$1 This will let you have: $1 is matched by the part of the url that is not matched by http://hostname.com/appb/app/ e.g. appdb/app/adobe-photoshop-cs2 Results in matchAppByName.php?AppName=adobe-photoshop-cs2 I'm not adverse to help with appdb whatever gets it solved more quickly =) Be careful when choosing your rewritebase as its more important than you'd think =P Hope this helps, John Right, this makes more sense. Checking REQUEST_URI in index.php won't work because the path given won't match an existing page so you'll get the 404 page instead. Chris
Re: Appdb nice urls: best way to test indexing of production data
On Wed, Mar 19, 2008 at 11:15 AM, Chris Morgan [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 12:12 PM, John Klehm [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 10:55 AM, Chris Morgan [EMAIL PROTECTED] wrote: I can provide help with integrating the code with the appdb if you have any questions. The real question I've got, since I haven't done it before, is how to get the path the user specified, eg. appdb.winehq.org/vendor/adobe (or whatever), into a php script so we can redirect to the list of applications for the vendor 'adobe'. Chris If it is desirable for winehq.org/appdb/show/verb/term (allows for appdb.winehq.org/show/vender appdb.winehq.org/show/app winehq.org/show/catagory) then this works for me: RewriteEngine On Options FollowSymLinks RewriteBase /appdb/ #RewriteRule ^app/(.*)$ matchAppByName.php?AppName=$1 RewriteRule ^show/([a-zA-Z]+)/(.*)$ matchByVerbAndTerm.php?verb=$1term=$2 E.g appdb.winehq.org/show/vendor/adobe = matchByVerbAndTerm.php?verb=vendorterm=adobe appdb.winehq.org/show/app/adobe-photoshop-cs2 = matchByVerbAndTerm.php?verb=appterm=adobe-photoshop-cs2 Regards, John
Re: Version of Windows
On 19/03/2008, Chris Teague [EMAIL PROTECTED] wrote: This is probably trivial, but I'm having a tough time figuring out the current version of Windows that Wine is mimicking. I have a situation where I need to behave differently if the version is NT (0x0500) versus when it is XP (0x0600). I see the WINVER #define, but that doesn't seem right to me since this must be a runtime variable. Can someone point me at an example of how to tell what the current version of Windows is? Thanks, Wine does not use the WINVER, or other associated version defines when building a project - it automatically uses the latest Windows version (although the API exposed may be incomplete due to missing functions). Programatically, you can use GetVersionEx [http://msdn2.microsoft.com/en-us/library/ms724451.aspx] to determine the version of Windows at runtime in your program, although Microsoft recommend using VerifyVersionInfo (see [http://msdn2.microsoft.com/en-us/library/ms725491(VS.85).aspx] for an example of its usage). To change the version in Wine you can use winecfg (the 'Windows Version' property on the 'Applications' tab). HTH, - Reece
Tests marked as todo are not displayed on the web results.
Hi, If you look at the output for a set of test results (e.g. http://test.winehq.org/data/200803181000/), it indicates whether particular tests need work on Wine. This is a great addition and works very well... however, if you navigate to the information about that test (e.g. http://test.winehq.org/data/200803181000/wine_xp_0.9.57-274-g5e463ac/gdiplus:graphicspath.txt), you don't see what tests are marked as todo. For example, using the above, it results in: gdiplus:graphicspath start dlls/gdiplus/tests/graphicspath.c 1.13 graphicspath: 198 tests executed (5 marked as todo, 0 failures), 0 skipped. gdiplus:graphicspath done (0) ...so does not tell me which of the 5 tests are todo and which are ok. I haven't checked to see if this is also an issue with the `make test` output. - Reece
[RFC] Improving the summary results on test.winehq.org
Hi, Looking at the results from a test run (e.g. http://test.winehq.org/data/200803181000/), it would be nice to have: 1. A summary of a dlls overall results (i.e. the summation of all its unit test results), preferably before the individual tests, but could live with them at the bottom. 2. A summary of the entire test results (i.e. the summation of all unit test results for all dlls). This would be best at the top where it is easily visible. 3. Possibly display the number of tests run in a given pass (e.g. 0/12 or 1+3/27). This is to give an idea of how many tests have been run easily (especially for the dll and overall summaries). The idea is to get a quick idea of the health of the test results for each operating system and dll. - Reece
Alexandre Julliard : winex11: Fix bug report address
The Patch points to wine-cvs. Shouldn't it point to wine-devel.
Wine1.0 and LGPLv3?
Just to resurrect this topic, as last time, of the responses to my email, two were positive (and the other just pointed out that I'd mistaken the Samba licensing for LGPL instead of GPL) but nothing else happened after that. Seeing as Wine is officially going to be having a 1.0 in the not too distant future, this would seem like the ideal time to introduce a license change ( e.g. Samba went to GPLv3 along with a version jump). I remember the WineConf 2007 presentation PDF from Alexandre mentioned it as a post-1.0 possibility - it would seem to me that 1.0 would in fact be the ideal time to make such a change - being able to say anything pre-1.0 is LGPLv2+ and anything 1.0+ is LGPLv3+ is quite nice and is easy to understand. LGPLv3 has a lot of benefits over the previous version (see my previous email below), some of which are particularly pertinent given Microsoft's attitude towards it (e.g. in the Novell agreement that led to a third draft of the GPL, Wine would seem to be excluded from the patent protection agreement - see http://tinyurl.com/25at6e). It would be great to have a decision made on this - personally, I can't see any reason why LGPLv3 would be detrimental to WINE (for example, I can't see any reason CodeWeavers would dislike any of the new provisions, which mostly target troll companies), and numerous reasons why it would be a good thing. Ian Macfarlane ps: Here's the email I sent about this some time back, but with the bits about Samba and Solaris snipped out: On 7/13/07, Ian Macfarlane [EMAIL PROTECTED] wrote: I've been meaning to ask about this since (L)GPL3 was released. The version 3 of the (L)GPL license has numerous benefits: - It's much more legally sound in the rest of the world (IMO one of the most important factors about the new license) - numerous reasons for this e.g. referencing WIPO rather than US laws. - It has an explicit patent agreement (really an extension of the above - (L)GPLv2 has an implicit patent agreement, but this is only valid in the US) - this means that people who contribute to and/or distribute WINE cannot sue WINE (or WINE users) for patent infringement. - It is compatible with the Apache 2.0 license, meaning that there is an even bigger pool of source code to draw from. - It helps ensure that companies cannot prevent people from modifying the source code by providing them explicit legal rights to change the code in these circumstances, and requiring information to allow users to change it. - For LGPL only, It makes 100% sure that GPL+linking exception and LGPL can be combined legally in all jurisdictions by merging them (which is essentially the only real difference, barring slightly different wording in the v2.1 of LGPL vs v2. of GPL) - It prevents patent agreements where only some people are protected. - It provides a mechanism for first-time accidental violations to be 'cured' more easily - ... and lots of other minor changes to improve the validity of the legal status of the license. snip So as you can see, (L)GPL version 3 has a lot of benefits. It also has broad support (excluding Linus of course, who I must point out objects only to a single clause in the license that can be resolved by adding an extra permission, as GPLv3 permits), including strong corporate backing (e.g. IBM, Red Hat, MySQL, Sun, even Novell). As one of the projects that Microsoft would most like to destroy, the added protections in this updated version of the license would seem even more valuable. Kind regards, Ian Macfarlane ps: As a last note to Damjan - all GPL versions have been considered both radical and political when they were released. In retrospect, the protections that they provided have been considered invaluable.
Re: [RFC] Improving the summary results on test.winehq.org
On Wed, Mar 19, 2008 at 3:47 AM, Reece Dunn [EMAIL PROTECTED] wrote: 3. Possibly display the number of tests run in a given pass (e.g. 0/12 or 1+3/27). This is to give an idea of how many tests have been run easily (especially for the dll and overall summaries). The idea is to get a quick idea of the health of the test results for each operating system and dll. You mouse over any of the results and it will give you the number of tests. --John
Re: [RFC] Improving the summary results on test.winehq.org
Reece Dunn wrote: Hi, Looking at the results from a test run (e.g. http://test.winehq.org/data/200803181000/), it would be nice to have: 1. A summary of a dlls overall results (i.e. the summation of all its unit test results), preferably before the individual tests, but could live with them at the bottom. 2. A summary of the entire test results (i.e. the summation of all unit test results for all dlls). This would be best at the top where it is easily visible. 3. Possibly display the number of tests run in a given pass (e.g. 0/12 or 1+3/27). This is to give an idea of how many tests have been run easily (especially for the dll and overall summaries). The idea is to get a quick idea of the health of the test results for each operating system and dll. - Reece I think Francois already put a lot of these on his todo list: http://www.winehq.org/pipermail/wine-devel/2008-March/063641.html Cheers, Paul.
Re: Wine1.0 and LGPLv3?
Ian Macfarlane wrote: Just to resurrect this topic, as last time, of the responses to my email, two were positive (and the other just pointed out that I'd mistaken the Samba licensing for LGPL instead of GPL) but nothing else happened after that. Seeing as Wine is officially going to be having a 1.0 in the not too distant future, this would seem like the ideal time to introduce a Quite the contrary, this is the worst time to introduce a license change as it drags developer time into unnecessary license discussion. license change (e.g. Samba went to GPLv3 along with a version jump). I remember the WineConf 2007 presentation PDF from Alexandre mentioned it Right, we discussed the issue at the Wine conference and there was 1 vote to move to LGPL v3. The rest didn't care and prefer to stay with the existing LGPL v2 until there is a compelling reason to move to v3. as a post-1.0 possibility - it would seem to me that 1.0 would in fact be the ideal time to make such a change - being able to say anything pre-1.0 is LGPLv2+ and anything 1.0+ is LGPLv3+ is quite nice and is easy to understand. Wine 1.0 should have been the X11 license ... ;) bye michael LGPLv3 has a lot of benefits over the previous version (see my previous email below), some of which are particularly pertinent given Microsoft's attitude towards it (e.g. in the Novell agreement that led to a third draft of the GPL, Wine would seem to be excluded from the patent protection agreement - see http://tinyurl.com/25at6e). It would be great to have a decision made on this - personally, I can't see any reason why LGPLv3 would be detrimental to WINE (for example, I can't see any reason CodeWeavers would dislike any of the new provisions, which mostly target troll companies), and numerous reasons why it would be a good thing. Ian Macfarlane ps: Here's the email I sent about this some time back, but with the bits about Samba and Solaris snipped out: On 7/13/07, *Ian Macfarlane* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I've been meaning to ask about this since (L)GPL3 was released. The version 3 of the (L)GPL license has numerous benefits: - It's much more legally sound in the rest of the world (IMO one of the most important factors about the new license) - numerous reasons for this e.g. referencing WIPO rather than US laws. - It has an explicit patent agreement (really an extension of the above - (L)GPLv2 has an implicit patent agreement, but this is only valid in the US) - this means that people who contribute to and/or distribute WINE cannot sue WINE (or WINE users) for patent infringement. - It is compatible with the Apache 2.0 license, meaning that there is an even bigger pool of source code to draw from. - It helps ensure that companies cannot prevent people from modifying the source code by providing them explicit legal rights to change the code in these circumstances, and requiring information to allow users to change it. - For LGPL only, It makes 100% sure that GPL+linking exception and LGPL can be combined legally in all jurisdictions by merging them (which is essentially the only real difference, barring slightly different wording in the v2.1 of LGPL vs v2. of GPL) - It prevents patent agreements where only some people are protected. - It provides a mechanism for first-time accidental violations to be 'cured' more easily - ... and lots of other minor changes to improve the validity of the legal status of the license. snip So as you can see, (L)GPL version 3 has a lot of benefits. It also has broad support (excluding Linus of course, who I must point out objects only to a single clause in the license that can be resolved by adding an extra permission, as GPLv3 permits), including strong corporate backing (e.g. IBM, Red Hat, MySQL, Sun, even Novell). As one of the projects that Microsoft would most like to destroy, the added protections in this updated version of the license would seem even more valuable. Kind regards, Ian Macfarlane ps: As a last note to Damjan - all GPL versions have been considered both radical and political when they were released. In retrospect, the protections that they provided have been considered invaluable.
Re: winefix - interesting wrapper for wine
On Mon, Oct 22, 2007 at 12:56 PM, Scott Ritchie [EMAIL PROTECTED] wrote: Dan Kegel wrote: Tom W. found and publicized a script called winefix by an ubuntu forums user named deadlydeathcone: http://digg.com/linux_unix/Winefix_improved_desktop_integration_for_Wine http://wine-review.blogspot.com/2007/10/winefix-improved-desktop-integration.html http://ubuntuforums.org/showthread.php?s=6e904c1df87d3fd1698ab5d7bbdbf664t=533257 It's got a bunch of interesting stuff. I wonder if we could get him to join wine-devel and start contributing to wine itself... Yeah, it's very strange that he just came out of nowhere. I found out about his script through Digg. I'm gonna spend some time this week dissecting it and seeing what we can put right into the Wine package. Did you ever get around to this? This came up again today in https://answers.launchpad.net/ubuntu/+source/wine/+question/26260 - Dan
Summer of code and bidi
Hi Shachar, I've removed the bi-directional entry from summer of code. I don't think it is a good project because it involves a lot of changes in pretty much all wine user controls. The only way to do this would be by using the pango library to do the laying out of text, but I'm not even sure whether that is a good summer of code idea, since it would need someone already very experienced with the plumbing of wine. Maarten.
Splitting wine wiki FAQ (was: Wine wiki cleanup)
On Wed, Mar 19, 2008 at 10:40 AM, Jim [EMAIL PROTECTED] wrote: Should we do this for the FAQ as well? I mean: Make a separate developer DeveloperFaq (WikiName) Move developer related topics from FAQ to DeveloperFAQ Add question to FAQ Where is the Developer FAQ? to FAQ. -OR- Possibly not as a FAQ question but a very visible Note at the top. Developers see DeveloperFaq A shorter FAQ may look less intimidating to lazy readers thus encouraging more readers and possibly fewer noob questions on the list. Sounds good to me! I'm cc'ing wine-devel; if nobody objects by Friday, go ahead and do it. - Dan
Re: Summer of code and bidi
Maarten Lankhorst wrote: Hi Shachar, I've removed the bi-directional entry from summer of code. I don't think it is a good project because it involves a lot of changes in pretty much all wine user controls. Actually, I don't think any touching of the actual user controls is involved at all. I think the first bullet (which can be all we want for this year) only really involves the ExtTextOut function, as well as the Uniscribe functions. No user controls are touched at all. The only way to do this would be by using the pango library to do the laying out of text, I was about to say that the code is practically already there, but I really think you should know that, being how it was you who put it there :-). I really think that if we came this far, we had better split the Unicode algorithm into the components it requires and put it into Uniscribe. I don't think we need any reliance on external libraries (pango, fribidi, or any other) for that. but I'm not even sure whether that is a good summer of code idea, since it would need someone already very experienced with the plumbing of wine. It would require someone to learn the BiDi algorithm and the Uniscribe interface, but the reason I offered to mentor it was precisely so that the student not have to follow the entire Wine structure. I really don't believe this task is heavier than some of the Direct3D stuff on that page. Maarten. Just MHO Shachar
Re: Summer of code and bidi
Hello, 2008/3/19, Shachar Shemesh [EMAIL PROTECTED]: Maarten Lankhorst wrote: Hi Shachar, I've removed the bi-directional entry from summer of code. I don't think it is a good project because it involves a lot of changes in pretty much all wine user controls. Actually, I don't think any touching of the actual user controls is involved at all. I think the first bullet (which can be all we want for this year) only really involves the ExtTextOut function, as well as the Uniscribe functions. No user controls are touched at all. I already did this work, exttextout relies on the reference bidi implementation now. Took about 3 days to adapt the reference implementation to wine. (dlls/gdi32/bidi.c) The only way to do this would be by using the pango library to do the laying out of text, I was about to say that the code is practically already there, but I really think you should know that, being how it was you who put it there :-). I really think that if we came this far, we had better split the Unicode algorithm into the components it requires and put it into Uniscribe. I don't think we need any reliance on external libraries (pango, fribidi, or any other) for that. There are all kinds of rules that tell how it work, a real rendering engine is complicated to write, and since there are already a few working, tried and tested engines out there we don't want to write our own. but I'm not even sure whether that is a good summer of code idea, since it would need someone already very experienced with the plumbing of wine. It would require someone to learn the BiDi algorithm and the Uniscribe interface, but the reason I offered to mentor it was precisely so that the student not have to follow the entire Wine structure. I really don't believe this task is heavier than some of the Direct3D stuff on that page. As I said, bidi is already implemented. A real uniscribe algorythm is something we want to depend on as external library, because a proper engine would be huge and impossible to maintain/debug. -Maarten.
Google Summer of Code Test Suite project
I would like to work on the Regression Suite project, but I'm not quite sure of the scope. Would I be choosing a good 30 or 40 applications that run well on wine, using wpkg to install them, and then test for failures? Because that would seem as though I am only doing installer testing, instead of actual application testing. I would also like to do some sort of automated regression testing for actual features you can easily test, if that would be possible. Corey
Re: Google Summer of Code Test Suite project
On Wed, Mar 19, 2008 at 3:01 PM, Corey McClymonds [EMAIL PROTECTED] wrote: I would like to work on the Regression Suite project, but I'm not quite sure of the scope. Would I be choosing a good 30 or 40 applications that run well on wine, using wpkg to install them, and then test for failures? Because that would seem as though I am only doing installer testing, instead of actual application testing. I would also like to do some sort of automated regression testing for actual features you can easily test, if that would be possible. Corey Let's just say you're going to write an installer tester. How do you define a failure? If you're doing silent installers, do you just look at the return value from the installer? If you installed app foo, and the installer created file bar on Windows with a checksum of qux, but not in Wine, does that count as a failure? How about if a registry key is missing on Wine?
Re: Google Summer of Code Test Suite project
On 3/19/08, Lei Zhang [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 3:01 PM, Corey McClymonds [EMAIL PROTECTED] wrote: I would like to work on the Regression Suite project, but I'm not quite sure of the scope. Would I be choosing a good 30 or 40 applications that run well on wine, using wpkg to install them, and then test for failures? Because that would seem as though I am only doing installer testing, instead of actual application testing. I would also like to do some sort of automated regression testing for actual features you can easily test, if that would be possible. Corey Let's just say you're going to write an installer tester. How do you define a failure? If you're doing silent installers, do you just look at the return value from the installer? If you installed app foo, and the installer created file bar on Windows with a checksum of qux, but not in Wine, does that count as a failure? How about if a registry key is missing on Wine? It depends if any functionality is lost. You could argue that if anything is different, then wine isn't implementing something correctly, but I would be fine with it completing and working as intended. I would probably do checks on all 3 things you talked about, and likely anything else that could be easily checked for by a computer.
Re: Google Summer of Code Test Suite project
On Wed, Mar 19, 2008 at 6:07 PM, Corey McClymonds [EMAIL PROTECTED] wrote: On 3/19/08, Lei Zhang [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 3:01 PM, Corey McClymonds [EMAIL PROTECTED] wrote: I would like to work on the Regression Suite project, but I'm not quite sure of the scope. Would I be choosing a good 30 or 40 applications that run well on wine, using wpkg to install them, and then test for failures? Because that would seem as though I am only doing installer testing, instead of actual application testing. I would also like to do some sort of automated regression testing for actual features you can easily test, if that would be possible. Corey Let's just say you're going to write an installer tester. How do you define a failure? If you're doing silent installers, do you just look at the return value from the installer? If you installed app foo, and the installer created file bar on Windows with a checksum of qux, but not in Wine, does that count as a failure? How about if a registry key is missing on Wine? It depends if any functionality is lost. You could argue that if anything is different, then wine isn't implementing something correctly, but I would be fine with it completing and working as intended. I would probably do checks on all 3 things you talked about, and likely anything else that could be easily checked for by a computer. Using a program like AutoHotkey to install a program and test its features would be a better route IMHO.
Re: winex11drv: Distinguish left and right keys for shift, ctrl and alt. (try 4)
Alexandre Julliard wrote: Vitaliy Margolen [EMAIL PROTECTED] writes: Anything wrong with this patch? The message patching inside peek_message looks very wrong, I have a hard time believing that this is really where this should happen. It most likely belongs somewhere like process_keyboard_message. Thank you. I wasn't sure where it should go myself. The process_keyboard_message is the last in the chain place it can go in. Some simple tests showed that journal hook gets the normal VK_SHIFT not left/right shift.
re: Google Summer of Code Test Suite project
On Wed, Mar 19, 2008 at 3:01 PM, Corey McClymonds galeru at gmail.com wrote: I would like to work on the Regression Suite project, but I'm not quite sure of the scope. Would I be choosing a good 30 or 40 applications that run well on wine, using wpkg to install them, and then test for failures? Because that would seem as though I am only doing installer testing, instead of actual application testing. That would be fine for starters. I would also like to do some sort of automated regression testing for actual features you can easily test, if that would be possible. That would be icing on the cake. Application testing is insanely difficult. Even installer testing is difficult to actually deliver. I would prefer that you aim to get a simple run-this-script-and-it-tests-N-installers script working and in the wine developers' hot little hands ASAP before you get fancy and try to make it test more than just installs. Because essentially all efforts to do that in the past have failed. Make sense? FWIW, here's my first try at it from long ago. It's a minimal little script that just tests one app's installer. I would prefer you start with something this simple. http://www.winehq.org/pipermail/wine-devel/2006-July/049913.html Also, maybe you could make some use of Lei's yawt script, http://code.google.com/p/yawt/ It's kind of overkill, but it takes care of comparing registry keys and files created by the installer. - Dan
Re: wine-devel Digest, Vol 32, Issue 75
From: Dan Kegel [EMAIL PROTECTED] To: Wine Developers List wine-devel@winehq.org Date: Wed, 19 Mar 2008 16:31:03 -0700 Subject: re: Google Summer of Code Test Suite project On Wed, Mar 19, 2008 at 3:01 PM, Corey McClymonds galeru at gmail.com wrote: I would like to work on the Regression Suite project, but I'm not quite sure of the scope. Would I be choosing a good 30 or 40 applications that run well on wine, using wpkg to install them, and then test for failures? Because that would seem as though I am only doing installer testing, instead of actual application testing. That would be fine for starters. I would also like to do some sort of automated regression testing for actual features you can easily test, if that would be possible. That would be icing on the cake. Application testing is insanely difficult. Even installer testing is difficult to actually deliver. I would prefer that you aim to get a simple run-this-script-and-it-tests-N-installers script working and in the wine developers' hot little hands ASAP before you get fancy and try to make it test more than just installs. Because essentially all efforts to do that in the past have failed. Make sense? FWIW, here's my first try at it from long ago. It's a minimal little script that just tests one app's installer. I would prefer you start with something this simple. http://www.winehq.org/pipermail/wine-devel/2006-July/049913.html Also, maybe you could make some use of Lei's yawt script, http://code.google.com/p/yawt/ It's kind of overkill, but it takes care of comparing registry keys and files created by the installer. - Dan Yeah, I was unaware of how difficult it would be, although now that I put on my programmers cap, I can see how it would be really difficult to do so. In that case, I would still like to do a regression test for installations to help out the wine project.
Re: wineboot: Add the Romanian translation.
On Wed, 2008-03-19 at 23:57 +0100, Michael Stefaniuc wrote: +LTEXT O îeșire sau oprire simulată este în curs dar acest proces nu răspunde., This should be O ieșire not O îeșire, no? -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: Proposed EM_Fontrange Patch
Eric Pouech wrote: James McKenzie a écrit : All: I would like to see the problems with EM_Fontrange be fixed. The attached patch is for comment/review and I would like SPECIFIC guidance on how to implement this patch as it relates to a Wine 1.0 bug (bug/issue 6254) and fixes the problem specified there. The conformance tests are already in tests/editor.c and all they involve is removing some todo_wine blocks related to this issue. The entire patch will do this. Sorry that the patch is in UNIX diff format, I could not get git to do what I wanted. The actual patch will be git format and use the daily git. I think that a couple of things should be improved in the patch: - there are 3 hDC stored in the context, while only 2 are of use (rendering and measure) Actually, there are four, but it appears the one that is not needed is fr.hdcTarget. Does it appear to be not used in normal usage of this feature? If so, then the portion of code that was written for this use of this handle would not be needed. That would remove a few lines of code. - there is some interdependency with the EM_SETTARGETDEVICE message implementation, that should be looked at I will look at this when I can. My time has become very limited as of late. That may be changing in a few months, however. - patch is likely a bit too big and should be sliced before inclusion This is the most difficult part. Where should I make the 'slice' at? With only the part that implements the called code first and then the calling code? That would make the most sense to me. James McKenzie
Re: The Linux/BSD DF kernel bug
Am Mittwoch, 19. März 2008 16:06:34 schrieb Francois Gouget: On Wed, 19 Mar 2008, Francois Gouget wrote: [...] So any compiler that not clear the direction flag at the start of each function can cause kernel crashes when running on a buggy Linux or BSD kernel. ^^ remove Sorry, it's just regular application crashes, not kernel crashes. It would still be interesting to know if that can impact Wine. Wouldn't the WINAPI function declaration sort this sort of issues out, if GCC implements it correctly?
Re: [4/22] WineD3D: A shader backend descriptor for the ati fragment shader backend
Stefan Dösinger wrote: I'll get back to you on that later tonight, need to think about this some more - way late for work right now... (thanks to you!) However, yes, I think there needs to be distinction between a standalone shader concept, and a pipeline concept, which is concerned with linking several multifunctional shaders together - your uber-shader-backend. Lack of distinction on this point is causing all this confusion. Cool, I'm looking forward to suggestions. It looks to me as if shader_backend is being overloaded for many different purposes that are not really related to each other. Typical object structure is to group related data an functions in one place, but what's happening in shader_backend is that it has no data of its own, and it's a vtable routing between different GL extensions with the data being scattered across multiple different places. - some functions are related to management of a single shader and its resources [ state is BaseShader ] - other code manages the link between vertex and fragment shader [ glsl programs stored in the Device ] - other code manages a group of 2 shaders to handle some fixed function purpose [ _blt, using Device-shader_priv_data ] - now you want to replace the main fixed function fragment processing [ state is in the state table ] I think it would be worthwhile to review all of this, and see if this organization makes sense. Why aren't the functions grouped together with the data ? Why is some of the data in the device object ? Why are functions managing different data containers in the same vtable ? I am no longer familiar with the details, but there's way too many things called shader by now - d3d shader, gl shader, this made up shader_backend that actually does fixed function stuff and represents neither. Maybe it makes sense to create new object types - like a 'pipeline', containing a 'vertex processor', 'fragment processor' (not necessarily implemented via shaders). Maybe each of these should have a fixed and dynamic facing d3d API, but attach or detach to the pipeline in the same way. Maybe they can have different gl extensions backend implementing each. Meanwhile, I've separated the ATIFS implementation and the shader backend changes in my patches. The result is attached. The patches named 1, 2, ... will be merged together to avoid regressions due to partial implementations, and they need some reordering. I've hacked that together during my train ride, so I've no idea if it really works. Will take a look...
Questions regarding Summer of Code( and Dplay)
Hi, I am student at IIT Kanpur[1]. I have quite good knowledge about C and have been tracking development of Wine over a period of 6 months or so. I have good knowledge about C(and using it theoretically to implement stacks, efficient structures and so on). However, I have little real life experience about programming a project. I have little experience about Window's API. I was looking to participate in Wine development this summer. On SoC page, the idea of Dplay was bought up. I am interested in trying hands on that. Can anyone suggest what would be a good starting point? Thanks, Anurag Mishra. [1] http://www.iitk.ac.in
Re: The Linux/BSD DF kernel bug
Francois Gouget skrev: The problem revolves around the x86 direction flag (DF), which governs whether block memory operations operate forward through memory or backwards. GCC [...] 4.3.0, assumes that the direction flag has been cleared [...] at the entry of each function, as is specified by the ABI [...] Prior to 4.3, GCC would emit a cld (clear direction flag) opcode before doing inline string or memory operations. So any compiler that not clear the direction flag at the start of each function can cause kernel crashes when running on a buggy Linux or BSD kernel. No, it doesn't say that. The kernel is unaffected. The problem is only with user-mode signal handlers; if DF is set when a signal occurs, the signal handler may get confused. Does anyone know if MSVC does a cld in the right places? Maybe. But it hardly matters. Only GCC-generated code is affected. The problem might then show up in Wine signal/exception handling. Things like, say, copying the CONTEXT structures around, for example. In Wine, you can probably easily manually clear the flag on Wine signal handler entry (init_handler), if you're worried.
Questions regarding Summer of Code( and Dplay)
Hello Anurag, 2008/3/19, Anurag Mishra [EMAIL PROTECTED]: I am student at IIT Kanpur[1]. I have quite good knowledge about C and have been tracking development of Wine over a period of 6 months or so. I have good knowledge about C(and using it theoretically to implement stacks, efficient structures and so on). However, I have little real life experience about programming a project. I have little experience about Window's API. I was looking to participate in Wine development this summer. On SoC page, the idea of Dplay was bought up. I am interested in trying hands on that. Can anyone suggest what would be a good starting point? There are only a few important things to directplay as far as I know. The first one is find a game that runs in wine and uses it, and works reasonably well single player but not at all multiplayer or online because of the missing things (fixmes on dplay in console). After you played the game a little bit, think of a plan on how you want to tackle this problem. Have you managed to compile a git version of wine yet? Cheers, Maarten.
