August 2007 - Wine-Devel - list.winehq.org

Re: Wine Kernel Handle Support Module
by Michael Ost Aug. 9, 2007

Aug. 9, 2007

>>> I know there is some discussion of what should be put in the kernel >>> module, so I am asking for advice on what to implement... ie. just >>> handles, everything wineserver does, etc. >> The first question is: >> Why do you want to do that and what specifically do >> you want to achieve? > > A small step towards less overhead in client <-> server calls? One _big_ vote for putting thread sync primitives --- events, semaphores, mutexes and critical sections --- in. We had to build a custom Wine to get acceptable realtime performance (thanks, Ulrich!). The client <-> server were causing high priority threads to block on low priority ones. I guess a test case would be something that shows how a high priority thread blocking on a sync primitive, while some low priority thread is doing some unrelated server heavy stuff, like lots of graphics updates. Cheers... mo

1 0

[SNMPAPI] How to fix the tests for win98 and NT4?
by Paul Vriens Aug. 9, 2007

Aug. 9, 2007

Hi, There are several functions in the util.c test that are not available on win98 and NT4. That can be dealt with easily. Almost all tests with a NULL parameter crash on win98/NT4. I know that a few weeks back we talked about ignoring win98 if it would mean skipping a lot of tests, but now NT4 is involved as well. I could introduce a variable of course that's set when we are on NT4 or lower (because of the missing functions) and don't run the 'NULL' tests. Any ideas, comments? Cheers, Paul.

2 1

Re: exporting file associations for linux desktops
by Misha Koshelev Aug. 9, 2007

Aug. 9, 2007

> To register those verbs for Linux desktops, some sort of command-line > wrapper around ShellExecute would be needed. I think this is a good > idea anyway. Does Windows have anything like that? Is it worth it for > me to try writing something like that based on winelib? Well this is exactly the start program which is already implemented. In fact I thought about this problem myself a bit, the problems with start right now for this purpose (starting wine associated files from linux) are: 1. start currently doesn't understand a simple UNIX path, easily fixed by prepending a Z: (assuming this is the drive the user has mapped to the UNIX root dir) 2. there is no standalone winestart program, and at least from my experimentation with Right Click->Open File With... on GNOME (or whatever the menu item is called), it won't let you put in "wine start" or wine start or the sort. What I actually do right now is use this shell script (I almost started working on this problem but then since the shell script was so easy I decided to focus on other things, but am still very interested in seeing it solved): #!/bin/sh wine start Z:$* And just associating it with my file type (well the problem with doing what I am doing is I am just associating it with a file .gb which I guess GNOME puts into some kind of text/plain type, so anything that is a text file ends up being opened with notepad on wine instead of gedit... I am too lazy to make it any more complex on my computer for now). Anyway, just though this info might help if you were not already aware, as the start program is definitely this wrapper around ShellExecute that already exists. One possibility would be to extend it to handle UNIX paths and then have it compiled and installed as a standalone winestart - like the other wine standalone programs we install, another is just to have the shell script somewhat like above installed (dangerous as Z: may not be mapped to the root so this would have to figured out) - I believe wineshelllink which is installed is a shell script, or maybe even go the route of letting the wine binary itself ShellExecute things (haven't really looked at it/thought this out in detail). Anyway, just my two cents. Thanks for thinking about/hopefully working on this. Misha > > > -- > Vincent Povirk

4 6

[Winetest] Possible removal of LoadLibrary and friends in the conformance tests
by Paul Vriens Aug. 9, 2007

Aug. 9, 2007

Hi, With the current version of winetest, conformance tests for which the main dll is not available will not run anymore. This will be reported on test.winehq.org. We will be seeing the new approach as of 12:00 GMT when the new winetest.exe is available and the first tests come in. Several tests currently check for the existence of the dll via LoadLibrary and do a lot of GetProcAddress calls to retrieve function pointers. This should not be needed anymore in most cases. The tests that come to mind: d3d8 d3d9 d3drm gdiplus localspl localui pdh uxtheme and there are (and will be in the future) others. My plan, and this is open for discussion of course, is to: 1. Add the main dll back as part of the IMPORTS in the Makefile.in files 2. Change LoadLibrary to GetModuleHandle and still use GetProcAddress to catch unexported functions (for a short period). We do need to reporting missing functions. 3. Remove GetModuleHandle and/or GetProcAddress's if possible and make more use of 'skip' if needed. This will be a lengthy process so if there are volunteers, please step up. Eventhough this is some considerable amount of work to be done, in the end the code will be cleaner (and several lines shorter). Comments/remarks ? Cheers, Paul.

5 8

Re: WineD3D: better pixelformat selection code
by H. Verbeet Aug. 9, 2007

Aug. 9, 2007

On 09/08/07, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > This code lets WineD3D use the pixelformat of the D3D device. The code helps > on Windows where OpenGL offers multiple pixelformats. > The stencil column is probably useful for determining if we need an stencil attachment for FBOs as well. >+int count_bits(int mask) >+{ >+ int i, count=0; >+ for(i=0; i<32; i++) >+ { >+ if(mask & (1<<i)) >+ count++; >+ } >+ return count; >+} The "classical" way to do that would be something like this: unsigned int count_bits(unsigned int mask) { unsigned int count; for (count = 0; mask; ++count) { mask &= mask - 1; } return count; } Ie, simply mask out the set bits one by one until none are set, rather than looping over all of them.

1 0

Re: user32: CallWindowProc[AW] for mismatched built-in winprocs should take into account if the window is Unicode (with testcase, fixes bug #9198)
by Dmitry Timoshkov Aug. 8, 2007

Aug. 8, 2007

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > --- a/dlls/user32/tests/class.c > +++ b/dlls/user32/tests/class.c > @@ -32,6 +32,7 @@ > #include "winreg.h" > #include "wingdi.h" > #include "winuser.h" > +#include <commctrl.h> /* for WC_EDITW */ Besides using braces instead of quotes to match existing style it's not really nice to include commctrl.h in a user32 (more lower level) test. It shouldn't be too hard to add "Edit" in WCHAR notation. > /*********************************************************************** > */ > static void ClassTest(HINSTANCE hInstance, BOOL global) > @@ -560,7 +566,12 @@ static void test_defwndproc() > { > static const char classA[] = "deftest"; > static const WCHAR classW[] = {'d','e','f','t','e','s','t',0}; > + WCHAR unistring[] = {0x142, 0x40e, 0x3b4, 0}; /* a string that would be destoryed by a W->A->W conversion */ Any other string should work just fine. In the current form the test will fail for some locales. > diff --git a/dlls/user32/winproc.c b/dlls/user32/winproc.c > index 27b31a1..4feb3d5 100644 > --- a/dlls/user32/winproc.c > +++ b/dlls/user32/winproc.c > @@ -2257,7 +2257,17 @@ LRESULT WINAPI CallWindowProcA( > > if (!func) return 0; > > - if (!(proc = handle_to_proc( func )) && !(proc = find_builtin_proc( func ))) > + /* for built-in procs we do as if the second item was a thunk */ > + if ((proc = find_builtin_proc( func )) != NULL) > + { > + if (func == proc->procA || !IsWindowUnicode( hwnd )) > + call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > + else > + call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > + return result; > + } > + > + if (!(proc = handle_to_proc( func ))) > call_window_proc( hwnd, msg, wParam, lParam, &result, func ); > else if (proc->procA) > call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > @@ -2281,8 +2291,18 @@ LRESULT WINAPI CallWindowProcW( WNDPROC func, HWND hwnd, UINT msg, > LRESULT result; > > if (!func) return 0; > + > + /* for built-in procs we do as if the second item was a thunk */ > + if ((proc = find_builtin_proc( func )) != NULL) > + { > + if (func == proc->procW || IsWindowUnicode( hwnd )) > + call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > + else > + call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > + return result; > + } > > - if (!(proc = handle_to_proc( func )) && !(proc = find_builtin_proc( func ))) > + if (!(proc = handle_to_proc( func ))) > call_window_proc( hwnd, msg, wParam, lParam, &result, func ); > else if (proc->procW) > call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > @@ -2340,7 +2360,17 @@ INT_PTR WINPROC_CallDlgProcA( DLGPROC func, HWND hwnd, UINT msg, WPARAM wParam, > > if (!func) return 0; > > - if (!(proc = handle_to_proc( func )) && !(proc = find_builtin_proc( func ))) > + /* for built-in procs we do as if the second item was a thunk */ > + if ((proc = find_builtin_proc( func )) != NULL) > + { > + if (func == proc->procA || !IsWindowUnicode( hwnd )) > + call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > + else > + call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > + return result; > + } > + > + if (!(proc = handle_to_proc( func ))) > ret = call_dialog_proc( hwnd, msg, wParam, lParam, &result, func ); > else if (proc->procA) > ret = call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > @@ -2368,8 +2398,18 @@ INT_PTR WINPROC_CallDlgProcW( DLGPROC func, HWND hwnd, UINT msg, WPARAM wParam, > INT_PTR ret; > > if (!func) return 0; > + > + /* for built-in procs we do as if the second item was a thunk */ > + if ((proc = find_builtin_proc( func )) != NULL) > + { > + if (func == proc->procW || IsWindowUnicode( hwnd )) > + call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > + else > + call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > + return result; > + } Please use spaces instead of tabs to match current formatting. -- Dmitry.

2 1

Wine Kernel Handle Support Module
by James Keane Aug. 8, 2007

Aug. 8, 2007

I have been working on something that might be useful for kernel integration. It is a way for wine to create its own interrupt, so that a wine server/kernel/handle/whatever function could be called from userspace with a simple INT 0xwhatever. Just as linux uses int 0x80. The only problem I could see with this technique is that it directly modifies the IDT, which only exists on i386/amd64 architectures, so that means we would have to find something else. I am not sure if this is the direction that some people want to take, because I am sure this modification of the IDT would be considered improper by kernel types but come on, I mean i386 has something like 200 software interrupts and linux uses only one. As it stands now, I have code that works perfectly with amd64 processors and just need to implement the actual wine system calls for handles or whatever it is. i386 support is a stones throw away, I just need to setup a virtual machine. I know there is some discussion of what should be put in the kernel module, so I am asking for advice on what to implement... ie. just handles, everything wineserver does, etc.

4 3

exporting file associations for linux desktops
by Vincent Povirk Aug. 8, 2007

Aug. 8, 2007

This was something I thought we wanted for wine for a long time, but I can't find any literature suggesting that's the case. So I'll just explain it here. As it is right now, we have a filetype/association system in Wine's registry, and we have a completely separate one in most Linux desktops. They do not talk to each other. Wine's system relies primarily on extensions because that's what Windows does, but the Linux system works based on MIME Types. I would like to see this gap bridged in one direction by exporting the information in Wine's registry in a simplified format and converting it to something useful for Linux desktops. From what I've seen so far, this looks surprisingly simple. On the Linux end, MIME Types can be registered as described at http://www.freedesktop.org/wiki/Specifications/AddingMIMETutor (only using ~/.local/share instead of /usr/local/share). fd.org doesn't seem to have a standard for registering actions so that would need to be desktop-specific, but I don't expect any major problems from that. The Windows registry does appear to contain some MIME Types, but they're spotty and unreliable. I'm told, though, that most desktops can cope with things like application/x-extension-html even when text/html exists. Generating types like that is probably the way to go. From there, it's a simple matter to get a list of verbs that apply to files with each extension. To register those verbs for Linux desktops, some sort of command-line wrapper around ShellExecute would be needed. I think this is a good idea anyway. Does Windows have anything like that? Is it worth it for me to try writing something like that based on winelib? Also, what's the best way to design this if I want to see it added to Wine? I know how I'd do it as a set of external programs, but I'd rather avoid that. Attached is a simple python script I wrote that prints all of the information I think is necessary to be exported from Wine's registry. I know python is the worst thing I could use if I want something in Wine, but it should be good enough that I can try to import the information on the Linux end before spending too much time on something that may or may not ultimately be useful. -- Vincent Povirk

2 1

Wine components: gdiplus
by Evan Stade Aug. 8, 2007

Aug. 8, 2007

Hi, Could we add gdiplus to the bugzilla components list? thanks. -- Evan Stade

1 0

Re: Rob Shearman : secur32: Split the NTLM credential and context handles into separate objects.
by Kai Blin Aug. 8, 2007

Aug. 8, 2007

On Wednesday 08 August 2007 15:59:23 Alexandre Julliard wrote: > > secur32: Split the NTLM credential and context handles into separate > objects. > > This prevents races with two threads using the helper object at the same > time on two different context handles, eliminates the need to free the > credential handle after freeing the context handles and also prevents a Rob, thanks for cleaning up the mess. This looks more sane now. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

Re: user32: CallWindowProc[AW] for mismatched built-in winprocs should take into account if the window is Unicode (with testcase, fixes bug #9198)
by Alexandre Julliard Aug. 8, 2007

Aug. 8, 2007

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > + hwnd = CreateWindowExW(0, classW, NULL, WS_OVERLAPPEDWINDOW, > + CW_USEDEFAULT, CW_USEDEFAULT, 680, 260, NULL, NULL, GetModuleHandleA(NULL), 0); > + ok(IsWindowUnicode(hwnd), "\n"); > + SetWindowLongPtrW(hwnd, GWLP_WNDPROC, (LONG_PTR)pDefWindowProcA); > + ok(IsWindowUnicode(hwnd), "\n"); > + ok(GetWindowLongPtrW(hwnd, GWLP_WNDPROC) == (LONG_PTR)pDefWindowProcW, "\n"); > + ok(GetWindowLongPtrA(hwnd, GWLP_WNDPROC) == (LONG_PTR)pDefWindowProcA, "\n"); > + SetWindowLongPtrA(hwnd, GWL_WNDPROC, (LONG_PTR)ClassTest_WndProc); > + ok(IsWindowUnicode(hwnd) == FALSE, "\n"); Please use meaningful error messages in the ok() calls. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Wine Kernel Handle Support Module
by Dan Kegel Aug. 8, 2007

Aug. 8, 2007

keane wrote: > I am not sure if this is the direction that some people want to take, > because I am sure this modification of the IDT would be considered > improper by kernel types but come on, I mean i386 has something like > 200 software interrupts and linux uses only one. Do not anger the kernel gods, for they will not take your patch. You are putting the cart before the horse, If you want to use a kernel module, please figure out why first, and work on solving that problem using standard kernel idioms. Linus has said that he would take a patch to add support for win32 system calls if it solved a real problem. Albert Calahan mentioned a few possible benefits in a thread seven years ago: http://marc.info/?l=linux-kernel&m=96954760832002&w=2 You might dig around in that thread for ideas. - Dan

1 0

Re: programs/wineconsole: Correctly display chars 00..1F and 7F [try 2]
by Kirill K. Smirnov Aug. 8, 2007

Aug. 8, 2007

Hi, Alexandre, > > > > Is there something wrong with my patch? Did I miss something important? > > I'm not at all convinced that the conversion has to happen at that > point. Do you have a test app that demonstrates this? I've written test application, which writes control chars and performs readback for comparision. It's behaviour heavily depends on console font: 1) True Type (lucida). Control chars are displayed as square boxes, ReadConsoleOutputCharacters[A|W] return codes [0..31]. 2) Raster (fixedsys). Control chars are correctly displayed as glyphs, ReadConsoleOutputCharacterA returns codes [0..31], ReadConsoleOutputCharacterW returns unicode glyphes. It seems I stumbled upon the same strange insane console behaviour I observed while working upon console codepages. (http://www.winehq.org/pipermail/wine-devel/2007-May/056511.html) Since wine renders fonts in his specific way (freetype, AFAIK), I propose the following: 1) Display control characters as glyphes. (like fixedsys). 2) ReadConsoleOutputCharacter[A|W] both should return characters without any corrupting - if I wrote [0..31] I expect [0..31], if I wrote unicode glyphes, I expect unicode glyphes to be returned. (like TrueType) My patch assumes this behaviour. Of course, I wanted to write proper wine test case, but it is impossible due to different default console fonts under Windows - test will fail. -- Kirill

1 0

Re: [kernel32/tests 2/2] Skip all tests if one W-function can't be found
by Paul Vriens Aug. 8, 2007

Aug. 8, 2007

On 8/7/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > (Should be applied after "[kernel32/tests] Changed skip message"). > > There are to many W-functions called so skip everything if the first function is > not implemented. This makes the test not crash on win95/win98. > > Changelog > Skip all tests if one W-function can't be found > > Cheers, > > Paul > > > Don't use this one. I'll sent an easier fix. The "[kernel32/tests] Changed skip message" can still be applied though. Cheers, Paul.

1 0

Re: WineD3D: move fake context code over to WGL
by Alexandre Julliard Aug. 8, 2007

Aug. 8, 2007

Roderick Colenbrander <thunderbird2k(a)gmx.net> writes: > Subject: [PATCH] Move WineD3D_CreateFakeGLContext and friends over > to WGL. For this we need a HDC and one received from lets say > GetDC(0) won't do. Further this HDC needs CS_OWNDC set. For this > reason we need our own window class. Why does it need CS_OWNDC? That sounds like a bug. -- Alexandre Julliard julliard(a)winehq.org

3 2

[Winetest] Status update (rsabase and secur32)
by Paul Vriens Aug. 7, 2007

Aug. 7, 2007

Hi, The new winetest is running fine and new reports are produced (http://test.winehq.org/data/200708071000/) I have seen at least 2 things so far that I need some info on. rsabase.dll is not available on for example w2k3 and vista but the tests ran in the past. secur32.dll is not available on for example NT4 but the current tests check if security.dll is available instead. What should we do to cater for the above: - we could move for example rsabase tests to rsaenh (we forward everything to rsaenh as well) and something similar for secur32. - we could implement an exception list in winetest for these particular cases. Remarks/Comments? Cheers, Paul.

3 3

Missing library - faultrep.
by Peter Dons Tychsen Aug. 7, 2007

Aug. 7, 2007

Hello. Wine is missing the library "faultrep". The library comes with Windows, and is used by apps for error reporting. Most apps don't really need it (unless something goes wrong), but simply require the DLL to be present. To start with i just wanted to add the DLL to Wine. I tried to submit a patch for this missing lib, but got zero response. Probably because there was something wrong with my commit. Any guess on what was wrong? /Pedro

2 4

Patch: VarWeekdayName
by Jiří Paleček Aug. 7, 2007

Aug. 7, 2007

Hello, I want to ask, is anything wrong with this patch? http://www.winehq.org/pipermail/wine-patches/2007-July/041434.html I'm asking because I have other patches, but don't know if it is worthwhile to send them. Regards Jiri Palecek

8 21

Re: [winecfg] Show version again in About box
by Dmitry Timoshkov Aug. 7, 2007

Aug. 7, 2007

"Paul Vriens" <paul.vriens.wine(a)gmail.com> wrote: > 'Wine 0.9.42' looks so much nicer than 'PACKAGE_STRING'. Thanks for catching this. Although a comment explaining why config.h is needed while there is no visible usage of #ifdef HAVE_xxx macros would be nice. -- Dmitry.

1 0

Re: [2/6] gdiplus: added GdipCreateBitmapFromFile
by Alexandre Julliard Aug. 7, 2007

Aug. 7, 2007

"Evan Stade" <estade(a)gmail.com> writes: > + CloseHandle(file); > + > + if(CreateStreamOnHGlobal(buff, TRUE, &stream) != S_OK){ > + ERR("could not make stream\n"); > + GdipFree(buff); > + return GenericError; > + } You should create a stream on the file directly instead of reading it in first. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/6] gdiplus: added GdipBitmapLockBits/GdipBitmapUnlockBits
by Alexandre Julliard Aug. 7, 2007

Aug. 7, 2007

"Evan Stade" <estade(a)gmail.com> writes: > + bm_is_selected = (BOOL) hdc; That's ugly, you should use something like (hdc != 0) instead. > + stride = bmi.bmiHeader.biWidth * bitspp / 8; > + stride += stride % 4; This doesn't do what you want. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: #1 winhttp: Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
by Robert Shearman Aug. 6, 2007

Aug. 6, 2007

Hans Leidekker wrote: > Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet. > We shouldn't be implementing winhttp on top of wininet as there are functions such as WinHttpSetCredentials (http://msdn2.microsoft.com/en-us/library/Aa384112.aspx) that can't be implemented on top of wininet functions. There are also issues with different error codes being returned as well as different callbacks (http://msdn2.microsoft.com/en-us/library/aa383917.aspx) -- Rob Shearman

5 7

FW: [Bug 2520] menu bar problem
by Ann & Jason Edmeades Aug. 6, 2007

Aug. 6, 2007

>Vitaliy >Jason, please don't forget to cc wine-bugs when you reassign the bug. Yeah, sorry... Its late here :-) Out of interest, why don't we fix bugzilla to always enforce that userid (ie if it gets removed, it automatically gets inserted back). I'm sure I'm not the only one who forgets to do it sometimes? Jason

1 0

Re: [WINE] WIDL regression between 0.9.38 and 0.9.39
by Dan Hipschman Aug. 6, 2007

Aug. 6, 2007

On Mon, Aug 06, 2007 at 04:24:39PM +0200, Herv? Poussineau wrote: > Hi Dan, > > I'm using Wine IDL compiler to compile some .idl files, and I found a > regression in WIDL between 0.9.38 and 0.9.39. > As you are the one who mostly changed WIDL between these releases, I'm > sending you this email ;) > > My .idl file looks like this one: > > [ > uuid (00112233-4455-6677-8899-AABBCCDDEEFF), > version(1.0), > pointer_default(unique) > #ifndef __midl > ,explicit_handle > #endif > ] > interface MyInterface > { > unsigned long GetRoot(handle_t BindingHandle, > [out, string, size_is(Length)] wchar_t > *RootString, > [in] unsigned long Length); > } > > Of course, Microsoft MIDL accepts to compile this file, so WIDL should too. > WIDL 0.9.38 was working, but WIDL 0.9.39 gives the following error: > error: write_string_tfs: Unimplemented for type 0x1b of name: RootString > > Type 0x1b is RPC_FC_CARRAY, but write_string_tfs function only supports > RPC_FC_BYTE, RPC_FC_CHAR and RPC_FC_WCHAR. > > Any idea how to fix it, or am I forced to keep WIDL 0.9.38? > > Thanks in advance, > > Hervé Hi Hervé. Thanks for the bug report. The code related to this problem was being worked on quite a bit recently, so I don't doubt there may be a regression. I may be a bit slow to look at this since I'm in the middle of working on something else at the moment, hence I'm CC-ing the list so other people can see that the problem exists. Dan

1 0

Re: [PATCH] msi: correct buffer overrun in msi_get_deferred_action().
by James Hawkins Aug. 6, 2007

Aug. 6, 2007

On 8/5/07, William Waghorn <willw(a)litany.me.uk> wrote: > --- > dlls/msi/custom.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/msi/custom.c b/dlls/msi/custom.c > index 390113e..17f581c 100644 > --- a/dlls/msi/custom.c > +++ b/dlls/msi/custom.c > @@ -153,7 +153,7 @@ static LPWSTR msi_get_deferred_action(LPCWSTR > action, LPCWSTR actiondata, > return strdupW(action); > > len = lstrlenW(action) + lstrlenW(actiondata) + > - lstrlenW(usersid) + lstrlenW(prodcode) + 5; > + lstrlenW(usersid) + lstrlenW(prodcode) + 9; > deferred = msi_alloc(len * sizeof(WCHAR)); > > sprintfW(deferred, format, actiondata, usersid, prodcode, action); > This has been properly fixed in git. -- James Hawkins

1 0