RE: Loadorder no more honoured
Alexandre, Are you still working on the import mechanism in Wine. I just want let you know, I'm still experiencing a problem. I'm trying to run my program with the builtin OLE32 and the native RPCRT4. But since your changes, it's no possible anymore, Wine always uses the builtin version of RPCRT4. I can get around by forcing a LoadLibrary of RPCRT4 before OLE32, but I was wondering if there's more patches coming down the pipe that will address this issue. Thanks. Stephane Lussier Macadamian Technologies Alexandre Julliard writes: Francois Gouget [EMAIL PROTECTED] writes: I believe Alexandre is working on it. If I understand correctly (soon?) libraries should no longer be linked with each other in the Unix sense. Exactly yes. My latest commits should already fix most of the problem. -- Alexandre Julliard [EMAIL PROTECTED]
RE: TOPMOST window support
-Original Message-
From: gerard patel [mailto:[EMAIL PROTECTED]]
As you can see (I have also added trace in XSetWindowPos),
your last patch is doing restacking with unmapped windows :-)
While it does not crash *my* X server, this kind of call seems
to not produce any effect for me.
In my other failing app, the problem was similar but the app was
trying to set a window before a combolbox (hidden, of course).
The following patch fixes both my failing apps, but is it
correct ? Probably it should be done at the X SetWindowPos
level instead, but I'm not sure, these 'Z-order + visible' problems
are complex :-(
@@ -2737,7 +2737,7 @@
{
if (!(wndTemp-dwExStyle WS_EX_TOPMOST))
break;
- else
+ else if (wndTemp-dwStyle WS_VISIBLE)
{
/* this is a topmost window, place the window
after this one */
hwndInsertAfter = wndTemp-hwndSelf;
To do it right, I think we should do the change in the X11 layer. If your
current patch is accepted, that shouldn't be too hard to do now, that you're
keeping a flag for the mapping state. When restacking the window, instead of
just checking if hwndInsertAfter is not a ZeroSized window, we could simply
check if it is map or not (using the flag you've introduced).
OTOH, I have tried to reimplement your rejected patch on zero-size
windows; the attached patch tries to tackle the same problem in
the X-driver
I have changed the presentation of your code because I found
difficult to wrap
my small brain around it and added a feature to reset the z-order
when a window
is reordered while not being mapped.
This patch fixes my 2 not-yet-broken apps, fixes Lotus Notes,
fixes also 2 other
problems of managed mode (pseudotooltips of ForteFreeAgent, pseudo
combos of the open dialog box of WordViewer 16 bits). OTOH it probably
breaks lots of other applications :-)
I don't have a whole test suite of applications like you have, but your
patch is not causing any problem with the apps I'm working on. Also, I think
it is a little bit easier to read than current implementation.
Stephane Lussier
Macadamian Technologies
RE: isZeroSizeWnd in x11drv/wnd.c calculated wrongly ?
The real problem of Wine code is that it does not handle correctly the case when a window is created with a zero size, then it is resized to a non-zero size; it's not mapped in this case You're right about that. My code was assuming that rectWindow wasn't changed yet when entering in X11DRV_WND_SetWindowPos function, which was a false assumption. The attached patch fix the problem. Changed log: Force mapping a window if the window wasn't map, the window is visible and we are changing the size of the window. This case could occur, if the previous size was zero. Modified file: window/x11drv/wnd.c I would appreciate some comment of the person who wrote this code (hey, Stephane :)). (I'm confused by the winposPtr pointer; why not use wndPtr directly ? is there any case where the hwnd in winpos could be different from the hwnd in wndptr ?) You're right, winposPtr will always be the same as wndPtr. Maybe in the past it wasn't the case, and the code hasn't be updated. Stephane Lussier Macadamian Technologies zerosized.diff
RE: isZeroSizeWnd in x11drv/wnd.c calculated wrongly ?
Gerard wrote: Now, even if I added a flag in the X window structure instead of using the wnd structure, this would not be very satisfying as I don't really understand fully the X setwindowpos function. I would appreciate some comment of the person who wrote this code (hey, Stephane :)). (I'm confused by the winposPtr pointer; why not use wndPtr directly ? is there any case where the hwnd in winpos could be different from the hwnd in wndptr ?) Gerard Hey guys, I'm kind of busy today. I'll take a look at it early next week. Stephane.
RE: Window drawing
James,
I wasn't able to reproduce your problem, I've tried with UltraEdit and
HyperTerminal.
Anyway, with what you suggest in your previous mail, I think I know where
the problem is coming from.
Instead of not doing the Z ordering when the application ask to place the
window under a zero-sized window. Now, I found the window above the
zero-sized window, and use this window instead.
This patch makes the code a little more complex, but it's better than the
present code.
Could you try the patch, and let me know if it's fixing your problem.
Stephane Lussier
Macadamian Technologies
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of James Abbatiello
Sent: Tuesday, August 08, 2000 10:04 PM
To: [EMAIL PROTECTED]
Subject: Re: Window drawing
I'm seeing the same problem here (running managed under kwm).
The following programs now have their main windows appear behind
everything else:
HyperTerminal v595160, Netscape v4.61, UltraEdit v7.10b, Winamp v2.64,
and Windows Media Player v6.4.07.1112. The problem seems to be the
following patch:
revision 1.54
date: 2000/08/06 03:35:24; author: julliard; state: Exp; lines: +64
-12
Stephane Lussier [EMAIL PROTECTED]
Top level windows with 0 width or height are created with a size of 1x1
in
the X11 driver. I've added some code to make sure those windows are
never
mapped while the size = 0.
Specifically, the portion:
@@ -635,11 +677,13 @@
stack[1] = X11DRV_WND_FindDesktopXWindow( winposPtr );
/* for stupid window managers (i.e. all of them) */
-
- TSXRestackWindows(display, stack, 2);
- changeMask = ~CWStackMode;
-
- WIN_ReleaseWndPtr(insertPtr);
+
+ if (!X11DRV_WND_IsZeroSizeWnd(insertPtr))
+ {
+ TSXRestackWindows(display, stack, 2);
+ changeMask = ~CWStackMode;
+ }
+ WIN_ReleaseWndPtr(insertPtr);
}
}
if (changeMask X11DRV_WND_GetXWindow(winposPtr))
Moving the line
changeMask = ~CWStackMode;
back outside of the if statement restores the previous behavior for all
of the above apps. I doubt that this is the correct fix though. Would
the author or someone knowledgeable in the ways of X care to comment?
--
James Abbatiello
Christopher Morgan wrote:
Sawfish(0.30 I think). No problem really, feel free to email with any
other questions :-)
Chris
On Tue, 8 Aug 2000, Andreas Mohr wrote:
On Mon, Aug 07, 2000 at 11:08:13PM -0500, Chris Morgan wrote:
In managed windows do appear. It appears that the zorder
is being set
incorrectly(for my wm). I didn't originally see the window
as my xterms covered
the entire desktop and the window was behind the xterms :-)
"for my wm" -- very descriptive, thank you.
Andreas Mohr
restack.diff
RE: Dealing with zero-sized windows.
Gerard wrote: While this patch makes some of my test apps work better,one exhibits a regression : winhelp. I use Nt4 Sp3,the file is dated from 1997; I did not test other versions. The problem is that the first window appears behind all other non-Wine windows, so it seems to vanish. If I bring it to the foreground it is functional as before. Of course the way this app is displaying is very specific. If you want traces, etc, I'll take one week of holidays this Friday so don't waste time if you are interested. Or later (in 10 days :-)) Anyway, I would not be surprised if other versions of winhelp have the same problem, so it's possible you will be able to reproduce it. I presume this is what's happenning: 1. The window is created with widht=0 and heigh=0 2. The window is then activated/put on the foreground 3. Then the size of the window is changed to something that make sense. I'm not sure how to fix this problem yet, I will need to think about it. I should be able to find the right winhelp reproducing this behvior. I've got just a couple quick questions on your setup: Are you using any native DLL? Which desktop/WM are you using? (KDE? Gnome?) Some Window managers are very sensitive to Z ordering with Wine. Stephane Lussier Macadamian Technologies
RE: InternetCheckConnection
Marcus, looking at Microsoft documentation seems to indicate if FLAG_ICC_FORCE_CONNECTION is set, it should try to ping the URL. http://msdn.microsoft.com/workshop/networking/wininet/reference/functions/In ternetCheckConnection.asp Stephane Lussier Macadamian Technologies -Original Message- From: Marcus Meissner [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 26, 2000 6:01 AM To: Aric Stewart Cc: [EMAIL PROTECTED] Subject: Re: InternetCheckConnection On Tue, Jul 25, 2000 at 10:14:25AM -0500, Aric Stewart wrote: This implements InternetCheckConnection. Because i cannot do it properly i had to use a kludge where i call ping via a system call. Explanation as well as the way i wanted to to the ping are in the code. I have doubts about this is being a good idea. pinging www.ibm.net? Not a good idea, this can be considered a denail of service attack. Imagine an application doing TryFireUpDialin(); while (!InternetCheckConnection()); Not good. Also even without a ping getting through we can still access URLs if behind a firewall. We should probably just check if we have a network connection at all. Or only return TRUE. How to check network connections: Parse output of: /sbin/ifconfig - for occurences of ppp*, eth* or similar. - for occurences of non 127.* addresses. /sbin/route -n - dito Ciao, Marcus
Backing store option. (painting optimization)
Hi, Is there a reason why we're setting the "backing_store" attribute to "NotUseful" at the creation of a X window? Setting it to "WhenMapped" increase significantly the refresh rate when moving or resizing a window (see the patch below). I understand that it will take more memory using this option, but I'm more concerned with the fact that it could cause some side effects with some applications. I'll be very surprise that nobody has never thought of setting this flag before, so I suspect there's some good reason to setting it to "NotUseful", anybody can tell me why? Stephane Lussier Macadamian Technologies Index: windows/x11drv/wnd.c === RCS file: /home/wine/wine/windows/x11drv/wnd.c,v retrieving revision 1.50 diff -u -r1.50 wnd.c --- windows/x11drv/wnd.c2000/07/10 12:09:32 1.50 +++ windows/x11drv/wnd.c2000/07/19 13:11:28 @@ -295,7 +308,7 @@ win_attr.bit_gravity = (classPtr-style (CS_VREDRAW | CS_HREDRAW)) ? BGForget : BGNorthWest; win_attr.colormap = X11DRV_PALETTE_PaletteXColormap; - win_attr.backing_store = NotUseful; + win_attr.backing_store = WhenMapped; win_attr.save_under= ((classPtr-style CS_SAVEBITS) != 0); win_attr.cursor= X11DRV_MOUSE_XCursor;
RE: EventExpose race condition problem
Ian, This patch should solve the splash screen problem you're experiencing. Let me know if it works. The patch is slightly different to what Gerard posted last week. I've done the invalidation in the service thread, and erased the background on reception of WM_SYNCPAINT only if it was needed. (based on Ove's suggestion) Stephane Lussier Macadamian Technologies -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ian Schmidt Sent: Saturday, July 15, 2000 12:31 AM To: gerard patel Cc: [EMAIL PROTECTED] Subject: Re: EventExpose race condition problem gerard patel wrote: I have tried a quick and dirty implementation of WM_SYNCPAINT and it seems to work as you intend. I have not seen any nasty side-effect on any program I use. Some paintings have a different order, it seems that a few splash screen are not painted as fast as before, but no crash or obvious mis-paintings. Gerard, This patch greatly improves Visual C++'s painting behavior. Previously it had severe problems where portions of the window wouldn't paint correctly or wouldn't paint at all. Now there's one problem remaining and one new one (Both managed and unmanaged modes behaved the same). - The left strip of the editor where e.g. breakpoint icons appear still isn't right. Without the patch it never paints at all (you see whatever's behind the window). With the patch it paints properly on initial draw when you open a project, but all refreshes of the window after that revert to the old broken behavior. - The splash window doesn't appear at all now (without the patch it works fine). Still, impressive improvement for a "quick and dirty" patch :-) -Ian Schmidt [EMAIL PROTECTED] expose.diff
FW: EventExpose race condition problem
I've made a mistake in my previous patch, Take this one instead. Stephane. -Original Message- From: Stephane Lussier [mailto:[EMAIL PROTECTED]] Sent: Monday, July 17, 2000 3:07 PM To: Ian Schmidt Cc: [EMAIL PROTECTED]; gerard patel Subject: RE: EventExpose race condition problem Ian, This patch should solve the splash screen problem you're experiencing. Let me know if it works. The patch is slightly different to what Gerard posted last week. I've done the invalidation in the service thread, and erased the background on reception of WM_SYNCPAINT only if it was needed. (based on Ove's suggestion) Stephane Lussier Macadamian Technologies -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ian Schmidt Sent: Saturday, July 15, 2000 12:31 AM To: gerard patel Cc: [EMAIL PROTECTED] Subject: Re: EventExpose race condition problem gerard patel wrote: I have tried a quick and dirty implementation of WM_SYNCPAINT and it seems to work as you intend. I have not seen any nasty side-effect on any program I use. Some paintings have a different order, it seems that a few splash screen are not painted as fast as before, but no crash or obvious mis-paintings. Gerard, This patch greatly improves Visual C++'s painting behavior. Previously it had severe problems where portions of the window wouldn't paint correctly or wouldn't paint at all. Now there's one problem remaining and one new one (Both managed and unmanaged modes behaved the same). - The left strip of the editor where e.g. breakpoint icons appear still isn't right. Without the patch it never paints at all (you see whatever's behind the window). With the patch it paints properly on initial draw when you open a project, but all refreshes of the window after that revert to the old broken behavior. - The splash window doesn't appear at all now (without the patch it works fine). Still, impressive improvement for a "quick and dirty" patch :-) -Ian Schmidt [EMAIL PROTECTED] expose.diff
RE: EventExpose race condition problem
Ove wrote: That is, we'd do: Service thread: 0. Receive Expose 1. Invalidate window rectangle 2. SendNotifyMessage(wnd,WM_SYNCPAINT,0,0); 3. Forget it and move on to doing other stuff DefWndProc: 0. Receive WM_SYNCPAINT 1. Check update region 2. Send ERASEBKGND and NCPAINT messages as necessary... Right now, the service thread sends ERASEBKGND and NCPAINT messages itself, which is a deadlock condition in multimedia apps. This would solve those, too... I'm not sure you should let the service thread do the invalidation. I think it is better to do it in the DefWndProc while processing WM_SYNCPAINT. You don't want have more than one thread playing with hrgnUpdate field in the window structure. Stephane Lussier Macadamian Technologies
RE: EventExpose race condition problem
Ove wrote: Internal window structure members are protected by the WIN_SysLevel lock, maintained by WIN_FindWndPtr/WIN_LockWndPtr/WIN_ReleaseWndPtr. That's not an issue at all. Oups, I forgot about that, you're right. Now I see your point, doing the invalidation in the service thread will give us the chance to sometime avoid an unnecessary repaint of the Window. In the case where by the time WM_SYNCPAINT is received if the application thread repaint the window, we won't have to repaint it another time while processing WM_SYNCPAINT. Stephane Lussier Macadamian Technologies
RE: Associations and a winelib application
Look at the implementation of ShellExecute in the Corel tree (opensource.corel.com). Association between file extension and application is stored in the registry (in Windows and in Wine Corel tree).I don't remember exactly which key, but that shouldn't be too tough to find. Now, Corel has modified some code inShellExecute (and all functions called by this function), to be able to discover if it's a Wine app or a native app, so to be able to launchthe application correctly. I know, this is kind of hacky, but this is effective. Stephane Lussier Macadamian Technologies -Original Message-From: Ed Snow [mailto:[EMAIL PROTECTED]]Sent: Thursday, June 29, 2000 4:07 PMTo: Wine-DevelSubject: Associations and a winelib application I am porting an application to run as a winelib app. It currently uses Windows mechanisms (at least ShellExecute) to initiate a Browser with a specific url. I would like to generate the same result under linux. I am new to KDE and Gnome, but they seem to have the association concept. What would the right way to approach this be? Ed Snow TTM Engineering10925 Corte CodornizSan Diego, CA 92128 Phone 858-672-3306 Fax 858-672-4642 mailto:[EMAIL PROTECTED] Focused on Time to Market
RE: EventExpose race condition problem
Gerard wrote: That's a problem I was hoping to tackle some time (lot of more urgent problems in the stack); my first idea was rather to flag the windows to be 'in painting', test the flag in the event code and just pass on the redrawwindow call; what do you think of this approach ? (I did not even think to begin a preliminary trial version so maybe there is an obvious fatal flaw...) I'm not sure, I correctly understand your idea. Where do you plan to set your 'in painting' flag? In BeginPaint? When the service thread process the expose event, it is possible the application hasn't started to repaint the window, and you'll do the RedrawWindow() call and you still have chance to end out with the window being erased. The problem is the application thread and the service thread are both trying to paint on the window without any synchronization. Let me describe again the order of events: 1. Service thread process an Expose event 2. Service thread call ReDrawWindow 2a. Service thread invalidate the window 2b. Service thread send a message to the application thread to erase the background. 2b is inter-thread send-message, so the message won't be process until the application do a GetMessage/PeekMessage. 3. Application thread is now running, and eventually could decide to repaint the window, which will validate the window. 4. Application thread do a GetMessage() 5. Pending inter-thread SendMessage is executed, and the background is erased. I think a better approach to avoid the extra repaint (and possibly remove some flickers) will be to use WM_SYNCPAINT message. On an ExposeEvent: a. Service thread invalidate the expose event. b. Send a WM_SYNCPAINT message to the application. lParam is pointing on the expose rectangle. On reception of an WM_SYNCPAINT in def window proc: a. Check if the rectangle pointed by lParam is still part of the invalid region (or update region) b. If so, erase the background (WM_ERASEBKGND) and repaint the non client area (WM_NCPAINT) With this solution, the WM_ERASEBKGND and WM_NCPAINT, will always be sent by the application thread, and we should avoid the race condition. I must admit, because of the lack of documentation on WM_SYNCPAINT, I'm not quite sure it's exactly the way this message should be used. Probably one day, I'll implement this, if nobody tries to do it before, but I'm like you, I've got more urgent problem to deal with. For now I think it's better to repaint twice (in very few occasions) that having a blank window. Stephane Lussier Macadamian Technologies
RE: socket patch, for network events not being signaled.
Thanks for pointing me this stupid mistake. The correct patch is attached. Is there anybody that can give more details on the possible problems of doing set_event twice in the same handler mentionned by Ove's mail? If it's a problem, I guess I can check if the event is signaled before seting it, but I haven't see any code doing this kind of stuff in the server. Stef. -Original Message- From: Ove Kaaven [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 28, 2000 10:42 AM To: Stephane Lussier Cc: wine-patches Subject: Re: socket patch, for network events not being signaled. On Wed, 28 Jun 2000, Stephane Lussier wrote: +if (sock-pmask sock-mask) +set_event(sock-event); Well, at least you could have used the binary operator () instead of the logical one ()... But note that I also seem to recall certain problems in the wineserver if set_event is called on some event objects (don't remember if it was manual reset or automatic reset) twice in the same handler, so perhaps you should verify that this won't happen. set_socket_event.diff
RE: Indeo Codec
Gilroy Billard wrote:
Wine also reports this error three times: "err: module:BUILTIN32_dlopen
failed to load libir50_lcs.so: /root/wine/cvs/libir50_lcs.so: cannot open
shared object file"
Wine could not found ir50_lcs.dll. Your program probably requires this DLL
to run under Windows, but it can't find it when running under Linux with
Wine.
Stephane Lussier
macadamian Technoologies
RE: WSAEventSelect (WinSock) patch. (fwd)
Ove, By looking a second time at the code, you're right all the way. In my case the event should be signaled (because there's a network event pending) , and it's not, I will track down th real problem and send another patch. Thanks, Stephane. -Original Message- From: Ove Kaaven [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 21, 2000 5:29 PM To: [EMAIL PROTECTED] Subject: Re: WSAEventSelect (WinSock) patch. (fwd) On Wed, 21 Jun 2000, Stephane Lussier wrote: ChangeLog: In WSAEventSelect() function of WinSock, the event should be signaled right away if there's some network events pending corresponding to the event selected in this function. That's how WSAEventSelect behaves under Windows. This patch seems incorrect to me. For one, the _get_sock_mask() function retrieves the current event mask, not the pending events (the pending events are in the "pmask" field of the server request, if you look at WSAEnumNetworkEvents), so this patch would simply *always* signal the event. Second, the server request set_socket_event (handled in server/sock.c) *already* checks the new event mask and acts on it (i.e. signals the event) immediately while handling set_socket_event, so it's not necessary for the client side to do so (it is a race condition to let the client side do so anyway). At least that's the theory; there could be some bugs lurking around...
RE: X Error of failed request: BadValue
Hi, Here's what I normally do when approaching problem at the X level (X error ...) First, this message is caused by a wrong call made to X API or a bug in X. In both cases you should start looking for which X call is causing the problem. All calls to X are in one directory: tsx11/*.c. Adding trace in TSX functions, should allow you to find it quickly. Looking at your error, it looks like it is XCreateWindow, then you should trace all the parameter of the failing call, and then verify each of the parameters according to X documentation (Ex: make sure the parent parameter is a valid Window when calling XCreateWindow). Also it is possible the problem is cause by a combination of X call. I hope, this helps. Stephane Lussier Macadamian Technologies -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, June 16, 2000 2:57 AM To: [EMAIL PROTECTED] Subject: X Error of failed request: BadValue Good day! I don't have a clue how to debug this. Wine-2614. (unmanaged) X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 1 (X_CreateWindow) Value in failed request: 0x0 Serial number of failed request: 4009 Current serial number in output stream: 4035 err:win32:EnterCriticalSection Critical section 0x402c2150 wait timed out, retrying (60 sec) err:win32:EnterCriticalSection Critical section 0x402c2150 wait timed out, retrying (60 sec) The debugger seems to insist on running in an xterm, but I thought it might not get buried if I used desktop: winedbg --desktop 800x600+200+150 /dosw/j1.49/bin/juno.exe The error does not occur. I guess I can try to debug it in unmanaged mode, but I fear the debugger will be buried, and I'm not much good with X errors. I'll even try --managed if I have to, but I was hoping maybe somebody already knew what this is. Regards, Lawson Oh - Michael McCormack, those little comm fixes are no harm to juno 1.49. :-) --- YOU'RE PAYING TOO MUCH FOR THE INTERNET! Juno now offers FREE Internet Access! Try it today - there's no risk! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
RE: problems with DestroyWindow
Serge,
It looks like to me the right way to fix the problem you mentioned. It
doesn't make sense than an unlinked window (a window removed from the tree)
has still a pointer on another window that is still in the tree. (via it's
next, parent or child pointer).
So why not extending your patch and setting wndptr-child and wndptr-parent
to 0 also.
Stephane Lussier
Macadamian Technologies
-Original Message-
From: Serge Ivanov [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 12, 2000 10:43 AM
To: [EMAIL PROTECTED]
Subject: problems with DestroyWindow
It looks like DestroyWindow has severe (potential?) problem.
There are some
situations when memory occupied be WND structure is released
earlier than it
is expected. It happens when window to be destroyed has any owned windows.
The problem place is very end of DestroyWindow:
windows/win.c: line 1417:
/* Unlink now so we won't bother with the children later on */
if( wndPtr-parent ) WIN_UnlinkWindow(hwnd);
/* Destroy the window storage */
WIN_ReleaseWndPtr(WIN_DestroyWindow( wndPtr ));
retvalue = TRUE;
end:
WIN_ReleaseWndPtr(wndPtr);
return retvalue;
}
---
Unlinked wndPtr still keeps pointer to the next window.
WIN_DestroyWindow is supposed to clean up window data and returns locked
pointer to next window. So we call WIN_ReleaseWndPtr to unlock it.
Several lines above this point DestroyWindow calls itself to destroy owned
windows. Sometimes owned window can have owner as next window in chain. So
it goes to WIN_Release(WIN_Destroy) place. I can't figure out where we
skipped
lock increment, but WIN_Release recieves wndPtr with irefCount == 1 so it
frees memory used by window.
A possible solution is to zero next ptr in UnlinkWindow as follows:
Index: win.c
===
RCS file: /home/cvs/r/corelwine/windows/win.c,v
retrieving revision 1.92
diff -u -r1.18 win.c
--- win.c 2000/06/08 01:01:09 1.92
+++ win.c 2000/06/08 19:46:31
@@ -320,6 +320,7 @@
if (*ppWnd)
{
*ppWnd = wndPtr-next;
+wndPtr-next = NULL;
ret = TRUE;
}
WIN_ReleaseWndPtr(wndPtr);
Or we can do it locally in DestroyWindow right after UnlinkWindow call.
Any comments?
--
Serge Ivanov
[EMAIL PROTECTED]
--
The address in the headers is not the poster's real email
address. Do not send
private mail to the poster using your mailer's "reply" feature.
CC's of mail
to mailing lists are OK. Problem reports to
"[EMAIL PROTECTED]".
The poster's email address is "[EMAIL PROTECTED]".
RE: cvs.winehq.com Down
I had the same problem, This resolved my problem. cvs logout cvs login Stephane Lussier Macadamian Technologies -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Adam Sacarny Sent: Tuesday, June 06, 2000 1:10 AM To: [EMAIL PROTECTED] Subject: cvs.winehq.com Down Hi! cvs update for cvs.winehq.com now produces this error: cvs server: Updating dlls/kernel cvs server: failed to create lock directory in repository `/home/wine/wine/dlls/kernel': Permission denied cvs server: failed to obtain dir lock in repository `/home/wine/wine/dlls/kernel' cvs [server aborted]: read lock failed - giving up Adam -- +---+ | Email: [EMAIL PROTECTED] Yahoo Messenger: Asacarny | |IRCNet/UnderNet: Asacarny ICQ: 19617831 AOL: Jazzrock12| |Wine Daily Builds: http://panter.soci.aau.dk/~dailywine| +---+
RE: LOCAL_GetBlock not enough space in GDI local heap
Jacques, In Wine there's currently a limitation on the size of the GDI heap. It is limited to 64K. This is a old limitation from Win 3.1 (16 bits), this limitation doesn't exist under Win9x/WinNT. Alexandre fixed that issue on the Corel wine tree, and I'm pretty sure eventually somebody will merge his work back into Wine-HQ source tree. It could even be you :-) If your application creates a lot of Gdi objects that could be the problem. Or maybe also your application leaks some Gdi object, if it's the case you'll run into that problem (no more space in the Gdi heap) much faster than in Windows. I think in Windows you can create 64K objects before Windows starts to complain. Stephane Lussier. Macadamian Technologies -Original Message- From: Jacques Gelinas [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 01, 2000 12:58 PM To: [EMAIL PROTECTED] Subject: LOCAL_GetBlock not enough space in GDI local heap We are trying to run a win32 application on wine and linux. The application is starting and ultimatly fails with the following message. LOCAL_GetBlock not enough space in GDI local heap (01d7) for 60 bytes The application does quite a lot before failing. It does ODBC access to a sybase server, brings its splash screen, then its main windows. Note that this application main window use quite a few widgets. It is made of a notebook object with several data browsers and input fields distributed in the various pages. Trying to pinpoint the offending piece of code (This is our own application, so we have to source), we think it is not any code in particular, but simply because there are two many widgets. Commenting out the area where our app fails, we get a little further and fails in another window. I would expect that a 32 bit application is not using the 16 bits heap much (--debugmsg +heap shows differently). Am I missing something ? The application is built using the wxWindow 1.66 toolkit. We came to the following conclusion (and we are no windows expert). Anyone may comment ? It is a limitation in wine. Its GDI library is still using a lot of 16 bits object. It is a limitation in win32. Is has to use 16 bits heap objects (then why our app is working correctly in windows and windows NT) Something odd is happening somewhere and confuse wine, so the error above does not mean much. We are getting this with the latest CVS version (well, updated may 25) - Jacques Gelinas [EMAIL PROTECTED] virtualfs: Automounting floppy, CDs, network share, etc... http://www.solucorp.qc.ca/
RE: AltGr support (for non US keyboard).
Gerard, That's funny, for me it's the other way around. I'm getting the result you mention before applying. Anyway, could you launch Notepad with "debugmsg +key" and type "AltGr+2", then send me the trace. I'll take a look. Thanks, Stephane. -Original Message- From: gerard patel [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 13, 2000 11:50 AM To: [EMAIL PROTECTED] Subject: Re: AltGr support (for non US keyboard). At 03:54 PM 4/13/00 -0400, you (Stephane Lussier) wrote: Change log: This patch will allow AltGr key (left Alt key with non US keyboard) to work properly with all Linux flavors. (not that I tested the patch on every flavor) Previous implementation didn't work for CorelLInux 1.0 and RedHat 6.1 snip With your patch, AltGr 2 displays é (the value for the 2 key with a french keyboard) and no more ~ (the value that is displayed under win32 when using AltGr). In short, it's a regression for me :-/ Using XFree86 11.0 (comes with my Suse 6.1) Gerard
RE: Non us keyboard and AltGr key
Alexandre wrote:
It may be due to the fact that Wine disables the XKB extension. I'm
not entirely sure why we do that but there was probably a good
reason...
--
Alexandre Julliard
[EMAIL PROTECTED]
You're right. By commenting the line:
putenv("XKB_DISABLE=");
in windows/x11drv/main.c : X11DRV_USER_Initialize()
I can now see the 0x2000 in the state field.
On my machine, it looks like the AltGr modifier for International keyboard
is implemented using this extension, it looks like I will need this to be
able to support correctly international keyboard. Does somebody out there
knows/remembers why do we have to disable the XKB extension in Wine?
Stephane Lussier
Macadamian Technologies
