Re: winecfg.cpl: Add new control panel applet for winecfg
2008/7/2 Owen Rudge <[EMAIL PROTECTED]>: > Well, the first part of the project was to get the shell namespace > implementation of Control Panel working properly, which is now > effectively complete. Hi, I just tested Cepstral SwiftTalker with latest git (see bug: http://bugs.winehq.org/show_bug.cgi?id=12534) and I can't see the options from the `control` program. You might want to get this and other applets displaying/working before creating default Wine-specific ones (e.g. like the one installed by Internet Explorer). >From my investigation into that bug (12534), I found that built-in control panel applets and installed ones were processed differently - installed ones used the registry, built-in ones didn't. - Reece
Re: gdi32: Implement automatic font substitution
2008/7/2 Dan Kegel <[EMAIL PROTECTED]>: > Can you write a conformance test that verifies this behavior? Sorry, I don't know how to write a test yet. Maybe I will write a test later. > Also, can you identify a bug in bugzilla this will fix? Such as bug 4065, 10864, 14151.
Re: Dylan Smith : richedit: Added missing DestroyWindow in a test.
On Wed, Jul 2, 2008 at 12:52 AM, Dylan Smith <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 1, 2008 at 1:24 PM, James Hawkins <[EMAIL PROTECTED]> wrote: > > This commit is causing ~350 failures on all platforms. Please send in > > a fix or a revert patch. > > Oh, crap. You are right, I must have only tested this on Windows with > further patches applied that fix this problem. There are some > problems in these tests with sending keyboard events, but they don't > always seem to show themselves. I am not sure what the conditions are > that result in these causing tests to fail, but I guess this someone > is one of them. > > I guess I should revert this patch, and add change to another patch > which fixes the issue. Sorry for posting again, but I just noticed that I already sent the patch that fixes the tests, and you suggested either _fix_ or revert the patch. Well, could you try applying the patch from http://www.winehq.org/pipermail/wine-patches/2008-June/056829.html and see if it fixes this problem? I tested it in Windows XP, and in Wine, and in Wine with valgrind.
Re: Dylan Smith : richedit: Added missing DestroyWindow in a test.
On Tue, Jul 1, 2008 at 1:24 PM, James Hawkins <[EMAIL PROTECTED]> wrote: > This commit is causing ~350 failures on all platforms. Please send in > a fix or a revert patch. Oh, crap. You are right, I must have only tested this on Windows with further patches applied that fix this problem. There are some problems in these tests with sending keyboard events, but they don't always seem to show themselves. I am not sure what the conditions are that result in these causing tests to fail, but I guess this someone is one of them. I guess I should revert this patch, and add change to another patch which fixes the issue.
New valgrind warnings in rpcrt4/tests/server
Hi Rob! Could you have a look at these fresh warnings in rpcrt4/tests/server? Thanks... http://kegel.com/wine/valgrind/logs-2008-07-01/vg-rpcrt4_server-diff.txt + Syscall param socketcall.send(msg) points to uninitialised byte(s) +at (within /lib/ld-2.7.so) +by rpcrt4_conn_write (rpc_binding.h:168) +by RPCRT4_SendWithAuth (rpc_message.c:533) +by RPCRT4_Send (rpc_message.c:675) +by I_RpcSend (rpc_message.c:1225) +by I_RpcSendReceive (rpc_message.c:1328) +by NdrSendReceive (ndr_clientserver.c:214) +by square_unencu (server_c.c:2467) +by union_tests (server.c:889) +by run_tests (server.c:1241) +by client (server.c:1260) +by func_server (server.c:1357) +by run_test (test.h:449) +by main (test.h:498) + Address 0x7f01350c is 28 bytes inside a block of size 36 alloc'd +at notify_alloc (heap.c:191) +by RtlAllocateHeap (heap.c:1231) +by RPCRT4_SendWithAuth (rpc_message.c:492) +by RPCRT4_Send (rpc_message.c:675) +by I_RpcSend (rpc_message.c:1225) +by I_RpcSendReceive (rpc_message.c:1328) +by NdrSendReceive (ndr_clientserver.c:214) +by square_unencu (server_c.c:2467) +by union_tests (server.c:889) +by run_tests (server.c:1241) +by client (server.c:1260) +by func_server (server.c:1357) +by run_test (test.h:449) +by main (test.h:498) + Uninitialised value was created by a stack allocation +at square_unencu (server_c.c:2424) ... + Syscall param write(buf) points to uninitialised byte(s) +at (within /lib/ld-2.7.so) +by WriteFile (file.c:559) +by rpcrt4_conn_np_write (rpc_transport.c:404) +by rpcrt4_conn_write (rpc_binding.h:168) +by RPCRT4_SendWithAuth (rpc_message.c:533) +by RPCRT4_Send (rpc_message.c:675) +by I_RpcSend (rpc_message.c:1225) +by I_RpcSendReceive (rpc_message.c:1328) +by NdrSendReceive (ndr_clientserver.c:214) +by square_unencu (server_c.c:2467) +by union_tests (server.c:889) +by run_tests (server.c:1241) +by client (server.c:1275) +by func_server (server.c:1357) +by run_test (test.h:449) +by main (test.h:498) + Address 0x7f013524 is 28 bytes inside a block of size 36 alloc'd +at notify_alloc (heap.c:191) +by RtlAllocateHeap (heap.c:1231) +by RPCRT4_SendWithAuth (rpc_message.c:492) +by RPCRT4_Send (rpc_message.c:675) +by I_RpcSend (rpc_message.c:1225) +by I_RpcSendReceive (rpc_message.c:1328) +by NdrSendReceive (ndr_clientserver.c:214) +by square_unencu (server_c.c:2467) +by union_tests (server.c:889) +by run_tests (server.c:1241) +by client (server.c:1275) +by func_server (server.c:1357) +by run_test (test.h:449) +by main (test.h:498) + Uninitialised value was created by a stack allocation +at square_unencu (server_c.c:2424) ... + 24 bytes in 2 blocks are definitely lost +at malloc (vg_replace_malloc.c:207) +by MIDL_user_allocate (server.c:53) +by s_get_s123 (server.c:538) +by IServer_get_s123 (server_s.c:4545) +by process_request_packet (rpc_server.c:290) +by RPCRT4_process_packet (rpc_server.c:345) +by RPCRT4_worker_thread (rpc_server.c:362) +by worker_thread_proc (threadpool.c:113) +by ??? (thread.c:128) +by call_thread_func (thread.c:383) +by start_thread (thread.c:443) +by start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so) +by clone (in /lib/tls/i686/cmov/libc-2.7.so)
New valgrind warnings in fusion/tests/asmcache
Hey James, could you have a look at these fresh warnings? Thanks! http://kegel.com/wine/valgrind/logs-2008-07-01/vg-fusion_asmcache-diff.txt + Conditional jump or move depends on uninitialised value(s) +at default_dbgstr_wn (debug.c:337) +by NTDLL_dbgstr_wn (debugtools.c:106) +by wine_dbgstr_wn (debug.c:408) +by debugstr_w (debug.h:260) +by GetCachePath (fusion.c:97) +by test_QueryAssemblyInfo (asmcache.c:981) +by func_asmcache (asmcache.c:1472) +by run_test (test.h:449) +by main (test.h:498) + Uninitialised value was created by a stack allocation +at test_QueryAssemblyInfo (asmcache.c:946) ... + + Conditional jump or move depends on uninitialised value(s) +at strlenW (unicode.h:212) +by strcatW (unicode.h:245) +by lstrcatW (string.c:190) +by test_QueryAssemblyInfo (asmcache.c:987) +by func_asmcache (asmcache.c:1472) +by run_test (test.h:449) +by main (test.h:498) + Uninitialised value was created by a stack allocation +at test_QueryAssemblyInfo (asmcache.c:946)
Re: winecfg.cpl: Add new control panel applet for winecfg
> I still don't see the need for a winecfg cpl applet at this point. > You say that the Wine Configuration icon is ok for the time being. > Take your time and design it correctly the first time, so you or > others don't have to go back and fix it later. Measure twice, cut > once, as they say. I want to reiterate that, as far as I remember, > this project doesn't have anything to do with redesigning winecfg. > Correct me if I'm wrong. Well, the first part of the project was to get the shell namespace implementation of Control Panel working properly, which is now effectively complete. The second part of the project is to work on some applets for Wine, including improving the standard winecfg applets, unifying all of Wine's configuration tools in the Control Panel. As an example, I'm working on a new Add/Remove Programs applet, to replace the standard Wine uninstaller with one of enhanced functionality, and I am looking into what other applets will be useful within Wine. Splitting up appropriate parts of winecfg into separate control panels is another intention. As this latter goal may take a while to design and implement, I personally believe this control panel applet (which also adds icons for the Registry Editor and Task Manager, two other key utilities, which would be useful to have easy access for) is a useful stepping-stone, as it were. I do get your point about designing things correctly, of course, but considering the relativey minor functionality of this control panel, it seems to me to be reasonable to include for the time being, so that it can be developed over the next month or so to include all this extra functionality - instead of turning up at the end of July with a large unwieldy patch! Hope this helps clarify things, -- Owen Rudge http://www.owenrudge.net/
Re: winecfg.cpl: Add new control panel applet for winecfg
On Tue, Jul 1, 2008 at 6:15 PM, Owen Rudge <[EMAIL PROTECTED]> wrote: > > First, that's not what I was suggesting. I was disagreeing with > > adding a winecfg cpl applet. Second, I'm likening winecfg to a very > > poorly-designed control panel. There are several categories that can > > go into their own cpl applet, like 'Sound' and 'Graphics' (or whatever > > you want to call them), though there's not a 1-to-1 correspondence > > between winecfg tabs and potentially beneficial cpl applets. > > Ah, I see now. Well, that's what I'm ultimately hoping to do, although > as mentioned before, working out issues with the likes of how to > integrate an interface for application-versus-global settings for each > applet will require a bit of thinking. In addition, I imagine splitting > up/redesigning winecfg is something that may involve a bit of resistance > from those already accustomed to its present manner of working. This > patch is just the first part of a submission to create a basic control > panel skeleton - as I said before, I am hoping to redesign parts of > winecfg and shift those parts into their own control panel applets > (which technically can be all part of this same .cpl file). For the bits > that don't get moved into separate applets, I don't see why a general > Wine Configuration icon would be a bad thing, for the time being at least. > I still don't see the need for a winecfg cpl applet at this point. You say that the Wine Configuration icon is ok for the time being. Take your time and design it correctly the first time, so you or others don't have to go back and fix it later. Measure twice, cut once, as they say. I want to reiterate that, as far as I remember, this project doesn't have anything to do with redesigning winecfg. Correct me if I'm wrong. -- James Hawkins
Re: winecfg.cpl: Add new control panel applet for winecfg
> First, that's not what I was suggesting. I was disagreeing with > adding a winecfg cpl applet. Second, I'm likening winecfg to a very > poorly-designed control panel. There are several categories that can > go into their own cpl applet, like 'Sound' and 'Graphics' (or whatever > you want to call them), though there's not a 1-to-1 correspondence > between winecfg tabs and potentially beneficial cpl applets. Ah, I see now. Well, that's what I'm ultimately hoping to do, although as mentioned before, working out issues with the likes of how to integrate an interface for application-versus-global settings for each applet will require a bit of thinking. In addition, I imagine splitting up/redesigning winecfg is something that may involve a bit of resistance from those already accustomed to its present manner of working. This patch is just the first part of a submission to create a basic control panel skeleton - as I said before, I am hoping to redesign parts of winecfg and shift those parts into their own control panel applets (which technically can be all part of this same .cpl file). For the bits that don't get moved into separate applets, I don't see why a general Wine Configuration icon would be a bad thing, for the time being at least. -- Owen Rudge http://www.owenrudge.net/
Re: winecfg.cpl: Add new control panel applet for winecfg
On Tue, Jul 1, 2008 at 6:05 PM, Rob Thornton <[EMAIL PROTECTED]> wrote: > Owen Rudge wrote: >> > As we said before, implementing a control panel applet doesn't mean >> > you have to do anything to the current winecfg code. >> >> True, but would it really benefit to add an icon for each winecfg tab >> (which I think is what you are suggesting, yes?) to the control panel, >> compared to having one general icon for Wine configuration? >> > I don't think think making winecfg seem more like the Windows Control > panel is really something wine should strive for. Wine may be a > compatibility layer for Windows but I'm not sure it should mimic it. > Then what's the point of this mini-project? We've already decided it's what we want for Wine, so you won't get much sympathy for this argument. Keep in mind: we're not removing winecfg (yet)...we're just adding applets to the control panel. -- James Hawkins
Re: winecfg.cpl: Add new control panel applet for winecfg
On Tue, Jul 1, 2008 at 5:47 PM, Owen Rudge <[EMAIL PROTECTED]> wrote: > > As we said before, implementing a control panel applet doesn't mean > > you have to do anything to the current winecfg code. > > True, but would it really benefit to add an icon for each winecfg tab > (which I think is what you are suggesting, yes?) to the control panel, > compared to having one general icon for Wine configuration? > First, that's not what I was suggesting. I was disagreeing with adding a winecfg cpl applet. Second, I'm likening winecfg to a very poorly-designed control panel. There are several categories that can go into their own cpl applet, like 'Sound' and 'Graphics' (or whatever you want to call them), though there's not a 1-to-1 correspondence between winecfg tabs and potentially beneficial cpl applets. -- James Hawkins
Re: winecfg.cpl: Add new control panel applet for winecfg
Owen Rudge wrote: > > As we said before, implementing a control panel applet doesn't mean > > you have to do anything to the current winecfg code. > > True, but would it really benefit to add an icon for each winecfg tab > (which I think is what you are suggesting, yes?) to the control panel, > compared to having one general icon for Wine configuration? > I don't think think making winecfg seem more like the Windows Control panel is really something wine should strive for. Wine may be a compatibility layer for Windows but I'm not sure it should mimic it. Rob Thornton
Re: winecfg.cpl: Add new control panel applet for winecfg
> As we said before, implementing a control panel applet doesn't mean > you have to do anything to the current winecfg code. True, but would it really benefit to add an icon for each winecfg tab (which I think is what you are suggesting, yes?) to the control panel, compared to having one general icon for Wine configuration? -- Owen Rudge http://www.owenrudge.net/
Re: winecfg.cpl: Add new control panel applet for winecfg
On Tue, Jul 1, 2008 at 4:22 PM, Owen Rudge <[EMAIL PROTECTED]> wrote: >> Isn't it more logical (and closer to native) to have a control panel >> applet for each category/tab already in winecfg instead of having one >> winecfg applet? Otherwise you're just moving winecfg to another >> place. > > Well, my plan, as mentioned before in another thread, is to split up winecfg > a bit, but there's only so much you can do this, due to the fact that most > of the tabs in winecfg can work on a global or application-specific basis. > As far as I can tell, the Desktop and Sound tabs are the only bits of > winecfg that are global-only and as such can be split from the rest in this > manner, and this is something I would be considering for a "next step" for > this applet. However, I figured a simple applet that showed some icons that > a) let us actually have something in the control panel and that would b) > provide a more user-friendly interface to these tools for users would be a > good start, rather than coming along straight away with a large patch that > hacks up winecfg! > As we said before, implementing a control panel applet doesn't mean you have to do anything to the current winecfg code. -- James Hawkins
start/stop logs by code... is it possible ?
I'd like to start some trace log entering a function and stopping it at
exit, to isolate just the part I need. Is it possible to add some code
inside the function body that do it ?
I mean...
void aWineFunction(...)
{
...
STARTLOG
...
...
STOPLOG
...
}
The purpose is to isolate traces from code called by a single function.
Max
Re: winecfg.cpl: Add new control panel applet for winecfg
> Isn't it more logical (and closer to native) to have a control panel > applet for each category/tab already in winecfg instead of having one > winecfg applet? Otherwise you're just moving winecfg to another > place. Well, my plan, as mentioned before in another thread, is to split up winecfg a bit, but there's only so much you can do this, due to the fact that most of the tabs in winecfg can work on a global or application-specific basis. As far as I can tell, the Desktop and Sound tabs are the only bits of winecfg that are global-only and as such can be split from the rest in this manner, and this is something I would be considering for a "next step" for this applet. However, I figured a simple applet that showed some icons that a) let us actually have something in the control panel and that would b) provide a more user-friendly interface to these tools for users would be a good start, rather than coming along straight away with a large patch that hacks up winecfg! -- Owen Rudge http://www.owenrudge.net/
Thoughts on implementation of winhttp.dll
Hi, I've been looking at implementing winhttp.dll. Does anyone have thoughts on implementing parts of winhttp in terms of wininet? The primary issue that prevents entirely implementing winhttp in terms of wininet is that there is no direct Win32 API for fetching an SSL certificate in winhttp. To access these, I'd need access to functions defined in wininet/netconnection.c but aren't exported. My current two ideas are to either: 1) Copy the networking sublayer from wininet into winhttp and build on top of that to implement winhttp. Effectively reimplementing mostly from scratch. 2) Implement most winhttp things in terms of wininet and then copying over parts that I need from wininet's network sublayer, like fetching SSL certificates and so on. Thoughts on this are greatly appreciated, as I'd prefer to only have to write the library once. -Zac
RE: [4/5] WineD3D: Delay render target activation
This time with the patch > -Original Message- > From: [EMAIL PROTECTED] [mailto:wine-patches- > [EMAIL PROTECTED] On Behalf Of Stefan Dösinger > Sent: Tuesday, July 01, 2008 2:13 PM > To: [EMAIL PROTECTED] > Subject: [4/5] WineD3D: Delay render target activation > > >From edba9e2adacaa9e599426f35058eb01fc1fabce6 Mon Sep 17 00:00:00 2001 From: Stefan Doesinger <[EMAIL PROTECTED]> Date: Tue, 17 Jun 2008 01:42:55 +0200 Subject: [PATCH] WineD3D: Delay render target activation The ActivateContext in SetRenderTarget was an old regression prevention, but now it is time to remove it. --- dlls/wined3d/device.c |7 --- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c index f7301d7..4ba22b6 100644 --- a/dlls/wined3d/device.c +++ b/dlls/wined3d/device.c @@ -6731,13 +6731,6 @@ static HRESULT WINAPI IWineD3DDeviceImpl_SetRenderTarget(IWineD3DDevice *iface, * SetViewport may catch NOP viewport changes, which would occur when switching between equally sized targets */ IWineD3DDeviceImpl_MarkStateDirty(This, STATE_VIEWPORT); - -/* Activate the new render target for now. This shouldn't stay here, but is needed until all methods using gl activate the - * ctx properly. - * Use resourceload usage, this will just set the drawables and context but not apply any states. The stateblock may be - * incomplete or incorrect when SetRenderTarget is called. DrawPrim() will apply the states when it is called. - */ -ActivateContext(This, This->render_targets[0], CTXUSAGE_RESOURCELOAD); } return WINED3D_OK; } -- 1.5.4.5
Re: [4/5] WineD3D: Delay render target activation
On Tue, Jul 1, 2008 at 2:12 PM, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > > You forgot the patch. -- James Hawkins
Re: winecfg.cpl: Add new control panel applet for winecfg
On Tue, Jul 1, 2008 at 2:17 PM, Owen Rudge <[EMAIL PROTECTED]> wrote: > This patch adds a new applet, winecfg.cpl, to Wine, based on a patch sent a > few months ago by Metody Stefanov (pure_evil @ mail.bg). The control panel > features three icons, for Wine Configuration, the Registry Editor, and the > Task Manager. > Isn't it more logical (and closer to native) to have a control panel applet for each category/tab already in winecfg instead of having one winecfg applet? Otherwise you're just moving winecfg to another place. -- James Hawkins
re: gdi32: Implement automatic font substitution
Liu Qishuai wrote: > This patch appends all fonts on child_list so that if a character is > not available in the font, other fonts will be automatically used. > This is how Windows does to get a CJK character when a latin font is > specified. > > A lot of CJK-related bugs will be fixed after applying this patch. Excellent! In case AJ hesitates to apply this patch: Can you write a conformance test that verifies this behavior? Also, can you identify a bug in bugzilla this will fix? - Dan
Re: RFC: Adding tests for windowless richedit services
On Sun, Jun 29, 2008 at 11:56 PM, Austin Lund <[EMAIL PROTECTED]> wrote: > OK. I won't have access to a windows machine for a little while. Can > someone please test this patch for me? > The tests pass in win95, win2k, winxp, win2k3. Please remember to cc wine-devel and bottom-post replies. -- James Hawkins
Re: Dylan Smith : richedit: Added missing DestroyWindow in a test.
On Tue, Jul 1, 2008 at 8:27 AM, Alexandre Julliard <[EMAIL PROTECTED]> wrote: > Module: wine > Branch: master > Commit: 2a139746cc631f4ec291a89b4556af17266ce8c0 > URL: > http://source.winehq.org/git/wine.git/?a=commit;h=2a139746cc631f4ec291a89b4556af17266ce8c0 > > Author: Dylan Smith <[EMAIL PROTECTED]> > Date: Sat Jun 28 03:00:46 2008 -0400 > > richedit: Added missing DestroyWindow in a test. > This commit is causing ~350 failures on all platforms. Please send in a fix or a revert patch. -- James Hawkins
Re: Possible issue with win.c and help
-Original Message- From: Lei Zhang <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: wine-devel@winehq.org Sent: Tue, 1 Jul 2008 11:34 am Subject: Re: Possible issue with win.c and help On Mon, Jun 30, 2008 at 9:05 PM, Chris Ahrendt <[EMAIL PROTECTED]> wrote: > Ok in my ever increasing search to figure out why EQ2 is getting a > unhandled exception and also a no ipixel error. (I am convinced this is > two separate bugs now) > > Bug One : > > This is the unhandled exception: > If I have EQ2 run in anything but win98 mode (which I don't think is > supported anymore by EQ2) wine dies with a unhandled exception. If I set > to win98 it ends with a no ipixel format error message box (the second > bug) after it begins to draw the window. The other thing is the msg box > is not a typical msg box saying that something isn't supported but looks > to be an exception in ClientApp.cpp which means they are getting some > unhandled exception while drawing the window. > > What I think might be going on based on this : > > trace:win:WIN_SetWindowLong 0x2002c 0 0 W > trace:win:WIN_SetWindowLong Fell Through > trace:win:WIN_SetWindowLong Release Ptr > trace:win:WIN_DestroyWindow 0x2002c > trace:win:WIN_DestroyWindow 0x1002e > trace:win:WIN_DestroyWindow 0x10030 > trace:win:WIN_DestroyWindow 0x10032 > trace:win:WIN_DestroyWindow 0x10034 > trace:win:WIN_DestroyWindow 0x10036 > trace:win:WIN_DestroyWindow 0x10038 > trace:win:WIN_DestroyWindow 0x1003a > trace:win:WIN_DestroyWindow 0x1003c > trace:win:WIN_DestroyWindow 0x1003e > trace:win:WIN_DestroyWindow 0x10040 > trace:win:WIN_DestroyWindow 0x10042 > trace:win:WIN_DestroyWindow 0x10044 > trace:win:WIN_SetWindowLong 0x2002c 0 0 W > > > These are my trace additions in SetWindowLong to help me follow the > execution of the code > > trace:win:WIN_SetWindowLong Fell Through > trace:win:WIN_SetWindowLong Release Ptr > trace:win:WIN_SetWindowLong 0x2002c 12 0 W > trace:win:WIN_SetWindowLong Fell Through > trace:win:WIN_SetWindowLong Server Start Request > trace:win:WIN_SetWindowLong Default > trace:win:WIN_SetWindowLong no call Err > trace:win:WIN_SetWindowLong Default get and Set Win Data > trace:win:WIN_SetWindowLong Release Ptr > trace:win:WIN_SetWindowLong Returning 1871960 > > CRASH! Unhandled Exception > > I think the window is being destroyed in reverse for some reason. Thats > just my gut first feeling based on the above trace and the exception > output. This is where my knowledge on Windows behavior ends. Does 98 > destroy the windows chain differently than XP? This would explain why > the exception doesn't occur in 98 but does in XP. > > Second Bug: > This is the ipixel problem which I haven't figured out > how to debug whats going on there, but think it might be related to > this error: > > libGL error: drmMap of framebuffer failed (Cannot allocate memory) > libGL error: reverting to (slow) indirect rendering > libGL error: drmMap of framebuffer failed (Cannot allocate memory) > libGL error: reverting to (slow) indirect rendering > > Which I am not sure why this is occurring yet but one bug at a time. > Where would someone look to trace along the window draw chain to see > where it dies. Some of the debug flags cause my machine to lock up which > I know is a driver issue and other lockups could be caused by the above > exception messing something up in X as the disk still runs when that > lockup occurs but X is DOA. > > Thoughts? Ideas Suggestions?? > > Chris > > > Hi, Please file bug reports on the Wine Bugzilla - http://bugs.winehq.org/ The second issue looks like 3d graphics are not set up correctly on your computer. You should ask your favorite Linux forum about that. Oh this is already reported as a bug... as to the second I know.. was just looking for some pointers... Need help actually understanding the way windows are handled in 98 vs XP . The graphic are set up correctly though... Chris
Re: programs: add rudimentary dxdiag
On Mo, 2008-06-30 at 10:15 -0500, Austin English wrote: > > Instead of simple stub, this patch also adds the (simplified) d3d test > > like seen in native dxdiag, so users can test if their d3d is setup > > correctly. Screenshot can be seen here: > > http://bugs.winehq.org/attachment.cgi?id=14342 > > It looks nice, but the Patch is very large! > > and it 's not really possible > > to send it in in small chuncks. Why not? - empty stub - the property-sheet - demo-window with an empty (in memory) Bitmap - the wine-logo as bitmap - spinning cube reorder, when needed > Like I said in the bug, you should add dxdiag to > configure.ac/Makefile.in/etc. > > -Austin No, Louis used the correct way: tools/make_makefiles ./autoconf -- By by ... Detlef
Re: Possible issue with win.c and help
On Mon, Jun 30, 2008 at 9:05 PM, Chris Ahrendt <[EMAIL PROTECTED]> wrote: > Ok in my ever increasing search to figure out why EQ2 is getting a > unhandled exception and also a no ipixel error. (I am convinced this is > two separate bugs now) > > Bug One : > > This is the unhandled exception: > If I have EQ2 run in anything but win98 mode (which I don't think is > supported anymore by EQ2) wine dies with a unhandled exception. If I set > to win98 it ends with a no ipixel format error message box (the second > bug) after it begins to draw the window. The other thing is the msg box > is not a typical msg box saying that something isn't supported but looks > to be an exception in ClientApp.cpp which means they are getting some > unhandled exception while drawing the window. > > What I think might be going on based on this : > > trace:win:WIN_SetWindowLong 0x2002c 0 0 W > trace:win:WIN_SetWindowLong Fell Through > trace:win:WIN_SetWindowLong Release Ptr > trace:win:WIN_DestroyWindow 0x2002c > trace:win:WIN_DestroyWindow 0x1002e > trace:win:WIN_DestroyWindow 0x10030 > trace:win:WIN_DestroyWindow 0x10032 > trace:win:WIN_DestroyWindow 0x10034 > trace:win:WIN_DestroyWindow 0x10036 > trace:win:WIN_DestroyWindow 0x10038 > trace:win:WIN_DestroyWindow 0x1003a > trace:win:WIN_DestroyWindow 0x1003c > trace:win:WIN_DestroyWindow 0x1003e > trace:win:WIN_DestroyWindow 0x10040 > trace:win:WIN_DestroyWindow 0x10042 > trace:win:WIN_DestroyWindow 0x10044 > trace:win:WIN_SetWindowLong 0x2002c 0 0 W > > > These are my trace additions in SetWindowLong to help me follow the > execution of the code > > trace:win:WIN_SetWindowLong Fell Through > trace:win:WIN_SetWindowLong Release Ptr > trace:win:WIN_SetWindowLong 0x2002c 12 0 W > trace:win:WIN_SetWindowLong Fell Through > trace:win:WIN_SetWindowLong Server Start Request > trace:win:WIN_SetWindowLong Default > trace:win:WIN_SetWindowLong no call Err > trace:win:WIN_SetWindowLong Default get and Set Win Data > trace:win:WIN_SetWindowLong Release Ptr > trace:win:WIN_SetWindowLong Returning 1871960 > > CRASH! Unhandled Exception > > I think the window is being destroyed in reverse for some reason. Thats > just my gut first feeling based on the above trace and the exception > output. This is where my knowledge on Windows behavior ends. Does 98 > destroy the windows chain differently than XP? This would explain why > the exception doesn't occur in 98 but does in XP. > > Second Bug: > This is the ipixel problem which I haven't figured out > how to debug whats going on there, but think it might be related to > this error: > > libGL error: drmMap of framebuffer failed (Cannot allocate memory) > libGL error: reverting to (slow) indirect rendering > libGL error: drmMap of framebuffer failed (Cannot allocate memory) > libGL error: reverting to (slow) indirect rendering > > Which I am not sure why this is occurring yet but one bug at a time. > Where would someone look to trace along the window draw chain to see > where it dies. Some of the debug flags cause my machine to lock up which > I know is a driver issue and other lockups could be caused by the above > exception messing something up in X as the disk still runs when that > lockup occurs but X is DOA. > > Thoughts? Ideas Suggestions?? > > Chris > > > Hi, Please file bug reports on the Wine Bugzilla - http://bugs.winehq.org/ The second issue looks like 3d graphics are not set up correctly on your computer. You should ask your favorite Linux forum about that.
Re: new inetmib1 test failures
> I'll relax the test from an == to a >=, which might > be surprising but is at least allowed according to RFC 1157. Oops, it isn't allowed, either. I'll use the handy new broken() instead. --Juan
Re: richedit: Store richedit version rather than boolean bEmulateVersion10 value.
On 29/06/2008, Dylan Smith <[EMAIL PROTECTED]> wrote: > On Sun, Jun 29, 2008 at 4:20 AM, Phil Krylov <[EMAIL PROTECTED]> wrote: > > Of course this looks most sane. But I'm asking if you're going to make > > use of the dwEmulatedVersion other than "< 0x200"? That is, under what > > circumstances we should emulate version 2 or 3 when we have support > > for version 5? It's interesting to me, because it seemed to me that > > the native versions (starting with 2.0) are very compatible to each > > other. > > > > -- Ph. > > > I know that versions 2 and 3 are very compatible with, since they register > the same class and dll name. Richedit 4.1 however uses msftedit.dll instead, > which means that programs would need to explicitlydecide which version > they are using depending on which dll they load and which class they specify. > > Certainly there are differences between richedit 3 and 4.1, but I don't know > if > programs would depend on these differences. OK I see your point, and after hitting a very interesting blog on RichEdit, I even agree that the exact version number may be needed. http://blogs.msdn.com/murrays/archive/2006/10/14/richedit-versions.aspx http://blogs.msdn.com/murrays/archive/2006/10/20/some-richedit-history.aspx BTW they say that the DLL name for versions 5.0, 5.1, and 6.0 is riched20.dll again. -- Ph.
Re: Linker differences between Windows and Linux
"Jussi Pakkanen" <[EMAIL PROTECTED]> writes: > I assume Wine deals with this by having its own linker. My question is > how does Winelib handle this problem (or does it handle it at all)? Wine and Winelib use the standard linker. Check out the -Bsymbolic linker option. -- Alexandre Julliard [EMAIL PROTECTED]
Linker differences between Windows and Linux
Hi I'm working on porting the Cuneiform OCR system from Windows to Linux. I'm getting a lot of problems by the different linking order of Linux and Windows. I want to make it a native Linux application, that is not depend on Winelib. (I already have it running, but it is very buggy.) The original code is a jumble of dll's that export all of their symbols. The problem is that there are hundreds of duplicate symbols among in them (for example each dll has an "error code" variable which all have the same name). Under Linux these symbols get aliased to one single symbol and cause spurious program crashes. I assume Wine deals with this by having its own linker. My question is how does Winelib handle this problem (or does it handle it at all)? Winelib's documentation does not mention this. Can this symbol resolver fix be (easily) extracted from Winelib and used on regular Linux programs? Or is there a way to automatically rename these kinds of symbols, preferably in the source code? For those interested, the code is at https://code.launchpad.net/~jpakkane/cuneiform-linux/trunk (the manual symbol resolvation fix is checked in in revision 185, so you might want to check out revision 184). Thanks for your help.
Re: oleaut32: Fix a test that fails on all platforms up to and including win2k
2008/7/1 James Hawkins <[EMAIL PROTECTED]>: > +if (leftvt == VT_RECORD && rightvt == VT_I8) > +ok((hres == expectedhres || hres == DISP_E_BADVARTYPE) && > + V_VT(&result) == resvt, > + "VarSub: %d|0x%X, %d|0x%X: Expected failure 0x%X " > + "or 0x%X, got 0x%X, expected vt %d got vt %d\n", > + leftvt, ExtraFlags[i], rightvt, ExtraFlags[i], > + expectedhres, DISP_E_BADVARTYPE, hres, resvt, > V_VT(&result)); > +else > +ok(hres == expectedhres && V_VT(&result) == resvt, > + "VarSub: %d|0x%X, %d|0x%X: Expected failure 0x%X, " > + "got 0x%X, expected vt %d got vt %d\n", > + leftvt, ExtraFlags[i], rightvt, ExtraFlags[i], > + expectedhres, hres, resvt, V_VT(&result)); There's the handy HAVE_OLEAUT32_I8 variable for the purpose of expecting when VT_I8 and VT_UI8 types are going to be accepted and when they're not. To avoid complicating the test, you could probably just skip it earlier on if we're testing a VT_I8 or VT_UI8 type in the left or right parameter and HAVE_OLEAUT32_I8 is false. -- Rob Shearman
