Re: Wine release 1.4-rc1
Alexandre: Congratulations to the Wine Team. Now to beat on it... James On Fri, Jan 27, 2012 at 12:58 PM, Alexandre Julliard wrote: > The Wine development release 1.4-rc1 is now available. > -- > Alexandre Julliard > julli...@winehq.org >
Re: w9x testbot state?
On 8/7/11 6:55 AM, Dmitry Timoshkov wrote: James McKenzie wrote: There are functions that vary between Windows9x/ME and WindowsNT and their ilk. People do use Wine to support Windows9x/ME programs that are not supported, anymore, by current Windows. When we make changes to functionality, it is a 'good thing' to make sure we don't break support for those folks, right? Supporting applications from a win9x era has nothing to do with running Wine tests on win9x platforms. Dmitry: That is correct. The two are distinctly different and no further reports of running compliance tests against Windows9x should be recorded. However, insuring what functionality we do have in Wine for running antiquated Windows9x/ME programs should remain, if possible, IMHO. However, there was a purpose of running Wine code against the testbots as well I thought. I've seen many patches run against them to add functionality and to insure nothing broke, not just running the old win9x tests. Or am I incorrect in their usage. As stated: They are off-line for now. And Maarten stated that they would be restored, if the images could be found. Otherwise, they are off-line and will remain that way for a long time. James
Re: w9x testbot state?
On 8/7/11 1:01 AM, Dmitry Timoshkov wrote: James McKenzie wrote: what happened to the w9x test bots? I'd like them to run some kernel32 tests. Testbot says "offline". They were hosted at Gé's house. Testbot can no longer reach them. Are there plans to 'revive' them? There is no point in that, it's been discussed many times already. There are functions that vary between Windows9x/ME and WindowsNT and their ilk. People do use Wine to support Windows9x/ME programs that are not supported, anymore, by current Windows. When we make changes to functionality, it is a 'good thing' to make sure we don't break support for those folks, right? It is not necessary, anymore, to do 'compatibility' tests against 9x as most functions from that time period should be fully implemented. That is my 'read' of what Alexandre said here about six months ago. James
Re: w9x testbot state?
On 8/3/11 7:10 AM, Maarten Lankhorst wrote: On 08/01/2011 07:12 PM, joerg-cyril.hoe...@t-systems.com wrote: Hi, what happened to the w9x test bots? I'd like them to run some kernel32 tests. Testbot says "offline". They were hosted at Gé's house. Testbot can no longer reach them. Are there plans to 'revive' them? If not, if I am provided with a test file, I do have a Windows98SE disk here that I could run tests against. This would be a manual process and would take time. James
Re: Assorted spelling fixes.
On 8/3/11 4:23 PM, Francois Gouget wrote: On Wed, 3 Aug 2011, Frédéric Delanoy wrote: [...] -rem Removing non-existent directory +rem Removing nonexistent directory [...] There is apparently no hard rule on the usage of hypens between 'non' and a subsequent adjective, but I've seen lots of "non-" (sometimes even "non ") so I wouldn't call that a spelling error. Furthermore, the "non-" form is more readable IMHO My paper dictionary lists a number of 'non-xxx' and 'nonxxx' words. It has 'nonexistent' and not 'non-existent'. The Merriam-Webster also prefers 'nonexistent'. http://www.merriam-webster.com/dictionary/nonexistent Mozilla did a pass through their code replacing 'onn-existent' with 'nonexistent': https://bugzilla.mozilla.org/show_bug.cgi?id=564091 However I'll acknowledge that a number of other online dictionaries seem to accept both forms. Maybe the explanation is in the Cambridge Dictionaries; they have 'non-existent' in the British dictionary and 'nonexistent' in the US one. http://dictionary.cambridge.org/dictionary/british/non-existent http://dictionaries.cambridge.org/define.asp?key=nonexistent*1+0&dict=A http://www.thefreedictionary.com/nonexistent http://www.thefreedictionary.com/non-existent http://dictionary.reference.com/browse/nonexistent http://dictionary.reference.com/browse/non-existent Overall 'nonexistent' seemed better referenced in the dictionaries and more 'legitimate'. But I can leave either form as is if that's preferred. Francois: I always thought that it was hyphenated. Ran the word through the spell checker on MS Word this afternoon and both spellings were accepted. Alexandre will have to be the final say so on this as both spellings are accepted. James
Re: Statur of DIB Engine
On 7/24/11 10:14 AM, Massimo Del Fedele wrote: Yep, true Autocad would gain benefit just with fonts. If fonts are not implemented, that's useless by now. Max: It might be worthwhile to rebase your code on the fixes inputted by Huw so that your patches continue to work until Huw finishes his work. It would give you a good start if Huw decides that your code is better than his! James
Re: urlmon: Fix various typos/misspellings
On 7/23/11 12:29 AM, Austin English wrote: 2011/7/23 Frédéric Delanoy: On Sat, Jul 23, 2011 at 02:03, Andrew Eikum wrote: On 07/22/2011 06:49 PM, Frédéric Delanoy wrote: 2011/7/22 Dan Kegel: -/* List of 3 character top level domain names Windows seems to recognize. +/* List of 3 characters top level domain names Windows seems to recognize. That change is incorrect. In English, 'character' should be singular there. (This occurs twice in your patch.) Interesting. Could you pls give me pointers explaining this peculiar English grammar rule? A "number-noun" adjective does not use the noun's plural form. Other examples are "four-wheel drive," "seven-day trip" and "three-lane highway." I think they're easier to read with hyphens, but it's really a matter of preference. This is the best reference I could find: http://www.grammar-quizzes.com/adjective.html Andrew OK thx. Guess there's a "-" missing as well. Frédéric It's optional, but does make it a bit clearer to non-native English speakers. s/seams/seems/g... James
Re: urlmon: Fix various typos/misspellings
On 7/23/11 12:07 AM, Frédéric Delanoy wrote: On Sat, Jul 23, 2011 at 02:03, Andrew Eikum wrote: On 07/22/2011 06:49 PM, Frédéric Delanoy wrote: 2011/7/22 Dan Kegel: -/* List of 3 character top level domain names Windows seems to recognize. +/* List of 3 characters top level domain names Windows seems to recognize. That change is incorrect. In English, 'character' should be singular there. (This occurs twice in your patch.) Interesting. Could you pls give me pointers explaining this peculiar English grammar rule? A "number-noun" adjective does not use the noun's plural form. Other examples are "four-wheel drive," "seven-day trip" and "three-lane highway." I think they're easier to read with hyphens, but it's really a matter of preference. This is the best reference I could find: http://www.grammar-quizzes.com/adjective.html Andrew OK thx. Guess there's a "-" missing as well. Actually, if we could get away with it, the correct (grammar wise, not Windows wise is): List of three-character top-level domain names Windows seams to recognize. But I'm not doing the change and I don't know if this is something that AJ would approve anyway. James
Re: [docs] winedev: Update code columns limit (resend)
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
Re: Glitch-free iTunes?
On 7/4/11 7:50 PM, Keith Curtis wrote: None of the Linux kernel developers are paid by Linus nor can be fired by him. Linus never forces people to respond to his mails or to work on anything. What has happened is that the team has realized that having goals and leadership has led to good results, and Linus is a good leader, and so they follow along. If Linus says something needs to be worked on, it happens. The rest of the people keep doing their own work. I think you missed my point. There is a 'leader' for Linux and that person just happens to be Linus. Whether or not he wants that position is pointless. He has it. Linux is and will remain his 'baby'. There is NO such person, that I'm aware of for Wine. Thus if I happen to 'need' to have a few functions in Wine I have two options: 1. File a bug report, categorize it, define it and then hope that someone has the skills and desire to fix the problem I've identified. 2. File a bug report, categorize it, define it and then fix it myself. I have two bug reports that I have worked on and now I'm working on code to bring those functions into Wine, with assistance from other Wine developers to insure that my code is high enough quality and is implemented properly. You have the same options as does everyone else. And yes, if you look through Wine's bugzilla you will see very old bugs (that is why I mentioned the DIB Engine, it is bug 421 and is almost ten years old) to bugs filed yesterday. All need love and attention. Some bug reports were opened only to be closed when this did not happen. Also, remember what is important to you may not be so for the entire project. That is why I'm working on code. Those functions are important to me, but to the overall project no so. There is one other difference between the LKM project and Wine. The Linux Kernel is essential to the functioning of Linux. Wine is only essential to getting well-behaved Windows programs to run on Linux/UNIX. There are some programs that started the project, many years ago, that are no longer available or now have Linux/UNIX equivalents. James
Re: Glitch-free iTunes?
On 7/2/11 7:49 PM, Keith Curtis wrote: So: yeah, we know it's an important app. But it's hard. Feel free to help out. - Dan Hi; I am glad to hear you say that iTunes is an "important" app, but I don't understand what you mean because it has never worked. You don't need my help. You've got a big group making many good fixes. It is just that priority is being ignored or something. Failure is not from lack of effort, but from planning. Keith: Maybe you missed Dan's point. iTunes, for a while, did work. Most of the work to get it to work has been by volunteers and it remains up to the volunteer side of the project to 'make it so'. Syncing an iPod did work as far as I knew using the USB device patches. Also, this is, mainly, an all-volunteer effort. I, for instance, picked up three richedit functions that are very near and dear to the functioning of several programs that I use. There is a long known work-around, but I would like to see appropriate code included in the Wine project so that the work-around is no longer needed. iTunes on the Linux platform may or may not be forthcoming. Making iTunes work on any flavor/distribution of Linux might take a very interested and talented user with programming skills in 'c' to generate the code and get appropriate fixes made in the Wine code. Attempts have been made and some successes gained, but more needs to be done and mostly by a small staff of volunteers. Project priorities might say 'make this work' but without appropriately interested and skilled volunteers, iTunes might not be working under Linux anytime soon. James McKenzie
Re: Ge (Greg) van Geldorp
On 6/11/11 6:18 AM, Scott Ritchie wrote: In tragic irony, I'm dealing with a father dying of very late stage cancer at the moment, so forgive me if I'm slow for a bit. First, how sad to read this about your father. Hopefully, he is receiving the best of care and is in little or no pain. Second, thank you for taking over the testbot (or at least appearing to do so, my apologies if this is incorrect.) It will take more than one person to fill Ge's shoes for providing the testbot system and for his actions to get our efforts recognized in the Virtual community. Very respectfully, James McKenzie
Re: Ge (Greg) van Geldorp
On 6/10/11 2:59 PM, Austin English wrote: On Fri, Jun 10, 2011 at 16:37, Wolfram Sang wrote: The sad news reached me two days ago that Ge (Greg) van Geldorp passed away. Please find below the mail from his brother. This is sad news indeed. The testbot he created is tremendously useful and a great achievement. He also was always helpful and nice when I asked him about it. His presence will be missed, yet he will be remembered. Condolences to his family and friends. My condolences to his family and friends as well. His contributions were greatly appreciated and won't be forgotten. As a more permanent memorial, perhaps we could dedicate the next (stable) Wine release to his memory. Ge's efforts with VMWare got all of the Wine Developers access for no cost to VMWare Fusion and his construction and maintenance of the Testbot system are appreciated by all the developers who use it. Without it, we would not be where we are today in the level and depth of Wine development and conformance testing. My condolences to his family, his friends and those in the Wine community that met him, either in person or 'over the wire'. His presence here will be missed and is one to be emulated. James McKenzie
Re: bug in GetUserNameW error return values
On 5/30/11 11:52 AM, Kevin Hendricks wrote:
Hi,
There is a small bug in the wine implementation of GetUserNameW (and the same
fix is needed in GetUserNameA).
From:
dlls/advapi32/advapi.c starting at line 92
if (len> *lpSize)
{
SetLastError(ERROR_MORE_DATA);
*lpSize = len;
return FALSE;
}
It seems the actual GetUserNameW returns 122 not 234 which maps to
ERROR_INSUFFICIENT_BUFFER and not ERROR_MORE_DATA
File a bug report with all of these details. Developers do not work
bugs from the mailing list.
James McKenzie
Re: NTDLL doesn't compile under Clang
On 5/29/11 11:43 AM, Charles Davis wrote:
On 5/29/11 12:41 PM, C.W. Betts wrote:
When compiling the NTDLL component of Wine, I get the following error:
../../../wine-git/./dlls/ntdll/large_int.c:267:13: error: unknown use of
instruction mnemonic without a size suffix
__asm__("div %4,%%eax"
^
:1:2: note: instantiated into assembly here
div 12(%esp),%eax
^
I'm using Clang 2.0 from Xcode 4.0
That's a Clang bug that's already been fixed. Sadly, it didn't make it
into Xcode 4.0.
Any hope of it making it into a up release of XCode? Don't like running
into upstream fixed bugs in a .0 release product. :(
James McKenzie
Re: Big ugly build changes might be needed for Debian/Ubuntu
On 5/21/11 11:51 PM, Marcus Meissner wrote: On Sat, May 21, 2011 at 05:57:40PM -0700, James McKenzie wrote: On 5/19/11 1:51 PM, Marcus Meissner wrote: It is trivial. You basically build wine twice, once in the 32bit environment and once inthe 64bit one. Maybe Wine can look into some sort of merge process to build both and at runtime select one or the other? I don't know if this is possible, I'm just 'throwing the idea out there'. Not sure what you mean. If you install 64 bit wine + 32bit stuff I listed, you will have a 64+32 bit capable wine setup. That was the answer I was looking for. Thank you, Marcus. The ability is already there. So, if I install 64 bit wine on a 64 bit machine it should work something like what Windows does now, one directory (wineprefix) for 64 bitness and one directory (wineprefix) for 32 bitness. James McKenzie
Re: Big ugly build changes might be needed for Debian/Ubuntu
On 5/19/11 1:51 PM, Marcus Meissner wrote: It is trivial. You basically build wine twice, once in the 32bit environment and once inthe 64bit one. Maybe Wine can look into some sort of merge process to build both and at runtime select one or the other? I don't know if this is possible, I'm just 'throwing the idea out there'. James McKenzie
Re: Big ugly build changes might be needed for Debian/Ubuntu
On 5/19/11 1:51 PM, Marcus Meissner wrote: It is trivial. You basically build wine twice, once in the 32bit environment and once inthe 64bit one. Maybe Wine can look into some sort of merge process to build both and at runtime select one or the other? I don't know if this is possible, I'm just 'throwing the idea out there'. James McKenzie
Re: riched20:tests Add conformance test for EM_FINDWORDBREAK function.
On 5/8/11 3:18 AM, André Hentschel wrote:
Am 08.05.2011 05:14, schrieb James McKenzie:
+ if (winetest_debug> 1) {
test_WM_CHAR();
test_EM_FINDTEXT();
test_EM_GETLINE();
@@ -7090,6 +7368,8 @@ START_TEST( editor )
test_WM_GETDLGCODE();
test_zoom();
test_dialogmode();
+ }
+ test_EM_FINDWORDBREAK();
Hi,
i guess you didn't meant to include that in your patch.
Resending. Thanks for catching that from my tests.
James McKenzie
Re: Huge frustration
On 5/7/11 3:52 AM, Roland Kaeser wrote: Hello Please take the following not personal but the huge pent-up frustration constrains me to say a few words. I've just tested one of my "longest waiting" apps to get working on linux: CorelDraw X3/X4. And I had to see that it fails already with the same errors. I tooke a short look into the bug database to see all the related bugs: http://bugs.winehq.org/show_bug.cgi?id=11687open (not even confirmed) since more than 3 years http://bugs.winehq.org/show_bug.cgi?id=14123open since 2008-06-25 http://bugs.winehq.org/show_bug.cgi?id=3599 open (new) since 2005-10-15 http://bugs.winehq.org/show_bug.cgi?id=3611 open (new) since 2005-10-17 I know we had this discussion already a lot of times but after six acc. Many bug fixes depend on fixing a six year old + bug (421). However, if you feel so strongly, then maybe YOU can take a stab at trying to fix a bug. It is NOT easy (6724 is one bug that I'm working on and it has been around for four+ years.) Also, not all developers are working on fixing and improving DirectX. Some are working on code improvements and long overdue code cleanups. James McKenzie
Question on Conformance Test
All: I am writing a conformance test for the richedit function EM_FINDWORDBREAK. I realize that WindowsNT 4.0 is our base configuration and most of the values process the same. However, a couple of values process differently for Windows NT 4.0/Windows2000, WindowsXP/Windows2003 and Windows Vista onward. What would be the BEST method of annotating this: Per the development guide: ok ( GetLastError() == WINXP_ERROR || GetLastError() == WINNT40_ERROR, ...); or: ok ( GetLastError() == WINXP_ERROR || Broken (GetLastError() == WINNT40_ERROR)); In other words, should I avoid the use of Broken() in this case, as the returned value is correct? Thank you. James McKenzie
Re: Google Summer of Code 2011 is on!
On 4/25/11 4:02 PM, Austin English wrote: We've got five projects this year: Jay Yang - Implement the Explorer - http://socghop.appspot.com/gsoc/project/google/gsoc2011/yangjay/8001 Lucas Fialho Zawacki - Implementation of DirectInput8 Action Mapping feature - http://socghop.appspot.com/gsoc/project/google/gsoc2011/lfzawacki/8001 Michael Mc Donnell - Implement Missing Mesh Functions in Wine’s D3DX9 - http://socghop.appspot.com/gsoc/project/google/gsoc2011/mmd/9001 Michal Zietek - Implementing WScript API - http://socghop.appspot.com/gsoc/project/google/gsoc2011/misiek/6001 Pluciński Mariusz - Extending gameux.dll by Games Explorer Shell Extension - http://socghop.appspot.com/gsoc/project/google/gsoc2011/vshader/29001 Congrats everyone! Now get coding :-). Looks like we have a few folks returning this year. Keep up the good work they started last year! James McKenzie
Re: Getting symbol names and ordinal numbers from Windows DLLs for Wine DLLs
On 4/17/11 8:39 AM, Juan Lang wrote: I think it's not allowed to do a "winedump.lib" Or is this ok? Yes, this is allowed. I would have asked the same question. However, is it not best to search first and then do the dump? James McKenzie
Re: Try to implement my first stub function - AbortPrinter() - (try 3)
On 4/8/11 5:54 AM, Loïc Maury wrote: Hello, I try always to implement my first stub function - AbortPrinter. One nice comment here, very efficient use of the local label end. James McKenzie
Re: [1/2] winefile: Remove unimplemented menu entries.
On Wed, Mar 30, 2011 at 7:46 AM, Francois Gouget wrote: > They unnecessarily clutter the GUI and are unlikely to ever be implemented. > --- > > As discussed on wine-devel. > I still left Rename and Create Directory because they are basic > functions that should really be there (but I won't implement them). Thank you Francois. These should only be brought back with a full implementation of the underlying code, if it is really needed. James McKenzie
Re: RFC: Remove unimplemented application menus?
On 3/28/11 7:23 PM, Austin English wrote: On Tue, Mar 29, 2011 at 03:20, James McKenzie wrote: On 3/28/11 7:19 PM, Austin English wrote: On Tue, Mar 29, 2011 at 03:17, James McKenzie wrote: On 3/28/11 7:15 PM, Austin English wrote: 2011/3/29 James McKenzie: On 3/28/11 9:28 AM, André Hentschel wrote: Am 28.03.2011 17:27, schrieb James McKenzie: 2011/3/27 André Hentschel: Am 27.03.2011 13:50, schrieb Francois Gouget: Some Wine programs, winefile in particular, have a lot of unimplemented menus. That is you can see the menu entry but clicking on it only gives you a 'Not yet implemented' error dialog (or does nothing in the case of iexplore). For instance just for the first two winefile menus none of the following are implemented: File ->Print... File ->Associate... File ->Search... File ->Select Files... Disk ->Share as... Disk ->Remove Share... Disk ->Select Drive... I think such a situation is bad: * Having tons of unimplemented menus looks amateurish. * It's very confusing. You see tons of menus except over 50% of them don't work. So it makes the GUI more complex with no benefit. * I suspect most of these menus have been unimplemented for years so there is little hope of seeing them improve any time soon. * For a number of them it's questionable whether it makes sense to implement them in Wine at all as they correspond to tasks that better belong to the native system facilities (Share as for instance). * I doubt they serve any significant compatibility purpose. * In the mean time they generate more work for translators and translation reviewers. * It generates more work for anyone checking whether the GUI is consistent / follows human interface guidelines (wrt. ellipses for instance). So I propose to simply remove unimplemented menus. When / if someone ever decides to implement some of the corresponding functionality, adding the corresponding code and GUI bits back should not be too hard. Objections? Good Idea, at least for the year old stub menus (like winefile). For recently added, with hope to see them implemented in the next time (maybe gsoc), we should wait some month (e.g. iexplore) IMO. I agree. This was proposed as a GOSC project by one of the people. There is a thread on Wine Users about these menus being 'unimplemented' and how they should be. Would this be a good item for a bug report for an Request for Enhancement? IMHO no, there is no point i think. PS: is this meant to be also sent to wine-devel? Are these features the program should possess or not? These tend to be 'standard' menu items for most Windows programs and the underlying code does lie in Windows, not the individual programs and has since the Windows 3.x days. Theoretically they should be there, yes, but it's not really worth the effort. At least we could implement some sort of stub to popup a dialog to say the function is not implemented in Wine? Does Excel have a Open... and Save... menu item (these are also implemented in Windows or is it the program?) Yes, Excel has the dialog, along with most other programs. Winefile itself does not have it implemented. If you want to take the time to stub out the dialogs, be my guest, but few people use winefile as is, and fewer use the full dialogs (I bet most that notice it is broken are just curious if it does work). The effort spent stubbing it would be better spent fixing bugs that break actual applications. Austin: However, this just might be something that AJ will approve. Sure, that's his call, but I don't see the point in discussing it without someone volunteering to write the code. It's a moot point, I don't use winefile, and I'd rather see it cleaned up than have tons of stubs that make it look incomplete. However, I'm not going to take the time to fix it, and am happy to see Francois do so. Either way is fine with me, and it's not my decision. That's all I've got to say here, back to bugzilla for me. I agree with this statement. Cleaning up poorly written code is always a noble task. James McKenzie
Re: RFC: Remove unimplemented application menus?
On 3/28/11 7:19 PM, Austin English wrote: On Tue, Mar 29, 2011 at 03:17, James McKenzie wrote: On 3/28/11 7:15 PM, Austin English wrote: 2011/3/29 James McKenzie: On 3/28/11 9:28 AM, André Hentschel wrote: Am 28.03.2011 17:27, schrieb James McKenzie: 2011/3/27 André Hentschel: Am 27.03.2011 13:50, schrieb Francois Gouget: Some Wine programs, winefile in particular, have a lot of unimplemented menus. That is you can see the menu entry but clicking on it only gives you a 'Not yet implemented' error dialog (or does nothing in the case of iexplore). For instance just for the first two winefile menus none of the following are implemented: File -> Print... File -> Associate... File -> Search... File -> Select Files... Disk -> Share as... Disk -> Remove Share... Disk -> Select Drive... I think such a situation is bad: * Having tons of unimplemented menus looks amateurish. * It's very confusing. You see tons of menus except over 50% of them don't work. So it makes the GUI more complex with no benefit. * I suspect most of these menus have been unimplemented for years so there is little hope of seeing them improve any time soon. * For a number of them it's questionable whether it makes sense to implement them in Wine at all as they correspond to tasks that better belong to the native system facilities (Share as for instance). * I doubt they serve any significant compatibility purpose. * In the mean time they generate more work for translators and translation reviewers. * It generates more work for anyone checking whether the GUI is consistent / follows human interface guidelines (wrt. ellipses for instance). So I propose to simply remove unimplemented menus. When / if someone ever decides to implement some of the corresponding functionality, adding the corresponding code and GUI bits back should not be too hard. Objections? Good Idea, at least for the year old stub menus (like winefile). For recently added, with hope to see them implemented in the next time (maybe gsoc), we should wait some month (e.g. iexplore) IMO. I agree. This was proposed as a GOSC project by one of the people. There is a thread on Wine Users about these menus being 'unimplemented' and how they should be. Would this be a good item for a bug report for an Request for Enhancement? IMHO no, there is no point i think. PS: is this meant to be also sent to wine-devel? Are these features the program should possess or not? These tend to be 'standard' menu items for most Windows programs and the underlying code does lie in Windows, not the individual programs and has since the Windows 3.x days. Theoretically they should be there, yes, but it's not really worth the effort. At least we could implement some sort of stub to popup a dialog to say the function is not implemented in Wine? Does Excel have a Open... and Save... menu item (these are also implemented in Windows or is it the program?) Yes, Excel has the dialog, along with most other programs. Winefile itself does not have it implemented. If you want to take the time to stub out the dialogs, be my guest, but few people use winefile as is, and fewer use the full dialogs (I bet most that notice it is broken are just curious if it does work). The effort spent stubbing it would be better spent fixing bugs that break actual applications. Austin: However, this just might be something that AJ will approve. James McKenzie
Re: RFC: Remove unimplemented application menus?
On 3/28/11 7:15 PM, Austin English wrote: 2011/3/29 James McKenzie: On 3/28/11 9:28 AM, André Hentschel wrote: Am 28.03.2011 17:27, schrieb James McKenzie: 2011/3/27 André Hentschel: Am 27.03.2011 13:50, schrieb Francois Gouget: Some Wine programs, winefile in particular, have a lot of unimplemented menus. That is you can see the menu entry but clicking on it only gives you a 'Not yet implemented' error dialog (or does nothing in the case of iexplore). For instance just for the first two winefile menus none of the following are implemented: File ->Print... File ->Associate... File ->Search... File ->Select Files... Disk ->Share as... Disk ->Remove Share... Disk ->Select Drive... I think such a situation is bad: * Having tons of unimplemented menus looks amateurish. * It's very confusing. You see tons of menus except over 50% of them don't work. So it makes the GUI more complex with no benefit. * I suspect most of these menus have been unimplemented for years so there is little hope of seeing them improve any time soon. * For a number of them it's questionable whether it makes sense to implement them in Wine at all as they correspond to tasks that better belong to the native system facilities (Share as for instance). * I doubt they serve any significant compatibility purpose. * In the mean time they generate more work for translators and translation reviewers. * It generates more work for anyone checking whether the GUI is consistent / follows human interface guidelines (wrt. ellipses for instance). So I propose to simply remove unimplemented menus. When / if someone ever decides to implement some of the corresponding functionality, adding the corresponding code and GUI bits back should not be too hard. Objections? Good Idea, at least for the year old stub menus (like winefile). For recently added, with hope to see them implemented in the next time (maybe gsoc), we should wait some month (e.g. iexplore) IMO. I agree. This was proposed as a GOSC project by one of the people. There is a thread on Wine Users about these menus being 'unimplemented' and how they should be. Would this be a good item for a bug report for an Request for Enhancement? IMHO no, there is no point i think. PS: is this meant to be also sent to wine-devel? Are these features the program should possess or not? These tend to be 'standard' menu items for most Windows programs and the underlying code does lie in Windows, not the individual programs and has since the Windows 3.x days. Theoretically they should be there, yes, but it's not really worth the effort. At least we could implement some sort of stub to popup a dialog to say the function is not implemented in Wine? Does Excel have a Open... and Save... menu item (these are also implemented in Windows or is it the program?) James McKenzie
Re: RFC: Remove unimplemented application menus?
On 3/28/11 9:28 AM, André Hentschel wrote: Am 28.03.2011 17:27, schrieb James McKenzie: 2011/3/27 André Hentschel: Am 27.03.2011 13:50, schrieb Francois Gouget: Some Wine programs, winefile in particular, have a lot of unimplemented menus. That is you can see the menu entry but clicking on it only gives you a 'Not yet implemented' error dialog (or does nothing in the case of iexplore). For instance just for the first two winefile menus none of the following are implemented: File -> Print... File -> Associate... File -> Search... File -> Select Files... Disk -> Share as... Disk -> Remove Share... Disk -> Select Drive... I think such a situation is bad: * Having tons of unimplemented menus looks amateurish. * It's very confusing. You see tons of menus except over 50% of them don't work. So it makes the GUI more complex with no benefit. * I suspect most of these menus have been unimplemented for years so there is little hope of seeing them improve any time soon. * For a number of them it's questionable whether it makes sense to implement them in Wine at all as they correspond to tasks that better belong to the native system facilities (Share as for instance). * I doubt they serve any significant compatibility purpose. * In the mean time they generate more work for translators and translation reviewers. * It generates more work for anyone checking whether the GUI is consistent / follows human interface guidelines (wrt. ellipses for instance). So I propose to simply remove unimplemented menus. When / if someone ever decides to implement some of the corresponding functionality, adding the corresponding code and GUI bits back should not be too hard. Objections? Good Idea, at least for the year old stub menus (like winefile). For recently added, with hope to see them implemented in the next time (maybe gsoc), we should wait some month (e.g. iexplore) IMO. I agree. This was proposed as a GOSC project by one of the people. There is a thread on Wine Users about these menus being 'unimplemented' and how they should be. Would this be a good item for a bug report for an Request for Enhancement? IMHO no, there is no point i think. PS: is this meant to be also sent to wine-devel? Are these features the program should possess or not? These tend to be 'standard' menu items for most Windows programs and the underlying code does lie in Windows, not the individual programs and has since the Windows 3.x days. Sorry, but I hit the reply button and not reply to all when I responded to you. My apologies. James McKenzie
Re: Wine compatibility
On 3/23/11, Adam Kłobukowski wrote: > Hello > > I have a question for Wine developers, not 100% related to development, > so: please excuse me for wasting your time. > > Officially sated, Wine wants to be 'bug-by-bug' implementation of > Windows APIs. On the other hand, it is known that all (?) version of > Windows contain 'hacks' to make important and not well behaving > applications work (mostly workarounds for application bugs). This > 'hacks' work by detecting that a faulty app is running, and turning > special 'hack' mode for such app. Because of this, black box testing > often used by Wine developers will not detect such workarounds, and > applications that (seem to) work perfectly well under Windows, will not > work under Wine. > And some programs that worked 'just fine' under WindowsXP will not in any other version due to the internal hacks. > Is there a solution for this? What is Wine devs position on this matter? Sure. We look at the interaction between the program and the Windows API (this is how true Black Box testing is done), implement a test case and then build code to the test case. > > Side question: Windows could make a 'clean start' with 64 bit > environment, did they? If that happened, there would have not been any version of Windows with 64 bitness for about twenty years. Microsoft 'extended' their code to work in a 64 bit environment. This is common with existing 32 bit code to extend it to 64 bits. James McKenzie
Re: [PATCH] winegcc - do not create .exe.so
On 3/20/11 4:14 AM, Pali Rohár wrote: 2011/2/19 Pali Rohár: 2011/2/4 Pali Rohár: Hello, I created patch which implement correct _start section in ELF shared libraries/binaries which generate winegcc. Into _start section this patch add calling execve syscall which start wine with all arguments. So it is not needed to generate shell wrapper and .exe.so binary. This replace code on: http://wiki.winehq.org/Winelib_binaries_as_ELF_executables_not_.exe.so $ winegcc app.c --> generate only a.exe (shared object ELF binary), no aditional a.exe.so $ ./a.exe --> start binary correctly without shell wrapper -- Pali Rohár pali.ro...@gmail.com I rewrited my patch. Now set up correctly enviromental variables too. Assembler code is only for x86. -- Pali Rohár pali.ro...@gmail.com Can anybody review my patch? Reviews are sent to wine-development list. If you want to submit a patch for comment only, please submit it to wine-development. Thank you. James McKenzie
Re: GSOC CMD parser.
On 3/12/11 6:18 PM, Joel Teichroeb wrote: I'm quite interested in the idea on the wiki of improving the CMD parser and fixing the bugs. I brought this up in the IRC and it was mentioned that there was some discussion of using bison/flex for parsing. I don't think that would be feasible for me to do in just three months but I'm wondering if that is the direction that is wanted for the CMD parser. I think that you have a good plan, but you should limit your scope of work to maybe one or two bugs and work on them. Taking on the 'whole' bug thing may prove to be overwhelming. As an example, I picked up a bug report from someone else and have been working on it, off and on, over three years. This was to add a complex function and it was implemented completely wrong and I realized this after much work. You might also want to look at finishing some of the missing tests and filing bugs for the missing functions. This depends on your 'c' programming skills and your ability to discover sources for CMD functions. Overall, I don't have the ability to say whether or not this would be a good GSOC candidate, but we do need someone to look into the CMD parser and figure out if there is a better way to implement it. James McKenzie
riched20/tests: Beginnings of EM_SETMARGINS test. This patch is released into the Public Domain under the requirements of the LGPL version 2.1 or later. Released by James McKenzie jjmckenzi...@gmail.c
Just checking if gmail has a 'wrapping' problem or if this will actually
go through.
riched20/tests: Beginnings of EM_SETMARGINS test. This patch is released
into the Public Domain under the requirements of the LGPL version 2.1 or
later. Released by James McKenzie jjmckenzi...@gmail.com
---
dlls/riched20/tests/editor.c | 215
++
1 files changed, 215 insertions(+), 0 deletions(-)
diff --git a/dlls/riched20/tests/editor.c b/dlls/riched20/tests/editor.c
index 7a4e032..31f3bdc 100644
--- a/dlls/riched20/tests/editor.c
+++ b/dlls/riched20/tests/editor.c
@@ -7034,6 +7034,220 @@ static void test_dialogmode(void)
DestroyWindow(hwParent);
}
+static INT CALLBACK is_truetype_font_installed_proc(const LOGFONT
*elf, const TEXTMETRIC *ntm, DWORD type, LPARAM lParam)
+{
+if (type != TRUETYPE_FONTTYPE) return 1;
+
+return 0;
+}
+
+static BOOL is_truetype_font_installed(const char *name)
+{
+HDC hdc = GetDC(0);
+BOOL ret = FALSE;
+
+if (!EnumFontFamiliesA(hdc, name, is_truetype_font_installed_proc, 0))
+ret = TRUE;
+
+ReleaseDC(0, hdc);
+return ret;
+}
+
+static INT CALLBACK is_font_installed_proc(const LOGFONT *elf, const
TEXTMETRIC *ntm, DWORD type, LPARAM lParam)
+{
+return 0;
+}
+
+static BOOL is_font_installed(const char *name)
+{
+HDC hdc = GetDC(0);
+BOOL ret = FALSE;
+
+if(!EnumFontFamiliesA(hdc, name, is_font_installed_proc, 0))
+ret = TRUE;
+
+ReleaseDC(0, hdc);
+return ret;
+}
+
+static void test_em_setmargins(void)
+{
+ HWND hwndRichEdit;
+ RECT old_rect, new_rect;
+
+ HDC hDC;
+ LOGFONTA lfA;
+ UINT ret;
+ int ry, i, j, k;
+
+ HFONT testFont1A, hDC_font;
+
+ /* Add various window sizes for USEFONTINFO tests */
+ static const struct rect_parameters
+ {
+int start_left, start_top, end_right, end_bottom;
+ } rect_param[] =
+ {
+{ 0, 0, 400, 80 },
+ };
+
+ /* data for ANSI font tests */
+ static const struct font_margins_data
+ {
+const char face_name[LF_FACESIZE];
+int weight, height, ascent, descent, int_leading, ext_leading;
+int ave_char_width, max_char_width, dpi;
+ } fmd[] =
+ {
+{ "Courier", FW_NORMAL, 13, 11, 2, 0, 0, 8, 8, 96 },
+{ "System", FW_BOLD, 16, 13, 3, 3, 0, 7, 14, 96 },
+{ "Arial", FW_NORMAL, 16, 13, 3, 3, 0, 6, 35, 96, },
+ };
+
+ /* Test data for margins testing */
+ static const struct margin_test_data
+ {
+int left_margin, right_margin;
+DWORD margin_type;
+ } mmt [] =
+ {
+{ 0, 0, EC_LEFTMARGIN }, /*Clear all margin settings */
+/*Left Margin tests*/
+{ 10, 0, EC_LEFTMARGIN }, /*Set Left Margin to 10 */
+{ EC_USEFONTINFO, 0, EC_LEFTMARGIN }, /*Test EC_USEFONTINFO as
lparam with EC_LEFTMARGIN */
+{ 0, 0, EC_LEFTMARGIN }, /*Clear margins for Right Margin tests */
+/*EC_USEFONTINFO as lpararm tests */
+{ 10, 10, EC_USEFONTINFO }, /*Set margins to 10 with
EC_USEFONTINFO, should return zero */
+{ 0, EC_USEFONTINFO, EC_USEFONTINFO }, /*Set Right Margin to
EC_USEFONTINFO under EC_USEFONTINFO, should
+ return zero except with TrueType Fonts, this should be the
lagging spacing value for large fonts and large
+ edit windows*/
+{ EC_USEFONTINFO, 0, EC_USEFONTINFO }, /*Set Left Margin to
EC_USEFONTINFO under EC_USEFONTINFO, should return
+ zero except with TrueType Fonts, this should be the leading
spacing value for large fonts and large edit
+ windows*/
+{ EC_USEFONTINFO, EC_USEFONTINFO, EC_USEFONTINFO }, /*Set both
margins to EC_USEFONTINFO under EC_USEFONTINFO,
+ should have same results for both left and right tests above */
+{ 0, 0, EC_USEFONTINFO }, /*Clear Margins, if set */
+ };
+
+ /* Run tests for number of rectangles */
+ for ( k=0; k< (sizeof(rect_param)/sizeof(rect_param[0])); k++)
+ {
+hwndRichEdit = CreateWindow(RICHEDIT_CLASS, NULL,
ES_MULTILINE|WS_POPUP|WS_HSCROLL|WS_VSCROLL|WS_VISIBLE,
+rect_param[k].start_left,
rect_param[k].start_top, rect_param[k].end_right,
+rect_param[k].end_bottom, NULL, NULL,
hmoduleRichEdit, NULL);
+ok(hwndRichEdit != NULL, "Error creating Richedit Window in
EM_SETMARGINS test. error received: %d\n",
+ (int) GetLastError());
+if (!hwndRichEdit)
+{
+ return;
+}
+
+hDC = GetDC(hwndRichEdit);
+ok (hDC != NULL, "Creation of hdc failed.\n");
+if (!hDC)
+{
+ DestroyWindow(hwndRichEdit);
+ return;
+}
+
+ry = GetDeviceCaps(hDC, LOGPIXELSY);
+
+ZeroMemory(&lfA, sizeof(lfA));
+ZeroMemory(&testFont1A, sizeof(HFONT));
+/*Initialize rect variable to be the size of the entire richedit
window */
+old_rect.left = rect_param[k].start_left;
+old_rect.right = rect_param[k].end_right;
+old_rect.top = rect_param[k].start_top;
+old_rect.bottom = rect_para
Re: USB Osciloscope
On 3/1/11 5:09 PM, Archie Robertson wrote: I have a USB osciloscope (Link Instruments DSO 8002) that I am quite motivated to get working in wine. I have followed the instructions to install the USB patches. The osciloscope software works fine in demo mode, but it still cannot find the device. I have spent some time messing around with this, but I am new to wine, so I am a little lost. I am a half decent c programmer, so If somebody could point me in the right direction I should be able to get this working. There is a page on USB support on the Wine Wiki. Please feel free to read through it. Note that the last time I tried to get to the page with the USB patches, it was not available. Others here have expressed their willingness to improve USB non-storage device support. This has been a tough problem to solve. James McKenzie
Re: comctl32: Shed an unused parameter of TOOLTIPS_HitTestT and rename to TOOLTIPS_HitTest.
On 2/27/11 1:46 AM, Nikolay Sivov wrote:
On 2/26/2011 23:01, Gerald Pfeifer wrote:
---
dlls/comctl32/tooltips.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/dlls/comctl32/tooltips.c b/dlls/comctl32/tooltips.c
index a2e58e0..445845c 100644
--- a/dlls/comctl32/tooltips.c
+++ b/dlls/comctl32/tooltips.c
@@ -1396,8 +1396,7 @@ TOOLTIPS_GetToolInfoT (const TOOLTIPS_INFO
*infoPtr, TTTOOLINFOW *ti, BOOL isW)
static LRESULT
-TOOLTIPS_HitTestT (const TOOLTIPS_INFO *infoPtr, LPTTHITTESTINFOW
lptthit,
- BOOL isW)
+TOOLTIPS_HitTest (const TOOLTIPS_INFO *infoPtr, LPTTHITTESTINFOW
lptthit)
{
TTTOOL_INFO *toolPtr;
INT nTool;
@@ -2209,8 +2208,8 @@ TOOLTIPS_WindowProc (HWND hwnd, UINT uMsg,
WPARAM wParam, LPARAM lParam)
case TTM_HITTESTA:
case TTM_HITTESTW:
-return TOOLTIPS_HitTestT (infoPtr, (LPTTHITTESTINFOW)lParam,
- uMsg == TTM_HITTESTW);
+return TOOLTIPS_HitTest (infoPtr, (LPTTHITTESTINFOW)lParam);
+
case TTM_NEWTOOLRECTA:
case TTM_NEWTOOLRECTW:
return TOOLTIPS_NewToolRectT (infoPtr, (LPTTTOOLINFOW)lParam);
This should properly handle text instead of removing A/W case.
Even if all it does is convert ANSI to UNICODE and then call the UNICODE
case correct?
This is more a question on how I should handle a case I'm working with
for riched20, not a comment on this particular piece of code.
James McKenzie
Re: kernel32/tests: remove win9x hacks (try 2)
On 2/25/11 10:33 AM, Alexandre Julliard wrote: Saulius Krasuckas writes: Thanks. Do you mean something like integrating OpenWatcom C compiler optionally into dlls/*/tests? And then running 16-bit part of winetest on Win3.1? WinXP seems to be broken in my case. While Win98 seems OK. No, winetest would run on XP. If your app doesn't work on XP then it's unlikely to work on Wine. We are *not* going to replicate the Win95 16-bit architecture. I've been looking at the use of is_win9x and all the tests do for riched20 (except one) is check for the presence of UNICODE calls, namely lstrcmpW. I would like to rename the variable and redo the test. Is this acceptable or should the test itself be dropped? James McKenzie
Re: kernel32/tests: remove win9x hacks (try 2)
On 2/24/11 4:50 AM, Alexandre Julliard wrote: Damjan Jovanovic writes: What's the first Git version of Wine on which Win9x tests started being removed? Is it 226c44097b26dcb547d533cb1690f60182d1728e or b7c18d104b2d68a2a07574f01bb306df3fc138d2? It might still be useful to cross-compile tests on the version before that one and sporadically run them against future versions of Wine. You are missing the point. The win9x support makes the tests less strict, by allowing additional behaviors, and that only when running on Windows. Running them on Wine is pointless since these code paths are never executed. In this context, I will state that you are correct. My patch was to remove a test based on the getversion() code and actually test if a called UNICODE function exists. It was not to add any additional test case results specific to Windows9x/ME (and from the testing I did, there was no difference on a live Windows98SE system vice a live WindowsXP system.) Adding broken() calls just to make a test pass on Windows9x should be discouraged. Creating specific tests for Windows9x/ME is better, but at this point in time not needed. We need to move forward with incorporating more of the API/ABI at the current running level. If someone wants to dedicate to completing an old and very undocumented functions, this should not be discouraged, but rather encouraged to work on the current project. However, if Wine has specific functionality to support Windows9x/ME based programs the tests should ensure that we don't break it when trying to add (for instance) Windows7 functionality. As to adding functions to emulate Windows9x/ME functions, that should only be done to clear a bug report and not as a priority. Some programs will now not run with Windows7 due to changes in the API/ABI. James McKenzie
Re: kernel32/tests: remove win9x hacks (try 2)
On 2/23/11 12:13 PM, Austin English wrote: On Wed, Feb 23, 2011 at 03:17, Damjan Jovanovic wrote: On Wed, Feb 23, 2011 at 11:38 AM, Austin English wrote: -- -Austin So test.winehq.org doesn't test Win9x any more, but why are we throwing away perfectly good Win9x tests that took years to get in? Because the code is essentially dead. Ok. I agree with that thought, but riched20.dll has different functionality based upon different versions of Windows. Thus riched20 functions will vary based upon the version of Windows we are trying to emulate. As I stated, I run dOOm II, which basically is a Windows95 First Person Shooter. There are other old games like this that I feel that Wine should support because this functionality is going away with Microsoft Windows. Windows 3.1/3.11 is already gone, for the most part. Thus, like Damjan said, the tests are there and have been proven. I agree that no new Windows9x tests should be added, except where needed, to the existing codebase. James McKenzie
Re: kernel32/tests: remove win9x hacks
On 2/23/11 2:38 AM, Austin English wrote:
On Wed, Feb 23, 2011 at 01:32, Paul Vriens 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
Re: Apologies to the List
On 2/22/11 10:44 PM, Tom Wickline wrote: On Wed, Feb 23, 2011 at 10:52 AM, James McKenzie mailto:jjmckenzi...@earthlink.net>> wrote: On 2/22/11 4:37 AM, Alexandre Julliard wrote: James McKenziemailto:jjmckenzi...@earthlink.net>> writes: First, my tirade was not intended to be as such. I wanted to pull the patch because it was incorrect and I did not want anyone else working on it while I silently trimmed it and made it better. Second, I realize this has affected my 'Jeremy White' score. I hope that AJ understands why the code was pulled and that this happens frequently with a project this large. No, it doesn't. Requesting your code to be pulled is a serious matter, and a major break of the trust that is necessary for us all to work together. You can't do something like this and expect it not to have consequences. It was already unlikely that you would get any of your patches in, based on their technical merit, but now even if you managed to make your code acceptable, I wouldn't put it in, because I can't trust you not to make me pull it out again next time you get mad at me. And I agree with this decision. You are technically "the keeper of the code" and I have on more than one occasion transgressed this unwritten rule. However, I will still post patches for comments in Wine Development and subsequently release them to the LGPL/Wine in Wine-Patches so that others can work with them. I feel that is only fair for what I have done. Is that acceptable? This seems to be the method used by others, however I have been known to be massively incorrect in the past, and I could be wrong now. If posting them to bug reports is the preferred method I will that instead. James McKenzie Hello James, This is just my opinion OK, So don't take this as the opinion of Wine/WineHQ or anyone else. In the past I had a very serious drinking problem and I pissed off allot of people, and most of them were my friends. So one day I decided to stop drinking and to try and repair old friendships, saying sorry will only get you, or me, or anyone of us just so far... The only way to get back trust and friendship is to earn it a little each day by your actions. And not to overreact to a past overreaction. :) So my suggestion is to take it a day at a time and try and mend past mistakes by future actions. Again, thank you. I have a few patches to work on and then they will be submitted, like I said, into the public domain. James McKenzie
Re: Apologies to the List
On 2/22/11 4:37 AM, Alexandre Julliard wrote: James McKenzie writes: First, my tirade was not intended to be as such. I wanted to pull the patch because it was incorrect and I did not want anyone else working on it while I silently trimmed it and made it better. Second, I realize this has affected my 'Jeremy White' score. I hope that AJ understands why the code was pulled and that this happens frequently with a project this large. No, it doesn't. Requesting your code to be pulled is a serious matter, and a major break of the trust that is necessary for us all to work together. You can't do something like this and expect it not to have consequences. It was already unlikely that you would get any of your patches in, based on their technical merit, but now even if you managed to make your code acceptable, I wouldn't put it in, because I can't trust you not to make me pull it out again next time you get mad at me. And I agree with this decision. You are technically "the keeper of the code" and I have on more than one occasion transgressed this unwritten rule. However, I will still post patches for comments in Wine Development and subsequently release them to the LGPL/Wine in Wine-Patches so that others can work with them. I feel that is only fair for what I have done. Is that acceptable? This seems to be the method used by others, however I have been known to be massively incorrect in the past, and I could be wrong now. If posting them to bug reports is the preferred method I will that instead. James McKenzie
Re: RFC: Patch to change what sets the is_win9x in riched20/tests
On 2/22/11 12:42 AM, Paul Vriens wrote: On 02/22/2011 01:21 AM, James McKenzie wrote: All: Upon examining other test code that creates a variable called is_win9x, I realized that using get_version and comparing it to a fixed value may not be best for the riched20 tests and have attached a proposed change to how this variable is set. It uses a called function, lstrcmpW and if it does not exist, the variable is set to a false value. This change has been tested on the testbot for Windows95/98/98SE/2K/2K3/XP/XP_64/Vista/Vista64/Win7/Win7_64 and no discrepancies were found. Win9x tests are no longer run with winetest. I also see that Austin sent some 9x cleanup patches. That said, I think the best way is to get rid of all the win9x 'hacks' in editor.c and rely on the fact that we have NT4+. Paul: While that is true, I thought the consensus was that testing would still be available for Window9X/ME. There are users (like me) that are running Windows9x/ME programs and don't want to loose the ability to run them under Wine. This function may not exist in Windows versions after Windows2K either, that is why I proposed changing this from a version check to actually checking for the called function. And lastly, I agree with adding tests to specifically check what happens in the riched20.dll for UNICODE calls. James McKenzie
RFC: Patch to change what sets the is_win9x in riched20/tests
All:
Upon examining other test code that creates a variable called is_win9x,
I realized that using get_version and comparing it to a fixed value may
not be best for the riched20 tests and have attached a proposed change
to how this variable is set. It uses a called function, lstrcmpW and if
it does not exist, the variable is set to a false value. This change
has been tested on the testbot for
Windows95/98/98SE/2K/2K3/XP/XP_64/Vista/Vista64/Win7/Win7_64 and no
discrepancies were found.
Comments on this patch are appreciated. I would like to submit this for
inclusion into the Wine code base on Friday.
James McKenzie
>From b9d828c5cbbcfc53bdb04afad8aca27bbfea1f11 Mon Sep 17 00:00:00 2001
From: James McKenzie
Date: Fri, 18 Feb 2011 19:49:51 -0700
Subject: richedit/test. Modify is_win9x determination to use actual called
UNICODE
function vice testing get_version.
---
dlls/riched20/tests/editor.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/dlls/riched20/tests/editor.c b/dlls/riched20/tests/editor.c
index a91d984..2dab92b 100644
--- a/dlls/riched20/tests/editor.c
+++ b/dlls/riched20/tests/editor.c
@@ -7101,7 +7101,8 @@ START_TEST( editor )
hmoduleRichEdit = LoadLibrary("RICHED20.DLL");
ok(hmoduleRichEdit != NULL, "error: %d\n", (int) GetLastError());
- is_win9x = GetVersion() & 0x8000;
+ ret = lstrcmpW(NULL, NULL);
+ is_win9x = !ret && GetLastError() == ERROR_CALL_NOT_IMPLEMENTED;
test_WM_CHAR();
test_EM_FINDTEXT();
--
1.7.3.5
Apologies to the List
First, my tirade was not intended to be as such. I wanted to pull the patch because it was incorrect and I did not want anyone else working on it while I silently trimmed it and made it better. Second, I realize this has affected my 'Jeremy White' score. I hope that AJ understands why the code was pulled and that this happens frequently with a project this large. I am aware that the code was placed into the LGPL at the time it was posted to Wine Patches. Third, I will be posting here three patches for riched20/test/editor.c. It is my desire that these patches be examined, with a critical eye and feedback applied. Be brutal, be blunt and most of all be helpful. If I write back that I don't understand what you are talking about, I really don't and may need additional guidance (examples, pointing out other code with a similar purpose.) This is how we grow and learn. Very respectfully, James McKenzie
Re: Pulling Patch
On 2/4/11 1:18 PM, Dan Kegel wrote: James McKenzie wrote: Since my Mac is dying I have decided to return to the Windows world. Please pull any and all patches. I have envoked the right to copyright and none of my code can or will be used in Wine. Sorry to see you go, but... why would you want to prohibit people from using your patches? (I only see two typo changes committed: http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=author&s=James+McKenzie&sr=1 Presumably you don't mean those, since they were trivial comment changes.) I guess you mean patches like http://www.winehq.org/pipermail/wine-patches/2010-June/089537.html When you sent those to wine-patches, weren't you placing them under the LGPL? Actually, the latest patch is what I don't want reused. And no, you don't put it in the LGPL until it is committed, which I don't expect AJ to do anyway. However, I'm moving in a different direction since my Mac needs more repairs than I'm willing to spend money on. Besides, I've been a big enough pain that my existence here is unwarranted and unneeded. James McKenzie
Pulling Patch
Since my Mac is dying I have decided to return to the Windows world. Please pull any and all patches. I have envoked the right to copyright and none of my code can or will be used in Wine. Thank you. James McKenzie
Re: RFC: Adding Mac support to secur32/schannel.c
Charles Davis wrote: > >On 2/3/11 9:22 AM, James Mckenzie wrote: >> 2. Building ANYTHING Unix'y on a Mac may require 'hacky' patches to get >> around some of the code issues. Both of the >>known UNIX to MacOSX porting projects provide GnuTLS but have to patch it to >>build and work on MacOSX without stepping on >>the existing capabilities. >What are you talking about? MacPorts doesn't need patches for GnuTLS anymore. >Looking at GnuTLS's Portfile, there are no >patch files pulled in and no reinplace (i.e. sed -ie) operations. It was my understanding that MacPorts did have them. I'll look at Fink tonight and see if there still is a patch file needed with the latest version. In any case, Mac users should be using build in functionality and as few as possible (none if possible) external 'Unix' add-on packages. For a while, they will be needed. >> I tend to agree with Ken Thomases for MacOSX we should be using the native >> code vice adding a package that may not provide full TLS functionality and >> moving towards schannel functionality to the higher levels of code in Wine. >I'm for that. In fact, my humble opinion is that Wine on Mac should only use >libraries that are part of the OS (i.e. only >dylibs in /usr/lib and frameworks in /System/Library/Frameworks). There are a >whole host of benefits, not the least of >which is that it makes binary distribution easier (to date, Mac OS is one of >the few platforms that does not have >an official binary distribution) and it could potentially expand our user-base >(since users would no longer have to have >MacPorts or Fink or Gentoo Prefix or use a third-party distro just to run >Wine). +1 :) It would be a great thing if we did not have to have 'special' builds for MacOSX and we could send out either an installable package or a disk image as the project. James McKenzie > >We've got a long way to go in that department, unfortunately. :( > >Chip > >
Re: RFC: Adding Mac support to secur32/schannel.c
Juan Lang wrote: I'll make this quick and address a comment here from Juan from the viewpoint of someone building Wine from scratch using one of the porting services: Fink. > >Besides, I'm still not convinced that GnuTLS on the Mac is such an >onerous problem. This is not just a Codeweavers' problem but a problem that: 1. MacOSX provides native TLS support. 2. Building ANYTHING Unix'y on a Mac may require 'hacky' patches to get around some of the code issues. Both of the known UNIX to MacOSX porting projects provide GnuTLS but have to patch it to build and work on MacOSX without stepping on the existing capabilities. Interfacing the existing TLS capabilities to appear as the GNU product may be a solution to this. I tend to agree with Ken Thomases for MacOSX we should be using the native code vice adding a package that may not provide full TLS functionality and moving towards schannel functionality to the higher levels of code in Wine. Thank you for reading this. James McKenzie
Re: Correction to crash inside RtlCaptureStackBackTrace() + test case
On 1/28/11 11:54 AM, Janne Hakonen wrote:
> Now, when I ran these tests on Testbot using all base VMs, the tests
were run also on W2KPROSP4 and WNT4WSSP6. However, the
> function seems to buggy in those. It throws access violation
whenever it is not skipping frames.
> Is there some way I could prevent/skip these tests to be run on
Windows NT4 and 2000?
Ah, no matter, I think I've got it. Adding following lines to start
allows the tests to be skipped on NT and 2000:
__TRY
{
pRtlCaptureStackBackTrace(0, 62, callers, NULL);
}
__EXCEPT_ALL
{
win_skip("RtlCaptureStackBackTrace threw SEH exception, "
"most likely running on Windows NT or 2000\n");
return;
}
__ENDTRY
Did you try this on WindowsXP or Windows7 to make sure that the win_skip
did not function on those platforms? My understanding is that win_skip
works on all Windows platforms not just WindowsNT or Windows2000.
Also, it is custom to mark your resubmissions with corrections as [try
x]. Makes it easier to determine what you are doing.
James McKenzie
Re: RFC: Adding Mac support to secur32/schannel.c
On 1/28/11 9:36 AM, Juan Lang wrote: Hi Ken, I'm planning to add an alternative implementation of schannel (SSL/TLS) support for the Mac. The current implementation is based on GnuTLS. That library is not typically found on Mac OS X. Although packagers can build it and ship it and its dependencies with Wine for Mac OS X, I think it's better (especially for security-related functionality) to use the system-provided library. What's the issue with building GnuTLS? Is it that GnuTLS doesn't support the Mac Keychain? Is it that it's an external dependency? If the latter, we already pull in quite a bit that isn't found on the Mac, so the incremental change isn't large. The point is that MacOSX has built-in TLS support out of the box. Why build GNU TLS when using MacOSX when it is not needed??? James McKenzie
Re: Policy regarding 3rd party "windows" distributions and winetest
On 1/30/11 9:02 AM, GOUJON Alexandre wrote: On 01/30/2011 04:47 PM, James McKenzie wrote: On 1/27/11 7:04 PM, Dan Kegel wrote: I suspect that we should discourage people from submitting winetest results from 3rd party repackagings of Microsoft Windows, e.g. http://thepiratebay.org/torrent/4254053/MicroXP_v0.82_-_eXPerience Agreed? +1. And that is a pirate version of Windows anyway. I don't see the point ... I mean, yeah it's not legal, it's bad and what you want but what about if they provide results that differ from the daily bot results ? Do you think this 'stripped' version can cause failures that would not happen on real windows ? Should we ignore these results ? I think Dan Kegel does not want them in the Winetest list. I'll defer to AJ as to what HE wants. I was just pointing out that this is legal to use in the United States and most other countries where Microsoft has enforceable copyrights. James McKenzie
Re: MapleStory Wine Bug
On 1/30/11 10:35 AM, Jack Edmonds wrote: I recently submitted a bug (http://bugs.winehq.org/show_bug.cgi?id=25934). I'm not sure if I did a good job on the submission, but if I did, I was thinking it would be a good first bug to work on so as to introduce me to the Wine source code. I was wondering if someone could help me get started on it. Jack: There is a whole bunch of information on how to develop for Wine on the Wine Wiki. Including Coding Standards and what NOT to do as well as what TO do. I'll defer to those pages. James McKenzie
Re: Policy regarding 3rd party "windows" distributions and winetest
On 1/27/11 7:04 PM, Dan Kegel wrote: I suspect that we should discourage people from submitting winetest results from 3rd party repackagings of Microsoft Windows, e.g. http://thepiratebay.org/torrent/4254053/MicroXP_v0.82_-_eXPerience Agreed? +1. And that is a pirate version of Windows anyway. James McKenzie
Re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
On 1/29/11 6:53 AM, Qian Hong wrote: Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! Qian: I would like to echo Nikolay's comment and add one more: Please search through the Bug Reports before submitting a new one. You might receive more assistance on the Wine User list as well. Most of the developers lurk there. Thank you. James McKenzie
Re: FYI: OpenCL/opencl.h from NVIDIA...
On 1/20/11 5:20 PM, Max TenEyck Woodbury wrote: 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: As far as I knew from information I gathered here, the only OS that supports OpenCL was MacOSX. Sorry for the misleading information. James McKenzie
Re: Where can I get OpenCL for Fedora 14.
On 1/20/11 8:28 AM, Max TenEyck Woodbury wrote: 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. The question is "Is there OpenCL" for Fedora? The only people who can answer this question are the Fedora Developers and Users. There is a wonderful Fedora Users Mailing list where this question would be more appropriate. Ask there (and I lurk there as well.) James McKenzie
Re: setupapi.dll: Call from 0x7b839292 to unimplemented function setupapi.dll.CM_Get_DevNode_Status (Crashing while running a USB production tool)
On 1/19/11 12:52 PM, Qian Hong wrote: On Thu, Jan 20, 2011 at 3:15 AM, Ricardo Filipe wrote: That should only need a stub to go forward (setupapi is already full of them). If you are not able to patch wine with a stub of that function then yeah, open a bug report. Thanks for reply :) Reported here : http://goo.gl/FHely Two things: ONE; CEASE TOP POSTING IMMEDIATELY. You have been told time and time again not to do this. Please read RFC 1855 if you need to know why. TWO: CEASE USING GOO.GL FOR SHORT URL POSTING. We expect a full URL to the Wine Bugzilla to be posted here and it is preferred. James McKenzie
Re: [1/1][user32.dll]Adding Arabic Translation resources
On 1/8/11 7:05 PM, Nowres wrote: From a5d9d1e4599ce5a6c2f45df7948182401526f997 Mon Sep 17 00:00:00 2001 From: Nowres Rafid <mailto:nss.zpeedz...@gmail.com>> Date: Sun, 9 Jan 2011 00:54:00 + Subject: [user32]Adding Arabic translation resources [Patch code deleted] Your patches are appearing in both the message and as a separate attachment. Also, your patches will not apply to current git code. Can you check your patches before sending them to the Patches list and please check if your git is current. Please review the Wiki article on how to create and send patches, please. James McKenzie
Re: RFC: Richedit: Test Patch for EM_SETMARGINS
On 1/17/11 1:07 AM, Dmitry Timoshkov wrote: James McKenzie wrote: +ok (16 == sentLogFontA.lfHeight, "Height not set to 12 for System Font. Height is %d\n", sentLogFontA.lfHeight); 12? Fixed in the next test patch. +ok (96 == ry, "DPI for screen does not equal 96 it is %d\n", ry); +ok (-240 == CharFont1ANSI.yHeight /* Wine */|| 195 == CharFont1ANSI.yHeight /* Windows */, "y Height of System Character is " +"not -240 or 195 but is %d\n", CharFont1ANSI.yHeight); +ok (16 == abs(CharFont1ANSI.yHeight) * ry / 1440 /*Wine*/|| 13 == abs(CharFont1ANSI.yHeight) * ry / 1440 /*Windows*/, \ +"Character Height of System character set is not 16 but %d\n", abs(CharFont1ANSI.yHeight) * ry / 1440); +ok (0 == CharFont1ANSI.yOffset, "Character Offset for System character set is not zero but %x\n", CharFont1ANSI.yOffset); +ok (7 == tma.tmAveCharWidth, "Average Character Width for System character set is %d\n", tma.tmAveCharWidth); +ok (15 == tma.tmMaxCharWidth /*Wine*/ || 14 == tma.tmMaxCharWidth /*Windows*/, "Maximum Character Width for System character set " \ +"is %d\n", tma.tmMaxCharWidth); Please use normal not reversed comparisons here and everywhere else, that style improves nothing. Actually this did catch an error where I used equal (=) instead of equal to (==) and that is a couple of best coding practice books that I use. However, for the final patch, this will be removed in its entirety. There is a difference between what Windows is returning and what Wine is returning but that is not the purpose of this patch. James McKenzie
Re: RFC: Richedit: Test Patch for EM_SETMARGINS
On 1/16/11 9:55 AM, Nikolay Sivov wrote: On 1/16/2011 19:39, James McKenzie wrote: All: I would like comments on this patch. Another question is how screen resolution affects that test. Thank you and Ge for this. Changing the resolution from 96 to 120 definitely affects the test results. Plus something else broke the test so now it is reporting errors. Sigh, back to testing some more. James McKenzie
Re: RFC: Richedit: Test Patch for EM_SETMARGINS
On 1/16/11 11:42 AM, Greg Geldorp wrote: From: James McKenzie I'll have to figure out how to change the resolution on the test bot and or my local copy of WindowsXP SP2 (not upgradable, no Internet connection to that system. I've now changed the resolution to 1024x768 and 120DPI on VM WXPPRODPY16 from their previous values of 800x600 and 96DPI. The other thing special about this VM is that it has a screen depth of 16 bits while all other VMs have a depth of 32 bits. I wonder how many tests this will break... Great. I'll run this test against it after I clean it up a bit. James McKenzie
Re: RFC: Richedit: Test Patch for EM_SETMARGINS
On 1/16/11 10:58 AM, Charles Davis wrote:
On 1/16/11 10:53 AM, James McKenzie wrote:
On 1/16/11 10:27 AM, Nikolay Sivov wrote:
On 1/16/2011 20:17, James McKenzie wrote:
+todo_wine {
+SendMessageW(hwndRichEdit, EM_SETMARGINS, EC_USEFONTINFO,
MAKELONG(EC_USEFONTINFO, EC_USEFONTINFO));
+}
Hm.
This is one of the test cases that was recommended and it appears to
be the only one that 'works'.
There's no test in this line, maybe that's why it 'works'.
No, USEFONTINFO is equal to 65,535 (0x) and in the other cases sets
the margin to either an overflow or underflow condition. This test does
not move the margins. Microsoft's documentation is lacking in how to
use this feature and I could not find a good case on the Internet.
Perhaps I used wrong search criteria or no one is using this capability.
He means there's no ok() macro call inside the todo_wine block. todo
blocks only have an effect on ok() macros.
I will remove the todo_wine from this call. It feeds back a 'fixme' for
now. I'll provide a 'cleaner' patch later today after working on it
some more.
James McKenzie
Re: RFC: Richedit: Test Patch for EM_SETMARGINS
On 1/16/11 10:58 AM, Nikolay Sivov wrote:
On 1/16/2011 20:53, James McKenzie wrote:
On 1/16/11 10:27 AM, Nikolay Sivov wrote:
On 1/16/2011 20:17, James McKenzie wrote:
+todo_wine {
+SendMessageW(hwndRichEdit, EM_SETMARGINS,
EC_USEFONTINFO, MAKELONG(EC_USEFONTINFO, EC_USEFONTINFO));
+}
Hm.
This is one of the test cases that was recommended and it appears
to be the only one that 'works'.
There's no test in this line, maybe that's why it 'works'.
No, USEFONTINFO is equal to 65,535 (0x) and in the other cases
sets the margin to either an overflow or underflow condition. This
test does not move the margins. Microsoft's documentation is lacking
in how to use this feature and I could not find a good case on the
Internet. Perhaps I used wrong search criteria or no one is using
this capability.
Ok, let's put it another way. There's no wine test entry in this line.
Got it. Thank you again, Nikolay for your feedback. Now to figure out
how to change the screen dpi.
James McKenzie
Re: RFC: Richedit: Test Patch for EM_SETMARGINS
On 1/16/11 10:27 AM, Nikolay Sivov wrote:
On 1/16/2011 20:17, James McKenzie wrote:
+todo_wine {
+SendMessageW(hwndRichEdit, EM_SETMARGINS, EC_USEFONTINFO,
MAKELONG(EC_USEFONTINFO, EC_USEFONTINFO));
+}
Hm.
This is one of the test cases that was recommended and it appears to
be the only one that 'works'.
There's no test in this line, maybe that's why it 'works'.
No, USEFONTINFO is equal to 65,535 (0x) and in the other cases sets
the margin to either an overflow or underflow condition. This test does
not move the margins. Microsoft's documentation is lacking in how to
use this feature and I could not find a good case on the Internet.
Perhaps I used wrong search criteria or no one is using this capability.
James McKenzie
Re: RFC: Richedit: Test Patch for EM_SETMARGINS
On 1/16/11 10:24 AM, André Hentschel wrote:
see http://test.winehq.org/data/
Will do. I don't want to break Windows9x functionality though.
+ /* Per http://msdn.microsoft.com/en-us/library/bb761649%(VS.85).asp
if the lparam is
+ EC_USEFONTINFO the Left and Right Margins should be set to a narrow
width if the
+ font has been set */
They don't use permanent links I believe.
Can I modify this to state the page name?
remove the url, maybe better something like "msdn's documentation for
functionxyz..."
Much better idea.
+ todo_wine {
+SendMessageW(hwndRichEdit, EM_SETMARGINS, EC_USEFONTINFO,
MAKELONG(EC_USEFONTINFO, EC_USEFONTINFO));
+}
Hm.
This is one of the test cases that was recommended and it appears to be the
only one that 'works'.
i bet Nikolay sighed about the curly brackets
Same style as used in the rest of the file. I like curly braces on
separate lines (I hope that is what you are referring to.)
+ if (winetest_debug> 1) {
test_WM_CHAR();
test_EM_FINDTEXT();
test_EM_GETLINE();
@@ -7126,6 +7643,8 @@ START_TEST( editor )
test_WM_GETDLGCODE();
test_zoom();
test_dialogmode();
+ }
+ test_em_setmargins();
Why?
Another question is how screen resolution affects that test.
I will look at this as well. I'll have to figure out how to change the
resolution on the test bot and or my local copy of WindowsXP SP2 (not
upgradable, no Internet connection to that system.
to be clear: i guess it's about the dpi and not the resolution like 1024x768.
I interpreted it that way as well. I have a system here set to 120 DPI
and use small fonts for the default font setting.
James McKenzie
Re: RFC: Richedit: Test Patch for EM_SETMARGINS
On 1/16/11 9:55 AM, Nikolay Sivov wrote:
On 1/16/2011 19:39, James McKenzie wrote:
All:
I would like comments on this patch.
Ok.
static HWND new_window(LPCTSTR lpClassName, DWORD dwStyle, HWND parent) {
HWND hwnd;
- hwnd = CreateWindow(lpClassName, NULL, dwStyle|WS_POPUP|WS_HSCROLL|WS_VSCROLL
+/* hwnd = CreateWindow(lpClassName, NULL,
dwStyle|WS_POPUP|WS_HSCROLL|WS_VSCROLL
|WS_VISIBLE, 0, 0, 200, 60, parent, NULL,
- hmoduleRichEdit, NULL);
+ hmoduleRichEdit, NULL); */
+ /* Set screen to VGA proportions for testing purposes, will be removed from
final patch release */
+hwnd = CreateWindow(lpClassName, NULL,
dwStyle|WS_POPUP|WS_HSCROLL|WS_VSCROLL
+|WS_VISIBLE, 0, 0, 640, 480, parent, NULL,
+hmoduleRichEdit, NULL);
ok(hwnd != NULL, "class: %s, error: %d\n", lpClassName, (int)
GetLastError());
return hwnd;
Commented code?
+static inline int is_win9xA()
+{
+static WCHAR arialW[]={'A','r','i','a','l',0};
+SetLastError(0xdeadbeef);
+lstrcmpW(arialW, arialW);
+return (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED);
+}
I think we don't care much about 9x now.
We still do tests on Windows95 to prevent regressions, or am I
incorrect? This code could be removed then.
+hDC = GetDC(hwndRichEdit);
+ok (hDC, "Creation of hdc failed \n");
+if (!hDC)
+{
+DeleteObject(testFont1A);
+DeleteObject(testFont2A);
+DeleteObject(testFont1W);
+DeleteObject(testFont2W);
+DeleteObject(testFont3W);
+DeleteObject(testFont4W);
+DeleteDC(hDC);
+DestroyWindow(hwndRichEdit);
+return;
+}
DeleteObject() with uninitialized handles?
Should I go ahead and just 'return' then?
+/* Calculate the twips per pixel */
+ry = GetDeviceCaps(hDC, LOGPIXELSY);
+
+static const WCHAR arialW[] = {'A','r','i','a','l',0};
+static const WCHAR courier[] = {'C','o','u','r','i','e','r',0};
+static const WCHAR msSansSerif [] = {'M','S',' ','S','a','n','s','
','S','e','r','i','f',0};
+
Variable declaration in code?
I can fix this.
+todo_wine {
+SendMessageA(hwndRichEdit, EM_SETMARGINS, EC_LEFTMARGIN, MAKELONG (5,0));
+SendMessageA(hwndRichEdit, EM_GETRECT, 0, (LPARAM)&new_rect);
+ok(new_rect.left == old_rect.left + 5, "The left border of the rectangle is
wrong. The value of it is %d.\n", \
+new_rect.left);
+}
todo_wine usually contains only test calls.
Ok. I missed this one.
+/*Set test font to be Courier font */
+SendMessageW(hwndRichEdit, WM_SETFONT, (WPARAM)testFont1W,
MAKELPARAM(TRUE, 0));
+/*Verify font is set */
+SendMessageW(hwndRichEdit, EM_GETCHARFORMAT, SCF_DEFAULT,
(LPARAM)&CharFont1Unicode);
+GetObjectW(testFont1W, sizeof(LOGFONTW),&sentLogFont);
Do you really need to verify that?
No. I will remove this code.
+/* Perhttp://msdn.microsoft.com/en-us/library/bb761649%(VS.85).asp if the
lparam is
+ EC_USEFONTINFO the Left and Right Margins should be set to a narrow
width if the
+ font has been set */
They don't use permanent links I believe.
Can I modify this to state the page name?
+ret = GetTextMetricsW (hDC,&tmw);
+ok (ret, "GetTextMetricsW failed\n");
+ok (7 == tmw.tmAveCharWidth, "Average Character Width for MS Sans Serif is
%d\n", tmw.tmAveCharWidth);
+ok (14 == tmw.tmMaxCharWidth, "Maximum Character Width for MS Sans Serif is
%d\n", tmw.tmMaxCharWidth);
+ok (150== CharFont1Unicode.yHeight /*Windows*/ || -195 ==
CharFont1Unicode.yHeight /*Wine*/, \
+ "Character height for MS Sans Serif is not 195 but is %d\n",
abs(CharFont1Unicode.yHeight));
+ok (10 == (abs(CharFont1Unicode.yHeight) * ry) / 1440 /*Windows*/ || 13 ==
(abs(CharFont1Unicode.yHeight) * ry) / 1440 /*Wine*/, \
+ "Character Height of MS San Serif character set is not 12 but %d\n",
abs(CharFont1Unicode.yHeight) * ry / 1440);
+ok (0 == CharFont1Unicode.wWeight /*Windows*/ || FW_NORMAL ==
CharFont1Unicode.wWeight /*Wine*/, "Average Character Weight for MS"\
+" Sans Serif is %d\n", CharFont1Unicode.wWeight);
I don't like that. Looks like it's necessary to figure out why values
differ comparing to native.
Ok. I questioned this as well.
+todo_wine {
+SendMessageW(hwndRichEdit, EM_SETMARGINS, EC_USEFONTINFO,
MAKELONG(EC_USEFONTINFO, EC_USEFONTINFO));
+}
Hm.
This is one of the test cases that was recommended and it appears
RFC: Richedit: Test Patch for EM_SETMARGINS
All:
I would like comments on this patch.
Thank you.
James McKenzie
>From da43fe92d633dade59e978e516b43ec409117a2a Mon Sep 17 00:00:00 2001
From: James McKenzie
Date: Sun, 16 Jan 2011 08:27:03 -0700
Subject: Adds tests for EM_SETMARGINS for ANSI and UNICODE
---
dlls/riched20/tests/editor.c | 523 +-
1 files changed, 521 insertions(+), 2 deletions(-)
diff --git a/dlls/riched20/tests/editor.c b/dlls/riched20/tests/editor.c
index 63b23e9..2bc684c 100644
--- a/dlls/riched20/tests/editor.c
+++ b/dlls/riched20/tests/editor.c
@@ -50,9 +50,13 @@ static int is_win9x = 0;
static HWND new_window(LPCTSTR lpClassName, DWORD dwStyle, HWND parent) {
HWND hwnd;
- hwnd = CreateWindow(lpClassName, NULL, dwStyle|WS_POPUP|WS_HSCROLL|WS_VSCROLL
+/* hwnd = CreateWindow(lpClassName, NULL,
dwStyle|WS_POPUP|WS_HSCROLL|WS_VSCROLL
|WS_VISIBLE, 0, 0, 200, 60, parent, NULL,
- hmoduleRichEdit, NULL);
+ hmoduleRichEdit, NULL); */
+ /* Set screen to VGA proportions for testing purposes, will be removed from
final patch release */
+hwnd = CreateWindow(lpClassName, NULL,
dwStyle|WS_POPUP|WS_HSCROLL|WS_VSCROLL
+|WS_VISIBLE, 0, 0, 640, 480, parent, NULL,
+hmoduleRichEdit, NULL);
ok(hwnd != NULL, "class: %s, error: %d\n", lpClassName, (int)
GetLastError());
return hwnd;
}
@@ -7068,6 +7072,518 @@ static void test_dialogmode(void)
DestroyWindow(hwParent);
}
+static INT CALLBACK find_font_proc(const LOGFONT *elf, const TEXTMETRIC *ntm,
DWORD type, LPARAM lParam)
+{
+return 0;
+}
+
+static inline int is_win9xA()
+{
+static WCHAR arialW[]={'A','r','i','a','l',0};
+SetLastError(0xdeadbeef);
+lstrcmpW(arialW, arialW);
+return (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED);
+}
+
+static void test_em_setmargins(void)
+{
+HWND hwndRichEdit;
+RECT old_rect, new_rect;
+
+HDC hDC;
+LOGFONT lf;
+LOGFONTW sentLogFont, lfW;
+LOGFONTA sentLogFontA, lfA;
+CHARFORMAT2A CharFont1ANSI;
+CHARFORMAT2W CharFont1Unicode;
+
+TEXTMETRICA tma;
+TEXTMETRICW tmw;
+
+UINT ret;
+int ry;
+
+HFONT testFont1W, testFont2W, testFont3W, testFont4W, testFont1A,
testFont2A, hDC_font;
+
+hwndRichEdit = new_richedit(NULL);
+
+hDC = GetDC(hwndRichEdit);
+ok (hDC, "Creation of hdc failed \n");
+if (!hDC)
+{
+DeleteObject(testFont1A);
+DeleteObject(testFont2A);
+DeleteObject(testFont1W);
+DeleteObject(testFont2W);
+DeleteObject(testFont3W);
+DeleteObject(testFont4W);
+DeleteDC(hDC);
+DestroyWindow(hwndRichEdit);
+return;
+}
+
+/* Calculate the twips per pixel */
+ry = GetDeviceCaps(hDC, LOGPIXELSY);
+
+static const WCHAR arialW[] = {'A','r','i','a','l',0};
+static const WCHAR courier[] = {'C','o','u','r','i','e','r',0};
+static const WCHAR msSansSerif [] = {'M','S',' ','S','a','n','s','
','S','e','r','i','f',0};
+
+memset(&CharFont1ANSI, 0, sizeof(CHARFORMAT2A));
+CharFont1ANSI.cbSize = sizeof(CharFont1ANSI);
+memset(&CharFont1Unicode, 0, sizeof(CHARFORMAT2W));
+CharFont1Unicode.cbSize = sizeof(CharFont1Unicode);
+memset(&sentLogFont, 0, sizeof(LOGFONTW));
+
+memset(&lfA, 0, sizeof(lfA));
+strcpy(lfA.lfFaceName, "Arial");
+lfA.lfHeight = 16;
+lfA.lfCharSet = ANSI_CHARSET;
+lfA.lfWeight = FW_NORMAL;
+testFont1A = CreateFontIndirectA(&lfA);
+lfA.lfHeight = 30;
+testFont2A = CreateFontIndirectA(&lfA);
+
+/*Initialize old_rect variable to be the size of the entire richedit
window */
+SendMessageA(hwndRichEdit, EM_SETRECT, 0, (LPARAM)&old_rect);
+SendMessageA(hwndRichEdit, EM_GETRECT, 0, (LPARAM)&old_rect);
+
+/*Set Left Margin to five pixels in size */
+todo_wine {
+SendMessageA(hwndRichEdit, EM_SETMARGINS, EC_LEFTMARGIN, MAKELONG (5,0));
+SendMessageA(hwndRichEdit, EM_GETRECT, 0, (LPARAM)&new_rect);
+ok(new_rect.left == old_rect.left + 5, "The left border of the rectangle
is wrong. The value of it is %d.\n", \
+new_rect.left);
+}
+ok(new_rect.right == old_rect.right, "The right border was changed in Left
Margin Change test by %d\n", \
+new_rect.right - old_rect.right);
+ok(new_rect.top == old_rect.top, "The top border was changed\n");
+ok(new_rect.bottom == old_rect.bottom, "The bottom border was changed\n");
+
+/*Set Right Margin to five pixels in size. The left margin should remai
Re: Configuration warning
On 1/15/11 11:45 AM, Taeksang Yoo wrote: configure: WARNING: OpenCL/opencl.h: present but cannot be compiled configure: WARNING: OpenCL/opencl.h: check for missing prerequisite headers? configure: WARNING: OpenCL/opencl.h: see the Autoconf documentation configure: WARNING: OpenCL/opencl.h: section "Present But Cannot Be Compiled" configure: WARNING: OpenCL/opencl.h: proceeding with the compiler's result configure: WARNING: ## ## configure: WARNING: ## Report this to wine-devel@winehq.org ## configure: WARNING: ## ## Hello Wine developers. While compiling wine 1.3.11 on Mac OS X 10.6.6 using F3-bgmusic.patch and wine-1.3.11-xinput2.patch I got this error. If you need to know anything else please let me know; I reported the error as requested. This can be ignored for now. OpenCL support is being built out. When I build Wine, I'll check my error logs since I do multiple daily builds and see if this happens on the same version of MacOSX here. So, don't do anything for now, please. James McKenzie
Re: semi-updated valgrind results
On 1/15/11 4:27 PM, Austin English wrote: On Wed, Jan 12, 2011 at 2:02 AM, Austin English wrote: I ran the tests with Valgrind for wine 1.3.11 on Debian Squeeze. I haven't yet updated the suppressions file (I'd appreciate feedback on what to add :p), so the logs are a bit noisy... But, if you're curious, see http://austinenglish.com/logs/valgrind/ I haven't yet setup the tests on that machine to run daily, I may do so eventually, especially if it proves useful :-). These results should be a bit cleaner, I had changed the script to run a persistent wineserver with `wineserver -p`, but that doesn't keep explorer/winedevice/etc. running. Now it's running a minimized winemine, which keeps the services running and shouldn't interfere with any user32 tests. Plus, some people have been busy and already fixed some leaks :-) http://austinenglish.com/logs/valgrind/2011-01-14-18.48/ Drip, drip. stop drip. Thank you to all of the folks that are detecting and fixing leaks. James McKenzie
Re: Testbot not accepting patch
On 1/15/11 8:53 AM, Greg Geldorp wrote: From: Alexandre Julliard Greg Geldorp writes: You'll have to take up the apply failure on the status page with Alexandre. That message has nothing to do with the bot. Since the patch applied without problems for me too, it seems you might have caught Alexandre on a little mistake :-) (don't we all love it when we get confirmation that he's human?). $ git apply 70225 error: patch failed: dlls/d3dx9_36/shader.c:874 error: dlls/d3dx9_36/shader.c: patch does not apply $ Guess I'm not human after all ;-) Turns out that Travis decided to confuse us by attaching a slightly different patch to the first message of this thread on wine-devel compared to the patch that he sent to wine-patches. The wine-patches one doesn't apply, the wine-devel one does. Anyway, glad we sorted this out, I hate it when I have to adjust my view of the world. Looks like it is time for [Try X] and a resubmission of the patch then. I was confused as well until I tried it on my local git and it also failed/passed. James McKenzie
Re: Testbot not accepting patch
On 1/14/11 3:20 PM, Travis Athougies wrote: Hi there, I've been trying to submit this patch to the testbot, and it keeps refusing it with the error "Unrecognized file typea" (that's not a typo, that's the exact error). The testbot has also refused to accept the patch when I sent it in on wine-patches (the error on the patch status page is apply failure). As far as I can tell, the patch looks good, it was generated by git format-patch from the latest git and I did not touch it after that, so it should apply, but it doesn't. Can you look into this? Travis: It applied just fine to my git here. I did not attempt to build Wine, would you like me to? James McKenzie
user32/test failing in cursoricon with proper results
All: I just ran the user32 tests to validate what I am seeing with my richedit test in progress but the test failed in the cursoricon check with valid results. Before I open a bug report, can anyone on a Mac validate that they receive 23 errors with valid test results? Thank you. James McKenzie
Re: {USB}Fail to patch 0002-Re-generate-some-files.txt
Qian Hong wrote:
>Sent: Jan 6, 2011 9:56 PM
>To: James McKenzie
>Cc: wine-devel@winehq.org
>Subject: Re: {USB}Fail to patch 0002-Re-generate-some-files.txt
>
>Dear James, thanks for reply. I think the current vesion of this patch is
>for wine1.3.10, the upload date is Dec 26.
>I'll try to attempt it.
>
I had not checked this as the last version was posted some time ago. I'll have
to look at it and see if it applies to the soon to be released (if not released
by the time I get to my Wine build machine) 1.3.11.
James McKenzie
Re: {USB}Fail to patch 0002-Re-generate-some-files.txt
On 1/6/11 8:43 PM, Qian Hong wrote: Dear all, After checkout latest wine from git, I tried to apply the USB support patches, but something is wrong. Could anyone tell me what did I have done wrong? This patch was written a long time ago for a much different revision of Wine. It needs to be updated. You could contact the author, or you could attempt to do it yourself. James McKenzie
Question on yHeight values for CHARFORMAT2A/CHARFORMAT2W
All: It is interesting that I am getting NEGATIVE values for this. I've ran this against the testbot and received 195 as the value for the System font in WindowsXP/WindowsVista/Windows7 but when I run this against Wine installed on a Mac, I get -240. Is this expected behavior or should I file a bug? Thank you. James McKenzie
Re: How to find out locking problem
On 1/1/11 7:10 PM, Dan Kegel wrote: Sometimes it helps to run winedbg from another window and get the stacks of all running processes with the command bt all With luck, you can then see which two code paths are competing for the lock. Dan: I've also been getting random 'locks' and this is only running 'make test' and that resulted in an update to the Wine Configuration. This looks like a regression of the problem that was fixed a long time ago, where interprocess locking happened constantly. Maybe Wylda can find it, if the problem is constant on his system. James McKenzie
Re: ntdll/cdrom : implement CDROM_Verify to work on Mac Os
On 1/1/11 4:07 AM, maury loïc wrote:
On Sat, Jan 1, 2011 at 2:22 AM, James McKenzie
mailto:jjmckenzi...@earthlink.net>> wrote:
On 12/31/10 1:50 PM, Charles Davis wrote:
On 12/31/10 1:11 PM, Ken Thomases wrote:
I should add that this patch seem correct to me. It
couldn't hurt to get Charles Davis's input, of course.
I agree, for now. He should at least put a comment in to the
effect of
"if we got this far, there's already media in the drive."
That was the point I was trying to get to. Based on Ken's comment
below, the device is temporary and only exists for the time period
that the device is in use.
MSDN documents that the purpose of IOCTL_*_CHECK_VERIFY is
to check if the media has changed. The Linux and FreeBSD
implementations basically just check if there's media in
the drive. On Mac OS X, the BSD device file just plain
doesn't exist unless and until there's media mounted.
There's no permanent BSD device file for the drive
itself. So, if CDROM_Verify() is called, which requires
that the BSD device file is opened and thus is present,
that by itself implies that there's media in the drive.
Therefore, CDROM_Verify() should just return success.
Makes sense. But the 'right' way to implement this on Mac OS
is to ask
DiskArbitration to tell us when the media changes. (In fact,
the right
way to implement this elsewhere is to ask udev or hald the
same thing.)
Then we can return STATUS_VERIFY_REQUIRED (as documented) when
the media
actually has changed. For now, though, Loïc's patch is OK.
Is this going to be changed sometime in the future to work per the
documentation?
AJ wants to eventually move some (all?) of the disk/CD/DVD/storage
IOCTLs into mountmgr anyway, where Wine's fake storage drivers are
hosted. Mountmgr already has infrastructure in place to talk
to DA on
Mac OS and to hald on Linux/FreeBSD, so doing this the 'right'
way will
be much easier there.
This is a good point. Maybe the effort should be to move the code
over to mountmgr.sys rather than implement and have to move it later.
And I am aware what the process is, I was asking general questions
based on what the comments were in the patch. Basically, the
comments did not make sense to me and I was asking for
clarification. That was provided by both Ken and Charles' comments.
James McKenzie
Hello Mr.McKenzie and Wine community,
Happy new years.
In fact, I don't try to resolve the SCSI command ioctl, to support the
cd-rom,
I have just modified the CDROM_Verify(), because I thought, this function
verify if the media is present in the device.
Here my reasoning :
in dll/ntdll/cdrom.c, we are in the function CDROM_DeviceIoControl().
get_parent_device() is called to get the device and Wine try to open
the device.
For what I understood, Mac Os will create an entry object into the
I/O Registry,
who represent our device, (the device exist at boot time or when it is
plugged).
get_parent_device() will find the object, and store the name of device.
After the device is found, Wine try to open it.
In the case of IOCTL_*_CHECK_VERIFY request, CDROM_Verify is called,
In this function, we already know we have a valid device,
in use, but if the device is present, the media is present too, we can
not have a file descriptor to a device, without
media present.
Thank you for the explanation of why you did it this way. This does
work. MacOSX has to be different in how it does this and that makes
things difficult for Mac users and developers (when you step outside the
'box' that Apple defined for us.)
James McKenzie
Re: happy new year!
On 12/31/10 10:43 PM, Dan Kegel wrote: May all your tests be green, and all your patches pass peer review :-) And may Quality Assurance Testing pass all of your code the first time and say "Good Job". James McKenzie
Re: 64-bit Notepad2 crashes
On 12/31/10 6:19 PM, Dan Kegel wrote: 'set' is not a good way to check the environment, since it also shows shell variables that are not yet exported. The portable way to check the environment is 'env'. True. Let me check this. correction: env | grep LIBRARY James McKenzie
Re: ntdll/cdrom : implement CDROM_Verify to work on Mac Os
On 12/31/10 1:50 PM, Charles Davis wrote: On 12/31/10 1:11 PM, Ken Thomases wrote: I should add that this patch seem correct to me. It couldn't hurt to get Charles Davis's input, of course. I agree, for now. He should at least put a comment in to the effect of "if we got this far, there's already media in the drive." That was the point I was trying to get to. Based on Ken's comment below, the device is temporary and only exists for the time period that the device is in use. MSDN documents that the purpose of IOCTL_*_CHECK_VERIFY is to check if the media has changed. The Linux and FreeBSD implementations basically just check if there's media in the drive. On Mac OS X, the BSD device file just plain doesn't exist unless and until there's media mounted. There's no permanent BSD device file for the drive itself. So, if CDROM_Verify() is called, which requires that the BSD device file is opened and thus is present, that by itself implies that there's media in the drive. Therefore, CDROM_Verify() should just return success. Makes sense. But the 'right' way to implement this on Mac OS is to ask DiskArbitration to tell us when the media changes. (In fact, the right way to implement this elsewhere is to ask udev or hald the same thing.) Then we can return STATUS_VERIFY_REQUIRED (as documented) when the media actually has changed. For now, though, Loïc's patch is OK. Is this going to be changed sometime in the future to work per the documentation? AJ wants to eventually move some (all?) of the disk/CD/DVD/storage IOCTLs into mountmgr anyway, where Wine's fake storage drivers are hosted. Mountmgr already has infrastructure in place to talk to DA on Mac OS and to hald on Linux/FreeBSD, so doing this the 'right' way will be much easier there. This is a good point. Maybe the effort should be to move the code over to mountmgr.sys rather than implement and have to move it later. And I am aware what the process is, I was asking general questions based on what the comments were in the patch. Basically, the comments did not make sense to me and I was asking for clarification. That was provided by both Ken and Charles' comments. James McKenzie
Re: 64-bit Notepad2 crashes
On 12/31/10 11:56 AM, Hin-Tak Leung wrote: Susan Cragin wrote: Does this 'path' exist in LD_LIBRARY_PATH or equivilent? Otherwise ld might not be able to 'find' it when starting the program. James McKenzie James... You've just exhausted my technical knowledge. How do I do / find that? Susan: For the BASH shell: Type in set and look for the LD_LIBRARY_PATH line. for the CSH/KSH shell: Type in env Look for the LD_LIBRARY_PATH line. Hopefully, /usr/local/lib is there. BTW, to make Wine work on a Mac, I have to add this line James McKenzie Typed "set" Did word search on "library." Nothing. for BASH, it should be export | grep LD_LIBRARY_PATH not "set". If you are setting the value, not searching for it. set | grep LIBRARY LD_LIBRARY_PATH=/Applications/Wine.app/Contents/Resources/Lib is what I get on my Mac (LD_LIBRARY_PATH has to be set due to the UNIXness of Wine.) James McKenzie
Re: [PATCH] d3dcompiler_43/tests: Added error tests to HLSL test suite
On 12/30/10 12:48 PM, Vitaliy Margolen wrote: On 12/30/2010 12:23 PM, Travis Athougies wrote: Tests to ensure the HLSL compiler won't crash on malformed input. You still haven't fixed strings spanning multiple lines. Please send a patch that fixes all incorrect strings first. Then continue on with the correct style. Adding more invalid strings because file already contains some of them isn't a valid reason for broken code. And you keep on forgetting to number your tries.It looks like you are up to try six or seven for this, correct? James McKenzie
Re: 64-bit Notepad2 crashes
Susan Cragin wrote: >Sent: Dec 30, 2010 8:30 AM >To: Marcus Meissner >Cc: Wine Developers , Eric Pouech > >Subject: Re: 64-bit Notepad2 crashes > >>On Thu, Dec 30, 2010 at 07:22:31AM -0500, Susan Cragin wrote: >>> >> ELF 7f3aa090b000-7f3aa0c3d000 Export >>> >> libwine.so.1 >>> >>if you've compiled wine yourself, it's strange that libwine.so doesn't >>> >>contain any dwarf information >>> >>maybe you're loading another instance of libwine? >>> >>A+ >>> >> >>> >>-- >>> >>Eric Pouech >>> > >>> >I did a search of the file system. >>> > >>> >Under /usr/local/lib64 I have >>> >libwine.so (link) >>> >libwine.so.1 (link) >>> >libwine.so.1.0 >>> >wine [folder} > >Then I ran ldconfig on the 64-bit, and then tried wine notepad. >I got the following error: >wine: error while loading shared libraries: libwine.so.1: cannot open shared >object file: No such file or directory Does this 'path' exist in LD_LIBRARY_PATH or equivilent? Otherwise ld might not be able to 'find' it when starting the program. James McKenzie
Re: ntdll/cdrom : implement CDROM_Verify to work on Mac Os
maury loïc wrote: > >Hello Ken and the Wine community, > Please bottom post or post directly to a question. Please do not top post. > >On Thu, Dec 30, 2010 at 12:51 PM, Ken Thomases wrote: > >> Hi Loïc, >> >> On Dec 30, 2010, at 4:20 AM, maury loïc wrote: >> >> > it's my first patch, and it implement the CDROM_Verify() >> > to work on Mac Os. >> >> I think most people are going to need more explanation for why this is a >> legitimate way to implement this function on Mac OS X. :) >> >> Cheers, >> Ken >> >> >For what i understood, The function CDROM_Verify(), verify if the media is >present on the device, and Wine try to open >the device(in Mac Os case), before call the CDROM_Verify(). > >But Mac Os manage the device differently from the other Os. It create the >device, only if the media >is already present. Logically, CDROM_Verify() return success, because when >we are in CDROM_Verify() >we already know the device. > >What do you think ? > This has been critically examined by several people and if the solution were this simple it would have been put in place a long time ago. Charles Davis has spend over a year looking at how to implement CDROM functionality for MacOSX. So, here is my question: How can the community be 100% certain that: 1. The device has EXACTLY the same name on every available MacOSX installation? 2. How can you be 100% certain that if the 'device' exists that the code will end up in CDROM_Verify()? James McKenzie (Another Mac User/Wine Tester.)
Re: [PATCH] JanitorialProjects/ReplaceMalloc: remove malloc and free from dlls folder
On 12/30/10 5:02 AM, Yegor Yefremov wrote: Hello, it's my first contribution to wine, so I wanted to start with some simple task. After fixing the files mentioned in the attached patch, following files in dlls folder still contain malloc/free calls: dlls/ntdll/server.c:if (!(tmp_dir = malloc( p + 1 - config_dir ))) fatal_error( "out of memory\n" ); dlls/msvcrt/heap.c: * malloc (MSVCRT.@) dlls/msvcrt/tests/printf.c:str = malloc(1024); dlls/msvcrt/tests/printf.c:str = malloc(1024); dlls/msvcrt/tests/heap.c: mem1 = malloc(size1); dlls/msvcrt/tests/heap.c: mem1 = malloc(size1); dlls/msvcrt/tests/heap.c:mem = malloc(0); dlls/msvcrt/tests/file.c:buffer = malloc( len * sizeof(WCHAR) ); dlls/msvcrt/tests/cpp.c: * or at program exit malloc() checking if these methods haven't been As far as I understand those files test the core functionality and should use malloc. If this is so, then malloc/free replacement for dlls is complete. The source code could be compiled without problems after applying the patch. I'm behind a firewall and couldn't clone the repository even via http (for some other projects it is functioning). That's why my patch was made with quilt. See the GitWine page in the Wiki on how to create git exports. James McKenzie
Re: [PATCH 2/2] Added ui64tow_s tests for msvcrt take 4 Can't believe I forgot to commit before creating the patch...
Arno Teigseth wrote: > You'll have to resend both parts of the patch for the testbot to recognize them. Use (resend) in the subject line for us humans. James McKenzie
Re: advapi32: Added check for NULL pointer being passed to QueryServiceStatus for either parameter. Updated tests to remove todo_wine for QueryServiceStatus.
Damian Dixon wrote: >Sent: Dec 20, 2010 1:28 PM >To: wine-patc...@winehq.org >Cc: damian.di...@gmail.com >Subject: advapi32: Added check for NULL pointer being passed to >QueryServiceStatus for either parameter. Updated tests to remove >todo_wine for QueryServiceStatus. > Please rebase to current git. James McKenzie
Re: Dutch translation for notepad and winecfg changed
Albert Pool wrote: One patch per message, please. Please see the Submitting Patches page on the Wiki. > >--- > programs/notepad/Nl.rc |5 +++-- > programs/winecfg/Nl.rc | 15 --- > 2 files changed, 11 insertions(+), 9 deletions(-) > >diff --git a/programs/notepad/Nl.rc b/programs/notepad/Nl.rc >index f5eeaab..31178a6 100644 >--- a/programs/notepad/Nl.rc >+++ b/programs/notepad/Nl.rc >@@ -1,7 +1,8 @@ > /* > * Notepad (Dutch resources) > * >- * Copyright 2003 Hans Leidekker >+ * Copyright 2003 Hans Leidekker Please follow the existing spacing in the file, this type of change is not needed. >+ * Copyright 2010 Albert Pool James McKenzie
Re: riched20/tests: Mark behaviour at 120 dpi as broken
Andre: My computer is set up for 125 dpi (Large Fonts on WindowsXP). Should we be testing for this as well? This should give different results than what is stated here. Maybe there is a better way to test this than using a fixed value of 39 in the ok comparision. James McKenzie -Original Message- >From: André Hentschel >Sent: Dec 9, 2010 11:38 AM >To: wine-patches >Subject: riched20/tests: Mark behaviour at 120 dpi as broken > >comparison to 96 dpi can be found at >http://test.winehq.org/data/23906816d87795c363f0199f33ff70f2732c6ab5/index_Win7.html >--- > dlls/riched20/tests/editor.c |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > >diff --git a/dlls/riched20/tests/editor.c b/dlls/riched20/tests/editor.c >index efd2023..5321d07 100644 >--- a/dlls/riched20/tests/editor.c >+++ b/dlls/riched20/tests/editor.c >@@ -6082,7 +6082,9 @@ static void test_EM_CHARFROMPOS(void) > point.x = 1000; > point.y = 40; > result = SendMessage(hwnd, EM_CHARFROMPOS, 0, (LPARAM)&point); >-todo_wine ok(result == 39, "expected character index of 39 but got %d\n", >result); >+todo_wine ok(result == 39, >+ broken(result == 34) /* 120 dpi */, >+ "expected character index of 39 but got %d\n", result); > > point.x = 1000; > point.y = -1; >-- > >Best Regards, André Hentschel > >
Re: Outlook-friendly stub for CreatePrivateObjectSecurity
Nick Sukharev wrote: > >Tab characters fixed. You need to resubmit as [Try 2] if you make a correction in the future in a new message, please. James McKenzie
Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.
On 12/6/10 1:41 PM, Juan Lang wrote: Hey ! I said I didn't want to be rude and that's still true RTFM is a kind of philosophy It's very hard to make RTFM not seem rude. Anything with the F word in it is, in my opinion, best left off this list. +1, Juan. Spell it out, Read the Fine Manual is what was intended, but could be misunderstood as a really rude comment. I prefer directing folks to the document, be it a web page (Google is your Friend), manual or a manpage... James McKenzie
Re: Death to win9x?
On 12/3/10 11:15 AM, André Hentschel wrote: As the VMs in Testbot are now retired we might want to delete the "old" win9x testdata from test.winehq.org(we need a name for this, testviewer?) manually? André: I almost have to agree with this because we should not expect improvements for these versions. However, I'm thinking of making a change to the richedit test as a prototype to a final introduction for what should be an improvement over using broken() for test cases for the older versions of Windows. The reason I'm picking on richedit is because there is vastly different results for the various riched versions that came with Windows 9x/ME and the current functionality. James McKenzie
Re: Death to win9x?
On 12/2/10 10:43 AM, André Hentschel wrote: Am 02.12.2010 16:11, schrieb James Mckenzie: Should I just go out and find a copy of Windows98SE and VirtualBox to run this on? Your reply makes it sound like the Wine program just does not care if Windows9x functionality does not matter, it does. Shutting down the test does not necessary meens wine will break the 9x stuff over time. actually we just always need to do something like skip() or broken() and that's nothing else as ignoring the test results of 9x and as you still play that game i guess wine still works here. True, but what happens IF the game stops working? Will a bug report with regression test be accepted or will it be rejected? You can see there is a little fear if we stop testing Windows9x completely. However, if we move the Windows9x VMs out of the way so we can concentrate on current versions, that is a good idea as some functionality of the current Windows versions does not exist or is vastly different. James McKenzie
Re: Death to win9x?
Austin English wrote: > >On Thu, Dec 2, 2010 at 8:00 PM, K.King wrote: >> <<< >> That's not useful. The whole point is that we don't want to spend the >> effort required to keep the tests error-free on platforms that we don't >> care about. That makes it easier to write tests for platforms that >> actually matter, which is a more productive use of everybody's time. >>>>> >> You may not care, but I know a number of people who do. >> For some running the older software is more important, of interest, or use. > >A majority of that effort is rewriting tests to make win9x happy, not >rewriting behavior to fix win9x applications. > >Few people (if any) want to intentionally break win9x applications, >but spending a large amount of developer effort to maintain the tests >there isn't really the best investment, when it could instead be spent >fixing real bugs. > This I do agree with. I'm working on tests for richedit and the expected reaction of the Win9x version is much different than the reaction of the WindowsXP version. I could drop the Win9x tests and concentrate on Windows 2000 and higher. Would this be a good course of action? James McKenzie
Re: Death to win9x?
Alexandre Julliard wrote: >Sent: Dec 2, 2010 6:30 AM >To: joerg-cyril.hoe...@t-systems.com >Cc: wine-devel@winehq.org >Subject: Re: Death to win9x? > > writes: > >> However, this only allows to run one test at a time, i.e. the big picture is >> missing. >> Therefore I'd suggest running winetest.exe on all testbot machines once a >> week >> or some such, e.g. only for releases. > >That's not useful. The whole point is that we don't want to spend the >effort required to keep the tests error-free on platforms that we don't >care about. That makes it easier to write tests for platforms that >actually matter, which is a more productive use of everybody's time. > YOU might not care about them AJ, but we have Wine users that are still using Windows95 programs with Wine on Linux and there are NO suitable replacements for them. Several recent user reports have asked how do I get program X (released for Windows95) to work on Wine. One of my test programs is dOOmII, released in 1996 and I use Wine to run it. Should I just go out and find a copy of Windows98SE and VirtualBox to run this on? Your reply makes it sound like the Wine program just does not care if Windows9x functionality does not matter, it does. I do agree that not much effort should be expended to incorporate more 'A' functionality, but breaking what does work is not reflect well on this project. Remember the original purpose and I think it is still the purpose is to build out the ENTIRE Windows64/32 API, not just a portion of it. If I'm wrong, feel free to chastise me. James McKenzie
Re: msvcrt: Fixed problem parsing multi-byte characters in _mbspbrk.
On 11/27/10 4:31 PM, William Gates wrote: On Sat, Nov 27, 2010 at 5:08 PM, James McKenzie wrote: On 11/26/10 11:41 AM, William Gates wrote: You have to send in patches with your real name. James McKenzie Who's to say this is not my real name? No one. However, you did submit patches as Nagato as well. That raises questions that might be answered with a comment in your patch submission. James McKenzie
Re: Added unit test suite for process functions (try 4)
On 11/27/10 9:03 AM, Borut Razem wrote: On 11/27/2010 03:48 AM, Marvin wrote: > process.c:133: Test failed: _pclose should return after 2 seconds, but it returned after 6 seconds It seems that the "paranoid android" Marvin was very busy... Looks like something else went busy too as I received about ten copies on the Wine Patches list. James McKenzie
Re: [PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo
On 11/26/10 12:15 AM, Damjan Jovanovic wrote: On Fri, Nov 26, 2010 at 6:56 AM, Vitaliy Margolen wrote: On 11/24/2010 07:19 PM, James McKenzie wrote: On 11/24/10 6:56 PM, Vitaliy Margolen wrote: On 11/24/2010 12:23 PM, jimpor...@gmail.com wrote: From: James Eder - while (fgets(line,200,f) != NULL) + while (fgets(line,450,f) != NULL) You might as well then change this to "sizeof(line)". Just for my edification, is there not a better way then setting the variable line to a flexible length for this purpose. Unless I didn't understand your question - you can't set a buffer to a "variable length". You have to provide fgets() a size of the buffer so it can read at most that many characters -1 for terminating \0. Vitaliy. So read lines dynamically instead: This is exactly what I was trying to get at. Thank you Damjan. James McKenzie
Re: [PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo
On 11/25/10 9:56 PM, Vitaliy Margolen wrote: On 11/24/2010 07:19 PM, James McKenzie wrote: On 11/24/10 6:56 PM, Vitaliy Margolen wrote: On 11/24/2010 12:23 PM, jimpor...@gmail.com wrote: From: James Eder - while (fgets(line,200,f) != NULL) + while (fgets(line,450,f) != NULL) You might as well then change this to "sizeof(line)". Just for my edification, is there not a better way then setting the variable line to a flexible length for this purpose. Unless I didn't understand your question - you can't set a buffer to a "variable length". You have to provide fgets() a size of the buffer so it can read at most that many characters -1 for terminating \0. Clarification: If we know the length of the input should we not set up the buffer to that length? If we don't know should we not set it to a maximum expected length that is a known value within the system? Pseudo code for known case: Length = # of characters in existing variable buffer [Length +1] use buffer... Pseudo code for unknown case: MaxLengthofCharacterString = 1024 buffer [MaxLengthofCharacterString] use buffer... Gets away from 'magic numbers' like 250 and 450. James McKenzie
Re: [PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo
On 11/24/10 6:56 PM, Vitaliy Margolen wrote: On 11/24/2010 12:23 PM, jimpor...@gmail.com wrote: From: James Eder -while (fgets(line,200,f) != NULL) +while (fgets(line,450,f) != NULL) You might as well then change this to "sizeof(line)". Just for my edification, is there not a better way then setting the variable line to a flexible length for this purpose. This might prevent 'growing' the variable over time. James McKenzie
