June 2010 - Wine-Devel - list.winehq.org

Re: [PATCH] [try 4] ddraw: Grow indexbuffer as needed

by Alexandre Julliard

Mikko Rasa <tdb(a)tdb.fi> writes: > + /* check that the buffer is large enough to hold the indices, > + * reallocate if necessary. > + */ > + hr = IWineD3DBuffer_GetDesc(This->indexbuffer, &desc); > + if(desc.Size < IndexCount * sizeof(WORD)) > + { > + UINT size = desc.Size; > + IWineD3DBuffer *buffer; > + IUnknown *parent; > + > + while(size < IndexCount * sizeof(WORD)) > + { > + size <<= 1; > + /* We keep adding zero bits to the right, so an overflow > + * will eventually result in all zeroes. Detect this to > + * avoid infinite loop. > + */ > + if(!size) > + { > + ERR("UINT overflow while trying to grow indexbuffer to hold %u indices\n", IndexCount); > + LeaveCriticalSection(&ddraw_cs); > + return D3DERR_TOOMANYPRIMITIVES; > + } > + } A simple "size = max(desc.Size*2,IndexCount*sizeof(WORD))" would do just as well. -- Alexandre Julliard julliard(a)winehq.org

June 25, 2010

Re: Addition of En resources to non-En resources

by Francois Gouget

On Fri, 25 Jun 2010, Dmitry Timoshkov wrote: > Francois Gouget <fgouget(a)free.fr> wrote: > > > Requiring that translators master both skills severly limits the pool of > > translators we can draw from. > > Doesn't this sound similar to so called limitation that exists for people > willing to work on Wine code, but have no appropriate skills? Absolutely not. For the coding part there is no other choice. For translations we can do better by reusing existing tools. [...] > Sounds not very exciting. If there is a choice of having resources with properly > placed and sized controls but english only, vs. translated but with broken layout > ones, then I'm afraid most users would prefer an english variant. You seem to think that the current situation results in a few translations with perfectly laid out dialogs. I did a few simple tests that make me pretty skeptical of that: dlls/comdlg32/cdlg_En.rc: LTEXT "List Files of &Type:", 1089, 6, 104, 90, 9 dlls/comdlg32/cdlg_Eo.rc: LTEXT "Dosier&speco:", 1089, 6, 104, 90, 9 dlls/comdlg32/cdlg_Wa.rc: LTEXT "Djveye des fitchs del sr&te:", 1089, 6, 104, 90, 9 dlls/comdlg32/cdlg_Fi.rc: LTEXT "&Luettele tiedostot tyypeittin:", 1089, 6, 104, 90, 9 [27 more] dlls/msvfw32/msvfw32_En.rc: PUSHBUTTON "&About...",883,129,52,49,14 dlls/msvfw32/msvfw32_Da.rc: PUSHBUTTON "O&m...",883,129,52,49,14 dlls/msvfw32/msvfw32_Ru.rc: PUSHBUTTON "&Информация...",883,129,52,49,14 dlls/msvfw32/msvfw32_Uk.rc: PUSHBUTTON "&Інформація...",883,129,52,49,14 [14 more] dlls/shell32/shell32_Ja.rc: LTEXT "Wine was brought to you by:", IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 dlls/shell32/shell32_Es.rc: LTEXT "Wine le ha sido proporcionado por:", IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 dlls/shell32/shell32_Si.rc: LTEXT "Wine smo ustvarili:", IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 dlls/shell32/shell32_Sv.rc: LTEXT "Wine hade inte varit mjligt utan dessa personer:", IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 [18 more] dlls/winspool.drv/En.rc: LTEXT "&Output File Name:", -1, 7, 13, 194, 13, WS_VISIBLE dlls/winspool.drv/Pl.rc: LTEXT "&Nazwa pliku do ktrego ma by zapisany wydruk:", -1, 7, 13, 194, 13, WS_VISIBLE dlls/winspool.drv/No.rc: LTEXT "&Ut-fil:", -1, 7, 13, 194, 13, WS_VISIBLE [19 more] These were picked at random. Isn't it strange how all these translated controls have the same size as the English version despite widely different text content? So in fact all you get with the status-quo is few translations *AND* broken dialog layouts. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

June 25, 2010

Re: Addition of En resources to non-En resources

by Dmitry Timoshkov

Michael Stefaniuc <mstefani(a)redhat.com> wrote: > > How is that different from transalting an .rc file and generating a patch from > > the resulting translation? > For Alexandre there is no difference; he gets a patch on wine-patches > and does his emacs magic on it. But we do not care about Alexandre here ;) > > For the translator it is a matter of just pressing "Submit" in the web > translation tool he used. I hope I don't have to explain the differences > to the manual git way... ;) So, is it Alexandre or somebody else who is responsible for verifying that the translation is acceptable, and doesn't break existing layout of controls, and doesn't break other things because the translator simply didn't see things like a requirement written in capital letters in comdlg32 .rc files that common dialogs should not be resized? -- Dmitry.

June 25, 2010

Re: Addition of En resources to non-En resources

by Michael Stefaniuc

Dmitry Timoshkov wrote: > Michael Stefaniuc <mstefani(a)redhat.com> wrote: > >>>>>> What we see is that there are several people who want to help us with >>>>>> the translation part but have no idea how to code (or are actually >>>>>> willing to code). We could use them, especially for the more exotic (or >>>>>> let's call it less mainstream) languages. >>>>> Since when the editing of .rc files started to require coding skills? >>>> Fine, let's call it editing an up to date file and creating a patch out >>>> of that. >>> Creating an actual patch could be done someone else of course. I'm just >>> curious, how the result of translating a .po file was supposed to be sent? >>> Isn't it going to be a patch of some kind in any case? >> Yes, but that can be automatically generated by the web based >> translation tool we use. There are a few to choose from. > > How is that different from transalting an .rc file and generating a patch from > the resulting translation? For Alexandre there is no difference; he gets a patch on wine-patches and does his emacs magic on it. But we do not care about Alexandre here ;) For the translator it is a matter of just pressing "Submit" in the web translation tool he used. I hope I don't have to explain the differences to the manual git way... ;) bye michael

June 25, 2010

Re: Addition of En resources to non-En resources

by Dmitry Timoshkov

Michael Stefaniuc <mstefani(a)redhat.com> wrote: > >>>> What we see is that there are several people who want to help us with > >>>> the translation part but have no idea how to code (or are actually > >>>> willing to code). We could use them, especially for the more exotic (or > >>>> let's call it less mainstream) languages. > >>> Since when the editing of .rc files started to require coding skills? > >> Fine, let's call it editing an up to date file and creating a patch out > >> of that. > > > > Creating an actual patch could be done someone else of course. I'm just > > curious, how the result of translating a .po file was supposed to be sent? > > Isn't it going to be a patch of some kind in any case? > Yes, but that can be automatically generated by the web based > translation tool we use. There are a few to choose from. How is that different from transalting an .rc file and generating a patch from the resulting translation? -- Dmitry.

June 25, 2010

Re: Addition of En resources to non-En resources

by Paul Vriens

On 06/25/2010 12:08 PM, Dmitry Timoshkov wrote: > Paul Vriens<paul.vriens.wine(a)gmail.com> wrote: > >>>> What we see is that there are several people who want to help us with >>>> the translation part but have no idea how to code (or are actually >>>> willing to code). We could use them, especially for the more exotic (or >>>> let's call it less mainstream) languages. >>> >>> Since when the editing of .rc files started to require coding skills? >> >> Fine, let's call it editing an up to date file and creating a patch out >> of that. > > Creating an actual patch could be done someone else of course. I'm just > curious, how the result of translating a .po file was supposed to be sent? > Isn't it going to be a patch of some kind in any case? > I'm actually not sure if somebody already has an idea how to approach this. I guess that we will end up with both resource files and po files in our tree and that we indeed will have patches to po files as well. The difference however could be that we could have a translation tool in place (for example Pootle if that's viable) that automatically generates the patches and sends them to wine-patches. One can even think of some 'approval layer' in between to verify if the translations actually messes up the layout. Why don't we add this as a nice topic for the next WineConf? -- Cheers, Paul.

June 25, 2010

Re: Addition of En resources to non-En resources

by Michael Stefaniuc

Dmitry Timoshkov wrote: > Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > >>>> What we see is that there are several people who want to help us with >>>> the translation part but have no idea how to code (or are actually >>>> willing to code). We could use them, especially for the more exotic (or >>>> let's call it less mainstream) languages. >>> Since when the editing of .rc files started to require coding skills? >> Fine, let's call it editing an up to date file and creating a patch out >> of that. > > Creating an actual patch could be done someone else of course. I'm just > curious, how the result of translating a .po file was supposed to be sent? > Isn't it going to be a patch of some kind in any case? Yes, but that can be automatically generated by the web based translation tool we use. There are a few to choose from. bye michael

June 25, 2010

Re: Addition of En resources to non-En resources

by Dmitry Timoshkov

Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > >> What we see is that there are several people who want to help us with > >> the translation part but have no idea how to code (or are actually > >> willing to code). We could use them, especially for the more exotic (or > >> let's call it less mainstream) languages. > > > > Since when the editing of .rc files started to require coding skills? > > Fine, let's call it editing an up to date file and creating a patch out > of that. Creating an actual patch could be done someone else of course. I'm just curious, how the result of translating a .po file was supposed to be sent? Isn't it going to be a patch of some kind in any case? -- Dmitry.

June 25, 2010

Re: Addition of En resources to non-En resources

by Paul Vriens

On 06/25/2010 11:44 AM, Dmitry Timoshkov wrote: > Paul Vriens<paul.vriens.wine(a)gmail.com> wrote: > >>>> For the actual resources and their size/placements it would be nice to >>>> have a tool/website as well that could be used to show how the >>>> translated language actually looks in a menu/dialog/whatever with even >>>> the possibility to change things. Is that feasible? >>> >>> What's wrong with running a test application with those menus/dialogs >>> under Wine? What's the reason to complicate things by separating tasks >>> of translating and verifying the result of the translation? >>> >> >> Well, nothing is wrong with that I guess. It's however geared to people >> who are coders, not? > > Of course not, that's proven by the amount of new translations we see these > days from new people, who apparently are not coders. Yes, but that also sometimes requires volunteers to do the actual work (editing the resource files and creating patches) for them. I mean, I did a lot of work for Danish and Michael is doing the same for Romanian. It would be much nicer if that can be automated in some way. > >> What we see is that there are several people who want to help us with >> the translation part but have no idea how to code (or are actually >> willing to code). We could use them, especially for the more exotic (or >> let's call it less mainstream) languages. > > Since when the editing of .rc files started to require coding skills? Fine, let's call it editing an up to date file and creating a patch out of that. -- Cheers, Paul.

June 25, 2010

Re: Addition of En resources to non-En resources

by Dmitry Timoshkov

Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > >> For the actual resources and their size/placements it would be nice to > >> have a tool/website as well that could be used to show how the > >> translated language actually looks in a menu/dialog/whatever with even > >> the possibility to change things. Is that feasible? > > > > What's wrong with running a test application with those menus/dialogs > > under Wine? What's the reason to complicate things by separating tasks > > of translating and verifying the result of the translation? > > > > Well, nothing is wrong with that I guess. It's however geared to people > who are coders, not? Of course not, that's proven by the amount of new translations we see these days from new people, who apparently are not coders. > What we see is that there are several people who want to help us with > the translation part but have no idea how to code (or are actually > willing to code). We could use them, especially for the more exotic (or > let's call it less mainstream) languages. Since when the editing of .rc files started to require coding skills? -- Dmitry.

June 25, 2010

Re: Addition of En resources to non-En resources

by Nikolay Sivov

On 6/25/2010 13:29, Paul Vriens wrote: > On 06/25/2010 11:23 AM, Dmitry Timoshkov wrote: >> Paul Vriens<paul.vriens.wine(a)gmail.com> wrote: >> >>> For the actual resources and their size/placements it would be nice to >>> have a tool/website as well that could be used to show how the >>> translated language actually looks in a menu/dialog/whatever with even >>> the possibility to change things. Is that feasible? >> >> What's wrong with running a test application with those menus/dialogs >> under Wine? What's the reason to complicate things by separating tasks >> of translating and verifying the result of the translation? >> > > Well, nothing is wrong with that I guess. It's however geared to > people who are coders, not? > > What we see is that there are several people who want to help us with > the translation part but have no idea how to code (or are actually > willing to code). We could use them, especially for the more exotic > (or let's call it less mainstream) languages. > Hi. Personally I don't see anything complicated or wrong about using .rc files, but yes, it's a bit painful for a contributor that wants to spend some time and discovers that he needs to do some rebuild-n-resize iterations to make it look nice. So correct me if I'm wrong - a po file could be tested without rebuild, right? For a problem with adjusting sizes we could find some free resource GUI tool I guess that creates a dialog as a IDE form designer, and allows for changes made to go directly to rc (with a way to simply switch languages of course). If there's a such way to do I don't see any problem for a non-coders to make changes.

June 25, 2010

Re: Addition of En resources to non-En resources

by Frédéric Delanoy

On Fri, Jun 25, 2010 at 11:14, Paul Vriens <paul.vriens.wine(a)gmail.com>wrote: > On 06/25/2010 11:04 AM, Dmitry Timoshkov wrote: > >> Francois Gouget<fgouget(a)free.fr> wrote: >> >>> We will still need people to take on the somwhat unsexy control resizing >>> >>> task and that may be a problem. If it turns out we lack volunteers for >>> that we may turn to some automatic layout scheme, for instance describe >>> the resources in a glade-like language and translate+convert them to rc >>> files at build time. >>> >> >> Sounds not very exciting. If there is a choice of having resources with >> properly >> placed and sized controls but english only, vs. translated but with broken >> layout >> ones, then I'm afraid most users would prefer an english variant. >> > > Once we start using po files we can probably get rid of the 'transl' > website as those stats will come from whatever tool we choose to deal with > po files. > > For the actual resources and their size/placements it would be nice to have > a tool/website as well that could be used to show how the translated > language actually looks in a menu/dialog/whatever with even the possibility > to change things. Is that feasible? > Why reinventing the wheel? Such a tool already exists (ResHacker or similar). What we should do to attract more people is to provide a more "user-friendly" web page/ translator page explaining in greater detail: - how to find what has to be translated (translation statistics, .rc files, ...) - how to edit a file (#pragma code_page, encoding, menu accelerators, ...) - how to check/adapt actual results with ResHacker, since you have to either adapt the text to fit in, or the dialogs size) - how to create a patch OR send it to e.g. translation(a)winehq.org for inclusion I may help in doing this. Furthermore, on the main web page, "Development - Become a Wine developer" can be intimidating for some potential translators (most non-developers potential translators would not consider themselves... well... developers!). Maybe something like "Contribute - How you can help" (or similar) would be less repulsive. Frédéric

June 25, 2010

Re: Addition of En resources to non-En resources

by Paul Vriens

On 06/25/2010 11:23 AM, Dmitry Timoshkov wrote: > Paul Vriens<paul.vriens.wine(a)gmail.com> wrote: > >> For the actual resources and their size/placements it would be nice to >> have a tool/website as well that could be used to show how the >> translated language actually looks in a menu/dialog/whatever with even >> the possibility to change things. Is that feasible? > > What's wrong with running a test application with those menus/dialogs > under Wine? What's the reason to complicate things by separating tasks > of translating and verifying the result of the translation? > Well, nothing is wrong with that I guess. It's however geared to people who are coders, not? What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages. -- Cheers, Paul.

June 25, 2010

Re: Addition of En resources to non-En resources

by Dmitry Timoshkov

Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > For the actual resources and their size/placements it would be nice to > have a tool/website as well that could be used to show how the > translated language actually looks in a menu/dialog/whatever with even > the possibility to change things. Is that feasible? What's wrong with running a test application with those menus/dialogs under Wine? What's the reason to complicate things by separating tasks of translating and verifying the result of the translation? -- Dmitry.

June 25, 2010

Re: Addition of En resources to non-En resources

by Paul Vriens

On 06/25/2010 11:04 AM, Dmitry Timoshkov wrote: > Francois Gouget<fgouget(a)free.fr> wrote: >> We will still need people to take on the somwhat unsexy control resizing >> task and that may be a problem. If it turns out we lack volunteers for >> that we may turn to some automatic layout scheme, for instance describe >> the resources in a glade-like language and translate+convert them to rc >> files at build time. > > Sounds not very exciting. If there is a choice of having resources with properly > placed and sized controls but english only, vs. translated but with broken layout > ones, then I'm afraid most users would prefer an english variant. Once we start using po files we can probably get rid of the 'transl' website as those stats will come from whatever tool we choose to deal with po files. For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible? -- Cheers, Paul.

June 25, 2010

Re: Addition of En resources to non-En resources

by Dmitry Timoshkov

Francois Gouget <fgouget(a)free.fr> wrote: > Requiring that translators master both skills severly limits the pool of > translators we can draw from. Doesn't this sound similar to so called limitation that exists for people willing to work on Wine code, but have no appropriate skills? I.e. there is always a choice between quality and quantity. > Introducing po files lets us treat each > task independently and leverage all the online po translation tools. > > We will still need people to take on the somwhat unsexy control resizing > task and that may be a problem. If it turns out we lack volunteers for > that we may turn to some automatic layout scheme, for instance describe > the resources in a glade-like language and translate+convert them to rc > files at build time. Sounds not very exciting. If there is a choice of having resources with properly placed and sized controls but english only, vs. translated but with broken layout ones, then I'm afraid most users would prefer an english variant. > > I was replying to a comment saying basically "me too" which the sender > > tends to reply to almost every message. > > The sender is excited by the prospect of rc files being used for > translating Wine resources and that's pretty understandable. I am too! Good to know. -- Dmitry.

June 25, 2010

Fwd: Possible patch for #12706

by Jeff Cook

This is a patch that makes WINE detect snd_usb_audio mics and assign them a mixer and working master control. See bug #12706 for more information about this problem: http://bugs.winehq.org/show_bug.cgi?id=12706 I wasn't able to test it completely because I wasn't able to switch my default input device to the USB mic and no one in IRC is helping with this, but it might make things work because theoretically the only problem was that WINE was ignoring devices that looked like snd_usb_audio's microphones. I suggest that someone who CAN get snd_usb_audio mic as their default test it out and confirm, I would really appreciate that. Thanks to all in IRC who helped me get things this far, especially mlankhorst. This patch is based against the current git HEAD, eaa227c12d8bb. I've also posted it at the aforementioned bug. -- Jeff Cook (801) 231-3157 jeff(a)deserettechnology.com

June 25, 2010

How do you make x64 crosstests?

by Ilya Basin

_

June 25, 2010

Re: wined3d: Silence a noisy fixme.

by Henri Verbeet

I don't think so. That FIXME should have been an ERR, and if you're seeing it that's a bug.

June 25, 2010

Debian package backorder

by Ben Klein

Unless someone wants to donate an AM2/DDR2 motherboard to me, someone is going to have to take over the packaging of Debian Stable, Testing and Unstable packages.

June 25, 2010

sorry guys... slow on uptake today :)

by Misha Koshelev

So I've been working on bug 13891, but got sidetracked by what I thought was a race condition as dlls/shell32/tests/shlexec.c was hanging. Spent several hours tracing it to line 464 in dlls/ntdll/directory.c if (stat( entry->mnt_dir, &st ) == -1) continue; (read from /etc/mtab) Turned out it was my curlftpfs file system, which tends to disconnect randomly and not unmount (doh!). Anyway I hope to have perhaps some tests for this bug before I leave to Russia (on Sat morning), but unfortunately I might not be able to get this bug fixed until post-code freeze. Sorry :( Misha

June 25, 2010

Re: comctl32/tests: remove noisy trace

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2910 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

June 24, 2010

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.

by Misha Koshelev

On Thu, 2010-06-24 at 11:33 -0700, James Mckenzie wrote: > Henri Verbeet <hverbeet(a)gmail.com wrote: > > > >On 24 June 2010 18:11, Misha Koshelev <misha680(a)gmail.com> wrote: > >> Ok thank you. Since we are in code freeze and I'd like to help wine, perhaps then I > >>will just go down the list of 1.2 milestone bugs for now and see if I can help. > >> > >Yeah, milestone bugs should generally be ok, as well as any open regressions. > > > Some of the regression bugs are pre-Wine 1.0. Sad, but if you can fix those, it would greatly help bring Wine code up-to-date. > > James McKenzie > Thanks James. Right now I am looking at: http://bugs.winehq.org/show_bug.cgi?id=13891 but at some point willing to track down regressions too. If you have a link would be great (I am leaving to Russia on Sat so I'm not sure how much I'll be able to get done before then though). Misha

June 24, 2010

Re: [PATCH] [try 4] ddraw: Grow indexbuffer as needed

by Stefan Dösinger

Am Donnerstag 24 Juni 2010 17:56:07 schrieb Henri Verbeet: > If we really cared about those cases we could explicitly handle them, > (e.g. by growing in smaller increments once we're over half the limit) > but I don't think we do. There's also the (more likely) consideration > that creating an index buffer of a certain size will fail due to > running out of memory / address space, while a slightly smaller buffer > might succeed, but I don't think we really care about that one either. Sounds reasonable Besides, this index buffer here is an ugly thing, and I am surprised it survived this long. It'll need a better solution after Wine 1.2, maybe a method in wined3d to draw from a vertex buffer with user pointer index data, or a special user pointer index buffer. I have played with the latter idea a while ago but ran into some issues.

June 24, 2010

Re: Porting WIne to D

by Marcus Meissner

On Thu, Jun 24, 2010 at 11:39:49AM -0700, James Mckenzie wrote: > Gert van den Berg <wine-devel(a)mohag.net> wrote: > >Like the D website says: > >Who D is Not For > > * Realistically, nobody is going to convert million line C or C++ > >programs into D. Since D does not compile unmodified C/C++ source > >code, *D is not for legacy apps*. (However, D supports legacy C API's > >very well. D can connect directly to any code that exposes a C > >interface.) > > That should rule out moving Wine to D for a long time. 9 Million + lines of code would make this a lengthy, but not impossible, task. > > > > >D also specifically drops 16-bit support, which might cause problems > >for the Win16 / DOS parts of Wine... > > Another show-stopper for those folks using Wine to run Windows 2.x/3.x programs. Well, our 16bit code is hidden behind assembler wrappers. :) Ciao, Marcus

June 24, 2010

Re: Yagmark and localized Windows

by Austin English

On Tue, Jun 22, 2010 at 9:42 AM, Dan Kegel <dank(a)kegel.com> wrote: > I'd love to have yagmark be more internationalized. > I did try to use button codes rather than english > strings in wisotool, but sometimes it wasn't possible, and > sometimes I didn't try hard enough. Not sure if I > tried at all in yagmark yet. > > According to > http://www.autohotkey.com/docs/commands/SetTitleMatchMode.htm > Autohotkey supports regular expressions, so for the matching > strings that can't be changed to button codes, > we could list a bunch of alternatives, e.g. Save As|Enregistrer Sous > Then the remaining mess is when we have to send a > keystroke, we might need a switch statement to decide > which keystroke to send based on the language. > > For the purposes of benchmarking wine, just setting > LANG=en_US.UTF-8 solves the problem, but that > doesn't help when you're trying to benchmark Windows. The proper way to do it with AutoHotKey is either to use the button ID, if available, or define the resource name for each language. Most of the time button ID's are available and work well. There was a bug for some of them being different in windows and wine that AJ recently fixed. -- -Austin

June 24, 2010

Re: Porting WIne to D

by James Mckenzie

Gert van den Berg <wine-devel(a)mohag.net> wrote: >Like the D website says: >Who D is Not For > * Realistically, nobody is going to convert million line C or C++ >programs into D. Since D does not compile unmodified C/C++ source >code, *D is not for legacy apps*. (However, D supports legacy C API's >very well. D can connect directly to any code that exposes a C >interface.) That should rule out moving Wine to D for a long time. 9 Million + lines of code would make this a lengthy, but not impossible, task. > >D also specifically drops 16-bit support, which might cause problems >for the Win16 / DOS parts of Wine... Another show-stopper for those folks using Wine to run Windows 2.x/3.x programs. James McKenzie

June 24, 2010

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.

by James Mckenzie

Henri Verbeet <hverbeet(a)gmail.com wrote: > >On 24 June 2010 18:11, Misha Koshelev <misha680(a)gmail.com> wrote: >> Ok thank you. Since we are in code freeze and I'd like to help wine, perhaps then I >>will just go down the list of 1.2 milestone bugs for now and see if I can help. >> >Yeah, milestone bugs should generally be ok, as well as any open regressions. > Some of the regression bugs are pre-Wine 1.0. Sad, but if you can fix those, it would greatly help bring Wine code up-to-date. James McKenzie

June 24, 2010

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.

by Henri Verbeet

On 24 June 2010 18:11, Misha Koshelev <misha680(a)gmail.com> wrote: >> http://source.winehq.org/patches/, you'll see 62909 is marked as >> "Deferred", so resending in a slightly different form isn't going to >> help much. > Ah I see thank you. I take it this means deferred until post-code freeze (please correct me if incorrect). > Pretty much. (There's a legend with more verbose explanations at the bottom of that page.) > Ok thank you. Since we are in code freeze and I'd like to help wine, perhaps then I will just > go down the list of 1.2 milestone bugs for now and see if I can help. > Yeah, milestone bugs should generally be ok, as well as any open regressions.

June 24, 2010

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.

by Misha Koshelev

> > On 24 June 2010 05:18, Misha Koshelev <misha680 at gmail.com> wrote: > > Dan suggested tests ok during code freeze so blame Dan for my patches ;) > Certainly will. wine-devel is an open mailing list, and posting is > easy. You'll probably want to check with something like "git shortlog > -s -n" if the advice you're getting is actually worth taking. The way > I see it, you have more experience with getting patches accepted > yourself. More to the point, if you look at > http://source.winehq.org/patches/, you'll see 62909 is marked as > "Deferred", so resending in a slightly different form isn't going to > help much. Ah I see thank you. I take it this means deferred until post-code freeze (please correct me if incorrect). > > > As for the patch itself, I'm not convinced there's value in having a > separate file for "Shape Drawing Functions", these are clearly mesh > constructors. I thought the original patch was mostly ok in that > regard, although there are (very) minor issues like using %d for > unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 > over simply "IDirect3DDevice9 *". > Ok thank you. Since we are in code freeze and I'd like to help wine, perhaps then I will just go down the list of 1.2 milestone bugs for now and see if I can help. Post code freeze, I can then start on the d3dx9 stuff as I am really not akin to having my own private repo as of yet and I think that going from a private repo to getting patches into Wine itself might be a little more difficult than I'd like - rather than doing it all at once... So thus for now work on 1.2 milestones. Then D3DX9. Off to work... Misha

June 24, 2010

Re: [PATCH] [try 4] ddraw: Grow indexbuffer as needed

by Henri Verbeet

On 24 June 2010 17:40, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Thinking about it, is there a reason for growing the buffer in power of two sizes, and not simply set it to the size required for the draw call? E.g. if the app passes index data with a size somewhere between 2^31 and 2^32-1(which still still fits in the UINT variable) the power of two growing will try to create a 2^32 byte buffer which overflows and fails. So you're cutting the possible index buffer size in half. > If we really cared about those cases we could explicitly handle them, (e.g. by growing in smaller increments once we're over half the limit) but I don't think we do. There's also the (more likely) consideration that creating an index buffer of a certain size will fail due to running out of memory / address space, while a slightly smaller buffer might succeed, but I don't think we really care about that one either.

June 24, 2010

Re: [PATCH] [try 4] ddraw: Grow indexbuffer as needed

by Stefan Dösinger

> + while(size < IndexCount * sizeof(WORD)) > + { > + size <<= 1; > + } Thinking about it, is there a reason for growing the buffer in power of two sizes, and not simply set it to the size required for the draw call? E.g. if the app passes index data with a size somewhere between 2^31 and 2^32-1(which still still fits in the UINT variable) the power of two growing will try to create a 2^32 byte buffer which overflows and fails. So you're cutting the possible index buffer size in half. (Of course if an app actually tries to create a >2GB index buffer we have bigger problems than the UINT, especially in a 32 bit process)

June 24, 2010

Re: Addition of En resources to non-En resources

by Francois Gouget

On Wed, 23 Jun 2010, Dmitry Timoshkov wrote: > Francois Gouget <fgouget(a)free.fr> wrote: > > > James never meant that Wine would not use rc files at all. What he meant > > is that rc files would lose their status as the autoritative source for > > the resource strings and would be mostly generated from po files. > > The .rc files are much more than just strings, in any case the translator > need to edit/check the .rc files to get an acceptable result. Which is something that translators have not all been doing because verifying that the dialog looks ok is such a pain. Currently translators need two have two completely distinct skillsets: * An English to the target language translator skill. * An rc file editing, testing and resizing skill. Requiring that translators master both skills severly limits the pool of translators we can draw from. Introducing po files lets us treat each task independently and leverage all the online po translation tools. We will still need people to take on the somwhat unsexy control resizing task and that may be a problem. If it turns out we lack volunteers for that we may turn to some automatic layout scheme, for instance describe the resources in a glade-like language and translate+convert them to rc files at build time. > I was replying to a comment saying basically "me too" which the sender > tends to reply to almost every message. The sender is excited by the prospect of rc files being used for translating Wine resources and that's pretty understandable. I am too! -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

June 24, 2010

Re: kernel32: Update Gaelic resource

by Michael Stefaniuc

Hello Ken, Ken Sharp wrote: > From: Ken Sharp <kennybobs(a)o2.co.uk> > Date: Tue, 15 Jun 2010 09:42:05 +0100 > Subject: kernel32: Update Gaelic resource the patch changes the file encoding to UTF-8 without changing the "#pragma code_page" too. Though Alexandre already rejected codepage changes to the NLS files during the 1.2 freeze as too risky changes; NLS files are more than just translations. The best thing is to resend the changes without the codepage change. thanks bye michael

June 24, 2010

Re: kernel32: Update Gaelic resource

by Dmitry Timoshkov

Ken Sharp <kennybobs(a)o2.co.uk> wrote: > diff --git a/dlls/kernel32/nls/gae.nls b/dlls/kernel32/nls/gae.nls > index 6e19ff4..a005be3 100644 > --- a/dlls/kernel32/nls/gae.nls > +++ b/dlls/kernel32/nls/gae.nls Looks like you are using UTF-8 while the file is in code page 1252. -- Dmitry.

June 24, 2010

Re: Porting WIne to D

by Gert van den Berg

On Thu, Jun 24, 2010 at 10:55, Francois Gouget wrote: > OOP: > > A lot of the Windows API is exported through DLL entry points and these > are not object oriented. Where the Windows API is object oriented is: OOP in C is not impossible wither... It is harder than it could be, but it is possible.... > Wine also has very strong requirements with regards to threading, CPU > register usage, exception handling, all of which require very low-level > control which negates the advantages high level languages might have in > these areas. The good: * D is specifically intended to support low-level applications. * Built in UTF-8 / UTF-16 / UTF-32 support * Types defines size - an int is always 32-bit * COM support * C-compatibility * Standardized inline assembly * Build-in support for unit-tests, etc. (Will require all the tests to be rewritten in a different way though..) D still have some issues, such as two incompatible, competing "standard libraries"... Version 2 might be worth considering for some new projects... Like the D website says: Who D is Not For * Realistically, nobody is going to convert million line C or C++ programs into D. Since D does not compile unmodified C/C++ source code, *D is not for legacy apps*. (However, D supports legacy C API's very well. D can connect directly to any code that exposes a C interface.) D also specifically drops 16-bit support, which might cause problems for the Win16 / DOS parts of Wine... I'm not sure how widely gcd/dmd is supported. Will it run on some of Wine(lib)'s rarer platforms? (like MIPS Linux, Itanium Linux, x86/x86_64 Solaris, SPARC Linux, *BSD on unusual platforms, OS X (PowerPC, x86 and x86_64)) Linking to C code from D is obviously supported. I'm not sure how well it is supported in the other direction (crucial for winelib...) It is not clear if non-Unicode strings are supported... (No non-Unicode char type exist...) Gert

June 24, 2010

Re: [PATCH] ddraw: Grow indexbuffer as needed (now with overflow check)

by Stefan Dösinger

Am 24.06.2010 um 11:30 schrieb Mikko Rasa: > On 24.06.2010 12:07, Stefan Dösinger wrote: >> >> Am 23.06.2010 um 21:57 schrieb Mikko Rasa: >>> + if(!size) >>> + { >>> + ERR("UINT overflow while trying to grow indexbuffer to hold %u indices\n", IndexCount); >>> + return D3DERR_TOOMANYPRIMITIVES; >>> + } >>> + } >> You have to release the ddraw lock before returning from the function(LeaveCriticalSection(&ddraw_cs)) > > Doh. Fixed that; anything else that should be rectified before I resubmit? Nothing I can spot so far

June 24, 2010

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.

by Henri Verbeet

On 24 June 2010 05:18, Misha Koshelev <misha680(a)gmail.com> wrote: > Dan suggested tests ok during code freeze so blame Dan for my patches ;) Certainly will. wine-devel is an open mailing list, and posting is easy. You'll probably want to check with something like "git shortlog -s -n" if the advice you're getting is actually worth taking. The way I see it, you have more experience with getting patches accepted yourself. More to the point, if you look at http://source.winehq.org/patches/, you'll see 62909 is marked as "Deferred", so resending in a slightly different form isn't going to help much. As for the patch itself, I'm not convinced there's value in having a separate file for "Shape Drawing Functions", these are clearly mesh constructors. I thought the original patch was mostly ok in that regard, although there are (very) minor issues like using %d for unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 over simply "IDirect3DDevice9 *".

June 24, 2010

Re: [PATCH 2/7] d3dx9: Add IUnknown method calls to ID3DXMesh.

by Henri Verbeet

On 24 June 2010 05:18, Misha Koshelev <misha680(a)gmail.com> wrote: > +#if !defined(__cplusplus) || defined(CINTERFACE) > +/*** IUnknown methods ***/ > +#define ID3DXMesh_QueryInterface(p,a,b) (p)->lpVtbl->QueryInterface(p,a,b) > +#define ID3DXMesh_AddRef(p) (p)->lpVtbl->AddRef(p) > +#define ID3DXMesh_Release(p) (p)->lpVtbl->Release(p) > +#else > +/*** IUnknown methods ***/ > +#define ID3DXMesh_QueryInterface(p,a,b) (p)->QueryInterface(a,b) > +#define ID3DXMesh_AddRef(p) (p)->AddRef() > +#define ID3DXMesh_Release(p) (p)->Release() > +#endif > + Which version of the DX SDK do these match?

June 24, 2010

Re: Tests for msvcrt

by Piotr Caban

On 06/24/10 10:49, Paul Chitescu wrote: > Hi! > > What would be the best way of testing MSVCRT.DLL considering that many > functions may or may be not present in the native version? There are already such tests in msvcrt. Take a look on e.g. dlls/msvcrt/tests/misc.c. It's working well on older systems. There are already tests of msvcr90. MsvcrXX specific tests should go there (unless the function is not present there).

June 24, 2010

Re: [PATCH] ddraw: Grow indexbuffer as needed (now with overflow check)

by Stefan Dösinger

Am 23.06.2010 um 21:57 schrieb Mikko Rasa: > + if(!size) > + { > + ERR("UINT overflow while trying to grow indexbuffer to hold %u indices\n", IndexCount); > + return D3DERR_TOOMANYPRIMITIVES; > + } > + } You have to release the ddraw lock before returning from the function(LeaveCriticalSection(&ddraw_cs))

June 24, 2010

Re: Tests for msvcrt

by Nicolas Le Cam

2010/6/24 Paul Chitescu <paulc(a)voip.null.ro>: > Hi! > > What would be the best way of testing MSVCRT.DLL considering that many > functions may or may be not present in the native version? > >> > /********************************************************************* >> > + * getenv_s - not exported in native msvcrt >> > + */ >> > +int CDECL getenv_s(size_t *size, char *buffer, size_t bufLen, const char > *name >> Both getenv_s and _wgetenv_s are exported in native msvcrt. > > In older versions of MSVCRT.DLL (XP and earlier, no idea about Vista) these > functions are not exported. They were added first in Visual Studio 2005 > (MSVCRT80.DLL) and somehow made they way back in MSVCRT. > > Using LoadLibrary / GetProcAddress would fail on all older Windows platforms. > > It would be possible to test MSVCR80 instead but that may not be installed on > the tested system. > > Any thoughts? > > Paul Chitescu > > > > What about loading msvcrt, fallback on loading msvcrt80 and win_skip if you can't find them in both libraries? -- Nicolas Le Cam

June 24, 2010

Re: Porting WIne to D

by Francois Gouget

On Wed, 23 Jun 2010, Christopher Selph wrote: > Hi everyone, new here. I have been fooling around with the idea of porting > WIne to the D programming language. What do you think would be the chances > of sucess? D has the speed of C, but is a garbage collected language and > OOP. Garbage collecting: Wine has strong requirements as far as the memory layout is concerned. Some applications don't expect to receive pointers to data above 3GB for instance. Windows also provides heap management routines and Windows applications create heaps, allocate memory inside them and don't expect things to move around. I suspect none of this would play well with garbage collecting. It would probably still be possible to use the garbage collector for a small fraction of Wine's allocations, but it seems to me that there would not be much point. OOP: A lot of the Windows API is exported through DLL entry points and these are not object oriented. Where the Windows API is object oriented is: * For some msvcrt parts. But the name of the corresponding C++ functions must be mangled in the Visual C++ way which probably does not match the D way. So we would still need to do the impedance adaptation in the spec file. * For COM objects. However these must have a very specific binary layout for compatibility with Windows applications. Again I doubt D objects would naturally generate the right datastructures. So you'd need to add an impedance adaptation just like for C. Wine also has very strong requirements with regards to threading, CPU register usage, exception handling, all of which require very low-level control which negates the advantages high level languages might have in these areas. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A polar bear is a cartesian bear after a coordinate transform.

June 24, 2010

Tests for msvcrt

by Paul Chitescu

Hi! What would be the best way of testing MSVCRT.DLL considering that many functions may or may be not present in the native version? > > /********************************************************************* > > + * getenv_s - not exported in native msvcrt > > + */ > > +int CDECL getenv_s(size_t *size, char *buffer, size_t bufLen, const char *name > Both getenv_s and _wgetenv_s are exported in native msvcrt. In older versions of MSVCRT.DLL (XP and earlier, no idea about Vista) these functions are not exported. They were added first in Visual Studio 2005 (MSVCRT80.DLL) and somehow made they way back in MSVCRT. Using LoadLibrary / GetProcAddress would fail on all older Windows platforms. It would be possible to test MSVCR80 instead but that may not be installed on the tested system. Any thoughts? Paul Chitescu

June 24, 2010

Re: Question about video capture and rendering and encoding in wine

by shenyue

Hi Maarten, Thanks for reply so soon. Details reply below. ----- Original Message ----- From: "Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> To: "shenyue" <shenyue(a)magima.com.cn> Cc: <wine-devel(a)winehq.org> Sent: Wednesday, June 23, 2010 10:50 PM Subject: Re: Question about video capture and rendering and encoding in wine > Hello, > > I only made it work for msn messenger a long time ago, in 6.2 or so. > I'm surprised it still works. Only change since then has been adding > support for libv4l. (v4l2 with v4l1 api) > > Could it be a ddraw/d3d7 failure rather than a wine failure? Yes, possible. Up to now, I'm sure v4l ReadThread keeps outputing frames, but I didn't find any related Blt for video preview window, only Blt for the video of my friends. And there's so many surfaces QQ created, I can only guess which surface is for preview and remote video from the surface's DSCAPS and DS_WIDTH/HEIGHT, I didn't find any surface close to preview video's width and height. Now since my timestamp modification finally doesn't solve QQ problem, I'm now checking whether something wrong with ddraw/d3d7. > Because originally I only wrote it to work with msn messenger 6.2 ;). > > Sort of, I didn't adjust the code for v4l2, however with libv4l it > should work in linux.. > > ~Maarten > Best Regards, Karma 搬迁通知： 2010年1月18日起，上海奇码数字信息有限公司迁至新址办公。新地址为：上海张江祖冲之路887弄88号502室。 ==========================================================

June 24, 2010

re: [PATCH 7/7] d3dx9: Test raw vertex data for D3DXCreateSphere.

by Dan Kegel

Misha wrote: + /* comparisons of 0.0f with -0.0f do not quite seem to work correctly */ Boy, that's for sure. + todo_wine ok( vertex_data[i].x==test_vertex_data[i].x || (fabsf(vertex_data[i].x) < 0.0001f && fabsf(test_vertex_data[i].x) < 0.0001f), "Got result %f, expected %f\n",vertex_data[i].x,test_vertex_data[i].x); You probably want to define an AlmostEqual() function and use that rather than repeating the logic. See http://code.google.com/p/googletest/wiki/GoogleTestAdvancedGuide#Floating-P… and the paper it points to, http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm - Dan

June 24, 2010

something I hacked up for git - maybe will help

by Misha Koshelev

I like to reapply my patches a lot - so this gets rid of trailing whitespace and applies the patch. Just thought I'd send out. I know there's tools to avoid trailing whitespace in emacs (http://github.com/glasserc/ethan-wspace works well), but this is my simple solution ;) Misha

June 24, 2010

Re: [PATCH 7/7] d3dx9: Test raw vertex data for D3DXCreateSphere.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2889 Your paranoid android. === WINEBUILD (build) === Make failed

June 24, 2010

Re: [PATCH 6/7] d3dx9: Add tests for D3DXCreateSphere vertex buffer description.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2888 Your paranoid android. === WINEBUILD (build) === Make failed

June 24, 2010

Re: [PATCH 5/7] d3dx9: Test number of vertices for D3DXCreateSphere.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2887 Your paranoid android. === WINEBUILD (build) === Make failed

June 24, 2010

Re: [PATCH 3/7] d3dx9: Add framework for a more sophisticated D3DXCreateSphere test.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2886 Your paranoid android. === WINEBUILD (build) === Make failed

June 24, 2010

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2885 Your paranoid android. === WINEBUILD (build) === Make failed

June 24, 2010

Re: Add files generated by "make depend", PGO and gcov to .gitignore

by Scott Ritchie

On 06/22/2010 11:03 AM, Alexandre Julliard wrote: > Peter Davies <ultratwo(a)gmail.com> writes: > >> @@ -79,6 +79,9 @@ my @ignores = ( >> "*.ok", >> "*.res", >> "*.so", >> + "*.gcno", >> + "*.gcov", >> + "/conf*", > > They are not generated by a standard build so they don't belong > here. Put then in your local ignore file. > Is best practice to confine these to a particular folder (like you get with -fprofile-dir)? Is there a switch to do that for gcov data? Thanks, Scott Ritchie

June 24, 2010

Re: Porting WIne to D

by Ben Klein

Please bottom-post on wine-devel. On 24 June 2010 09:26, Christopher Selph <cds.wine(a)gmail.com> wrote: > I agreee that just converting syntax would not be enough, but it would make > OO design in D alot easier and faster. It an idea currently, I was just > looking for some input. Given that there is (by definition) no genuine OO stuff in Wine at the moment, porting Wine (successfully) to an OO language is a task equal to, if not greater than, reimplementing the current state of the codebase from scratch. On 24 June 2010 04:48, Stephen Eilert <spedrosa(a)gmail.com> wrote: > On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph <cds.wine(a)gmail.com> wrote: >> Well, being a garbage collected language, it would help with the memory >> leaks in Wine. Being OOP it could extend the design of the code to make it >> cleaner and reusable. > > The assertions above are opinions, not facts. Also, it requires a full rewrite. > > Wine Initial release(per Wikipedia): 4 July 1993 ^^ Very important point. I'm pretty sure that garbage collection on its own does not solve memory leaks. Java is notorious for memory issues; if there's a leak in the engine then no amount of fixking in your code will reduce the memory footprint. Furthermore, if the leak is created by some reference still being valid in the first place (i.e., not being cleaned up by the code, which no doubt is the current case), then any benefits of automated GC would be minimal at best. Things that cause memory leaks are bad practice, and for a project as large as Wine, I'm not sure relying on a language feature to clean up the loose ends is the best idea. Also, what benefit could an OO language bring to implementing win32/win64? Are the Microsoft APIs actually suited to object-orientied implementation? > On Wed, Jun 23, 2010 at 4:17 PM, Gert van den Berg <wine-devel(a)mohag.net> > wrote: >> >> On Wed, Jun 23, 2010 at 22:58, Christopher Selph <cds.wine(a)gmail.com> >> wrote: >> >>Porting a codebase the size >> >> >> >> >of Wine will probably take years... >> >> >> >> Actually I'm working on a program to convert C code to D code. You can >> >> find/replace most instances of code, like unsigned int (C) with uint >> >> (D). >> >> The import/include files might take some work though. >> >> Just converting the syntax won't help much. It might compile, but it >> lacks the design changes (such as proper OO) needed to properly >> exploit a new language. You end up with code with the same problems as >> the original, but in a language that the programmers are unfamiliar >> with... (For C++, duplication of functionality in the STL is an >> example of what often happens if you directly port C code) >> >> Wine (like the Linux kernel) might be a good codebase to test your >> application on (for your own testing), since it is quite a large, >> complicated codebase... The chances of having it accepted into Wine is >> probably quite small... (My guess would be that your chances of being >> struck by lightning while winning the lottery are about equal...) >> >> http://www.winehq.org/site/docs/winedev-guide/style-notes might give >> you an idea of some of the things relatively simple patches struggle >> with to get included... >> >> Gert > > > > >

June 24, 2010

Re: Porting WIne to D

by Christopher Selph

I agreee that just converting syntax would not be enough, but it would make OO design in D alot easier and faster. It an idea currently, I was just looking for some input. On Wed, Jun 23, 2010 at 4:17 PM, Gert van den Berg <wine-devel(a)mohag.net>wrote: > On Wed, Jun 23, 2010 at 22:58, Christopher Selph <cds.wine(a)gmail.com> > wrote: > >>Porting a codebase the size > >> > >> >of Wine will probably take years... > >> > >> Actually I'm working on a program to convert C code to D code. You can > >> find/replace most instances of code, like unsigned int (C) with uint > (D). > >> The import/include files might take some work though. > > Just converting the syntax won't help much. It might compile, but it > lacks the design changes (such as proper OO) needed to properly > exploit a new language. You end up with code with the same problems as > the original, but in a language that the programmers are unfamiliar > with... (For C++, duplication of functionality in the STL is an > example of what often happens if you directly port C code) > > Wine (like the Linux kernel) might be a good codebase to test your > application on (for your own testing), since it is quite a large, > complicated codebase... The chances of having it accepted into Wine is > probably quite small... (My guess would be that your chances of being > struck by lightning while winning the lottery are about equal...) > > http://www.winehq.org/site/docs/winedev-guide/style-notes might give > you an idea of some of the things relatively simple patches struggle > with to get included... > > Gert >

June 23, 2010

Re: wordpad: Remove untranslated resources from the Chinese translation.

by Austin English

2010/6/23 Dylan Smith <dylan.ah.smith(a)gmail.com>: > > --- > programs/wordpad/Zh.rc | 24 ------------------------ > 1 files changed, 0 insertions(+), 24 deletions(-) You sent this to wine-devel, not wine-patches. -- -Austin

June 23, 2010

wordpad: Remove untranslated resources from the Chinese translation.

by Dylan Smith

--- programs/wordpad/Zh.rc | 24 ------------------------ 1 files changed, 0 insertions(+), 24 deletions(-) diff --git a/programs/wordpad/Zh.rc b/programs/wordpad/Zh.rc index 135f00c..bae40a7 100644 --- a/programs/wordpad/Zh.rc +++ b/programs/wordpad/Zh.rc @@ -111,30 +111,6 @@ BEGIN END END -IDM_COLOR_POPUP MENU DISCARDABLE -BEGIN - POPUP "" - BEGIN - MENUITEM "Black", ID_COLOR_BLACK - MENUITEM "Maroon", ID_COLOR_MAROON - MENUITEM "Green", ID_COLOR_GREEN - MENUITEM "Olive" ID_COLOR_OLIVE - MENUITEM "Navy" ID_COLOR_NAVY - MENUITEM "Purple" ID_COLOR_PURPLE - MENUITEM "Teal" ID_COLOR_TEAL - MENUITEM "Gray" ID_COLOR_GRAY - MENUITEM "Silver" ID_COLOR_SILVER - MENUITEM "Red" ID_COLOR_RED - MENUITEM "Lime" ID_COLOR_LIME - MENUITEM "Yellow" ID_COLOR_YELLOW - MENUITEM "Blue" ID_COLOR_BLUE - MENUITEM "Fuchsia" ID_COLOR_FUCHSIA - MENUITEM "Aqua" ID_COLOR_AQUA - MENUITEM "White" ID_COLOR_WHITE - MENUITEM "Automatic" ID_COLOR_AUTOMATIC - END -END - IDD_DATETIME DIALOG DISCARDABLE 30, 20, 130, 80 STYLE DS_MODALFRAME | WS_CAPTION | WS_SYSMENU CAPTION "日期和时间" -- 1.7.0.4

June 23, 2010

Re: oledlg: Add the Romanian translation.

by Alexandru Băluț

On Thu, Jun 24, 2010 at 00:13, Michael Stefaniuc <mstefani(a)redhat.com> wrote: >>> + CONTROL "Inserează&linkul", IDC_PS_PASTELINK, "Button", >>> BS_AUTORADIOBUTTON | WS_VISIBLE, >> >> Is "Inserează&legătura" wrong? > > No problem at all. But I found both versions for link, Claudia used 'linkul' > and last but not least I was lazy and went with the shorter form which > required less changes to resource size/positions. I have changed it to > legătura in the resend. "Linkul" is also fine, it seems. Thanks, Alex

June 23, 2010

Re: [PATCH] user32: check for valid pointer in CURSORICON_CreateIconFromBMI

by Wolfram Sang

On 23/06/10 15:32, Alexandre Julliard wrote: > Wolfram Sang <wolfram(a)the-dreams.de> writes: > >> @@ -884,6 +884,10 @@ static HICON CURSORICON_CreateIconFromBMI( BITMAPINFO *bmi, >> return 0; >> } >> >> + /* A few Windows versions crash getting NULL, but most simply return it */ >> + if (!bmi) >> + return 0; > > That's not the right place for it, this is an internal function. OK. Shall I remove the similar check in CURSORICON_CreateIconFromANI() then in the second version of the patch?

June 23, 2010

Re: oledlg: Add the Romanian translation.

by Michael Stefaniuc

On 06/23/2010 02:02 PM, Alexandru Băluț wrote: > 2010/6/23 Michael Stefaniuc<mstefani(a)redhat.com>: > > >> + CONTROL "Creează un nou",IDC_CREATENEW,"Button",BS_AUTORADIOBUTTON | >> + WS_GROUP,7,20,67,10 > > "Creează nou" seems better, the original is "Create New", not "Create > a New". I don't really get what "Create New" is supposed to mean, or > what is the difference between the "Create New" and "Create Control", > since for both you press the same button "Add Control...", so both > actually create a Control. I might be wrong. Yeah, I kept adding and removing the "un" as I was undecided and both don't look great. I was assuming it refers to create a new object. Anyway I have removed it in my resend. >> + PUSHBUTTON "&Adăugare control...",IDC_ADDCONTROL,81,88,67,14,NOT WS_VISIBLE > > This is a button, "&Adaugă [...]" seems more appropriate. > > "&Adaugă un control" would be consistent with "Creează un control" > which is used for a radio button. Fixed. >> +CAPTION "Paste Special" > > It should say "Inserare specială", to be consistent with: I wonder how i missed that one. I have changed the caption of the other dialog too to the impersonal form. >> + CONTROL "I&nserează", IDC_PS_PASTE, "Button", BS_AUTORADIOBUTTON | WS_TABSTOP | WS_GROUP | WS_VISIBLE, > > >> + CONTROL "Inserează&linkul", IDC_PS_PASTELINK, "Button", BS_AUTORADIOBUTTON | WS_VISIBLE, > > Is "Inserează&legătura" wrong? No problem at all. But I found both versions for link, Claudia used 'linkul' and last but not least I was lazy and went with the shorter form which required less changes to resource size/positions. I have changed it to legătura in the resend. >> + IDS_PS_PASTE_DATA "Inserează conținutul din clipboard în document ca %s." >> + IDS_PS_PASTE_OBJECT "Inserează conținutul din clipboard în document astfel încât să îl puteți activa utilizând %s." >> + IDS_PS_PASTE_OBJECT_AS_ICON "Inserează conținutul din clipboard în document astfel încât să îl puteți activa utilizând %s. Va fi afișat ca o pictogramă." >> + IDS_PS_PASTE_LINK_DATA "Inserează conținutul din clipboard în document ca %s. Datele sunt legate de fișierul sursă, astfel încât modificările aduse fișierului vor fi reflectate în document." >> + IDS_PS_PASTE_LINK_OBJECT "Inserați o imagine a conținutului din clipboard în document. Imaginea este legată de fișierul sursă, astfel încât modificările aduse fișierului vor fi reflectate în document." >> + IDS_PS_PASTE_LINK_OBJECT_AS_ICON "Inserați o scurtătură care conduce la locația conținutului din clipboard. Scurtătura este legată de fișierul sursă, astfel încât modificările aduse fișierului vor fi reflectate în document." >> + IDS_PS_NON_OLE "Inserează conținutul din clipboard în document." > > All the English messages for these start with "Inserts [...]" - We > should be consistent, and use "Inserează [...]" for all of them. Fixed! Thank you Alex for your review. bye michael

June 23, 2010

Re: Porting WIne to D

by Gert van den Berg

On Wed, Jun 23, 2010 at 22:58, Christopher Selph <cds.wine(a)gmail.com> wrote: >>Porting a codebase the size >> >> >of Wine will probably take years... >> >> Actually I'm working on a program to convert C code to D code. You can >> find/replace most instances of code, like unsigned int (C) with uint (D). >> The import/include files might take some work though. Just converting the syntax won't help much. It might compile, but it lacks the design changes (such as proper OO) needed to properly exploit a new language. You end up with code with the same problems as the original, but in a language that the programmers are unfamiliar with... (For C++, duplication of functionality in the STL is an example of what often happens if you directly port C code) Wine (like the Linux kernel) might be a good codebase to test your application on (for your own testing), since it is quite a large, complicated codebase... The chances of having it accepted into Wine is probably quite small... (My guess would be that your chances of being struck by lightning while winning the lottery are about equal...) http://www.winehq.org/site/docs/winedev-guide/style-notes might give you an idea of some of the things relatively simple patches struggle with to get included... Gert

June 23, 2010

Re: Porting WIne to D

by Christopher Selph

>Porting a codebase the size > >of Wine will probably take years... > > Actually I'm working on a program to convert C code to D code. You can > find/replace most instances of code, like unsigned int (C) with uint (D). > The import/include files might take some work though. > > > On Wed, Jun 23, 2010 at 2:46 PM, Gert van den Berg <wine-devel(a)mohag.net>wrote: > >> On Wed, Jun 23, 2010 at 20:48, Stephen Eilert <spedrosa(a)gmail.com> wrote: >> > On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph <cds.wine(a)gmail.com> >> wrote: >> >> Well, being a garbage collected language, it would help with the memory >> >> leaks in Wine. Being OOP it could extend the design of the code to make >> it >> >> cleaner and reusable. >> > >> > The assertions above are opinions, not facts. Also, it requires a full >> rewrite. >> > >> You can mix D code and C code... >> >> A more modern language can result in more readable code, but it is a >> lot of effort for a small benefit... (And D is a very new language, >> possibly to the degree that portability might be impacted due to a >> lack of compilers on some of the more obscure platforms / >> architectures). >> >> Certain parts of Wine might benefit from the latest (draft) version of >> C++ and the size of the codebase can probably be reduced in size >> slightly, but a bad port to another language doesn't help anyone... >> (The C++ standard library is huge and might getrid of some POSIX >> dependancies) It might require quite an extensive rewrite to get it to >> a proper C++ program, rather than a C program containing a bit of C++ >> and compiled with a C++ compiler... >> >> Fixing the current problems with Wine should be a much higher priority >> than porting it to a different language... Porting a codebase the size >> of Wine will probably take years... C can do anything that other >> languages can, the amount of effort might differ a bit, bit the >> difference is probably minor compared to familiarizing yourself with a >> new language, new libraries, etc.... >> >> (I like D - it have most features from languages like Java and C#, >> with the option to switch off things like garbage collection and it >> compiles to native code... Experimenting with it for new project might >> make sense) >> >> (IMHO: Allowing other languages than C for some of Wine's bundled >> applications (notepad, winecfg, winemine, etc) might make sense, as >> long as the QC for committing patches doesn't suffer. The mixing of >> languages within components (single application / DLL) will probably >> cause confusion and ugly code though... Getting proper QC would >> probably mostly involve sticking to things that AJ is familiar with.) >> >> Gert >> >> >> >

June 23, 2010

Re: Porting WIne to D

by Gert van den Berg

On Wed, Jun 23, 2010 at 20:48, Stephen Eilert <spedrosa(a)gmail.com> wrote: > On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph <cds.wine(a)gmail.com> wrote: >> Well, being a garbage collected language, it would help with the memory >> leaks in Wine. Being OOP it could extend the design of the code to make it >> cleaner and reusable. > > The assertions above are opinions, not facts. Also, it requires a full rewrite. > You can mix D code and C code... A more modern language can result in more readable code, but it is a lot of effort for a small benefit... (And D is a very new language, possibly to the degree that portability might be impacted due to a lack of compilers on some of the more obscure platforms / architectures). Certain parts of Wine might benefit from the latest (draft) version of C++ and the size of the codebase can probably be reduced in size slightly, but a bad port to another language doesn't help anyone... (The C++ standard library is huge and might getrid of some POSIX dependancies) It might require quite an extensive rewrite to get it to a proper C++ program, rather than a C program containing a bit of C++ and compiled with a C++ compiler... Fixing the current problems with Wine should be a much higher priority than porting it to a different language... Porting a codebase the size of Wine will probably take years... C can do anything that other languages can, the amount of effort might differ a bit, bit the difference is probably minor compared to familiarizing yourself with a new language, new libraries, etc.... (I like D - it have most features from languages like Java and C#, with the option to switch off things like garbage collection and it compiles to native code... Experimenting with it for new project might make sense) (IMHO: Allowing other languages than C for some of Wine's bundled applications (notepad, winecfg, winemine, etc) might make sense, as long as the QC for committing patches doesn't suffer. The mixing of languages within components (single application / DLL) will probably cause confusion and ugly code though... Getting proper QC would probably mostly involve sticking to things that AJ is familiar with.) Gert

June 23, 2010

Re: wordpad: Update Portuguese translation

by Paul Vriens

On 06/23/2010 09:33 PM, Paul Vriens wrote: > On 06/23/2010 09:30 PM, Gustavo wrote: >> Yes, that's what I did. I just tested wordpad with the wrong order and >> noticed that choosing to create a new file showed a window with blank >> entries, and when trying to open a file the drowpdown file type menu was >> also blank. In the right order everything worked. >> >> In other words, I introduced a bug in Portuguese Wine :/ > > That remains to be seen. It still could be a bug in out treatment of > different languages in one STRINGTABLE (of 16 strings). > > What you did of course fixes the problem. > From a brief look at MSDN one can only have one LANGUAGE per resource so your fix is fine. -- Cheers, Paul.

June 23, 2010

Re: wordpad: Update Portuguese translation

by Paul Vriens

On 06/23/2010 09:30 PM, Gustavo wrote: > Yes, that's what I did. I just tested wordpad with the wrong order and > noticed that choosing to create a new file showed a window with blank > entries, and when trying to open a file the drowpdown file type menu was > also blank. In the right order everything worked. > > In other words, I introduced a bug in Portuguese Wine :/ That remains to be seen. It still could be a bug in out treatment of different languages in one STRINGTABLE (of 16 strings). What you did of course fixes the problem. -- Cheers, Paul.

June 23, 2010

Re: wordpad: Update Portuguese translation

by Gustavo

Yes, that's what I did. I just tested wordpad with the wrong order and noticed that choosing to create a new file showed a window with blank entries, and when trying to open a file the drowpdown file type menu was also blank. In the right order everything worked. In other words, I introduced a bug in Portuguese Wine :/ Cheers, Gustavo. 2010/6/23 Paul Vriens <paul.vriens.wine(a)gmail.com> > On 06/23/2010 09:19 PM, Gustavo wrote: > >> I found out the problem. It was the order of the definition of strings >> that >> was wrong. Committing a new patch. >> > > you mean you did it now like in the En.rc file? Tried that but that's not > the issue, although it's probably better to have the same list as the > English one just for consistency. > > -- > Cheers, > > Paul. >

June 23, 2010

Re: wordpad: Update Portuguese translation

by Gustavo

I found out the problem. It was the order of the definition of strings that was wrong. Committing a new patch. 2010/6/23 Paul Vriens <paul.vriens.wine(a)gmail.com> > On 06/23/2010 03:12 PM, Gustavo wrote: > >> One more translation :) >> >> > This somehow messed up the stats: > > > http://source.winehq.org/transl/resource.php?lang=016%3A02&resfile=programs… > > and > > > http://source.winehq.org/transl/resource.php?lang=016%3A01&resfile=programs… > > It looks like we have two (sub)languages in one STRINGTABLE. Now, I'm not > sure if that's allowed (I think it is because ResHacker doesn't have an > issue with it) or if it's a wrc/transl bug/issue. > > -- > Cheers, > > Paul. >

June 23, 2010

Re: Porting WIne to D

by Stephen Eilert

On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph <cds.wine(a)gmail.com> wrote: > Well, being a garbage collected language, it would help with the memory > leaks in Wine. Being OOP it could extend the design of the code to make it > cleaner and reusable. The assertions above are opinions, not facts. Also, it requires a full rewrite. Wine Initial release(per Wikipedia): 4 July 1993 Good luck. --Stephen Sent from my Emacs

June 23, 2010

Re: wordpad: Update Portuguese translation

by Paul Vriens

On 06/23/2010 03:12 PM, Gustavo wrote: > One more translation :) > This somehow messed up the stats: http://source.winehq.org/transl/resource.php?lang=016%3A02&resfile=programs… and http://source.winehq.org/transl/resource.php?lang=016%3A01&resfile=programs… It looks like we have two (sub)languages in one STRINGTABLE. Now, I'm not sure if that's allowed (I think it is because ResHacker doesn't have an issue with it) or if it's a wrc/transl bug/issue. -- Cheers, Paul.

June 23, 2010

Re: Add files generated by "make depend", PGO and gcov to .gitignore

by Peter Davies

> It shouldn't. What conf* files do you see? conf23880 conf23880.dir conf23880.file Where "conf23880.dir" is an empty directory, "conf238800.file" is a file containing only a newline and "conf23880" symlinks to "conf23880.file". Having looked into it, it seems that these files are usually deleted by 'make depend' and are only temp files (I probably stopped "make depend" with ^C to generate them). The pattern is broken anyway since it also catches "configure", etc. Peter

June 23, 2010

Re: msvcrt: Implement getenv_s and _wgetenv_s, forwards from msvcr80, 90 and 100

by Piotr Caban

On 06/23/10 15:26, Paul Chitescu wrote: > /********************************************************************* > + * getenv_s - not exported in native msvcrt > + */ > +int CDECL getenv_s(size_t *size, char *buffer, size_t bufLen, const char *name Both getenv_s and _wgetenv_s are exported in native msvcrt. > + unsigned int len = strlen(var) + 1; > + *size = len; > + if (len > bufLen) > + return MSVCRT_ERANGE; If bufLen is set to 0 the function is used for obtaining output size. No ERANGE error is returned in this case. Cheers, Piotr

June 23, 2010

Re: Porting WIne to D

by Conan Kudo (ニール・ゴンパ)

On Wed, Jun 23, 2010 at 11:59 AM, Stephen Eilert <spedrosa(a)gmail.com> wrote: > On Wed, Jun 23, 2010 at 1:38 PM, Christopher Selph <cds.wine(a)gmail.com> > wrote: > > of sucess? D has the speed of C, but is a garbage collected language and > > OOP. > > And that would help how, exactly? > > > --Stephen > > Sent from my Emacs > > > Frankly, this sounds crazy and pointless. Your time would be better spent improving the current codebase, in C.

June 23, 2010

Re: Porting WIne to D

by Stephen Eilert

On Wed, Jun 23, 2010 at 1:38 PM, Christopher Selph <cds.wine(a)gmail.com> wrote: > of sucess? D has the speed of C, but is a garbage collected language and > OOP. And that would help how, exactly? --Stephen Sent from my Emacs

June 23, 2010

Porting WIne to D

by Christopher Selph

Hi everyone, new here. I have been fooling around with the idea of porting WIne to the D programming language. What do you think would be the chances of sucess? D has the speed of C, but is a garbage collected language and OOP. D: http://www.digitalmars.com/d Chris

June 23, 2010

Re: [PATCH 2/2] d3dx9: Add stub and basic test for D3DXCreateSphere.

by Misha Koshelev

On Wed, 2010-06-23 at 10:39 -0500, Austin English wrote: > On Wed, Jun 23, 2010 at 10:29 AM, Misha Koshelev <misha680(a)gmail.com> wrote: > > Oh, and please remind me as I do not quite recall. > > > > If we are in code freeze, does this mean that I should > > (i) refrain from submitting patches until I have a large patchset that > > is ready for testing or > > (ii) submit anyway a bit at a time? > > 1) Please bottom post on wine mailing lists. Oops sorry. > > 2) Avoid sending patches during code freeze, unless they fix a bug on > the 1.2 list ( http://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bu… > ), or are very small and not intrusive. > > See also: > http://www.winehq.org/pipermail/wine-devel/2010-May/083439.html > Thank you. I appreciate the link and will do. Misha

June 23, 2010

Re: [PATCH 2/2] d3dx9: Add stub and basic test for D3DXCreateSphere.

by Austin English

On Wed, Jun 23, 2010 at 10:29 AM, Misha Koshelev <misha680(a)gmail.com> wrote: > Oh, and please remind me as I do not quite recall. > > If we are in code freeze, does this mean that I should > (i) refrain from submitting patches until I have a large patchset that > is ready for testing or > (ii) submit anyway a bit at a time? 1) Please bottom post on wine mailing lists. 2) Avoid sending patches during code freeze, unless they fix a bug on the 1.2 list ( http://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bu… ), or are very small and not intrusive. See also: http://www.winehq.org/pipermail/wine-devel/2010-May/083439.html -- -Austin

June 23, 2010

Re: [PATCH 2/2] d3dx9: Add stub and basic test for D3DXCreateSphere.

by Misha Koshelev

Oh, and please remind me as I do not quite recall. If we are in code freeze, does this mean that I should (i) refrain from submitting patches until I have a large patchset that is ready for testing or (ii) submit anyway a bit at a time? Thank you Misha On Wed, Jun 23, 2010 at 10:19 AM, Misha Koshelev <misha680(a)gmail.com> wrote: > Oops. You know what - I'm not subscribed to wine-patches, that's why > they didn't go through ;) Doh! > > Misha > > On Wed, 2010-06-23 at 10:15 +0200, Henri Verbeet wrote: >> I think patch 1/2 is missing? Patches aren't picked up from >> wine-devel, you should send them to wine-patches. However, we're also >> currently in code freeze. > > >

June 23, 2010

Re: [PATCH 2/2] d3dx9: Add stub and basic test for D3DXCreateSphere.

by Misha Koshelev

Oops. You know what - I'm not subscribed to wine-patches, that's why they didn't go through ;) Doh! Misha On Wed, 2010-06-23 at 10:15 +0200, Henri Verbeet wrote: > I think patch 1/2 is missing? Patches aren't picked up from > wine-devel, you should send them to wine-patches. However, we're also > currently in code freeze.

June 23, 2010

Re: avifil32: Update Portuguese (Brazilian) translation

by Gustavo

No problem :) Thank you for the tip. 2010/6/23 Ricardo Filipe <ricardojdfilipe(a)gmail.com> > 2010/6/23 Gustavo <gugamilare(a)gmail.com>: > > Updated Brazilian Portuguese translation and changed codification of > > resource file to UTF-8 > > > > > > > > > > hi gustavo! > > thanks for doing the .br translations, and fixing sizes i overlooked > in the .pt translation. :) > however, you need to add the following line to the beginning of the > file when you change encoding to UTF-8: > #pragma code_page(65001) > > there are several resources where you can see that example. > > keep up the good work, > ricardo >

June 23, 2010

Re: Question about video capture and rendering and encoding in wine

by Maarten Lankhorst

Hello, 2010/6/23 shenyue <shenyue(a)magima.com.cn>: > Hi everyone, > > Previously I post this question on wine-user forum, seems nobody > answered/interested, so I post it here. Hope somebody give me > a hand :) > > I have some questions about wine video capture andrendering. > > I'm a newbie to wine, and am working on QQ or any other messengers in wine. > My environment is : ubuntu 10.04, installed wine 1.1.42 (later when I modify > code, wine-1.1.42's source instead), QQ2009. And during my debugging, I also > check some source code from latest wine 1.2-rc4. > > Although QQ's level is "garbage", but fortunately it works almost fine under > wine, including login, text chat, ..... But the video call can only > partially work.I can see my friend's(he's under windows of course) video, > while I can't see my preview video, and he cannot see mine video too. > And no audio at all. (Audio is another issue, I haven't deal with it now.) > > As a comparison, I run GraphEdt to check what's wrong with video capture and > rendering, my filter graph=video capture + video render. when I 'use clock', > the same thing happens, no video rendering at all, but when I DONOT > 'use clock', video rendering works fine. > > Then I read the source code and find out one problem(maybe right, maybe > wrong), when wine/dlls/qcap/v4l.c send media samples to downstream filters, > it do not set any timestamp on it. Thus if I use VideoRenderer as I did in > GraphEdt, the video render got wrong start and stop reference time for > media sample, and then the synchronisation result will be very strange. > So I modify the v4l.c and set proper timestamp on media sample. Good result, > even when I 'use clock', the capture+render graph works find in GraphEdt. > > But when I turn to QQ, my video capture+preview+encoding graph still seems > don't work. I only made it work for msn messenger a long time ago, in 6.2 or so. I'm surprised it still works. Only change since then has been adding support for libv4l. (v4l2 with v4l1 api) > Then I checked msdn for these things, according to msdn: > "Video frames from a preview pin (as opposed to a capture pin) are not time > stamped. Because of graph latency, a video frame that is stamped with the > capture time will always arrive late at the video renderer. This may cause > the renderer to drop frames, in an attempt at quality control." > "Quality control is a mechanism for adjusting the rate of data flow through > the filter graph in response to run-time performance. If a renderer filter > is receiving too much data or too little data, it can send a quality > message. The quality message requests an adjustment in the data rate. > By default, quality messages travel upstream from the renderer until > they reach a filter that can respond (if any)." > > I've cheked winedbg log, QQ's filter graph looks like: > vfw capture filter + QQ's own video render filter + ... + ddraw/d3d7 > rendering. > QQ did not use smarttee, preview pin, standard VideoRender or > VideoRenderDefault or VideoMixingRender9 (because QQ never query > their id). Instead, I guess QQ write a video render filter by itself, and in > QQ's render filter, it directly use ddraw/d3d7 surface to render, and maybe > it does something similar to smarttee, to output to preview and encoding > at the same time. Could it be a ddraw/d3d7 failure rather than a wine failure? > Since QQ did not use preview pin directly, at first I guess maybe 'not time > stamped' is not correct, so I add some timestamp to capture's output > video frame, still no preview occurs, but result in continuous > IQualityControl interface query, but even latest wine-1.2-rc4 has not > implemented IQualityControl, so I guess, still something wrong in > timestamp synchronisation, and QQ's video render want to use > IQualityControl to fix it which wine doesn't support, so maybe > every frame is dropped, this result in my black preview video window. > I read from wine docs/wiki, once before windows messenger (8.1?) worked fine > in wine, I guess since you have written qcap/vfwcapture, of course somebody > has used wine for camera+preview+maybe encoding before, why it succeeded > by then, but fail now? > Is there anything wrong for me? Because originally I only wrote it to work with msn messenger 6.2 ;). > Btw1: there's a bug in wine-1.1.42's dlls/quartz/memallocator.c, > MediaSample's GetTime() return value is wrong, I've fixed that bug > according to latest wine, but still no video preview, and my friend cannot > see my video. > > Btw2: since qcap only works for v4l1, I ran flashcam to convert v4l2 to > v4l1. But I still wondering, since Maarteen original code supports v4l2, why > it > result in only support v4l1 (but not both v4l1 and v4l2)? Sort of, I didn't adjust the code for v4l2, however with libv4l it should work in linux.. ~Maarten

June 23, 2010

Re: avifil32: Update Portuguese (Brazilian) translation

by Ricardo Filipe

2010/6/23 Gustavo <gugamilare(a)gmail.com>: > Updated Brazilian Portuguese translation and changed codification of > resource file to UTF-8 > > > > hi gustavo! thanks for doing the .br translations, and fixing sizes i overlooked in the .pt translation. :) however, you need to add the following line to the beginning of the file when you change encoding to UTF-8: #pragma code_page(65001) there are several resources where you can see that example. keep up the good work, ricardo

June 23, 2010

Re: [PATCH] winedevice: Use 64-bit wide delta when relocating

by Dmitry Timoshkov

Alessandro Pignotti <a.pignotti(a)sssup.it> wrote: > @@ -67,7 +67,8 @@ static HMODULE load_driver_module( const WCHAR *name ) > IMAGE_NT_HEADERS *nt; > const IMAGE_IMPORT_DESCRIPTOR *imports; > size_t page_size = getpagesize(); > - int i, delta; > + int i; > + intptr_t delta; You need to use SDK types, INT_PTR in this case. -- Dmitry.

June 23, 2010

Re: avifil32: Update Portuguese (Brazilian) translation

by Paul Vriens

On 06/23/2010 04:28 PM, Gustavo wrote: > Updated Brazilian Portuguese translation and changed codification of > resource file to UTF-8 > Hi Gustavo, If you change the encoding to UTF-8 you also need to add a "#pragma code_page(65001)", otherwise we'll end up with compile warnings like: Warning: string "Opções de compressão" seems to be UTF-8 but codepage 1252 is in use. Same is true for your other patches where you change the encoding. -- Cheers, Paul.

June 23, 2010

Re: [PATCH] user32: check for valid pointer in CURSORICON_CreateIconFromBMI

by Alexandre Julliard

Wolfram Sang <wolfram(a)the-dreams.de> writes: > @@ -884,6 +884,10 @@ static HICON CURSORICON_CreateIconFromBMI( BITMAPINFO *bmi, > return 0; > } > > + /* A few Windows versions crash getting NULL, but most simply return it */ > + if (!bmi) > + return 0; That's not the right place for it, this is an internal function. -- Alexandre Julliard julliard(a)winehq.org

June 23, 2010

Re: [PATCH 4/4] wined3d: use stretch_rect_fbo for swapchainless blits

by Henri Verbeet

On 22 June 2010 21:38, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > Regarding BltOverride in what way did you want to 'try the FBO blit > first'. Did you want fbo_blit_supported sorting out the 'unsupported > swapchain cases' (it lacks surface info and only has flags) itself or > was all you wanted just: > if ( !unhandled_swapchain_cases && !color_keying && fbo_blit_supported(..)) > stretch_rect_fbo(..); > > continue with all other checks > In principle inside fbo_blit_supported() should be fine, but for a part that's also what you're supposed to figure out. I.e., which of those checks are generic restrictions, which of those are fixed function blitter restrictions, which are FBO blitter restrictions, etc.

June 23, 2010

Re: msvcrt/tests: Make test_dup2() static.

by Francois Gouget

On Wed, 23 Jun 2010, testbot(a)testbot.winehq.org wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=2829 [...] > === W98SE (32 bit file) === > file.c:988: Test failed: smaller size block: Wrong error data () > file.c:996: Test failed: smaller size block: Stdout file shouldn't contain data This test does not have a history of failing on the Win98SE systems at test.winehq.org. Yet I don't see how this could be related to my patch since it happens in another part of the test. http://test.winehq.org/data/tests/msvcrt:file.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

June 23, 2010

Re: msvcr90/tests: Make test_invalid_parameter_handler() static.

by Francois Gouget

On Wed, 23 Jun 2010, testbot(a)testbot.winehq.org wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=2832 Apparently the test systems don't have this library. In fact this library seems to be very rare: apparently only of the test machines has it on test.winehq.org. http://test.winehq.org/data/tests/msvcr90:msvcr90.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

June 23, 2010

Re: shlwapi/tests: Make the XXX_Construct() functions static.

by Francois Gouget

On Wed, 23 Jun 2010, testbot(a)testbot.winehq.org wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=2830 These were present before my patch. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything.

June 23, 2010

Re: [PATCH 2/2] d3dx9: Add stub and basic test for D3DXCreateSphere.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2859 Your paranoid android. === WINEBUILD (build) === Make failed

June 23, 2010

Re: oledlg: Add the Romanian translation.

by Alexandru Băluț

2010/6/23 Michael Stefaniuc <mstefani(a)redhat.com>: > + CONTROL "Creează un nou",IDC_CREATENEW,"Button",BS_AUTORADIOBUTTON | > + WS_GROUP,7,20,67,10 "Creează nou" seems better, the original is "Create New", not "Create a New". I don't really get what "Create New" is supposed to mean, or what is the difference between the "Create New" and "Create Control", since for both you press the same button "Add Control...", so both actually create a Control. I might be wrong. > + PUSHBUTTON "&Adăugare control...",IDC_ADDCONTROL,81,88,67,14,NOT WS_VISIBLE This is a button, "&Adaugă [...]" seems more appropriate. "&Adaugă un control" would be consistent with "Creează un control" which is used for a radio button. > +CAPTION "Paste Special" It should say "Inserare specială", to be consistent with: > + CONTROL "I&nserează", IDC_PS_PASTE, "Button", BS_AUTORADIOBUTTON | WS_TABSTOP | WS_GROUP | WS_VISIBLE, > + CONTROL "Inserează &linkul", IDC_PS_PASTELINK, "Button", BS_AUTORADIOBUTTON | WS_VISIBLE, Is "Inserează &legătura" wrong? > + IDS_PS_PASTE_DATA "Inserează conținutul din clipboard în document ca %s." > + IDS_PS_PASTE_OBJECT "Inserează conținutul din clipboard în document astfel încât să îl puteți activa utilizând %s." > + IDS_PS_PASTE_OBJECT_AS_ICON "Inserează conținutul din clipboard în document astfel încât să îl puteți activa utilizând %s. Va fi afișat ca o pictogramă." > + IDS_PS_PASTE_LINK_DATA "Inserează conținutul din clipboard în document ca %s. Datele sunt legate de fișierul sursă, astfel încât modificările aduse fișierului vor fi reflectate în document." > + IDS_PS_PASTE_LINK_OBJECT "Inserați o imagine a conținutului din clipboard în document. Imaginea este legată de fișierul sursă, astfel încât modificările aduse fișierului vor fi reflectate în document." > + IDS_PS_PASTE_LINK_OBJECT_AS_ICON "Inserați o scurtătură care conduce la locația conținutului din clipboard. Scurtătura este legată de fișierul sursă, astfel încât modificările aduse fișierului vor fi reflectate în document." > + IDS_PS_NON_OLE "Inserează conținutul din clipboard în document." All the English messages for these start with "Inserts [...]" - We should be consistent, and use "Inserează [...]" for all of them. Thanks, Alex

June 23, 2010

Re: msvfw32: Add the Romanian translation.

by Michael Stefaniuc

Alexandru Băluț wrote: > On Wed, Jun 23, 2010 at 01:14, Michael Stefaniuc <mstefani(a)redhat.com> wrote: >> + CONTROL "&Toate cadre cheie",887,"Button",BS_AUTOCHECKBOX|WS_TABSTOP,9,60,70,12 >> + EDITTEXT 888,82,60,22,12 >> + LTEXT "Cadre",889,106,62,22,10 > > This will look like "Toate cadre cheie X Cadre" and it does not make sense. > The original message is "Key Frame Every X frames" - it could be translated as > "Cadru cheie la fiecare X cadre". Heh, Claudia had it correct; that was my error. It looked strange when I checked the dialog in ResHacker. I'll fix it. Thanks bye michael

June 23, 2010

Re: msvfw32: Add the Romanian translation.

by Alexandru Băluț

On Wed, Jun 23, 2010 at 01:14, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > + CONTROL "&Toate cadre cheie",887,"Button",BS_AUTOCHECKBOX|WS_TABSTOP,9,60,70,12 > + EDITTEXT 888,82,60,22,12 > + LTEXT "Cadre",889,106,62,22,10 This will look like "Toate cadre cheie X Cadre" and it does not make sense. The original message is "Key Frame Every X frames" - it could be translated as "Cadru cheie la fiecare X cadre". Thanks, Alex

June 23, 2010

Re: wined3d: Better validation of BltFast destination

by Iain Arnell

On Wed, Jun 23, 2010 at 11:47 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 23 June 2010 10:40, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> I recommend to put this check into ddraw, >> like in your previous attempts(but keep checking for < 0, don't do any bit >> testing magic like in your old patches) >> > Both of you, please don't ever work on any kind of critical system. Seriously. > > Does the attached patch help? Ah! Yes, and thank you for the enlightenment. -- Iain.

June 23, 2010

Question about video capture and rendering and encoding in wine

by shenyue

Hi everyone, Previously I post this question on wine-user forum, seems nobody answered/interested, so I post it here. Hope somebody give me a hand :) I have some questions about wine video capture andrendering. I'm a newbie to wine, and am working on QQ or any other messengers in wine. My environment is : ubuntu 10.04, installed wine 1.1.42 (later when I modify code, wine-1.1.42's source instead), QQ2009. And during my debugging, I also check some source code from latest wine 1.2-rc4. Although QQ's level is "garbage", but fortunately it works almost fine under wine, including login, text chat, ..... But the video call can only partially work.I can see my friend's(he's under windows of course) video, while I can't see my preview video, and he cannot see mine video too. And no audio at all. (Audio is another issue, I haven't deal with it now.) As a comparison, I run GraphEdt to check what's wrong with video capture and rendering, my filter graph=video capture + video render. when I 'use clock', the same thing happens, no video rendering at all, but when I DONOT 'use clock', video rendering works fine. Then I read the source code and find out one problem(maybe right, maybe wrong), when wine/dlls/qcap/v4l.c send media samples to downstream filters, it do not set any timestamp on it. Thus if I use VideoRenderer as I did in GraphEdt, the video render got wrong start and stop reference time for media sample, and then the synchronisation result will be very strange. So I modify the v4l.c and set proper timestamp on media sample. Good result, even when I 'use clock', the capture+render graph works find in GraphEdt. But when I turn to QQ, my video capture+preview+encoding graph still seems don't work. Then I checked msdn for these things, according to msdn: "Video frames from a preview pin (as opposed to a capture pin) are not time stamped. Because of graph latency, a video frame that is stamped with the capture time will always arrive late at the video renderer. This may cause the renderer to drop frames, in an attempt at quality control." "Quality control is a mechanism for adjusting the rate of data flow through the filter graph in response to run-time performance. If a renderer filter is receiving too much data or too little data, it can send a quality message. The quality message requests an adjustment in the data rate. By default, quality messages travel upstream from the renderer until they reach a filter that can respond (if any)." I've cheked winedbg log, QQ's filter graph looks like: vfw capture filter + QQ's own video render filter + ... + ddraw/d3d7 rendering. QQ did not use smarttee, preview pin, standard VideoRender or VideoRenderDefault or VideoMixingRender9 (because QQ never query their id). Instead, I guess QQ write a video render filter by itself, and in QQ's render filter, it directly use ddraw/d3d7 surface to render, and maybe it does something similar to smarttee, to output to preview and encoding at the same time. Since QQ did not use preview pin directly, at first I guess maybe 'not time stamped' is not correct, so I add some timestamp to capture's output video frame, still no preview occurs, but result in continuous IQualityControl interface query, but even latest wine-1.2-rc4 has not implemented IQualityControl, so I guess, still something wrong in timestamp synchronisation, and QQ's video render want to use IQualityControl to fix it which wine doesn't support, so maybe every frame is dropped, this result in my black preview video window. I read from wine docs/wiki, once before windows messenger (8.1?) worked fine in wine, I guess since you have written qcap/vfwcapture, of course somebody has used wine for camera+preview+maybe encoding before, why it succeeded by then, but fail now? Is there anything wrong for me? Btw1: there's a bug in wine-1.1.42's dlls/quartz/memallocator.c, MediaSample's GetTime() return value is wrong, I've fixed that bug according to latest wine, but still no video preview, and my friend cannot see my video. Btw2: since qcap only works for v4l1, I ran flashcam to convert v4l2 to v4l1. But I still wondering, since Maarteen original code supports v4l2, why it result in only support v4l1 (but not both v4l1 and v4l2)? Thank you very much in advance. Best regards, Karma 搬迁通知： 2010年1月18日起，上海奇码数字信息有限公司迁至新址办公。新地址为：上海张江祖冲之路887弄88号502室。 ==========================================================

June 23, 2010

Re: wined3d: Better validation of BltFast destination

by Michael Stefaniuc

Iain Arnell wrote: > On Wed, Jun 23, 2010 at 10:47 AM, Stefan Dösinger > <stefandoesinger(a)gmx.at> wrote: >> Am Mittwoch 23 Juni 2010 10:40:30 schrieb Stefan Dösinger: >>> You're catching only the GDI surface case here since opengl surfaces don't >>> use IWineD3DBaseSurfaceImpl_BltFast. I recommend to put this check into >>> ddraw, like in your previous attempts(but keep checking for < 0, don't do >>> any bit testing magic like in your old patches) > > I'd hope that the opengl implementation also has some checking of its own. > > I did the nasty bit twiddling to avoid making any assumptions about > equivalence of types (is it always safe to assume that DWORD can be > cast as a LONG?). And gcc optimizes dstx < 0 away as "comparison of > unsigned expression < 0 is always false". In the Windows world: - DWORD == unsigned int32 - LONG == signed int32 bye michael

June 23, 2010

Re: wined3d: Better validation of BltFast destination

by Henri Verbeet

On 23 June 2010 10:40, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > I recommend to put this check into ddraw, > like in your previous attempts(but keep checking for < 0, don't do any bit > testing magic like in your old patches) > Both of you, please don't ever work on any kind of critical system. Seriously. Does the attached patch help?

June 23, 2010

Re: wined3d: Better validation of BltFast destination

by Iain Arnell

On Wed, Jun 23, 2010 at 10:47 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Mittwoch 23 Juni 2010 10:40:30 schrieb Stefan Dösinger: >> You're catching only the GDI surface case here since opengl surfaces don't >> use IWineD3DBaseSurfaceImpl_BltFast. I recommend to put this check into >> ddraw, like in your previous attempts(but keep checking for < 0, don't do >> any bit testing magic like in your old patches) I'd hope that the opengl implementation also has some checking of its own. I did the nasty bit twiddling to avoid making any assumptions about equivalence of types (is it always safe to assume that DWORD can be cast as a LONG?). And gcc optimizes dstx < 0 away as "comparison of unsigned expression < 0 is always false". >> Am Dienstag 22 Juni 2010 23:37:20 schrieb Iain Arnell: >> > Scratch this - after thinking again about Henri's hint, I've moved the >> > fix to wined3d. > I searched the archives to see if I missed any of Henri's suggestions but I > couldn't find any like that. My consideration is that ddraw already has the > other range checks, so it would just be consistent to keep it there. besides, > in many situations ddraw, d3d8 and d3d9 have different checks or behavior in > case of wrong parameters(see for example surface locking) > > (ok, the latter is somewhat academic since only ddraw calls BltFast directly) Henri's magic words were simply "integer overflow". So I looked for the point where this actually happens. And I could make the same argument for making the check in wined3d - it also makes a whole bunch of range checks. But, of course, I'm willing to bow to your better judgement. -- Iain.

June 23, 2010

Re: wined3d: Better validation of BltFast destination

by Stefan Dösinger

Am Mittwoch 23 Juni 2010 10:40:30 schrieb Stefan Dösinger: > You're catching only the GDI surface case here since opengl surfaces don't > use IWineD3DBaseSurfaceImpl_BltFast. I recommend to put this check into > ddraw, like in your previous attempts(but keep checking for < 0, don't do > any bit testing magic like in your old patches) > Am Dienstag 22 Juni 2010 23:37:20 schrieb Iain Arnell: > > Scratch this - after thinking again about Henri's hint, I've moved the > > fix to wined3d. I searched the archives to see if I missed any of Henri's suggestions but I couldn't find any like that. My consideration is that ddraw already has the other range checks, so it would just be consistent to keep it there. besides, in many situations ddraw, d3d8 and d3d9 have different checks or behavior in case of wrong parameters(see for example surface locking) (ok, the latter is somewhat academic since only ddraw calls BltFast directly)

June 23, 2010

Re: wined3d: Better validation of BltFast destination

by Stefan Dösinger

Am Dienstag 22 Juni 2010 23:37:20 schrieb Iain Arnell: > --- a/dlls/wined3d/surface_base.c > +++ b/dlls/wined3d/surface_base.c > @@ -1657,6 +1657,11 @@ HRESULT WINAPI > IWineD3DBaseSurfaceImpl_BltFast(IWineD3DSurface *iface, DWORD dst > lock_dst.right = dstx + w; > lock_dst.bottom = dsty + h; > > + if ( lock_dst.left < 0 || lock_dst.top < 0 ) { > + WARN("Application gave us bad desitination offset for > BltFast.\n"); + return WINEDDERR_INVALIDRECT; > + } You're catching only the GDI surface case here since opengl surfaces don't use IWineD3DBaseSurfaceImpl_BltFast. I recommend to put this check into ddraw, like in your previous attempts(but keep checking for < 0, don't do any bit testing magic like in your old patches)

June 23, 2010

Re: [PATCH 2/2] d3dx9: Add stub and basic test for D3DXCreateSphere.

by Henri Verbeet

I think patch 1/2 is missing? Patches aren't picked up from wine-devel, you should send them to wine-patches. However, we're also currently in code freeze.

June 23, 2010