box is not on test.winehq.org, but as the broken tests are not
run by the currently provided binaries (because of the also broken win9x
checks), it wouldn't help.
Regards,
Michael Karcher
Am Montag, den 25.01.2010, 10:47 +0100 schrieb Paul Vriens:
> On 01/25/2010 09:37 AM, Michael Karcher wrote:
> > Am Montag, den 25.01.2010, 15:27 +0800 schrieb Dmitry Timoshkov:
> >>> The current code misdetects both Windows XP and Wine as Win9x and skips
> >>
always bisect to the enabling patch, and I used to think that
interim versions that fail tests are frowned upon.
Thank you for looking at the patch nevertheless,
Michael Karcher
These tests should added to existing dlls/ntdll/tests/exception.c
> framework.
You are right, I will resubmit the series. I was just grepping for
"__TRY" in the tests to find a source file to add to, so I didn't find
that stuff because it sets up the handler manually.
Regards,
Michael Karcher
Am Montag, den 27.07.2009, 13:24 +0900 schrieb Dmitry Timoshkov:
> "Michael Karcher" wrote:
> > The meaning of "enable" is the same in Windows and Wine: it enables the
> > execute permission, not the data execution prevention.
> JFYI, I based my origin
Am Donnerstag, den 02.07.2009, 09:02 +0200 schrieb Paul Vriens:
> There is no need for the RegCloseKey as you are opening a predefined one.
Are you sure? He opens "HKCU\Software\Microsoft\Windows\CurrentVersion
\Applets\Regedit"
Regards,
Michael Karcher
signature.asc
Description:
HKCU\Software\Microsoft\Windows
\CurrentVersion\Applets\Regedit.
Regards,
Michael Karcher
No, I don't really care. I just fixed that bug and your statement:
"Color on monochrome bitmap is seldomly used anyway" sounded an alarming
bell in my head. This mail was just a warning to not disregard the issue
and no specific problem report.
Regards,
Michael Karcher
palettes. I guess not ever
> Microsoft knows what they did on this respect :-)
Be careful with such statements. Look at bug 6519 for example.
Regards,
Michael Karcher
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
zip was one of them. Microsoft never broke this behaviour.
And even if Wine would decide this behaviour to be a bug, we want it to
be in Wine as Wine should be bug-to-bug compatible.
Regards,
Michael Karcher
e argument
list of an ok() statement. ok()/trace() first sets a global variable to
the current location, and then calls a printing function passing and
evaluating the parameters. If one of them changes the global variable
already set, the location printed is wrong, as you see here.
Regards,
Michael Karcher
he I/O buffer for special files (/dev/..) to be
> > aligned on 512 byte boundary to get the correct data. #4/10 corrects
> > that problem for both reading and writing.
> That's really ugly.
That's only the case if the device has been opened with O_DIRECT. For
buffered read/write, no alignment is needed.
Regards,
Michael Karcher
ot able to compile x86 16-bit code, it's
just as that can translate 16 bit assembler code.
Regards,
Michael Karcher
i.e. previously the fake
italic transformation was just ignored, so roman characters were
displayed, now WineEngGetGlyphOutline runs into this error case,
breaking applications trying to use "MS Sans Serif" in italic.
Regards,
Michael Karcher
Am Dienstag, den 17.02.2009, 09:19 +0100 schrieb Michael Karcher:
> Should fix bug #17050
Doesn't do. Please ignore.
GPL.
No, it is not. You may charge as much as you want for binaries of GPL
programs. You just have to allow your clients to pass it on for free.
> From memory, GPL allows you to charge for the cost of delivering the
> software (e.g. CD media, postage), but not the binaries themselves.
This just applies to the source code.
Regards,
Michael Karcher
ead at that point. Just as a hint how to
attack such beasts, if you encounter things like that again.
Regards,
Michael Karcher
pointer at all.
I will try to use all your helpful suggestions to submit a better series
tomorrow (and to the right address, of course!)
Regards,
Michael Karcher
Am Samstag, den 10.01.2009, 22:41 + schrieb Rob Shearman:
> 2009/1/10 Michael Karcher :
> > If we take MIDL 6.00.0366 as reference, the following method type is
> > legal:
> >
> >void frobnicate([size_is(x),in,out] int * bar1,
> >
Am Samstag, den 10.01.2009, 22:32 + schrieb Rob Shearman:
> 2009/1/10 Michael Karcher :
> > get_deref_type yields the type of array elements for arrays or the
> > pointed-to type of pointers. Most important, it works on anything
> > is_declptr returns true for.
> I don&
Am Samstag, den 10.01.2009, 22:21 + schrieb Reece Dunn:
> 2009/1/10 Michael Karcher :
> > Output NULL pointers into proxy table and STUB_FORWARDING_FUNCTION into
> > stub tables if a local function has no call_as function associated, just
> > as MIDL does.
> Shouldn&#x
---
tools/widl/proxy.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/tools/widl/proxy.c b/tools/widl/proxy.c
index 4e69190..bb16b72 100644
--- a/tools/widl/proxy.c
+++ b/tools/widl/proxy.c
@@ -182,6 +182,11 @@ int cant_be_null(const var_t *v)
if (is_ptr(type))
---
tools/widl/typegen.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/widl/typegen.c b/tools/widl/typegen.c
index 2b0e414..7dfa0b2 100644
--- a/tools/widl/typegen.c
+++ b/tools/widl/typegen.c
@@ -3046,7 +3046,7 @@ static void write_parameter_conf_or_var_exprs(FIL
get_deref_type yields the type of array elements for arrays or the
pointed-to type of pointers. Most important, it works on anything
is_declptr returns true for.
---
tools/widl/header.h |1 +
tools/widl/typegen.c| 15 +++
tools/widl/write_msft.c |3 +--
3 files change
If we take MIDL 6.00.0366 as reference, the following method type is
legal:
void frobnicate([size_is(x),in,out] int * bar1,
[size_is(*bar1),out] int * bar2,
[in] int x);
Without this patch, size_is(*bar1) would be rejected.
---
tools/widl/e
---
tools/widl/header.c | 24
tools/widl/header.h |2 ++
tools/widl/typegen.c | 24
tools/widl/typegen.h |1 -
4 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/tools/widl/header.c b/tools/widl/header.c
index a3d2250..d
This matches midl behaviour. In
void test1([out,size_is(x)] char str[], [in] int x);
void test2([size_is(x), out] char* str, [in] int x);
the parameter to test1 is not NULL-checked, but the one to test2 is.
---
tools/widl/client.c|2 +-
tools/widl/proxy.c | 15 ++-
typdef [wire_marshal(wirefoo)] foo * pfoo;
made widl incorrectly set the RPC_FC_P_DEREF bit for pfoo. But this
declares a user-marshalled pointer, so the RPC runtime must not dereference
it before passing it on to the UserFoo functions.
---
tools/widl/header.h |3 ++-
1 files changed, 2 insert
Output NULL pointers into proxy table and STUB_FORWARDING_FUNCTION into
stub tables if a local function has no call_as function associated, just
as MIDL does.
try 2: Fix various mistakes (one of them found by Rob Shearman)
try 3: Rebased to current git
---
tools/widl/proxy.c | 51 ++
ET, NET_RT_FLAGS, RTF_LLINFO};
should do. (Even better: Put this define to the top of the file [but
still #if-protected], and just use RTF_LLINFO later on)
Regards,
Michael Karcher
> Michael, do you plan to rebase and resend these? If not, I can do
> this.
They got in:
http://source.winehq.org/git/wine.git?a=commit;h=656de48e4ea5f15b5ecc58923e3a0e2f0c3fae90
http://source.winehq.org/git/wine.git?a=commit;h=5f7886925db80cfe93aea89b4b3d604ab62e1cc8
Regards,
Michael Karcher
; > long" gets encoded as FC_LONG, "unsigned short" as FC_SHORT and "unsigned
> > small" as FC_SMALL.
> >
> > Like I said, I'm no IDL expert. Does the stuff above make sense to you? Do
> > you think it would be a good idea to change WIDL
;
> Gcc wont complain and the code is as before?
what about
(void)write(*(This->fd), &event, sizeof(event));
Does that work to? Seems nicer than the if.
Regards,
Michael Karcher
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Am Sonntag, den 04.01.2009, 00:30 + schrieb Rob Shearman:
> 2009/1/3 Michael Karcher :
> > @@ -548,8 +548,9 @@ static int write_proxy_methods(type_t *iface, int skip)
> >if (iface->funcs) LIST_FOR_EACH_ENTRY( cur, iface->funcs, const func_t,
> > entry ) {
>
hat widl doesn't handle this too well...
Seems so. I don't want to hurt anyone, but I somehow get the impression
that the quality of widl is somewhere around works-for-me.
Regards,
Michael Karcher
Am Donnerstag, den 01.01.2009, 11:22 +0100 schrieb Michael Karcher:
> The old behaviour was to emit a half-complete C statement without
> any error message.
This patch is bad. Please ignore.
Regards,
Michael Karcher
Am Donnerstag, den 01.01.2009, 19:09 + schrieb Rob Shearman:
> 2009/1/1 Michael Karcher :
> > +[call_as(AddPropertySheetPages)]
> > +HRESULT RemoteAddPropertySheetPages();
[...]
> > +[call_as(SendControlMsg)]
> > +HRESULT RemoteSendControlMsg();
&g
Am Donnerstag, den 01.01.2009, 18:53 + schrieb Rob Shearman:
> 2009/1/1 Michael Karcher :
> > diff --git a/include/oaidl.idl b/include/oaidl.idl
> > index 1cc166a..4ee3b43 100644
> > --- a/include/oaidl.idl
> > +++ b/include/oaidl.idl
> > @@ -1620,9 +1620,9 @@
Am Donnerstag, den 01.01.2009, 18:58 + schrieb Rob Shearman:
> 2009/1/1 Michael Karcher :
> > + hr = IPropertyBag_RemoteRead_Proxy(This, pszPropName, &outVariant,
> > pErrorLog,
> > + V_VT(pVar), pUnk);
> > + if(SUCCEEDED
/widl I'm currently attacking.
Regards,
Michael Karcher
Am Freitag, den 26.12.2008, 17:20 + schrieb Rob Shearman:
> 2008/12/21 Michael Karcher :
> > This makes widl generate null pointer checks for HWND parameters, as
> > HXXX is a void pointer without the unique attribute. My question is:
> > Should widl really add this
patching into the testcase (i.e. copy a good tlb,
patch it, and perform some tests with the copy, than delete it)
Which approach would have the highest chance of getting the fix
(including the testcase that tests broken type libraries) included into
Wine?
Regards,
Michael Karcher
checks for handles, or is widl to be fixed instead?
Best regards and thanks for advice,
Michael Karcher
sitory, make_makefiles only considers Makefile.in files already
added to the git index, so call git-add before make_makefiles. If you
don't use git, make_makefiles scans all directories for Makefile.in to
find about buildable directories.
> Thank you,
> Jörg Höhle
You're welcome,
Michael Karcher
*horribly*[1] if foo is not an array, but a
pointer. If foo denotes an array, sizeof foo returns the size of the
whole array, which is the size per element multiplied by the number of
elements. The size of a single element is calculated by
sizeof(foo[anything]), anything being zero by convention
what problems you are trying to solve.
Regards,
Michael Karcher
er way around) to lines that do not get other changes
are generally frowned upon and usually reject, so don't feel requested
to fix the tab-n-space mix in the test list as well. Just choose one of
the correct variants, that is 8 spaces or one tab.
Regards,
Michael Karcher
msstyles.c to find a precedence case in the
file you are patching. In short, that would mean
+if(MSSTYLES_GetNextInteger(...) &&
+MSSTYLES_GetNextInteger(...) &&
+MSSTYLES_GetNextInteger(...))
+{
Regards,
Michael Karcher
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Am Samstag, den 29.11.2008, 10:52 +0100 schrieb Michael Karcher:
> This makes the xmlnode structures kind-of aggregatable COM objects.
> The explanation of the new reference management is in the rather verbose
> comment at the top of the new node_unk.c file.
For reference, the comment e
hat they did to my
> > desktop!
> heh, I didn't include the tip but if you want it here it is:
> chmod a+x .git/hooks/pre-commit
Great! I didn't know about that. Can we put this somewhere in one of the
Wine development hint pages?
Regards,
Michael Karcher
signature.asc
Desc
;HEAD" for it. HEAD always means the version
you are currently working on. If you do a git-commit, git-pull or other
things like that, the target of the alias HEAD is automatically
adjusted.
Regards,
Michael Karcher
ch you
C file. This is true for the "MSVCRT_wtmpnam" part of the same line.
Regards,
Michael Karcher
CCESS is just zero. To prevent just this possible mistake, a
patch making the condition obvious was requested.
Regards,
Michael Karcher
Am Dienstag, den 18.11.2008, 08:51 -0800 schrieb Jeremy Drake:
> On Tue, 18 Nov 2008, Michael Karcher wrote:
>
> > Looks OK to me, but what happened to your finding about
> > INET_E_RESOURCE_NOT_FOUND? Was it a red herring?
> I saw that on XP, but I couldn't reproduce i
ls, we know that
VariantChangeType is not the way to go.
> I would provide details
> about how to deal with the VARIANT, but it may be misinterpreted as
> knowledge gained from the disassembler. So I'll just leave you with a
> couple of links to MS docs.
If you tell me whether VariantChangeType should be used here or not, it
*is* knowledge gained from the disassembler, so it is exactly right you
don't tell me that. Write good testcases instead that make me infer how
to implement it. Thanks for the pointers to MSDN. I didn't know about
the VT_ERROR/DISP_E_PARAMNOTFOUND case yet.
Regards,
Michael Karcher
.dll.so
is linked with anyway? That would do away with the need to know the
soname during compilation. As it is hardcoded into the executable during
link, hard-coding the soname doesn't hurt that much too, but still it
gets simpler
Regards,
Michael Karcher
ading it carefully is in the same situation as you and
shouldn't implement the function.
Testcases on the other hand are fine. They just describe *what* to do,
but not *how*. Especially for the error case testcases might be
interesting.
> > Is there anyone out there who
> > would volunteer to do it if I were to write a description of the
> > function?
I would do so, if its just some minutes.
Regards,
Michael Karcher
outside wine's).
> Would it be better ?
No you should go into the opposite direction. CUPS should provide you
with an PPD file telling you what postscript fragment has to be included
into the job to select the right page size. Also the correct DSC comment
"%%PaperSize" might help.
Regards,
Michael Karcher
them. These tests should get
expunged and replaced by different implementation chosen by the vtable
of the IXMLDOMFoo imlementing objects.
Thanks for your input,
Michael Karcher
L))
Any reason you don't use E_UNEXPECTED instead of the numerical constant?
Regards,
MIchael Karcher
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
if (broken(hr == 0x8000 || hr == E_FAIL))
Any reason you don't use E_UNEXPECTED instead of the numerical constant?
Regards,
MIchael Karcher
Am Freitag, den 17.10.2008, 00:46 +0200 schrieb Michael Karcher:
> If libxml2 is new enough, it is possible to parse directly from the
> stream using xmlReadIO to avoid copying the whole stream contents to
> memory.
Testing native, it looks like this is the right approach. Piotr Caban
One really has to ask Alexandre, or
ask on wine-devel for feedback. Something like "Obviously, patch did not get applied even after resending. Does anybody see
anything obviously wrong with it?". As a guide to non-native speakers on
#winehackers: Just ask (when julliard is online and not marked as ways)
"julliard: What is wrong with ". Copy'n'paste all
responses (recognizable by being from Alexandre or starting with your
nickname) and try to make sense of them later.
Regards,
Michael Karcher
g
vm86 (that is most notably x64), full-blown CPU emulation (either
interpreting or a JIT compiler) is used instead. 32 bit protected mode
programs can run natively on x86 and x64, but emulation is also
available as an option in protected mode.
Regards,
Michael Karcher (who already fixed some b
a test did not get committed and you
resubmit it, please add a note on which Windows version you tested it,
if you didn't include it in your first try. General hint: If you can't
test on windows for some reason (like you propose a direct3d test that
needs a graphics card you don't own), do not send the testcase to
wine-patches, but to wine-devel, and explain briefly why you can't test,
and ask other developers to test it for you. This is usually not a
problem.
Regards,
Michael Karcher
uot;\" -> "'\''") or to replace them (for example by
'_').
Regards,
Michael Karcher
e types called AC_CREATE_STDINT_H
or AX_CREATE_STDINT_H to create "wine/stdint.h" (which will create a
one-liner including on systems where it is available)?
Regards,
Michael Karcher
.
Thanks in advance for any feedback,
Michael Karcher
diff --git a/dlls/msxml3/domdoc.c b/dlls/msxml3/domdoc.c
index 8ef0db4..969e25e 100644
--- a/dlls/msxml3/domdoc.c
+++ b/dlls/msxml3/domdoc.c
@@ -234,6 +234,29 @@ static inline domdoc *impl_from_IObjectSafety(IObjectSafety *iface)
return
ment and the document element.
Regards,
Michael Karcher
oot. Placeing
the element itself on the orphan list causes it to be freed when freeing
the orphans and a second time (some lines later) when the document
element is freed.
So, I doubt this patch is correct.
Regards,
Michael Karcher
conditional statement
might be written as
return (hr == S_OK ? E_FAIL : hr);
Regards,
Michael Karcher
tests succeeded, and
the visual test got started. This test crashed (and would do that on
your system also before your patches, as it is completely unrelated).
> Now shouldn't the test run the same reguardless of the stack limit?
Not necessarily. The problem is that the ATI driver behaves differently
with different stack limits, and the Wine developers have to decide
whether they accept both behaviours as OK.
Regards,
Michael Karcher
DRM causes CreateSurface to fail you are
right that the testcase should handle that.
Regards,
Michael Karcher
Am Dienstag, den 14.10.2008, 13:34 -0700 schrieb chris ahrendt:
> Yes if we need to move this off list please let me know
>
> Michael Karcher wrote:
> > That's why I suggested you to introduce the err2 label. The end of the
> > function should look like this:
>
ble
> > here. Your return statement leaks palette.
> Yes I saw that.. which is why it did not make much sense...
Sorry, I don't understand *what* did not make much sense. Could you try
to be a bit clearer in your messages?
> if you want
> I can recreate and show you the exception which occurs when I don't have
> the return or the dsurface error I mentioned above.
That would be interesting. But it is enough if you can quote the values
of hr and lpSurf in the error case (put them in the skip message!). If
you really do get a hr value indicating an error (highest bit set) and
lpSurf is not NULL, some action is required, but up to you showing the
output, I keep very sceptical that this happens on any real-world
system. If you post the output of a modified test (as I suggested),
*please* also post the code you used to generate that output.
Regards,
Michael Karcher
nterface is stored) is not NULL. This
is *always* the case, as the variable "dsurface" is allocated on the
stack and &dsurface is thus pointing into the stack. The check
if(dsurface) checks whether the contents of the variable dsurface, which
should point to the DirectDrawSurface interface, is a NULL value
pointing nowhere instead, which is exactly what we need here.
Regards,
Michael Karcher
LT hr;
| LPDIRECTDRAWSURFACE lpSurf = NULL;
| DDSURFACEDESC ddsd;
| IDirectDrawPalette *palette = NULL;
As they are initialized to NULL, the condition of the if statement is
false if these variables were not yet initialized. So no crash possible
here. Your return statement leaks palette.
Regards,
Michael Karcher
ost notably, packed 24 bpp true color (D3DFMT_R8G8B8) support
is missing, as most modern cards use 32 bpp true color
(D3DFMT_X8R8G8B8). I would expect NULLREF to fail on a system with
d3dref9.dll available but a 24 bpp framebuffer.
Regards,
Michael Karcher
d about the
> missing members through experimentation after that.
Use this URL instead:
http://web.archive.org/web/20061224095348/http://blogs.msdn.com/oldnewthing/archive/2005/04/29/412577.aspx
Regards,
Michael Karcher
Am Freitag, den 10.10.2008, 14:26 +0100 schrieb Rob Shearman:
> 2008/10/8 Michael Karcher <[EMAIL PROTECTED]>:
> > In http://www.winehq.org/pipermail/wine-patches/2008-June/056508.html
> > Peter Urbanec sent a patch I like, that adds timing information to the
> > lo
o the From line. He did never submit
in that form. I would be happy about any advice.
The indentation-fixed patch is included, although the first two lines
are munged to prevent the patch to get away with the "forged"
attribution.
Regards,
Michael Ka
Am Samstag, den 04.10.2008, 20:44 +0200 schrieb Michael Karcher:
> Hello Huw Davies,
>
> it looks like test_removeChild (introduced by you in commit 187ab1c0)
> contains a typo.
Ugh. Please disregard the previous mail. The test after "fixing" the
typo does *not* succeed
Am Samstag, den 04.10.2008, 21:00 +0200 schrieb Michael Karcher:
> > it looks like test_removeChild (introduced by you in commit 187ab1c0)
> > contains a typo.
> Ugh. Please disregard the previous mail. The test after "fixing" the
> typo does *not* succeed in WinXP, on
[resend, as I used a non-subscribed From: in the first try]
Am Samstag, den 04.10.2008, 20:44 +0200 schrieb Michael Karcher:
> Hello Huw Davies,
>
> it looks like test_removeChild (introduced by you in commit 187ab1c0)
> contains a typo.
Ugh. Please disregard the previous mail. Th
Hello Huw Davies,
it looks like test_removeChild (introduced by you in commit 187ab1c0)
contains a typo. The test passes both ways, but from the code flow I
suspect that node_list2 was obtained for a reason, namely using it.
Regards,
Michael Karcher
This patch fixes the type, if it turn out
this case:
http://www.winehq.org/pipermail/wine-patches/2008-September/061760.html
In that patch, you are definitely missing the prototype for
MsiSetExternalUIRecord in msi.h. I didn't notice any further problems.
Regards,
Michael Karcher
upwards to the trace output. It's right next to
the failure message.
Regards,
Michael Karcher
Am Sonntag, den 21.09.2008, 13:46 +0200 schrieb Alexandre Julliard:
> Michael Karcher <[EMAIL PROTECTED]> writes:
>
> > Am Sonntag, den 21.09.2008, 13:07 +0200 schrieb Alexandre Julliard:
> >> If performance is an issue you most likely don't want to use msvcrt at
Am Sonntag, den 21.09.2008, 13:07 +0200 schrieb Alexandre Julliard:
> Michael Karcher <[EMAIL PROTECTED]> writes:
> > Sure I can, this was approach b I suggested. But that may be harmful to
> > performance, as it forbids gcc to use any knowledge about the standard
> > li
Am Sonntag, den 21.09.2008, 11:25 +0200 schrieb Alexandre Julliard:
> Michael Karcher <[EMAIL PROTECTED]> writes:
>
> > OK. Thanks for the pointer. I have a configure test ready that checks
> > whether the global -fno-builtin is really needed., and uses separate
> >
gt; +ok(ret == 18, "Run %d: Expected 18, got %d\n", run, ret);
Questions to everyone: I suppose if the trace above indicates the run
number, these modifications are unneded. Do you agree?
Regards,
Michael Karcher
gure test ready that checks
whether the global -fno-builtin is really needed., and uses separate
flags otherwise. I am planning to submit it in series with a second
patch that checks for whether -fno-builtin-scanf is needed (check for
warning on "%P").
Regards,
Michael Karcher
Am Samstag, den 20.09.2008, 10:50 +0200 schrieb Michael Karcher:
> Looks like we need to compile with -fno-builtin-sscanf, because gcc
> knows the implementation of glibc's sscanf,
OK, I looked further into it. On Linux, we don't get the warning,
because gcc is called with the sle
ompile with -fno-builtin-sscanf, because gcc
knows the implementation of glibc's sscanf, and you explicitly have to
forbid it to use this knowledge which does not apply perfectly to
Microsofts sscanf. This (of course) is only applicable to those parts of
wine that link to msvcrt and thus use msvcrt's scanf implementation.
Regards,
Michael Karcher
mit
message) that the different loading behaviour for DependOnService and
DependOnGroup is verified. Just for reference: WinXP SP3 in KVM here.
Regards,
Michael Karcher
g the patch wrong. It tries to read DependOnService
with TRUE, and aborts if it *fails*. If it succeeds, it loads *another*
setting (DependOnGroup) with FALSE, so definitely not a retry.
Peter, are you sure that windows will handle REG_SZ *only* in the
DependOnService case and fail if you have a REG_SZ in DependOnGroup?
Regards,
Michael Karcher
#x27;t matter at all in this case, since
> the API is supposed to fail due to source length being 0.
Even if the size doesn't matter, this line should get fixed, as the Wine
tests are a kind of of Win32 API reference by example. IMHO you
shouldn't include such misleading parameters as the size in the wrong
unit into API usage examples.
Regards,
Michael Karcher
hat might cause a crash, too.
In this particular case, I think the crash log does not really indicate
an alignment problem, but a "x/i $eip" in winedbg on the crash might
help to check further. I suspect a [edx-1] address while edx contains a
NULL pointer.
Regards,
Michael Karcher
s
Am Donnerstag, den 11.09.2008, 18:21 +0200 schrieb Martin Profittlich:
> > In this particular case, I think the crash log does not really indicate
> > an alignment problem, but a "x/i $eip" in winedbg on the crash might
> > help to check further. I suspect a [edx-1] address while edx contains a
> >
as been inlined at three different places.
Regards,
Michael Karcher
1 - 100 of 182 matches
Mail list logo
