Re: PDB format documentation.
On Sun, 25 Mar 2012 05:24:45 -0300, Svyatoslav Kuzmich svatosl...@gmail.com wrote: Hello dear Wine mailing list! I've found that Wine dbghelp.dll includes PDB file parser. Does anyone know where I can find documentation of PDB internal structure? http://undocumented.rawol.com/ May have parts of the info you want. Roald
re: PDB format documentation.
Svyatoslav wrote: I've found that Wine dbghelp.dll includes PDB file parser. Does anyone know where I can find documentation of PDB internal structure? I think you've found it :-) As you probably know, PDB is an undocumented format. I suspect the best you can find are scattered posts like http://moyix.blogspot.com/2007/08/pdb-stream-decomposition.html http://www.godevtool.com/Other/pdb.htm from people who reverse engineer bits of it. Although http://moyix.blogspot.com/2007/08/pdb-stream-decomposition.html claims http://ccimetadata.codeplex.com/ has some interesting bits from the horse's mouth, and http://code.google.com/p/pdbparse/ http://code.google.com/p/pdbparser/ http://pdbparser.codeplex.com might be interesting.
Re: [PATCH 1/2] cmd: Improve WCMD_fgets documentation
2011/10/1 Dan Kegel d...@kegel.com: + * We can't use the native f* functions because of the filename syntax differences + * between DOS and Unix. That doesn't belong in a function comment; it's an implementation detail that belongs, at most, inside the function. Yeah true. I simply copied it over from previous doc. Might move it/delete part of it
re: [PATCH 1/2] cmd: Improve WCMD_fgets documentation
+ * We can't use the native f* functions because of the filename syntax differences + * between DOS and Unix. That doesn't belong in a function comment; it's an implementation detail that belongs, at most, inside the function.
Re: advpack: Only do_ocx_reg (and thus DllRegisterServer) from RegisterOCX when 'N' is passed as a flag. Clarify documentation.
Hi James, On Thu, 13 May 2010, Gerald Pfeifer wrote: Would you feel more comfortable leaving the documentation as is and me just suggesting the following? if(strchrW(str_flags,'I')) hr = do_ocx_reg(hm, TRUE); to replace hr = do_ocx_reg(hm, TRUE); ? Or would you prefer to submit a patch to clarify the documentation (copying me) and based on that I hack the code? That way we'd ensure that the former is sufficiently clear and I assume you'll verify whether the code matches that? I just realized I did not see a response to this. How about the patch below that actually matches current documentation (which the current code does not seem to)? Gerald ChangeLog: Only register if I has been passed as a flag. --- dlls/advpack/advpack.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/dlls/advpack/advpack.c b/dlls/advpack/advpack.c index 112d38a..c57933b 100644 --- a/dlls/advpack/advpack.c +++ b/dlls/advpack/advpack.c @@ -519,7 +519,8 @@ HRESULT WINAPI RegisterOCX(HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show) if (!hm) goto done; -hr = do_ocx_reg(hm, TRUE); +if(strchrW(str_flags,'I')) +hr = do_ocx_reg(hm, TRUE); done: FreeLibrary(hm); -- 1.7.6
Re: advpack: Only do_ocx_reg (and thus DllRegisterServer) from RegisterOCX when 'N' is passed as a flag. Clarify documentation.
I recommend writing unit tests to answer the open questions. Thanks, James On Sat, Sep 24, 2011 at 2:46 PM, Gerald Pfeifer ger...@pfeifer.com wrote: Hi James, On Thu, 13 May 2010, Gerald Pfeifer wrote: Would you feel more comfortable leaving the documentation as is and me just suggesting the following? if(strchrW(str_flags,'I')) hr = do_ocx_reg(hm, TRUE); to replace hr = do_ocx_reg(hm, TRUE); ? Or would you prefer to submit a patch to clarify the documentation (copying me) and based on that I hack the code? That way we'd ensure that the former is sufficiently clear and I assume you'll verify whether the code matches that? I just realized I did not see a response to this. How about the patch below that actually matches current documentation (which the current code does not seem to)? Gerald ChangeLog: Only register if I has been passed as a flag. --- dlls/advpack/advpack.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/dlls/advpack/advpack.c b/dlls/advpack/advpack.c index 112d38a..c57933b 100644 --- a/dlls/advpack/advpack.c +++ b/dlls/advpack/advpack.c @@ -519,7 +519,8 @@ HRESULT WINAPI RegisterOCX(HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show) if (!hm) goto done; - hr = do_ocx_reg(hm, TRUE); + if(strchrW(str_flags,'I')) + hr = do_ocx_reg(hm, TRUE); done: FreeLibrary(hm); -- 1.7.6
Re: documentation: Remove ChangeLog.*.
On Wed, Aug 31, 2011 at 3:25 PM, Octavian Voicu wrote: They are not used anymore. Last change was with the release of wine 1.0. Sent as attachment because of the huge lines. Alexandre, This patch was sent before I got your reply on wine-devel, so you can ignore it. Probably was in the moderation queue because it is totally huge... Octavian
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.
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
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: [PATCH] NTDLL atom.c documentation.
On 3/6/2011 22:34, Max TenEyck Woodbury wrote: 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. 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. Max
Re: [PATCH] Fixed several links in the documentation...
m...@mtew.isa-geek.net writes: @@ -204,7 +204,7 @@ int CDECL MSVCRT__chdir(const char * newdir) /* * _wchdir (MSVCRT.@) * - * Unicode version of _chdir. + * Unicode version of MSVCRT__chdir. You don't want to use the internal name here, it's not useful for users. -- Alexandre Julliard julli...@winehq.org
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
Old documentation changelogs to be kept?
In the documentation directory, there are ChangeLog.ALPHA, ChangeLog.BETA and ChangeLog.OLD. Are these files still useful (most recent entry is dated 2008-06-16)? Or are they simply kept as a log of the good old pre-git days? Frédéric
Re: RFC: Wine API Documentation Proposal
On Fri, Jul 2, 2010 at 12:01 PM, Peter Davies ultra...@gmail.com wrote: I think the speed and freedom provided by wiki is more important than vetting. Most problems would be due to vandalism (easily reverted), people will keep an eye on Recent Changes. If the problem is overwhelming, we will make editing privileges require a grant by an admin on a shall issue basis. Bogus information is a non-issue, people with sufficient knowledge to enter convincing information are not going to be the sort to enter bogus information. Wikipedia has a high level of accuracy despite its openness. Maybe our concern should not be bogus information but ill-gotten information. My concern would be that information acquired from reverse engineering would be tainted for Wine development purposes (which is what concerns me about the soared.org site mentioned on wine-devel). I suppose that it technically would fall under the traditional Compaq clean room reverse engineering - provided that whomever posted API details on the site was not also the person posting patches to implement those details in Wine. I'm not sure how we could best handle this, but it is my understanding that most of the modern wiki software has an option to require editor approval. I am hesitant to want to turn on such an option, at least in the beginning, since I think it would discourage contribution - but it is an option. Does anyone have a particularly preferred wiki software that they are familiar with that they think will work well for what we're doing? I don't really keep track of the different wiki packages, but last time I setup a mediawiki site I was a bit disappointed by the lack of built-in macros. While SF specifically mentions a couple wiki packages it looks like they are pretty flexible with what you can load up, since they will let you create your own databases - so I think we could setup anything we like. Does anyone have any reasons we would want to go with somewhere other than SF? It seems to me like it would provide us with anything we need with the added bonus of being free. Erich Hoover ehoo...@mines.edu
Re: TRACE () documentation
James McKenzie wrote: James Hawkins wrote: On Thu, Jan 14, 2010 at 6:19 PM, James McKenzie jjmckenzi...@earthlink.net wrote: All: Is there documentation anywhere on how to use the TRACE command? I am trying to print out the contents of a UNICODE string using this commnd. Thank you. There are thousands and thousands of examples in the source already. wchar* unicode_str; or LPWSTR unicode_str; TRACE(%s\n, debugstr_w(unicode_str)); Duh I knew the answer was simple. I think this needs a page on the Wiki in the developer area. I just could not find an example in all of the TRACEs there Thank you James. One further question, will this work with printf or will I have to do something else? I'm trying to find out why the UNICODE'd version of the same ASCII letter is not being interpeted the same. This just recently stopped working as well. James McKenzie
Re: TRACE () documentation
James McKenzie wrote: James McKenzie wrote: James Hawkins wrote: On Thu, Jan 14, 2010 at 6:19 PM, James McKenzie jjmckenzi...@earthlink.net wrote: All: Is there documentation anywhere on how to use the TRACE command? I am trying to print out the contents of a UNICODE string using this commnd. Thank you. There are thousands and thousands of examples in the source already. wchar* unicode_str; or LPWSTR unicode_str; TRACE(%s\n, debugstr_w(unicode_str)); Duh I knew the answer was simple. I think this needs a page on the Wiki in the developer area. I just could not find an example in all of the TRACEs there Thank you James. One further question, will this work with printf or will I have to do something else? I'm trying to find out why the UNICODE'd version of the same ASCII letter is not being interpeted the same. This just recently stopped working as well. Had to go to TRACE. Using this with printf produced a wonderful error (function not found). James McKenzie
Re: TRACE () documentation
James McKenzie wrote: James McKenzie wrote: James McKenzie wrote: James Hawkins wrote: On Thu, Jan 14, 2010 at 6:19 PM, James McKenzie jjmckenzi...@earthlink.net wrote: All: Is there documentation anywhere on how to use the TRACE command? I am trying to print out the contents of a UNICODE string using this commnd. Thank you. There are thousands and thousands of examples in the source already. wchar* unicode_str; or LPWSTR unicode_str; TRACE(%s\n, debugstr_w(unicode_str)); Duh I knew the answer was simple. I think this needs a page on the Wiki in the developer area. I just could not find an example in all of the TRACEs there Thank you James. One further question, will this work with printf or will I have to do something else? I'm trying to find out why the UNICODE'd version of the same ASCII letter is not being interpeted the same. This just recently stopped working as well. Had to go to TRACE. Using this with printf produced a wonderful error (function not found). Still did not work. Used ok and now am trying to figure out what is truncating the string James McKenzie
Re: (Resent) Documentation - Reference to MSDN?
James McKenzie jjmckenzi...@earthlink.net wrote: Creating a MSDN clone does not belong to the Wine project. I think you completely miss what this is all about. We are NOT creating an MSDN 'clone'. Maybe a cleaned up duplicate of soared.org. We do need to annotate, in one location, the project's findings and code that is pending implementation that was acquired through research of existing resources and validation through blackbox testing. It is NOT our purpose to provide sample code or anything like it. That is what MSDN is there for. To assist Microsoft Developers working with Windows products to produce Windows programs. Not to assist or aid any others in the pursuit of a 'look alike' API that just happens to run on UNIXy operating systems. I agree with Alexandre, we don't need to hijack the wiki for Wine to do this. Maybe we do need another wiki site that is separate from but equal to the current wiki, but for Wine developers/hackers only and their efforts to improve upon current Wine project efforts. Who are those we? I personally don't need anything listed above. Quoting Alexandre's response: That's what the source code and test cases are for. If you rely on the function documentation you are in trouble anyway, nobody bothers to update it when new behaviors are discovered. -- Dmitry.
Re: (Resent) Documentation - Reference to MSDN?
On Fri, Jul 2, 2010 at 3:51 AM, Dmitry Timoshkov dmi...@codeweavers.com wrote: James McKenzie jjmckenzi...@earthlink.net wrote: ... It is NOT our purpose to provide sample code or anything like it. That is what MSDN is there for. To assist Microsoft Developers working with Windows products to produce Windows programs. Not to assist or aid any others in the pursuit of a 'look alike' API that just happens to run on UNIXy operating systems. ... Who are those we? I personally don't need anything listed above. We is whomever wants to help with this idea. Preferably, many people like you that are already intimately aware with the details of at least some of the API. This kind of resource would be most beneficial for those that are either just getting started contributing to Wine or those branching out to fix something outside of their area of expertise. I know that I've been spending a large fraction of my free time researching how Windows handles animated cursors, consolidating the links to all the resources and the tidbits of information I've found would likely save anyone else looking into the same problems a lot of time. I still don't know what GetCursorFrameInfo does, and I have a hunch that it might be useful in doing a proper animated cursor implementation. Quoting Alexandre's response: That's what the source code and test cases are for. If you rely on the function documentation you are in trouble anyway, nobody bothers to update it when new behaviors are discovered. I would argue that good documentation is just as important as source code and test cases. It can save a lot of time in introducing new people to the code, even if it is somewhat out of date. On projects I've been in charge of in the past my policy has always been that the documentation is in the code and generated by a script - that usually works as a pretty good eyesore to get developers to update it as they go. However, since that's off the table there are other methods for keeping documentation up to date. For example, a Documentation Tracker could be setup for the documentation folks to review new commits and see if they warrant an update to the documentation. Erich Hoover ehoo...@mines.edu
Re: RFC: Wine API Documentation Proposal
I don't know about the 'respectability' of SF, but I'm more concerned with the content and who gets to change it. There are folks that may decide to enter incorrect or even bogus information. I would like it if all added information that is not already present in the Wine API be vetted. That means one person enters it and another disassociated person verifies before it goes live. Code already in the API should be considered automatically vetted. I think the speed and freedom provided by wiki is more important than vetting. Most problems would be due to vandalism (easily reverted), people will keep an eye on Recent Changes. If the problem is overwhelming, we will make editing privileges require a grant by an admin on a shall issue basis. Bogus information is a non-issue, people with sufficient knowledge to enter convincing information are not going to be the sort to enter bogus information. Wikipedia has a high level of accuracy despite its openness. Peter
Re: (Resent) Documentation - Reference to MSDN?
On 06/30/2010 03:13 PM, Alexandre Julliard wrote: Erich Hooverehoo...@mines.edu writes: Alright, well then I won't do it. Is the existing documentation going to be stripped at some point? It seems to me like we would benefit from more-detailed function descriptions in the auto-generated API documentation. I think it would save a lot of time for new developers to get their feet wet if they were able to see directly in the source what the different functions are supposed to do (as best as we know) and exactly what applications will trigger known edge cases (or if there's a test for a given situation). That's what the source code and test cases are for. If you rely on the function documentation you are in trouble anyway, nobody bothers to update it when new behaviors are discovered. If you really want to write good API documentation, as opposed to the current useless one-sentence-per-parameter description, you'd need probably a text 10 times the size of the source code for each function. That can't go in the source files. So, would it be OK with you to extract the current documentation and put it in the wiki where it can be more easily maintained? Wikis are supposed to be good for exactly that kind of thing. Once the wiki is populated with the initial information from the source code, the source code could then be cleaned up by having links to the wiki in place of the current cruft. Erich Hover's tree structure sounds like the right way to go. Formatting guidelines and templates to tag the article contents so the information can be easily extracted will be needed, but that belongs on the wiki, although issues should be discussed and decided on this mailing list.
Re: Documentation - Reference to MSDN?
On 06/30/2010 09:22 AM, Max TenEyck Woodbury wrote: 1) Would including the URL of the MSDN article be useful/a good idea? No. Microsoft in all these years haven't figured out how to create permanent links. All, and I really mean it _ALL_ URLS on MSDN had changed at least once a year. 2) Would enumerating coded values and flags be allowed? That's what headers are for. 3) Where should data structures be documented? On MSDN. Wine is an implementation of API not the spec. Vitaliy.
Re: (Resent) Documentation - Reference to MSDN?
Max TenEyck Woodbury m...@mtew.isa-geek.net writes: So, would it be OK with you to extract the current documentation and put it in the wiki where it can be more easily maintained? Wikis are supposed to be good for exactly that kind of thing. Once the wiki is populated with the initial information from the source code, the source code could then be cleaned up by having links to the wiki in place of the current cruft. That's fine, but please don't hijack the Wine wiki for this, start a separate one. -- Alexandre Julliard julli...@winehq.org
Re: (Resent) Documentation - Reference to MSDN?
On Thu, Jul 1, 2010 at 7:56 AM, Alexandre Julliard julli...@winehq.org wrote: Max TenEyck Woodbury m...@mtew.isa-geek.net writes: So, would it be OK with you to extract the current documentation and put it in the wiki where it can be more easily maintained? Wikis are supposed to be good for exactly that kind of thing. Once the wiki is populated with the initial information from the source code, the source code could then be cleaned up by having links to the wiki in place of the current cruft. That's fine, but please don't hijack the Wine wiki for this, start a separate one. If we mock up an example, and it is deemed acceptable, would we be permitted to make patches replacing the in-code documentation with the URL for the appropriate function? The idea here would be to accomplish several goals: 1) Give new Wine developers somewhere to look for documentation to help them get started 2) Give current Wine developers investigating something outside of their expertise some information to help familiarize them with another area of the API 3) Provide unchanging URLs that can legitimately be used in the source code without fear of them changing every week (or being lost forever in the case of some older functions) 4) Document the ever-growing list of unexpected behaviors that MSDN will never tell you about Obviously this is a big task and it's not something that is going to happen overnight, but I think that such a wiki could provide a useful service to the Wine community. My primary concern here is participation, since if there's little or no participation it will never grow to the magnitude that's necessary for it to be a helpful resource. So, I guess I'm saying that if there's at least some chance of embedding URLs in the source that will direct people to this documentation then I'd feel much more comfortable investing my free time in setting something up. Erich Hoover ehoo...@mines.edu
Re: (Resent) Documentation - Reference to MSDN?
Erich Hoover ehoo...@mines.edu writes: Obviously this is a big task and it's not something that is going to happen overnight, but I think that such a wiki could provide a useful service to the Wine community. My primary concern here is participation, since if there's little or no participation it will never grow to the magnitude that's necessary for it to be a helpful resource. So, I guess I'm saying that if there's at least some chance of embedding URLs in the source that will direct people to this documentation then I'd feel much more comfortable investing my free time in setting something up. We can have pointers on the website or the README, and we can probably find a way to have doc links in the lxref source browser. We certainly don't want a URL in front of each function in the source, it will be a major pain when they change (and trust me, they will). Just make sure that your pages are properly indexed by Google. -- Alexandre Julliard julli...@winehq.org
Re: (Resent) Documentation - Reference to MSDN?
My primary concern here is participation Count me in! I think it would be a great way to learn the wine/windows internals. Peter
Re: (Resent) Documentation - Reference to MSDN?
On 07/01/2010 04:34 AM, Dmitry Timoshkov wrote: Max TenEyck Woodburym...@mtew.isa-geek.net wrote: I created the top page as a table and populated it with all the directory entries in the 'dll' directory. Somebody immediately deleted it. WTF? Creating a MSDN clone does not belong to the Wine project. But maybe it should? MSDN is famous for being pretty good, but incomplete, incorrect and changing URLs all the time. // Jakob
Re: (Resent) Documentation - Reference to MSDN?
On Thu, Jul 1, 2010 at 8:06 PM, Erich Hoover ehoo...@mines.edu wrote: 3) Provide unchanging URLs that can legitimately be used in the source code without fear of them changing every week (or being lost forever in the case of some older functions) 4) Document the ever-growing list of unexpected behaviors that MSDN will never tell you about Why would we want to help Micro$oft with that? How did they ever contribute to the open source community to deserve that? As I see it, Wine's primary goal is to aid in the migration from Windows, a closed platform, to an open platform like Linux. There is enough to do already (kernel, system dlls, many many libraries, installer, directx, command line tools, various programs and tools, testing infrastructure, translations, etc), if we spread ourselves too thin we won't get anywhere with anything. Imho there are very few cases in which better documentation would benefit our cause, but I'm pretty sure that devoting that time to writing wine code instead of winapi documentation would have a much greater impact. Octavian PS: there are other resources except MSDN; for example, osronline.com has very good documentation for windows driver developers, including some undocumented APIs.
Re: (Resent) Documentation - Reference to MSDN?
On Fri, Jul 2, 2010 at 7:35 AM, Octavian Voicu octavian.vo...@gmail.com wrote: PS: there are other resources except MSDN; for example, osronline.com has very good documentation for windows driver developers, including some undocumented APIs. I don't know if this is worth mentioning or not, Geoff Chappell maintains a website with some in depth information covering Windows internals, granted the methods used to discover the information may not be in line with what a Wine contributor is allowed to do, but in the same spirit of quality information he has proposed an initiative producing an Opened Windows Library (OWL) as an alternative to Microsoft’s MSDN Library. Maybe this could be what you're looking for. http://geoffchappell.com/viewer.htm?doc=index.htm http://www.soared.org/ http://www.soared.org/plan/index.htm http://www.soared.org/plan/faq.htm PS. The idea of publishing this information to a wiki seems a little ad-hoc, wouldn't it be better to put things under a dvcs (like git) and then publish based on that?
Re: (Resent) Documentation - Reference to MSDN?
Dmitry Timoshkov wrote: Max TenEyck Woodbury m...@mtew.isa-geek.net wrote: I created the top page as a table and populated it with all the directory entries in the 'dll' directory. Somebody immediately deleted it. WTF? Creating a MSDN clone does not belong to the Wine project. Dmitry: I think you completely miss what this is all about. We are NOT creating an MSDN 'clone'. Maybe a cleaned up duplicate of soared.org. We do need to annotate, in one location, the project's findings and code that is pending implementation that was acquired through research of existing resources and validation through blackbox testing. It is NOT our purpose to provide sample code or anything like it. That is what MSDN is there for. To assist Microsoft Developers working with Windows products to produce Windows programs. Not to assist or aid any others in the pursuit of a 'look alike' API that just happens to run on UNIXy operating systems. I agree with Alexandre, we don't need to hijack the wiki for Wine to do this. Maybe we do need another wiki site that is separate from but equal to the current wiki, but for Wine developers/hackers only and their efforts to improve upon current Wine project efforts. James McKenzie
Re: Documentation - Reference to MSDN?
Vitaliy Margolen wrote: On 06/30/2010 09:22 AM, Max TenEyck Woodbury wrote: 1) Would including the URL of the MSDN article be useful/a good idea? No. Microsoft in all these years haven't figured out how to create permanent links. All, and I really mean it _ALL_ URLS on MSDN had changed at least once a year. They have learned well from IBM. I have links that I use at work that change on an almost weekly basis. 2) Would enumerating coded values and flags be allowed? That's what headers are for. Correct. However, if a flag is used in more than one place, it would be 'nice' to annotate that the flag/enumeration does exist. Saves embarrassing and unnecessary patch submissions 3) Where should data structures be documented? On MSDN. Wine is an implementation of API not the spec. I agree. The functions and their calls/results are what we are interested in. We don't care how M$ got there, we are on a different path. James McKenzie
(Resent) Documentation - Reference to MSDN?
I've been reading the Wine code and noticed that some of the external interfaces are practically undocumented. I did a web search on some of the names and found descriptions in MSDN. I realize that copying the information from MSDN directly into the code is a poor idea (like copyright violation) so I have a couple of questions: 1) Would including the URL of the MSDN article be useful/a good idea? 2) Would enumerating coded values and flags be allowed? 3) Where should data structures be documented?
Re: (Resent) Documentation - Reference to MSDN?
Hi Max, 1) Would including the URL of the MSDN article be useful/a good idea? No. MSDN is in the habit of changing its URLs all too frequently. A more general response: I'm not sure that a lot of documentation patches will be accepted. MSDN has to be considered the definitive resource for the Windows API. It's often incorrect, of course, and our regression tests aim to ameliorate the inaccuracy, but we probably have enough work implementing the Windows API without taking on the task of documenting it too. --Juan
Re: (Resent) Documentation - Reference to MSDN?
Am 30.06.2010 19:25, schrieb Max TenEyck Woodbury: I've been reading the Wine code and noticed that some of the external interfaces are practically undocumented. I did a web search on some of the names and found descriptions in MSDN. I realize that copying the information from MSDN directly into the code is a poor idea (like copyright violation) so I have a couple of questions: 1) Would including the URL of the MSDN article be useful/a good idea? Might be a bad idea as such URL may be dead in 12 Month or so, but it is not forbidden. 2) Would enumerating coded values and flags be allowed? That is the best solution i think. -- Best Regards, André Hentschel
Re: (Resent) Documentation - Reference to MSDN?
No. MSDN is in the habit of changing its URLs all too frequently. For what it's worth, while MSDN seems to like changing its URLs a lot, it does seem to be quite good at maintaining forwarders for the old URLs - most API documentation URLs I've randomly found from 5 years ago still work, for instance. But I agree that it's probably not worth including them in Wine's documentation. -- Owen Rudge http://www.owenrudge.net/
Re: (Resent) Documentation - Reference to MSDN?
On Wed, Jun 30, 2010 at 11:44 AM, Juan Lang juan.l...@gmail.com wrote: ... A more general response: I'm not sure that a lot of documentation patches will be accepted. MSDN has to be considered the definitive resource for the Windows API. It's often incorrect, of course, and our regression tests aim to ameliorate the inaccuracy, but we probably have enough work implementing the Windows API without taking on the task of documenting it too. --Juan I was looking into this a while ago and you can add documentation to the Wine API by properly formatting it in your patches, for example: http://source.winehq.org/WineAPI/CreateIcon.html is generated from the code here: http://source.winehq.org/source/dlls/user32/cursoricon.c#L1473 Personally, I think that it would be really good to do a better job of documenting the API functions (particularly edge cases). I'm currently very busy with work, but if Alexandre is ok with documentation-only patches then this is something I'm tempted to jump on (in the areas where I have sufficient familiarity) when I have some more free time. Erich Hoover ehoo...@mines.edu
Re: (Resent) Documentation - Reference to MSDN?
Juan Lang: grin Of course one of the reasons to add documentation is precisely because the information on MSDN is less than perfect. Having a good interface definition makes things easier. I'm still in the process of learning how to submit patches. These would be low risk but useful changes so they make good test material. Juan Lang, André Hentschel, Owen Rudge: So, from what Owen said, having a URL can be helpful, but should not be the total documentation. A date as part of the reference probably would be enough warning that things change. Alexandre: Would you mind getting documentation update patches during the code freeze?
Re: (Resent) Documentation - Reference to MSDN?
Erich Hoover ehoo...@mines.edu writes: Personally, I think that it would be really good to do a better job of documenting the API functions (particularly edge cases). I'm currently very busy with work, but if Alexandre is ok with documentation-only patches then this is something I'm tempted to jump on (in the areas where I have sufficient familiarity) when I have some more free time. I'm not OK with it. If you want to start a project to document the Windows API, go ahead, but don't put that in the Wine source, that's not where it belongs. -- Alexandre Julliard julli...@winehq.org
Re: (Resent) Documentation - Reference to MSDN?
On Wed, Jun 30, 2010 at 12:44 PM, Alexandre Julliard julli...@winehq.org wrote: Erich Hoover ehoo...@mines.edu writes: Personally, I think that it would be really good to do a better job of documenting the API functions (particularly edge cases). I'm currently very busy with work, but if Alexandre is ok with documentation-only patches then this is something I'm tempted to jump on (in the areas where I have sufficient familiarity) when I have some more free time. I'm not OK with it. If you want to start a project to document the Windows API, go ahead, but don't put that in the Wine source, that's not where it belongs. Alright, well then I won't do it. Is the existing documentation going to be stripped at some point? It seems to me like we would benefit from more-detailed function descriptions in the auto-generated API documentation. I think it would save a lot of time for new developers to get their feet wet if they were able to see directly in the source what the different functions are supposed to do (as best as we know) and exactly what applications will trigger known edge cases (or if there's a test for a given situation). Erich Hoover ehoo...@mines.edu
Re: (Resent) Documentation - Reference to MSDN?
Erich Hoover ehoo...@mines.edu writes: Alright, well then I won't do it. Is the existing documentation going to be stripped at some point? It seems to me like we would benefit from more-detailed function descriptions in the auto-generated API documentation. I think it would save a lot of time for new developers to get their feet wet if they were able to see directly in the source what the different functions are supposed to do (as best as we know) and exactly what applications will trigger known edge cases (or if there's a test for a given situation). That's what the source code and test cases are for. If you rely on the function documentation you are in trouble anyway, nobody bothers to update it when new behaviors are discovered. If you really want to write good API documentation, as opposed to the current useless one-sentence-per-parameter description, you'd need probably a text 10 times the size of the source code for each function. That can't go in the source files. -- Alexandre Julliard julli...@winehq.org
Re: (Resent) Documentation - Reference to MSDN?
On 06/30/2010 03:13 PM, Alexandre Julliard wrote: Erich Hooverehoo...@mines.edu writes: Alright, well then I won't do it. Is the existing documentation going to be stripped at some point? It seems to me like we would benefit from more-detailed function descriptions in the auto-generated API documentation. I think it would save a lot of time for new developers to get their feet wet if they were able to see directly in the source what the different functions are supposed to do (as best as we know) and exactly what applications will trigger known edge cases (or if there's a test for a given situation). That's what the source code and test cases are for. If you rely on the function documentation you are in trouble anyway, nobody bothers to update it when new behaviors are discovered. If you really want to write good API documentation, as opposed to the current useless one-sentence-per-parameter description, you'd need probably a text 10 times the size of the source code for each function. That can't go in the source files. That documentation has to be stored somewhere. Where?
Re: (Resent) Documentation - Reference to MSDN?
Alexandre Julliard julli...@winehq.org wrote: Erich Hoover ehoo...@mines.edu writes: Alright, well then I won't do it. Is the existing documentation going to be stripped at some point? It seems to me like we would benefit from more-detailed function descriptions in the auto-generated API documentation. I think it would save a lot of time for new developers to get their feet wet if they were able to see directly in the source what the different functions are supposed to do (as best as we know) and exactly what applications will trigger known edge cases (or if there's a test for a given situation). That's what the source code and test cases are for. If you rely on the function documentation you are in trouble anyway, nobody bothers to update it when new behaviors are discovered. If you really want to write good API documentation, as opposed to the current useless one-sentence-per-parameter description, you'd need probably a text 10 times the size of the source code for each function. That can't go in the source files. How about some place on the Wiki along with an implementation status. That way we can also annotate items that are missing in MSDN (I just re-stumbled across something in my latest Richedit tests) as well. This would help greatly in our progress towards current and future implementations of the Windows API. And I agree, adding all of this to the source would make it unwieldy. James McKenzie
Re: (Resent) Documentation - Reference to MSDN?
On Wed, Jun 30, 2010 at 1:36 PM, James Mckenzie jjmckenzi...@earthlink.net wrote: ... How about some place on the Wiki along with an implementation status. That way we can also annotate items that are missing in MSDN (I just re-stumbled across something in my latest Richedit tests) as well. This would help greatly in our progress towards current and future implementations of the Windows API. And I agree, adding all of this to the source would make it unwieldy. So something like http://wiki.winehq.org/WineAPI/DLL/Function ? If that's acceptable I would not mind a system like that, especially if the links of documented functions are provided in the source. Documenting these things is a lot of work, so I'm not about to run off and do all that work if no-one is ever going to take advantage of it. Erich Hoover ehoo...@mines.edu
Re: (Resent) Documentation - Reference to MSDN?
Erich Hoover ehoo...@mines.edu wrote: Sent: Jun 30, 2010 12:43 PM To: James Mckenzie jjmckenzi...@earthlink.net Cc: Alexandre Julliard julli...@winehq.org, Max TenEyck Woodbury m...@mtew.isa-geek.net, wine-devel@winehq.org Subject: Re: (Resent) Documentation - Reference to MSDN? On Wed, Jun 30, 2010 at 1:36 PM, James Mckenzie jjmckenzi...@earthlink.net wrote: ... How about some place on the Wiki along with an implementation status. That way we can also annotate items that are missing in MSDN (I just re-stumbled across something in my latest Richedit tests) as well. This would help greatly in our progress towards current and future implementations of the Windows API. And I agree, adding all of this to the source would make it unwieldy. So something like http://wiki.winehq.org/WineAPI/DLL/Function ? If that's acceptable I would not mind a system like that, especially if the links of documented functions are provided in the source. Documenting these things is a lot of work, so I'm not about to run off and do all that work if no-one is ever going to take advantage of it. +1 Acceptable variables should be listed in an order other than the one on MSDN. We don't want a direct copy, but rather OUR findings using the old 'black box' method. James McKenzie
Documentation - Reference to MSDN?
I've been reading the Wine code and noticed that some of the external interfaces are practically undocumented. I did a web search on some of the names and found descriptions in MSDN. I realize that copying the information from MSDN directly into the code is a poor idea (like copyright violation) so I have a couple of questions: 1) Would including the URL of the MSDN article be useful/a good idea? 2) Would enumerating coded values and flags be allowed? 3) Where should data structures be documented?
Re: (Resent) Documentation - Reference to MSDN?
On 06/30/2010 03:43 PM, Erich Hoover wrote: On Wed, Jun 30, 2010 at 1:36 PM, James Mckenzie jjmckenzi...@earthlink.net wrote: ... How about some place on the Wiki along with an implementation status. That way we can also annotate items that are missing in MSDN (I just re-stumbled across something in my latest Richedit tests) as well. This would help greatly in our progress towards current and future implementations of the Windows API. And I agree, adding all of this to the source would make it unwieldy. So something like http://wiki.winehq.org/WineAPI/DLL/Function ? If that's acceptable I would not mind a system like that, especially if the links of documented functions are provided in the source. Documenting these things is a lot of work, so I'm not about to run off and do all that work if no-one is ever going to take advantage of it. Erich Hoover ehoo...@mines.edu I created the top page as a table and populated it with all the directory entries in the 'dll' directory. Somebody immediately deleted it. WTF?
Re: (Resent) Documentation - Reference to MSDN?
Max TenEyck Woodbury m...@mtew.isa-geek.net wrote: I created the top page as a table and populated it with all the directory entries in the 'dll' directory. Somebody immediately deleted it. WTF? Creating a MSDN clone does not belong to the Wine project. -- Dmitry.
Re: advpack: Only do_ocx_reg (and thus DllRegisterServer) from RegisterOCX when 'N' is passed as a flag. Clarify documentation.
On Tue, 11 May 2010, James Hawkins wrote: I'm very hesitant about this. MSDN has no documentation about RegisterOCX, so I'm not sure how you're justifying this change. It's been a long time since I worked on this, so I don't remember much, but I do remember testing this method and documenting the parameters correctly. Where are you getting information that 'I' is required when using 'N'? I had to look again, and it seems the best I managed to find is the following: http://msdn.microsoft.com/en-us/library/bb759846%28VS.85%29.aspx If you experimentally verified something differently I will be happy to follow that. However, I did not found the original documentation sufficiently clear to really use it as a specification to base the implementation on. Specific questions I ran into were: - what happens if none of these are specified? - can the string contain more than one character? (pressumably yes?) - what happens if both are specified? Would you feel more comfortable leaving the documentation as is and me just suggesting the following? if(strchrW(str_flags,'I')) hr = do_ocx_reg(hm, TRUE); to replace hr = do_ocx_reg(hm, TRUE); ? Or would you prefer to submit a patch to clarify the documentation (copying me) and based on that I hack the code? That way we'd ensure that the former is sufficiently clear and I assume you'll verify whether the code matches that? Whatever works for you as long as we make progress. :-) Gerald
Re: advpack: Only do_ocx_reg (and thus DllRegisterServer) from RegisterOCX when 'N' is passed as a flag. Clarify documentation.
I'm very hesitant about this. MSDN has no documentation about
RegisterOCX, so I'm not sure how you're justifying this change. It's
been a long time since I worked on this, so I don't remember much, but
I do remember testing this method and documenting the parameters
correctly. Where are you getting information that 'I' is required
when using 'N'?
James
On Tue, May 11, 2010 at 1:24 PM, Gerald Pfeifer ger...@pfeifer.com wrote:
This is my humble attempt of addressing Alexandre's feeback at
http://www.winehq.org/pipermail/wine-devel/2010-May/083518.html
It does pass testing for me, even on FreeBSD/i386, but I will say I did
not find the MSDN documentation I located too helpful/clear, and may have
been misled.
As a next step we'd need to look into DllInstall. This change, hopefully,
is a move in the right direction, though. If not, some guidance or one of
the pros looking into it will be appreciated.
Gerald
---
dlls/advpack/advpack.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/dlls/advpack/advpack.c b/dlls/advpack/advpack.c
index 112d38a..f040ec6 100644
--- a/dlls/advpack/advpack.c
+++ b/dlls/advpack/advpack.c
@@ -486,8 +486,10 @@ HRESULT do_ocx_reg(HMODULE hocx, BOOL do_reg)
* NOTES
* OCX - Filename of the OCX to register.
* flags - Controls the operation of RegisterOCX.
- * 'I' Call DllRegisterServer and DllInstall.
- * 'N' Only call DllInstall.
+ * 'I' Call DllInstall and, unless 'N' is specified as well,
+ * DllRegisterServer.
+ * 'N' Do not call DllRegisterServer; only valid if 'I' is
+ * specified too.
* param - Command line passed to DllInstall.
*/
HRESULT WINAPI RegisterOCX(HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT
show)
@@ -519,8 +521,12 @@ HRESULT WINAPI RegisterOCX(HWND hWnd, HINSTANCE hInst,
LPCSTR cmdline, INT show)
if (!hm)
goto done;
- hr = do_ocx_reg(hm, TRUE);
-
+ if(strchrW(str_flags,'I'))
+ {
+ if (!strchrW(str_flags,'N'))
+ hr = do_ocx_reg(hm, TRUE);
+ }
+
done:
FreeLibrary(hm);
HeapFree(GetProcessHeap(), 0, cmdline_copy);
--
1.6.6.2
Re: Documentation?
Luke Benstead kaz...@gmail.com writes: While on the subject of documentation... would it be a good idea to begin documenting functions with something like Doxygen or similar? I'm just wondering if we could be building our own, much more accurate, MSDN. Is there a reason that Wine isn't documented in this way? Yes, it's not useful. Wine implements the Win32 API, and there's plenty of documentation for it already. If you want to replicate MSDN you are welcome to do it, but there's no reason to do it in Wine, the Win32 API is not defined by the Wine code. -- Alexandre Julliard julli...@winehq.org
Re: Documentation?
On Sat, Mar 13, 2010 at 11:40 PM, Scott Ritchie sc...@open-vote.org wrote: On 03/12/2010 11:01 AM, André Hentschel wrote: Hi Folks, As we are getting somehow closer to Wine 1.2 i wonder how important updates on the Documentation are. Further i am confused about sending patches, should they just change the git-repo docs or the pages on the website or both? The website pages are supposed to be automatically generated from the docs every release. So patch the docs themselves. Not sure if this process still works though. Thanks, Scott Ritchie I thought the plans were to attempt to move all documentation (in an updated form) to the Wiki. We would then need some mechanism to create documentation out of the wiki. Myself I rather update the wiki when I encounter an issue than that I update the old docs. Roderick
Re: Documentation?
On 14 March 2010 10:03, Roderick Colenbrander thunderbir...@gmail.com wrote: On Sat, Mar 13, 2010 at 11:40 PM, Scott Ritchie sc...@open-vote.org wrote: On 03/12/2010 11:01 AM, André Hentschel wrote: Hi Folks, As we are getting somehow closer to Wine 1.2 i wonder how important updates on the Documentation are. Further i am confused about sending patches, should they just change the git-repo docs or the pages on the website or both? The website pages are supposed to be automatically generated from the docs every release. So patch the docs themselves. Not sure if this process still works though. Thanks, Scott Ritchie I thought the plans were to attempt to move all documentation (in an updated form) to the Wiki. We would then need some mechanism to create documentation out of the wiki. Myself I rather update the wiki when I encounter an issue than that I update the old docs. Roderick While on the subject of documentation... would it be a good idea to begin documenting functions with something like Doxygen or similar? I'm just wondering if we could be building our own, much more accurate, MSDN. Is there a reason that Wine isn't documented in this way? Luke.
Re: Documentation?
On 03/14/2010 11:45 AM, Luke Benstead wrote: On 14 March 2010 10:03, Roderick Colenbranderthunderbir...@gmail.com wrote: On Sat, Mar 13, 2010 at 11:40 PM, Scott Ritchiesc...@open-vote.org wrote: On 03/12/2010 11:01 AM, André Hentschel wrote: Hi Folks, As we are getting somehow closer to Wine 1.2 i wonder how important updates on the Documentation are. Further i am confused about sending patches, should they just change the git-repo docs or the pages on the website or both? The website pages are supposed to be automatically generated from the docs every release. So patch the docs themselves. Not sure if this process still works though. Thanks, Scott Ritchie I thought the plans were to attempt to move all documentation (in an updated form) to the Wiki. We would then need some mechanism to create documentation out of the wiki. Myself I rather update the wiki when I encounter an issue than that I update the old docs. Roderick While on the subject of documentation... would it be a good idea to begin documenting functions with something like Doxygen or similar? I'm just wondering if we could be building our own, much more accurate, MSDN. Is there a reason that Wine isn't documented in this way? We do have (the autogenerated) http://source.winehq.org/WineAPI/ I know there is (was) an issue with the winapi tool so I can't tell if the API documentation on that page is accurate. -- Cheers, Paul.
Re: Documentation?
On 03/14/2010 11:58 AM, Paul Vriens wrote: On 03/14/2010 11:45 AM, Luke Benstead wrote: On 14 March 2010 10:03, Roderick Colenbranderthunderbir...@gmail.com wrote: On Sat, Mar 13, 2010 at 11:40 PM, Scott Ritchiesc...@open-vote.org wrote: On 03/12/2010 11:01 AM, André Hentschel wrote: Hi Folks, As we are getting somehow closer to Wine 1.2 i wonder how important updates on the Documentation are. Further i am confused about sending patches, should they just change the git-repo docs or the pages on the website or both? The website pages are supposed to be automatically generated from the docs every release. So patch the docs themselves. Not sure if this process still works though. Thanks, Scott Ritchie I thought the plans were to attempt to move all documentation (in an updated form) to the Wiki. We would then need some mechanism to create documentation out of the wiki. Myself I rather update the wiki when I encounter an issue than that I update the old docs. Roderick While on the subject of documentation... would it be a good idea to begin documenting functions with something like Doxygen or similar? I'm just wondering if we could be building our own, much more accurate, MSDN. Is there a reason that Wine isn't documented in this way? We do have (the autogenerated) http://source.winehq.org/WineAPI/ I know there is (was) an issue with the winapi tool so I can't tell if the API documentation on that page is accurate. I think the page I mentioned is fine. It's http://www.winehq.org/winapi_stats that didn't have an update in a while due to winapi issues. -- Cheers, Paul.
Re: Documentation?
On 14 March 2010 12:08, Paul Vriens paul.vriens.w...@gmail.com wrote: On 03/14/2010 11:58 AM, Paul Vriens wrote: On 03/14/2010 11:45 AM, Luke Benstead wrote: On 14 March 2010 10:03, Roderick Colenbranderthunderbir...@gmail.com wrote: On Sat, Mar 13, 2010 at 11:40 PM, Scott Ritchiesc...@open-vote.org wrote: On 03/12/2010 11:01 AM, André Hentschel wrote: Hi Folks, As we are getting somehow closer to Wine 1.2 i wonder how important updates on the Documentation are. Further i am confused about sending patches, should they just change the git-repo docs or the pages on the website or both? The website pages are supposed to be automatically generated from the docs every release. So patch the docs themselves. Not sure if this process still works though. Thanks, Scott Ritchie I thought the plans were to attempt to move all documentation (in an updated form) to the Wiki. We would then need some mechanism to create documentation out of the wiki. Myself I rather update the wiki when I encounter an issue than that I update the old docs. Roderick While on the subject of documentation... would it be a good idea to begin documenting functions with something like Doxygen or similar? I'm just wondering if we could be building our own, much more accurate, MSDN. Is there a reason that Wine isn't documented in this way? We do have (the autogenerated) http://source.winehq.org/WineAPI/ I know there is (was) an issue with the winapi tool so I can't tell if the API documentation on that page is accurate. I think the page I mentioned is fine. It's http://www.winehq.org/winapi_stats that didn't have an update in a while due to winapi issues. -- Cheers, Paul. Oh, I had actually seen that auto-generated documentation once before then lost it - still there are many functions without documentation. Would documentation-only patches be accepted? For example, I can use my lunch break at work to document functions but it's not long enough to do any serious hacking. I only ask because I can't remember seeing documentation only patches on wine-patches :) Luke.
Re: Documentation?
Would documentation-only patches be accepted? For example, I can use my lunch break at work to document functions but it's not long enough to do any serious hacking. I only ask because I can't remember seeing documentation only patches on wine-patches :) Indeed, yes. There have been some documentation only patches submitted and accepted once upon a time, but not in a while. --Juan
Re: Documentation?
On 03/12/2010 11:01 AM, André Hentschel wrote: Hi Folks, As we are getting somehow closer to Wine 1.2 i wonder how important updates on the Documentation are. Further i am confused about sending patches, should they just change the git-repo docs or the pages on the website or both? The website pages are supposed to be automatically generated from the docs every release. So patch the docs themselves. Not sure if this process still works though. Thanks, Scott Ritchie
Documentation?
Hi Folks, As we are getting somehow closer to Wine 1.2 i wonder how important updates on the Documentation are. Further i am confused about sending patches, should they just change the git-repo docs or the pages on the website or both? -- Best Regards, André Hentschel
TRACE () documentation
All: Is there documentation anywhere on how to use the TRACE command? I am trying to print out the contents of a UNICODE string using this commnd. Thank you. James McKenzie
Re: TRACE () documentation
On Thu, Jan 14, 2010 at 6:19 PM, James McKenzie jjmckenzi...@earthlink.net wrote: All: Is there documentation anywhere on how to use the TRACE command? I am trying to print out the contents of a UNICODE string using this commnd. Thank you. There are thousands and thousands of examples in the source already. wchar* unicode_str; or LPWSTR unicode_str; TRACE(%s\n, debugstr_w(unicode_str)); -- James Hawkins
Re: TRACE () documentation
James Hawkins wrote: On Thu, Jan 14, 2010 at 6:19 PM, James McKenzie jjmckenzi...@earthlink.net wrote: All: Is there documentation anywhere on how to use the TRACE command? I am trying to print out the contents of a UNICODE string using this commnd. Thank you. There are thousands and thousands of examples in the source already. wchar* unicode_str; or LPWSTR unicode_str; TRACE(%s\n, debugstr_w(unicode_str)); Duh I knew the answer was simple. I think this needs a page on the Wiki in the developer area. I just could not find an example in all of the TRACEs there Thank you James.
Re: TRACE () documentation
James McKenzie wrote: James Hawkins wrote: On Thu, Jan 14, 2010 at 6:19 PM, James McKenzie jjmckenzi...@earthlink.net wrote: All: Is there documentation anywhere on how to use the TRACE command? I am trying to print out the contents of a UNICODE string using this commnd. Thank you. There are thousands and thousands of examples in the source already. wchar* unicode_str; or LPWSTR unicode_str; TRACE(%s\n, debugstr_w(unicode_str)); Duh I knew the answer was simple. I think this needs a page on the Wiki in the developer area. I just could not find an example in all of the TRACEs there Thank you James. To be fair, it is mentioned at http://www.winehq.org/docs/winedev-guide/dbg-helpers though the given example is for FIXME, not TRACE. ~Nate
Re: TRACE () documentation
On 1/15/2010 05:31, James McKenzie wrote: James Hawkins wrote: On Thu, Jan 14, 2010 at 6:19 PM, James McKenzie jjmckenzi...@earthlink.net wrote: All: Is there documentation anywhere on how to use the TRACE command? I am trying to print out the contents of a UNICODE string using this commnd. Thank you. There are thousands and thousands of examples in the source already. wchar* unicode_str; or LPWSTR unicode_str; TRACE(%s\n, debugstr_w(unicode_str)); Duh I knew the answer was simple. I think this needs a page on the Wiki in the developer area. I just could not find an example in all of the TRACEs there Thank you James. http://www.winehq.org/docs/winedev-guide/dbg-helpers Last paragraph. No?
Re: TRACE () documentation
Nikolay Sivov wrote: On 1/15/2010 05:31, James McKenzie wrote: James Hawkins wrote: On Thu, Jan 14, 2010 at 6:19 PM, James McKenzie jjmckenzi...@earthlink.net wrote: All: Is there documentation anywhere on how to use the TRACE command? I am trying to print out the contents of a UNICODE string using this commnd. Thank you. There are thousands and thousands of examples in the source already. wchar* unicode_str; or LPWSTR unicode_str; TRACE(%s\n, debugstr_w(unicode_str)); Duh I knew the answer was simple. I think this needs a page on the Wiki in the developer area. I just could not find an example in all of the TRACEs there Thank you James. http://www.winehq.org/docs/winedev-guide/dbg-helpers Last paragraph. No? Yes, Nikolay. A search using TRACE of the entire Winehq site did not reveal this on the first page. I blame Google... James McKenzie
Documentation
I saw on http://www.winehq.org/status/wine That there Nonexistent documentation for Initial directory structure and Poor documentation for Initial INI files. So I wrote documentation for those on the wiki. http://wiki.winehq.org/Initial_directory_structure http://wiki.winehq.org/Initial_INI_files Hope I helped out, and this was useful. If so, it could be linked from the /status/wine article, and maybe move to /site/docs/winedev-guide/
Re: Documentation
2009/4/1 Fred . eldman...@gmail.com: I saw on http://www.winehq.org/status/wine That there Nonexistent documentation for Initial directory structure and Poor documentation for Initial INI files. So I wrote documentation for those on the wiki. http://wiki.winehq.org/Initial_directory_structure http://wiki.winehq.org/Initial_INI_files Wiki pages should be in CamelCase, not with underscores in the names. What you've got is a good start, but so far it's nothing that can't be determined from normal usage of Wine. What's needed from here is: 1) an explanation of why Wine creates INI files/this directory structure 2) what each of the INI files do, what the default contents of the directories are, why they're needed, what they do etc 3) Mention WINEPREFIX and make it more obvious where the default location of the wine directory is (perhaps this deserves another wiki page?) Hope I helped out, and this was useful. If so, it could be linked from the /status/wine article, and maybe move to /site/docs/winedev-guide/
[Wine Documentation] GDB Help
Hello Wine Developers, Besides the winedbg --gdb mode, I found a way to run gdb directly on wine. I figured all or part of this text file I'm included could be appended to section 1.8 of the Wine documentation where other debuggers are discussed. Thanks, Andrew Look This debugging document is meant to be appended to the Wine Developer's documentation, at: http://www.winehq.org/docs/winedev-guide/dbg-others 1.8.9 Using GDB to debug Wine tests From the wine build directory, GDB can be called in such a manner as to load wine's symbol table: cd wine64 gdb ./loader/wine-pthread At this point, breakpoints can be set in GDB on the wine source code files. However, breakpoints will be set on future loads of the source code file. (gdb) break sock.c:430 No source file named sock.c. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (sock.c:430) pending. Now, we can run the tests and have our breakpoint get loaded before execution. Using the 'run' command with the desired .exe file of our test will begin testing. (gdb) run ./dlls/ws2_32/tests/ws2_32_test.exe.so sock Starting program: /home/andrew/BRANCH_WINE/wine64/loader/ wine-pthread ./dlls/ws2_32/tests/ws2_32_test.exe.so sock [Thread debugging using libthread_db enabled] [New Thread 0x7f5b46eae6e0 (LWP 6229)] Could not load Mozilla. HTML rendering will be disabled. err:process:__wine_kernel_init boot event wait timed out sock.c:1820: Test failed: getsockopt should fail for UDP sockets but return value is 0x sock.c:2322: STARTING TEST 0 [New Thread 0x7f5b4456f950 (LWP 6255)] sock.c:409: simple_server (20) starting [New Thread 0x7f5b4445f950 (LWP 6256)] sock.c:597: simple_client (21): starting sock.c:418: simple_server (20) ready sock.c:600: simple_client (21): server ready [New Thread 0x7f5b4434f950 (LWP 6257)] sock.c:423: simple_server (20): waiting for client sock.c:597: simple_client (22): starting sock.c:600: simple_client (22): server ready sock.c:612: simple_client (21) connected [Switching to Thread 0x7f5b4456f950 (LWP 6255)] Now, all of the normal GDB commands can be called to help analyze the program execution. 'backtrace' is a good starting point to get an idea of the context under which we are executing. 'info threads' displays a representation of the current threads at this breakpoint. Breakpoint 1, simple_server (par=0x7f5b44bfdc48) at ../../../../wine-git/dlls/ws2_32/tests/sock.c:430 430 ok ( mem-sock[0].peer.sin_addr.s_addr == inet_addr ( gen-inet_addr ), (gdb) backtrace #0 simple_server (par=0x7f5b44bfdc48) at ../../../../ wine-git/dlls/ws2_32/tests/sock.c:430 #1 0x7f5b45f80a54 in call_thread_func (rtl_func=0x7f5b449f7510 simple_server, arg=0x7f5b44bfdc48) at ../../../wine-git/dlls/ntdll/thread.c:413 #2 0x7f5b45f80c00 in start_thread (info=value optimized out) at ../../../wine-git/dlls/ ntdll/thread.c:489 #3 0x7f5b467493ea in start_thread () from /lib/libpthread.so.0 #4 0x7f5b464b6cbd in clone () from /lib/libc.so.6 #5 0x in ?? () (gdb) info threads 4 Thread 0x7f5b4434f950 (LWP 6257) 0x7f5b4675024b in connect () from /lib/libpthread.so.0 3 Thread 0x7f5b4445f950 (LWP 6256) 0x7f5b4674ff4b in read () from /lib/libpthread.so.0 * 2 Thread 0x7f5b4456f950 (LWP 6255) simple_server (par=0x7f5b44bfdc48) at ../../../../wine-git/dlls/ ws2_32/tests/sock.c:430 1 Thread 0x7f5b46eae6e0 (LWP 6229) 0x7f5b4674ff4b in read () from /lib/libpthread.so.0 To inspect our current frame, 'info locals' displays local variables, 'info args' displays the values of all arguments with which the current function was called. In debugging Wine 64 particularly, I found 'info registers' to be particularly useful for a low level view of the execution.
Re: shell32: Make ILGetDisplayNameExA() static and fix its documentation.
Please don't apply. I should have removed the WINAPI when making the
function static. I'll resend a patch.
diff --git a/dlls/shell32/pidl.c b/dlls/shell32/pidl.c
index 5f26265..2792bc6 100644
--- a/dlls/shell32/pidl.c
+++ b/dlls/shell32/pidl.c
@@ -75,7 +75,7 @@ static LPWSTR _ILGetTextPointerW(LPCITEMIDLIST pidl);
* RETURNS
* True if the display name could be retrieved successfully, False otherwise
*/
-BOOL WINAPI ILGetDisplayNameExA(LPSHELLFOLDER psf, LPCITEMIDLIST pidl, LPSTR
path, DWORD type)
+static BOOL WINAPI ILGetDisplayNameExA(LPSHELLFOLDER psf, LPCITEMIDLIST
pidl, LPSTR path, DWORD type)
{
BOOL ret = FALSE;
WCHAR wPath[MAX_PATH];
--
Francois Gouget fgou...@free.fr http://fgouget.free.fr/
Broadcast message : fin du monde dans cinq minutes, repentez vous !
Re: Compiling WINE from source - Documentation needs to be updated?
2008/9/27 Dan Kegel [EMAIL PROTECTED]: And while we're on the subject, is make depend really needed anymore? I thought it happened automatically. It does. You don't generally need make install either, you can just run from whatever place you built Wine.
Re: Compiling WINE from source - Documentation needs to be updated?
On Sat, Sep 27, 2008 at 1:45 AM, Henri Verbeet [EMAIL PROTECTED] wrote: 2008/9/27 Dan Kegel [EMAIL PROTECTED]: And while we're on the subject, is make depend really needed anymore? I thought it happened automatically. It does. Great. So can we get rid of all the doc that tells people to make depend? You don't generally need make install either, you can just run from whatever place you built Wine. Yeah. (Except in a few situations... I think there are a few rough edges there that I run into when doing things like winegcc. I forget what, exactly.)
Re: Compiling WINE from source - Documentation needs to be updated?
Dan Kegel [EMAIL PROTECTED] writes: On Sat, Sep 27, 2008 at 1:45 AM, Henri Verbeet [EMAIL PROTECTED] wrote: 2008/9/27 Dan Kegel [EMAIL PROTECTED]: And while we're on the subject, is make depend really needed anymore? I thought it happened automatically. It does. Great. So can we get rid of all the doc that tells people to make depend? No, the automatic depend doesn't work with all make versions. -- Alexandre Julliard [EMAIL PROTECTED]
Compiling WINE from source - Documentation needs to be updated?
I see different advice on the best way to compile in various places. The http://www.winehq.org/site/docs/wineusr-guide/installing-wine-source user guide says to run: $ ./configure $ make depend $ make $ make install The README in the root of the source directory says to run: ./tools/wineinstall Which is the preferred method? Is there any difference? I'm thinking the docs in one of those two places probably needs to be updated. -- View this message in context: http://www.nabble.com/Compiling-WINE-from-source---Documentation-needs-to-be-updated--tp19694643p19694643.html Sent from the Wine - Devel mailing list archive at Nabble.com.
re: Compiling WINE from source - Documentation needs to be updated?
And while we're on the subject, is make depend really needed anymore? I thought it happened automatically.
Re: gdiplus: Add some documentation stubs to make winapicheck happy.
Francois Gouget wrote: +/* + * GdipSetEmptye [EMAIL PROTECTED] + */ Typo here.
Re: [PATCH] ntdll: use symbols, add documentation for i386 page faulterror code
John Reiser [EMAIL PROTECTED] wrote: diff --git a/include/winnt.h b/include/winnt.h index e8a37f5..ad2f674 100644 --- a/include/winnt.h +++ b/include/winnt.h @@ -812,9 +812,24 @@ typedef struct _CONTEXT86 typedef CONTEXT86 CONTEXT; -#define EXCEPTION_READ_FAULT0 -#define EXCEPTION_WRITE_FAULT 1 -#define EXCEPTION_EXECUTE_FAULT 8 +/* Page Fault Error Code. + * Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3A: + * System Programming Guide, Part 1; Figure 5-9, Page-Fault Error Code, p.5-55. + * http://www.intel.com/design/processor/manuals/253668.pdf + * linux/arch/x86/mm/fault.c do_page_fault() + */ +/* This hardware bit is ignored by shifting it off the bottom. + *#define EXCEPTION_PAGE_NOT_P (00) + *#define EXCEPTION_PROT_VIOL (10) + * + * Hardware delivers these bits [below] one position to the left. + */ +#define EXCEPTION_READ_FAULT(00) +#define EXCEPTION_WRITE_FAULT (10) /* 1 */ +#define EXCEPTION_KERNEL_MODE (01) +#define EXCEPTION_USER_MODE (11) /* 2 */ +#define EXCEPTION_RSV_PAGETAB (12) /* 4 */ +#define EXCEPTION_EXECUTE_FAULT (13) /* 8 */ These changes are not compatible with PSDK. -- Dmitry.
Re: [PATCH] ntdll: use symbols, add documentation for i386 page faulterror code
John Reiser [EMAIL PROTECTED] wrote: These changes are not compatible with PSDK. Which PSDK is that, and what are the error messages? I'm using Software Development Kit Update for Windows Vista. The numerical values are identical, and the new names are the ones used by the hardware documentation. The problem is that you are introducing things not existing in PSDK. -- Dmitry.
Re: Documentation updating / XML?
On Tue, 22 Apr 2008, Austin English wrote: [...] On Tue, Apr 22, 2008 at 5:25 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: Austin English [EMAIL PROTECTED] writes: I've been working on some of the documentation, then remembered that Scott requested a move to XML: http://bugs.winehq.org/show_bug.cgi?id=12217 There are quite a few programs to convert SGML to XML, and I've got a bit of time to kill. Alexandre, would you accept a move to XML, or would this be a waste of time? [...] Web/html/PDF/XML? I would vote for DocBook XML so we can get Html and PDF documents out of it. Also now po4a works quite well with it. I could give you a hand on the po4a part. However I'd say that there are some subtle but important differences between DocBook SGML and DocBook XML, especially around the include mechanism. So I'm a bit skeptical that automated tools can really produce clean DocBook XML code. But then they can probably be a good starting point. It would also be nice if we could switch to a Git repository. Since it's not possible with SourceForge it would mean moving elsewhere. Would it be possible to have get it hosted on winehq.org? -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong
Re: Documentation updating / XML?
Austin English [EMAIL PROTECTED] writes: I've been working on some of the documentation, then remembered that Scott requested a move to XML: http://bugs.winehq.org/show_bug.cgi?id=12217 There are quite a few programs to convert SGML to XML, and I've got a bit of time to kill. Alexandre, would you accept a move to XML, or would this be a waste of time? I don't really care about the format as long as there are decent tools to generate all the outputs we want. Considering the state of SGML tools it's probably not hard to do better... -- Alexandre Julliard [EMAIL PROTECTED]
Re: Documentation updating / XML?
On Tue, Apr 22, 2008 at 5:25 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: Austin English [EMAIL PROTECTED] writes: I've been working on some of the documentation, then remembered that Scott requested a move to XML: http://bugs.winehq.org/show_bug.cgi?id=12217 There are quite a few programs to convert SGML to XML, and I've got a bit of time to kill. Alexandre, would you accept a move to XML, or would this be a waste of time? I don't really care about the format as long as there are decent tools to generate all the outputs we want. Considering the state of SGML tools it's probably not hard to do better... -- Alexandre Julliard [EMAIL PROTECTED] Web/html/PDF/XML?
Documentation updating / XML?
I've been working on some of the documentation, then remembered that Scott requested a move to XML: http://bugs.winehq.org/show_bug.cgi?id=12217 There are quite a few programs to convert SGML to XML, and I've got a bit of time to kill. Alexandre, would you accept a move to XML, or would this be a waste of time? -Austin
Re: AVI file format documentation
While we are on the subject of AVI files: could someone please take a look at the function IAVIStream_fnWriteData() in avifil32/avifile.c? There is an unused variable dwPos (line 1326), which has been there since this function was first implemented (2002-10-18), I could just remove this variable, but I think the calculation of available space may be incorrect anyway. Comments please! Thanks, -- Andy.
Re: AVI file format documentation
Dan Kegel [EMAIL PROTECTED] wrote: Maarten stumbled across what he said was very useful documentation about the AVI file format. For future reference, here it is: http://sunsson.iptime.org/projects/juliet/wiki/MediaFileFormat AVI files are just RIFF files, and RIFF file format is very well documented, and should be well supported in Wine: mmioOpen, mmioDescend, etc. Both dlls/mciavi32 and dlls/avifil32 are able to parse and play AVI files. -- Dmitry.
Re: AVI file format documentation
Hello Dmitry, 2008/4/11, Dmitry Timoshkov [EMAIL PROTECTED]: Dan Kegel [EMAIL PROTECTED] wrote: Maarten stumbled across what he said was very useful documentation about the AVI file format. For future reference, here it is: http://sunsson.iptime.org/projects/juliet/wiki/MediaFileFormat AVI files are just RIFF files, and RIFF file format is very well documented, and should be well supported in Wine: mmioOpen, mmioDescend, etc. Both dlls/mciavi32 and dlls/avifil32 are able to parse and play AVI files. I don't think I can use that from quartz though. It uses the asyncreader primitives and I don't believe there is such thing as a IRiffReader interface. ;-) Also, I don't think avifill and mciavi currently support seeking, that is very important as well. Cheers, Maarten.
Re: AVI file format documentation
Maarten Lankhorst [EMAIL PROTECTED] wrote: Both dlls/mciavi32 and dlls/avifil32 are able to parse and play AVI files. I don't think I can use that from quartz though. It uses the asyncreader primitives and I don't believe there is such thing as a IRiffReader interface. ;-) There is no such a thing as IRiffReader interface at all. Also, I don't think avifill and mciavi currently support seeking, that is very important as well. That depends on what you mean by seeking. If that's what commonly used for moving from one frame to another, or from one position in stream to another there is nothing magic to implement. -- Dmitry.
AVI file format documentation
Maarten stumbled across what he said was very useful documentation about the AVI file format. For future reference, here it is: http://sunsson.iptime.org/projects/juliet/wiki/MediaFileFormat
Re: AVI file format documentation
On Thu, Apr 10, 2008 at 11:42 AM, Dan Kegel [EMAIL PROTECTED] wrote: Maarten stumbled across what he said was very useful documentation about the AVI file format. For future reference, here it is: http://sunsson.iptime.org/projects/juliet/wiki/MediaFileFormat Sorry for the spam, but here's one more document he found that deals with really big avi files: http://the-labs.com/Video/odmlff2-avidef.pdf - Dan
Re: Documentation is still in CVS?
On Fri, Apr 4, 2008 at 8:35 AM, Hin-Tak Leung [EMAIL PROTECTED] wrote: Doesn't work for me: $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/wine co -P docs cvs [checkout aborted]: connect to [wine.cvs.sourceforge.net]:2401 failed: Connection timed out $ git cvsimport -C wine-doc -v -k -d :pserver:[EMAIL PROTECTED]:/cvsroot/wine docs Socket to wine.cvs.sourceforge.net: Connection timed out I'll need to try stunnel and see if it improves things. (but I can still check out stuff from other sourceforge projects...) Firewall issue on your side? Can you ping wine.cvs.sourceforge.net? Connect to it on port 80? or port 2401?
Re: Documentation is still in CVS?
--- On Thu, 3/4/08, Lei Zhang [EMAIL PROTECTED] wrote: snipped The instructions on http://www.winehq.org/site/cvs works for me. Doesn't work for me: $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/wine co -P docs cvs [checkout aborted]: connect to [wine.cvs.sourceforge.net]:2401 failed: Connection timed out $ git cvsimport -C wine-doc -v -k -d :pserver:[EMAIL PROTECTED]:/cvsroot/wine docs Socket to wine.cvs.sourceforge.net: Connection timed out I'll need to try stunnel and see if it improves things. (but I can still check out stuff from other sourceforge projects...) ___ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/
Re: Documentation is still in CVS?
--- On Fri, 4/4/08, Lei Zhang [EMAIL PROTECTED] wrote: From: Lei Zhang [EMAIL PROTECTED] Subject: Re: Documentation is still in CVS? To: Hin-Tak Leung [EMAIL PROTECTED] Cc: Wine Devel wine-devel@winehq.org Date: Friday, 4 April, 2008, 6:50 PM On Fri, Apr 4, 2008 at 8:35 AM, Hin-Tak Leung [EMAIL PROTECTED] wrote: Doesn't work for me: $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/wine co -P docs cvs [checkout aborted]: connect to [wine.cvs.sourceforge.net]:2401 failed: Connection timed out $ git cvsimport -C wine-doc -v -k -d :pserver:[EMAIL PROTECTED]:/cvsroot/wine docs Socket to wine.cvs.sourceforge.net: Connection timed out I'll need to try stunnel and see if it improves things. (but I can still check out stuff from other sourceforge projects...) Firewall issue on your side? Can you ping wine.cvs.sourceforge.net? Connect to it on port 80? or port 2401? Can do port 80, can't do port 2401. Wierd. It is probably problem in my end. ___ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/
Documentation is still in CVS?
Hi, Is there a reason why the Wine documentation is still in CVS, and not in GIT? - Lei
Re: Documentation is still in CVS?
On Thu, 2008-04-03 at 10:37 -0700, Lei Zhang wrote: Is there a reason why the Wine documentation is still in CVS, and not in GIT? Yes. The docs are now maintained at SourceForge, and given the glacial pace of updates, there is little reason to move them to git. Moreover, git presents a much higher barrier to entry, and there's no reason to raise it for (potentially non-technical) documentation contributors. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: Documentation is still in CVS?
--- On Thu, 3/4/08, Dimi Paun [EMAIL PROTECTED] wrote: From: Dimi Paun [EMAIL PROTECTED] Subject: Re: Documentation is still in CVS? To: Wine Devel wine-devel@winehq.org Date: Thursday, 3 April, 2008, 6:50 PM On Thu, 2008-04-03 at 10:37 -0700, Lei Zhang wrote: Is there a reason why the Wine documentation is still in CVS, and not in GIT? Yes. The docs are now maintained at SourceForge, and given the glacial pace of updates, there is little reason to move them to git. Moreover, git presents a much higher barrier to entry, and there's no reason to raise it for (potentially non-technical) documentation contributors. Actually I tried to follow the wiki instructions to do a git-cvsimport and it didn't work a week or two ago; and plain cvs co did not work either. I have a few other stuff on sourceforge, so the problem seems to be specific to wine. Does anonymous check out work for anybody else? __ Sent from Yahoo! Mail. A Smarter Inbox http://uk.docs.yahoo.com/nowyoucan.html
Re: Documentation is still in CVS?
On Thu, Apr 3, 2008 at 11:29 AM, Hin-Tak Leung [EMAIL PROTECTED] wrote: Actually I tried to follow the wiki instructions to do a git-cvsimport and it didn't work a week or two ago; and plain cvs co did not work either. I have a few other stuff on sourceforge, so the problem seems to be specific to wine. Does anonymous check out work for anybody else? The instructions on http://www.winehq.org/site/cvs works for me.
New DLL, Server and Service Documentation
Howdy All, This autumn I began learning both Wine and COM. A combination of limited documentation and trouble finding the right example code for my task at hand made this a difficult process. In an attempt to help other new Wine and COM developers I wrote a tutorial on COM development the Wine way. This tutorial describes: - A simple DLL providing a in-process COM object - A simple server providing a local COM object - A simple service that publishes a COM object and the corresponding proxy / stub required to use the service with instructions on Wine integration and, for Windows users or testers building for Windows, basic instructions on building and running these same applications in Windows. The tutorial is available at: http://ambleramble.org/wine/ I hope other developers enjoy this documentation. If you see mistakes, either minor typos or conceptual problems, please drop me an email and I'll clean up the docs. Peace, -Roy
Re: New DLL, Server and Service Documentation
Am Donnerstag, 1. November 2007 08:00:36 schrieb Roy Shea: Howdy All, This autumn I began learning both Wine and COM. A combination of limited documentation and trouble finding the right example code for my task at hand made this a difficult process. In an attempt to help other new Wine and COM developers I wrote a tutorial on COM development the Wine way. This tutorial describes: This should propably be linked from the wiki. Which would be the right place for that? signature.asc Description: This is a digitally signed message part.
Re: [wintrust] Add some documentation
On 8/29/06, Paul Vriens [EMAIL PROTECTED] wrote: Hi, I thought I'd start with some documentation. The tests are already there so what's missing is the implementation :-). /*** * WintrustAddActionID (WINTRUST.@) + * + * Add a Trust provider. Or actually the functions it performs. + * Can you rewrite this sentence? It's not grammatically correct, and I don't understand what you're saying. -- James Hawkins
Re: [wintrust] Add some documentation
On Tue, 2006-08-29 at 09:38 -0700, James Hawkins wrote: On 8/29/06, Paul Vriens [EMAIL PROTECTED] wrote: Hi, I thought I'd start with some documentation. The tests are already there so what's missing is the implementation :-). /*** * WintrustAddActionID (WINTRUST.@) + * + * Add a Trust provider. Or actually the functions it performs. + * Can you rewrite this sentence? It's not grammatically correct, and I don't understand what you're saying. Hi, something like this: * Add a Trust provider. Part of the Trust provider is the definition of * the actions it can perform. WintrustAddActionID add these definitions * to the registry. Paul.
Re: [wintrust] Add some documentation
On 8/29/06, Paul Vriens [EMAIL PROTECTED] wrote: On Tue, 2006-08-29 at 09:38 -0700, James Hawkins wrote: On 8/29/06, Paul Vriens [EMAIL PROTECTED] wrote: Hi, I thought I'd start with some documentation. The tests are already there so what's missing is the implementation :-). /*** * WintrustAddActionID (WINTRUST.@) + * + * Add a Trust provider. Or actually the functions it performs. + * Can you rewrite this sentence? It's not grammatically correct, and I don't understand what you're saying. Hi, something like this: * Add a Trust provider. Part of the Trust provider is the definition of * the actions it can perform. WintrustAddActionID add these definitions * to the registry. I wouldn't describe the Trust provider concept in an API documentation, we only need to document what action the function performs. Something along these lines would work: Add a Trust provider and the definition of the actions it can perform to the registry. I'm not familiar enough with wintrust to make this clear, but you get the idea. -- James Hawkins
Re: How are we doing? (documentation + regression tests)
Am Freitag, den 02.06.2006, 08:03 -0500 schrieb Jeremy White: But there are plenty of places in Wine where the code does something screwball or out of the ordinary (hell, the API itself is screwball), and those places deserve more comments. IMHO, more comment's help to teach someone, who read the code, what a Function does. Many of my Patches add the missing WineAPI - Documentation, but the overall API Documentation - Status is still to low. We can of course add the same Type of documentation for internal Functions. Example: http://source.winehq.org/source/dlls/winspool.drv/info.c#L214 Another big Place to teach someone what a Function does, are the regression tests. We are missing a lot of tests. Example: After a comment by Alexandre about my recent patch, i read again our WineAPI-Guide and MSDN. Both document's say the same, but our implementation is different. The affected Function is called only 3 times in our regression tests (WideCharToMultiByte). -- By By ... ... Detlef
