Re: advapi32: Correct tests under WOW64 (try 2)
Vitaliy Margolen wine-de...@kievinfo.com writes: On 03/10/2012 09:44 AM, André Hentschel wrote: Am 10.03.2012 17:37, schrieb Vitaliy Margolen: On 03/10/2012 12:36 AM, Alistair Leslie-Hughes wrote: Hi, Marked test as broken if it returns true. +/* WoW64 return TRUE with the LastError set */ +ok((!ret GetLastError() == ERROR_INSUFFICIENT_BUFFER) || broken(ret), %d with error %d\n, ret, GetLastError()); This is incorrect. You can check or report result of GetLastError(). But not both at the same time. You have to store the result in additional variable. Then compare and report it. Really? That's quite common practice. The value won't change between the two GetLastError() calls. It sure can change. Of course not. The only thing which is bad is if you test a function inside the ok() macro and report the last error in the same ok(). Isn't that what I said? To clarify, it applies to any printf type function that has call to GetLastError() as a parameter. There's nothing magical about printf. -- Alexandre Julliard julli...@winehq.org
Re: What happens upon mmdevapi capture overrun on native?
Hi, A. mmdevapi fills the whole buffer once. B. mmdevapi continuously overwrites the circular buffer. I think A makes sense but really I don't know. I suspect B I realized that I don't need a microphone if I can trust IAC_CaptureClient's pu64QPCPosition output parameter: the value of the performance counter at the time that the audio endpoint device recorded the device position of the first audio frame in the data packet. Modifying the capture tests to trace that value shows that mmdevapi mostly implements behaviour A with a few quirks. Please visit bug #30147 for details. Regards, Jörg Höhle
Re: Web based translation tool
Hi Dne Mon, 12 Mar 2012 12:02:49 +0200 Yaron Shahrabani sh.ya...@gmail.com napsal(a): The Wine project is thinking about using Weblate in order to translate Wine, you can look at the following discussion and see for yourself. That sounds great! Looking good although a litle immature, not sure about authentication as wel... For authentication you can basically use anything what can be used in Django. Any specific concerns on this topic? I'll talk to Michal Cihar and ask him for a roadmap for this project. Well I don't have any real roadmap right now. I urgently needed replacement for Pootle because we got hit by too many bugs there and did not manage to understand the code there to be able to fix them myself. So far I think it is in pretty good shape for day to day work (with today's 0.5 release fixing few annoying bugs). Of course there are some features missing, you can check what I plan for 1.0 release here: https://github.com/nijel/weblate/issues?state=openmilestone=1 I currently hope to have 1.0 in a month or so, but I really don't want to commit to any specific date. PS: I'm not subscribed to mailing list so please CC me on reply. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Fwd: Web based translation tool
This is Michal's reply to our conversation. Please keep him in CC for any further updates. Michal, thank you so much for joining this conversation! ☺ Kind regards, Yaron Shahrabani Hebrew translator -- Forwarded message -- From: Michal Čihař mic...@cihar.com Date: Mon, Mar 12, 2012 at 12:27 PM Subject: Re: Web based translation tool To: Yaron Shahrabani sh.ya...@gmail.com, wine-devel@winehq.org Hi Dne Mon, 12 Mar 2012 12:02:49 +0200 Yaron Shahrabani sh.ya...@gmail.com napsal(a): The Wine project is thinking about using Weblate in order to translate Wine, you can look at the following discussion and see for yourself. That sounds great! Looking good although a litle immature, not sure about authentication as wel... For authentication you can basically use anything what can be used in Django. Any specific concerns on this topic? I'll talk to Michal Cihar and ask him for a roadmap for this project. Well I don't have any real roadmap right now. I urgently needed replacement for Pootle because we got hit by too many bugs there and did not manage to understand the code there to be able to fix them myself. So far I think it is in pretty good shape for day to day work (with today's 0.5 release fixing few annoying bugs). Of course there are some features missing, you can check what I plan for 1.0 release here: https://github.com/nijel/weblate/issues?state=openmilestone=1 I currently hope to have 1.0 in a month or so, but I really don't want to commit to any specific date. PS: I'm not subscribed to mailing list so please CC me on reply. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Instructions for using JACK with with Wine's ALSA output on wiki: reverted twice
Vitaliy, On Sun, Mar 11, 2012 at 10:15:40AM -0600, Vitaliy Margolen wrote: That information simply does not belong on Wine wiki. It talks about making Jack work as Alsa sound device. This has nothing to do with Wine in particular. Especially that he posted the link to an external wiki which has most of this information. Let me make it a bit more clear, Wine is huge and it uses lots and lots of system libraries, packages, subsystems, features, and so on. Unless some information directly related to Wine it should not be posted on the Wine wiki. Or we'll end up with a huge collection of generic Linux/OS X/BSD/ARM/etc articles that will rot over time. Next time you're going to delete an entire half of a Wiki page that someone clearly cares about and maintains (see the edit history), please contact that someone first so we can discuss what should be done about the information that doesn't belong there. I agree that the Wiki isn't the best place for that code, and I was planning on getting around to fixing it. In the meantime, I had linked to that code in Bug 29294 and now it's not there for users to find. There is no emergency here that could not have been better resolved by a discussion over email. The fact that you've been specifically called out in two threads in one weekend might be a hint that it is _your_ behavior that is inappropriate. Andrew
Re: advapi32: Correct tests under WOW64 (try 2)
On 03/12/2012 03:23 AM, Alexandre Julliard wrote: Vitaliy Margolenwine-de...@kievinfo.com writes: On 03/10/2012 09:44 AM, André Hentschel wrote: Am 10.03.2012 17:37, schrieb Vitaliy Margolen: On 03/10/2012 12:36 AM, Alistair Leslie-Hughes wrote: Hi, Marked test as broken if it returns true. +/* WoW64 return TRUE with the LastError set */ +ok((!ret GetLastError() == ERROR_INSUFFICIENT_BUFFER) || broken(ret), %d with error %d\n, ret, GetLastError()); This is incorrect. You can check or report result of GetLastError(). But not both at the same time. You have to store the result in additional variable. Then compare and report it. Really? That's quite common practice. The value won't change between the two GetLastError() calls. It sure can change. Of course not. The only thing which is bad is if you test a function inside the ok() macro and report the last error in the same ok(). Isn't that what I said? To clarify, it applies to any printf type function that has call to GetLastError() as a parameter. There's nothing magical about printf. As always you right, my apologies. Was thinking about other code cleanup that was moving function calls outside of ok() check when also printing GetLastError(). Vitaliy.
Re: Instructions for using JACK with with Wine's ALSA output on wiki: reverted twice
On 03/12/2012 06:11 AM, Andrew Eikum wrote: Vitaliy, On Sun, Mar 11, 2012 at 10:15:40AM -0600, Vitaliy Margolen wrote: That information simply does not belong on Wine wiki. It talks about making Jack work as Alsa sound device. This has nothing to do with Wine in particular. Especially that he posted the link to an external wiki which has most of this information. Let me make it a bit more clear, Wine is huge and it uses lots and lots of system libraries, packages, subsystems, features, and so on. Unless some information directly related to Wine it should not be posted on the Wine wiki. Or we'll end up with a huge collection of generic Linux/OS X/BSD/ARM/etc articles that will rot over time. Next time you're going to delete an entire half of a Wiki page that someone clearly cares about and maintains (see the edit history), please contact that someone first so we can discuss what should be done about the information that doesn't belong there. Sorry, but I'm not going to do that. If you think that some, not Wine related, information belongs on Wine wiki, you better bring that question here. We already shot down a lot of attempts to host all sort of junk, including win API documentation. Which, if anything, more relates to Wine then how to make one sound device work like another sound device. I agree that the Wiki isn't the best place for that code, and I was planning on getting around to fixing it. In the meantime, I had linked to that code in Bug 29294 and now it's not there for users to find. There is no emergency here that could not have been better resolved by a discussion over email. What prevent you from attaching that code to the bug that needs it? And discussion with whom? That person has no wiki personal page, nor was he using a known nik associated with an e-mail. The fact that you've been specifically called out in two threads in one weekend might be a hint that it is _your_ behavior that is inappropriate. I've been called out in more then two threads, that doesn't bother me. That just an indication that no one else wants to do this work. Vitaliy.
Re: Instructions for using JACK with with Wine's ALSA output on wiki: reverted twice
On Mon, Mar 12, 2012 at 07:18:39AM -0600, Vitaliy Margolen wrote: On 03/12/2012 06:11 AM, Andrew Eikum wrote: On Sun, Mar 11, 2012 at 10:15:40AM -0600, Vitaliy Margolen wrote: That information simply does not belong on Wine wiki. It talks about making Jack work as Alsa sound device. This has nothing to do with Wine in particular. Especially that he posted the link to an external wiki which has most of this information. Let me make it a bit more clear, Wine is huge and it uses lots and lots of system libraries, packages, subsystems, features, and so on. Unless some information directly related to Wine it should not be posted on the Wine wiki. Or we'll end up with a huge collection of generic Linux/OS X/BSD/ARM/etc articles that will rot over time. Next time you're going to delete an entire half of a Wiki page that someone clearly cares about and maintains (see the edit history), please contact that someone first so we can discuss what should be done about the information that doesn't belong there. Sorry, but I'm not going to do that. If you think that some, not Wine related, information belongs on Wine wiki, you better bring that question here. We already shot down a lot of attempts to host all sort of junk, including win API documentation. Which, if anything, more relates to Wine then how to make one sound device work like another sound device. So host the content elsewhere and link to it. Revert wars on the Wiki are not going to accomplish anything or make anybody happy. If you can't or aren't willing to do that, then email someone who cares about the page and ask them to clean it up. There are more options here than delete the content without comment. See also: http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith We used to have JACK support, and we removed it. It makes sense to have some sort of fallback for JACK users, even if it's not supported. A very knowledgeable user found a setup that works well for him and offered that information to us. Rather than act like a jerk and tell him to go elsewhere with his information, I chose to take him up on his offer. If it doesn't belong on the Wiki in exactly that form, then let's work to find a better way to give that information to users. I agree that the Wiki isn't the best place for that code, and I was planning on getting around to fixing it. In the meantime, I had linked to that code in Bug 29294 and now it's not there for users to find. There is no emergency here that could not have been better resolved by a discussion over email. What prevent you from attaching that code to the bug that needs it? And discussion with whom? That person has no wiki personal page, nor was he using a known nik associated with an e-mail. If you browse the edit history for that page, you'll see that I edit it pretty frequently. Maybe I have an opinion? No lives are going to be lost if some inappropriate data is left on the Wiki for a weekend. The fact that you've been specifically called out in two threads in one weekend might be a hint that it is _your_ behavior that is inappropriate. I've been called out in more then two threads, that doesn't bother me. That just an indication that no one else wants to do this work. Or that no one wants this work done. Andrew
Re: GSoC 2011 - introduction
Il 09 marzo 2012 23:41, Józef Kucia joseph.ku...@gmail.com ha scritto: Hi, My name is Józef Kucia. I'm a Masters student in Computer Science at Wrocław University of Technology in Poland. I would like to apply for Google Summer of Code this year. I have a good knowledge of C and OpenGL. I also have limited experience with Direct3D and win32 programming. With regard to the Wine project, I'm familiar with the project from user perspective. I used to run some applications in Wine on my Gentoo Linux box, mostly games to be exact. Unfortunately, I haven't made any previous contributions to the Wine project, except submitting two small patches recently. I have read your project ideas for GSoC, and I am primarily interested in projects related to Direct3D. Nevertheless, I'm open to other projects. I would appreciate any suggestions or comments. Thanks, Józef Kucia Hi Józef, and welcome! Don't worry about not having contributed to Wine in the past, it's not important. Also, the patches you sent in the last few days make perfectly sense to me i.e. it shows you understand the code. About the project... that's the hard part. As Stefan wrote to another student interested in 3D-related GSOC projects, most of the missing stuff in wined3d is either too small or too big/hard for GSOC. We typically suggest to newcomers to just pick a game of their choice and make it run correctly on Wine, but that's not going to work for GSOC, essentially because you don't know how difficult it would be until you do it, while accountability is an important prerequisite for a project. So, while you can still try to follow this route, you'd need to figure out NOW what you'll be going to do during the project. Maybe implementing some easy pieces of d3d9ex or d3d10 (assuming there really are easy pieces to be done, I haven't really looked) is a possible alternative, but, again, hard to say. May be simpler to make a project out of d3dx9. There are still quite a few functions/object without an implementation and, at this point, a few of them (I'm thinking about mesh, surface and font functions, for example) are pretty much self contained. Probably you could choose an interesting subset of those for a project. Anyway, I'd suggest to look around in the code and/or Wine bugzilla and see if you find something interesting. Then just post a proposal of your own, we can adjust it if it looks too small or too big (it may very well happen that something which seems simple at first sight actually isn't, or even the other way around). You can also come by #winehackers on freenode, to further discuss this.
Re: [PATCH 4/5] msxml3: Added partial XMLView IPersistMoniker_Load implementation
Piotr Caban pi...@codeweavers.com writes: --- dlls/msxml3/xmlview.c | 908 - 1 files changed, 904 insertions(+), 4 deletions(-) This doesn't build without libxml (missing domdoc functions). -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 4/5] msxml3: Added partial XMLView IPersistMoniker_Load implementation
On 3/12/2012 18:44, Alexandre Julliard wrote: Piotr Cabanpi...@codeweavers.com writes: --- dlls/msxml3/xmlview.c | 908 - 1 files changed, 904 insertions(+), 4 deletions(-) This doesn't build without libxml (missing domdoc functions). This also kind of breaks implementation separation. You're doing a CoCreateInstance() and calling internal function in the same time, that relies on domdoc implementation. Why not to load it from url directly?
Re: mscoree: Better support RUNTIME_INFO_UPGRADE_VERSION in, GetRequestedRuntimeInfo (try 3)
-FIXME(Unrecognized version %s\n, debugstr_w(pwzVersion)); +WARN(Unrecognized version %s\n, debugstr_w(pwzVersion)); I'm not so sure about this. I think GetRuntime is still incomplete, so I'd still like to know when it fails. You will get a useless FIXME in the case where RUNTIME_INFO_UPGRADE_VERSION is specified, but I think a program that makes that specifies a version number and that flag is doing it wrong. Anyway, we shouldn't be spammed with fixme's, right?
Re: GSoC 2011 - introduction
Hi Jósef, (I've CCed Danien since this is relevant for him as well) I wanted to write an answer to your mail as well, but Matteo beat me to it :-) First of all, do not hesitate to submit more than one proposal. This gives us more flexibility in selecting compatible proposals should we happen to select two or more proposals in the same code area(d3d in your case). Generally it is discouraged to have two gsoc projects that depend on each other because problems will occur if one student cannot complete his proposal for some reason. Am Montag, 12. März 2012, 15:45:29 schrieb Matteo Bruni: Maybe implementing some easy pieces of d3d9ex or d3d10 (assuming there really are easy pieces to be done, I haven't really looked) is a possible alternative, but, again, hard to say. d3d9ex(not to be confused with d3dx9) may be an option. We have thunks already, and a few implemented features. The remaining features is mostly a matter of writing tests and preferably finding apps that use them. Some features like screen rotation may require extra work in user32.dll and winex11.drv. signature.asc Description: This is a digitally signed message part.
Re: [PATCH] po: Remove bad characters (C2 A0) from french translations.
On 3/12/2012 21:52, Christian Costa wrote: They are displayed as a single space in a text editor but visible with an hex editor. I guess this is a non-breakable space.
Re: [PATCH] po: Remove bad characters (C2 A0) from french translations.
Le 12/03/2012 21:02, Nikolay Sivov a écrit : On 3/12/2012 21:52, Christian Costa wrote: They are displayed as a single space in a text editor but visible with an hex editor. I guess this is a non-breakable space. I don't know. Anyway it produces garbage for what the string is used for so the patch still applies. I will resend the patch with a description that reflects that.
Re: kernel32: Make CreateFile called with creation == 0 work when opening a vxd in win9x mode.
* On Sun, 11 Mar 2012, Dmitry Timoshkov wrote: A widely used approach to open/load device drivers under win9x is /* Check if already loaded in system.ini */ hvxd = CreateFile(.\\mydevice, 0, 0, 0, 0, 0, 0); if (hvxd == INVALID_HANDLE_VALUE) /* Load dynamically from PATH */ hvxd = CreateFile(.\\path\\to\\mydevice.vxd, 0, 0, 0, CREATE_NEW, FILE_FLAG_DELETE_ON_CLOSE, 0); First call never succeeds under Wine, and some device drivers refuse to load more than once. Are there any proof one can see? What application does behave like this? Where has this source excerpt come from? S.
Preprocessing asm shaders
Hi, I'm writing because I found a bug in asm shader preprocessor in Wine and I'm not sure what's the best way to fix it. The D3DPreprocess function is an universal shader preprocess for HLSL and asm shaders. In fact, it's C-like language preprocessor and it doesn't understand assembler style comments (comments from ';' to the end of line). The fact that it doesn't understand these comments is a root of whole problem. Valid asm shaders can contain single or double quotation characters in assembler style comments, and these quotation characters will be treated as a beginning of quoted string constants while preprocessing. The Wine's implementation of D3DPreprocess behaves differently than Windows implementation in respect to strings passing the end of line. Generally, strings passing the end of line are an error in C, but they can result in a correct asm shader when contained in a assembler style comment. D3DPreprocess on Windows works fine for shaders which contains single or double quotation marks. It only issues an error in case of unmatched double quotation mark, but returns D3D_OK anyway. In Wine situation is different, wpp tries to find a matching quotation mark to the end of file, while shader preprocessor on Windows gives up on parsing a string when it gets a first newline character. The result of wpp's behavior is a truncated output and an error returned from D3DPreprocess. I wonder if it's fine to change wpp behavior for strings passing the end of line to mimic the behavior observed on Windows. Perhaps, strings passing the end of line could be treated as an error by default. Whereas D3DCompiler would activate an option to treat such strings as a warning. Thanks, Józef Kucia
Re: Preprocessing asm shaders
Am Montag, 12. März 2012, 22:13:45 schrieb Józef Kucia: I wonder if it's fine to change wpp behavior for strings passing the end of line to mimic the behavior observed on Windows. Perhaps, strings passing the end of line could be treated as an error by default. Whereas D3DCompiler would activate an option to treat such strings as a warning. My first guess would be to see how other users of wpp are behaving, or are supposed to behave. grep claims that the other parts of Wine that use wpp are toold/widl and tools/wrc. Beyond those it's probably a good idea to keep HLSL in mind, even if we don't have a HLSL compiler yet. What I don't know is if/how you can write proper tests for widl and wrt. They have counterparts on Windows(midl and windres afaik), but they live in tools/ and not programs/ in the Wine source.
Re: [PATCH] po: Remove bad characters (C2 A0) from french translations.
Le 12/03/2012 20:32, Christian Costa a écrit : Le 12/03/2012 21:02, Nikolay Sivov a écrit : On 3/12/2012 21:52, Christian Costa wrote: They are displayed as a single space in a text editor but visible with an hex editor. I guess this is a non-breakable space. I don't know. Anyway it produces garbage for what the string is used for so the patch still applies. I will resend the patch with a description that reflects that. BTW, is there an editor that shows them ? gvim doesn't. Non-breakable space are only present in french translations. Between a name and a ':'. This is not nicer to me. I wondering if that would not be better to remove them all...
Re: Preprocessing asm shaders
On Mon, Mar 12, 2012 at 11:31 PM, Stefan Dösinger wrote: My first guess would be to see how other users of wpp are behaving, or are supposed to behave. grep claims that the other parts of Wine that use wpp are toold/widl and tools/wrc. Beyond those it's probably a good idea to keep HLSL in mind, even if we don't have a HLSL compiler yet. I'll make some tests to check how wrc and widl should behave. However I'm not sure if submitting tests for wrc and widl would be welcome. We don't have any tests for these tools yet and I can imagine not everyone, who's running the tests on Windows, has Visual Studio or SDK installed. Perhaps such tests could rely on presence of these tools in PATH, and would be skipped in case of their absence. Does it make any sense?
Problem with Precise beta 1, unity-3d, and wine menus?
Hi all, on Precise beta 1 logged in with unity-3d, giving the command wine winemine and then clicking on the Game menu usually results in only a small part of the pulldown menu showing up. (Also shows up in many other apps that use menus, e.g. mspaint.) This is not a problem in unity 2d, or in Ubuntu 11.10 with unity 3d. Using virtual desktop, or telling the window manager to not manage windows, works around the problem. In all cases, I'm using the commercial nvidia drivers supplied by ubuntu (for precise, version 295.20; for 11.10, version 280.13), so I'm not sure if the problem is the new X, or the new drivers. Before I go reporting an ubuntu bug, or jamming newer drivers into my older ubuntu system, has anybody else noticed this?
