- wine-devel - winehq.org

Fwd: wine-bugs Digest, Vol 42, Issue 330
by Austin English 26 Jan '09

26 Jan '09

---------- Forwarded message ---------- From: <wine-bugs-request(a)winehq.org> Date: Tue, Jan 13, 2009 at 9:20 AM Subject: wine-bugs Digest, Vol 42, Issue 330 To: wine-bugs(a)winehq.org ---------------------------------------------------------------------- Message: 1 Date: Tue, 13 Jan 2009 08:40:35 -0600 From: wine-bugs(a)winehq.org Subject: [Bug 14413] Freedom: First Resistance problems To: wine-bugs(a)winehq.org Message-ID: <E1LMkRX-0004cJ-Iv(a)wine.codeweavers.com> Content-Type: text/plain; charset="UTF-8" http://bugs.winehq.org/show_bug.cgi?id=14413 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|REMIND |ABANDONED --- Comment #5 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-01-13 08:40:35 --- REMIND is not an appropriate resolution in Wine bugzilla. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes. ------------------------------ Message: 3 Date: Tue, 13 Jan 2009 08:45:37 -0600 From: wine-bugs(a)winehq.org Subject: [Bug 14413] Freedom: First Resistance problems To: wine-bugs(a)winehq.org Message-ID: <E1LMkWP-0004zA-63(a)wine.codeweavers.com> Content-Type: text/plain; charset="UTF-8" http://bugs.winehq.org/show_bug.cgi?id=14413 Maki <Makitk(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|ABANDONED |LATER --- Comment #6 from Maki <Makitk(a)gmail.com> 2009-01-13 08:45:36 --- (In reply to comment #5) > REMIND is not an appropriate resolution in Wine bugzilla. > Fun, fun. It shouldn't BE IN bugzilla's dropdown menu then. ------------------------------ Message: 6 Date: Tue, 13 Jan 2009 08:53:34 -0600 From: wine-bugs(a)winehq.org Subject: [Bug 14413] Freedom: First Resistance problems To: wine-bugs(a)winehq.org Message-ID: <E1LMke6-0005WL-SX(a)wine.codeweavers.com> Content-Type: text/plain; charset="UTF-8" http://bugs.winehq.org/show_bug.cgi?id=14413 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|LATER |ABANDONED --- Comment #7 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-01-13 08:53:34 --- > Fun, fun. It shouldn't BE IN bugzilla's dropdown menu then. It doesn't matter what in the bugzilla's dropdown menu. LATER and REMIND are considered as not appropriate resolutions in WineHQ bugzilla, they are meaningless. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes. How do we expect users to know not to use these resolutions? It's not listed anywhere, and those are appropriate resolutions in other bugzillas. We've already went through and removed all of them from bug entries in bugzilla, so can an admin please remove these resolutions? -- -Austin

2 1

Re: Bugzilla question with respect to .NET 1.1SP1
by James Mckenzie 26 Jan '09

26 Jan '09

Paul Vriens <paul.vriens.wine(a)gmail.com> >Sent: Jan 26, 2009 4:45 AM >To: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Bugzilla question with respect to .NET 1.1SP1 > >Hi, > >I have an application that won't install because it's trying to first do an >install of .NET 1.1 and straight after that an upgrade/update to SP1. > >.NET 1.1SP1 install fails (see bug http://bugs.winehq.org/show_bug.cgi?id=13995). > >Should I create a new bug report and say that it depends on 13995, should I >create a bugreport that is then marked as a duplicate of 13995 or should I just >add my findings to 13995? > If it is a separate application, separate bug report. If the same application is affected, update. Since it appears that you are using a different application to install .NET 1.1 SP1, then a new report should be submitted and then linked to issue 13995. The reason I state this is that additional problems may be discovered, even after .NET 1.1 SP1 runs and installs. It may also be possible to get your application to run, even if .NET 1.1 SP1 will not fully install. I would classify this as an application does not install because .NET 1.1 SP1 will not install properly. James McKenzie

3 5

Re: Bugzilla question with respect to .NET 1.1SP1
by James Mckenzie 26 Jan '09

26 Jan '09

Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: >Sent: Jan 26, 2009 7:10 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Re: Bugzilla question with respect to .NET 1.1SP1 > >James Mckenzie wrote: >> Paul Vriens <paul.vriens.wine(a)gmail.com> >>> Sent: Jan 26, 2009 4:45 AM >>> To: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >>> Subject: Bugzilla question with respect to .NET 1.1SP1 >>> >>> Hi, >>> >>> I have an application that won't install because it's trying to first do an >>> install of .NET 1.1 and straight after that an upgrade/update to SP1. >>> >>> .NET 1.1SP1 install fails (see bug http://bugs.winehq.org/show_bug.cgi?id=13995). >>> >>> Should I create a new bug report and say that it depends on 13995, should I >>> create a bugreport that is then marked as a duplicate of 13995 or should I just >>> add my findings to 13995? >>> >> If it is a separate application, separate bug report. If the same application is affected, update. Since it appears that you are using a different application to install .NET 1.1 SP1, then a new report should be submitted and then linked to issue 13995. The reason I state this is that additional problems may be discovered, even after .NET 1.1 SP1 runs and installs. It may also be possible to get your application to run, even if .NET 1.1 SP1 will not fully install. >> >> I would classify this as an application does not install because .NET 1.1 SP1 will not install properly. >> >> James McKenzie >> >> >So that means bug 14850 needs to be reopened with a link to 13995? > If the problem may be outside of .NET 1.1 SP1, yes. If not, then the answer is no. I'll have to look at the two bug reports and see if they are related and true duplicates. James McKenzie

1 0

Bugzilla question with respect to .NET 1.1SP1
by Paul Vriens 26 Jan '09

26 Jan '09

Hi, I have an application that won't install because it's trying to first do an install of .NET 1.1 and straight after that an upgrade/update to SP1. .NET 1.1SP1 install fails (see bug http://bugs.winehq.org/show_bug.cgi?id=13995). Should I create a new bug report and say that it depends on 13995, should I create a bugreport that is then marked as a duplicate of 13995 or should I just add my findings to 13995? Bug 9140 for example is a separate report with a dependence on 13995. And bug 14850 is marked as a duplicate of 13995. -- Cheers, Paul.

1 0

Re: d3d8/tests: Make tests pass on W2K8
by Ge van Geldorp 26 Jan '09

26 Jan '09

Hi Henri, > From: Henri Verbeet > 2009/1/26 Ge van Geldorp <ge at gse.nl>: > > Changelog: > > d3d8/tests: Make tests pass on W2K8 > > > > >- ok(hr == D3D_OK || hr == D3DERR_INVALIDCALL, "IDirect3D8_CreateDevice failed with %#08x\n", hr); > >+ ok(hr == D3D_OK || hr == D3DERR_INVALIDCALL || hr == D3DERR_NOTAVAILABLE, "IDirect3D8_CreateDevice failed with %#08x\n", hr); > > This looks more like something certain VMs would return than something specific to a particular Windows version. You're probably right, this was run on a VM. However, I don't see the same failure on other Windows versions. And I guess the test should still pass, even when it runs on a VM? Gé.

2 1

Checking an empty CDROM drive
by Paul Vriens 26 Jan '09

26 Jan '09

Hi, I'm trying to come up with some test to show that GetDriveType returns DRIVE_CDROM regardless whether there is or isn't a CD mounted. I have the following: diff --git a/dlls/kernel32/tests/drive.c b/dlls/kernel32/tests/drive.c index a94cbdf..53b0262 100644 --- a/dlls/kernel32/tests/drive.c +++ b/dlls/kernel32/tests/drive.c @@ -46,6 +46,24 @@ static void test_GetDriveTypeA(void) "GetDriveTypeA should return DRIVE_NO_ROOT_DIR for inexistent drive %c: but not %u\n", drive[0], type); + /* Check if type is still DRIVE_CDROM even when no CD is mounted */ + if (type == 5) + { + DWORD attrs; + + SetLastError(0xdeadbeef); + attrs = GetFileAttributesA(drive); + if (attrs == INVALID_FILE_ATTRIBUTES) + { + trace("Unmounted CDROM with type DRIVE_CDROM\n"); + ok(GetLastError() == ERROR_NOT_READY, + "Expected ERROR_NOT_READY for an unmounted CDROM\n"); + } + else + ok((attrs & FILE_ATTRIBUTE_DIRECTORY) == FILE_ATTRIBUTE_DIRECTORY, + "Expected FILE_ATTRIBUTE_DIRECTORY for a mounted CDROM\n"); + } + logical_drives >>= 1; } } The idea however is to show that Wine is wrong in returning DRIVE_NO_ROOT_DIR for an unmounted CD. The test above of course doesn't show that, it only proves that Windows does it this way. (All is related to bug http://bugs.winehq.org/show_bug.cgi?id=16592) -- Cheers, Paul.

1 1

Re: d3d8/tests: Make tests pass on W2K8
by Henri Verbeet 26 Jan '09

26 Jan '09

2009/1/26 Ge van Geldorp <ge(a)gse.nl>: > Changelog: > d3d8/tests: Make tests pass on W2K8 > >- ok(hr == D3D_OK || hr == D3DERR_INVALIDCALL, "IDirect3D8_CreateDevice failed with %#08x\n", hr); >+ ok(hr == D3D_OK || hr == D3DERR_INVALIDCALL || hr == D3DERR_NOTAVAILABLE, "IDirect3D8_CreateDevice failed with %#08x\n", hr); This looks more like something certain VMs would return than something specific to a particular Windows version.

1 0

user32: Resend: Move character conversion logic to dde_server.d & remove todo's
by Jeff Latimer 26 Jan '09

26 Jan '09

I have resubmitted this patch for discussion purposes. Patch "user32/tests: Clarify the msgs to differentiate Unicode and ASCII in tests" cleans up existing tests for this situation and demonstrates the functionality. The problem remains that the application passes to the dde/ddeml data that is of type LPBYTE. This can occur as a message post or a DDEML call. DDE operates in two ways. * The first is the native DDE using POST and GET messaging. In this case data is passed without translation. * The second case uses DDEML. When using DDEML, the data is translated to and from Unicode depending on the server client window type. * However, there is a third case, the hybrid. In this case if the client uses messaging and posts a message, and the server uses DDEML translation will occur. If the client uses DDEML and the server uses a get to retrieve the message translation will not occur. The data passed to DDE/DDEML is LPBYTE but it can be Unicode or ASCII regardless of the interface type of the client. In all cases the data is translated into the type of the server. The issue is that the client passes data using messaging or DDEML there is no method in the api to inform the server whether the data is Unicode or not. The only method I have determined is to use IsTextUnicode() but that is guessing. However, it looks like Windows guesses too. Can I get some advice on this as the existing code does need to be fixed. Jeff

2 9

Re: re: Test Case to show Wine-MSVCRT still misshandling ASCII Mode
by Uwe Bonnes 25 Jan '09

25 Jan '09

>>>>> "Dan" == Dan Kegel <dank(a)kegel.com> writes: Dan> That's how we used to do it, but tests showed that _filbuf really Dan> has to do the cr removal. Dan> On Jan 25, 2009 10:57 AM, "Uwe Bonnes" < Dan> bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: >>>>> "Dan" == Dan Kegel <dank(a)kegel.com> writes: Dan> I'll have a look... Dan> For me it looks like our whole black magic handling for the CR Dan> removal in read_i() is wrong. Probably _filbuf() should fill the Dan> buffer as is, only fget(w)c() should skip CR in text mode and Dan> fread() in binary mode should use unaltered chunks of _filbuf() in Dan> binary mode and iterate through _filbuf() in text mode, skipping Dan> CR. Could it be that _filbuf also skips CR as return value in text mode? B.t.w., for a file like "\\r\\r\\r\\nEOF", native _filbuf returns 0x0d... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

returned status 2
by gnuoytr＠rcn.com 25 Jan '09

25 Jan '09

I was able to install some packages, but this and mdac27 can't find itself. The file is there.??? ubuntu 8.10 wine 1.1.13 I was able to install all packages needed on ubuntu 6.06 wine 1.0.1; different machine. thanks, Robert Location: http://ufpr.dl.sourceforge.net/sourceforge/bzflag/BZEditW32_1.6.5_Installer… [following] --2009-01-25 15:12:46-- http://ufpr.dl.sourceforge.net/sourceforge/bzflag/BZEditW32_1.6.5_Installer… Resolving ufpr.dl.sourceforge.net... 200.236.31.1, 200.17.202.1 Connecting to ufpr.dl.sourceforge.net|200.236.31.1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 882263 (862K) [application/x-msdos-program] Saving to: `BZEditW32_1.6.5_Installer.exe' 100%[==========================================================================================>] 882,263 110K/s in 15s 2009-01-25 15:13:02 (57.7 KB/s) - `BZEditW32_1.6.5_Installer.exe' saved [882263/882263] Executing wine /home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe wine: cannot find '/home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe' Note: command 'wine /home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe' returned status 2. Aborting.

2 1

Talk at Google, "the Wine user experience"
by Owen Rudge 25 Jan '09

25 Jan '09

Hey all, I've been a bit quiet as of late with uni work and so on, but figured I'd let you guys know that I was visiting Google in Mountain View on Thursday, and while there gave a tech talk on "Windows Meets Linux: the Wine user experience" - basically going over some of the issues with getting Wine out to users, ensuring a smooth experience for these users, and the challenges involves in this. It seemed to be well-received, and the talk is now up on YouTube: http://uk.youtube.com/watch?v=5E2HDQw4xmM Cheers! -- Owen Rudge http://www.owenrudge.net/

1 0

re: Test Case to show Wine-MSVCRT still misshandling ASCII Mode
by Dan Kegel 25 Jan '09

25 Jan '09

I'll have a look...

1 0

Re: comctl32[2/2]: toolbar: fix the layout of TBUTTON_INFO on Win64
by Dmitry Timoshkov 25 Jan '09

25 Jan '09

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > +/* Note: TOOLBAR_DumpButton assumes the layout of the beginning of the structure > + * is the same as of TBBUTTON */ > typedef struct > { > INT iBitmap; > @@ -96,6 +98,9 @@ typedef struct > BYTE fsStyle; > BYTE bHot; > BYTE bDropDownPressed; > +#ifdef _WIN64 > + BYTE bReserved64[4]; > +#endif > DWORD_PTR dwData; > INT_PTR iString; > INT nRow; Then probably it would make sense to make TBBUTTON the first member of the above structure. That would help in avoiding possible layout problems in future. -- Dmitry.

3 5

A step in the wrong direction, in an ocean of steps in the right direction (try 3)
by Guillaume SH 25 Jan '09

25 Jan '09

Hi wine team, First let me thank you for providing wine software witch I see as a strong asset in the expansion of free software and as a useful tool for people (like me) already using free software wherever possible. At this point, Wine is at a very good level both in API coverage, quality (less and less hack, more and more nice and clean solutions) and efficiency. Reaching that level required a tremendous work in all kinds of domains (implementation, coordination, patch value judgment, test suite...). In this regard I want to thank you again and congratulate you all guys, what you have done so far is quite an achievement. This week however I was quite puzzled by one commit : "kernel32: Make GetOverlappedResult crash on NULL args as native does."(1) As I'm following wine only for a short time (count in months, not in years) I guess reproducing windows unfixed defects is a choice (although I am not sure this decision comes from consensus or from a boss statement) made by wine team. Thinking about it I see only one argument justifying it's the good direction : for the sake or portability from wine to windows platforms. For example, a firm using wine on a free-OS platform, for software development with a Windows target platform. Relying on this assertion (which someone may demonstrate me to be false, secondary or incomplete), I'm afraid that wine take a step in the wrong direction from what seems to me the third major reason to switch from non-free OS platform (typically Windows) from free-OS platform. Those 3 main reasons are for me : 1 - Freedom (possibility to browse sources, self-compile from sources and even modifying them) 2 - Free from charge 3 - Communicating openly about known defects in software, fixing defects without respects for commercial stakes (ex: hide bug until the xxth release, or not fixing a known bug until it is publicly discovered) To summarize, I'm stating that removing the clean and safe way to handle NULL parameters in this function to fall back to bad and dirty crash, exposing security issue for user (a software can be created specifically by a ill-intentioned one to exploit this defect), all for the sake of being as bad as Windows is, is a step in the wrong direction. I feel sad enough about it, and I think it can prevent advertised people to use it but above all to recommends Windows user to go for free-OS platform with usage of wine for their needs not covered by free-software (like proprietary format). Nevertheless, just as I said, I'm still very enthusiast about wine and still think it's great and very useful. I will continue to use it, promote its usage when suitable, and also warn about its known defects people around me. Guillaume (1) for reference : 32cc4011ee04046d41a41549d5a6a6233647f756 from 22/01/2009 PS : I am fully aware that free software have defects too, some of them being security issue. I am also aware, that in a software as huge as wine, reaching even a medium security level is a real strong challenge, increased by the defects in Windows API design. I am also fully aware that security is a process, not a product.

4 4

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
by Ben Klein 25 Jan '09

25 Jan '09

2009/1/26 Guillaume SH <gsh.debianlists(a)gmail.com>: > I will be my last mail though because I understood that there is a > consensus that wine shouldn't be a safe and good tool enabling > transition from Windows to free-OS, but rather a tool with a > not-so-clear goal (again I'm not willing to start flaming, so please > don't). Wine's goal is perfectly clear: to provide, as best as possible, a complete and accurate implementation of win32 (and win64 long-term) and related APIs. If putting invalid data into a specific function causes a known crash on the only other implementation of win32 (Microsoft Windows), especially considering that win32 is standardised by the same company that produces Windows, it can be assumed that the crash is the correct behaviour and Wine should emulate it. >>> 1 - Freedom (possibility to browse sources, self-compile from sources >>> and even modifying them) >> >> This one commit does not making the source any less open. > I totally agree : this the first reason i evoked and it is 100% reached by wine > >>> 2 - Free from charge >> >> This one commit does not put a price tag on Wine. > I totally agree : this is the second reason I evoked and it is 100% > reached by wine > >>> 3 - Communicating openly about known defects in software, fixing >>> defects without respects for commercial stakes (ex: hide bug until the >>> xxth release, or not fixing a known bug until it is publicly >>> discovered) > I agree that wine doesn't try to hide defect, but Microsoft is, and > copycatting Microsoft behavior is like being accomplice of its silence > and lack of actions Microsoft's defect, if not already documented, has been revealed by this patch. It's not something they're likely to fix. If they fix it, then a matching fix has to go in Wine at some point (which could be interesting due to different behaviour on different Windows versions). Until they fix the bug and update win32 specifications to match, crashes directly caused by the commit in question are expected and can be assumed to be correct. > Regarding the security part, I am full aware of the facts you stated, > and this is a point that's dooming wine to have less success than It > could have. No, it's dooming Wine to have more success than it should have. Big difference. In implementing win32 API, Wine inherently opens up *nix to a whole new world of malware. Sure, it still needs to be explicitly run by the user, sure there is "wineserver -k" and "rm -rf ~/.wine", but that won't stop spyware, trojans, worms etc. completely. And it shouldn't, because if Wine attempts to stop malware, then legitimate applications will surely suffer too. Not to mention legitimate software that *acts* like malware, e.g. punkbuster :) > You are an intelligent man Ben, I happy to exchange with such a man. Lies, all lies! But thank you nonetheless.

2 2

A step in the wrong direction, in an ocean of steps in the right direction (try 3)
by Guillaume SH 25 Jan '09

25 Jan '09

Hi Dimitry, Thank you very much for bringing this explanation to my knowledge. As you name came over and over through wine-devel list, I am aware that you are an experimented and influential member within wine community (which make a huge difference with me, as this is the first time I try to bring a contribution to wine(1) ), so I will consider this explanation as the way most involved wine people are considering things up. The most interesting part in your answer is indeed this word of "Behaviour" you used. Indeed, in my understanding (but maybe "I am hoping" is more correct here) wine's goal is to provide the same functionalities as Windows API, not to implement those functionalities C statement for C statement with respect to Window's ones. Two reason comes to my mind : 1 - Just copycatting Windows implementation would brought wine very close to plagiarism, thus legally threaten is mere existence 2 - Obviously, Windows implementation is not always the most efficient nor the most secure, due to commercial stakes (release schedule, financial arbitrations...) Regarding the part of your mail where you wrote : "that's actually good that applications crash when they pass invalid data", I must admit I don't understand your point at all. It seems to me a dogma, not the result of some thought or stand back. Don't misunderstand me here, I'm not insulting you neither I'm not saying that I am better than you nor I'm not trying to start a flaming thread. I respect the assertion you stated, but honestly and deeply fail to understand why is it correct. Guillaume (1) Talking openly and honestly about a subject that may be considered a problem is a way of contributing, less concrete than patches, but real too.

5 4

Re: [2/3]: winemenubuilder: generate fd.o MIME and file type associations
by Frank Richter 25 Jan '09

25 Jan '09

On 24.01.2009 12:03, Damjan Jovanovic wrote: > +static char* wchars_to_unix_chars(LPCWSTR string) > +{ > + char *ret; > + INT size = WideCharToMultiByte(CP_UNIXCP, 0, string, -1, NULL, 0, NULL, NULL); Since that is used to write fd.o desktop and mime files: double-check the respective specs, I believe they mandate UTF-8 as the character encoding. UNIXCP isn't necessarily UTF-8. -f.r.

2 1

Updated testing DIB Engine
by Massimo Del Fedele 24 Jan '09

24 Jan '09

I did some update on the engine, I tried to post it here as a zipped patch, but didn't got published.... So I've put it on bug 421 page with instructions on how to use it. I'd like to have some feedback if the implementation way is the right one. Ciao Max

1 0

bugzilla/appdb hung <EOT>
by Dan Kegel 24 Jan '09

24 Jan '09

3 3

re: New Coverity run
by Dan Kegel 24 Jan '09

24 Jan '09

... and here are the new issues since the last run, all of type FORWARD_NULL. If you don't have coverity access, see http://scan.coverity.com/devfaq.html#account for how to get it. 595 CryptDecodeObjectEx dlls/crypt32/decode.c 596 CryptEncodeObjectEx dlls/crypt32/encode.c 549 SLTG_ProcessCoClass dlls/oleaut32/typelib.c 550 SLTG_ProcessDispatch dlls/oleaut32/typelib.c 551 SLTG_ProcessInterface dlls/oleaut32/typelib.c 552 SLTG_ProcessModule dlls/oleaut32/typelib.c 824 SHGetFileInfoW dlls/shell32/shell32_main.c 86 unpack_dde_message dlls/user32/message.c 584 WINSPOOL_GetPrinterDriver dlls/winspool.drv/info.c 825 WINSPOOL_EnumPrinters dlls/winspool.drv/info.c 826 WINSPOOL_EnumPrinters dlls/winspool.drv/info.c 827 WINSPOOL_EnumPrinters dlls/winspool.drv/info.c 828 WINSPOOL_GetDriverInfoFromReg dlls/winspool.drv/info.c 506 TREEVIEW_LButtonDown dlls/comctl32/treeview.c

5 8

Re: msi: Fix NULL dereference in MsiQueryComponentStateW (coverity)
by Paul Vriens 24 Jan '09

24 Jan '09

Nikolay Sivov wrote: > Changelog: > - Fix NULL dereference in MsiQueryComponentStateW, test added > > + r = pMsiQueryComponentStateA(prodcode, NULL, MSIINSTALLCONTEXT_MACHINE, NULL, &state); > + ok(r == ERROR_INVALID_PARAMETER, "Expected ERROR_SUCCESS, got %d\n", r); Copy-paste error in the ok message. -- Cheers, Paul.

2 1

help with coverity spotted problem in region.c::CreatePolyPolygonRgn
by Marcus Meissner 24 Jan '09

24 Jan '09

Hi, Coverity says something about array indices in CreatePolyPolygonRgn and I see some code that looks bad: if (((nbpolygons == 1) && ((*Count == 4) || ((*Count == 5) && (Pts[4].x == Pts[0].x) && (Pts[4].y == Pts[0].y))) && (((Pts[0].y == Pts[1].y) && (Pts[1].x == Pts[2].x) && (Pts[2].y == Pts[3].y) && (Pts[3].x == Pts[0].x)) || ((Pts[0].x == Pts[1].x) && (Pts[1].y == Pts[2].y) && (Pts[2].x == Pts[3].x) && (Pts[3].y == Pts[0].y))))) The braces seems to be mismatched, so that even for *Count==4 it dereferences Pts[4]. But I cannot really make sense of the Count==5 version either, it seems broken too. Pts[4] is compared to Pts[0] points, but then again the 4 point polygon is compared. Anyone? git blame says its from Alexandre in 1998 ... Ciao, Marcus

2 1

Re: mlang: implementation of base functionality ofIMultiLanguage2::ValidateCodePageand IMultiLanguage2::ValidateCodePageEx
by Dmitry Timoshkov 24 Jan '09

24 Jan '09

"Aric Stewart" <aric(a)codeweavers.com> wrote: > @@ -2990,7 +2989,13 @@ static HRESULT WINAPI fnIMultiLanguage2_ValidateCodePageEx( > DWORD dwfIODControl) > { > ICOM_THIS_MULTI(MLang_impl, vtbl_IMultiLanguage3, iface); > - FIXME("%p %u %p %08x: stub!\n", This, uiCodePage, hwnd, dwfIODControl); > + > + TRACE("%p %u %p %08x\n", This, uiCodePage, hwnd, dwfIODControl); > + if (IsValidCodePage(uiCodePage)) > + return S_OK; > + > + if (dwfIODControl != CPIOD_PEEK) > + FIXME("Request to install codepage language pack not handled\n"); > > return S_FALSE; > } IsValidCodePage() covers only kernel32 supported code pages, you probably need to follow what GetCodePageDescription() does and use internal mlang data. -- Dmitry.

1 0

Re: gdiplus: do not call delete_element(NULL)
by Andrew Nguyen 24 Jan '09

24 Jan '09

On Sat, Jan 24, 2009 at 12:42 AM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: > In several cases we call delete_element(x) after x has been set to > NULL or after an unsuccessful clone_element(y, &x) call. clone_element > always gives a NULL element pointer when it fails. > delete_element(NULL) will dereference the NULL and crash. These lines > will never be reached with a non-NULL element. > > Vincent Povirk > > > You have forgotten to attach a patch.

1 0

Re: gdiplus: do not call delete_element(NULL)
by Austin English 24 Jan '09

24 Jan '09

On Sat, Jan 24, 2009 at 12:42 AM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: > In several cases we call delete_element(x) after x has been set to > NULL or after an unsuccessful clone_element(y, &x) call. clone_element > always gives a NULL element pointer when it fails. > delete_element(NULL) will dereference the NULL and crash. These lines > will never be reached with a non-NULL element. > > Vincent Povirk > > > You forgot the patch. -- -Austin

1 0

Anything wrong with this patch?
by Jérôme Gardou 23 Jan '09

23 Jan '09

http://www.winehq.org/pipermail/wine-patches/2009-January/067564.html Any comment on this one? Related to bug 15616.

3 2

wineg++ compile error
by Rino Farina 23 Jan '09

23 Jan '09

Hi All, I'm completely new to wine, and am having trouble compiling code before it ever gets to the linker. Can anyone point me in the right direction? BaseGameEntity.h: #include <string> class BaseGameEntity { private: int m_ID; static int m_iNextValidID; void SetID(int val); public: BaseGameEntity(int id) { SetID(id); } virtual ~BaseGameEntity(){} virtual void Update()=0; virtual bool HandleMessage(const long& msg)=0; int ID()const{return m_ID;} }; BaseGameEntity.cpp: #include "BaseGameEntity.h" #include <cassert> int BaseGameEntity::m_iNextValidID = 0; void BaseGameEntity::SetID(int val) { assert ( (val >= m_iNextValidID) && "<BaseGameEntity::SetID>: invalid ID"); m_ID = val; m_iNextValidID = m_ID + 1; } Console: make all wineg++ -c -mno-cygwin -I. -o BaseGameEntity.o BaseGameEntity.cpp In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cwchar:52, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/postypes.h:47, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/char_traits.h:47, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/string:47, from BaseGameEntity.h:12, from BaseGameEntity.cpp:1: /usr/include/wchar.h:62: error: conflicting declaration 'typedef unsigned int wint_t' /usr/include/wine/msvcrt/stdio.h:109: error: 'wint_t' has a previous declaration as 'typedef short unsigned int wint_t' In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cwchar:52, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/postypes.h:47, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/char_traits.h:47, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/string:47, from BaseGameEntity.h:12, from BaseGameEntity.cpp:1: /usr/include/wchar.h:527: error: expected initializer before '*' token /usr/include/wchar.h:534: error: '__FILE' was not declared in this scope /usr/include/wchar.h:534: error: '__fp' was not declared in this scope /usr/include/wchar.h:534: error: expected primary-expression before 'int' /usr/include/wchar.h:534: error: initializer expression list treated as compound expression /usr/include/wchar.h:534: error: expected ',' or ';' before 'throw' /usr/include/wchar.h:541: error: 'int fwprintf' redeclared as different kind of symbol /usr/include/wine/msvcrt/stdio.h:214: error: previous declaration of 'int fwprintf(FILE*, const wchar_t*, ...)' /usr/include/wchar.h:541: error: '__FILE' was not declared in this scope /usr/include/wchar.h:541: error: expected primary-expression before '__restrict__' /usr/include/wchar.h:542: error: expected primary-expression before 'const' /usr/include/wchar.h:542: error: expected primary-expression before '...' token /usr/include/wchar.h:553: error: declaration of C function 'int swprintf(wchar_t*, size_t, const wchar_t*, ...)' conflicts with /usr/include/wine/msvcrt/stdio.h:223: error: previous declaration 'int swprintf(wchar_t*, const wchar_t*, ...)' here /usr/include/wchar.h:559: error: 'int vfwprintf' redeclared as different kind of symbol /usr/include/wine/msvcrt/stdio.h:226: error: previous declaration of 'int vfwprintf(FILE*, const wchar_t*, char*)' /usr/include/wchar.h:559: error: '__FILE' was not declared in this scope /usr/include/wchar.h:559: error: expected primary-expression before '__restrict__' /usr/include/wchar.h:560: error: expected primary-expression before 'const' /usr/include/wchar.h:561: error: expected primary-expression before '__arg' /usr/include/wchar.h:575: error: declaration of C function 'int vswprintf(wchar_t*, size_t, const wchar_t*, char*)' conflicts with /usr/include/wine/msvcrt/stdio.h:227: error: previous declaration 'int vswprintf(wchar_t*, const wchar_t*, char*)' here /usr/include/wchar.h:582: error: 'int fwscanf' redeclared as different kind of symbol /usr/include/wine/msvcrt/stdio.h:216: error: previous declaration of 'int fwscanf(FILE*, const wchar_t*, ...)' /usr/include/wchar.h:582: error: '__FILE' was not declared in this scope /usr/include/wchar.h:582: error: expected primary-expression before '__restrict__' /usr/include/wchar.h:583: error: expected primary-expression before 'const' /usr/include/wchar.h:583: error: expected primary-expression before '...' token /usr/include/wchar.h:636: error: '__FILE' was not declared in this scope /usr/include/wchar.h:636: error: expected primary-expression before '__restrict__' /usr/include/wchar.h:637: error: expected primary-expression before 'const' /usr/include/wchar.h:638: error: expected primary-expression before '__arg' /usr/include/wchar.h:638: error: initializer expression list treated as compound expression /usr/include/wchar.h:692: error: 'wint_t fgetwc' redeclared as different kind of symbol /usr/include/wine/msvcrt/stdio.h:210: error: previous declaration of 'wint_t fgetwc(FILE*)' /usr/include/wchar.h:692: error: '__FILE' was not declared in this scope /usr/include/wchar.h:692: error: '__stream' was not declared in this scope /usr/include/wchar.h:693: error: 'wint_t getwc' redeclared as different kind of symbol /usr/include/wine/msvcrt/stdio.h:217: error: previous declaration of 'wint_t getwc(FILE*)' /usr/include/wchar.h:693: error: '__FILE' was not declared in this scope /usr/include/wchar.h:693: error: '__stream' was not declared in this scope /usr/include/wchar.h:706: error: '__FILE' has not been declared /usr/include/wchar.h:706: error: declaration of C function 'wint_t fputwc(wchar_t, int*)' conflicts with /usr/include/wine/msvcrt/stdio.h:212: error: previous declaration 'wint_t fputwc(wint_t, FILE*)' here /usr/include/wchar.h:707: error: '__FILE' has not been declared /usr/include/wchar.h:707: error: declaration of C function 'wint_t putwc(wchar_t, int*)' conflicts with /usr/include/wine/msvcrt/stdio.h:220: error: previous declaration 'wint_t putwc(wint_t, FILE*)' here /usr/include/wchar.h:713: error: declaration of C function 'wint_t putwchar(wchar_t)' conflicts with /usr/include/wine/msvcrt/stdio.h:221: error: previous declaration 'wint_t putwchar(wint_t)' here /usr/include/wchar.h:722: error: '__FILE' has not been declared /usr/include/wchar.h:722: error: declaration of C function 'wchar_t* fgetws(wchar_t*, int, int*)' conflicts with /usr/include/wine/msvcrt/stdio.h:211: error: previous declaration 'wchar_t* fgetws(wchar_t*, int, FILE*)' here /usr/include/wchar.h:729: error: '__FILE' has not been declared /usr/include/wchar.h:729: error: declaration of C function 'int fputws(const wchar_t*, int*)' conflicts with /usr/include/wine/msvcrt/stdio.h:215: error: previous declaration 'int fputws(const wchar_t*, FILE*)' here /usr/include/wchar.h:736: error: '__FILE' has not been declared /usr/include/wchar.h:736: error: declaration of C function 'wint_t ungetwc(wint_t, int*)' conflicts with /usr/include/wine/msvcrt/stdio.h:225: error: previous declaration 'wint_t ungetwc(wint_t, FILE*)' here /usr/include/wchar.h:748: error: '__FILE' was not declared in this scope /usr/include/wchar.h:748: error: '__stream' was not declared in this scope /usr/include/wchar.h:757: error: '__FILE' was not declared in this scope /usr/include/wchar.h:757: error: '__stream' was not declared in this scope /usr/include/wchar.h:765: error: '__FILE' has not been declared /usr/include/wchar.h:774: error: '__FILE' has not been declared /usr/include/wchar.h:785: error: '__FILE' has not been declared /usr/include/wchar.h:794: error: '__FILE' has not been declared In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cstdio:50, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/char_traits.h:48, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/string:47, from BaseGameEntity.h:12, from BaseGameEntity.cpp:1: /usr/include/stdio.h:49: error: conflicting declaration 'typedef struct _IO_FILE FILE' /usr/include/wine/msvcrt/stdio.h:84: error: 'FILE' has a previous declaration as 'typedef struct _iobuf FILE' In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/char_traits.h:48, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/string:47, from BaseGameEntity.h:12, from BaseGameEntity.cpp:1: /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cstdio:170: error: '::snprintf' has not been declared /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cstdio:171: error: '::vfscanf' has not been declared /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cstdio:172: error: '::vscanf' has not been declared /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cstdio:174: error: '::vsscanf' has not been declared /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cstdio:181: error: '__gnu_cxx::snprintf' has not been declared /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cstdio:182: error: '__gnu_cxx::vfscanf' has not been declared /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cstdio:183: error: '__gnu_cxx::vscanf' has not been declared /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cstdio:185: error: '__gnu_cxx::vsscanf' has not been declared In file included from /usr/include/_G_config.h:20, from /usr/include/libio.h:32, from /usr/include/stdio.h:75, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cstdio:50, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/ios_base.h:49, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ios:48, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ostream:45, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/iostream:45, from /home/rino/Download/Buckland_AISource_070308/EclipseProjects/Common/Messaging/Telegram.h:14, from BaseGameEntity.h:14, from BaseGameEntity.cpp:1: /usr/include/wine/msvcrt/wchar.h:62: error: conflicting declaration 'typedef int mbstate_t' /usr/include/wchar.h:101: error: 'mbstate_t' has a previous declaration as 'typedef struct __mbstate_t mbstate_t' /usr/include/wine/msvcrt/wchar.h:412: error: declaration of C function 'wchar_t* wcstok(wchar_t*, const wchar_t*)' conflicts with /usr/include/wchar.h:246: error: previous declaration 'wchar_t* wcstok(wchar_t*, const wchar_t*, wchar_t**)' here /usr/include/wine/msvcrt/wchar.h:425: error: declaration of C function 'wchar_t btowc(int)' conflicts with /usr/include/wchar.h:300: error: previous declaration 'wint_t btowc(int)' here In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cstdio:50, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/ios_base.h:49, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ios:48, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ostream:45, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/iostream:45, from /home/rino/Download/Buckland_AISource_070308/EclipseProjects/Common/Messaging/Telegram.h:14, from BaseGameEntity.h:14, from BaseGameEntity.cpp:1: /usr/include/stdio.h:91: error: conflicting declaration 'typedef struct _G_fpos_t fpos_t' /usr/include/wine/msvcrt/stdio.h:88: error: 'fpos_t' has a previous declaration as 'typedef long long int fpos_t' In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cstdio:50, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/ios_base.h:49, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ios:48, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ostream:45, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/iostream:45, from /home/rino/Download/Buckland_AISource_070308/EclipseProjects/Common/Messaging/Telegram.h:14, from BaseGameEntity.h:14, from BaseGameEntity.cpp:1: /usr/include/stdio.h:145: error: expected `)' before '+' token /usr/include/stdio.h:145: error: expected initializer before '+' token /usr/include/stdio.h:146: error: expected `)' before '+' token /usr/include/stdio.h:146: error: expected initializer before '+' token /usr/include/stdio.h:147: error: expected `)' before '+' token /usr/include/stdio.h:147: error: expected initializer before '+' token /usr/include/wine/msvcrt/stdio.h:246: error: previous declaration of 'char* tempnam(const char*, const char*)' with 'C++' linkage /usr/include/stdio.h:207: error: conflicts with new declaration with 'C' linkage /usr/include/wine/msvcrt/stdio.h:240: error: previous declaration of 'FILE* fdopen(int, const char*)' with 'C++' linkage /usr/include/stdio.h:285: error: conflicts with new declaration with 'C' linkage /usr/include/wine/msvcrt/stdio.h:251: error: previous declaration of 'int vsnprintf(char*, size_t, const char*, char*)' with 'C++' linkage /usr/include/stdio.h:369: error: conflicts with new declaration with 'C' linkage /usr/include/wine/msvcrt/stdio.h:255: error: previous declaration of 'int getw(FILE*)' with 'C++' linkage /usr/include/stdio.h:590: error: conflicts with new declaration with 'C' linkage /usr/include/wine/msvcrt/stdio.h:256: error: previous declaration of 'int putw(int, FILE*)' with 'C++' linkage /usr/include/stdio.h:593: error: conflicts with new declaration with 'C' linkage /usr/include/stdio.h:774: error: declaration of C function 'int fsetpos(FILE*, const fpos_t*)' conflicts with /usr/include/wine/msvcrt/stdio.h:166: error: previous declaration 'int fsetpos(FILE*, fpos_t*)' here In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cstdio:50, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/ios_base.h:49, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ios:48, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ostream:45, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/iostream:45, from /home/rino/Download/Buckland_AISource_070308/EclipseProjects/Common/Messaging/Telegram.h:14, from BaseGameEntity.h:14, from BaseGameEntity.cpp:1: /usr/include/wine/msvcrt/stdio.h:242: error: previous declaration of 'int fileno(FILE*)' with 'C++' linkage /usr/include/stdio.h:829: error: conflicts with new declaration with 'C' linkage /usr/include/wine/msvcrt/stdio.h:245: error: previous declaration of 'FILE* popen(const char*, const char*)' with 'C++' linkage /usr/include/stdio.h:844: error: conflicts with new declaration with 'C' linkage /usr/include/wine/msvcrt/stdio.h:244: error: previous declaration of 'int pclose(FILE*)' with 'C++' linkage /usr/include/stdio.h:850: error: conflicts with new declaration with 'C' linkage In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cwctype:51, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/locale_facets.h:46, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/basic_ios.h:44, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ios:50, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ostream:45, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/iostream:45, from /home/rino/Download/Buckland_AISource_070308/EclipseProjects/Common/Messaging/Telegram.h:14, from BaseGameEntity.h:14, from BaseGameEntity.cpp:1: /usr/include/wctype.h:53: error: conflicting declaration 'typedef long unsigned int wctype_t' /usr/include/wine/msvcrt/stdio.h:110: error: 'wctype_t' has a previous declaration as 'typedef short unsigned int wctype_t' /usr/include/wctype.h:195: error: declaration of C function 'wint_t towlower(wint_t)' conflicts with /usr/include/wine/msvcrt/wchar.h:255: error: previous declaration 'wchar_t towlower(wchar_t)' here /usr/include/wctype.h:198: error: declaration of C function 'wint_t towupper(wint_t)' conflicts with /usr/include/wine/msvcrt/wchar.h:256: error: previous declaration 'wchar_t towupper(wchar_t)' here winegcc: g++ failed make: *** [BaseGameEntity.o] Error 2

5 8

Re: server(1/3): Use kernel support for process affinity when available
by Alexandre Julliard 23 Jan '09

23 Jan '09

Juan Lang <juan.lang(a)gmail.com> writes: > +static void get_process_affinity( struct process *process ) > +{ > + affinity_t affinity = ~0; > + > +#ifdef HAVE_SCHED_H > + if (process->unix_pid != -1) > + { > + cpu_set_t set; > + > + CPU_ZERO( &set ); > + if (!sched_getaffinity( process->unix_pid, sizeof(set), &set )) You should add a configure check for sched_getaffinity, having sched.h is not enough. > @@ -403,6 +432,7 @@ data_size_t init_process( struct thread *thread ) > struct process *process = thread->process; > struct startup_info *info = process->startup_info; > > + get_process_affinity( process ); You should retrieve it as needed. Most apps don't have any need for that information so we don't want to incur the cost of fetching it for every started process. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [user32] Allocate buffer on heap (Bug 17076)
by Jeff Latimer 23 Jan '09

23 Jan '09

Paul Vriens wrote: > > > Some called functions assume that buffer is always on heap. That isn't > the case > anymore. If you do + local_buffer = HeapAlloc(GetProcessHeap(), 0, buffer_size); shouldn't there be a HeapFree() added to match? Jeff

2 1

AppDB: Rating / Patching
by Joerg-Cyril.Hoehle＠t-systems.com 23 Jan '09

23 Jan '09

Hi, here are, from an obvious user perspective, my 0.02$ on the issue. - Platinum: app works "out of the box" -- without changing any settings -- *and* as well as on MS-Windows. That means no feature is missing: music plays, graphics look similar on both plattforms, the perceived speed or responsiveness is similar, ... (Question: does the need to install thrid party SW like codecs or Quicktime preclude "platinum" because it's not "out of the box"?) For anything below platinum, I don't want AppDB to ask users to compare with MS-Windows. Users either don't care about MS-Windows or don't have the time to perform a dual installation or don't even have a MS-Windows machine! Yet to gain platinum rating, I concede that the additional effort to test the application's behaviour on MS-Windows is valuable to detect discrepancies between the two ("hey, I didn't know before that the application would play background music!"). - Garbage: nobody knows how to make this app work with that version of wine. Don't buy it, you are likely wasting your time & money. Anything else gets a rating above garbage, no matter how ugly the fix or patch is. What counts is that there's a known way to make it work. - Bronze: the application shows a "promise" that some additional fixes and patches may make it work well. I'm opposed to the idea that a given AppDB version should only denote an unpatched wine in test results. Consider how Dan Kegel recently recommended distributors not to distribute 1.1.12. E.g. a hypothetical future Ubuntu package "1.1.12" may contain the official 1.1.12 plus the three patches that Dan Kegel recommends. Users would likely not know nor notice. Typically, distributors add whatever patches they feel right to the upstream releases. So it does not seem practical to have the need for a patch prevent ratings above garbage (or bronze), as some people suggested here. To me, 1.1.12 plus N patches (N "small") is still 1.1.12 as far as the AppDB is concerned. However N>0 might preclude platinum, as defined above (except for Ubuntu users). Similarly, AppDB might prevent Gold or Silver ratings depending on qualitative aspects of the steps needed to make an app work: - need for known distributable third party libraries (e.g. codecs, Quicktime) (not provided with the application's installer) - complexity of settings (winecfg vs. *.reg vs. environment variable vs. ...) - nocd or not copy-protected executables - patch to source, requiring compilation of wine E.g. Recompilation would prevent Gold? Would you agree that any application in need of a nocd would necessarily rate one level below another one not "equipped" with copy protection? Or does only the result count, and e.g. "Gold" is perfectly describing an application that works flawlessly "out of the box", except you need to replace the .exe with the nocd one between install and run? (So far I have handled it like this, a patch is not enough reason to drop a rating to garbage, this does not effectively describe the user experience.) Regards, Jörg Höhle

6 11

Running a simple .Net 3.0 application.
by Louis Lenders 23 Jan '09

23 Jan '09

I saw some good progress is being made on getting the .net 3.0 installer fixed in wine. Nice. As it will take yet quite some time until the installer is fixed, i wondered if wine is in good shape to run .net 3.0 apps, once the installer is finished. Today I saw someone mentioning a program called InstallRite on the users-list, and using this program, I was able to get a a simple .Net 3.0 app running in wine. I thought just share my experience here, in case anyone finds it useful. The application i got running is very simple: AnimatedApplication from http://www.longhorncorner.com/UploadFile/rahul4_saxena/AnAnimatedApplicatio… (You just need register, then you can download the file) This way I got it running: 1. Fire up Windows Xp (a snapshot from a clean install) in my VirtualBox 2. Install Installrite from http://www.epsilonsquared.com/ in VirtualBox. 3. Start InstallRite, and from within InstallRite you can fire up the dotnetfx3.exe (after downloaded it) 4. After the dotnetfx3.exe finshed the install, there's an option, that you can make a "Build Install Kit". I did that, it creates an executable (foo.exe). Save it in a place where you can access it from linux 5. In wine, first do 'winetricks dotnet20' (needed for l_int.nls i guess, otherwise I got crash very early in the app) 6. Run foo.exe in wine, it will extract all files, and write all registry-keys, as if it were a successfull dotnetfx3 installation in wine. 7. Now Run the app, it crashes into a bunch of unimplemented functions. Fortunately just simple stubs were enough to make the app happy. I added stubs for gdi32.GdiEntry13 kernel32.WerRegisterMemoryBlock ntdll.NtSecureConnectPort ntdll.RtlEnumerateGenericTableWithoutSplaying ntdll.RtlIsGenericTableEmpty Well, that was enough to get the app running. I was not able to work around a problem in d3d9 ( the app just hang, displaying nothing, probably due to some unimplemented stuff in d3d9) but fortunaly disabling d3d9, was enough to get it running (WINEDLLOVERRIDES="d3d9=""" wine AnimatedApplication.exe) I'm not sure if it would be useful to open bugs already for the unimplemented functions. If so, just shout, and i'll open some bugs. Conclusion: once the installer is fixed, there's good chance simple .net 3.0 at least apps will run quickly

3 2

Re: Problems with configure on Mac
by James McKenzie 23 Jan '09

23 Jan '09

James Mckenzie wrote: > Cesar Izurieta <cesar(a)ecuarock.net> wrote: > >> Sent: Jan 21, 2009 7:49 AM >> To: James Mckenzie <jjmckenzie51(a)earthlink.net> >> Cc: Wine Development Mailing List <wine-devel(a)winehq.org> >> Subject: Re: Problems with configure on Mac >> >> Try something like: >> >> LDFLAGS="-L/opt/local/lib" CPPFLAGS="-I/opt/local/include/" ./configure >> >> You need to specify both the library dirs and the include dirs. This is >> using macports. For fink I guess the libraries are located somewhere under >> /sw IIRC. >> > > I'll find them and use them this evening after reviewing the log file. > > Used the proper directories for Fink and built it after addressing a few more 'missing dependencies'. However when I run wine notepad, I get a lengthy error. The thread on gdi32.dll errors addresses some of this. However, the .wine directory gets created but it is partially empty which leads me to believe there is a problem with my build as yours works. One question: What version of gcc are you using to build Wine? Thank you. James McKenzie

1 0

LWN Timeline for 2008: Wine 1.0 made it!
by Zachary Goldberg 23 Jan '09

23 Jan '09

All, It seems Wine 1.0 was deemed a significant event for Linux and Free Software in 2008. http://lwn.net/Articles/Timeline2008/ Cool beans. -Zach

9 10

cmd.exe.manifest
by Luke Kenneth Casson Leighton 22 Jan '09

22 Jan '09

0010:trace:file:RtlGetFullPathName_U (L"C:\\windows\\system32\\cmd.exe.manifest" 520 0xff9aaaf4 (nil)) attr=00000000 sharing=00000001 disp=1 options=00000010 ea=(nil).0x00000000 0009:trace:seh:start_debugger Starting debugger "winedbg --auto 8 100" ????? !!!! ahh fer xxxx's sake :) this is after various complicated ways to create a subprocess with which to communicate (stdin / stdout) involving CreatePipe, open_osfhandle, - but it's being done from an app that's compiled with msvcr80. 0009: close_handle() = 0 0010:trace:heap:RtlAllocateHeap (0x110000,00000002,00000038): returning 0x114e58 0010:trace:actctx:get_manifest_in_module looking for res #0001 in module 0x7ec10000 L"C:\\windows\\system32\\cmd.exe" 0010:trace:heap:RtlFreeHeap (0x110000,00000002,0x114e58): returning TRUE 0010:trace:resource:LdrFindResource_U module 0x7ec10000 type #0018 name #0001 lang 0000 level 3 0010:trace:resource:find_entry_by_id root 0x7ec322e4 dir 0x7ec322e4 id 0018 not found 0010:trace:actctx:get_manifest_in_associated_manifest looking for manifest associated with (null) id 1 0010:trace:heap:RtlAllocateHeap (0x110000,00000002,00000060): returning 0x114e58 0009:trace:heap:RtlFreeHeap (0x110000,00000002,0x1361e0): returning TRUE 0010:trace:file:RtlDosPathNameToNtPathName_U (L"C:\\windows\\system32\\cmd.exe.manifest",0xffdc6170,(nil),(nil)) 0009:trace:process:CreateProcessW started process pid 000f tid 0010 0010:trace:file:RtlGetFullPathName_U (L"C:\\windows\\system32\\cmd.exe.manifest" 520 0xffdc5f14 (nil)) ... but hang on... some notes somewhere after a google search for cmd.exe.manifest, apparently there isn't supposed to _be_ a manifest for cmd.exe - so that it can't be "themed". ... wossgoinon?! :) l.

2 5

Re: msxml3/tests:domdoc.c Test doc pointer before using it (coverity)
by Austin English 22 Jan '09

22 Jan '09

On Thu, Jan 22, 2009 at 6:50 AM, Joris Huizer <joris_huizer(a)yahoo.com> wrote: > >From: Joris Huizer <jorishuizer(a)debian.(none)> Your e-mail is messed up in the patches. Alexandre's scripts take the patch info over the e-mail headers, so you should fix that. -- -Austin

2 1

Re: warning in wldap32/parse.c:447
by Michael Stefaniuc 22 Jan '09

22 Jan '09

Hi! Nikolay Sivov wrote: > Hi, your patch for wldap32 added a warning: I know and I sent a patch to revert that change: http://www.winehq.org/pipermail/wine-patches/2009-January/067780.html and Alexandre rejected it: http://www.winehq.org/pipermail/wine-devel/2009-January/072151.html He is right and wrong in that email: - Right: wldap32 is broken for Win64 Wine builds - Wrong: I didn't do the long to LONG wldap32 changes but Francois. > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ > -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits > -Wpointer-arith -g -O2 -o parse.o parse.c > parse.c: In function ‘ldap_parse_vlv_controlW’: > parse.c:447: warning: passing argument 5 of ‘ldap_parse_vlv_control’ > from incompatible pointer type The warning is a minor nuisance but not an error. And that code isn't used with never openldap versions so not many people see it. That's why I didn't catch it first hand as there is no warning on F9 and F10. bye michael

1 0

Re: WMF Support
by Rolf Kalbermatter 22 Jan '09

22 Jan '09

Erich Hoover wrote: >I ran into an issue with WMF files in helping someone get an application to >work (Athena Visual Studio) and I worked around it by pre-rendering the >application's vector WMF files. I don't currently have the time to resolve >the issue, but for when I do I'm curious whether there is a reason that >OleLoadPicture* has been implemented manually. It seems that the LGPL >"libwmf" has excellent support for both bitmap and vector WMF files (it at >least worked for converting the files I had trouble with!), so it seems to >me like it would make sense to use this library rather than spinning a >separate implementation. Any comments are appreciated. Do you have somewhere the specific WMF file in question? The license is a "bit" to expensive to buy it just to test this ;-) Rolf Kalbermatter

2 1

Re: [5/6] ddraw: Rename the main vtables to just "vtbl".
by Alexandre Julliard 22 Jan '09

22 Jan '09

Henri Verbeet <hverbeet(a)codeweavers.com> writes: >>From ba79c111cb9a6de4d65d9e2cb9d77ef836802bc4 Mon Sep 17 00:00:00 2001 > From: Henri Verbeet <hverbeet(a)codeweavers.com> > Date: Thu, 22 Jan 2009 10:33:37 +0100 > Subject: ddraw: Rename the main vtables to just "vtbl". I hate to suggest adding Hungarian notation noise, but "lpVtbl" may be a better choice since that's the standard name in all COM macros and generated code. It would make it more obvious that this is the regular main vtable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msxml3: Implement IXMLDOMDocument2 IPersistStream_Save
by Nikolay Sivov 22 Jan '09

22 Jan '09

Alistair Leslie-Hughes wrote: > Hi, > Helps http://bugs.winehq.org/show_bug.cgi?id=9012 > > > Changelog: > msxml3: Implement IXMLDOMDocument2 IPersistStream_Save > > Best Regards > Alistair Leslie-Hughes > > > > > > No patch here.

1 0

Only 28 more uninspected coverity warnings left!
by Dan Kegel 22 Jan '09

22 Jan '09

Hey, looks like our Coverity elves have been busy; there are only 28 more coverity warnings left to be evaluated. Maybe if we finish triaging all the warnings, they'll get motivated to scan us more often... For more info, see http://scan.coverity.com Here are the error types, files, and functions as of Oct 27th (they haven't done a run since then): FORWARD_NULL dlls/comdlg32/filedlg16.c FileOpenDlgProc16 dlls/comdlg32/filedlg16.c FileSaveDlgProc16 dlls/dbghelp/dwarf.c dwarf2_read_one_debug_info dlls/dbghelp/module.c SymLoadModuleExW dlls/dbghelp/msc.c codeview_process_info dlls/dbghelp/source.c source_new dlls/dmime/segtriggertrack.c IDirectMusicSegTriggerTrack_IPersistStream_ParseSegment dlls/dmloader/container.c IDirectMusicContainerImpl_IDirectMusicContainer_EnumObject dlls/dmstyle/style.c IDirectMusicStyle8Impl_IPersistStream_ParsePartRefList dlls/dsound/tests/ds3d.c test_secondary dlls/msxml3/tests/domdoc.c test_domnode dlls/oleaut32/typelib.c SLTG_ProcessAlias dlls/quartz/filtermapper.c FM2_ReadFilterData dlls/shell32/shlexec.c SHELL_ArgifyW dlls/user32/dde_misc.c WDML_RemoveAllLinks dlls/user32/dde_misc.c WDML_RemoveConv dlls/user32/dde_misc.c WDML_RemoveServer dlls/user32/edit.c EDIT_EM_ReplaceSel dlls/winex11.drv/bitblt.c BITBLT_InternalStretchBlt dlls/winex11.drv/palette.c X11DRV_PALETTE_ToPhysical dlls/winmm/mmsystem.c mmioOpen16 programs/winedbg/gdbproxy.c packet_write_register programs/winedbg/gdbproxy.c packet_write_registers programs/winedbg/symbol.c fill_sym_lvalue programs/winhlp32/winhelp.c WINHELP_GetWindowInfo RESOURCE_LEAK tools/wrc/readres.c read_res32 REVERSE_INULL dlls/msxml3/tests/domdoc.c test_domnode dlls/uxtheme/draw.c get_image_part_size

1 0

Ole32: le32toh/le16toh conflict in storage32.h's endian macros
by Austin English 22 Jan '09

22 Jan '09

In file included from storage32.c:50: storage32.h:406:1: warning: "le32toh" redefined In file included from /usr/include/machine/endian.h:3, from /usr/include/sys/types.h:98, from /usr/include/stdlib.h:41, from storage32.c:36: /usr/include/sys/endian.h:178:1: warning: this is the location of the previous definition There are a four of these warnings. Apparently Wine defines these in storage32.h: /********************************************************* * Endian conversion macros */ #ifdef WORDS_BIGENDIAN #define htole32(x) RtlUlongByteSwap(x) #define htole16(x) RtlUshortByteSwap(x) #define le32toh(x) RtlUlongByteSwap(x) #define le16toh(x) RtlUshortByteSwap(x) #else #define htole32(x) (x) #define htole16(x) (x) #define le32toh(x) (x) #define le16toh(x) (x) #endif And on NetBSD: #if BYTE_ORDER == BIG_ENDIAN #define htole16(x) bswap16((uint16_t)(x)) #define htole32(x) bswap32((uint32_t)(x)) #define htole64(x) bswap64((uint64_t)(x)) ... #define HTOLE16(x) (x) = bswap16((uint16_t)(x)) #define HTOLE32(x) (x) = bswap32((uint32_t)(x)) #define HTOLE64(x) (x) = bswap64((uint64_t)(x)) ... #else /* LITTLE_ENDIAN */ ... #define htole16(x) (x) #define htole32(x) (x) #define htole64(x) (x) ... #define HTOLE16(x) (void) (x) #define HTOLE32(x) (void) (x) #define HTOLE64(x) (void) (x) I started to send a patch to #ifdef,#undef, but I'm not sure that's right...which definition should we be using here, NetBSD's or Wine's? Furthermore, do we need to add le64toh/htole64? -- -Austin

2 1

Debian packages of Wine
by Ben Klein 22 Jan '09

22 Jan '09

Hi Maurilio, I see you've taken over building Lenny packages of Wine. Good work; at least now there are *some* updated packages available. I talked to Scott a while ago about taking over from him for all Debian package building. I have an automated build environment that builds packages for all variations from etch/i386 to sid/amd64 (even the very annoying-to-bulid-Wine-for etch/amd64). The one thing that was stopping me from fully taking over from Scott was I don't have the resources to host the packages. So I'm wondering the following: 1) Do you think it's worth supporting Etch? (I argue yes, because it's still stable) 2) Are you interested in hosting my Etch and Sid packages? 3) I'm clueless as to how to correctly set up a repository, so all I have at the moment are the raw packages. Would you or Scott be able to help out with this? Thanks, Ben

3 8

Re: Problems with configure on Mac
by James Mckenzie 21 Jan '09

21 Jan '09

Cesar Izurieta <cesar(a)ecuarock.net> wrote: >Sent: Jan 21, 2009 7:49 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Wine Development Mailing List <wine-devel(a)winehq.org> >Subject: Re: Problems with configure on Mac > >Try something like: > >LDFLAGS="-L/opt/local/lib" CPPFLAGS="-I/opt/local/include/" ./configure > >You need to specify both the library dirs and the include dirs. This is >using macports. For fink I guess the libraries are located somewhere under >/sw IIRC. I'll find them and use them this evening after reviewing the log file. James McKenzie

1 0

Dead code in winedbg
by Francois Gouget 21 Jan '09

21 Jan '09

Hi, I have noticed that expr_alloc_uconstant() is unused in winedbg. Is that normal? It causes all of the code in the attached patch to essentially be dead code since expr.type is never set to EXPR_TYPE_U_CONST. Should we just remove all that code? Just the expr_alloc_uconstant() function? Or is this unused just because of a bug? Or maybe it will be used 'soon'? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

3 3

RE: [4/5] ddraw: Get rid of ICOM_INTERFACE.
by Stefan Dösinger 21 Jan '09

21 Jan '09

> -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Henri Verbeet > Sent: Wednesday, January 21, 2009 10:01 AM > To: wine-patches(a)winehq.org > Subject: [4/5] ddraw: Get rid of ICOM_INTERFACE. > > - *obj = ICOM_INTERFACE(This, IDirect3DDevice3); > + *obj = &This->IDirect3DDevice3_vtbl; > - *obj = ICOM_INTERFACE(This, IDirect3DDevice7); > + *obj = This; > - return IDirect3DDevice7_AddRef(ICOM_INTERFACE(This, IDirect3DDevice7)); > + return IDirect3DDevice7_AddRef((IDirect3DDevice7 *)This); I think it would be better to access IDirect3DDevice7 via explicit specifying the vtable, or an inline function for consistency and to avoid hardwiring the assumption that the IDirect3DDevice7 vtable is the first member of the object

3 5

Re: rpcrt4: Add a stub implementation of NdrGetUserMarshalInfo.
by Rob Shearman 21 Jan '09

21 Jan '09

2009/1/21 Hans Leidekker <hans(a)codeweavers.com>: > > diff --git a/dlls/rpcrt4/rpcrt4.spec b/dlls/rpcrt4/rpcrt4.spec > index 2c86e68..56a55f6 100644 > --- a/dlls/rpcrt4/rpcrt4.spec > +++ b/dlls/rpcrt4/rpcrt4.spec > @@ -203,7 +203,7 @@ > @ stub NdrGetSimpleTypeBufferSize # wxp > @ stub NdrGetSimpleTypeMemorySize # wxp > @ stub NdrGetTypeFlags # wxp > -@ stub NdrGetUserMarshallInfo > +@ stdcall NdrGetUserMarshalInfo(ptr long ptr) > @ stub NdrHardStructBufferSize #(ptr ptr ptr) > @ stub NdrHardStructFree #(ptr ptr ptr) > @ stub NdrHardStructMarshall #(ptr ptr ptr) > diff --git a/dlls/rpcrt4/rpcrt4_main.c b/dlls/rpcrt4/rpcrt4_main.c > index 537a005..1a6b61d 100644 > --- a/dlls/rpcrt4/rpcrt4_main.c > +++ b/dlls/rpcrt4/rpcrt4_main.c > @@ -1016,3 +1016,9 @@ RPC_STATUS RPC_ENTRY RpcCancelThreadEx(void* ThreadHandle, LONG Timeout) > else > return rpc_cancel_thread(target_tid); > } > + > +RPC_STATUS RPC_ENTRY NdrGetUserMarshalInfo(ULONG *flags, ULONG level, NDR_USER_MARSHAL_INFO *mi) > +{ > + FIXME("(%p, %u, %p)\n", flags, level, mi); > + return RPC_X_INVALID_BUFFER; > +} Since this function has the prefix Ndr it should go in an ndr_*.c file in rpcrt4, not one of the others (I would suggest ndr_marshall.c next to the user marshal functions, which initialise the data structure that it operates on). It also lacking a winapi comment. -- Rob Shearman

1 0

Problems with configure on Mac
by James Mckenzie 21 Jan '09

21 Jan '09

All: When I run the configure script for 1.1.13 on my Mac, at the end it states that the jpeg and png development libraries could not be found and thus support for these two file types will not be incorporated. I checked my system and the libraries are there and I added symlinks to /usr/lib from the Fink installation directories. What do I need to do in order to get this to work? Also I noticed that a program called conftest is called using otool. How do I disable the deletion of this program so that I can manually run this program? If that is not possible, how do I build this program? Reading through the configure script is a little difficult, but not impossible.... James McKenzie

2 1

Re: Adjust dlls/iphlpapi/ipstats.c to FreeBSD 8
by Francois Gouget 21 Jan '09

21 Jan '09

On Thu, 1 Jan 2009, Gerald Pfeifer wrote: [...] > ChangeLog: > Only use RTF_LLINFO if #defined, fixing FreeBSD 8 after the arp-v2 > rewrite. [...] > #if defined(HAVE_SYS_SYSCTL_H) && defined(NET_RT_DUMP) > - int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO}; > + int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, > +#ifdef RTF_LLINFO > + RTF_LLINFO > +#else > + 0 > +#endif > + }; Is there a way to do it so the same binary can run and work on FreeBSD 7.x and 8.0? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

3 3

Does this D-Bus change affect us? (Fwd: New D-Bus Uploaded)
by Scott Ritchie 21 Jan '09

21 Jan '09

This email was just sent to the Ubuntu developer list about a change to D-Bus security in 9.04 -- do I need to create a D-Bus .conf file for Wine, or will the default policy suffice for us? Thanks, Scott Ritchie Scott James Remnant wrote: > If your package contains a D-Bus system bus service, you need to pay > attention! > > It was discovered that the default policy of the D-Bus system bus was > not as was expected, due to a quirk of the language. In fact, whereas > the default policy was supposed to have been that messages would not be > allowed by default, the default was in fact that messages _were_ > allowed! > > CVE-2008-4311 was issued, and a new release of D-Bus was updated to > correct the default policy to be deny-by-default. > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4311 > > It was quickly discovered that the policy files shipped by most services > no longer worked, and that many were (inadvertently, perhaps) relying on > the misconfiguration of the daemon. > > > We've audited the system bus services shipped in Ubuntu, and are > confident that there is no security exploit. Those services exporting > privileged methods either have sufficient "deny" rules, or use PolicyKit > for authorisation. > > For this reason, and due to the large potential for regressions, we've > opted not to release a security update for previous Ubuntu versions. We > may still do so if we discover a potential for exploit. > > > However this is a bug, and I've uploaded a new version of D-Bus to > jaunty that corrects it. I've filed bugs on all packages that appear to > ship a D-Bus system bus service (those with /etc/dbus-1/system.d/*.conf > files), but I may have missed some. I'd appreciate your help tracking > down any I've missed, and updating all of the packages. > > Please read the following carefully to assist with updating the > configuration. > > > The default policy of the D-Bus system bus is: > > - Name ownership is DENIED by default. > > - Method calls are DENIED by default. > > - Replies to method calls, including errors, are PERMITTED by default. > > - Signals are PERMITTED by default. > > > Therefore each service MUST, in its policy configuration: > > - Permit an appropriate user to own the name it wishes to claim: > > <policy user="example"> > <allow own="com.ubuntu.Example" /> > </policy> > > - Allow method calls to be made on objects it exports, for particular > users. This may be done in a number of different ways. > > You may simply allow all method calls to your claimed name: > > <policy context="default"> > <allow send_destination="com.ubuntu.example" /> > </policy> > > You may allow method calls to particular interfaces you export, > especially useful if you have privileged and non-privileged > interfaces: > > <policy context="default"> > <allow send_destination="com.ubuntu.example" > send_interface="com.ubuntu.Example" /> > </policy> > > <policy user="root"> > <allow send_destination="com.ubuntu.example" > send_interface="com.ubuntu.Example.System" /> > </policy> > > *IMPORTANT* you MUST include send_destination on ALL allow or deny > tags. Omitting it is a SERIOUS bug! > >  > <allow send_interface="x.y.z" /> > > This allows any service to receive method calls of the given > interface, not just your own service! > > It also implicitly allows any service to receive method calls > with no interface specified, in case they match this interface! > > Using the above means you are potentially allowing exploiting of > a different service. DO NOT DO IT! > >  > <deny send_interface="x.y.z" /> > > This denies all services from receiving method calls of the > given interface, not just your own service! It also implicitly > denies all services from receiving method calls with no > interface specified. DO NOT DO IT! > > - You must allow standard interfaces as well, such as Introspection and > Properties: > > <policy context="default"> > <allow send_destination="com.ubuntu.example" > send_interface="org.freedesktop.DBus.Introspectable" /> > <allow send_destination="com.ubuntu.example" > send_interface="org.freedesktop.DBus.Properties" /> > </policy> > > > - You should not normally allow receipt of any messages sent from your > interface, this is also the default. > > (ie. remove any lines of the form <allow receive_*>) > > > - You do not normally need to deny any messages, this is the default. > > (ie. remove any lines of the form <deny...>) > > > You should fully test the service with the new D-Bus after updating the > policy, you'll need to restart the bus daemon for that (it's probably > easier to reboot). > > If messages are being denied, it will be logged in /var/log/auth.log as > follows: > > Dec 19 14:17:53 space-ghost dbus: Rejected send message, 1 matched > rules; type="method_return", sender=":1.26" (uid=0 pid=2966 > comm="/usr/libexec/nm-dispatcher.action ") interface="(unset)" > member="(unset)" error name="(unset)" requested > _reply=0 destination=":1.18" (uid=0 pid=2806 comm="NetworkManager > --pid-file=/var/run/NetworkManager/")) > > > Be aware that a denied message may still happen if you have other > invalid policy installed (such as those which don't qualify allow/deny > rules with the destination!). Take the opportunity to fix all you see. > > Scott >

4 3

Add "none" to list of skipped filesystems in automatic drive detection
by Ben Klein 21 Jan '09

21 Jan '09

In programs/winecfg/drivedetect.c, there is a list of skipped filesystem types: static const char * const ignored_fstypes[] I propose that "none" be added to this list. The "none" type is used in fstab in combination with options such as "bind" and "rbind". I have such entries in my fstab for my various chroots that I use to build packages of Wine.

1 0

Re: [1/2] dinput: Do not close device upon Unacquire
by Vitaliy Margolen 21 Jan '09

21 Jan '09

Vincent Pelletier wrote: > This fixes force feedback effects in MS Flight Sim 2000: it releases the > device after uploading effects, reaquires it later and try to update effects. > This fails, because linux requires all access to be done from a single file > descriptor. > > It doesn't feel right to open a device without ever closing it... But I could > not find any "dealloc" method. > This patch is not correct. The device can get removed, opened by other application, etc. You can't open it during the creating and keep it open all that time. The more correct way to do it would be to re-upload all the state changes on acquire. Vitaliy.

1 0

Re: dinput: Add effect gain support
by Daniel Remenak 21 Jan '09

21 Jan '09

On Mon, Jan 19, 2009 at 12:52 PM, Vincent Pelletier <plr.vincent(a)gmail.com> wrote: > dinput: Add effect gain support > > -- > Vincent Pelletier > Vincent, This patch is ok as far as it goes, but not completely correct. Firstly, SetParameters needs to apply the parameters to effects while they are playing, not just store them. Existing parameters are all part of the effect structure, so that is taken care of automatically. Since gain is handled by a different mechanism, you also need to handle the while-playing case (unless DIEP_NODOWNLOAD is specified). This probably means you need to implement GetEffectStatus, since you won't want to apply the gain unless the effect is playing. Secondly, the kernel's ff.txt suggests that evdev handles the gain globally for the device. Since the DirectInput definition of gain is per-effect rather than per-device, you should also test what happens when you set the gain differently in two simultaneously-playing effects on the same device. If Windows mixes them (i.e. truly applies the gain per-effect) then we need to come up with some logic to do the same (probably by scaling the effect envelope or magnitude, depending on the effect type, and keeping it updated when the user modifies the scaled parameters). Thirdly, SetParameters still has a comment that says gain and sample periods aren't supported. Please update any applicable comments when you update the code - outdated comments are worse than no comments at all. Regards, Daniel Remenak

1 0

Re: Support for Dragon NS in Wine
by Susan Cragin 21 Jan '09

21 Jan '09

>On Tue, Jan 20, 2009 at 3:23 PM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: >> While I don't own any NS product, two open bugs to come to mind for NS >> 8, one affecting the installer but with a workaround, bug 15708 and >> the other a user has reported a regression bug 16248 but was not >> interested in running a regression test. >> >> http://bugs.winehq.org/show_bug.cgi?id=15708 >> http://bugs.winehq.org/show_bug.cgi?id=16248 > >I think those were both for NS 7, not 8... >A full list of NS bugs is at >http://bugs.winehq.org/buglist.cgi?quicksearch=Dragon+Naturally+Speaking >Looks like 9 is happier than 10...? I have 7, 8, 9, 9.5 and 10 here. I'll test a couple tonight, maybe 7 and 8, on today's git. Here's what I remember. 7 worked great right out of the box at one time, with all-native code. 8 is virtually the same product as 7. Ditto worked great. (Nobody bought 8 much because it was the same engine as 7.) 9.0 worked pretty good out of the box with a couple of glitches. 9.5 does not install, and works not at all, except for one lucky man who developed a workaround that doesn't always work. (9.5 replaced 9.0 as "version 9," and 9.0 is no longer sold, at least in the US.) 10.0 installs well and runs pretty well for 10 minutes, then nasty crashes happen. Wine support has been given primarily for the two cheapest "consumer" versions, Standard and Preferred. Very few people have asked about Professional, and I don't know of anyone who has tried to make Professional 8 run with wine. Susan

2 1

Support for Dragon NS in Wine
by Steven Druker 20 Jan '09

20 Jan '09

Dan, I deeply appreciate your endeavors to broaden the number of Windows-based applications that will run on Linux via Wine. Your Feb. '08 message indicated that while you had achieved significant progress for Dragon NS, it was not yet fully functional. Since then has more progress been made? I'm particularly interested in whether the professional versions of NS 8 as well as 10 are fully supported now. Thank you for whatever information you can provide. Steven M. Druker Executive Director Alliance for Bio-Integrity www.biointegrity.org Home Office: (641) 472-8008

3 3

$200 bid for autocad support
by Dan Kegel 20 Jan '09

20 Jan '09

http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?ln… Someone's got to break the bad news to him about the likely cost...

2 1

Re: Fix wine-bugs mailing list traffic message.
by Francois Gouget 20 Jan '09

20 Jan '09

On Tue, 20 Jan 2009, Christoph Korn wrote: > Only a small fix. > > I subscribed to the wine-bugs mailing list because it was listed as > medium traffic. But I got hundreds of mails in about two hours or so. Usually it's a medium traffic mailing list (I believe), but occasionally (2/3 times a year) someone does a big cleanup touching hundreds of bugs and that's when you get a lot of emails... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

3 2

re: QT4 applications not receiving clicks
by Dan Kegel 20 Jan '09

20 Jan '09

louis wrote: > I may have uncovered a bug in which grandchild HWNDs do not receive mouse-down events. Cool... think you can come up with a conformance test that demonstrates the bug? That might be the best way to answer your questions. - Dan

1 0

QT4 applications not receiving clicks
by louis＠museresearch.com 20 Jan '09

20 Jan '09

Hi, I'm looking at a WINE issue in which some QT-based software isn't getting mouse clicks. The program in question is a VST plug-in. The plug-in, in our host, creates its UI in a child window. Now, in QT, HWNDs are created several layers deep-- seemingly one HWND per widget (QWidget), and then a few others like "QEventDispatcher". I think in doing this, I may have uncovered a bug in which grandchild HWNDs do not receive mouse-down events. To summarize before I dive into the details: On these mouse-down events, WINE attempts to bring the HWND to the front, but fails because the HWND in question is not a top-level window or a top-level window's child and subsequently eats the message. Now for the gory details. Let's start at process_mouse_messages in user32/message.c. If the event in question is a button-down event, WINE tries to activate the window it's for. In the switch statement near the bottom of the function, there is a case MA_ACTIVATE. This calls FOCUS_MouseActivate which in turn calls set_foreground_window (both in user32/focus.c). Jump to the wineserver's set_foreground_window function (in server/queue.c). There is a line which reads: if (is_top_level_window( req->handle ) && . . . ) What this is_top_level_window function says (in server/window.c) is to return true only if the HWND is_desktop_window or a child of the desktop window. is_desktop_window says to return true if there is no parent (because "only desktop windows have no parent"). So, if the HWND has no parent or is the parent of a window with no parent, WINE deems the window top level and the HWND receives the click. If this test fails, set_foreground_window returns an error and causes process_mouse_messages to eat the click instead of passing it on. So, I have a couple questions about WINE operation. My first question is whether the click really should be passed on even if WINE can't bring the HWND to the front in this case. My second question is whether the top-level window test works as expected-- my instinct was that the top-level window is just a window without a parent and that the check might not need to involve the desktop. Thanks, Louis Gorenfeld Muse Research

1 0

Re: shell32: initial stub for SHGetImageList
by Nikolay Sivov 20 Jan '09

20 Jan '09

Aric Stewart wrote: > --- > dlls/shell32/shell32.spec | 1 + > dlls/shell32/shellord.c | 6 ++++++ > 2 files changed, 7 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Should be -noname.

2 2

Today's git does not compile
by Susan Cragin 20 Jan '09

20 Jan '09

At least, it doesn't for me... O2 -o wowthunk.o wowthunk.c ../../tools/winebuild/winebuild -D_REENTRANT -fPIC --as-cmd "as" -o relay16asm.o --relay16 ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_deu.mc.rc nls/winerr_deu.mc ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_enu.mc.rc nls/winerr_enu.mc ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_fra.mc.rc nls/winerr_fra.mc ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_kor.mc.rc nls/winerr_kor.mc ../../tools/wmc/wmc -i -U -H /dev/null -o nls/winerr_nor.mc.rc nls/winerr_nor.mc ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -D__WINESRC__ -D_KERNEL32_ -fokernel.res kernel.rc Source: �̤� a2 cc a4 eb Unicode: 5341 6708 Back: �Q�� a4 51 a4 eb nls/cht.nls:84:16: Error: String �̤� does not convert identically to Unicode and back in codepage 950. Try using a Unicode string instead make[2]: *** [kernel.res] Error 1 make[2]: Leaving directory `/home/susan/wine/dlls/kernel32' make[1]: *** [kernel32] Error 2 make[1]: Leaving directory `/home/susan/wine/dlls' make: *** [dlls] Error 2 susan@ubuntu:~/wine$

2 1

CVS/GIT removal
by Austin English 20 Jan '09

20 Jan '09

All CVS/GIT versions have been moved. Whoever's got bugzilla admin privileges, please delete that version. -- -Austin

1 0

Re: [5/9] Add support of WDM drivers for USB devices.
by Alexandre Julliard 20 Jan '09

20 Jan '09

Alexander Morozov <amorozov(a)etersoft.ru> writes: > From ed6e12ca39e194829ad8d6be4fbd91d9f276d435 Mon Sep 17 00:00:00 2001 > From: Alexander Morozov <amorozov(a)etersoft.ru> > Date: Fri, 3 Oct 2008 17:57:00 +0400 > Subject: [PATCH] Add support of WDM drivers for USB devices. > > --- > configure.ac | 14 ++ > dlls/wineusbhub/Makefile.in | 15 ++ > dlls/wineusbhub/wineusbhub.c | 291 +++++++++++++++++++++++++++++++++++++++ > dlls/wineusbhub/wineusbhub.spec | 7 + > programs/winedevice/Makefile.in | 2 +- > programs/winedevice/device.c | 79 +++++++++++- > programs/wineusb/Makefile.in | 15 ++ > programs/wineusb/main.c | 224 ++++++++++++++++++++++++++++++ > server/device.c | 111 +++++++++++++++ > server/protocol.def | 16 ++ > tools/wine.inf.in | 10 ++ > 11 files changed, 782 insertions(+), 2 deletions(-) Your design needs a lot more thought. You can't add all these Wine-specific modules, or make winedevice special-case usb devices, or poll the server for the add_device request like you do. All this needs to be properly integrated in the existing infrastructure. -- Alexandre Julliard julliard(a)winehq.org

2 1

How to distinct different behavior of IE versions
by Thomas Heckel 20 Jan '09

20 Jan '09

Hi, I'm new to the wine development and interested in some bug hunting to gain better compatibility on windows. Just for starts I looked a little bit onto test.winehq.org and there especially why wininet:http was passing on some windows systems and on some failing with "http.c:1837: Test failed: got 12150 expected ERROR_IO_PENDING". 12150 is defined in include/winhttp.h as ERROR_WINHTTP_HEADER_NOT_FOUND. The occurence is dependent on the version of the wininet.dll. If it is 6.xxx the test fails. If the dll is 7.xxx the test passes. The relevant test case "static void test_HttpSendRequestW(int port)" checked in 3 days ago from Hans Leidekker as commit 667e48286e25c56bca98a135db62d723b74ef89e looks for the HTTP header "UA-CPU: x86". But this string is only supported from IE 7 up. It makes sense that this test has to fail on machines with no IE 7+ installed. But how to tackle such things in a test case? Take care of different windows versions is used in various test cases. Can the IE version be found out with a similar mechanism? Or should a test case just ignore such nuances from internet explorer? Thanks in advance Thomas

3 2

Re: [1/5] richedit: Implemented ITextHost for windowed richedit controls.
by Austin English 20 Jan '09

20 Jan '09

On Tue, Jan 20, 2009 at 12:41 AM, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote: > I plan on implementing windowless richedit controls by refactoring out > the references the richedit controls hWnd into an ITextHost > implementation. This way windowless richedit controls can be > implemented using the same code by using the ITextHost implementation > provided to the CreateTextServices function. > > This patch mostly aims to provide an implementation of ITextHost that > can be created and used in the windowed richedit control. Later patches > will use the ITextHost interface to avoid using the richedit controls > hWnd. Once the existing code is able to properly handle to the case > where hWnd is NULL by using ITextHost, then ITextServices can be > implemented using the existing richedit code. > --- > dlls/riched20/Makefile.in | 1 + > dlls/riched20/editor.c | 71 +++-- > dlls/riched20/editor.h | 49 +++ > dlls/riched20/editstr.h | 7 + > dlls/riched20/txthost.c | 726 +++++++++++++++++++++++++++++++++++++++++++++ > include/textserv.h | 40 --- > 6 files changed, 830 insertions(+), 64 deletions(-) > create mode 100644 dlls/riched20/txthost.c > > > > I just wanted to thank Dylan for all his work on riched, and also for his explanation on his work when submitting patches. While I don't always know what he's fixing, it makes it easier to get an idea what it is he's doing because of his clear explanations on each patchset. -- -Austin

1 0

Re: fix commit 3fe5d80512ec5dbfbb2ee7dbb426be7d582e262e
by Francois Gouget 20 Jan '09

20 Jan '09

On Sat, 17 Jan 2009, Shunichi Fuji wrote: > >http://source.winehq.org/git/wine.git/?a=commit;h=3fe5d80512ec5dbfbb2ee7dbb… > >configure: Check for ESound, FreeType, GPhoto2 and SANE even if their 'xxx-config' tool is missing. [...] if test "x$with_sane" != "xno" then ac_save_CPPFLAGS="$CPPFLAGS" + ac_sane_libs="-lsane" We don't need -lsane here because we're using WINE_CHECK_SONAME() which will add it itself (see LIBS="-l$1 $5... on line 42 or aclocal.m4) and because we're not exporting ac_sane_libs. Having it twice would not hurt but it's less correct. By the way, sane.ds will do a dlopen("libsane.so") to load SANE. That was justified when the dlopen() was done by twain_32.dll, but is it still justified now? Maybe sane.ds should simply link to libsane? That would also 'solve' the 'issue of the extra libraries' that we may have to load before loading libsane (though my understanding is that if libsane requires extra libs and does not link with them that's very much a libsane bug). If we change that then it would be a different matter. if test "x$with_gphoto" != "xno" then ac_save_CPPFLAGS="$CPPFLAGS" + ac_gphoto2_libs="-lgphoto2" AC_CHECK_PROG(gphoto2_devel,gphoto2-config,gphoto2-config,no) This one is right because we export ac_gphoto2_libs in GPHOTO2LIBS. However, I think it would be clearer to do it in the else branch of the test for teh xxx-config tool. So something like this: if test "$gphoto2_devel" != "no" -a "$gphoto2port_devel" != "no" then ... else ac_gphoto2_libs="-lgphoto2" fi ... dnl **** Check for FreeType 2 **** if test "x$with_freetype" != "xno" then + ac_freetype_libs="-lfreetype" AC_CHECK_PROGS(ft_devel,[freetype-config freetype2-config],no) if test "$ft_devel" != "no" then This one looks correct, but again I think it would be clearer to have it in the else branch (even if it's one extra line): if test "$ft_devel" != "no" then ... else ac_freetype_libs="-lfreetype" fi if test "x$with_esd" != xno then save_CFLAGS="$CFLAGS" + ac_esd_libs="-lesd" AC_PATH_PROG(ESDCONFIG, esd-config, no) if test "x$ESDCONFIG" != "xno" then Same here. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

2 1

OpenAL back-end: repost for reconsideration
by FeepingCreature 20 Jan '09

20 Jan '09

After STALKER: Clear Sky failed to generate viable sound output using the existing drivers (in GIT head as of a few days back), I started looking for solutions and stumbled over this thread: http://www.nabble.com/RFC:-OpenAL-Winmm-driver-and-OpenAL32.dll-thunk-was-R… I brought the patch up to speed with current Wine to the best of my knowledge and pasted it here: http://pastebin.com/f2a559a22 It appears to make sound work flawlessly in at least one OpenAL-based game, and I suspect there may be more. In case this driver adds too much of a support/code overhead, would it be possible to add it as a band-aid, until the problem that prevents the other back-ends from working with Clear Sky is fixed? Thanks for your comments. --feep PS: No I'm not running Pulseaudio :) ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

5 4

Re: widl: fix a compiler error
by Rob Shearman 19 Jan '09

19 Jan '09

2009/1/19 Austin English <austinenglish(a)gmail.com>: > diff --git a/tools/widl/widltypes.h b/tools/widl/widltypes.h > index e6b0369..0851d2b 100644 > --- a/tools/widl/widltypes.h > +++ b/tools/widl/widltypes.h > @@ -539,6 +539,7 @@ static inline enum type_type type_get_type_detect_alias(const type_t *type) > default: > assert(0); > } > + return 0; > } > > #define STATEMENTS_FOR_EACH_FUNC(stmt, stmts) \ Please put the return statement in the default case. -- Rob Shearman

1 0

Re: msi/tests: Make tests pass for Windows Installer 3.0 [2/3]
by James Hawkins 19 Jan '09

19 Jan '09

On Sun, Jan 18, 2009 at 3:38 PM, Ge van Geldorp <ge(a)gse.nl> wrote: > I see different estimated size values for Windows Installer 2.x and 3.0 > compared to 3.1 and later. > Please don't remove the check. It is set, and that's what we're testing. If the value is different on different platforms, then do like we do for other tests and add them to the check. -- James Hawkins

3 3

kernel32: fix cpu detection on NetBSD
by Austin English 19 Jan '09

19 Jan '09

I submitted OpenBSD's patch for CPU detection a while back (http://www.winehq.org/pipermail/wine-patches/2009-January/067002.html). Francois sent a 'more correct' one (http://www.winehq.org/pipermail/wine-patches/2009-January/067382.html), but that one is broken on NetBSD/OpenBSD (http://bugs.winehq.org/show_bug.cgi?id=16927). With the below changes, it works again, but I'm not sure it's correct. Comments appreciated: diff --git a/dlls/kernel32/cpu.c b/dlls/kernel32/cpu.c index 95ac469..5bd3a38 100644 --- a/dlls/kernel32/cpu.c +++ b/dlls/kernel32/cpu.c @@ -547,7 +547,7 @@ VOID WINAPI GetSystemInfo( #elif defined (__NetBSD__) { int mib[2]; - int value; + int value[2]; size_t val_len; char model[256]; char *cpuclass; @@ -578,7 +579,7 @@ VOID WINAPI GetSystemInfo( mib[1] = HW_NCPU; val_len = sizeof(value); if (sysctl(mib, 2, &value, &val_len, NULL, 0) >= 0) - if (value > cachedsi.dwNumberOfProcessors) + if (value[0] > cachedsi.dwNumberOfProcessors) cachedsi.dwNumberOfProcessors = value[0]; mib[1] = HW_MODEL; val_len = sizeof(model)-1; -- -Austin

3 11

Re: libs/wine/Makefile.in: replace `wine` with @PACKAGE_NAME@
by Detlef Riekenberg 19 Jan '09

19 Jan '09

On Fr, 2009-01-16 at 20:51 +0300, Vitaly Lipatov wrote: > - version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD > 2>/dev/null || echo "wine-@PACKAGE_VERSION@") | sed -n -e '$$s/$.* > $/const char wine_build[] = "\1";/p'` && (echo $$version | cmp -s - > $@) || echo $$version >$@ || ($(RM) $@ && exit 1) > + version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD > 2>/dev/null || echo "@PACKAGE_NAME@ @PACKAGE_VERSION@") Your patch change also the minus to a space -- By by ... Detlef

7 12

request for packagers - icon for builtin wine internet explorer
by Steven Edwards 19 Jan '09

19 Jan '09

Hi, Do you guys that package Wine mind adding Wine Internet Explorer to your Wine program group? I think it would be nice to encourage more users install gecko and test builtin IE rendering and having the shortcut would save them a bit of trouble. Thanks -- 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

3 2

Re: urlmon/tests: Fix protocol tests when proxy is configured
by Ge van Geldorp 19 Jan '09

19 Jan '09

Hi Jacek, > From: Jacek Caban <jacek(a)codeweavers.com> > Subject: Re: urlmon/tests: Fix protocol tests when proxy is configured > > Ge van Geldorp wrote: > > There is a large amount of proxy configurations possible on > > Windows (WPAD, proxy.pac, fixed proxy values), which might behave > > differently on a second run of the protocol test compared to the > > first run. These configurations influence when/how > > IInternetProtocolSink methods are called. For example, > > with a standard, direct connection you'll get the following > > ReportProgress notifications during the https test: > > BINDSTATUS_FINDINGRESOURCE > > BINDSTATUS_CONNECTING > > BINDSTATUS_SENDINGREQUEST > > BINDSTATUS_ACCEPTRANGES > > BINDSTATUS_MIMETYPEAVAILABLE > > However, when you run the protocol test for the second time > > on a machine with a fixed proxy server configured, you'll only > > get these notifications: > > BINDSTATUS_SENDINGREQUEST > > BINDSTATUS_ACCEPTRANGES > > BINDSTATUS_MIMETYPEAVAILABLE > > > > When a proxy is used, the BINDSTATUS_FINDINGRESOURCE and > > BINDSTATUS_CONNECTING notifications report the hostname/ip > > address of the proxy server, not the end destination. > > I can't see this behavior in tests results, where do you see > them? Which IE version is it? This started when investigated the failures reported here: http://test.winehq.org/data/8b10dd2a8daed738527f92aa89104c8647e4535c/2003_gv g-w2k3r2sesp2/urlmon:protocol.html. This is a Windows 2003 R2 Standard Edition SP2 machine with IE6. The status 32 shown there is BINDSTATUS_PROXYDETECTING. It turns out that on this particular machine "Automatically detect settings" (aka WPAD) was activated. The full sequence of of ReportProtress notifications for the https test was: BINDSTATUS_FINDINGRESOURCE BINDSTATUS_CONNECTING BINDSTATUS_PROXYDETECTING BINDSTATUS_CONNECTING BINDSTATUS_SENDINGREQUEST BINDSTATUS_ACCEPTRANGES BINDSTATUS_MIMETYPEAVAILABLE I then started experimenting on that machine with various proxy settings. I found that this sequence happens on the first run with WPAD configured but no wpad.mydomain.mytld available. On a second run it seems the info that no wpad was available was cached, I got "standard" behavior. If I configured a wpad.mydomain.mytld domain the sequence would also revert back to "standard" on the first run (whether there was a wpad.dat file available from that host or not didn't seem to matter, there just needs to be a wpad.mydomain.mytld DNS entry). When a proxy was indeed configured via WPAD, the BINDSTATUS_FINDINGRESOURCE and BINDSTATUS_CONNECTING notifications reported the hostname/ip address of the proxy server. Next I experimented with "Use automatic configuration script" (aka proxy.pac). I found that in that case the "standard" notification sequence was used, but still with the proxy server hostname/ip address. Finally I set a manual proxy server. In that case, the first time I run the test I get the "standard" sequence, but on the second (and later) runs I see the very minimal sequence mentioned in my original post. So most of the behavior was seen in one-off experimentation. If you want, I can set up some machines to report some of the behaviors to test.winehq.org. > Also, you have to make sure that each SET_EXPECT is followed by > CHECK_CALLED (or CLEAR_CALLED if you want to ignore that function was > not called). Ok, thanks, I'll take care of that. Ge.

1 0

Re: d3dxof: Fix object files size limitation
by Alexandre Julliard 19 Jan '09

19 Jan '09

Christian Costa <titan.costa(a)wanadoo.fr> writes: > commit 2ddacc839326d96f6508e8e431308160979c7082 > Author: Christian Costa <titan.costa(a)wanadoo.fr> > Date: Mon Jan 19 12:04:09 2009 +0100 > > Fix object files size limitation. If you need to parse such large files using a file mapping would be better than reading it into a buffer. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [7/7] d3d9: test table fog and exp fog in the shader fog test
by Henri Verbeet 19 Jan '09

19 Jan '09

Since you're going to resend this one anyway: > From: unknown <stefan@.(none)> Your From: line is broken. > - 0x005fa000, 0x0040bf00, 0x0020df00, 0x0000ff00, 0x0000ff00}}, > + 0x005fa000, 0x0040bf00, 0x0020df00, 0x0000ff00, 0x0000ff00}}, Any reason for changing the indentation here? I could understand changing it for consistency, but that's not really the case here.

2 1

Re: [1/7] WineD3D: Don't single-allocate new gl shaders
by Henri Verbeet 19 Jan '09

19 Jan '09

2009/1/19 Stefan Dösinger <stefan(a)codeweavers.com>: > + shader->shader_array_size += max(1, old_size * 0.5); I don't know for sure if the compiler is able to get rid of the floating point multiplication, but wouldn't a right shift or divide by 2 work at least as well? > + shader->gl_shaders = HeapReAlloc(GetProcessHeap(), 0, old_array, > + (shader->shader_array_size + 1) * sizeof(*shader->gl_shaders)); This looks more complicated than it has to be. It's easier to just change "old_size <= shader->num_gl_shaders" into "old_size < shader->num_gl_shaders" and drop the +1 here. Also note that "old_array" isn't particularly useful here, you overwrite shader->gl_shaders regardless of whether the allocation fails or succeeds. The typical way to do this would be: if (shader->num_gl_shaders >= shader->shader_array_size) { UINT new_size; struct ps_compiled_shader *new_array; if (shader->gl_shaders) { new_size = shader->shader_array_size << 1; new_array = HeapReAlloc(GetProcessHeap(), 0, shader->gl_shaders, new_size * sizeof(*new_array)); } else { new_size = 1; new_array = HeapAlloc(GetProcessHeap(), 0, new_size * sizeof(*new_array)); } if (!new_array) { ERR("Out of memory\n"); return 0; } shader->shader_array_size = new_size; shader->gl_shaders = new_array; } This applies to 4/7 as well.

2 1

Re: [4/7] WineD3D: Put vertex shader duplication infrastructure in place
by Henri Verbeet 19 Jan '09

19 Jan '09

2009/1/19 Stefan Dösinger <stefan(a)codeweavers.com>: > @@ -1860,14 +1861,19 @@ static void shader_arb_destroy(IWineD3DBaseShader *iface) { > This->shader_array_size = 0; When did this line get added? It's not in 1/7.

2 1

Re: urlmon/tests: Fix protocol tests when proxy is configured
by Jacek Caban 19 Jan '09

19 Jan '09

Hi, Ge van Geldorp wrote: > There is a large amount of proxy configurations possible on Windows (WPAD, > proxy.pac, fixed proxy values), which might behave differently on a second > run of the protocol test compared to the first run. These configurations > influence when/how IInternetProtocolSink methods are called. For example, > with a standard, direct connection you'll get the following ReportProgress > notifications during the https test: > BINDSTATUS_FINDINGRESOURCE > BINDSTATUS_CONNECTING > BINDSTATUS_SENDINGREQUEST > BINDSTATUS_ACCEPTRANGES > BINDSTATUS_MIMETYPEAVAILABLE > However, when you run the protocol test for the second time on a machine > with a fixed proxy server configured, you'll only get these notifications: > BINDSTATUS_SENDINGREQUEST > BINDSTATUS_ACCEPTRANGES > BINDSTATUS_MIMETYPEAVAILABLE > > When a proxy is used, the BINDSTATUS_FINDINGRESOURCE and > BINDSTATUS_CONNECTING notifications report the hostname/ip address of the > proxy server, not the end destination. > > I can't see this behavior in tests results, where do you see them? Which IE version is it? Also, you have to make sure that each SET_EXPECT is followed by CHECK_CALLED (or CLEAR_CALLED if you want to ignore that function was not called). Jacek

1 0

Re: mshtml: Implement IHTMLDocument5 createComment (try 3)
by Jacek Caban 19 Jan '09

19 Jan '09

HI Alistair, Alistair Leslie-Hughes wrote: > Hi, > Removed unused variables. > > Changelog: > mshtml: Implement IHTMLDocument5 createComment + else + { + win_skip("Could not get IHTMLDocument5, probably too old IE\n"); + } There is no need for skip here. These tests will be skipped in create_document call if IHTMLDocument5 is not available anyways. Jacek

1 0

Re: crypt32(4/4): Add a localized name for the TrustedPublisher store
by Alexandre Julliard 19 Jan '09

19 Jan '09

"Juan Lang" <juan.lang(a)gmail.com> writes: > Actually, this doesn't depend on the others. My mistake. It breaks the tests: ../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p crypt32_test.exe.so protectdata.c && touch protectdata.ok protectdata.c:200: Test failed: Description not empty make: *** [protectdata.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: [4/7] WineD3D: Put vertex shader duplication infrastructure in place
by Stefan Dösinger 19 Jan '09

19 Jan '09

Please don't apply this patch and the following ones yet. They break device::reset because they don't delete old gl shaders properly in this case. I'll try to get a fixed patch asap. Patches 1-3 should still be ok > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Stefan Dösinger > Sent: Monday, January 19, 2009 11:49 AM > To: wine-patches(a)winehq.org > Subject: [4/7] WineD3D: Put vertex shader duplication infrastructure in > place >

1 0

libmsi.a import library from wine, and header files available (entirely free software), available for python-win32 builds under msys+wine
by Luke Kenneth Casson Leighton 18 Jan '09

18 Jan '09

as part of building python2.5.2 under msys under wine on linux using mingw, i thought i'd try building _msi.pyd just for kicks. of course, that required having an msi.lib import library, and associated header files. so, purely as an experiment, i've documented the process by which it is possible to take wine 1.1.13 (current development release) source code, modify the header files for use with mingw, create a typelibrary (using dlltool) and then, surprise-surprise, _msi.pyd successfully builds. i say successfully builds: but then, running from _outside_ of a wineconsole cmd, doing this: /usr/local/bin/wine ./python.exe -c 'import _msi' succeeds. but if you do this: /usr/local/bin/wineconsole cmd c:/python2.5/bin/python.exde -c 'import _msi' you get an "access violation - no access to memory" blah blah to be honest, i don't care about that: this message is to let people know that it _is_ possible, and, if anyone is interested in e.g. adding -lmsi -lcabinet support to MinGW, here's where you can get the necessary crud: http://lkcl.net/msi.tgz if the wine team have any objections, if they believe this is a bad idea, please do say so :) l. p.s. if anyone would like to add a regression test to python called "test_msi.py" - or if they know of one that exists, i'd love to hear from you and try it out. outside of a wine cmd.exe of course :)

1 0

python regression tests - a monster hammer to keep wine "in check" :)
by Luke Kenneth Casson Leighton 18 Jan '09

18 Jan '09

folks, hi, i've started running the python regression tests under wine (using the build of python i've only just created) and have started filling in bugreports for the tests that fail, but some things occurred to me: 1) why am i the only person filling out the bugreports? :) 2) surely these regression tests would work equally as well under the python2.5.2.exe that you can get as part of the pre-prepared python win32 install that comes from python.org and activestate.com, you don't _need_ my wine-built version of python.exe 3) why am i considering rewriting the tests as c-code when they can just as well be left as python code? one of the bugs that's _really_ really important is: crlf conversion. the code in wine's msvcrt is completely borked. i demonstrated this by switching over to "native" msvcrt.dll, and nearly _all_ of the 12 tests that failed, all but the test_os.py ones miraculously succeeded. the majority of tests fail due to file corruption over writing \n and getting back \r\n, which is clearly bogus. _yes_ i'm aware of the difference between O_BINARY and O_TEXT, and it would seem that there's either a default setting which is wrong, or there's some runtime detection going on, or... just... _something_ :) but the behaviour of msvcrt wrt crlf is _definitely_ not right, as it stands, and as a result it completely screws any possibility for running python.exe under wine. completely. you can't have files that you write to, that are different from when they are read back. l.

3 7

Re: winejoystick.drv: Implement POV support
by Austin English 18 Jan '09

18 Jan '09

On Sat, Jan 17, 2009 at 6:01 AM, Vincent Pelletier <plr.vincent(a)gmail.com> wrote: > Note: > The code generating "discrete" values uses raw numbers istead of defined > values, because they exist only for 4 directions and (on the contrary of what > is advertised by MSDN) JOY_RETURNPOV also reports diagonal angles (verified > on vista 32 bits, with joytester.exe). I believe it's easier to see the > correlations between values this way. > > TODO: > JOYCAPS_POVCTS support, requiring some trigonometry functions and a joystick > reporting "analog" POV coordinates. > -- > Vincent Pelletier > > > > + case 16: /* Hat 0 X */ + case 17: /* Y */ + lpCaps->wCaps |= JOYCAPS_HASPOV | JOYCAPS_POV4DIR; + /* TODO: JOYCAPS_POVCTS handling */ + break; Minor, but shouldn't that be 'case 17: /* Hat 0 Y */' -- -Austin

2 1

http://bugs.winehq.org/show_bug.cgi?id=17003 - lseek with SEEK_END being ignored after fread
by Luke Kenneth Casson Leighton 18 Jan '09

18 Jan '09

this one's a loovely obscure one - fread makes lseek be ignored :) l.

1 0

Wine AppDB Test Results Submitted by Distribution @ 2009/01/18
by nn 18 Jan '09

18 Jan '09

Ubuntu users account for the majority of submitted test results to date. ------- Distribution / Number of Test Results Submitted ------- Ubuntu 17968 Gentoo 4135 Debian 2747 Open SUSE 1554 Fedora_Core 1334 SUSE 1011 fedoraproject 960 Mandrake 794 Arch_Linux 768 Slackware 678 Kubuntu 238 Mint_Linux 208 pclinuxos 206 FreeBSD 204 MacOSX 185 ubuntustudio 121 linuxfromscratch 113 CentOS 100 sabayonlinux 87 sidux 58 kanotix 46 slamd64 41 Red_Hat 41 gobolinux 39 mepis 38 pcbsd 37 zenwalk 33 pld-linux 29 na 25 uhulinux.hu 25 vectorlinux 24 Source_Mage 23 xandros 22 ultimalinux 20 Puppy_Linux 19 frugalware 19 mepis 17 pardus-linux.nl 16 KNOPPIX 15 pardus.treng 13 Kurumin_Linux 13 xubuntu 12 redflag-linuxenindex.php 12 pcbsd 12 slax 11 sam-linux 9 kalangolinux 9 elivecd 9 lunar-linux 8 dreamlinux.br 8 Alt_Linux 8 ubuntu-eee 7 64studio 6 skolelinux 5 remote-exploitbacktrack.html 5 freespire 5 wolvix 4 opensolaris 4 opensolaris 4 yoper 3 thinkgos 3 paldo 3 magiclinuxdrupal 3 linux-xp 3 linspire 3 damnsmalllinux 3 AGNULA-DeMuDi 3 tinyme.mypclinuxos 3 opengeu.intilinux 3 developers.sunsxde 3 pardus.treng 2 cdlinux.pl 2 asplinux.ru 2 Aurox_Linux 2 wiki.rpathwikirPath_Linux 2 ubuntusoftware.infoultimate 2 grml 2 arklinux 1 yeslinux 1 sun 1 realnetworks 1 pendrivelinux20080206usb-mcnlive-toronto 1 pendrivelinux 1 myah 1 linpus 1 linnexos.pl 1 kateos 1 foresightlinux 1 wiki.laptopgoFedora 1 linux.startcom 1 fluxbuntu 1 easys.gnulinux.de 1 blagblagblag 1 ------- Grand Total 34225 ------- Rough Stats Compiled from ( http://appdb.winehq.org/objectManager.php?sClass=distribution&sTitle=View%2… ) Stay connected to the people that matter most with a smarter inbox. Take a look http://au.docs.yahoo.com/mail/smarterinbox

1 0

stdin and stdout getting connected to the wrong things!
by Luke Kenneth Casson Leighton 18 Jan '09

18 Jan '09

http://bugs.winehq.org/show_bug.cgi?id=16968 this one's _really_ intriguing. i've been observing that occasionally, running python.exe e.g from /bin/sh.exe interactively shows... nothing. it's like, "dude, where's my car^H^H^Hinteractive python prompt?>>>" and the python developers are _really_ getting heavy at me for moving Py_Initialize() around and doing all sorts of weird shit like _assuming_ that the isatty(stdin) test has succeeded n stuff. well, i think what's happening - and this popen() test gives some clues - is that stdin and stdout are being connected to the xterm from which /usr/bin/wine was started... for a _brief_ period of time. after some unspecified time, they are no longer connected to the starting-process's stdin or stdout, but are connected to the correct places. but in many instances, that's far too late - a process should _never_ start up with its stdin and stdout connected to the wrong place in the first place! l.

1 0

python regression tests - a monster hammer to keep wine "in check" :)
by Dan Kegel 18 Jan '09

18 Jan '09

Luke wrote: > 1) why am i the only person filling out the bugreports? :) You got lucky and found a good test suite! If you put up a nice easy recipe, you'll probably get some help. > 2) surely these regression tests would work equally as well under the > python2.5.2.exe that you can get as part of the pre-prepared python > win32 install that comes from python.org and activestate.com, you > don't _need_ my wine-built version of python.exe Indeed. (For the curious, see http://docs.python.org/library/test.html ) > 3) why am i considering rewriting the tests as c-code when they can > just as well be left as python code? You only have to do that for the tests that fail. It's useful because a) it greatly reduces the size of the log a wine developer has to look at, and b) adding it to wine's test suite makes it much less likely to recur. I agree we should be running the Python tests routinely, but probably not as part of wine's "make test". - Dan

3 6

fgets followed by fread gives wrong results
by Luke Kenneth Casson Leighton 17 Jan '09

17 Jan '09

http://bugs.winehq.org/show_bug.cgi?id=16982 test case included, along with output shown from native msvcrt.dll run. this is _different_ from #16790 (but inter-related, as fgets is made up from lots of fgetc()s. the file pos (from ftell) is off by one, compared to msvcrt.dll On Sat, Jan 17, 2009 at 7:53 PM, Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> wrote: > give it a bit more time - there's another one (involving fgets > followed by fread) which i'm investigating, i'll have that one nailed > as a test case in a bit, am just about to add a test case to #16790

1 0

Re: Debian packages of Wine
by Paul Bryan Roberts 17 Jan '09

17 Jan '09

Maurilio is doing a great job providing Lenny packages for Wine. The site at http://wine.x.pl has been providing Wine packages for Etch for some time. x86 only I'm afraid. The site's author is very modest but I believe it's a chap named James Huk who used to send messages to the wine-user mailing list letting people know he'd put up a new package. James claimed his packages work under Lenny as well as Etch and I have used them this way before Maurilio started putting up packages built specifically for Lenny. Is there really that much difference ? I'm puzzled by the sizes of the packages. Packages for Debian by Maurilio and James are 13-14 Mb to download whereas Ubuntu packages by Scott are only 7-8 Mb. Anyone see any reason for this ? Cheers, PBR

6 6

Re: winetest: make the wrapper immune to Ctrl-C
by Dylan Smith 17 Jan '09

17 Jan '09

On Fri, Jan 16, 2009 at 6:21 PM, Ge van Geldorp <ge(a)gse.nl> wrote: > > The riched20:editor test seems to be sending Ctrl-C keystrokes to the > wrong window on Windows. When running "winetest -q" They end up in the > winetest console window, causing it to terminate. Judging from the lack of > test results, I'm not the only one experiencing this problem. Thanks for noticing this, because I think I might have made the change that caused this to happen. I tracked down the source of the problem and I sent a patch that seems to prevent this from happening: richedit: Prevent sending Ctrl-C to console and ending tests. http://www.winehq.org/pipermail/wine-patches/2009-January/067836.html > > Changelog: > winetest: make the wrapper immune to Ctrl-C > If there is no problem with my patch, then do you think we still need your patch as a preventative measure?

2 1

success: compilation of python2.5.2 under wine+msys+mingw32
by Luke Kenneth Casson Leighton 16 Jan '09

16 Jan '09

hi folks, i promised i'd get python built under wine - and i'm happy to report that this goal has been successfully achieved. http://bugs.python.org/issue4954 if anyone's interested. what has been achieved is that a python.exe, libpython2.5.dll, an implib libpython2.5.dll.a and a python2.5.def have all been successfully created using an entirely free software toolchain, along with the dynamic libraries (such as pyexpat.pyd - python for win32's convention is .pyd not .so). running the regression testing has been... interesting :) several bugs in wine have been detected, along with faults in the header-files that need to be corrected. tmpfile() is faulty; MAX_LONG and MIN_INT #defines cause problems; the default file format CRLF instead of LF causes the builtin regression test to fail; _ctypes _utterly_ borks on c structure creation and manipulation but is using assembly-stuff (a copy of libffi is included in python) - there are a few more, but out of 350 tests, the majority of them succeed. amazingly. anyway, the point of this message is primarily to let people know that this successful compile shows just how far along wine is coming, and it's like a really big hairy deal that python can now be compiled for win32 platforms, for native use on windows or on wine, _without_ having to have a proprietary operating system or a proprietary compiler to do it. now it's possible to port things like pygtk2, pyqt4, pywebkit-gtk and numpy to win32 etc. (because of the header files and the implibs) - again, _without_ requiring proprietary technology. which is absolutely fantastic. thank you to everyone on the wine team. l.

2 1

re: success: compilation of python2.5.2 under wine+msys+mingw32
by Dan Kegel 16 Jan '09

16 Jan '09

Awesome. Thanks for the tmpfile bug report. If you can feed us any more similar reports, please do!

2 1

New winetricks 20090116: new verbs mono22, urlmon, wininet, controlpad, native_oleaut32, msscript, hosts; plus various updates and bugfixes
by Dan Kegel 16 Jan '09

16 Jan '09

Gee, it's been a while since I posted a new version of winetricks. This is rather a big update. As always, online at http://kegel.com/wine/winetricks Please submit bug reports to http://code.google.com/p/winezeug/issues/list svn log since version 20081127: r264 | daniel.r.kegel | 2009-01-16 Don't set winver to win2K when installing .net 1.1. r263 | daniel.r.kegel | 2009-01-16 Add mono2.2. r262 | daniel.r.kegel | 2009-01-12 Updated mshflxgd (still might not work, let me know) r261 | daniel.r.kegel | 2009-01-11 Austin English: add 'hosts' verb to create dummy hosts and services files (helps informix apps, see bug 12076) r260 | daniel.r.kegel | 2009-01-11 Fix gecko to grab right version for newer wine. r259 | daniel.r.kegel | 2009-01-11 Alternate URL for tahoma, not sure if it's needed, so just a comment. r253 | daniel.r.kegel | 2008-12-23 Fix symlink vulnerability pointed out by Stefan Nordhausen. r252 | daniel.r.kegel | 2008-12-23 wininet verb didn't actually override wininet. (Thanks to Austin English.) r251 | daniel.r.kegel | 2008-12-17 Added new verb msscript to fix http://code.google.com/p/winezeug/issues/detail?id=19 Also noticed that msmask.ocx wasn't registered, so do that r250 | daniel.r.kegel | 2008-12-17 Don't behave strangely if WINEDEBUG is set Make the dirac0.8 verb work as documented (fixes http://code.google.com/p/winezeug/issues/detail?id=18 ) r249 | daniel.r.kegel | 2008-12-17 Avoid if ! test, use if test ! instead. Makes it work better on ancient shells like the one in Solaris. Fixes http://code.google.com/p/winezeug/issues/detail?id=1 r247 | daniel.r.kegel | 2008-12-13 Fix firefox3 for curl (thanks to Tijl Coosemans) Clean up ie6 a bit r245 | daniel.r.kegel | 2008-12-02 1. Added new variable WINDIR (good suggestion from Nicolas Koch) 2. Removed obsolete wsh51 verb 3. make xvid load vcrun6 if needed (else it dies without mfc42) 4. Fix some places where a space in WINEPREFIX would have caused grief r244 | daniel.r.kegel | 2008-12-02 Quoted the last few instances of $WINETRICKS_TMP. (Thanks to Nicolas Koch for the tip.) r243 | daniel.r.kegel | 2008-11-30 New verb urlmon. r242 | daniel.r.kegel | 2008-11-30 Add verb wininet. r241 | daniel.r.kegel | 2008-11-29 New version 20081129. r240 | daniel.r.kegel | 2008-11-29 New verbs: controlpad/fm20, native_oleaut32. Clean up temp directory between verbs.

1 0

To Wiki admin
by Vitaliy Margolen 16 Jan '09

16 Jan '09

Please ban this IP: freenet.lds-freenet.lds.net.ua[193.192.36.230]

1 0

mshtml: What is wrong with my patch?
by Vitaly Perov 16 Jan '09

16 Jan '09

What is wrong with my patch? mshtml: Add TRACE for unsupported IStdMarshalInfo -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru

1 0

Re: [2/2] ntdll: Fix NtOpenKey return value on different failures
by Alexandre Julliard 16 Jan '09

16 Jan '09

Nikolay Sivov <bunglehead(a)gmail.com> writes: > Changelog: > - Fix NtOpenKey return value on different failures > - Added some tests for NULL arguments And this one causes the advapi32 tests to fail: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so registry.c && touch registry.ok registry.c:956: Test failed: expected ERROR_INVALID_PARAMETER, got 998 make[2]: *** [registry.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] ntdll: Fix NtQueryValueKey ret. value for insufficient buffer
by Alexandre Julliard 16 Jan '09

16 Jan '09

Nikolay Sivov <bunglehead(a)gmail.com> writes: > Changelog: > - Fix NtQueryValueKey ret. value for insufficient buffer > - Added some tests for NULL arguments and a fix for them This causes the kernel32 debugger test to hang. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wldap32: Re-add one cast removed in d576c2d9342e769c.
by Alexandre Julliard 16 Jan '09

16 Jan '09

Michael Stefaniuc <mstefani(a)redhat.de> writes: > This cast is needed to silence a compile warning with older openldap > versions; e.g. on RHEL5. Actually the code is broken now, since you changed long to LONG the structures are no longer compatible... They will have to be converted explicitly. -- Alexandre Julliard julliard(a)winehq.org

2 1

RE: Wine being targeted for adware
by Eduardo Menezes 16 Jan '09

16 Jan '09

I think a "isolate prefix" option in winecfg (or even winetricks) would be very useful. Undoing symlinks and editing the registry to take out the reference to the root is boring (and I'm not sure only doing this is entirely safe) and this kind of option would make it possible to run untrusted software without worrying. I even ran some malwares in isolated wine prefixes and used diff to see what it did. Learned a lot from this. Anyway, a "nice to have" feature. Best wishes and thanks for this amazing software, 2009/1/14 <wine-devel-request(a)winehq.org> > Date: Wed, 14 Jan 2009 15:07:06 -0500 > From: Nicholas LaRoche <nlaroche(a)vt.edu> > Subject: Re: Wine being targeted for adware > To: Stefan D?singer <stefan(a)codeweavers.com> > Cc: wine-devel(a)winehq.org > Message-ID: <496E45EA.9060603(a)vt.edu> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Stefan D?singer wrote: > >> As long as the facilities exist for keeping an entire wine bottle > >> isolated from other bottles (and ~/) I don't see this being a major > >> issue. > > They don't. > > > > Even if you don't have a drive link pointing out of a bottle, a Windows > app > > running in Wine can still call Linux syscalls(int 0x80). This is > > possible/needed because Windows apps run as a regular Linux process that > > links in Linux libraries which perform linux syscalls. > > > > So any Windows malware can break out of the Wine "sandbox"(which isn't a > > sandbox really) by simply using linux syscalls. > > > > > > > > On more recent distros (FC9/10) SELinux is enabled by default. Rolling a > policy specifically for an untrusted bottle would severely limit the > damage it could do. It could restrict all unnecessary read/write/execute > access outside of the ~/.wine folder for wineserver and the program. > > I see your point though, since none of the aforementioned security > precautions are commonplace or specifically targeted to wine. > > -- Eduardo "Toda Revolução é IMPOSSÍVEL até que se torne INEVITÁVEL!!!" (Leon Trotsky)

4 6

RFC: fd.o file type association integration
by Damjan Jovanovic 16 Jan '09

16 Jan '09

Hi I've hacked together a little program (attached) that creates freedesktop file type associations (eg. open .dev files with Dev-C++ when you double-click them in a file manager) from what Windows programs do in the registry (#13597). Currently it works well, but has to be run explicitly to refresh the associations. Ideally we'd have something in Wine that automatically refreshes the associations when they change, but since they are done in the registry, what's the way to go here? Do it on every wineboot, or in some permanently running process (explorer?) that monitors the registry for changes? Also what is a good way to invent a MIME type for an extension? Currently for a .ext extension I'm just using application/x-wine-ext. Comments much appreciated. Damjan

3 3

WMF Support
by Erich Hoover 16 Jan '09

16 Jan '09

I ran into an issue with WMF files in helping someone get an application to work (Athena Visual Studio) and I worked around it by pre-rendering the application's vector WMF files. I don't currently have the time to resolve the issue, but for when I do I'm curious whether there is a reason that OleLoadPicture* has been implemented manually. It seems that the LGPL "libwmf" has excellent support for both bitmap and vector WMF files (it at least worked for converting the files I had trouble with!), so it seems to me like it would make sense to use this library rather than spinning a separate implementation. Any comments are appreciated. Erich Hoover ehoover(a)mines.edu

4 3

Download Link at budgetdedicated.com not working
by James McKenzie 16 Jan '09

16 Jan '09

Jeremy Newman: Looks like the download-deb page on winehq.org has gone missing again. James McKenzie

5 5

Re: [3/5] user32: Resend: Move character conversion logic to dde_server.d & remove todo's
by Hans Leidekker 16 Jan '09

16 Jan '09

On Wednesday 14 January 2009 08:29:33 Jeff Latimer wrote: > I have tested this a number of ways and I can not see a mechanism that > DDE can determine whether data passed is UNICODE (pData is of type > LPBYTE). In my tests, the case of the server uses a UNICODE window it > is immaterial as to the type of window the client uses but is dependent > on the type of data passed. This has been discussed before, we cannot rely on IsTextUnicode since it's just a heuristic. MSDN mentions that the character set depends on whether the client called DdeInitializeA or DdeInitializeW, and it can be overridden by setting iCodePage in the CONVCONTEXT structure. This suggests to me that we'll need some form of IPC. -Hans

3 4

Re: mshtml: Implement IHTMLDocument5 createComment (resend)
by Alistair Leslie-Hughes 15 Jan '09

15 Jan '09

Hi, Can I get some feedback on this please? Best Regards Alistair Leslie-Hughes "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote in message news:496D1EBF.2000800@hotmail.com... > Hi, > > Changelog: > mshtml: Implement IHTMLDocument5 createComment > > Best Regards > Alistair Leslie-Hughes > > > > -------------------------------------------------------------------------------- > From 98f08b3836336d2f129413beada591fb8f2f1094 Mon Sep 17 00:00:00 2001 > From: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > Date: Tue, 16 Dec 2008 21:49:25 +1100 > Subject: [PATCH] Implement IHTMLDocument5 createComment > To: wine-patches <wine-patches(a)winehq.org> > > --- > dlls/mshtml/htmldoc5.c | 28 ++++++++++++++++++++++++++-- > dlls/mshtml/tests/dom.c | 11 +++++++++++ > 2 files changed, 37 insertions(+), 2 deletions(-) > > diff --git a/dlls/mshtml/htmldoc5.c b/dlls/mshtml/htmldoc5.c > index 34dc4e0..8fdfb68 100644 > --- a/dlls/mshtml/htmldoc5.c > +++ b/dlls/mshtml/htmldoc5.c > @@ -124,8 +124,32 @@ static HRESULT WINAPI > HTMLDocument5_createComment(IHTMLDocument5 *iface, BSTR bs > IHTMLDOMNode **ppRetNode) > { > HTMLDocument *This = HTMLDOC5_THIS(iface); > - FIXME("(%p)->(%s %p)\n", This, debugstr_w(bstrdata), ppRetNode); > - return E_NOTIMPL; > + nsIDOMComment *nsComment; > + HTMLDOMNode *node; > + nsAString str; > + nsresult nsres; > + > + TRACE("(%p)->(%s %p)\n", This, debugstr_w(bstrdata), ppRetNode); > + > + if(!This->nsdoc) { > + WARN("NULL nsdoc\n"); > + return E_UNEXPECTED; > + } > + > + nsAString_Init(&str, bstrdata); > + nsres = nsIDOMHTMLDocument_CreateComment(This->nsdoc, &str, > &nsComment); > + nsAString_Finish(&str); > + if(NS_FAILED(nsres)) { > + ERR("CreateTextNode failed: %08x\n", nsres); > + return E_FAIL; > + } > + > + node = &HTMLCommentElement_Create(This, > (nsIDOMNode*)nsComment)->node; > + nsIDOMElement_Release(nsComment); > + > + *ppRetNode = HTMLDOMNODE(node); > + IHTMLDOMNode_AddRef(HTMLDOMNODE(node)); > + return S_OK; > } > > static HRESULT WINAPI HTMLDocument5_put_onfocusin(IHTMLDocument5 *iface, > VARIANT v) > diff --git a/dlls/mshtml/tests/dom.c b/dlls/mshtml/tests/dom.c > index 3decd4b..400f83b 100644 > --- a/dlls/mshtml/tests/dom.c > +++ b/dlls/mshtml/tests/dom.c > @@ -410,7 +410,9 @@ static IHTMLDocument2 *create_document(void) > { > IHTMLDocument2 *doc; > IHTMLDocument5 *doc5; > + IHTMLDOMNode *comment; > HRESULT hres; > + BSTR str; > > hres = CoCreateInstance(&CLSID_HTMLDocument, NULL, > CLSCTX_INPROC_SERVER|CLSCTX_INPROC_HANDLER, > &IID_IHTMLDocument2, (void**)&doc); > @@ -423,6 +425,15 @@ static IHTMLDocument2 *create_document(void) > return NULL; > } > > + str = a2bstr("testing"); > + hres = IHTMLDocument5_createComment(doc5, str, &comment); > + SysFreeString(str); > + ok(hres == S_OK, "createComment failed: %08x\n", hres); > + if(hres == S_OK) > + { > + IHTMLDOMNode_Release(comment); > + } > + > IHTMLDocument5_Release(doc5); > return doc; > } > -- > 1.5.4.3 > > -------------------------------------------------------------------------------- > >

2 1

Re: user32: Check for bad scroll value and fix return values inEDIT_EM_Scroll
by Alistair Leslie-Hughes 15 Jan '09

15 Jan '09

Hi, Can I get some feedback on this please? Best Regards Alistair Leslie-Hughes "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote in message news:496DB2F4.2020505@hotmail.com... > Hi, > > Based on a patch by David Hedberg and later Austin English. > Fixes bug 1517. > Corrected test and corrected tab/space issues. > > > Changelog: > user32: Check for bad scroll value and fix return values in EDIT_EM_Scroll > > Best Regards > Alistair Leslie-Hughes > > > > > > -------------------------------------------------------------------------------- > From 398cc9b765070ee10dd429b55f6c3b0cdb5bcc46 Mon Sep 17 00:00:00 2001 > From: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > Date: Wed, 14 Jan 2009 20:33:08 +1100 > Subject: [PATCH] Check for bad scroll value and fix return values in > EDIT_EM_Scroll > To: wine-patches <wine-patches(a)winehq.org> > > --- > dlls/user32/edit.c | 18 +++++++++++--- > dlls/user32/tests/edit.c | 55 > ++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 69 insertions(+), 4 deletions(-) > > diff --git a/dlls/user32/edit.c b/dlls/user32/edit.c > index 6914906..4cd1497 100644 > --- a/dlls/user32/edit.c > +++ b/dlls/user32/edit.c > @@ -3430,13 +3430,23 @@ static LRESULT EDIT_EM_Scroll(EDITSTATE *es, INT > action) > INT vlc = get_vertical_line_count(es); > /* check if we are going to move too far */ > if(es->y_offset + dy > es->line_count - vlc) > - dy = es->line_count - vlc - es->y_offset; > + { > + dy = es->line_count - vlc - es->y_offset; > + > + /* Make sure we're not trying to scroll backwards here */ > + if(es->y_offset + dy < 0) > + dy = 0; > + } > > - /* Notification is done in EDIT_EM_LineScroll */ > - if(dy) > + /* Notification is done in EDIT_EM_LineScroll */ > + if(dy) > EDIT_EM_LineScroll(es, 0, dy); > } > - return MAKELONG((INT16)dy, (BOOL16)TRUE); > + > + if(dy) > + return MAKELONG((INT16)dy, (BOOL16)TRUE); > + else > + return (LRESULT)FALSE; > } > > > diff --git a/dlls/user32/tests/edit.c b/dlls/user32/tests/edit.c > index b1a9820..ec4759e 100644 > --- a/dlls/user32/tests/edit.c > +++ b/dlls/user32/tests/edit.c > @@ -1205,6 +1205,60 @@ static void test_edit_control_5(void) > DestroyWindow(hWnd); > } > > +static void test_edit_control_6(void) > +{ > + HWND hwEdit; > + LONG r; > + > + static const char *single_line_str = "a"; > + static const char *multiline_str = "Test\nText"; > + > + /* Check the return value when EM_SCROLL doesn't actually scroll > anything. */ > + > + hwEdit = CreateWindow( > + "EDIT", > + single_line_str, > + WS_VSCROLL | ES_MULTILINE, > + 1, 1, 35, 35, > + NULL, NULL, hinst, NULL); > + > + assert(hwEdit); > + > + trace("EDIT: Scrolling down one page \n"); > + r = SendMessage(hwEdit, EM_SCROLL, SB_PAGEDOWN, 0); > + ok(!r, "Returned %x\n", r); > + > + trace("EDIT: Scrolling up one page \n"); > + r = SendMessage(hwEdit, EM_SCROLL, SB_PAGEUP, 0); > + ok(!r, "Returned %x\n", r); > + > + trace("EDIT: Scrolling up one line\n"); > + r = SendMessage(hwEdit, EM_SCROLL, SB_LINEUP, 0); > + ok(!r, "Returned %x\n", r); > + > + trace("EDIT: Scrolling down one line\n"); > + r = SendMessage(hwEdit, EM_SCROLL, SB_LINEDOWN, 0); > + ok(!r, "Returned %x\n", r); > + > + DestroyWindow (hwEdit); > + > + /* Check for bug in wine where sending SB_PAGEDOWN causes > + EDIT_EM_Scroll to return a negative amount of scrolled lines. */ > + > + hwEdit = CreateWindow( > + "EDIT", > + multiline_str, > + ES_MULTILINE, > + 0, 0, 50, 1000, > + NULL, NULL, hinst, NULL); > + assert(hwEdit); > + > + r = SendMessage(hwEdit, EM_SCROLL, SB_PAGEDOWN, 0); > + ok(!r, "Returned %x\n", r); > + > + DestroyWindow (hwEdit); > +} > + > static void test_edit_control_limittext(void) > { > HWND hwEdit; > @@ -2058,6 +2112,7 @@ START_TEST(edit) > test_edit_control_3(); > test_edit_control_4(); > test_edit_control_5(); > + test_edit_control_6(); > test_edit_control_limittext(); > test_margins(); > test_margins_font_change(); > -- > 1.5.4.3 > > -------------------------------------------------------------------------------- > >

1 0

Wine being targeted for adware
by Jeff Zaroyko 15 Jan '09

15 Jan '09

http://philosecurity.org/2009/01/12/interview-with-an-adware-author In an interesting interview, former adware author Matt Knox mentions that he was able to run his adware client on Wine: S: In your professional opinion, how can people avoid adware? M: Um, run UNIX. S: [ laughs] M: We did actually get the ad client working under Wine on Linux. S: That seems like a bit of a stretch! M: That was a pretty limited market, I'd say.

7 12

Re: iphplpai/ipstats.c: only use RTF_MULTICAST if available (try 2)
by James Hawkins 15 Jan '09

15 Jan '09

On Thu, Jan 15, 2009 at 12:48 PM, Austin English <austinenglish(a)gmail.com> wrote: > RTF_MULTICAST isn't available on NetBSD/OpenBSD (possibly others) > > Changelog: > Moved to a #define 0 at the top of the file to get rid of ugly ifdef's > Forgot the patch. -- James Hawkins

1 0

Re: Wine runs IE7!
by James Mckenzie 15 Jan '09

15 Jan '09

Austin English <austinenglish(a)gmail.com> wrote: >Sent: Jan 15, 2009 1:04 PM >To: Michael Stefaniuc <mstefani(a)redhat.com> >Cc: James Mckenzie <jjmckenzie51(a)earthlink.net>, wine-devel(a)winehq.org >Subject: Re: Wine runs IE7! > >On Thu, Jan 15, 2009 at 1:53 PM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: >> James Mckenzie wrote: >>> Hans Leidekker <hans(a)codeweavers.com> >>>> Sent: Jan 15, 2009 10:45 AM >>>> To: wine-devel(a)winehq.org >>>> Subject: Wine runs IE7! >>>> >>>> >>>> Well, sort of. I found bugs in shell32, rpcrt4, comctl32 and wininet >>>> that I had to implement, stub and override my way past before it would >>>> render a page, but finally, here's the obligatory screenshot. >>> >>> Good work. Now where are those patches....;-) >> You know you can look it up yourself? >> git log --author="Hans Leidekker" origin/master >> > >Correct me if I'm wrong, but I don't think all the patches are in yet: >http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=author&s=Hans+Lei… > >Looking through the first couple pages, I don't see any comctl32 patches. > Boy, talk about folks taking a joke the wrong way. The wink should have been a hint. I'm happy that Hans got IE 7 working and installed. I also think there is more work to be done before it can be fully used and then there should be patches submitted to implement this either in Wine Gecko or to allow installation of this product in Wine. Again, good job Hans and thank you for the screen shot showing IE7 can work with Wine. James McKenzie

1 0

Re: Wine runs IE7!
by James Mckenzie 15 Jan '09

15 Jan '09

Hans Leidekker <hans(a)codeweavers.com> >Sent: Jan 15, 2009 10:45 AM >To: wine-devel(a)winehq.org >Subject: Wine runs IE7! > > >Well, sort of. I found bugs in shell32, rpcrt4, comctl32 and wininet >that I had to implement, stub and override my way past before it would >render a page, but finally, here's the obligatory screenshot. Good work. Now where are those patches....;-) James McKenzie

3 2

Re: Running a simple .Net 3.0 application.
by James Mckenzie 15 Jan '09

15 Jan '09

Steven Edwards <winehacker(a)gmail.com> wrote: > >On Wed, Jan 14, 2009 at 3:59 PM, Louis Lenders ><xerox_xerox2000(a)yahoo.co.uk> wrote: >> gdi32.GdiEntry13 >> kernel32.WerRegisterMemoryBlock >> ntdll.NtSecureConnectPort >> ntdll.RtlEnumerateGenericTableWithoutSplaying >> ntdll.RtlIsGenericTableEmpty >> >> Well, that was enough to get the app running. >> I was not able to work around a problem in d3d9 ( the app just hang, >> displaying nothing, probably due to some unimplemented stuff in d3d9) >> but fortunaly disabling d3d9, was enough to get it running >> (WINEDLLOVERRIDES="d3d9=""" wine AnimatedApplication.exe) >> >> I'm not sure if it would be useful to open bugs already for the >> unimplemented functions. If so, just shout, and i'll open some bugs. > >Or you can send diff's ;) > Be very careful with this type of request. It would be better to send in a bug report with the unimplemented functions and what they are supposed to do and then have another do the actual code builds. That keeps the code base 'clean'. James McKenzie

3 2

Fwd: Draft XI 2 protocol specification
by Roderick Colenbrander 15 Jan '09

15 Jan '09

Hi Vitaliy, Peter Hutterer has submitted a draft specification of Xinput2 to the xorg mailinglist. As you know it will offer relative mouse movements. He is asking for feedback. Since I have no experience with Xinput you might want to review it and see if it works out for Wine. Roderick -------- Original-Message-------- From: Peter Hutterer <peter.hutterer(a)who-t.net> To: "X.Org List" <xorg(a)lists.freedesktop.org> CC: Daniel Stone <daniel(a)fooishbar.org> Subject: Draft XI 2 protocol specification I know we're all thinking about getting 1.6 out, but here's the next lot of big changes that I really need some feedback on. LCA is coming up and napkins want to be written on, so the more feedback before that happens, the better. As a friendly reminder, the X Protocol has a tendency to be set in stone, so if you don't speak up now you will have to explain yourself to your grandchildren why GUI's still suck. Short story long, X Input 2.0 is in the making and should come out with server 1.7 somewhen later this decade. Server 1.6 has all the internal changes but doesn't expose anything to the clients. So far, I have bits and pieces of XI2 that compile and henceforth are bug-free. But I need your review is needed, before I go further down a dead end. Some clarification: XI2 ........ X Input Extension version 2.0 Protocol XI 1.x ..... X Input Extension version 1.x Protocol server 1.6 . X server version 1.6 (supports XI 1.5) server 1.7 . X server version 1.7 (will support XI 2.0) If you want to skip the background, scroll down to "Protocol Specification" == Background == The biggest change between XI 1.5 and XI 2.0 will be the master/slave device hierarchy being visible to the client and the ability to create additional master devices (i.e. cursors/keyboard foci). The current state of XI2 in master is that we're using the XI 1.x events plus a few new ones (some of which are GenericEvents) and we have a few new requests. This has some shortcomings: - XI 1.x events are "full", there is no more space in the 32 bytes that allow for more data. - XI 1.x events suck for event registration. It is not possible to just register for motion events, you have to open all devices, get the class, etc. - The pointer/keyboard distinction is not really a good idea these days, many devices are both. - XI 1.x does not allow for both rel+abs axes on a device. - Subpixel precision only for absolute valuators. - Static input devices. Devices cannot change capabilities (e.g. add an axis) at runtime. - Keycode range 255. This is also a limitation with XKB. == Protocol Specification == Basically the idea is to provide GenericEvents for *all* XI2 events, even those covered through XI 1.x. Which means that we have another API to support for those clients that keep using XI 1. This however can be achieved in a similar fashion to the core emulation we already do anyway. Why? GenericEvent have a length-field, so we can keep extending in future versions without having to modify the client. Clients are expected to read the full event off the wire, but only access the fields that they know of, allowing us to tack on data to the end of the event. Below is the preliminary specification for those XI2 events I was planning to add/implement for XI 2.0. If anything doesn't make sense, is missing, etc. please state so. I am not yet covering requests, this is events only for now. In the remainder of this email, the following notation is used ┌─── Name of event name of field: type of field name of field: type of field ─── name of field: type of field └─── Where ─── denotes the 32 byte boundary of the event, padded accordingly if necessary. Fields after ─── require the event to have a length greater than 0. If ─── is missing, the event is exactly 32 bytes long. ┌─── XIGenericDeviceEvent type: BYTE extension: BYTE sequenceNumber: CARD16 length: CARD32 evtype: CARD16 deviceid: CARD16 time: CARD32 └─── XGenericDeviceEvent is the generic header for all XI 2 events. type is always GenericEvent. extension is always the X Input extension offset. evtype is the XI-specific event type. For brevity, this information is specified as GENERICEVENTDATA in the following events. ┌─── XIDeviceHierarchyEvent: GENERICEVENTDATA flags: SETofHIERARCHYMASK ndevices: CARD16 ─── devices: LISTofINT16 └─── HIERARCHYMASK { MasterAdded, MasterRemoved, SlaveAttached, SlaveDetached, SlaveAdded, SlaveRemoved } type is XI_HierarchyChangedNotify. flags specifies all types of hierarchy modifiations that have occured. ndevices specifies the number of devices. devices is the list of all devices affected by this hierarchy change. An XDeviceHierarchyChangedEvent is sent whenever the device hierarchy has been changed by either the client, or by server-internal events. The flags specify all types of hierarchy modifiations that have occured. Clients are expected to query the server for the new hierarchy. Note: Because multiple modification affecting multiple devices may take place in one request, deviceid in an XDeviceHierarchyChangedEvent is always the first affected device. Clients should ignore deviceid and instead use the devices list. ┌─── XIDeviceChangedEvent: GENERICEVENTDATA num_classes: CARD8 new_slave: BOOL slaveid: CARD16 ─── classes: LISTofINPUTINFO └─── type is XI_DeviceChangedNotify. Sent whenever an MD changes due to a new SD sending events through it. - new_slave is TRUE, slavedi is the deviceid of the new SD. Sent whenever a device changes any of its classes. - new_slave is FALSE, slaveid is undefined. Classes is a list of input device classes that are now provided by the device, see XI 1.x specification for more details. ┌─── XIDeviceEvent: GENERICEVENTDATA detail: CARD32 root: Window event: Window child: Window ─── root_x: CARD32 root_y: CARD32 event_x: CARD32 event_y: CARD32 last_button: CARD16 last_modifier: CARD16 last_valuator: CARD16 sourceid: CARD16 buttons: SETofBUTTONBIT modifiers: SETofMODIFIERBIT valuators: SETofVALUATORBIT axisvalues: LISTofCARD32 └─── BUTTONBIT { (1 << Button1), (1 << Button2), ... , (1 << ButtonN) } MODIFIERBIT { ShiftMask, LockMask, ControlMask, Mod1Mask, ... , ModNMask } VALUATORBIT { (1 << 1), ( 1 << 2), ... ( 1 << n) } SETofBUTTONBIT, SETofMODIFIERBIT and SETofVALUTORBIT are always padded to 4 bytes. Generic event structure for motion, button and key events. type is one of XI_ButtonPress, XI_ButtonRelease, XI_KeyPress, XI_KeyRelease, XI_Motion, XI_Proximity. detail is the button number or key code, or 0. root, event, child are the root window, event window or subwindow, respectively. See core protocol spec for more detail. root_x, root_y is the position of the pointer in screen coordinates event_x, event_y is the position of the pointer in screen coordinates relative to the event window. last_button is the highest bit set in buttons and determines the size of buttons. last_modifier is the highest bit set in modifiers and determines the size of modifiers. last_valuator is the highest bit set in valuators and determines the size of valuators sourceid is the device id of the SD that generated the event. buttons is the button state before the event, with a button mask set if the matching button is down. modifiers is the modifier state before the event, with a modifier mask set if the matching modifier is down. valuators specifies which valuators are provided in this event. If a valuator's mask is specified, the valuator is provided in axisvalues. axisvalues specifies the current value of the valuator in it's current mode (relative or absolute). ┌─── XRelativeMotionEvent GENERICEVENTDATA last_button: CARD16 last_modifier: CARD16 last_valuator: CARD16 sourceid: CARD16 ─── buttons: SETofBUTTONBIT modifiers: SETofMODIFIERBIT valuators: SETofVALUATORBIT axisvalues: LISTofCARD32 └─── Relative Motion event. type is XI_RelativeMotion This event is sent regardless of clipping and always provides the device-specific data. Pointer acceleration does not affect the axis values. All fields are equivalent to the respective fields in the XDeviceEvent. ┌─── XIPresence GENERICEVENTDATA devchange: SETofDEVICECHANGE control: CARD16 └─── DEVICECHANGE { DeviceAdded, DeviceRemoved, DeviceEnabled, DeviceDisabled, DeviceControlChanged } DevicePresence event, equivalent to the XI 1.4 event. type is XI_PresenceNotify devchange specifies the type of device change that has occured. If devchange is DeviceControlChanged, control specifies the ID of the device control that has changed. Otherwise, control is unspecified. The length of a Presence event is always 0. === Current Status === The current status is that I have switched parts of the server over to generate and process XI2 events (it requires *a lot* of changes, but also cleans the server up a bit). I'm not sure about the following things: - modifiers. daniel, can you chime in here how to solve this the best way? - device controls in XI2? Really? (see Presence event) - this isn't fixing the problem we have with devices that are both pointers and keyboards - how do go about input classes. refurbish them? - having 16 bit device ids requires to re-implement all requests and replies. Mostly just typing, but it has to be done. - 32 bit keycodes is good but requires XKB2. I think. Daniel? - still no subpixel precision, unless we decide to make the valuators 24.8, or provide 32+32 or something. - am I heading down a dead end? - is it beer o'clock yet? Cheers, Peter _______________________________________________ xorg mailing list xorg(a)lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

3 2

re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
by Dan Kegel 15 Jan '09

15 Jan '09

FWIW, my opinion is that any deep integration is going to be hard, and that for the moment we should go with something much simpler: simply support mstheme files well, and provide themes that look like the default themes on Ubuntu / OpenSuse / Fedora.

6 15

Re: oleaut32/tests: add tests for OleLoadPictureFile(Ex) and OleLoadPicturePath (resend) [2/2]
by Jeremy Drake 15 Jan '09

15 Jan '09

On Mon, 5 Jan 2009, Jeremy Drake wrote: > > --- > dlls/oleaut32/tests/olepicture.c | 321 ++++++++++++++++++++++++++++++++++++++ > 1 files changed, 321 insertions(+), 0 deletions(-) > Is there anything wrong with these two patches? I'd really like to see these tests go in, so hopefully someone will decide to tackle this olepicture stuff. At the very least, putting the stubs in for OleLoadPictureFile (patch 1/2) keeps my app from crashing...

2 4

Re: Wine being targeted for adware
by James Mckenzie 14 Jan '09

14 Jan '09

Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: >In an interesting interview, former adware author Matt Knox mentions >that he was able to run his adware client on Wine: > >S: In your professional opinion, how can people avoid adware? >M: Um, run UNIX. > >S: [ laughs] >M: We did actually get the ad client working under Wine on Linux. > >S: That seems like a bit of a stretch! >M: That was a pretty limited market, I'd say. > One: This shows how well we run Windows programs. Two: The last comment should show how much respect we have in the community. Things have changed since the release of Wine 1.0, but we have a long way to go to be on every Linux desktop and most of the MacIntosh community. However, we should attempt to block adware as a matter of policy? That is up to the Wine User Community and not based on the opinions of one or two people. I for one would like to see if this is possible and feasible. I do know that some of the virus testing community are using Wine as a Virtual Machine to see how much damage can be done by viruses in that environment. James McKenzie

3 2

Yearly commit statistics
by Zachary Goldberg 14 Jan '09

14 Jan '09

All, I received an email in response to the top article in WWN 355 about generating commit stats. See below. > I just saw that you used "git log" with some funny > options to filter out certain dates... You might be interested in the > --min-age and --max-age options, which have been there almost forever. Useful? -Zach

2 1

Re: [PATCH] quartz: Add a filtergraph test for mpeg files.
by Paul Vriens 14 Jan '09

14 Jan '09

Lei Zhang wrote: > Hi, > > I cleaned up dlls/quartz/tests/filtergraph.c a bit so we can drop in a > 'test.mpg' file and test the rendering of MPEG files. > > > ------------------------------------------------------------------------ > > Please stick to the CreateFileA (instead of W) to have these tests run on win9x. -- Cheers, Paul.

2 1

Re: shell32: Implement ordinal 704, also known as GUIDFromStringW.
by Juan Lang 14 Jan '09

14 Jan '09

Hi Hans, + 704 stdcall @(wstr ptr) SHELL32_704 # GUIDFromStringW Out of curiosity, what's the reason for using SHELL32_704 as the name, instead of GUIDFromStringW? --Juan

5 5

Re: [1/2] richedit: Clip painting to formatting rectangle (try 2)
by Alexandre Julliard 14 Jan '09

14 Jan '09

Dylan Smith <dylan.ah.smith(a)gmail.com> writes: > @@ -29,6 +29,17 @@ void ME_PaintContent(ME_TextEditor *editor, HDC hDC, BOOL bOnlyNew, const RECT * > ME_Context c; > int yoffset; > int ys, ye; > + HRGN oldRgn, clipRgn; > + > + oldRgn = CreateRectRgn(0, 0, 0, 0); > + if (!GetClipRgn(hDC, oldRgn)) > + { > + DeleteObject(oldRgn); > + oldRgn = NULL; > + } > + clipRgn = CreateRectRgnIndirect(rcUpdate); > + ExtSelectClipRgn(hDC, clipRgn, RGN_AND); > + DeleteObject(clipRgn); IntersectClipRect would be a lot easier. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [setupapi/tests] Fix some test failures on win9x
by Alexandre Julliard 14 Jan '09

14 Jan '09

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > Win9x returns the system directory instead of system32. Decided against using > broken() for this but could be convinced otherwise ;). GetSystemDirectory is probably better. -- Alexandre Julliard julliard(a)winehq.org

1 0

Functions that should be static
by Francois Gouget 14 Jan '09

14 Jan '09

I have attached a script that identifies functions that should be made static (among other things). There are approximately 450 of them, there should be pretty efw false positives, and I will look into them eventually. But if someone beats me to it I sure won't complain <g>. So if you do try to tackle them you are likely to find that they fall into one of the following categories: 1) Unused debug functions. For instance for dumping the contents of a structure to stderr. Although these are unused we probably want to keep them. Let me know about these and I will put them in an exception list. 2) Functions that should be exported by a spec file It happens. Sometimes the developer implementing a function just forgets to add it to the spec file! 3) Generated functions This typically happens with widl: it generates a bunch of functions for the client / server and proxy cases, but these functions may be unused. I have special code to not warn about these, but there may be other cases. For instance in the list below you will find a number of yy*() functions generated by lex. Either we can tell lex to make them static or to not generate them, or I should make another special case. If you find some of these, let me know. 4) Assembly functions I believe there should not be any of these in the list below. So if you find one let me know. 5) Functions declared in a private header file but implemented and used from a single C file. I'm in favor of removing these functions from the private header and making them static. 6) All the others should be pretty clear-cut. dlls/advapi32/advapi32.dll.so: CRYPT_DESkey8to7 dlls/browseui/tests/browseui_test.exe.so: strdup_AtoW dlls/browseui/tests/browseui_test.exe.so: TestACL_ACList_AddRef dlls/browseui/tests/browseui_test.exe.so: TestACL_ACList_QueryInterface dlls/browseui/tests/browseui_test.exe.so: TestACL_ACList_Release dlls/browseui/tests/browseui_test.exe.so: TestACL_AddRef dlls/browseui/tests/browseui_test.exe.so: TestACL_Clone dlls/browseui/tests/browseui_test.exe.so: TestACL_Expand dlls/browseui/tests/browseui_test.exe.so: TestACL_Next dlls/browseui/tests/browseui_test.exe.so: TestACL_QueryInterface dlls/browseui/tests/browseui_test.exe.so: TestACL_Release dlls/browseui/tests/browseui_test.exe.so: TestACL_Reset dlls/browseui/tests/browseui_test.exe.so: TestACL_Skip dlls/cabinet/cabinet.dll.so: checksum dlls/cabinet/cabinet.dll.so: make_decode_table dlls/cabinet/cabinet.dll.so: QTMupdatemodel dlls/comctl32/tests/comctl32_test.exe.so: flush_sequence dlls/comdlg32/comdlg32.dll.so: CC_WMCommand dlls/crypt32/crypt32.dll.so: ContextList_Empty dlls/dbghelp/dbghelp.dll.so: hash_table_find dlls/dbghelp/dbghelp.dll.so: hash_table_hash dlls/dbghelp/dbghelp.dll.so: module_find_by_name dlls/dbghelp/dbghelp.dll.so: module_get_container dlls/dinput/dinput.dll.so: DIEnumDevicesCallbackAtoW dlls/dmime/dmime.dll.so: DMUSIC_CreateDirectMusicobjImpl dlls/dmime/dmime.dll.so: DMUSIC_CreateDirectMusicPatternTrackImpl dlls/dmusic/dmusic.dll.so: DMUSIC_CreateDirectMusicBufferImpl dlls/dmusic/dmusic.dll.so: DMUSIC_CreateDirectMusicDownloadedInstrumentImpl dlls/dmusic/dmusic.dll.so: DMUSIC_CreateDirectMusicDownloadImpl dlls/dnsapi/dnsapi.dll.so: dns_ns_name_pton dlls/dplayx/dplayx.dll.so: cbDeleteGroupsElem dlls/dplayx/dplayx.dll.so: cbDeletePlayerElem dlls/dplayx/dplayx.dll.so: DPLAYX_DestroyLobbyApplication dlls/dplayx/dplayx.dll.so: DPLAYX_SetLocalSession dlls/dplayx/dplayx.dll.so: NS_GetOtherMagic dlls/dplayx/dplayx.dll.so: NS_SetRemoteComputerAsNameServer dlls/dsound/dsound.dll.so: DirectSoundCaptureDevice_AddRef dlls/fusion/fusion.dll.so: assembly_get_architecture dlls/fusion/fusion.dll.so: CompareAssemblyIdentity dlls/fusion/fusion.dll.so: GetAssemblyIdentityFromFile dlls/inetcomm/inetcomm.dll.so: InternetTransport_Read dlls/iphlpapi/iphlpapi.dll.so: getInterfaceEntryByIndex dlls/iphlpapi/iphlpapi.dll.so: getInterfacePhysicalByName dlls/itss/itss.dll.so: chm_enumerate dlls/jscript/jscript.dll.so: jsdisp_call dlls/jscript/jscript.dll.so: parser_parse dlls/mountmgr.sys/mountmgr.sys.so: DriverEntry dlls/msacm32/msacm32.dll.so: MSACM_UnregisterLocalDriver dlls/mshtml/mshtml.dll.so: HTMLElementCollection_Create dlls/msi/msi.dll.so: cond_parse dlls/msi/msi.dll.so: ControlEvent_UnSubscribeToEvent dlls/msi/msi.dll.so: db_get_raw_stream dlls/msi/msi.dll.so: encode_streamname dlls/msi/msi.dll.so: find_published_source dlls/msi/msi.dll.so: MSI_DatabaseExport dlls/msi/msi.dll.so: MSI_DatabaseImport dlls/msi/msi.dll.so: msi_dialog_register_class dlls/msi/msi.dll.so: MSI_EnableUIPreview dlls/msi/msi.dll.so: msi_id2stringA dlls/msi/msi.dll.so: msi_id2stringW dlls/msi/msi.dll.so: msi_load_media_info dlls/msi/msi.dll.so: MSI_PreviewDialogW dlls/msi/msi.dll.so: MSI_RecordDataSize dlls/msi/msi.dll.so: MSI_RecordSetStream dlls/msi/msi.dll.so: MSI_RecordSetStringA dlls/msi/msi.dll.so: MSIREG_OpenInstallerFeaturesKey dlls/msi/msi.dll.so: msi_strcmp dlls/msi/msi.dll.so: msi_string2idA dlls/msi/msi.dll.so: msi_ui_error dlls/msi/msi.dll.so: msi_version_dword_to_str dlls/msi/msi.dll.so: reduce_to_shortfilename dlls/msi/msi.dll.so: sql_parse dlls/msxml3/msxml3.dll.so: httprequest_Release dlls/msxml3/msxml3.dll.so: XMLElementCollection_create dlls/netapi32/netapi32.dll.so: NBNameCacheUpdateNBName dlls/ole32/ole32.dll.so: IMalloc16_Constructor dlls/qcap/qcap.dll.so: FreeMediaType dlls/qcap/qcap.dll.so: IPinImpl_QueryInternalConnections dlls/quartz/quartz.dll.so: MemInputPin_AddRef dlls/quartz/quartz.dll.so: MemInputPin_GetAllocator dlls/quartz/quartz.dll.so: MemInputPin_GetAllocatorRequirements dlls/quartz/quartz.dll.so: MemInputPin_NotifyAllocator dlls/quartz/quartz.dll.so: MemInputPin_QueryInterface dlls/quartz/quartz.dll.so: MemInputPin_Receive dlls/quartz/quartz.dll.so: MemInputPin_ReceiveCanBlock dlls/quartz/quartz.dll.so: MemInputPin_ReceiveMultiple dlls/quartz/quartz.dll.so: MemInputPin_Release dlls/quartz/quartz.dll.so: OutputPin_DeliverNewSegment dlls/riched20/riched20.dll.so: ME_ConcatString dlls/riched20/riched20.dll.so: ME_CopyToCF2W dlls/riched20/riched20.dll.so: ME_DestroyEditor dlls/riched20/riched20.dll.so: ME_DITypesEqual dlls/riched20/riched20.dll.so: ME_DrawParagraph dlls/riched20/riched20.dll.so: ME_FindItemFwdOrHere dlls/riched20/riched20.dll.so: ME_FindNextURLCandidate dlls/riched20/riched20.dll.so: ME_FindRowStart dlls/riched20/riched20.dll.so: ME_GetOptimalBuffer dlls/riched20/riched20.dll.so: ME_GetParaFormat dlls/riched20/riched20.dll.so: ME_GetYScrollVisible dlls/riched20/riched20.dll.so: ME_InvalidateFromOfs dlls/riched20/riched20.dll.so: ME_IsCandidateAnURL dlls/riched20/riched20.dll.so: ME_LinkNotify dlls/riched20/riched20.dll.so: ME_MakeEditor dlls/riched20/riched20.dll.so: ME_MakeStringB dlls/riched20/riched20.dll.so: ME_MarkForWrapping dlls/riched20/riched20.dll.so: ME_QueueInvalidateFromCursor dlls/riched20/riched20.dll.so: ME_Scroll dlls/riched20/riched20.dll.so: ME_SelectByType dlls/riched20/riched20.dll.so: ME_SetParaFormat dlls/riched20/riched20.dll.so: ME_ToCFAny dlls/riched20/riched20.dll.so: ME_UpdateLinkAttribute dlls/riched20/riched20.dll.so: ME_UpdateSelection dlls/riched20/riched20.dll.so: ME_UpdateSelectionLinkAttribute dlls/riched20/riched20.dll.so: REComboWndProc dlls/riched20/riched20.dll.so: REListWndProc dlls/riched20/riched20.dll.so: RTFExpandStyle dlls/riched20/riched20.dll.so: RTFGetClassCallback dlls/riched20/riched20.dll.so: RTFGetDestinationCallback dlls/riched20/riched20.dll.so: RTFGetInputName dlls/riched20/riched20.dll.so: RTFGetOutputName dlls/riched20/riched20.dll.so: RTFGetReadHook dlls/riched20/riched20.dll.so: RTFGetStyle dlls/riched20/riched20.dll.so: RTFHexToChar dlls/riched20/riched20.dll.so: RTFPeekToken dlls/riched20/riched20.dll.so: RTFSetClassCallback dlls/riched20/riched20.dll.so: RTFSetInputName dlls/riched20/riched20.dll.so: RTFSetOutputName dlls/riched20/riched20.dll.so: RTFSetToken dlls/riched20/riched20.dll.so: RTFUngetToken dlls/rpcrt4/rpcrt4.dll.so: NCA2RPC_STATUS dlls/rpcrt4/rpcrt4.dll.so: NdrByteCountPointerMemorySize dlls/rpcrt4/rpcrt4.dll.so: NdrRangeBufferSize dlls/rpcrt4/rpcrt4.dll.so: NdrRangeFree dlls/rpcrt4/rpcrt4.dll.so: NdrRangeMarshall dlls/rpcrt4/rpcrt4.dll.so: NdrRangeMemorySize dlls/rpcrt4/rpcrt4.dll.so: RPCRT4_receive_fragment dlls/rpcrt4/rpcrt4.dll.so: RPCRT4_SpawnConnection dlls/rpcrt4/rpcrt4.dll.so: RPCRT4_ValidateCommonHeader dlls/rsaenh/rsaenh.dll.so: alloc_handle_table dlls/rsaenh/rsaenh.dll.so: mp_2expt dlls/rsaenh/rsaenh.dll.so: mp_abs dlls/rsaenh/rsaenh.dll.so: mp_add_d dlls/rsaenh/rsaenh.dll.so: mp_clamp dlls/rsaenh/rsaenh.dll.so: mp_clear dlls/rsaenh/rsaenh.dll.so: mp_cmp_mag dlls/rsaenh/rsaenh.dll.so: mp_cnt_lsb dlls/rsaenh/rsaenh.dll.so: mp_div dlls/rsaenh/rsaenh.dll.so: mp_div_2 dlls/rsaenh/rsaenh.dll.so: mp_div_2d dlls/rsaenh/rsaenh.dll.so: mp_div_d dlls/rsaenh/rsaenh.dll.so: mp_dr_reduce dlls/rsaenh/rsaenh.dll.so: mp_dr_setup dlls/rsaenh/rsaenh.dll.so: mp_exch dlls/rsaenh/rsaenh.dll.so: mp_grow dlls/rsaenh/rsaenh.dll.so: mp_init dlls/rsaenh/rsaenh.dll.so: mp_init_size dlls/rsaenh/rsaenh.dll.so: mp_lshd dlls/rsaenh/rsaenh.dll.so: mp_mod_2d dlls/rsaenh/rsaenh.dll.so: mp_mod_d dlls/rsaenh/rsaenh.dll.so: mp_montgomery_calc_normalization dlls/rsaenh/rsaenh.dll.so: mp_montgomery_reduce dlls/rsaenh/rsaenh.dll.so: mp_montgomery_setup dlls/rsaenh/rsaenh.dll.so: mp_mul_2 dlls/rsaenh/rsaenh.dll.so: mp_mul_2d dlls/rsaenh/rsaenh.dll.so: mp_mul_d dlls/rsaenh/rsaenh.dll.so: mp_prime_is_divisible dlls/rsaenh/rsaenh.dll.so: mp_prime_is_prime dlls/rsaenh/rsaenh.dll.so: mp_prime_miller_rabin dlls/rsaenh/rsaenh.dll.so: mp_reduce dlls/rsaenh/rsaenh.dll.so: mp_reduce_2k dlls/rsaenh/rsaenh.dll.so: mp_reduce_2k_setup dlls/rsaenh/rsaenh.dll.so: mp_reduce_setup dlls/rsaenh/rsaenh.dll.so: mp_rshd dlls/rsaenh/rsaenh.dll.so: mp_set dlls/rsaenh/rsaenh.dll.so: mp_signed_bin_size dlls/rsaenh/rsaenh.dll.so: mp_sqr dlls/rsaenh/rsaenh.dll.so: mp_sqrmod dlls/rsaenh/rsaenh.dll.so: mp_zero dlls/rsaenh/rsaenh.dll.so: release_handle_table dlls/sane.ds/sane.ds.so: SANE_AutomaticCaptureDirectory dlls/sane.ds/sane.ds.so: SANE_FileSystemCopy dlls/sane.ds/sane.ds.so: SANE_PendingXfersStopFeeder dlls/sane.ds/sane.ds.so: SANE_SetupFileXfer2Get dlls/sane.ds/sane.ds.so: SANE_SetupFileXfer2GetDefault dlls/sane.ds/sane.ds.so: SANE_SetupFileXfer2Reset dlls/sane.ds/sane.ds.so: SANE_SetupFileXfer2Set dlls/secur32/secur32.dll.so: SECUR32_initNegotiateSP dlls/secur32/secur32.dll.so: SECUR32_strdupW dlls/setupapi/setupapi.dll.so: PARSER_string_substW dlls/setupapi/setupapi.dll.so: VcpEnumFiles dlls/setupapi/setupapi.dll.so: VcpFlush16 dlls/setupapi/setupapi.dll.so: vsmStringCompare16 dlls/setupapi/setupapi.dll.so: vsmStringFind16 dlls/shell32/shell32.dll.so: HCR_GetDefaultIconFromGUIDW dlls/shell32/shell32.dll.so: ILGetDisplayNameExA dlls/shell32/shell32.dll.so: _ILGetSTextPointer dlls/shell32/shell32.dll.so: _ILGetTextPointerW dlls/shell32/shell32.dll.so: RenderFILECONTENTS dlls/shell32/shell32.dll.so: RenderFILEDESCRIPTOR dlls/shell32/shell32.dll.so: RenderPREFEREDDROPEFFECT dlls/shell32/shell32.dll.so: RenderSHELLIDLISTOFFSET dlls/shell32/shell32.dll.so: SHILCreateFromPathA dlls/shell32/shell32.dll.so: TRASH_DisposeElement dlls/shell32/shell32.dll.so: XDG_GetPath dlls/user32/user32.dll.so: EditWndProcW dlls/user32/user32.dll.so: LookupIconIdFromDirectory16 dlls/uxtheme/uxtheme.dll.so: UXINI_ResetINI dlls/w32skrnl/w32skrnl.dll.so: _GetThunkBuff dlls/winealsa.drv/winealsa.drv.so: ALSA_PeekRingMessage dlls/winealsa.drv/winealsa.drv.so: wodSetVolume dlls/winedos/winedos.dll.so: DOSDEV_Console dlls/winedos/winedos.dll.so: DOSDEV_FindCharDevice dlls/winedos/winedos.dll.so: DOSDEV_IoctlRead dlls/winedos/winedos.dll.so: DOSDEV_IoctlWrite dlls/winedos/winedos.dll.so: DOSDEV_Peek dlls/winedos/winedos.dll.so: DOSDEV_Read dlls/winedos/winedos.dll.so: DOSDEV_Write dlls/winedos/winedos.dll.so: DOSVM_AllocCodeUMB dlls/winedos/winedos.dll.so: DOSVM_AllocUMB dlls/winedos/winedos.dll.so: DPMI_FreeInternalRMCB dlls/winedos/winedos.dll.so: VGA_SetQuadPalette dlls/winedos/winedos.dll.so: VGA_SetTextAttribute dlls/wineps.drv/wineps.drv.so: PSDRV_CmpColor dlls/wineps.drv/wineps.drv.so: PSDRV_WriteArrayGet dlls/wineps.drv/wineps.drv.so: PSDRV_WriteInitClip dlls/wineps.drv/wineps.drv.so: PSDRV_WriteRRectangle dlls/winex11.drv/winex11.drv.so: X11DRV_get_client_window dlls/winex11.drv/winex11.drv.so: X11DRV_SetupGCForPen dlls/winex11.drv/winex11.drv.so: X11DRV_window_to_X_rect dlls/winex11.drv/winex11.drv.so: X11DRV_XF86VM_SetExclusiveMode dlls/winex11.drv/winex11.drv.so: X11DRV_XRandR_Cleanup dlls/winhttp/winhttp.dll.so: netconn_set_timeout dlls/wininet/wininet.dll.so: HTTP_FinishedReading dlls/wininet/wininet.dll.so: HTTP_GetHeader dlls/wininet/wininet.dll.so: HTTP_HttpOpenRequestW dlls/wininet/wininet.dll.so: HTTP_HttpSendRequestW dlls/winmm/winmm.dll.so: MCI_DefYieldProc dlls/winmm/winmm.dll.so: MCI_GetDriverFromString dlls/winmm/winmm.dll.so: MCI_SendCommandFrom16 dlls/winmm/winmm.dll.so: MCI_SendCommandFrom32 dlls/winmm/winmm.dll.so: MCI_WriteString dlls/wintrust/wintrust.dll.so: CRYPT_AsnEncodeInt dlls/wintrust/wintrust.dll.so: WINTRUST_ReAlloc dlls/wnaspi32/wnaspi32.dll.so: ASPI_SendASPICommand dlls/wnaspi32/wnaspi32.dll.so: SCSI_GetDeviceName dlls/wuapi/wuapi.dll.so: AutomaticUpdates_create programs/cmd/cmd.exe.so: handleExpansion programs/cmd/cmd.exe.so: WCMD_addCommand programs/cmd/cmd.exe.so: WCMD_ask_confirm programs/cmd/cmd.exe.so: WCMD_dir_sort programs/cmd/cmd.exe.so: WCMD_filesize64 programs/cmd/cmd.exe.so: WCMD_opt_s_strip_quotes programs/cmd/cmd.exe.so: WCMD_parse programs/cmd/cmd.exe.so: WCMD_show_prompt programs/cmd/cmd.exe.so: WCMD_strrev programs/cmd/cmd.exe.so: WCMD_strtrim_trailing_spaces programs/oleview/oleview.exe.so: AddToStrW programs/oleview/oleview.exe.so: AddToTLDataStrW programs/oleview/oleview.exe.so: AddToTLDataStrWithTabsW programs/oleview/oleview.exe.so: CreateInstOnProc programs/oleview/oleview.exe.so: DetailsProc programs/oleview/oleview.exe.so: InterfaceViewerProc programs/oleview/oleview.exe.so: PaneProc programs/oleview/oleview.exe.so: SysConfProc programs/oleview/oleview.exe.so: TreeProc programs/oleview/oleview.exe.so: TypeLibProc programs/oleview/oleview.exe.so: WndProc programs/progman/progman.exe.so: DIALOG_Symbol programs/regedit/regedit.exe.so: GetMultiByteStringN programs/regedit/regedit.exe.so: GetRootKeyName programs/regedit/regedit.exe.so: GetWideStringN programs/regedit/regedit.exe.so: HexEdit_Unregister programs/regedit/regedit.exe.so: processRegLinesA programs/regedit/regedit.exe.so: processRegLinesW programs/taskmgr/taskmgr.exe.so: Draw3dRect programs/taskmgr/taskmgr.exe.so: Draw3dRect2 programs/taskmgr/taskmgr.exe.so: FillSolidRect2 programs/taskmgr/taskmgr.exe.so: GraphCtrl_DrawPoint programs/taskmgr/taskmgr.exe.so: GraphCtrl_InvalidateCtrl programs/taskmgr/taskmgr.exe.so: GraphCtrl_Paint programs/taskmgr/taskmgr.exe.so: GraphCtrl_Resize programs/taskmgr/taskmgr.exe.so: TrayIcon_GetProcessorUsageIcon programs/taskmgr/taskmgr.exe.so: UpdateApplicationListControlViewSetting programs/view/view.exe.so: FileIsPlaceable programs/view/view.exe.so: GetPlaceableMetaFile programs/winecfg/winecfg.exe.so: enumerate_valuesW programs/wineconsole/wineconsole.exe.so: WCUSER_AreFontsEqual programs/wineconsole/wineconsole.exe.so: WINECON_FetchCells programs/wineconsole/wineconsole.exe.so: WINECON_GetHistoryMode programs/wineconsole/wineconsole.exe.so: WINECON_SetHistoryMode programs/wineconsole/wineconsole.exe.so: WINECON_SetHistorySize programs/winedbg/winedbg.exe.so: be_cpu_build_addr programs/winedbg/winedbg.exe.so: be_cpu_linearize programs/winedbg/winedbg.exe.so: dbg_alloc programs/winedbg/winedbg.exe.so: dbg__create_buffer programs/winedbg/winedbg.exe.so: dbg__delete_buffer programs/winedbg/winedbg.exe.so: dbg__flush_buffer programs/winedbg/winedbg.exe.so: dbg_free programs/winedbg/winedbg.exe.so: dbg_get_debug programs/winedbg/winedbg.exe.so: dbg_get_in programs/winedbg/winedbg.exe.so: dbg_get_leng programs/winedbg/winedbg.exe.so: dbg_get_lineno programs/winedbg/winedbg.exe.so: dbg_get_out programs/winedbg/winedbg.exe.so: dbg_get_text programs/winedbg/winedbg.exe.so: dbg_lex_destroy programs/winedbg/winedbg.exe.so: dbg_outputA programs/winedbg/winedbg.exe.so: dbg_parse programs/winedbg/winedbg.exe.so: dbg_pop_buffer_state programs/winedbg/winedbg.exe.so: dbg_push_buffer_state programs/winedbg/winedbg.exe.so: dbg_realloc programs/winedbg/winedbg.exe.so: dbg_restart programs/winedbg/winedbg.exe.so: dbg__scan_buffer programs/winedbg/winedbg.exe.so: dbg__scan_bytes programs/winedbg/winedbg.exe.so: dbg__scan_string programs/winedbg/winedbg.exe.so: dbg_set_debug programs/winedbg/winedbg.exe.so: dbg_set_in programs/winedbg/winedbg.exe.so: dbg_set_lineno programs/winedbg/winedbg.exe.so: dbg_set_out programs/winedbg/winedbg.exe.so: dbg__switch_to_buffer programs/winedbg/winedbg.exe.so: dbg_wrap programs/winedbg/winedbg.exe.so: expr_alloc_uconstant programs/winedbg/winedbg.exe.so: lexeme_alloc programs/winedbg/winedbg.exe.so: parser programs/winedbg/winedbg.exe.so: validate_file programs/winemine/winemine.exe.so: AboutDlgProc programs/winemine/winemine.exe.so: AddFlag programs/winemine/winemine.exe.so: CompleteBox programs/winemine/winemine.exe.so: CompleteBoxes programs/winemine/winemine.exe.so: CreateBoard programs/winemine/winemine.exe.so: DestroyBoard programs/winemine/winemine.exe.so: DrawBoard programs/winemine/winemine.exe.so: DrawFace programs/winemine/winemine.exe.so: DrawLeds programs/winemine/winemine.exe.so: DrawMine programs/winemine/winemine.exe.so: DrawMines programs/winemine/winemine.exe.so: InitBoard programs/winemine/winemine.exe.so: LoadBoard programs/winemine/winemine.exe.so: MainProc programs/winemine/winemine.exe.so: PlaceMines programs/winemine/winemine.exe.so: PressBox programs/winemine/winemine.exe.so: PressBoxes programs/winemine/winemine.exe.so: SaveBoard programs/winemine/winemine.exe.so: SetDifficulty programs/winemine/winemine.exe.so: TestBoard programs/winemine/winemine.exe.so: TestFace programs/winemine/winemine.exe.so: TestMines programs/winemine/winemine.exe.so: UnpressBox programs/winemine/winemine.exe.so: UnpressBoxes programs/winhlp32/winhlp32.exe.so: HLPFILE_BPTreeSearch programs/winhlp32/winhlp32.exe.so: HLPFILE_Contents programs/winhlp32/winhlp32.exe.so: HLPFILE_HalfPointsToTwips programs/winhlp32/winhlp32.exe.so: MACRO_AddAccelerator programs/winhlp32/winhlp32.exe.so: MACRO_ALink programs/winhlp32/winhlp32.exe.so: MACRO_AppendItem programs/winhlp32/winhlp32.exe.so: MACRO_Back programs/winhlp32/winhlp32.exe.so: MACRO_BackFlush programs/winhlp32/winhlp32.exe.so: MACRO_BookmarkMore programs/winhlp32/winhlp32.exe.so: MACRO_BrowseButtons programs/winhlp32/winhlp32.exe.so: MACRO_ChangeButtonBinding programs/winhlp32/winhlp32.exe.so: MACRO_ChangeEnable programs/winhlp32/winhlp32.exe.so: MACRO_ChangeItemBinding programs/winhlp32/winhlp32.exe.so: MACRO_CheckItem programs/winhlp32/winhlp32.exe.so: MACRO_CloseSecondarys programs/winhlp32/winhlp32.exe.so: MACRO_CloseWindow programs/winhlp32/winhlp32.exe.so: MACRO_Compare programs/winhlp32/winhlp32.exe.so: MACRO_Contents programs/winhlp32/winhlp32.exe.so: MACRO_ControlPanel programs/winhlp32/winhlp32.exe.so: MACRO_CopyTopic programs/winhlp32/winhlp32.exe.so: MACRO_DeleteItem programs/winhlp32/winhlp32.exe.so: MACRO_DeleteMark programs/winhlp32/winhlp32.exe.so: MACRO_DestroyButton programs/winhlp32/winhlp32.exe.so: MACRO_DisableItem programs/winhlp32/winhlp32.exe.so: MACRO_EnableButton programs/winhlp32/winhlp32.exe.so: MACRO_EnableItem programs/winhlp32/winhlp32.exe.so: MACRO_EndMPrint programs/winhlp32/winhlp32.exe.so: MACRO_ExecFile programs/winhlp32/winhlp32.exe.so: MACRO_ExecProgram programs/winhlp32/winhlp32.exe.so: MACRO_ExtAbleItem programs/winhlp32/winhlp32.exe.so: MACRO_ExtInsertItem programs/winhlp32/winhlp32.exe.so: MACRO_ExtInsertMenu programs/winhlp32/winhlp32.exe.so: MACRO_FileExist programs/winhlp32/winhlp32.exe.so: MACRO_Find programs/winhlp32/winhlp32.exe.so: MACRO_Finder programs/winhlp32/winhlp32.exe.so: MACRO_FloatingMenu programs/winhlp32/winhlp32.exe.so: MACRO_Flush programs/winhlp32/winhlp32.exe.so: MACRO_FocusWindow programs/winhlp32/winhlp32.exe.so: MACRO_Generate programs/winhlp32/winhlp32.exe.so: MACRO_GotoMark programs/winhlp32/winhlp32.exe.so: MACRO_IfThen programs/winhlp32/winhlp32.exe.so: MACRO_IfThenElse programs/winhlp32/winhlp32.exe.so: MACRO_InitMPrint programs/winhlp32/winhlp32.exe.so: MACRO_InsertItem programs/winhlp32/winhlp32.exe.so: MACRO_InsertMenu programs/winhlp32/winhlp32.exe.so: MACRO_IsBook programs/winhlp32/winhlp32.exe.so: MACRO_IsMark programs/winhlp32/winhlp32.exe.so: MACRO_IsNotMark programs/winhlp32/winhlp32.exe.so: MACRO_JumpHelpOn programs/winhlp32/winhlp32.exe.so: MACRO_JumpID programs/winhlp32/winhlp32.exe.so: MACRO_JumpKeyword programs/winhlp32/winhlp32.exe.so: MACRO_KLink programs/winhlp32/winhlp32.exe.so: MACRO_Menu programs/winhlp32/winhlp32.exe.so: MACRO_MPrintHash programs/winhlp32/winhlp32.exe.so: MACRO_MPrintID programs/winhlp32/winhlp32.exe.so: MACRO_Next programs/winhlp32/winhlp32.exe.so: MACRO_NoShow programs/winhlp32/winhlp32.exe.so: MACRO_PopupHash programs/winhlp32/winhlp32.exe.so: MACRO_PopupId programs/winhlp32/winhlp32.exe.so: MACRO_PositionWindow programs/winhlp32/winhlp32.exe.so: MACRO_Prev programs/winhlp32/winhlp32.exe.so: MACRO_RegisterRoutine programs/winhlp32/winhlp32.exe.so: MACRO_RemoveAccelerator programs/winhlp32/winhlp32.exe.so: MACRO_ResetMenu programs/winhlp32/winhlp32.exe.so: MACRO_SaveMark programs/winhlp32/winhlp32.exe.so: MACRO_Search programs/winhlp32/winhlp32.exe.so: MACRO_SetHelpOnFile programs/winhlp32/winhlp32.exe.so: MACRO_SetPopupColor programs/winhlp32/winhlp32.exe.so: MACRO_ShellExecute programs/winhlp32/winhlp32.exe.so: MACRO_ShortCut programs/winhlp32/winhlp32.exe.so: MACRO_TCard programs/winhlp32/winhlp32.exe.so: MACRO_Test programs/winhlp32/winhlp32.exe.so: MACRO_TestALink programs/winhlp32/winhlp32.exe.so: MACRO_TestKLink programs/winhlp32/winhlp32.exe.so: MACRO_UncheckItem programs/winhlp32/winhlp32.exe.so: MACRO_UpdateWindow programs/winhlp32/winhlp32.exe.so: WINHELP_IndexDlgProc programs/winhlp32/winhlp32.exe.so: WINHELP_MessageBoxIDS_s programs/winhlp32/winhlp32.exe.so: WINHELP_SearchDlgProc programs/winhlp32/winhlp32.exe.so: yyalloc programs/winhlp32/winhlp32.exe.so: yy_create_buffer programs/winhlp32/winhlp32.exe.so: yy_delete_buffer programs/winhlp32/winhlp32.exe.so: yy_flush_buffer programs/winhlp32/winhlp32.exe.so: yyfree programs/winhlp32/winhlp32.exe.so: yyget_debug programs/winhlp32/winhlp32.exe.so: yyget_in programs/winhlp32/winhlp32.exe.so: yyget_leng programs/winhlp32/winhlp32.exe.so: yyget_lineno programs/winhlp32/winhlp32.exe.so: yyget_out programs/winhlp32/winhlp32.exe.so: yyget_text programs/winhlp32/winhlp32.exe.so: yylex programs/winhlp32/winhlp32.exe.so: yylex_destroy programs/winhlp32/winhlp32.exe.so: yypop_buffer_state programs/winhlp32/winhlp32.exe.so: yypush_buffer_state programs/winhlp32/winhlp32.exe.so: yyrealloc programs/winhlp32/winhlp32.exe.so: yyrestart programs/winhlp32/winhlp32.exe.so: yy_scan_buffer programs/winhlp32/winhlp32.exe.so: yy_scan_bytes programs/winhlp32/winhlp32.exe.so: yy_scan_string programs/winhlp32/winhlp32.exe.so: yyset_debug programs/winhlp32/winhlp32.exe.so: yyset_in programs/winhlp32/winhlp32.exe.so: yyset_lineno programs/winhlp32/winhlp32.exe.so: yyset_out programs/winhlp32/winhlp32.exe.so: yy_switch_to_buffer programs/winhlp32/winhlp32.exe.so: yywrap -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

5 13

RE: [2/5] wined3d: Remove AddDirtyBox() from the public interface.
by Stefan Dösinger 14 Jan '09

14 Jan '09

I realized that you just removed the calls from surface and volume, where they don't exist in the public d3d9 API. However, textures have such a call in the public d3d9 API - do you know what it is supposed to do, and if this has any implications on this change? > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Henri Verbeet > Sent: Wednesday, January 14, 2009 10:05 AM > To: wine-patches(a)winehq.org > Subject: [2/5] wined3d: Remove AddDirtyBox() from the public interface. >

2 1

Re: setupapi: Add the Romanian translation.
by Paul Vriens 14 Jan '09

14 Jan '09

Michael Stefaniuc wrote: > +/* > + * English resources for SETUPAPI > + * I guess that should be Romanian resources. -- Cheers, Paul.

2 1

Re: ole32: add a test for OleInitialize
by Paul Vriens 14 Jan '09

14 Jan '09

Austin English wrote: > Pointed out by Anastasius in bug 13011. Tested on XP SP2 & 2K SP4 (and > Wine, of course). > > > > ------------------------------------------------------------------------ > > Hi Austin, The test case that is pointed out in bug 13011 is different though: hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); ok(hr == S_OK, "CoInitializeEx failed with error 0x%08x\n", hr); hr = OleInitialize(NULL); ok(hr == S_OK, "OleInitialize failed with error 0x%08x\n", hr); The above succeeds on W2K3 but fails on Wine. -- Cheers, Paul.

4 9

Re: [5/5] d3d9: Use D3DFOG_* constants instead of plain integers
by Henri Verbeet 13 Jan '09

13 Jan '09

I think this change is ok, but note that the ok() line for this test will still just print the numeric value.

2 1

Wineaudioio driver
by Francois Gouget 13 Jan '09

13 Jan '09

Does anyone know how to get the libaudioio.h and libaudioio.so files needed by the wineaudioio driver? This driver is supposed to specifically be for Solaris but I could not find either files on the Solaris 10u5 DVD, nor on the 200807 Solaris 10 companion CD. Has audioio been replaced by something else? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

3 3

Re: [2/5] WineD3D: Get rid of last_was_foggy_shader & friends
by Alexandre Julliard 13 Jan '09

13 Jan '09

Stefan Dösinger <stefan(a)codeweavers.com> writes: > This patch "breaks" a set of fog tests, so they're marked as todo. The tests > aren't really working correctly right now anyway, they depend on undefined > default values in opengl. A later patch will make the vertex shader select > the result.fogcoord(and glsl equivalent) depending on the fog settings, thus > really fixing this test. The added todo doesn't fail here: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:8746: Tests skipped: D3DFMT_G16R16F textures not supported visual.c:8746: Tests skipped: D3DFMT_G32R32F textures not supported visual.c:7536: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests visual.c:1540: Test succeeded inside todo block: fog vs1 ps0 fvm0 ftm0 0: got color 0000ff00, expected 0000ff00 +-5%(todo) visual.c:8607: Tests skipped: Only 1 simultaneous render target supported, skipping MRT test make[2]: *** [visual.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: wcmd: Fix redirecting a pipe to another pipe
by Andrew Nguyen 13 Jan '09

13 Jan '09

On Sun, Jan 11, 2009 at 12:52 PM, Erich Hoover <ehoover(a)mines.edu> wrote: > Real Name: > Erich Hoover > Description: > Fix a problem with Wine's cmd.exe that causes redirecting a pipe to > another pipe to fail. Can be tested by executing 'echo "test" 2>&1' > in cmd.exe. Without the patch the redirect will fail, with the patch > the redirect is properly handled by existing code. > Changelog: > wcmd: Fix redirecting a pipe to another pipe Please set your real e-mail address in your Git configuration; see http://wiki.winehq.org/GitWine#head-8631765a8d71509690613c9191ed2094c7775722 for directions.

3 2

Re: [2/2] setupapi: Fix resolving target path when given a section. Default to the system directory.
by Alexandre Julliard 13 Jan '09

13 Jan '09

Hans Leidekker <hans(a)codeweavers.com> writes: > @@ -68,6 +68,20 @@ static const char inf_data2[] = > "sp1qfe\\winhttp.dll=3EC6F518114606CA59D4160322077437,000500010A280615,331776,SP1QFE\n" > "sp1qfe\\xpob2res.dll=DB83156B9F496F20D1EA70E4ABEC0166,000500010A280622,158720,SP1QFE\n"; > > +static const char inf_data3[] = > + "[Version]\n" > + "Signature = \"$Windows NT$\"\n" > + "[DestinationDirs]\n" > + "CopyAlways.System32.files = 11\n" > + "[CopyAlways.System32.Files]\n" > + "WindowsCodecs.dll\n"; > + > +static const char inf_data4[] = > + "[Version]\n" > + "Signature = \"$Windows NT$\"\n" > + "[CopyAlways.System32.Files]\n" > + "WindowsCodecs.dll\n"; It would be better to use a different directory in the first test so that you can make sure there's a difference. Also you should try setting DefaultDestDir to see how this changes the behavior. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: urlmon: Skip more tests on old IE and ignore BINDSTATUS_PROXYDETECTING notification.
by Paul Vriens 13 Jan '09

13 Jan '09

Jacek Caban wrote: > --- > dlls/urlmon/tests/url.c | 157 > +++++++++++++++++++++++++---------------------- > 1 files changed, 84 insertions(+), 73 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi Jacek, As of this patch we skip running most of the tests on Wine (and Windows). I only see a few W2K boxes that run the full tests for url.c (+/- 3800 tests). The rest only run 137 tests -- Cheers, Paul.

2 3

Re: [2/5] wined3d: Fix texture creation error handling.
by Roderick Colenbrander 13 Jan '09

13 Jan '09

Hi Henri, Just a suggestion for a future patch. The current autogenmipmap code isn't correct. Even when this capability isn't supported the function might not return D3DERR_INVALIDCALL IF CheckDeviceFormat returns D3DOK_NOAUTOGEN for this usage flag. I stumbled on this when I started improving our caps code but didn't have time to fix it yet. Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

1 0

Re: [3/5] WineD3D: Put vertex shader duplication infrastructure in place
by Henri Verbeet 13 Jan '09

13 Jan '09

2009/1/13 Stefan Dösinger <stefan(a)codeweavers.com>: > - This->baseShader.is_compiled = TRUE; > - This changes code in pixelshader.c, looks unrelated. > +void find_vs_compile_args(IWineD3DVertexShaderImpl *shader, IWineD3DStateBlockImpl *stateblock, struct vs_compile_args *args) { > + args->fog_src = stateblock->renderState[WINED3DRS_FOGTABLEMODE] == WINED3DFOG_NONE ? VS_FOG_COORD : VS_FOG_Z; > + args->swizzle_map = ((IWineD3DDeviceImpl *)shader->baseShader.device)->strided_streams.swizzle_map; > +} You need to mask swizzle_map with use_map like in the original code, or you'll end up creating new shaders if an attribute that was previously swizzled is undefined now. > + shader->gl_shaders = HeapReAlloc(GetProcessHeap(), 0, old_array, > + (shader->num_gl_shaders + 1) * sizeof(*shader->gl_shaders)); Please don't grow arrays by a single element like that. I noticed find_gl_pshader() does that as well, please fix. > - * > + * You're adding a trailing space here.

1 0

Re: [dxdiagn] Implemented retrieval of b3DAccelerationEnabled property
by Vitaliy Margolen 13 Jan '09

13 Jan '09

Markus wrote: > > ------------------------------------------------------------------------ > > + HKEY key_handle; > + LPCSTR searchSubKey = "SOFTWARE\\Microsoft\\DirectDraw"; > + LPCSTR dataSubKey = "EmulationOnly"; I don't see anywhere Wine using this key. How did you came up with this key? > + V_VT(&v) = VT_BOOL; V_BOOL(&v) = get_ddraw_acceleration(); > + IDxDiagContainerImpl_AddProp( pDisplayAdapterSubCont, b3DAccelerationEnabled, &v ); > + VariantClear(&v); Why don't you use add_prop_bool()? Vitaliy

3 2

Re: [PATCH 1/6] wininet: Make sure that we have data buffered before sending INTERNET_STATUS_REQUEST_COMPLETE notification.
by Hans Leidekker 12 Jan '09

12 Jan '09

On Monday 12 January 2009 18:19:54 Jacek Caban wrote: > +static void HTTP_ReceiveRequest(WININETHTTPREQW *req) > +{ > + INTERNET_ASYNC_RESULT iar; > + BYTE buffer[4048]; I think HTTP_ReceiveRequestData would be a better name for this function. And I guess this is also a good opportunity to round that buffer size up to the nearest power of two. -Hans

2 2

Re: comctl32: fix Itemtext in treeview.c (Bug #16466)
by Austin English 12 Jan '09

12 Jan '09

On Sun, Jan 11, 2009 at 10:03 AM, Nerv <nerv(a)dawncrow.de> wrote: > This fixes TREEVIEW_DoSetItemT if tvItem->pszText=0 > > > > Please use your full real name on patches. A testcase would help. -- -Austin

1 0

Comctl32 tests on version 6.0
by Nikolay Sivov 12 Jan '09

12 Jan '09

Running crossbuilt tests for comctl32 showed some failures when version 6.0 used: 27 - imagelist 25 - rebar 130 - toolbar (version 6.0 module used through external manifest xml in my test) Toolbar and rebar failures show different rectangle coordinates (all toolbar fails are about -2 shift of y coord). I've some questions: 0) What way is better to implement this 6.0 module - using WinSxS creating another separate version 6 and act like Win, or extend existing module (with version checking probably see next question)? 1) the main is about imagelist: why are we relying here on internal storage format? Tests show that on 6.0 this format's changed. If the reason is to get the same structure when writing to IStream (to be compatible with streams saved on native platform) here's another question => 2) Since wine module should be able to support "all" versions of native ones we need to run tests on both versions on Windows. Is there any way to do so easily maybe playing with activation contexts? The reason why I'm interested in that is the implementation of interfaces IImageList (followed by IImageList2) and related calls HIMAGELIST_QueryInterface from comctl32 (6.0) SHGetImageList from shell32 All this comes from http://bugs.winehq.org/show_bug.cgi?id=15885 Any thoughts are appreciated. Nikolay

2 1

Failing wine tests
by Rico Schüller 12 Jan '09

12 Jan '09

Hi, I've just done 4 runs on the same machine with the same wine version with the same test version (see http://test.winehq.org/data/8cf8e2c60a263e0b015b36dc36c9bf83e6767aa8/#group… - the rs-f10-...). Therefore I named the runs like: inst - test run from a wine version with an installed wine (make install) noinst - test run from a not installed wine version (run directly from the built dir) lo - (links oben) - which means the window from the winetest.exe is on the upper left side on the desktop (default position) ru - (rechts unten) - which means the window from the winetest.exe is on the lower right side on the desktop (just moved the window before I hit start) My result is, that some tests fail/ behave different on the some runs: The main difference is that two tests fail because the winetest.exe window is at the wrong position. These are: user32:msg and riched20:editor. These tests fail when the winetest.exe window as in the upper left corner. Any ideas? The next difference is that some fonts are not found if wine is run from the build directory. Running the installed version these test succeed: user32:combo , gdi32:font and comctl:rebar. Has anyone an idea where this comes from? (Probably a path problem?) There is also a test comctl32:treeview which has 6 todos more if it is run from the build directory. Also note: user32:msg and the user32:win test run a different number of tests each time. Is this intended? Cheers Rico

1 0

Re: [1/2] httpapi: add HttpInitialize and HttpTerminate stubs
by Austin English 12 Jan '09

12 Jan '09

On Mon, Jan 12, 2009 at 11:33 AM, Andrey Turkin <andrey.turkin(a)gmail.com> wrote: > > .Net 3.0 installer needs these > --- > dlls/httpapi/httpapi.spec | 2 + > dlls/httpapi/httpapi_main.c | 42 +++++++++++++++++++++++++++++++++++++ > include/http.h | 48 +++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 92 insertions(+), 0 deletions(-) > create mode 100644 include/http.h > > > > > > diff --git a/dlls/httpapi/httpapi.spec b/dlls/httpapi/httpapi.spec index aa8fea2..1033eb8 100644 --- a/dlls/httpapi/httpapi.spec +++ b/dlls/httpapi/httpapi.spec @@ -18,6 +18,7 @@ @ stub HttpFilterRawWriteAndAppRead @ stub HttpFlushResponseCache @ stub HttpGetCounters +@ stdcall HttpInitialize(long long ptr) @ stub HttpInitialize @ stub HttpInitializeServerContext @ stub HttpOpenAppPool You forgot to remove the stub entry. @@ -48,5 +49,6 @@ @ stub HttpShutdownAppPool @ stub HttpShutdownFilter @ stub HttpTerminate +@ stdcall HttpTerminate(long ptr) @ stub HttpWaitForDemandStart @ stub HttpWaitForDisconnect Same. -- -Austin

2 1

gecko regressions; debug build of gecko?
by Dan Kegel 12 Jan '09

12 Jan '09

I've been doing some random qa of popular apps lately, and think I've found some regressions caused by the gecko update: http://bugs.winehq.org/show_bug.cgi?id=16869 - Sketchup 7 crashes when bringing up 3d Warehouse http://bugs.winehq.org/show_bug.cgi?id=16892 - Yahoo Messenger 8.1 crashes after it puts up the instant message window Hmm, can we have a debug version of the gecko download so we can give more useful backtraces?

3 5

Re: [PATCH 2/2] widl: Optimise the generated code by skipping calls calling the type function directly for some reference pointers.
by Alexandre Julliard 12 Jan '09

12 Jan '09

"Rob Shearman" <robertshearman(a)gmail.com> writes: > Skip calling the Pointer marshalling/unmarshalling/buffer > sizing/freeing function in this case. > > Output code for calling union marshalling/unmarshalling/buffer > sizing/freeing functions. Now it breaks the tests: ../../../tools/runtest -q -P wine -M qmgr.dll -T ../../.. -p qmgr_test.exe.so file.c && touch file.ok wine: Unhandled page fault on read access to 0x001322a8 at address 0x7b86122d (thread 0032), starting debugger... Unhandled exception: page fault on read access to 0x001322a8 in 32-bit code (0x7b86122d). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7b86122d ESP:0032fcf0 EBP:0032fd18 EFLAGS:00010246( - 00 -RIZP1) EAX:001322a8 EBX:7b8b5818 ECX:7bc904c4 EDX:001322a8 ESI:ffffffff EDI:00000000 Stack dump: 0x0032fcf0: 00000001 0032fd04 00110014 6055221c 0x0032fd00: 00000001 00000409 0032fd18 7b8b5818 0x0032fd10: 60552980 001322a8 0032fd48 7b863944 0x0032fd20: 00000409 00000000 001322a8 ffffffff 0x0032fd30: 60552980 ffffffff 0032fd58 6055221c 0x0032fd40: 00000000 60550060 0032fd78 6054ca20 Backtrace: =>0 0x7b86122d CompareStringW+0x12d(lcid=1033, style=0, str1=0x1322a8, len1=0, str2=0x60552980, len2=-1) [/home/julliard/wine/wine/dlls/kernel32/../../include/wine/unicode.h:216] in kernel32 (0x0032fd18) 1 0x7b863944 lstrcmpW+0x64(str1=<register EDI not in topmost frame>, str2=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/kernel32/locale.c:2830] in kernel32 (0x0032fd48) 2 0x6054ca20 test_GetRemoteName+0x90() [/home/julliard/wine/wine/dlls/qmgr/tests/file.c:127] in qmgr_test (0x0032fd78) 3 0x6054ccf4 func_file+0x274() [/home/julliard/wine/wine/dlls/qmgr/tests/file.c:108] in qmgr_test (0x00320000) 4 0x00000000 (0x00000000) 0x7b86122d CompareStringW+0x12d [/home/julliard/wine/wine/dlls/kernel32/../../include/wine/unicode.h:216] in kernel32: cmpw $0,0x0(%eax) 216 while (*s) s++; -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: rpcrt4/tests: NdrVaryingArrayUnmarshall() is broken on Windows
by Alexandre Julliard 12 Jan '09

12 Jan '09

"Ge van Geldorp" <ge(a)gse.nl> writes: > The failures in rpcrt4:server on Windows are caused by an access violation > thrown in NdrVaryingArrayUnmarshall() called from get_5numbers(). I've > created a minimum get_5numbers() test with Microsoft tools and that throws > the same access violation. The access violation disappears when zeroing > out the StubMsg before calling NdrClientInitializeNew(), so my guess is > Windows NdrVaryingArrayUnmarshall() uses an uninitialized member. > > Changelog: > NdrVaryingArrayUnmarshall() is broken on Windows If it's broken on Windows then there's no point in testing it, you can simply remove it. -- Alexandre Julliard julliard(a)winehq.org

4 5

Re: [4/5] widl: Rewrite of cant_be_null
by Alexandre Julliard 12 Jan '09

12 Jan '09

Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> writes: > As Rob Shearman commented to my patch "Null-check pointers with [size_is]", > the code flow in cant_be_null is non-obvious, the variable type check could > be included into this function and last but not least it is buggy. This > is a hopefully cleaner rewrite of this function, which still fixes the > problem the original patch intended to fix, namely null-checking of pointers > declared with size_is. This matches midl behaviour. It still doesn't seem to be doing the right thing on the svcctl client code. The current code matches widl for all functions except QueryServiceStatusEx, yours has a lot more differences. I'd also suggest adding some test cases for this. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] widl: Optimise the generated code by skipping calls calling the type function directly for some reference pointers.
by Alexandre Julliard 12 Jan '09

12 Jan '09

"Rob Shearman" <robertshearman(a)gmail.com> writes: > Skip calling the Pointer marshalling/unmarshalling/buffer > sizing/freeing function in this case. > > Output code for calling union marshalling/unmarshalling/buffer > sizing/freeing functions. It doesn't work: ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -DREGISTER_PROXY_DLL -DPROXY_CLSID_IS="{ 0xb8da6310, 0xe19b, 0x11d0, { 0x93, 0x3c, 0x00, 0xa0, 0xc9, 0x0d, 0xca, 0xa9 } }" -p -P actxprxy_servprov_p.c actxprxy_servprov.idl widl: typetree.h:191: type_pointer_get_ref: Assertion `is_ptr(type)' failed. make[2]: *** [actxprxy_servprov_p.c] Aborted make[2]: *** Deleting file `actxprxy_servprov_p.c' -- Alexandre Julliard julliard(a)winehq.org

2 1

WIDL 'import' question
by Nikolay Sivov 12 Jan '09

12 Jan '09

Hi, I've a small question on using 'import' in .idl. Sorry if it's too dummy, it's my first try to use widl. Trying to get commoncontrols.idl port compile on Wine I've got the following problems - this file contains struct definitions already defined in commctrl.h. Adding import "commctrl.h" and removing after that all conflict definitions from commoncontrols.idl caused for me ../tools/widl/widl -I. -I. -I../include -I../include -h -H commoncontrols.h commoncontrols.idl ./prsht.h:39: error: syntax error, unexpected '{' make[1]: *** [commoncontrols.h] Error 1 make[1]: Leaving directory `/home/mrlarch/wine/include' make: *** [include] Error 2 showing that prsht.h isn't processed properly here 39 static const WCHAR WC_PROPSHEETW[] = { 'S','y','s', 40 'P','r','o','p','e','r','t','y','S','h','e','e','t',0 }; How could I get over that?

2 2

Re: [2/9] cryptui: Use "-1" as a "don't care value", fix dialog id duplicates.
by Alexandre Julliard 12 Jan '09

12 Jan '09

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > diff --git a/dlls/cryptui/cryptui_En.rc b/dlls/cryptui/cryptui_En.rc > index 119eac6..b5bd067 100644 > --- a/dlls/cryptui/cryptui_En.rc > +++ b/dlls/cryptui/cryptui_En.rc > @@ -274,11 +274,11 @@ BEGIN > PUSHBUTTON "B&rowse...", IDC_IMPORT_BROWSE_FILE, 236,11,60,14 > LTEXT "Note: The following file formats may contain more than one certificate, certificate revocation list, or certificate trust list:", stc2, 21,26,265,16 > LTEXT "Cryptographic Message Syntax Standard/PKCS #7 Messages (.p7b)", > - stc3, 31,49,265,10 > + IDC_STATIC, 31,49,265,10 > LTEXT "Personal Information Exchange/PKCS #12 (.pfx, .p12)", > - stc3, 31,64,265,10 > + IDC_STATIC, 31,64,265,10 > LTEXT "Microsoft Serialized Certificate Store (.sst)", > - stc3, 31,79,265,10 > + IDC_STATIC, 31,79,265,10 > END It would be better to use -1 directly in the resource file and get rid of IDC_STATIC. There's no need to have a define for an ignored value. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] server: add ability to send a unix signal to arbitrary thread
by Alexandre Julliard 12 Jan '09

12 Jan '09

"Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > diff --git a/server/protocol.def b/server/protocol.def > index 6d6be5b..35dfcc0 100644 > --- a/server/protocol.def > +++ b/server/protocol.def > @@ -664,6 +664,12 @@ typedef union > int count; /* new suspend count */ > @END > > +/* Send a unix signal to thread */ > +@REQ(kill_thread) > + obj_handle_t handle; /* thread handle */ > + int sig; /* unix signal to send */ > +@END This does not belong in the server. The dosvm support should be fixed to use Win32 APIs instead of Unix signals. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32/tests: keybd_event can send HCBT_KEYSKIPPED notifications
by Dmitry Timoshkov 12 Jan '09

12 Jan '09

"Ge van Geldorp" <ge(a)gse.nl> wrote: > static const struct message WmKeyUpSkippedSeq[] = > { > - { HCBT_KEYSKIPPED, hook|wparam|lparam|optional, 'N', 0xc0000001 }, /* XP */ > + { HCBT_KEYSKIPPED, hook|wparam|optional, 'N' }, /* XP */ > + { 0 } > +}; > +static const struct message WmUserKeyUpSkippedSeq[] = > +{ > + { WM_USER, sent }, > + { HCBT_KEYSKIPPED, hook|wparam|optional, 'N' }, /* XP */ > { 0 } > }; Please don't remove lparam checks, add message sequences for key down messages instead. -- Dmitry.

1 0

Re: [TOOLS] Add Windows 7
by James Hawkins 12 Jan '09

12 Jan '09

On Sat, Jan 10, 2009 at 3:32 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > We have our first Windows 7 test results : > http://test.winehq.org/data/a69c86d3f517f659ba47495f77deac2df671fb03/vista_… > > I'm not sure if '7' is a nice/correct header though. Maybe "Win7" ? > > This also means we need to add it to winecfg. > > Changelog > Add Windows 7 > > -- > Cheers, > > Paul. > > > >From b8ec6ca34b85f7ba1ae736ef35ee380b1b5721f0 Mon Sep 17 00:00:00 2001 > From: Paul Vriens <Paul.Vriens.Wine(a)gmail.com> > Date: Sat, 10 Jan 2009 12:28:57 +0100 > Subject: [PATCH] Add Windows 7 > > --- > winetest/build-index | 3 ++- > winetest/dissect | 6 ++++-- > winetest/gather | 6 ++++-- > 3 files changed, 10 insertions(+), 5 deletions(-) > > diff --git a/winetest/build-index b/winetest/build-index > index 2813ae8..0f257ad 100755 > --- a/winetest/build-index > +++ b/winetest/build-index > @@ -27,11 +27,12 @@ my %xp = (name => "XP"); > my %w2k3 = (name => "2003"); > my %vista = (name => "Vista"); > my %w2k8 = (name => "2008"); > +my %w7 = (name => "7"); > my %unknown = (name => "Other"); > my %wine = (name => "Wine"); > I'm behind on my emails this weekend, so I don't know if this has been committed yet or not, but it seems like win7 is a better name than w7. -- James Hawkins

3 3

Re: richedit: Added tests for autoscrolling options based on WS_V/HSCROLL.
by Detlef Riekenberg 12 Jan '09

12 Jan '09

On So, 2009-01-11 at 02:58 -0500, Dylan Smith wrote: > It seems as if the autoscrolling options can be set based on whether > WS_VSCROLL or WS_HSCROLL styles are used to create the window, but this > is done differently between version 1.0 and 3.0 of the richedit control. > > I noticed this indirectly before because wordwrap is initially set only > if the auto-horizontal scrolling is initially enabled. > --- > dlls/riched20/tests/editor.c | 30 ++++++++++++++++++++++++++++-- > dlls/riched32/tests/editor.c | 32 ++++++++++++++++++++++++++++++++ > 2 files changed, 60 insertions(+), 2 deletions(-) Hi Dylan. After testing your first Patch, i tried this one: patching file dlls/riched20/tests/editor.c Hunk #1 succeeded at 5826 (offset 23 lines). Hunk #2 succeeded at 5856 (offset 23 lines). Hunk #3 succeeded at 6281 (offset 23 lines). patching file dlls/riched32/tests/editor.c All patches should apply clean. When you send a Patchset, please mark them with [Patch x/y] In this case, [Patch 1/8], [Patch 2/8], ... And again, new failures in win9x due to the use of UNICODE. (The riched32 test already produce >40 failures in Win9x) I didn't view/test the following Patches. Please inspect them also for UNICODE faults. -- By by ... Detlef

2 1

cmd.exe AppDB page
by Erich Hoover 12 Jan '09

12 Jan '09

Is there a reason that the cmd.exe AppDB page is locked (http://appdb.winehq.org/objectManager.php?sClass=application&iId=1196)? Erich Hoover ehoover(a)mines.edu

4 10

Re: [1/4] mshtml: Implement IHTMLStyle get/put borderRightStyle
by Jacek Caban 12 Jan '09

12 Jan '09

Hi Alistair, Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Implement IHTMLStyle get/put borderRightStyle > +static BOOL IsValidBorderStyle(BSTR v) - Please use the same name convention as other functions in this file - There is no test proving that the style is validated - You didn't include get_borderRightStyle, which makes put_borderRightStyle almost useless static HRESULT WINAPI HTMLStyle_get_borderLeftStyle(IHTMLStyle *iface, BSTR *p) That's not what changelog says. Jacek

2 2

re:cmd.exe AppDB page
by nn 11 Jan '09

11 Jan '09

Eric, I have created a new AppDB page for cmd.exe as the existing one would not accept new test reports: new AppDB page is: http://appdb.winehq.org/objectManager.php?sClass=application&iId=8995 Submit a test and I will delete the fake report. Nat Stay connected to the people that matter most with a smarter inbox. Take a look http://au.docs.yahoo.com/mail/smarterinbox

1 0

Re: wcmd: Fix redirecting a pipe to another pipe
by Reece Dunn 11 Jan '09

11 Jan '09

2009/1/11 Erich Hoover <ehoover(a)mines.edu>: + /* If a redirect is immediately followed by '&' (ie. 2>&1) then + do nor process that ampersand as an AND operator */ Shouldn't that be "do *not* process that ampersand"? - Reece

3 3

setupapi:parser - suspicious test results
by Rico Schüller 11 Jan '09

11 Jan '09

Hi, concerning to http://test.winehq.org/data/tests/setupapi:parser.html there are some suspicious results for the test from 6-10. January. On my system (F10-x86_64) the setupapi:parser test (setupapi_test.exe) from the test site has 15 additional failures (17 failures) on wine. I checked it with my own build (setupapi_crosstest.exe) which has only 2 failures). Both tests executables succeeded on my windows machine without any failures. Attached is the log from both runs on wine. I have no glue where the difference come from. I guess it has something todo with this commit http://source.winehq.org/git/wine.git/?a=blobdiff;f=dlls/setupapi/tests/par… , which introduced the failing tests. But I couldn't run a regression test because my own compiled version didn't trigger the failures. Any suggestions? Cheers Rico [Ricola@ricola build]$ ./wine ~/Desktop/setupapi_test.exe parser parser.c:148: hinf=FFFFFFFF err=0xe0000100 line=0 parser.c:148: hinf=FFFFFFFF err=0xe0000000 line=1 parser.c:154: Test failed: file 1: Bad error 3758096384/3758096640 parser.c:156: Test failed: file 1: Bad error line 1/0 parser.c:148: hinf=FFFFFFFF err=0xe0000100 line=0 parser.c:148: hinf=FFFFFFFF err=0xe0000100 line=0 parser.c:148: hinf=FFFFFFFF err=0xe0000100 line=0 parser.c:148: hinf=00127410 err=0x0 line=-559038737 parser.c:148: hinf=00127410 err=0x0 line=-559038737 parser.c:148: hinf=00127410 err=0x0 line=-559038737 parser.c:148: hinf=00127410 err=0x0 line=-559038737 parser.c:148: hinf=00127410 err=0x0 line=-559038737 parser.c:148: hinf=00127410 err=0x0 line=-559038737 parser.c:148: hinf=00127410 err=0x0 line=-559038737 parser.c:148: hinf=00127410 err=0x0 line=-559038737 parser.c:148: hinf=00127410 err=0x0 line=-559038737 parser.c:148: hinf=FFFFFFFF err=0xe0000001 line=3 parser.c:148: hinf=FFFFFFFF err=0xe0000001 line=5 parser.c:148: hinf=FFFFFFFF err=0xe0000002 line=3 parser.c:148: hinf=00127410 err=0x0 line=-559038737 parser.c:148: hinf=FFFFFFFF err=0xe0000000 line=1 parser.c:148: hinf=FFFFFFFF err=0xe0000000 line=3 parser.c:148: hinf=FFFFFFFF err=0xe0000000 line=3 parser.c:148: hinf=00127410 err=0x0 line=-559038737 parser.c:148: hinf=FFFFFFFF err=0xe0000001 line=3 parser.c:148: hinf=FFFFFFFF err=0xe0000001 line=3 parser.c:148: hinf=FFFFFFFF err=0xe0000001 line=3 parser.c:148: hinf=FFFFFFFF err=0xe0000001 line=3 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=-1 err=0xe0000101 parser.c:233: hinf=00127410 ret=-1 err=0xe0000101 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:233: hinf=00127410 ret=0 err=0x0 parser.c:277: Test failed: wrong len 0 parser.c:284: Test failed: wrong len 0 parser.c:289: Test failed: wrong len 0 parser.c:277: Test failed: wrong len 0 parser.c:284: Test failed: wrong len 0 parser.c:289: Test failed: wrong len 0 parser.c:277: Test failed: wrong len 0 parser.c:284: Test failed: wrong len 0 parser.c:289: Test failed: wrong len 0 parser.c:277: Test failed: wrong len 0 parser.c:284: Test failed: wrong len 0 parser.c:289: Test failed: wrong len 0 parser.c:277: Test failed: wrong len 0 parser.c:284: Test failed: wrong len 0 parser.c:289: Test failed: wrong len 0 parser: 843 tests executed (0 marked as todo, 17 failures), 0 skipped. [Ricola@ricola build]$ ./wine ~/Desktop/setupapi_crosstest.exe parser parser.c:148: hinf=FFFFFFFF err=0xe0000100 line=0 parser.c:148: hinf=FFFFFFFF err=0xe0000000 line=1 parser.c:154: Test failed: file 1: Bad error 3758096384/3758096640 parser.c:156: Test failed: file 1: Bad error line 1/0 parser.c:148: hinf=FFFFFFFF err=0xe0000100 line=0 parser.c:148: hinf=FFFFFFFF err=0xe0000100 line=0 parser.c:148: hinf=FFFFFFFF err=0xe0000100 line=0 parser.c:148: hinf=00127340 err=0x0 line=-559038737 parser.c:148: hinf=00127340 err=0x0 line=-559038737 parser.c:148: hinf=00127340 err=0x0 line=-559038737 parser.c:148: hinf=00127340 err=0x0 line=-559038737 parser.c:148: hinf=00127340 err=0x0 line=-559038737 parser.c:148: hinf=00127340 err=0x0 line=-559038737 parser.c:148: hinf=00127340 err=0x0 line=-559038737 parser.c:148: hinf=00127340 err=0x0 line=-559038737 parser.c:148: hinf=00127340 err=0x0 line=-559038737 parser.c:148: hinf=FFFFFFFF err=0xe0000001 line=3 parser.c:148: hinf=FFFFFFFF err=0xe0000001 line=5 parser.c:148: hinf=FFFFFFFF err=0xe0000002 line=3 parser.c:148: hinf=00127340 err=0x0 line=-559038737 parser.c:148: hinf=FFFFFFFF err=0xe0000000 line=1 parser.c:148: hinf=FFFFFFFF err=0xe0000000 line=3 parser.c:148: hinf=FFFFFFFF err=0xe0000000 line=3 parser.c:148: hinf=00127340 err=0x0 line=-559038737 parser.c:148: hinf=FFFFFFFF err=0xe0000001 line=3 parser.c:148: hinf=FFFFFFFF err=0xe0000001 line=3 parser.c:148: hinf=FFFFFFFF err=0xe0000001 line=3 parser.c:148: hinf=FFFFFFFF err=0xe0000001 line=3 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=-1 err=0xe0000101 parser.c:233: hinf=00127340 ret=-1 err=0xe0000101 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser.c:233: hinf=00127340 ret=0 err=0x0 parser: 843 tests executed (0 marked as todo, 2 failures), 0 skipped. [Ricola@ricola build]$

3 4

Re: richedit: Added tests to show that options are stored internally.
by Detlef Riekenberg 11 Jan '09

11 Jan '09

On So, 2009-01-11 at 02:58 -0500, Dylan Smith wrote: Hi Dylan. First of all, thanks for working on riched* > + /* EM_SETOPTIONS changes the window style, but changing the > + * window style does not change the options. */ > + dwStyle = GetWindowLongW(hwndRichEdit, GWL_STYLE); Almost all UNICODE functions do not work on Win9x > + ok(dwStyle & ES_READONLY, "Readonly style not set by > EM_SETOPTIONS\n"); > + SetWindowLongW(hwndRichEdit, GWL_STYLE, dwStyle & ~ES_READONLY); This also does not work on Win9x. > + options = SendMessage(hwndRichEdit, EM_GETOPTIONS, 0, 0); > + todo_wine ok(options & ES_READONLY, "Readonly option set by > SetWindowLong\n"); I tested your patch on win98se. As expected from reading the patch, you introduced a failure. -- By by ... Detlef

1 0

Re: richedit: Added tests for autoscrolling options based on WS_V/HSCROLL.
by Paul Vriens 11 Jan '09

11 Jan '09

Dylan Smith wrote: > It seems as if the autoscrolling options can be set based on whether > WS_VSCROLL or WS_HSCROLL styles are used to create the window, but this > is done differently between version 1.0 and 3.0 of the richedit control. > > I noticed this indirectly before because wordwrap is initially set only > if the auto-horizontal scrolling is initially enabled. > --- > dlls/riched20/tests/editor.c | 30 ++++++++++++++++++++++++++++-- > dlls/riched32/tests/editor.c | 32 ++++++++++++++++++++++++++++++++ > 2 files changed, 60 insertions(+), 2 deletions(-) > > > ------------------------------------------------------------------------ > > Hi Dylan, Same remark about the W-calls. -- Cheers, Paul.

1 0

Re: richedit: Added tests to show that options are stored internally.
by Paul Vriens 11 Jan '09

11 Jan '09

Dylan Smith wrote: > Wine is currently getting the window styles and using them directly, but > the tests I added show that an internal copy is being stored by native > richedit controls. > --- > dlls/riched20/tests/editor.c | 23 +++++++++++++++++++++++ > 1 files changed, 23 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Hi Dylan, Care to change the GetWindowLongW and SetWindowLongW to use the A-version (or remove the W)? These tests will not work on Win9x I guess. -- Cheers, Paul.

1 0

[6/8] widl: Null-check pointers with [size_is]
by Michael Karcher 10 Jan '09

10 Jan '09

This matches midl behaviour. In void test1([out,size_is(x)] char str[], [in] int x); void test2([size_is(x), out] char* str, [in] int x); the parameter to test1 is not NULL-checked, but the one to test2 is. --- tools/widl/client.c | 2 +- tools/widl/proxy.c | 15 ++++++++++----- tools/widl/widltypes.h | 1 + 3 files changed, 12 insertions(+), 6 deletions(-) diff --git a/tools/widl/client.c b/tools/widl/client.c index a23e298..0b10eb6 100644 --- a/tools/widl/client.c +++ b/tools/widl/client.c @@ -59,7 +59,7 @@ static void check_pointers(const var_t *func) LIST_FOR_EACH_ENTRY( var, type_get_function_args(func->type), const var_t, entry ) { - if (is_var_ptr(var) && cant_be_null(var)) + if (is_var_declptr(var) && cant_be_null(var)) { print_client("if (!%s)\n", var->name); print_client("{\n"); diff --git a/tools/widl/proxy.c b/tools/widl/proxy.c index bb16b72..ce07ddc 100644 --- a/tools/widl/proxy.c +++ b/tools/widl/proxy.c @@ -150,6 +150,11 @@ int is_var_ptr(const var_t *v) return is_ptr(v->type); } +int is_var_declptr(const var_t *v) +{ + return is_declptr(v->type); +} + int cant_be_null(const var_t *v) { /* Search backwards for the most recent pointer attribute. */ @@ -164,10 +169,10 @@ int cant_be_null(const var_t *v) if (is_user_type(type)) return 0; - if (!attrs && is_ptr(type)) + if (!attrs && is_declptr(type)) { attrs = type->attrs; - type = type_pointer_get_ref(type); + type = get_deref_type(type); } while (attrs) @@ -180,7 +185,7 @@ int cant_be_null(const var_t *v) if (t == RPC_FC_RP) return 1; - if (is_ptr(type)) + if (is_declptr(type)) { if (type->type == RPC_FC_FP || type->type == RPC_FC_OP || @@ -188,7 +193,7 @@ int cant_be_null(const var_t *v) return 0; attrs = type->attrs; - type = type_pointer_get_ref(type); + type = get_deref_type(type); } else attrs = NULL; @@ -229,7 +234,7 @@ static void proxy_check_pointers( const var_list_t *args ) if (!args) return; LIST_FOR_EACH_ENTRY( arg, args, const var_t, entry ) { - if (is_var_ptr(arg) && cant_be_null(arg)) { + if (is_var_declptr(arg) && cant_be_null(arg)) { print_proxy( "if(!%s)\n", arg->name ); indent++; print_proxy( "RpcRaiseException(RPC_X_NULL_REF_POINTER);\n"); diff --git a/tools/widl/widltypes.h b/tools/widl/widltypes.h index fe8c250..6a770c3 100644 --- a/tools/widl/widltypes.h +++ b/tools/widl/widltypes.h @@ -445,6 +445,7 @@ void clear_all_offsets(void); int is_ptr(const type_t *t); int is_array(const type_t *t); int is_var_ptr(const var_t *v); +int is_var_declptr(const var_t *v); int cant_be_null(const var_t *v); int is_struct(unsigned char tc); int is_union(unsigned char tc); -- 1.5.6.5

2 2

[5/8] widl: dereference operator in expr work on any declared pointer
by Michael Karcher 10 Jan '09

10 Jan '09

If we take MIDL 6.00.0366 as reference, the following method type is legal: void frobnicate([size_is(x),in,out] int * bar1, [size_is(*bar1),out] int * bar2, [in] int x); Without this patch, size_is(*bar1) would be rejected. --- tools/widl/expr.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/widl/expr.c b/tools/widl/expr.c index 7f0e26d..e943062 100644 --- a/tools/widl/expr.c +++ b/tools/widl/expr.c @@ -468,8 +468,8 @@ static struct expression_type resolve_expression(const struct expr_loc *expr_loc break; case EXPR_PPTR: result = resolve_expression(expr_loc, cont_type, e->ref); - if (result.type && is_ptr(result.type)) - result.type = type_pointer_get_ref(result.type); + if (result.type && is_declptr(result.type)) + result.type = get_deref_type(result.type); else error_loc_info(&expr_loc->v->loc_info, "dereference operator applied to non-pointer type in expression%s%s\n", expr_loc->attr ? " for attribute " : "", -- 1.5.6.5

2 2

[7/8] widl: move is_user_type from typegen to header
by Michael Karcher 10 Jan '09

10 Jan '09

--- tools/widl/header.c | 24 ++++++++++++++++++++++++ tools/widl/header.h | 2 ++ tools/widl/typegen.c | 24 ------------------------ tools/widl/typegen.h | 1 - 4 files changed, 26 insertions(+), 25 deletions(-) diff --git a/tools/widl/header.c b/tools/widl/header.c index a3d2250..da42e95 100644 --- a/tools/widl/header.c +++ b/tools/widl/header.c @@ -119,6 +119,30 @@ int is_conformant_array(const type_t *t) return is_array(t) && type_array_has_conformance(t); } +type_t *get_user_type(const type_t *t, const char **pname) +{ + for (;;) + { + type_t *ut = get_attrp(t->attrs, ATTR_WIREMARSHAL); + if (ut) + { + if (pname) + *pname = t->name; + return ut; + } + + if (type_is_alias(t)) + t = t->orig; + else + return 0; + } +} + +int is_user_type(const type_t *t) +{ + return get_user_type(t, NULL) != NULL; +} + void write_guid(FILE *f, const char *guid_prefix, const char *name, const UUID *uuid) { if (!uuid) return; diff --git a/tools/widl/header.h b/tools/widl/header.h index 89583e1..3f0eec1 100644 --- a/tools/widl/header.h +++ b/tools/widl/header.h @@ -32,6 +32,8 @@ extern int is_void(const type_t *t); extern int is_conformant_array(const type_t *t); extern int is_declptr(const type_t *t); extern type_t * get_deref_type(const type_t * t); +extern int is_user_type(const type_t *t); +extern type_t *get_user_type(const type_t *t, const char **pname); extern const char* get_name(const var_t *v); extern void write_type_left(FILE *h, type_t *t, int declonly); extern void write_type_right(FILE *h, type_t *t, int is_field); diff --git a/tools/widl/typegen.c b/tools/widl/typegen.c index 9256bba..a7b7d0f 100644 --- a/tools/widl/typegen.c +++ b/tools/widl/typegen.c @@ -502,30 +502,6 @@ static void guard_rec(type_t *type) type->typestring_offset = 1; } -static type_t *get_user_type(const type_t *t, const char **pname) -{ - for (;;) - { - type_t *ut = get_attrp(t->attrs, ATTR_WIREMARSHAL); - if (ut) - { - if (pname) - *pname = t->name; - return ut; - } - - if (type_is_alias(t)) - t = t->orig; - else - return 0; - } -} - -int is_user_type(const type_t *t) -{ - return get_user_type(t, NULL) != NULL; -} - static int is_embedded_complex(const type_t *type) { unsigned char tc = type->type; diff --git a/tools/widl/typegen.h b/tools/widl/typegen.h index b2c48df..f790d49 100644 --- a/tools/widl/typegen.h +++ b/tools/widl/typegen.h @@ -61,7 +61,6 @@ int decl_indirect(const type_t *t); void write_parameters_init(FILE *file, int indent, const var_t *func, const char *local_var_prefix); void print(FILE *file, int indent, const char *format, va_list ap); int get_padding(const var_list_t *fields); -int is_user_type(const type_t *t); expr_t *get_size_is_expr(const type_t *t, const char *name); int is_full_pointer_function(const var_t *func); void write_full_pointer_init(FILE *file, int indent, const var_t *func, int is_server); -- 1.5.6.5

2 1

[4/8] widl: add helper function get_deref_type
by Michael Karcher 10 Jan '09

10 Jan '09

get_deref_type yields the type of array elements for arrays or the pointed-to type of pointers. Most important, it works on anything is_declptr returns true for. --- tools/widl/header.h | 1 + tools/widl/typegen.c | 15 +++++++++++---- tools/widl/write_msft.c | 3 +-- 3 files changed, 13 insertions(+), 6 deletions(-) diff --git a/tools/widl/header.h b/tools/widl/header.h index 6ac7cb0..89583e1 100644 --- a/tools/widl/header.h +++ b/tools/widl/header.h @@ -31,6 +31,7 @@ extern unsigned long get_attrv(const attr_list_t *list, enum attr_type t); extern int is_void(const type_t *t); extern int is_conformant_array(const type_t *t); extern int is_declptr(const type_t *t); +extern type_t * get_deref_type(const type_t * t); extern const char* get_name(const var_t *v); extern void write_type_left(FILE *h, type_t *t, int declonly); extern void write_type_right(FILE *h, type_t *t, int is_field); diff --git a/tools/widl/typegen.c b/tools/widl/typegen.c index 7dfa0b2..9256bba 100644 --- a/tools/widl/typegen.c +++ b/tools/widl/typegen.c @@ -1784,6 +1784,16 @@ int is_declptr(const type_t *t) return is_ptr(t) || (is_conformant_array(t) && !t->declarray); } +type_t * get_deref_type(const type_t * t) +{ + if (is_ptr(t)) + return type_pointer_get_ref(t); + else if (is_array(t)) + return type_array_get_element(t); + else + return NULL; +} + static size_t write_string_tfs(FILE *file, const attr_list_t *attrs, type_t *type, const char *name, unsigned int *typestring_offset) @@ -1812,10 +1822,7 @@ static size_t write_string_tfs(FILE *file, const attr_list_t *attrs, start_offset = *typestring_offset; update_tfsoff(type, start_offset, file); - if (is_array(type)) - rtype = type_array_get_element(type)->type; - else - rtype = type_pointer_get_ref(type)->type; + rtype = get_deref_type(type)->type; if ((rtype != RPC_FC_BYTE) && (rtype != RPC_FC_CHAR) && (rtype != RPC_FC_WCHAR)) { diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c index 04195ff..a4eba3c 100644 --- a/tools/widl/write_msft.c +++ b/tools/widl/write_msft.c @@ -1116,8 +1116,7 @@ static int encode_var( vt = get_type_vt(type); if (vt == VT_PTR) { - type_t *ref = is_ptr(type) ? - type_pointer_get_ref(type) : type_array_get_element(type); + type_t *ref = get_deref_type(type); int skip_ptr = encode_var(typelib, ref, var, &target_type, NULL, NULL, &child_size); -- 1.5.6.5

2 2

[8/8] widl: consider ptrs to user-marshalled types as pointers-to-nonpointers
by Michael Karcher 10 Jan '09

10 Jan '09

typdef [wire_marshal(wirefoo)] foo * pfoo; made widl incorrectly set the RPC_FC_P_DEREF bit for pfoo. But this declares a user-marshalled pointer, so the RPC runtime must not dereference it before passing it on to the UserFoo functions. --- tools/widl/header.h | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/tools/widl/header.h b/tools/widl/header.h index 3f0eec1..f572440 100644 --- a/tools/widl/header.h +++ b/tools/widl/header.h @@ -61,7 +61,8 @@ extern int is_const_decl(const var_t *var); static inline int last_ptr(const type_t *type) { - return is_ptr(type) && !is_declptr(type_pointer_get_ref(type)); + const type_t * ref = type_pointer_get_ref(type); + return is_ptr(type) && (is_user_type(ref) || !is_declptr(ref)); } static inline int last_array(const type_t *type) -- 1.5.6.5

2 1

[1/8] widl: fix handling of [local] functions without [call_as] (try 3)
by Michael Karcher 10 Jan '09

10 Jan '09

Output NULL pointers into proxy table and STUB_FORWARDING_FUNCTION into stub tables if a local function has no call_as function associated, just as MIDL does. try 2: Fix various mistakes (one of them found by Rob Shearman) try 3: Rebased to current git --- tools/widl/proxy.c | 51 ++++++++++++++++++++++++++++----------------------- 1 files changed, 28 insertions(+), 23 deletions(-) diff --git a/tools/widl/proxy.c b/tools/widl/proxy.c index 878e820..4e69190 100644 --- a/tools/widl/proxy.c +++ b/tools/widl/proxy.c @@ -543,6 +543,17 @@ static int count_methods(type_t *iface) return count; } +static const statement_t * get_callas_source(const type_t * iface, const var_t * def) +{ + const statement_t * source; + STATEMENTS_FOR_EACH_FUNC( source, type_iface_get_stmts(iface)) { + const var_t * cas = is_callas(source->u.var->attrs ); + if (cas && !strcmp(def->name, cas->name)) + return source; + } + return NULL; +} + static int write_proxy_methods(type_t *iface, int skip) { const statement_t *stmt; @@ -554,8 +565,11 @@ static int write_proxy_methods(type_t *iface, int skip) STATEMENTS_FOR_EACH_FUNC(stmt, type_iface_get_stmts(iface)) { const var_t *func = stmt->u.var; if (!is_callas(func->attrs)) { + if (i != func->type->details.function->idx ) + error("widl internal error: method index mismatch"); if (i) fprintf(proxy, ",\n"); - if (skip) print_proxy( "0 /* %s_%s_Proxy */", iface->name, get_name(func)); + if (skip || (is_local(func->attrs) && !get_callas_source(iface, func))) + print_proxy( "0 /* %s_%s_Proxy */", iface->name, get_name(func)); else print_proxy( "%s_%s_Proxy", iface->name, get_name(func)); i++; } @@ -575,10 +589,19 @@ static int write_stub_methods(type_t *iface, int skip) STATEMENTS_FOR_EACH_FUNC(stmt, type_iface_get_stmts(iface)) { const var_t *func = stmt->u.var; - if (!is_local(func->attrs)) { + if (!is_callas(func->attrs)) { + int missing = 0; + const char * fname = get_name(func); + if(is_local(func->attrs)) { + const statement_t * callas_source = get_callas_source(iface, func); + if(!callas_source) + missing = 1; + else + fname = get_name(callas_source->u.var); + } if (i) fprintf(proxy,",\n"); - if (skip) print_proxy("STUB_FORWARDING_FUNCTION"); - else print_proxy( "%s_%s_Stub", iface->name, get_name(func)); + if (skip || missing) print_proxy("STUB_FORWARDING_FUNCTION"); + else print_proxy( "%s_%s_Stub", iface->name, fname); i++; } } @@ -587,7 +610,7 @@ static int write_stub_methods(type_t *iface, int skip) static void write_proxy(type_t *iface, unsigned int *proc_offset) { - int midx = -1, count; + int count; const statement_t *stmt; int first_func = 1; @@ -619,28 +642,10 @@ static void write_proxy(type_t *iface, unsigned int *proc_offset) gen_proxy(iface, func, idx, *proc_offset); gen_stub(iface, func, cname, *proc_offset); *proc_offset += get_size_procformatstring_func( func ); - if (midx == -1) midx = idx; - else if (midx != idx) error("method index mismatch in write_proxy\n"); - midx++; - } - } - - /* interface didn't have any methods - search in inherited interfaces */ - if (midx == -1) { - const type_t *inherit_iface; - for (inherit_iface = type_iface_get_inherit(iface); - inherit_iface; - inherit_iface = type_iface_get_inherit(inherit_iface)) { - STATEMENTS_FOR_EACH_FUNC(stmt, type_iface_get_stmts(inherit_iface)) { - const var_t *func = stmt->u.var; - int idx = func->type->details.function->idx; - if (idx + 1 > midx) midx = idx + 1; - } } } count = count_methods(iface); - if (midx != -1 && midx != count) error("invalid count %u/%u\n", count, midx); /* proxy vtable */ print_proxy( "static const CINTERFACE_PROXY_VTABLE(%d) _%sProxyVtbl =\n", count, iface->name); -- 1.5.6.5

3 3

[3/8] widl: use base pointer type instead of default if not overwritten. (resend)
by Michael Karcher 10 Jan '09

10 Jan '09

--- tools/widl/proxy.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/tools/widl/proxy.c b/tools/widl/proxy.c index 4e69190..bb16b72 100644 --- a/tools/widl/proxy.c +++ b/tools/widl/proxy.c @@ -182,6 +182,11 @@ int cant_be_null(const var_t *v) if (is_ptr(type)) { + if (type->type == RPC_FC_FP || + type->type == RPC_FC_OP || + type->type == RPC_FC_UP) + return 0; + attrs = type->attrs; type = type_pointer_get_ref(type); } -- 1.5.6.5

2 1

[2/8] widl: Don't forget conformance info on [iid_is] void pointers. (resend)
by Michael Karcher 10 Jan '09

10 Jan '09

--- tools/widl/typegen.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/widl/typegen.c b/tools/widl/typegen.c index 2b0e414..7dfa0b2 100644 --- a/tools/widl/typegen.c +++ b/tools/widl/typegen.c @@ -3046,7 +3046,7 @@ static void write_parameter_conf_or_var_exprs(FILE *file, int indent, const char } break; } - else if (type->type == RPC_FC_IP) + else if (type->type == RPC_FC_IP || type->type == 0) { expr_t *iid; -- 1.5.6.5

2 1

Re: advapi32: fix failing tests for Windows 2007
by Alexandre Julliard 10 Jan '09

10 Jan '09

"Jeff Zaroyko" <jeffzaroyko(a)gmail.com> writes: > From 5f8813a25338ce88a150dac09e5811dd1246383f Mon Sep 17 00:00:00 2001 > From: Jeff Zaroyko <jeffz(a)jeffz.name> > Date: Sat, 10 Jan 2009 20:16:44 +1100 > Subject: advapi32: fix failing tests for Windows 2007 I don't think it makes sense to fix the tests for a beta version. We need to wait until the final release to find out which behavior changes are for real and which are just bugs in the beta. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: #ifdef out some code that is not needed on non-i386
by Alexandre Julliard 10 Jan '09

10 Jan '09

"Austin English" <austinenglish(a)gmail.com> writes: > Alexandre fixed most of it in > 13df062d3686a9b1961f0877aa8aaccd1fdc7332, but missed these. Tested on > Linux with PPC/i386. Please don't add extra ifdefs to work around missing implementations. FormatMessage needs to be implemented on other platforms, and the warning only shows that the code is incomplete. The proper fix is to implement it, not silence the warning. This applies to most of your other patches as well. -- Alexandre Julliard julliard(a)winehq.org

1 0

running msys under wine
by Luke Kenneth Casson Leighton 10 Jan '09

10 Jan '09

http://bugs.winehq.org/show_bug.cgi?id=13606 folks, hi, am running a configure script under wine, and it's _literally_ one to two seconds per sh.exe instance. i started running ./configure over two hours ago and there are about 100 lines of output so far, with a further 200 to go i am better off leaving this running overnight. as this is development work i am doing, not "building something that's already known to work" i have to call a halt to the development, because it is crazy to expect to have to wait four to six hours if i make a single change to configure.in or Makefile.pre.in - god help me if i have to run autoconf (fortunately i can do that from linux). ... so i did some investigation: strace -o log.txt -ff wine cmd followed by running c:\msys\msys.bat ignoring the fact that sh.exe crashed on me (which it doesn't do when you don't use strace) i was able to obtain some system call usage when firing up sh.exe, and it's _horrendous_. X11 keyboard files, X11 locale files, iconv, windows fonts, unix fonts - all to fire up c:/msys/bin/sh.exe ? further up the strace files, i'm looking at the biggest offender and it looks like it's reading files one byte at a time. reconstructing some of the sentences i can make out "remember that we get here even under command.com\r\n". ohhh i remember where i've seen that - that's in msys.bat. .... why is it being read one byte at a time?? there are _thousands_ of lines like this: rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 read(13, "t", 1) = 1 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 write(3, "7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(6, "\r\0\0\300\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 write(3, "4\0\0\0\0\0\0\0\0\0\0\0?\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(6, "$\0\0\300\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 checking earlier in the same strace log file (the one that loaded msys.bat one byte at a time) _again_ i see font-loading (every single one on my system). there are _forty_ instances of libraries being loaded - per process! open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 3 open("/usr/lib/libwine.so.1", O_RDONLY) = 3 open("/usr/lib/wine/wine-pthread", O_RDONLY) = 3 open("/usr/lib/libwine.so.1", O_RDONLY) = 3 open("/usr/lib/wine/ntdll.dll.so", O_RDONLY) = 3 open("/usr/lib/wine/kernel32.dll.so", O_RDONLY) = 7 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 7 open("/usr/lib/wine/cmd.exe.so", O_RDONLY) = 10 open("/usr/lib/wine/shell32.dll.so", O_RDONLY) = 10 open("/usr/lib/wine/shlwapi.dll.so", O_RDONLY) = 10 open("/usr/lib/wine/user32.dll.so", O_RDONLY) = 10 open("/usr/lib/wine/gdi32.dll.so", O_RDONLY) = 10 open("/usr/lib/wine/advapi32.dll.so", O_RDONLY) = 10 open("/usr/lib/wine/comctl32.dll.so", O_RDONLY) = 10 open("/usr/lib/wine/krnl386.exe16", O_RDONLY|O_LARGEFILE) = 10 open("/usr/lib/wine/system.drv16", O_RDONLY|O_LARGEFILE) = 10 open("/usr/lib/wine/gdi.exe16", O_RDONLY|O_LARGEFILE) = 10 open("/usr/lib32/libfreetype.so.6", O_RDONLY) = 10 open("/usr/lib32/libz.so.1", O_RDONLY) = 10 open("/usr/lib32/libexpat.so.1", O_RDONLY) = 10 open("/usr/lib/wine/user.exe16", O_RDONLY|O_LARGEFILE) = 10 open("/usr/lib/wine/winex11.drv.so", O_RDONLY) = 10 open("/usr/lib32/libSM.so.6", O_RDONLY) = 10 open("/usr/lib32/libICE.so.6", O_RDONLY) = 10 open("/usr/lib32/libXxf86vm.so.1", O_RDONLY) = 10 open("/usr/lib32/libXext.so.6", O_RDONLY) = 10 open("/usr/lib32/libX11.so.6", O_RDONLY) = 10 open("/usr/lib32/libXau.so.6", O_RDONLY) = 10 open("/usr/lib32/libxcb-xlib.so.0", O_RDONLY) = 10 open("/usr/lib32/libxcb.so.1", O_RDONLY) = 10 open("/usr/lib32/libXdmcp.so.6", O_RDONLY) = 10 open("/usr/lib/wine/imm32.dll.so", O_RDONLY) = 10 open("/usr/lib32/libXinerama.so.1", O_RDONLY) = 11 open("/usr/lib32/libXrender.so.1", O_RDONLY) = 11 open("/usr/lib32/libXrandr.so.2", O_RDONLY) = 11 open("/usr/lib32/libXcomposite.so.1", O_RDONLY) = 11 open("/usr/lib32/libXfixes.so.3", O_RDONLY) = 11 open("/usr/lib32/libXcursor.so.1", O_RDONLY) = 11 open("/usr/lib/wine/uxtheme.dll.so", O_RDONLY) = 11 open("/usr/lib/wine/ole32.dll.so", O_RDONLY) = 11 open("/usr/lib/wine/rpcrt4.dll.so", O_RDONLY) = 11 open("/usr/lib/wine/iphlpapi.dll.so", O_RDONLY) = 11 open("/usr/lib/wine/start.exe.so", O_RDONLY|O_LARGEFILE) = 7 surely, on a console-based command shell, all of the fonts and the X11 libraries can be skipped? l.

4 6

Re: [PATCH 1/2] Add definitions used by reparse points
by Paul TBBle Hampson 10 Jan '09

10 Jan '09

On Wed, Jan 07, 2009 at 07:24:07PM +1100, Paul TBBle Hampson wrote: > Resend, removing C++-style comments > -- > Paul "TBBle" Hampson, Paul.Hampson(a)Pobox.com > Shorter .sig for a more eco-friendly paperless office. Any comments on this patch series? The only thing I've had for this resend of the two patches is that it's kinda long. I'm thinking if I need to split the second patch up further, I'd break it up into a patch that creates the test without doing any actual reparse point work (ie create directory, create files, count files, delete files, count files, clean up) and then one that does the junction point creation and tests that it matches the directory being linked to... I'm not sure that's a particularly useful change, but I can do it. Otherwise, is there anything else I'm dong wrong? -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

1 0

Student project pages online
by Dan Kegel 10 Jan '09

10 Jan '09

I finally threw together a page about the two student projects (win64 porting and dxdiag) I'm organizing; it's online at http://kegel.com/wine/sweng/2009/ Comments welcome. I had particular fun putting together the presentation at http://kegel.com/wine/sweng/2009/talk.html - Dan

1 0

Re: ntdll: fix a compiler warning on PowerPC (try 2)
by Austin English 10 Jan '09

10 Jan '09

On Mon, Jan 5, 2009 at 12:59 AM, Austin English <austinenglish(a)gmail.com> wrote: > Changed offset to be a %u since it's a USHORT. > > -- > -Austin > Anything wrong with this one? -- -Austin

1 0

Re: msvcrt: fix a compiler error on powerpc
by Austin English 10 Jan '09

10 Jan '09

2009/1/2 Austin English <austinenglish(a)gmail.com>: > char defaults to unsigned char on powerpc, so explicitly setting the > variable to be a signed char > > -- > -Austin > Anything wrong with this one? -- -Austin

1 0

SafeDisc v1.35.000 seems to not work 100% good, at least with Rayman 2.
by Milan Kostić 10 Jan '09

10 Jan '09

Really, it works for first few levels, but in the middle of "The Sanctuary of Stone and Fire" (and upper levels periodicaly) it start to gives "head of Pirate":) (screenshot attached) and no more playing is possibile. This is tried with old original CD and also with backup CD. Tested with wine-1.1.12 (first version in which graphics and sound are good), but actualy it needs only XP 'dinput.dll' native. And what is funny it work in all "Windows" versions, but not in XP. So, if maybe someone interested in this, i can debug (just tell me what can be usefull), give game saved states, etc.

2 1

mpr: fix a compiler error on PowerPC
by Steven Edwards 09 Jan '09

09 Jan '09

---------- Forwarded message ---------- From: art yerkes <art.yerkes(a)gmail.com> Date: 2009/1/9 Subject: Re: mpr: fix a compiler error on PowerPC To: Steven Edwards <winehacker(a)gmail.com> According to Art Yerkes who has a copy of PPC VC++ "Here's what I get. The first test (char) works identically to the second test (signed char), so the default has to be signed." -- 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

1 0

Re: mpr: fix a compiler error on PowerPC
by Francois Gouget 09 Jan '09

09 Jan '09

On Fri, 2 Jan 2009, Austin English wrote: > CHAR defaults to unsigned char on PowerPC, so explicitly setting hi/lo > to signed char to avoid this error. CHAR is a Windows type so I don't think it's right for it to be unsigned on PowerPC. Even more so since there is a UCHAR type. So I think the right thing to do is to fix the CHAR declaration in wtypes.h and winnt.h. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Research is the transformation of money to knowledge. Innovation is the transformation of knowledge to money. -- Dr. Hans Meixner

3 6

MSI Patch Feedback
by Andrew Nguyen 09 Jan '09

09 Jan '09

Hello, I've written a few patches against dlls/msi/action.c in an effort to rectify a difference in behavior with an MSI-based installer between Windows and Wine with regard to environment variable processing. Behavior not explicitly enumerated by MSDN is noted when a combination of the environment table "+" name prefix and "[~]" value expression are combined. How should I attempt to test the changes I have made, and is there anything I can do to improve the quality of my changes? Feedback is appreciated! -Andrew

4 3

Re: wined3d: Add code to cleanup device multistate_funcs
by Allan Tong 09 Jan '09

09 Jan '09

On Tue, Jan 6, 2009 at 10:45 PM, Allan Tong <actong88(a)gmail.com> wrote: > Second try, replaces both "wined3d: Fix a memory leak in > compile_state_table()" and "wined3d: Free multistate_funcs when > destroying the device" patches from yesterday. Anything wrong with this patch? - Allan

1 0

Re: ntdll: Change the WinXP service pack version to 3.0
by Alexandre Julliard 09 Jan '09

09 Jan '09

"Johan Dahlin" <jdahlin(a)gmail.com> writes: > Change the XP SP version to 3.0, as required by some recent apps. You also need to fix wine.inf and winecfg. -- Alexandre Julliard julliard(a)winehq.org

1 0

Does preloader attempt to fix ASR?
by Nicholas LaRoche 09 Jan '09

09 Jan '09

On a standard installation of Fedora 10 address space randomization is enabled by default. The base address of a process started by wine seems to change.. and it is easy to see when loading Dlls and checking their base addresses. Does the preloader attempt to compensate for this? Or is it necessary to use setarch to turn off ASR completely when debugging with reproducibility? $> setarch $(uname -p) -RL Regards, Nick

2 1

Re: kernel32: implement CPU detection for OpenBSD
by Francois Gouget 09 Jan '09

09 Jan '09

On Fri, 2 Jan 2009, Austin English wrote: @@ -544,7 +544,7 @@ VOID WINAPI GetSystemInfo( } fclose (f); } -#elif defined (__NetBSD__) +#elif defined (__NetBSD__) || defined(__OpenBSD__) { int mib[2]; int value[2]; @@ -557,31 +557,55 @@ VOID WINAPI GetSystemInfo( #ifdef CPU_FPU_PRESENT mib[1] = CPU_FPU_PRESENT; value[1] = sizeof(int); - if (sysctl(mib, 2, value, value+1, NULL, 0) >= 0) +#ifdef __OpenBSD__ + if (sysctl(mib, 2, value, (size_t *)(value+1), NULL, 0) >= 0) { +#else + if (sysctl(mib, 2, value, value+1, NULL, 0) >= 0) { +#endif This was wrong to start with because even if size_t is 8 bytes, value+1 will only have space for 4. Plus the code tests whether value changed instead of testing *value! I'm sending a patch to fix that. Then you can resend your patch adding just the defined(__OpenBSD__). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A polar bear is a cartesian bear after a coordinate transform.

1 0

Re: [shell32/tests 6/6] Skip a test on Vista
by Reece Dunn 08 Jan '09

08 Jan '09

2009/1/8 Paul Vriens <paul.vriens.wine(a)gmail.com>: > Hi, > > With this last patch all shlfileop tests succeed on all my boxes (Win95, > Win98, > NT4, W2K, W2K3 and Vista). > > Changelog > Skip a test on Vista +static BOOL on_vista = FALSE; + I don't see where this is used. Kudos for fixing the shell32:shfileop tests. - Reece

1 0

Re: setupapi/tests: Remove an unneeded cast.
by Hans Leidekker 08 Jan '09

08 Jan '09

On Thursday 08 January 2009 00:05:01 Francois Gouget wrote: > memset(buffer, 0x55, sizeof(buffer)); > - retval = pStringTableLookUpStringEx(table, uilevel, ST_CASE_SENSITIVE_COMPARE, buffer, (LPDWORD)0); > + retval = pStringTableLookUpStringEx(table, uilevel, ST_CASE_SENSITIVE_COMPARE, buffer, NULL); > ok(retval != ~0u, "failed find 'UILEVEL' in string table\n"); > ok(memcmp(buffer, &data, 4), "unexpected data\n"); This test is there to show that the prototype of StringTableLookUpStringEx is broken; the last parameter is treated as an integer instead of a pointer and this notation serves to document that fact. But I can see how this will repeatedly trigger janitorial scripts, so I do not object to this patch going in. -Hans

6 7

Dates in Wine announcement
by Ian Macfarlane 08 Jan '09

08 Jan '09

Very small suggestion - it would be helpful to have dates included somewhere (preferably near the top) of the wine announce pages, for example: http://www.winehq.org/announce/1.1.12 This will let people who come to it via search engines know what date this particular release was made on, without having to dig around. (it will also help prevent people mistaking an old development release for a new one - I'm sure most people have seen at least one news story about something where the reporter/blogger is reporting years-old news as new because they didn't look at the dates on the article, or there were no dates or they were a hard to spot grey colour). Just a small suggestion. Ian

4 3

WIDL and Windows rpcrt4
by Ge van Geldorp 08 Jan '09

08 Jan '09

Hi Rob, Is WIDL supposed to generate code that's compatible with Windows RPCRT4.DLL? Because it appears this is currently not the case. When you look at http://test.winehq.org you'll see that the rpcrt4:server test fails on pretty much any Windows version. I investigated a bit more, the failures are caused by an exception 0x6e6 ("An internal error occurred in a remote procedure call (RPC)" thrown from NdrPointerBufferSize() in server_c.c function get_name(). The mingw-crosscompiled executable doesn't handle that exception which causes the process to crash. Since this is in WIDL-generated code, I decided to take a look at what MIDL generates for the same IDL file. It turns out that MIDL treats the name_t struct as a simple structure, while WIDL treats it as a complex structure. That made comparison a bit difficult. Since WIDL never seems to generate simple structures, I tried to convince MIDL to generate a complex structure too. After a bit of fiddling around (I'm no IDL expert...) I came up with the following type, a mix of name_t and sun_t: typedef struct { [string, size_is(size)] char *name; unsigned int size; [switch_is(s)] union { [case(SUN_I)] int i; [case(SUN_F1, SUN_F2)] float f; [case(SUN_PI)] int *pi; } u; int s; } complex_t; After staring at the WIDL-generated and MIDL-generated code for a while (which still differed quite a bit), I noticed something interesting: in the type format string, "unsigned int size" gets encoded as FC_ULONG by WIDL, but as FC_LONG by MIDL. I then went back to the server_c.c and server_s.c files generated by WIDL for the tests and changed the type format strings there (replaced the "unsigned int size" encoding from FC_ULONG by FC_LONG). With this change, the get_name() test passes :-). It then crashes later on with an access violation inside NdrVaryingArrayUnmarshall() in get_5numbers(), but let's take the problems one at a time... So it appears Windows RPCRT4.dll is not happy with FC_ULONG entries within a complex structure. I added a bunch of other primitive types to my complex_t structure to see how they are treated by MIDL. See attached complex.idl file and the MIDL-generated midl_complex_c.c file (also attached WIDL-generated widl_complex_c.c for completeness). It appears that MIDL simply drops the "unsigned" from any base type, at least within complex structures. "unsigned long" gets encoded as FC_LONG, "unsigned short" as FC_SHORT and "unsigned small" as FC_SMALL. Like I said, I'm no IDL expert. Does the stuff above make sense to you? Do you think it would be a good idea to change WIDL to generate the same encodings as MIDL? Thanks, Gé.

3 3

D3D shaders
by Anton Romanov 08 Jan '09

08 Jan '09

Hi. First, sorry for maybe somewhat newbish questions/approach... but anyway. Do i understand correctly that wined3d implementation takes d3d shaders' bytecode and converts it to other format depending on hardware? What is the state of wine's d3d shaders' implementation? I'm asking because I've recently came across a MojoShader (http://icculus.org/mojoshader/) project which is a library (zlib licensed) to convert compiled Direct3D shaders from bytecode to some other format (several profiles). The library seems to work well - it is used for OpenGL renderer in Unreal Tournament 3 engine. So i wonder - can there be some benefit to wine from such a project? Thanks.

2 1

Implementing b3DAccelerationExists and b3DAccelerationEnabled in dxdiagn
by Markus 08 Jan '09

08 Jan '09

Hello, can anyone tell me where to find information about the b3DAccelerationExists and b3DAccelerationEnabled properties in the display container returned by dxdiagn.dll and when they are supposed to be false or true? In fact, MSDN does not seem to provide information about any of the properties returned by that dll. Thanks, -- Markus

3 5

Proof the new site design is superior!
by Dan Kegel 08 Jan '09

08 Jan '09

The new site design is already paying dividends. Look: http://www.zmogo.com/gear/the-new-year-linux-resolution-day-5/ says: "... I chose Wine mainly because its site is more appealing looking than VMware's, which has all the sleek design features and well-considered organization of an expired domain name..." :-)

2 1

Re: mshtml: Implement IHTMLStyle get/set Attribute
by Alistair Leslie-Hughes 08 Jan '09

08 Jan '09

Hi, Is there anything wrong with this patch? Best Regards Alistair Leslie-Hughes > From dca7b396838e3367ad78144ccb07aed24cd5917f Mon Sep 17 00:00:00 2001 > From: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > Date: Mon, 5 Jan 2009 21:22:35 +1100 > Subject: [PATCH] Implement IHTMLStyle get/set Attribute > To: wine-patches <wine-patches(a)winehq.org> > > --- > dlls/mshtml/htmlstyle.c | 69 > ++++++++++++++++++++++++++++++++++++++++++---- > dlls/mshtml/tests/dom.c | 36 ++++++++++++++++++++++++ > 2 files changed, 99 insertions(+), 6 deletions(-) > > diff --git a/dlls/mshtml/htmlstyle.c b/dlls/mshtml/htmlstyle.c > index fa4ad51..3453f7b 100644 > --- a/dlls/mshtml/htmlstyle.c > +++ b/dlls/mshtml/htmlstyle.c > @@ -2048,18 +2048,75 @@ static HRESULT WINAPI > HTMLStyle_setAttribute(IHTMLStyle *iface, BSTR strAttribut > VARIANT AttributeValue, LONG lFlags) > { > HTMLStyle *This = HTMLSTYLE_THIS(iface); > - FIXME("(%p)->(%s v%d %08x)\n", This, debugstr_w(strAttributeName), > - V_VT(&AttributeValue), lFlags); > - return E_NOTIMPL; > + HRESULT hres; > + DISPID dispid; > + > + TRACE("(%p)->(%s v%d %08x)\n", This, debugstr_w(strAttributeName), > + V_VT(&AttributeValue), lFlags); > + > + if(!strAttributeName) > + return E_INVALIDARG; > + > + if(lFlags == 1) > + FIXME("Parameter lFlags ignored\n"); > + > + hres = HTMLStyle_GetIDsOfNames(iface, &IID_NULL, > (LPOLESTR*)&strAttributeName, 1, > + LOCALE_USER_DEFAULT, &dispid); > + if(hres == S_OK) > + { > + VARIANT ret; > + DISPID dispidNamed = DISPID_PROPERTYPUT; > + DISPPARAMS params; > + > + params.cArgs = 1; > + params.rgvarg = &AttributeValue; > + params.cNamedArgs = 1; > + params.rgdispidNamedArgs = &dispidNamed; > + > + hres = HTMLStyle_Invoke(iface, dispid, &IID_NULL, > LOCALE_SYSTEM_DEFAULT, > + DISPATCH_PROPERTYPUT, &params, &ret, NULL, NULL); > + } > + else > + { > + FIXME("Custom attributes not supported.\n"); > + } > + > + TRACE("ret: %08x\n", hres); > + > + return hres; > } > > static HRESULT WINAPI HTMLStyle_getAttribute(IHTMLStyle *iface, BSTR > strAttributeName, > LONG lFlags, VARIANT *AttributeValue) > { > HTMLStyle *This = HTMLSTYLE_THIS(iface); > - FIXME("(%p)->(%s %08x %p)\n", This, debugstr_w(strAttributeName), > - lFlags, AttributeValue); > - return E_NOTIMPL; > + HRESULT hres; > + DISPID dispid; > + > + TRACE("(%p)->(%s v%p %08x)\n", This, debugstr_w(strAttributeName), > + AttributeValue, lFlags); > + > + if(!AttributeValue || !strAttributeName) > + return E_INVALIDARG; > + > + if(lFlags == 1) > + FIXME("Parameter lFlags ignored\n"); > + > + hres = HTMLStyle_GetIDsOfNames(iface, &IID_NULL, > (LPOLESTR*)&strAttributeName, 1, > + LOCALE_USER_DEFAULT, &dispid); > + if(hres == S_OK) > + { > + DISPPARAMS params = {NULL, NULL, 0, 0 }; > + > + hres = HTMLStyle_Invoke(iface, dispid, &IID_NULL, > LOCALE_SYSTEM_DEFAULT, > + DISPATCH_PROPERTYGET, &params, AttributeValue, NULL, NULL); > + } > + else > + { > + FIXME("Custom attributes not supported.\n"); > + } > + > + return hres; > } > > static HRESULT WINAPI HTMLStyle_removeAttribute(IHTMLStyle *iface, BSTR > strAttributeName, > diff --git a/dlls/mshtml/tests/dom.c b/dlls/mshtml/tests/dom.c > index de363bb..516aa3e 100644 > --- a/dlls/mshtml/tests/dom.c > +++ b/dlls/mshtml/tests/dom.c > @@ -2745,6 +2745,42 @@ static void test_default_style(IHTMLStyle *style) > ok(hres == S_OK, "put_overflow failed: %08x\n", hres); > SysFreeString(sOverflowDefault); > > + /* Attribute Tests*/ > + hres = IHTMLStyle_getAttribute(style, NULL, 1, &v); > + ok(hres == E_INVALIDARG, "getAttribute failed: %08x\n", hres); > + > + str = a2bstr("position"); > + hres = IHTMLStyle_getAttribute(style, str, 1, NULL); > + ok(hres == E_INVALIDARG, "getAttribute failed: %08x\n", hres); > + > + hres = IHTMLStyle_getAttribute(style, str, 1, &v); > + ok(hres == S_OK, "getAttribute failed: %08x\n", hres); > + ok(V_VT(&v) == VT_BSTR, "type failed: %d\n", V_VT(&v)); > + VariantClear(&v); > + > + hres = IHTMLStyle_setAttribute(style, NULL, v, 1); > + ok(hres == E_INVALIDARG, "getAttribute failed: %08x\n", hres); > + > + V_VT(&v) = VT_BSTR; > + V_BSTR(&v) = a2bstr("absolute"); > + hres = IHTMLStyle_setAttribute(style, str, v, 1); > + ok(hres == S_OK, "setAttribute failed: %08x\n", hres); > + VariantClear(&v); > + > + hres = IHTMLStyle_getAttribute(style, str, 1, &v); > + ok(hres == S_OK, "getAttribute failed: %08x\n", hres); > + ok(V_VT(&v) == VT_BSTR, "type failed: %d\n", V_VT(&v)); > + ok(!strcmp_wa(V_BSTR(&v), "absolute"), "str=%s\n", > dbgstr_w(V_BSTR(&v))); > + VariantClear(&v); > + > + V_VT(&v) = VT_BSTR; > + V_BSTR(&v) = NULL; > + hres = IHTMLStyle_setAttribute(style, str, v, 1); > + ok(hres == S_OK, "setAttribute failed: %08x\n", hres); > + VariantClear(&v); > + > + SysFreeString(str); > + > hres = IHTMLStyle_QueryInterface(style, &IID_IHTMLStyle2, > (void**)&style2); > ok(hres == S_OK, "Could not get IHTMLStyle2 iface: %08x\n", hres); > if(SUCCEEDED(hres)) { > -- > 1.5.4.3 > > -------------------------------------------------------------------------------- > >

1 0

Unused function in quartz
by Francois Gouget 07 Jan '09

07 Jan '09

Hi, In the following commit you added the OutputPin_DeliverNewSegment() function to pin.c. However today it is unused. Is there any plan to use it? Is it still relevant? commit 0a6f11c88a8da49d80e4e7d8a0236ae4b36926b7 Author: Robert Shearman <R.J.Shearman(a)warwick.ac.uk> Date: Thu Sep 25 23:50:06 2003 +0000 - A few cosmetic fixes. - Various bug fixes. - Add some OutputPin helpers. - Add a new type of pin, PullPin. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ In a world without fences who needs Gates?

3 2

Re: compiling python2.5 on linux under wine
by Luke Kenneth Casson Leighton 07 Jan '09

07 Jan '09

On Sat, Jan 3, 2009 at 9:22 PM, Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> wrote: > hey, has anyone investigated compiling python2.5 using winegcc, under wine? some people might find this kind of thing amusing. it's considered in very obtuse circles to be "progress"... :) lkcl@gonzalez:/mnt/src/python2.5-2.5.2/Lib$ ../build/python -v Could not find platform independent libraries <prefix> Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] # installing zipimport hook import zipimport # builtin # installed zipimport hook 'import site' failed; traceback: ImportError: No module named site Python 2.5.2 (r252:60911, Jan 7 2009, 20:33:53) [gcc] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import site fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored [....] [....] [....] import sre_compile # from Z:\mnt\src\python2.5-2.5.2\Lib\sre_compile.py fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored # wrote Z:\mnt\src\python2.5-2.5.2\Lib\sre_compile.pyc import _sre # builtin import sre_constants # from Z:\mnt\src\python2.5-2.5.2\Lib\sre_constants.py # wrote Z:\mnt\src\python2.5-2.5.2\Lib\sre_constants.pyc import sre_parse # from Z:\mnt\src\python2.5-2.5.2\Lib\sre_parse.py # wrote Z:\mnt\src\python2.5-2.5.2\Lib\sre_parse.pyc Traceback (most recent call last): File "<stdin>", line 1, in <module> File "site.py", line 415, in <module> main() File "site.py", line 406, in main aliasmbcs() File "site.py", line 356, in aliasmbcs import locale, codecs File "Z:\mnt\src\python2.5-2.5.2\Lib\locale.py", line 167, in <module> import re, operator File "Z:\mnt\src\python2.5-2.5.2\Lib\re.py", line 223, in <module> _pattern_type = type(sre_compile.compile("", 0)) File "Z:\mnt\src\python2.5-2.5.2\Lib\sre_compile.py", line 530, in compile groupindex, indexgroup OverflowError: signed integer is less than minimum >>>

1 0

Re: AppDB: Rating / Patching
by James Mckenzie 07 Jan '09

07 Jan '09

>On Tue, Jan 6, 2009 at 6:48 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote: >> >>> Now, the story changes if the patch is conforming and has been accepted >>> by AJ and is pending the next development release. >>> >> Then the next development release can get the gold, but previous ones still shouldn't. AppDB test ratings are tied to specific releases, and intended to tell normal users how different versions of Wine will work with their app. Patching Wine is not something normal users can or want to do, and allowing ratings based on patched versions of Wine is misleading, even if the patch does eventually make it in to a later release. > >It sounds like the problem is that the version string in appdb isn't >descriptive enough. It's perfectly reasonable to wonder if a given >program can be made to work with a patched version of wine, and wonder >how well it will work. It's also reasonable to wonder how it will >work with a vanilla version. Both types of reports are useful to have >in the appdb. Having a version "x.x.x (patched)" available to >reporters would allow both types of reports to be clearly separated. > No, the appdb should not be touched. Rosanne said it correctly, ordinary users are NOT going to take the time to build Wine, nor should they. We can put in the bug report that the patch works and whether or not it has been submitted. Sometimes a patch is to rough or a real hack that breaks other programs, but with refinement is acceptable and will be incorporated into Wine. The appdb needs to stay as clean as it can. Of course, you can always add a bug report to the appdb entry, add comments and let users decide what they want to do. Rating a rogue patched Wine as Gold is very misleading. We need to keep ratings to what is available for the ordinary, unknowing user (read nOOb.) James McKenzie

7 8

New appdb checkbox: "officially supports wine"?
by Dan Kegel 07 Jan '09

07 Jan '09

http://wiki.winehq.org/AppsThatSupportWine is a nice stopgap, but perhaps it should be a report in the appdb, driven by a checkbox that maintainers can check. What do folks think?

4 3

Re: readme: add a note about UNIX paths
by James Hawkins 07 Jan '09

07 Jan '09

On Tue, Jan 6, 2009 at 7:04 PM, Austin English <austinenglish(a)gmail.com> wrote: > Adds a note discouraging use of UNIX paths, since there's seems to > have been a rash of it in recent bug reports. > If we don't recommend it, and usually advise against it, why not just remove that line from the README? -- James Hawkins

4 5

Re: AppDB: Rating / Patching
by James Mckenzie 07 Jan '09

07 Jan '09

Sparr <sparr0(a)gmail.com> wrote: >On Wed, Jan 7, 2009 at 4:47 AM, Chris Howe <mrmessiah(a)gmail.com> wrote: >> argument for some kind of WineTricks-like Wine application launcher >> that would exist as a separate project to Wine, but would apply patches, > >Re-compiling wine with patches is an extremely farfetched idea when no >one outside Cedega has ever tackled the far simpler tasks involved >with making a wine launcher. > I take offesense to that comment. Darwine does have a wine launcher and it does work. James McKenzie

1 0

Re: AppDB: Rating / Patching
by James Mckenzie 07 Jan '09

07 Jan '09

Sparr <sparr0(a)gmail.com> wrote: >On Wed, Jan 7, 2009 at 4:47 AM, Chris Howe <mrmessiah(a)gmail.com> wrote: >> argument for some kind of WineTricks-like Wine application launcher >> that would exist as a separate project to Wine, but would apply patches, > >Re-compiling wine with patches is an extremely farfetched idea when no >one outside Cedega has ever tackled the far simpler tasks involved >with making a wine launcher. > I take offesense to that comment. Darwine does have a wine launcher and it does work. James McKenzie

1 0

why are we not using pkg-config in configure
by Danny Rawlins 07 Jan '09

07 Jan '09

Hi, I would like to know if there is any issues as to why we are not using pkg-config to check for needed library's with the m4 macros. Also this question arose in #winehackers TBBle> Hmm. Is pkg-config broken under mingw? And do we care? Regards, Danny Rawlins

2 1

Re: [PATCH 1/2] Add definitions used by reparse points
by Paul Vriens 07 Jan '09

07 Jan '09

Paul TBBle Hampson wrote: > Not much to say about this. It's needed for the unit tests coming up. > > > ------------------------------------------------------------------------ > > Hi Paul, Part of your signature says: License: http://creativecommons.org/licenses/by/2.5/au/ Does this mean your patches come under this license (or is it just the signature ;))? -- Cheers, Paul.

2 1

Re: [1/2] dlls: Add loadperf.dll
by Andrew Nguyen 07 Jan '09

07 Jan '09

On Tue, Jan 6, 2009 at 8:21 AM, Andrey Turkin <andrey.turkin(a)gmail.com> wrote: > .NET 1.1 uses this dll during installation > > --- > configure.ac | 1 + > dlls/loadperf/Makefile.in | 13 +++++++++++++ > dlls/loadperf/loadperf.spec | 14 ++++++++++++++ > dlls/loadperf/loadperf_main.c | 29 +++++++++++++++++++++++++++++ > 4 files changed, 57 insertions(+), 0 deletions(-) > create mode 100644 dlls/loadperf/Makefile.in > create mode 100644 dlls/loadperf/loadperf.spec > create mode 100644 dlls/loadperf/loadperf_main.c > You've forgotten to append the licensing header to loadperf_main.c.

1 0

Re: [PATCH 1/2] Add definitions used by reparse points
by Austin English 07 Jan '09

07 Jan '09

On Wed, Jan 7, 2009 at 12:05 AM, Paul TBBle Hampson <Paul.Hampson(a)pobox.com> wrote: > Not much to say about this. It's needed for the unit tests coming up. > -- > ----------------------------------------------------------- > Paul "TBBle" Hampson, B.Sc, LPI, MCSE > Very-later-year Asian Studies student, ANU > The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) > Paul.Hampson(a)Pobox.com > > Of course Pacman didn't influence us as kids. If it did, > we'd be running around in darkened rooms, popping pills and > listening to repetitive music. > -- Kristian Wilson, Nintendo, Inc, 1989 > > License: http://creativecommons.org/licenses/by/2.5/au/ > ----------------------------------------------------------- > > > > +// Used for all tags where IsReparseTagMicrosoft is false +// and for some tags where IsReparseTagMicrosoft is true Please use /* comments */, not C++ style. -- -Austin

2 1

AppDB: Rating / Patching
by Björn Krombholz 07 Jan '09

07 Jan '09

Hi, I started a discussion inside AppDB about the in my eyes "strange" Gold rating of Fallout 3 (it's actually just an example, other entries suffer the same problems). I know there was a discussion about the rating on this list last month, but as far as I could see my particular issue wasn't covered and I only just subscribed. So here goes a new thread. The appdb thread [1] is included below (prevent OT-cleanup deletion inside appdb). I don't expect anyone to read it completely, but I didn't want to repeat every argument again either. ;) The basic point is: Fallout 3 (a game) only works with a small -- but nevertheless -- patch, otherwise it will crash, no matter what dll-overrides/settings/3rd-party apps. From how I understand the wording in [2], an app that requires a patch to run, can't get a gold rating. In fact, if there is no way to get it working in a vanilla wine release, then there is no other option than "Garbage" IMO. The various arguments for that assumption (possible breaking of other apps run by the same wine installation, regression tracking, etc.) are in the quote below. The maintainer tried to convince me that a gold rating is valid, because Fallout 3 works great with the patch applied. Well obviously he failed, and the discussion went away from Fallout in particular to a more general interpretation of [2]. I'm neither saying I'm right and he's wrong, nor the other way around. IMO both interpretation can be valid, depending on how you read "some DLL overrides, other settings or third party software." My suggestion now would be: * Clarify the wording on what "other settings" really means (my interpretation is mainly registry modifications with winecfg and/or regedit). * Add an explicit statement about patched wine versions. Something like: - Any application that requires a patched wine to run MUST NOT be rated higher than "Garbage" (or whatever rating was intended for this situation). [1] http://appdb.winehq.org/objectManager.php?sClass=version&iId=14322#Comment-… [2] http://appdb.winehq.org/help/?sTopic=maintainer_ratings Björn ==== Copy from AppDB discussion [1] below ==== Björn Krombholz on Monday January 5th 2009, 10:10: Hi, I don't understand the recent ratings. I've played the game a lot under Windows and with various versions of wine, using all kinds of different tweaks and settings the game itself and wine offer. It runs pretty well and it's become even better (meaning faster) since 1.11 (no evidence, could be caused by a driver update as well). Nevertheless, as far as I can see, noone has ever managed to get past menu + the loading screen without at least applying the D3D patch attached to [1], that allows setting the VideoDescription and VideoDriver in the registry. For flawless mouse interaction, you also need the mouse hack from [2]. Considering these 2 as a fact (please correct me, if there actually is a way to run it without patches), how can it ever be rated higher than "Garbage"? My understanding of the ratings are, that they offer a quick hint on what you are able to run (nearly) without problems, while the discussion and howto sections deal with "broken" stuff and tell a user, how he might be able to run an app/game despite the garbage state. [1] http://bugs.winehq.org/show_bug.cgi?id=15839 [2] http://bugs.winehq.org/show_bug.cgi?id=6971 ----- RE: Rating / Patching by Tymoteusz Paul on Monday January 5th 2009, 10:20 Let me explain you how ranking system works, because you seem to have it confused. As expalined in http://appdb.winehq.org/help/?sTopic=maintainer_ratings gold/silver rating is ok as long as you can use it for it's purpose. All you have to do is override couple dlls and settings and then the game is working pretty much flawlessy. Garbage rating would be then if it was impossible to play the game. Ratings as is provide good info about the game, if you see that its rated as gold - then you are safe to buy it for linux playig, it may take some work to get it work but it will work and will be playable. Only rating that fits your description "hint on what you are able to run (nearly) without problems" fits platinum rating, which this game didn't get so far. Hope this will be more clear for you now. ----- RE: Rating / Patching by Björn Krombholz on Monday January 5th 2009, 14:08 I was referring to this help text as well, although I read it differently. ;) In any vanilla/clean release version of wine, Fallout 3 won't run. You get the menu, can change settings, but when you start the game to play ("purpose it was designed") it crashes, even "with some DLL overrides, other settings or third party software" you install in wine. => Garbage rating. Let's imagine the small driver patch in bug 15839 was applied to the development tree and so released with 1.1.13. The game would become playable with one major "issue". No matter what settings you change/etc. the mouse is either always stuck in the middle of the screen or it gets stuck at the screen edges (bug 9671). => Bronze rating for wine >= 1.1.13. Maybe even Silver, as it might work very well with a different kind of controller like a gamepad. Now the mouse bug gets fixed in 1.1.x. Suddenly all you need to do is to override some (actually just one) dlls and tweak some settings to make it enjoyable. => Silver (in case you consider Live functionality an important part of the program) or Gold rating. Eventually someone adds the d3dx9_38.dll to wine and the DeviceDriver + DeviceDescription settings will be automatically detected by wine. That means the game works flawlessly without touching any wine setting. => Platinum rating. IMO this makes sense, otherwise a version 1.1.x gold app, wouldn't be downgradable in its rating for 1.1.x+1 (in case version x+1 introduced a regression that breaks this app); because all you had to do to make it work again is unapply the faulty patch. In addition to that, users wouldn't be encouraged to file a bug report if there is source-patch that upgrades it to gold anyway. Anyway, I don't care much about which interpretation should be used, I just want it to be more consistent. As you can see in the reports history Fallout 3 people rated in both ways. E.g., the newest one voting gold, because it works great after patching according to the HOWTO; http://appdb.winehq.org/objectManager.php?sClass=version&iId=14322&iTesting… rating "Garbage" because "Mouse is borked and gameplay is impossible without patches. Which would be the best way to ask for a more indisputable explanation on the help page? Filing a bug report against appdb or using the "Email Us" link at the right, or ...? ----- RE: Rating / Patching by Radosław Ciechowski on Monday January 5th 2009, 15:15 Gold is for apps that "Works flawlessly with DLL overrides, third party software or other settings" so if Fallout 3 is working without bugs after applaying patches, dll-s and other settings it should be rated Gold. If there was no way to get it working or there were lots of bugs after all tweaks, then it could be rated Garbage. If game works flawlessly then no matter how mamy things you have to do, it can be rated Gold which makes sense for me. There is no sense in rating apps Garbage when they can work flawlessly ! Also there is already rating system which we are using ( http://appdb.winehq.org/help/?sTopic=maintainer_ratings ) and changing it now wouldnt be a good idea. ----- RE: Rating / Patching by Björn Krombholz on Monday January 5th 2009, 15:55 > Gold is for apps that "Works flawlessly with DLL overrides, third party software or other settings" < Indeed, that's what I'm saying. But applying a patch to the wine source and recompiling it -- which effectively makes it some _different_ version than the _release_ version you are supposed to rate -- is neither of those 3. - "DLL override": installing a custom DLL into $WINEPREFIX and adding the override) - "third party software": installing additional software into $WINEPREFIX that is needed and expected by the app you want to run - "other settings": tweak the wine registry and similar configuration None of these change the wine version, any such change would still be a "wine 1.1.x", while patches like the mouse patch might even break other software even if those are installed in a different $WINEPREFIX, because the binary changed and it's behaviour is different from the official release. You can't say "A is running well on wine 1.1.x", if in fact it is running well on wine 1.1.x+patch, while it actually breaks on wine 1.1.x. And yes, as I already said, there is a help page for the rating system. I don't ask to change, but to clarify it, as at the moment people are rating differently depending on their interpretation. This has become OT on this page - I will try to move it to the -devel list. :)

8 12

Re: PR 16828 dlls/ntdll/serial.c clear IEXTEN when clearing ICANON
by Austin English 06 Jan '09

06 Jan '09

On Tue, Jan 6, 2009 at 12:49 PM, G. Paul Ziemba <p-wine-bugs(a)ziemba.us> wrote: > FreeBSD fix for Nirvis CDJ application, PR 16828 > > > --- dlls/ntdll/serial.c.orig 2008-12-20 06:55:38.000000000 -0800 > +++ dlls/ntdll/serial.c 2009-01-05 21:35:47.000000000 -0800 > @@ -648,7 +648,9 @@ > port.c_cflag &= ~(HUPCL); > port.c_cflag |= CLOCAL | CREAD; > > - port.c_lflag &= ~(ICANON|ECHO|ISIG); > + // on FreeBSD, turning off ICANON does not disable IEXTEN, > + // so we must turn it off explicitly. No harm done on Linux. > + port.c_lflag &= ~(ICANON|ECHO|ISIG|IEXTEN); > port.c_lflag |= NOFLSH; > > bytesize = slc->WordLength; > > > -- > G. Paul Ziemba > FreeBSD unix: > 10:46AM up 12 days, 21:25, 10 users, load averages: 0.21, 0.29, 0.23 > > > Again, no C++ comments. -- -Austin

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel