April 2010 - Wine-Devel - list.winehq.org

Native Windows web Browser plugins for Linux Mozilla
by Joni Salmela April 6, 2010

April 6, 2010

I have an idea how to get native windows mozilla plugins to work in native Linux mozilla... as you know in Chrome each new tab is its own independent process yet they all share a parent x-window so... if you could create a Windows which would host an active-x plugin or just the mozilla NP_PAPI plugin it could serve as an wrapper okay so create a generic "plugin wrapper" for mozilla and start a new instance of wine the application that hosts the active-x plugin and set its parent as the mozillas window... this hosting an Active-X plugin via NP_PAPI does work in Windows btw... sincerely Joni Salmela. joni.salmela(a)hesburger.fi

3 2

msvidc32/msvideo1 question: upside down buffers?
by Joerg-Cyril.Hoehle＠t-systems.com April 6, 2010

April 6, 2010

Hi, does anybody know why msvideo_decode_8bit(), when imported from the FFmpeg project in 2004, was changed such that the pixels[] array became filled upside down? See how #ifdef ORIGINAL, which shows the original FFmpeg code, differs from the #else branch in msvideo1.c Do buffers in Wine work upside down and backwards? Why can't Wine use exactly FFmpeg's code? I'm asking because no similar set of changes was applied to msvideo_decode_16bit(). I have files that are rendered incorrectly and even suspect of crashing Wine because of this. I could write a patch but need to know. Thank you for your help, Jörg Höhle

2 1

Re: Working on "DOS" VGA.
by chris ahrendt April 6, 2010

April 6, 2010

Just my 2 phennings worth on this... Why reinvent the wheel... I would say instead of doing the emulator inside wine... or a JIT... why not have wine intersept the call to start the vm86 mode.. and forks off and starts DOSEMU or whatever DOS box system is configured.. That way wine doesnt have to worry about it... chris

9 10

[PATCH 1/5] winmm: Improve MCI's Sysinfo command.
by Joerg-Cyril.Hoehle＠t-systems.com April 6, 2010

April 6, 2010

Hi, Eric Pouech wrote: >did you test the 16 => 32 bit conversion for the MCI_ALL_DEVICE ? Which ones do you have in mind? There are tests involving MCI_ALL_DEVICE_ID that pass on both win9x and later (also in patch #5). I wrote a few more MCI tests privately. Generally, I added (UINT16) casts in Wine when I saw test failures on Win9x platforms, then kept doing so (i.e. I'm not sure I've tested SYSINFO with a 0000FFFF deviceID on Win9x in particular or whether I simply use that pattern everywhere now after having been burnt once). There are a few patches already in git that fix a few MCI_ALL_DEVICE_ID here and there, but as you wrote yourself in the TODO header long ago, support for it is incomplete. Making "close all", "play all" etc. work is on my private TODO list, but I never started working on this particular item. >actually, I'd say it belongs to the 16=>32 mci message mapper, not in >generic 32bit code Do you mean dlls/mmsystem.dll16? I never looked at it but I don't think that's the correct place, see below. Do you mean the A/W (un)mapping? That's distinct, because it deals with string conversions only, as the name suggests, and it does not mogrify dwParam1. Current test results suggest that MCI_ALL_DEVICE_ID is not only a 16/32 issue -- at least when I equate 16 with MS-Windows 3.x -- Have a look at the mciGetDeviceID("all") test case, which returns a 16bit FFFF on Win9x, not FFFFFFFF. Therefore I believe Wine must be prepared for receiving 0000FFFF as ALL_ID from old Win9X apps or drivers -- possibly regardless of them using the A or W function entry points. Of course, a single (or few) central place(s) to convert wDeviceID=(MCIDEVICEID)(WORD)wDeviceID or wDeviceID= wDeviceID==0xFFFF ? MCI_DEVICE_ALL_ID : wDeviceID is a nice idea. That could be a distinct patch. I'm convinced this handle is truly a 16 bit entity, even after it has been upgraded to a UINT/DWORD type at some time in the past. Still, SYSINFO is a special case, as it receives a device ID not only as function argument but also in its PARMS structure. Regards, Jörg Höhle.

2 4

Icon Patches Feedback
by Joel Holdsworth April 6, 2010

April 6, 2010

Hi, Are there any thoughts about my latest round of icon patches? Thanks Joel

1 0

wisotool: now supports seven games, runs on windows, too
by Dan Kegel April 5, 2010

April 5, 2010

My little automated app installer tool, wisotool, now supports seven apps: assassinscreed, diablo2, dragonage, morrowind, sims3, starcraft, and wog (world of goo) It also seems to run on Windows ok in Cygwin (though I've only barely tested that). Thanks to Austin for dragonage, morrowind, and some windows fixes, and Eleazar Galano for a draft of the assassinscreed verb. I've updated the doc at http://wiki.winehq.org/wisotool It has a section explaining the difference between wisotool and somewhat related things like appinstall and PlayOnLinux. (In a nutshell, wisotool is a winetricks-like tool for installing games automatically, with no user interaction. It caches .iso files to automate disc-swapping for multiple-disc apps, and caches cd keys to automate installers that need keys, but you have to load the cache from your real copy of the cds or dvds first.) - Dan

1 0

Application period ends in ~4 days
by Maarten Lankhorst April 5, 2010

April 5, 2010

Hi all, I've seen a few very good proposals on the mailing list, but not enough of them ended up as a proposal on the official summer of code app. So if you haven't done so already please apply there now. You can still modify your proposal there after submitting it based on feedback, but you'll have to submit something there soon. Cheers, Maarten

1 0

Re: [PATCH 6/6] Due to code rewrites is_color_fixup_supported is not needed anymore in RealizePalette. The code in question should be executed in all cases. This also fixes palette refresh issues when shaders / paletted textures aren't around.
by Stefan Dösinger April 5, 2010

April 5, 2010

Am 05.04.2010 um 20:05 schrieb Roderick Colenbrander: > - IWineD3DDeviceImpl *device = This->resource.device; > - if((This->resource.usage & WINED3DUSAGE_RENDERTARGET) && > - device->blitter->color_fixup_supported(&device->adapter->gl_info, This->resource.format_desc->color_fixup)) > + if(This->resource.usage & WINED3DUSAGE_RENDERTARGET) It's a problem with the existing code, but checking the usage here doesn't make much sense. It should check if the surface is a front buffer on any swapchain(or, as long as we store a P8 surface as ARGB in GL this code also applies to backbuffers)

2 1

Re: [PATCH 2/6] d3dx9_36: Beginning of constants parsing + tests (based on work from Luis Busquets) (try 2)
by Henri Verbeet April 5, 2010

April 5, 2010

On 5 April 2010 20:28, Christian Costa <titan.costa(a)wanadoo.fr> wrote: > +inline ctab_constant* get_constant(D3DXHANDLE ptr) > +{ > + if (!ptr) return NULL; > + return (ctab_constant*)~(UINT)ptr; > +} > + > +inline D3DXHANDLE get_handle(ctab_constant* ptr) > +{ > + return (D3DXHANDLE)~((UINT)ptr); > +} How is that different? You'd have to cast to UINT_PTR to fit a 64-bit pointer in there, although of course that only works if D3DXHANDLE is also a 64-bit value on 64-bit Windows (didn't check).

2 1

Re: [PATCH 3/6] d3dx9_36: Implement D3DXGetImageInfoFromFileInMemory using WindowsCodecs (based on work from Tony Wasserka) (try 2)
by Vincent Povirk April 5, 2010

April 5, 2010

+ hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); + if (FAILED(hr)) + return E_FAIL; You should continue in this case, but don't call CoUninitialize at the end. On Mon, Apr 5, 2010 at 1:28 PM, Christian Costa <titan.costa(a)wanadoo.fr> wrote: > -- > Check return of CoInitializeEx and some WIC calls. Return an error for unsupported file and pixel formats. > --- > > dlls/d3dx9_36/Makefile.in | 2 - > dlls/d3dx9_36/surface.c | 113 ++++++++++++++++++++++++++++++++++++++++- > dlls/d3dx9_36/tests/texture.c | 40 ++++++--------- > 3 files changed, 127 insertions(+), 28 deletions(-) > > > >

1 0