Re: Linklint results for winehq
On 9/28/06, Tom Wickline [EMAIL PROTECTED] wrote: Hello, I ran our linklint script on winehq and here's the results. I will try and fix as many errors as possible over the next couple weeks. Tom --- Processing ... writing files to linklint wrote 25 txt files wrote 23 html files wrote index file index.html found 1 default index found 476 cgi files found 3 html files found 17 image files found 208 other files found 3833 http links found 5 https links found 20 ftp links found 54 mailto links found 15 news links found 2 unknown links found 2658 named anchors - 766 ignored files - 3 actions skipped - 125 files skipped warn3 warnings ERROR 1 missing image file ERROR 3 missing other files ERROR 99 missing named anchors Linklint found 705 files and checked 500 html files. There were 4 missing files. 13 files had broken links. 103 errors, 3 warnings. real5m58.972s user0m6.960s sys 0m0.320s checking 3833 urls ... The results from checking the 3833 urls. writing files to linklint wrote 11 txt files wrote 9 html files wrote index file urlindex.html found 3323 urls: ok - 254 urls: moved permanently (301) - 330 urls: moved temporarily (302) ERROR 11 urls: access forbidden (403) ERROR 7 urls: could not connect to host ERROR 26 urls: could not find ip address ERROR 1 url: gateway timeout (503) ERROR 2 urls: internal server error (500) ERROR 276 urls: not found (404) ERROR 46 urls: timed out connecting to host ERROR 2 urls: timed out getting host ip address ERROR 6 urls: timed out waiting for data warn4 urls: access not authorized (401) warn 129 urls: not an http link warn2 warnings Linklink checked 3833 urls: 3323 were ok, 377 failed. 584 urls moved. 43 hosts failed: 88 urls could be retried. 191 files had failed urls. No urls were modified since last reset. real38m27.804s user0m3.190s sys 0m0.820s Tom
Re: wined3d base GLX requirement
Hi, Why should someone have to install glx to run Wine if they don't care about using wined3d, or if they do need to use wined3d they don't care about using glx? Well, glx is a base requirement for getting OpenGL set up, which we need for d3d functionality. So wined3d without glx does not make any sense. But I agree that it should compile. pgpINcMoJCzbr.pgp Description: PGP signature
Re: wined3d base GLX requirement
On 28/09/06, James Hawkins [EMAIL PROTECTED] wrote: Why should someone have to install glx to run Wine if they don't care about using wined3d, or if they do need to use wined3d they don't care about using glx? Wine should at least be able to compile in circumstances such as these. There could be lots of reasons why no one has complained, most likely because such a user hasn't showed up, but that doesn't mean it's not possible. My previous work machine didn't meet these glx version demands, and every time something new was added without checks, my build would break, and it was getting very annoying having to write to wine-devel that the build broke again. -- James Hawkins Not quite. The build breaking on certain machines has/had to do with GL versions rather than GLX versions. GLX versions 1.3 should be a lot less common than old GL versions. Note that Roderick has been restructuring the wgl code, with one of the goals being to use wgl rather than GLX in wined3d. It might be worth it to just wait for that to get moved over.
Re: oleaut32 1/2: [RESEND 2] Implements function varformat:VarWeekdayName
Benjamin Arai [EMAIL PROTECTED] writes: + if (fAbbrev) +if (iFirstDay == 0) + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 5) % 7); +else + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); + else +if (iFirstDay == 0) + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + iFirstDay + 5) % 7); +else + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); iFirstDay == 0 is supposed to mean system default, but that is locale-dependent, you can't simply hardcode it. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Patchwork (was Re: Governance revisited)
From: Vitaliy Margolen [EMAIL PROTECTED] So in a sense you will require some one to respond for any incoming e-mail to wine-patches. And if no one does, Alexandre don't get to see the status? Not sure I understand what you mean. If no-one responds to the patch on wine-devel the patch would remain queued and it would show up in Alexandres list. What if he already applied the patch? Now you slowing down what would have worked just fine before. If the patch is already applied it would be marked as such in the database. When a message is sent to wine-devel after the fact, it won't get magically un-applied. Ok now you making it dependant on an e-mail client. Yet that's exactly what we are trying avoid with GIT. Actually, my preference would be to do patch management via a web-based interface. But that's just my preference, I assume a lot of other people prefer the mailinglist method. So let's try to support both. Not really. You can't make some one to review something that don't understand. Or if they are busy/on vacation/away from PC/etc. I'm not trying to change the review process, it would remain as-is. The only addition would be a bot which could do some checks (e.g. does the patch apply cleanly?). But that bot could be introduced anyway, even if Patchwork isn't introduced, so I guess it's not an integral part of the proposed system. So in the end you'll end up with either huge queue that no one wants to touch. Or a clean up jobs that will once in a while go and mark all patches as old and will require authors to resubmit. How's that better then what we use now? If no-one touches a patch, it would end up on Alexandres plate. He could review the patch himself or ask a subsystem maintainer to review it. Again, that's not different from the current system. If the queue of patches waiting for commit grows without bounds, that's a clear indication that Alexandre is overloaded and the project should find ways to remove some of his workload. The same would happen without a patch management system, but perhaps it wouldn't be as visible, so I'm chalking this one up as an added benefit of a patch management system. The system would also be self-cleaning. If a patch has been in RFC status too long it would be deleted from the queue (with appropriate warning email to the author) http://www.winehq.org/pipermail/wine-devel/2006-September/051114.html When people well send out right hacks and expect some one to tell then what they really should do. Current system allows to no waste any time on such craft. We seem to have fundamentally different views of the peripheral (non-core) Wine developers. You seem to view them as potentially bad guys, going out of their way to submit hacks and decrease the quality of Wine code as much as possible, people you'd rather see leave. I see people willing to donate their time to improve Wine. Sure, they make mistakes but at least they make an effort. No, by requiring some one to respond you making them responsible (at least until they respond). Of course responses like sucks wouldn't be nice, so some one who does understand the subject will have to spend their time to understand the patch, write a review of the patch and send it. I don't get your point here. Isn't the purpose of reviewing to actually review the patch? And you want that ASAP! Which means whenever patch arrives in wine-patches some one (most likely more then one person) will stop everything they are doing, and start writing a review? No, I don't want to change the review process. It can remain just as it is now. My objective is to improve Wine by maximizing the number of patches of acceptable quality. In my opinion, this can be done by: 1) assuring no patches get lost 2) assuring an author gets informed about why his patch is not acceptable in its current form so he can improve it. Ge van Geldorp.
Re: Route WGL font code through gdi32.dll
On Thu, Sep 28, 2006 at 08:01:00AM +0200, Roderick Colenbrander wrote: As mentioned by Huw, I forgot to attach the gdi32.spec changes :( This is (hopefully) a full patch. --- dlls/opengl32/opengl32.spec 2006-09-25 23:15:35.0 +0200 +++ dlls/opengl32/opengl32.spec 2006-09-27 23:09:11.0 +0200 @@ -396,5 +396,5 @@ @ stdcall wglSwapLayerBuffers(long long) @ stdcall wglUseFontBitmapsA(long long long long) @ stdcall wglUseFontBitmapsW(long long long long) -@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) -@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) +@ stdcall wglUseFontOutlinesA(long long long long long long long ptr) gdi32.wglUseFontOutlinesA +@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) gdi32.wglUseFontOutlinesW You're still forwarding the wrong set of UseFont functions here. Your patch moved wglUseFontBitmaps to gdi32, so you should forward those not wglUseFontOutlines. Huw. -- Huw Davies [EMAIL PROTECTED]
Re: Patchwork (was Re: Governance revisited)
Ge van Geldorp ge at gse.nl writes: From: Vitaliy Margolen wine-devel at kievinfo.com So in a sense you will require some one to respond for any incoming e-mail to wine-patches. And if no one does, Alexandre don't get to see the status? Not sure I understand what you mean. If no-one responds to the patch on wine-devel the patch would remain queued and it would show up in Alexandres list. Hi, Just to mix in this discussion my 0.02, I am one of those would-be submitters who hasn't done so because I don't want to submit crappy code. I've been viewing at loads of patches to see what they need to conform to. In my opinion, this patchwork system combined with the proposal of mentors/domain experts (as also described by someone in this thread) would mean that once I submit a patch which does not comply with the rules (which I would not know as starting contributer), I at least would get a message back from the bot which tells me why it was obvious wrong. Perhaps based on this I would receive a link to a wiki page where these rules are mentioned? If the mentors get multiple patches from different patches with a generic mistake, perhaps a new rule could be added to the bot (and the wiki) to prevent new contributers from making this mistake in the future. Worst case scenario: The bot does not find anything wrong, the mentor would review and approve, but Alexandre would not approve. In this case at least it would be rejected and he would have to make a (minor) comment as to why. But this seems to be the current situation. For me, the positive side would be that I could have an overview of my patches, learn from the feedback and improve them. I'm not saying that that is currently not possible, but since I am only able to work on this after working hours, it would take more of a bite out of my time available than if this patchwork system would be there, which increases the chances of me actually submitting patches. There is a lot of information for developers in the wiki already, but as a new person it would be nice to have some tools/pages to guide you through the process. I am very much in favour of the mentor initiative, since they could filter/improve the patches for specific areas before Alexandre needs to be bothered and provide valuable feedback to me. Okay, system or not, I will continue to try to contribute. Even if it is just by testing applications or translating strings. Frans Kool.
Re: Patchwork (was Re: Governance revisited)
On Thursday 28 September 2006 05:49, Mike McCormack wrote: Seems like that is a system that doesn't scale well at all, as it requires Alexandre to specifically respond to each and every patch. He still has to take an action to review each patch now, and presumably some action to remove it from his queue (speculation since we don't have his process documented - which is why I asked if we could get a vncrec file showing a patch reveiew/application/rejection session, so I could document it). If the process fits into this workflow without disruption the cost should actually be less since it saves having a conversation about why the patch was rejected. It also seems like it encourages patch submitters to not polish their patches themselves and just submit a higher volume of low quality patches for Alexandre to review, since the onus will then be on him to respond. You seem to be assuming people are submitting patches they *know* will not be accepted (discounting ones submitted for the purposes of record only where the submitter says they don't expect it to be committed). This would be pathological behaviour since it would require more work on the part of the submitter as well as on the part of Alexandre. In fact the present process is likely to involve more work since it requires people to speculate about why the patch was rejected or passed over, and if they get it wrong, resubmit. Often there wasn't even anything wrong in the first place (the oops bitbucket) so all the speculation and rework will be a pointless exercise. If the patch is reworked, it's submitted again, has to be reviewed again, wait, rinse, repeat. That will result in more patches than if people are told the actual (rather than speculative) reason it was not applied. The current system, which leaves the responsibility for the patch with the submitter both scales better, and encourages patch submitters to think about their patches more. (the following sounds somewhat harsher than it's intended to but I couldn't figure out a better way to say it) If you can call speculation thinking, but I don't know what you mean by scales better. Speculative review increases the chance that Alexandre has to spend time reviewing more wrong patches because other people guessed wrong. The current system has literally cost me tens of thousands of dollars in wasted developer time on just a handful of patches (not including time I have wasted on it personally), so if by scales better you mean passes off a relatively small cost off (sometimes without actually removing that cost) to others magnified by huge factors then yes I guess it does scale better, but scaling up the expense doesn't seem to be a good idea to me. Maybe some other employers don't mind throwing money away like this (Jeremy?), but I do. Responding to each and every patch seems like it would be a waste of Alexandre's time. We should encourage more people to participate in the patch review process, so that we have more reviewers and a more scalable process. It's more of an heuristic than a determinitive process unless the reviewers know for certain Alexandre's reasons for rejecting a patch (assuming an unapplied patch has in fact been rejected), which requires either telepathy or that he tell them. The current process results in regular oops situations leading to no feedback. There are the oops, must have missed that patch, and oops, I thought I did reply to tell you what was wrong with that patch, both of which I have seen multiple times. These at least could be improved with a suitable system in place and result in some improvement even if the speculative post-rejection-review process is kept. I'm not sure why you seem to be opposed to even attempting to find a better process that will work for everybody. The attempt to do so may well fail, but the surest way to fail is not to try. -- [EMAIL PROTECTED] - Sydney, Australia pgpK8AHMzEWjY.pgp Description: PGP signature
Can't open DLL's without sudo
Im running wine v 0.9.20 under Fedora Core 5. I'm trying to get the Syncrosoft License Control Center to run under wine. for some reason it can only load MFC42.DLL and MSVCRT.DLL if I put 'sudo' on the command line: [EMAIL PROTECTED] LCC]$ wine LCC.exe err:module:import_dll Library MFC42.DLL (which is needed by LC:\\Program Files\\Syncrosoft\\LCC\\LCC.exe) not found err:module:import_dll Library MSVCRT.dll (which is needed by LC:\\Program Files\\Syncrosoft\\LCC\\LCC.exe) not found err:module:import_dll Library MSVCRT.dll (which is needed by LC:\\windows\\system32\\MSVCP60.dll) not found err:module:import_dll Library MSVCP60.dll (which is needed by LC:\\Program Files\\Syncrosoft\\LCC\\LCC.exe) not found err:module:LdrInitializeThunk Main exe initialization for LC:\\Program Files\\Syncrosoft\\LCC\\LCC.exe failed, status c135 [EMAIL PROTECTED] LCC]$ The NtOpenFile that tries to open the DLL (in loader.c) is returning c0022 (ACCESS_DENIED). But the permissions for these DLLs are wide open. Any idea whats going on? - Paul
Re: Coverity coverage of Wine
On Mi, 2006-09-27 at 14:43 +0200, Paul Vriens wrote: Got an email from a Coverity guy. Apparently they have some backlog but Wine is by no means not covered anymore. Things should settle down soon and we can look forward to some nice reports again. Great news. Examining and fixing all Smatch and Coverity-Hits before Wine 1.0 would be great, but I think, that might be to much for the short Time. -- By by ... Detlef
Re: Coverity coverage of Wine
On Thu, 2006-09-28 at 12:00 +0200, Detlef Riekenberg wrote: On Mi, 2006-09-27 at 14:43 +0200, Paul Vriens wrote: Got an email from a Coverity guy. Apparently they have some backlog but Wine is by no means not covered anymore. Things should settle down soon and we can look forward to some nice reports again. Great news. Examining and fixing all Smatch and Coverity-Hits before Wine 1.0 would be great, but I think, that might be to much for the short Time. I've seen a lot of Coverity 'bugs' to already be marked as BUG back in April when this thing started. Would be good if we could already squash those. Cheers, Paul.
Re: Patchwork (was Re: Governance revisited)
Ge van Geldorp wrote: My objective is to improve Wine by maximizing the number of patches of acceptable quality. In my opinion, this can be done by: 1) assuring no patches get lost 2) assuring an author gets informed about why his patch is not acceptable in its current form so he can improve it. That sounds good, but it's not reasonable to put the responsibility on Alexandre, as he has enough work already. From your other mail: mention the time it costs the author. Shouldn't we be looking at the productivity of everyone involved in Wine development and not just at Alexandres productivity (although I acknowledge his special position)? I'm a bit surprised (and, to be honest, also a little bit annoyed) about the low value you seem to place on the time contributed by the developers. With a single maintainer system, costs to patch submitters and authors are much less crucial to a working system than costs to the single maintainer. Spreading the workload, so the many do more work, is the only way to improve the system. We agree that encouraging more reviewers is a good thing, so how about focusing on ways to get more people to review patches? Mike
RE: Patchwork (was Re: Governance revisited)
Hello Mike, From: Mike McCormack [mailto:[EMAIL PROTECTED] That sounds good, but it's not reasonable to put the responsibility on Alexandre, as he has enough work already. Unless you can read Alexandres mind, he's really the only one who can tell what he didn't like about a certain patch. Hopefully he'll get help from others to weed out obviously incorrect patches, but in the end it's his decision. With a single maintainer system, costs to patch submitters and authors are much less crucial to a working system than costs to the single maintainer. Which is why I made the remark about Alexandres special position. It doesn't mean (at least I hope it doesn't mean) that costs to authors are not important at all. We agree that encouraging more reviewers is a good thing, so how about focusing on ways to get more people to review patches? One doesn't preclude the other. I indeed agree it would be good to get more people to review patches, but I also think that's not a complete solution. The results of the review (either by peers, subsystem maintainers or Alexandre) needs to be communicated back to the author. Focusing solely on review doesn't solve the problem of patches getting lost either. Ge van Geldorp.
Re: msi: Implement MsiDatabaseImport [try2]
James Hawkins [EMAIL PROTECTED] writes:
+static LPWSTR msi_read_text_archive(LPCWSTR path)
{
-FIXME(%p %s %s\n, db, debugstr_w(folder), debugstr_w(file) );
+HANDLE file;
+LPSTR data = NULL;
+DWORD read, size = 0;
+
+file = CreateFileW( path, GENERIC_READ, FILE_SHARE_READ, NULL,
OPEN_EXISTING, 0, NULL );
+if (file == INVALID_HANDLE_VALUE)
+return NULL;
+
+size = GetFileSize( file, NULL );
+data = msi_alloc( size + 1 );
+if (!data)
+return NULL;
+
+if (!ReadFile( file, data, size, read, NULL ))
+return NULL;
+
+data[size] = '\0';
+return strdupAtoW( data );
+}
You're leaking both the file and the ascii string.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: clusapi: [RESEND] Implements stub dll for clusapi
Benjamin Arai wrote: +@ stdcall -private DllMain(long long ptr) There's no need to export DllMain. -- Rob Shearman
Governance Ideas
Alexandre said = To be honest, I have no idea what it is that you are suggesting. All I see is phrases like community focused process or acceptance policy which frankly are just meaningless buzzwords. If you expect anything to happen, you'll need to make much more concrete suggestions, and provide examples to make us understand how what you are suggesting would work in practice, and how it would be different from what we are doing now. -- Alexandre Julliard [EMAIL PROTECTED] == To which I said I would respond soon - well here goes. From the outset I want to say that I am not going to redefine the wine project or make suggestions in the sense of a particular change. I want the communities of developers users and others to define that change. What I will do here is suggest ways in which we could organise to make a change as a collective. Firstly the buzzwords Community Focused Process means what it says, develop a process which is centred on the community the project serves. This requires the project to answer some introspective questions 1. Who owns Wine, does wine belong to A.) Alexandre, or B) the community it serves. 2 If the answer is B then which community. It may surprise some to realise that a project like this has many communities. We discovered this when setting up the OpenSolaris community process. Some obvious ones are The Developer Community and The User Community and Developer + User Community. There are other less obvious communities, eg the community of distribution maintainers who may be neither developer or user. If we decide that the community Owns Wine then it needs to be established whether the community has a right to direct wine's development. As the Owner I'd argue the community should have this right. Second Buzzword Patch Acceptance Policy means the rules by which a patch is deemed acceptable or not. At the moment this is pretty close to It's acceptable if Alexandre commits it This is OK in a community process as long as the community that wine serves supports this approach. I think the recent thread throws significant doubt on this. This particular patch acceptance policy is not Transparent, this is the key reason why dropped patches cause so much argument, why many developers leave the project and possibly why Wine doesn't get the major backing some projects do (EG Gnome, KDE Xorg) dealing with the wine project is risky business. Now what do I propose... 1. Answer the questions about the ownership of wine and identify the community it serves. Determine the right of the community to be involved is setting wines direction IE The Bill of rights I mentioned before (for each community Developers VS Users etc). 2. Alexandre documents the exact logic he uses to determine patch acceptability which becomes the patch acceptance policy in the interim. This should be done to the point that someone else could take over from Alexandre and achieve the same result. This opens the way to multiple maintainers as well as allowing Alexandre to take more holidays. 3. The project develops a community process for establishing project direction and maintaining the patch acceptance policy which includes stakeholders elected from the owners IE communities with a stakeholding in wine 4. A community process is run to A.) Establish the communities objective for wine - this will actually probably be reasonably argumentative, but that is exactly how it should be. If it's not there is probably something wrong. It was with OpenSolaris and governance was the greatest concern with that project too. B) review the Patch acceptance policy in line with the community objective. For example the policy may be adjusted to favour functionality improvements, or loosen gating on changes leading to solutions that wine critically needs or even establish a must have application. 5. A mechanism is created to independently review patches (appeal process) for acceptability IE Whether a patch meets the acceptance policy. Note that if a patch acceptable to the policy is rejected then the policy may need to change (Requiring a new community process to review that change) or an architectural decision needs to be taken. This is done by the architecture review board in the OpenSolaris process. Among other things when a patch is sent to appeal the owner of the patch is guaranteed an explanation of how the patch doesn't meet the acceptance policy. Now if we did all this we would * Have a picture of the needs of the community * Have a way to direct the project toward meeting that need * Have a way to demonstrate we intend to meet that need * Have a consistent review process for patches * Have a way to multistream patches * Have an open transparent, trusting and consistent environment in which to work * Have a way to change and grow * Open ways to allow business to confidently invest
Re: Setupapi: add stubs [resend]
Julien [EMAIL PROTECTED] writes:
+/***
+ * SetupDiDestroyClassImageList(SETUPAPI.@)
+ */
+BOOL WINAPI SetupDiDestroyClassImageList(PSP_CLASSIMAGELIST_DATA
ClassImageListData)
+{
+FIXME (Stub %p\n, ClassImageListData);
+SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
+return TRUE;
+}
+
+/***
+ * SetupDiGetClassImageList(SETUPAPI.@)
+ */
+BOOL WINAPI SetupDiGetClassImageList(PSP_CLASSIMAGELIST_DATA
ClassImageListData)
+{
+FIXME (Stub %p\n, ClassImageListData);
+SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
+return TRUE;
+}
It makes no sense to set last error if you return success. And you
really shouldn't return success unless you also store the right things
in that data structure.
--
Alexandre Julliard
[EMAIL PROTECTED]
Award for solving bug 6183
There is bug in wine, which prevents me to play NFS MW with sound (and even Call of Duty). I would like to offer some money for solving this bug. I dont know how much will be good and i can give you all info from my system to solve this (debug, system info). If you are interested in just reply on my email address. Thanks, Mirek
Re: Can't open DLL's without sudo
This e-mail belongs in wine-user not here. Please read error messages yourself first. Vitaliy Paul Wilkinson wrote: I’m running wine v 0.9.20 under Fedora Core 5. I'm trying to get the Syncrosoft License Control Center to run under wine. for some reason it can only load MFC42.DLL and MSVCRT.DLL if I put 'sudo' on the command line: [EMAIL PROTECTED] LCC]$ wine LCC.exe err:module:import_dll Library MFC42.DLL (which is needed by LC:\\Program Files\\Syncrosoft\\LCC\\LCC.exe) not found err:module:import_dll Library MSVCRT.dll (which is needed by LC:\\Program Files\\Syncrosoft\\LCC\\LCC.exe) not found err:module:import_dll Library MSVCRT.dll (which is needed by LC:\\windows\\system32\\MSVCP60.dll) not found err:module:import_dll Library MSVCP60.dll (which is needed by LC:\\Program Files\\Syncrosoft\\LCC\\LCC.exe) not found err:module:LdrInitializeThunk Main exe initialization for LC:\\Program Files\\Syncrosoft\\LCC\\LCC.exe failed, status c135 [EMAIL PROTECTED] LCC]$ The NtOpenFile that tries to open the DLL (in loader.c) is returning c0022 (ACCESS_DENIED). But the permissions for these DLL’s are wide open. Any idea what’s going on? - Paul
RE: Patchwork (was Re: Governance revisited)
From: Jakob Eriksson [mailto:[EMAIL PROTECTED] I have been watching this thread with keen interest. Alexandre does not HAVE to respond to that patch, he can silently ignore it just like he can now. The only difference with Patchwork would be that after a certain time with no comments and no commits, the patch would be removed from the queue and the submitter would get an email warning. Actually, that's not how I intended things to work. The automatic removal from the queue would only happen if the patch had a RFC status, i.e. if action is expected from the patch submitter. If the patch is unopposed and just waiting in the queue, it should stay there. It's reasonable to tell a submitter you seem to have lost interest in this patch, it has been waiting on action from you for [a month, whatever] but nothing has happened, therefore it will be removed from the queue. Sending a warning message your patch is going to be dropped without explanation is no improvement over the current situation. Gé van Geldorp.
Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype (2nd attempt)
Thomas Weidenmueller wrote: The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, not unsigned int. - Thomas It's been discussed numerous times, you should avoid use of 'long' in Wine. On win64 sizeof(long) == 4. On Linux64 sizeof(long) == 8. Vitaliy.
Anybody have a RegDeleteTree[A|W] implementation lying around?
Hi, I was browsing some code and found that we have several places where we made our own implementation of a recursive delete of registry keys/value. Apparently there is an official one in Vista: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/regopenkeyex.asp I don't know if somebody has this already lying around somewhere. If not, I'll have a go (not soon though). Would be a nice code cleanup, or are there any pitfalls? Cheers, Paul.
Re: Governance Ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Lunnon wrote: arrgh, I know you're not supposed to feed the trolls, but... I'm a user I find wine to be very useful. I've got a client who owns a bus charter line that was able to move away from windows, and the only thing they needed was their payroll system that does work in wine. the way I see it, wine is distributed under the LGPL. this means that when I download it, I 'own' it, am able to 'direct' it's 'development', etc. --privately-- what I don't have the right to is to tell anyone on earth what to do. that includes Alexandre, Rob, or anyone else. if anyone else is interested in modifications I may happen to make (I don't have any, wine just works for me), that's great, but I can't force anyone to listen to me. perhaps this email is futile too. - --RFMuller -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFG8dNjfMdLxNd9ZERAg/mAJ9ADty2vUAzecP2dxc8tQ4TdSbOSgCfUbMs tuN8smer6kYFr2LFSqaMAEc= =vOgw -END PGP SIGNATURE-
Re: Governance Ideas
2. Alexandre documents the exact logic he uses to determine patch acceptability which becomes the patch acceptance policy in the interim. This should be done to the point that someone else could take over from Alexandre and achieve the same result. This opens the way to multiple maintainers as well as allowing Alexandre to take more holidays. I'm of the opinion that code is art as its implementation is subjective. The idea that you could document when a patch is acceptable or not seems like an impossibility. You might be able to set a series of ground rules, no c++ comments, shouldn't contain asm unless necessary, but even a patch that fits these requirements isn't necessarily an acceptable patch. I've almost never been unhappy with AJ's judgement except in cases like the safedisc patches where it seemed like no one really knew what was good and more effort wasn't put into at least providing development guidance. Chris
Re: Anybody have a RegDeleteTree[A|W] implementation lying around?
On 28.09.2006 15:26, Paul Vriens wrote: I'll have a few hours tomorrow and will have a look. The cleanest solution for now seems to create RegDeleteTree[A|W] in advapi32 and use that wherever possible (unless we find that it forwards to shlwapi). Most DLL's already import advapi32. Hmm... isn't advapi32 lower level than shlwapi? I'd expect that if forwarding takes place then it'd be shlwapi-advapi32. -f.r.
Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype (2nd attempt)
Vitaliy Margolen wrote: Thomas Weidenmueller wrote: The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, not unsigned int. - Thomas It's been discussed numerous times, you should avoid use of 'long' in Wine. On win64 sizeof(long) == 4. On Linux64 sizeof(long) == 8. I will answer myself: it is declared as 'unsigned long' in SDK. Sorry for the noise. Vitaliy
Re: Governance Ideas
On Thu, September 28, 2006 9:24 am, Chris Morgan wrote: I'm of the opinion that code is art as its implementation is subjective. The idea that you could document when a patch is acceptable or not seems like an impossibility. I wholeheartedly subscribe to this. We are far away (as a profession) to document what is a good/bad patch even when that is fairly obvious to a good maintainer, let alone document exactly the thought process for more complicated cases. This is a waste of time. Alexandre is an amazing judge of patches, we should be happy we have him. More to the point, I think this is missing the point. If we are good at something, it is in evaluating patches on their techincal merit. This doesn't need improvement. What we may be erring a bit is putting the techincal aspects above and beyond other considerations, such as desire for a feature at the expense of a little quality. We are delaying patch inclusion waiting for the 'right' solution, which in part is good, but when that means keeping desired features away for years on end, i think it hurts us more than it helps us being relevant to our users. Maybe there's a way to help Alexandre better understand how much people want something, maybe that can be factored in a bit? -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: clusapi: [RESEND] Implements stub dll for clusapi
When I was creating the stub I looked around in several dll's and some of the them export DllMain. ./advpack/advpack.spec:@ stdcall -private DllMain(long long ptr) ./dciman32/dciman32.spec:@ stdcall -private DllEntryPoint(long long ptr) DllMain ./itss/itss.spec:@ stdcall -private DllMain(long long ptr) ./msimg32/msimg32.spec:@ stdcall -private DllInitialize(long long ptr) DllMain Then in what case do you need to export? Benjamin On 9/28/06, Robert Shearman [EMAIL PROTECTED] wrote: Benjamin Arai wrote: +@ stdcall -private DllMain(long long ptr) There's no need to export DllMain. -- Rob Shearman -- Benjamin Arai http://www.benjaminarai.com
Re: Governance Ideas
On 9/28/06, Chris Morgan [EMAIL PROTECTED] wrote: I've almost never been unhappy with AJ's judgement except in cases like the safedisc patches where it seemed like no one really knew what was good and more effort wasn't put into at least providing development guidance. http://www.winehq.org/pipermail/wine-devel/2006-August/050489.html Tom Chris
make test failure
Hi, Running make test fails with: make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests' ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so tab.c touch tab.ok tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:184: Test failed: no icon, set size: Expected [54,20] got [56,20] make[2]: *** [tab.ok] Error 6 -- James Hawkins
make test failure #2
Hi, This test passes on my machine, should it not? make[2]: Entering directory `/usr/local/src/wine/dlls/d3d9/tests' ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so surface.c touch surface.ok fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x18cd10) : stub, simulating 64MB for now, returning 64MB left surface.c:131: Test succeeded inside todo block: Got pitch 12, expected 12 make[2]: *** [surface.ok] Error 1 -- James Hawkins
Re: make test failure
On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: Hi, Running make test fails with: make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests' ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so tab.c touch tab.ok tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:184: Test failed: no icon, set size: Expected [54,20] got [56,20] make[2]: *** [tab.ok] Error 6 Succeeds over here. Paul.
Re: make test failure #2
On Thu, 2006-09-28 at 11:30 -0700, James Hawkins wrote: Hi, This test passes on my machine, should it not? make[2]: Entering directory `/usr/local/src/wine/dlls/d3d9/tests' ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so surface.c touch surface.ok fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x18cd10) : stub, simulating 64MB for now, returning 64MB left surface.c:131: Test succeeded inside todo block: Got pitch 12, expected 12 make[2]: *** [surface.ok] Error 1 Nothing wrong here (todo_wine is still needed). Paul.
Re: make test failure
On 9/28/06, Paul Vriens [EMAIL PROTECTED] wrote: On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: Hi, Running make test fails with: make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests' ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so tab.c touch tab.ok tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:184: Test failed: no icon, set size: Expected [54,20] got [56,20] make[2]: *** [tab.ok] Error 6 Succeeds over here. I know, it succeeds on a lot of machines, but the point is that it shouldn't fail on any machine. -- James Hawkins
Re: make test failure #2
On 9/28/06, Paul Vriens [EMAIL PROTECTED] wrote: On Thu, 2006-09-28 at 11:30 -0700, James Hawkins wrote: Hi, This test passes on my machine, should it not? make[2]: Entering directory `/usr/local/src/wine/dlls/d3d9/tests' ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so surface.c touch surface.ok fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x18cd10) : stub, simulating 64MB for now, returning 64MB left surface.c:131: Test succeeded inside todo block: Got pitch 12, expected 12 make[2]: *** [surface.ok] Error 1 Nothing wrong here (todo_wine is still needed). Then whoever wrote the test needs to figure out why the test fails on most machines, but passes on mine. 'make test' should not fail on any machine. -- James Hawkins
make test failure #3
Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/shell32/tests' ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c touch shlfileop.ok shlfileop.c:168: Test failed: The requested file does not exist, ret=3 make[2]: *** [shlfileop.ok] Error 1 -- James Hawkins
Re: Route WGL font code through gdi32.dll
On Thu, Sep 28, 2006 at 08:20:51PM +0200, Roderick Colenbrander wrote: Again as mentioned by Huw, the gdi32.spec file wasn't correct. It should be correct this time. No. Your gdi32.spec was fine. It was the opengl32.spec that was wrong (hint: that's why I quoted that bit of the patch ;-). Your patch is for the wglUseFont*Bitmaps* functions and not the wglUseFont*Outlines* functions, so the only thing that should be changing is the former and not the latter. So in opengl32.spec you need to forward the wglUseFont*Bitmaps* functions to functions of the same name in gdi32. Huw.
Re: Route WGL font code through gdi32.dll
The spec file line read '+@ stdcall wglUseFontOutlinesW(long long long long long long long ptr) gdi32.wglUseFontOutlinesW' the last part wasn't needed I think. I thought it was about that. Didn't see the FontBitmaps/FontOutlines issue .. I guess I'll need a take 4 and hope it is right then. Thanks, Roderick On Thu, Sep 28, 2006 at 08:20:51PM +0200, Roderick Colenbrander wrote: Again as mentioned by Huw, the gdi32.spec file wasn't correct. It should be correct this time. No. Your gdi32.spec was fine. It was the opengl32.spec that was wrong (hint: that's why I quoted that bit of the patch ;-). Your patch is for the wglUseFont*Bitmaps* functions and not the wglUseFont*Outlines* functions, so the only thing that should be changing is the former and not the latter. So in opengl32.spec you need to forward the wglUseFont*Bitmaps* functions to functions of the same name in gdi32. Huw. -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
make test failure #4
Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[0]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[1]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[2]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[3]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) make[2]: *** [monitor.ok] Error 4 -- James Hawkins
make test failure #6
Hi, This is with a clean .wine. make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so sysparams.c touch sysparams.ok sysparams.c:1471: Test failed: wrong value in registry -1, expected 154 sysparams.c:1474: Test failed: wrong value in registry -1, expected 0 sysparams.c:1477: Test failed: wrong value in registry -1, expected 0 sysparams.c:1480: Test failed: wrong value in registry -1, expected 8 make[2]: *** [sysparams.ok] Error 4 -- James Hawkins
Re: make test failure
Paul Vriens wrote: On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: Hi, Running make test fails with: make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests' ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so tab.c touch tab.ok tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:184: Test failed: no icon, set size: Expected [54,20] got [56,20] make[2]: *** [tab.ok] Error 6 Succeeds over here. Fails on my RHEL4 laptop too. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: LOSTWAGES: Instructions for getting additional modules
On Do, 2006-09-28 at 05:31 +0900, Mike McCormack wrote: When switching the Instructions for the Wine tree from cvs to git, the Instructions for the additional modules (docs, lostwages, ...) got lost. They're still available at the old link: http://www.winehq.org/site/cvs I was unable to find a Link on the Frontpage, but since git is prefered over CVS, adding cvs next to git might be not the best Idea. The downside is, that the Patch double the information (as already done with the LRX-Tree). Today, I found a Link to the cvs-Page: The Release-Announce. It would be nice to move the remaining modules to Git too, IMO. You are welcome to send a Patch. OTOH, is a change to git for all modules really needed? -- By by ... Detlef
Re: make test failure #2
On 28/09/06, James Hawkins [EMAIL PROTECTED] wrote: Then whoever wrote the test needs to figure out why the test fails on most machines, but passes on mine. 'make test' should not fail on any machine. Stefan wrote that test. It's probably succeeding because your card supports GL_ARB_texture_non_power_of_two.
Re: make test failure
James Hawkins wrote: On 9/28/06, Paul Vriens [EMAIL PROTECTED] wrote: On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: Hi, Running make test fails with: make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests' ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so tab.c touch tab.ok tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:184: Test failed: no icon, set size: Expected [54,20] got [56,20] make[2]: *** [tab.ok] Error 6 Succeeds over here. I know, it succeeds on a lot of machines, but the point is that it shouldn't fail on any machine. Please remove your ~/.wine dir and try again. It seems your metrics are set different. Or your fonts are wrong. Vitaliy
Re: make test failure
On 9/28/06, Vitaliy Margolen [EMAIL PROTECTED] wrote: James Hawkins wrote: On 9/28/06, Paul Vriens [EMAIL PROTECTED] wrote: On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: Hi, Running make test fails with: make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests' ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so tab.c touch tab.ok tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:184: Test failed: no icon, set size: Expected [54,20] got [56,20] make[2]: *** [tab.ok] Error 6 Succeeds over here. I know, it succeeds on a lot of machines, but the point is that it shouldn't fail on any machine. Please remove your ~/.wine dir and try again. It seems your metrics are set different. Or your fonts are wrong. The tests still fail with a clean .wine. -- James Hawkins
Re: make test failure #5
James Hawkins [EMAIL PROTECTED] wrote: make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' msg.c:3700: Test failed: DrawMenuBar: the msg sequence is not complete: expected - actual 0021 0021 is WM_MOUSEACTIVATE. Please re-run the test without touching mouse and see if it helps. msg.c:3727: Test failed: MsgWaitForMultipleObjects returned 0 fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet msg.c:6768: Test failed: WmEmpty: the msg sequence is not complete: expected - actual 0014 make[2]: *** [msg.ok] Error 3 This one is a black magic: sometimes I see it as well, but subsequent runs of the test in most cases succeed for me. -- Dmitry.
Re: make test failure #5
On 9/28/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote: James Hawkins [EMAIL PROTECTED] wrote: make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' msg.c:3700: Test failed: DrawMenuBar: the msg sequence is not complete: expected - actual 0021 0021 is WM_MOUSEACTIVATE. Please re-run the test without touching mouse and see if it helps. Ok, the tests pass now (made sure to not move the mouse). I'm guessing there's not a way to disable mouse input for the duration of the test. msg.c:3727: Test failed: MsgWaitForMultipleObjects returned 0 fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet msg.c:6768: Test failed: WmEmpty: the msg sequence is not complete: expected - actual 0014 make[2]: *** [msg.ok] Error 3 This one is a black magic: sometimes I see it as well, but subsequent runs of the test in most cases succeed for me. Yea, this failure didn't occurr the second time around. Thanks, James Hawkins
