cross-compiler availability (was Re: Wine on cygwin)
I think on most shells, you need to backslash escape the "*" - i.e. yum install mingw32\* Just to cover all grounds, I came across the opensuse location of SuSE cross-compiler recently on the mono web site. (search in http://www.go-mono.com or www.mono-project.com) since win32 mono can be cross-built, and ximian/mono/suse/novell is one big family... --- On Sun, 26/7/09, King InuYasha wrote: > If you are using Fedora, "yum install > mingw32*" will install the whole cross-compiling > suite. > > On Sat, Jul 25, 2009 at 6:39 PM, > Austin English > wrote: > The cygwin build is pretty broken...you can > build the tests for > > windows really easily on Linux/Unix if you install mingw. > > > > Just 'sudo apt-get/yum/etc. install mingw', then > ./configure in your > > wine tree. Use 'make crosstest' to build the > windows tests. > > > > -- > > -Austin >
Spotted on Reddit's frontpage [ wine-patches the black hole of code? ]
Spotted on Reddit's frontpage wine-patches the black hole of code? http://kazade.livejournal.com/2451.html Access Yahoo!7 Mail on your mobile. Anytime. Anywhere. Show me how: http://au.mobile.yahoo.com/mail
Re: [2/5] ntdll/tests: Implement tests for data execution prevention.
"Michael Karcher" wrote: The tests will be skipped on Wine until next patch, as the not-yet-implemented NtQueryInformationProcess(...,ProcessExecuteFlags,...,...) call is used to detect a DEP-capable platform. These tests should added to existing dlls/ntdll/tests/exception.c framework. -- Dmitry.
Re: [1/5] ntdll: Fix ProcessExecuteFlag logic
"Michael Karcher" wrote: The meaning of "enable" is the same in Windows and Wine: it enables the execute permission, not the data execution prevention. This patch precedes the test as the inverted logic would make the test case fail in interesting ways. There is no sense in first adding a lot of (partly conditional) todo_wines to the test just to make this fix come later. JFYI, I based my original patch on the information at http://www.uninformed.org/?v=2&a=4 (To enable NX support, the MEM_EXECUTE_OPTION_DISABLE flag (0x1) is specified. To disable NX support, the MEM_EXECUTE_OPTION_ENABLE flag (0x2) is specified) and Chromium sources: http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/dep.cc -- Dmitry.
Re: Help resources for wine-users mailing list
André Hentschel wrote: > Austin English schrieb: >> 2009/7/26 Frédéric Delanoy : >>> Over and over, I see help requests on wine-users with responses like >>> "installed latest wine", "read FAQ section x.y", ... >>> >>> Wouldn't it be useful to send a regular reminder (like every month, >>> and on subscription)? >>> This would contain: >>> - how to upgrade to latest version >>> - link to FAQ >>> - link to bugzilla + how to look for dups before creating new bugs >>> - >>> >>> This would avoid countless identical responses to common problems, >>> and help reduce >>> traffic on wine-users, hence concentrating on "difficult" problems. >> >> Keep in mind that most of the traffic now is on the forums (traffic >> exploded after adding it). There's already a sticky saying to read the >> FAQ...we could add a second sticky with a few basic questions/answers, >> but I'm not sure how much good it would do. >> > if a user is too lazy to update or to read the FAQ, i think a reminder > wouldnt help. > And I like the DEMAND messages, like fix this now!!! (and I'm not exaggerating either.) We need to let folks know that this is a FOSS project and that there is NO commercial sponsorship, unlike OpenOffice.org which still has SUN/Oracle as a sponsor. Non-withstanding the fact that CodeWeavers sponsors the web site, but they do not sponsor the project, but do provide a version of Wine with support. Most of the technical support is volunteer and at the person's ability to help and to provide guidance. James McKenzie
Re: RFC XRender add support for dibsections in more color depths
Hi all,
This is an updated version of my patch. It should fix the XChangeGC
crash but the text color issue in that japanese game is still around.
I hope to receive some more feed back.
Roderick
On Sat, Jul 25, 2009 at 11:20 PM, Jesse Allen wrote:
> On Thu, Jul 23, 2009 at 2:51 PM, Roderick
> Colenbrander wrote:
>> Hi,
>>
>> For some weeks I have been working on moving more 2D rendering to
>> XRender. XRender has three advantages for Wine. First of all it allows
>> us to perform more rendering operations using X which we previously
>> did using a combination of software rendering and back-forth copying
>> between the Xserver. Second XRender offers depth conversion (this
>> gives us proper alpha support in Wine and allows us to bypass DIB
>> color conversion in some cases!). Third XRender brings us more
>> hardware acceleration and that way more performance.
>>
>> The patch attached to this thread adds support for dibsections in
>> additional color depths. On Xservers running at 24-bit this patch
>> offers us dibsections in 1-bit/15-bit/16-bit/24-bit/32-bit. (32-bit is
>> for proper alpha support) Big parts of the Wine X11 Driver make
>> assumptions about having only two color depths around (1-bit and
>> screen_depth e.g. 24-bit). I would like to request that people apply
>> the current patch to latest git (in combination with the Office2007
>> patch which I posted to wine-patches). Please report any 2D rendering
>> issues you see and also mention possible Wine crashes due to X errors
>> like BadMatch. Try as much programs as possible.
>>
>> Thanks in advance,
>> Roderick Colenbrander
>>
>>
>>
>>
>
>
>
> Very nice Roderick, it seems to be working on my system with
> StarEdit.exe where it is faster. It seems like it could be a good
> solution.
>
> Jesse
>
From 80f7325253f8b38750398daf044f7c6e32f772e1 Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander
Date: Sun, 26 Jul 2009 22:35:59 +0200
Subject: [PATCH] Add support for dibsections in more formats when XRender is around.
---
dlls/winex11.drv/bitmap.c |1 +
dlls/winex11.drv/brush.c | 16 +++--
dlls/winex11.drv/dib.c | 11 +++-
dlls/winex11.drv/x11drv.h |1 +
dlls/winex11.drv/xrender.c | 140
5 files changed, 161 insertions(+), 8 deletions(-)
diff --git a/dlls/winex11.drv/bitmap.c b/dlls/winex11.drv/bitmap.c
index a288352..03e78a0 100644
--- a/dlls/winex11.drv/bitmap.c
+++ b/dlls/winex11.drv/bitmap.c
@@ -161,6 +161,7 @@ BOOL CDECL X11DRV_CreateBitmap( X11DRV_PDEVICE *physDev, HBITMAP hbitmap, LPVOID
physBitmap->pixmap_depth = (bitmap.bmBitsPixel == 1) ? 1 : screen_depth;
physBitmap->pixmap = XCreatePixmap(gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight, physBitmap->pixmap_depth);
+//ERR("hbitmap=%p pixmap_depth=%d pixmap=%p\n", hbitmap, physBitmap->pixmap_depth, physBitmap->pixmap);
wine_tsx11_unlock();
if (!physBitmap->pixmap)
{
diff --git a/dlls/winex11.drv/brush.c b/dlls/winex11.drv/brush.c
index c94e04e..37d5e1f 100644
--- a/dlls/winex11.drv/brush.c
+++ b/dlls/winex11.drv/brush.c
@@ -204,7 +204,8 @@ static void BRUSH_SelectSolidBrush( X11DRV_PDEVICE *physDev, COLORREF color )
}
}
-
+//this will be moved to x11drv.h later on
+BOOL X11DRV_XRender_CopyBrush(X11DRV_PDEVICE *physDev, X_PHYSBITMAP *physBitmap, int width, int height);
/***
* BRUSH_SelectPatternBrush
*/
@@ -215,25 +216,26 @@ static BOOL BRUSH_SelectPatternBrush( X11DRV_PDEVICE *physDev, HBITMAP hbitmap )
if (!physBitmap || !GetObjectW( hbitmap, sizeof(bitmap), &bitmap )) return FALSE;
-wine_tsx11_lock();
if ((physDev->depth == 1) && (physBitmap->pixmap_depth != 1))
{
+wine_tsx11_lock();
/* Special case: a color pattern on a monochrome DC */
physDev->brush.pixmap = XCreatePixmap( gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight, 1);
/* FIXME: should probably convert to monochrome instead */
XCopyPlane( gdi_display, physBitmap->pixmap, physDev->brush.pixmap,
get_bitmap_gc(1), 0, 0, bitmap.bmWidth, bitmap.bmHeight, 0, 0, 1 );
+wine_tsx11_unlock();
}
else
{
physDev->brush.pixmap = XCreatePixmap( gdi_display, root_window,
bitmap.bmWidth, bitmap.bmHeight,
- physBitmap->pixmap_depth );
-XCopyArea( gdi_display, physBitmap->pixmap, physDev->brush.pixmap,
- get_bitmap_gc(physBitmap->pixmap_depth), 0, 0, bitmap.bmWidth, bitmap.bmHeight, 0, 0 );
+ physDev->depth );
+
+/* XRender is needed because of possible depth conversion */
+X11DRV_XRender_CopyBrush(physDev, physBitmap, bitmap.bmWidth, bitmap.bmHeight);
}
-
Re: Help resources for wine-users mailing list
>> Keep in mind that most of the traffic now is on the forums (traffic >> exploded after adding it). There's already a sticky saying to read the >> FAQ...we could add a second sticky with a few basic questions/answers, >> but I'm not sure how much good it would do. >> > if a user is too lazy to update or to read the FAQ, i think a reminder > wouldnt help. Well I never went on the forums but read wine-users only via the mailing list, but apparently I'm an exception here ;)
Re: Help resources for wine-users mailing list
On Sun, 26 Jul 2009 19:47:05 +0200 André Hentschel wrote: > Austin English schrieb: > > 2009/7/26 Frédéric Delanoy : > >> Over and over, I see help requests on wine-users with responses like > >> "installed latest wine", "read FAQ section x.y", ... > >> > >> Wouldn't it be useful to send a regular reminder (like every month, and on > >> subscription)? > >> This would contain: > >> - how to upgrade to latest version > >> - link to FAQ > >> - link to bugzilla + how to look for dups before creating new bugs > >> - > >> > >> This would avoid countless identical responses to common problems, and > >> help reduce > >> traffic on wine-users, hence concentrating on "difficult" problems. > > > > Keep in mind that most of the traffic now is on the forums (traffic > > exploded after adding it). There's already a sticky saying to read the > > FAQ...we could add a second sticky with a few basic questions/answers, > > but I'm not sure how much good it would do. > > > if a user is too lazy to update or to read the FAQ, i think a reminder > wouldnt help. > > -- I agree. Those repetitive questions mainly come from users who join the list/forum and immediately post their problem/question without ever bothering to read anything. However, looking at the stickies on the forum, I think there should be a more direct one to the FAQ. Right now, to get to the FAQ from the forum, users have to click on the "Sticky: Welcome to the WineHQ Forums (New User Guide)" thread, then click on "Read the Guide" in the only post in that thread, which will take them to the Forum Guidelines wiki page, where they must then click on the FAQ link to get to the actual FAQ. That's an awful lot of levels to have to go through. A sticky labeled something like "FAQ--read before posting" with a direct link to the FAQ might help. -- Rosanne DiMesio
Re: Help resources for wine-users mailing list
Austin English schrieb: 2009/7/26 Frédéric Delanoy : Over and over, I see help requests on wine-users with responses like "installed latest wine", "read FAQ section x.y", ... Wouldn't it be useful to send a regular reminder (like every month, and on subscription)? This would contain: - how to upgrade to latest version - link to FAQ - link to bugzilla + how to look for dups before creating new bugs - This would avoid countless identical responses to common problems, and help reduce traffic on wine-users, hence concentrating on "difficult" problems. Keep in mind that most of the traffic now is on the forums (traffic exploded after adding it). There's already a sticky saying to read the FAQ...we could add a second sticky with a few basic questions/answers, but I'm not sure how much good it would do. if a user is too lazy to update or to read the FAQ, i think a reminder wouldnt help. -- Best Regards, André Hentschel
Re: Help resources for wine-users mailing list
2009/7/26 Frédéric Delanoy : > Over and over, I see help requests on wine-users with responses like > "installed latest wine", "read FAQ section x.y", ... > > Wouldn't it be useful to send a regular reminder (like every month, and on > subscription)? > This would contain: > - how to upgrade to latest version > - link to FAQ > - link to bugzilla + how to look for dups before creating new bugs > - > > This would avoid countless identical responses to common problems, and help > reduce > traffic on wine-users, hence concentrating on "difficult" problems. Keep in mind that most of the traffic now is on the forums (traffic exploded after adding it). There's already a sticky saying to read the FAQ...we could add a second sticky with a few basic questions/answers, but I'm not sure how much good it would do. -- -Austin
Help resources for wine-users mailing list
Over and over, I see help requests on wine-users with responses like "installed latest wine", "read FAQ section x.y", ... Wouldn't it be useful to send a regular reminder (like every month, and on subscription)? This would contain: - how to upgrade to latest version - link to FAQ - link to bugzilla + how to look for dups before creating new bugs - This would avoid countless identical responses to common problems, and help reduce traffic on wine-users, hence concentrating on "difficult" problems. Frédéric
Re: comctl32: stop flicker when drawing themed
On 26.07.2009 15:57, André Hentschel wrote: > ...and draw the correct image smothly. > the code shouldnt have been copied and paste from the unthemed code. This changes the appearance of progress bars: now they look always "smooth" when themed. But on Windows they look always "chunky" when themed. -f.r.
Re: ntdll: spellingfix in a comment
On 07/26/2009 03:59 PM, André Hentschel wrote: > Frédéric Delanoy schrieb: >> On 07/26/2009 02:37 PM, André Hentschel wrote: >>> --- >>> dlls/ntdll/server.c |2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> >>> >>> >>> >> >> iff could be an abbreviation for "if and only if" (equivalence >> relationship), >> so it may not be an error after all (but I haven't checked the code). >> >> Frédéric >> >> >> > Didnt knew that. I also didnt checked the code, i just saw the two f's > and fixed them. > So it might be wrong. > After some checking, the original iff is correct (even if the value of needs_close parameter is currently discarded, but that's an other story]). So this patch should be discarded IMO
Re: ntdll: spellingfix in a comment
Frédéric Delanoy schrieb: On 07/26/2009 02:37 PM, André Hentschel wrote: --- dlls/ntdll/server.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) iff could be an abbreviation for "if and only if" (equivalence relationship), so it may not be an error after all (but I haven't checked the code). Frédéric Didnt knew that. I also didnt checked the code, i just saw the two f's and fixed them. So it might be wrong. -- Best Regards, André Hentschel
Re: ntdll: spellingfix in a comment
On 07/26/2009 02:37 PM, André Hentschel wrote: > --- > dlls/ntdll/server.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > iff could be an abbreviation for "if and only if" (equivalence relationship), so it may not be an error after all (but I haven't checked the code). Frédéric
Re: Wine on cygwin
Am Sunday 26 July 2009 01:53:46 schrieb King InuYasha:
> > > .section ".init","ax"
> > > yields
> > > a.0dtc3a.s: Assembler messages:
> > > a.0dtc3a.s:5: Error: junk at end of line, first unrecognized character
> > > is `"'
> > >
> > > Then there is:
> > > .hidden __wine_spec_nt_header
> > > =>
> > > a.0dtc3a.s:14: Error: unknown pseudo-op: `.hidden'
> > >
> > > .type __wine_stub_EditAuditInfo,@function
> > > =>
> > > a.iNk2s9.s:81: Warning: .type pseudo-op used outside of .def/.endef
I think winebuild has some problems. I sent one patch for this, but more is
remaining. This is a "git diff" from my Wine tree on my windows
partition(mostly used for D3D testing, so there are some unrelated things in
it).
Its mostly a matter of opening the right files in binary mode(Not sure how
much that matters on cygwin though, it does on mingw). Also you have to run
configure with CFLAGS=-D_WINDOWS because of the code in
tools/winebuild/main.c, line 69. I think the correct define to check is
__WIN32__, but I am not sure.
diff --git a/dlls/d3d9/directx.c b/dlls/d3d9/directx.c
index e9547a7..7521375 100644
--- a/dlls/d3d9/directx.c
+++ b/dlls/d3d9/directx.c
@@ -123,6 +123,8 @@ static HRESULT WINAPI IDirect3D9Impl_GetAdapterIdentifier(LPDIRECT3D9EX iface, U
EnterCriticalSection(&d3d9_cs);
hr = IWineD3D_GetAdapterIdentifier(This->WineD3D, Adapter, Flags, &adapter_id);
LeaveCriticalSection(&d3d9_cs);
+
+strcpy(pIdentifier->Description, "NVIDIA GeForce Go 7400 ");
return hr;
}
diff --git a/dlls/d3d9/tests/visual.c b/dlls/d3d9/tests/visual.c
index 23258cc..45af3fe 100644
--- a/dlls/d3d9/tests/visual.c
+++ b/dlls/d3d9/tests/visual.c
@@ -1204,6 +1204,8 @@ static void offscreen_test(IDirect3DDevice9 *device)
IDirect3DTexture9 *offscreenTexture = NULL;
IDirect3DSurface9 *backbuffer = NULL, *offscreen = NULL;
DWORD color;
+RECT scissor;
+D3DVIEWPORT9 vp;
static const float quad[][5] = {
{-0.5f, -0.5f, 0.1f, 0.0f, 0.0f},
@@ -1256,6 +1258,23 @@ static void offscreen_test(IDirect3DDevice9 *device)
if(IDirect3DDevice9_BeginScene(device) == D3D_OK) {
hr = IDirect3DDevice9_SetRenderTarget(device, 0, offscreen);
ok(hr == D3D_OK, "SetRenderTarget failed, hr = %08x\n", hr);
+
+/* Test how the SetRenderTarget affects viewport and scissor rectangle */
+hr = IDirect3DDevice9_GetScissorRect(device, &scissor);
+ok(hr == D3D_OK, "IDirect3DDevice9_GetScissorRect failed, hr = %08x\n", hr);
+ok(scissor.top == 0, "Scissor rect top is %d, expected 0\n", scissor.top);
+ok(scissor.left == 0, "Scissor rect left is %d, expected 0\n", scissor.left);
+ok(scissor.right == 128, "Scissor rect right is %d, expected 128\n", scissor.right);
+ok(scissor.bottom == 128, "Scissor rect bottom is %d, expected 128\n", scissor.bottom);
+hr = IDirect3DDevice9_GetViewport(device, &vp);
+ok(hr == D3D_OK, "IDirect3DDevice9_GetViewport failed, hr = %08x\n", hr);
+ok(vp.X == 0, "Expected viewport X = 0, got %d\n", vp.X);
+ok(vp.Y == 0, "Expected viewport Y = 0, got %d\n", vp.Y);
+ok(vp.Width == 128, "Expected viewport Width = 128, got %d\n", vp.Width);
+ok(vp.Height == 128, "Expected viewport Height = 128, got %d\n", vp.Height);
+ok(vp.MinZ == 0.0, "Expected viewport MinZ = 0.0, got %f\n", vp.MinZ);
+ok(vp.MaxZ == 1.0, "Expected viewport MinZ = 1.0, got %f\n", vp.MaxZ);
+
hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET, 0x00ff, 0.0, 0);
ok(hr == D3D_OK, "Clear failed, hr = %08x\n", hr);
diff --git a/dlls/d3d9/version.rc b/dlls/d3d9/version.rc
index 99b7c76..29d11b3 100644
--- a/dlls/d3d9/version.rc
+++ b/dlls/d3d9/version.rc
@@ -16,11 +16,11 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
*/
-#define WINE_FILEDESCRIPTION_STR "Wine Direct3D"
-#define WINE_FILENAME_STR "d3d9.dll"
-#define WINE_FILEVERSION 5,3,1,904
-#define WINE_FILEVERSION_STR "5.3.1.904"
-#define WINE_PRODUCTVERSION 5,3,1,904
+//#define WINE_FILEDESCRIPTION_STR "Wine Direct3D"
+//#define WINE_FILENAME_STR "d3d9.dll"
+//#define WINE_FILEVERSION 5,3,1,904
+//#define WINE_FILEVERSION_STR "5.3.1.904"
+//#define WINE_PRODUCTVERSION 5,3,1,904
#define WINE_PRODUCTVERSION_STR "5.3.1.904"
-#include "wine/wine_common_ver.rc"
+//#include "wine/wine_common_ver.rc"
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 536d7a4..0947fc9 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -3759,6 +3759,23 @@ static HRESULT WINAPI IWineD3DImpl_CreateDevice(IWineD3D *iface, UINT Adapter,
struct shader_caps shader_caps;
HRESULT hr;
+ERR("Create!!\n");
+ERR("Create!!\n");
+ERR("Create!!\n");
+ERR("Create!!\n");
+ERR("Create!!\n");
+ERR("Create!!\n");
+ERR("Create!!\n");
+ERR("Create!!\n");
+ERR("Create!!\n");
+ERR("Create
