April 2008 - Wine-devel - list.winehq.org

Translating Wine with PO files
by Dwayne Bailey 22 Apr '08

22 Apr '08

Hi, I've just completed a tool for converting resource files (.rc) to Gettext PO. http://translate.sourceforge.net/wiki/toolkit/rc2po This should allow many more FOSS translators to add translations to Wine, hopefully before the 1.0 release. In some ways this is a response to some issues raised in the 'Translations and Wine 1.0' thread: http://thread.gmane.org/gmane.comp.emulators.wine.devel/58000 further into this email I offer some comments on the issues raised in that thread. My suggestion is to deploy a Pootle server: http://translate.sourceforge.net/wiki/pootle/index The new RC tool, rc2po, is part of the Translate Toolkit, a general translation conversion toolkit and localisation library. http://translate.sourceforge.net/wiki/toolkit/index I've cut 1.2-alpha1 for those who want to give it a spin. We've just started work on v1.2 so the toolkit is mature, started in 2002, and the alpha status is simply an indication that we've got quite a while before 1.2 official. Download it from here: http://translate.sourceforge.net/snapshots/ Status of rc2po: ---------------- * Its very new - I've done roundtrip testing and some translating in ummm pig latin :) but will begin more serious Afrikaans translation soon. So I expect to see some bugs. * It can handle: DIALOG*, MENU, LANGUAGE, STRINGTABLE * You can't change the dialog sizes - I have some ideas of how we could do this in PO but its not implemented at all How it works: ------------- Make POT files: rc2po -P some.rc some.pot Recover old translations: rc2po -t some.rc translated.rc translated.po Make rc files: po2rc --lang=LANG_XXX -t some.rc translated.po translated.rc The wiki page provides clearer usage examples: http://translate.sourceforge.net/wiki/toolkit/rc2po Things to be aware of --------------------- * You cannot tweak the translations in .rc and hope to keep things in sync with PO, you'll need to only work in PO files or make sure any tweaks you make in your .rc you copy to the .po. * You cannot change the sizes of the dialogues in your translation for the above reason. This should change in the future to allow you to 'translate' the sizes. * Recovered translations need to be fully reviewed as we can't determine if your translation is based on the same English text. * We cannot create multi-language .rc files, you'll need one languages in each file. * We can read multilingual files but will only take the first language and drop anything after that, since PO files can only contain one language this makes sense. * We don't do any changes to the Makefiles, you'll have to do those by hand. But it would probably be easy to create a simple bash script or change the build system to automagically include all xxx_yy.rc files. * We handle encoding issues but prefer UTF-8 throughout. How you can help ---------------- * By testing rc2po and po2rc * Help implement a solution to allow size changes * Report bugs on http://bugs.locamotion.org Getting help ------------ * On IRC: irc://irc.freenode.net/#pootle * Mailing list: http://lists.sourceforge.net/lists/listinfo/translate-devel * Wiki: http://translate.sourceforge.net/wiki/toolkit/rc2po Suggested localization infrastructure for Wine ---------------------------------------------- In the thread 'Translation and Wine 1.0': http://thread.gmane.org/gmane.comp.emulators.wine.devel/58000 there was some discussion about localization infrastructure for wine. I'd like to suggest that Wine looks at using Pootle: http://translate.sourceforge.net/wiki/pootle/index this is already in use by projects such as OLPC, OpenOffice.org and others. It can manage PO files, commit to various VC systems (including Git), allows suggestions, does various QA checks and allows download and submission of PO files, has translation memory and glossary suggestions, statistics, etc, etc. A hosting option is to put the files on http://pootle.locamotion.org but I would request someone from the Wine community to take charge of keeping the PO files up-to-date and authorising users, etc. I would however encourage the Wine community to run its own server. This would make it easier to commit files directly into Git. I would suggest some work to ensure that POT files, updating of PO files and conversion back to .rc are automatic. Being within the control of the Wine community makes this easier. Launchpad is not an options unless you convert to PO using the above rc2po. Pootle has the advantage that you can run your own server, you don't have that with Launchpad. -- Dwayne Bailey Translate.org.za +27-12-460-1095 (w) +27-83-443-7114 (cell)

1 0

Re: kernel32: Fix a test that fails on all NT platforms
by Paul Vriens 22 Apr '08

22 Apr '08

James Hawkins wrote: > Hi, > > Changelog: > * Fix a test that fails on all NT platforms. > > dlls/kernel32/tests/toolhelp.c | 12 +++++++++--- > 1 files changed, 9 insertions(+), 3 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi James, I've been looking at some of the patches to fix the tests but I'm a bit unsure if some of them are the correct way to go. Things like: + /* win9x does not return a thread, NT does */ te.dwSize = sizeof(te); - ok(!pThread32First( hSnapshot, &te ), "shouldn't return a thread\n"); + ret = pThread32First( hSnapshot, &te ); + ok(ret || !ret, "You'll never see this\n"); renders the whole test useless. It turns out that win9x in this case leaves te.dwSize and XP-and-up set te.dwSize to 0. Shouldn't we make use of that fact? So something like (or another combination): if (te.dwSize == 0) { XP-and-up, expect failure } else if (te.dwSize == sizeof(te)) { win9x, expect success } else { something is wrong/unexpected } On a sidenote (and this has been the case for a long time): I've seen patches where ok(function(a,b),"Failed"); is turned into c = function(a,b); if (c) { ..... } but done without a skip or such. So if Wine has a regression for 'function' we won't notice. We have loads of patches where we expect 3 or more different last errors. This will make sure the tests always succeed of course but makes it difficult to tell if we (Wine) are doing the correct/best thing. -- Cheers, Paul.

2 3

Re: Secure filename copy to fixed size variable wfileName
by Dmitry Timoshkov 22 Apr '08

22 Apr '08

"Tomasz Jezierski - Tefnet" <developers(a)tefnet.pl> wrote: > - strcpyW(wfileName, sei_tmp.lpFile); > + StrCpyNW(wfileName, sei_tmp.lpFile,sizeof(wfileName)); > } > } else > - strcpyW(wfileName, sei_tmp.lpFile); > + StrCpyNW(wfileName, sei_tmp.lpFile,sizeof(wfileName)); Your patch doesn't make the code more secure than it is now. StrCpyNW takes number of characters, not bytes. And since it's just a wrapper around lstrcpynW it's better to use the latter one instead. -- Dmitry.

1 0

Strange struct alignment errors?
by Dan Kegel 22 Apr '08

22 Apr '08

http://test.winehq.org/data/94883af56d7348228963d7e70a5af578310c2228/wine_x… looks kinda funny. Is somebody compiling the tests wrong somehow?

3 3

Re: version: Fix tests that fail in win9x and win2k
by Alistair Leslie-Hughes 22 Apr '08

22 Apr '08

James Hawkins wrote: > Hi, > > Changelog: > * Fix tests that fail in win9x and win2k. > > dlls/version/tests/info.c | 29 +++++++++++++++++++---------- > 1 files changed, 19 insertions(+), 10 deletions(-) > Hi James, No patch attached. Best Regards Alistair Leslie-Hughes

1 0

Re: [1/4] dinput: Return error for unknown property.
by Vitaliy Margolen 22 Apr '08

22 Apr '08

Sergey Khodych wrote: > > > - WARN("Unknown property %s\n", debugstr_guid(rguid)); > - break; > + FIXME("Unknown property %s\n", debugstr_guid(rguid)); > + return DIERR_UNSUPPORTED; I'd like to see tests for this. Also lots of programs will break because they won't get some not significant property. No short - don't do this. Vitaliy

2 2

Re: gdi32: Make the bitmap test pass under Windows 2000
by Alexandre Julliard 21 Apr '08

21 Apr '08

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > @@ -967,15 +970,19 @@ static void test_bitmap(void) > hdc = CreateCompatibleDC(0); > assert(hdc != 0); > > +if (0) > +{ /* this test fails under Win2k */ > SetLastError(0xdeadbeef); > hbmp = CreateBitmap(0x7ffffff, 1, 1, 1, NULL); > ok(hbmp != 0, "CreateBitmap should not fail\n"); > DeleteObject(hbmp); > +} It would be better to find values that work on all platforms, instead of disabling the test completely. -- Alexandre Julliard julliard(a)winehq.org

5 8

Re: Alternative for isinf (fix for bug 12008) (version 2)
by Francois Gouget 21 Apr '08

21 Apr '08

+#if !defined(HAVE_ISINF) && defined(HAVE_IEEEFP_H) +#include <ieeefp.h> +#define isinf(x) (!(finite(x) || isnand(x))) +#endif The problem with macros is that something like isinf(*x++) won't do what you intend. That's why even for such a simple case a function would be better imho. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

1 0

d3dx9: Texturing functions
by tony.wasserka＠freenet.de 21 Apr '08

21 Apr '08

Hi all, as it's a larger chunk of functions, I felt like proposing my design idea for the D3DXCreateTexture/Volume/CubeTextureFromFile/Resource/FileInMemory/etc... functions. I'm CC'ing it to any wine d3dx coder I have in my addressbook yet, so sorry if I forgot one :) So, the first thing I want to make sure is that we redirect the function calls correctly in order to reduce double coding. This means on the one hand that we should call the Extended versions of each function from inside of the simpler ones (most default parameters for the Ex functions are on MSDN) and on the other hand that we unify all D3DXCreateTextureFromXXEx functions somehow. I don't know how Resources are stored internally, but I guess the simplest would be to redirect all of them to D3DXCreateTextureFromFileInMemory, i.e. when D3DXCreateTextureFromFile is called we read the file into memory and call the InMemory function. I hope this shouldn't be too hard to be applied to the resource function either. Of course, this should also be done at the corresponding Surface, Volume and cube texture functions. Also, I haven't looked too much into it yet, but I guess we could go even a step further and define the CreateTextuteFromXX calls like this: 1. Redirect to the corresponding D3DXCreateXFromFileInMemoryEx call 2. Call D3DXCheckXRequirements 3. Call IDirect3DDevice9::CreateTexture 4. Lock its surface 5. Call LoadSurfaceFromFileEx with it This would reduce most of our coding work on LoadSurfaceFromFileEx. However, there are still plenty of formats supported by the texturing functions and thus, plenty of work for us to do. IIRC we once came to the decision to use libraries like libpng or so to reduce that work, too, so we'd just need to implement formats like .dds. And the last thing I'd like to ask goes to Louis Lenders: I've just found out that you have been working on a D3DXCreateTextureFromFile implementation. Are you still working on that? I'm really looking forward to do some coding work again, so I could continue your implementation from the 24th March if you've stopped to work on it ;-) However, feel free to comment on my proposals for the texturing functions and tell me if you see any concerns with it :) Best regards, Tony Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

2 1

Some XDC update
by Stefan Dösinger 21 Apr '08

21 Apr '08

Hi, Here's a short summary of the wine-related things that were going on on XDC: -> Mouse input: Daniel Stone will take care of that. He says DGA would give us what we want, but recommends not to use it. He is working on extending XInput(or making a new XI2) which can report relative mouse movements. The X people want to phase out DGA. Some games use it for relative input, so they'll make a DGA emulation layered on the new XInput stuff. He will need debugging / testing help from us since Wine will most likely be the only App making use of that directly. Also we should not hold our breath, he has some other items on his TODO list, but the end of 2008 is a plausible ETA. -> Tablets: Config issue is known and being worked on -> Graphics, general: The Mesa and ATI people are willing to help out with our issues. I talked to Aaron Plattner and Pierre ? from Nvidia, and they know the issues and worked on some extensions for that internally some time ago, but then decided that they're not going to implement that for some reason they didn't tell me(I hope they re-consider that now that someone is asking for it though). The ATI guys warned me that it might take a while until any new extensions are available in production drivers, but that's something we have to put up with I guess. Also both the ATI and Mesa people like the idea of using our conformance tests for their driver testing and debugging. The Nvidia guys offered help with the multithreading crashes and the 32 vs 40 varying issue. (I also talked to Ben Byer from Apple, but he's not in charge of the graphics drivers) -> Graphics: Flat shading: Picking that as a first case for working on an extension. Should be fairly easy to implement in Mesa since all cards have a specific register for exactly that issue. -> Graphics, multithreading: general agreement that what we are doing is correct, and driver bugs need fixing. It looks like the crash in fglrx will be fixed soon(my test app worked in Matthew's development driver). For the Nvidia issues I'll file a bugreport as soon as I know if the glxSwapBuffers crash is a driver or Gentoo bug) -> Graphics, sRGB blending: Everyone believes me that our emulation is slow("pow() - uh oh, don't use that, that's not parallelizeable"[Keith Packard]). The nvidia people are aware of the issue, but a fix is also unlikely. The ATI people aren't sure if their dx9 hardware supports sRGB writing, maybe the windows driver is emulating things as well - have to check -> Graphics, GLSL issues: MOVA and LIT, possibly extensions for that. -> Graphics, Hacks: Both the ATI and Nvidia developers warned me that their Windows drivers have a huge per-application bug workaround database. Aaron was pretty impressed that Wine doesn't have any app-specific hacks. I am afraid we will need them, as some apps seem to expect different behavior that our d3d9 tests get. I think the best way is to fetch some information about the Windows driver hacks and write tests which trigger them to show that "hl2.exe" gets different driver behavior than "d3d9_test.exe"(or in whatever way things work)

2 1