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

Re: [tools/wine.desktop] Add czech translation

by Scott Ritchie

On 06/30/2010 03:46 PM, Nikolay Sivov wrote: > On 7/1/2010 02:20, Scott Ritchie wrote: >> Translation by Sven Augustin > >> @@ -20,7 +21,12 @@ Name[sr]=Wine - аДаИаЗаАб� Windows аПб�аОаГб�аАаМаА >> Name[sr(a)latin]=Wine - dizaФ� Windows programa >> Name[hr]=Wine - dizaФ� Windows programa >> Exec=wine start /unix %f >> +<<<<<<< HEAD >> >> MimeType=application/x-ms-dos-executable;application/x-msi;application/x-win-lnk;application/x-ms-shortcut >> >> +======= >> +MimeType=application/x-ms-dos-executable;application/x-msi;application/x-win-lnk; >> >> +>>>>>>> tools/wine.desktop: add Icon=wine to support systems with an >> icon theme >> Icon=wine >> NoDisplay=true >> StartupNotify=true >> + > Conflicts? Already noticed, resent

June 30, 2010

Re: [tools/wine.desktop] Add czech translation

by Nikolay Sivov

On 7/1/2010 02:20, Scott Ritchie wrote: > Translation by Sven Augustin > @@ -20,7 +21,12 @@ Name[sr]=Wine - аДаИаЗаАб� Windows аПб�аОаГб�аАаМаА > Name[sr(a)latin]=Wine - dizaФ� Windows programa > Name[hr]=Wine - dizaФ� Windows programa > Exec=wine start /unix %f > +<<<<<<< HEAD > MimeType=application/x-ms-dos-executable;application/x-msi;application/x-win-lnk;application/x-ms-shortcut > +======= > +MimeType=application/x-ms-dos-executable;application/x-msi;application/x-win-lnk; > +>>>>>>> tools/wine.desktop: add Icon=wine to support systems with an icon theme > Icon=wine > NoDisplay=true > StartupNotify=true > + Conflicts?

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by James Mckenzie

Erich Hoover <ehoover(a)mines.edu> wrote: >Sent: Jun 30, 2010 12:43 PM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Alexandre Julliard <julliard(a)winehq.org>, Max TenEyck Woodbury <max(a)mtew.isa-geek.net>, wine-devel(a)winehq.org >Subject: Re: (Resent) Documentation - Reference to MSDN? > >On Wed, Jun 30, 2010 at 1:36 PM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >> ... >> How about some place on the Wiki along with an implementation status. That way we can also annotate items that are missing in MSDN (I just re-stumbled across something in my latest Richedit tests) as well. This would help greatly in our progress towards current and future implementations of the Windows API. >> >> And I agree, adding all of this to the source would make it unwieldy. >> > >So something like "http://wiki.winehq.org/WineAPI/<DLL>/<Function>" ? >If that's acceptable I would not mind a system like that, especially >if the links of documented functions are provided in the source. >Documenting these things is a lot of work, so I'm not about to run off >and do all that work if no-one is ever going to take advantage of it. > +1 Acceptable variables should be listed in an order other than the one on MSDN. We don't want a direct copy, but rather OUR findings using the old 'black box' method. James McKenzie

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Erich Hoover

On Wed, Jun 30, 2010 at 1:36 PM, James Mckenzie <jjmckenzie51(a)earthlink.net> wrote: > ... > How about some place on the Wiki along with an implementation status. That way we can also annotate items that are missing in MSDN (I just re-stumbled across something in my latest Richedit tests) as well. This would help greatly in our progress towards current and future implementations of the Windows API. > > And I agree, adding all of this to the source would make it unwieldy. > So something like "http://wiki.winehq.org/WineAPI/<DLL>/<Function>" ? If that's acceptable I would not mind a system like that, especially if the links of documented functions are provided in the source. Documenting these things is a lot of work, so I'm not about to run off and do all that work if no-one is ever going to take advantage of it. Erich Hoover ehoover(a)mines.edu

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by James Mckenzie

Alexandre Julliard <julliard(a)winehq.org> wrote: > >Erich Hoover <ehoover(a)mines.edu> writes: > >> Alright, well then I won't do it. Is the existing documentation going >> to be stripped at some point? It seems to me like we would benefit >> from more-detailed function descriptions in the auto-generated API >> documentation. I think it would save a lot of time for new developers >> to get their feet wet if they were able to see directly in the source >> what the different functions are supposed to do (as best as we know) >> and exactly what applications will trigger known edge cases (or if >> there's a test for a given situation). > >That's what the source code and test cases are for. If you rely on the >function documentation you are in trouble anyway, nobody bothers to >update it when new behaviors are discovered. > >If you really want to write good API documentation, as opposed to the >current useless one-sentence-per-parameter description, you'd need >probably a text 10 times the size of the source code for each >function. That can't go in the source files. > How about some place on the Wiki along with an implementation status. That way we can also annotate items that are missing in MSDN (I just re-stumbled across something in my latest Richedit tests) as well. This would help greatly in our progress towards current and future implementations of the Windows API. And I agree, adding all of this to the source would make it unwieldy. James McKenzie

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Max TenEyck Woodbury

On 06/30/2010 03:13 PM, Alexandre Julliard wrote: > Erich Hoover<ehoover(a)mines.edu> writes: > >> Alright, well then I won't do it. Is the existing documentation going >> to be stripped at some point? It seems to me like we would benefit >> from more-detailed function descriptions in the auto-generated API >> documentation. I think it would save a lot of time for new developers >> to get their feet wet if they were able to see directly in the source >> what the different functions are supposed to do (as best as we know) >> and exactly what applications will trigger known edge cases (or if >> there's a test for a given situation). > > That's what the source code and test cases are for. If you rely on the > function documentation you are in trouble anyway, nobody bothers to > update it when new behaviors are discovered. > > If you really want to write good API documentation, as opposed to the > current useless one-sentence-per-parameter description, you'd need > probably a text 10 times the size of the source code for each > function. That can't go in the source files. > That documentation has to be stored somewhere. Where?

June 30, 2010

updating spec files - which windows version to use?

by Austin English

Howdy, I was looking at http://bugs.winehq.org/show_bug.cgi?id=23421, and wanted to add a stub for it. Using winedump on a Windows 7 shlwapi.dll gives different exports than Windows XP SP3 shlwapi.dll. Which dll should the spec file be updated to match? I'm assuming the latest and greatest, since eventually applications will head that direction. An additional related question. Some of the functions that are ordinals in previous Windows versions are now exported (e.g., ParseUrlA/W seems to have been documented/exported since Vista). Should the spec file be adjusted to match the newer behavior? I'm assuming this will have to wait until after 1.2 to be applied... Thanks! Austin

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Alexandre Julliard

Erich Hoover <ehoover(a)mines.edu> writes: > Alright, well then I won't do it. Is the existing documentation going > to be stripped at some point? It seems to me like we would benefit > from more-detailed function descriptions in the auto-generated API > documentation. I think it would save a lot of time for new developers > to get their feet wet if they were able to see directly in the source > what the different functions are supposed to do (as best as we know) > and exactly what applications will trigger known edge cases (or if > there's a test for a given situation). That's what the source code and test cases are for. If you rely on the function documentation you are in trouble anyway, nobody bothers to update it when new behaviors are discovered. If you really want to write good API documentation, as opposed to the current useless one-sentence-per-parameter description, you'd need probably a text 10 times the size of the source code for each function. That can't go in the source files. -- Alexandre Julliard julliard(a)winehq.org

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Erich Hoover

On Wed, Jun 30, 2010 at 12:44 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Erich Hoover <ehoover(a)mines.edu> writes: > >> Personally, I think that it would be really good to do a better job of >> documenting the API functions (particularly edge cases). I'm >> currently very busy with work, but if Alexandre is ok with >> documentation-only patches then this is something I'm tempted to jump >> on (in the areas where I have sufficient familiarity) when I have some >> more free time. > > I'm not OK with it. If you want to start a project to document the > Windows API, go ahead, but don't put that in the Wine source, that's not > where it belongs. Alright, well then I won't do it. Is the existing documentation going to be stripped at some point? It seems to me like we would benefit from more-detailed function descriptions in the auto-generated API documentation. I think it would save a lot of time for new developers to get their feet wet if they were able to see directly in the source what the different functions are supposed to do (as best as we know) and exactly what applications will trigger known edge cases (or if there's a test for a given situation). Erich Hoover ehoover(a)mines.edu

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Alexandre Julliard

Erich Hoover <ehoover(a)mines.edu> writes: > Personally, I think that it would be really good to do a better job of > documenting the API functions (particularly edge cases). I'm > currently very busy with work, but if Alexandre is ok with > documentation-only patches then this is something I'm tempted to jump > on (in the areas where I have sufficient familiarity) when I have some > more free time. I'm not OK with it. If you want to start a project to document the Windows API, go ahead, but don't put that in the Wine source, that's not where it belongs. -- Alexandre Julliard julliard(a)winehq.org

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Max TenEyck Woodbury

Juan Lang: <grin> Of course one of the reasons to add documentation is precisely because the information on MSDN is less than perfect. Having a good interface definition makes things easier. I'm still in the process of learning how to submit patches. These would be low risk but useful changes so they make good test material. Juan Lang, André Hentschel, Owen Rudge: So, from what Owen said, having a URL can be helpful, but should not be the total documentation. A date as part of the reference probably would be enough warning that things change. Alexandre: Would you mind getting documentation update patches during the code freeze?

June 30, 2010

Re: Please review: Patch for non-Linux serial set_baud_rate()

by Ken Thomases

On Jun 30, 2010, at 11:47 AM, Ken Thomases wrote: > I happened to stumble across some code which didn't look quite right in dlls/ntdll/serial.c. However, I have no expertise in serial comms or termios. Also, I have no means to test the change I propose. On the other hand, the change seems clearly right and conforms to what I learn from man pages, etc. On re-reading, I realize I didn't say what the nature of the problem and change are: set_baud_rate() needs to poke at a termios structure and enter the desired baud rate into its fields. However, the baud rate is represented differently on Linux than on other platforms. This is detected with an "#ifdef CBAUD" test. On Linux, the baud rate goes into the c_cflag field; elsewhere, it goes into dedicated c_ospeed and c_ispeed fields. At some point, somebody extended the non-Linux branch to support higher baud rates, to match capability that the Linux branch had. However, they seem to have just copied the Linux-appropriate code and pasted it into the non-Linux branch. So, the code is stuffing the baud rate into the c_cflag field and not the c_ospeed field. In the non-Linux branch, the high baud rate cases of the switch statement don't match the lower baud rate cases. My proposed change sets the baud rate via the c_ospeed field for all cases on the non-Linux branch. Cheers, Ken

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Erich Hoover

On Wed, Jun 30, 2010 at 11:44 AM, Juan Lang <juan.lang(a)gmail.com> wrote: > > ... > A more general response: I'm not sure that a lot of documentation > patches will be accepted. MSDN has to be considered the definitive > resource for the Windows API. It's often incorrect, of course, and > our regression tests aim to ameliorate the inaccuracy, but we probably > have enough work implementing the Windows API without taking on the > task of documenting it too. > --Juan I was looking into this a while ago and you can add documentation to the "Wine API" by properly formatting it in your patches, for example: http://source.winehq.org/WineAPI/CreateIcon.html is generated from the code here: http://source.winehq.org/source/dlls/user32/cursoricon.c#L1473 Personally, I think that it would be really good to do a better job of documenting the API functions (particularly edge cases). I'm currently very busy with work, but if Alexandre is ok with documentation-only patches then this is something I'm tempted to jump on (in the areas where I have sufficient familiarity) when I have some more free time. Erich Hoover ehoover(a)mines.edu

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Owen Rudge

> No. MSDN is in the habit of changing its URLs all too frequently. For what it's worth, while MSDN seems to like changing its URLs a lot, it does seem to be quite good at maintaining forwarders for the old URLs - most API documentation URLs I've randomly found from 5 years ago still work, for instance. But I agree that it's probably not worth including them in Wine's documentation. -- Owen Rudge http://www.owenrudge.net/

June 30, 2010

Re: add russian translation for winerrs messages [try2]

by Vitaly Lipatov

В сообщении от Среда 30 июня 2010 Вы написали: > Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: ... > Also it doesn't make much sense to send a half completed translation. You are welcome :) I have no time for translate stupid, obsoleted, unexisted errors. Later, as next step, I will do review again and update translation. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by André Hentschel

Am 30.06.2010 19:25, schrieb Max TenEyck Woodbury: > I've been reading the Wine code and noticed that some of the external > interfaces are practically undocumented. I did a web search on some of > the names and found descriptions in MSDN. > > I realize that copying the information from MSDN directly into the code > is a poor idea (like copyright violation) so I have a couple of > questions: > > 1) Would including the URL of the MSDN article be useful/a good idea? Might be a bad idea as such URL may be dead in 12 Month or so, but it is not forbidden. > 2) Would enumerating coded values and flags be allowed? That is the best solution i think. -- Best Regards, André Hentschel

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Juan Lang

Hi Max, > 1) Would including the URL of the MSDN article be useful/a good idea? No. MSDN is in the habit of changing its URLs all too frequently. A more general response: I'm not sure that a lot of documentation patches will be accepted. MSDN has to be considered the definitive resource for the Windows API. It's often incorrect, of course, and our regression tests aim to ameliorate the inaccuracy, but we probably have enough work implementing the Windows API without taking on the task of documenting it too. --Juan

June 30, 2010

(Resent) Documentation - Reference to MSDN?

by Max TenEyck Woodbury

I've been reading the Wine code and noticed that some of the external interfaces are practically undocumented. I did a web search on some of the names and found descriptions in MSDN. I realize that copying the information from MSDN directly into the code is a poor idea (like copyright violation) so I have a couple of questions: 1) Would including the URL of the MSDN article be useful/a good idea? 2) Would enumerating coded values and flags be allowed? 3) Where should data structures be documented?

June 30, 2010

Please review: Patch for non-Linux serial set_baud_rate()

by Ken Thomases

Hi, I happened to stumble across some code which didn't look quite right in dlls/ntdll/serial.c. However, I have no expertise in serial comms or termios. Also, I have no means to test the change I propose. On the other hand, the change seems clearly right and conforms to what I learn from man pages, etc. So, I'm hoping somebody who is more familiar with this functionality can review the attached patch before I formally submit it. Another approach that seems better from my reading of the man pages is to switch to using cfsetspeed() [or cfsetospeed() and cfsetispeed()] instead of having separate branches based on defined(CBAUD). But maybe that has portability problems worse than the current approach. Thanks, Ken

June 30, 2010

Creating tests with additional binary modules

by Mariusz Pluciński

Hi, wine-devel I'm working on implementation of Windows Game Explorer interfaces for Wine. The work is in advanced stage now, but I have problem with implementation of conformance tests. Thing I want to test is loading and parsing so-called Game Definition Files. GDF are not separate files, but stored as resources in binary modules (usually in game's main executable). Using GE interfaces, programmer only needs to pass path to binary, and GE automatically loads and process embedded GDF(s). Checking results of routines execution is not problem for me. But thing I test is parser, so I need to pass various GDF files to routine. And, as GDFs are stored in binaries, I will need to create many binaries. They should be created in compile time and available for test's executable while running it. The problem is that I don't know how to do this using wine's mechanisms. How should Makefile.in file look to build additional executable files properly (they should be probably always native win32 executables, even if parameter "crosstest" wasn't specified)? How should I guarantee that these additional executables will be copied into winetest directory (to make them accessible while executing tests)? Thanks in advance Mariusz Pluciński

June 30, 2010

Re: user32: Recurse into WS_EX_CONTROLPARENT controls in GetDlgItem

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > This fixes bug 22862 which blocks bug 12804 (1.2) > We already do a similar recursion in DEFDLG_FindDefButton and GetNextDlgGroupItem > > I didnt found any other changes in the tests... i expected some more "Test succeeded inside todo block" You need to add explicit tests for GetDlgItem() inside of user32/tests. -- Dmitry.

June 30, 2010

Documentation - Reference to MSDN?

by Max TenEyck Woodbury

I've been reading the Wine code and noticed that some of the external interfaces are practically undocumented. I did a web search on some of the names and found descriptions in MSDN. I realize that copying the information from MSDN directly into the code is a poor idea (like copyright violation) so I have a couple of questions: 1) Would including the URL of the MSDN article be useful/a good idea? 2) Would enumerating coded values and flags be allowed? 3) Where should data structures be documented?

June 30, 2010

Re: add russian translation for winerrs messages [try2]

by Paul Vriens

On 06/30/2010 03:43 PM, Dmitry Timoshkov wrote: > Dmitry Timoshkov<dmitry(a)codeweavers.com> wrote: > >> Vitaly Lipatov<lav(a)etersoft.ru> wrote: >> >>> +LanguageNames=(RUS=0x19:winerr) >>> +CodePages=(FRA=65001:0) >> >> 'FRA'? This doesn't look correct. > > Also it doesn't make much sense to send a half completed translation. > I could agree but if you look at the Dutch kernel32 resource it's even worse I'm afraid. This at least gives us a starting point. (Try3 was sent with at least the 'FRA' fixed). -- Cheers, Paul.

June 30, 2010

Re: add russian translation for winerrs messages [try2]

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Vitaly Lipatov <lav(a)etersoft.ru> wrote: > > > +LanguageNames=(RUS=0x19:winerr) > > +CodePages=(FRA=65001:0) > > 'FRA'? This doesn't look correct. Also it doesn't make much sense to send a half completed translation. -- Dmitry.

June 30, 2010

Re: add russian translation for winerrs messages [try2]

by Dmitry Timoshkov

Vitaly Lipatov <lav(a)etersoft.ru> wrote: > +LanguageNames=(RUS=0x19:winerr) > +CodePages=(FRA=65001:0) 'FRA'? This doesn't look correct. -- Dmitry.

June 30, 2010

Re: user32/tests: Use if(0) instead of a comment to make sure code still compiles

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=3023 Your paranoid android. === W7PRO (32 bit msg) === msg.c:9516: Test failed: wrong qstatus 00110011 msg.c:9523: Test failed: wrong qstatus 00190008 msg.c:9529: Test failed: wrong qstatus 00390020 msg.c:9538: Test failed: wrong qstatus 00790040 msg.c:9559: Test failed: wrong qstatus 00390000 msg.c:9567: Test failed: wrong qstatus 00790040 msg.c:9578: Test failed: wrong qstatus 00390000 msg.c:9589: Test failed: wrong qstatus 00310000 msg.c:9594: Test failed: PeekMessageA should have returned FALSE instead of msg 0113 === W7PROX64 (64 bit msg) === Timeout

June 29, 2010

Re: wininet: fix the handling of insufficient buffers in InternetGetCookie*()

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=3020 Your paranoid android. === W98SE (32 bit internet) === internet.c:440: Test failed: A=B present internet.c:442: Test failed: E=F present internet.c:444: Test failed: I=J present internet.c:445: Test failed: K=L present internet.c:452: Test failed: A=B present internet.c:454: Test failed: E=F present internet.c:456: Test failed: I=J present internet.c:457: Test failed: K=L present internet.c:1158: Test failed: Retrieved proxy server should've been L"proxy.example", was: L"\0001\a000\2684X\0fb4h\0200" internet.c:1164: Test failed: Expected regtype to be REG_DWORD, was: 3 internet.c:1192: Test failed: Retrieved flags should've been PROXY_TYPE_DIRECT, was: 5767180 internet.c:1195: Test failed: Expected regtype to be REG_DWORD, was: 3 internet.c:1222: Test failed: Retrieved flags should've been PROXY_TYPE_PROXY | PROXY_TYPE_DIRECT, was: 5767180 internet.c:1225: Test failed: Expected regtype to be REG_DWORD, was: 3 === W2KPROSP4 (32 bit internet) === internet.c:440: Test failed: A=B present internet.c:442: Test failed: E=F present internet.c:444: Test failed: I=J present internet.c:445: Test failed: K=L present internet.c:452: Test failed: A=B present internet.c:454: Test failed: E=F present internet.c:456: Test failed: I=J present internet.c:457: Test failed: K=L present === WXPPROSP3 (32 bit internet) === internet.c:517: Test failed: bad last error {error = 122} internet.c:545: Test failed: the function failed internet.c:546: Test failed: bad last error {error = 122} === WVISTAADM (32 bit internet) === internet.c:517: Test failed: bad last error {error = 122} internet.c:545: Test failed: the function failed internet.c:546: Test failed: bad last error {error = 122} === W2K8SE (32 bit internet) === internet.c:517: Test failed: bad last error {error = 122} internet.c:545: Test failed: the function failed internet.c:546: Test failed: bad last error {error = 122} === W7PRO (32 bit internet) === internet.c:474: Test failed: bad last error {error = 5023} internet.c:502: Test failed: bad last error {error = 5023} internet.c:517: Test failed: bad last error {error = 5023} internet.c:545: Test failed: the function failed internet.c:546: Test failed: bad last error {error = 122} === W7PROX64 (32 bit internet) === internet.c:474: Test failed: bad last error {error = 5023} internet.c:502: Test failed: bad last error {error = 5023} internet.c:517: Test failed: bad last error {error = 5023} internet.c:545: Test failed: the function failed internet.c:546: Test failed: bad last error {error = 122} === W7PROX64 (64 bit internet) === internet.c:474: Test failed: bad last error {error = 5023} internet.c:502: Test failed: bad last error {error = 5023} internet.c:517: Test failed: bad last error {error = 5023} internet.c:545: Test failed: the function failed internet.c:546: Test failed: bad last error {error = 122}

June 29, 2010

Re: Using string resources in conformance tests.

by Michael Mc Donnell

Thanks for taking the time to write a comment Juan. On Tue, Jun 29, 2010 at 5:55 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > Hi Michael, > >> I use the LoadString function to get the "New folder" string from >> shell32.dll that is used for creating a new folder. The problem is >> that the location where it is stored in shell32.dll varies between the >> different versions of Windows. I can only make the test work on one >> version at a time. Even the capitalization varies between the >> different versions of Windows, i.e. "New Folder" vs. "New folder". > > It appears as though you shouldn't be doing this in a conformance > test. It varies enough that applications can't depend on the resource > ID or string value being the same in different versions of Windows. > Our conformance tests try to test for invariants across Windows > versions, i.e. behavior that applications may depend on or expect. Yeah that sounds reasonable. I guess it means there will be very few Windows applications that depend on the folder getting the correct "New folder" name and we can therefore ignore this issue. > You might check the contents of the containing folder before and after > the command is executed, and make sure that at least one new folder > exists after the command is executed. Super, my test already does this. I'll cut out the resource handling part and clean the patch up so it will be ready for when the code freeze is lifted. Michael Mc Donnell

June 29, 2010

Re: [2/2] urlmon: implement HlinkSimpleNavigateToMoniker

by Jacek Caban

On 6/28/10 9:17 PM, André Hentschel wrote: > --- > dlls/urlmon/umon.c | 8 ++++++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/dlls/urlmon/umon.c b/dlls/urlmon/umon.c > index e122e07..12b1b0c 100644 > --- a/dlls/urlmon/umon.c > +++ b/dlls/urlmon/umon.c > @@ -734,8 +734,12 @@ HRESULT WINAPI HlinkSimpleNavigateToMoniker(IMoniker *pmkTarget, > LPCWSTR szLocation, LPCWSTR szTargetFrameName, IUnknown *pUnk, > IBindCtx *pbc, IBindStatusCallback *pbsc, DWORD grfHLNF, DWORD dwReserved) > { > - FIXME("stub\n"); > - return E_NOTIMPL; > + URLMoniker *This = MONIKER_THIS(iface); You can't do this. There is no guaranty that the moniker is URL moniker. Jacek

June 29, 2010

Re: Using string resources in conformance tests.

by Juan Lang

Hi Michael, > I use the LoadString function to get the "New folder" string from > shell32.dll that is used for creating a new folder. The problem is > that the location where it is stored in shell32.dll varies between the > different versions of Windows. I can only make the test work on one > version at a time. Even the capitalization varies between the > different versions of Windows, i.e. "New Folder" vs. "New folder". It appears as though you shouldn't be doing this in a conformance test. It varies enough that applications can't depend on the resource ID or string value being the same in different versions of Windows. Our conformance tests try to test for invariants across Windows versions, i.e. behavior that applications may depend on or expect. You might check the contents of the containing folder before and after the command is executed, and make sure that at least one new folder exists after the command is executed. --Juan

June 29, 2010

Re: The WINE Project should solicit grants to hire professional developers

by Damjan Jovanovic

On Mon, Jun 28, 2010 at 9:07 PM, Richard Yao <shiningarcanine(a)gmail.com> wrote: > Dear All: > > I am a senior undergraduate applied mathematics/computer science > student and this year, I migrated from Windows 7 to Gentoo Linux on my > computers. I tried using Linux alternatives to many applications I > used on Windows, but not all software has good alternatives, so I have > been using WINE for certain things. The WINE project's accomplishments > so far have been extremely impressive, but at the same time, WINE's > implementation of the Windows API is deficient in many ways and I > think that the WINE project will need to improve its own organization > before progress toward true API parity with Windows can be made. > > I can divide WINE's development resources into two groups, volunteer > and professional. The volunteer group is predominantly focused on > games.The professional group is comprised of CodeWeavers and Google. > CodeWeavers does what its customers want it to do, and as such, it has > a large focus on games. Google on the other hand, paid CodeWeavers to > make some improvements to WINE, mostly for Picasa, but also for Adobe > Photoshop CS2, the reason for which I cannot imagine. Google also has > its annual Summer of Code program. Each source of manpower has its own > special interest and I do not believe that WINE will ever obtain any > kind of API parity with Windows as long as this remains the case. > > With these things in mind, I would like to propose that the WINE > project solicit grants from charitable organizations so that it could > hire professional developers to augment its existing resources, > specifically in the areas for which special interests could care less. > If the Wine project could solicit sufficient funding to hire a few > dozen developers for a period of several years, then I think that > having WINE become as good as Windows would enter the realm of > possibility. I know that many people will laugh at my suggestion > (especially when they read the organization I suggest that the WINE > project contact), but as far as I can tell, the WINE project has not > solicited grants to be able to hire professional developers and I > think that failing to solicit such grants places a handicap on the > WINE project. > > There exist charitable organizations that seek to fund solutions to > "global problems that are ignored by governments and other > organizations" (as stated in Wikipedia). Because enabling Windows > programs to run on free UNIX operating systems would reduce the cost > of computing for all people, including those in third world countries, > I am certain that such organizations that would be willing to fund > WINE, provided that the WINE project inform them of its existence. The > specific organization from which I think that the WINE project should > attempt to solicit grant money is the Bill and Melinda Gates > Foundation. In consideration of their guiding principles and the fact > that they must spend $1.5 billion a year, it seems only logical to me > that they would provide funding for the WINE project if asked: > > http://www.gatesfoundation.org/about/Pages/guiding-principles.aspx > http://en.wikipedia.org/wiki/Bill_%26_Melinda_Gates_Foundation#Activities > > The Bill and Melinda Gates Foundation is not the only organization for > which the WINE project could solicit funding, but I think that it is a > good place to start. Please consider the possibility of soliciting > grants so that the WINE project could hire professional developers. > Also, I am not registered on the mailing list, so please CC me any > responses made either directly or indirectly to this email, even if it > ridicules my suggestion. > > Yours truly, > Richard Yao > > > What about persuading the European Union to spend some of the €497 million it got from the Microsoft competition lawsuit on improving Wine? Damjan Jovanovic

June 29, 2010

Re: The WINE Project should solicit grants to hire professional developers

by James McKenzie

Richard Yao wrote: > Dear All: > > I am a senior undergraduate applied mathematics/computer science > student and this year, I migrated from Windows 7 to Gentoo Linux on my > computers. I tried using Linux alternatives to many applications I > used on Windows, but not all software has good alternatives, so I have > been using WINE for certain things. The WINE project's accomplishments > so far have been extremely impressive, but at the same time, WINE's > implementation of the Windows API is deficient in many ways and I > think that the WINE project will need to improve its own organization > before progress toward true API parity with Windows can be made. > Thank you for the kind comments. What you suggest is a taxation nightmare. Having worked with 501(c)(3) organizations, you HAVE to prove that your grants were used in an appropriate manner. Using them to pay the wages of a for-hire person is NOT appropriate (and will result in the IRS coming down on you like a ton of bricks). If you are looking for a job/internship, contact CodeWeavers. Donations to the Wine Project are used to support developers at WineConf (Wine Conference). We cannot LEGALLY pay wages to others without encountering the wrath of United States taxation laws. Sorry to be so harsh, but that's the reality of the FOSS world. Either you volunteer your time, or you look for a company that will pay wages for your 'support' efforts. James McKenzie

June 29, 2010

Re: ntdll: add stub for NtSystemDebugControl (try 2)

by Andrew Nguyen

2010/6/28 Austin English <austinenglish(a)gmail.com>: > with correct spec file this time > > -- > -Austin > > > > The spec argument that corresponds to the PULONG prototype argument should also be ptr.

June 29, 2010

Re: ntdll: add stub for NtSystemDebugControl

by Andrew Nguyen

On Mon, Jun 28, 2010 at 8:16 PM, Austin English <austinenglish(a)gmail.com> wrote: > See http://bugs.winehq.org/show_bug.cgi?id=23431 > > -- > -Austin > > > > The NtSystemDebugControl spec types don't match the prototype arguments.

June 29, 2010

Re: configure.ac: Don't try to rm dirs.

by Nicolas Le Cam

2010/6/28 Alexandre Julliard <julliard(a)winehq.org>: > Nicolas Le Cam <niko.lecam(a)gmail.com> writes: > >> Hi, >> >> This patch allows to do a make clean in a wine tree configured with >> with-wine64 option and fix following errors : >> rm: cannot remove `fonts': Is a directory >> rm: cannot remove `server': Is a directory > > These should be symlinks in a wow64 tree. Probably you didn't start from > a fresh tree. > > -- > Alexandre Julliard > julliard(a)winehq.org > You're right even if I can't remember creating it so long ago. Sorry for the noise. -- Nicolas Le Cam

June 28, 2010

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

by Florian Köberle

On 06/28/2010 01:44 PM, Reece Dunn wrote: > On 28 June 2010 12:26, Alexandre Julliard <julliard(a)winehq.org> wrote: > >> Wolfram Sang <wolfram(a)the-dreams.de> writes: >> >> >>> According to TestBot (#2851), all non-crashing Windows versions return 0. >>> >>> Found while working on Bug 21012. Although this patch doesn't cure this >>> bug, I think it is still worth adding the check because the pointer >>> may come from the (always evil ;)) user-application. >>> >> Do you have an actual application that does this, or is this just hiding >> a Wine bug? >> > When running winedbg on bfginstaller.exe (trying to track down > http://bugs.winehq.org/show_bug.cgi?id=14343) winedbg will trap in > the cursoricon.c code (line 771 -- > http://source.winehq.org/git/wine.git/?a=blob;f=dlls/user32/cursoricon.c;h=…) > > 767 /* pre-multiply by alpha */ > 768 for (i = 0, ptr = bits; i < bm.bmWidth * bm.bmHeight; i++, ptr += 4) > 769 { > 770 unsigned int alpha = ptr[3]; > 771 ptr[0] = ptr[0] * alpha / 255; > 772 ptr[1] = ptr[1] * alpha / 255; > 773 ptr[2] = ptr[2] * alpha / 255; > 774 } > > The app itself does not crash there when not running without winedbg, > but is generating an issue later on that does not make sense (which I > am suspecting is a stack corruption issue, possibly triggered by this > issue). > > I'm not sure if this is a wine bug, whether Wolfram's patch gets past > the break triggered or whether it addresses the Big Fish Games issue. > > I'll test the patch tonight. > > - Reece > > > > > When debugging another application I got a page fault at the same position. You can either type "pass" or you can set |BreakOnFirstChance to false to prevent the debugger from running into that "first chance" page faults. That's expecially usefull when your application triggers the page fault very frequently. See http://www.winehq.org/docs/winedev-guide/dbg-config for more information. The application I were debugging has a stack corruption bug too but I don't think it's related. |

June 28, 2010

Re: ddraw: Move complex surface destruction into its own function

by Henri Verbeet

On 28 June 2010 21:51, Luke Benstead <kazade(a)gmail.com> wrote: > Ok I wasn't sure as it's pretty trivial. I'll resend along with the others > after 1.2. > It's trivial, but also mostly pointless on its own.

June 28, 2010

Re: ddraw: Move complex surface destruction into its own function

by Luke Benstead

Ok I wasn't sure as it's pretty trivial. I'll resend along with the others after 1.2. On Jun 28, 2010 8:36 PM, "Henri Verbeet" <hverbeet(a)gmail.com> wrote: On 28 June 2010 20:03, Luke Benstead <kazade(a)gmail.com> wrote: > Needed to properly fix ddraw surfac... That's of course not appropriate during code freeze.

June 28, 2010

Re: ddraw: Move complex surface destruction into its own function

by Henri Verbeet

On 28 June 2010 20:03, Luke Benstead <kazade(a)gmail.com> wrote: > Needed to properly fix ddraw surface refcounting as it must be called from > the surface thunks. > That's of course not appropriate during code freeze.

June 28, 2010

The WINE Project should solicit grants to hire professional developers

by Richard Yao

Dear All: I am a senior undergraduate applied mathematics/computer science student and this year, I migrated from Windows 7 to Gentoo Linux on my computers. I tried using Linux alternatives to many applications I used on Windows, but not all software has good alternatives, so I have been using WINE for certain things. The WINE project's accomplishments so far have been extremely impressive, but at the same time, WINE's implementation of the Windows API is deficient in many ways and I think that the WINE project will need to improve its own organization before progress toward true API parity with Windows can be made. I can divide WINE's development resources into two groups, volunteer and professional. The volunteer group is predominantly focused on games.The professional group is comprised of CodeWeavers and Google. CodeWeavers does what its customers want it to do, and as such, it has a large focus on games. Google on the other hand, paid CodeWeavers to make some improvements to WINE, mostly for Picasa, but also for Adobe Photoshop CS2, the reason for which I cannot imagine. Google also has its annual Summer of Code program. Each source of manpower has its own special interest and I do not believe that WINE will ever obtain any kind of API parity with Windows as long as this remains the case. With these things in mind, I would like to propose that the WINE project solicit grants from charitable organizations so that it could hire professional developers to augment its existing resources, specifically in the areas for which special interests could care less. If the Wine project could solicit sufficient funding to hire a few dozen developers for a period of several years, then I think that having WINE become as good as Windows would enter the realm of possibility. I know that many people will laugh at my suggestion (especially when they read the organization I suggest that the WINE project contact), but as far as I can tell, the WINE project has not solicited grants to be able to hire professional developers and I think that failing to solicit such grants places a handicap on the WINE project. There exist charitable organizations that seek to fund solutions to "global problems that are ignored by governments and other organizations" (as stated in Wikipedia). Because enabling Windows programs to run on free UNIX operating systems would reduce the cost of computing for all people, including those in third world countries, I am certain that such organizations that would be willing to fund WINE, provided that the WINE project inform them of its existence. The specific organization from which I think that the WINE project should attempt to solicit grant money is the Bill and Melinda Gates Foundation. In consideration of their guiding principles and the fact that they must spend $1.5 billion a year, it seems only logical to me that they would provide funding for the WINE project if asked: http://www.gatesfoundation.org/about/Pages/guiding-principles.aspx http://en.wikipedia.org/wiki/Bill_%26_Melinda_Gates_Foundation#Activities The Bill and Melinda Gates Foundation is not the only organization for which the WINE project could solicit funding, but I think that it is a good place to start. Please consider the possibility of soliciting grants so that the WINE project could hire professional developers. Also, I am not registered on the mailing list, so please CC me any responses made either directly or indirectly to this email, even if it ridicules my suggestion. Yours truly, Richard Yao

June 28, 2010

Re: kernel32: Add NERR_UserNotFound to Norweigan winerr

by Austin English

On Mon, Jun 28, 2010 at 1:24 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > On 06/28/2010 08:15 PM, Austin English wrote: >> >> See http://bugs.winehq.org/show_bug.cgi?id=11168 >> > > Hi Austin, > > Applying the patch gives: > > [paul(a)acer wine-git]$ patch -p 1 -i /home/paul/kernel32_nor.txt > (Stripping trailing CRs from patch.) > patching file dlls/kernel32/nls/winerr_nor.mc > > Compiling gives: > > ../../../wine-git/dlls/kernel32/nls/winerr_nor.mc:3737:2: Error: Unexpected > EOF > make: *** [nls/winerr_nor.mc.rc] Error 1 > > You need to add a '.' at the end of the mc file (see the others). Crap, thanks. Was on a slow machine, didn't test compiling it. I'll resend. -- -Austin

June 28, 2010

Re: kernel32: Add NERR_UserNotFound to Norweigan winerr

by Paul Vriens

On 06/28/2010 08:15 PM, Austin English wrote: > See http://bugs.winehq.org/show_bug.cgi?id=11168 > Hi Austin, Applying the patch gives: [paul(a)acer wine-git]$ patch -p 1 -i /home/paul/kernel32_nor.txt (Stripping trailing CRs from patch.) patching file dlls/kernel32/nls/winerr_nor.mc Compiling gives: ../../../wine-git/dlls/kernel32/nls/winerr_nor.mc:3737:2: Error: Unexpected EOF make: *** [nls/winerr_nor.mc.rc] Error 1 You need to add a '.' at the end of the mc file (see the others). -- Cheers, Paul.

June 28, 2010

Re: Wine on cygwin now compiles!

by Steven Edwards

On Sun, Jun 27, 2010 at 4:59 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote: > Is there any real, practical interest in Wine on Windows? For doing a full port, other than the argument of climbing the mountain because it's there, I doubt it. > I've been making some progress in this direction recently (though I think my > approach would be to have a ported, NT-version of wineserver.exe which just > uses native functions of the OS instead of emulating them over cygwin, which > emulates those features using its own code once again; discussable anyway). I think as we have discussed before, taking arwinss, or at least the core parts of it and attempting to make an independent subsystem that runs under Windows has value. I believe there is a worthwhile product based upon your work with arwinss using Wine user32/gdi32/x11drv with the rest of the Windows stack to support remotely displaying Win32 applications over X11 to OS X, Solaris and Linux clients. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

June 28, 2010

Re: Possible patch for #12706

by Maarten Lankhorst

Hi Jeff, 2010/6/25 Jeff Cook <jeff(a)deserettechnology.com>: > 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. If you really want to force it, do lsmod |grep snd and do modprobe -r over all driver modules, snd-usb-audio and usually snd-hda-intel or something like that. Then modprobe snd-usb-audio and it will be the only audio device, so its always the default. ;) ~Maarten

June 28, 2010

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

by Wolfram Sang

On 28/06/10 13:26, Alexandre Julliard wrote: > Wolfram Sang <wolfram(a)the-dreams.de> writes: > >> According to TestBot (#2851), all non-crashing Windows versions return 0. >> >> Found while working on Bug 21012. Although this patch doesn't cure this >> bug, I think it is still worth adding the check because the pointer >> may come from the (always evil ;)) user-application. > > Do you have an actual application that does this, or is this just hiding > a Wine bug? Nope, no application (yet). As said, I found this flaw while checking #21012. The accompanying tests, which sadly crash some windows versions, backup the changes AFAICS. I can repost after 1.2 if you prefer that. Regards, Wolfram

June 28, 2010

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

by Alexandre Julliard

Reece Dunn <msclrhd(a)googlemail.com> writes: > When running winedbg on bfginstaller.exe (trying to track down > http://bugs.winehq.org/show_bug.cgi?id=14343) winedbg will trap in > the cursoricon.c code (line 771 -- > http://source.winehq.org/git/wine.git/?a=blob;f=dlls/user32/cursoricon.c;h=…) > > 767 /* pre-multiply by alpha */ > 768 for (i = 0, ptr = bits; i < bm.bmWidth * bm.bmHeight; i++, ptr += 4) > 769 { > 770 unsigned int alpha = ptr[3]; > 771 ptr[0] = ptr[0] * alpha / 255; > 772 ptr[1] = ptr[1] * alpha / 255; > 773 ptr[2] = ptr[2] * alpha / 255; > 774 } > > The app itself does not crash there when not running without winedbg, > but is generating an issue later on that does not make sense (which I > am suspecting is a stack corruption issue, possibly triggered by this > issue). That's a DIB exception. Perfectly normal, and nothing whatsoever to do with the patch. -- Alexandre Julliard julliard(a)winehq.org

June 28, 2010

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

by Reece Dunn

On 28 June 2010 12:26, Alexandre Julliard <julliard(a)winehq.org> wrote: > Wolfram Sang <wolfram(a)the-dreams.de> writes: > >> According to TestBot (#2851), all non-crashing Windows versions return 0. >> >> Found while working on Bug 21012. Although this patch doesn't cure this >> bug, I think it is still worth adding the check because the pointer >> may come from the (always evil ;)) user-application. > > Do you have an actual application that does this, or is this just hiding > a Wine bug? When running winedbg on bfginstaller.exe (trying to track down http://bugs.winehq.org/show_bug.cgi?id=14343) winedbg will trap in the cursoricon.c code (line 771 -- http://source.winehq.org/git/wine.git/?a=blob;f=dlls/user32/cursoricon.c;h=…) 767 /* pre-multiply by alpha */ 768 for (i = 0, ptr = bits; i < bm.bmWidth * bm.bmHeight; i++, ptr += 4) 769 { 770 unsigned int alpha = ptr[3]; 771 ptr[0] = ptr[0] * alpha / 255; 772 ptr[1] = ptr[1] * alpha / 255; 773 ptr[2] = ptr[2] * alpha / 255; 774 } The app itself does not crash there when not running without winedbg, but is generating an issue later on that does not make sense (which I am suspecting is a stack corruption issue, possibly triggered by this issue). I'm not sure if this is a wine bug, whether Wolfram's patch gets past the break triggered or whether it addresses the Big Fish Games issue. I'll test the patch tonight. - Reece

June 28, 2010

Re: user32: Make sure the desktop window is created before caps enumeration.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > This patch fixes the problem reported in the bug 21709. That's just hiding the bug. -- Alexandre Julliard julliard(a)winehq.org

June 28, 2010

Re: [PATCH 2/3] shell32: Use more accurate PathIsURL instead of searching for a colon

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > diff --git a/dlls/shell32/shfldr_desktop.c b/dlls/shell32/shfldr_desktop.c > index 30aea3b..54d13dc 100644 > --- a/dlls/shell32/shfldr_desktop.c > +++ b/dlls/shell32/shfldr_desktop.c > @@ -193,7 +193,7 @@ static HRESULT WINAPI ISF_Desktop_fnParseDisplayName (IShellFolder2 * iface, > *ppidl = pidlTemp; > return S_OK; > } > - else if (strchrW(lpszDisplayName,':')) > + else if (PathIsURLW(lpszDisplayName)) > { A better way would be to check the result of the ParseURLW call. -- Alexandre Julliard julliard(a)winehq.org

June 28, 2010

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

by Alexandre Julliard

Wolfram Sang <wolfram(a)the-dreams.de> writes: > According to TestBot (#2851), all non-crashing Windows versions return 0. > > Found while working on Bug 21012. Although this patch doesn't cure this > bug, I think it is still worth adding the check because the pointer > may come from the (always evil ;)) user-application. Do you have an actual application that does this, or is this just hiding a Wine bug? -- Alexandre Julliard julliard(a)winehq.org

June 28, 2010

Re: configure.ac: Don't try to rm dirs.

by Alexandre Julliard

Nicolas Le Cam <niko.lecam(a)gmail.com> writes: > Hi, > > This patch allows to do a make clean in a wine tree configured with > with-wine64 option and fix following errors : > rm: cannot remove `fonts': Is a directory > rm: cannot remove `server': Is a directory These should be symlinks in a wow64 tree. Probably you didn't start from a fresh tree. -- Alexandre Julliard julliard(a)winehq.org

June 28, 2010

Re: [hhctrl.ocx] Null pointer fix, new patch

by James McKenzie

Jaroslav Šmíd wrote: > On Wed, Jun 23, 2010 at 6:50 AM, Dmitry Timoshkov > <dmitry(a)codeweavers.com> wrote: > >> Jaroslav Šmíd <jardasmid(a)gmail.com> wrote: >> >> >>> diff -urN Wine-git.orig/dlls/hhctrl.ocx/chm.c Wine-git/dlls/hhctrl.ocx/chm.c >>> --- Wine-git.orig/dlls/hhctrl.ocx/chm.c 2010-06-22 12:41:54.034540000 +0200 >>> +++ Wine-git/dlls/hhctrl.ocx/chm.c 2010-06-22 12:51:07.454541388 +0200 >>> @@ -238,11 +238,11 @@ >>> info->WinType.pszIndex = strdupW(null); >>> info->WinType.fsValidMembers=0; >>> info->WinType.fsWinProperties=HHWIN_PROP_TRI_PANE; >>> - info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle); >>> + info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle ? >>> info->pCHMInfo->defTitle : null); >>> info->WinType.dwStyles=WS_POPUP; >>> info->WinType.dwExStyles=0; >>> info->WinType.nShowState=SW_SHOW; >>> - info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic); >>> + info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic ? >>> info->pCHMInfo->defTopic : null); >>> info->WinType.curNavType=HHWIN_NAVTYPE_TOC; >>> return TRUE; >>> } >>> >> The patch is wrapped. >> >> -- >> Dmitry. >> >> > > What does it mean it is wrapped? Accepted or not? If not, why? > > Your mailer wrapped lines. This will NOT APPLY. You need to attach the patches to your messages. James McKenzie

June 28, 2010

Re: Fwd: Possible patch for #12706

by James McKenzie

Jeff Cook wrote: > 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 > Please hold this patch until after Wine 1.2 is released. Others may comment on the content to help you improve your code. Also, if you are proposing new functionality, you have to include conformance tests that prove what you are trying to do is what native Windows does. James McKenzie

June 27, 2010

Re: Release plans

by wylda＠volny.cz

Hi, another week and Sunday gone. Lastly Scott had a nice idea about release & "drop in non-deferred patches". I like it too, but no more stat in this area ;) 340 regressions <-- release announcement 356 regressions <-- release announcement + 1week 339 regressions <-- release announcement + 2weeks(rc1) 322 regressions <-- release announcement + 3weeks(rc2) 325 regressions <-- release announcement + 4weeks 326 regressions <-- release announcement + 5weeks(rc3) 325 regressions <-- release announcement + 6weeks(rc4) 308 regressions <-- release announcement + 7weeks(rc5) This nice drop consist of: +04 Newly marked, opened (new/unconfirmed) -13 Closed, resolved fixed -08 Not a regression (invalid, duplicate) ==== -17 But it looks like, we can't have nice number in both regressions and milestones. 59 bugs <-- release announcement + 5weeks(rc3) 46 bugs <-- release announcement + 6weeks(rc4) 43 bugs <-- release announcement + 7weeks(rc5) Closer look reveals only one was fixed this week: +00 Newly marked, opened (new/unconfirmed) -01 Closed, resolved fixed -02 Not a Milestone-1.2, back off Milestone-1.2 ==== -03 W.

June 27, 2010

Re: How do you make x64 crosstests?

by André Hentschel

Am 26.06.2010 04:47, schrieb Austin English: > On Fri, Jun 25, 2010 at 2:49 AM, Ilya Basin <basinilya(a)gmail.com> wrote: > > Should be install 64-bit mingw, compile wine in 64-bit mode, and run > 'make crosstest'. Though I just tried this on Ubuntu Lucid, and it > fails for me there (configure is looking for > checking for x86_64-pc-mingw32-gcc... no > checking for x86_64-w64-mingw32-gcc... no > > while on Ubuntu, it is: > amd64-mingw32msvc-gcc > > however, it seems compiling with it is broken: > austin(a)midna:~/64-wine-git$ amd64-mingw32msvc-gcc foo.c > /usr/lib/gcc/amd64-mingw32msvc/4.4.2/../../../../amd64-mingw32msvc/bin/ld: > cannot find -lgcc > collect2: ld returned 1 exit status > > perhaps someone else has tried and had better luck... > I had to copy a mingw64 libgcc over to my system. it seems it is a packager bug... -- Best Regards, André Hentschel

June 27, 2010

Re: Reg ukrainian translation update

by Michael Stefaniuc

Hello Igor, On 06/27/2010 12:35 PM, Igor Paliychuk wrote: > Updated translation, changed cyrillic 'i' to latin 'i' because first one in cmd is shown as '?'. you don't need that because there is no problem with that. Wine needs a proper windows console. Try it out in "wineconsole cmd" and there it will show up correctly. bye michael

June 27, 2010

Re: [1/3] msvcrt.dll: Tests for getenv_s and _wgetenv_s

by Piotr Caban

> Is there any known MSVCRT version in which getenv_s is exported and > _set_invalid_parameter_handler is not? Both under Windows Vista and Windows 7 getenv_s is exported and _set_invalid_paramter_handler is not.

June 27, 2010

Re: Debian package backorder

by Ben Klein

On 26 June 2010 17:13, Ben Klein <shacklein(a)gmail.com> wrote: > On 25 June 2010 15:17, Ben Klein <shacklein(a)gmail.com> wrote: >> 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. >> > > Good news: I got a motherboard that is made of 120% concentrated awesome: > http://www.gigabyte.com/products/product-page.aspx?pid=3313 > > Bad news: My desktop is still not powering up. No flickering lights or > fans spinning (not even in the PSU). Maybe someone can help diagnose > this for me: OK, let's try again. Good news: It *is* actually the PSU that's the problem. I'm not sure why this didn't come up in my earlier diagnosis, but after testing the both the old and new motherboards with just the known good PSU plugged in and a screwdriver to the power switch pins, then switching over to the suspect PSU, the results are 99% indicative of a dead PSU (the remaining 1% is the LED on the old motherboard, so power is getting through along *some* wire). Bad news: wasted time/money. Although I do like the new motherboard enough to keep it. For reference: if the PSU fan doesn't spin (and any other fans connected to the PSU directly), it is most certainly a dead mobo or dead PSU. For those people who offered me help (Nate accidentally replied-to-all, the rest of you know who you are), I cannot thank you enough even just for the offer. I can't in good conscious ask for help with paying for my new PSU as I'm now surplus one motherboard, the cost of which would likely cover a suitable PSU. I'll manage somehow.

June 27, 2010

Re: Wine on cygwin now compiles!

by Stefan Dösinger

For dx10 you just need wined3d and the client libs. Those work since quite a while without any other wine component

June 27, 2010

Re: Wine on cygwin now compiles!

by David Gerard

2010/6/27 Conan Kudo (ニール・ゴンパ) <ngompa13(a)gmail.com>: > DirectX 10 games on Windows XP :P > Seriously though, being able to run programs that ran on Windows 9x but not > NT based Windows would be a pretty good use for Wine. Granted, most of those > programs are games, but meh. And then there's being able to run 16-bit > Windows apps on 64-bit Windows! :P 16-bit compilation is currently disabled in Cygwin. There's a list of ideas on http://wiki.winehq.org/WineOnWindows - * As much as possible should compile (and even work). * Check how well the .EXE and .DLL made by Wine on Cygwin work in Windows. If a MinGW-compiled DLL works in Windows, a Cygwin-compiled DLL should. * ./configure fails to pick up the presence of a lot of packages it should. * Win16 is disabled in Cygwin (severe compilation problems). Enabling that and getting it to compile would be interesting. That's as well as writing a program loader that works ;-) It is important to stress that this is *largely pointless* and mostly driven by *hack value*. - d.

June 27, 2010

Re: Wine on cygwin now compiles!

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

On Sun, Jun 27, 2010 at 3:59 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote: > Is there any real, practical interest in Wine on Windows? > I've been making some progress in this direction recently (though I think > my approach would be to have a ported, NT-version of wineserver.exe which > just uses native functions of the OS instead of emulating them over cygwin, > which emulates those features using its own code once again; discussable > anyway). > > WBR, > Aleksey Bragin. > > > DirectX 10 games on Windows XP :P Seriously though, being able to run programs that ran on Windows 9x but not NT based Windows would be a pretty good use for Wine. Granted, most of those programs are games, but meh. And then there's being able to run 16-bit Windows apps on 64-bit Windows! :P

June 27, 2010

Re: add russian translation for winerrs messages

by Nikolay Sivov

On 6/26/2010 18:23, Vitaly Lipatov wrote: > It patch adds russian translation for kernel32 windows error code descriptions This one: --- +LanguageNames=(RUS=0x419:winerr) --- should be --- +LanguageNames=(RUS=0x19:winerr) --- cause #define LANG_RUSSIAN 0x19

June 27, 2010

Re: Wine on cygwin now compiles!

by Aleksey Bragin

Is there any real, practical interest in Wine on Windows? I've been making some progress in this direction recently (though I think my approach would be to have a ported, NT-version of wineserver.exe which just uses native functions of the OS instead of emulating them over cygwin, which emulates those features using its own code once again; discussable anyway). WBR, Aleksey Bragin. On Jun 17, 2010, at 12:19 AM, Steven Edwards wrote: > On Wed, Jun 16, 2010 at 4:04 PM, Roderick Colenbrander > <thunderbird2k(a)gmail.com> wrote: >> I don't expect Wine itself to ever work on cygwin. Last year I asked >> AJ about it and there are some special file handle features which are >> needed. This stuff is supported in SUA but at least in the Vista >> version this was broken. They MIGHT have fixed it for Win7, so if >> Wine >> can work on Windows it would need Win7 but still you would need a >> version which supports SUA (which are Ultimate and perhaps some >> business version). > > If anyone is sufficiently interested in the sendrecv message sockets > over file descriptor stuff (I know I am not anymore) there may be an > archived email with a regression test I found showing the problem. > Even though it was now listed as a supported operation, it kinda sorta > worked in limited cases under Server 2003 and hung in others which > Wine stress. I don't even recall all of the details at this point but > it culminated in me presenting my findings to the SUA team developers > and them saying 'that's nice, call our support to file a bug report'. > Since I could not actually file the bug report myself online and > calling Microsoft support is like a $200 (even if they do issue a > refund or not charge your CC if it's a new real bug), I decided to > waste no more time with it. > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > >

June 27, 2010

Re: [hhctrl.ocx] Make sure pszCaption and pszFile are never 0

by Reece Dunn

On 26 June 2010 21:52, Jaroslav Šmíd <jardasmid(a)gmail.com> wrote: > Sorry, with txt extension Please resend to the wine-patches mailing list so that Alexandre can pick it up and add a "(RESEND)" to the end of the subject. Thank you for improving Wine, - Reece

June 26, 2010

Re: [hhctrl.ocx] Make sure pszCaption and pszFile are never 0

by Jaroslav Šmíd

Sorry, with txt extension On Sat, Jun 26, 2010 at 10:52 PM, Jaroslav Šmíd <jardasmid(a)gmail.com> wrote: > Attached > > On Sat, Jun 26, 2010 at 10:43 PM, Sven Baars <sven.wine(a)gmail.com> wrote: >> Charles Davis wrote: >>> >>> On Jun 26, 2010, at 2:32 PM, Jaroslav Šmíd wrote: >>> >>> >>>> >>>> --- >>>> dlls/hhctrl.ocx/chm.c | 4 ++-- >>>> 1 files changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/dlls/hhctrl.ocx/chm.c b/dlls/hhctrl.ocx/chm.c >>>> index 4c85bd9..f0452fa 100644 >>>> --- a/dlls/hhctrl.ocx/chm.c >>>> +++ b/dlls/hhctrl.ocx/chm.c >>>> @@ -238,11 +238,11 @@ BOOL LoadWinTypeFromCHM(HHInfo *info) >>>> info->WinType.pszIndex = strdupW(null); >>>> info->WinType.fsValidMembers=0; >>>> info->WinType.fsWinProperties=HHWIN_PROP_TRI_PANE; >>>> - info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle); >>>> + info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle ? >>>> info->pCHMInfo->defTitle : null); >>>> info->WinType.dwStyles=WS_POPUP; >>>> info->WinType.dwExStyles=0; >>>> info->WinType.nShowState=SW_SHOW; >>>> - info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic); >>>> + info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic ? >>>> info->pCHMInfo->defTopic : null); >>>> info->WinType.curNavType=HHWIN_NAVTYPE_TOC; >>>> return TRUE; >>>> } >>>> >>> >>> Your mailer mangled the patch, such that long lines are broken into two >>> lines. THAT is what we mean by "your patch got wrapped". We can't apply your >>> patch in this state, so you'll have to send it again after configuring your >>> mail client not to wrap long lines. >>> >>> Chip >>> >>> >>> >>> >> >> Or you could just attach them instead. That way the patch can't get mangled. >> Some mail clients just can't be trusted (like Thunderbird, which is what I'm >> using). >> >> Sven >> >> >> >> > > > > -- > Jaroslav Šmíd > -- Jaroslav Šmíd

June 26, 2010

Re: [hhctrl.ocx] Make sure pszCaption and pszFile are never 0

by Jaroslav Šmíd

Attached On Sat, Jun 26, 2010 at 10:43 PM, Sven Baars <sven.wine(a)gmail.com> wrote: > Charles Davis wrote: >> >> On Jun 26, 2010, at 2:32 PM, Jaroslav Šmíd wrote: >> >> >>> >>> --- >>> dlls/hhctrl.ocx/chm.c | 4 ++-- >>> 1 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/dlls/hhctrl.ocx/chm.c b/dlls/hhctrl.ocx/chm.c >>> index 4c85bd9..f0452fa 100644 >>> --- a/dlls/hhctrl.ocx/chm.c >>> +++ b/dlls/hhctrl.ocx/chm.c >>> @@ -238,11 +238,11 @@ BOOL LoadWinTypeFromCHM(HHInfo *info) >>> info->WinType.pszIndex = strdupW(null); >>> info->WinType.fsValidMembers=0; >>> info->WinType.fsWinProperties=HHWIN_PROP_TRI_PANE; >>> - info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle); >>> + info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle ? >>> info->pCHMInfo->defTitle : null); >>> info->WinType.dwStyles=WS_POPUP; >>> info->WinType.dwExStyles=0; >>> info->WinType.nShowState=SW_SHOW; >>> - info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic); >>> + info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic ? >>> info->pCHMInfo->defTopic : null); >>> info->WinType.curNavType=HHWIN_NAVTYPE_TOC; >>> return TRUE; >>> } >>> >> >> Your mailer mangled the patch, such that long lines are broken into two >> lines. THAT is what we mean by "your patch got wrapped". We can't apply your >> patch in this state, so you'll have to send it again after configuring your >> mail client not to wrap long lines. >> >> Chip >> >> >> >> > > Or you could just attach them instead. That way the patch can't get mangled. > Some mail clients just can't be trusted (like Thunderbird, which is what I'm > using). > > Sven > > > > -- Jaroslav Šmíd

June 26, 2010

Re: [hhctrl.ocx] Make sure pszCaption and pszFile are never 0

by Sven Baars

Charles Davis wrote: > On Jun 26, 2010, at 2:32 PM, Jaroslav Šmíd wrote: > > >> --- >> dlls/hhctrl.ocx/chm.c | 4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/dlls/hhctrl.ocx/chm.c b/dlls/hhctrl.ocx/chm.c >> index 4c85bd9..f0452fa 100644 >> --- a/dlls/hhctrl.ocx/chm.c >> +++ b/dlls/hhctrl.ocx/chm.c >> @@ -238,11 +238,11 @@ BOOL LoadWinTypeFromCHM(HHInfo *info) >> info->WinType.pszIndex = strdupW(null); >> info->WinType.fsValidMembers=0; >> info->WinType.fsWinProperties=HHWIN_PROP_TRI_PANE; >> - info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle); >> + info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle ? >> info->pCHMInfo->defTitle : null); >> info->WinType.dwStyles=WS_POPUP; >> info->WinType.dwExStyles=0; >> info->WinType.nShowState=SW_SHOW; >> - info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic); >> + info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic ? >> info->pCHMInfo->defTopic : null); >> info->WinType.curNavType=HHWIN_NAVTYPE_TOC; >> return TRUE; >> } >> > Your mailer mangled the patch, such that long lines are broken into two lines. THAT is what we mean by "your patch got wrapped". We can't apply your patch in this state, so you'll have to send it again after configuring your mail client not to wrap long lines. > > Chip > > > > Or you could just attach them instead. That way the patch can't get mangled. Some mail clients just can't be trusted (like Thunderbird, which is what I'm using). Sven

June 26, 2010

Re: [hhctrl.ocx] Make sure pszCaption and pszFile are never 0

by Charles Davis

On Jun 26, 2010, at 2:32 PM, Jaroslav Šmíd wrote: > --- > dlls/hhctrl.ocx/chm.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/hhctrl.ocx/chm.c b/dlls/hhctrl.ocx/chm.c > index 4c85bd9..f0452fa 100644 > --- a/dlls/hhctrl.ocx/chm.c > +++ b/dlls/hhctrl.ocx/chm.c > @@ -238,11 +238,11 @@ BOOL LoadWinTypeFromCHM(HHInfo *info) > info->WinType.pszIndex = strdupW(null); > info->WinType.fsValidMembers=0; > info->WinType.fsWinProperties=HHWIN_PROP_TRI_PANE; > - info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle); > + info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle ? > info->pCHMInfo->defTitle : null); > info->WinType.dwStyles=WS_POPUP; > info->WinType.dwExStyles=0; > info->WinType.nShowState=SW_SHOW; > - info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic); > + info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic ? > info->pCHMInfo->defTopic : null); > info->WinType.curNavType=HHWIN_NAVTYPE_TOC; > return TRUE; > } Your mailer mangled the patch, such that long lines are broken into two lines. THAT is what we mean by "your patch got wrapped". We can't apply your patch in this state, so you'll have to send it again after configuring your mail client not to wrap long lines. Chip

June 26, 2010

Re: [hhctrl.ocx] Null pointer fix, new patch

by Jaroslav Šmíd

On Wed, Jun 23, 2010 at 6:50 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Jaroslav Šmíd <jardasmid(a)gmail.com> wrote: > >> diff -urN Wine-git.orig/dlls/hhctrl.ocx/chm.c Wine-git/dlls/hhctrl.ocx/chm.c >> --- Wine-git.orig/dlls/hhctrl.ocx/chm.c 2010-06-22 12:41:54.034540000 +0200 >> +++ Wine-git/dlls/hhctrl.ocx/chm.c 2010-06-22 12:51:07.454541388 +0200 >> @@ -238,11 +238,11 @@ >> info->WinType.pszIndex = strdupW(null); >> info->WinType.fsValidMembers=0; >> info->WinType.fsWinProperties=HHWIN_PROP_TRI_PANE; >> - info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle); >> + info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle ? >> info->pCHMInfo->defTitle : null); >> info->WinType.dwStyles=WS_POPUP; >> info->WinType.dwExStyles=0; >> info->WinType.nShowState=SW_SHOW; >> - info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic); >> + info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic ? >> info->pCHMInfo->defTopic : null); >> info->WinType.curNavType=HHWIN_NAVTYPE_TOC; >> return TRUE; >> } > > The patch is wrapped. > > -- > Dmitry. > What does it mean it is wrapped? Accepted or not? If not, why? -- Jaroslav Šmíd

June 26, 2010

Re: How do you make x64 crosstests?

by Nicolas Le Cam

2010/6/26 Austin English <austinenglish(a)gmail.com>: > On Fri, Jun 25, 2010 at 2:49 AM, Ilya Basin <basinilya(a)gmail.com> wrote: > > Should be install 64-bit mingw, compile wine in 64-bit mode, and run > 'make crosstest'. Though I just tried this on Ubuntu Lucid, and it > fails for me there (configure is looking for > checking for x86_64-pc-mingw32-gcc... no > checking for x86_64-w64-mingw32-gcc... no > > while on Ubuntu, it is: > amd64-mingw32msvc-gcc > > however, it seems compiling with it is broken: > austin(a)midna:~/64-wine-git$ amd64-mingw32msvc-gcc foo.c > /usr/lib/gcc/amd64-mingw32msvc/4.4.2/../../../../amd64-mingw32msvc/bin/ld: > cannot find -lgcc > collect2: ld returned 1 exit status > > perhaps someone else has tried and had better luck... > > -- > -Austin > > > For the configure part you could use CROSSCC=amd64-mingw32msvc-gcc to help on debian/ubuntu but I'm stuck with the same problem, it can't find libgcc, although it is installed in /usr/lib/gcc/amd64-mingw32msvc/4.4.4/ by gcc-mingw32 package. I remember seeing documentation on how to build crosstests on the wiki but it seems to have disappeared from it (with a circular reference now between ConformanceTests and MakeTestFailures pages). -- Nicolas Le Cam

June 26, 2010

Re: add russian translation for winerrs messages

by Paul Vriens

On 06/26/2010 04:31 PM, Paul Vriens wrote: > On 06/26/2010 04:23 PM, Vitaly Lipatov wrote: >> + >> +LanguageNames=(RUS=0x419:winerr) >> + >> +MessageId=0 > > Hi, > > It looks like the file is in UTF-8 so shouldn't we need a > "CodePages=(RUS=65001:0)"? > Ran the patch against my local copy of 'transl' and that CodePages line should indeed be added. -- Cheers, Paul.

June 26, 2010

Re: add russian translation for winerrs messages

by Paul Vriens

On 06/26/2010 04:23 PM, Vitaly Lipatov wrote: > + > +LanguageNames=(RUS=0x419:winerr) > + > +MessageId=0 Hi, It looks like the file is in UTF-8 so shouldn't we need a "CodePages=(RUS=65001:0)"? -- Cheers, Paul.

June 26, 2010

Re: Please resend the fixed gcov patch by tomorrow so I can test building with it :)

by Peter Davies

> What is the cleanest way to do this? I was hoping it would be as simple > as passing -fprofile-generate and -fprofile-dir as CFLAGS and LDFLAGS > to configure. > > Thanks, > Scott Ritchie Copy 'preloader.o' (to prevent wine-preloader being rebuilt) and 'wine-preloader' from a normal build. As noted elsewhere -fprofile-dir won't work (I intend to fix this soon). Peter

June 26, 2010

Using string resources in conformance tests.

by Michael Mc Donnell

Hi wine developers! I've written a conformance test (my first) for bug 17986: BrsFolder_OnCommand make new folder not implemented. The conformance test tests if clicking on the "Make New Folder" button in a SHBrowseForFolder dialog box results in creation of a new folder. I want the test to be localized and work across all newer versions of Windows, but I'm having trouble with it. I use the LoadString function to get the "New folder" string from shell32.dll that is used for creating a new folder. The problem is that the location where it is stored in shell32.dll varies between the different versions of Windows. I can only make the test work on one version at a time. Even the capitalization varies between the different versions of Windows, i.e. "New Folder" vs. "New folder". My question is how should we handle a problem like the one mentioned above? Should we avoid using string resources in conformance test, or should we try to handle the version issues? One solution would be to hard code the string instead of loading it from a resource. This would, however, mean that the test would be skipped on all non-English versions of windows, and it would additionally have to ignore the capitalization differences. Another solution would be to get the string according to the version of Windows. This would, however, pose a problem in wine because it does not emulate any specific Windows version. The location of the string in wine's shell32.dll does not match any version of Windows, and we would therefore also have to detect if the test is running on wine. Has anyone bumped into the same problem, or does anyone know a thread about this on wine-devel? Do you have any comments on what to do? Thanks, Michael Mc Donnell

June 26, 2010

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

by Peter Davies

> 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? Due to limitations of my patch -fprofile-dir (or passing arguments to -fprofile-* is unsupported). All it allows you can do is pass "--coverage", "-fprofile-generate" or "-fprofile-use" to winegcc without arguments. It started as a hack to enable gcov and evolved into a hack to enable PGO and gcov. Peter

June 26, 2010

Re: Please resend the fixed gcov patch by tomorrow so I can test building with it :)

by Scott Ritchie

On 06/18/2010 11:40 AM, Peter Davies wrote: > I didn't send it because the change was so trivial (I have now). Note > you will need to build wine-preloader without PGO (and with a > libport.a without PGO) or you will get libc linking errors. > > Peter > > What is the cleanest way to do this? I was hoping it would be as simple as passing -fprofile-generate and -fprofile-dir as CFLAGS and LDFLAGS to configure. Thanks, Scott Ritchie

June 26, 2010

Re: Debian package backorder

by Ben Klein

On 25 June 2010 15:17, Ben Klein <shacklein(a)gmail.com> wrote: > 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. > Good news: I got a motherboard that is made of 120% concentrated awesome: http://www.gigabyte.com/products/product-page.aspx?pid=3313 Bad news: My desktop is still not powering up. No flickering lights or fans spinning (not even in the PSU). Maybe someone can help diagnose this for me: * Last time working, newly-plugged-in USB devices were not functioning. USB mouse was fine (plugged in from boot, no legacy mouse in BIOS), no other USB device functioned correctly (one card reader not detected at all, another only detected with first of four slots accessible). * System believed to have shut down normally from last working state, but cannot confirm this. * Main issue: press power button; nothing happens. * Power supply LED on old motherboard was active (indicating PSU giving power to motherboard). New motherboard does not have this LED. * Tested with another system's power button, no difference. * Tested with another system's PSU, no difference. * Suspected mobo issue due to USB problems. Tried new mobo (above), no difference. So now I suspect the CPU (Phenom x4 945, IIRC). The RAM (4x 2GB DDR2-800) is the only other device I haven't changed or unplugged. If my (new) suspicion is right: Pro: I'd have to get a Phenom II to replace it (don't even mention Semprons!), meaning more cache and faster processing, and having the option of going X6. Con: I CAN HAS TEH CASH PLZ? I can't afford a comparable CPU (AUD$161 for Phenom II x4 945), especially after buying the new motherboard (which I don't particularly want to return; it's narrower than my old one and has features that better suit me). Remind me to send a letter to AMD thanking them for putting DDR2 controllers in their AM3 CPUs.

June 26, 2010

Re: automated stack dumps broken, just output winedbg usage message now?

by Eric Pouech

Le 26/06/2010 01:58, Dan Kegel a écrit : > Is anybody else seeing winedbg fail to generate stack dumps? > I'm seeing > > wine: Unhandled page fault on read access to 0x00000000 at address > 0xb736bd68 (thread 0009), starting debugger... > Usage: > winedbg [ [ --gdb ] [ prog-name [ prog-args ] |<num> | > file.mdmp | --help ] > > on a lot of apps when they crash. Could be me, but I figured I'd ask. > > This is with wine-1.2-rc3. > > > > > maybe your AeDebug registry entry is broken (in system.reg) it should read (for a standard install): [Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 1274602108 "Auto"="1" "Debugger"="winedbg --auto %ld %ld" or (if you want to still use the debugger when a crash happens) [Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 1274602108 "Auto"="1" "Debugger"="winedbg %ld %ld" A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

June 26, 2010

Re: Addition of En resources to non-En resources

by Dmitry Timoshkov

Francois Gouget <fgouget(a)free.fr> wrote: [skipped] > 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? There is nothing strange there, if the text still fits and doesn't get clipped out. > So in fact all you get with the status-quo is few translations *AND* > broken dialog layouts. Same position and size of the controls in different languages doesn't suddenly make the dialog layout broken. -- Dmitry.

June 26, 2010

Re: How do you make x64 crosstests?

by Austin English

On Fri, Jun 25, 2010 at 2:49 AM, Ilya Basin <basinilya(a)gmail.com> wrote: Should be install 64-bit mingw, compile wine in 64-bit mode, and run 'make crosstest'. Though I just tried this on Ubuntu Lucid, and it fails for me there (configure is looking for checking for x86_64-pc-mingw32-gcc... no checking for x86_64-w64-mingw32-gcc... no while on Ubuntu, it is: amd64-mingw32msvc-gcc however, it seems compiling with it is broken: austin(a)midna:~/64-wine-git$ amd64-mingw32msvc-gcc foo.c /usr/lib/gcc/amd64-mingw32msvc/4.4.2/../../../../amd64-mingw32msvc/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status perhaps someone else has tried and had better luck... -- -Austin

June 26, 2010

Re: [PATCH 6/6] 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=2935 Your paranoid android. === WINEBUILD (build) === Make failed

June 26, 2010

Re: [PATCH 5/6] 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=2934 Your paranoid android. === WINEBUILD (build) === Make failed

June 26, 2010

Re: [PATCH 4/6] 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=2933 Your paranoid android. === WINEBUILD (build) === Make failed

June 26, 2010

Re: [PATCH 3/6] 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=2932 Your paranoid android. === WINEBUILD (build) === Make failed

June 26, 2010

Re: [PATCH 2/6] d3dx9: Add a few more 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=2931 Your paranoid android. === WINEBUILD (build) === Make failed

June 26, 2010

Re: [PATCH 1/6] 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=2930 Your paranoid android. === WINEBUILD (build) === Make failed

June 26, 2010

automated stack dumps broken, just output winedbg usage message now?

by Dan Kegel

Is anybody else seeing winedbg fail to generate stack dumps? I'm seeing wine: Unhandled page fault on read access to 0x00000000 at address 0xb736bd68 (thread 0009), starting debugger... Usage: winedbg [ [ --gdb ] [ prog-name [ prog-args ] | <num> | file.mdmp | --help ] on a lot of apps when they crash. Could be me, but I figured I'd ask. This is with wine-1.2-rc3.

June 25, 2010

Re: structure has #pragma pack(8) in Windows SDK (AMD64) and #pragma pack(1) in wine headers

by Alexandre Julliard

Ilya Basin <basinilya(a)gmail.com> writes: > The struct in question is CSFV defined in shlobh.h. If I try to > compile shell32_test for x64 using headers from windows 2008 SDK, I > get assertion failure here: > http://source.winehq.org/source/dlls/shell32/tests/generated.c?v=wine-1.2-r… > > Is it normal for wine to have different structure packing? No, please send a patch. -- Alexandre Julliard julliard(a)winehq.org

June 25, 2010

structure has #pragma pack(8) in Windows SDK (AMD64) and #pragma pack(1) in wine headers

by Ilya Basin

The struct in question is CSFV defined in shlobh.h. If I try to compile shell32_test for x64 using headers from windows 2008 SDK, I get assertion failure here: http://source.winehq.org/source/dlls/shell32/tests/generated.c?v=wine-1.2-r… Is it normal for wine to have different structure packing?

June 25, 2010

Re: Tests for msvcrt

by Paul Chitescu

On Thursday 24 June 2010 12:14:34 pm Piotr Caban wrote: > 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). The problem is that these functions will be available: - on Wine in MSVCRT and MSVCRxx >= 80 - on Windows XP only in MSVCRxx >= 80 (if installed) - on Windows 7 in MSVCRT and MSVCRxx >= 80 (if installed) - no idea about Vista and other intermediate versions, service packs, etc. What should the test do and where should it be located? In msvcrt/tests ? Or in msvcr90/tests ? Or create a msvcr80/tests ? Or...? Would it be acceptable to test the functions only if available in msvcrt.dll ? If the functions are not present should the code in msvcrt/tests attempt to load msvcr80 or msvcr90 or...? What do you think? Paul

June 25, 2010

Re: Debian package backorder

by Nate Gallaher

Ben Klein wrote: > 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. > > > Sure. Send me a newegg link and an address. ~Nate

June 25, 2010

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

by Misha Koshelev

On Fri, 2010-06-25 at 18:59 +0200, Henri Verbeet wrote: > On 25 June 2010 18:20, Misha Koshelev <misha680(a)gmail.com> wrote: > >> regard, although there are (very) minor issues like using %d for > >> unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 > >> over simply "IDirect3DDevice9 *". > > > > Oh and the LPDIRECT3DDEVICE9's are straight from line.c tests. But I will heed > > your advice on the %d's > > > I wouldn't object to a patch based on either of those alone, but if > you'll have to resend anyway I might as well point those out. Very well then. Let's just leave the deferred patch as is if that's okay http://source.winehq.org/patches/data/62909 and I'll send out further patches post-code freeze heeding all of your advice. Thank you Misha

June 25, 2010

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

by Henri Verbeet

On 25 June 2010 18:14, Misha Koshelev <misha680(a)gmail.com> wrote: > If I do not declare these functions, how do I call the Release method of > the appropriate interfaces? > > Specifically, I started looking at the test for line.c - I believe that > if I create a mesh, I have to release it. > If it's just about releasing the interface, using the generic IUnknown_Release macro should always work. The larger issue though is that most (all?) of the d3dx9 interfaces don't have corresponding C macros. That means you'll have to call those functions explicitly through lpVtbl in C, but you'd have to do that when using the MS headers as well.

June 25, 2010

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

by Henri Verbeet

On 25 June 2010 18:20, Misha Koshelev <misha680(a)gmail.com> wrote: >> regard, although there are (very) minor issues like using %d for >> unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 >> over simply "IDirect3DDevice9 *". > > Oh and the LPDIRECT3DDEVICE9's are straight from line.c tests. But I will heed > your advice on the %d's > I wouldn't object to a patch based on either of those alone, but if you'll have to resend anyway I might as well point those out.

June 25, 2010

Re:

by Henri Verbeet

On 25 June 2010 18:07, Misha Koshelev <misha680(a)gmail.com> wrote: > So here is why I thought maybe having a separate shape.c file might be good. I am very new to D3DX9 so > please pardon my ignorance, but simply looking at SDK, I see: > > i) http://msdn.microsoft.com/en-us/library/bb172976%28v=VS.85%29.aspx > Shape Drawing Functions are all defined in "D3dx9shape.h" > > whereas > http://msdn.microsoft.com/en-us/library/bb172973%28v=VS.85%29.aspx > Mesh Functions are all defined in "D3dx9mesh.h" > > This is not a reason to implement shape drawing functions in a separate file _per se_, but additionally: > > ii) all the tests in mesh.c do not rely on CreateWindow calls or Direct3DCreate9 calls whereas those for shape > functions inherently will (like line.c) > > Thus, since I'm going to try to focus on d3dx9 stuff (hope code-freeze is over July 4th), it seems like it might be good > to have a separate file. > > What is the argument for keeping them all in the mesh file besides that they are mesh creation functions? > Essentially that there's no convincing reason not to. It's only a handful of functions, clearly related to the mesh functions, so you can't justify it with reasons like prohibitive source file size or being clearly distinct functionality. Also, Wine as a project has a preference of fewer large files over lots of small ones. You can make good arguments for that in terms of e.g. ease of editing and keeping a good overview of things, but if nothing else you can simply consider it project policy.

June 25, 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. > > 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 *". Oh and the LPDIRECT3DDEVICE9's are straight from line.c tests. But I will heed your advice on the %d's Misha

June 25, 2010

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

by Misha Koshelev

> On 24 June 2010 05:18, Misha Koshelev <misha680 at 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? > > > ______________________________________________________________________ Ok, now here I just have to plead ignorance my apologies... If I do not declare these functions, how do I call the Release method of the appropriate interfaces? Specifically, I started looking at the test for line.c - I believe that if I create a mesh, I have to release it. I have largely been learning from this page: http://www.mvps.org/directx/articles/d3dxmesh.htm (which is DirectX 8) but it seems I have to somehow release the functions no? Also, I'm probably going to start with the D3DXCreateBox function, as I need to figure out exactly what's going on with the vertices before I delve into something as complicated as spheres ;) Thanks y'all :) Misha

June 25, 2010

(no subject)

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. > > 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 *". > So I don't think I'm going to be getting much productive done with 1.2 bugs done in a single day, and the one I started working on yesterday is now fixed. So might as well start thinking about D3DX9. So here is why I thought maybe having a separate shape.c file might be good. I am very new to D3DX9 so please pardon my ignorance, but simply looking at SDK, I see: i) http://msdn.microsoft.com/en-us/library/bb172976%28v=VS.85%29.aspx Shape Drawing Functions are all defined in "D3dx9shape.h" whereas http://msdn.microsoft.com/en-us/library/bb172973%28v=VS.85%29.aspx Mesh Functions are all defined in "D3dx9mesh.h" This is not a reason to implement shape drawing functions in a separate file _per se_, but additionally: ii) all the tests in mesh.c do not rely on CreateWindow calls or Direct3DCreate9 calls whereas those for shape functions inherently will (like line.c) Thus, since I'm going to try to focus on d3dx9 stuff (hope code-freeze is over July 4th), it seems like it might be good to have a separate file. What is the argument for keeping them all in the mesh file besides that they are mesh creation functions? Thank you Misha

June 25, 2010

Re: sorry guys... slow on uptake today :)

by Misha Koshelev

On Fri, 2010-06-25 at 07:31 -0700, James Mckenzie wrote: > Misha Koshelev <misha680(a)gmail.com> wrote: > > > >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 :( > > > If the fix is large and ugly, it will not be looked at until after the code freeze is lifted anyway. Ah I see :) > > Have a safe travel. Thank you. Much appreciated. > > James Mckenzie >

June 25, 2010

Re: sorry guys... slow on uptake today :)

by James Mckenzie

Misha Koshelev <misha680(a)gmail.com> wrote: > >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 :( > If the fix is large and ugly, it will not be looked at until after the code freeze is lifted anyway. Have a safe travel. James Mckenzie

June 25, 2010