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

Re: Wine test bot and win16 exe

by Austin English

On Sat, Mar 31, 2012 at 12:42, Christian Costa <titan.costa(a)gmail.com> wrote: > Hi, > > I wrote a win16 exe test file using open watcom but I cannot submit it to > winebot. I fails saying "Unricognized file type". This is a little annoying. > Is this a known limitation of wine test bot ? > > Thanks > Christian http://wine.git.sourceforge.net/git/gitweb.cgi?p=wine/winetestbot;a=blob;f=… it's not 16-bit aware. You could perhaps make a self extracting zip and have it run the test, maybe. Or patch the testbot.. ;) -- -Austin

April 1, 2012

Re: wined3d: Added PCI device IDs for AMD Radeon 6750M & 6770M

by Henri Verbeet

On 1 April 2012 19:08, Gaurav Jain <gaurav(a)gauravjain.org> wrote: > However isn't it important for wine to still distinguish between models (if possible) if they have different minimum memory sizes across models? Are there any other significant differences across models that wine need to be aware of? > In general it isn't very important to report the exact model to the application, as long as it's roughly the same class of hardware wrt e.g. supported shader model. Ideally applications wouldn't care at all about this and use the caps instead, though in practice applications might use the PCI IDs for workarounds for driver bugs or for capability detection. The video memory is even more of a guess than everything else, in particular because you can have the same model with different amounts of video memory. The GL_NVX_gpu_memory_info extension would be very useful for this if it wasn't experimental.

April 1, 2012

Re: d3dx9: Implement D3DXCreatePolygon

by Józef Kucia

On Sun, Apr 1, 2012 at 10:43 PM, David Adam <david.adam.cnrs(a)gmail.com> wrote: > + *mesh = polygon; > + > + if (adjacency) > + { > + hr = D3DXCreateBuffer(3 * sides * sizeof(DWORD), &adjacency_tmp); > + if (FAILED(hr)) return hr; You should release the polygon mesh. Also, you probably shouldn't touch *mesh when the function fails. -- Józef Kucia

April 1, 2012

Re: shell32: Added stubs for IMarshal interface (resend)

by Gaurav Jain

Hi Jacek, First I'd like to put a disclaimer, that I'm extremely new to this, so please forgive me if I don't understand most of the behaviours and dependancies. That being said, I will try my very best to dig as much as I can to find out more. On 2012-04-01, at 7:08 AM, Jacek Caban wrote: > the fact that you see better behavior in an app may be very well a side effect of Wine behaving badly but in a different (more friendly for given application) way Yes I believe the poor behaviour in wine is that it does not properly resolve the lookup of the IMarshal interface, which the application does not like. Thus adding the stubs allows the lookup to pass and stubs to return "not implemented" error values. > The first question is does the object really implements custom IMarshal implementation on Windows? How should I go about understanding this more? Would you like to know which IMarshal stubs are being called out to? I should probably explain more the poor application behaviour that I was seeing. Towards the end of the installation, I got the error: "Unable to add game tasks: IPersistFile::Save failed". With the addition of the IMarshal stubs, this error goes away. I'm not entirely sure what path the application takes as a result of calling the unimplemented IMarshal functions. Thanks, Gaurav

April 1, 2012

Re: wined3d: Added PCI device IDs for AMD Radeon 6750M & 6770M

by Gaurav Jain

On 2012-04-01, at 6:57 AM, Henri Verbeet wrote: > Does the Windows driver really distinguish > between these? I'm not sure if it does, if the matching is only on the vendor and device ID, then it's unlikely. However isn't it important for wine to still distinguish between models (if possible) if they have different minimum memory sizes across models? Are there any other significant differences across models that wine need to be aware of? Gaurav

April 1, 2012

Re: shell32: Added stubs for IMarshal interface (resend)

by Jacek Caban

Hi Gaurav, On 3/31/12 9:22 PM, Gaurav Jain wrote: > shell32: Added stubs for IMarshal interface (resend) > > Resending due to previous code freeze. > > ShellLink_QueryInterface() did not have a lookup for the IMarshal Interface. This resulted in an error message popping up in the Quest for Glory II (remake) installer. Providing IMarshal interface stubs avoids this error behaviour. > IMarshal is an interface that has serious impact on how the object is handled in RPC calls and the fact that you see better behavior in an app may be very well a side effect of Wine behaving badly, but in a different (more friendly for given application) way. The first question is does the object really implements custom IMarshal implementation on Windows? Cheers, Jacek

April 1, 2012

Re: wined3d: Added PCI device IDs for AMD Radeon 6750M & 6770M

by Henri Verbeet

On 1 April 2012 01:55, Gaurav Jain <gaurav(a)gauravjain.org> wrote: > Ahh... I didn't catch that the 6600M & 6750M was identical. Is there even a 6600M? My google search only found a 6630M, 6650M & 6670M. I believe 6600M is the series. I can remove the 6750M from the patch if you'd like. Please note that there is another duplicate entry for 5700 & 5750. > > The 6770M did have a different PCI ID, would you like the patch modified with only changes for the 6770M? Actually, I didn't spot this yesterday, but the description strings look suspect as well. Does the Windows driver really distinguish between these? Most of the r600 cards only distinguish the general series in the driver description string, and you can't necessarily tell them apart from the PCI IDs either. Unless the Windows drivers actually distinguish between these cards, they probably shouldn't have separate entries at all.

April 1, 2012

Re: [2/2] gdi32: Simplify font cache. (try 2)

by Alexandre Julliard

Kusanagi Kouichi <slash(a)ac.auone-net.jp> writes: > On 2012-03-30 15:36:06 +0200, Alexandre Julliard wrote: >> I don't think that's a good idea. There are many things in the structure >> that don't make sense to have in the registry. > > Font cache lacks some information. Of course we can fix that, but that > might occur again. If we save and load full information, we never lose > any information. > >> Also this won't work on 64-bit. > > Wine64 looks to work. Do you mean WoW64? Yes. There are also potential security issues with the leaking of pointer values or padding bytes. You really don't want to store such internal structures in the registry. -- Alexandre Julliard julliard(a)winehq.org

April 1, 2012

Re: d3dx9_36: Implement D3DXSHDot

by Rico Schüller

Am 01.04.2012 04:33, schrieb David Adam: + * Order is not limited by D3DXSH_MINORDER and D3DXSH_MAXORDER! + * All values will work, test from 0-7 [D3DXSH_MINORDER = 2, D3DXSH_MAXORDER = 6] + * Exceptions will show up when out, in1 or in2 are NULL + */ + for (k = 0; k < 8; k++) Where is the variable out? Cheers Rico

April 1, 2012