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

Re: shdocvw: Update French translation

by Frédéric Delanoy

Please discard; has been mangled by misconfigured git 2010/8/2 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > --- > dlls/shdocvw/Fr.rc | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/dlls/shdocvw/Fr.rc b/dlls/shdocvw/Fr.rc > index 94b4a7e..b7326bb 100644 > --- a/dlls/shdocvw/Fr.rc > +++ b/dlls/shdocvw/Fr.rc > @@ -55,6 +55,11 @@ IDR_BROWSE_MAIN_MENU MENU > MENUITEM SEPARATOR > MENUITEM "&Propriétés...", ID_BROWSE_PROPERTIES > } > + POPUP "&Favoris" > + { > + MENUITEM "&Ajouter aux favoris..." ID_BROWSE_ADDFAV > + MENUITEM SEPARATOR > + } > POPUP "&Aide" > { > MENUITEM "À &propos d'Internet Explorer...", ID_BROWSE_ABOUT > -- > 1.7.2 > >

Aug. 2, 2010

Re: [PATCH 1/6] winealsa.drv: Init mixer on cards with a single Mic control, like snd_usb_audio mics (try 2)

by Ricardo Filipe

2010/8/2 Jeff Cook <jeff(a)deserettechnology.com>: > What compiler are you running? It works fine for me and I don't see > any errors or warnings. > > On Mon, Aug 2, 2010 at 6:05 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Jeff Cook <jeff(a)deserettechnology.com> writes: >> >>> @@ -245,6 +245,10 @@ static void fillcontrols(mixer *mmixer) >>> for (id = 0; id < mmixer->chans; ++id) >>> { >>> line *mline = &mmixer->lines[id]; >>> + if (!mline->elem) >>> + { >>> + break; >>> + } >>> int ofs = CONTROLSPERLINE * id; >> >> You can't do that: >> >> mixer.c: In function ‘fillcontrols’: >> mixer.c:252: error: ISO C90 forbids mixed declarations and code >> >> -- >> Alexandre Julliard >> julliard(a)winehq.org >> > > > it's not compiler related. you can't mix variable declarations with code in C90 standard. just move that check to the end of all variable declarations and it'll be fine.

Aug. 2, 2010

Re: [PATCH 1/6] winealsa.drv: Init mixer on cards with a single Mic control, like snd_usb_audio mics (try 2)

by Jeff Cook

What compiler are you running? It works fine for me and I don't see any errors or warnings. On Mon, Aug 2, 2010 at 6:05 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Jeff Cook <jeff(a)deserettechnology.com> writes: > >> @@ -245,6 +245,10 @@ static void fillcontrols(mixer *mmixer) >> for (id = 0; id < mmixer->chans; ++id) >> { >> line *mline = &mmixer->lines[id]; >> + if (!mline->elem) >> + { >> + break; >> + } >> int ofs = CONTROLSPERLINE * id; > > You can't do that: > > mixer.c: In function ‘fillcontrols’: > mixer.c:252: error: ISO C90 forbids mixed declarations and code > > -- > Alexandre Julliard > julliard(a)winehq.org >

Aug. 2, 2010

Re: The WineAPI wiki.

by Gert van den Berg

On Mon, Aug 2, 2010 at 19:26, Max TenEyck Woodbury <max(a)mtew.isa-geek.net> wrote: > On 08/02/2010 01:04 PM, Gert van den Berg wrote: > >> There seem to be several interfaces to retreive MSDN articles... Some >> of those interface might be more stable / provide a way to retrieve a >> current link? (Framing the content would probably not be allowed, but >> retreiving links should be...) >> > If it *looks* like copying, it should be avoided. What I meant is, that it would allow for things like some really nice side-to-side postings of Wine's documentation and MSDN... It is unlikely to be legal though... (And should therefore be avoided) > I think it will be necessary to regenerate articles as the Wine project > evolves. I regenerated the 'dlls' page after Alexandre's CVS run today. > There was some new content so I saved the result. I've regenerated the > individual DLL pages several times as I improved the generating > scripts. Both activities put a load on me that I am trying to automate. > In fact, if you look at the original post before it got hijacked into a > discussion of the project name, it asks about a way to improve that > automation. > > Since there will be fairly frequent semi-intelligent reviews of pages, > such queries can probably be incorporated into that process. > > Can you help me with this, please? I can give an overview of what I think... I might do a bit of implementation, but finishing something bigger than a short script when I have other things to do isn't always easy... Sourceforge provides quite decent hosting in the project hosting space as well... Automating things from there might be a good idea. To handle MSDN, I can see the following (very) high level process: Posted MSDN links gets converted to point to redirect system in the project space. (The conversion retrieves and save some additional data). The redirect system will redirect the user to relevant content on current MSDN (allowing user to configure some parameters, such as view type / language) What I managed to figure out about MSDN content for the Web services documentation this far: 1. Content is identified by a Content identifier, which can be any of the following: a. GUID b. Short ID (Short (~8 character) unique identifier such as ms224917) c. Alias ("Friendly string") d. asset ID (Documented here: http://msdn.microsoft.com/en-us/magazine/cc163541.aspx Can be used to retrieve other (non-URL) identifiers) e Content URL (The URL to an MSDN page) 2. A Content key uniquely identifies an article and consists of a content identifier, locale and version 3 The version.identifies the various versions of the documented item. e.g. the .NET version / VC++ version 4. Locale identifies preferred language More detailed version: 1. Find MSDN URL and retrieve other identifiers (GetContent without a locale seem to retreive almost all the metadata ("partial match" in the docmentaiton)) 2. Store data in database, with GUID / short ID / assetID as primary key (they are always-present unique identifiers) other fields include alias, current URL. (content table) 3. Other tables: Locales and versions. Mapping tables between content and possible locales and versions hould also exist. The content table should save when the data was last updated and it should be automatically updated once it reaches a certain age and an user wants to retreive the page / select a non-default locale / version. 4. Generate new link pointing to the redirector system. The redirector system needs the unique content identifier (GUID / shortID / assetID) and preferably a version. It should be able to take a parameter to preview the URL (probably a smaller "options link") and allow the user to choose other locales / versions and generate links to those. This "content options" page should also allow problems with the redirector's link to be reported. The reports should be used to update the information for that link by querying it again from MSDN. It might require several trips to MSDN to initially add an item / to update versions and locales. This should possibly scheduled once the data get really old (somewhere between 180 days and 1 year) and be run on demand when someone requests the content from somewhere where they might want to see the other versions / locales about half the scheduled update age. This should keep the request volumes to MSDN low... MSDN changes and updates required: 1. Changes to web services interface: Update relevant parts (This shouldn't be too serious as long as the entire interface is not redesigned) 2. Link changes: Change how the URLs are generated from the identifiers in the database (I don't see an easy way to request an URL from the web services interface) Other possible extensions: The "redirector" can build a more complete view of what is available to allow documentation to be found easier (the information should only be retrieved on demand and saved) and to prevent duplicate trips to MSDN. (This should eventually provide a nice "tree" of MSDN with reliable links to the content) Gert

Aug. 2, 2010

Latest version of ddraw/tests plus fixes

by Oldřich Jedlička

Hi Stefan, Roderick, I've sent my latest version of ddraw/tests plus some fixes right now (it takes some time to get to wine-patches ML), one of them fixes bug #9008. Unfortunately I don't have much spare time (and actually I didn't have it the whole time working on patches), my spare time is almost over now, so I would appreciate some last comments - what to remove (if there is something unacceptable), what to change. But I don't have more time to enhance the backbuffers+3D interaction investigations/tests, sorry. It would be great if you let the fix for bug #9008 go into the wine tree. Thanks! Regards, Oldřich.

Aug. 2, 2010

Re: wordpad: Added Hebrew translation.

by Yaron Shahrabani

On Mon, Aug 2, 2010 at 6:33 PM, Alexandre Julliard <julliard(a)winehq.org>wrote: > Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > > >> Eventually we probably have to but I'm not sure what Alexandre > >> thinks about introducing it (now). We probably also have to teach > >> our tools (like the translation site) that detects translation > >> differences/issues to cope with this. > >> > >> So I shouldn't add that for now? > > > > I don't know what Alexandre's opinion is here. > > Adding WS_EX_LAYOUTRTL is fine. It won't have any effect today, but it > will be useful as a test case once we start implementing it. And yes, > the translation site will need to cope with this (and maybe signal an > error when the RTL flag doesn't match the dialog language). > Great! Thanks a lot! And Paul, my computer can barely run the basic games that ship with Ubuntu, so compiling wine is out of question :) > > -- > Alexandre Julliard > julliard(a)winehq.org >

Aug. 2, 2010

Re: The WineAPI wiki.

by Max TenEyck Woodbury

On 08/02/2010 01:04 PM, Gert van den Berg wrote: > There seem to be several interfaces to retreive MSDN articles... Some > of those interface might be more stable / provide a way to retrieve a > current link? (Framing the content would probably not be allowed, but > retreiving links should be...) > If it *looks* like copying, it should be avoided. > .... (It might also work to try and retreive as much information > about MSDN links when they are posted, in order to allow the > links to be updated when the site stucture change?) (Doing a web > service query everytime to retreive a link would probably be slow >and inefficient...) > I think it will be necessary to regenerate articles as the Wine project evolves. I regenerated the 'dlls' page after Alexandre's CVS run today. There was some new content so I saved the result. I've regenerated the individual DLL pages several times as I improved the generating scripts. Both activities put a load on me that I am trying to automate. In fact, if you look at the original post before it got hijacked into a discussion of the project name, it asks about a way to improve that automation. Since there will be fairly frequent semi-intelligent reviews of pages, such queries can probably be incorporated into that process. Can you help me with this, please? - Max

Aug. 2, 2010

Re: The WineAPI wiki.

by Gert van den Berg

On Mon, Aug 2, 2010 at 18:16, Max TenEyck Woodbury <max(a)mtew.isa-geek.net> wrote: > There should be links to the Microsoft documentation in each article, > but Microsoft has been known to move their documentation around without > maintaining redirects. To avoid being at Microsoft's mercy in this, a > summary (*not* a duplicate) of the Microsoft articles, which would be > fair use, should be maintained. There seem to be several interfaces to retreive MSDN articles... Some of those interface might be more stable / provide a way to retrieve a current link? (Framing the content would probably not be allowed, but retreiving links should be...) http://blogs.msdn.com/b/innovation/archive/2009/04/22/launching-low-bandwid… Some more: http://blogs.msdn.com/b/innovation/archive/2009/10/26/launching-lightweight… Web service interface: http://services.msdn.microsoft.com/ContentServices/ContentService.asmx (possibly the most useful for building current links?) (It might also work to try and retreive as much information about MSDN links when they are posted, in order to allow the links to be updated when the site stucture change?) (Doing a web service query everytime to retreive a link would probably be slow and inefficient...) Gert

Aug. 2, 2010

Re: write: Added Hebrew translation

by Yaron Shahrabani

LOL, I knew I forgot something... Yaron Shahrabani <Hebrew translator> On Mon, Aug 2, 2010 at 6:13 PM, Paul Vriens <paul.vriens.wine(a)gmail.com>wrote: > On 08/02/2010 04:57 PM, Yaron Shahrabani wrote: > >> +++ b/programs/write/He.rc >> @@ -0,0 +1,30 @@ >> +/* >> + * English language support >> > > Should be 'Hebrew' of course ;) > > -- > Cheers, > > Paul. >

Aug. 2, 2010

Re: The WineAPI wiki.

by Max TenEyck Woodbury

On 08/02/2010 11:18 AM, James Mckenzie wrote: > Max TenEyck Woodbury<max(a)mtew.isa-geek.net> wrote: > >> On 08/02/2010 07:00 AM, Dmitry Timoshkov wrote: >>> Max TenEyck Woodbury<max(a)mtew.isa-geek.net> wrote: >>> >>>> I have started the WineAPI wiki at >>>> >>>> https://sourceforge.net/apps/mediawiki/wineapi/index.php?title=Main_Page >>> >>> You have chosen not very good name. There is no such a thing as Wine API, >>> Wine implements Win32 API, and doesn't specify/add anything custom to it. >>> The name "WineAPI" implies that Wine defines its own API which is not true, >>> and is confusing. >>> > This should be named, the Windows32/Window64 API as implemented by Wine > Documentation site. That is what it is. We have found shortcomings in > the MSDN documentation (I'm dealing with this right now in one function > call for Richedit.) This should be a collaborative site where Wine > developers, Windows on Wine developers and others can place information > on what Wine has implemented today, what needs to be implemented (with > case code and discoveries) and what Wine cannot implement. > Hmm, I may change the brief project description to match that. I will think about it... >> There is a lot of information specific to Wine, particularly its >> internal structure, that is not shared with Microsoft's product. >> Further, there is a little confusing and incorrect information in the >> Microsoft documentation. Bluntly, the Microsoft documentation is what >> they want it to be. We need to document what it really is. >> >> We have tried to embed API documentation in the source code. That has >> not worked as well as it could. Alexandre Julliard has said as much. I >> think that having good documentation will help the project. Not having >> good documentation can and does hurt Wine in my opinion. I also think >> that trying to prevent the creation of that documentation might be >> harmful. > > AJ has stated that documenting the Windows API and internal API calls >should NOT be documented just in the source. It bloats the source code >terribly and can make code unreadable. > > I agree that this Wiki should only be used to document the external > interfaces to Wine as we implement Windows32/Windows64 API/ABI calls > and what we have found in our testing that is different than MSDN. > We should NOT duplicate MSDN where is is proper, but rather have a > note that states MSDN and other sources have been found to be proper. > I disagree. Really good documentation includes 'Theory of Operation'. Of course we do not have that for the Microsoft code, but it *may* be helpful for our own code. I think documenting our test code would also be useful. There should be links to the Microsoft documentation in each article, but Microsoft has been known to move their documentation around without maintaining redirects. To avoid being at Microsoft's mercy in this, a summary (*not* a duplicate) of the Microsoft articles, which would be fair use, should be maintained. - Max

Aug. 2, 2010

Re: The WineAPI wiki.

by Max TenEyck Woodbury

On 08/02/2010 11:25 AM, Dmitry Timoshkov wrote: > Max TenEyck Woodbury<max(a)mtew.isa-geek.net> wrote: > >>>> Further, there is a little confusing and incorrect information in the >>>> Microsoft documentation. Bluntly, the Microsoft documentation is what >>>> they want it to be. We need to document what it really is. >>> >>> Regardless of the quality of Microsoft documentation it's still Win32 API, >>> not a Wine API. >>> >> And it is Microsoft's documentation and nominally documents their code. >> We have to document *our* code. There will be differences. Differences >> that I expect will be removed when found unless we can show that the >> Microsoft documentation is, in fact, incorrect. > > An API is Application Programming Interface, not the code or implementation > details. The API is for application programmers, not for system's analists. > If the Wine implementaion of win32 differs from Microsoft one - that's a bug, > it's not worth documenting, it's worth a bug report and fixing. > Your implication that I do not know wat 'API' stands for comes very close to being an insult. Please stop. The readable title is 'Wine API *and related documentation*'. Documentation is used for many purposes. Application programmers use it, but system's analysts also use it. Telling me that it can not be used any way but your way is arrogant. Implementation and documentation are two different things. Bugs can, and in some cases should, be documented. I am not asking you to do anything in particular. That would be arrogance on my part. - Max

Aug. 2, 2010

Re: [PATCH 1/4] wined3d: separate driver info from GPU info

by Roderick Colenbrander

On Mon, Aug 2, 2010 at 2:58 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 1 August 2010 05:37, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: >> struct driver_version_information >> { >> + WORD vendor; /* reported PCI card vendor ID */ > ... >> + enum wined3d_display_driver driver; >> +}; > That doesn't make all that much sense. > I agree that the vendor is redundant or did you mean the driver field didn't make sense? It is needed for selecting a different driver + version (especially on Intel the driver name depends on the gpu). Roderick

Aug. 2, 2010

Re: wordpad: Added Hebrew translation.

by Alexandre Julliard

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: >> Eventually we probably have to but I'm not sure what Alexandre >> thinks about introducing it (now). We probably also have to teach >> our tools (like the translation site) that detects translation >> differences/issues to cope with this. >> >> So I shouldn't add that for now? > > I don't know what Alexandre's opinion is here. Adding WS_EX_LAYOUTRTL is fine. It won't have any effect today, but it will be useful as a test case once we start implementing it. And yes, the translation site will need to cope with this (and maybe signal an error when the RTL flag doesn't match the dialog language). -- Alexandre Julliard julliard(a)winehq.org

Aug. 2, 2010

Re: The WineAPI wiki.

by Dmitry Timoshkov

Max TenEyck Woodbury <max(a)mtew.isa-geek.net> wrote: > >> Further, there is a little confusing and incorrect information in the > >> Microsoft documentation. Bluntly, the Microsoft documentation is what > >> they want it to be. We need to document what it really is. > > > > Regardless of the quality of Microsoft documentation it's still Win32 API, > > not a Wine API. > > > And it is Microsoft's documentation and nominally documents their code. > We have to document *our* code. There will be differences. Differences > that I expect will be removed when found unless we can show that the > Microsoft documentation is, in fact, incorrect. An API is Application Programming Interface, not the code or implementation details. The API is for application programmers, not for system's analists. If the Wine implementaion of win32 differs from Microsoft one - that's a bug, it's not worth documenting, it's worth a bug report and fixing. -- Dmitry.

Aug. 2, 2010

Re: The WineAPI wiki.

by James Mckenzie

Max TenEyck Woodbury <max(a)mtew.isa-geek.net> wrote: >Sent: Aug 2, 2010 4:25 AM >To: wine-devel(a)winehq.org >Subject: Re: The WineAPI wiki. > >On 08/02/2010 07:00 AM, Dmitry Timoshkov wrote: >> Max TenEyck Woodbury<max(a)mtew.isa-geek.net> wrote: >> >>> I have started the WineAPI wiki at >>> >>> https://sourceforge.net/apps/mediawiki/wineapi/index.php?title=Main_Page >> >> You have chosen not very good name. There is no such a thing as Wine API, >> Wine implements Win32 API, and doesn't specify/add anything custom to it. >> The name "WineAPI" implies that Wine defines its own API which is not true, >> and is confusing. >> This should be named, the Windows32/Window64 API as implemented by Wine Documentation site. That is what it is. We have found shortcomings in the MSDN documentation (I'm dealing with this right now in one function call for Richedit.) This should be a collaborative site where Wine developers, Windows on Wine developers and others can place information on what Wine has implemented today, what needs to be implemented (with case code and discoveries) and what Wine cannot implement. >This has been discussed elsewhere on this mailing list. > Agreed. >There is a lot of information specific to Wine, particularly its >internal structure, that is not shared with Microsoft's product. >Further, there is a little confusing and incorrect information in the >Microsoft documentation. Bluntly, the Microsoft documentation is what >they want it to be. We need to document what it really is. > >We have tried to embed API documentation in the source code. That has >not worked as well as it could. Alexandre Julliard has said as much. I >think that having good documentation will help the project. Not having >good documentation can and does hurt Wine in my opinion. I also think >that trying to prevent the creation of that documentation might be >harmful. AJ has stated that documenting the Windows API and internal API calls should NOT be documented just in the source. It bloats the source code terribly and can make code unreadable. I agree that this Wiki should only be used to document the external interfaces to Wine as we implement Windows32/Windows64 API/ABI calls and what we have found in our testing that is different than MSDN. We should NOT duplicate MSDN where is is proper, but rather have a note that states MSDN and other sources have been found to be proper. As to the griping, we need to be public with our progress. This eliminates confusion and also gives new developers a place to start. James McKenzie

Aug. 2, 2010

Re: wordpad: Added Hebrew translation.

by Paul Vriens

On 08/02/2010 05:04 PM, Yaron Shahrabani wrote: > On Sun, Aug 1, 2010 at 4:59 PM, Paul Vriens <paul.vriens.wine(a)gmail.com > <mailto:paul.vriens.wine(a)gmail.com>> wrote: > > Hi Yaron, > > > On 08/01/2010 10:52 AM, Yaron Shahrabani wrote: > > Alexander and Paul, please notice I added the EXSTYLE > WS_EX_LAYOUTRTL > for the dialogs, hope that helps. > > Also found out that menus does not need any special RTL > property, they > are self aligned according to the app. > > > What do you mean by that? Running Wordpad in Hebrew still gives me > LTR menu styles/justification. The global (per process) RTL settings > still need to be implemented for our internal apps. > > Of course but menus don't have a special propery meaning that there is > no special addition to the POPUP object... (like WS_EX_LAYOUTRTL for > windows) Ok, I thought you meant that it magically worked for you. > Eventually we probably have to but I'm not sure what Alexandre > thinks about introducing it (now). We probably also have to teach > our tools (like the translation site) that detects translation > differences/issues to cope with this. > > So I shouldn't add that for now? I don't know what Alexandre's opinion is here. > ../../../wine-git/programs/wordpad/He.rc:279:32: Error: Stringtable > ID 1416 already in use > > Is there any way to deal with such errors (I can't compile wordpad since > there's no Makefile)? I usually run a full 'make' from the root of the tree (I'm using an out-of-tree build directory btw). -- Cheers, Paul.

Aug. 2, 2010

Re: write: Added Hebrew translation

by Paul Vriens

On 08/02/2010 04:57 PM, Yaron Shahrabani wrote: > +++ b/programs/write/He.rc > @@ -0,0 +1,30 @@ > +/* > + * English language support Should be 'Hebrew' of course ;) -- Cheers, Paul.

Aug. 2, 2010

Re: wordpad: Added Hebrew translation.

by Yaron Shahrabani

On Sun, Aug 1, 2010 at 4:59 PM, Paul Vriens <paul.vriens.wine(a)gmail.com>wrote: > Hi Yaron, > > > On 08/01/2010 10:52 AM, Yaron Shahrabani wrote: > >> Alexander and Paul, please notice I added the EXSTYLE WS_EX_LAYOUTRTL >> for the dialogs, hope that helps. >> >> Also found out that menus does not need any special RTL property, they >> are self aligned according to the app. >> > > What do you mean by that? Running Wordpad in Hebrew still gives me LTR menu > styles/justification. The global (per process) RTL settings still need to be > implemented for our internal apps. > Of course but menus don't have a special propery meaning that there is no special addition to the POPUP object... (like WS_EX_LAYOUTRTL for windows) > > >> Kind regards, >> Yaron Shahrabani >> >> <Hebrew translator> >> >> >> >> 0002-wordpad-Added-Hebrew-translation.patch >> >> >> From 8f5dfcb55656e7e4d7943d622234fb37753210f7 Mon Sep 17 00:00:00 2001 >> From: Yaron Shahrabani<sh.yaron(a)gmail.com> >> Date: Sun, 1 Aug 2010 11:48:23 +0300 >> Subject: wordpad: Added Hebrew translation. >> >> --- >> programs/wordpad/He.rc | 282 >> ++++++++++++++++++++++++++++++++++++++++++ >> programs/wordpad/Makefile.in | 1 + >> 2 files changed, 283 insertions(+), 0 deletions(-) >> create mode 100644 programs/wordpad/He.rc >> >> diff --git a/programs/wordpad/He.rc b/programs/wordpad/He.rc >> new file mode 100644 >> index 0000000..091ec98 >> --- /dev/null >> +++ b/programs/wordpad/He.rc >> @@ -0,0 +1,282 @@ >> +/* >> + * Copyright 2004 by Krzysztof Foltman >> + * Hebrew Translation by Yaron Shahrabani<sh.yaron(a)gmail.com>, 2010 >> > > Minor, but why did you not use the same format (as we see in most files)? > So something like: > > /* > * Hebrew Translation of wordpad > * > * Copyright 2004 by Krzysztof Foltman > * Copyright 2010 Yaron Shahrabani<sh.yaron(a)gmail.com> > I'll keep that in mind from now on, thanks! > > +IDD_DATETIME DIALOG 30, 20, 130, 80 >> +STYLE DS_MODALFRAME | WS_CAPTION | WS_SYSMENU >> +EXSTYLE WS_EX_LAYOUTRTL >> > > Eventually we probably have to but I'm not sure what Alexandre thinks about > introducing it (now). We probably also have to teach our tools (like the > translation site) that detects translation differences/issues to cope with > this. > So I shouldn't add that for now? > > +STRINGTABLE >> +BEGIN >> + STRING_ALIGN_LEFT, "שמאל" >> + STRING_ALIGN_RIGHT, "ימין" >> + STRING_ALIGN_CENTER, "מרכז" >> +END >> > > This piece is already defined starting on line 226 and thus leads to: > > ../../../wine-git/programs/wordpad/He.rc:279:32: Error: Stringtable ID 1416 > already in use > Is there any way to deal with such errors (I can't compile wordpad since there's no Makefile)? How come the original file compiles while the translated one doesn't? What's the difference? they have the exact same resources. Kind regards, Yaron Shahrabani > > -- > Cheers, > > Paul. >

Aug. 2, 2010

Re: The WineAPI wiki.

by Max TenEyck Woodbury

On 08/02/2010 07:53 AM, Dmitry Timoshkov wrote: > Max TenEyck Woodbury<max(a)mtew.isa-geek.net> wrote: > >>> You have chosen not very good name. There is no such a thing as Wine API, >>> Wine implements Win32 API, and doesn't specify/add anything custom to it. >>> The name "WineAPI" implies that Wine defines its own API which is not true, >>> and is confusing. >>> >> This has been discussed elsewhere on this mailing list. >> >> There is a lot of information specific to Wine, particularly its >> internal structure, that is not shared with Microsoft's product. > > Then "Wine internals" or "Wine architecture" would be more appropriate. > But it is NOT just the internals. I believe that good API documentations should include a 'Theory of Operation' section which describes how it is actually implemented. There should also be a section that documents regression and other tests. In other words, I hope this will become a *really* good set of API documentation. So 'Wine internals' would have been a bad name for the project. Similarly 'Wine architecture' is inappropriate. This is not particularly a name I chose. The other discussions of this have also used 'WineAPI'. I did consider your objections that you have voiced previously. I understand that the target API is in fact the Win32API, but the Win32API is not something we control. We do control the actual API Wine uses. There will be differences between the WineAPI and the Win32API. When those differences are pointed out, I expect the WineAPI will be changed to match the Win32API. We are free to do that. We are *not* free to change the Win32API. I think 'WineAPI' is an appropriate name and better than either of the names you suggested. If anyone comes up with a better name, I will try to get the Sourceforge project name changed, but the project is currently called 'wineapi'. So, for the moment, it is what it is. >> Further, there is a little confusing and incorrect information in the >> Microsoft documentation. Bluntly, the Microsoft documentation is what >> they want it to be. We need to document what it really is. > > Regardless of the quality of Microsoft documentation it's still Win32 API, > not a Wine API. > And it is Microsoft's documentation and nominally documents their code. We have to document *our* code. There will be differences. Differences that I expect will be removed when found unless we can show that the Microsoft documentation is, in fact, incorrect. You are setting up a 'straw man' argument. You are assuming that we can and *have* implemented the Win32 API correctly and that Microsoft's published documentation is completely correct. We have not and Microsoft has not. Our documentation will help us fix our code. We can not and should not even try to get try to get Microsoft fix their problems. From that your argument fails. - Max

Aug. 2, 2010

Re: winex11.drv: implement drag and drop from X to OLE (try 3)

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > @@ -300,6 +499,66 @@ static void X11DRV_XDND_ResolveProperty(Display *display, Window xwin, Time tm, > wine_tsx11_unlock(); > } > > + /* We get the list of formats in descending order of preference, yet the linked > + * list is a stack so the order is inverted. Reverse the linked list here so > + * that we get the right order. > + */ > + current = XDNDData; You should first convert it to a standard Wine list, then you can use it in either order. > + /* For some strange reason, load-time linking SHELL32.DLL to WINEX11.DRV > + * causes wine to segfault on startup. So rather use run-time linking. > + */ > + shell32 = GetModuleHandleA("SHELL32.DLL"); > + if (shell32 == NULL) > + shell32 = LoadLibraryA("SHELL32.DLL"); A delayed import should work fine. -- Alexandre Julliard julliard(a)winehq.org

Aug. 2, 2010

Re: winex11.drv: implement X session management (try 2)

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > +static void SM_Init(void) > +{ > + CreateThread(NULL, 0, manage_session, NULL, 0, NULL); > +} > +#endif /* defined(SONAME_LIBSM) */ You don't want to create a new thread in every process for this. It will cause lots of trouble. -- Alexandre Julliard julliard(a)winehq.org

Aug. 2, 2010

Re: [PATCH 07/10] explorerframe/nstc: Implement Initialize.

by Alexandre Julliard

David Hedberg <david.hedberg(a)gmail.com> writes: > + /* Native accepts a NULL prc, so should we. */ > + if(prc) > + SetWindowPos(This->hwnd_main, HWND_TOP, prc->left, prc->top, > + prc->right - prc->left, prc->bottom - prc->top, SWP_SHOWWINDOW); It would be better to create it directly with the correct rectangle. Also SWP_SHOWWINDOW is not useful since the window is created visible. And please don't add comments like "native does this", that should be true of pretty much anything we do. Native behavior should be documented by test cases anyway, not comments. -- Alexandre Julliard julliard(a)winehq.org

Aug. 2, 2010

Re: shell32: Partial implementation of IShellItem::BindToHandler.

by Nikolay Sivov

On 8/2/2010 16:07, David Hedberg wrote: > On Mon, Aug 2, 2010 at 10:50 AM, Nikolay Sivov<nsivov(a)codeweavers.com> wrote: > >> Ok, this test is present already cause Desktop list is an empty list. So >> please change this test for >> mkid.cb magic value to _ILIsEmpty() in BindToObject() and all other >> occurrences too (InitializeTreeView() for example). >> > Is something like the attached patch acceptable? I have only changed > the checks where it would not introduce an extra check for NULL, and I > have also not touched debughlp.c. Should I be more radical and also > change places that only checks pidl->mkid.cb? It's fine I think, for only pidl->mkid.cb I'd say no for now, cause I'm no sure about it. All this check thing needs to be revised and simplified probably. > Also, the check in _ILIsDesktop() seems a bit counter-intuitive to me > (interpreting it as "pidl&& (pidl->mkid.cb ? FALSE : TRUE)" is closer > to what you would expect as the current version also considers NULL > pidl's to be the desktop (or empty)), but I assume that the current > meaning is the intended one. I'm not aware about assumptions in code that NULL pidl means desktop. For now your change doesn't change functionality, but only clarifies things. Again, occurrences of "NULL means desktop" should be found and tested if possible, but later (if you'll feel brave enough after your gsoc project end, for example).

Aug. 2, 2010

Re: [PATCH 1/5] include/mswsock: add WS_ prefix if necessary

by Alexandre Julliard

Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> writes: > @@ -173,11 +174,28 @@ typedef BOOL (WINAPI * LPFN_TRANSMITFILE)(SOCKET, HANDLE, DWORD, DWORD, LPOVERLA > typedef BOOL (WINAPI * LPFN_TRANSMITPACKETS)(SOCKET, LPTRANSMIT_PACKETS_ELEMENT, DWORD, DWORD, LPOVERLAPPED, DWORD); > typedef INT (WINAPI * LPFN_WSARECVMSG)(SOCKET, LPWSAMSG, LPDWORD, LPWSAOVERLAPPED, LPWSAOVERLAPPED_COMPLETION_ROUTINE); > typedef INT (WINAPI * LPFN_WSASENDMSG)(SOCKET, LPWSAMSG, DWORD, LPDWORD, LPWSAOVERLAPPED, LPWSAOVERLAPPED_COMPLETION_ROUTINE); > +#else > +typedef BOOL (WINAPI * LPFN_ACCEPTEX)(SOCKET, SOCKET, PVOID, DWORD, DWORD, DWORD, LPDWORD, LPOVERLAPPED); > +typedef BOOL (WINAPI * LPFN_CONNECTEX)(SOCKET, const struct WS_sockaddr *, int, PVOID, DWORD, LPDWORD, LPOVERLAPPED); > +typedef BOOL (WINAPI * LPFN_DISCONNECTEX)(SOCKET, LPOVERLAPPED, DWORD, DWORD); > +typedef VOID (WINAPI * LPFN_GETACCEPTEXSOCKADDRS)(PVOID, DWORD, DWORD, DWORD, struct WS_sockaddr **, LPINT, struct WS_sockaddr **, LPINT); > +typedef BOOL (WINAPI * LPFN_TRANSMITFILE)(SOCKET, HANDLE, DWORD, DWORD, LPOVERLAPPED, LPTRANSMIT_FILE_BUFFERS, DWORD); > +typedef BOOL (WINAPI * LPFN_TRANSMITPACKETS)(SOCKET, LPTRANSMIT_PACKETS_ELEMENT, DWORD, DWORD, LPOVERLAPPED, DWORD); > +typedef INT (WINAPI * LPFN_WSARECVMSG)(SOCKET, LPWSAMSG, LPDWORD, LPWSAOVERLAPPED, LPWSAOVERLAPPED_COMPLETION_ROUTINE); > +typedef INT (WINAPI * LPFN_WSASENDMSG)(SOCKET, LPWSAMSG, DWORD, LPDWORD, LPWSAOVERLAPPED, LPWSAOVERLAPPED_COMPLETION_ROUTINE); > +#endif What you want is the WS() macro. -- Alexandre Julliard julliard(a)winehq.org

Aug. 2, 2010

Re: shell32: Partial implementation of IShellItem::BindToHandler.

by David Hedberg

On Mon, Aug 2, 2010 at 10:50 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > > Ok, this test is present already cause Desktop list is an empty list. So > please change this test for > mkid.cb magic value to _ILIsEmpty() in BindToObject() and all other > occurrences too (InitializeTreeView() for example). > Is something like the attached patch acceptable? I have only changed the checks where it would not introduce an extra check for NULL, and I have also not touched debughlp.c. Should I be more radical and also change places that only checks pidl->mkid.cb? Also, the check in _ILIsDesktop() seems a bit counter-intuitive to me (interpreting it as "pidl && (pidl->mkid.cb ? FALSE : TRUE)" is closer to what you would expect as the current version also considers NULL pidl's to be the desktop (or empty)), but I assume that the current meaning is the intended one.

Aug. 2, 2010