Purist keyword?
I see quite a few people filing bugs that are only exposed when bundled native dlls are removed. I think it would be good to be able to group these bugs, perhaps with a 'purist' keyword. Anyone opposed?
WINE Performance and Evernote 4.0 Windows Client
Evernote are in the process of releasing 4.0 of their Windows client. This is completely rewritten to avoid the use of things that would stop it running under WINE. (This WASN'T their target - it was more about device drivers that had been problematic.) It runs reasonably well on the latest WINE. However it runs slowly (in a way it doesn't under real Windows) and also the autoupdater doesn't seem to work. Is anyone here willing to work with them and us to help it run faster? (I haven't got commitment from Evernote to make changes but I have got their attention now.) :-) Hopefully you can see this thread on the Evernote bulletin board: http://forum.evernote.com/phpbb/viewtopic.php?f=56t=18674 Thanks, Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
re: WINE Performance and Evernote 4.0 Windows Client
Hi Martin, http://forum.evernote.com/phpbb/viewtopic.php?f=56t=18674 Thanks for letting us know. Looking at that thread, your message, and the appdb entry http://appdb.winehq.org/objectManager.php?sClass=versioniId=21775 it looks like people are reporting four or so problems: - autoupdate doesn't work - pdf preview hangs or is slow - switching notebooks is slow - clicking on menu is slow It would probably help to have Wine bug reports at http://bugs.winehq.org for each individual problem, with clear instructions for non-Evernote users on how to reproduce them. (I'd file a couple myself, but I don't have time to experiment at the moment.) - Dan
ddraw [try 3]: Add tests for the foreground window set by SetCooperativeLevel
Any problem with this patch? A+ David
Re: Purist keyword?
Austin English austinengl...@gmail.com wrote: I see quite a few people filing bugs that are only exposed when bundled native dlls are removed. I think it would be good to be able to group these bugs, perhaps with a 'purist' keyword. Anyone opposed? Personally I don't see the point. The less keywords is the better IMO. Why not clarify the problem in the subject, like xxx doesn't install without native yyy.dll ? -- Dmitry.
Re: Purist keyword?
On Saturday, October 30, 2010, Dmitry Timoshkov dmi...@codeweavers.com wrote: Austin English austinengl...@gmail.com wrote: I see quite a few people filing bugs that are only exposed when bundled native dlls are removed. I think it would be good to be able to group these bugs, perhaps with a 'purist' keyword. Anyone opposed? Personally I don't see the point. The less keywords is the better IMO. Why not clarify the problem in the subject, like xxx doesn't install without native yyy.dll ? I meant bugs that only occur by manually removing native dlls. The report summaries are usually clear enough, I was hoping to get an easy way to search for them and separate them from 'normal' bugs. -- -Austin
Re: Purist keyword?
On 30/10/10 19:25, Austin English wrote: I meant bugs that only occur by manually removing native dlls. The report summaries are usually clear enough, I was hoping to get an easy way to search for them and separate them from 'normal' bugs. I suspect your use of the word native is different than the one defined by Wine (see, for example, http://www.winehq.org/docs/wineusr-guide/config-wine-main). Native DLLs, in Wine, are DLLs that come from a real Windows system. This as opposed to built-in DLLs, that are DLLs compiled for Wine as winelib, carrying the .dll.so extension. To the best of my knowledge, Wine arrives with no native DLLs at all, and thus one cannot remove any. Can you point to a bug report you might tag as purist, so we can all get on the same page? Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: Purist keyword?
On Saturday, October 30, 2010, Shachar Shemesh shac...@shemesh.biz wrote: On 30/10/10 19:25, Austin English wrote: I meant bugs that only occur by manually removing native dlls. The report summaries are usually clear enough, I was hoping to get an easy way to search for them and separate them from 'normal' bugs. I suspect your use of the word native is different than the one defined by Wine (see, for example, http://www.winehq.org/docs/wineusr-guide/config-wine-main). Native DLLs, in Wine, are DLLs that come from a real Windows system. This as opposed to built-in DLLs, that are DLLs compiled for Wine as winelib, carrying the .dll.so extension. No, I mean native. Some applications install native redistibutables, e.g. msvcr80 or d3dx9_36. To the best of my knowledge, Wine arrives with no native DLLs at all, and thus one cannot remove any. Can you point to a bug report you might tag as purist, so we can all get on the same page? Sure. I forget not everyone follows wine-bugs, so this was unclear. See http://bugs.winehq.org/show_bug.cgi?id=24510. Blur runs out of the box, but if you remove the bundled native dll (being a purist) the game fails, because wine is missing a dozen or so functions. There are several similar bugs. -- -Austin
Re: Purist keyword?
Hi Austin, 2010/10/30 Austin English austinengl...@gmail.com: On Saturday, October 30, 2010, Shachar Shemesh shac...@shemesh.biz wrote: On 30/10/10 19:25, Austin English wrote: I meant bugs that only occur by manually removing native dlls. The report summaries are usually clear enough, I was hoping to get an easy way to search for them and separate them from 'normal' bugs. I suspect your use of the word native is different than the one defined by Wine (see, for example, http://www.winehq.org/docs/wineusr-guide/config-wine-main). Native DLLs, in Wine, are DLLs that come from a real Windows system. This as opposed to built-in DLLs, that are DLLs compiled for Wine as winelib, carrying the .dll.so extension. No, I mean native. Some applications install native redistibutables, e.g. msvcr80 or d3dx9_36. To the best of my knowledge, Wine arrives with no native DLLs at all, and thus one cannot remove any. Can you point to a bug report you might tag as purist, so we can all get on the same page? Sure. I forget not everyone follows wine-bugs, so this was unclear. See http://bugs.winehq.org/show_bug.cgi?id=24510. Blur runs out of the box, but if you remove the bundled native dll (being a purist) the game fails, because wine is missing a dozen or so functions. There are several similar bugs. I really don't see what 'purist' adds, if a game fails because a builtin dll is missing a function, why would it matter if the game installs a native dll by default or not? The bug is still in the builtin dll, whether you use the builtin dll or not. ;) Cheers, Maarten
Re: Added TokenOwner and TokenPrimaryGroup cases to NtSetInformationToken.
On 10/30/2010 06:12 AM, Sami Aario wrote:
Added TokenOwner and TokenPrimaryGroup cases to NtSetInformationToken.
From: Sami Aario sae...@hima.(none)
Your e-mail isn't set correctly in git configuration.
dlls/ntdll/nt.c| 63
include/wine/server_protocol.h | 18 +++-
server/protocol.def|6
server/request.h |5 +++
server/token.c | 36 +++
server/trace.c | 10 ++
Please don't include changes to automatically generated files
(server_protocol.h, request.h, trace.c).
+SERVER_START_REQ( set_token_sid )
+{
+SID *sid = ((TOKEN_OWNER *)TokenInformation)-Owner;
+WORD size;
+
+if (sid) size = RtlLengthRequiredSid(sid-SubAuthorityCount);
+else size = 0;
+
+TRACE(size=%d\n, size);
+
+req-handle = wine_server_obj_handle( TokenHandle );
+req-which_sid = TokenInformationClass;
+wine_server_add_data( req, sid, size );
+ret = wine_server_call( req );
+}
+SERVER_END_REQ;
Please get everything outside of SERVER_START_REQ()/SERVER_END_REQ except
actual wine_server function calls and handling of returned result(s). Some
functions can do their own server calls and you will have a deadlock.
+case TokenOwner:
+free( token-user );
+token-user = NULL;
+
+if (sid_len)
+token-user = memdup( sid, sid_len );
+break;
This is wrong, you can't clear token user - it always have to be set, or you
risking an assert in get_token_sid. Which means you have to validate the
data user passes in.
Vitaliy.
