Re: Governance revisited (Wineconf report)
Andreas Mohr wrote: > And exactly this information should probably be stated in the wine-patches > subscription welcome mail. > > "If for some reason the Wine patches you submit fail to get applied, > then we'd appreciate you taking the effort of submitting your current patch > as a new item at bugzilla to help us track your work properly until it's > fully applied." > > Or, for improved visibility, even state this in the footer of every > wine-patches mail > sent (probably bad idea, though). > > Oh, and a DNS alias (or preferrably forwarder) bugzilla.winehq.org might be > useful (after all it's quite common to have that site name, see e.g. > bugzilla.kernel.org or bugzilla.mozilla.org etc.). > This would be an excellent idea - it would simply highlight the fact that there is an alternative route to providing visibility for patches that are not accepted. I must admit I had always thought of bugzilla as a bug-reporting mechanism and I hadn't thought of using it in this manner: to open a bug specifically in order to present your own fix! John.
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 no
OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
I was interested to read several comments on this list in respect of such comments as 'IQ of zero'. Such comments were the final straw in leading me to take this action. A few days ago I sent a comment to the list. Nothing really sinister, just an observation and an experience. Before long I had a particularly vicious and vile diatribe sent in reply to my comment - to my private email address. I have appended the lower headers and the bulk of the message I received at the end of this message (trimming the html from the bottom). I thought long and hard before taking this action. It is not something I would normally do, but in this instance I was so incensed at this individual's behaviour that I felt that 'naming and shaming' was the only way forward. Not even so much as to the fact that he directed his comments to me, but more the fact that had I been a new prospective developer, the effect such diatribe would have would not in any way be positive. It certainly would taint their perception of the open-source community. Furthermore I sincerely doubt that I am the only one to experience this behaviour. Others may just suffer in silence. I have worked with many smaller community projects, on OS/2 and latterly on Linux, and never been subjected to this kind of abuse from members of the community. I joined this list because I felt that there was something I could contribute to Wine, and in the instance it turned out that there was. I did not join it to receive unsolicited email of an abusive nature from members of the community. Had he done this by telephone I could have had him prosecuted, at least in the UK. But he hides behind a gmail.com address and makes comments I seriously suspect he would not have the balls to say to my face. No, I do not believe that we need a 'net police force'. Common decency between individuals, however, is essential. Diversity, discussion, criticism, expression, even annoyance are all valuable when driving a project forward. Blatant personal abuse is not tolerable. It is not tolerable in society, it should not be tolerated in the developer community. The community needs to police itself, rather than be policed, and individuals who bring the community into disrepute need to be dealt with by the community. That is why I bring this into the open. How to prevent such actions? I do not think it that this is possible in its entirety. I can (and have) simply add this individual's address to my blocked list. However, I may have been a newcomer to open-source development who would not have been so tolerant, and whose opinions of the community may have been changed by this action. May I suggest that whoever is responsible for the hosting of the mailing list change the configuration so that email addresses are not placed in the header? (I am no expert on mailing-list software but it does not immediately seem to be impractical.) That way all replies have to go to the list and this would prevent such unsolicited email being sent. This is my last word on this matter. Make of it what you will. I refuse to be prevented from contributing to vital projects such as Wine when I can by the antics of some depraved individual. It has left a sour taste in my mouth though, and like it or not, it does not portray Wine developers in a good light. --- Disposition-Notification-To: Segin <[EMAIL PROTECTED]> Date: Fri, 24 Mar 2006 15:01:11 -0500 From: Segin <[EMAIL PROTECTED]> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051202) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dr J A Gow <[EMAIL PROTECTED]> Subject: Re: Winetools -> wine doors References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> Content-Type: multipart/alternative; boundary="010900050103010506060607" X-BV-Spam-Score: 0.4 (/) X-Envelope-From: [EMAIL PROTECTED] X-Virus-Scanned: by amavisd-new This is a multi-part message in MIME format. --010900050103010506060607 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dr J A Gow wrote: > >> I've looked through the winetools code and it is a clusterf*ck of >> nonsense. It appears to be in the final stages of code rot, however > > > This "clusterf*ck of nonsense" helped me to get a microcontroller > development suite running under Wine, which otherwise would not install You're a fucking retard, RTFM! You'd learn you need to use DLLOverrides in Winecfg. > natively. After over ten years designing and developing embedded systems, > there is one thing that stands out. That you're a dumbfuck? > Code that is 'nonsense' does not work > at all. That's 100% definitive of Winetools. > Code that works may not
Re: Winetools -> wine doors
Karl Lattimer wrote: Fair point that it has been useful to you, it has been useful to me also. Here's what I see. * An over complicated bash script, with way too many difficult to maintain parts * An inflexible application, which can only have new applications added to it by the maintainer * A terrible confusing GUI My choice of words was strong I admit, but I think this application is ready to go to silicone heaven. Your points are quite true. I was only really pointing out that something that enables individuals to Get Work Done Quickly (however bad the tool might be technically) is of considerable value. That, of course, does not mean that the tool shouldn't be replaced when it starts to suffer from 'bit-rot'. But let's not completely can it until a viable replacement is available otherwise we could undermine the perceived 'usefulness' of Wine when it comes to a necessary rush-job. I should add I don't use Winetools as a matter of course - I used it once to get me out of a hole, and it did! What I am proposing and indeed working on is; * An appdb integrated application manager * A clean UI which fits with gnome HIG * A flexible, expandable, small and simple application which is easily maintained but can do everything winetools does. This sounds like an excellent idea. Maybe nostalgia will keep some people using winetools, or trying to fix something which is broken. Or maybe a couple people could lend a hand with this and we could have something better ;) K,
Re: Winetools -> wine doors
I've looked through the winetools code and it is a clusterf*ck of nonsense. It appears to be in the final stages of code rot, however This "clusterf*ck of nonsense" helped me to get a microcontroller development suite running under Wine, which otherwise would not install natively. After over ten years designing and developing embedded systems, there is one thing that stands out. Code that is 'nonsense' does not work at all. Code that works may not be elegant, it may not be pretty and you may hate the style, but it _works_ and therefore it is not nonsense. This code works, is useful and serves a purpose. Just because you don't like the way it is written does not make it nonsense. Language, please! John.
Recently created font problem - anyone see similar?
Hi,
I found that the following patch, committed to CVS on 23/02/06
at 20:33:06 made all my Wine system fonts squashed up and unreadable, which
in turn made a mess of formatting in some dialog boxes. I backed the
patch out from a current tree and the problem went away. Anyone else see
this behaviour? I am wondering what the purpose of this patch is as
the fonts were quite OK before it was committed, and now they are
completely unreadable on this system. Any thoughts before I submit a
patch to put this back the way it was?
John.
The offending patch:
Module: wine
Branch: refs/heads/master
Commit: 69a23a608eea59624b2f37ab424e0f42b3da5baf
URL:
http://source.winehq.org/git/?p=wine.git;a=commit;h=69a23a608eea59624b2f37ab424e0f42b3da5baf
Author: Dmitry Timoshkov
Date: Thu Feb 23 20:33:06 2006 +0800
gdi: Use "MS Sans Serif" as default sans serif font, not Arial.
---
dlls/gdi/freetype.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dlls/gdi/freetype.c b/dlls/gdi/freetype.c
index ad0d6eb..51e92b8 100644
--- a/dlls/gdi/freetype.c
+++ b/dlls/gdi/freetype.c
@@ -284,10 +284,10 @@ static struct list font_list = LIST_INIT
static const WCHAR defSerif[] = {'T','i','m','e','s',' ','N','e','w',' ',
'R','o','m','a','n','\0'};
-static const WCHAR defSans[] = {'A','r','i','a','l','\0'};
+static const WCHAR defSans[] = {'M','S',' ','S','a','n','s','
','S','e','r','i','f','\0'};
static const WCHAR defFixed[] = {'C','o','u','r','i','e','r','
','N','e','w','\0'};
-static const WCHAR defSystem[] = {'A','r','i','a','l','\0'};
+static const WCHAR defSystem[] = {'S','y','s','t','e','m','\0'};
static const WCHAR SystemW[] = {'S','y','s','t','e','m','\0'};
static const WCHAR MSSansSerifW[] = {'M','S',' ','S','a','n','s',' ',
'S','e','r','i','f','\0'};
Re: Patch: fix for bug #4436 with associated fixes for stream reference counting
Thanks for the comments. Patch now resubmitted as two chunks as suggested. John. Mike McCormack wrote: Dr J A Gow wrote: FROM: Dr J A Gow PATCH: Provides fix for bug 4436, some reference counting fixes, and now the IStorage correctly handles the following: - Stream opening when storage was opened in transacted mode - Stream methods called after parent object has been closed correctly return STG_E_REVERTED - Adds conformance test for stream opening in transacted mode Looks great, however we usually try to keep seperate fixes seperate so that regression testing is easier, and to reduce the size and complexity of each patch. If you could split these two patches into one for the transacted storage/stream permissions problem, and one for the reference counting problem I'm think they'll be committed without further trouble. thanks, Mike
Re: Regression problems in Easy-PC - UPDATE: Have conformance test that triggers reference counting bug in ole32.dll
Dr J A Gow wrote: It is as I thought that there is some issue with the object destructor for the storage object being called and not actually releasing the object. I have attached the complete patch to the tests for storage32 to I have just had another thought on this and wonder if anyone could confirm it: Shouldn't destruction of the parent IStorage object automatically destroy all IStream objects opened within it? This seems to be the way Windows works as far as I can tell so far. Wine does not do this, requiring all child IStreams to be closed before the final call to the destructor of IStorage will actually release the memory (and file) associated with it. Any ideas? John.
Re: Regression problems in Easy-PC - UPDATE: Have conformance test that triggers reference counting bug in ole32.dll
Hello All,
I wrote this some time ago:
Dr J A Gow wrote:
Hello All,
I have some regression problems relating to Wine in a commercial ECAD
app 'Easy-PC' version 9.0, available from http://www.numberone.com
Since then I have been doing some more digging into the problem and have
come up with a test that triggers the bugs: i.e. passes on Windows and
fails on Wine (latest CVS). Looking at the failure mode I feel that it
has the potential to break a _lot_ of apps.
It is as I thought that there is some issue with the object destructor
for the storage object being called and not actually releasing the
object. I have attached the complete patch to the tests for storage32 to
this message if anyone could try it I would be grateful, but I will just
describe some of the reasoning behind it first.
It seems that the problem is not the grfMode with which the file is
opened, but a reference counting method used within storage32. A call to
the destructor of the storage object is not destroying the object - with
it left open the error appears when a subsequent call to open the
storage object fails with access issues because the previous one is left
open. So, I introduced this test that exactly mimics the behaviour of
the app. To do this, I needed a storage object that contained a stream,
so I wrote code in the appropriate conformance test module to create one:
r = StgOpenStorage( filename, NULL, STGM_TRANSACTED | STGM_WRITE |
STGM_SHARE_DENY_WRITE, NULL, 0, &stg);
ok(r==S_OK, "StgOpenStorage failed\n");
if(stg)
{
static const WCHAR stmname[] = {
'w','i','n','e','t','e','s','t',0};
IStream *stm = NULL;
r = IStorage_CreateStream( stg, stmname, STGM_WRITE |
STGM_SHARE_EXCLUSIVE,
0, 0, &stm );
ok(r == S_OK, "CreateStream should succeed\n");
if(stm) {
r=IStorage_Commit(stg,STGC_DEFAULT);
ok(r==S_OK, "StorageCommit failed\n");
}
// Windows reference counting seems different
r = IStorage_Release(stg);
ok(r == 0, "wrong ref count"); printf("- ref count = %lx\n",r);
if(r) {
r = IStorage_Release(stg);
ok(r == 0, "wrong ref count"); printf(" - ref count = %lx\n",r);
}
}
It was here where I got the surprise! I expected this code to work on
both Wine and Windows, so the next part of the patch could trigger the
bug. However I found that on Windows, the first call to IStorage_Release
returns zero, and the storage object is destroyed. Under Wine however,
the first call to IStorage_Release returns 1 but does not destroy the
object - the second call to IStorage_Release returns zero and destroys
the object. It appears that Windows takes no notice of reference counts
when the IStorage destructor is called! I only discovered this because
in the original test code I had two calls to IStorage_Release straight
after each other without the if(r) test: and although it worked on Wine
it segfaulted on Windows due to the 'stg' object being destroyed on the
first call. This proved the difference in behaviour.
Now on to the second part of the test, that attempted to re-open the
closed storage object, then open the stream within it:
/* Easy-PC test 2 - this looks for the OpenStream mode check. Fails
under Wine */
r = StgOpenStorage( filename, NULL, 0x00010020, NULL, 0, &stg);
ok(r==S_OK, "StgOpenStorage failed\n");
if(stg)
{
static const WCHAR stmname[] = {
'w','i','n','e','t','e','s','t',0};
IStream *stm = NULL;
r = IStorage_OpenStream( stg, stmname, 0,
STGM_SHARE_EXCLUSIVE|STGM_READWRITE, 0, &stm );
ok(r == S_OK, "OpenStream should succeed - "); printf("rc from
OpenStream : %lx\n",r);
r = IStorage_Release(stg);
ok(r == 0, "wrong ref count\n");
}
Again, this works on Windows, but the OpenStream call fails with an
access denied error on Wine. This is the exact mode of the bug in the app.
Could one of the ole32 developers please contact me: I am happy to work
with them to resolve this problem as I need this app to work under Wine,
but not being a Windows programmer I am not fully familiar with the
storage API. In the meantime I will continue my investigation and see if
I can fix this directly, but I am sure it will happen sooner if I could
work with the ole32 developer.
Many thanks for listening. The patch is below, I will submit this for
inclusion in CVS.
John.
Index: wine/dlls/ole32/tests/storage32.c
==
Re: Regression problems in app - help with debugging?
Thanks for the advice Dan. I have done this now, and the bug report is entered into the database as bug #4436. As I say I am more than happy to help the developers debug this, providing someone can work with me in respect the operation of this portion of the userland Win32 API with which I have very limited experience. John. Dan Kegel wrote: Smashing analysis! You might want to repost your note as a bug report at http://bugs.winehq.org. Set the 'component' field of the report to wine-ole, and put 'download' in the 'keyword' field. This will get the attention of the right folks somewhat more reliably than a post to wine-devel. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Regression problems in app - help with debugging?
Hello All,
I have some regression problems relating to Wine in a commercial ECAD
app 'Easy-PC' version 9.0, available from http://www.numberone.com
The application was quite usable on Crossover Office 4.2, with just some
minor dialog corruption. Alpha versions of Wine available at the same
time (can not exactly remember which ones) could also run it
successfully. However, under the latest Wine 0.9.6, Wine CVS and CXO
5.0.1 it does not work. Note that it does not crash, it errors out
cleanly with a dialog box message.
I have been debugging the problems in this app for some time now. It is
a critical app for me as I use it in a production environment, but I do
not want to pay Microsoft for the privilege of exposing my machine to
malware. I am thus prepared to help debug Wine to get this application
running. However, my Windows programming experience is limited to device
drivers, not apps (although fluent C/C++ systems programming on other
platforms), I have hit a brick wall, possibly due to my limited
knowledge of how the Windows API works and I will need some help with this.
If anyone would like to help me debug this app (hope springs eternal!),
a demo version of the app is available free of charge from the web site
address above, and this version exhibits the same problems as the full
version.
Background
-
The system: Dual physical processor (not dual core) Opteron running SuSE
10.0 x86_64 SMP.
Wine: Latest 0.9.6 release, up to CVS grabbed a week or so ago.
The application installs OK and when run, puts up a GUI as expected.
However, when you try to create a new PCB or schematic, an error dialog
box is displayed indicating that the app can not read the technology
file Default.stf (schematic) or Default.ptf (pcb). This is _not_ a
permissions problem, all files are actually present and the same install
will work under CXO 4.2.
I generated and analyzed several hundred MB of logfiles over many days,
added extra debug statements to the Wine code and analyzed the
application's operation. The problem actually appears to have two
causes, and this is what I have come up with so far.
Problem 1
---
Application calls StgOpenStorage with a grfMode flag of 0x10020
(STGM_TRANSACTED | STGM_SHARE_DENY_WRITE). Immediately afterwards it
calls StorageBaseImpl_OpenStream with a grfMode of 0x12
(STGM_SHARE_EXCLUSIVE | STGM_READWRITE). This second call fails with an
access denied error code, after which the logs show an easily traced
error handling sequence leading to display of the error dialog mentioned
above:
0009:Call ole32.StgOpenStorage(59693db0 L"c:\\Program Files\\Number One
Systems\\Easy-PC\\Technology\\Default.ptf",,00010020,,,5821f850)
ret=1022e7f0
...
...
trace:storage:StgOpenStorage <-- , IStorage 0x5b3465f8
0009:Ret ole32.StgOpenStorage() retval= ret=1022e7f0
...
...
trace:storage:StorageBaseImpl_OpenStream (0x5b3465f8, L"\0005FileType", (nil),
12, 0, 0x5821f848)
fixme:storage:StorageBaseImpl_OpenStream STORAGE ACCESS DENIED - parent 0, this
2
Note that the last fixme is one I added to find out exactly what was
going on here. Now, logic would dictate that the grfMode of the
OpenStream method call is indeed incompatible with that of its parent
storage object. However, I would have thought that the application
coders would most likely have hard-coded the grfMode flags in the
application. If so, it would seem that the app is buggy, yet this
application works on Windows! Either the app is buggy and the Win32
OLE32 implementation behaves differently, or I am missing something here.
Ok, so with no obvious solution to this problem, I decided to bypass it.
I modified the storage32.c implementation in the following way to bypass
the grfMode check:
parent_grfMode = STGM_ACCESS_MODE( This->ancestorStorage->base.openFlags );
*if* ( STGM_ACCESS_MODE( grfMode ) > STGM_ACCESS_MODE( parent_grfMode ) )
{
FIXME("StorageBase_OpenStream called with grfMode mismatch - parent %d, this
%d\n",
parent_grfMode,STGM_ACCESS_MODE(grfMode));
///res = STG_E_ACCESSDENIED;/
///goto end;/
}
Obviously not a viable fix, but a hack to get it working. After
implementing this, the OpenStream call succeeded, as did subsequent
stream access. However, the app _still_ errored out in exactly the same
manner and at the same time. After more log searching, this led to the
discovery of the second problem.
Problem 2
---
During its loading and setup, the application repeatedly calls
StgOpenStorage on the .stf/.ptf files in question, calls OpenStream,
reads from the stream, and then finally closes the storage. I placed
tell-tales in useful locations in the file open/close handlers in the
wineserver, and could clearly see the files being opened and
subsequently closed. This open/read/close occurs correctly and in
sequence up to a certain point. At this point in the execution, th
