Re: RFC: XEmbed Systray Patches
On Tue, 2006-08-08 at 13:48 +0100, Mike Hearn wrote: It's not that we need to slow it down - slowing something down is never an acceptable solution to a race. We are missing some kind of synchronisation somewhere, Actually, I don't think it has to do with synchronization--I think it has to do with window mapping. Today I did some more research on the issue, and I came across the XEmbed spec, and there's a pretty interesting tidbit in there [1] (look under the XEMBED_MAPPED section.) The problem is that the systray window has to be unmapped so that when we dock, the embedder (the systray applet that holds the icon) has to map the client (the systray icon) itself--we can't do it in WINE or we risk having the race conditions that we do (where the window becomes visible as a child of the root window and not the tray, or sometimes both the root window and tray) So here's the solution that I'm currently using to solve it: don't call XMapWindow on systray icon windows. That combined with the mapped flag in the XEMBED_INFO array we set just before we dock the icon allows it to work properly. I've run my small test app over 50 times straight (probably more by now--I've lost count,) and it works. I'll do some more tests to make sure everything is good, and hone my solution a little before submitting. The problem with this is that we probably want mapping if we don't have a tray to send our icon to, so I'll be playing with getting that to work cleanly. James Notes: [1]: http://standards.freedesktop.org/xembed-spec/latest/ar01s04.html
Re: wineconsole: command line option output / default user backend
Kuba Ober wrote: Popping up console windows is equal to not working for me. (...) Also, I'd love it a lot if all the ncurses crap was avoided. The compilers output plain text on the standard output (whatever that is on windows). Why don't you just use wcmd app? As I gather, wineconsole is for providing a Windows console environment. Unfortunately, the ncurses implementation seems to be broken (doesn't work properly on my box), that's why I suggest using a separate window, because it works. For running text-mode applications that don't need a user interface, you can use wcmd stand-alone.
Re: wineconsole: command line option output / default user backend
Alexandre Julliard wrote: Your mailer wrapped the patch, please resend it. How? Do you think it will work as an attachment? I'm using Mozilla Mail. Also please send separate changes as separate patches, OK and try to follow the coding conventions of the surrounding code. I will have another look at it shortly. After apparently 7 years of no-one doing anything on that code, I think a couple of days in delay will not hurt! ;-) This is also the first time I ever contributed to an open-source project! So, the entire thing is new to me! :-) I would also like to replace WCMD with a compatible, but much better version, sometime. How would I go about that? Can I provide a patch for a whole folder?
Re: riched20: new selection invalidation logic
Vitaliy Margolen wrote:
I don't see how that can be if users report crashes immediately when installer
tries to show licence. Or when user tries to scroll text to the bottom so Next
button will become enabled.
It doesn't happen on my machine on installers I've tried (including the
infamous NSIS), so it's not because of lack of testing at all. In fact,
I still don't know why it happens on one machine and not another.
Anyway, the issue is not easy to solve, so I'd be grateful for any ideas
that may help in solving this important issue.
_TRY
{
call riched20
}
_EXCEPT(handler)
_ENDTRY
Seems like easy to me.
How does that solve the improper operation vs lack of bug reports issue?
Do we want to have buggy richedit forever?
Unless you put some mail sending code in the exception handler. But that
qualifies as spyware and shouldn't happen.
Krzysztof
Re: riched20: new selection invalidation logic
Vitaliy Margolen wrote: upset. Users will have their functioning installers and you will have your error reports. I will have my error reports? How exactly will I get them? Does average user (or Wine) send us err: error reports? If he/she usually had, this would be a non-issue, and asserts could be replaced with if (!condition) ERR(...). Krzysztof
Re: wineconsole: command line option output / configurable default backend
Wednesday, August 9, 2006, 2:33:17 AM, Ekkehard Morgenstern wrote: This patch is akin to the previously posted; however, instead of making the user backend the default, I read an environment variable WINECONBACKEND to determine the default. If the value isn't set, curses will be the default as in the original code. You patch wrapped again. Please attach it to the e-mail instead. Vitaliy.
Re: wineconsole: command line option output / configurable default backend
You patch wrapped again. Please attach it to the e-mail instead. Vitaliy. Are you sure? It doesn't wrap in Mozilla Mail unless it crosses window borders. I've checked it multiple times and tried out different window sizes in the mail viewer. In the Mail config, I set the margin to 512 characters. But okay, I'll resend it attached this time.
Re: wineconsole: command line option output / configurable default backend
Ekkehard Morgenstern [EMAIL PROTECTED] writes: This patch is akin to the previously posted; however, instead of making the user backend the default, I read an environment variable WINECONBACKEND to determine the default. I don't think that's an improvement, please let's not add more obscure environment variables. You should try to use the user backend when the X display is available and fall back to curses otherwise. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wineconsole: command line option output / default user backend
Ekkehard Morgenstern [EMAIL PROTECTED] writes: I would also like to replace WCMD with a compatible, but much better version, sometime. How would I go about that? Can I provide a patch for a whole folder? The usual way is to fix one bug at a time... If you are suggesting a complete rewrite you'll need to make a very convincing case that throwing away the existing code is preferable to fixing it. -- Alexandre Julliard [EMAIL PROTECTED]
Re: ntdll: make shared user data access work
Robert Reif [EMAIL PROTECTED] writes: diff -p -u -r1.66 thread.c --- dlls/ntdll/thread.c 26 Jul 2006 14:01:20 - 1.66 +++ dlls/ntdll/thread.c 6 Aug 2006 01:15:43 - @@ -215,7 +215,7 @@ HANDLE thread_init(void) addr = (void *)0x7ffe; size = 0x1; -NtAllocateVirtualMemory( NtCurrentProcess(), addr, 0, size, MEM_RESERVE, PAGE_READONLY ); +NtAllocateVirtualMemory( NtCurrentProcess(), addr, 0, size, MEM_RESERVE | MEM_COMMIT, PAGE_READONLY); This code is only intended to reserve the space at startup. We need to initialize it properly later on before making it accessible. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wineconsole: command line option output / configurable default backend
Alexandre Julliard wrote: I don't think that's an improvement, please let's not add more obscure environment variables. You should try to use the user backend when the X display is available and fall back to curses otherwise. How should I check if the X Display is available? The DISPLAY environment variable doesn't suffice for that. It might be set, but the connection might be unavailable anyway. Or some user that doesn't have X Windows might use the DISPLAY variable for something else. Not a good idea IMO.
Re: wineconsole: command line option output / configurable default backend
Ekkehard Morgenstern [EMAIL PROTECTED] writes: How should I check if the X Display is available? Try to create the console window, it should fail if X is not available. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wineconsole: command line option output / default user backend
Alexandre Julliard wrote: The usual way is to fix one bug at a time... If you are suggesting a complete rewrite you'll need to make a very convincing case that throwing away the existing code is preferable to fixing it. Well, WCMD allows only 2 arguments, for instance. IMNSHO the code is effed-up beyond repair, and I would rather rewrite it than expand on it. But I won't bother writing a replacement if it's not desired by the WINE community. What I want to do is basically provide a true reimplementation of Windows' CMD.EXE program, including, but not limited to, all commands that are available on Windows XP. Extensions I plan to include are graphics commands and more console control commands, among others. Plus more ksh-like redirection operators. CMD.EXE already supports a few, and I would add the full suite. The extensions would check if a Wine console window was present by calling GetConsoleWindow() (which is currently not implemented) and posting a message there that would alter the screen font, cursor location, color, etc.
Re: oleaut32: Add tmarshal conformance test
Dan Hipschman [EMAIL PROTECTED] writes:
This adds a conformance test written by Rob Shearman. Pretty much all the
code in the four files beginning with tmarshal is his. All I did was make
some changes to the Makefiles to be able to test things with IDL components,
and I tweaked his stuff in one or two places where needed. For example, I
wrapped the tests that failed in todo_wine blocks, and I commented out a test
that crashes Wine. All the tests pass on Windows (including the one that
crashes Wine).
They don't work on Wine here:
../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p
oleaut32_test.exe.so tmarshal.c touch tmarshal.ok
fixme:ole:ITypeInfo_fnRelease destroy child objects
err:ole:marshal_object couldn't get IPSFactory buffer for interface
{a028db05-30f0-4b93-b17a-41c72f831d84}
err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hres=0x80040155
err:ole:CoMarshalInterface Failed to marshal the interface
{a028db05-30f0-4b93-b17a-41c72f831d84}, 80040155
tmarshal.c:139: Test failed: CoMarshalInterface failed with error 0x80040155
err:ole:CoUnmarshalInterface IMarshal::UnmarshalInterface failed, 0x8003001e
tmarshal.c:760: Test failed: CoUnmarshalInterface failed with error 0x8003001e
wine: Unhandled page fault on write access to 0x at address 0x15a159
(thread 0009), starting debugger...
WineDbg starting on pid 0x8
Unhandled exception: page fault on write access to 0x in 32-bit code
(0x0015a159).
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
EIP:0015a159 ESP:0033fc88 EBP:0033fd58 EFLAGS:00010246( - 00 -RIZP1)
EAX:00159310 EBX:7b8abaa8 ECX: EDX:0001
ESI:8003001e EDI:60412be7
Stack dump:
0x0033fc88: 00159310 7b88c87f 00159310 0001
0x0033fc98: 0015a500 0015a158 00159310 0033ff2c
0x0033fca8: 7b82be98 7b8415c0 7b8abaa8 8003001e
0x0033fcb8: 60412be7 0033fd58 0033fc90 7b88c805
0x0033fcc8: 0001 0020
0x0033fcd8: 0033fd58 7bc2764f 0011 7bc77848
fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c119
Backtrace:
=1 0x0015a159 (0x0015a159)
fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information
for oleaut32_testelf
2 0x603092f7 func_tmarshal+0x2f7
[/home/julliard/wine/wine/dlls/oleaut32/tests/tmarshal.c:763] in oleaut32_test
(0x603092f7)
3 0x6040ee81 run_test+0x121(name=0x1103a9)
[/home/julliard/wine/wine/dlls/oleaut32/tests/../../../include/wine/test.h:365]
in oleaut32_test (0x6040ee81)
4 0x6040f1a9 __wine_spec_exe_entry+0x99(peb=0x7ffdf000)
[/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:37] in oleaut32_test
(0x6040f1a9)
fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information
for kernel32elf
5 0x7b87015b start_process+0xeb(arg=0x0)
[/home/julliard/wine/wine/dlls/kernel/process.c:822] in kernel32 (0x7b87015b)
fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information
for libwine.so.1
6 0x6001f887 wine_switch_to_stack+0x17 in libwine.so.1 (0x6001f887)
0x0015a159: addb%dl,0x0(%ecx)
Wine-dbg
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: wineconsole: command line option output / configurable default backend
Alexandre Julliard wrote: Try to create the console window, it should fail if X is not available. Well, I'll look into that when I find time.
Re: RFC: XEmbed Systray Patches
On 8/9/06, James Liggett [EMAIL PROTECTED] wrote: Actually, I don't think it has to do with synchronization--I think it has to do with window mapping. Ah awesome, good work! I know when I looked at this originally it seemed you could set a flag that told the embedder whether it was already mapped or not, maybe that doesn't work properly. There was also a problem where a window would dock but only be allocated 1 pixel, I think that was a bug in GNOME that is now fixed. Hopefully we can nail this all finally. thanks -mike
Re: ntdll: make shared user data access work
Alexandre Julliard wrote: Robert Reif [EMAIL PROTECTED] writes: diff -p -u -r1.66 thread.c --- dlls/ntdll/thread.c 26 Jul 2006 14:01:20 - 1.66 +++ dlls/ntdll/thread.c 6 Aug 2006 01:15:43 - @@ -215,7 +215,7 @@ HANDLE thread_init(void) addr = (void *)0x7ffe; size = 0x1; -NtAllocateVirtualMemory( NtCurrentProcess(), addr, 0, size, MEM_RESERVE, PAGE_READONLY ); +NtAllocateVirtualMemory( NtCurrentProcess(), addr, 0, size, MEM_RESERVE | MEM_COMMIT, PAGE_READONLY); This code is only intended to reserve the space at startup. We need to initialize it properly later on before making it accessible. Technically, the server should probably create, initialize and update this memory and each thread should just get their own read only mapping . This patch is just a quick fix to prevent a crash when an application or dll tries to read from that memory. I guess this is the equivalent of a stub function.
Re: ntdll: make shared user data access work
Robert Reif [EMAIL PROTECTED] writes: This patch is just a quick fix to prevent a crash when an application or dll tries to read from that memory. I guess this is the equivalent of a stub function. The problem is that there's no FIXME being printed, so unlike with stubs things will most likely fail silently. BTW which app is using this, and which part of the data does it need? -- Alexandre Julliard [EMAIL PROTECTED]
Re: Re: wine
On Wed, 9 Aug 2006, hendric wrote: Hi,Rob Hmm Chinese characters were shown as ??. I think there must be something wrong with the code page. Either can't I input Chinese characters. Applications could not detect their running in Chinese local correctly. I think wine still need a great improvement in supporting multiple languages but the task is of low priority. What is your locale in the terminal where you are running wine? Check the output of: env | egrep (LC_|LANG) -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.
Re: wineconsole: command line option output / default user backend
Ekkehard Morgenstern [EMAIL PROTECTED] writes: Well, WCMD allows only 2 arguments, for instance. IMNSHO the code is effed-up beyond repair, and I would rather rewrite it than expand on it. But I won't bother writing a replacement if it's not desired by the WINE community. wcmd certainly needs a lot of love, and improvements would be welcome. But it's usually not a good idea to start with the throw it away and rewrite attitude; and to be blunt, I'm not going to accept a rewrite unless you demonstrate that a) you thorougly understand the existing code, and b) you can really do better. And the only way to demonstrate both is by first submitting good patches against the existing code. -- Alexandre Julliard [EMAIL PROTECTED]
Rooms for Wineconf - Please act now
Hi Folks, I know that Wineconf is still over a month away, but you'll really regret it if you don't make your accomodation selections now. If you paypal (or even arrange to mail a check) to me *now*, you'll get to hang out with all the cool people, on campus, and learn what the Drink-making facilities on each corridor really means, all for the low low price of about 40 pounds (okay, so the exchange rate sucks, and that's $75 US, but still...) If you *don't* get me an room request in the next few days, then I'll have to close down our room reservation, and you'll be stuck in some sleazy motel on the edge of town paying outrageous sums of of money. (Okay, they actually all look like nice places to stay, but they will be a ways away, and they all cost more :-/). Again, see this page for more details: http://www.winehq.org/site/wineconf/travel If you can't do Paypal, I can take a check in US currency as well. Cheers, Jeremy
Re: [2/2] WINED3D: Fix D3DCOLOR swizzling in shaders.
On Sat, Aug 05, 2006 at 06:15:42PM +0200, H. Verbeet wrote: This patch fixes those issues by looking at the data types in the vertex declaration the shader will be used with. To be able to do that, we have to wait with compiling the shader until the shader is first used and we have a vertex declaration. I am not sure, if exactly *this* patch fixes the problem - but i assume so: the colors of the cars and lights in Live For Speed are not fixed also. thanks for that! -- cu pgpVYvAYhYTb8.pgp Description: PGP signature
Re: [FreeBSD] locating wine at 0x20000000
On Tuesday 08 August 2006 23:28, Alexandre Julliard wrote: Tijl Coosemans [EMAIL PROTECTED] writes: Only the super-user can increase the max limit. Other users can only decrease it. And all those unix shared libs (x11, etc.) need heap space as well. I don't know how much they all need. Maybe a 128Mb heap would be sufficient? That would bring us to 0x7400. Do you need to set the max limit? Isn't the current limit sufficient? No, it's the max limit. The FreeBSD kernel code is pretty clear on that: if (addr == 0 || (addr = round_page((vm_offset_t)vms-vm_taddr) addr round_page((vm_offset_t)vms-vm_daddr + lim_max(td-td_proc, RLIMIT_DATA addr = round_page((vm_offset_t)vms-vm_daddr + lim_max(td-td_proc, RLIMIT_DATA)); So, when the addr argument to mmap is NULL or somewhere in the text segment or maximum possible data segment it is pushed back to after the data segment, which of course works quite well for any normal unix program. Anyway, the situation is different in FreeBSD 7.0, so I need to think this over some more and do some more testing.
widl: Error on simple idl file
Hi,
The attached idl file gives an error when used with
widl -DUSE_TYPEDEF simple.idl
I doubt, that it is a syntax error, since adding -h
creates the header, using -c gives the error.
The error is:
error: Unsupported member type 0x0
Elrond
[
uuid(fcd1436a-22e0-4e44-97e7-030e18586f92),
version(0.0),
pointer_default(unique),
explicit_handle
]
interface simple
{
#ifdef USE_TYPEDEF
typedef unsigned int DWORD;
#else
#define DWORD unsigned int
#endif
typedef struct _some_struct {
DWORD some_data;
} SomeStruct;
/* Function 0 */
DWORD SimpleTestFn(handle_t BindingHandle,
[in] SomeStruct *data);
}
Re: RFC: XEmbed Systray Patches
On Wed, 2006-08-09 at 12:16 +0100, Mike Hearn wrote: Ah awesome, good work! I know when I looked at this originally it seemed you could set a flag that told the embedder whether it was already mapped or not, maybe that doesn't work properly. It's not that it doesn't work properly. What happened is that the x11drv maps any visible window, so that and the mapping flag were conflicting with one another. In order for this to work, the systray window (our icon) can *never* be mapped by WINE at any point during its life, or the tray will have problems with it, the extent of which depends on how said tray implements XEmbed (which explains disparities between the behavior of GNOME, XFce, and IceWM with the patches.) IOW, the tray has to handle everything with mapping/unmapping, or you get races. On that subject, I've found that with some more tests, we're not quite out of the woods yet. I think the problem now is that WINE wants to map the window every time the tray becomes visible. I've thought about handling this in X11DRV_set_window_pos, but I'm not sure of the correct way to handle it. What we need to do is get the extended style of the window, but this seems to involve a bunch of wineserver calls that I'm not familiar with. Can you help me out on that? Thanks! There was also a problem where a window would dock but only be allocated 1 pixel, I think that was a bug in GNOME that is now fixed. I'm not quite sure about that one--I've got an X test app that docks, but I can only get 1 pixel wide. :( On wine, this isn't a problem though. Still trying to figure out what I need to do. James
Re: version/tests: Write-strings warnings fix
On 8/9/06, Andrew Talbot [EMAIL PROTECTED] wrote: Please note: in install.c, I have preserved a distinction between regedit and regedit.exe that was in the original code. If this distinction is accidental, please inform me, via wine-devel, and I shall send a revised version of this patch. ... @@ -34,6 +34,9 @@ char filename[MAX_PATH]; char outBuf[MAX_PATH]; char windir[MAX_PATH]; +static CHAR empty[]= , + regedit_a[] = regedit, + regedit_b[] = regedit.exe; memset(appdir, 0, MAX_PATH); memset(windir, 0, MAX_PATH); Seems like regedit and regedit_exe might be better names than regedit_a/b. -- James Hawkins
WineD3D: Minor cursor fixes
In an attempt to catch the issue in some games that the gdi cursor is shown on
top of a cursor drawn by the game I wrote a test case for the cursor. I
didn't catch the main issue, but just 2 little things
* If no cursor image is set the cursor is never enabled
* The cursor image can't be unset(SetCursorProperties returns an error on
NULL)
* The GDI cursor is formally not affected.
_Visually_ the gdi cursor disappears after the first successfull
SetCursorProperties call. Before that it is drawn and can be moved with the
mouse. After a SetCursorProperties call it disappears, but GetCursorInfo
still says it is enabled. Any ideas how else the cursor could be hidden?
Maybe a windows-internal thing?
From nobody Mon Sep 17 00:00:00 2001
From: Stefan Dösinger [EMAIL PROTECTED]
Date: Wed Aug 9 22:01:46 2006 +0200
Subject: [PATCH] WineD3D: Little cursor fixed + tests
---
dlls/d3d9/device.c |4 ++
dlls/d3d9/tests/device.c | 83 ++
dlls/wined3d/device.c|6 ++-
3 files changed, 91 insertions(+), 2 deletions(-)
56b2285176bfed1a0b142efc25ccc1aea08d03ec
diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c
index ad415a8..6eeaceb 100644
--- a/dlls/d3d9/device.c
+++ b/dlls/d3d9/device.c
@@ -147,6 +147,10 @@ static HRESULT WINAPI IDirect3DDevice9
IDirect3DDevice9Impl *This = (IDirect3DDevice9Impl *)iface;
IDirect3DSurface9Impl *pSurface = (IDirect3DSurface9Impl*)pCursorBitmap;
TRACE((%p) Relay\n, This);
+if(!pCursorBitmap) {
+WARN(No cursor bitmap, returning WINED3DERR_INVALIDCALL\n);
+return WINED3DERR_INVALIDCALL;
+}
return
IWineD3DDevice_SetCursorProperties(This-WineD3DDevice,XHotSpot,YHotSpot,(IWineD3DSurface*)pSurface-wineD3DSurface);
}
diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c
index 9175d27..d126860 100644
--- a/dlls/d3d9/tests/device.c
+++ b/dlls/d3d9/tests/device.c
@@ -392,6 +392,88 @@ cleanup:
DestroyWindow( hwnd );
}
+static void test_cursor(void)
+{
+HRESULT hr;
+HWND hwnd = NULL;
+IDirect3D9 *pD3d = NULL;
+IDirect3DDevice9*pDevice= NULL;
+D3DPRESENT_PARAMETERSd3dpp;
+D3DDISPLAYMODE d3ddm;
+CURSORINFO info;
+IDirect3DSurface9 *cursor = NULL;
+HCURSOR cur;
+
+memset(info, 0, sizeof(info));
+info.cbSize = sizeof(info);
+hr = GetCursorInfo(info);
+cur = info.hCursor;
+
+pD3d = pDirect3DCreate9( D3D_SDK_VERSION );
+ok(pD3d != NULL, Failed to create IDirect3D9 object\n);
+hwnd = CreateWindow( static, d3d9_test, WS_OVERLAPPEDWINDOW, 100, 100,
160, 160, NULL, NULL, NULL, NULL );
+ok(hwnd != NULL, Failed to create window\n);
+if (!pD3d || !hwnd) goto cleanup;
+
+IDirect3D9_GetAdapterDisplayMode( pD3d, D3DADAPTER_DEFAULT, d3ddm );
+ZeroMemory( d3dpp, sizeof(d3dpp) );
+d3dpp.Windowed = TRUE;
+d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
+d3dpp.BackBufferFormat = d3ddm.Format;
+
+hr = IDirect3D9_CreateDevice( pD3d, D3DADAPTER_DEFAULT,
D3DDEVTYPE_NULLREF, hwnd,
+ D3DCREATE_SOFTWARE_VERTEXPROCESSING, d3dpp,
pDevice );
+ok(SUCCEEDED(hr), Failed to create IDirect3D9Device (%s)\n,
DXGetErrorString9(hr));
+if (FAILED(hr)) goto cleanup;
+
+IDirect3DDevice9_CreateOffscreenPlainSurface(pDevice, 32, 32,
D3DFMT_A8R8G8B8, D3DPOOL_SCRATCH, cursor, 0);
+ok(cursor != NULL, IDirect3DDevice9_CreateOffscreenPlainSurface failed
with %08lx\n, hr);
+
+/* Initially hidden */
+hr = IDirect3DDevice9_ShowCursor(pDevice, TRUE);
+ok(hr == FALSE, IDirect3DDevice9_ShowCursor returned %08lx\n, hr);
+
+/* Not enabled without a surface*/
+hr = IDirect3DDevice9_ShowCursor(pDevice, TRUE);
+ok(hr == FALSE, IDirect3DDevice9_ShowCursor returned %08lx\n, hr);
+
+/* Fails */
+hr = IDirect3DDevice9_SetCursorProperties(pDevice, 0, 0, NULL);
+ok(hr == D3DERR_INVALIDCALL, IDirect3DDevice9_SetCursorProperties
returned %08lx\n, hr);
+
+hr = IDirect3DDevice9_SetCursorProperties(pDevice, 0, 0, cursor);
+ok(hr == D3D_OK, IDirect3DDevice9_SetCursorProperties returned %08lx\n,
hr);
+
+IDirect3DSurface9_Release(cursor);
+
+memset(info, 0, sizeof(info));
+info.cbSize = sizeof(info);
+hr = GetCursorInfo(info);
+ok(hr != 0, GetCursorInfo returned %08lx\n, hr);
+ok(info.flags CURSOR_SHOWING, The gdi cursor is hidden (%08lx)\n,
info.flags);
+ok(info.hCursor == cur, The cursor handle is %p\n, info.hCursor); /*
unchanged */
+
+/* Still hidden */
+hr = IDirect3DDevice9_ShowCursor(pDevice, TRUE);
+ok(hr == FALSE, IDirect3DDevice9_ShowCursor returned %08lx\n, hr);
+
+/* Enabled now*/
+hr = IDirect3DDevice9_ShowCursor(pDevice, TRUE);
+ok(hr == TRUE, IDirect3DDevice9_ShowCursor returned %08lx\n, hr);
+
+/* GDI cursor
Re: WineD3D: draw buffers support (patch 2)
This is a slighly updated version of the patch. The code is the same but I
changed the comment a little as suggested by Henri as the part about SM3 was
wrong.
Roderick
Hi,
This is a second draw buffers / gl_FragColor patch and it depends on the
other patch which was sent earlier today. The previous patch added draw
buffers support and fixed a gl_FragData bug. This patch fixes another case
where we incorrectly use gl_FragData.
Regards,
Roderick Colenbrander
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
--- dlls/wined3d/glsl_shader.c 2006-08-09 20:56:43.0 +0200
+++ dlls/wined3d/glsl_shader.c 2006-08-09 22:49:46.0 +0200
@@ -562,6 +562,7 @@
/* oPos, oFog and oPts in D3D */
const char* hwrastout_reg_names[] = { gl_Position, gl_FogFragCoord, gl_PointSize };
+WineD3D_GL_Info *gl_info = ((IWineD3DImpl*)((IWineD3DPixelShaderImpl*)arg-shader)-wineD3DDevice-wineD3D)-gl_info;
DWORD reg = param D3DSP_REGNUM_MASK;
DWORD regtype = shader_get_regtype(param);
IWineD3DBaseShaderImpl* This = (IWineD3DBaseShaderImpl*) arg-shader;
@@ -641,10 +642,17 @@
sprintf(tmpStr, Vsampler%lu, reg);
break;
case D3DSPR_COLOROUT:
-sprintf(tmpStr, gl_FragData[%lu], reg);
-if (reg 0) {
-/* TODO: See GL_ARB_draw_buffers */
-FIXME(Unsupported write to render target %lu\n, reg);
+if (GL_SUPPORT(ARB_DRAW_BUFFERS)) {
+sprintf(tmpStr, gl_FragData[%lu], reg);
+if (reg 0) {
+/* TODO: See GL_ARB_draw_buffers */
+FIXME(Unsupported write to render target %lu\n, reg);
+}
+} else { /* On older cards with GLSL support like the GeforceFX there's only one buffer. */
+if (reg 0)
+WARN(This OpenGL implementation doesn't support writing to multiple render targets!\n);
+else
+sprintf(tmpStr, gl_FragColor);
}
break;
case D3DSPR_RASTOUT:
Re: This patch should fix bug 4863 - Icons in Notes Workspace
Here is the link to the patch which I have sent (thanks VJ): http://winehq.org/pipermail/wine-patches/2006-July/028932.html And the link to the bug report and the subsequent discussion on Wine bugzilla is: http://bugs.winehq.org/show_bug.cgi?id=4863 About working on a conformance test, as I have said on the bug report, I haven't the knowledge to validate the resultant DIB structure returned from SetDIBits function. But I still have great interest in learning and contributing with Wine commuinty and if someone helps me understand the DIB structure, I will implement a conformance test for this bug. Regards, Augusto Arcoverde da Rocha On 8/8/06, Dan Kegel [EMAIL PROTECTED] wrote: And weren't you going to work on a conformance test for this? On 8/8/06, Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: Please put a link to your patch that has been sent to wine patches. So that interested people can easily locate it and review it. Thanks, VJ
Re: version/tests: Write-strings warnings fix
James Hawkins wrote: Seems like regedit and regedit_exe might be better names than regedit_a/b. Good point. I shall re-post, marked Try 2. Thanks, -- Andy.
Re: This patch should fix bug 4863 - Icons in Notes Workspace
On Wed, Aug 09, 2006 at 06:29:56PM -0300, Augusto Arcoverde da Rocha wrote: Here is the link to the patch which I have sent (thanks VJ): http://winehq.org/pipermail/wine-patches/2006-July/028932.html And the link to the bug report and the subsequent discussion on Wine bugzilla is: http://bugs.winehq.org/show_bug.cgi?id=4863 About working on a conformance test, as I have said on the bug report, I haven't the knowledge to validate the resultant DIB structure returned from SetDIBits function. But I still have great interest in learning and contributing with Wine commuinty and if someone helps me understand the DIB structure, I will implement a conformance test for this bug. It's still not clear to me what the bug is. Could you indicate which functions are being called by Notes are causing the problem. A (very small) bit of a relay trace would help. Huw.
localspl.dll: Implementation-Question
Am Sonntag, den 30.07.2006, 21:41 +0200 schrieb Detlef Riekenberg: Printmonitors need spoolss.dll,EnumPortsW On windows, all work is done in spoolss.dll and winspool.drv is just the Forwarder (RPC). We avoid the need for loading spoolss.dll in every App by doing the work in winspool.drv and use spoolss.dll as relay. Changelog: - spoolss: add EnumPortsW (by calling winspool.drv) The Codebase in dlls/winspool.drv/info.c get really large and the actual Code-Path is: winspool.drv - CUPS/LPR (with help from GDI). A possible place to split the Code is at the Printmonitor-Level. The Printmonitor for the Standard Local Ports in Windows (COM*:, LPT*:, FILE:, Windows-File) was in localmon.dll and merged into localspl.dll with w2k. On IRC, Alexandre already accepted to handle Wine-Specific Ports ( CUPS:*, LPR:*, Pipe to a unix_app, /unix-File ) together with the Standard Window-Ports in a single Printmonitor: localspl.dll The Requirement, that updating the System-Printers in wine must work automatic, need some Attention, when the related code (LoadSystemPrinters) move from winspool.drv to localspl.dll: 1) Changing the Code-Path to winspool.drv - localspl.dll - CUPS/LPR and using the same Memory-Functions for localspl.dll as done in Windows (the Memory-Related Exports from spoolss.dll), give us a circular dependency, when we load and call winspool.drv from spoolss.dll. For this reason, using HeapAlloc(GetProcessHeap(), ...) and Friends from kernel32.dll is a Possible way to go for localspl.dll. 2) To let Printing in Wine work as similar as possible as Printing is done in Windows, (but without RPC and without the Spooler-Service) we can change the Code-Path to winspool.drv - spoolss.dll - localspl.dll - CUPS/LPR and use the Exports from spoolss.dll. Since we need the Memory-Exports from spoolss.dll also for other Printmonitors and many Names/Prototypes of the other spoolss.dll - Exports are Equal to the Functions in winspool.drv, I prefer Solution 2. (Wine as an EMF-Printing-Backend for samba is only Possible with 2) As a Reference, what windows does, is: winspool.drv --(RPC)-- spoolsv.exe(Spooler Service) --(WINAPI)-- spoolss.dll - localspl.dll - Driver for LPT*: / COM*: Any comments please. Thanks -- By By ... ... Detlef
Re: RFC: XEmbed Systray Patches
On 8/9/06, James Liggett [EMAIL PROTECTED] wrote: way to handle it. What we need to do is get the extended style of the window, but this seems to involve a bunch of wineserver calls that I'm not familiar with. Can you help me out on that? Thanks! You can always stick some needed field in the X11DRV private data (you can see how to access that in the code itself). I'm not quite sure about that one--I've got an X test app that docks, but I can only get 1 pixel wide. :( On wine, this isn't a problem though. Still trying to figure out what I need to do. Oh dear :( Maybe you should ping one of the GNOME guys? thanks -mike
Re: Wine is stripping comments from system register
Augusto Arcoverde da Rocha wrote: I'm tring store some marks as comments inside of system register, but when I start some wine process and it finish the comments have disappeared from the register file. Is this the expected behaviour? Yes. As the registry is both read and written, and there's no API level requirement to preserve comments, they're not preserved. You could put them in tools/wine.inf if you like. Mike
Re: RFC: XEmbed Systray Patches
On Thu, 2006-08-10 at 00:16 +0100, Mike Hearn wrote: You can always stick some needed field in the X11DRV private data (you can see how to access that in the code itself). Are you referring to x11drv_win_data? I looked at that, but it seems cleaner if I just use GetWindowLongW. I don't know if that's considered correct in this case (Sorry if it's a really dumb question, but I'm not sure on that.) Oh dear :( Maybe you should ping one of the GNOME guys? Yes, oh dear indeed. Maybe I will talk to the GNOME people about that. James
All right, let's solve these .desktop issues forever
As of right now, I'd estimate that over half of our users are using Wine from a terminal window to launch their applications, largely because their window manager doesn't put Wine's Start Menu entries into their applications menu. Wine's been making .desktop files for some time, however it seems like they're being put in the wrong place. There's supposedly a proper, standard place to put them (or there should be), and perhaps a hack can be put in at the package-maintainer level, but in any case this is a pretty big usability issue at the moment. I'm pretty confident that someone here knows the answer to how things should be, and I'm also pretty sure it's a fairly simple change to make. Either way, we need to have a discussion about it - what's the next step here? Thanks, Scott Ritchie
Re: All right, let's solve these .desktop issues forever
On 8/9/06, Scott Ritchie [EMAIL PROTECTED] wrote: As of right now, I'd estimate that over half of our users are using Wine from a terminal window to launch their applications, largely because their window manager doesn't put Wine's Start Menu entries into their applications menu. Indeed. Wine's been making .desktop files for some time, however it seems like they're being put in the wrong place. There's supposedly a proper, standard place to put them (or there should be), and perhaps a hack can be put in at the package-maintainer level, but in any case this is a pretty big usability issue at the moment. I'm pretty confident that someone here knows the answer to how things should be, and I'm also pretty sure it's a fairly simple change to make. Either way, we need to have a discussion about it - what's the next step here? I started up xfce today, and was surprised to see all the menu items for all the windows apps I'd installed over the last few months show up. Sadly, this was wrong, since I'd done rm -rf .wine many times. It'd be nice if the .desktop files were stored inside ~/.wine so they could go away when that directory did :-( Hrmf. Lemme ask the Portland folks. - Dan
