Re: Building and packaging Wine Gecko

On Fri, Dec 11, 2009 at 9:07 PM, Ove Kaaven 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 > >

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 recommendati

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 use

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" wrote: On Sat, Dec 12, 2009 at 2:35 AM, Austin English 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

Re: meaning of "Hardware" field in bugzilla?

On Sat, Dec 12, 2009 at 2:35 AM, 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? > > -- > -Austin > > If your

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 li

Re: Building and packaging Wine Gecko

Sir Gallantmon wrote: > On Fri, Dec 11, 2009 at 5:06 PM, Ove Kaaven > 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

Re: Building and packaging Wine Gecko

On Fri, Dec 11, 2009 at 5:37 PM, Ove Kaaven 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 Fedo

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 ye

Re: Building and packaging Wine Gecko

On Fri, Dec 11, 2009 at 5:06 PM, Ove Kaaven 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

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 au

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: Building and packaging Wine Gecko

2009/12/12 Ove Kaaven : > 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

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,

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/

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

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) every

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

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

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 >

Re: meaning of "Hardware" field in bugzilla?

On Thu, Jan 15, 2009 at 5:37 PM, Scott Ritchie wrote: > Austin English wrote: >> On Tue, Jan 13, 2009 at 1:12 PM, Juan Lang 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 a

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 D

Re: [3/3] winex11.drv: Use the old method to delete the desktop window.

Vincent Povirk writes: > On Fri, Dec 11, 2009 at 4:55 AM, Alexandre Julliard > wrote: >> "Vincent Povirk" writes: >> >>> @@ -516,6 +516,14 @@ static void handle_wm_protocols( HWND hwnd, >>> XClientMessageEvent *event ) >>>              HMENU hSysMenu; >>>              POINT pt; >>> >>> +    

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 wrote: > "Vincent Povirk" writes: > >> @@ -516,6 +516,14 @@ static void handle_wm_protocols( HWND hwnd, >> XClientMessageEvent *event ) >>              HMENU hSysMenu; >>              POINT pt; >> >> +            if (hwnd == GetDesktopWindow())

Re: WineD3D: Frontbuffers are always onscreen

2009/12/11 Stefan Dösinger : > > 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 >> iss

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->I

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 cl

Re: WineD3D: Frontbuffers are always onscreen

2009/12/11 Stefan Dösinger : > 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 u

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_PA

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, u

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 99b08d8497491d5293

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 wrote: > Hi Paul, > >> Don't think

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

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_c

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 t

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: [3/3] winex11.drv: Use the old method to delete the desktop window.

"Vincent Povirk" 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

Re: WineD3D: Frontbuffers are always onscreen

2009/12/11 Stefan Dösinger : >>   - 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

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', '

Re: UNC Pathname handling

Hi Paul, On Fri, Dec 11, 2009 at 11:09 AM, Paul Vriens 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

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) suc

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

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 w

Re: WineD3D: Frontbuffers are always onscreen

Am 10.12.2009 um 23:15 schrieb Henri Verbeet: > 2009/12/10 Stefan Dösinger : >> @@ -6304,7 +6304,7 @@ HRESULT create_primary_opengl_context(IWineD3DDevice >> *iface, IWineD3DSwapChain * > ... >> -swapchain->context[0]->render_offscreen = swapchain->render_to_fbo; >> +swapchain->context[0

Re: shdocvw: Fix test for non-english IE MUI (try 2)

2009/12/11 Alistair Leslie-Hughes : > 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_dbgs

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.

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 GetLongP

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 Get