January 2009 - Wine-Devel - list.winehq.org

Making the file dialog resizable(implementing OFN_ENABLESIZING)
by Diaa Sami Jan. 26, 2009

Jan. 26, 2009

Hi, Can you please have a look at the patch at http://bugs.winehq.org/show_bug.cgi?id=10394 ? It's pretty much done except for some nasty bug and the repainting problem. -- Regards, Diaa Sami

1 0

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

Jan. 26, 2009

Alexandre Julliard <julliard(a)winehq.org> >Sent: Jan 26, 2009 7:21 AM >To: Paul Vriens <paul.vriens.wine(a)gmail.com> >Cc: James Mckenzie <jjmckenzie51(a)earthlink.net>, "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Re: Bugzilla question with respect to .NET 1.1SP1 > >Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > >> So that means bug 14850 needs to be reopened with a link to 13995? > >No, if it's the same bug it should be a single report. If .NET doesn't >install then obviously all apps that try to install it will be broken, >it doesn't make sense to create a separate bug for each app that suffers >from the problem. > Actually, I have a different opinion as the reason a program will not install may, at first appearance, be the lack of .NET1.1SP1 but may be another function that Wine does not provide. Paul is 'smart enough' to figure that the problem IS the lack of .NET functionality or the inability to install, but the common user may not. I say, open the bug, mark it as a duplicate of the existing bug and then close it. Add the reporter as a cc to the original bug. When the bug is resolved, then have the user attempt to install the program, if it still fails, reopen the duplicate with whatever does not work now. This keeps the number of bugs down and lets us know how much the lack of functionality affects the Wine user base. Some users complain of being lost in the shuffle because they add to an existing bug that another program is affected. What do you say about doing this? James McKenzie

2 1

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

Jan. 26, 2009

---------- 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 Jan. 26, 2009

Jan. 26, 2009

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 Jan. 26, 2009

Jan. 26, 2009

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 Jan. 26, 2009

Jan. 26, 2009

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 Jan. 26, 2009

Jan. 26, 2009

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 Jan. 26, 2009

Jan. 26, 2009

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 Jan. 26, 2009

Jan. 26, 2009

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 Jan. 26, 2009

Jan. 26, 2009

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