Hi Hugh,
Thanks for looking at this issue with wine's cmd
I do not think this patch is enough - From memory (I once tried
something similar) the problem with resolving it the way you have is
you then lose the ability of breaking out of a batch program. I think
the right solution needs an actual
Hiya,
Its been a while since I did some cmd work and noticed there were some new
bugs so am doing some fiddling. The real pain for me was always keeping the
tests passing on nt4, so I noted with relief/surprise that the testbot
doesnt have an NT4 VM anymore.
Is it correct that there is no longer
Dont know what's happened, need to investigate further - Had 100% pass rate
in job 23438 only to fail on submission... Needs some investigation so will
work on it later in the week
Jason
NB: replies on wine-devel should be only the bottom
Hmm... gmail new style compose window missed the ...'s - How
obvious is that... hopefully sorted?
I don't really understand your point here. You're echoing the variable
name anyway, so if the 'set foo' displays it as well; I don't see
Thanks for the review!
Jason
On 14 December 2012 02:01, Frédéric Delanoy frederic.dela...@gmail.comwrote:
On Fri, Dec 14, 2012 at 2:59 AM, Frédéric Delanoy
frederic.dela...@gmail.com wrote:
On Thu, Dec 13, 2012 at 10:59 PM, Ann and Jason Edmeades
ja...@edmeades.me.uk wrote:
The tests
On 20 November 2012 12:15, Jacek Caban ja...@codeweavers.com wrote:
On 11/20/12 12:39 AM, Ann and Jason Edmeades wrote:
(I'll make this change in try 2, as I need to fix the broken NT4 stuff
from patch 1 anyway)
I think it's time to consider skipping all cmd tests on NT4. Adding
On 20 November 2012 12:31, Alexandre Julliard julli...@winehq.org wrote:
That doesn't guarantee that it's the process console, console handles
can be passed across processes.
So apologies if this is an ignorant question, I dont really understand this
console logic properly so I was
IMHO it might be better to use variable names like WINE_xxx for tests
involving enumerations to avoid needlessly altering the environment.
(not that BAR, FOO or FOOBAR are likely to be already used environment
variables)
Frédéric
Thanks!
We dont really change the environment long term, as
Hi Eric, Thanks for taking the time to reply
The issue is that WriteConsoleInputW requires GENERIC_WRITE access, but the
CON device (\\.\CON) was opened as GENERIC_READ (and in fact fails if I try
to open it with GENERIC_WRITE).
You said...
- you're using a bare console, ie didn't run your
Hello,
I've been looking at a patch which sorts out NUL and CON handling in a part
of the command shell, and have stumbled upon a problem I am not sure how to
fix because I really dont understand the underlying console handling, and
would appreciate someone pointing me in a direction.
For
It's clearly time to start splitting WCMD_for into several
helper functions.
I completely agree, and it was definitely on my radar to do... its really
ugly code in there (I take responsibility for a lot of that!) as it has
been a slow incremental increase in what we actually supported... I was
Concept of patch is fine (and we ought to support it), but I dont think
this would work as coded (if (tolowerW(c)=='c'||'r') will always be true).
Also, can you add a quick test for it (there's cmd.exe /c tests - just
add a cmd.exe /r echo test worked).
PS You might want to just hold off until
Hello,
While working on more of the 'for' processing in the command shell, I've
come across a stumbling block that wildcard expansion 'ordering' is not
guaranteed (findfirst/findnext) meaning I cannot automate tests for some of
the key bits - this is frustrating as we really need tests for the
=== WVISTAADM (32 bit) ===
Failure running script in VM: The specified guest user must be logged in
interactively to perform this operation
I dont think this is related to my patch, especially when the tests run and
pass on patch 2
Does anyone have any comments on this please?
-- Forwarded message --
From: Jason Edmeades jason.edmea...@googlemail.com
Date: Wed, Jan 27, 2010 at 1:09 AM
Subject: Loader, mapping and sharing issues with main exe
To: wine-devel@winehq.org
Hello,
I've been debugging a problem
Hello,
I've been debugging a problem with an application which checks itself
for consistency before it runs. It does this extremely simply and
fails in a trivial way under wine, but for the life of me I do not
know how to fix it, and I would appreciate any thoughts - its not
everyday I delve into
This doesn't seem correct to me
You are right, its incomplete, but it also was based on the logic
already in MSVCRT_vswprintf_s, which is just as incomplete!
I'll happily just raise a bug report if the patch is insufficient, but
in general all the _s special processing is missing from the
Thanks Alexandre,
(BTW This createwindow / movewindow / draw to window is all occurring in
LBUTTONDOWN processing)
1. MoveWindow doesn't update the DCEx clip_region region, and hence when
the
visible region changes, it is merged with the clip region and since there
is
no overlap the visible
Hello, I've been investigating defect 11562, and would appreciate some
thoughts on how to move forward...
Basically the application creates a new visible window (eg at 0,0 - 200,50)
and then draws in it by:
1. BeginPaint - This sets up the cliprgn to the whole window
2. Works out some sizes...
3.
Out of interest, what is meant by improving cmd.exe compatibility?
Add support for all the cmd.exe switches and all the dos batch
programming constructs?
I do track bugzilla for any cmd.exe issues regularly and aside from one
which I started work on, I don't know of any other batch issues. I
Hiya,
Out of interest, what is meant by improving cmd.exe compatibility?
Jason
Hi Alexander,
In the process of debugging I
also determined that Windows doesn't seem to send this message to
parent at all (tested on win98-Qemu, winXP SP2-Qemu and winXP SP1
normal installation). So I'm deleting this second call altogether and
a conformance test for this situation will
Sending message to parent in tooltip code
probably simply works around toolbar's broken behavior. In this case I
think
I've identified a line in toolbar.c that fails to properly detect empty
string
causing not appearing tooltips in Radmin. I'll try to submit another patch
with
this fix
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
I run a program which uses a *.bat files via wine wineconsole
--backend=user start program.bat and this program runs well but after
exit it program fails
The context should be valid as it was allocated a few lines higher up. To be
fair, there's no checking the LocalAlloc worked, but you would
I did a simple test here and it works, although I would like to test 2
scnarios:
a calls b which runs c
a runs b runs c
I test that and found the previous email was very slightly wrong. I've coded
and sent my new patch into wine-patches as it corrects an identical trap to
what you were seeing
We need to check context before than refer to context - skip_rest .
But we have just referred to it higher up, and I didn't think it was valid
to get into this routine without a context.
Whats the problem you are trying to fix?
Jason
Out of interest, is there any way to get (read here 'write code for') the
wine's cmd.exe better integrated in the window you launch it from when it is
not in wineconsole mode.
For example, I would love to see cls clear the screen (I suppose I could
just launch 'clear'!), or command retrieval
I'll double check later, but are you sure?
When I said I hadn't changed the patches, I meant the contents, but I had
done a git fetch, git rebase origin on the branch (and resolved the german
resource conflict) before resubmitting
Jason
Apologies for the size of this patch - I tried 3 or 4 ways of converting
chunks to unicode and always ended up duplicating huge bits of code and
having problems keeping track of duplicated variables that in the end I
did the lot in one go.
You need TCHAR and friends to reduce the Patch-Size
With git commit, you can use the --author switch
for example:
$ git commit -a --author Jesse Allen [EMAIL PROTECTED]
Set user.email and user.name once with:
git repo-config
Thanks! I found I'd already done it when installing git (must have made a
mistake and actually read the docs when doing
I believe what is happening is that the WineHQ mail server only accepts
one SMTP connection at a time. This will probably reject half the
messages sent by your mail server. Then they will get resent after a
short period of time, but in batches so more messages will get rejected
and then resent
Alexandre - How does the email address get into the change log, is it a
manual process or by hand. Ideally I'd like my main email address to be
the
one in the Changelog, rather than the gmail one which is purely to see if
it
resolves the problems I am having sending in patchsets - Is there
Apologies if this set arrives multiple times - I sent it all on Friday, and
the mailing list only shows 1,2 and 4. I sent then again tonight separately,
and immediately 3 went missing...
FYI I had this problem before the last hardware upgrade on winehq, and it
appeared fixed since then. I'll
Whilst trying to convert cmd to Unicode, I've stumbled across a problem
which I either need to work around or fix, and I am not sure which.
WCHAR h[] = {'h','e','l','l','o','\0'};
WCHAR fmt[] = {':', '%', '1', '0','s',':','\0'};
char test[255];
WCHAR result[255];
sprintf(test, '%10s',
Alexandre Julliard [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Jason Edmeades [EMAIL PROTECTED] writes:
Note: This makes cmd.exe pull in msvcrt, but so does native
Native doesn't have a choice, but we do. Unless there are good reasons
to import msvcrt it's better
Hiya,
Firstly, fantastic work, and its also explained to me something Eric said
which I didn't grasp...
While preparing tests I found the 'user' backend of wineconsole works with
WriteConsole/WriteFile correct (see test1 and test2), so I used it as etal.
I figured out the main issue with cmd:
Detlef - Thanks... You can see what I added as an afterthough!
Eric, Thanks for taking the time to look at this and for your answers
- ensure that all msvcrt's function needing to write unicode strings
behave as follows:
+ if the output handle is a console handle, use WriteConsoleW -
this
(Meant to copy wine-devel as well, in case anyone else had any comments)
Subject: RE: locales, unicode and ansi with msvcrt (bug 8022)
My current plan, unless you have strong objections, is to make the
wprintf
msvcrt routines use WideCharToMultiByte on the string into the GetACP
codepage
Anything else I can test, or am I ok to put file tests into msvcrt test
buckets and allow the msvcrt unicode printf and friends to convert to
non-unicode using the console codepage before being output to the file
handle?
Why don't you simply run native MSVCRT under +relay,+snoop and see how
My current plan, unless you have strong objections, is to make the wprintf
msvcrt routines use WideCharToMultiByte on the string into the GetACP
codepage before being written out, and add file tests for this into the
msvcrt testsuite
OK, A bit more testing and a bit more research starts to
What your test app is doing? It probably needs a test under Windows
to see in which encoding (ANSI/OEM) a not unicode app should
receive input via a pipe.
I meant things like 'dir lst.txt', 'dir | sort lst.txt'. 'dir' and
'sort' could be replaced by some external .exes that get
Dmitry Timoshkov wrote:
Ann Jason Edmeades [EMAIL PROTECTED] wrote:
Bug 8022 (http://bugs.winehq.org/show_bug.cgi?id=8022) has highlighted
something interesting which has me puzzled...
Basically lets take xcopy as an example command line application. It
issues
messages to the screen using
Apparently you need to use appropriate console output APIs directly
(that
take into account the console input/output code page) instead of using
MSVCRT APIs.
Unfortunately just using the wide console function will only help the
output to the screen, but as my test program shows there is
What your test app is doing? It probably needs a test under Windows to
see in which encoding (ANSI/OEM) a not unicode app should receive input
via a pipe.
Sorry, just realized I had not addressed your last comment - Can you expand
on this sample test please and I'll do some experimenting. How do
Hello,
Bug 8022 (http://bugs.winehq.org/show_bug.cgi?id=8022) has highlighted
something interesting which has me puzzled...
Basically lets take xcopy as an example command line application. It issues
messages to the screen using MSVCRT's wprintf(LUnicode string) type
function
Wprintf -
+if (wcsstr(copyFromUpper, pos-name) != NULL) {
wcsstr() doesn't seem the right way to compare file names. You
probably want to do a wcsicmp() of the end of the name or something
like that.
It's not a file compare, it's a substring compare, eg if the file contains
just the
Er... I have just managed to get git send-email set up and working, and it
would appear to be a feature of it. I do get one question which I answered n
to, perhaps I should anser yes to it and see what happens :-)
Anyone else using git send-email want to comment on how to avoid this?
Thanks!
wouldn't it be nicer to use sizeof(copyCmd) here?
if (GetEnvironmentVariable(COPYCMD, copyCmd, MAXSTRING)) {
There are many spots like this in wcmdmain.c
Yes... I'm blaming cut and paste as I didn't do all the wcmd ones :-)
Once I get all my xcopy patches in I want to continue my rework of the
Further investigations shows the strstr bit is right, but the string I am
comparing with differs from windows. I have fixed up xcopy's output display
to mirror windows, and added that as a patch on the end of the resubmitted
patchset, as it is not directly related to the strstr bit
Regards,
Jason
Hiya,
If adding files for translation to a new directory (xcopy), can anyone
confirm of deny whether the following is all I need to do:
1. Add rsrc.rc containing (* - see below)
#include windows.h
#include resources.h
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
I'm just curious: xcopy.exe is an external program in Windows,
but you want to make it a builtin command in Wine?
No, its already committed in the tree already as an external program
(programs\xcopy).
The installer I was fiddling with which caused me to write xcopy
actually uses
The installer I was fiddling with which caused me to write xcopy
actually uses (effectively) cmd.exe /c xcopy. The fact I cant
run a wine supplied program from within another portion of wine was
what concerned me. I was trying to understand how wine locates it,
given that CreateProcess
Sage Line 50 already has a bug filed:
http://bugs.winehq.org/show_bug.cgi?id=2956
but we're hampered because there's no free demo for us to test.
You could register for a free trial cd?
http://www.sage.co.uk/considering/TryNow.aspx?tid=213114
However according to http://support.microsoft.com/kb/830473 : the total
length
cannot contain more than either 2047 or 8191 characters (as appropriate to
your
operating system)
I'd suggest changing it to MAXSTRING which is used throughout cmd to refer
to a 'big' string (of 8192 chars). At
There does not seem to be a patch attached.
They followed
However - I sent all 9, and got immediate cc: copies returned to me for all
9. Browsing the patches through either gmame or wine-patches archives, only
shows 1,2,5 and 7 got through. This is the same as yesterday when a number
of the 19 I
diff --git a/programs/xcopy/Makefile.in b/programs/xcopy/Makefile.in
new file mode 100755
All the files you create or modify are marked executable, could you
please fix that?
Thanks for the heads up - I should have fixed it now, any problems please
let me know.
For reference, in case anyone
Hi Detlef,
Firstly thanks for taking the time to comment on this...
Configure.ac - I included that because another 'regular' developer who added
a dll recently added it (See:)
http://www.winehq.org/pipermail/wine-patches/2007-February/036243.html)
I'll leave it in for that reason unless
Hi Detlef, (again)
Configure.ac - I included that because another 'regular' developer who
added a dll recently added it (See:)
http://www.winehq.org/pipermail/wine-patches/2007-February/036243.html)
I'll leave it in for that reason unless there's a big problem with it (I
always thought you
Hi,
Trying to convert my xcopy to Unicode proved simple on windows, but when
putting into wine has proved more interesting. Most of the wide string calls
are like lstrcmpW and they all work fine, but I really need the Unicode
equivalent to strchr and strrchr. As far as I can tell my only option
For reference:
'obviously'... adding this line to the makefile solves it
MODCFLAGS = -fno-builtin
(Copied from msvcrt\tests)
Jason
Hi, Looking at the cmd.exe bugs in the database, one is caused by a lack of
XCOPY support. Does anyone have anything like this in their tree, or should
I try to knock something up?
I also assume it needs to be a separate program, not part of cmd.exe, to
mimic how windows does it?
Jason
Hello,
Its been a while since I did any wine work so thought I'd fix some bugs in
the cmd shell. I have come across a call which fails at compile time which I
was interested in knowing the 'right' way to solve
_splitpath appears to exist in ntdll, but none of the #includes I have tried
pick it
Again, the very first thing I'd suggest to do is to write a comprehensive
test
case and send it to wine-patches with appropriate todo_wine statements to
make
it pass. Then we could see exact steps which lead to a failure and could
start
thinking of a possible fix.
Attached is a set of tests
Hiya,
I've found my changes for this other bug, which also relates to the menu
code are wrong, and am trying to work out how to identify how windows does
it.
The problem is that there is a menu item with the same id as a popup menu.
In all the tests for all the calling functions, windows will
The fact that you need to intorduce the txtWasAllocated flag suggests that
something is wrong. Also MF_OWNERDRAW certainly does not qualify as a
MF_STRING
alias. I'll try to play with your test case and see if I can find a better
fix.
The particular problem in the bug report was that the
I attach it here now (bzip2'ed for once because of its size). Before
submitting to wine-patches, I need some time to review the code once
more for remnants of old way of thinking and to get rid of the
IS__ITEM macro's ( or rename them to reflect the true intention).
Glancing through the
You don't check SetMenuItemInfo return code after the above calls and I
very
much suspect that they fail leading to the observed results.
Well spotted, thanks!
In the one case of string - ownerdraw you are right, and I have now
modified the tests to flag a todo where this unexpectedly works on
Hi, How do you set breakpoints in 16 bit code, or cant you?
I can add in the winedos code a debugbreak at a particular point in time,
and I really want to step through some of the code following the return to
see why something is happening.
If I do, for example, break 0x1257:0x33f3 or
Ok, more information...
The routine (slightly modified to allow code before the return) is
ATOM WINAPI RegisterClass16( const WNDCLASS16 *wc )
{
WNDCLASSEX16 wcex;
ATOM fred;
wcex.cbSize= sizeof(wcex);
:
Hiya,
I've got a weird issue and was wondering if anyone could advise on how to
resolve. (Comes from a 16bit windows app, but is a more general debugging
issue).
The problem is ...
1) If I run the application, it just hangs - no overly helpful information
at all.
2) If I add WINEDEBUG +relay
How about an one line test case which simply does
ret = DefWindowProc(hwnd, WM_MOUSEACTIVATE, 0, HTNOWHERE);
ok(ret == MA_ACTIVATE, expected to return MA_ACTIVATE\n);
Yes, the patch does that (via the window proc for the test, but it gets
forwarded on as its not handled). I didn't think of
Out of interest, does reversing this patch fix the wc3 fonts - If I recall
correctly if was the glTranslate calls which originally made the wc3 fonts
look correct, and I noticed in one of the patches Oliver changed them. He's
probably right, but just in case its worth a test
Try changing
LISTBOX_RemoveItem already does pretty much the same check, you should
reuse that instead of duplicating it, you just need to remove the -1
special case in there.
OK - Done, and changed the special case use by setcount appropriately
Changelog
Listbox delete string handling should validate the
I asked this a while ago and noone was too upset, but I am going to try to
spend some time slowly closing off some of the bugs which do not have enough
info in them to be reproduced, and have not had a response to a request to
see if the problem persists for a long time (e.g. 6 months).
I wont
Without removing the update region there's no way to step further in the
list, if I understand the problem correctly?
Yes, but that's what needs to be fixed, we need to make progress even
if the update region is not validated. We will then get a WM_PAINT in
the main message loop, which I
(Sent from old email account this time, since I haven't registered the new
one yet!)
the resulting patch that was attached to the bug do fix the problem.
I'm
not sure if the patch has been committed to CVS, but if it hasn't it
probably should before the next wine release...
No it hasn't.
the resulting patch that was attached to the bug do fix the problem. I'm
not sure if the patch has been committed to CVS, but if it hasn't it
probably should before the next wine release...
No it hasn't. The problem is that the fix does indeed solve the problem, but
also makes the behaviour
if ((hrgn = send_ncpaint( child, NULL, erase_flags )))
send_erase( child, erase_flags, hrgn, NULL, NULL );
-prev = 0;
+break;
The problem is that this will cause children to be skipped too. What
you really need is to repaint every
Hiya, Is there any way to change the email address I am registered with for
the wine mailing lists, bug tracking, Changelog etc, or is the best way just
to reregister for them all with a different id?
Jason
It only loops if the window procedure doesn't validate the window, so
what you can do for instance is to have a window proc that does
nothing the first 10 times around, and on the 11th call signals an
error and validates the window to break the loop.
Would something like this suffice?
/* Global
Ok, I need advice on this one...
I have been purely testing on windows, no wine involvement, to see what
happens when I do various things.
My test program doesn't do anything in the WM_PAINT handler at all. This
results in the machine sitting at 100% CPU processing WM_PAINT messages.
1.
I believe staying in the updatenow code in wine is incorrect. I think
what
happens is that when the message dispatch loop gets an empty queue and
the
window has an invalid region, then a WM_PAINT is returned.
So... Can we / I please remove the loop? :-))
Sure you can, you just need to
I think I have reproduced the same problem with a simple testpgm...
Instructions...
1. Start Visual Studio, create a default windows application
2. Comment out the code in the WM_PAINT and replace it with return 1
(important)
3. Run it...
On windows you can play with the menu etc and it works.
Hi all,
I'm trying to track down a regression which causes UT2003 (and UT2004 /
Unreal2 apparently) to fail, and am getting stuck at the windowing level so
would appreciate any thoughts as to possible causes. (And no, I haven't
tried to work out what regressed it... Why spoil my fun!)
Basically
I've been moving house over the past couple of weeks
which is why I dropped off the face of the earth for a
while.
Phew - I was worried I'd have to try to understand all of your patch :-)
Welcome back and keep up the good work
Jason
Hi,
FYI I stopped d3d9/wined3d work when I got to a point I had completed the
parts I was doing, and Oliver had sped ahead so I was ending up duplicating
work he was doing - I've put it to one side while waiting on the cvs tree to
get up to where he was.
The last I heard, Raphael was also
Hiya,
I was trying to confirm an old bug still existed and the bug #440 has
a tar file with an exe in it which apparently used to run under wine and
fails with some problems later on. Nowdays, it fails dismally when you
try
to launch it.
What exactly is the bug number and where that DOS
Hiya, I was trying to confirm an old bug still existed and the bug #440 has
a tar file with an exe in it which apparently used to run under wine and
fails with some problems later on. Nowdays, it fails dismally when you try
to launch it.
Disclaimer#1 - I haven't tried a regression test but I have
1. I would like to get implemented an AUTOMATIC timeout on the bug
reports.
I have looked at this and it is not possible to do this without
drastically altering (forking) bugzilla.
I have looked into having a resolution abandoned and that should be
possible to do without forking bugzilla Too
Hello,
I thought I'd try to start a discussion to try to encourage changes in the
bug tracking, but it would both require agreement and someone (else) who
could physically make the changes.
Is it me or is our bug tracking database not really working the way it
should?
Firstly I'd like to thank
Hiya,
I was working on bug#2716 - a trap running install which turned out to be
due to a missing registry key which wineprefixcreate should have created.
Now I had an excuse (I deleted *.reg for another test previously!) but the
reporter also got the same problem.
To quote:
I've installed WINE
Hi,
1. Winedbg:
I can get to the trap by winedbg program.exe, cont, and it stops and
displays everything ok
2. KDBG: I launch winedbg --gdb --no-start program.exe, and it starts and
issues the line target remote localhost:32835
I then issue kdbg -r localhost:32835
KDBG seems to be working ok, except when I select run
winedbg reports
Unknown packet request vCont?
0015:0016: exception code=0x406d1388
http://www.rons.net.cn/htp/gdb/gdb_33.html
vCount should be valid so I'll see if I can find out
what's not going on.
I've tried ddd and get the same
Hi
I was trying to get a gui replacement for winedbg as I can never remember
how to view memory etc, and saw
http://www.winehq.com/site/docs/wine-devel/dbg-others
where it talks about using kdbg. I was looking at a simple trap and thought
it ideal to test with
So...
1. Winedbg:
I can get
Well yes and no. The 'problem' is most of this code isn't implemented yet...
Try Olivers large patch and see if things are any better, or wait a while
while a whole load of code gets into cvs. Basically d3d9 shouldn't have any
of the code relating to the stencil buffers - that will be in wine3d.
Hi Raphael,
Get/SetRenderTarget in d3d9 cant be right - if has to go through wined3d, as
it's the only person who knows the front/back buffer etc. You don't want
This-renderTarget at all at the d3d9 level
The same issue later,
+ if (NULL == pDeviceImpl-backBuffer) {
+
Hi Oliver,
I said I'd give this a review, and there's some great work here.
I've had a chance to go through these changes, and some mostly trivial
comments. Apologies if some of these are inaccurate, because some of the
diffs look complex and I was purely reviewing the patch files! There seems
Hiya,
In the wined3d code I have, for example, a class surface which inherits a
lot of methods of Resource. Most of these methods can be called as-is, and I
have code which looks like:
HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface,
IUnknown **pParent) {
return
I have code which looks like:
HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface,
IUnknown **pParent) {
return IWineD3DResource_GetParent((IWineD3DResource *)iface, pParent);
}
IWineD3DResource_GetParent is a macro:
#define IWineD3DSurface_GetParent(p,a)
1 - 100 of 137 matches
Mail list logo
