wine-devel February 2008

wine-devel@winehq.org

141 participants
325 discussions

Re: [msi/tests] Make tests run on win9x/NT4 again
by James Hawkins 25 Feb '08

25 Feb '08

On Sun, Feb 24, 2008 at 10:30 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > MsiSourceListEnumSourcesA and MsiSourceListSetInfoA are only available as of W2K. > > Some tests will still fail on those platforms as the missing functions are not > skipped yet (part of a next patch when time permits). > > Changelog > Make tests run on win9x/NT4 again > This is nitpicky, but it took a long time to write those tests so I feel it's deserved. - r = MsiSourceListEnumSourcesA(prodcode, NULL, MSIINSTALLCONTEXT_USERUNMANAGED, + r = pMsiSourceListEnumSourcesA(prodcode, NULL, MSIINSTALLCONTEXT_USERUNMANAGED, MSICODE_PRODUCT | MSISOURCETYPE_URL, 0, NULL, &size); You can't see it in this email because it's wrapped, but the style of the file is that the continued function parameters on the next lines match up with the first character on the first line. So you need to add the missing space to any continuing lines. Please fix that. -- James Hawkins

2 1

Re: add rule for the .m suffix
by Emmanuel Maillard 25 Feb '08

25 Feb '08

Hi, Did you convince Alexandre Julliard to include Objective-C on wine tree ?? Because you need to if you want to submit my patches to winehq, or rewrite it in plain C with Carbon. Emmanuel Le 20 févr. 08 à 13:31, Steven Edwards a écrit : > This is needed for quartzdrv patch. Trying to reduce the size of the > diff, I expect a real winequartzdrv will need it later on anyway > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > <support-m-suffix.patch>

3 2

USB with libusb
by Eliot Blennerhassett 25 Feb '08

25 Feb '08

Greetings, I have been reading about general USB support. E.g. http://www.winehq.org/?issue=331#USB%20Support%20in%20Wine which mentions 4 scenarios for giving apps access to USB. But here's a 5th that I am wondering about: The Windows app has been linked to (win32) libusb. How do I get it to use the linux version of libusb? Will it "just work", or do I need to make a libusb.dll for Wine that passes calls through to linux libusb? (I am talking to a hardware manufacturer that currently uses their own custom .sys driver to access usb on windows, suggesting libusb might make their app easier to port or just run with Wine) thanks and regards -- Eliot

2 1

USB with libusb
by Eliot Blennerhassett 24 Feb '08

24 Feb '08

Greetings, I have been reading about general USB support. E.g. http://www.winehq.org/?issue=331#USB%20Support%20in%20Wine This mentions 4 scenarios. But here's a 5th that I am wondering about: The Windows app has been linked to libusb. How do I get it to use the linux version of libusb? Will it "just work", or do I need to make a libusb.dll for Wine that passes calls through to linux libusb? (I am talking to a hardware manufacturer that currently uses their own custom .sys driver to access usb on windows, suggesting libusb might make their app easier to port or just run with Wine) thanks and regards -- -- Eliot

1 0

Re: d3dx9: Add stubs for the ID3DXFont functions [PATCH 5/9, try 2]
by tony.wasserka＠freenet.de 24 Feb '08

24 Feb '08

> You have fixed object to *object, what about other places with > a similar problem? Also, the stubs have to use FIXME not TRACE, > and if you do nothing with a passed in parameter, don't assign > it to an internal variable. There is no need to cast NULL either. > If you allocate memory on object creation, you must free it on > object destruction. There is no need to initialize 'object' to > NULL if on the next line you are doing an attempt to allocate it. > What's the point of adding all those includes to d3dx9_36_private.h > if you are not using them? Thanks for that detailed response :) I have fixed what you said and have attached the fixed patch to this mail. The added includes prevented the compilation from failing, but some of them were really not needed as you pointed out. If there won't be any criticisms until tomorrow afternoon I'll resend it to wine-patches.

1 0

Wine and PulseAudio
by Tomas Carnecky 24 Feb '08

24 Feb '08

This subject was discussed a few months ago (around 10/2007). But it was rather a discussion about whether to make a PA sound driver or not. I personally would love to see that happen, if not only because PA has some very nifty features, like per-app volume, transparent sink switching etc, some of which are impossible to emulate through the alsa pulse plugin. Also, then next Ubuntu and Fedora releases will have PA enabled by default so if Wine doesn't work with that well there will be complaints. I switched my desktop to PA yesterday, got most apps working, and to my surprise even flash (netscape 32bit plugin in a 64bit browser). All apps that I need use PA natively, only Wine doesn't have a PA sound driver. Since winealsa.drv will stay the default driver for Linux for the foreseeable future, I started digging and hacking to see why it doesn't work with the alsa pulse plugin and what can be fixed. There are a few bug reports that track the winealsa.drv/PA issue, such as [1]. There is very little required to make it work. Only two tiny changes to the alsa pulse plugin (one can be described as a quirk, until I figure out how exactly the alsa API can be emulated using PA, seems to be a very specific issue in how Wine uses the alsa API since other apps work fine) and sound works perfectly (tested with foobar2000 and WoW, both playback and recording). alsa-1.0.16 was just released, so I hope the needed changes make it into the next version. In the PA volume control, all wine apps show up under the same name: ALSA plug-in [wine-preloader] and thus share the same volume and sink preferences. The alsa plugin could try to do some /proc/self voodoo to extract the true exe name. But given the simplicity of the PA API (no hwparams negotiation, just request a format and you'll get it) and the current problems with the alsa pulse plugin, I think a true wine sound driver would be a viable alternative. I'm still waiting to hear from those people who have said that they have a wine PA driver working :) tom [1] http://bugs.winehq.org/show_bug.cgi?id=10910.

3 6

Re: d3dx9: Add stubs for the ID3DXFont functions [PATCH 5/9, try 2]
by Dmitry Timoshkov 24 Feb '08

24 Feb '08

<tony.wasserka(a)freenet.de> wrote: > Replaced the S_OKs with D3D_OKs, moved the QueryInterface TRACE out of the if condition > and replaced object by *object. You have fixed object to *object, what about other places with a similar problem? Also, the stubs have to use FIXME not TRACE, and if you do nothing with a passed in parameter, don't assign it to an internal variable. There is no need to cast NULL either. If you allocate memory on object creation, you must free it on object destruction. There is no need to initialize 'object' to NULL if on the next line you are doing an attempt to allocate it. What's the point of adding all those includes to d3dx9_36_private.h if you are not using them? -- Dmitry.

1 0

Re: d3dx9: Add stubs for the ID3DXRenderToSurface functions [PATCH 8/9]
by tony.wasserka＠freenet.de 24 Feb '08

24 Feb '08

> Shouldn't that be a n (here and in the other patches)? > Setting object to NULL here doesn't do a whole lot, you should set > *object to NULL (also goes for the other QueryInterface > implementations). Also, you'll probably want to put the TRACE before > the if block. Thank you very much for pointing that out :) Is there anything else wrong with it or can I resend the patches? Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

3 2

Re: d3dx9: Add stubs for the ID3DXRenderToSurface functions [PATCH 8/9]
by H. Verbeet 24 Feb '08

24 Feb '08

On 23/02/2008, tony.wasserka(a)freenet.de <tony.wasserka(a)freenet.de> wrote: > +static HRESULT WINAPI ID3DXRenderToSurfaceImpl_QueryInterface(LPD3DXRENDERTOSURFACE iface, REFIID riid, LPVOID *object) > +{ > + ID3DXRenderToSurfaceImpl *This=(ID3DXRenderToSurfaceImpl*)iface; > + > + if(IsEqualGUID(riid, &IID_IUnknown) || IsEqualGUID(riid, &IID_ID3DXRenderToSurface)) { > + TRACE("(%p): QueryInterface from %sn", This, debugstr_guid(riid)); > + IUnknown_AddRef(iface); > + *object=This; > + return S_OK; > + } > + WARN("(%p)->(%s, %p): not foundn", iface, debugstr_guid(riid), object); > + object=NULL; > + return E_NOINTERFACE; > +} > + Setting object to NULL here doesn't do a whole lot, you should set *object to NULL (also goes for the other QueryInterface implementations). Also, you'll probably want to put the TRACE before the if block.

1 0

Re: d3dx9: Add stubs for the ID3DXFont functions [PATCH 5/9]
by H. Verbeet 24 Feb '08

24 Feb '08

On 23/02/2008, tony.wasserka(a)freenet.de <tony.wasserka(a)freenet.de> wrote: > + TRACE("stubn"); Shouldn't that be a \n (here and in the other patches)?

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
33
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel February 2008