May 2009 - Wine-Devel - list.winehq.org

Static-ify rsaenh/mpi?
by Francois Gouget May 23, 2009

May 23, 2009

So dlls/rsaenh/mpi.c defines 13 functions that are only used there. So they could be made static by tweaking mpi.c and tomcrypt.h. However my understanding is that this files has been imported in Wine from another project so maybe it's not a good idea to diverge much from them. What do you think? Should we just leave them as is? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner

2 3

re: Updating bugs in Bugzilla
by Dan Kegel May 23, 2009

May 23, 2009

Ken Sharp asked: > [Can I have bugzilla privs?] OK, you have them now. Please them wisely.

1 0

[patch] segv on use-after-free in dsound/buffer.c
by Yuriy Kaminskiy May 23, 2009

May 23, 2009

Hello! One of games rarely crashed with segv in line 86 of dsound/buffer.c: 85: IDirectSoundBuffer_Release((LPDIRECTSOUNDBUFFER)This->dsb); 86: This->dsb->notify = NULL; (sorry, I failed to save actual backtrace at the time). This looks like typical assign-after-free bug. I've applied attached patch (wine-1.1.7, now on 1.1.19), no crashes so far (btw, similar *Secodary*Release method down in code uses proper order - assign-NULL-then-release).

2 1

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
by James Mckenzie May 22, 2009

May 22, 2009

Roderick Colenbrander wrote about Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3 > >On Wed, May 20, 2009 at 4:04 PM, Austin English <austinenglish(a)gmail.com> wrote: >> On Wed, May 20, 2009 at 4:46 AM, Roderick Colenbrander >> <thunderbird2k(a)gmail.com> wrote: >>> On Tue, May 19, 2009 at 6:41 PM, Mike Kronenberg >>> <mike.kronenberg(a)kronenberg.org> wrote: >>>> On 18.05.2009, at 06:56, Dmitry Timoshkov wrote: >>>> >>>>> "James McKenzie" <jjmckenzie51(a)earthlink.net> wrote: >>>>> >>>>>> Austin: >>>>>> Contact Mike Kronenberg or Zach Drayer and see what they currently >>>>>> have. >>>>> >>>>> IMHO since they haven't even bothered so far to change the license from >>>>> GPL to LGPL to match Wine, and clarify what exactly is so much different >>>>> in their builds so that they insist on different naming (Darwine vs. >>>>> Wine), >>>>> they shouldn't be even considered as partners to the Wine project. >>>>> >>>>> If we could have our own Wine builds for Intel Macs, that would finally >>>>> help to avoid this confusion Darwine adds, and remove it from our Wiki >>>>> altogether (since it's apparently where the users coming to them from). >>>>> >>>>> -- >>>>> Dmitry. >>>>> >>>>> >>>> >>>> >>>> >>>> Hi, >>>> >>>> (I hope I did not double-post, but somehow my mail from yesterday was eaten >>>> by filter-gnomes) >>>> >>>> It's not about being willing to, but plain lack of time. >>>> I follow this list closely and work on solutions as time permits. >>>> After half a year, it's been four weeks now that I am able again to build >>>> and test on a regular base again. >>>> >>>> There are other components on OS X that need some love, like the >>>> winehelper.app into which I'm looking atm. >>>> >>>> License and renaming is definitely on the list. >>>> I thought to revamp the package, once the winehelper is replaced, to not >>>> double do the work. >>>> >>>> As already mentioned, I build the dependencies and store them inside the >>>> apple .app package, which allows for drag'n'drop installation and removal. >>>> >>>> Having the dependencies as frameworks would be even better, as there is a >>>> lot of trouble with PATHS, especially if multiple environments are on the >>>> system, like fink and macports. >>>> >>>> But if the name-change is the most pressing issue, I will gladly do that >>>> with this weekends release. >>>> >>>> Mike Kronenberg >>>> >>>> >>>> >>> >>> Could you also upload some docs / scripts on how to build 'DarWine' >>> from scratch? I have an app which I need to run on osx which I like to >>> package as well. I have time to help fixing osx issues (duplicating >>> the effort is not worth it). >>> >>> Roderick >>> >>> >>> >> >> It's available under 'build env': >> http://www.kronenberg.org/darwine/buildenv-1.1.5.zip >> >> -- >> -Austin >> > >Thanks, I used this to compile wine 1.1.21 for testing purposes this >week. I had to update the scripts a bit (e.g. use newere versions of >some libraries and tools because the old ones are offline). I can post >a patch against the old script. Further don't ship the opengl hack >anymore for new wine packages as you are aware it isn't needed for >xquartz 2.3.3 anymore. Everyone should move to the latest xquartz. >This might prevent some opengl bug reports which I have to close on >bugzilla as well ;) > Does XQuartz 2.3.3 apply on Tiger systems? The 'hack' is for both Tiger and Leopard so that some missing functions will work. Please list the updated libraries so that I can upgrade the script as well. James McKenzie

1 0

Entry point not found for GetDiskInfoA (wininet_crosstest.exe)
by Detlef Riekenberg May 22, 2009

May 22, 2009

In "dlls/wininet/tests/urlcache.c", GetDiskInfoA is called, but wininet.dll (native and wine) export this function only by ordinal. When I build the crosstest, my mingw [i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2)] creates a named Import for GetDiskInfoA with an ordinal hint of 65. Using that executable on Windows or Wine is not possible (Entry point not found for GetDiskInfoA) The wininet_test.exe on winehq has an ordinal Import of 102 in that place. How can we fix that? (My patch to use an ordinal import in the test was dropped: http://www.winehq.org/pipermail/wine-patches/2009-May/073130.html ) -- By by ... Detlef

2 2

Handle Types: Big flaw in wine
by Daniel Santos May 22, 2009

May 22, 2009

As I've been working with user32, adding tests & such, I've noticed that gdi32 also suffers from the same drawbacks: it appears to have no mechanism to track object types with handles. Thus, the functions (that I've examined thus far) simply assume that the caller responsibly passed a handle to the correct object type and proceeds with that assumption. This is the cause of at least one bug that I know of (18371). Right now, I'm trying to determine the best way to implement a solution and I'm still green to wine's architecture. My initial thought was a handle type table in user32 that would just contain a handle's type as a byte (or possibly two types packed in one byte since there are less than 16) using a huge ugly 64k table that directly mapped handle to entry (ugly but correct) and something more efficient later. But I'm wondering if it wouldn't be more appropriate to put something like that in kernel32's global arena table. Input appreciated. Daniel

1 0

Using TlsGetValue internally
by Daniel Santos May 22, 2009

May 22, 2009

I'm playing with user32/cursoricon.c and winex11.drv/mouse.c and have noticed that one of the TODOs is that SetCursor (and probably lots others) clear the last error when they do not do so in windows. I tracked down the cause and winex11.drv's primary function for retrieving its per-thread data, x11drv_thread_data() calls the public kernel32 function TlsGetValue, which must set the last error to zero by specification. So, should we be using some internal function to get the TLS data that does not alter SetLastError or should we just save the last error in winex11.drv, call TlsGetValue and then restore the last error state? The later seems hack-ish, but the former sounds like a pain. Thanks, Daniel

1 0

Re: Change BITS_IBackgroundCopyJob_SetPriority to a stub so the EvE-Online patcher works.
by Ricardo Filipe May 21, 2009

May 21, 2009

2009/5/20 Tim Wright <timw(a)splhi.com> > The EvE-online updater blows up because it's trying to set the download > priority in BITS (qmgr) and that isn't implemented. Simply stubbing it to > return S_OK is sufficient to allow it to work. > > Third attempt at sending. For some reason, it isn't being posted from > git-send-email even though the Cc: arrives just fine at another account. > Patch against git repository. This is bug 18528/12312. > > > > --- > dlls/qmgr/job.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/qmgr/job.c b/dlls/qmgr/job.c > index 3baa893..09693a3 100644 > --- a/dlls/qmgr/job.c > +++ b/dlls/qmgr/job.c > @@ -334,8 +334,8 @@ static HRESULT WINAPI > BITS_IBackgroundCopyJob_SetPriority( > IBackgroundCopyJob2 *iface, > BG_JOB_PRIORITY Val) > { > - FIXME("Not implemented\n"); > - return E_NOTIMPL; > + FIXME("(%p,0x%08x) stub\n", iface, Val); > + return S_OK; > } > > static HRESULT WINAPI BITS_IBackgroundCopyJob_GetPriority( > -- > 1.6.0.4 > > > > > your previous patch was already commited. check git page the next day when you send patches. http://source.winehq.org/git/wine.git/?a=commit;h=cb26244adb4e15ab60e4d02b5… ;)

2 1

Re: Bugzilla upgrade - opening attachments in browser
by Austin English May 21, 2009

May 21, 2009

On Wed, May 20, 2009 at 6:05 AM, Igor Tarasov <tarasov.igor(a)gmail.com> wrote: > attachment.cgi shows that it relies on allow_attachment_display > parameter in bugzilla configuration. It has to be set to true. > > -- > Igor > Can a bugzilla admin please enable this? -- -Austin

3 4

Re: shell32: for FO_COPY, if the destination is an empty string, SHFileOperation should use the current directory.
by Alexandre Julliard May 21, 2009

May 21, 2009

lionel_debroux(a)yahoo.fr writes: > @@ -1179,6 +1181,15 @@ static HRESULT copy_files(FILE_OPERATION *op, const FILE_LIST *flFrom, FILE_LIST > const FILE_ENTRY *entryToCopy; > const FILE_ENTRY *fileDest = &flTo->feFiles[0]; > > + /* If the destination is empty, SHFileOperation should use the current directory */ > + if (!fileDest) > + { > + WCHAR currd[MAX_PATH]; > + GetCurrentDirectoryW(MAX_PATH, currd); > + parse_file_list(flTo, currd); > + fileDest = &flTo->feFiles[0]; > + } This can't possibly work. parse_file_list requires a null-terminated list, and you will be overwriting the previous data. This needs more thought. -- Alexandre Julliard julliard(a)winehq.org

2 2

DIB Engine - Mostly fixed against test suite
by Massimo Del Fedele May 21, 2009

May 21, 2009

Remaining bugs are related to : 1) Some color on monochrome bitmaps.... here I guess nobody knows how to do it right. I fixed some todo wine (most) but have 2 failures which wine does right. Seldom used anyways, and happens only on weird palettes. I guess not ever Microsoft knows what they did on this respect :-) 2) an AlphaBlend() call which should fail and doesn't. Here I really don't know why it should fail..... Uninfluent, anyways. 3) GetDIBits on a source DIB with BPP <= 8 fails to retrieve the original DIB palette, and synthesizes a new one instead. For the moment I found no simple way to grab the palette from inside GetDIBits without maintaining a linked list of HBITMAP <--> internal bitmaps. Not worth the effort for the moment anyways. If somebody notices weird colors due to it, I'll try to fix..... There are still some missing/buggy features rarely used that aren't spotted by testsuite; by now I've no time to fix them, anyways no one felt into them up to now :-) Austin, could you please retest it against test suite ? (code on Bug421 page) Ciao Max

6 9

Need help writing test
by Igor Tarasov May 20, 2009

May 20, 2009

Hi! I've found few visual glitches in comctl32/toolbar, and now try to write this all down as conformance tests, but I have some problems. I see that there is bug, when I test it with control spy. But when I repeat it in testcase, it won't work. Here is how you can reproduce it: TB_SETBITMAPSIZE 20,20 TB_SETBUTTONSIZE 30,30 TB_SETBITMAPSIZE 10,10 Now, if you do TB_SETBUTTONSIZE, you'll see the difference. builtin comctl will return 17,16. Native - 30,16. But when I write something like this: rebuild_toolbar_with_buttons(&hToolbar); himl = ImageList_LoadImage(GetModuleHandle(NULL), MAKEINTRESOURCE(IDB_BITMAP_80x15), 20, 2, CLR_NONE, IMAGE_BITMAP, LR_DEFAULTCOLOR); ok(SendMessageA(hToolbar, TB_SETIMAGELIST, 0, (LRESULT)himl) == 0, "TB_SETIMAGELIST failed\n"); SendMessageA(hToolbar, TB_SETBITMAPSIZE, 0, MAKELONG(20, 20)); SendMessageA(hToolbar, TB_SETBUTTONSIZE, 0, MAKELONG(30, 30)); ok(SendMessageA(hToolbar, TB_GETBUTTONSIZE, 0, 0) == MAKELONG(30, 30), "Unexpected button size\n"); SendMessageA(hToolbar, TB_SETBITMAPSIZE, 0, MAKELONG(10, 10)); compare((int)SendMessageA(hToolbar, TB_GETBUTTONSIZE, 0, 0), MAKELONG(30, 16), "%x"); This test fails, when I test it with native comctl32 (the size is 17,16). Why could this happen or what am I doing wrong? -- Igor

2 2

Re: gdiplus: implement partially transparent solid fill brushes
by Vincent Povirk May 20, 2009

May 20, 2009

Don't commit this one. I forgot to pre-multiply the alpha. Vincent Povirk On Wed, May 20, 2009 at 11:33 AM, Vincent Povirk <vincent(a)codeweavers.com> wrote: > > > >

1 0

Re: [PATCH] Add missing classes for DOMDocument in msxml, and add test-cases back it up.
by Austin English May 20, 2009

May 20, 2009

On Tue, May 19, 2009 at 3:07 PM, Judy Devyak <judycarol(a)ameritech.net> wrote: > > > > You forgot the patch. -- -Austin

1 0

Re: [PATCH 7/8] urlmon: Added MIME filter handling in BindProtocol tests.
by Paul Vriens May 20, 2009

May 20, 2009

Jacek Caban wrote: > --- > dlls/urlmon/tests/protocol.c | 723 > +++++++++++++++++++++++++++++++++++------- > 1 files changed, 608 insertions(+), 115 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi Jacek, This introduces extra failures on what seems to be mostly on IE7 and higher; see test.winehq.org. Could you have a look? -- Cheers, Paul.

2 1

malloc() use in rpcrt4/tests/server.c
by Francois Gouget May 20, 2009

May 20, 2009

Is there a specific reason for using malloc() in these tests? Testing that rpcrt4 does not assume HeapAlloc pointers? (but why would it even care?) Here are the relevant lines: in midl_user_allocate(): dlls/rpcrt4/tests/server.c:56: use HeapXxx(): return malloc(n); in array_tests(): dlls/rpcrt4/tests/server.c:1212: use HeapXxx(): dc = malloc(FIELD_OFFSET(doub_carr_t, a[2])); dlls/rpcrt4/tests/server.c:1214: use HeapXxx(): dc->a[0] = malloc(FIELD_OFFSET(doub_carr_1_t, a[3])); dlls/rpcrt4/tests/server.c:1219: use HeapXxx(): dc->a[1] = malloc(FIELD_OFFSET(doub_carr_1_t, a[2])); -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

1 0

Re: [PATCH] winhttp: avoid NULL ptr dereference (Coverity 927)
by Paul Vriens May 20, 2009

May 20, 2009

Marcus Meissner wrote: > Hi, > > Not sure if we need to set these values in all error paths, > but definitely not in the NULL lpwhr. (lpwhdr?) > > Ciao, Marcus > --- > dlls/wininet/http.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c > index 212ff9f..53c3743 100644 > --- a/dlls/wininet/http.c > +++ b/dlls/wininet/http.c > @@ -3831,8 +3831,9 @@ static BOOL HTTP_OpenConnection(LPWININETHTTPREQW lpwhr) > > TRACE("-->\n"); > > + if (!lpwhr) goto lend2; > > - if (NULL == lpwhr || lpwhr->hdr.htype != WH_HHTTPREQ) > + if (lpwhr->hdr.htype != WH_HHTTPREQ) > { > INTERNET_SetLastError(ERROR_INVALID_PARAMETER); > goto lend; > @@ -3894,6 +3895,7 @@ lend: > lpwhr->read_pos = lpwhr->read_size = 0; > lpwhr->read_chunked = FALSE; > > +lend2: > TRACE("%d <--\n", bSuccess); > return bSuccess; > } Hi Marcus, After AJ's remark you marked this Coverity one as "lpwhr can not be NULL". Should we thus delete the "NULL == lpwhr" altogether? -- Cheers, Paul.

2 1

Bugzilla upgrade - opening attachments in browser
by Austin English May 20, 2009

May 20, 2009

It seems the bugzilla upgrade stopped allowing opening attachments in browser. Not sure if that's by choice or just an unchanged setting, but having to open .txt/.jpeg/.png files in outside applications is a bit annoying...Any possibility of fixing that? -- -Austin

2 1

user32: improvements
by Daniel Santos May 20, 2009

May 20, 2009

In the process of working on this bug (http://bugs.winehq.org/show_bug.cgi?id=18371) I have discovered that user32's SetCursor function does not ensure that the the handle passed is valid or that it is even a handle to a cursor object (and it seems that the lingo for user32 objects is "resources"). The root cause of this problem is that the app attempts to use a cursor after it already destroyed it. At first, this just causes the cursor to be blank. Then, it would appear that the handle is re-used for a different type of resource, which leads to the gibberish image & subsequent hang. When this app runs on windows, I presume that the SetCursor calls just fail and the app resumes harmlessly ignoring the failure (or correcting it, either way). In general, this flaw will affect applications which use the user32 api irresponsibly, and I'm certain that a great number of windows apps out there, to some extent, do. My 1st step is to write some tests that illustrate/prove this problem (and that it works on windows) and I'm building the tests now so I can start on that. However, I've been reading up and considering how to implement a solution. I presume that this problem affects every user32 handle & function related to them, but I have only thoroughly examined mousecursor.c, so please forgive any incorrect assumptions I still have at this point (and let me know if I'm way off!). There was a quaint MSDN article on how the windows GDI32 dll manages GDI objects that even gave the internal structure, etc. (http://msdn.microsoft.com/en-us/magazine/cc188782.aspx) Although this only covers gdi32, I'm getting the idea that what needs to happen in user32 isn't too much different. Essentially, it would seem that user32 needs to associate a handle with a type and it would *appear* at this point that would be sufficient. However, I need to gain a better understanding of the nuisances of user32 objects.. From reading this ms kb article (http://support.microsoft.com/kb/184802) it seems that the windows user32 maintains 3 different types of heaps, a global one, one for each desktop and a different (differently sized?) one for non-interactive desktops. Windows' "global heap" is where user32 stores it's handle table, presumably which, simply associates a kernel32 handle with appropriate information for user32 objects, similar to the way GDI does (as illustrated in the above referenced MSDN article). Thus, if you create a thread, it can never have the same handle value as a cursor, icon, etc. So I'm going to write my tests on my windows machine, starting with only the mousecursor.c stuff because there appears to be quite a lot of ground to cover. If anybody has any feedback, corrections to anything I've said, etc. please do reply. Daniel

1 0

Re: Detecting an invalid handle in setupapi
by Daniel Santos May 19, 2009

May 19, 2009

oops, I meant to reply-all on this. --- On Mon, 5/18/09, Daniel Santos <javatroubadour(a)yahoo.com> wrote: From: Daniel Santos <javatroubadour(a)yahoo.com> Subject: Re: Detecting an invalid handle in setupapi To: "Paul Vriens" <paul.vriens.wine(a)gmail.com> Date: Monday, May 18, 2009, 5:43 PM I'm so very glad you brought this up Paul. I'm new to wine development and I've been working on Lord of the Rings Online issues and I have discovered and validated that the root cause of two of my problems are related (http://bugs.winehq.org/show_bug.cgi?id=18371) There are numerous places in Wine where the validity of handles are not checked. If the handle turns out to be invalid, then a NULL pointer is simply passed instead (which sometimes has an alternate meaning). Worse yet, in the code I was working with (dlls/kernel32/global16.c) the type of object the handle refers to is not stored! I see this as a critical flaw in Wine and I hope I can come up with a viable solution. I'm planning on setting up some test programs to examine the bit-data of some windows objects (starting with user32 -- where my issue lies) as any solution will have to be bit-compatibile with windows since apps like paint shop pro de-reference handles and examine the data of the underlying objects. In truth, if the LOTRO app didn't destroy objects it was still using and then try to use them, the problem wouldn't exist -- this part of wine will work perfectly if the app behaved responsibly. But development timelines and pressures frequently lead to code that works, but is incorrect and is a part of reality. Daniel --- On Sat, 5/16/09, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: From: Paul Vriens <paul.vriens.wine(a)gmail.com> Subject: Detecting an invalid handle in setupapi To: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> Date: Saturday, May 16, 2009, 12:18 PM Hi, I'm trying to install Microsoft's MMC (W2K3) and it crashes every now and then with different symptoms. I've tracked it down to what I think is a fault in the application that triggers a bug in Wine. All inf files that are read are closed with SetupCloseInfFile but the app is still trying to use the handle in a call to SetupFindFirstLineA. On Windows (tested on W2K3) this will lead to a failure of SetupFindFirstLineA with a last error of ERROR_INVALID_HANDLE. On Wine we don't check the handle and thus the outcome cannot be predicted (mostly crash). What ways do we have to detect invalid handles or better yet how can this be solved? -- Cheers, Paul.

1 0

Re: winemaker: add include-directory parsing
by Paul Vriens May 19, 2009

May 19, 2009

André Hentschel wrote: > --- > tools/winemaker | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi André, Not a comment on the patch itself but this is the third time you tried with the same patch. We usually add a 'resend' to the subject of a patch that is, uuh resend. If it's another revision we add 'try x'. In your case you should probably ask (on wine-devel) for comments or contact AJ directly on irc. -- Cheers, Paul.

1 0

re: [Article] WINE and the importance of application compatibility
by Dan Kegel May 19, 2009

May 19, 2009

James McKensie wrote: > WE need to get to the point where most of the common business type > applications will run in Wine without a bunch of twiddling and fixes. Well, yes. That was one of my goals during my big Wine push ( http://www.winehq.org/pipermail/wine-devel/2008-February/062550.html ), and I think we made a lot of progress. Still lots to do, as you know. Sure would be nice if we could convince the DoD they needed a second source for Windows :-) - Dan

9 10

Gecko installation broken?
by Stefan Dösinger May 19, 2009

May 19, 2009

Hi, Is my setup broken, or does the gecko installation fail? In a new wine prefix, when I open builtin iexplore, I get the installation dialog. The download runs successfully, but after installation iexplore still says that HTML rendering is currently disabled. When I run iexplore again, I again see the Wine Gecko installer dialog box. My hacky nightly game tests ran into this problem. The last successfull Team Fotress 2 test run is from May 14, 2009. After that my Gecko setup script failed and did not even try to start up Steam. Cheers, Stefan

4 6

Re: ntdll/tests: Mark return value of RtlUnicodeStringToInteger("", 16) as broken for nt4.
by Paul Vriens May 19, 2009

May 19, 2009

Huw Davies wrote: > --- > dlls/ntdll/tests/rtlstr.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > Hi, I don't think this is correct. This test has always succeeded until March 9th. There haven't been any changes to the test in that period, but I remember an upgrade of winehq in that weekend. In other words, there is more to it. Testing a simple cross compiled version of this test doesn't yield an error on NT4. -- Cheers, Paul.

3 2

Re: gdiplus: implement GdipTransformPoints
by Nikolay Sivov May 19, 2009

May 19, 2009

Vincent Povirk wrote: >From 1de9b2291bf9a5617ca1e3b0cba5f1260889c259 Mon Sep 17 00:00:00 2001 From: Vincent Povirk <vincent(a)codeweavers.com> Date: Mon, 23 Mar 2009 16:34:12 -0500 Subject: [PATCH] gdiplus: implement GdipTransformPoints It's a strange way to check enumeration with integer comparison, isn't it? And not clear in this particular case. > + if (stat == Ok) > + { > + unitscale = convert_unit(graphics->hdc, graphics->unit); > + > + if(graphics->unit != UnitDisplay) > + unitscale *= graphics->scale; > + > + if (src_space <= CoordinateSpaceWorld && dst_space >= CoordinateSpacePage) > + GdipMultiplyMatrix(matrix, graphics->worldtrans, MatrixOrderAppend); > + if (src_space <= CoordinateSpacePage && dst_space >= CoordinateSpaceDevice) > + GdipScaleMatrix(matrix, unitscale, unitscale, MatrixOrderAppend); > + > + if (dst_space <= CoordinateSpacePage && src_space >= CoordinateSpaceDevice) > + GdipScaleMatrix(matrix, 1.0/unitscale, 1.0/unitscale, MatrixOrderAppend); > + if (dst_space <= CoordinateSpaceWorld && src_space >= CoordinateSpacePage) > + { > + GpMatrix *inverted_transform; > + stat = GdipCloneMatrix(graphics->worldtrans, &inverted_transform); > + if (stat == Ok) > + { > + GdipInvertMatrix(inverted_transform); > + GdipMultiplyMatrix(matrix, inverted_transform, MatrixOrderAppend); > + GdipDeleteMatrix(inverted_transform); > + } > + Maybe it's better to use 'switch' for source coords with falling and ifs inside cases for destination. <= CoordinateSpaceWorld is just CoordinateSpaceWorld >= CoordinateSpaceDevice - is CoordinateSpaceDevice.

3 3