Re: mshtml: Set outgoing pass-by-address variable in an error case case within confirm_safety_load.
Hi Gerald, On 03/07/12 23:35, Gerald Pfeifer wrote: I noticed we return in this case, without initializing this variable. Visual inspection indicates we do not seem to access the variable in this error case, but a) better safe than sorry, and b) GCC 4.8 currently warns about it. Not sure URLPOLICY_DISALLOW is the best return value, open for better alternatives. I generally don't think this patch makes things any better (or worse). If we return an error, the caller should not expect this value to be sane. What's the GCC 4.8 warning? Jacek
Building the 1.6 Release Notes as things are written.
So, congrats everyone, 1.4 is out and I'm very happy about it :) I wanted to thank Alexandre for his release announcement, it was very through and informative. It also looked like a lot of work. This made me wonder if we could instead build up the announcement gradually with some sort of process. For instance, if every significant feature added to a development release were put onto a wiki page, then at any point in time we could point someone there to answer a general what does 1.5 have over 1.4? question. Come 1.6 release time, we could just copy and edit the page as the official announcement. Thoughts? -Scott Ritchie
Re: [PATCH 3/3] urlmon: Use CopyBindInfo in InternetBindInfo_GetBindInfo
Hi Piotr, On 03/08/12 13:00, Piotr Caban wrote: - -*pbindinfo = This-bindinfo; - -if(pbindinfo-szExtraInfo || pbindinfo-szCustomVerb) -FIXME(copy strings\n); - -if(pbindinfo-stgmedData.pUnkForRelease) -IUnknown_AddRef(pbindinfo-stgmedData.pUnkForRelease); - -if(pbindinfo-pUnk) -IUnknown_AddRef(pbindinfo-pUnk); - -return S_OK; +pbindinfo-cbSize = sizeof(BINDINFO); Isn't caller responsible for setting this? +return CopyBindInfo(This-bindinfo, pbindinfo); Jacek
Got Application cross-compiled with msvc11 for ARM running
Hi, I cross-compiled a simple Application with the preview of MSVC 11 to ARM. After some minor changes to Wine i was able to run it on my Pandaboard using the native msvcr110.dll. One thing i noticed in the cross-compile environment is that there are much less libraries available for ARM, that's mostly because the win32 API isn't meant to be ported entirely, instead ARM Apps should be based on WinRT. Still i was able to dynamic load functions from dlls available in Wine beside static loaded functions that also worked. In short: The good news: The ABI is compatible (to armel gnueabi) The bad news: no fully win32 API on ARM Maybe my small changes to Wine will make it into 1.5.1 :) At least i hope so. -- Best Regards, André Hentschel
Re: Got Application cross-compiled with msvc11 for ARM running
On 03/08/2012 05:40 PM, André Hentschel wrote: Hi, I cross-compiled a simple Application with the preview of MSVC 11 to ARM. After some minor changes to Wine i was able to run it on my Pandaboard using the native msvcr110.dll. One thing i noticed in the cross-compile environment is that there are much less libraries available for ARM, that's mostly because the win32 API isn't meant to be ported entirely, instead ARM Apps should be based on WinRT. Still i was able to dynamic load functions from dlls available in Wine beside static loaded functions that also worked. In short: The good news: The ABI is compatible (to armel gnueabi) The bad news: no fully win32 API on ARM Bad news? Quite the contrary. Good use case for Wine on Windows. Maybe my small changes to Wine will make it into 1.5.1 :) At least i hope so. 1.5.1 or 1.4.1? bye michael
Re: Got Application cross-compiled with msvc11 for ARM running
Am 08.03.2012 17:52, schrieb Michael Stefaniuc: On 03/08/2012 05:40 PM, André Hentschel wrote: Hi, I cross-compiled a simple Application with the preview of MSVC 11 to ARM. After some minor changes to Wine i was able to run it on my Pandaboard using the native msvcr110.dll. One thing i noticed in the cross-compile environment is that there are much less libraries available for ARM, that's mostly because the win32 API isn't meant to be ported entirely, instead ARM Apps should be based on WinRT. Still i was able to dynamic load functions from dlls available in Wine beside static loaded functions that also worked. In short: The good news: The ABI is compatible (to armel gnueabi) The bad news: no fully win32 API on ARM Bad news? Quite the contrary. Good use case for Wine on Windows. If we get that running, true. Maybe my small changes to Wine will make it into 1.5.1 :) At least i hope so. 1.5.1 or 1.4.1? I don't decide that :) Maybe both ;) -- Best Regards, André Hentschel
Re: Got Application cross-compiled with msvc11 for ARM running
On 03/08/2012 05:54 PM, André Hentschel wrote: Am 08.03.2012 17:52, schrieb Michael Stefaniuc: On 03/08/2012 05:40 PM, André Hentschel wrote: Hi, I cross-compiled a simple Application with the preview of MSVC 11 to ARM. After some minor changes to Wine i was able to run it on my Pandaboard using the native msvcr110.dll. One thing i noticed in the cross-compile environment is that there are much less libraries available for ARM, that's mostly because the win32 API isn't meant to be ported entirely, instead ARM Apps should be based on WinRT. Still i was able to dynamic load functions from dlls available in Wine beside static loaded functions that also worked. In short: The good news: The ABI is compatible (to armel gnueabi) The bad news: no fully win32 API on ARM Bad news? Quite the contrary. Good use case for Wine on Windows. If we get that running, true. I don't mean the full Wine, just the missing libs and headers for people to easily port their Windows apps to ARM. Maybe my small changes to Wine will make it into 1.5.1 :) At least i hope so. 1.5.1 or 1.4.1? I don't decide that :) Maybe both ;) bye michael
Translating the Wiki to Portuguese
Hello guys, I'd like to help translate some chunks of the Wine wiki to Portuguese. What is the accepted method of translating the wiki pages? What pages do you recognize as being more important to be translated first? If any portuguese speakers want to help let's get in touch to organize ourselves and split the work. Cheers :)
Re: ole32/tests: Load CoRegisterChannelHook dynamic
André Hentschel n...@dawncrow.de writes: Seems Win8 (at least the costumer preview) doesn't export CoRegisterChannelHook in ole32 I don't think we should be adding test behaviors for previews. Wait until the final version is released. -- Alexandre Julliard julli...@winehq.org
Re: Translating the Wiki to Portuguese
On Thu, Mar 8, 2012 at 09:32, Lucas Zawacki lfzawa...@gmail.com wrote: Hello guys, I'd like to help translate some chunks of the Wine wiki to Portuguese. What is the accepted method of translating the wiki pages? What pages do you recognize as being more important to be translated first? The FAQ would probably be the most important to translate. -- -Austin
Re: gdiplus: Create GDI brush only when needed. Take 2. (Resend)
Looks good to me.
Re: [PATCH 6/6] d3dxof: Do not allow separator to terminate the string. Only the double quote can do that.
Christian Costa titan.co...@gmail.com writes: This should fix the d3dxof problem of bug 12694. It's broken on 64-bit: ../../../../wine/tools/runtest -q -P wine -M d3dxof.dll -T ../../.. -p d3dxof_test.exe.so ../../../../wine/dlls/d3dxof/tests/d3dxof.c touch d3dxof.ok d3dxof.c:578: Test failed: Got size 8, expected 4 d3dxof.c:597: Test failed: Got size 8, expected 4 make[1]: *** [d3dxof.ok] Error 2 -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 4/5] wined3d: Remove a texture dimension check in state_alpha().
Alexandre: The patch is OK, this mail is just some random note on why the code was there in the first place. Am Donnerstag, 8. März 2012, 20:27:15 schrieb Henri Verbeet: I don't think there's any reason color-keying shouldn't work on e.g. cube textures, although it probably isn't very common either. Fyi, I believe the original reason for this check was this line of code, removed by commit 70ed814b95f7719d52fa5b18a375d566a185a9ec. surf = (IWineD3DSurfaceImpl *) ((IWineD3DTextureImpl *)stateblock- textures[0])-surfaces[0]; The implication for the current code is that there should be tests for color keying with mipmaps and cubemaps. Cubemaps are unlikely to be used with color keying as you say, and writing tests for mipmapping is on my todo list for proper color keying with the ffp replacement shader and blit shaders once I have time for this. signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/5] wined3d: Clamp fog coordinate in the vertex shader.
Am Donnerstag, 8. März 2012, 18:22:15 schrieb Matteo Bruni: -shader_addline(buffer, gl_FogFragCoord = OUT[%u].%c;\n, i, reg_mask[1]); +shader_addline(buffer, gl_FogFragCoord clamp(OUT[%u].%c, 0.0, 1.0);\n, i, reg_mask[1]); Is it correct to clamp the fog coord in the vertex shader, or should this be done in the pixel shader? The tests do not answer this question because they write the same fog coordinate for each vertex. Imagine for example two lines. In each of those lines, one vertex has oFog 0.0. The other vertex has oFog = 1.1 in one line, and oFog = 100 in the other. If the value is clamped per vertex, those lines will look the same. If it's clamped per pixel, the latter line will have much steeper gradient Also, what happens to shaders that do not write oFog, but use oPos.z, especially in the situations where the near and far clipping planes are disabled? signature.asc Description: This is a digitally signed message part.
Re: Got Application cross-compiled with msvc11 for ARM running
Am Donnerstag, 8. März 2012, 17:59:48 schrieb Michael Stefaniuc: I don't mean the full Wine, just the missing libs and headers for people to easily port their Windows apps to ARM. What libraries are missing? Or is this still under NDA? signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/5] wined3d: Clamp fog coordinate in the vertex shader.
Il 08 marzo 2012 22:10, Stefan Dösinger stefandoesin...@gmx.at ha scritto: Am Donnerstag, 8. März 2012, 18:22:15 schrieb Matteo Bruni: - shader_addline(buffer, gl_FogFragCoord = OUT[%u].%c;\n, i, reg_mask[1]); + shader_addline(buffer, gl_FogFragCoord = clamp(OUT[%u].%c, 0.0, 1.0);\n, i, reg_mask[1]); Is it correct to clamp the fog coord in the vertex shader, or should this be done in the pixel shader? The tests do not answer this question because they write the same fog coordinate for each vertex. Imagine for example two lines. In each of those lines, one vertex has oFog = 0.0. The other vertex has oFog = 1.1 in one line, and oFog = 100 in the other. If the value is clamped per vertex, those lines will look the same. If it's clamped per pixel, the latter line will have much steeper gradient I think I wrote a test at some point which shows that it is actually per-vertex. But I may be mistaken and such a test should be in the testsuite anyway, so I'll add it. Also, what happens to shaders that do not write oFog, but use oPos.z, especially in the situations where the near and far clipping planes are disabled? That's another good point, I don't think I tested that (that case isn't used by either Soul Reaver or the Sands of Time, the two games I was looking into at the time). I'll update the patches accordingly.
Re: My Idea for GSOC
Hi Daniel, Again, welcome to Wine :-) Finding good d3d-related gsoc projects has become harder each year, as the code is quite mature and we're out of easy things to fix. A few things that come to my mind are: *) Writing more tests. Especially ddraw.dll could use a lot more tests and fixes for the pre-DirectX7 interfaces that are part of this dll, but also the dx7 interfaces. *) The d3dx9 dlls are mentioned in the gsoc wiki page. I don't know how many medium-size tests (read: not HLSL-compiler related) are still left. *) Speaking of d3dx9: An implementation of the vsa.exe, psa.exe and fxc.exe command line tools offered by the DirectX SDK may be a nice thing. This doesn't really require detailed d3d or gl knowledge either. *) Fixing a bug of your choice may be an option. The risk here is that you get stuck finding out what the problem is, or that you end up with a problem that is not 3d-related and/or hard to fix. (e.g. the steam overlay had nothing to do with d3d, it needed a new feature in gcc) *) Further implement Direct3D9Ex. This mostly comes down to writing tests, but there may be infrastructure changes involved that require in-depth knowledge of the d3d code. *) A very long shot: Improve ddraw overlay support, e.g. to get some video players running. This *will* require very good understanding of Wine's d3d code. I haven't looked into the details, so the time needed to accomplish either goal may be way off. signature.asc Description: This is a digitally signed message part.
Re: Got Application cross-compiled with msvc11 for ARM running
Am 08.03.2012 22:15, schrieb Stefan Dösinger: Am Donnerstag, 8. März 2012, 17:59:48 schrieb Michael Stefaniuc: I don't mean the full Wine, just the missing libs and headers for people to easily port their Windows apps to ARM. What libraries are missing? Or is this still under NDA? Easier to tell what's available: ActiveDS.Lib evr.lib PortableDeviceGuids.lib AdvAPI32.Lib Gdi32.LibRpcRT4.Lib ComDlg32.Lib kernel32.Lib shell32.lib d2d1.lib Mfcore.lib strsafe.lib d3d11.lib Mf.lib twinapi.lib d3dcompiler.lib Mfplat.lib UIAutomationCore.lib dcomp.lib mfreadwrite.lib User32.Lib deviceaccess.lib mfuuid.lib Uuid.Lib DhcpCSvc6.Lib mmdevapi.lib WebServices.lib DhcpCSvc.Lib msxml6.lib windowscodecs.lib dloadhelper.lib normaliz.lib WinSpool.Lib dwrite.libodbc32.lib Xinput.lib dxgi.lib odbccp32.lib xmllite.lib ElsCore.lib Ole32.Lib esent.lib OleAut32.Lib (That's the build environment, can't tell what will be available in WOA) -- Best Regards, André Hentschel
Re: My Idea for GSOC
On Thu, Mar 8, 2012 at 3:23 AM, Vitaliy Margolen wine-de...@kievinfo.com wrote: You can find few ideas on what to do on GSOC Wiki page: http://wiki.winehq.org/SummerOfCode If he is adventurous, here is another idea: A wish a day 14: Wine-based Application Virtualization http://www.elpauer.org/?p=1005 (too big for a Summer of Code, though) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Got Application cross-compiled with msvc11 for ARM running
Without opengl, we won't be able to run wined3d. Msi also seems like an important gap. In theory, we can cover that, but I have to wonder about the consequences of putting Wine's msi in a WOA system. It looks like a good base for the rest of Wine to me. It helps that all our sound now goes through mmdevapi, and all our imaging goes through windowscodecs. Let's hope opengl/msi appear in the final WOA, or can be replaced somehow.
Re: Got Application cross-compiled with msvc11 for ARM running
Am Donnerstag, 8. März 2012, 18:38:16 schrieb Vincent Povirk: Without opengl, we won't be able to run wined3d. Yeah, that's unfortunate. d3d9.dll is a big gap in the dll list we could fill. Depending on the 3D driver, we may be able to call into the vendor ICD if microsoft doesn't provide a opengl32.dll. André, can you check if gdi32 has wgl exports like wglCreateContext and wglMakeCurrent? signature.asc Description: This is a digitally signed message part.
