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 ste...@codeweavers.com 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.
Re: [PATCH] msvcrt: fix character/byte confusion in buffer overflow branch
On 2013/05/07 17:46, Juan Lang juan.l...@gmail.com 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
[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] dlls/gdi32/fretype.c: Avoid division by zero.
On 05/04/2013 01:56 AM, Dmitry Timoshkov wrote:
Max TenEyck Woodbury 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.
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 m...@mtew.isa-geek.net 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 m...@mtew.isa-geek.net 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/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 2/2] gdi32: Clip font glyphs to fit within text metrics.
On 04/19/2013 02:46 AM, Dmitry Timoshkov wrote: Sam Edwards cfswo...@gmail.com 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: msvcp60: Avoid signed-unsigned integer comparisons
On 03/10/2013 07:00 AM, Henri Verbeet wrote: On 10 March 2013 08:20, larmbr zhan nasa4...@gmail.com 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: 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: 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.
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: 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 m...@mtew.isa-geek.net 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...
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, joerg-cyril.hoe...@t-systems.com 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.
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 m...@mtew.isa-geek.net 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 m...@mtew.isa-geek.net 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 m...@mtew.isa-geek.net 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: [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(interface) that this would break. The real question is ;Could it be useful?'. I think the answer is 'yes'.
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_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.
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_IFACE_DATA iface_IFACE_DATA #endif /* iface_IFACE_DATA defined */ for each inherited interface, in order.
Re: [PATCH] Potential reference count races
On 10/28/2012 12:07 PM, Alexandre Julliard wrote: Nikolay Sivov bungleh...@gmail.com 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 m...@mtew.isa-geek.net 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;ihowmuch;i++) +for (i=0;ihowmuch;++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 m...@mtew.isa-geek.net --- 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.
windowscodecs questions.
Background: I am trying to improve the performance/reliability of GuildWars2 under wine. In particular, PNG handling seems very slow, so I am looking at windowscodecs and I seem to be misunderstanding some things. I have read the PNG spec. First: The CRC check. The spec says that a 'chunk' contains a four byte size of data field, a four byte 'chunk identifier', the data and a CRC32 of the data. 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. There is a 'FIXME' that asks about checking the CRC, but no code to actually read or check the CRC. 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. 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. 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. This has been done for the basic object; all start with a pointer to the 'vtable'. What I think should follow is the critical section lock structure and, for 'IUnknown', the reference count. What I see is that these common elements are placed more or less at random in each extended object. 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'.
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 titan.co...@gmail.com 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 1/1] include/basetsd.h: fix bad casting
On 10/14/2012 05:33 AM, GOUJON Alexandre wrote: On 10/14/2012 01:40 AM, Max TenEyck Woodbury wrote: Dan: AJ and DT can both speak for themselves, and have just done so. It is now AJs decision. There are criteria beyond the two you mentioned, but it is rare to see them come into play. Few people know enough to even recognize such problems. While far from an expert on such matters, I have enough background to recognize a situation that might be troublesome. I think this could be one of those situations and I have urged AJ to consult a real expert on the subject. I do NOT see this as dissing AJ in any way. In fact, He has stated the basic facts quite well. I am pointing at an additional factor he should consider. If people are discouraged from bringing such points up, as you are doing, the project could end up in trouble that could have been avoided. You know, discussing is a good thing and the end result is often positive so no one want to hush you up. In principle, people expose their point of view and argue with evidences. Saying I have enough background then [I'm] far from an expert and previously check with a *copyright* lawyer means I don't know but believe me so that's not a valid argument. Do you have any test case [proving there's a need to fix something] ? If so, we could reconsider your patch. If not, it's then gratuitous. Using CAPITALS! and *bold words* is not a good behaviour. I don't know you but reading your responses makes me think you're a child crying and shouting for having some candies. Don't take it bad, it's just my [personal] impression. If you want to discuss, accept others arguments and reply calmly with evidences. AJ position is quite clear : wine aims to be [bug-for-bug] compatible with Windows. Finally, do you know basetds.h is a public header ? Please stop and think about what I actually said and what it really means. The problem is not so much the code as the law. The only kind of valid test case for the law is before a judge and jury. When you fail that test case, the entire project is shut down. I am not in a position nor would I ever want to be responsible for the results of such a test. I think none of you would be happy if I even tried to run such a test. Think about what you just said in that context. So, I have enough background to recognize that this is a legal issue. 'I am far from an expert' means, among other things that I am not a lawyer. There is no contradiction there. What I said really means is 'there is trouble here but I can not fix the real problem, so try this instead' and if you want a proper fix, the kind of expert you need is not just any lawyer, but a *copyright* lawyer'. That distinction is important enough to call for the bold emphasis I used. The caps were there because Dan was projecting his point of view on me. I have very strong objections to that kind of thing. I have responded because it is clear that I (not AJ et al) have not made myself clear. That is hardly childish. I have failed my responsibility in making myself clearly understood and I am responding by trying to say what I need to say more clearly. Also, I explicitly recognized that AJ is the one to decide this issue. I would be remiss if I did not make it clear that this is a change to avoid a legal trap, and the exact technical nature of that trap. And Finally, if 'basetds.h' is public in the legal sense, it should not include an LGPL license unless Patric Stiridvall wrote all the code in that header himself from the specification and included the license and has never worked for Microsoft. The fact that this particular header includes an infringement trap argues against that. While this exact situation did not come up in Oracle vs Google, similar issues did. Again, consult an expert copyright lawyer.
Fwd: Re: [PATCH 1/1] include/basetsd.h: fix bad casting
On 10/12/2012 09:49 PM, Dmitry Timoshkov wrote: Max TenEyck Woodbury m...@mtew.isa-geek.net wrote: -#define IntToPtr(i) ((void *)(INT_PTR)((INT)i)) -#define UIntToPtr(ui) ((void *)(UINT_PTR)((UINT)ui)) -#define LongToPtr(l)((void *)(LONG_PTR)((LONG)l)) -#define ULongToPtr(ul) ((void *)(ULONG_PTR)((ULONG)ul)) +#define IntToPtr(i) ((void *)(INT_PTR)(i)) +#define UIntToPtr(ui) ((void *)(UINT_PTR)(ui)) +#define LongToPtr(l)((void *)(LONG_PTR)(l)) +#define ULongToPtr(ul) ((void *)(ULONG_PTR)(ul)) You forgot to explain what's bad with it. The original applied the extra conversion to ONLY THE FIRST component of the expression, not to the WHOLE expression. That can (although it's not likely to) cause hard to diagnose problems. What 'the first component' are you talking about? This code is win32 only. 'i', 'ui', 'l' and 'ul' are parameters to the macros, When the macros are used, you put in an expression as the argument to the macro. As originally written for example, the cast to LONG in ((LONG)l) is applied to only the first component of the expression substituted in place of 'l'. In order to get the cast to apply to the whole expression, you need parenthesis around the parameter. That is literally (l). Then the cast applies to the whole expression. That is (LONG_PTR)(l) casts the entire expression substituted into 'l' to a LONG_PTR value. The macros that convert to 'Handle' rather than 'Ptr' do this properly. In the vast majority of cases the expression substituted into 'l' is a simple variable and there is no problem. In almost all of the remaining cases, casting the first element of the expression coerces the rest of the expression to the proper type. In rare cases, other elements of the expression might force the expression's value to some other type. In most of those cases the cast to LONG_PTR fixes the problem. In a really odd case there might be a problem caused by the extra cast to LONG. Since that cast is buried in a macro definition, it will be difficult to spot that cast as the source of such a problem from the source code. The original definitions include three casts in sequence. The first of those casts is done improperly. Even if it were done properly, the next cast in the sequence makes it redundant. I removed the improper cast since it IS redundant. NUFF SAID?
Fwd: Re: [PATCH 1/1] include/basetsd.h: fix bad casting
On 10/12/2012 10:25 PM, Dan Kegel wrote:
Hi Max,
here's a little test program that shows that your patch changes how
UIntToPtr works:
#include stdio.h
#include stdint.h
#define UIntToPtrA(i) ((void *)(intptr_t)((unsigned int)i))
#define UIntToPtrB(i) ((void *)(intptr_t)(i))
int main(int argc, char **argv)
{
short x = 65534;
printf(%d - %p\n, x, UIntToPtrA(x));
printf(%d - %p\n, x, UIntToPtrB(x));
return 0;
}
On a 64 bit machine, this outputs
-2 - 0xfffe
-2 - 0xfffe
This could change the behavior of functions that call UIntToPtr, like
say EnumResourceTypesA().
I would suggest writing a conformance test to expose whether the
change brings Wine closer to native behavior, or further away, adding
that to your patch, and then verifying with winetestbot that the patch
improves wine's conformance.
My guess is that the current behavior is right, but hey, the test will
show what's really up.
- Dan
I 'greped' the entire wine tree for uses of these macros. There was
only a couple places where the argument was an expression and in those
cases I did not see that the change would cause problems.
Frankly, I do not think I could come up with a test where the change
would make a difference. I am submitting the patch against the weird
possibility that such a case does exist.
The change is strictly preventative maintenance with just a hint of
aesthetic improvement to make them coordinate with the 'Handle' variants
of these macros.
Now, if you are going to tell me that these definitions were *copied*
from a Microsoft *source* rather than derived from a Microsoft
specification, you would have a point, but then there would be a whole
bunch of copyright issues that would need to be worked through.
Re: Fwd: Re: [PATCH 1/1] include/basetsd.h: fix bad casting
On 10/13/2012 09:14 AM, Alexandre Julliard wrote: Max TenEyck Woodbury m...@mtew.isa-geek.net writes: Now, if you are going to tell me that these definitions were *copied* from a Microsoft *source* rather than derived from a Microsoft specification, you would have a point, but then there would be a whole bunch of copyright issues that would need to be worked through. You can't copyright a typecast, and yes, the macros are broken the same way in the Microsoft headers, we are just being compatible. Ah, but you CAN copyright a MISTAKE! Especially if it was introduced deliberately for the sake of catching copyright infringers. Since it is gratuitous, like a grace note in a musical score, it can be used to show the code was actually copied rather than being something needed to implement the uncopyrightable idea in a specification. Please apply the change. If you have any doubts, check with a *copyright* lawyer. Reference the recent Oracle vs Google case.
Re: [PATCH 1/1] include/basetsd.h: fix bad casting
On 10/13/2012 06:30 PM, Dan Kegel wrote: In general, patches to wine should have some demonstrated benefit, either by increasing the number of passing conformance tests, or by making some app work better, or both. Your current patch doesn't seem to do either of these things. Getting into a pissing match with AJ about patent and copyright law is not a good strategy for potential contributors to wine. He generally knows his stuff, and I think he's right in this case. If I were you, I'd go off and reflect for a while, then pick some other way to contribute. Dan: AJ and DT can both speak for themselves, and have just done so. It is now AJs decision. There are criteria beyond the two you mentioned, but it is rare to see them come into play. Few people know enough to even recognize such problems. While far from an expert on such matters, I have enough background to recognize a situation that might be troublesome. I think this could be one of those situations and I have urged AJ to consult a real expert on the subject. I do NOT see this as dissing AJ in any way. In fact, He has stated the basic facts quite well. I am pointing at an additional factor he should consider. If people are discouraged from bringing such points up, as you are doing, the project could end up in trouble that could have been avoided.
Re: [PATCH 1/1] include/basetsd.h: fix bad casting
On 10/12/2012 01:46 PM, Dmitry Timoshkov wrote: Max TenEyck Woodbury m...@mtew.isa-geek.net wrote: -#define IntToPtr(i) ((void *)(INT_PTR)((INT)i)) -#define UIntToPtr(ui) ((void *)(UINT_PTR)((UINT)ui)) -#define LongToPtr(l)((void *)(LONG_PTR)((LONG)l)) -#define ULongToPtr(ul) ((void *)(ULONG_PTR)((ULONG)ul)) +#define IntToPtr(i) ((void *)(INT_PTR)(i)) +#define UIntToPtr(ui) ((void *)(UINT_PTR)(ui)) +#define LongToPtr(l)((void *)(LONG_PTR)(l)) +#define ULongToPtr(ul) ((void *)(ULONG_PTR)(ul)) You forgot to explain what's bad with it. The original applied the extra conversion to ONLY THE FIRST component of the expression, not to the WHOLE expression. That can (although it's not likely to) cause hard to diagnose problems.
Re: [patch 1/1] dlls/windowscodecs/pngformat.c: implemented 'PngDecoder_Block_GetCount'
On 10/05/2012 03:55 AM, Nikolay Sivov wrote:
On 10/5/2012 06:43, max+...@mtew.isa-geek.net wrote:
From: Max TenEyck Woodbury max+...@mtew.isa-geek.net
---
dlls/windowscodecs/pngformat.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/dlls/windowscodecs/pngformat.c
b/dlls/windowscodecs/pngformat.c
index 686f9c6..e8e7cbe 100644
--- a/dlls/windowscodecs/pngformat.c
+++ b/dlls/windowscodecs/pngformat.c
@@ -899,8 +899,10 @@ static HRESULT WINAPI
PngDecoder_Block_GetContainerFormat(IWICMetadataBlockReade
static HRESULT WINAPI
PngDecoder_Block_GetCount(IWICMetadataBlockReader *iface,
UINT *pcCount)
{
-FIXME(%p,%p: stub\n, iface, pcCount);
-return E_NOTIMPL;
+PngDecoder *This = impl_from_IWICMetadataBlockReader(iface);
+if (!pcCount) return E_INVALIDARG;
+*pcCount = This-ref;
+return S_OK;
}
static HRESULT WINAPI
PngDecoder_Block_GetReaderByIndex(IWICMetadataBlockReader *iface,
Return reference count as block count?
I've screwed up. This is NOT what is supposed to be returned here. I am
in the process of digging out what this really should be. Please do
NOT apply this patch! (However, it does trigger at least one app to
do something useful and reveals the need for other changes...)
Re: 'PngDecoder_Block_GetCount'
Hmm. I definitely misunderstood what this function was intended to do. As I understand things now, there are two ways to approach processing graphical information: 1) As a stream of information to be processed in the order it arrives. 2) As an aggregate to be processed all at once. The PNG format is specifically designed to allow it to be processed as a stream with good efficiency. Processing the aggregate is done by processing the stream and accumulating the aggregated information. The key interface to the stream approach is to enumerate the blocks and process each one as you come to it. This approach has already been implemented. The strategy of the aggregate approach is to have an array of blocks and use an index to access the elements of the array. The key elements are getting the number of blocks (this function) and getting access to the block by its index number (using 'GetReaderByIndex'). This approach has not been implemented. To do this efficiently, it should be possible to validate the correctness of each block WITHOUT getting into any more details about the blocks than possible. Have I got this right so far?
Re: 'PngDecoder_Block_GetCount'
On 10/05/2012 10:58 AM, Vincent Povirk wrote: You should take a look at the PNG format spec, particularly the part about chunks: http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html I believe what's needed here is to return all ancillary chunks. First, thank you for the pointer to the HTML version of the PNG spec. I had the PDF one already, but the cross references make it a lot easier to use. Beyond that, I am not sure what you are talking about. The value to be returned (at the address specified by the 2nd parameter) is an unsigned integer. There is no place to return 'chunks'; only a place to return a count. In order to get that count, each and every one of the chunks needs to be scanned and validated. During the scanning process, it would make sense to store the location of chunks in an indexed data structure. That would nominally be an array, but a linked list or tree would also work. For a general WIC design, there needs to be at least three layers with indexes built into at least two of the layers. The top layer is the entire file. The next layer is the set of frames in the file. PNG only allows one frame per file, but other formats can have several (even many) frames. The next layer is the set of blocks (in this case chunks) in each frame. In some cases there might be a need for additional layers. All this means I need to dig out the 'class' structure of IWIC, but it would help if someone can confirm that I have not gone off the deep end yet.
Re: 'PngDecoder_Block_GetCount'
On 10/05/2012 05:53 PM, Vincent Povirk wrote: Beyond that, I am not sure what you are talking about. The value to be returned (at the address specified by the 2nd parameter) is an unsigned integer. There is no place to return 'chunks'; only a place to return a count. Other methods on that interface allow you to return an IWICMetadataReader, which need to be based on individual PNG chunks. Obviously, the GetCount method just gives the number that can be returned. Agreed then. This is only one part of the total aggregate interface. If this routine is implemented, the other methods need to be done as well. The enumeration of the chunks needs to be recorded. In order to get that count, each and every one of the chunks needs to be scanned and validated. During the scanning process, it would make sense to store the location of chunks in an indexed data structure. That would nominally be an array, but a linked list or tree would also work. I don't think it's really necessary to verify the checksum. You just need to read a few bytes of header to get the chunk type and the location of the next one. See the png_read_chunk function. I think the CRC check would be a good idea. As the rational in the spec mentioned, doing it guards against transition (and other) errors. cynic_modeNo assurance that Murphy (or his so unkind worshipers) can't get in of course./cynic_mode I don't understand anything you said after that paragraph. I was thinking about other formats the IWIC framework has to handle. Not just about PNG.
Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono
On 06/05/2012 01:50 AM, Hin-Tak Leung wrote: --- On Mon, 4/6/12, Max TenEyck Woodburym...@mtew.isa-geek.net wrote: On 06/04/2012 03:05 AM, Frédéric Delanoy wrote: On Mon, Jun 4, 2012 at 8:35 AM, Dan Kegeld...@kegel.com wrote: On Sun, Jun 3, 2012 at 11:20 PM, Frédéric Delanoy frederic.dela...@gmail.com wrote: On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegeldaniel.r.ke...@gmail.com wrote: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh now also installs mono. ... Wouldn't it be better (and more acceptable for people disliking/wanting to avoid mono) to - keep install-gecko.sh as is - create install-mono.sh - create wine-install-addons.sh calling the former ? The point of this script is to make life easier for me and for the average user. It's not to make life easier for people who don't like mono, mostly because I doubt there are many of them. My comment was not only meant for mono-haters, but it can also be useful IMHO to split e.g. to limit download size when one doesn't even need mono, and it maybe clearer as well (addons is pretty generic). Frédéric Actually, it really is the name that matters. 'mono' is a lightning rod for a lot of political history. If you were to integrate the same functions into Wine itself, and hopefully avoid tripping over the stinking Microsoft patents, that set of problems can be avoided, A native MSWindows application that wants .net support would either connect to the installed dll that provides the required services or install such a dll. It would know nothing about 'mono'. It is only non-MSWindows platform programs that will try to link to the non-MSWinows libraries in 'mono'. So an MSWindows executable looking for .net support needs .net support, NOT mono. We can and should provide such executables the services they need. However we should NOT make it easy for programs from other platforms to fall into the stinking Microsoft Patent trap. That gateway to hell is called 'mono' and we should NOT open it. This is irrational bias against mono. The fact is that, since Vista, .Net Framework runtime is shipped as standard in windows. Therefore any windows application has a reasonable expectation of assuming .Net runtime to be around, and not prompt the user to go and download the .net runtime from microsoft. Athough some application does explicitly test for the presence of .net runtime and make the user go and download it from microsoft when it cannot detect such or when the version of net runtime is too low (i.e. if the user tries to install such software on XP). Granted the authentic MS .net runtime can be installed and works well enough under wine; but would you rather the user goes and download genuine MS .net and install it on wine? If you say downloading .net runtime and using that on linux is preferable from your point of view, I have nothing more to say... The issue is access from linux native code to the .net framework. That should require a specific decision on the part of the system administrator to make it available. It is that package that I believe is called 'mono'. I have taken steps to assure that it never appears on the systems I run. Providing a .net framework to MSWindows platform applications that I want to run on my systems is another mater. Wine should provide that framework on demand but that is NOT 'mono'. The Wine .net support does NOT make the .net framework available to native linux application. (If it IS provided a part of the wine migration library, I will grumble but not scream about it.) The problem is the lawyers and senior management at Microsoft. They have been caught laying traps for anything competitive with their products. There are 'markers' that they use to make springing their trap easier. One of those markers is the name 'mono'. The people who built the original 'mono' have been identified as Microsoft shills. They have NOT kept their development environment clean. It is known to be contaminated with Microsoft's 'IP'. Wine, on the other hand, has tried quite hard to prevent contamination by Microsoft 'IP'. I am seriously concerned that accepting anything with the name 'mono' on it will have the appearance of being contaminated, and even more important, might cause some developers to relax their standards and inadvertently accept pieces from the 'mono' project instead of doing a clean re-implementation.
Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono
On 06/05/2012 03:00 AM, Francois Gouget wrote: On Mon, 4 Jun 2012, Max TenEyck Woodbury wrote: [...] A native MSWindows application that wants .net support would either connect to the installed dll that provides the required services or install such a dll. It would know nothing about 'mono'. It is only non-MSWindows platform programs that will try to link to the non-MSWinows libraries in 'mono'. So an MSWindows executable looking for .net support needs .net support, NOT mono. [...] You obviously have absolutely no idea what the wine-mono package is for. You should read up and apologize. NO APOLOGY! You are missing the point. If it is NOT a linux native interface, it is NOT an analog of 'mono'. Call it what it is: DotNetFramework or something like that. Just do NOT make the mistake of tying it to the contaminated package, even if it is only by using a similar name. This is because legal risks are fairly high here, and APPEARANCE does account for a lot in that domain. While the odds are somewhat in favor of any legal action coming out correctly if the tech is right, it IS a crap shoot and the lawyer's are the only sure winners.
Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono
On 06/05/2012 01:16 PM, James Eder wrote: You obviously have absolutely no idea what the wine-mono package is for. You should read up and apologize. NO APOLOGY! You are missing the point. You are missing the point. You're argument lacks weight because you clearly have no idea what you're talking about. One cannot base a reasonable argument on top of displays of ignorance and irrationality. You can try but in the end you only look like an ass. I understand that you're very passionate about the subject but understand that such displays harm your cause more than help it. You were wrong on several technical details which you based several key points of your argument on. A reasonable thing to do would be to offer an apology while moving on to other points you feel more sure about. Instead you respond with more rudeness. At this point I don't think you can recover well enough to have a meaningful discussion. You should make a strategic withdrawal, do some research, and reform your argument. It is not so much the technical details that are the problem. It is the LEGAL problems and potential legal problems that are at the root of my complaint. Telling me that I have the technical details wrong does not help. I have very carefully tried to move the discussion away from secondary technical points and onto the strategic issues that are not being addressed. I find it very frustrating that the technical points are made over and over as if they were somehow answers to the legal and strategic problems. If you think I have been rude, consider that ignoring the more important issues that I am trying to raise is equally if not more rude. If I have resorted to name calling or personal characterizations, then I do owe you all an apology, but I do not apologize for trying to get the non-technical aspects of the problem presented.
Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono
On 06/04/2012 03:05 AM, Frédéric Delanoy wrote: On Mon, Jun 4, 2012 at 8:35 AM, Dan Kegeld...@kegel.com wrote: On Sun, Jun 3, 2012 at 11:20 PM, Frédéric Delanoy frederic.dela...@gmail.com wrote: On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegeldaniel.r.ke...@gmail.com wrote: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh now also installs mono. ... Wouldn't it be better (and more acceptable for people disliking/wanting to avoid mono) to - keep install-gecko.sh as is - create install-mono.sh - create wine-install-addons.sh calling the former ? The point of this script is to make life easier for me and for the average user. It's not to make life easier for people who don't like mono, mostly because I doubt there are many of them. My comment was not only meant for mono-haters, but it can also be useful IMHO to split e.g. to limit download size.when one doesn't even need mono, and it maybe clearer as well (addons is pretty generic). Frédéric Actually, it really is the name that matters. 'mono' is a lightning rod for a lot of political history. If you were to integrate the same functions into Wine itself, and hopefully avoid tripping over the stinking Microsoft patents, that set of problems can be avoided, A native MSWindows application that wants .net support would either connect to the installed dll that provides the required services or install such a dll. It would know nothing about 'mono'. It is only non-MSWindows platform programs that will try to link to the non-MSWinows libraries in 'mono'. So an MSWindows executable looking for .net support needs .net support, NOT mono. We can and should provide such executables the services they need. However we should NOT make it easy for programs from other platforms to fall into the stinking Microsoft Patent trap. That gateway to hell is called 'mono' and we should NOT open it.
Re: Wine in Humble Indie Bundle
On 06/03/2012 02:03 PM, Dan Kegel wrote: I see the Humble Indie Bundle includes a game ported via wine, http://zcint.co.uk/article/limbo-on-linux-incites-humble-bundle-petition That's pretty cool, but not everyone agrees, and somebody has started circulating an anti-wine petition. So I put together a pro-wine petition: http://www.ipetitions.com/petition/use-wine-as-needed-in-future-humble-indie-bundles/ How's that look? If you agree with it, please sign and forward to your friends. Thanks, Dan Your petition is very carefully worded and on point, however... the other petition does have a point about Wine not doing as well with sound as it should. Still, it does go too far in its opposition.
Re: Mono?!?
On 06/01/2012 12:34 AM, Vincent Povirk wrote: Yes, that was added in today's Git. When you do a prefix update, and a recent wine-mono (or native .NET) isn't installed, Wine will try to install it from a system location, and if that fails it will ask to download it. The wine-mono install is limited to your Wine prefix, and you don't have to have Mono on your host system. If you don't have the wine-mono msi package on your system, and you cancel the download, it won't be installed. If you don't want to use it, and the dialog annoys you, override mscoree to disabled or native-only. Apps that don't need .NET should still work fine, but it's not a supported configuration. I can respect irrational dislike. I sort of feel that way about Java (I'll generally avoid any software that requires it). But the ideal of Wine is for all programs to just work like on Windows, and we can't get there for .NET apps without this change. Please add a --without-mono option to configure, and so on...
Re: Mono?!?
On 06/01/2012 09:58 AM, Conan Kudo (ニール・ゴンパ) wrote: On Fri, Jun 1, 2012 at 12:28 AM, Max TenEyck Woodbury m...@mtew.isa-geek.net mailto:m...@mtew.isa-geek.net wrote: On 06/01/2012 12:40 AM, Conan Kudo (ニール・ゴンパ) wrote: You realize that Microsoft has a legally binding irrevocable agreement to not assert patents on .NET implementations that comply with the standard, right? Mono falls under that. I wouldn't worry about patents when it comes to Mono. We're more likely to have problems on the Java side of things than with Mono. No, I do NOT 'realize' Microsoft has a legally binding irrevocable agreement I have heard that such a thing exists, but with the recent debacle by Oracle and tSCOg's treatment of 'irrevocable agreements, I do NOT trust them to not find a way to get around such a pronouncement. In fact I expect that they could simply ignore any such promise if they found it convenient to do so and that they will do so eventually. Further, there are enough weasel words in that pronouncement that I think they plan to get nasty anyway. I realize ANYBODY can sue ANYBODY, but I prefer to stay clear of tar pits like MONO when I can. (There is also an indication that .NET is a dead letter and MONO will become unnecessary.) Oracle could sue because its legal agreement for patents requires that the implementation is derived from Oracle's completely and must be under GPL. Other independent implementations are not protected. Microsoft's protects all implementations that comply with published standards. You have that wrong. Google made no such agreements. Oracle sued anyway on the basis of copy right and patent infringement. They lost on BOTH counts, but it still cost Google tens of millions of dollars in legal fees and it still has a ways to run. I can't afford that. I suspect that anyone who is not operating on Google's scale can. Worse, Sun LIKED it that Google was trying for compatibility. Oracle bought Sun and the situation changed dramatically. Microsoft does NOT like the competition and has pulled stunts like their end-run to MosAid to get around binding promises. Relying on ANY legal pronouncement by Microsoft is even worse than relying on their technical pronouncements.
Mono?!?
When did WINE start requiring MONO? I have a VERY strong DISLIKE for MONO and do NOT want it on my machines. Seems to be a recent addition. Is it possible to NOT use it? PLEASE!
Re: Mono?!?
On 05/31/2012 11:05 PM, Conan Kudo (ニール・ゴンパ) wrote: On Thu, May 31, 2012 at 10:00 PM, Max TenEyck Woodbury m...@mtew.isa-geek.net mailto:m...@mtew.isa-geek.net wrote: When did WINE start requiring MONO? I have a VERY strong DISLIKE for MONO and do NOT want it on my machines. Seems to be a recent addition. Is it possible to NOT use it? PLEASE! First off, what is your beef with Mono? It's a decent technology that makes .NET available on non-Windows platforms. Secondly, the wine-mono addon is optional, I believe. You do not have to install it. My beef (as you call it, it is more an outright RAGE in fact) is PATENTS. Mono uses Microsoft's own technology that are covered by their STINKING patents, making any system that has them installed vulnerable to all kinds of legal hassles if Microsoft decides to get nastier than they already are. And the installation request when running 'make test' does NOT mention that you have the option of NOT installing the beast! So it does NOT look like it is OPTIONAL. If it IS optional, then there should be a clear way to REMOVE it, and while I have not looked at the situation long enough to find out how to remove it, I did not see something as obvious as an 'uninstall-mono' script. The ONLY way I could trust MONO is if it had a GPL 3+ or LGPL 3+ license that had been court tested and was therefore immune to Microsoft's legal shenanigans. I do NOT believe any of the other FOSS and definitely the plain OSS licenses provide the necessary protection. And, yes, I am more than a little crazed on this subject.
Re: Mono?!?
On 06/01/2012 12:51 AM, Vincent Povirk wrote: If it IS optional, then there should be a clear way to REMOVE it, and while I have not looked at the situation long enough to find out how to remove it, I did not see something as obvious as an 'uninstall-mono' script. If you run wine uninstaller and you have it installed (which you probably don't), it will show up in the list as something you can remove. http://wiki.winehq.org/Mono also has a command line to remove it that will work for the foreseeable future. Thank you. That was helpful. I removed Mono and several older versions of Gecko from various prefix directories.
Using an IDE on Wine?
How many of you use an Integrated Development Environment (IDE) when working on Wine? If you do, which one do you use and how, how useful is it and how hard was it to set up? 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
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: 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: [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: 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 neri...@users.sourceforge.net wrote: --- AUTHORS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Maybe you should ensure that the name you commit your patches with (foo in 'fooemail') 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: 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.
Trailing white space and other pedantry.
From: Max TenEyck Woodburym...@mtew.isa-geek.net 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 Woodburym...@mtew.isa-geek.net 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 ignored. Originally defined at /usr/include/asm-generic/ioctl.h:75 Old:' ( type , nr , size ) _IOC ( _IOC_READ , ( type ) , ( nr ) , ( _IOC_TYPECHECK ( size ) ) ) ' New:' ( x , y , t ) ( IOC_OUT | ( ( ( UINT ) sizeof ( t ) IOCPARM_MASK
Re: [PATCH] Label verbosity levels.
From: max m...@mtew.isa-geek.net
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
Re: [PATCH] NTDLL atom.c documentation.
On 03/06/2011 02:45 PM, Nikolay Sivov wrote: What's a point to make such changes in a first place? I don't see how it's useful to have automatically extracted partially filled function names from sources (if it's a purpose of these documentation headers of course). You always have sources, everything that might be useful for development is in as code or comments for not-so-obvious parts. What is really helpful for documenting behaviour that isn't documented officially is writing test cases to show bugs or to prevent regressions. What are you saying? I can't quite figure out your point. There were no summaries for these functions before, mostly for technical reasons, and this particular set is _not_ documented by Microsoft. Juan Lang's point was about the quality of the source I was using to check on the absence of documentation. I'm not sure that the limited use I was making of that source would have the impact predicted, but I'm willing to use another source if there is one available. Your comments don't address that issue. There are already test cases that define what the functions do, so that is not the issue here. What is not currently being tested is the behavior of the Microsoft code when it is being abused. In particular, I see where passing pointers that cause faults can create problems and have noted those places. Someone needs to look at those notes and decide if they represent things that need testing. I suspect that they represent very low priority issues. I am noting where tests do and do not exist for particular entry points, so that can't be your point. I've been reading other peoples code for _decades_. This particular set of code is fairly clear with only a few arcane points, mostly to do with 'integral' atoms. The notes I've added bring out this issue somewhat more strongly than the code does. That should provide a clue to why some of the minor twists in the code are there. Maybe I'll see your point in the morning... Max
Re: [PATCH] NTDLL atom.c documentation.
On 03/06/2011 10:34 AM, Juan Lang wrote: Hi Max, + * http://www.geoffchappell.com/studies/windows/win32/ntdll/history/names40.htm Please don't link to his site. As I said in an unrelated message to wine-patches last week, he used disassembly when performing his analysis: http://www.geoffchappell.com/viewer.htm?doc=notes/index.htm I wouldn't want to endorse such an effort implicitly by linking to him: future Wine developers could be misled. Thanks, --Juan The list of entry point names and the version history is all I am interested in and I believe that does not require disassembly, but if you can point me at another source for that information, I will be glad to use that instead. Max
Re: Please help me with document extraction.
On 02/27/2011 05:55 PM, Alexandre Julliard wrote: The other reason is that a decent documentation of the Windows API would be huge; look at how much information there is on MSDN, and that's still incomplete. It's completely impossible to maintain something of that size in the middle of the source code. As long as it's inside the source, it will just be one or two sentences per function, and maybe a list of parameters. That's not useful documentation. Hmm. Reviewing c2man.pl: The reason there are only one line comments on the parameters is because that is all the extraction program allows. I had access to commercial grade source code for some years (_NOT_ Microsoft!) and the library function documentation was indeed in the source files and there was a program that extracted the documentation and that was published and sold. So, I have to disagree that the situation is impossible. Yes, it is _hard_ to do, and duplicating MSDN should not be the goal. If done right the embedded documentation should add value to the code. Such things as what has and has not been implemented and _why_ might be helpful. It might even be useful to describe _how_ some of the stuff is done. Oh, and the total amount is indeed huge, but each piece is not. It's just that there are _lots_ of pieces. The way to eat an elephant is one bite at a time... Max
Re: Please help me with document extraction.
On 02/28/2011 11:34 AM, André Hentschel wrote: Am 28.02.2011 17:20, schrieb Max TenEyck Woodbury: I think the idea of building upon the existing documentation somewhere else has a better chance than the deal on the 100 Frankly, I believe embedded documentation is the way to go. It is _not_ a panacea, but it is better than trying to maintain a separate set of functional documentation. I have seen cases where it worked. Not great but OK. I tried the separate document approach and got _very_ frustrated, and _no_one_ was really interested. Yeah, so let's see how interested people will be in the new aproach. (Also OK might not be enough for Wine) Hmm. First, it is _not_ a new approach. It has literally decades of application. I first encountered it in the '80s and it was well entrenched even then. Such people as D. Knuth have much to say on the subject. It is not even new to Wine. There is a lot of embedded documentation already. It just is not being maintained. Second, OK is better than nothing. I say it is OK because I have actually used such a system. It is a pain to maintain, but the results are usually very good. While the stuff I did never reached the public (It got hung at the informal Q/A stage), other similar material was sold at a profit and was generally rated as very good to excellent. Again, the reason I call it OK is because of the amount of work required. Max
Re: Please help me with document extraction.
On 02/28/2011 08:08 AM, André Hentschel wrote: Am 27.02.2011 20:37, schrieb Max TenEyck Woodbury: I've picked up Perl in the last couple weeks. An interesting language with lots of adopted features. It's been easy to learn, so I think I will _not_ need help with the language itself, but I will listen to any advice. When i started with Wine developing i tackled winemaker which is also in perl. I also had to learn Perl for it, so i know you situation. Perl is truely cool, but the inline use of RegEx is sometimes confusing (So are $_ and friends) and i hate to use curly brackets for every if. Perl's focus seems to be on compact code. Since I have an existing program to work from, I don't have to learn it all at once. The Perl regex is quite a bit more advanced than some others and I'm happy to learn the new features it present. I find it easy to learn. Curlies are frustrating if you insist on a style that emphasize them, but I think that is due to the conflict between a 'lots of white space' style and the compact philosophy built into the language. The focus should be on the purpose of the code, not on the syntax of the language. The c2man.pl code is extensive and sparsely commented. In order to understand what it does, I've made a transcription of it with a more compact style and lots more comments. I check the rewrite against the source code so there should not be any serious errors. There are also a number of what I believe to be defects in the original and places where my comments may be inappropriate or my style may be very objectionable. _This_ is what I need help with. Would someone be willing to review my rewrite? If so, send me e-mail so I can arrange to get a copy of it to you. Remember that you won't get one big patch in at once, you need to split it up later. I was going to try for a whole hog replacement, call it c2man2 or something like that, but I can retro-fit as needed. P.S. to AJ et al. There is a _lot_ of documentation embedded in the wine code, but it is hard to find at the moment. I'd like to see it indexed and this is the program that does the extraction and indexing. Advice on making this new version available and active are in order. I think the idea of building upon the existing documentation somewhere else has a better chance than the deal on the 100 Frankly, I believe embedded documentation is the way to go. It is _not_ a panacea, but it is better than trying to maintain a separate set of functional documentation. I have seen cases where it worked. Not great but OK. I tried the separate document approach and got _very_ frustrated, and _no_one_ was really interested. Max
Please help me with document extraction.
As my previous efforts have probably informed you, I am interested in documentation. My initial efforts were _not_ on target and had missed the existing 'c2man.pl' tool. I am in the process of correcting my failure on that. I've picked up Perl in the last couple weeks. An interesting language with lots of adopted features. It's been easy to learn, so I think I will _not_ need help with the language itself, but I will listen to any advice. The c2man.pl code is extensive and sparsely commented. In order to understand what it does, I've made a transcription of it with a more compact style and lots more comments. I check the rewrite against the source code so there should not be any serious errors. There are also a number of what I believe to be defects in the original and places where my comments may be inappropriate or my style may be very objectionable. _This_ is what I need help with. Would someone be willing to review my rewrite? If so, send me e-mail so I can arrange to get a copy of it to you. P.S. to AJ et al. There is a _lot_ of documentation embedded in the wine code, but it is hard to find at the moment. I'd like to see it indexed and this is the program that does the extraction and indexing. Advice on making this new version available and active are in order. Max
Re: Please help me with document extraction.
On 02/27/2011 02:49 PM, Alexandre Julliard wrote: Max TenEyck Woodburym...@mtew.isa-geek.net writes: P.S. to AJ et al. There is a _lot_ of documentation embedded in the wine code, but it is hard to find at the moment. I'd like to see it indexed and this is the program that does the extraction and indexing. Advice on making this new version available and active are in order. This has already been discussed, but documentation on the Windows API doesn't belong in the source code. I've been accepting small amounts of function documentation (which IMHO is pretty much useless) along with implementations, but I'm not going to accept significantly more than that. This is why you were directed to do this as a separate project. But it _does_ belong someplace in the repository and there is already a lot of it embedded. I'm also not sure that what is in there already can really be called documentation of the _Windows_ API. Rather it is documentation of what we _think_ the API is. That is a small but important difference. I'd also like clarification on why you think it does _not_ belong in the source code. Some projects insist that documentation _has_ to be part of the source code so that it will be properly maintained. Max
Re: Please help me with document extraction.
On 02/27/2011 05:55 PM, Alexandre Julliard wrote: ... If you want to prove me wrong, start writing it. Once you have properly documented 100 functions, we can discuss what extra infrastructure is needed for the remaining 50,000. Deal on the 100! Max
Re: kernel32/tests: remove win9x hacks
On 02/23/2011 09:23 PM, James McKenzie wrote: On 2/23/11 2:38 AM, Austin English wrote: On Wed, Feb 23, 2011 at 01:32, Paul Vrienspaul.vriens.w...@gmail.com wrote: On 02/23/2011 10:15 AM, Austin English wrote: SetLastError(0xdeadbeef); ret = GetFullPathNameW(NULL, 0, NULL, NULL); I think you can get rid of the above two as well as they are merely used to trigger the ERROR_CALL_NOT_IMPLEMENTED. - is_win9x = !ret GetLastError() == ERROR_CALL_NOT_IMPLEMENTED; - - if (is_win9x) - win_skip(Skipping some tests that cause GetFullPathNameA to crash on Win9x\n); Good catch, will resend, thanks. Austin: I thought the consensus was to leave the is_win9x hacks in place so that folks will not break Windows98 when testing. However, there are going to be no new tests for Windows9x/ME and that all tests were to assume that we have or are using WindowsNT4 or higher. Did I miss something while I was away collecting my thoughts? James McKenzie That was my understanding as well. Max
Resend: Who does c2man?
I have just been going over tools/c2man and have a fair number of questions about it. I can probably dig some of the answers out myself, but it would probably go faster and raise less fuss if I can talk to the person (people) who have worked on it previously. Please send me email with contact information, or indicate that you want this done on some forum. Max
Re: Resend: Who does c2man?
On 02/11/2011 12:20 PM, GOUJON Alexandre wrote: On 02/11/2011 05:19 PM, Max TenEyck Woodbury wrote: I have just been going over tools/c2man and have a fair number of questions about it. You can ask them here. This is why wine-devel exists. There is also IRC (http://wiki.winehq.org/IRC) But keep in mind that everyone is very busy. So ask something useful. If you are too lazy to read the source code, then don't be surprised if you don't get any answer. Umm, I HAVE been reading the source code. There is quite a lot of it and there are not a lot of descriptive comments. There are a few things I think need changing but some people might consider those changes controversial. Such things as links that go nowhere and mangled names. Also places where the parsing of the input does one thing while the comments say it does something slightly different (and the comments are what should be done). Please send me email with contact information, or indicate that you want this done on some forum. wine/tools$ git blame c2man.pl Thanks, that was useful. Summary: Mike McCormack who was the original author around Aug 2000. Jon Griffiths who rewrote most of it from Mar 2003 thru Dec 2004. Francois Gouget who made some changes in Oct 2004. Stefan Stranz who added XML stuff in Jun 2009. A few others with small changes some time ago. It looks like Jon Griffiths is the one I need to contact. Is he still around? Max
Patch 21026 superseded by patch 71118.
No text.
Re: Killing WineAPI project on SourceForge.
On 02/05/2011 08:59 AM, André Hentschel wrote: Am 05.02.2011 06:36, schrieb Max TenEyck Woodbury: No feedback and apparently no interest in the WineAPI project on SourceForge. Understandable since there is now a WineAPI on the regular Wine Wiki. Unless someone objects, I'm going to ask that it be shutdown on SourceForge. Which WineAPI on the regular Wine Wiki??? URL? Sorry, not Wiki. http://source.winehq.org/WineAPI/ Max
Re: Killing WineAPI project on SourceForge.
On 02/05/2011 10:38 AM, Steve Brown wrote: On Sat, 5 Feb 2011, GOUJON Alexandre wrote: On 02/05/2011 02:59 PM, André Hentschel wrote: Which WineAPI on the regular Wine Wiki??? URL? I guess he's talking about this http://source.winehq.org/WineAPI/ It says generated automatically but where is the script ? Max, if you want, you can still improve the script and make it more useful. For instance, instead of Statistics which give simple numbers, I think a link to each function in the wine source code should be great. I have some ideas like adding a search feature, a link to the test that implement the selected function ..etc It may be useful when you want modify a function but you don't know where it is. For instance, wine_dbgstr_w() is used everywhere. But where is it defined ? It should be a usage of the WineAPI but that's only my point of view. I've seen this discussion come and go a few times... Would something like LXR be appropriate for generating a web front-end to searching and indexing the Wine source code? I've used the various Linux kernel sites a time or two: http://sourceforge.net/projects/lxr/ Steve Brown sbro...@umbc.edu Script is 'tools/c2man.pl'. There are several things in it that need improvement. See my other thread from yesterday. Max
Killing WineAPI project on SourceForge.
No feedback and apparently no interest in the WineAPI project on SourceForge. Understandable since there is now a WineAPI on the regular Wine Wiki. Unless someone objects, I'm going to ask that it be shutdown on SourceForge. Max
Wine API documentation questions.
I've been going through the Wine API documentation and there seem to be some things that I think should be changed: - There are references to Wine documents that do not include links to the pages. The links should be included. - Some 'implementation' sections claim that the API is not declared but there are declarations, just not in headers that 'c2man' is looking at. It should also look in any sub-directories (except for 'tests') of the '-I' directories it is told about for additional headers. (I have very little skill with Perl at present, so someone else might be able to add this much faster than I will be able to do it.) - There are quite a few APIs implemented but without standard documentation. All accessible APIs should have enough documentation so that there is a page for it, even if it is only a synopsis. - Mangled interface names only appear in their mangled form. The documentation should include the demangled name as well. Should the demangled names also appear in the indexes? - The 'synopsis' does not include needed '#include' directives. This may need to be fixed in each API description rather than trying to get 'c2man' to generate it. - The name of the file containing the implementation is included in each 'implementation' section and includes a link to the appropriate repository source entry. The name of the appropriate header is also included, but does not include a link. A link should be included. Max
Where can I get OpenCL for Fedora 14.
For the first time in several years, I did a fresh install on this machine and I am in the process of getting all the tweaks back in place. Part of that process is assuring that wine's configure script has all the pieces it can use. I have found almost everything. What I am missing is OpenCL (that is C as in Charles). I see stuff for Apple, but not for Fedora.i386 (cpu is intel.core2 and an Nvidia card). Search results are inconclusive - I checked the first five pages and found nothing specifically about .rpm files. Where can I get an .rpm or tarball that contains a usable OpenCL implementation for Fedora 14? Max
FYI: OpenCL/opencl.h from NVIDIA...
But it is not an RPM or tarball. It's in their 'cudatoolkit'. Umm, guys, the pointer to the fedora list isn't helpful. Someone here is going to know much more about where to get that package than J. Random Joe over on the Fedora lists since someone here obviously coded the requirement for it into 'configure'. 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
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
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 (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 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 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: 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 articles. That's one of the things I don't like in msdn. Want do know what's
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 DLLs with corresponding names
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
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 Woodburym...@mtew.isa-geek.net 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 Woodburym...@mtew.isa-geek.net 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 Woodburym...@mtew.isa-geek.net 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
