February 2008 - Wine-Devel - list.winehq.org

Re: wine.inf: Create fake dll entry for dosx.exe

by Steven Edwards

On Fri, Feb 29, 2008 at 2:16 PM, Justin Chevrier <jchevrier(a)nexicom.net> wrote: > Anything wrong with this one liner? I think you should create a stub version of dosx in wine/programs as well. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has cdosome." - Victor Hugo

Feb. 29, 2008

Re: Conformance tests for LoadStringW and LoadStringA

by Christopher

wine-devel-request(a)winehq.org wrote: > Message: 3 > Date: Fri, 29 Feb 2008 12:50:53 +0100 > From: Alexandre Julliard <julliard(a)winehq.org> > Subject: Re: Conformance tests for LoadStringW and LoadStringA > To: Christopher <raccoonone(a)procyongames.com> > Cc: wine-devel(a)winehq.org > Message-ID: <87y794yo9u.fsf(a)wine.dyndns.org> > Content-Type: text/plain; charset=us-ascii > > Christopher <raccoonone(a)procyongames.com> writes: > > >> > + ok(!memcmp(copiedstring, returnedstring, (length2 + 1)*sizeof(WCHAR)), >> > + "LoadStringW returned a string that does not match the string pointed to by the pointer it returned. \ >> > + returnedstring = %ls, copiedstring = %ls", (wchar_t *)returnedstring, (wchar_t *)copiedstring); >> > > You cannot cast a WCHAR* to a wchar_t*. > > -- Alexandre Julliard julliard(a)winehq.org Thanks, I assumed they were the same since under Windows WCHAR is typedef'ed as wchar_t. Is the proper way to handle this to use WideCharToMultiByte() on returnedstring and copiedstring, and then pass the converted (multibyte) strings to ok()? Christopher Berner

Feb. 29, 2008

Re: kernel32: Forward fiber local storage APIs to thread local storage equivalents.

by Paul Chitescu

Actually a lot of programs fail to start since the addition of these stubs. In particular anything that uses MSVCRT80. This is a major regression. Most applications seem to live a happy life without fiber local storage - is there one that would benefit from it? On Fri, 29 Feb 2008, Hans Leidekker wrote: > > Photoshop CS2 fails to start after the Fls* stubs were added. This patch > makes it start again but I'm not enough of an expert on this matter to say > if this is the right thing to do. > > -Hans > > Changelog > Forward fiber local storage APIs to thread local storage equivalents.

Feb. 29, 2008

Re: wine.inf: Create fake dll entry for dosx.exe

by Justin Chevrier

> Changelog: > > Create a fake dll entry for dosx.exe Anything wrong with this one liner? Justin Chevrier

Feb. 29, 2008

Re: kernel32 & winelib: Don't test string size in CompareStringW for null terminated strings

by James Hawkins

On Fri, Feb 29, 2008 at 11:06 AM, Robert Shearman <rob(a)codeweavers.com> wrote: > Adam Strzelecki wrote: > > During playing with installing Visual Studio 2005 with WINE I found > > out that WINE's MSI is spending lot of time inside lstrcmpW. With Mac > > OS X process sampler I checked that actually 60-70% of CompareStringW > > is wine_compare_string, rest is rest of function body, which is in > > case 2 strlenW calls (inline). > > I believe this isn't necessary, moreover most of compares in MSI are > > non-matching on first few characters, however with current > > implementation we go trough all strings with strlenW regardless of > > anything, which is waste in CPU cucles. > > I modified both CompareStringW and wine_compare_string so they work > > with -1 strings without strlenW checking before. > > This saves in my testing about 20-30% of CPU cycles. > > You introduce a lot of complexity into the low-level helper routines. We > don't want to put Win32 quirks, like -1 meaning "until the null > terminator" being put into the low-level functions unless we have to. In > this case, if this is the sole cause of the slowdown then you would be > better off caching the length at the MSI level since the strings are > bound to be accessed more than once. > > However, I think you'll find that this is an algorithm problem in MSI > rather than a performance issue in the functions you mention. By that, I > mean it is likely that one MSI query is being performed again and again > and that the results should be cached. > This is not the case at all. If you use native MSI, you'll see almost exactly the same number of string comparisons (give or take). I've rarely seen the same SQL query used multiple times with the exact same parameters. Caching would add too much complexity, and in normal cases, more processing time than time saved. > > > Note also that WINE's strlenW and lstrcmpW functions are far from > > perfect. Normal msvcrt or glibc string functions are far more > > optimized at machine code level. This makes strong impact on WINE > > parts strongly relaying on string manipulation which is in this case MSI. > > How do you know that the compiler isn't generating the same assembly for > the functions as that used by msvcrt / glibc? Theories like these need > numbers to back them up. > -- James Hawkins

Feb. 29, 2008

Re: msi: ACTION_RegisterProduct store all InstallProperties

by James Hawkins

On Fri, Feb 29, 2008 at 9:13 AM, Adam Strzelecki <ono(a)java.pl> wrote: > Hi, > > WINE is writing properties such as Language or VersionMajor only to > Uninstall key in ACTION_RegisterProduct, while MSI_GetProductInfo is > trying to read those from InstallProperties key. > > So this patch duplicates all properties written into MSI product > Uninstall key, also to InstallProperies. > This is normal behavior I can see in Windows XP's MSI, as properties > are duplicated in both Uninstall and InstallProperties. > Please do not accept this patch. I'm trying to clean up the publishing code, and without tests to prove this case, it should not go in. The tests that do exist show that the properties are written into the Uninstall key on RegisterProduct, but not the product key. -- James Hawkins

Feb. 29, 2008

Re: kernel32: Fix for WritePrivateProfileString Sharing Problem [2/2]

by Erich Hoover

On Fri, Feb 29, 2008 at 1:18 AM, James Hawkins <truiken(a)gmail.com> wrote: > > On Fri, Feb 29, 2008 at 1:17 AM, Erich Hoover <ehoover(a)mines.edu> wrote: > > > > On Thu, Feb 28, 2008 at 11:44 PM, James Hawkins <truiken(a)gmail.com> wrote: > > > > > > On Fri, Feb 29, 2008 at 12:29 AM, Erich Hoover <ehoover(a)mines.edu> wrote: > > > > Patch Originally From: > > > > Louis Lenders > > > > Description: > > > > This patch adds conformance tests for WritePrivateProfileString sharing > > > > problems. The patch was created by Louis Lenders and extensively tested, > > > > but never submitted (see Bug #5024). Please note that a couple of the tests > > > > now fail because cached profile information is returned, resolving that > > > > problem is outside the scope of these patches. > > > > Changelog: > > > > kernel32: Test for WritePrivateProfileString Sharing Permissions > > > > > > > > > > If a test fails, it has to be wrapped in todo_wine, else make test will fail. > > > > > > -- > > > James Hawkins > > > > > > > I would argue that make test should fail for regressions, though I > > don't know when exactly this particular problem surfaced. Re-ording > > the tests can actually mask the problem as well as inserting > > todo_wine, which would be preferred? > > > > Um make test does fail for regressions. make test fails if an ok call > fails and is not covered by todo_wine, and it also fails when a test > in a todo_wine block succeeds. That's how we keep track of the tests. > If reordering the tests masks the problem, what's the point of the > tests? > > -- > James Hawkins > The tests are for checking the sharing permissions problem, which causes WritePrivateProfileString to fail when the profile file is opened by CreateFile before WritePrivateProfileString is called. The tests failing now is a result of a problem with wine caching the profile information from when the call previously succeeded (the cache is not updated properly when the file is deleted). What I'm trying to say is that the tests are currently exposing a separate issue, so a separate set of tests would probably be appropriate - problems with caching are outside the scope of the patches I submitted. Erich Hoover ehoover(a)mines.edu

Feb. 29, 2008

Re: kernel32 & winelib: Don't test string size in CompareStringW for null terminated strings

by Robert Shearman

Adam Strzelecki wrote: > During playing with installing Visual Studio 2005 with WINE I found > out that WINE's MSI is spending lot of time inside lstrcmpW. With Mac > OS X process sampler I checked that actually 60-70% of CompareStringW > is wine_compare_string, rest is rest of function body, which is in > case 2 strlenW calls (inline). > I believe this isn't necessary, moreover most of compares in MSI are > non-matching on first few characters, however with current > implementation we go trough all strings with strlenW regardless of > anything, which is waste in CPU cucles. > I modified both CompareStringW and wine_compare_string so they work > with -1 strings without strlenW checking before. > This saves in my testing about 20-30% of CPU cycles. You introduce a lot of complexity into the low-level helper routines. We don't want to put Win32 quirks, like -1 meaning "until the null terminator" being put into the low-level functions unless we have to. In this case, if this is the sole cause of the slowdown then you would be better off caching the length at the MSI level since the strings are bound to be accessed more than once. However, I think you'll find that this is an algorithm problem in MSI rather than a performance issue in the functions you mention. By that, I mean it is likely that one MSI query is being performed again and again and that the results should be cached. > Note also that WINE's strlenW and lstrcmpW functions are far from > perfect. Normal msvcrt or glibc string functions are far more > optimized at machine code level. This makes strong impact on WINE > parts strongly relaying on string manipulation which is in this case MSI. How do you know that the compiler isn't generating the same assembly for the functions as that used by msvcrt / glibc? Theories like these need numbers to back them up. -- Rob Shearman

Feb. 29, 2008

Re: kernel32 & winex11: WaitForMultipleObjectsEx should ignore NULL handles

by Robert Shearman

Adam Strzelecki wrote: > Hi, > > In MSI dialog.c: msi_dialog_check_messages function it often happens > that is sends: > MsgWaitForMultipleObjects( 1, &handle, 0, INFINITE, QS_ALLINPUT ); > Where handle = NULL. I'm not sure if it is correct behavior. But > tracing it down I found out that kernel32 and winex11 sync functions > are not checking at all if the passes handles are not NULLs. > > So I'm not sure whether this patch is right or not, but I believe we > shouldn't bother wineserver with NULL handles!? > Yet maybe I don't understand clearly the way interserver communication > works, and sending "WaitFor" with NULL handle makes sense. Does it? No, but this is the wrong fix. You're assuming that because MSI code does action A and that causes bad effect when it does action B that the correct action is to fix B so that it doesn't have a bad effect. However, the bug could also be that action A shouldn't be done. In this case, MSI should not be calling MsgWaitForMultipleObjects with an invalid handle and in fact that barring memory corruption, this can't happen: > while (1) > { > msi_process_pending_messages( NULL ); > > if( !handle ) > break; > > /* > * block here until somebody creates a new dialog or > * the handle we're waiting on becomes ready > */ > r = MsgWaitForMultipleObjects( 1, &handle, 0, INFINITE, > QS_ALLINPUT ); > if( r == WAIT_OBJECT_0 ) > break; > } -- Rob Shearman

Feb. 29, 2008

Visual Studio 2005 installation finally works with WINE

by Adam Strzelecki

Hi, Hmm.. I think my last mail didn't manage to get into the list because of too big image attachements, sorry. If it does, I'm sorry for dupes. I just want to mention that I've managed to install Visual Studio 2005 completely with WINE. 1) installed "vcrun6" (with winetricks) 2) applied 1 patch from http://bugs.winehq.org/show_bug.cgi?id=8439#c3 (Required for overall installation) 3) applied patched from http://appdb.winehq.org/appview.php?iVersionId=3754 (Required for .NET 2.0 installation) 4) applied "msi: ACTION_RegisterProduct store all InstallProperties" patch from wine-patches I've sent recently (Without this patch Visual Studio 2005 will think that MS XML 6.0 and some others is still uninstalled!) Installation goes without problem, however running "devenv.exe" causes several problems with .NET 2.0 packages and crashes a lot :( too bad. Most crashes and errors are because of few missing WINE API functions, and incomplete .NET 2.0 support. Still I think WINE's close to run Visual Studio! which will be great news for multi-platform developers. See attached screenshots from my MacBook Pro running OSX 10.5.2 at: http://bugs.winehq.org/show_bug.cgi?id=8439 Cheers, -- Adam Strzelecki |: nanoant.com :|

Feb. 29, 2008

Visual Studio 2005 installation finally works with WINE

by Adam Strzelecki

Hi, I just want to mention that I've managed to install Visual Studio 2005 completely with WINE. 1) installed "vcrun6" (with winetricks) 2) applied 1 patch from http://bugs.winehq.org/show_bug.cgi?id=8439#c3 (Required for overall installation) 3) applied patched from http://appdb.winehq.org/appview.php?iVersionId=3754 (Required for .NET 2.0 installation) 4) applied "msi: ACTION_RegisterProduct store all InstallProperties" match from patches list I just sent (Without this patch Visual Studio 2005 will think that MS XML 6.0 and some others is still uninstalled!) Installation goes without problem, however running "devenv.exe" causes several problems with .NET 2.0 packages and crashes a lot :( too bad. Most crashes and errors are because of few missing WINE API functions, and incomplete .NET 2.0 support. Still I think WINE's close to run Visual Studio! which will be great news for multi-platform developers. See attached screenshots from my MacBook Pro running OSX 10.5.2. Cheers, -- Adam Strzelecki |: nanoant.com :|

Feb. 29, 2008

Re: New winetricks 20080226: adds dotnet11 verb

by bill lam

Lei Zhang wrote: > Can you file a bug on bugzilla and provide a sample image / test code > to demonstrate this problem? > Done. Test code is as follows, beware of line wrap. NB. tested on J602 beta / wine 0.9.56 NB. script to demostrate bug in GdipGetImageWidth GdipGetImageHeight NB. ========================================================= require 'dll' s=. 'Ok GenericError InvalidParameter OutOfMemory ObjectBusy InsufficientBuffer ' s=. s,'NotImplemented Win32Error WrongState Aborted FileNotFound ValueOverflow ' s=. s,'AccessDenied UnknownImageFormat FontFamilyNotFound FontStyleNotFound ' s=. s,'NotTrueTypeFont UnsupportedGdiplusVersion GdiplusNotInitialized ' s=. ;:s,'PropertyNotFound PropertyNotSupported ProfileNotFound' assi=: {::&s assert 0=] cdi=: (&cd)(assi@) PixelFormat32bppARGB=: 16b26200a GdiplusStartup =: 'gdiplus GdiplusStartup > i *i *i i ' &cd GdiplusShutdown =: 'gdiplus GdiplusShutdown > n i ' &cd GdipCreateBitmapFromFile =: 'gdiplus GdipCreateBitmapFromFile > i *w *i ' cdi GdipDisposeImage =: 'gdiplus GdipDisposeImage > i i ' cdi GdipBitmapLockBits =: 'gdiplus GdipBitmapLockBits > i i *i i i *i ' &cd GdipBitmapUnLockBits =: 'gdiplus GdipBitmapUnlockBits > i i *i ' cdi GdipGetImageWidth =: 'gdiplus GdipGetImageWidth > i i *i ' &cd GdipGetImageHeight =: 'gdiplus GdipGetImageHeight > i i *i ' &cd ImageLockModeRead=: 1 GUID=: 'WWWWXXYYZZZZZZZZ' BitmapData=: 'WdthHghtStrdFrmtScanRsrv' GdiplusStartupInput=: 1 0 0 0 readimg1=: 3 : 0 DATA=. i.4%~#BitmapData assi GdiplusStartup (TOK=. ,_1);GdiplusStartupInput;0 assi GdipCreateBitmapFromFile y;(BMP=. ,_1) assi GdipGetImageWidth ({.BMP);(Width=. ,_1) assi GdipGetImageHeight ({.BMP);(Height=. ,_1) 1!:2&2 'GdipGetImageWidth GdipGetImageHeight ', ": Width,Height rt=. 0 0, Width, Height assi GdipBitmapLockBits ({.BMP);rt;ImageLockModeRead;PixelFormat32bppARGB;DATA 'w h s f p r'=. DATA 1!:2&2 'width height stride format scan0 res ', ":DATA z=. |.^:(s<0) w&{."1^:(w~:|s%4) (h,|s%4)$memr p,((s<0)*s*<:h),(h*<.|s%4),JINT GdipBitmapUnLockBits ({.BMP);DATA GdipDisposeImage {.BMP GdiplusShutdown {.TOK '' ) NB. ========================================================= NB. run the script readimg1 'z:/tmp/2083.jpg'

Feb. 29, 2008

Re: New winetricks 20080226: adds dotnet11 verb

by James McKenzie

bill lam wrote: > If the user beware this possibility and write a more secure code, > GdipBitmapLockBits from wine's gdiplus will work. > > However this is another bug in wine gdiplus in that > value return from GdipGetImageWidth ( and GdipGetImageHeight ?) will often be 1 > pixel less than actual value, eg a jpeg of size 800x600 will be reported as > 799x600. The larger the picture size, the more often it goes wrong. > > This is a bug and should be reported. If this happens for any jpeg file then an attached file is unnecessary, but if you provide one that is 'more better' and will help. James McKenzie

Feb. 29, 2008

Re: Conformance tests for LoadStringW and LoadStringA

by Alexandre Julliard

Christopher <raccoonone(a)procyongames.com> writes: > + ok(!memcmp(copiedstring, returnedstring, (length2 + 1)*sizeof(WCHAR)), > + "LoadStringW returned a string that does not match the string pointed to by the pointer it returned. \ > + returnedstring = %ls, copiedstring = %ls", (wchar_t *)returnedstring, (wchar_t *)copiedstring); You cannot cast a WCHAR* to a wchar_t*. -- Alexandre Julliard julliard(a)winehq.org

Feb. 29, 2008

Re: New winetricks 20080226: adds dotnet11 verb

by Lei Zhang

On Fri, Feb 29, 2008 at 1:51 AM, bill lam <cbill.lam(a)gmail.com> wrote: > However this is another bug in wine gdiplus in that > value return from GdipGetImageWidth ( and GdipGetImageHeight ?) will often be 1 > pixel less than actual value, eg a jpeg of size 800x600 will be reported as > 799x600. The larger the picture size, the more often it goes wrong. Can you file a bug on bugzilla and provide a sample image / test code to demonstrate this problem?

Feb. 29, 2008

Re: gdi32: Move 16-bit printing functions to printdrv16.c.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > --- > dlls/gdi32/Makefile.in | 1 + > dlls/gdi32/printdrv.c | 752 > +--------------------------------------------- > dlls/gdi32/printdrv16.c | 779 > +++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 783 insertions(+), 749 deletions(-) That won't work, some of these functions are exported from gdi32. -- Alexandre Julliard julliard(a)winehq.org

Feb. 29, 2008

Re: dxdiagn: Fix the variable that the result of GetFileVersionInfoW is assigned to in DXDiag_AddFileDescContainer.

by Robert Shearman

Paul Vriens wrote: > Robert Shearman wrote: >> --- >> dlls/dxdiagn/provider.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> >> ------------------------------------------------------------------------ >> >> > > Is there a need to have it assigned, as the next line overwrites > boolret again? When somebody bothers to actually do some error checking in the function it will be a better starting point. -- Rob Shearman

Feb. 29, 2008

Re: dxdiagn: Fix the variable that the result of GetFileVersionInfoW is assigned to in DXDiag_AddFileDescContainer.

by Paul Vriens

Robert Shearman wrote: > --- > dlls/dxdiagn/provider.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > Hi Rob, Is there a need to have it assigned, as the next line overwrites boolret again? -- Cheers, Paul.

Feb. 29, 2008

Re: [PATCH] shlwapi: Handle PathCanonicalize with too long paths

by Robert Shearman

Marcus Meissner wrote: > lpszPath) > { > WCHAR szPath[MAX_PATH]; > WCHAR szBuff[MAX_PATH]; > - MultiByteToWideChar(CP_ACP,0,lpszPath,-1,szPath,MAX_PATH); > + DWORD le = GetLastError(); > + int ret = MultiByteToWideChar(CP_ACP,0,lpszPath,-1,szPath,MAX_PATH); > + > + if (!ret) { > + FIXME("Failed to convert string to widechar (too long?), LE %d.\n", GetLastError()); > + SetLastError (le); /* failure does not change Lasterror, see testcase. */ > + return FALSE; > + } > Hi Marcus, FIXME should be used for unimplemented functionality, not for highlighting application bugs that will happen on Windows too. WARN would be more appropriate here. -- Rob Shearman

Feb. 29, 2008

Re: New winetricks 20080226: adds dotnet11 verb

by bill lam

James Hawkins wrote: > On Thu, Feb 28, 2008 at 10:07 PM, bill lam <cbill.lam(a)gmail.com> wrote: >> I patched platimg to work with negative stride and now it works with wine >> built-in gdiplus. >> >> FYI, native gdiplus gives a top-down bitmap but wine's gdiplus gives a >> bottom-up. It is not a bug in wine's but might causes compatibility problem. >> > > How is it not a bug? > If the user beware this possibility and write a more secure code, GdipBitmapLockBits from wine's gdiplus will work. However this is another bug in wine gdiplus in that value return from GdipGetImageWidth ( and GdipGetImageHeight ?) will often be 1 pixel less than actual value, eg a jpeg of size 800x600 will be reported as 799x600. The larger the picture size, the more often it goes wrong. regards,

Feb. 29, 2008

Re: kernel32: Fix for WritePrivateProfileString Sharing Problem [2/2]

by James Hawkins

On Fri, Feb 29, 2008 at 1:17 AM, Erich Hoover <ehoover(a)mines.edu> wrote: > > On Thu, Feb 28, 2008 at 11:44 PM, James Hawkins <truiken(a)gmail.com> wrote: > > > > On Fri, Feb 29, 2008 at 12:29 AM, Erich Hoover <ehoover(a)mines.edu> wrote: > > > Patch Originally From: > > > Louis Lenders > > > Description: > > > This patch adds conformance tests for WritePrivateProfileString sharing > > > problems. The patch was created by Louis Lenders and extensively tested, > > > but never submitted (see Bug #5024). Please note that a couple of the tests > > > now fail because cached profile information is returned, resolving that > > > problem is outside the scope of these patches. > > > Changelog: > > > kernel32: Test for WritePrivateProfileString Sharing Permissions > > > > > > > If a test fails, it has to be wrapped in todo_wine, else make test will fail. > > > > -- > > James Hawkins > > > > I would argue that make test should fail for regressions, though I > don't know when exactly this particular problem surfaced. Re-ording > the tests can actually mask the problem as well as inserting > todo_wine, which would be preferred? > Um make test does fail for regressions. make test fails if an ok call fails and is not covered by todo_wine, and it also fails when a test in a todo_wine block succeeds. That's how we keep track of the tests. If reordering the tests masks the problem, what's the point of the tests? -- James Hawkins

Feb. 29, 2008

Re: kernel32: Fix for WritePrivateProfileString Sharing Problem [2/2]

by Erich Hoover

On Thu, Feb 28, 2008 at 11:44 PM, James Hawkins <truiken(a)gmail.com> wrote: > > On Fri, Feb 29, 2008 at 12:29 AM, Erich Hoover <ehoover(a)mines.edu> wrote: > > Patch Originally From: > > Louis Lenders > > Description: > > This patch adds conformance tests for WritePrivateProfileString sharing > > problems. The patch was created by Louis Lenders and extensively tested, > > but never submitted (see Bug #5024). Please note that a couple of the tests > > now fail because cached profile information is returned, resolving that > > problem is outside the scope of these patches. > > Changelog: > > kernel32: Test for WritePrivateProfileString Sharing Permissions > > > > If a test fails, it has to be wrapped in todo_wine, else make test will fail. > > -- > James Hawkins > I would argue that make test should fail for regressions, though I don't know when exactly this particular problem surfaced. Re-ording the tests can actually mask the problem as well as inserting todo_wine, which would be preferred? Erich Hoover ehoover(a)mines.edu

Feb. 29, 2008

Re: kernel32: Fix for WritePrivateProfileString Sharing Problem [2/2]

by James Hawkins

On Fri, Feb 29, 2008 at 12:29 AM, Erich Hoover <ehoover(a)mines.edu> wrote: > Patch Originally From: > Louis Lenders > Description: > This patch adds conformance tests for WritePrivateProfileString sharing > problems. The patch was created by Louis Lenders and extensively tested, > but never submitted (see Bug #5024). Please note that a couple of the tests > now fail because cached profile information is returned, resolving that > problem is outside the scope of these patches. > Changelog: > kernel32: Test for WritePrivateProfileString Sharing Permissions > If a test fails, it has to be wrapped in todo_wine, else make test will fail. -- James Hawkins

Feb. 29, 2008

Re: New winetricks 20080226: adds dotnet11 verb

by James Hawkins

On Thu, Feb 28, 2008 at 10:07 PM, bill lam <cbill.lam(a)gmail.com> wrote: > I patched platimg to work with negative stride and now it works with wine > built-in gdiplus. > > FYI, native gdiplus gives a top-down bitmap but wine's gdiplus gives a > bottom-up. It is not a bug in wine's but might causes compatibility problem. > How is it not a bug? -- James Hawkins

Feb. 29, 2008

Re: New winetricks 20080226: adds dotnet11 verb

by bill lam

I patched platimg to work with negative stride and now it works with wine built-in gdiplus. FYI, native gdiplus gives a top-down bitmap but wine's gdiplus gives a bottom-up. It is not a bug in wine's but might causes compatibility problem.

Feb. 29, 2008