Re: DIB Engine - Separated in small patches
Roderick Colenbrander ha scritto: As requested I separated the engine in small patches, trying to keep original authors when possible. As the post didn't appear here (problem with zipped files, maybe ?), I've put it on bug 421 page. I whish to know if it can be ok for including on wine tree. Ciao Max Getting large patches into Wine takes time especially drastic changes like the DIB engine. Well, gdi32 part isn't that drastic with engine disabled is totally transparent Recently I aksed him about this DIB work on IRC and while he didn't check the patches in much detail yet he has huge doubts whether the chosen design is the good one. (Allen his design wasn't good; Huw his design was better) Mine IS Huw design with some small changes. The changes are mostly related to when the engine is loaded and to make it transparent to GDI32 when not loaded. I would recommend to invite all the people interested in a DIB engine (Alexandre, Allen, Huw and perhaps others) for a meeting on IRC to discuss the current design and how to proceed. Ok, I'll do it :-) Thank you for answer Max Roderick
"remote" start/stop of relay/snoop output
I asked that question some years ago, and IIRC then it was not possible, so I resorted to add an external filter app in order to start/stop relays on an already running app. Filter app solved partially the problem : I could get the relay part I needed, but the speed was about the same as dumping the full relay on file. Now (as it was years ago for autocad r14...) I'm trying to trace some calls in autocad2005, but relay log becomes easily 10-20 GB in size, so quite useless. I think the log start/stop feature could be a *very* useful way to isolate needed relay part and to speed up tests. Is it still not possible nor faisible ? Max
Re: Path reset on wine update
THE 'path', the one set in window's environment, the one windows uses to look for executables. Upon wine update, when wineprefix gets updated the path is reset to default one (IIRC c:\\windows;c:\\windows\\system32) I didn't open a bug because I don't know if it's a bug or a required behaviour. For me it's just annoying. Max Vitaliy Margolen ha scritto: > Massimo Del Fedele wrote: >> Maybe that's an already asked question, but why does wine reset >> path on each wine update ? That's becoming annoying... I mus reedit >> registry on each update to make my apps work again. >> > Which "path" are you talking about? Please open a bug. > > Vitaliy > >
d3d11 patch
Hi, I would like to know when the first patchs for d3d11 will be introduce into wine ? Beginning of 2014 ? middle 2014 ? End 2014 ? Thanks,
RE: d3d11 patch
Hum... WIR= When it's ready ??? Ok ok, i still wait > From: frederic.dela...@gmail.com > Date: Sun, 13 Oct 2013 01:49:04 +0200 > Subject: Re: d3d11 patch > To: asnl...@hotmail.com > CC: wine-devel@winehq.org > > On Fri, Oct 11, 2013 at 7:20 PM, Max . wrote: > > Hi, > > > > I would like to know when the first patchs for d3d11 will be introduce into > > wine ? > > Beginning of 2014 ? middle 2014 ? End 2014 ? > > > > Thanks, > > WIR
Re: [PATCH] Label verbosity levels.
From: max
On 03/19/2011 08:42 PM, Joris Huizer wrote:
> On 03/19/2011 11:32 PM, Vitaliy Margolen wrote:
>> On 03/18/2011 09:24 PM, m...@mtew.isa-geek.net wrote:
>>> - if ($opt_verbose> 0)
>>> - {
>>> -print "Processing ".$spec_name."\n";
>>> - }
>>> + print "Processing ".$spec_name."\n"
>>> +if $opt_verbose q>= $VERBOSE_INPUT;
>>
>> Please don't do this reverse notation. It's much more confusing to most
>> people who are not too familiar with Perl.
>>
>> Also you changing logic, by replacing ">" (greater then) with ">=" (greater
>> of equal. This is a big no-no to combine any logical changes with cleanup
>> changes.
>
> This doesn't seem to change logic as $VERBOSE_INPUT equals 1 ( $VERBOSE_QUIET
> equals 0 )
>
Correct. The clean-up involves two counter-acting logic changes. The change
from > to >= is
countered by increasing the target number by one. The result is that the number
itself has the
designated meaning. Before the number was one less than level needed to change
the affect.
There is no _functional_ change.
The suffix logical form is not that difficult to understand. It shifts the
emphasis from the
conditional as the thing of primary import to the message being conveyed, where
it belongs.
On the other hand if anybody can come up with better names for the levels,
PLEASE comment!
Max
Trailing white space and other pedantry.
From: Max TenEyck Woodbury I have been working on the documentation extraction problem and code analysis problem. I have made some progress with the program I am writing to do this. It reads the same files as c2man.pl does, but does a more detailed parse of the code. In fact, it even reads and processes all the include files. It is far from complete at this time, but it does produce interesting warnings. One of the warnings reports lines with trailing while space. It has turned up quite a few places where this occurs. If I understand the preferred style, there should not be trailing white space. The question I have is what should I do with them. I can either fix the files or turn that particular warning off. So far, I have been fixing the files on a local copy of the repository. Should I turn the fixes into patches and submit them, or just keep them to myself? Another problem the program warns about is incompatible macro redefinitions. In a few places the differences are just white space, and I have made local fixes. In other places, the differences are more substantial and there are two basic options available. The more difficult solution is to change the definitions in wine to make them compatible with the rest of the system. This could cause problems for people with different system configurations. The other solution is to simply #undef the macros before redefining them. Should I turn the simple fixes into patches and submit them? Should I submit the other problems as bug reports? Max
Re: Trailing white space and other pedantry.
On 05/16/2011 01:00 PM, André Hentschel wrote: Am 16.05.2011 18:34, schrieb m...@mtew.isa-geek.net: From: Max TenEyck Woodbury I have been working on the documentation extraction problem and code analysis problem. I have made some progress with the program I am writing to do this. It reads the same files as c2man.pl does, but does a more detailed parse of the code. In fact, it even reads and processes all the include files. It is far from complete at this time, but it does produce interesting warnings. One of the warnings reports lines with trailing while space. It has turned up quite a few places where this occurs. If I understand the preferred style, there should not be trailing white space. The question I have is what should I do with them. I can either fix the files or turn that particular warning off. So far, I have been fixing the files on a local copy of the repository. Should I turn the fixes into patches and submit them, or just keep them to myself? No, white space only changes will not be accepted. Your are right about the preferred style, but most likely the regarding code is a bit old. new code should never have trailing white space. The best reason is "git blame" to see who wrote the code, i think that makes it clear. I understand that white space only patches will not be applied. Will they be applied if they accompany other corrections? Also, please address the other questions. Should I submit patches against simple errors in macro definition formatting? There are some places where my program catches mismatches that SOME other compilers might ignore. There are also some places in the wine headers where macros are redefined differently from the headers provided by the system or compilers I have installed. There are also cases where the macros are defined differently by different wine headers. Because these problems may depend on my system configuration, I believe it might not be possible to simply patch these definitions match the configuration I have. The problems CAN be fixed simply by adding #undef before each redefinition, but I think a review of these changes might be in order. They seem to occur in batches, with none in most headers and multiple messes in others. Should I submit each correction as a separate patch, separate patches accompanying separate bug reports, combined patches for a given header or combined patch and bug report? Max
Re: Trailing white space and other pedantry.
On 05/16/2011 09:39 PM, Ken Thomases wrote: On May 16, 2011, at 7:42 PM, max wrote: On 05/16/2011 01:00 PM, André Hentschel wrote: I understand that white space only patches will not be applied. Will they be applied if they accompany other corrections? If one would otherwise have modified a line in the course of doing development, then one can and should fix an issue like trailing whitespace on that line. If the line would not have been changed except for the whitespace issue, then it shouldn't be changed. Also, please address the other questions. Well, he might not have known the answer to or had an opinion about the other questions. Should I submit patches against simple errors in macro definition formatting? There are some places where my program catches mismatches that SOME other compilers might ignore. There are also some places in the wine headers where macros are redefined differently from the headers provided by the system or compilers I have installed. There are also cases where the macros are defined differently by different wine headers. Because these problems may depend on my system configuration, I believe it might not be possible to simply patch these definitions match the configuration I have. The problems CAN be fixed simply by adding #undef before each redefinition, but I think a review of these changes might be in order. They seem to occur in batches, with none in most headers and multiple messes in others. Am I understanding correctly that these are whitespace difference again? Maybe you could provide an example of what you mean. To my knowledge the mismatches you have identified have never actually caused problems. Until they do, I expect that fixes for them won't be accepted. Also, when they do, that will probably help guide which of your proposed solutions is preferred. FYI: Scanning (C) source file 'dlls/atl/atl_ax.c'. --Warning: Trailing white space at dlls/atl/atl_ax.c:991. --Warning: Trailing white space at dlls/atl/atl_ax.c:1005. --Warning: Trailing white space at dlls/atl/atl_ax.c:1027. --Warning: Trailing white space at dlls/atl/atl_ax.c:1042. --Warning: Trailing white space at dlls/atl/atl_ax.c:1131. --Warning: Trailing white space at dlls/atl/atl_ax.c:1141. --Warning: Trailing white space at dlls/atl/atl_ax.c:1245. Scanning (C) source file 'dlls/atl/registrar.c'. --Warning: Trailing white space at dlls/atl/registrar.c:206. --Warning: Trailing white space at dlls/atl/registrar.c:213. --Warning: Trailing white space at dlls/atl/registrar.c:243. --Warning: Trailing white space at dlls/atl/registrar.c:380. --Warning: Trailing white space at dlls/atl/registrar.c:525. --Warning: Trailing white space at dlls/atl/registrar.c:597. Should I submit each correction as a separate patch, separate patches accompanying separate bug reports, combined patches for a given header or combined patch and bug report? Hard to say without an illustration of what you're talking about. In the simple cases, they would produce compiler warnings, not functional issues. In other cases, there are differences that I expect do not show up because the wine project does not use the macro, but could cause application programmers grief. For example: Scanning (C) source file 'dlls/advapi32/service.c'. ==Error: Attempt to change the definition of macro '__attribute__' at line 88 of include/wine/exception.h ignored. Originally defined at /usr/include/sys/cdefs.h:203 Old:' ( xyz ) ' New:' ( x ) ' Scanning (C) source file 'dlls/avicap32/avicap32_main.c'. ==Error: Attempt to change the definition of macro 'IOC_OUT' at line 697 of include/winsock.h ignored. Originally defined at /usr/include/asm-generic/ioctl.h:91 Old:' ( _IOC_READ << _IOC_DIRSHIFT ) ' New:' 1073741824 ' ==Error: Attempt to change the definition of macro 'IOC_IN' at line 698 of include/winsock.h ignored. Originally defined at /usr/include/asm-generic/ioctl.h:90 Old:' ( _IOC_WRITE << _IOC_DIRSHIFT ) ' New:' 2147483648 ' ==Error: Attempt to change the definition of macro 'IOC_INOUT' at line 699 of include/winsock.h ignored. Originally defined at /usr/include/asm-generic/ioctl.h:92 Old:' ( ( _IOC_WRITE | _IOC_READ ) << _IOC_DIRSHIFT ) ' New:' ( IOC_IN | IOC_OUT ) ' ==Error: Attempt to change the definition of macro '_IO' at line 701 of include/winsock.h ignored. Originally defined at /usr/include/asm-generic/ioctl.h:74 Old:' ( type , nr ) _IOC ( _IOC_NONE , ( type ) , ( nr ) , 0 ) ' New:' ( x , y ) ( IOC_VOID | ( ( x ) << 8 ) | ( y ) ) ' ==Error: Attempt to change the definition of macro '_IOR' at line 702 of include/winsock.h i
Re: Glitch-free iTunes?
On 07/02/2011 03:46 PM, Keith Curtis wrote: Hi; Here is a rant about iTunes: http://www.pcworld.com/businesscenter/article/229398-2/day_3_dude_wheres_my_itunes.html You guys are doing great, but I think it would be better if you were to work more in priority order. There are 200M devices, last I checked. I don't think iTunes has ever properly worked in WINE. It seems like Apple keep revising it and so the current WINE never works with the current iTunes. Can you make a goal of supporting iTunes with no glitches? I know many of you are volunteers, but it is globally efficient if the installation number plays into the priority of the bugs. Just this one app could be huge for Linux on the desktop. Warm regards, -Keith Everyone (with very few if any exceptions) who works on Wine does so because they want to. Priorities are set by each person for themselves. That is simply a fact of life when it comes to community developed software. You are, of course, entitled to your opinion of what is important but you need to persuade rather than trying to command compliance with your wishes. One of the most effective ways to assure progress on a particular piece of Wine is to put your own effort into improving that particular piece. In the case of iTunes, one of the early steps would be to examine the log Wine produces when you try to install it or run it. This is likely to show that some particular function is not implemented or is not implemented properly. Next, write a test that demonstrates what should happen. Make sure it works on recent native Windows versions. Submit the new test as a patch. Then fix Wine so that it passes that test and does not fail any existing tests due to your changes. Once the test patch has been accepted, check that you changes to Wine pass the new test. Finally, submit your change to Wine. At that point there will be one less thing that keeps iTunes from running on Wine. Other things you need to keep in mind: 1. Does it run on Windows? iTunes is an Apple product and it could be that it has been intentionally implemented so that it does not run on Microsoft's OS. 2. Are there legal issues that would keep it from being run under Wine? 3. Assure that your code meets the Wine style.
Re: Glitch-free iTunes?
On 07/04/2011 02:15 PM, André Hentschel wrote: Am 04.07.2011 20:08, schrieb max: 1. Does it run on Windows? iTunes is an Apple product and it could be that it has been intentionally implemented so that it does not run on Microsoft's OS. Why then providing a Windowsversion??? :) So you are saying it runs on MS Windows. That answers the question. Thanks.
Re: use Lithuanian letter in my name
On 07/19/2011 03:54 AM, Frédéric Delanoy wrote: On Mon, Jul 18, 2011 at 23:53, Nerijus Baliunas wrote: --- AUTHORS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Maybe you should ensure that the name you commit your patches with (foo in 'foo') is correctly spelled as well. I believe the authors list is generated from wine git's patch authors Frédéric Having looked at some of the code that generates 'contributor' lists recently, (specifically tools/c2man.pl), the information is taken from the 'copyright' lines in the source files. At least in the case of c2man, the git logs are not consulted. Max
Re: [docs] winedev: Update code columns limit (resend)
On 07/23/2011 07:05 PM, James McKenzie wrote: On 7/23/11 3:33 PM, Andrew Eikum wrote: On 07/23/2011 05:02 PM, Francois Gouget wrote: On Mon, 4 Jul 2011, André Hentschel wrote: [...] -Code is usually limited to 80 columns. This helps prevent -mailers mangling patches by line wrap. Also it generally +Code is usually limited to 100 columns. It generally I'd prefer to keep the 80 columns recommandation. +1 I have never seen a terminal emulator that defaults to anything other than 80 columns. This limit exists because of the old Hollerith cards. You can set the width of your terminal session to whatever you want as a default. James The size of a Hollerith card is based on the size of a dollar bill at the time the standard was set. Dollars have shrunk in more than one sense since that time... Much more to the point is the number of characters that can fit on a (more or less) standard piece of paper. US standard paper is 8 1/2 inches wide and typewriter pitch was something like 10 characters per inch; with no margins, you get an 85 character line. Throw in 1/4 inch margins and you are down to 80. Similar calculations for A4 yield similar numbers. Other standard widths exist. 120 and 132 column formats have their traditional supporters. 72 columns is the usual text width on punched cards with 8 columns reserved for a sequence number field. (If you have ever dropped a 2000+ card program or data deck, you become a strong believer in sequence numbers!) So much for history. My personal preference is for an 80 column standard. That is large enough to allow a reasonable number of 4 column tab stops, and I can get two pages up on a good screen with some slack for scroll bars, boarders and other useful decorations. Wider and conflicts arise with the less expensive kinds of equipment. I've lived with the 80 column for more then 3 decades. It chafes a little at times, but ANY standard will irritate. Max 0112233445566778 123456789012345678901234567890123456789012345678901234567890
Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
On 08/03/2011 05:18 AM, Stefan Dösinger wrote: On Wednesday 03 August 2011 10:56:25 Michael Mc Donnell wrote: It is *technically* undefined, but all the compilers I have tested it on do the same thing. There may be a future compiler that behaves differently. You may get away with it right now, but it will cause pain in the rear sooner or later. (I didn't know bitfield layout is undefined, otherwise I wouldn't have advised you to keep using them) Technically they are 'implementation defined', not 'undefined', which means each compiler has to define them but different compilers may define them differently. Because different compilers DO define them differently, they are not portable. Since they are not portable, wine should not use them without cloaking them in macros that compensate for the differences. Which is a PITA. Has anybody done the cloaks already? Max
Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
On 08/03/2011 09:28 AM, Henri Verbeet wrote:
Well yes, it's implementation defined, not undefined. The point is
that there isn't necessarily any relation to endianness. Just use
shifts and masks.
Correct. It is a different issue from endedness.
But you can use configurable wrappers to cloak the compiler differences:
Meta procedure:
1) Write a test to determine which order bit fields are assigned in:
int main(){
union field_order { int an_int; int a_bit:1 } test;
test.an_int=0;
test.a_bit=1;
return test.an_int == 1;
}
which returns 0 if bit fields are allocated most significant bits
first, 1 otherwise.
2) Add a test to configure that checks the field allocation order.
Record the result of the test as LO_ORDER_FIRST or something.
3) Write some macros that hide the declaration order:
#if LO_ORDER_FIRST
#define BIT_FIELDS_2(a,b) a;b;
#define BIT_FIELDS_3(a,b,c) a;b;c;
#define BIT_FIELDS_4(a,b,c,d) a;b;c;d;
...
#else
#define BIT_FIELDS_2(a,b) b;a;
#define BIT_FIELDS_3(a,b,c) c;b;a;
#define BIT_FIELDS_4(a,b,c,d) d;c;b;a;
...
#endif
4) Constraint: The combined fields must have the same number of bits
as the underlying data type. For example, if 'int' has 32 bits, the total
size of all the fields in the group must be 32 bits.
THIS HAS PROBABLY BEEN DONE ALREADY!, you just have to dig it out
of the list of available configure tests.
max
(I'm in the middle of something else, otherwise, I'd dig it out myself...)
Re: GSoC-2011: Implement Missing Mesh Functions in Wine?s D3DX9
On 08/04/2011 12:36 PM, David Laight wrote:
On Thu, Aug 04, 2011 at 08:30:41AM -0400, max wrote:
On 08/03/2011 09:28 AM, Henri Verbeet wrote:
Well yes, it's implementation defined, not undefined. The point is
that there isn't necessarily any relation to endianness. Just use
shifts and masks.
...
union field_order { int an_int; int a_bit:1 } test;
test.an_int=0;
test.a_bit=1;
...
There are 4 likely values for test.an_int (1, 0x80, 0x8000, 0x0100),
and all might be generated regardless of the system endianness.
David
Hmm... 0x80 and 0x0100 would be very hard to handle. So hard in
fact that
I would consider any implementation that produced them to be broken, but
you're
right, THWI!
Max
Re: w9x testbot state?
Dmitry Timoshkov: If I understand the philosophy of Wine correctly, it is to provide an alternative to the Microsoft implementation of the platform. The criteria for success is that applications written to run on the current Microsoft platform can run on Wine. To that end mandatory support for the Windows 9X and other older versions was removed from the patch acceptance test procedure. The test procedures were also to be simplified when a change touched on one of the special cases where the special provisions for older versions was part of a test. However, certain things were not to be done: The ABILITY to test under older versions is to be retained. Such testing is no longer required, but the tests are supposed to be available on request. Simply removing support for older versions in tests is not sufficient reason for changing a test. Something else about the test has to change before there is justification of stripping out special case code. Gratuitous removal of support for older versions in the actual Wine code is not acceptable. There has to be a reason for breaking support of older applications. We are NOT trying to support Microsoft's effort to force their customers to upgrade to new versions of Microsoft's products. In fact, my understanding is that Wine is intended to provide an 'as good as or better' alternative to Microsoft. Efforts to improve Wine's ability to support current applications is very important, but supporting older applications is also useful. Max
[PATCH] msvcrt: fix character/byte confusion in buffer overflow branch
The first memcpy() call in puts_clbk_str_w() confuses character count
and byte count. It uses the number of characters (out->len) as number
of bytes. This leaves half of the buffer undefined.
Interestingly, the second memcpy() call in the same function is
correct.
This bug potentially makes applications expose internal (secret) data.
Usually, the destination buffer is on the stack, and the stack often
contains secrets. Therefore, one could argue that this bug
constitutes a security vulnerability.
---
dlls/msvcrt/printf.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/msvcrt/printf.h b/dlls/msvcrt/printf.h
index cfba4b7..8b749bc 100644
--- a/dlls/msvcrt/printf.h
+++ b/dlls/msvcrt/printf.h
@@ -48,7 +48,7 @@ static int FUNC_NAME(puts_clbk_str)(void *ctx, int len, const
APICHAR *str)
return len;
if(out->len < len) {
-memcpy(out->buf, str, out->len);
+memcpy(out->buf, str, out->len*sizeof(APICHAR));
out->buf += out->len;
out->len = 0;
return -1;
Re: [PATCH] msvcrt: fix character/byte confusion in buffer overflow branch
On 2013/05/07 17:46, Juan Lang wrote:
> In general, I think you want to send this to wine-patches, not here.
True, I resent it to wine-patches yesterday already, when I noticed
that.
> > if(out->len < len) {
> > -memcpy(out->buf, str, out->len);
> > +memcpy(out->buf, str, out->len*sizeof(APICHAR));
> > out->buf += out->len;
> >
>
> If the memcpy was incorrect, the += is also incorrect. I'm not sure which
> is the case, but either way, your patch can't be correct as is.
Sure?
out->buf is an "APICHAR*" (see printf.h), and adding out->len advances
the pointer by "out->len * sizeof(APICHAR)" bytes.
Am I missing something?
Max
Re: Bugzilla upgrade - opening attachments in browser
Hey Jeremy. The allow_attachment_display parameter has a detailed
description that notes that you are opening a security hole if you set
it without setting another parameter (which you haven't set). Did you
read the description of the parameter?
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Re: Bugzilla upgrade - opening attachments in browser
Hey Jeremy. Which parameter, attachment_base or
allow_attachment_display? And do you mean that you unset the
cookiedomain parameter, or...? (Usually cookiedomain shouldn't be set at
all.)
-Max
Jeremy Newman wrote:
The parameter has been set, as well as the cookie domain param.
-Newman
Max Kanat-Alexander wrote:
Hey Jeremy. The allow_attachment_display parameter has a detailed
description that notes that you are opening a security hole if you set
it without setting another parameter (which you haven't set). Did you
read the description of the parameter?
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Some Questions From The Bugzilla Project
Hey there Wine Bugzilla folks. I've been funded by the Mozilla Foundation to do a survey of the major Bugzilla-using organizations in the world, to find out what people like and don't like about Bugzilla, what we could improve, what changes you'd like to see in Bugzilla, etc., and you guys are one of the organizations picked for the survey. :-) The Bugzilla Project is going to use this information to prioritize its work on future releases, and we may even be able to get a grant from the Mozilla Foundation to work on some of the most popular or pressing issues. In other words, what you say here will really matter. I was wondering--who's the best contact there who I could ask a few questions to about how you guys use Bugzilla? It'd just be over email, unless you want to do it over IRC or on the phone. (Oh, and make sure you reply to me directly, since I'm not on the list.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Re: Some Questions From The Bugzilla Project
On Tue, 24 Jun 2008 11:18:25 -0500 "James Hawkins" <[EMAIL PROTECTED]> wrote: > Can we do this in an open forum like wine-devel instead of having one > point of contact? I think we all have particular issues with bugzilla > that we don't necessarily communicate to the project. Having said > that, I think it's great that the Bugzilla Project is getting feedback > from the open source community, and I'm glad we're one of the projects > you would like input from. Yeah, you can gather the information in an open forum. I can give you guys the questions and you can get the information and put it up on a Wiki or compile it into a single email and all, if you want. On Tue, 24 Jun 2008 11:21:09 -0500 "Austin English" <[EMAIL PROTECTED]> wrote: > Administrators would be Dan Kegel, Jan Zerebecki, Jeremy Newman, and > Tony Lambregts. > > A few of the devs/volunteers frequently triaging/verifying/etc. would > be Dmitry Timoshkov, James Hawkins, Louis Lenders, Vitaliy Margolen > and myself. Okay. Well, here are the questions, and you guys can come to a decision on how you want to do the research or answer them. I'd definitely be interested in having feedback from all the different aspects of the community, triagers, developers, administrators, etc. What version of Bugzilla are you currently running? What problems do you have with Bugzilla? (What are the most commonly experienced or reported problems, what are the most major problems?) What features of Bugzilla do you use the most at your organization, besides standard HTML bug searches, bug filing, and HTML bug viewing? If not answered above, are either of the New Charts or Old Charts reporting features of Bugzilla in common use at your organization? What customizations have you done to Bugzilla that you'd really like to see upstream? What features would you like to see Bugzilla have in the future? Are there any current features of Bugzilla that you'd like to see some change in, even if only a little? (Work differently, look different, fix some annoyance, etc.) Any other feedback that you'd like to give to the Bugzilla Project? None of these questions are limited to any particular number of responses. Also, feel free to make your answers as structured or as freeform as you'd like--if you want to give us explanations of why you've answered certain things, or explain more about anything, go ahead! If you want any clarification on any question, just let me know. :-) And if you want to take time to research any of them within the community, that's fine too--I don't really need the answers until July 7 (though sooner is of course always nicer). -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Re: Some Questions From The Bugzilla Project
Hey guys! I really appreciate all the feedback, but could you work it all out together and then have one person send me all the answers to the questions that I sent? I'm surveying about 25 organizations, it's hard to keep track of things if there's a lot of separate emails from each one. I don't need to be CC'ed on the actual discussions. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
A Handle Cache?
While Reading the developer's guide, I noticed that it said that translating windows' handles was always done by the server. I may have misunderstood this. Since interaction between the client and server requires at least two context switches and context switches are fairly heavy duty operations, would it make sense to cache handle lookups on the client?
Anotated 'make test' log
I'm trying to get a start on helping with wine development. I'm still in the process of reading the developer's guide, and I think I am making progress on that. As a test of my understanding, I started to annotate the output of 'make -k test'. I'd like your opinion on the usefulness of this. A few reservations: * I started from the top of the log. If I continue, I will be selecting sections that I find interesting. * I am not going to produce patches until someone says that the annotations are going in the right direction. This will change when I become more familiar with the community's opinion of my efforts. ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so cred.c && touch cred.ok Note: This test is expected to produce 2 error reports call is pCredReadA(TEST_TARGET_NAME, -1, 0, &cred) implementation at dll/advavi32/cred.c - CredReadA parameter names: TargetName, Type, Flags, *Credentials conversion to CreadReadW implementation at same - CredReadW fixme:cred:CredReadW unhandled type -1 Fixup: Convert 'if (Type != CRED_TYPE_GENERIC && Type != CRED_TYPE_DOMAIN_PASSWORD)' to a switch(case?) with all known types enumerated. Put unimplemented types at the end with a 'fixup' then fall through to the default case which sets the error code and fails. Note: In other words, don't request fixup for improper type codes. call is pCredReadA(TEST_TARGET_NAME, CRED_TYPE_GENERIC, 0xdeadbeef, &cred) see above for details fixme:cred:CredReadW unhandled flags 0xdeadbeef Fixup: Get a list of all known flags. Build a mask for all of them. Check for any unknown flags set and issue a warning if there are any. Build a mask of all implemented flags (currently none) and issue a fixme if any of those are set. Note: In other words, don't request fixup for undefined flags set. Question: Should this be an failure exit? Alternatively, should there be a list of flags that, if set trigger a failure exit? Note: Only fail if the flags indicate an option that can not be ignored. Note: No sucess tests. Note: Possible memory leak of returned credentials buffers? call is pCredWriteA(&new_cred, 0) implementation at same - CredWriteA parameter names: Credential, Flags new_cred.UserName = 'winetest' new_cred.TargetName = TEST_TARGET_NAME conversion to CredWriteW implementation at same - CredWriteW err:cred:CredWriteW bad username L"winetest" Note: This is an expected error. Note: Should it mention 'syntax' since it is checking for \ and @? Note: No bad flags test - Fixup per CredReadW above. Note: No bad type test - Fixup per CredReadW above. call is pCredWriteA(&new_cred, 0) see above for details. new_cred.UserName = NULL err:cred:CredWriteW bad username (null) Note: This is an expected error. Note: No sucess tests. Note: Possible memory leak of returned credentials buffers? call is pCredDeleteA(TEST_TARGET_NAME, -1, 0) implementation at same - CredDeleteA parameter names: TargetName, Type, Flags conversion to CredDeleteW fixme:cred:CredDeleteW unhandled type -1 Fixup: see CredReadA above call is pCredDeleteA(TEST_TARGET_NAME, CRED_TYPE_GENERIC, 0xdeadbeef) se above for details. fixme:cred:CredDeleteW unhandled flags 0xdeadbeef fixup: see CreadReadA above Note: No sucess tests. Note: Test order is questionable. A better order would be Write, Read then Delete with tests that are expected to succeed added. call is pCredReadDomainCredentialsA(&info, 0, &count, &creds implementation at same - CredReadDomainCredentialsA parameter names: TargetInformation, Flags, *Size, **Credentials conversion to CredReadDomainCredentialsW fixme:cred:CredReadDomainCredentialsW (0x15ddf8, 0x0, 0x33fd18, 0x33fc4c) stub Fixup: No suggestion
Re:Anotated 'make test' log
Thank you Dan. > What problem are you trying to solve? Curing my ignorance and rebuild my self-confidence. :) > I gather you're just plowing through the output of 'make test', > looking at each bit of noise, and trying to figure out a way > to improve the tests? Sort of. I needed a place to start, so I started at the top of the log. I expect that to change once I become more sure that I have the mechanics correct. There are several things I'm trying to do. First is to find the place where each 'bit of noise' is generated. I seem to be doing that right. Then I look at why the noise was generated and to show that I've understood why, I wrote a note on how the 'noise' could be turned off without changing the test. I labelled these 'fixup:'. I then looked at the test code and added 'Note:'s where I thought the test could be improved. > While that's a noble quest, and I'd like to encourage people > to improve the tests, it might be more productive to do so > around areas of pain for users. > For instance, you could look at bugs in bugzilla that have > patches attached that aren't committed yet because tests are > needed, and write those tests. > - Dan That sounds useful. I also have a few issues I'd like fixed too. However, it's been more than five years since I've done serious coding; things happened that destroyed my self-confidence. A little reassurance that I am not crazy and have the social skills needed to contribute to the community are what I need at the moment. - Max
Re: Anotated 'make test' log
Dan wrote: > OK. I'd suggest starting by looking at > http://bugs.winehq.org/show_bug.cgi?id=15435 > "Wine logs too verbose, quieter fixme's needed" and sending > in a patch to make one of the overly-verbose fixme's a bit > quieter. Thanks. I'll look at it. > Also, check your mail system; I can't email to you directly, > it bounces. And that's going to be a problem communicating > with other developers. A system disk failed this past weekend and I've been trying to get everything back up. I got test messages through starting about two hours ago. I've been checking the mailing list archive. (Yes, messages do not get properly threaded that way.) I'm also in the process of reinstalling much software. That machine is not very fast... - Max
Re: Anotated 'make test' log
Dan wrote: OK. I'd suggest starting by looking at http://bugs.winehq.org/show_bug.cgi?id=15435 "Wine logs too verbose, quieter fixme's needed" and sending in a patch to make one of the overly-verbose fixme's a bit quieter. Thanks. I'll look at it. Summary: Wine logs too verbose, quieter fixme's needed The bug report contains, among other things, this suggestion: One thing we've done in the past is added a check to only > print the fixme the first time it's hit. This is probably the > way to go. ... I took a look at this one, but it seems there's a > WINE_SPI_FIXME macro in there, which makes it a bit harder to > fix. Which suggests to me that the macro(s) could be modified to: 1. Use a local code block to declare a static flag variable. 2. Check that variable for zero (the default initial value IIUC) 3. and if it is zero, set the flag non-zero and print the message. There is a short race where different threads might see the zero value. If that happens, the message would be printed more than once. I believe that is acceptable because the alternate is to create a critical section, which is over-kill. That would limit ALL fixme's to one printing. The bug report mentioned variable information that might be included but implied that any such information is more properly included in a 'trace'. - Max
Re: Anotated 'make test' log
On 06/16/2010 04:48 PM, Dan Kegel wrote:
Max wrote:
[Maybe we should modify FIXME itself to only print out once.]
That's worth discussing, but changing FIXME itself might be going a
bit too far during the current code freeze.
You could try adding a FIXME_ONCE macro, though, and use it to quiet
some particular message that really gets in the way of (i.e. slows down)
a real application.
Something along the lines of?
#define FIXME_ONCE(...) \
do {static volatile unsigned char once = 0U; \
if ( once == 0U ) { /* The race here is ignorable. */ \
once = ^0U; \
FIXME(__VA_ARGS__); \
} \
} while(0)
(Resent) Documentation - Reference to MSDN?
I've been reading the Wine code and noticed that some of the external interfaces are practically undocumented. I did a web search on some of the names and found descriptions in MSDN. I realize that copying the information from MSDN directly into the code is a poor idea (like copyright violation) so I have a couple of questions: 1) Would including the URL of the MSDN article be useful/a good idea? 2) Would enumerating coded values and flags be allowed? 3) Where should data structures be documented?
Re: (Resent) Documentation - Reference to MSDN?
Juan Lang: Of course one of the reasons to add documentation is precisely because the information on MSDN is less than perfect. Having a good interface definition makes things easier. I'm still in the process of learning how to submit patches. These would be low risk but useful changes so they make good test material. Juan Lang, André Hentschel, Owen Rudge: So, from what Owen said, having a URL can be helpful, but should not be the total documentation. A date as part of the reference probably would be enough warning that things change. Alexandre: Would you mind getting documentation update patches during the code freeze?
Re: (Resent) Documentation - Reference to MSDN?
On 06/30/2010 03:13 PM, Alexandre Julliard wrote: Erich Hoover writes: Alright, well then I won't do it. Is the existing documentation going to be stripped at some point? It seems to me like we would benefit from more-detailed function descriptions in the auto-generated API documentation. I think it would save a lot of time for new developers to get their feet wet if they were able to see directly in the source what the different functions are supposed to do (as best as we know) and exactly what applications will trigger known edge cases (or if there's a test for a given situation). That's what the source code and test cases are for. If you rely on the function documentation you are in trouble anyway, nobody bothers to update it when new behaviors are discovered. If you really want to write good API documentation, as opposed to the current useless one-sentence-per-parameter description, you'd need probably a text 10 times the size of the source code for each function. That can't go in the source files. That documentation has to be stored somewhere. Where?
Documentation - Reference to MSDN?
I've been reading the Wine code and noticed that some of the external interfaces are practically undocumented. I did a web search on some of the names and found descriptions in MSDN. I realize that copying the information from MSDN directly into the code is a poor idea (like copyright violation) so I have a couple of questions: 1) Would including the URL of the MSDN article be useful/a good idea? 2) Would enumerating coded values and flags be allowed? 3) Where should data structures be documented?
Re: (Resent) Documentation - Reference to MSDN?
On 06/30/2010 03:43 PM, Erich Hoover wrote: On Wed, Jun 30, 2010 at 1:36 PM, James Mckenzie wrote: ... How about some place on the Wiki along with an implementation status. That way we can also annotate items that are missing in MSDN (I just re-stumbled across something in my latest Richedit tests) as well. This would help greatly in our progress towards current and future implementations of the Windows API. And I agree, adding all of this to the source would make it unwieldy. So something like "http://wiki.winehq.org/WineAPI//" ? If that's acceptable I would not mind a system like that, especially if the links of documented functions are provided in the source. Documenting these things is a lot of work, so I'm not about to run off and do all that work if no-one is ever going to take advantage of it. Erich Hoover ehoo...@mines.edu I created the top page as a table and populated it with all the directory entries in the 'dll' directory. Somebody immediately deleted it. WTF?
Re: (Resent) Documentation - Reference to MSDN?
On 06/30/2010 03:13 PM, Alexandre Julliard wrote: Erich Hoover writes: Alright, well then I won't do it. Is the existing documentation going to be stripped at some point? It seems to me like we would benefit from more-detailed function descriptions in the auto-generated API documentation. I think it would save a lot of time for new developers to get their feet wet if they were able to see directly in the source what the different functions are supposed to do (as best as we know) and exactly what applications will trigger known edge cases (or if there's a test for a given situation). That's what the source code and test cases are for. If you rely on the function documentation you are in trouble anyway, nobody bothers to update it when new behaviors are discovered. If you really want to write good API documentation, as opposed to the current useless one-sentence-per-parameter description, you'd need probably a text 10 times the size of the source code for each function. That can't go in the source files. So, would it be OK with you to extract the current documentation and put it in the wiki where it can be more easily maintained? Wikis are supposed to be good for exactly that kind of thing. Once the wiki is populated with the initial information from the source code, the source code could then be cleaned up by having links to the wiki in place of the current cruft. Erich Hover's tree structure sounds like the right way to go. Formatting guidelines and templates to tag the article contents so the information can be easily extracted will be needed, but that belongs on the wiki, although issues should be discussed and decided on this mailing list.
Re: dlls/ntdll/file.c: Use FIXME_ONCE for quieter reports.
On 07/14/2010 03:57 PM, Sven Baars wrote: Michael Stefaniuc wrote: Hello Max, are you replacing all FIXME with FIXME_ONCE? While I do agree that we need the _ONCE variant changing all FIXME is not useful. bye michael On 07/14/2010 09:02 PM, Max TenEyck Woodbury wrote: --- dlls/ntdll/file.c | 40 ++-- 1 files changed, 18 insertions(+), 22 deletions(-) Also, the patch that you sent earlier, that implements FIXME_ONCE has been deferred until after wine 1.2, which means you have to send it again after wine 1.2 has been released. The same counts for every patch you have sent today (because they depend on yesterday's patch), so you might want to wait until after the release before sending any more patches. Sven P.S. You can see that it has been deferred here: http://source.winehq.org/patches/ 1) No, I am not replacing all 'FIXME's with 'FIXME_ONCE's. I'm working on things labeled 'stub' or equivalent. Also 'FIXME's that do not have any additional information. I went over the files that bug 15435 said were too noisy. There are almost certainly many other places 'FIXME_ONCE' can be used. 2) Consider committing yesterday's patch instead of deferring it?
Re: dlls/ntdll/file.c: Use FIXME_ONCE for quieter reports.
On 07/14/2010 05:57 PM, Henri Verbeet wrote: On 14 July 2010 22:57, Max TenEyck Woodbury wrote: 1) No, I am not replacing all 'FIXME's with 'FIXME_ONCE's. I'm working on things labeled 'stub' or equivalent. Also 'FIXME's that do not have any additional information. I went over the files that bug 15435 said were too noisy. There are almost certainly many other places 'FIXME_ONCE' can be used. Actually, since this seems to come up from time to time, let me go and explicitly say it. I think bug 15435 is mildly offensive at best. There are basically two claims at the basis of that bug report: "debug output confuses users" and "debug output makes log analysis hard". For the first claim, I'd like to think most of our users aren't complete idiots, so I find this hard to believe. Regardless, debug output isn't meant for users, so if you don't want to see debug output run with WINEDEBUG=-all, or don't run from the terminal in the first place. The second claim actively offends me though, because it basically comes down to "I think developers are idiots". If, as a developer who actually does analyze those logs, I really thought those FIXMEs made my life so much harder I would've changed them myself. I like to think I'm capable enough of deciding for myself which debug output I like to see, and I imagine other actual developers are as well. That's not to say there aren't FIXMEs that would be better of only being printed once, but please leave those kinds of decisions to qualified developers familiar with the code in question. I did read the bug report and I think I understand the issue. Dan Kegel suggested that that bug report was a good place to start working on wine. I did think about what was happening. If a report contains variable information that should be printed on each entry, that report should us 'TRACE', not 'FIXME'. 'FIXME's that contain no variable information are completely redundant after their first report. After the first reminder, the additional reports are just noise. They add no additional information in terms of action required. If this is not true in a particular situation, again, 'TRACE' should be used. Similarly, 'WARN' without variable information are usually redundant after they are first issued. I may be new to Wine, but I have a substantial amount of experience designing, writing and fixing code. I learned programming by fixing my fathers code. I more than understand and accept your desire to decide that '_ONCE' is appropriate in special situations but there are many situations where the need for '_ONCE' is obvious. The changes I have made are of that type, at least in my opinion.
Re: dlls/ntdll/file.c: Use FIXME_ONCE for quieter reports.
On 07/14/2010 08:53 PM, Chris Robinson wrote: On Wednesday, July 14, 2010 5:02:59 pm Max TenEyck Woodbury wrote: 'FIXME's that contain no variable information are completely redundant after their first report. After the first reminder, the additional reports are just noise. They add no additional information in terms of action required. I wouldn't say that. Sometimes the simple knowledge that a FIXME is called a whole lot says enough on its own (eg, in WineD3D, you get a fixme when an sRGB reload occurs, because it's a performance drain; if this happens a lot, it can be taken as a source for performance issues). Sometimes knowing particular a fixme is triggered near to a crash or other behavioral anomaly can say a bit, too. If such fixmes were only printed once, it would be impossible to see this information without more in-depth testing that most users won't bother with. If the fixme is only printed once and the rest are TRACEs, it would still cause more work and a whole lot more noise (ie. all the other traces) in trying to spot it. Good points, but the formatting and I/O can contribute significantly to the lack of performance. There is also the fact that trying to fix performance problems before you have the operation working correctly is really poor technique. Which 'FIXME's for stubs should not be '_ONCE'd is an issue for specialists. With the new macros, it is easy to back out this kind of change. Another variation could be made to use an exponential back-off for the reports. That is, the 2^0, 2^1, 2^2, 2^3, 2^4... instances could be allowed to print, but that's something that we might want to discuss before throwing it into the mix of options available. What would you call that anyway? '_22I'?
Re: dlls/ntdll/file.c: Use FIXME_ONCE for quieter reports.
On 07/15/2010 01:13 AM, Dmitry Timoshkov wrote: Max TenEyck Woodbury wrote: I may be new to Wine, but I have a substantial amount of experience designing, writing and fixing code. I learned programming by fixing my fathers code. I more than understand and accept your desire to decide that '_ONCE' is appropriate in special situations but there are many situations where the need for '_ONCE' is obvious. The changes I have made are of that type, at least in my opinion. It's better to spend time by implementing missing features and effectively removing those FIXMEs instead of inventing new ways to disable output. As been said if too much FIXME messages hurts your eyes just use '-all'. That bug should be closed as wontfix if not as inavlid. Thank you for your opinion. In order to actually implement the features, I have to have good descriptions of what those features are, which was the reason I started the API documentation pages on the wiki. Since things are at an impasse on that front, I have time to work on less critical things. I've done a fair amount with debugging frameworks in the past, so I think I can make useful contributions in that area. I am aware of the '-all' option, but there are times when it is inappropriate. Particularly when it comes to regression and unit tests. It is not a matter of visual discomfort. It is a matter of signal to noise ratios. Reducing the noise makes it easier to identify the problems. Each of us has strengths and weaknesses. I have some idea of my own but I am loath to try to prescribe for others. On a project the size of wine, the diversity of talents available is a great positive. Let's not screw things up by trying to dictate what others should or should not do. If I am not mistaken, Alexandre is the one who decides what gets fixed. I observe that some movement has already taken place with respect to bug 15345. In reviewing the various files, some patching has already been done, so 'WONTFIX' is not really an option. How much more should be done is another question of course. It will be answered by people who are willing to do the work and by Alexandre.
Re: Anotated 'make test' log
On 07/17/2010 10:27 AM, Detlef Riekenberg wrote: Hi Max Welcome to Wine. Your Patch "[Add '_ONCE' variants of DPRINTF, FIXME, WARN.]" ( http://source.winehq.org/patches/data/63503 ) has a typo near the end: #define ERR_ONCE WINE_ERR_ONCEE Thank you! Fixed and resubmitted.
Re: include/wine/debug.h: ... and uses of '_ONCE' variants.
Please discard this series of patches. They will not work with compilers that do not support macros with variable numbers of arguments. While most modern compilers do provide variadic macros, some older compilers do not. To do this right a non-intuitive syntax would be required. (i.e. 'FIXME_ONCE((...));'.) Also, the current implementation is imperfect. There should be a test in 'configure' for the various kinds of variadic macro support and the conditionals should be based on what configure finds, not on the use of any particular compiler. -Max
Re: include/wine/debug.h: ... and uses of '_ONCE' variants.
On 07/22/2010 03:35 AM, Alexandre Julliard wrote: Max TenEyck Woodbury writes: Also, the current implementation is imperfect. There should be a test in 'configure' for the various kinds of variadic macro support and the conditionals should be based on what configure finds, not on the use of any particular compiler. No, the current implementation is correct, debug.h should be usable from Winelib apps where you don't have access to Wine configure checks. Ahh. Should the list of compilers that support varadic macros be updated?
Re: [PATCH] dlls/ntdll/file.c: Setting FileAllInformation is not 'fixable'.
On 07/24/2010 10:58 AM, Nikolay Sivov wrote:
On 7/24/2010 18:51, Max TenEyck Woodbury wrote:
---
dlls/ntdll/file.c | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c
index 0a6ee55..86c200f 100644
--- a/dlls/ntdll/file.c
+++ b/dlls/ntdll/file.c
@@ -2148,6 +2148,11 @@ NTSTATUS WINAPI NtSetInformationFile(HANDLE
handle, PIO_STATUS_BLOCK io,
io->u.Status = STATUS_INVALID_PARAMETER_3;
break;
+ /* Invalid requests - do not need 'fixing'. */
+ case FileAllInformation:
+ io->u.Status = STATUS_NOT_IMPLEMENTED;
+ break;
+
default:
FIXME("Unsupported class (%d)\n", class);
io->u.Status = STATUS_NOT_IMPLEMENTED;
Add a test please, and a comment won't be needed with a test too.
There already is a test in dlls/ntdll/test/file.c. It produces a
'fixme:' when it should not. This fixes that.
Re: [PATCH] dlls/ntdll/file.c: Setting FileAllInformation is not 'fixable'.
On 07/25/2010 12:50 AM, Dmitry Timoshkov wrote:
Max TenEyck Woodbury wrote:
+ /* Invalid requests - do not need 'fixing'. */
+ case FileAllInformation:
+ io->u.Status = STATUS_NOT_IMPLEMENTED;
+ break;
+
default:
FIXME("Unsupported class (%d)\n", class);
io->u.Status = STATUS_NOT_IMPLEMENTED;
Add a test please, and a comment won't be needed with a test too.
There already is a test in dlls/ntdll/test/file.c. It produces a
'fixme:' when it should not. This fixes that.
This is not a fix. A fix is a patch that makes a test pass that previously
did not. You simply silence a harmless fixme.
The 'fixme' is not 'harmless'. It gets counted. It claims that there is
something wrong that needs fixing. In fact, the proper implementation
for this particular request is to set an error code and ignore the
request. The test code checks for exactly that condition and does NOT
report a test failure when that happens. It reports a failure if the
error code does NOT have the specified value. In other words this patch
fixes an error in the 'work to be done count'.
Please stop the sniping. There is now more text disparaging the patch
than there is text in the patch itself.
-Max
Re: [PATCH] dlls/ntdll/file.c: Setting FileAllInformation is not 'fixable'.
On 07/25/2010 09:45 AM, James McKenzie wrote:
Max TenEyck Woodbury wrote:
---
dlls/ntdll/file.c | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c
index 0a6ee55..86c200f 100644
--- a/dlls/ntdll/file.c
+++ b/dlls/ntdll/file.c
@@ -2148,6 +2148,11 @@ NTSTATUS WINAPI NtSetInformationFile(HANDLE
handle, PIO_STATUS_BLOCK io,
io->u.Status = STATUS_INVALID_PARAMETER_3;
break;
+ /* Invalid requests - do not need 'fixing'. */
+ case FileAllInformation:
+ io->u.Status = STATUS_NOT_IMPLEMENTED;
+ break;
+
default:
FIXME("Unsupported class (%d)\n", class);
io->u.Status = STATUS_NOT_IMPLEMENTED;
Max:
I think you missed what Nicolay and Dmitry are trying to tell you.
We are trying to implement, bug for bug, the functionality of what
Windows does. Does Windows return "STATUS_NOT_IMPLEMENTED" when this
call is made? If not, your fix is WRONG. Silencing a 'fixme' is NOT a
fix and this will be REJECTED.
If this is correct and is what Windows does, then state so. Otherwise,
withdraw the patch and fix it the right way.
James McKenzie
Frankly, I do not know what Microsoft does, but the test would fail on
their implementation if they did something else, so I think it is safe
to assume the test is implemented properly. Given that, the fixme is
wrong.
Specifically, Nicolay asked for a test case. Since I was working from
an already existing test case, his request didn't really make sense. I
pointed out that there already was a test case and that should have
been the end of it.
Dimtry's response makes even less sense. The fixme was produced by a
default branch in a switch statement. It is fairly good practice to
have such a branch and note that it is being used with a 'fixme',
though technically it should check the switch value to assure it is in
the correct range before issuing the 'fixme'. I would have added that
test if I had documentation on what the proper range is. Since I did
not have that documentation, I left the default branch alone. However,
the 'FileAllInformation' branch is obviously in range and the test case
code makes it clear that it should return STATUS_NOT_IMPLEMENTED. It
should not produce a 'fixme'. So I added a branch that returns the
proper status without an unnecessary and erroneous 'fixme'. I suspect,
but do not know, that there may be other codes that are not
implemented. Thus the comment so future additions to the list of
unimplemented codes would be put in the same place. Dimtry's response
shows that he did not look at the situation in any detail, where I had
examined what needed doing from several points of view.
Now you come along and make loud demands that the patch be rejected,
without having looked at the situation carefully. Frankly, this looks
very much like the activities of an 'in-crowd' trying to defend its
boarders. Much the same thing happend with the '_ONCE' patches. The
arguments presented by others for their rejection contained some bogus
rationalizations (along with a few points that I corrected) but did NOT
even touch the reason those patches had to be withdrawn. In other
words, I have and will withdraw patches when there are good reasons to
do so, but no such reasons have been presented for the withdrawal of
this patch so far.
- Max
Re: [PATCH] dlls/ntdll/file.c: Setting FileAllInformation is not 'fixable'.
On 07/25/2010 01:55 PM, James McKenzie wrote: Andrew Eikum wrote: On 07/25/2010 12:04 PM, Max TenEyck Woodbury wrote: On 07/25/2010 09:45 AM, James McKenzie wrote: I think you missed what Nicolay and Dmitry are trying to tell you. We are trying to implement, bug for bug, the functionality of what Windows does. Does Windows return "STATUS_NOT_IMPLEMENTED" when this call is made? If not, your fix is WRONG. Silencing a 'fixme' is NOT a fix and this will be REJECTED. If this is correct and is what Windows does, then state so. Otherwise, withdraw the patch and fix it the right way. James McKenzie Frankly, I do not know what Microsoft does, but the test would fail on their implementation if they did something else, so I think it is safe to assume the test is implemented properly. Given that, the fixme is wrong. You had very well much know what Microsoft does and care very much about what they do. The goal of this project, as it has been since the mid 1990s is to fully emulate, bug and all, the Microsoft Windows32 and Windows64 (since 64 bit versions of Windows arrived) APIs. Thus we have test cases that demonstrate what the actions are of the API/ABI. That is what I've been working on with several richedit functions that I need to have for programs that I personally use. I'm 'eating my own dog food' to speak. Since I do not have (and should never have if I work on Wine) access to Microsoft's code, I can not know what they actually do. The test case code is what is available. I did not write this test case code, but it has been run against Microsoft's code and has been around long enough that it would have been corrected if it did not match their results. I believe it is also safe to assume that the Microsoft code does NOT produce 'fixme' messages. Unless the test case code is wrong, there should not be a 'fixme' produced. Specifically, Nicolay asked for a test case. Since I was working from an already existing test case, his request didn't really make sense. I pointed out that there already was a test case and that should have been the end of it. Well, you didn't point out which existing testcase you are talking about. All that your patch does is silence a FIXME. Presumably, the FIXME was placed there for a reason. Nikolay and Dmitry were pointing out that silencing that FIXME might not be appropriate, and were asking for you to demonstrate why that FIXME is invalid. Adding a testcase or pointing to an existing testcase would accomplish this. I looked at the testcase. He will need to 'beef up' the testcase to demonstrate what functions that particular test case does. If it does return "not implemented" then it has to be demonstrated. I tried to point this out as did Nicolay and Dmitry. Otherwise, this patch will be rejected by AJ as an attempt to silence the fixme, which he detests greatly. You obviously found the test case code. I did not write it. If it reports failures when run against Microsoft's code, it needs fixing, but I am not the one to fix it. As it stands, the expected result is a 'not implemented' status. Given that, any 'fixme' issued would be improper. Which existing testcase demonstrates that this behavior is valid and that the FIXME is unwarranted? Does the existing testcase demonstrate the full range of behavior given that parameter? Can you expand on the tests to show that your implementation is always correct? Now you come along and make loud demands that the patch be rejected, without having looked at the situation carefully. Frankly, this looks very much like the activities of an 'in-crowd' trying to defend its boarders. No. we have stated that you have no authoritative source that you are correct. State this and we all will be satisfied that the patch you propose is correct. Right now, it appears as if the patch is just a 'silence the fixme' attempt. This is why your original set of patches was beat up. We want to know, and so do our users, that implementation is not complete for functions. If this is breaking a program you are using, you are welcome to fully implement the function. That is what we are all here for. Fixmes are not the way to go, but if a stub makes things work that is the first step of many. There are many fixmes in Wine code and I'm working on three of them in the richedit dll that directly affect the ability for me to properly use programs. I've built a test case for one of them, that was rejected by AJ. I'm working on a second test case and then will build out code from that position. This is how the project moves ahead. There is no 'authoritative source'. There are only the test cases. The 'fixme' appears to be the result of slightly sloppy coding. Since the test case shows that the proper behavior is to return an error code, the 'fixme' is an error. T
Re: [PATCH] dlls/ntdll/file.c: Setting FileAllInformation is not 'fixable'.
On 07/25/2010 01:34 PM, Andrew Eikum wrote:
On 07/25/2010 12:04 PM, Max TenEyck Woodbury wrote:
On 07/25/2010 09:45 AM, James McKenzie wrote:
I think you missed what Nicolay and Dmitry are trying to tell you.
We are trying to implement, bug for bug, the functionality of what
Windows does. Does Windows return "STATUS_NOT_IMPLEMENTED" when this
call is made? If not, your fix is WRONG. Silencing a 'fixme' is NOT a
fix and this will be REJECTED.
If this is correct and is what Windows does, then state so. Otherwise,
withdraw the patch and fix it the right way.
James McKenzie
Frankly, I do not know what Microsoft does, but the test would fail on
their implementation if they did something else, so I think it is safe
to assume the test is implemented properly. Given that, the fixme is
wrong.
Specifically, Nicolay asked for a test case. Since I was working from
an already existing test case, his request didn't really make sense. I
pointed out that there already was a test case and that should have
been the end of it.
Well, you didn't point out which existing testcase you are talking
about. All that your patch does is silence a FIXME. Presumably, the
FIXME was placed there for a reason. Nikolay and Dmitry were pointing
out that silencing that FIXME might not be appropriate, and were asking
for you to demonstrate why that FIXME is invalid. Adding a testcase or
pointing to an existing testcase would accomplish this.
Which existing testcase demonstrates that this behavior is valid and
that the FIXME is unwarranted? Does the existing testcase demonstrate
the full range of behavior given that parameter? Can you expand on the
tests to show that your implementation is always correct?
From my notes (line breaks added to prevent wrapping)
fixme:ntdll:NtSetInformationFile Unsupported class (18)
dlls/ntdll/file.c:2152 in NtSetInformationFile
NTSTATUS WINAPI NtSetInformationFile(HANDLE handle, PIO_STATUS_BLOCK
io, PVOID ptr, ULONG len, FILE_INFORMATION_CLASS class)
switch (class) { ... default: FIXME("Unsupported class (%d)\n",
class); 18=FileAllInformation
called by dlls/ntdll/tests/file.c: in test_file_all_information
res = pNtSetInformationFile(h, &io, &fai_buf.fai, sizeof fai_buf,
FileAllInformation);
should not be 'FIXME'?
Now you come along and make loud demands that the patch be rejected,
without having looked at the situation carefully. Frankly, this looks
very much like the activities of an 'in-crowd' trying to defend its
boarders.
You need to take it easy, man. No one is out to get you :)
A lot of folks on this list don't have English as a first language, and
it can be easy to sound offensive if you haven't had the experience with
the subtleties English that native speakers have had. There might also
be some folks who are just abrasive, and you have to ignore or politely
respond to those. In no case does accusing people like this help, even
if they are doing some injustice towards you.
I don't think this has anything to do with me personally. I see it as
pretty standard behaviour when an 'in-crowd' is chalanged.
Wine has a high barrier for entry and patches are reviewed harshly. If
people are responding negatively to your patch, then it's likely because
your patch was not obviously correct. The correct way to respond to this
is by proving that it's correct, not asserting that it's correct. You're
going to have to deal with defending your patches, and accept that
sometimes you are wrong and sometimes other people are wrong.
Andrew
Yes, some people are abrasive. Giving them a pass only encourages their
bad behavior. If Nicolay or anybody else was not happy with the
pointer I gave to the test case, they could have simply said so.
Proof is necessarily in the mind of the reader. If the reader is not
willing to examine the proof, they are impossible to convince.
Similarly, if they are prejudiced, it will be impossible to change
their minds no matter how much evidence is presented. On the other hand
you asked for more specific information. I am providing it, but you
will have to convince yourself that the arguments presented are correct.
If you will notice, I've already admitted to being wrong on some
things. To some people that encourages their attack behavior.
- Max
Re: [PATCH] dlls/ntdll/file.c: Setting FileAllInformation is not 'fixable'.
On 07/25/2010 02:25 PM, Reece Dunn wrote:
On 24 July 2010 16:10, Max TenEyck Woodbury wrote:
On 07/24/2010 10:58 AM, Nikolay Sivov wrote:
On 7/24/2010 18:51, Max TenEyck Woodbury wrote:
---
dlls/ntdll/file.c | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c
index 0a6ee55..86c200f 100644
--- a/dlls/ntdll/file.c
+++ b/dlls/ntdll/file.c
@@ -2148,6 +2148,11 @@ NTSTATUS WINAPI NtSetInformationFile(HANDLE
handle, PIO_STATUS_BLOCK io,
io->u.Status = STATUS_INVALID_PARAMETER_3;
break;
+ /* Invalid requests - do not need 'fixing'. */
+ case FileAllInformation:
+ io->u.Status = STATUS_NOT_IMPLEMENTED;
+ break;
+
default:
FIXME("Unsupported class (%d)\n", class);
io->u.Status = STATUS_NOT_IMPLEMENTED;
Add a test please, and a comment won't be needed with a test too.
There already is a test in dlls/ntdll/test/file.c. It produces a
'fixme:' when it should not. This fixes that.
The only test I can find is:
1110 res = pNtSetInformationFile(h,&io,&fai_buf.fai, sizeof
fai_buf, FileAllInformation);
ok ( res == STATUS_INVALID_INFO_CLASS || res ==
STATUS_NOT_IMPLEMENTED, "shouldn't be able to set FileAllInformation,
res %x\n", res);
I would say that (based on this test), STATUS_NOT_IMPLEMENTED is the
wrong value to use -- it should really be STATUS_INVALID_INFO_CLASS.
The check should mark the STATUS_NOT_IMPLEMENTED value as a broken
value:
ok ( res == STATUS_INVALID_INFO_CLASS || broken(res ==
STATUS_NOT_IMPLEMENTED), "shouldn't be able to set FileAllInformation,
res %x\n", res);
This would fix the return value for this condition.
In addition to this, the Wine implementation is returning io->u.Status
in all these cases, but the tests for pNtSetInformationFile do not
also check they are the same. To avoid false positives or negatives,
io->u.Status needs to be set before each test. Thus, you have
something like:
io.u.Status = 0xdeadbeef;
res = pNtSetInformationFile(...);
ok (res == STATUS_SUCCESS, "Expected NtSetInformationFile to
return STATUS_SUCCESS, got %d\n", res);
ok(res == U(io).Status, "Expected NtSetInformationFile return to
match io.u.Status, got res = %d, io.u.Status = %d\n", res,
U(io).Status);
or:
ok (res == STATUS_SUCCESS, "Expected NtSetInformationFile to
return STATUS_SUCCESS, got %d\n", res);
ok(U(io).Status == STATUS_SUCCESS, "Expected io.u.Status to be
STATUS_SUCCESS, got %d\n", U(io).Status);
This way, the tests confirm that io.u.Status and the return value of
NtSetInformationFile are the same.
- Reece
Excellent critique. You are obviously better informed than I am. Please
submit a patch. I will assume your logic to be correct and will change
the status value generated.
- Max
Creation of the Wine API wiki on SourceForge
A wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php has been created for documenting the API interface of WINE (as opposed to Microsoft Windows). It is in the planning stage at this point. - Max
The WineAPI wiki.
I have started the WineAPI wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php?title=Main_Page Some issues have come up that may need to be discussed here. In particular, there is going to be an 'Overview' section for many articles and I think the information to fill it in should come from the wine source tree. Specifically, I'd like to create 'Overview.wiki' files to contain this information. - Max
Re: The WineAPI wiki.
On 08/02/2010 07:00 AM, Dmitry Timoshkov wrote: Max TenEyck Woodbury wrote: I have started the WineAPI wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php?title=Main_Page You have chosen not very good name. There is no such a thing as Wine API, Wine implements Win32 API, and doesn't specify/add anything custom to it. The name "WineAPI" implies that Wine defines its own API which is not true, and is confusing. This has been discussed elsewhere on this mailing list. There is a lot of information specific to Wine, particularly its internal structure, that is not shared with Microsoft's product. Further, there is a little confusing and incorrect information in the Microsoft documentation. Bluntly, the Microsoft documentation is what they want it to be. We need to document what it really is. We have tried to embed API documentation in the source code. That has not worked as well as it could. Alexandre Julliard has said as much. I think that having good documentation will help the project. Not having good documentation can and does hurt Wine in my opinion. I also think that trying to prevent the creation of that documentation might be harmful. - Max
Re: The WineAPI wiki.
On 08/02/2010 07:53 AM, Dmitry Timoshkov wrote: Max TenEyck Woodbury wrote: You have chosen not very good name. There is no such a thing as Wine API, Wine implements Win32 API, and doesn't specify/add anything custom to it. The name "WineAPI" implies that Wine defines its own API which is not true, and is confusing. This has been discussed elsewhere on this mailing list. There is a lot of information specific to Wine, particularly its internal structure, that is not shared with Microsoft's product. Then "Wine internals" or "Wine architecture" would be more appropriate. But it is NOT just the internals. I believe that good API documentations should include a 'Theory of Operation' section which describes how it is actually implemented. There should also be a section that documents regression and other tests. In other words, I hope this will become a *really* good set of API documentation. So 'Wine internals' would have been a bad name for the project. Similarly 'Wine architecture' is inappropriate. This is not particularly a name I chose. The other discussions of this have also used 'WineAPI'. I did consider your objections that you have voiced previously. I understand that the target API is in fact the Win32API, but the Win32API is not something we control. We do control the actual API Wine uses. There will be differences between the WineAPI and the Win32API. When those differences are pointed out, I expect the WineAPI will be changed to match the Win32API. We are free to do that. We are *not* free to change the Win32API. I think 'WineAPI' is an appropriate name and better than either of the names you suggested. If anyone comes up with a better name, I will try to get the Sourceforge project name changed, but the project is currently called 'wineapi'. So, for the moment, it is what it is. Further, there is a little confusing and incorrect information in the Microsoft documentation. Bluntly, the Microsoft documentation is what they want it to be. We need to document what it really is. Regardless of the quality of Microsoft documentation it's still Win32 API, not a Wine API. And it is Microsoft's documentation and nominally documents their code. We have to document *our* code. There will be differences. Differences that I expect will be removed when found unless we can show that the Microsoft documentation is, in fact, incorrect. You are setting up a 'straw man' argument. You are assuming that we can and *have* implemented the Win32 API correctly and that Microsoft's published documentation is completely correct. We have not and Microsoft has not. Our documentation will help us fix our code. We can not and should not even try to get try to get Microsoft fix their problems. From that your argument fails. - Max
Re: The WineAPI wiki.
On 08/02/2010 11:25 AM, Dmitry Timoshkov wrote: Max TenEyck Woodbury wrote: Further, there is a little confusing and incorrect information in the Microsoft documentation. Bluntly, the Microsoft documentation is what they want it to be. We need to document what it really is. Regardless of the quality of Microsoft documentation it's still Win32 API, not a Wine API. And it is Microsoft's documentation and nominally documents their code. We have to document *our* code. There will be differences. Differences that I expect will be removed when found unless we can show that the Microsoft documentation is, in fact, incorrect. An API is Application Programming Interface, not the code or implementation details. The API is for application programmers, not for system's analists. If the Wine implementaion of win32 differs from Microsoft one - that's a bug, it's not worth documenting, it's worth a bug report and fixing. Your implication that I do not know wat 'API' stands for comes very close to being an insult. Please stop. The readable title is 'Wine API *and related documentation*'. Documentation is used for many purposes. Application programmers use it, but system's analysts also use it. Telling me that it can not be used any way but your way is arrogant. Implementation and documentation are two different things. Bugs can, and in some cases should, be documented. I am not asking you to do anything in particular. That would be arrogance on my part. - Max
Re: The WineAPI wiki.
On 08/02/2010 11:18 AM, James Mckenzie wrote: Max TenEyck Woodbury wrote: On 08/02/2010 07:00 AM, Dmitry Timoshkov wrote: Max TenEyck Woodbury wrote: I have started the WineAPI wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php?title=Main_Page You have chosen not very good name. There is no such a thing as Wine API, Wine implements Win32 API, and doesn't specify/add anything custom to it. The name "WineAPI" implies that Wine defines its own API which is not true, and is confusing. This should be named, the Windows32/Window64 API as implemented by Wine Documentation site. That is what it is. We have found shortcomings in the MSDN documentation (I'm dealing with this right now in one function call for Richedit.) This should be a collaborative site where Wine developers, Windows on Wine developers and others can place information on what Wine has implemented today, what needs to be implemented (with case code and discoveries) and what Wine cannot implement. Hmm, I may change the brief project description to match that. I will think about it... There is a lot of information specific to Wine, particularly its internal structure, that is not shared with Microsoft's product. Further, there is a little confusing and incorrect information in the Microsoft documentation. Bluntly, the Microsoft documentation is what they want it to be. We need to document what it really is. We have tried to embed API documentation in the source code. That has not worked as well as it could. Alexandre Julliard has said as much. I think that having good documentation will help the project. Not having good documentation can and does hurt Wine in my opinion. I also think that trying to prevent the creation of that documentation might be harmful. AJ has stated that documenting the Windows API and internal API calls should NOT be documented just in the source. It bloats the source code terribly and can make code unreadable. I agree that this Wiki should only be used to document the external interfaces to Wine as we implement Windows32/Windows64 API/ABI calls and what we have found in our testing that is different than MSDN. We should NOT duplicate MSDN where is is proper, but rather have a note that states MSDN and other sources have been found to be proper. I disagree. Really good documentation includes 'Theory of Operation'. Of course we do not have that for the Microsoft code, but it *may* be helpful for our own code. I think documenting our test code would also be useful. There should be links to the Microsoft documentation in each article, but Microsoft has been known to move their documentation around without maintaining redirects. To avoid being at Microsoft's mercy in this, a summary (*not* a duplicate) of the Microsoft articles, which would be fair use, should be maintained. - Max
Re: The WineAPI wiki.
On 08/02/2010 01:04 PM, Gert van den Berg wrote: There seem to be several interfaces to retreive MSDN articles... Some of those interface might be more stable / provide a way to retrieve a current link? (Framing the content would probably not be allowed, but retreiving links should be...) If it *looks* like copying, it should be avoided. (It might also work to try and retreive as much information about MSDN links when they are posted, in order to allow the links to be updated when the site stucture change?) (Doing a web service query everytime to retreive a link would probably be slow and inefficient...) I think it will be necessary to regenerate articles as the Wine project evolves. I regenerated the 'dlls' page after Alexandre's CVS run today. There was some new content so I saved the result. I've regenerated the individual DLL pages several times as I improved the generating scripts. Both activities put a load on me that I am trying to automate. In fact, if you look at the original post before it got hijacked into a discussion of the project name, it asks about a way to improve that automation. Since there will be fairly frequent semi-intelligent reviews of pages, such queries can probably be incorporated into that process. Can you help me with this, please? - Max
Re: The WineAPI wiki.
On 08/04/2010 03:15 PM, Francois Gouget wrote: On Mon, 2 Aug 2010, Max TenEyck Woodbury wrote: [...] This has been discussed elsewhere on this mailing list. There is a lot of information specific to Wine, particularly its internal structure, that is not shared with Microsoft's product. Further, there is a little confusing and incorrect information in the Microsoft documentation. Bluntly, the Microsoft documentation is what they want it to be. We need to document what it really is. I think such documentation should be open to all projects involved in the Win32 space such as Mingw, React OS, as well as Windows software developpers whenever they are irritated by an MSDN deficiency. Sure there will be differences between how each project implements a given API, just like there are differences between the Windows 98, 2000 or Vista implementations. But I expect most of the documentation to be common to all so that the best approach would be to describe the reference behavior and then have notes describing the platform-specific differences. However calling the Wiki 'WineAPI' is not very welcoming to other contributors and it would be a shame if each project ended up duplicating this huge effort just because of a naming issue. That is a very good point! There several things that have to be coordinated however: - This is not just the API documentation. It includes a great deal of information about the meta-structure of the Wine project. Easy access to that meta-information might be one of the more useful aspects of this sub-project. - The detailed information is, at least initially, coming out of the Wine code. It is being generated using scripts. The scripts are very likely to be rerun when a file in the Wine repository changes. It may take a lot of effort to merge the new information with information from other sources. - If the licenses are compatible, it should be possible to copy articles between projects. Also, the page tree structure is based on the structure of the Wine repository. Since the Wine repository structure is fairly stable, (new parts are added fairly often, but once a piece is in place for a while, it usually stays where it is. I could definitely be wrong about this!) links into the WineAPI wiki should also be stable. - Max
Re: The WineAPI wiki.
On 08/05/2010 03:56 AM, Francois Gouget wrote: On Wed, 4 Aug 2010, Max TenEyck Woodbury wrote: [...] There several things that have to be coordinated however: - This is not just the API documentation. It includes a great deal of information about the meta-structure of the Wine project. Easy access to that meta-information might be one of the more useful aspects of this sub-project. I suspect some of that information is already present in the Wine Developer's Guide, in particular the section 'II. Wine Architecture': http://www.winehq.org/docs/winedev-guide/index So there is the issue of where to put this information: in the developer guide, in the win32 api wiki or in a separate wiki. Even if it's in the win32 api wiki I think it could be set slightly apart. Here's roughly what I have in mind: 1. Win32 API 1. Overview 2. acledit API 1. Overview 2. Functions 1. Func1 2. Func2 ... 3. Interfaces 1. Interface 1 1. Method1 2. Method2 ... 2. Interface 2 1. Method1 2. Method2 ... 4. Datastructures 1. Struct1 2. Struct2 3. Enum1 ... 3. aclui API ... 2. Standard Windows tools 1. attrib command line options 2. cacls command line options ... 3. General platform-specific notes 1. Windows 9x Talks about interaction with DOS, etc. 2. Windows 95 More Win 9x specific general notes 3. Windows NT and greater Kernel stuff 4. Wine 1. Wine architecture documentation 2. Wine-specific dlls 3. Wine-specific tools like winebuild, winemenubuilder, etc) 5. Mingw Stuff about Mingw, etc. 6. ReactOS Stuff about ReactOS, etc. Ah! That is where the misunderstanding is. You are thinking of this as a *document*, a single coherent document. That is not quite what this is. It is a collection of *pages*. Each page has a distinct name. Those names are what the scripts maintain. The pages will also contain sub-pages. Those sub-pages are where the user-editable content are stored. Once those sub-pages are created, the scripts will not touch them. (That answers the question in my original post by the way.) There is also technical content. Such things as the names of the entry points, the return type, the number of parameters and their types. That information really should not be subject to debate. It is determined by the implementation. That might be something the scripts can maintain, however I will leave that maintenance until later. - The detailed information is, at least initially, coming out of the Wine code. It is being generated using scripts. The scripts are very likely to be rerun when a file in the Wine repository changes. It may take a lot of effort to merge the new information with information from other sources. No matter what, if such a wiki is meant to be edited directly you won't be able to merge in data through scripts very long. It will soon have to stand on its own. You had better be wrong on this particular point. If you are in fact correct, it will be impossible to keep the technical information and structural information intact. I believe the descriptive and technical information can be put on seperate pages and sub-pages. The project is still in the planning and experimental phase. The details are in the process of being worked out. - If the licenses are compatible, it should be possible to copy articles between projects. Yes, licensing is an important issue and one you must solve before accepting outside contributions. To incorportate data from the Wine source it must be LGPL-compatible (e.g. GPL). To incorporate data from the Mingw or ReactOS source it must be compatible with their license (GPL?). Even if copying articles from one project to another is technically legal, I think you cannot count on this as a means to avoid massive duplication of effort: as soon as you have over a hundred articles (once fully sutbbed out you should have way over 3) the work involved for watching changes on each side and merging duplicate documentation will be overwhelming (and I suspect finding volunteers for it will be hard too). Whether the information comes out of the Wine code or other code, there could be problems. But that is not where most of the value of this project will lie. It will be in the descriptive information that does not come out of the code. It will be the material the individual contributers add. I suspect that the meta-information will in fact have to be duplicated. It can be different for the different projects. For example Wine is similar to the Microsoft stuff at the file level. They each have DLL
Re: The WineAPI wiki.
On 08/06/2010 05:44 AM, Francois Gouget wrote: On Thu, 5 Aug 2010, Max TenEyck Woodbury wrote: [...] Here's roughly what I have in mind: 1. Win32 API 1. Overview 2. acledit API 1. Overview 2. Functions 1. Func1 2. Func2 ... 3. Interfaces 1. Interface 1 1. Method1 2. Method2 ... 2. Interface 2 1. Method1 2. Method2 ... 4. Datastructures 1. Struct1 2. Struct2 3. Enum1 ... 3. aclui API ... 2. Standard Windows tools 1. attrib command line options 2. cacls command line options ... 3. General platform-specific notes 1. Windows 9x Talks about interaction with DOS, etc. 2. Windows 95 More Win 9x specific general notes 3. Windows NT and greater Kernel stuff 4. Wine 1. Wine architecture documentation 2. Wine-specific dlls 3. Wine-specific tools like winebuild, winemenubuilder, etc) 5. Mingw Stuff about Mingw, etc. 6. ReactOS Stuff about ReactOS, etc. Ah! That is where the misunderstanding is. You are thinking of this as a *document*, a single coherent document. I am not thinking of this as a single document. Each of the above line would be a separate wiki page. [...] Those names are what the scripts maintain. I'm not sure what there is to maintain. I think we are almost in agreement. The problem is the numbers. The numbers *will* change as things evolve. Hopefully, the basic reference *names* will be fairly stable. There will also be indexes from different points of view and the indexes will have sub-pages that redirect to the appropriate basic page. Maintenance will consist of keeping those redirects up-do-date. The pages will also contain sub-pages. Those sub-pages are where the user-editable content are stored. Do you mean that the documentation for an API like CreateFile() would be a collection of pages? That seems counterproductive to me. There is also technical content. Such things as the names of the entry points, the return type, the number of parameters and their types. That information really should not be subject to debate. It is determined by the implementation. Well, yes. That's what Func1, Func2 are above. And on their pages you would get the signature, general documentation of the function, description of what each parameter is for, links to the pages describing the types of the parameters if they're complex, what the function returns, finer points about how the function behaves in corner cases if appropriate, and platform-specific details about how it behaves. That might be something the scripts can maintain, however I will leave that maintenance until later. However while it would be easy for scripts to create a skeleton page, once the page exists and has been editied they may have a hard time changing stuff like correcting the type of an output parameter. But I guess that's why you want to have sub pages I guess. Though I really would not want to have to go through multiple pages for each of the documentation aspects I mentioned above. I believe I understand your concern. From observation it is not going to actually be a problem. The sub-pages are 'transcluded' into the base page. The sub-pages will contain the section headings and when you edit the section, you in fact edit the sub-page. There is a problem that you end up on the sub-page when you finish editing. I'll add a link back to the main article page, and that should make the problem smaller. I suspect that the meta-information will in fact have to be duplicated. It can be different for the different projects. For example Wine is similar to the Microsoft stuff at the file level. They each have DLLs with corresponding names. On the other hand, WinGW consists of a single DLL, if I understand its structure correctly. My mingw-runtime package has a lot of separate 'dlls': libaclui.a, libadvapi32.a, libgdi32.a, etc. Besides, how does that matter? CreateFile() is a kernel32 fnuction, no matter what, and the documentation should reflect that. OK, but they are called 'aclui' in the Wine repository, not 'libaclui.a'. I think each project will want to maintain seperate meta-structure sub-pages so we do not change something about another project's meta structure when we update our own meta-structure. There is complication here no matter how it is done. There is simply too much stuff to keep it really simple. Category markers should be used extensively. Redirection links will be needed to provide views from different perspectives without having to actually replicate art
WineAPI structure plans
I think I have a usable structure for the pages on the WineAPI wiki which I am about to lay before you, but first a discussion of the project name... I understand that some people do not particularly approve of the name I have given this project. It is on Sourceforge and a short relevant name was needed. Much of the information to be presented is specific to Wine and will be based on the contents of the Wine repository. The name reflects that dependence. Other projects may want to use the information presented. They are welcome to do so as far as I am concerned. They may also wish to present information specific to their projects. That is an excellent idea and I will help where I can, but I have two reservations: First, I am unlikely to be familiar with the structure of other projects; I will not be able to maintain those contributions. Someone from the other projects will have to take responsibility for maintaining those contributions and coordinate with the members of the project from Wine. Second, where there are differences between the projects, and the other projects are invited to provide their information but not at the expense of the Wine information. I also included a reference to 'API'. More than just the API will be covered, but the API will definitely be included. While Wine is intended to provide an interface functionally equivalent to the Microsoft products, it will differ from their interface in small ways. One of the most important differences will be that this API is open and *not* particularly designed to promote Microsoft's products. References to the Microsoft documentation will be included, but infringement of Microsoft's copyrights is *not* intended and will be corrected as quickly as it can be verified. The project name can be changed if really necessary, but requests to change it should be constructive with an emphasis on how the new name meets the projects needs. There are two major types of information that will be presented. One type of information is annotation, opinion, discussion, description and so on. This will be managed by people. Another type of information is technical and is tied directly to the contents of the Wine project (and other projects when the details have been worked out). My intention is to write scripts that extract and report this kind of information. This information will change as Wine changes. It will be difficult for the scripts to work around the human generated content. To allow the two major kinds of information to mix, they will be kept on separate pages. Specifically, the editable information will be kept on what MediaWiki calls 'sub-pages'. The places where sub-pages are included will be controlled by the scripts. The script writers will need to be informed of where these inclusions should be placed. Also, to keep the number of 'red-links' under control, The scripts will generate initial versions of the sub-pages. Some structure is needed to make the scripts work and to allow people to check the scripts. For that reason, all script generated pages will start with a comment describing the main script responsible for generating the page along with revision information for the script and script components. The comment will also identify the revision of the repository used to generate the page. (Note, the revision information will be for the last time the page content has to be changed, and will not be updated unless the page content, and not the revision information, is changed. Some structure will also be needed for sub-pages and will be set up in the generated initial versions of those pages. That structure consists of a link back to the article that included the sub-page, markings that the page is editable and at least one section header to serve as a handle to enable easy editing of the sub-page. -Max
Re: [PATCH 1/5] d3dx9_36: Implement D3DXFileCreate. (try 3)
On 10/24/2012 12:02 PM, Rico Schüller wrote:
> On 24.10.2012 16:33, Dmitry Timoshkov wrote:
>> Christian Costa wrote:
>>
> +if (!object)
> +{
> +ERR("Out of memory\n");
> +return E_OUTOFMEMORY;
> +}
The ERR() is useless here, just return E_OUTOFMEMORY in such
situations.
>>> It's done this way in many places in wine.
>>
>> Then that other places need to be fixed as well. Printing an ERR() on
>> memory
>> allocation errors is not helpful.
>>
> In which cases do you use ERR? I thought it is used, when there are
> system errors. And I think ERR is fine for out of memory, because the
> system is not able to hand out the needed memory. Just do a git grep.
> There are ~400 usages for ERR and out of memory... What's your
> suggestion how to do that with the "Out of memory"?
>
My understanding is that this is similar (although less severe) than
writing log messages when out of disk space.
The report may not be generated because the resources needed to produce
the report are not available.
The absence of the report may be taken to mean that the problem is on
some other code path.
Deliberately not reporting 'out of whatever' errors or, better yet,
commenting that reporting such errors are not being generated may make
diagnosing such problems easier.
Re: windowscodecs questions.
On 10/24/2012 02:18 PM, Vincent Povirk wrote: >> I found some code that reads a generic chunk. I see where the size >> and type are read, where a correctly sized record is allocated and >> where the data is read into the record. > > That code is unused for reading and writing PNG images right now, > sorry for the confusion. Libpng has its own code for reading and > writing PNG chunks, and that is what is being used. Our chunk code is > used for PNG metadata handlers (which will have to work independently > from libpng so we can have a proper, pluggable system for metadata), > but the architecture isn't there yet to use those handlers when > reading a PNG image. > >> I added code to read and check the CRC to my working copy of the git >> tree. That threw off the block synchronization, so I think there is >> code someplace else that either checks or skips the CRC, but I have >> not found it after a few hours searching for it. An indication on >> where to look and other advice would be very helpful at this time. > > None of that code should be used yet in a file with more than one > block, so I don't know how this could be causing problems. My plan was > that it would be up to the caller to seek to the next block based on > the returned data size. > Hmm. With the version that reads the CRC, I get more error messages and failures doing a 'make test' than the version without the addition. >> Second: At least two of the methods GuildWars2 wants to use are stubbed. >> To implement those methods, the frame section of the WIC object should >> contain an array (or something with similar properties) of pointers to >> chunks. From what I have read about WIC, other formats could use a >> similar array. Some could even use an array of pointers to frames. >> Before I go messing with that level of change, I think I should listen >> to other peoples opinions of the subject. > > Please keep in mind that Guild Wars 2 is probably not using WIC > directly. You should find out which library it's actually using > (probably d3dx9, but could also be gdiplus or oleaut32's IPicture > interface) and take that into account. We can modify users of WIC to > use it in efficient ways, and/or optimize WIC for the way we are using > it. (MSDN recommends reading the entire image once either in one > CopyPixels call or in rows from top to bottom, and optimizing for that > case. We don't do that yet because we needed the general case first.) > d3dx9. From comments from the developers, they were having trouble with slow access to their data file. It's a huge thing, 30+GB. (Yes, that is a G, not an M). I'd tried a patch on GetCount (which completely misunderstood) and it went on to do something 'ReaderByIndex'. It put more images on the screen much faster for some reason. I have very very little information on the game's internal structure other than what wine logs. >> Third: On a very broad level, the whole OLE implementation seems to be >> very messed up. In particular, the usual practice for doing >> inheritance in C does not seem to be being used. That practice is to >> have the elements common to the base and extending object be placed at >> the beginning of the implementing data structures. While the member >> names need not be the same in all instances, the function, type and >> order of the common elements must be the same for economical >> implementation. > > I don't think a base class would've make anything easier. > >> Is there any reason, other than inertia, that at least these two >> fields should not be moved to the beginning of implementing objects. >> This can be done one object at a time and would allow the changed >> objects to use a common implementation of 'AddRef' at least, and >> another common routine or macro that handles the critical part of >> 'Release'. > > We still couldn't do that because every interface vtable pointer would > be at a different offset within the struct. We couldn't share them > between encoders because different encoders have different data that > they need to free. Anyway, it's not likely to have a measurable impact > on performance. > OK. I was thinking every object based on IUnknown would start with a VTable pointer, a critical section lock and a reference count. I did not expect to see any performance improvement, just the absence of innumerable 'AddRef' and 'Release' variants. In fact I sort of expected both of them to go away as virtual functions with a virtual destructor in their place. > Could you share some results of your profiling? What is it that led > you to believe the PNG code is a bottleneck? > Not allowed to profile as such. It was just the difference in speed when the game thought it had 'PNGGetCount'
Re: [PATCH] Potential reference count races
On 10/28/2012 12:07 PM, Alexandre Julliard wrote: > Nikolay Sivov writes: > >> On 10/28/2012 17:44, Max TenEyck Woodbury wrote: >>> Specifying the unnecessary use of a temporary store is a bad habit to >>> have. You should tell the compiler exactly what needs to be done, not >>> throw in extraneous operations. >>> >>> So, the use of a post operator where a prefix operator is sufficient, >>> while almost certainly harmless, is still technically a mistake. > > You must be joking. > Joking? Only sort of. Just being my usual wryly pedantic self... :-)
Re: [PATCH] Potential reference count races
On 10/28/2012 12:06 PM, Nikolay Sivov wrote:
> On 10/28/2012 17:44, Max TenEyck Woodbury wrote:
>> On 10/28/2012 02:40 AM, Nikolay Sivov wrote:
>>> On 10/28/2012 04:59, m...@mtew.isa-geek.net wrote:
>>>> From: Max TenEyck Woodbury
>>>>
>>>> I have been looking at the Microsoft COM and related documentations
>>>> and noticed that they emphatically recommend using the Interlocked...
>>>> functions when manipulating reference counts. I managed to set up a
>>>> search that showed where many of the reference count updates occur and
>>>> was somewhat surprised at how often this advice was not followed.
>>>
>>> It doesn't mean it always has to be followed.
>>
>> True in a limited sense, but there is a good reason behind their
>> recommendation. Unless there is a good reason not to do so, this
>> particular piece of advice should be followed.
>
> COM objects in wine follow this recommendation in general, even object
> itself is not thread safe.
> This doesn't mean however that you need this every time you have some
> kind of refcount of any sort.
It may or may not be necessary every time, but it should be demonstrated
that it is not necessary rather than assumed that it is not. This is a
'race condition' after all, and they are known to be rare and difficult
to isolate. I think it is good practice to assume there could be a race
problem rather than otherwise.
>>
>>>> While I have not converted every reference count update to use the
>>>> Interlocked... functions, this set of patches fixes a fair number of
>>>> them.
>>>>
>>>> These are not associated with any particular bug report; they are
>>>> simply a general precaution against operations that are known to be
>>>> associated with race conditions.
>>>
>>> This precaution doesn't work in general. It's not enough to atomically
>>> update refcount to make an implementation thread safe. Also not
>>> everything is supposed to be thread safe in a first place.
>>>
>> First, explain what does not have to be thread safe.
>
> Anything really, COM objects in particular if you were talking about them.
>
I think you are talking about the apartment model here, which forces
thread serialization. Despite that, the Microsoft documentation still
recommends interlocked operations on reference counts...
>> I believe that application may try to use multiple threads anywhere,
>> so everything that can be made thread safe, should be.
> No.
What do you mean 'No'. That is an opinion, If you disagree, please
explain why.
>> Using interlocks on the reference count updates is a necessary step
>> for thread safety. You are correct that it is not sufficient, but
>> it is necessary.
> Again, it depends.
Yes, it might depend on many factors, most of which will make it safe
to not interlock, but it is a lot of work checking that all those
factors necessary to not use the interlock are in fact in place.
Further, if enough of those factors get changed, you have a problem.
This is what make code fragile. Fragile can be avoided with steps
like this.
>>
>>> Changes like this:
>>>
>>>> -for (i=0;i>>> +for (i=0;i>>>TRACE("notify at %d to %p\n",
>>>>notify[i].dwOffset,notify[i].hEventNotify);
>>>
>>> are not helpful at all.
>>>
>> The post increment and decrement operation are specified as saving
>> the original value for use in the evaluation of the expression they
>> are part of and modifying the underlying stored value. In expressions
>> like this, that saved value is then discarded. The optimization phase
>> of the compilation usually removes both the save and discard operations.
>
> Sure, but I don't think it's enough to justify such changes all over the
> place, in existing code.
>
I agree that it is not enough to justify a separate set of patches, but
as part of another set of changes, I think it is justified. After all,
how else are examples of bad code going to be removed.
Re: [PATCH] Remove potential reference count races
On 10/28/2012 12:07 PM, Nikolay Sivov wrote:
> On 10/28/2012 18:00, Max TenEyck Woodbury wrote:
>> On 10/28/2012 03:13 AM, Nikolay Sivov wrote:
>>> On 10/28/2012 04:59, m...@mtew.isa-geek.net wrote:
>>>> From: Max TenEyck Woodbury
>>>>
>>>> ---
>>>>dlls/shlwapi/thread.c |4 ++--
>>>>1 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/dlls/shlwapi/thread.c b/dlls/shlwapi/thread.c
>>>> index eb2c35d..43e0433 100644
>>>> --- a/dlls/shlwapi/thread.c
>>>> +++ b/dlls/shlwapi/thread.c
>>>> @@ -157,7 +157,7 @@ static ULONG WINAPI threadref_AddRef(IUnknown
>>>> *iface)
>>>> threadref * This = impl_from_IUnknown(iface);
>>>>TRACE("(%p)\n", This);
>>>> - return InterlockedIncrement(This->ref);
>>>> + return InterlockedIncrement(&This->ref);
>>>>}
>>>> static ULONG WINAPI threadref_Release(IUnknown *iface)
>>>> @@ -167,7 +167,7 @@ static ULONG WINAPI threadref_Release(IUnknown
>>>> *iface)
>>>>TRACE("(%p)\n", This);
>>>>- refcount = InterlockedDecrement(This->ref);
>>>> + refcount = InterlockedDecrement(&This->ref);
>>>> if (!refcount)
>>>> HeapFree(GetProcessHeap(), 0, This);
>>>>
>>> Did you try to build this?
>>>
>>>
>> Yes, it built. I don't submit stuff that causes the compiler to barf
>> unless I am completely totally zonked from lack of sleep and this was
>> not what happened here. I will admit that I have not looked at the
>> build and test logs closely, so there may be problems I missed.
>>
> These changes I wrong that's what I'm saying.
You could well be right about this one. All the other '->ref's are LONG
or ULONG or DWORD and the '&' is necessary. If this one is a pointer,
then I messed up.
>
> P.S. please CC wine-devel list in your replies.
>
Pushed the wrong button when setting up for the reply. Apologies.
Add data members to interface data structures?
Would a patch that allows data members to be hacked into interface data structures be acceptable? Specifically, this would add sequences that follow this template: #ifdef _IFACE_DATA _IFACE_DATA #endif /* _IFACE_DATA defined */ for each inherited interface, in order.
Re: How to tell Mac from Linux wine within a Wine app? (steam hardware survey)
On 11/10/2012 02:03 PM, Scott Ritchie wrote: > Is there an easy way for the steam hardware survey to tell whether it's > running under Mac or Linux Wine? > > I remember discussing this issue with an engineer from Valve after > asking they make the % of Wine users public again. > > Why do you care? The best way is probably to try something that works on a Mac, and if it comes back with 'not implemented', try a workaround that works with Wine. It would not be a good idea to infer that because one thing is broken under wine, that some other work around is also needed. Each capability should be checked separately. Things can change fairly rapidly in Wine.
Re: [PATCH] tools/widl/header.c: Add a way to declare interface data members.
I mentioned this a few days ago. It would have helped if you had raised this point then. As it stands, it is simply a way to adding data members to an aggregate with an interface. In that sense it is not an addition to the interface since the Vtbl pointer remains exactly as before. The new information is not part of the interface as such. Putting it in the same 'struct' as the Vtbl is simply a way of enforcing the association. If you do not define a _IFACE_DATA macro, nothing happens.
Re: [PATCH] tools/widl/header.c: Add a way to declare interface data members.
On 11/11/2012 01:01 AM, Nikolay Sivov wrote: > On 11/11/2012 05:00, Max TenEyck Woodbury wrote: >> I mentioned this a few days ago. It would have helped if you had >> raised this point then. >> >> As it stands, it is simply a way to adding data members to an aggregate >> with an interface. > > Data members to an aggregate? What are you talking about and what it has > to do with interface definition? An aggregate is a collection of information, like a class, struct or union. Some aggregates include 'interface's, a COM, OLE or RPC thingy. The interface can have only methods defined, but those methods might want access to some additional data. To get to that data, the method now has to build a pointer to the containing aggregate and reference the data through that pointer. This introduces complications to the code since the data may not be in same place in the aggregate in each instance where the interface is used. You need a slightly different code sequence for each different place the method is needed. However, the source code will be virtually identical for each instance. This patch allows those aggregate data members associated with the interface, which are not technically part of the interface, to be placed in a fixed relation to the interfaces Vtbl pointer. (Practically the Vtbl pointer is the interface.) By establishing such a relationship, the need to convert from the pointer to the interface (specifically to its Vtbl pointer) to a pointer to its containing aggregate in order to get to the relevant data is removed. Now, technically, the associated data is not part of the interface. It is part of the aggregate containing and implementing the interface. Moving the declaration from the aggregate to the end of the struc for the interface is a hack that lets simpler and more general code to be generated. So, it's a hack, that you only use if you want to, to speed up execution and simplify maintenance.
Re: [PATCH] tools/widl/header.c: Add a way to declare interface data members.
On 11/11/2012 03:05 PM, Michael Stefaniuc wrote: > On 11/11/2012 07:12 AM, Max TenEyck Woodbury wrote: >> On 11/11/2012 01:01 AM, Nikolay Sivov wrote: >>> On 11/11/2012 05:00, Max TenEyck Woodbury wrote: >>>> I mentioned this a few days ago. It would have helped if you had >>>> raised this point then. >>>> >>>> As it stands, it is simply a way to adding data members to an aggregate >>>> with an interface. >>> >>> Data members to an aggregate? What are you talking about and what it has >>> to do with interface definition? >> >> An aggregate is a collection of information, like a class, struct or >> union. > > Your mixing up terminology. > Please excuse the confusion. I learned that usage when I worked for DEC in the 1980's. >> Some aggregates include 'interface's, a COM, OLE or RPC thingy. The >> interface can have only methods defined, but those methods might want >> access to some additional data. To get to that data, the method now >> has to build a pointer to the containing aggregate and reference the >> data through that pointer. This introduces complications to the code >> since the data may not be in same place in the aggregate in each >> instance where the interface is used. You need a slightly different >> code sequence for each different place the method is needed. However, >> the source code will be virtually identical for each instance. >> >> This patch allows those aggregate data members associated with the >> interface, which are not technically part of the interface, to be >> placed in a fixed relation to the interfaces Vtbl pointer. >> (Practically the Vtbl pointer is the interface.) By establishing such >> a relationship, the need to convert from the pointer to the interface >> (specifically to its Vtbl pointer) to a pointer to its containing >> aggregate in order to get to the relevant data is removed. > > Please check how a C compiler is laying out structs in memory. In both > cases the data is at a fixed offset (calculated at compile time) in > relation to the interface. > I believe you are confused here. The relative addresses in the original may change if changes are made to the aggregate. If you want to tell the compiler which aggregate member you want to use, you need to use a pointer to the aggregate. It has no way to figure out what you are talking about unless you give it that without this hack. >> Now, technically, the associated data is not part of the interface. It >> is part of the aggregate containing and implementing the interface. >> Moving the declaration from the aggregate to the end of the struc for >> the interface is a hack that lets simpler and more general code to be >> generated. >> >> So, it's a hack, that you only use if you want to, to speed up >> execution and simplify maintenance. >> > It is a hack that breaks the ABI (sizeof(interface) == sizeof(void*)), > doesn't improves the generated code, doesn't simplify maintenance at > all, quite the contrary. This sounds more like trolling than a serious > attempt to improve Wine. > That depends on exactly what you call the 'interface'. If you call the Vtbl the interface, the size does not change. If you call the 'struct' containing the Vtbl the interface (which someone else pointed out is only an artifact of the implementation technique), it changes. So, as with most hacks, you have to be careful what you ask for. I might change my mind if you point out an existing non-contrived example of using sizeof() that this would break. The real question is ;Could it be useful?'. I think the answer is 'yes'.
Implementation of PNG 'Get Count' and indexed reads...
These are currently returning 'not implemented'. Would it make sense to have 'GetCount' always return '1' and have the indexed read simply read in the whole thing?
Re: Implementation of PNG 'Get Count' and indexed reads...
On 11/14/2012 07:03 AM, Dmitry Timoshkov wrote: > Max TenEyck Woodbury wrote: > >> These are currently returning 'not implemented'. >> >> Would it make sense to have 'GetCount' always return '1' and have the >> indexed read simply read in the whole thing? > > Looks like you don't understand what those APIs do. What's that 'the whole > thing'? > Yes, it's the simplest way to stub the whole sequence into doing something useful. When someone wants to get fancy, they can build a vector of blocks, but that is much more work. Definitely NOT great, but better than nothing, which is what we have now. 'The whole thing' is the entire image in one swallow.
Re: Implementation of PNG 'Get Count' and indexed reads...
On 11/14/2012 09:38 AM, Dmitry Timoshkov wrote: > Max TenEyck Woodbury wrote: > >>>> These are currently returning 'not implemented'. >>>> >>>> Would it make sense to have 'GetCount' always return '1' and have the >>>> indexed read simply read in the whole thing? >>> >>> Looks like you don't understand what those APIs do. What's that 'the whole >>> thing'? >>> >> Yes, it's the simplest way to stub the whole sequence into doing >> something useful. When someone wants to get fancy, they can build a >> vector of blocks, but that is much more work. Definitely NOT great, but >> better than nothing, which is what we have now. >> >> 'The whole thing' is the entire image in one swallow. > > Then you need to investigate what should be returned and in which format, > probably write some tests, read some docs. > Document reading is in progress. Have the PNG side more or less in hand, Need to do the windows side. Looking for an overview and match between the two. So, its just a small mater of code... Would calculating the total number of 'row' calls and reading each row as a 'block in turn be an alternate implementation?
Re: Implementation of PNG 'Get Count' and indexed reads...
On 11/14/2012 10:15 AM, Dmitry Timoshkov wrote: > Max TenEyck Woodbury wrote: > >> Would calculating the total number of 'row' calls and reading each row >> as a 'block in turn be an alternate implementation? > > No, your terminology (what is a "row" in PNG?) shows lack of undertsanding > of what is a block, or what that APIs are supposed to return. Start with > writing a couple of simple tests, and demonstrate that you really undrestand > things before asking further questions. > PNG terminology does not mention 'blocks' as such. It talks about 'rows' and 'chunks'. 'Row' is mentioned in the 'libpng' terminology, as in reading a 'row' and 'row_pointer'. It is apparently a unit of processable data. Much as a block is apparently a unit of processable data from the WIC end. WIC is the end I have only scratched the surface on.
Re: RFC: Remove auto-scan of ALSA devices from winealsa.drv
On 12/11/2012 10:46 AM, Henri Verbeet wrote: On 11 December 2012 16:05, wrote: Cost to users: Users with a working ALSA device "default" should experience no drawback, only benefits. I believe this is the vast majority of users. Users that edit their ~/.asoundrc to define other devices without simultaneously overriding !default will have to additionally edit the Wine registry to name their working ALSA capture and render devices, e.g. "asnoop" and "amix". It will also pretty much just remove device selection on setup with multiple audio devices, which is actually fairly common these days with USB audio devices and HDMI outputs on graphics cards. I think the correct approach would to work with upstream ALSA to fix things, instead of just removing device enumeration. I do not think this is a particularly good idea. I do have two sound systems on my machine and I have assigned each to different roles. That seems to work quite well. What does not work well is leaving the role set to 'default'. That results in the selection of the highest latency device with corresponding stutters and over-runs. The current requirement for selecting an output device is mildly annoying, but no where near as annoying as being forced to use a faulty device.
Re: RFC: Remove auto-scan of ALSA devices from winealsa.drv
On 12/11/2012 02:11 PM, Austin English wrote: On Tue, Dec 11, 2012 at 9:39 AM, Max TenEyck Woodbury wrote: On 12/11/2012 10:46 AM, Henri Verbeet wrote: It will also pretty much just remove device selection on setup with multiple audio devices, which is actually fairly common these days with USB audio devices and HDMI outputs on graphics cards. I think the correct approach would to work with upstream ALSA to fix things, instead of just removing device enumeration. I do not think this is a particularly good idea. I do have two sound systems on my machine and I have assigned each to different roles. That seems to work quite well. What does not work well is leaving the role set to 'default'. That results in the selection of the highest latency device with corresponding stutters and over-runs. The current requirement for selecting an output device is mildly annoying, but no where near as annoying as being forced to use a faulty device. You'd still be able to select a different device in the registry. Replacing the ability to use a drop box in the app to select the audio device with a 'regedit' session is not an improvement. On the other hand, I may not understand the impact of this proposal...
A new demangler test?
Would it be appropriate to add a test to the name demangler that: 1) Scans all '.dll' and '.spac' files for mangled names, and 2) Tries to decode those names. 3) Prints the mangled and decoded names and where they occur. Success would be that all names decode without the decoder blowing up or failing.
Re: A new demangler test?
On 02/23/2013 02:54 AM, Eric Pouech wrote: Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit : Would it be appropriate to add a test to the name demangler that: 1) Scans all '.dll' and '.spec' files for mangled names, and 2) Tries to decode those names. 3) Prints the mangled and decoded names and where they occur. Success would be that all names decode without the decoder blowing up or failing. adding tests for demangler is good but you just need to have a set of mangled/unmangled strings for the test as core demangler in msvcrt, test should be added here... (but grabbing the mangled strings shall be left out of the test itself) A+ One of the important aspects of name demangling is that it should work on _all_ the names in the current system. The current test does demangle a list of known strings, but that list was incomplete with respect to all the features used in real names the last time I dug into the details (which was none too recently). Scanning for all the real mangled names not only makes sure that the demangler is working properly, it also assures that all the names used are properly formed and decode to their intended values.
Re: A new demangler test?
On 02/24/2013 04:18 AM, Nikolay Sivov wrote: By the way, do you see something broken or it's just something you want to work on? Partly broken. If fed a bad string, it sometimes blows up and sometimes returns an error code. The 'real' routine also blows up on some strings. Which strings depends on the windows version. That means there is no specific bug we have to match, so it would make sense to do it right (that is return an error code) in all cases. Is that OK? In my opinion, the search for names is fairly important, but it may not belong in a msvcrt test. It might be better as part of a dbghelp test or in some other utility test. That search should work in a windows environment as well as a Wine environment. It should almost certainly check all the '.dll's in 'C:\windows\system*' and possibly a few other places where mangled names are likely to be found... But I have to admit, it is also something I want to work on...
Re: msvcp60: Avoid signed-unsigned integer comparisons
On 03/10/2013 07:00 AM, Henri Verbeet wrote: On 10 March 2013 08:20, larmbr zhan wrote: But It behaves different when it is signed or not. According to C Standard, >> - For the signed case, once it overflows, resulting in representing a negative value . Actually, signed overflow behavior is undefined according to the standard. Specifically, some hardware throws an exception on signed arithmetic overflow and C is specifically designed to be hardware independent, so it has to be 'undefined behavior'. - For the unsigned case, once it overflows, resulting in representing a value reduced modulo the largest value that object could hold. Nit: modulo the largest value the object can hold _plus one_, but it should be treated as another 'undefined behavior'. To further complicate the issue, while size_t is always unsigned, size_t can be 16, 18, 32, 36 or 64 bits and still be compliant. So use 'size_t' when you are talking about the size of something, and 'unsigned' for flag sets and counts.
Re: [PATCH 2/2] gdi32: Clip font glyphs to fit within text metrics.
On 04/19/2013 02:46 AM, Dmitry Timoshkov wrote: Sam Edwards wrote: This change only affects malformed fonts that have glyphs with splines that go above the maximum ascent as specified in the font's hhea/os2 table. For that reason, any tests for this change would have to include a malformed font, so I did not write tests. If we want in-tree tests, we'll need to figure out how to include a malformed font to test against. Please add a test case, Wine test suite already includes custom fonts, you can either use an existing font, or add a new one. As I understand it, some fonts deliberately have glyphs larger than their metrics bounding boxes. Clipping them is almost certainly not a good idea.
Re: [PATCH] dlls/gdi32/fretype.c: Avoid division by zero.
On 05/04/2013 12:38 AM, Dmitry Timoshkov wrote:
m...@mtew.isa-geek.net wrote:
+if ( font->aveWidth && font->potm->otmTextMetrics.tmHeight ) {
+if (((font->aveWidth + font->potm->otmTextMetrics.tmHeight - 1) /
+ font->potm->otmTextMetrics.tmHeight) > 100) {
WARN("Ignoring too large font->aveWidth %d\n",
font->aveWidth);
font->aveWidth = 0;
}
In which case font->potm->otmTextMetrics.tmHeight is going to be 0?
I am not sure what you are asking. I have had this particular division
throw an exception for some font I have installed, but I have no idea
which one at the moment. So if you are implying that font->aveWidth==0
is always true if font->potm->otmTextMetrics.tmHeight==0, that seems not
to be the case.
Re: [PATCH] dlls/gdi32/fretype.c: Avoid division by zero.
On 05/04/2013 01:56 AM, Dmitry Timoshkov wrote:
Max TenEyck Woodbury wrote:
+if ( font->aveWidth && font->potm->otmTextMetrics.tmHeight ) {
+if (((font->aveWidth + font->potm->otmTextMetrics.tmHeight - 1) /
+ font->potm->otmTextMetrics.tmHeight) > 100) {
WARN("Ignoring too large font->aveWidth %d\n",
font->aveWidth);
font->aveWidth = 0;
}
In which case font->potm->otmTextMetrics.tmHeight is going to be 0?
I am not sure what you are asking. I have had this particular division
throw an exception for some font I have installed, but I have no idea
which one at the moment. So if you are implying that font->aveWidth==0
is always true if font->potm->otmTextMetrics.tmHeight==0, that seems not
to be the case.
If font->potm->otmTextMetrics.tmHeight is 0 then the font is invalid and
should not be loaded and used at all. There is no point is adding checks
for things that shouldn't happen, and may cause various bad things in other
places of code as well.
Sorry, but WRONG. It HAPPENS. Someplace in the collection of fonts I
have accumulated from standard sources, there is at least one that has
this property but is otherwise useful. You can say all you want about
'it should not be loaded', but it does load. This deals with the
problem.
Further, this was NOT a problem until the patch that introduced the
SCALE_X and SCALE_Y macros. I did a bisection and that was the commit
that introduced the divide by zero exception. Before that patch, there
was no exception thrown by this code. With that patch and since then
it throws a divide by zero consistently. I did NOT change my font
mix. The wine test suite simply started throwing a divide by zero
exception at that point. I have not gone over that patch in detail,
but its intent seems to have been clear. There was just some detail
that messed up. This patch corrects the problem.
If you REALLY think the font should not load, you should add code to
reject the font with an appropriate diagnostic, not have this code
throw a divide by zero exception and abort execution. Until you do
that, this patch is needed.
Re: [PATCH] dlls/gdi32/fretype.c: Avoid division by zero.
On 05/04/2013 10:50 AM, Dmitry Timoshkov wrote: Max TenEyck Woodbury wrote: If you REALLY think the font should not load, you should add code to reject the font with an appropriate diagnostic, not have this code throw a divide by zero exception and abort execution. Until you do that, this patch is needed. First, what is needed, is an investigation what is happening exactly, that's what I asked about in the first place. If you belive that tmHeight being 0 is normal and should be accepted, then you need to provide more details and probably a test case. Sorry, but that is not the case. While an investigation would be useful, the question that it is normal or not is not relevant. The simple fact is that it happens. Since it DOES happen, the patch should be applied, at least until some code elsewhere assures that it can not happen. If you want to throw in a 'FIXME' to the effect that it should not happen and a test is needed to assure that, by all means do so.
Re: [PATCH] dlls/gdi32/fretype.c: Avoid division by zero.
On 05/04/2013 11:30 AM, Dmitry Timoshkov wrote: Max TenEyck Woodbury wrote: If you REALLY think the font should not load, you should add code to reject the font with an appropriate diagnostic, not have this code throw a divide by zero exception and abort execution. Until you do that, this patch is needed. First, what is needed, is an investigation what is happening exactly, that's what I asked about in the first place. If you belive that tmHeight being 0 is normal and should be accepted, then you need to provide more details and probably a test case. Sorry, but that is not the case. While an investigation could be useful, the question that it is normal or not is not relevant. The simple fact is that it happens. Since it DOES happen, the patch should be applied, at least until some code elsewhere assures that it can not happen. If you want to throw in a 'FIXME' to the effect that it should not happen and a test is needed to assure that, by all means do so. I wonder why did you bother with sending a patch at all? You don't want to provide any details or do any investigation. With such an attitude just open a bug report in bugzilla, and let somebody else do real work for you, but even then you will be asked to provide at least some details. You are trying to make this about me. It is not. Windows fairly obviously does not do this 'sanity' test. Wine is supposed to imitate windows. To do this absolutely correctly, the whole 'sanity' test should go away. The patch merely reduces the problem from totally unacceptable to tolerable. The original code snippet is low quality. There should not be any division in the 'sanity' test. As I said, it really does not belong in wine. If you insist on including it in something like its original form, multiply both sides of the comparison by the 'denominator'. Maybe throw in a couple of 'iabs(...)'s. Why send the patch? Because, for me, all versions of wine have been unacceptable since the problem appeared. Wine simply should not throw this exception. An application that uses a font with this problem will blow up. The standard 'make test' suite on my machine has the problem. I isolated the problem, and came up with a fix. Bug reports are for cases where you can not yourself identify the bad code. That this code is bad is obvious when you know that it can throw an exception. The only investigation absolutely needed is to report the occurrence of the exception. It happens in at least some circumstances. Anything additional is simply an invitation to delay.
Re: [PATCH] dlls/gdi32/fretype.c: Avoid division by zero.
On 05/04/2013 05:37 PM, Sam Edwards wrote: On 05/04/2013 12:59 PM, Max TenEyck Woodbury wrote: You are trying to make this about me. It is not. Windows fairly obviously does not do this 'sanity' test. Wine is supposed to imitate windows. To do this absolutely correctly, the whole 'sanity' test should go away. This sounds like an excellent reason to write a conformance test. A test that succeeds on Windows but fails under Wine is a great way to convince everyone that the patch is necessary. It's also gives us a closer look at Windows's behavior under the same circumstances, so we can see whether Windows does this sanity check or not, and if not, how it reacts when aveWidth is wrong. Having wine throw an exception where it did not do so before is another kind of problem indicator. One that hardly needs a special conformance test. I should note, the commit that introduces the sanity check (21589993826cdb1cb2f87ceb94c8a188bd4a3090) also includes a test (dlls/gdi32/tests/font.c:3908 as of this writing) that passes under Windows, which could mean that Windows actually does include this sanity check for the width vs. the height. Hmm. As I suspected, that is a single point pass only test. It does not explore any of the possible fail conditions. Thus, it is also definitely a possibility that Windows makes no such sanity check. I isolated the problem, and came up with a fix. Bug reports are for cases where you can not yourself identify the bad code. That this code is bad is obvious when you know that it can throw an exception. The only investigation absolutely needed is to report the occurrence of the exception. It happens in at least some circumstances. Anything additional is simply an invitation to delay. Are we sure that *this* code is the problem? Almost certainly. Without this patch, the 'make test' suit throws a divide by zero exception and brings up a dialog box. With this patch, it does not. I believe that is sufficient to convict the unpatched code of having something wrong with it. As Dmitry has said, tmHeight should never be 0, so it's probably valid to assume tmHeight!=0. But that assumption can be checked. Currently there is no such check. 'Should' in this context is a very bad word and has no place at the foundation of an argument about what actually happens. The bug may instead be in allowing the font to load with tmHeight=0, and this is merely the first crash that the problem causes for you. But what about apps that divide by tmHeight under the same assumption? We can't change those, so it's better to fix tmHeight. If the APP does the division, that is the APP's problem. Wine, on the other hand should not throw an exception, and it did NOT do so until recently. Whoever wrote the new code (Dmitry?) should have put in the check or made the test work without doing a division. The fact that it fails is the problem being addressed. Are delays necessarily a bad thing? This bug doesn't have any security implications, and we aren't hurrying to catch the Wine 1.6 release window. We can afford to take the extra time to ensure the quality of the patch. :) I have no objection to someone writing an alternative patch and backing this one out when that patch goes in, but until then, this patch, or something like it, needs to be applied. With wine throwing the exception, some Apps are going to fail that would not fail otherwise. That is definitely a 'Bad Thing' and should be fixed ASAP (like right now)!
Re: [PATCH] dlls/gdi32/fretype.c: Avoid division by zero.
On 05/04/2013 07:50 PM, Hin-Tak Leung wrote: I'd like to mention two things: - there were(are?) overflows/underflows within Freetype itself, up to and including 2.4.11 - the fixes went into trunk, but AFAIK 2.4.12 isn't release yet. That's specifically affect 32-bit platform, and emulated styles (i.e. where the application requires a font style which cannot be provided by any one font, but needed to be "synthesized" by fontconfig and freetype). - there a few well-known "open-source" fonts which microsoft's gdiplus does not like and crash on them, but nonetheless, windows users never encounter the problems, because they typically have the proprietary MS equivalent, and therefore do not need those fonts at all. I suggest - (1) check out freetype trunk to see if it helps, or at least, patch your freetype with those fixes from end of January; (2) modify the "Avoid division by zero" patch to emit the font's typeface > name whenever the condition occur, and just run it on the affected system to see which typeface wine doesn't like? Does this sound reasonable? Actually quite reasonable, particularly the part about identifying the troublesome font. However, I doubt that it would be accepted by the others.
Re: [PATCH] dlls/gdi32/fretype.c: Avoid division by zero.
OK. Let's summarize:
There are some fonts where tmHeight is in fact 0. If Hin-Tak Leang is
correct, these may be Open-Source fonts possibly with proprietary
equivalents. Since I have hundreds of fonts installed on my system, it
is almost certain that I have one or more. Identifying which without
support in wine is a large task, not to be undertaken lightly.
Dmitry argues that this should not happen. Fine :-(. That's a Coulda,
Shoulda, Woulda argument. When it meets reality, it holds no water. It
is the reality that has to be dealt with.
The code in the 'sanity test' is too low quality. It throws divide by
zero exceptions. That is *not* acceptable. The patch I made leaves
that code practically unchanged and works around only the exception
problem. It is an absolutely minimalist change. It changes only what
is absolutely necessary. A better patch is possible, but it hides the
direct source of the problem (which makes the designation 'better'
debatable):
+ if ( font->aveWidth ) {
+if ((font->aveWidth + font->potm->otmTextMetrics.tmHeight - 1) >
+(font->potm->otmTextMetrics.tmHeight) * 100)) {
WARN("Ignoring too large font->aveWidth %d\n", font->aveWidth);
font->aveWidth = 0;
}
}
Either my original patch or this one *must* be applied to remove the
possibility of a divide by zero exception.
All discussion about what *SHOULD* be done when tmHeight is 0 is another
issue and has *NOTHING* directly to do with this patch. It is, however,
a significant question, and does need to be investigated. It probably
deserves a bugzilla entry, but it is *ANOTHER ISSUE*. As part of *THAT*
issue, I totally think the current 'conformance test' is inadequate and
needs expansion, but I am *NOT* the person to do that. *NOR* am I the
person who would be best at addressing *THAT* problem.
Re: [PATCH] dlls/gdi32/fretype.c: Avoid division by zero.
On 05/05/2013 12:09 AM, Sam Edwards wrote: On 05/04/2013 08:27 PM, Max TenEyck Woodbury wrote: OK. Let's summarize: There are some fonts where tmHeight is in fact 0. If Hin-Tak Leang is correct, these may be Open-Source fonts possibly with proprietary equivalents. Since I have hundreds of fonts installed on my system, it is almost certain that I have one or more. Identifying which without support in wine is a large task, not to be undertaken lightly. Let's try to fully understand this problem and identify a font that causes the issue. Since you already have one installed in your font library, you could just run the tests with the attached patch applied and make quick work of identifying the troublesome font. Maybe (hopefully) it's an easy font to obtain so all of us can get a better look at what's going on. I'm going to *guess* that tmHeight being 0 is the actual problem, but we won't know until we try the same font on Windows and see what Windows does. If Windows also produces tmHeight=0, then this patch makes perfect sense. If Windows gives a non-zero tmHeight under the same circumstances, then we know the problem is in the font loader, and we'll fix that instead, thus making this patch unnecessary because tmHeight will always be nonzero anyway. $ grep ' has tmHeight=0, aveWidth=' 201305055-make-test-native.log err:font:get_text_metrics Font named 'Emmentaler-Brace' has tmHeight=0, aveWidth=3! err:font:get_text_metrics Font named 'Emmentaler-Brace' has tmHeight=0, aveWidth=3! err:font:get_text_metrics Font named 'Emmentaler-Brace' has tmHeight=0, aveWidth=3! err:font:get_text_metrics Font named 'Emmentaler-Brace' has tmHeight=0, aveWidth=3! err:font:get_text_metrics Font named 'RiordonFancy' has tmHeight=0, aveWidth=0!
Re: [PATCH] dlls/gdi32/fretype.c: Avoid division by zero.
On 05/05/2013 06:27 PM, Sam Edwards wrote: So, Wine's font loader seems to be working appropriately and thus the sane thing to do is to make sure tmHeight=0 is handled gracefully. Just to make this clear, the most recent version of this patch is such a graceful handling, right?
Re: [PATCH] dlls/gdi32/freetype.c: A better divide by zero fix, report bad fonts.
On 05/07/2013 08:15 AM, Sam Edwards wrote:
On 05/06/2013 03:05 PM, Max TenEyck Woodbury wrote:
Just to make this clear, the most recent version of this patch is such
a graceful handling, right?
I haven't worked on gdi32/freetype.c much, so I wouldn't be the one to
say for sure (you should probably talk to Alexandre Julliard, Dmitry
Timoshkov, or Huw Davies), but I'll give you my thoughts anyway:
On 05/05/2013 12:48 PM, m...@mtew.isa-geek.net wrote:
+ /* HACKHACK: If a font has tmHeight=0, let us know. */
+ if (!font->potm->otmTextMetrics.tmHeight) {
+ ERR("Font named '%s' has tmHeight=0, aveWidth=%d!\n",
font->ft_face->family_name, font->aveWidth);
+ }
+
Since we've learned that tmHeight=0 is not actually an error, it doesn't
make sense to log it using ERR(...). I would suggest a TRACE(...) or
(preferably) nothing at all. Also, when I wrote the ERR message patch
for you, it was intended only to help you locate the problematic font
and wasn't meant to be included in upstream Wine. (Which is why I marked
it with HACKHACK and didn't bother to use debugstr_a.)
As for the actual check, it makes sense to consider what the math is
trying to do: If aveWidth is extremely large (relative to tmHeight),
then assume aveWidth is wrong and set it to 0. If tmHeight is 0, then it
seems reasonable to assume that aveWidth isn't valid either.
I'm not sure why the sanity check cares to do this:
(aveWidth+tmHeight-1) / tmHeight > 100
When it can just do this:
(aveWidth+tmHeight-1) / tmHeight > 100
= (aveWidth-1)/tmHeight + 1 > 100
= (aveWidth-1)/tmHeight > 99
= (aveWidth-1) > tmHeight*99
= aveWidth > tmHeight*99 + 1
≈ aveWidth > tmHeight*100
This allows us to write out tmHeight just once, and is also much easier
to understand at a glance.
So, I would just simplify the whole sanity check to something like:
/* Make sure that the font has sane width/height ratio */
if (font->aveWidth > font->potm->otmTextMetrics.tmHeight * 100)
{
WARN("Ignoring too large font->aveWidth %d\n", font->aveWidth);
font->aveWidth = 0;
}
But even then, the sanity check itself sounds like a workaround for a
much deeper bug. Maybe add a "FIXME: Investigate why this is necessary"
comment while you're at it?
Best,
Sam
OK. Could you please put in a patch that removes the divide by zero
crash? You obviously have a much better understanding of the situation
than I do, but the crash still is a Bad Thing and needs to go away.
Re: [PATCH 6/6] d3d9/tests: d3d9ex video memory accounting tests
On 05/15/2013 06:32 AM, Henri Verbeet wrote: On 14 May 2013 23:46, Stefan Dösinger wrote: These tests have the potential to break on Windows when other applications create or release a large number of video memory resources while the test is running. Yeah, maybe we don't really need this to be in the tree, although it's good to see for reference. OTOH, if they work on a moderately loaded, as opposed to a heavily loaded, Windows system they _are_ valid tests, and provide good targets for the wine implementations.
WineAPI wiki progress.
The wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php now has pages for the directories in the Wine Repository with classifications of the directory content. Please take a look at it and tell me if you think the content is useful and how it could be improved. None of the analysis of the file content is in place. I plan to start with analysis of the '.spec' files. That should make some of the information on the API available. - Max
WineAPI wiki progress (resent)
The previous version ended up as a reply to something inappropriate. The wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php now has pages for the directories in the Wine Repository with classifications of the directory content. Please take a look at it and tell me if you think the content is useful and how it could be improved. None of the analysis of the file content is in place. I plan to start with analysis of the '.spec' files. That should make some of the information on the API available. - Max
Re: WineAPI wiki progress (resent)
On 09/15/2010 10:25 AM, GOUJON Alexandre wrote: On 09/15/2010 03:32 PM, Max TenEyck Woodbury wrote: The wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php now has pages for the directories in the Wine Repository with classifications of the directory content. Well, to be frank, I don't like the structure. Doxygen is able to produce colored and well structured pages but it's not perfect. Personally, I prefer something like this [1] and this [2] for the detail. I know frames are something awful but in this case, this is quite handy. But it's just my thoughts. I hope you'll get more feedback. Many thanks for your efforts --- (I bookmarked the [1] some years ago so ignore the deprecated "1.5.0") [1]: http://download.oracle.com/javase/1.5.0/docs/api/ [2]: http://download.oracle.com/javase/1.5.0/docs/api/java/applet/AppletContext.html Nice examples... I'm not sure it would be practical to do that with the way Sourceforge has its standard MediaWiki app configured, and frankly I've not gotten around to figuring out how to install and configure MediaWiki de novo. Another problem is getting the descriptive information. I know a way to do it, but it would put a hell of a load on the Sourceforge server. It would also be very evil to edit. With several hundred directories to scan, I'm not sure the extra effort to add it to the top level directory analysis pages is going to be useful. I wanted to direct that effort to the working directory pages. - Max
Re: WineAPI wiki progress (resent)
On 09/15/2010 10:56 AM, Francois Gouget wrote: On Wed, 15 Sep 2010, Max TenEyck Woodbury wrote: The previous version ended up as a reply to something inappropriate. The wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php now has pages for the directories in the Wine Repository with classifications of the directory content. Please take a look at it and tell me if you think the content is useful and how it could be improved. The first thing is that it requires a SourceForge login which is just wrong for what's supposed to be a public resource. Hopefully that's temporary but it's likely to limit who can comment on it. Actually, that was a mistake on my part. If you use: https://sourceforge.net/apps/mediawiki/wineapi/index.php you can skip the login. I don't see the point of creating one page for every single Wine source file. That makes the WineAPI website very very Wine-specific and duplicates GitWeb functionality. My understanding is that this is supposed to provide documentation about the Windows APIs in a more open, collaborative and long-term way than MSDN. People who come for the documentation won't care whether CreateFile is implemented in file.c or kernel_main.c and that Wine has a Makefile.in file or an nls subfolder. A little off point, but it points up an alternative. The process of scanning the repository is all I have in place at this point and I really should label the pages generated so far as Wine specific. That way other projects could produce similar pages specific to their structure. There is not a page for every file, only those that I intend to analyze. If I don't plan to analyze it, I simply provide a link to the file in the repository. I have *not* gotten started on the extraction of the API information. I plan to label each page of that type with an 'API/' prefix so that it would be common to multiple projects. I needed to get the framework in place so that I could the results where it will be possible to find them. Now that is done, the real work begins... - Max
Re: WineAPI wiki progress (resent)
On 09/15/2010 10:47 PM, Max TenEyck Woodbury wrote: Actually, that was a mistake on my part. If you use: https://sourceforge.net/apps/mediawiki/wineapi/index.php you can skip the login. ARGH! Make that: http://sourceforge.net/apps/mediawiki/wineapi/index.php - Max
WineAPI wiki status update
The wiki is at http://sourceforge.net/apps/mediawiki/wineapi/index.php and this address should *not* require a Sourceforge login. At least one person has complained that this project is too Wine specific. They want it to be more generic. I do *not* plan to remove the Wine specific content, but I have labeled it with the prefix 'Wine/' so there will be space for content specific to other projects. I have to admit that the format is pretty UGLY with too much information crammed into too little space. I have received some suggestions on how this can be improved. I intend to act on those suggestions, but not right now. I need to put the content in and assure that it is correct before I get into aesthetics. If someone wants to help with this, let me know. There are now links to every directory and file in the repository and a mechanism is in place to assure that this will continue to be the case. Significant repository entries have their own wiki pages with at least one place where editable content can be added that will not be over-written by the automatic update process. There are also the usual wiki discussion pages. Most of the file related pages are simply place holders at this time, with the exception of '.spec' file pages. Please see the section below on plans before complaining about this. Statistics (very approximate) 400 Directories 3000 Files 55000 APIs identified Plans and problems. The current maintenance process is based on bash scripts with different scripts doing different parts of the analysis. Scheduling is based on a list of work items. The scripts add work items as they are discovered and remove work items as they are finished. If someone wants to try their hand at them, let me know and I'll post them to the wiki. I expect that re-writes in other languages are in order, but I do bash scripts well. My other strong languages are C and C++. I am very interested in learning Python, Perl and others. Some of the pages are HUGE and cause problems when some wiki operations are tried. In particular there are at least two '.spec' files with more than 8000 entries. The scripts need to be taught how to split these monsters into managable pieces. Some of the APIs are class-object based and their names have been mangled in the usual C++ manner. They are currently displayed in their raw form. De-mangling is needed and a separate hierarchy should be established for indexing them. A section in each standard directory has been set aside to hold API descriptions for each executable but are currently empty (and invisible as a result). Once the names have been de-mangled, I plan to fill in these sections. Header and code analysis are on queue after that, as is improving the page format. There are a bunch of old pages without the 'Wine/' prefix. They are being removed. Advice on wiki-bots would be helpful. - Max
WineAPI wiki progress
The repository summary pages exist but in most cases are incomplete. These pages can serve as a map of the repository contents. There are categories for translations. The category indexes should provide complete lists of identifiable translations for each language. There are summaries of all .spec files with sortable tables. There is a top level index for the APIs with seperate indexes for each initial letter. These are in alphabetical order so it should be possible to determine if Wine knows about a particular API. Indexes for C++ name spaces are scheduled to the next phase of implementation. There is ONE API description page at this point. If any of you would care to look at it and send me comments, I will read them. I will be setting up analytic scripts for the individual API pages after the name space indexes are in place. Max
Help with 'WineAPI' wiki
As I mentioned before, I am trying to establish a place where the Windows API can be discussed that is not under the control of Microsoft. While the name I have chosen is debatable, it is not beyond reason and conveys enough about its intended contents that it should not be too hard to find. It currently consists of two major pieces: * The Wine piece follows the distribution directory structure with pages for each directory and many of the files. * The API piece currently consists of an index of all the APIs I found in the .spec files. * Other projects that use the windows API can put the information specific to their project in directory trees similar to the one I have set up for Wine. I am having a few specific problems: * Some of the .spec files contain more information than can be displayed on a single Wiki page. This information has to be split up into a reasonable number of sub-pages and organized so the information needed can be found fairly easily. I can handle the technical aspects of setting up the pages, and have some idea of where the splits should be, but I am uncertain enough that I want advice. * This is the first Wiki I have had administrative responsibility for and I frankly do not know what I am doing. Advice and help with the administration of the Wiki and the project would help. * Some of the technical choices have been based on my technical limits. I am simply ignorant of possible alternatives. Again, I think advice would help. * I know some of the sections are just plain ugly. I am mostly concerned with getting accurate and current information into the Wiki at this point, but the presentation does need improvement and again, I think some advice would be helpful. * My dyslexia has bitten me more than once. Someone to review what I am doing might help. - Max
