April 2007 - Wine-devel - list.winehq.org

Re: patch for msi.dll (action.c and custom.c)
by James Hawkins 24 Apr '07

24 Apr '07

On 4/24/07, Ivan Sinitsin <ivan(a)etersoft.ru> wrote: > The patch fix the problem with wrong source path when you install *.msi (for > example FineReader 8.0). > > Changelog: > This patch fix problem with wrong source path. > This is wrong. Please read msdn about custom action type 17. The source dll for the custom action is the installed file, so file->TargetPath is right. -- James Hawkins

1 0

Fwd: Status of Wine in (K)Ubuntu
by Vijay Kiran Kamuju 24 Apr '07

24 Apr '07

Hi Jonathan Riddell has sent me a reply regarding the wine status in Ubuntu. I am also putting that message below. I have nominated Scott Ritchie as maintainer for wine in Ubuntu. I think we need to put up a proposal for wine for Ubuntu. Any Ideas, guys. Thanks, VJ ---------- Forwarded message ---------- From: Jonathan Riddell <jriddell(a)ubuntu.com> Date: Apr 23, 2007 8:49 AM Subject: Re: Status of Wine in (K)Ubuntu To: Vijay Kiran Kamuju <infyquest(a)gmail.com> On Sun, Apr 08, 2007 at 05:10:59PM -0400, Vijay Kiran Kamuju wrote: > What is the current release/packaing stratergy wrt Wine. > Is it possible toomchange the release/packaging statergy of Wine. > As the current release of wine is fortnightly and mostly its bug fix > release. > And the ubuntu universe version is not upto date with the current wine > release. > I would like to create a blueprint for wine like as > Till the release of 1.0 we will be releasing fortnightly updates in > sync with Wine releases. > After that we will give patches based on fixes given on main branch > like all other s/w till next version. > I think this is a good statergy. > And I t will be benificial to wine and ubuntu. > Can i make such a blue print and make it available for fiesty, please. > I dont mind if you do it. I don't know of anyone who actively works on wine in the Ubuntu archives. I'd recommend posting a proposal to ubuntu-motu for more regular updates. But updates must follow the ubuntu release schedule. https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu Jonathan

1 0

Re: localui: add Polish translation
by Detlef Riekenberg 24 Apr '07

24 Apr '07

On Mo, 2007-04-23 at 19:55 +0200, Mikołaj Zalewski wrote: > (0009-localui-add-Polish-translation.txt) > From 4045f052bd5814a2dbf35527af4f6f7fee259c8e Mon Sep 17 00:00:00 2001 > +#include "ui_Pl.rc" You missed the translated File, but it would be nice, when you wait a week please: I have a Patch for AddPortUI, that add more strings and a Dialog and the Patchs grow whith more translations. Thanks -- By by ... Detlef

2 1

SambaXP 2007 Report, Day 1
by Kai Blin 24 Apr '07

24 Apr '07

Hi folks, this will be the first installment of my SambaXP 2007 report. SambaXP started on monday with a tutorial from Jerry Carter, which was interesting but not really related to Wine. However, in the evening I finally managed to grab hold of Steve French to talk about implementing a remote named pipes interface in cifs. This afternoon, the actual conference is about to start, featuring a couple of talks about winbind, cifs and couple of other things that might be interesting for Wine. For remote named pipes, Steve suggested to use mount to set up the pipes, switching from byte mode to message mode and back using chattr. I'll look into writing some example code for Steve to test and then we'll look into kicking that off. That's it for the monday writeup, I expect that today will give more intersting things to write about. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

RE: dinput: Constify some variables
by Vitaliy Margolen 24 Apr '07

24 Apr '07

Andrew Talbot wrote: > Changelog: > dinput: Constify some variables. > -static LONG map_axis(JoystickImpl * This, short val, short index) > +static LONG map_axis(const JoystickImpl *This, short val, short index) > { > double fval = val; > double fmin = This->props[index].lMin; > diff -urN a/dlls/dinput/joystick_linuxinput.c b/dlls/dinput/joystick_linuxinput.c > --- a/dlls/dinput/joystick_linuxinput.c 2007-03-08 21:37:02.000000000 +0000 > +++ b/dlls/dinput/joystick_linuxinput.c 2007-04-23 20:28:26.000000000 +0100 > @@ -586,7 +586,7 @@ > * adapts values accordingly. > */ > static int > -map_axis(JoystickImpl* This, int axis, int val) { > +map_axis(const JoystickImpl *This, int axis, int val) { > int hmax = This->props[axis].havemax; > int hmin = This->props[axis].havemin; > int wmin = This->props[axis].wantmin; Please don't make a pointer to This a const. Same objections as with any COM object. Vitaliy.

1 0

Re: [UPDATE] [programs/uninstaller] Check HKCU for uninstall entries too
by James Hawkins 23 Apr '07

23 Apr '07

On 4/19/07, Tom Spear <speeddymon(a)gmail.com> wrote: > Apparently the last patch had multiple patches in the file because I > didnt delete it before creating the new one.. > > So here we go again. > > Check HKCU as well as HKLM for uninstall entries, using a for loop > @@ -69,7 +69,7 @@ /** * Used to output program list when used with --list */ -static void ListUninstallPrograms(void) +static void ListUninstallPrograms() The parameter list was correct as is. If a function takes no parameters, the correct list is 'void'. Don't change parts of the code that don't have to do with your patch, especially when you don't know what you're changing. if (i < numentries) - UninstallProgram(); + for (x=0; x<2; x++) + UninstallProgram(rootkey); Why are you calling UninstallProgram twice with the same key? Besides that, using magic numbers (2) is bad coding. + HKEY keys[2]; + keys[0] = HKEY_CURRENT_USER; + keys[1] = HKEY_LOCAL_MACHINE; HKEY keys[] = { HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE }; + for (x=0; x<2; x++) You're hardcoding this value to 2, which is another bad magic number. What if, hypothetically, more root keys are added to the list? for (x = 0; x < sizeof(keys); x++) + rootkey[0] = HKEY_CURRENT_USER; + rootkey[1] = HKEY_LOCAL_MACHINE; Same thing as above. + sizeOfSubKeyName = 255; What is 255? + HKEY rootkey[2]; + rootkey[0] = HKEY_CURRENT_USER; + rootkey[1] = HKEY_LOCAL_MACHINE; Same. + /* FIXME: UninstallProgram should figure out which root key to uninstall + * from, as opposed to just going with the first value in rootkey. The + * entry gets removed this way as well, but it is not apparent by this code. + */ + UninstallProgram(*rootkey); What is the point of adding rootkey if you're not going to use it? UninstallProgram(HKEY_X) is a lot shorter. The point is, don't add something until you're going to use it. On top of that, this new code is basically UninstallProgram(HKEY_CURRENT_USER) when the original code was (parameter added for convenience) UninstallProgram(HKEY_LOCAL_MACHINE). That's not right. -- James Hawkins

2 4

Re: [PATCH] Make wine build with the Intel CC
by Jonathan Schleifer 23 Apr '07

23 Apr '07

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > Wine could build fine without c++, not sure why everything has to > link against the c++ library as it will probably only be needed in > winegcc. Also these compiling flags seem kind of agressive. As I said, just quoted from my .profile, nothing special for wine. I just have -lstdc++ added there as some apps need it to compile with icc. > They are defined in include/winbase.h That's the point. They are defined INCLUDING the asm code. That's why the asm code is already defined and not needed in the file itself. > just make sure icc is recognised there. You mean: Make sure that icc doesn't get recognized as gcc. Well, I tried that. It doesn't work. This will still end in stuff like: /tmp/iccCwib4Das_.s:1499: Error: symbol `wine_get_fs' is already defined /tmp/iccCwib4Das_.s:1523: Error: symbol `wine_set_fs' is already defined > you can't just comment out those Interlocked functions, some > applications might need them. I only commented them out because they are defined TWICE. They are still there and thus the programs run. I tested running a few apps with this patch. > Plus the way you do it makes the code unreadable. I cannot test this > as I don't have icc. I'm sure someone on the list has icc. -- Jonathan

5 11

Re: ADVAPI32: Implement GetServiceDisplayNameW
by Alexandre Julliard 23 Apr '07

23 Apr '07

"Rolf Kalbermatter" <r.kalbermatter(a)hccnet.nl> writes: > + size = *lpcchBuffer * sizeof(WCHAR); > + ret = RegGetValueW(hscm->hkey, lpServiceName, szDisplayName, RRF_RT_REG_SZ, &type, NULL, &size); > + switch (ret) > + { > + case ERROR_SUCCESS: > + ret = RegGetValueW(hscm->hkey, lpServiceName, szDisplayName, RRF_RT_REG_SZ, &type, lpDisplayName, &size); > + *lpcchBuffer = (size / sizeof(WCHAR)) - 1; > + break; It would be better to put the data into the buffer right away, so that you don't need two registry queries in the common case of the buffer being large enough. -- Alexandre Julliard julliard(a)winehq.org

2 1

D3DRM (to be continued....)
by David.Adam＠math.cnrs.fr 23 Apr '07

23 Apr '07

Hi all, my patches for D3DRM have not been applied yet. I thought to have made all the requested changes. But it seems no. So, am I in the good way? What changes must I make now? These patches fix Bug 7442 also. Thanks you in advance for any advice and suggestion. David Adam PS: I follow closely the following advice of wine-wiki for developpers: "Just do not give up!" of the page http://winehq.org/site/sending_patches :))

3 2

The Alky Project
by Ian Macfarlane 23 Apr '07

23 Apr '07

The Inquirer has an interesting article about something called the Alky Project which claims to have initial support for DirectX 10 on Windows XP (and possibly other operating systems). The Inquirer article is here (it links to a number of bits of info about the project): http://www.theinquirer.net/default.aspx?article=39095 They've released some sample DirectX 10 DLL files here: http://fallingleafsystems.com/site_media/preview.zip which they claim support at least one of the DirectX 10 demos fairly well (there's a readme in the zip, which is small, only 824k). I see that some person with an interest in WINE has already asked about this, to make sure they're not ripping off WINE, and they've responded with some details (including a bit of code) here: http://www.fallingleafsystems.com/forum/index.php?showtopic=12 Just posting this in case any developers haven't seen this yet and would like to know about it - sorry if it's just repeating stuff you already know, but I couldn't find anything in wine.devel about it. Best wishes Ian Macfarlane (I'm not affiliated with any of the stuff mentioned in this email)

3 2