Re: UNC Pathname handling
Hi Alexandre, On 12/11/2009 09:02 AM, Alexandre Hardy wrote: Hi, I have written a patch to add basic UNC pathname support which tries to handle UNC pathnames according to the MSDN spec. The patch satisfies some of the UNC pathname tests for GetLongPathNameA, but is actually intended to fix GetLongPathNameW. I am not entirely satisfied with the patch, and would appreciate some comments. Some issues: 1) Paths prefixed by '\\?\' require GetLongPathName to handle strings of length 32767. I don't like the fact that the patch creates two such large strings on the local stack, should the memory be dynamically allocated only when needed? Dynamic is preferred. We maybe needs some tests to see what Windows does if we pass longer strings (without the '\\?\') to the A- and W-version and variants of this (including '\\?\'). 2) The handling of shares \\hostname\C$ is implemented, but no other shares are handled. And even in this case, only the host on which wine We need a more general way of handling UNC paths. We can't just have this single one (only local host and only C: drive) to satisfy the tests. This probably goes beyond GetLongPathName though. is executed is handled, no other hosts are handled. I have read that Windows 7 disables this share by default. So should wine be handling this particular URL, or should more general sharing be implemented? The test results on test.winehq.org tells us a different thing though. It looks like this is only the case for the Home versions of Windows. And (again) I think we need more general sharing to be implemented not just one case to have a test succeed. The patch is included as an attachment to this message. Kind regards Alexandre For what bug was this? -- Cheers, Paul.
Re: UNC Pathname handling
Hi Alexandre, On 12/11/2009 09:49 AM, Alexandre Hardy wrote: Hi Paul, I guess it could fall under bug #19807. I was actually testing it with Nokia Ovi Installer. (Please bottom post on wine-devel). So to fix 19807 you need to handle the '\\?\' cases only so it seems? Remember that GetLongPathNameA is forward to GetLongPathNameW and from the bug report one can't see which one is actually called. So you need a log file with either a +file trace or change the TRACE() in GetLongPathNameA to a FIXME(). -- Cheers, Paul.
Re: UNC Pathname handling
On 12/11/2009 10:03 AM, Alexandre Hardy wrote: Hi Paul, Stupid question: What do you mean by bottom post? I have added wine-devel as a CC to these messages, is that sufficient? http://en.wikipedia.org/wiki/Posting_style#Bottom-posting According to my log it seems to be a GetLongPathNameW. GetLongPathNameA does not exhibit the same problems as GetLongPathNameW. So GetLongPathNameA(path, NULL, 0) succeeds, while GetLongPathNameW(path, NULL, 0) segfaults. This is because GetLongPathNameA provides its own not NULL buffer to GetLongPathNameW. It also seems to me that only GetLongPathNameW is required to handle UNC pathnames that begin with '\\?\' (at least, that is how I understand the MSDN). Well, the tests show that the A-version also handles this case. -- Cheers, Paul.
Re: shdocvw: Fix test for non-english IE MUI (try 2)
2009/12/11 Alistair Leslie-Hughes leslie_alist...@hotmail.com: Hi, Changelog: shdocvw: Fix test for non-english IE MUI Best Regards Alistair Leslie-Hughes Hi Alistair, -ok(!strcmp_wa(sName, Microsoft Web Browser Control), got '%s', expected 'Microsoft Web Browser Control'\n, wine_dbgstr_w(sName)); +if (PRIMARYLANGID(LANGIDFROMLCID(GetThreadLocale())) == LANG_ENGLISH) +ok(!strcmp_wa(sName, Microsoft Web Browser Control), got '%s', expected 'Microsoft Web Browser Control'\n, wine_dbgstr_w(sName)); +else /* Non-English cannot be blant. */ +ok(sName!=NULL, get_Name return a NULL string.\n); Did you mean blank ? -- Nicolas Le Cam
Re: WineD3D: Frontbuffers are always onscreen
Am 10.12.2009 um 23:15 schrieb Henri Verbeet: 2009/12/10 Stefan Dösinger ste...@codeweavers.com: @@ -6304,7 +6304,7 @@ HRESULT create_primary_opengl_context(IWineD3DDevice *iface, IWineD3DSwapChain * ... -swapchain-context[0]-render_offscreen = swapchain-render_to_fbo; +swapchain-context[0]-render_offscreen = surface_is_offscreen(target); This will introduce a warning, surface_is_offscreen() takes an IWineD3DSurface pointer. Woops, I guess I should not use my own gcc all the time which chokes on the OSX headers and writes warning spam :-/ - Setting render_offscreen is really the responsibility of the context_create() call, similar to create_primary_opengl_context(). context_create() doesn't take a swapchain as parameter, only a window. This is correct, because GL contexts are linked to the drawable, not the swapchain. Thus context_create doesn't have the needed information to set the offscreen flag. (I could just pass in a TRUE or FALSE parameter, but there's something else) The reason why this line is needed however is because the context has a last render target set, and if the app never changes the render target the sorta-cached render-offscreen value never gets set properly. Maybe we should make sure that the full FindContext() runs at least once for a newly created context, then we can drop this line and the one in create_primary_opengl_context(). Should keeping the last_rt set to NULL after context creation work correctly? As a sidenode, maybe create_primary_opengl_context is named badly. It's not part of the context management, its a device helper function that happens to use the context management to set up a GL context, among other things. Maybe device_restart_opengl or something similar is better. - The line is actually wrong, the relevant context has been setup to render to the front buffer, so render_offscreen should always be FALSE, even if there is a back buffer. Well, this code is in the backbuffer path. Render_offscreen is false if we don't set it due to the alloc HEAP_ZERO_MEMORY. The point of the line is to set it to true if we render to an FBO. We never set a swapchain to render to the front buffer at creation time if there is a back buffer. - It doesn't make sense for render_to_fbo to be TRUE for a swapchain without back buffer. Correct, but this needs another patch to fix. First of all, render_to_fbo shouldn't matter when we're dealing with the front buffer, even when a back buffer is there. surface_is_offscreen takes care of that, but we have to use it. This is important when we're forcing render_to_fbo on for driver bug workarounds, or if we have a double buffered environment with render_to_fbo on for a real(non-driver) reason and access the front buffer due to some ddraw/d3d9ex tricks or wined3d internal stuff. In the ddraw windowed mode rendering situation rendering the backbuffer to a FBO is actually the correct thing to do, because from the application's point of view the backbuffer is an offscreen plain surface. We just construct a double-buffered GL setup to be able to use windowed ddraw rendering without FBOs on older drivers. Currently this triggers a few other bugs(e.g. in GetDC() + Client_storage) that I want to fix first. So the next step after fixing the GL errors and the GetDC bug is to ignore the back buffer size in CreateSwapchain and Reset if there is no backbuffer. Then render_to_fbo will be false for single buffered setups. The academic question afterwards is if we render windowed d3d7 setups to an FBO if available or not. If we have FBOs, the difference is small. I haven't seen an app that depends on this yet, and unless we are on MacOS 10.5 or earlier which cannot write to the front buffer I don't expect driver issues either. This whole thing is done do please drivers without FBOs. So once the other bugs are fixed I'll add a check to CreateSwapchain and reset to ignore the backbuffer size if backbuffercount == 0
Re: UNC Pathname handling
Hi Paul, I guess it could fall under bug #19807. I was actually testing it with Nokia Ovi Installer. So, If I take out the \\host\C$ part, then this patch won't change which tests are passed. So I think we need to add GetLongPathNameW tests. I'm going to give it a bash... I would prefer not to work further on UNC pathnames that refer to shares, I would rather try to solve other problems... Kind regards Alexandre On Fri, Dec 11, 2009 at 10:32 AM, Paul Vriens paul.vriens.w...@gmail.com wrote: Hi Alexandre, On 12/11/2009 09:02 AM, Alexandre Hardy wrote: Hi, I have written a patch to add basic UNC pathname support which tries to handle UNC pathnames according to the MSDN spec. The patch satisfies some of the UNC pathname tests for GetLongPathNameA, but is actually intended to fix GetLongPathNameW. I am not entirely satisfied with the patch, and would appreciate some comments. Some issues: 1) Paths prefixed by '\\?\' require GetLongPathName to handle strings of length 32767. I don't like the fact that the patch creates two such large strings on the local stack, should the memory be dynamically allocated only when needed? Dynamic is preferred. We maybe needs some tests to see what Windows does if we pass longer strings (without the '\\?\') to the A- and W-version and variants of this (including '\\?\'). 2) The handling of shares \\hostname\C$ is implemented, but no other shares are handled. And even in this case, only the host on which wine We need a more general way of handling UNC paths. We can't just have this single one (only local host and only C: drive) to satisfy the tests. This probably goes beyond GetLongPathName though. is executed is handled, no other hosts are handled. I have read that Windows 7 disables this share by default. So should wine be handling this particular URL, or should more general sharing be implemented? The test results on test.winehq.org tells us a different thing though. It looks like this is only the case for the Home versions of Windows. And (again) I think we need more general sharing to be implemented not just one case to have a test succeed. The patch is included as an attachment to this message. Kind regards Alexandre For what bug was this? -- Cheers, Paul. -- -- Alexandre Hardy http://www.ahardy.za.net
UNC Pathname handling
Hi,
I have written a patch to add basic UNC pathname support which tries
to handle UNC pathnames according to the MSDN spec.
The patch satisfies some of the UNC pathname tests for GetLongPathNameA,
but is actually intended to fix GetLongPathNameW.
I am not entirely satisfied with the patch, and would appreciate some
comments.
Some issues:
1) Paths prefixed by '\\?\' require GetLongPathName to handle
strings of length 32767. I don't like the fact that the patch creates two
such large strings on the local stack, should the memory be dynamically
allocated only when needed?
2) The handling of shares \\hostname\C$ is implemented, but no other
shares are handled. And even in this case, only the host on which wine
is executed is handled, no other hosts are handled. I have read that
Windows 7 disables this share by default. So should wine be handling this
particular URL, or should more general sharing be implemented?
The patch is included as an attachment to this message.
Kind regards
Alexandre
--
--
Alexandre Hardy
http://www.ahardy.za.net
From b013419f366c83248704f444cbbb6976df740fc9 Mon Sep 17 00:00:00 2001
From: Alexandre Hardy alexandre.ha...@gmail.com
Date: Fri, 11 Dec 2009 09:49:59 +0200
Subject: Add partial UNC pathname support
---
dlls/kernel32/path.c | 54 +--
dlls/kernel32/tests/path.c |4 ---
2 files changed, 51 insertions(+), 7 deletions(-)
diff --git a/dlls/kernel32/path.c b/dlls/kernel32/path.c
index e9463bb..54d9403 100644
--- a/dlls/kernel32/path.c
+++ b/dlls/kernel32/path.c
@@ -44,6 +44,7 @@
WINE_DEFAULT_DEBUG_CHANNEL(file);
#define MAX_PATHNAME_LEN1024
+#define MAX_LONGPATHNAME_LEN32767
/* check if a file name is for an executable file (.exe or .com) */
@@ -290,19 +291,29 @@ DWORD WINAPI GetFullPathNameA( LPCSTR name, DWORD len, LPSTR buffer,
*/
DWORD WINAPI GetLongPathNameW( LPCWSTR shortpath, LPWSTR longpath, DWORD longlen )
{
-WCHAR tmplongpath[MAX_PATHNAME_LEN];
+WCHAR tmplongpath[MAX_LONGPATHNAME_LEN];
+WCHAR sharename[MAX_LONGPATHNAME_LEN];
LPCWSTR p;
DWORD sp = 0, lp = 0;
DWORD tmplen;
+DWORD hostlen;
BOOLunixabsolute;
WIN32_FIND_DATAWwfd;
HANDLE goit;
+WCHAR cdollar[4] = { '\\', 'C', '$', 0 };
+WCHAR c_colon[3] = { 'C', ':', 0 };
+BOOLret;
if (!shortpath)
{
SetLastError(ERROR_INVALID_PARAMETER);
return 0;
}
+if (!longpath longlen)
+{
+SetLastError(ERROR_INVALID_PARAMETER);
+return 0;
+}
if (!shortpath[0])
{
SetLastError(ERROR_PATH_NOT_FOUND);
@@ -314,8 +325,45 @@ DWORD WINAPI GetLongPathNameW( LPCWSTR shortpath, LPWSTR longpath, DWORD longlen
if (shortpath[0] == '\\' shortpath[1] == '\\')
{
ERR(UNC pathname %s\n, debugstr_w(shortpath));
-lstrcpynW( longpath, shortpath, longlen );
-return strlenW(longpath);
+
+/* Handle extended length path */
+if (shortpath[2] == '?' shortpath[3] == '\\') {
+tmplen = GetLongPathNameW(shortpath + 4, tmplongpath, MAX_LONGPATHNAME_LEN);
+if (tmplen + 5 = longlen) {
+lstrcpynW(longpath, shortpath, 5);
+lstrcatW(longpath, tmplongpath);
+return tmplen + 4;
+} else
+return tmplen + 5;
+}
+
+/* Handle only our host name\C$ for network shares*/
+hostlen = MAX_COMPUTERNAME_LENGTH + 1;
+ret = GetComputerNameW(sharename, hostlen);
+if (ret) {
+lstrcatW(sharename, cdollar);
+if (strncmpW(sharename, shortpath + 2, hostlen + 3) == 0) {
+lstrcpyW(sharename, c_colon);
+lstrcatW(sharename, shortpath + 5 + hostlen);
+tmplen = GetLongPathNameW(sharename, tmplongpath, MAX_LONGPATHNAME_LEN);
+if (tmplen + hostlen + 4 = longlen) {
+lstrcpynW(longpath, shortpath, hostlen + 4);
+lstrcatW(longpath, tmplongpath);
+longpath[hostlen + 4] = '$';
+return tmplen + hostlen + 2;
+} else
+return tmplen + hostlen + 3;
+}
+}
+
+/* Can't handle shares at the moment, just copy the filename
+ * But only if there is enough space in the buffer */
+tmplen = strlenW(shortpath);
+if (longlen = tmplen + 1) {
+lstrcpynW( longpath, shortpath, longlen );
+return tmplen;
+}
+return tmplen + 1;
}
unixabsolute = (shortpath[0] == '/');
diff --git a/dlls/kernel32/tests/path.c b/dlls/kernel32/tests/path.c
index 104a48c..86207ce 100644
--- a/dlls/kernel32/tests/path.c
Re: UNC Pathname handling
Hi Paul, Stupid question: What do you mean by bottom post? I have added wine-devel as a CC to these messages, is that sufficient? According to my log it seems to be a GetLongPathNameW. GetLongPathNameA does not exhibit the same problems as GetLongPathNameW. So GetLongPathNameA(path, NULL, 0) succeeds, while GetLongPathNameW(path, NULL, 0) segfaults. This is because GetLongPathNameA provides its own not NULL buffer to GetLongPathNameW. It also seems to me that only GetLongPathNameW is required to handle UNC pathnames that begin with '\\?\' (at least, that is how I understand the MSDN). Kind regards Alexandre On Fri, Dec 11, 2009 at 10:56 AM, Paul Vriens paul.vriens.w...@gmail.com wrote: Hi Alexandre, On 12/11/2009 09:49 AM, Alexandre Hardy wrote: Hi Paul, I guess it could fall under bug #19807. I was actually testing it with Nokia Ovi Installer. (Please bottom post on wine-devel). So to fix 19807 you need to handle the '\\?\' cases only so it seems? Remember that GetLongPathNameA is forward to GetLongPathNameW and from the bug report one can't see which one is actually called. So you need a log file with either a +file trace or change the TRACE() in GetLongPathNameA to a FIXME(). -- Cheers, Paul. -- -- Alexandre Hardy http://www.ahardy.za.net
Re: UNC Pathname handling
Hi Paul,
On Fri, Dec 11, 2009 at 11:09 AM, Paul Vriens
paul.vriens.w...@gmail.com wrote:
Well, the tests show that the A-version also handles this case.
Okay, no problem there, but since the edge cases for GetLongPathNameW
are not tested by GetLongPathNameA, how about adding a few of
these tests?
A proposed patch with such tests is attached.
Thanks for the friendly advice!
Kinf regards
Alexandre
--
--
Alexandre Hardy
http://www.ahardy.za.net
From 742e937bf945d7769b99782e21e1b5e4f567b6d0 Mon Sep 17 00:00:00 2001
From: Alexandre Hardy alexandre.ha...@gmail.com
Date: Fri, 11 Dec 2009 11:50:18 +0200
Subject: Some UNC GetLongPathNameW tests
---
dlls/kernel32/tests/path.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/dlls/kernel32/tests/path.c b/dlls/kernel32/tests/path.c
index 104a48c..20b13c5 100644
--- a/dlls/kernel32/tests/path.c
+++ b/dlls/kernel32/tests/path.c
@@ -1067,6 +1067,12 @@ static void test_GetLongPathNameW(void)
{
DWORD length;
WCHAR empty[MAX_PATH];
+WCHAR tempfile[MAX_PATH];
+WCHAR longpath[MAX_PATH];
+WCHAR shortpath[MAX_PATH];
+WCHAR longfilename[] = {'l', 'o', 'n', 'g', 'f', 'i', 'l', 'e', 'n', 'a', 'm', 'e', '.', 'l', 'o', 'n', 'g', 'e', 'x', 't', 0};
+WCHAR uncprefix[] = {'\\', '\\' , '?', '\\', 0};
+HANDLE file;
/* Not present in all windows versions */
if(pGetLongPathNameW)
@@ -1086,6 +1092,29 @@ static void test_GetLongPathNameW(void)
length = pGetLongPathNameW(empty,NULL,0);
ok(0==length,GetLongPathNameW returned %d but expected 0\n,length);
ok(GetLastError()==ERROR_PATH_NOT_FOUND,GetLastError returned %d but expected ERROR_PATH_NOT_FOUND\n,GetLastError());
+
+GetTempPathW(MAX_PATH, tempfile);
+lstrcatW(tempfile, longfilename);
+
+file = CreateFileW(tempfile, GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
+CloseHandle(file);
+
+memset(longpath, 0, MAX_PATH * sizeof(WCHAR));
+lstrcpyW(longpath, uncprefix);
+lstrcatW(longpath, tempfile);
+length = pGetLongPathNameW(longpath,NULL,0);
+todo_wine
+ok(lstrlenW(longpath) + 1==length,GetLongPathNameW returned %d but expected 0\n,length);
+
+memset(shortpath, 0, MAX_PATH * sizeof(WCHAR));
+memset(longpath, 0, MAX_PATH * sizeof(WCHAR));
+lstrcpyW(shortpath, uncprefix);
+GetShortPathNameW(shortpath + 4, tempfile, MAX_PATH - 4);
+length = pGetLongPathNameW(shortpath,NULL,0);
+todo_wine
+ok(lstrlenW(longpath) + 5==length,GetLongPathNameW returned %d but expected 0\n,length);
+
+DeleteFileW(tempfile);
}
}
--
1.6.2.1
Re: UNC Pathname handling
On 12/11/2009 10:57 AM, Alexandre Hardy wrote:
@@ -1067,6 +1067,12 @@ static void test_GetLongPathNameW(void)
{
DWORD length;
WCHAR empty[MAX_PATH];
+WCHAR tempfile[MAX_PATH];
+WCHAR longpath[MAX_PATH];
+WCHAR shortpath[MAX_PATH];
+WCHAR longfilename[] = {'l', 'o', 'n', 'g', 'f', 'i', 'l', 'e', 'n', 'a',
'm', 'e', '.', 'l', 'o', 'n', 'g', 'e', 'x', 't', 0};
+WCHAR uncprefix[] = {'\\', '\\' , '?', '\\', 0};
+HANDLE file;
/* Not present in all windows versions */
if(pGetLongPathNameW)
@@ -1086,6 +1092,29 @@ static void test_GetLongPathNameW(void)
length = pGetLongPathNameW(empty,NULL,0);
ok(0==length,GetLongPathNameW returned %d but expected 0\n,length);
ok(GetLastError()==ERROR_PATH_NOT_FOUND,GetLastError returned %d but expected
ERROR_PATH_NOT_FOUND\n,GetLastError());
+
+GetTempPathW(MAX_PATH, tempfile);
+lstrcatW(tempfile, longfilename);
+
+file = CreateFileW(tempfile, GENERIC_READ|GENERIC_WRITE, 0, NULL,
CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
+CloseHandle(file);
+
+memset(longpath, 0, MAX_PATH * sizeof(WCHAR));
Don't think this memset makes sense as you do lstrcpyW after that (and
yes it does not make sense in the A-test I did either ;) ).
+lstrcpyW(longpath, uncprefix);
+lstrcatW(longpath, tempfile);
+length = pGetLongPathNameW(longpath,NULL,0);
+todo_wine
+ok(lstrlenW(longpath) + 1==length,GetLongPathNameW returned %d but expected
0\n,length);
You're saying that length should be 0 but the test tests something else.
+
+memset(shortpath, 0, MAX_PATH * sizeof(WCHAR));
+memset(longpath, 0, MAX_PATH * sizeof(WCHAR));
You're setting longpath but it's not used anymore after that.
+lstrcpyW(shortpath, uncprefix);
+GetShortPathNameW(shortpath + 4, tempfile, MAX_PATH - 4);
+length = pGetLongPathNameW(shortpath,NULL,0);
This doesn't make sense to me. You are fill tempfile but not using it
afterwards and then you call pGetLongPathNameW with NULL?
+todo_wine
+ok(lstrlenW(longpath) + 5==length,GetLongPathNameW returned %d but expected
0\n,length);
+
+DeleteFileW(tempfile);
}
}
These are added tests but Wine crashes right now with these?
--
Cheers,
Paul.
Re: WineD3D: Frontbuffers are always onscreen
2009/12/11 Stefan Dösinger stefandoesin...@gmx.at: - Setting render_offscreen is really the responsibility of the context_create() call, similar to create_primary_opengl_context(). context_create() doesn't take a swapchain as parameter, only a window. This is correct, because GL contexts are linked to the drawable, not the swapchain. Thus context_create doesn't have the needed information to set the offscreen flag. (I could just pass in a TRUE or FALSE parameter, but there's something else) It has a target parameter that can be either an onscreen or offscreen surface. This parameter is also used to set the initial current_rt field. similar to create_primary_opengl_context() was perhaps badly worded, what I meant is that context_create() should be setting render_offscreen, not its callers. As a sidenode, maybe create_primary_opengl_context is named badly. It's not part of the context management, its a device helper function that happens to use the context management to set up a GL context, among other things. Maybe device_restart_opengl or something similar is better. Yeah. - The line is actually wrong, the relevant context has been setup to render to the front buffer, so render_offscreen should always be FALSE, even if there is a back buffer. Well, this code is in the backbuffer path. Render_offscreen is false if we don't set it due to the alloc HEAP_ZERO_MEMORY. The point of the line is to set it to true if we render to an FBO. We never set a swapchain to render to the front buffer at creation time if there is a back buffer. context_create(device, (IWineD3DSurfaceImpl *)swapchain-frontBuffer, window, FALSE /* pbuffer */, present_parameters); The draw buffer handling in swapchain_init() is also broken in the sense that it always sets GL_BACK if there's a back buffer, regardless of what the context thinks it should be, but that's a separate issue, I'm working on some patches to fix draw buffer handling in the general case.
Re: [3/3] winex11.drv: Use the old method to delete the desktop window.
Vincent Povirk vinc...@codeweavers.com writes:
@@ -516,6 +516,14 @@ static void handle_wm_protocols( HWND hwnd,
XClientMessageEvent *event )
HMENU hSysMenu;
POINT pt;
+if (hwnd == GetDesktopWindow())
+{
+/* The desktop window does not have a close button that we
can
+ * pretend to click. Therefore, we simply send it a close
command. */
+PostMessageW( hwnd, WM_X11DRV_DELETE_WINDOW, 0, 0 );
+return;
+}
You could just as well send the WM_SYSCOMMAND directly.
--
Alexandre Julliard
julli...@winehq.org
Re: UNC Pathname handling
A proposed patch with such tests is attached. There is a bug, the call to GetShortPathName should be GetShortPathNameW(tempfile, shortpath + 4, MAX_PATH - 4); Kind regards Alexandre
Re: UNC Pathname handling
Hi Paul, Don't think this memset makes sense as you do lstrcpyW after that (and yes it does not make sense in the A-test I did either ;) ). Okay, that can be removed... You're saying that length should be 0 but the test tests something else. WIll correct that (copy and paste - I was in too much of a hurry) + + memset(shortpath, 0, MAX_PATH * sizeof(WCHAR)); + memset(longpath, 0, MAX_PATH * sizeof(WCHAR)); I should remove that as well :) You're setting longpath but it's not used anymore after that. + lstrcpyW(shortpath, uncprefix); + GetShortPathNameW(shortpath + 4, tempfile, MAX_PATH - 4); + length = pGetLongPathNameW(shortpath,NULL,0); This doesn't make sense to me. You are fill tempfile but not using it afterwards and then you call pGetLongPathNameW with NULL? Yes, sorry, that should be GetShortPathNameW(tempfile, shortpath + 4, MAX_PATH - 4); These are added tests but Wine crashes right now with these? Yes, wine crashes right now with these. Kind regards Alexandre -- -- Alexandre Hardy http://www.ahardy.za.net
Re: WineD3D: Frontbuffers are always onscreen
Am 11.12.2009 um 11:33 schrieb Henri Verbeet: context_create(device, (IWineD3DSurfaceImpl *)swapchain-frontBuffer, window, FALSE /* pbuffer */, present_parameters); What is missing is access to the swapchain-render_to_fbo setting. context_create could use the same logic as the swapchain_create code(look at window and backbuffer size etc). However, I prefer not to initialize render_offscreen during context creation, and instead keep context-current_rt set to NULL until the context is actually used the first time. This way context-render_offscreen will be set the first time the context is used. The swapchain is fully initialized at this point, and we don't run into the same problem the next time we add a field similar to render_offscreen to the context.
Re: UNC Pathname handling
On 12/11/2009 02:00 PM, Alexandre Hardy wrote:
DWORD WINAPI GetLongPathNameW( LPCWSTR shortpath, LPWSTR longpath, DWORD
longlen )
{
-WCHAR tmplongpath[MAX_PATHNAME_LEN];
+LPWSTR tmplongpath;
LPCWSTR p;
DWORD sp = 0, lp = 0;
DWORD tmplen;
@@ -309,13 +310,44 @@ DWORD WINAPI GetLongPathNameW( LPCWSTR shortpath, LPWSTR
longpath, DWORD longlen
return 0;
}
+if (!(tmplongpath = (WCHAR *)HeapAlloc( GetProcessHeap(), 0,
MAX_LONGPATHNAME_LEN * sizeof(WCHAR) ))) {
+SetLastError( ERROR_OUTOFMEMORY );
+return 0;
+}
+
This is not really dynamic, is it? You are still allocating that same
amount. Now, I'm not sure how to fix this as you need some way of
calculating the needed length in any case. Is that cast necessary btw?
Now as I understand the function it can only be a maximum of 32767 when
you use '\\?\', right? If so then this allocation should only be needed
in the '\\?\' case. This however is something you have to add tests for
as well. So create a path MAX_PATH (if that's possible as I guess the
path/file has to exist as well) and see what is returned on Windows.
As you are now covering the '\\?\' case the ERR should go down as well
and should maybe be a FIXME now?
--
Cheers,
Paul.
Re: UNC Pathname handling
Hi Paul,
Thanks for the help with the tests. Here is a new set of tests.
I'll send the patch that makes these tests succeed
shortly. I would appreciate it if you could have a look at it.
Kind regards
Alexandre
On Fri, Dec 11, 2009 at 12:25 PM, Alexandre Hardy
alexandre.ha...@gmail.com wrote:
Hi Paul,
Don't think this memset makes sense as you do lstrcpyW after that (and yes
it does not make sense in the A-test I did either ;) ).
Okay, that can be removed...
You're saying that length should be 0 but the test tests something else.
WIll correct that (copy and paste - I was in too much of a hurry)
+
+ memset(shortpath, 0, MAX_PATH * sizeof(WCHAR));
+ memset(longpath, 0, MAX_PATH * sizeof(WCHAR));
I should remove that as well :)
You're setting longpath but it's not used anymore after that.
+ lstrcpyW(shortpath, uncprefix);
+ GetShortPathNameW(shortpath + 4, tempfile, MAX_PATH - 4);
+ length = pGetLongPathNameW(shortpath,NULL,0);
This doesn't make sense to me. You are fill tempfile but not using it
afterwards and then you call pGetLongPathNameW with NULL?
Yes, sorry, that should be
GetShortPathNameW(tempfile, shortpath + 4, MAX_PATH - 4);
These are added tests but Wine crashes right now with these?
Yes, wine crashes right now with these.
Kind regards
Alexandre
--
--
Alexandre Hardy
http://www.ahardy.za.net
--
--
Alexandre Hardy
http://www.ahardy.za.net
From 05e69ddb946cc0de5c71157ea83bcd24f013bbe1 Mon Sep 17 00:00:00 2001
From: Alexandre Hardy alexandre.ha...@gmail.com
Date: Fri, 11 Dec 2009 13:21:36 +0200
Subject: Some UNC GetLongPathNameW tests
---
dlls/kernel32/tests/path.c | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/dlls/kernel32/tests/path.c b/dlls/kernel32/tests/path.c
index 104a48c..c7e3dc7 100644
--- a/dlls/kernel32/tests/path.c
+++ b/dlls/kernel32/tests/path.c
@@ -1067,6 +1067,13 @@ static void test_GetLongPathNameW(void)
{
DWORD length;
WCHAR empty[MAX_PATH];
+WCHAR tempfile[MAX_PATH];
+WCHAR longpath[MAX_PATH];
+WCHAR shortpath[MAX_PATH];
+WCHAR temppath[MAX_PATH];
+WCHAR longfilename[] = {'l', 'o', 'n', 'g', 'f', 'i', 'l', 'e', 'n', 'a', 'm', 'e', '.', 'l', 'o', 'n', 'g', 'e', 'x', 't', 0};
+WCHAR uncprefix[] = {'\\', '\\' , '?', '\\', 0};
+HANDLE file;
/* Not present in all windows versions */
if(pGetLongPathNameW)
@@ -1086,6 +1093,30 @@ static void test_GetLongPathNameW(void)
length = pGetLongPathNameW(empty,NULL,0);
ok(0==length,GetLongPathNameW returned %d but expected 0\n,length);
ok(GetLastError()==ERROR_PATH_NOT_FOUND,GetLastError returned %d but expected ERROR_PATH_NOT_FOUND\n,GetLastError());
+
+GetTempPathW(MAX_PATH, tempfile);
+lstrcatW(tempfile, longfilename);
+
+file = CreateFileW(tempfile, GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
+CloseHandle(file);
+
+lstrcpyW(longpath, uncprefix);
+lstrcatW(longpath, tempfile);
+length = pGetLongPathNameW(longpath,NULL,0);
+todo_wine
+ok(lstrlenW(longpath) + 1==length,GetLongPathNameW returned %d but expected %d\n,length, lstrlenW(longpath) + 1);
+
+lstrcpyW(shortpath, uncprefix);
+GetShortPathNameW(tempfile, shortpath + 4, MAX_PATH - 4);
+length = pGetLongPathNameW(shortpath,NULL,0);
+todo_wine
+ok(lstrlenW(longpath) + 1==length,GetLongPathNameW returned %d but expected %d\n,length, lstrlenW(longpath) + 1);
+
+todo_wine
+length = pGetLongPathNameW(shortpath,temppath,MAX_PATH);
+ok(lstrlenW(longpath)==length,GetLongPathNameW returned %d but expected %d\n,length, lstrlenW(longpath));
+
+DeleteFileW(tempfile);
}
}
--
1.6.2.1
Re: UNC Pathname handling
Hi Paul,
Here is the patch for GetLongPathNameW. Would you mind
looking at it to see if it makes sense?
(Forgot to bottom post in the last message :-( )
Kind regards
Alexandre
--
--
Alexandre Hardy
http://www.ahardy.za.net
From 99b08d8497491d52935335e8dd6f9173f68fbab8 Mon Sep 17 00:00:00 2001
From: Alexandre Hardy alexandre.ha...@gmail.com
Date: Fri, 11 Dec 2009 14:53:35 +0200
Subject: Handle non share UNC pathnames
---
dlls/kernel32/path.c | 40 +---
dlls/kernel32/tests/path.c |3 ---
2 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/dlls/kernel32/path.c b/dlls/kernel32/path.c
index e9463bb..168946a 100644
--- a/dlls/kernel32/path.c
+++ b/dlls/kernel32/path.c
@@ -44,6 +44,7 @@
WINE_DEFAULT_DEBUG_CHANNEL(file);
#define MAX_PATHNAME_LEN1024
+#define MAX_LONGPATHNAME_LEN32767
/* check if a file name is for an executable file (.exe or .com) */
@@ -290,7 +291,7 @@ DWORD WINAPI GetFullPathNameA( LPCSTR name, DWORD len, LPSTR buffer,
*/
DWORD WINAPI GetLongPathNameW( LPCWSTR shortpath, LPWSTR longpath, DWORD longlen )
{
-WCHAR tmplongpath[MAX_PATHNAME_LEN];
+LPWSTR tmplongpath;
LPCWSTR p;
DWORD sp = 0, lp = 0;
DWORD tmplen;
@@ -309,13 +310,44 @@ DWORD WINAPI GetLongPathNameW( LPCWSTR shortpath, LPWSTR longpath, DWORD longlen
return 0;
}
+if (!(tmplongpath = (WCHAR *)HeapAlloc( GetProcessHeap(), 0, MAX_LONGPATHNAME_LEN * sizeof(WCHAR) ))) {
+SetLastError( ERROR_OUTOFMEMORY );
+return 0;
+}
+
TRACE(%s,%p,%d\n, debugstr_w(shortpath), longpath, longlen);
if (shortpath[0] == '\\' shortpath[1] == '\\')
{
ERR(UNC pathname %s\n, debugstr_w(shortpath));
-lstrcpynW( longpath, shortpath, longlen );
-return strlenW(longpath);
+
+/* Handle extended length path */
+if (shortpath[2] == '?' shortpath[3] == '\\') {
+tmplen = GetLongPathNameW(shortpath + 4, tmplongpath, MAX_LONGPATHNAME_LEN);
+if (tmplen == 0) {
+HeapFree( GetProcessHeap(), 0, tmplongpath );
+return 0;
+}
+if (tmplen + 5 = longlen) {
+lstrcpynW(longpath, shortpath, 5);
+lstrcatW(longpath, tmplongpath);
+HeapFree( GetProcessHeap(), 0, tmplongpath );
+return tmplen + 4;
+} else
+HeapFree( GetProcessHeap(), 0, tmplongpath );
+return tmplen + 5;
+}
+
+HeapFree( GetProcessHeap(), 0, tmplongpath );
+
+/* Can't handle shares at the moment, just copy the filename
+ * But only if there is enough space in the buffer */
+tmplen = strlenW(shortpath);
+if (longlen = tmplen + 1) {
+lstrcpynW( longpath, shortpath, longlen );
+return tmplen;
+}
+return tmplen + 1;
}
unixabsolute = (shortpath[0] == '/');
@@ -358,6 +390,7 @@ DWORD WINAPI GetLongPathNameW( LPCWSTR shortpath, LPWSTR longpath, DWORD longlen
{
TRACE(not found %s!\n, debugstr_w(tmplongpath));
SetLastError ( ERROR_FILE_NOT_FOUND );
+HeapFree( GetProcessHeap(), 0, tmplongpath );
return 0;
}
FindClose(goit);
@@ -379,6 +412,7 @@ DWORD WINAPI GetLongPathNameW( LPCWSTR shortpath, LPWSTR longpath, DWORD longlen
tmplen--; /* length without 0 */
}
+HeapFree( GetProcessHeap(), 0, tmplongpath );
return tmplen;
}
diff --git a/dlls/kernel32/tests/path.c b/dlls/kernel32/tests/path.c
index c7e3dc7..c3b216d 100644
--- a/dlls/kernel32/tests/path.c
+++ b/dlls/kernel32/tests/path.c
@@ -1103,16 +1103,13 @@ static void test_GetLongPathNameW(void)
lstrcpyW(longpath, uncprefix);
lstrcatW(longpath, tempfile);
length = pGetLongPathNameW(longpath,NULL,0);
-todo_wine
ok(lstrlenW(longpath) + 1==length,GetLongPathNameW returned %d but expected %d\n,length, lstrlenW(longpath) + 1);
lstrcpyW(shortpath, uncprefix);
GetShortPathNameW(tempfile, shortpath + 4, MAX_PATH - 4);
length = pGetLongPathNameW(shortpath,NULL,0);
-todo_wine
ok(lstrlenW(longpath) + 1==length,GetLongPathNameW returned %d but expected %d\n,length, lstrlenW(longpath) + 1);
-todo_wine
length = pGetLongPathNameW(shortpath,temppath,MAX_PATH);
ok(lstrlenW(longpath)==length,GetLongPathNameW returned %d but expected %d\n,length, lstrlenW(longpath));
--
1.6.2.1
Re: UNC Pathname handling
On 12/11/2009 01:58 PM, Alexandre Hardy wrote: + +GetTempPathW(MAX_PATH, tempfile); +lstrcatW(tempfile, longfilename); + +file = CreateFileW(tempfile, GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); +CloseHandle(file); + +lstrcpyW(longpath, uncprefix); +lstrcatW(longpath, tempfile); +length = pGetLongPathNameW(longpath,NULL,0); +todo_wine +ok(lstrlenW(longpath) + 1==length,GetLongPathNameW returned %d but expected %d\n,length, lstrlenW(longpath) + 1); How can you be sure about longpath being actually a long path? Maybe should do a proper call to pGetLongPathNameW just to be sure you're starting point is correct. I say this as on my W2K3 box I get: tempfile : (C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\longfilename.longext) And that results in: path.c:1109: Test failed: GetLongPathNameW returned 85 but expected 60 path.c:1115: Test failed: GetLongPathNameW returned 85 but expected 60 (linenumbers don't match because I add some trace()'s) + +lstrcpyW(shortpath, uncprefix); +GetShortPathNameW(tempfile, shortpath + 4, MAX_PATH - 4); +length = pGetLongPathNameW(shortpath,NULL,0); +todo_wine +ok(lstrlenW(longpath) + 1==length,GetLongPathNameW returned %d but expected %d\n,length, lstrlenW(longpath) + 1); + +todo_wine +length = pGetLongPathNameW(shortpath,temppath,MAX_PATH); +ok(lstrlenW(longpath)==length,GetLongPathNameW returned %d but expected %d\n,length, lstrlenW(longpath)); If longpath is indeed a long path you could compare it with temppath? + +DeleteFileW(tempfile); -- Cheers, Paul.
Re: UNC Pathname handling
On 12/11/2009 02:40 PM, Alexandre Hardy wrote: Now as I understand the function it can only be a maximum of 32767 when you use '\\?\', right? If so then this allocation should only be needed in the '\\?\' case. This however is something you have to add tests for as well. So create a path MAX_PATH (if that's possible as I guess the path/file has to exist as well) and see what is returned on Windows. Actually, I'm not certain that the maximum is not always 32767 WCHARS. The MSDN states that GetLongPathNameA is limited to MAX_PATH characters, and that you should use \\?\ to increase the limit to 32767 characters. I'm not entirely sure what GetLongPathNameW has as a limit. So that's why we need the tests ;) -- Cheers, Paul.
Re: WineD3D: Frontbuffers are always onscreen
2009/12/11 Stefan Dösinger stefandoesin...@gmx.at: Am 11.12.2009 um 11:33 schrieb Henri Verbeet: context_create(device, (IWineD3DSurfaceImpl *)swapchain-frontBuffer, window, FALSE /* pbuffer */, present_parameters); What is missing is access to the swapchain-render_to_fbo setting. context_create could use the same logic as the swapchain_create code(look at window and backbuffer size etc). It's really not that hard, you just call surface_is_offscreen() on the target. Arguably swapchain_init() shouldn't be screwing around with context creation in the first place, but that's really a separate issue, unless you're volunteering to clean that up first.
Re: WineD3D: Frontbuffers are always onscreen
Am 11.12.2009 um 15:47 schrieb Henri Verbeet: It's really not that hard, you just call surface_is_offscreen() on the target. Arguably swapchain_init() shouldn't be screwing around with context creation in the first place, but that's really a separate issue, unless you're volunteering to clean that up first. By the time we create the context the swapchain and surfaces aren't fully constructed. However, we luckily call SetContainer on the initial surface before we call create_context, so it should work for now. (Incidentally, we create the context with the front buffer as target, so context_acquire with the back buffer as target should set context-render_offscreen correctly anyway. For some reason though it doesn't (Or did not, when I wrote the render-to-fbo code. Or maybe that was after a Reset() call)
Valgrind errors: 893 leaks, 105 conditional depends on uninit, 63 invalid read, 12 invalid write, ...
Here's a more detailed breakdown of the current valgrind warnings when running the wine test suite as of yesterday, with the ntdll/heap warnings suppressed (as they will be from now on): 1 --25396-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting 1 vex x86-IR: unhandled instruction bytes: 0xFB 0xC3 0x0 0x0 2 Source and destination overlap 3 Use of uninitialised value of size 4 4 Invalid read of size 1 4 Invalid write of size 4 4 Unhandled exception: illegal instruction 5 Unhandled exception: page fault on write 7 Unhandled exception: page fault on read 7 Invalid free() / delete / delete[] 8 Invalid write of size 1 14 Syscall param writev(vector[...]) points to uninitialised byte(s) 19 Invalid read of size 4 40 Invalid read of size 2 105 Conditional jump or move depends on uninitialised value(s) 893 X bytes are definitely lost I think *all* the remaining invalid write errors are bogus, either they're in GetDIBits, in a video driver, or in the stack backtracing code. All of the remaining invalid free errors are in the oleaut32 vartype test: Invalid free() / delete / delete[] at notify_free (heap.c:255) by RtlFreeHeap (heap.c:1748) by SysFreeString (oleaut.c:194) by test_VarBstrFromDate (vartype.c:4910) by func_vartype (vartype.c:6276) by run_test (test.h:535) by main (test.h:585) Address 0x7f0a1560 is not stack'd, malloc'd or (recently) free'd for which I've filed http://bugs.winehq.org/show_bug.cgi?id=20992
Re: WineD3D: Frontbuffers are always onscreen
2009/12/11 Stefan Dösinger stefandoesin...@gmx.at: Am 11.12.2009 um 15:47 schrieb Henri Verbeet: It's really not that hard, you just call surface_is_offscreen() on the target. Arguably swapchain_init() shouldn't be screwing around with context creation in the first place, but that's really a separate issue, unless you're volunteering to clean that up first. By the time we create the context the swapchain and surfaces aren't fully constructed. However, we luckily call SetContainer on the initial surface before we call create_context, so it should work for now. That's a big part of the reason why swapchain_init() shouldn't do context creation. Doesn't change the fact that it's the responsibility of context_create() to properly initialize the context's fields.
Re: [3/3] winex11.drv: Use the old method to delete the desktop window.
On Fri, Dec 11, 2009 at 4:55 AM, Alexandre Julliard julli...@winehq.org wrote:
Vincent Povirk vinc...@codeweavers.com writes:
@@ -516,6 +516,14 @@ static void handle_wm_protocols( HWND hwnd,
XClientMessageEvent *event )
HMENU hSysMenu;
POINT pt;
+ if (hwnd == GetDesktopWindow())
+ {
+ /* The desktop window does not have a close button that we
can
+ * pretend to click. Therefore, we simply send it a close
command. */
+ PostMessageW( hwnd, WM_X11DRV_DELETE_WINDOW, 0, 0 );
+ return;
+ }
You could just as well send the WM_SYSCOMMAND directly.
Out of curiosity, when was WM_X11DRV_DELETE_WINDOW needed, and why
isn't it needed here?
--
Vincent Povirk
Re: [3/3] winex11.drv: Use the old method to delete the desktop window.
Vincent Povirk madewokherd+8...@gmail.com writes:
On Fri, Dec 11, 2009 at 4:55 AM, Alexandre Julliard julli...@winehq.org
wrote:
Vincent Povirk vinc...@codeweavers.com writes:
@@ -516,6 +516,14 @@ static void handle_wm_protocols( HWND hwnd,
XClientMessageEvent *event )
HMENU hSysMenu;
POINT pt;
+ if (hwnd == GetDesktopWindow())
+ {
+ /* The desktop window does not have a close button that we
can
+ * pretend to click. Therefore, we simply send it a close
command. */
+ PostMessageW( hwnd, WM_X11DRV_DELETE_WINDOW, 0, 0 );
+ return;
+ }
You could just as well send the WM_SYSCOMMAND directly.
Out of curiosity, when was WM_X11DRV_DELETE_WINDOW needed, and why
isn't it needed here?
It was needed because some apps didn't expect to receive a sent
WM_SYSCOMMAND at that point. The desktop doesn't care.
--
Alexandre Julliard
julli...@winehq.org
Sound concerns
Hi all, I believe most oconcerns about OpenAL have been addressed. One of the open questions was whether midi and wave would be synced. And I think the most likely answer is that they aren't, even on windows. On windows winmm midi drivers use winmm timeGetTime or QueryPerformanceCounter for DirectMusic. Sample accurate wave is used to sync with midi, by using exclusive mode or the asio model. If there are any other open concerns, apart from packaging, let me know, since I really want to get dsound openal merged. :) If there are still concerns that are open I would like to know, especially if they affect wasapi which is defined in include/audioclient.idl and audiopolicy.idl Cheers, Maarten.
Re: meaning of Hardware field in bugzilla?
On Thu, Jan 15, 2009 at 5:37 PM, Scott Ritchie sc...@open-vote.org wrote: Austin English wrote: On Tue, Jan 13, 2009 at 1:12 PM, Juan Lang juan.l...@gmail.com wrote: Does mac mean powerpc mac only? I rather thought it meant apple macintosh, regardless of cpu. I ask because Austin has just gone through and changed lots of mac bugs to pc even though the bugs were on Intel macs, which just seems wrong. I agree with you, this change seems suspect. Austin, are you trying to distinguish PPC bugs from x86 ones with this, or what? --Juan I've seen the same change made a few times in the past (I'd have to search for it). Looking at other bugzilla's, Mozilla puts Intel Mac bugs under PC...after all, since they've moved to x86, for all intents and purposes, Intel Macs are PC's (especially if running Linux rather than OS X). Those running OS X still can be identified as such by the OS field. Yes, my goal was to separate x86/ppc bugs. Then we should change the tab to read ppc rather than mac. I know this is an old thread, but I'd like to (finally) make some progress on this... I'd really like to see the Macintosh verb removed/renamed, since an Intel Mac is really just a PC. The OS field tells us it's a Mac, and, for example, a Linux OS on an Intel Mac is no different (to Wine) than a regular x86/x86_64 PC running Linux. Dan and I discussed it, and figured renaming the hardware to reflect the architecture would be more descriptive: Macintosh - ppc32 PC - x86 PC-x86-64 - x86-64 sun - sparc How does that sound? -- -Austin
Re: Sound concerns
Am 11.12.2009 um 19:07 schrieb Maarten Lankhorst: Hi all, I believe most oconcerns about OpenAL have been addressed. One of the open questions was whether midi and wave would be synced. And I think the most likely answer is that they aren't, even on windows. On windows winmm midi drivers use winmm timeGetTime or QueryPerformanceCounter for DirectMusic. Sample accurate wave is used to sync with midi, by using exclusive mode or the asio model. Sounds ok. If there are any other open concerns, apart from packaging, let me know, since I really want to get dsound openal merged. :) If there are still concerns that are open I would like to know, especially if they affect wasapi which is defined in include/audioclient.idl and audiopolicy.idl Well, there are still the two (comparably minor) issues like 1) OpenAL's future, since the development is fragmented and little is going on. That said, there probably isn't much going on in the sound world(or its rather going backwards, see dsound3d), so its probably OK that there isn't much development 2) How maintaining separate winmm drivers for midi and using openal for wasapi and dsound is any better than using separate wasapi drivers that do midi+wave. Since you're writing the code, if you're not concerned about (2) it's probably not an issue. Concerning (1) if I were writing this stuff I'd probably hedge my bets and avoid making openal an integral part of our sound design(like dsound via openal does). But again, you're writing the code, so you are the boss. And as far as I understand it using openal for dsound is one of your main goals and not an unintended side effect.
Re: meaning of Hardware field in bugzilla?
Austin English wrote: Dan and I discussed it, and figured renaming the hardware to reflect the architecture would be more descriptive: Macintosh - ppc32 PC - x86 PC-x86-64 - x86-64 sun - sparc How does that sound? +1 here. Sounds like a solid idea. ~Nate Gallaher
Re: Sound concerns
If there are any other open concerns, apart from packaging, let me know, since I really want to get dsound openal merged. :) If there are still concerns that are open I would like to know, especially if they affect wasapi which is defined in include/audioclient.idl and audiopolicy.idl One of the things which worries me and which you also mentioned on irc is whether openal is the right library to implement wasapi. You mentioned that some tasks require a 'server' (for the session guid stuff). Further there are other features like per stream volume which sound servers support but openal doesn't support this (it would the task of a real sound server). I have the feeling that 'classic' sound libraries (openal, alsa, oss, ..) are not the right approach for implementing a 'sound server'. In my opinion they should be implemented on top of CoreAudio/PulseAudio/.. Roderick
Building and packaging Wine Gecko
Hi all! I see that Wine has recently started to always request installation of Gecko, and that it is recommended to use a distribution provided package. We do not yet provide a wine-gecko package in Mandriva, but we'd like to. According to our policy (and the policy of e.g. Debian, Fedora) everything in our main repositories has to be compiled by us without external binaries compiled by a third party. I noticed there are build instructions here: http://wiki.winehq.org/BuildingWineGecko However, the instructions on that page ask for copying binaries directly provided in wine-mozilla tarball, and for modifying mingw32 headers. These actions are rather unacceptable for us (I guess the latter one is workaroundable, though). I saw that http://wiki.winehq.org/Gecko says Gentoo and openSUSE package Gecko properly. I looked at the Gentoo package [1] and saw that they simply download the prebuilt cab, which we can't do. I took a look in openSUSE src.rpm [2], but found no references to Gecko, and I didn't see any separate wine-gecko src.rpm there. I did found wine-gecko OpenSUSE binary packages in Wine's SourceForge page, but no source packages or information on how it was built. Is it really not possible to build Wine Gecko from the source code, on command line, on Linux? Or is it just that nobody has written any instructions on how to do that? [1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emulation/wine/wine-1.1.34.ebuild?view=markup [2] http://download.opensuse.org/factory/repo/src-oss/suse/src/wine-1.1.28-3.4.src.rpm -- Anssi Hannula Mandriva packager
Re: Building and packaging Wine Gecko
On Fri, Dec 11, 2009 at 10:11:59PM +0200, Anssi Hannula wrote: Hi all! I see that Wine has recently started to always request installation of Gecko, and that it is recommended to use a distribution provided package. We do not yet provide a wine-gecko package in Mandriva, but we'd like to. According to our policy (and the policy of e.g. Debian, Fedora) everything in our main repositories has to be compiled by us without external binaries compiled by a third party. I noticed there are build instructions here: http://wiki.winehq.org/BuildingWineGecko However, the instructions on that page ask for copying binaries directly provided in wine-mozilla tarball, and for modifying mingw32 headers. These actions are rather unacceptable for us (I guess the latter one is workaroundable, though). I saw that http://wiki.winehq.org/Gecko says Gentoo and openSUSE package Gecko properly. I looked at the Gentoo package [1] and saw that they simply download the prebuilt cab, which we can't do. I took a look in openSUSE src.rpm [2], but found no references to Gecko, and I didn't see any separate wine-gecko src.rpm there. I did found wine-gecko OpenSUSE binary packages in Wine's SourceForge page, but no source packages or information on how it was built. Is it really not possible to build Wine Gecko from the source code, on command line, on Linux? Or is it just that nobody has written any instructions on how to do that? For openSUSE it is currently only in the openSUSE buildservice. For acceptance into the openSUSE distribution itself, it either needs to be: - fully buildable from source (difficult) - less strict licensed than (L)GPL. As it is Mozilla stuff which seems dual or triple licensed, what is the actual license(s) of the wine-gecko build? Ciao, Marcus
Re: Sound concerns
Hi Roderick, Roderick Colenbrander schreef: If there are any other open concerns, apart from packaging, let me know, since I really want to get dsound openal merged. :) If there are still concerns that are open I would like to know, especially if they affect wasapi which is defined in include/audioclient.idl and audiopolicy.idl One of the things which worries me and which you also mentioned on irc is whether openal is the right library to implement wasapi. You mentioned that some tasks require a 'server' (for the session guid stuff). Further there are other features like per stream volume which sound servers support but openal doesn't support this (it would the task of a real sound server). I have the feeling that 'classic' sound libraries (openal, alsa, oss, ..) are not the right approach for implementing a 'sound server'. In my opinion they should be implemented on top of CoreAudio/PulseAudio/.. OpenAL supports per stream volume. The service is basically needed if an application wants to 'audio groups' all using the same sound card across processes, and be able to switch it to some different card with 1 command. Since I don't think the sessions are persistent, this requires a audio service no matter what audio api is used. :) Cheers, Maarten.
Re: Building and packaging Wine Gecko
Anssi Hannula wrote: However, the instructions on that page ask for copying binaries directly provided in wine-mozilla tarball, and for modifying mingw32 headers. It's probably also possible to generate these at package build time by invoking the appropriate commands. If it's the lib*.a files, you can probably just build-depend on wine-dev and run i586-mingw32msvc-dlltool or something on the appropriate Wine .def file to get a mingw32 import library in .a format. I'm not sure about the wintools libs, but if they're actually needed, there must be a way to build them... even if it might take making official mingw-built packages of glib and libidl to include in the distro... Well, I've been planning to try to make a Debian package of gecko, but won't have time to finish it before the holidays.
Re: Building and packaging Wine Gecko
2009/12/12 Ove Kaaven o...@arcticnet.no: Anssi Hannula wrote: However, the instructions on that page ask for copying binaries directly provided in wine-mozilla tarball, and for modifying mingw32 headers. It's probably also possible to generate these at package build time by invoking the appropriate commands. If it's the lib*.a files, you can probably just build-depend on wine-dev and run i586-mingw32msvc-dlltool or something on the appropriate Wine .def file to get a mingw32 import library in .a format. I'm not sure about the wintools libs, but if they're actually needed, there must be a way to build them... even if it might take making official mingw-built packages of glib and libidl to include in the distro... Well, I've been planning to try to make a Debian package of gecko, but won't have time to finish it before the holidays. Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net repository? It's just the pre-packaged cab file stored in /usr/share/wine/gecko.
Re: Building and packaging Wine Gecko
Ben Klein skrev: Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net repository? It's just the pre-packaged cab file stored in /usr/share/wine/gecko. That's the reason I'm not looking at it.
Re: Sound concerns
OpenAL supports per stream volume. The service is basically needed if an application wants to 'audio groups' all using the same sound card across processes, and be able to switch it to some different card with 1 command. Since I don't think the sessions are persistent, this requires a audio service no matter what audio api is used. :) Speaking about Cross-Process Does wasapi offer any ways to manipulate(e.g. volume control) or access another processes streams? With a sound server this might be possible, don't know if it makes sense though. I guess openal cannot do this because its just a per-process library.
Re: Building and packaging Wine Gecko
On Fri, Dec 11, 2009 at 5:06 PM, Ove Kaaven o...@arcticnet.no wrote: Ben Klein skrev: Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net repository? It's just the pre-packaged cab file stored in /usr/share/wine/gecko. That's the reason I'm not looking at it. I don't think I have seen any distribution include wine-gecko. Fedora seems to be in the best position to finally make a wine-gecko package, since it now provides a MinGW toolchain. I haven't used Mandriva in years, so I have no idea if Mandriva includes a full blown toolchain like Fedora does. If it does, you might want to look into using that toolchain to help make a package for wine-gecko.
Re: Building and packaging Wine Gecko
Sir Gallantmon skrev: I don't think I have seen any distribution include wine-gecko. Fedora seems to be in the best position to finally make a wine-gecko package, since it now provides a MinGW toolchain. Why does *that* put Fedora in the best position? Debian has had a MinGW toolchain for years, the building wine-gecko wiki page even mentions attempts to use it. Only problem with it is that it's not the newest version. Perhaps if you meant that Fedora also has built a whole bunch of libraries using mingw and packaged them as rpms, then that *might* give it an edge. Still won't make me ever use Fedora, though.
Re: Building and packaging Wine Gecko
On Fri, Dec 11, 2009 at 5:37 PM, Ove Kaaven o...@arcticnet.no wrote: Sir Gallantmon skrev: I don't think I have seen any distribution include wine-gecko. Fedora seems to be in the best position to finally make a wine-gecko package, since it now provides a MinGW toolchain. Why does *that* put Fedora in the best position? Debian has had a MinGW toolchain for years, the building wine-gecko wiki page even mentions attempts to use it. Only problem with it is that it's not the newest version. Perhaps if you meant that Fedora also has built a whole bunch of libraries using mingw and packaged them as rpms, then that *might* give it an edge. Still won't make me ever use Fedora, though. Sorry, I think of the word toolchain differently I guess. I always considered a toolchain to include both tools and common libraries, as Fedora did. I was aware of the MinGW compiler offered in the Debian package repository, but with no libraries, I considered it useless.
Re: Building and packaging Wine Gecko
Sir Gallantmon wrote: On Fri, Dec 11, 2009 at 5:06 PM, Ove Kaaven o...@arcticnet.no mailto:o...@arcticnet.no wrote: Ben Klein skrev: Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net http://lamaresh.net repository? It's just the pre-packaged cab file stored in /usr/share/wine/gecko. That's the reason I'm not looking at it. I don't think I have seen any distribution include wine-gecko. Fedora seems to be in the best position to finally make a wine-gecko package, since it now provides a MinGW toolchain. I haven't used Mandriva in years, so I have no idea if Mandriva includes a full blown toolchain like Fedora does. If it does, you might want to look into using that toolchain to help make a package for wine-gecko. Yes, it does. I don't think I have the time to figure out the Gecko build myself without proper documentation, though :/ -- Anssi Hannula
Re: meaning of Hardware field in bugzilla?
Nate Gallaher wrote: Austin English wrote: Dan and I discussed it, and figured renaming the hardware to reflect the architecture would be more descriptive: Macintosh - ppc32 PC - x86 PC-x86-64 - x86-64 sun - sparc How does that sound? +1 here. Sounds like a solid idea. Looks good to me too. Vitaliy.
Re: meaning of Hardware field in bugzilla?
On Sat, Dec 12, 2009 at 2:35 AM, Austin English austinengl...@gmail.comwrote: Dan and I discussed it, and figured renaming the hardware to reflect the architecture would be more descriptive: Macintosh - ppc32 PC - x86 PC-x86-64 - x86-64 sun - sparc How does that sound? -- -Austin If your going to re-work this I would also add ARM to the list, their has been some work to port Wine to the ARM processor lately. Anyone have any objections to adding a ARM selection to the list? ARM - RISC Cheers, Tom
Re: meaning of Hardware field in bugzilla?
Sure, once it's far enough along... might be a bit early yet? On Dec 11, 2009 6:15 PM, Tom Wickline twickl...@gmail.com wrote: On Sat, Dec 12, 2009 at 2:35 AM, Austin English austinengl...@gmail.com wrote:Dan and I dis... If your going to re-work this I would also add ARM to the list, their has been some work to port Wine to the ARM processor lately. Anyone have any objections to adding a ARM selection to the list? ARM - RISC Cheers, Tom
Re: Building and packaging Wine Gecko
Sir Gallantmon skrev: Sorry, I think of the word toolchain differently I guess. I always considered a toolchain to include both tools and common libraries, as Fedora did. I was aware of the MinGW compiler offered in the Debian package repository, but with no libraries, I considered it useless. Well, to be fair, the libraries included with mingw32 include the whole Win32 API, including the standard C runtime (msvcrt). What more could you possibly need from a minimalist GNU for Windows compiler for it to be useful...? I think, though, that Debian decided not to bloat the Debian archive with precompiled third-party libraries for mingw. They prefer to bloat it only with packages built for the supported Debian architectures. Cross compilers (like mingw) are often included since they need to run on the host, but extra libraries for the non-native architecture usually aren't, you may need to compile stuff like that yourself (or use stuff like apt-cross/dpkg-cross if possible, but they may not apply to mingw). Can be a bit of a pain, though, yes... but maybe, once they've finally gotten multiarch up and running (planned for years and probably due to occur sometime before the heat death of the universe), it'll be easier and cleaner to deal with cross-compilation (and emulation) environments. I think I may be able to deal with it for now though. Even the current situation is less hassle than ever having to touch rpm... or even worse, Fedora...
Re: meaning of Hardware field in bugzilla?
I was thinking sense your about to revise this area why not just do it now and have it over with? But yea I suppose Wine support on ARM is in the early stages, but if enough people are interested in Wine on ARM then the bug reports should start to come in. It's just a suggestion not a recommendation :) Thanks, Tom On Sat, Dec 12, 2009 at 10:45 AM, Dan Kegel d...@kegel.com wrote: Sure, once it's far enough along... might be a bit early yet? On Dec 11, 2009 6:15 PM, Tom Wickline twickl...@gmail.com wrote: On Sat, Dec 12, 2009 at 2:35 AM, Austin English austinengl...@gmail.com wrote:Dan and I dis... If your going to re-work this I would also add ARM to the list, their has been some work to port Wine to the ARM processor lately. Anyone have any objections to adding a ARM selection to the list? ARM - RISC Cheers, Tom
Re: Building and packaging Wine Gecko
On Fri, Dec 11, 2009 at 9:07 PM, Ove Kaaven o...@arcticnet.no wrote: Sir Gallantmon skrev: Sorry, I think of the word toolchain differently I guess. I always considered a toolchain to include both tools and common libraries, as Fedora did. I was aware of the MinGW compiler offered in the Debian package repository, but with no libraries, I considered it useless. Well, to be fair, the libraries included with mingw32 include the whole Win32 API, including the standard C runtime (msvcrt). What more could you possibly need from a minimalist GNU for Windows compiler for it to be useful...? It almost certainly doesn't include the whole API set for Windows. It includes the minimal Win32 API, yes, but not all the Win32 APIs. I don't care for your bias on RPM based distros, so meh. I respect Debian's decision not to include common libraries under cross-arching, but I personally like the convenience that Fedora offers, especially given all the circular dependencies some of the libraries that Fedora provides would require if built from source.
