msi/iTunes and questions
Hi,
just for fun I've tried to install iTunes 7 on a fresh .wine. According
to the AppDB this fails (one should first install QuickTime).
While going through some traces I saw something the apparently needs
this fix, but I'm no MSI-guy:
diff --git a/dlls/msi/custom.c b/dlls/msi/custom.c
index dad67a2..7b862fe 100644
--- a/dlls/msi/custom.c
+++ b/dlls/msi/custom.c
@@ -703,8 +703,8 @@ static UINT HANDLE_CustomType19(MSIPACKA
static const WCHAR query[] = {
'S','E','L','E','C','T',' ','`','M','e','s','s','a','g','e','`',' ',
'F','R','O','M',' ','`','E','r','r','o','r','`',' ',
- 'W','H','E','R','E',' ','`','E','r','r','o','r','`',' ','=',' ',
- '%','s',0
+ 'W','H','E','R','E',' ','`','E','r','r','o','r','`',' ','=',' ','\'',
+ '%','s','\'',0
};
MSIRECORD *row = 0;
LPWSTR deformated = NULL;
The single-quotes should be needed as the SQL statement in the trace showed:
trace:msi:MSI_DatabaseOpenViewW LSELECT `Message` FROM `Error` WHERE
`Error` = The installlation of QuickTime did not complete successfully.
iTunes requires QuickTime. 0x6669a498
and a bit further:
err:msidb:WHERE_VerifyCondition Couldn't find column LThe
This is just one of many issues with this installation.
Does the fix look OK? Should this be sent? If it has to be accompanied
with tests then please use the above fix at will, as I don't have the
time (nor the msi-skills to look into that).
Cheers,
Paul.
Recovering a patch accidentally removed by git reset
How do you get a patch back that you have managed to remove completely from your system with a git reset HEAD^ git reset git checkout patchname ? git fetch does not seem to refresh the patch from the repository. I was going fairly well with git then stuffed this up. Jeff
Re: make test failure
On Tue, Sep 19, 2006 at 01:57:22PM -0700, James Hawkins wrote: I get the following failures with fontforge 20060822. font.c:423: Test failed: GetGlyphIndices count of glyphs should = 5 not -1 font.c:424: Test failed: GetGlyphIndices should have returned a nonexistent char not f000 font.c:427: Test failed: GetGlyphIndices count of glyphs should = 5 not -1 font.c:428: Test failed: GetGlyphIndices should have returned a not f000 make: *** [font.ok] Error 4 Hi James, This is a different problem - the test is a bit broken and doesn't check that the 'Symbol' font is installed before running the test. I'll send a patch in for this in a bit. Huw. -- Huw Davies [EMAIL PROTECTED]
Re: Recovering a patch accidentally removed by git reset
* On Wed, 20 Sep 2006, Jeff L wrote: How do you get a patch back that you have managed to remove completely from your system with a git reset HEAD^ git reset git checkout patchname ? What branch you were on during this? git fetch does not seem to refresh the patch from the repository. I was going fairly well with git then stuffed this up. Hmm, old git (1.0.4) can do it by git rebase origin here on my stable debian box.
Re: Implement GetKerningPairs for TrueType fonts, take 3
On Wed, Sep 20, 2006 at 03:22:02PM +0900, Dmitry Timoshkov wrote:
Changelog:
Implement GetKerningPairs for TrueType fonts.
Hi Dmitry,
Looks good, apart from one small nitpick below.
I still think it would be nice to add the tests that you have to the
test suite, even if it's just something that checks the first few
pairs of Arial at some fixed font height.
+static DWORD parse_format0_kern_subtable(GdiFont font,
+ const struct
TT_format0_kern_subtable *tt_f0_ks,
+ const USHORT *glyph_to_char,
+ KERNINGPAIR *kern_pair, DWORD
cPairs)
+{
+kern_pairs_copied = 0;
+
+for (i = 0; i nPairs; i++)
+{
+kern_pair-wFirst = glyph_to_char[GET_BE_WORD(tt_kern_pair[i].left)];
+kern_pair-wSecond =
glyph_to_char[GET_BE_WORD(tt_kern_pair[i].right)];
+kern_pair-iKernAmount =
MulDiv((short)GET_BE_WORD(tt_kern_pair[i].value), font-ppem,
font-ft_face-units_per_EM);
+
+TRACE(left %u right %u value %d\n,
+ kern_pair-wFirst, kern_pair-wSecond,
kern_pair-iKernAmount);
+
+kern_pair++;
+kern_pairs_copied++;
+if (!--cPairs) break;
+}
Seems to me that if you set nPairs = min(cPairs, nPairs) at the start
of the loop, then you can eliminate the break and get rid of the
kern_pairs_copied variable that basically mirrors i.
Thanks,
Huw.
--
Huw Davies
[EMAIL PROTECTED]
Re: Recovering a patch accidentally removed by git reset
Saulius Krasuckas wrote: * On Wed, 20 Sep 2006, Jeff L wrote: How do you get a patch back that you have managed to remove completely from your system with a git reset HEAD^ git reset git checkout patchname ? What branch you were on during this? This was the Origin or Master Hmm, old git (1.0.4) can do it by git rebase origin here on my stable debian box. Looking at the log the last couple of patches were: commit 15b46847b0bc4d9bcc2b03d9377ce7342f4da536 Author: James Hawkins [EMAIL PROTECTED] Date: Wed Sep 13 17:18:23 2006 -0700 setupapi: Add stubs for SetupOpenLog, SetupCloseLog, and SetupLogError. commit 7588b669d8331ff64fc3b75cebe40ef518cd0de1 Author: James Hawkins [EMAIL PROTECTED] Date: Wed Sep 13 14:19:12 2006 -0700 setupapi: Implement pSetupGetField, with tests. They still seem to be there so I don't even know if I did delete a patch. Jeff
Re: Recovering a patch accidentally removed by git reset
* On Wed, 20 Sep 2006, Jeff Latimer wrote: * Saulius Krasuckas wrote: * On Wed, 20 Sep 2006, Jeff L wrote: How do you get a patch back that you have managed to remove completely from your system with a git reset HEAD^ git reset git checkout patchname ? Hmm, old git (1.0.4) can do it by git rebase origin here on my stable debian box. Looking at the log the last couple of patches were: commit 15b46847b0bc4d9bcc2b03d9377ce7342f4da536 Author: James Hawkins [EMAIL PROTECTED] Date: Wed Sep 13 17:18:23 2006 -0700 setupapi: Add stubs for SetupOpenLog, SetupCloseLog, and SetupLogError. commit 7588b669d8331ff64fc3b75cebe40ef518cd0de1 Author: James Hawkins [EMAIL PROTECTED] Date: Wed Sep 13 14:19:12 2006 -0700 setupapi: Implement pSetupGetField, with tests. They still seem to be there so I don't even know if I did delete a patch. Hm, and what branch does this come from? Are there any difference between your recently used branches: git-whatchanged origin git-whatchanged master git-whatchanged patchname git diff origin..master git diff origin..patchname git diff master..patchname ?
Re: Recovering a patch accidentally removed by git reset
Jeff L wrote: How do you get a patch back that you have managed to remove completely from your system with a git reset HEAD^ git reset git checkout patchname ? git fetch does not seem to refresh the patch from the repository. I was going fairly well with git then stuffed this up. If the patch you uncommitted with git reset is your own, you can search for it with git fsck-objects. That will give you a list of SHA1 commit IDs (and perhaps other objects). You can check what is in each commit with git log SHA1ID. If you've just uncommitted one of Alexandre's commits, first make sure that you have the master branch checked out: bash-2.05b$ git branch * master origin Unless you've made more branches, master is your, and origin is Alexandre's. Then try: git checkout master git rebase origin That should bring your master back in line with the origin branch. I did a presentation on Git at wineconf, you can see it here: http://mandoo.dyndns.org/git-presentation/git-wine.html Mike
Re: Governance revisited
On Sunday 17 September 2006 21:48, Marcus Meissner wrote: On Sun, Sep 17, 2006 at 08:09:24AM +1000, Robert Lunnon wrote: I note the recent flamefest, where some of this list seared yet another contributor (Roland Kaeser) Since this particular very old, very shrivelled chestnut. is one of my personal favourites (thanks to Colin Wright for the chestnut thing...). I'd like to repeat my observations about this. Feel free to flame away since I have donned my asbestos suit and have long since decided my viewpoint. The problem is that code gets rejected that is *** NOT *** Hacky because there is a, single point of review - a single opinion of what constitutes a hack, and no appeal process. For example I once submitted code to implement cpu.c using the x86 cpuid instruction directly on all x86 platforms. This was NO hack. But the code was rejected. This code replaces the OS specific code for several x86 cases with generic code. The way I see it this code removes hacks (since I consider any OS specific code fragment a hack). This just shows that opinions differ about what a hack is. This code now sits in my patch-kit, never to see the light of day on wine-hq, but happily runs in every copy of wine for Solaris for the last 4 years with ZERO issues. Well, regular WINE no longer needs this patch, since it has been fixed differently. In fact according to Alexandre everyone of your patches is now done in mainline, so your patch set is no longer necessary. No hacks should not be an objective, by my definition wine already has more hacks than just about any other open source package out there. Linuxisms continue to contaminate wine every month (I can vouch for it). What we need is management, balance between function and beauty delivered by peer review. Necessary functional hacks should be allowed unless they have severe side-effects. Even application specific work-arounds can be permitted if the work around adds significant functionality per the objectives of the project, the scope of the work-around is suitably confined, and assuming the code can be maintained over time. Wine needs process... Wine works fine as-is in my opinion ;) Which you are entitled to, but my opinion happens to differ. Whether the wine core source has all the patches, (Which it doesn't - many, but not all) isn't relevant, it's the process that they go through that I believe could improve. Bob
Re: ALSA implementation
On Mon, Sep 18, 2006 at 02:12:02PM +0200, Tomas Carnecky wrote: Jan Zerebecki wrote: To fix bug #4093 we need to replace the currently used signal callback method (very complex to make signals work properly [in Wine], thus we should avoid it) with I guess a fd based method for example with select. The alsa-api documentation about this looks pretty usable. Would that fix the DSOUND_MixOne underrun problem, too? Or is that a different bug? No, as far as I understand this, that might (partially) be a dsound bug (if it is a bug) that gets worse when the thread that handles dsound doesn't get enough cpu (or not at the right time). A couple of weeks ago on IRC Roderick Colenbrander ( Thunderbird ) dug out some old incomplete patch that seemed as if it was intended to fix part of this, but it seemed not to work (deadlock) and I don't think anyone tried futher. Using the SetThreadPrio patch makes this problem much less noticable. Anyway this has only so much to do with winealsa as different sound backends provoke different scheduling by the kernel (like oss, jack and alsa; but this is also true for different ways to use alsa-lib [so the fd-based method may give us better scheduling]). Jan
Re: ALSA implementation
On Mon, Sep 18, 2006 at 01:54:26AM -0400, Aaron Slunt wrote: Jan, could you please clarify what you mean by an fd-based method? Thanks. On http://alsa-project.org/alsa-doc/alsa-lib/pcm.html search for the headline Event waiting routines. That is what I meant with fd-based method. Below that is Asynchronous notification and it describes what we currently use in winealsa. Jan
Re: Implement GetKerningPairs for TrueType fonts, take 4
On Thu, Sep 21, 2006 at 12:18:51AM +0900, Dmitry Timoshkov wrote: this version of the patch incorporates another Huw's suggestion in eliminating redundant local variable and simplifying the code. Thanks Dmitry, Looks good to me. -- Huw Davies [EMAIL PROTECTED]
EnumServicesStatusA - Typical return structure contents with a working internet LAN connection
I'm trying to get an application running that accesses the Internet, but fails with the message, no Internet connection present. The internet connection is fine, as proved by the fact I can run firefox wow under wine. I've disassembled the applications exe and examined wine's fixme errors when the application runs and it seems to do the following It calls InternetGetConnectedState to determine whether there is a modem or LAN connection. Wine returns the fact there is a LAN connection. It then calls EnumServicesStatusA with a type=30 state=1, in order to get a list of running services, now what I think it's doing is expecting to see a service that provides the internet connection, because wine doesn't actually return a list of services the application then decides there's no internet connection. What I want to do is provide a return structure that does at least contain the service name state (internet related) that the application is expecting to see. Does anybody know what service that could be, (specifically it's actual name) or even better provide a typical return structure that is returned by windows when a application calls EnumServicesStatusA so I can construct the structure this app is expecting to see. I've never written anything under MS windows otherwise I would write a small application myself that calls EnumServicesStatus figure it out myself. In fact maybe I will have to get myself a copy of visual C++ so I can do these tests. Regards Nick Law PS I'm new to this debugging without access to the applications source code, so any hints tricks would be appreciated. It looks like I may have to learn Intels assembler instruction set as well!, which I don't mind. The last time I wrote an assembly language program was 25 years ago on a PerkinElmer 3220 mini computer! So this should be fun. -- Regards Nick Law Mobile: 07736 022165 Email: [EMAIL PROTECTED] Medical Imaging Consultancy Ltd (M.I.C) Sales and Service of ADAC and IS2 Products http://www.mic-nucmed.co.uk
Re: ALSA implementation
Jan Zerebecki wrote: As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected. Why won't it work without special care? Is it because of the SIGIO signal? Wouldn't the fd-method require a separate thread? tom
EnumServicesStatusA - Typical return structure contents with a working internet LAN connection
I'm trying to get an application running that accesses the Internet, but fails with the message, no Internet connection present. The internet connection is fine, as proved by the fact I can run firefox wow under wine. I've disassembled the applications exe and examined wine's fixme errors when the application runs and it seems to do the following It calls InternetGetConnectedState to determine whether there is a modem or LAN connection. Wine returns the fact there is a LAN connection. It then calls EnumServicesStatusA with a type=30 state=1, in order to get a list of running services, now what I think it's doing is expecting to see a service that provides the internet connection, because wine doesn't actually return a list of services the application then decides there's no internet connection. What I want to do is provide a return structure that does at least contain the service name state (internet related) that the application is expecting to see. Does anybody know what service that could be, (specifically it's actual name) or even better provide a typical return structure that is returned by windows when a application calls EnumServicesStatusA so I can construct the structure this app is expecting to see. I've never written anything under MS windows otherwise I would write a small application myself that calls EnumServicesStatus figure it out myself. In fact maybe I will have to get myself a copy of visual C++ so I can do these tests. Regards Nick Law PS I'm new to this debugging without access to the applications source code, so any hints tricks would be appreciated. It looks like I may have to learn Intels assembler instruction set as well!, which I don't mind. The last time I wrote an assembly language program was 25 years ago on a PerkinElmer 3220 mini computer! So this should be fun.
Re: ALSA implementation
Aaron Slunt wrote: Jan Zerebecki wrote: On Sun, Sep 17, 2006 at 05:26:12PM +0100, James Courtier-Dutton wrote: I am an ALSA developer, and at one point tried to fix the wine alsa support. I found the wine source code very difficult to read and understand. Windows seems to have so many different sound APIs, I did not really know where to start. Everything in wine that uses alsa is below dlls/winmm/winealsa/. I explained in a different mail to this thread what bugs are in winealsa. (Archive link to that mail is: http://www.winehq.org/pipermail/wine-devel/2006-September/050826.html ) I suspect that either wine will have to change a lot, or ALSA will have to change a lot before they work nicely together. As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected. We just need someone to code this change. It seems I just found out how to fix the other winealsa problem I mentioned in that mail, I'm currently testing if it works. Jan Jan, could you please clarify what you mean by an fd-based method? Thanks. I have not looked at the wine source code lately, but I would advise you that it would be sensible to talk to the sound card at only the 48000 Hz rate. If a windows application wants 44.1kHz, I would suggest that you add your own resampling code to wine. The reason for this is that a Linux application can ask for some buffer size from the alsa-lib. If the sound card hardware cannot do that buffer size in hardware, alsa-lib will reject the request and leave it to the application to try a different value. This is all ok for an open source application, as one can just fix the application to act accordingly. This is not the case with a binary application like all the applications running on top of wine. One cannot fix those applications to work nicely with alsa-lib. As a majority of sound card hardware works nicely at 48kHz, but very few sound cards do 44.1kHz in hardware, the application must then do the resampling necessary to achieve the task. alsa-lib does do resampling currently, but it has some importance constraints that I think are incompatible with wine. I would therefore recommend that wine does it's own resampling to 48kHz before passing sound to alsa-lib. In time alsa will remove the resampling constraints present in alsa-lib, but that fix is not expected any time soon. As most windows applications running on wine tend to use the 44.1kHz rate, that will cause problems with the current alsa-lib. So, if wine want windows games to work better with sound when using alsa-lib, I would recommend wine doing the resampling. James
Text Layout Summit
Hi folks, There is going to be a Text Layout Summit during the Boston Gnome Summit http://live.gnome.org/Boston2006/TextLayout We are going to discuss things related to text layout. Hopefully we will discuss a uniscribe compatible API that could be used by wine and mono SWF since afaik neither has uniscribe support. It would be great if someone from wine and mono could be there. If that wouldn't be possible we would appreciate your input on what you would need. Regards, Daniel P.S. OK to CC me on replies as I'm not subscribed to either list.
Re: msi/iTunes and questions
Hi, On 20/09/06, Paul Vriens [EMAIL PROTECTED] wrote: The single-quotes should be needed as the SQL statement in the trace showed: trace:msi:MSI_DatabaseOpenViewW LSELECT `Message` FROM `Error` WHERE `Error` = The installlation of QuickTime did not complete successfully. iTunes requires QuickTime. 0x6669a498 and a bit further: err:msidb:WHERE_VerifyCondition Couldn't find column LThe This is just one of many issues with this installation. Does the fix look OK? Looks good but it will probably fail when %s contains an apostrophe. -- Ph.
COM
A recent article in a Linux magazine talking about winelib mentioned using __attribute__((com_interface)). I thought that attribute was no longer valid in gcc. The reason I am asking is because I am trying to do COM development using mingw, C++, (hopefully) WIDL. I thought the 3.x and higher version of gcc supported -fvtable-thunks by default making it binary compatible with windows COM. Does anyone know if this is really true? jmccay
Re: EnumServicesStatusA - Typical return structure contents with a working internet LAN connection
Nick Law wrote: I've never written anything under MS windows otherwise I would write a small application myself that calls EnumServicesStatus figure it out myself. In fact maybe I will have to get myself a copy of visual C++ so I can do these tests. Have you looked at creating a conformance test to include with Wine? That would be preferable. http://www.winehq.org/site/docs/winedev-guide/testing I guess you would create a new test file dlls/advapi32/tests/service.c with a test of this behavior. Take a look at the other tests already there to get an idea of how it is done. Included there are instructions for cross compiling a Windows executable in Linux using MinGW. No need to get and learn visual C++. Regards Nick Law PS I'm new to this debugging without access to the applications source code, so any hints tricks would be appreciated. It looks like I may have to learn Intels assembler instruction set as well!, which I don't mind. The last time I wrote an assembly language program was 25 years ago on a PerkinElmer 3220 mini computer! So this should be fun. Ack... assembler? Hopefully that won't be required ;)
Re: ALSA implementation
On Wed, Sep 20, 2006 at 05:54:06PM +0200, Tomas Carnecky wrote: Jan Zerebecki wrote: As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected. Why won't it work without special care? Is it because of the SIGIO signal? Wouldn't the fd-method require a separate thread? Yes, we cannot execute code in signals, namely critical sections cannot be entered recursively from a signal handler. Blocking the signal was not accepted by Alexandre, so we would need to use something else ;) Ciao, Marcus
Re: EnumServicesStatusA - Typical return structure contents with a working internet LAN connection
Duane Clark wrote: Nick Law wrote: I've never written anything under MS windows otherwise I would write a small application myself that calls EnumServicesStatus figure it out myself. In fact maybe I will have to get myself a copy of visual C++ so I can do these tests. Have you looked at creating a conformance test to include with Wine? That would be preferable. http://www.winehq.org/site/docs/winedev-guide/testing I guess you would create a new test file dlls/advapi32/tests/service.c with a test of this behavior. Take a look at the other tests already there to get an idea of how it is done. Included there are instructions for cross compiling a Windows executable in Linux using MinGW. No need to get and learn visual C++. Regards Nick Law PS I'm new to this debugging without access to the applications source code, so any hints tricks would be appreciated. It looks like I may have to learn Intels assembler instruction set as well!, which I don't mind. The last time I wrote an assembly language program was 25 years ago on a PerkinElmer 3220 mini computer! So this should be fun. Ack... assembler? Hopefully that won't be required ;) Thanks, much appreciated, I'll take a look at the winedev-guide tonight, I am also really glad I don't need to buy visual C++ :) Nick
Re: ALSA implementation
On Wed, Sep 20, 2006 at 05:55:03PM +0200, Marcus Meissner wrote: On Wed, Sep 20, 2006 at 05:54:06PM +0200, Tomas Carnecky wrote: Jan Zerebecki wrote: As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected. Why won't it work without special care? Is it because of the SIGIO signal? Wouldn't the fd-method require a separate thread? It is because how (all) signals work and how wine works. The fd method may not require a separate thread when we can combine the event loop of the currently used sound thread with e.g. the select for the alsa-lib fd(s), thu I didn't look at that and it might not be possible. Yes, we cannot execute code in signals, namely critical sections cannot be entered recursively from a signal handler. Blocking the signal was not accepted by Alexandre, so we would need to use something else ;) I later noticed that the signal blocking patch also didn't work as expected (for e.g. War3 I got many buffer underruns) because it seemed to use much cpu (so It might have only mitigated the race condition...). Also as I understood from what AJ said, the issue is more complex. He mentioned that it would be possible to make it work, but we agreed that when there is an easier and more straight forward solution it should be preferred. (Another problem I remember is that the sigaction callback can trigger in any thread which seems to be something we realy want to avoid.) Jan
Re: oleaut32 1/2: Implements function variant:VarImp
Benjamin Arai [EMAIL PROTECTED] writes: +case VT_I1: if (V_I1(left) == -1) resvt = VT_NULL; break; +case VT_UI1:if (V_UI1(left) == 0xff) resvt = VT_NULL; break; +case VT_I2: if (V_I2(left) == -1) resvt = VT_NULL; break; +case VT_UI2:if (V_UI2(left) == 0x) resvt = VT_NULL; break; +case VT_INT:if (V_INT(left) == -1) resvt = VT_NULL; break; +case VT_UINT: if (V_UINT(left) == 0x) resvt = VT_NULL; break; +case VT_I4: if (V_I4(left) == -1) resvt = VT_NULL; break; +case VT_UI4:if (V_UI4(left) == 0x) resvt = VT_NULL; break; +case VT_I8: if (V_I8(left) == -1) resvt = VT_NULL; break; +case VT_UI8:if (V_UI8(left) == 0x) resvt = VT_NULL; break; Shouldn't the last one be something like ~(ULONGLONG)0 instead of 0x? -- Alexandre Julliard [EMAIL PROTECTED]
Re: [c2man] remove hardcoded extension (try#2)
Vijay Kiran Kamuju [EMAIL PROTECTED] writes:
my $uc_dll_name = uc $dll_name;
+
+ if (($dll_ext ne 'ds') ($dll_ext ne 'acm') ($dll_ext ne 'drv')
+ ($dll_ext ne 'exe') ($dll_ext ne 'ocx') ($dll_ext ne 'vxd'))
+ {
+$dll_ext='dll';
+ }
You are still hardcoding things, there's really no reason to do that.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Governance revisited (Wineconf report)
Wine works fine as-is in my opinion ;) Which you are entitled to, but my opinion happens to differ. Whether the wine core source has all the patches, (Which it doesn't - many, but not all) isn't relevant, it's the process that they go through that I believe could improve. For the record, Governance is something we often spend a chunk of time on at each Wine conference. Brian has written a nice summary of Wineconf on WWN (thanks Brian!), including a reprise of the talk on governance. Being insufferably long winded, and feeling the need to create a complete record, I would add a few things to what Brian wrote. First, I think there was clear and essentially unanimous agreement that the current high standards for quality were a Good Thing (TM), including the Holy Order of Writing Conformance Tests. Second, I think we had fairly clear agreement that so long as he can handle it, it is most efficient to have Alexandre as the sole maintainer. Obviously, the more help he gets from component maintainers (e.g. Mike/MSI, Rob/COM), the better. Third, I think there was clear agreement that Alexandre is often a Royal Pain In the Ass (RPITA). He ignores patches, responds tersely, and sometimes delivers the occassional kiss of death: I can't tell you what to change, but your patch is wrong. However, we, the assembled 30 or so of the most core Wine developers, could not think of a single case where Alexandre had been proven wrong. Nor could we think of a single instance when he had failed to be persuaded by reasonable argument; making a rather compelling case that he is generally right. We also talk, from time to time, about building some sort of patch tracking system to allow for better management of patches. Something like a 'ticket' system, so people could see the status of their email, whether or not it had been reviewed, etc, etc. I think there is some sense that this might be useful, but it's a sufficiently complex problem, and it has to be written in emacs, that we always defer it for the future. So I think the strong (if not unamimous) consensus was to continue on as we are, but make an effort to provide an 'ambassador' program of some kind, particularly around folks that are new to Wine. If you have a specific concrete suggestion for change, this would be a fine time to put it forward. But if your proposal is largely: Alexandre should accept more patches, I think you'll find that none of the core Wine developers will support you in that, so it's not worth the effort, at least not in this venue. Cheers, Jeremy
Re: oleaut32 1/2: Implements function variant:VarImp
Sounds good, but in that case shouldn't I also change the one for UINT to something like ~(UINT)0? Benjamin Alexandre Julliard wrote: Benjamin Arai [EMAIL PROTECTED] writes: +case VT_I1: if (V_I1(left) == -1) resvt = VT_NULL; break; +case VT_UI1:if (V_UI1(left) == 0xff) resvt = VT_NULL; break; +case VT_I2: if (V_I2(left) == -1) resvt = VT_NULL; break; +case VT_UI2:if (V_UI2(left) == 0x) resvt = VT_NULL; break; +case VT_INT:if (V_INT(left) == -1) resvt = VT_NULL; break; +case VT_UINT: if (V_UINT(left) == 0x) resvt = VT_NULL; break; +case VT_I4: if (V_I4(left) == -1) resvt = VT_NULL; break; +case VT_UI4:if (V_UI4(left) == 0x) resvt = VT_NULL; break; +case VT_I8: if (V_I8(left) == -1) resvt = VT_NULL; break; +case VT_UI8:if (V_UI8(left) == 0x) resvt = VT_NULL; break; Shouldn't the last one be something like ~(ULONGLONG)0 instead of 0x?
Re: oleaut32 1/2: Implements function variant:VarImp
Benjamin Arai [EMAIL PROTECTED] writes: Sounds good, but in that case shouldn't I also change the one for UINT to something like ~(UINT)0? Well, yes, ~0u is usually a better choice than 0x, but that's more of a cosmetic issue, unlike the long long case. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Governance revisited
Robert Lunnon wrote: Which you are entitled to, but my opinion happens to differ. Whether the wine core source has all the patches, (Which it doesn't - many, but not all) isn't relevant, it's the process that they go through that I believe could improve. The way to get your changes in is not to keep questioning the current process, but to adapt to it. Try fixing your patches. Try asking for guidance. Try testing them on some other platforms. Getting feedback isn't always easy, so listen when you get it. If you don't want to go to the effort required to get your patches into Alexandre's tree, they're not going to get in themselves. Mike
Re: msi/iTunes and questions
Paul Vriens wrote: The single-quotes should be needed as the SQL statement in the trace showed: trace:msi:MSI_DatabaseOpenViewW LSELECT `Message` FROM `Error` WHERE `Error` = The installlation of QuickTime did not complete successfully. iTunes requires QuickTime. 0x6669a498 Might be worth checking MSDN first... the action is described here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/custom_action_type_19.asp The above query is meant to fail. The action data can either contain an error message, or a number that references an entry in the Error table. The way it works at the moment is just to try using the action data in the query, and if the query fails, then use the action data as it is. If you add quotes, the query won't work, as it's looking up a number not a string. It might make sense to check if the custom action data is a number or a string to avoid the bad query. Mike
Re: EnumServicesStatusA - Typical return structure contents with a working internet LAN connection
The correct way to fix this is to call services.exe (which doesn't exist yet) and get a list of services from there. In the mean time you should be able to persuade Alexandre to take a small hack that returns the appropriate information to the application, you should be able to write a small test app for windows and build it with mingw, or better still a conformance test for wine, the easiest way to do this is look at existing tests and the MSDN docs on the API you'll be testing, in this case EnumServicesStatus, the information it will return is also documented on MSDN. Ivan.
Re: [c2man] remove hardcoded extension (try#2)
well some spec files are like wnaspi32.spec, when we parse the names of those.
We need to hard code them to dll.
There is no other way unless you change the spec file names.
On 9/20/06, Alexandre Julliard [EMAIL PROTECTED] wrote:
Vijay Kiran Kamuju [EMAIL PROTECTED] writes:
my $uc_dll_name = uc $dll_name;
+
+ if (($dll_ext ne 'ds') ($dll_ext ne 'acm') ($dll_ext ne 'drv')
+ ($dll_ext ne 'exe') ($dll_ext ne 'ocx') ($dll_ext ne 'vxd'))
+ {
+$dll_ext='dll';
+ }
You are still hardcoding things, there's really no reason to do that.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Governance revisited (Wineconf report)
Some kinda patch management system would help. I think like bugzilla. On 9/20/06, Jeremy White [EMAIL PROTECTED] wrote: Wine works fine as-is in my opinion ;) Which you are entitled to, but my opinion happens to differ. Whether the wine core source has all the patches, (Which it doesn't - many, but not all) isn't relevant, it's the process that they go through that I believe could improve. For the record, Governance is something we often spend a chunk of time on at each Wine conference. Brian has written a nice summary of Wineconf on WWN (thanks Brian!), including a reprise of the talk on governance. Being insufferably long winded, and feeling the need to create a complete record, I would add a few things to what Brian wrote. First, I think there was clear and essentially unanimous agreement that the current high standards for quality were a Good Thing (TM), including the Holy Order of Writing Conformance Tests. Second, I think we had fairly clear agreement that so long as he can handle it, it is most efficient to have Alexandre as the sole maintainer. Obviously, the more help he gets from component maintainers (e.g. Mike/MSI, Rob/COM), the better. Third, I think there was clear agreement that Alexandre is often a Royal Pain In the Ass (RPITA). He ignores patches, responds tersely, and sometimes delivers the occassional kiss of death: I can't tell you what to change, but your patch is wrong. However, we, the assembled 30 or so of the most core Wine developers, could not think of a single case where Alexandre had been proven wrong. Nor could we think of a single instance when he had failed to be persuaded by reasonable argument; making a rather compelling case that he is generally right. We also talk, from time to time, about building some sort of patch tracking system to allow for better management of patches. Something like a 'ticket' system, so people could see the status of their email, whether or not it had been reviewed, etc, etc. I think there is some sense that this might be useful, but it's a sufficiently complex problem, and it has to be written in emacs, that we always defer it for the future. So I think the strong (if not unamimous) consensus was to continue on as we are, but make an effort to provide an 'ambassador' program of some kind, particularly around folks that are new to Wine. If you have a specific concrete suggestion for change, this would be a fine time to put it forward. But if your proposal is largely: Alexandre should accept more patches, I think you'll find that none of the core Wine developers will support you in that, so it's not worth the effort, at least not in this venue. Cheers, Jeremy
Re: [c2man] remove hardcoded extension (try#2)
Vijay Kiran Kamuju [EMAIL PROTECTED] writes: well some spec files are like wnaspi32.spec, when we parse the names of those. We need to hard code them to dll. There is no other way unless you change the spec file names. That doesn't mean you need to hardcode a list of extensions, any extension is allowed, and the code should cope with that. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [c2man] remove hardcoded extension (try#2)
Well then will this do good, if the file extension is 'spec', then we will take the default value as 'dll'. As the logic i am using to parse the filenames is, I am checking using the first part of the extension. Can you tell me a better method other than this? I will cahnge to that. On 9/20/06, Alexandre Julliard [EMAIL PROTECTED] wrote: Vijay Kiran Kamuju [EMAIL PROTECTED] writes: well some spec files are like wnaspi32.spec, when we parse the names of those. We need to hard code them to dll. There is no other way unless you change the spec file names. That doesn't mean you need to hardcode a list of extensions, any extension is allowed, and the code should cope with that. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Governance revisited (Wineconf report)
On 9/20/06, Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: Some kinda patch management system would help. I think like bugzilla. It'd better have an emacs interface ;) -Brian
Re: X11DRV: wgl move font code [resubmit]
On 9/20/06, Roderick Colenbrander [EMAIL PROTECTED] wrote: Hi, This is a resubmit of the previous font moving patch against the latest cvs/git version. The old version didn't apply anymore to winex11.drv. For the rest the patch is the same. You forgot to attach the patch. -- James Hawkins
Re: ALSA implementation
Jan Zerebecki wrote: On Mon, Sep 18, 2006 at 01:54:26AM -0400, Aaron Slunt wrote: Jan, could you please clarify what you mean by an fd-based method? Thanks. On http://alsa-project.org/alsa-doc/alsa-lib/pcm.html search for the headline Event waiting routines. That is what I meant with fd-based method. Below that is Asynchronous notification and it describes what we currently use in winealsa. Jan I don't think asynchronous notification works at all well. There are several polling methods that can be used. 1) block on poll Used in jackd and generally considered the best method currently. It is often called the callback method where one has a thread block on the poll, and then call the callback function when triggered. jackd expands on this idea letting multiple different applications callback functions be called per trigger event. 2) let the audio buffer free wheel and use a timer to periodically fill/drain the buffers. (what ex windows apps/games tend to do. E.g. Doom3.) The current asynchronous method uses signals and as a result does not tend to work at all well. James
Re: Governance revisited (Wineconf report)
After having followed this thread for some time, I feel that there is an aspect that is often missed in the debate. As I see it, it would appear that Wine contributors fall into essentially two camps. There are those who develop Wine for Wine's sake. This category includes the core developers, and others who just feel strongly about a particular aspect in order to improve it and perfect it. These people have time to spend developing and perfecting their code to meet the necessary high standards for acceptance and would not see the current system of governance to be an issue. These are the very people that would attend Wineconf and discuss the issue! There is another category, however, and I suspect it is the larger of the two. Some people simply need to quickly fix an aspect of Wine in order simply to get an application working. These individuals, a category into which I fall, are driven by a very different motive. To take an example, my (very) small contribution to Wine was driven by the need to get a commercial ECAD application running, so that I could continue to use the application as a production tool on a production system in order to continue to function as an electronics engineer. In my case, I am also a software developer who believes in feeding useful fixes back to the community, so I used up some of my valuable free time and got the patch accepted. It took approximately three times longer to get the patch accepted than it did to fix the problem in the first place! I persevered, but I wonder how many other individuals who fall into this category would do the same? Another contractor driven purely by commercial pressures may have just got it working and kept the fix in their own tree. Such people do not have the free time or the inclination to go through the numerous iterations to get the patch accepted. Free time is a rare commodity these days, and most software developers will have other projects. These are not the people who would attend Wineconf and whose opinions can only be solicited through other means. How many Wine trees are there out there containing useful small fixes that see the light of day outside of the developers's box, simply because they do not have the time to struggle through the QA system. A number of these patches could be being lost to the community. How to capture these 'lost' contributions is a difficult issue. Maybe a centralized repository for patches could be maintained separate from the main Wine tree and with a very loose method of acceptance (maybe just ensure that it is clearly indicated what the patch is for and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel. The quality of Wine is important, and a workable QA system is very necessary. However there should be a mechanism to enable widespread dissemination of contributions that for various reasons do not merit direct inclusion in the tree at that time and for which the developer has neither the time nor the inclination to do battle with the QA system. Just my thoughts. John. Vijay Kiran Kamuju wrote: Some kinda patch management system would help. I think like bugzilla. On 9/20/06, Jeremy White [EMAIL PROTECTED] wrote: Wine works fine as-is in my opinion ;) Which you are entitled to, but my opinion happens to differ. Whether the wine core source has all the patches, (Which it doesn't - many, but not all) isn't relevant, it's the process that they go through that I believe could improve. For the record, Governance is something we often spend a chunk of time on at each Wine conference. Brian has written a nice summary of Wineconf on WWN (thanks Brian!), including a reprise of the talk on governance. Being insufferably long winded, and feeling the need to create a complete record, I would add a few things to what Brian wrote. First, I think there was clear and essentially unanimous agreement that the current high standards for quality were a Good Thing (TM), including the Holy Order of Writing Conformance Tests. Second, I think we had fairly clear agreement that so long as he can handle it, it is most efficient to have Alexandre as the sole maintainer. Obviously, the more help he gets from component maintainers (e.g. Mike/MSI, Rob/COM), the better. Third, I think there was clear agreement that Alexandre is often a Royal Pain In the Ass (RPITA). He ignores patches, responds tersely, and sometimes delivers the occassional kiss of death: I can't tell you what to change, but your patch is wrong. However, we, the assembled 30 or so of the most core Wine developers, could not think of a single case where Alexandre had been proven wrong. Nor could we think
Re: X11DRV: wgl move font code [resubmit]
This time with a patch. Hi, This is a resubmit of the previous font moving patch against the latest cvs/git version. The old version didn't apply anymore to winex11.drv. For the rest the patch is the same. Regards, Roderick Colenbrander -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer -- NEU: GMX DSL Sofort-Start-Set - blitzschnell ins Internet! Echte DSL-Flatrate ab 0,- Euro* http://www.gmx.net/de/go/dsl x11drv_wgl_font_updated.patch.gz Description: GNU Zip compressed data
Re: Governance revisited (Wineconf report)
Dr J A Gow wrote: How to capture these 'lost' contributions is a difficult issue. Maybe a centralized repository for patches could be maintained separate from the main Wine tree and with a very loose method of acceptance (maybe just ensure that it is clearly indicated what the patch is for and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel. Why reinvent the wheel? If such people can spend their time chasing down the problem and developing a fix for it, they sure can open a bug in bugzilla, describe theproblem and attach a patch they made. How more simple can it be? No patches lost, no extra places to look for. And all the information describing the problem. Everything in one place. Vitaliy
Re: gdi32: GetTextExtentPoint and GetTextExtentExPoint behavedifferently if there's a \n in the string.
Huw Davies [EMAIL PROTECTED] wrote:
-ok(sz1.cx == sz2.cx sz1.cy == sz2.cy,
- results from GetTextExtentExPointW and GetTextExtentPointW differ\n);
+ok(sz1.cy == sz2.cy,
+ cy from GetTextExtentExPointW (%ld) and GetTextExtentPointW (%ld)
differ\n, sz1.cy, sz2.cy);
+todo_wine {
+/* The \n in the string is apparently handled differently in
GetTextExtentPoint and GetTextExtentExPoint */
+ok(sz1.cx != sz2.cx,
+ cx from GetTextExtentExPointW (%ld) and GetTextExtentPointW (%ld) are the
same\n, sz1.cx, sz2.cx);
+ }
This test fails for me (i.e. sz1.cx == sz2.cx) under XP (SP2+all the latest
fixes).
--
Dmitry.
Re: msi [6/7]: Translate the INSTALLSTATE_UNKNOWN index into the INSTALLSTATE_ABSENT image index
Hiya James, -TRACE(Feature %s - %d %d %d\n, debugstr_w(feature-Title), +printf(Feature %s - %d %d %d\n, debugstr_w(feature-Title), I don't think you meant that to slip in. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
