Re: Fwd: RFC: OpenGL x11drv rewrite (WoW fix)
The biggest issue I had when porting was the OpenGL extensions. All extensions had to be called through the wgl thunks to get the calling conventions right, but that isn't hard, just a little extra initial work. - Aric I have done the same a while ago. The calling convention first was a pain (it led to strange crashes) but in the end it worked fine by adjusting GLAPIENTRY :) Roderick -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! Feel free mit GMX DSL: http://www.gmx.net/de/go/dsl
wine and other xservers
Hi, How does wine work/perform with other opensource X servers, like nano Xserver. Thanks, VJ
Re: Fwd: RFC: OpenGL x11drv rewrite (WoW fix)
Hi, Problem with WineD3D on top of WGL is that we lost many of usefull APIs I think WineD3D on top of x11drv (as WGL on top of x11drv) should a the better way WineD3D on top of WGL has the advantage that we can use our D3D libraries in windows too. This can be useful for testing(no other libs interfering), and it might come handy to use gl for D3D games in windows too, like d3d10 on xp once we have d3d10 support :-) . I personally prefer the way to support glX, wgl and agl in wined3d directly, without using wine's wgl or x11drv. pgpVu0WS7zHjM.pgp Description: PGP signature
Re: Read to 0x7ffe02c0
--- Vitaliy Margolen [EMAIL PROTECTED] wrote: 0x7ffe is KSHARED_USER_DATA and 0x2c0 is (not even sure how to get what is at this offset). You can see it's declaration in include/ddk/wdm.h Thanks Vitaliy. So this is supposed to be a boolean for some processor feature? I guess it doesn't matter what it contains, the problem is the address isn't mapped. Any idea what to do about that? I notice your patch[1] wasn't applied, but it doesn't apply cleanly anymore. [1] http://www.winehq.org/pipermail/wine-patches/2005-December/022780.html --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Read to 0x7ffe02c0
Juan Lang wrote: Hi folks, I'm trying to debug an access (by native userenv.dll in my case, but also by MS Money 2006) to address 0x7ffe02c0. It might be easier to implement the necessary functions in userenv, depending on which ones it uses. -- Rob Shearman
Re: Read to 0x7ffe02c0
--- Robert Shearman [EMAIL PROTECTED] wrote: It might be easier to implement the necessary functions in userenv, depending on which ones it uses. Thanks for the suggestion. I think not in this case; it's calling unnamed ordinal 149. --Jua __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: opengl pixel format regression
Hello
Your pixel format patches caused a regression in half-life 1 for me with
the fglrx drivers.
The same happend to me with opensource Intel drivers on a:
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM
Integrated
Graphics Device (rev 02)
It refuses to start in opengl mode and
reports ChoosePixelFormat failed, and then comes up in software(ddraw)
mode. The d3d mode still works fine. This problem also does not occur
with
the open source radeon driver. I tested with fglrx 8.28.8 and fglrx
8.27.10. Other games seem to work fine(appart of a few fglrx bugs)
Perfectly replicable on my system.
$ X -version
X Window System Version 7.1.1
What infos do you need to debug this? This is the format table glxinfo
reports:
$ glxinfo
[cut]
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
--
0x23 24 tc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x24 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x25 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x27 24 tc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x28 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x2a 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x2b 24 dc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x2c 24 dc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x2d 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x2e 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x2f 24 dc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x30 24 dc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x31 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x32 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
Both of you try to remove the following code from src/winex11.drv/opengl.c:
/* Aux buffers */
pglXGetFBConfigAttrib(gdi_display, cfgs[fmt_index], GLX_AUX_BUFFERS,
value);
if (ppfd-cAuxBuffers !value) {
goto choose_exit;
}
I compared both glxinfo outputs with the output from Nvidia cards and the main
difference is that Nvidia cards advertise aux buffers and others not. Removing
the code will likely fix the problem.
Roderick
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: [1/9] DDraw: Make IDirectDrawImpl thread safe
Stefan Dösinger [EMAIL PROTECTED] writes:
@@ -245,11 +252,12 @@ void
IDirectDrawImpl_Destroy(IDirectDrawImpl *This)
{
IDirectDrawImpl *prev;
+DDOBJ_LOCK(This);
You shouldn't need locking in Destroy, if the refcount is zero no one
else can be using the object.
for(prev = ddraw_list; prev; prev = prev-next)
+{
if(prev-next == This) break;
+}
if(prev)
+{
+DDOBJ_LOCK(prev);
prev-next = This-next;
+DDOBJ_UNLOCK(prev);
+}
You can't lock just one object, you have the protect the whole list.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Fwd: RFC: OpenGL x11drv rewrite (WoW fix)
Roderick Colenbrander wrote: If we could set a pbuffer flag in there and retrieve it in wglMakeCurrent it would work. I fear that this can only be done in a clean way if it code would be in x11drv :( I did that, I created a new field in the PDEVICE structure and used two new ExtEscape codes (SET_FLAGS/GET_FLAGS), but Alexandre doesn't want to add new ExtEscape codes.. That's why I hacked even more on wine and moved the wgl implementation to x11drv... and there they are, my old patches. I never bothered updating them though. tom
Re: [TRY 2] XEmbed System Tray Support
James Liggett [EMAIL PROTECTED] writes: +/* fall back to he KDE hints if the WM doesn't support XEMBED'ed + * systrays */ + +/* Put the window back within the screen so it will be mapped */ +SetWindowPos( data-hwnd, NULL, 0, 0, 0, 0, SWP_NOZORDER | SWP_NOSIZE ); It would be nicer to create the window with normal coordinates, and only move it off-screen when needed, instead of having off-screen be the default behavior. It would also avoid having explorer know about internals of the systray implementation. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Fwd: RFC: OpenGL x11drv rewrite (WoW fix)
I did that, I created a new field in the PDEVICE structure and used two new ExtEscape codes (SET_FLAGS/GET_FLAGS), but Alexandre doesn't want to add new ExtEscape codes.. That's why I hacked even more on wine and moved the wgl implementation to x11drv... and there they are, my old patches. I never bothered updating them though. tom We don't need very big changes. Basicly all code can be moved to x11drv. Then basicly we want access to our wglGetProcAddress function to get access to our wgl functions. We can dynamicly load those from opengl32 that way. All wgl functions in opengl32 can be stubs.I think this is the right way to do it. It works a bit more like a real ICD this way aswell. I believe that in case of a real ICD some ExtEscape-like call is used to retrieve a table with all exported opengl functions from an icd driver. It then does something similar to a GetProcAdress. The difference would be that we don't transfer the whole table but only a function to retrieve function calls. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: Read to 0x7ffe02c0
Vitaliy Margolen wrote: Tuesday, August 22, 2006, 1:56:20 AM, Juan Lang wrote: --- Vitaliy Margolen [EMAIL PROTECTED] wrote: 0x7ffe is KSHARED_USER_DATA and 0x2c0 is (not even sure how to get what is at this offset). You can see it's declaration in include/ddk/wdm.h Thanks Vitaliy. So this is supposed to be a boolean for some processor feature? I guess it doesn't matter what it contains, the problem is the address isn't mapped. Any idea what to do about that? I notice your patch[1] wasn't applied, but it doesn't apply cleanly anymore. Because Wine already reserves it but doesn't allocates it. All you need to do is to change this: http://source.winehq.org/source/dlls/ntdll/thread.c#L218 to look like: NtAllocateVirtualMemory( NtCurrentProcess(), addr, 0, size, MEM_RESERVE | MEM_COMMIT, PAGE_READONLY ); Vitaliy. This issue came up a week ago: http://www.winehq.org/pipermail/wine-devel/2006-August/050182.html
Re: developers-hints 2 -- second try
Tom Wickline [EMAIL PROTECTED] writes: Changelog: add newly implemented dlls and update http links I think the DEVELOPERS-HINTS contents should really be moved to the Wiki, it would be a lot easier to keep up to date there. Does anybody feel like doing that? -- Alexandre Julliard [EMAIL PROTECTED]
Re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462
Hi, Is there something wrong with this patch / a reason it's not being accepted? Sorry if this might have been answered this on IRC last night - X died while I was away, so I'd have missed it. Thanks, --Matt Finnicum On 8/19/06, Matt Finnicum [EMAIL PROTECTED] wrote: Hi, I've cleaned up / re-diffed this patch from Brian Chang. It fixes bug 4462 by handling several odd ways in which EM_EXSETSEL can be called. It also make the message return a proper value, not just zero. --Matt Finnicum (Please commit as Brian Chang) The last version of this patch can be found here: http://www.winehq.com/pipermail/wine-patches/2006-March/024976.html --- dlls/riched20/editor.c | 25 +--- dlls/riched20/tests/editor.c | 52 ++ 2 files changed, 73 insertions(+), 4 deletions(-)
Re: Read to 0x7ffe02c0
All you need to do is to change this: http://source.winehq.org/source/dlls/ntdll/thread.c#L218 to look like: NtAllocateVirtualMemory( NtCurrentProcess(), addr, 0, size, MEM_RESERVE | MEM_COMMIT, PAGE_READONLY ); Ah, indeed. Thank you, that solves it for me. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462
Matt Finnicum [EMAIL PROTECTED] writes: Hi, Is there something wrong with this patch / a reason it's not being accepted? Sorry if this might have been answered this on IRC last night - X died while I was away, so I'd have missed it. When resending a patch, especially a patch by someone else, please include the original Changelog, and the full name/email of the original author, so that I don't have to go hunt them down. Thanks. -- Alexandre Julliard [EMAIL PROTECTED]
Re: regression with gothic1/2
Am Tue, 22 Aug 2006 08:56:05 +0200 schrieb Stefan Dösinger [EMAIL PROTECTED]: This is odd, I did a regression testing and it came up with Jason Greens dynamic shader constant patch as the first bad commit. While this sounds odd for a d3d7 game it could happen because of broken stateblock initialization. With a enabling the heap filler I ended ap with a crash in dmusic(altough music in the game is disabled), using native dmusic made the game working again. You are right - with native dmusic,dmloader,dmime,dmsynth the game runs. I also had some dmusic/dmime output with the heap error, but that looked quite normal. Strange though that my regression testing had a different result. I did it just like the GitWine entry in the wiki suggests...
Re: developers-hints 2 -- second try
I think the DEVELOPERS-HINTS contents should really be moved to the Wiki, it would be a lot easier to keep up to date there. Does anybody feel like doing that? -- Alexandre Julliard [EMAIL PROTECTED] That would be a good place for it. It would be easier to locate. The developer's guide, resources, etc. on winehq should be redirect you to the wiki as well as its scattered about, partially on winehq and partially on the wiki site. It would be more helpful if this was all in one centralized location and you didn't have to jump back and forth between the two. A basic tutorial on how to write a hello world windows application under wine, with a form and controls would be helpful as well, for the person who was interested in writing a soundrec32 application or other similar applications.
Re: regression with gothic1/2
Hi, You are right - with native dmusic,dmloader,dmime,dmsynth the game runs. I also had some dmusic/dmime output with the heap error, but that looked quite normal. Strange though that my regression testing had a different result. I did it just like the GitWine entry in the wiki suggests... The error occurs only sporadic, sometimes it works with native dmusic friends stuff. I guess that sometimes it started successfully even though the bad patch was in. pgpvLNbtVta2F.pgp Description: PGP signature
Re: wine's fullscreen code has no effect on metacity
On 8/7/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Elijah Newren [EMAIL PROTECTED] wrote: Anyway, the returning from fullscreen mode bug makes perfect sense, and I'm pretty sure I know the cause: metacity tries to return the window to the size it was before it was fullscreened, and it sounds like it was successful in this case. Remember that the application resized itself to the size of the screen, then you (wine) noticed that and decided to send the fullscreen toggle message. Thus, the size the window had before being fullscreen, happened to be a size equal to the size of the screen. Since wine has added heuristics for detecting when an app sets its size to the size of the screen, I think it either needs to add heuristics for resizing back to normal size, or to just have the fullscreen toggle message replace the apps' resizing commands instead of supplementing them. Wine asks a WM to switch off the fullscreen state as a result of app's request to change its window size to something less than a screen resolution. So, the fix would be to change Metacity to not restore window's size if it's no more the same as it was before entering the full screen state. Ugh. Apparently, I busted our fullscreen handling in metacity=2.14.x in lots of cases in addition to problems we've being talking about in this thread. See http://bugzilla.gnome.org/show_bug.cgi?id=343115#c6 if you're curious. Anyway, I think I've fixed all those issues, and I believe my fixes should cover this last issue of yours (making windows return to the original size correctly). Is there any chance I could get you test (with metacity 2.15.34) and verify? (You could also backport the patch from bug 343115...) Thanks for all the help! Elijah
Re: msiexec: Add handling for msiexec's regserver option
On 8/22/06, Vitaliy Margolen [EMAIL PROTECTED] wrote:
Tuesday, August 22, 2006, 7:56:00 PM, James Hawkins wrote:
Hi,
More and more installers are expecting the MSI service to exist, or at
least be installable using msiexec /regserver. This patch is the
first step in fixing bug 5540.
+if (!scm)
+{
+fprintf(stderr, Failed to open the service control manager.\n);
+return 1;
+}
Please use proper WINE_[ERR|WARN|FIXME|TRACE] macros.
If you'll look in msiexec.c, you'll see that fprintf is used
throughout the entire file for error output. I'm just keeping the
style of the file consistent.
--
James Hawkins
Re: user: [2/2] Pass hook handle to the destination thread. Call server to get hook information
Thursday, August 17, 2006, 8:46:12 AM, Vitaliy Margolen wrote: ChangeLog: user: Pass hook handle to the destination thread. Call server to get hook information for inter-thread hooks. Currently Wine has a major problem with LL hooks (low level hooks) when second hook is installed in a separate thread - the second hook callback is never called. And while attempting to call it Wine almost locks up in never ending loop. This happening because instead of calling current thread's hook callback Wine restarts the whole hook chain from the start. This patch deals with both sides of this problem. Fixes Bug [5803], [5712] and possibly others. dlls/user/hook.c | 41 + dlls/user/message.c | 13 + dlls/user/user_private.h |7 +++ server/hook.c| 29 + server/protocol.def | 13 + 5 files changed, 95 insertions(+), 8 deletions(-) Why wasn't this patch accepted? Alexandre on IRC said that there are some race conditions here. I don't see how and where. The only possible place that I can think of is passing handle from one thread to the other thread using internal message. But that is covered. If the hook gets removed, we don't remove it in the server: http://source.winehq.org/source/server/hook.c#L291 When new hook is added, it's being placed ahead of all others, so it's not a problem either - we can't call it anyway after hook-chain has been started. Am I missing something here? Vitaliy Margolen
