Proposed goal for website: happily usable at 800x600?
What with netbooks with small screens abounding, it might make sense to review our web site and make sure its most important parts are usable in an 800x600 screen (easy to simulate, just resize your browser until xwininfo says it's 800x550, those gnome top and bottom bars chew 25 pixels each). That's asking a lot, I suppose... - Dan
Re: [sane.ds 1/3] Get resolution from sane, instead of hard coding -1.
I'm sorry; I failed to do a git-add options.c prior to this commit.
Please use this patch instead.
Cheers,
Jeremy
>From d0c4a185b93a8b3040f4b7ffc001fa3f8f7b0199 Mon Sep 17 00:00:00 2001
From: Jeremy White
Date: Thu, 12 Feb 2009 16:22:46 -0600
Subject: [PATCH] Get resolution from sane, instead of hard coding -1.
To: wine-patches
---
dlls/sane.ds/Makefile.in |3 +-
dlls/sane.ds/ds_image.c |7 -
dlls/sane.ds/options.c | 47 ++
dlls/sane.ds/sane_i.h|4 +++
4 files changed, 58 insertions(+), 3 deletions(-)
create mode 100644 dlls/sane.ds/options.c
diff --git a/dlls/sane.ds/Makefile.in b/dlls/sane.ds/Makefile.in
index d8646fe..245c42e 100644
--- a/dlls/sane.ds/Makefile.in
+++ b/dlls/sane.ds/Makefile.in
@@ -11,7 +11,8 @@ C_SRCS = \
ds_ctrl.c \
ds_image.c \
sane_main.c \
- ui.c
+ ui.c \
+ options.c
RC_SRCS = \
rsrc.rc
diff --git a/dlls/sane.ds/ds_image.c b/dlls/sane.ds/ds_image.c
index 9a88bb5..5bb6cbb 100644
--- a/dlls/sane.ds/ds_image.c
+++ b/dlls/sane.ds/ds_image.c
@@ -86,6 +86,7 @@ TW_UINT16 SANE_ImageInfoGet (pTW_IDENTITY pOrigin,
TW_UINT16 twRC = TWRC_SUCCESS;
pTW_IMAGEINFO pImageInfo = (pTW_IMAGEINFO) pData;
SANE_Status status;
+SANE_Int resolution;
TRACE("DG_IMAGE/DAT_IMAGEINFO/MSG_GET\n");
@@ -111,9 +112,11 @@ TW_UINT16 SANE_ImageInfoGet (pTW_IDENTITY pOrigin,
activeDS.sane_param_valid = TRUE;
}
-pImageInfo->XResolution.Whole = -1;
+if (sane_option_get_int(activeDS.deviceHandle, "resolution", &resolution) == SANE_STATUS_GOOD)
+pImageInfo->XResolution.Whole = pImageInfo->YResolution.Whole = resolution;
+else
+pImageInfo->XResolution.Whole = pImageInfo->YResolution.Whole = -1;
pImageInfo->XResolution.Frac = 0;
-pImageInfo->YResolution.Whole = -1;
pImageInfo->YResolution.Frac = 0;
pImageInfo->ImageWidth = activeDS.sane_param.pixels_per_line;
pImageInfo->ImageLength = activeDS.sane_param.lines;
diff --git a/dlls/sane.ds/options.c b/dlls/sane.ds/options.c
new file mode 100644
index 000..764b104
--- /dev/null
+++ b/dlls/sane.ds/options.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright 2009 Jeremy White for CodeWeavers
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
+ */
+
+#include "config.h"
+
+#include
+#include "twain.h"
+#include "sane_i.h"
+#include "wine/debug.h"
+
+WINE_DEFAULT_DEBUG_CHANNEL(twain);
+
+SANE_Status sane_option_get_int(SANE_Handle h, const char *option_name, SANE_Int *val)
+{
+SANE_Status rc;
+SANE_Int optcount;
+const SANE_Option_Descriptor *opt;
+int i;
+
+rc = psane_control_option(h, 0, SANE_ACTION_GET_VALUE, &optcount, NULL);
+if (rc != SANE_STATUS_GOOD)
+return rc;
+
+for (i = 1; i < optcount; i++)
+{
+opt = psane_get_option_descriptor(h, i);
+if (opt && (opt->name && strcmp(opt->name, option_name) == 0) &&
+ opt->type == SANE_TYPE_INT )
+return psane_control_option(h, i, SANE_ACTION_GET_VALUE, val, NULL);
+}
+return SANE_STATUS_EOF;
+}
diff --git a/dlls/sane.ds/sane_i.h b/dlls/sane.ds/sane_i.h
index 5a3a6d0..5938eef 100644
--- a/dlls/sane.ds/sane_i.h
+++ b/dlls/sane.ds/sane_i.h
@@ -211,4 +211,8 @@ TW_UINT16 SANE_RGBResponseSet
BOOL DoScannerUI(void);
HWND ScanningDialogBox(HWND dialog, LONG progress);
+/* Option functions */
+SANE_Status sane_option_get_int(SANE_Handle h, const char *option_name, SANE_Int *val);
+
+
#endif
--
1.5.6.3
Re: gdiplus: in GdipDrawString only NULL terminate if we have room in the buffer.
if we do this call with a string of "XX" and a length of 2.
then we create a 2 WCHAR buffer to store the string in.
then i == 0; j == 0 on the first look i++ and j++ so i == 1, j == 1
and length is 2.
then we loop again and i++ and j++ so i == 2, j == 2 and length == 2.
so then when we do the stringdup[j] = 0 we are writing one WCHAR off
the end of the buffer.
-aric
Nikolay Sivov wrote:
> Aric Stewart wrote:
>> ---
>> dlls/gdiplus/graphics.c |3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c
>> index 2673042..c276a43 100644
>> --- a/dlls/gdiplus/graphics.c
>> +++ b/dlls/gdiplus/graphics.c
>> @@ -1901,7 +1901,8 @@ GpStatus WINGDIPAPI GdipDrawString(GpGraphics
>> *graphics, GDIPCONST WCHAR *string
>> j++;
>> }
>>
>> -stringdup[j] = 0;
>> +if (j < length)
>> +stringdup[j] = 0;
>> length = j;
>>
>> while(sum < length){
>>
> Hm, maybe I don't follow something, but I think 'j < length' is always
> true after that:
> ---
> for(i = 0, j = 0; i < length; i++){
> if(!isprintW(string[i]) && (string[i] != '\n'))
> continue;
>
> stringdup[j] = string[i];
> j++;
> }
>
> stringdup[j] = 0;
> length = j;
> ---
> Or you thought about zero length case? It should be handled earlier, on
> stringdup allocation or before...
>
>
Re: [2/2] tools/winemaker.man.in: update man-page
André Hentschel wrote: > sorry, had the wrong mail-account last time. > updating the man-page of winemaker. > there were such old things, there was dust on it! > > > > No attachment here...
Re: gdiplus: in GdipDrawString only NULL terminate if we have room in the buffer.
Aric Stewart wrote:
> ---
> dlls/gdiplus/graphics.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c
> index 2673042..c276a43 100644
> --- a/dlls/gdiplus/graphics.c
> +++ b/dlls/gdiplus/graphics.c
> @@ -1901,7 +1901,8 @@ GpStatus WINGDIPAPI GdipDrawString(GpGraphics
> *graphics, GDIPCONST WCHAR *string
> j++;
> }
>
> -stringdup[j] = 0;
> +if (j < length)
> +stringdup[j] = 0;
> length = j;
>
> while(sum < length){
>
Hm, maybe I don't follow something, but I think 'j < length' is always
true after that:
---
for(i = 0, j = 0; i < length; i++){
if(!isprintW(string[i]) && (string[i] != '\n'))
continue;
stringdup[j] = string[i];
j++;
}
stringdup[j] = 0;
length = j;
---
Or you thought about zero length case? It should be handled earlier, on
stringdup allocation or before...
RE: wintrust(2/3): Remove a couple tests that fail on a variety of systems (try 2)
> From: Paul Vriens [mailto:paul.vriens.w...@gmail.com] > > Paul Vriens wrote: > > Juan Lang wrote: > >> This removes the unused variables in the last version. > >> --Juan > >> > >> > >> > - > >> --- > >> > >> > > I think that these failures are also because of "not enough rights" > > (people running winetest as a normal user). So just removing them is > > probably not the best approach? > > Maybe it's not that there are not enough rights. The common > denominator that I see is that all reports/boxes that produce > these failures seems to be coming from one person (Ge). Maybe > worthwhile checking with him before just removing the tests? All the failure cases on my machines are when running as non-Administrator. I've set up a number of boxes deliberately that way, but I'm starting to wonder if that is a good idea? For a whole bunch of tests (MSI comes to mind) the only sensible approach is to skip the test when running as non-Administrator, so it seems that I'm not actually adding new test runs in a different environment as I originally wanted to do. Gé.
Re: wintrust(2/3): Remove a couple tests that fail on a variety of systems (try 2)
2009/2/12 Paul Vriens : > Juan Lang wrote: I think that these failures are also because of "not enough rights" (people running winetest as a normal user). So just removing them is probably not the best approach? >>> Maybe it's not that there are not enough rights. The common denominator that >>> I see is that all reports/boxes that produce these failures seems to be >>> coming from one person (Ge). Maybe worthwhile checking with him before just >>> removing the tests? >> >> Perhaps. The last error didn't change in any of these tests, so I'm >> discinclined to believe it's a permissions issue. The only change was >> that on some systems the return value is FALSE, whereas on others it's >> TRUE. I don't think a test that says ok(ret == TRUE || ret == FALSE) >> is worth much, so I removed it. >> >> In general, I treat this Windows boxes as oracles: if they behave a >> certain way, then by definition that's allowed behavior. The only >> exception is when the behavior differs and is clearly broken on older >> machines. Since in this case, the failures are on relatively new >> machines as well, the tests appear to be flawed. >> >> Of course, if it's a misconfiguration, I'll reconsider. >> --Juan >> > What we maybe need in the header of the report is more information: > > - The locale > - The screen dimensions > - Do we have admin rights +1 - DPI setting - Installed theme (if any) - system metrics (font name & size, etc) -- this would be useful for those tests - installed versions of system components -- MSI; IE; .NET -- I know that these could probably be implied from DLL versions, but it can be difficult to find out what version of a DLL corresponds to IE6SP1 or whatever - Reece
Re: wintrust(2/3): Remove a couple tests that fail on a variety of systems (try 2)
Juan Lang wrote: >> What we maybe need in the header of the report is more information: >> >> - The locale >> - The screen dimensions >> - Do we have admin rights >> >> (just brainstorming here). >> >> That would make it easier to decide if it's a misconfiguration or a real >> acceptable configuration. > > Maybe you're right. To that list I'd add the video driver, as the > DirectX folks appear to have black-balled most video cards. > --Juan > Well all cards are fine as long as it's a NVIDIA :) -- Cheers, Paul.
Re: wintrust(2/3): Remove a couple tests that fail on a variety of systems (try 2)
> What we maybe need in the header of the report is more information: > > - The locale > - The screen dimensions > - Do we have admin rights > > (just brainstorming here). > > That would make it easier to decide if it's a misconfiguration or a real > acceptable configuration. Maybe you're right. To that list I'd add the video driver, as the DirectX folks appear to have black-balled most video cards. --Juan
Re: wintrust(2/3): Remove a couple tests that fail on a variety of systems (try 2)
Juan Lang wrote: >>> I think that these failures are also because of "not enough rights" >>> (people running winetest as a normal user). So just removing them is >>> probably not the best approach? >>> >> Maybe it's not that there are not enough rights. The common denominator that >> I see is that all reports/boxes that produce these failures seems to be >> coming from one person (Ge). Maybe worthwhile checking with him before just >> removing the tests? > > Perhaps. The last error didn't change in any of these tests, so I'm > discinclined to believe it's a permissions issue. The only change was > that on some systems the return value is FALSE, whereas on others it's > TRUE. I don't think a test that says ok(ret == TRUE || ret == FALSE) > is worth much, so I removed it. > > In general, I treat this Windows boxes as oracles: if they behave a > certain way, then by definition that's allowed behavior. The only > exception is when the behavior differs and is clearly broken on older > machines. Since in this case, the failures are on relatively new > machines as well, the tests appear to be flawed. > > Of course, if it's a misconfiguration, I'll reconsider. > --Juan > What we maybe need in the header of the report is more information: - The locale - The screen dimensions - Do we have admin rights (just brainstorming here). That would make it easier to decide if it's a misconfiguration or a real acceptable configuration. -- Cheers, Paul.
Re: wintrust(2/3): Remove a couple tests that fail on a variety of systems (try 2)
>> I think that these failures are also because of "not enough rights" >> (people running winetest as a normal user). So just removing them is >> probably not the best approach? >> > Maybe it's not that there are not enough rights. The common denominator that > I see is that all reports/boxes that produce these failures seems to be > coming from one person (Ge). Maybe worthwhile checking with him before just > removing the tests? Perhaps. The last error didn't change in any of these tests, so I'm discinclined to believe it's a permissions issue. The only change was that on some systems the return value is FALSE, whereas on others it's TRUE. I don't think a test that says ok(ret == TRUE || ret == FALSE) is worth much, so I removed it. In general, I treat this Windows boxes as oracles: if they behave a certain way, then by definition that's allowed behavior. The only exception is when the behavior differs and is clearly broken on older machines. Since in this case, the failures are on relatively new machines as well, the tests appear to be flawed. Of course, if it's a misconfiguration, I'll reconsider. --Juan
Re: wintrust(3/3): Fix a couple tests on a variety of systems
Juan Lang wrote: > Hi Paul, > >> This is of course on boxes where people dont' run winetest as a >> administrator. I'm not sure if ERROR_ACCESS_DENIED is thus actually an >> acceptable failure. In other tests we have used skip() for this. > > Of course that's the reason, but not running as administrator is an > acceptable configuration, is it not? I use skip() where subsequent > tests will fail as a result of an early failure, but that wasn't the > case here. > --Juan > I guess the main problem lies in the fact that we as Wine are now also accepting ERROR_ACCESS_DENIED and we won't be noticed of this fact. A skip (which is most of the time valid) at least shows us something. -- Cheers, Paul.
Re: wintrust(3/3): Fix a couple tests on a variety of systems
Hi Paul, > This is of course on boxes where people dont' run winetest as a > administrator. I'm not sure if ERROR_ACCESS_DENIED is thus actually an > acceptable failure. In other tests we have used skip() for this. Of course that's the reason, but not running as administrator is an acceptable configuration, is it not? I use skip() where subsequent tests will fail as a result of an early failure, but that wasn't the case here. --Juan
Re: wintrust(2/3): Remove a couple tests that fail on a variety of systems (try 2)
Paul Vriens wrote: > Juan Lang wrote: >> This removes the unused variables in the last version. >> --Juan >> >> >> >> >> > I think that these failures are also because of "not enough rights" > (people running winetest as a normal user). So just removing them is > probably not the best approach? > Maybe it's not that there are not enough rights. The common denominator that I see is that all reports/boxes that produce these failures seems to be coming from one person (Ge). Maybe worthwhile checking with him before just removing the tests? -- Cheers, Paul.
Re: wintrust(2/3): Remove a couple tests that fail on a variety of systems (try 2)
Juan Lang wrote: > This removes the unused variables in the last version. > --Juan > > > > > I think that these failures are also because of "not enough rights" (people running winetest as a normal user). So just removing them is probably not the best approach? -- Cheers, Paul.
Re: mshtml: Implement IHTMLStyle get/put minHeight (resend)
Hi Alistair, Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Implement IHTMLStyle get/put minHeight > [get|set]_nsstyle_attr_var functions were introduces to avoid the code duplication like you do. You should use them (and probably implement VT_I4 handling in set_nsstyle_attr_var). Jacek
Re: Is the test.winehq.org front page too pessimistic?
John Klehm wrote: > On Thu, Feb 12, 2009 at 8:27 AM, Paul Vriens > wrote: >> I do it for my own boxes (see attachment). The spikes (up and down) are >> mainly >> when I didn't run the tests on all my boxes. But you can see the overall >> trend. >> > > Nice. :) What are you using to generate that? > > --John Klehm > Google Chart API : http://code.google.com/apis/chart/ -- Cheers, Paul.
Re: Is the test.winehq.org front page too pessimistic?
On Thu, Feb 12, 2009 at 8:27 AM, Paul Vriens wrote: > I do it for my own boxes (see attachment). The spikes (up and down) are > mainly > when I didn't run the tests on all my boxes. But you can see the overall > trend. > Nice. :) What are you using to generate that? --John Klehm
Re: mshtml: Implement IHTMLStyle_put_textDecorationUnderline (resend)
Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Implement IHTMLStyle_put_textDecorationUnderline + +return set_style_attr(This, STYLEID_TEXT_DECORATION, v == VARIANT_TRUE ? valUnderline : emptyW, 0); You shouldn't compare v to VARIANT_TRUE. The correct way to deal with bool values is 'v ? valUnderline : emptyW'. Jacek
Re: ntdll: Avoid Potential Infinite Loop
On Thu, Feb 12, 2009 at 2:30 AM, Paul Bryan Roberts
wrote:
> Something like "We think your product is superlative but someone may
> wonder if your code not finding this bug in our code might be a bug in your
> code."
>
Well I don't think coverity claims 100% of bugs will be found. :)
>
> SERVER_START_REQ( get_token_groups )
> {
> TOKEN_GROUPS *groups = tokeninfo;
>
> +
> req->handle = wine_server_obj_handle( token );
>
Unneeded whitespace change.
Regards,
--John Klehm
Re: Is the test.winehq.org front page too pessimistic?
John Klehm wrote: On Wed, Feb 11, 2009 at 3:58 PM, Juan Lang wrote: My own feeling is that there are far fewer failing tests now than there used to be, and I'd sure like to see that reflected somewhere at a quick glance. Thoughts? Maybe a test.winehq.org/trends page showing some nice (hopefully upwards) trend graphs of number of succeeding tests? --John Klehm I do it for my own boxes (see attachment). The spikes (up and down) are mainly when I didn't run the tests on all my boxes. But you can see the overall trend. -- Cheers, Paul. <>
Fwd: Need Your Help about "dll" on linux
-- Forwarded message -- From: Jigar Joshi Date: Mon, Feb 9, 2009 at 6:53 PM Subject: Need Your Help about "dll" on linux To: wine-devel@winehq.org Respected sir, i refered your post at http://www.winehq.org/pipermail/wine-devel/2007-April/055855.html i want to know have you completed successfully that project? (using dll on linux) please reply soon . actually i have dlls derived from c , i dont have c code and i need to use those dlls on linus using java (JNI), first i tried to convert dll to ".so" bt i couldn't. . . read your post and got some moral support please reply soon . . . Regards Jigar
Re: gdi32/tests: Use the ANSI text metrics so the tests work on win9x.
On Thu, Feb 12, 2009 at 01:40:54PM +0100, Paul Vriens wrote: > Huw Davies wrote: >> --- >> dlls/gdi32/tests/font.c | 20 ++-- >> 1 files changed, 10 insertions(+), 10 deletions(-) >> >> >> >> >> > Looks a lot like: > > http://www.winehq.org/pipermail/wine-patches/2009-February/069297.html > > Maybe we should use yours as it has less changes to the code. Doh, I just saw that patch after I sent mine! Huw.
Re: gdi32/tests: Use the ANSI text metrics so the tests work on win9x.
Huw Davies wrote: > --- > dlls/gdi32/tests/font.c | 20 ++-- > 1 files changed, 10 insertions(+), 10 deletions(-) > > > > > Looks a lot like: http://www.winehq.org/pipermail/wine-patches/2009-February/069297.html Maybe we should use yours as it has less changes to the code. -- Cheers, Paul.
Re: Download page requires too much scrolling...
Dan Kegel wrote: > While I was generating screenshots for my presentation, > I noticed that http://www.winehq.org/download/ has too > much clutter at the top. I don't mind the Codeweavers > ad, but it's not good that users have to scroll down > to see the useful part of the page... > > Good point, I've submitted a patch to remove some clutter. We don't actually need to tell people in text that they're getting some files from sourceforge, for instance. Thanks, Scott Ritchie
Re: Wine64 : Trying to load PE image for unsupported architecture (I386)
2009/2/12 Joel Holdsworth : > On Wed, 2009-02-11 at 23:34 +0100, Alexandre Julliard wrote: >> Not really, you'll of course still need to build a full 32-bit version >> of Wine, the 64-bit Wine will never be able to run 32-bit apps. What >> needs to be improved is that the 64-bit loader should be able to forward >> automatically to the 32-bit one when encountering a 32-bit app. > > So there's no plans for implementing a clone of WoW64? > I would imagine that the end goal is to implement a side-by-side 64bit and 32bit wine, with some sort of wrapper to send the app to the appropriate version. From what I understand, this is what a WoW64 clone would look like anyway. See David's comment: 2009/2/12 David Gerard : > 2009/2/11 Erik de Castro Lopo : > >> I realise that the Win64 stuff is experimental but I'm curions, in >> the longer term is it expected that one executable will be able to >> run both Win32 and Win64 executables? > > Not yet. You're welcome to write it though ;-)
Re: Wine64 : Trying to load PE image for unsupported architecture (I386)
Erik de Castro Lopo writes: > So there will need to be two executables wine and wine64 and if either is > started with the wrong kind of binary, it will need to run the binary with > the other version? > > Would it not be possible to have a single light weight binary that has just > enough code to detect i386 vs amd64 and then execs either wine32 or wine64? sure, that would be possible. I don't know yet how it will be done, but that's a minor implementation detail. -- Alexandre Julliard julli...@winehq.org
Re: Wine64 : Trying to load PE image for unsupported architecture (I386)
On Wed, 2009-02-11 at 23:34 +0100, Alexandre Julliard wrote: > Not really, you'll of course still need to build a full 32-bit version > of Wine, the 64-bit Wine will never be able to run 32-bit apps. What > needs to be improved is that the 64-bit loader should be able to forward > automatically to the 32-bit one when encountering a 32-bit app. So there's no plans for implementing a clone of WoW64? smime.p7s Description: S/MIME cryptographic signature
ntdll: Avoid Potential Infinite Loop
Hi,
I expect this patch will be accepted due to precedent - a few months ago
I submitted the same patch for the same problem in a different routine
in a different compilation unit of ntdll.
Yes, I guess the infinite loop does not occur in practice (someone would
have noticed) and I guess it has been there a very long time. But it
isn't exactly hard to spot - I was speed reading the code looking for
something else.
I've seen a lot of chatter recently about something called Coverity. I
looked it up on Wikipedia (after checking the spelling). Apart from
it's obvious use as a conversation piece, is it proving useful to the
project ?
Is there a feedback policy ?
Something like "We think your product is superlative but someone
may wonder if your code not finding this bug in our code might be a bug
in your code."
Security :); false sense of security :(
Paul Bryan Roberts
>From dd2f31b0176e795edf5b1eb081410de7ed5ed03d Mon Sep 17 00:00:00 2001
From: Paul Bryan Roberts
Date: Thu, 12 Feb 2009 08:09:17 +
Subject: ntdll: avoid potential infinite loop
---
dlls/ntdll/nt.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/dlls/ntdll/nt.c b/dlls/ntdll/nt.c
index 879a324..dc81648 100644
--- a/dlls/ntdll/nt.c
+++ b/dlls/ntdll/nt.c
@@ -293,17 +293,20 @@ NTSTATUS WINAPI NtQueryInformationToken(
char stack_buffer[256];
unsigned int server_buf_len = sizeof(stack_buffer);
void *buffer = stack_buffer;
-BOOLEAN need_more_memory = FALSE;
+BOOLEAN need_more_memory;
/* we cannot work out the size of the server buffer required for the
* input size, since there are two factors affecting how much can be
* stored in the buffer - number of groups and lengths of sids */
do
{
+need_more_memory = FALSE;
+
SERVER_START_REQ( get_token_groups )
{
TOKEN_GROUPS *groups = tokeninfo;
+
req->handle = wine_server_obj_handle( token );
wine_server_set_reply( req, buffer, server_buf_len );
status = wine_server_call( req );
--
1.5.4.3
