wine-devel July 2001

wine-devel@winehq.org

62 participants
189 discussions

CoGetClassObject
by Daniel Walker 07 Aug '01

07 Aug '01

I was thinking of ways to get the CLSCTX_LOCAL_SERVER option working in wine. The only program that uses it , that I know of, is installshield v6 .. I pretty sure some other people are working on this, but I don't know that status. (Anyone care to update me?) There is another problem. It's with the TypeLib information in the IKernel.exe that comes with InstallShield v6. The TypeLib information is encoded somehow, any ideas? I was able to get around that problem because installshield also looks for type information in "ikernel.tlb" . So I was able to create a .tlb that worked. I also used the reaktivate typelib patch so the typelib info gets put into the registry. So the way I understand it is that when CoGetClassObject is called Wine is suppose to , in this case, execute IKernel.exe . Then IKernel.exe will CoRegisterClassObject on all needed objects .. One problem is that the registered class object list isn't shared between the two processes, so we would need to move that list into the wine server (Right?) .. Then we would also need to send an instance of the class object to the Wine server (Yeah??) .. Following that road seems to lead to some messy address translations for DLL's and whatever else.. Since we have complete control over how IKernel.exe is run, how would we get the two processes to share memory? Maybe have IKernel.exe execute in a thread? IKernel.exe doesn't do anything but register it's class objects .. Would it be possible to treat IKernel.exe as a DLL then run CoRegisterClassObject for it? Daniel Walker

8 13

Re: (no subject)
by Alexandre Julliard 05 Aug '01

05 Aug '01

Ladislav Sladecek <lsla(a)post.cz> writes: > If you run the binary in the Windows, you will see two properly sized > red rectangles on a white background. If you run the same binary in > Wine, you will see only one large red child but no white parent > background. If either the CS_PARENTDC or WS_CLIPSIBLINGS gets removed > from my example, both Windows and Wine give identical results. Yes, there were a number of problems with the flags handling in GetDCEx. I think the behavior with the current CVS should now be correct in all cases; please give it a try. -- Alexandre Julliard julliard(a)winehq.com

3 3

Dose wine people hate Solaris?
by EriK W 03 Aug '01

03 Aug '01

I have posted my question for compiling Wine in solaris x86 for 2 weeks, seems no anybody even has a bit interest. Do you guys hate solaris? :) I checked almost all the documents and faq, except it mentioned wine works with Solaris, there almost have no other info for it at all. Does anybody has even a suggestion for me? pls don't tell me nuke my solaris. :)

5 8

Re: Prevent excessive clipping in SysListView32
by Uwe Bonnes 02 Aug '01

02 Aug '01

>>>>> "Medland," == Medland, Bill <Bill.Medland(a)accpac.com> writes: Medland,> I am not very comfortable with this one but strange as it may Medland,> seem it solves the problem. I'd love to know why. Medland,> <<diff13.txt>> Bill Medland (medbi01(a)accpac.com) Prevents Medland,> excessive clipping in SysListView32. Medland,> Medland,>-static inline int perfect_graphics(void) Medland,>+static int perfect_graphics(void) Medland,> { Medland,> static int perfect = -1; Medland,> if (perfect == -1) Medland,> Some C-Expert is requested here, but I suspect that in the old function the variable "perfect" was created in every instantiation of the "perfect_graphics" inlined function. Could you perhaps try to declare the "perfect" outside the inlined function, like static int perfect = -1; static inline int perfect_graphics(void) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

6 9

Documenting functions
by Bill Medland 01 Aug '01

01 Aug '01

Getting back to what we are and are not allowed to do.. Suppose I am looking at a low-level function that I believe is only 75%-complete (the most important 75% of course and no disrespect meant to those who have got it that far). One of the problems with it is it is not totally clear EXACTLY what the function should do in some of its more esoteric modes. To me the first task is to define what it should do and that should be part of the documentation of the function. The particular function currently does not have any true documentation within the code; the best documentation of what it does is the code itself, and the best documentation of what it should do is the MSDN description of the function. 1. Should the function be completely defined in its header in the source code (which will probably make the header twice as large as the function) or should the details be put somewhere else. 2. Are we walking into copyright danger if the Wine documentation of the function is clearly based on the MSDN documentation, even if we acknowledge that. 3. Are we interested in that level of documentation? Bill

4 3

Re: Patch to fix the Linux 2.2 joysitck interface
by Alexandre Julliard 31 Jul '01

31 Jul '01

David Hagood <wowbagger(a)sktc.net> writes: > To be done: the file descriptor is never closed under normal > circumstances - this might be a problem if a Wine app is opened and > accesses the stick, as the file descriptor will be open until that > process terminates. If this is viewed as a problem, it would be a simple > matter to add a device close function to the Wine driver to close the FD. Shouldn't this be done in the driver DRV_OPEN/DRV_CLOSE calls then? Any joystick experts out there? (BTW please use diff -u to generate patches, the default diff format is unreadable). -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: RFC: Patch for making GrabPointer work
by Alexandre Julliard 31 Jul '01

31 Jul '01

Jukka Heinonen <jhei(a)iki.fi> writes: > Storing old windows procedure in struct x11drv_win_data > would remove the worst race, but unless window > procedure update is atomic, it would not remove > all races. Since you have the window locked when changing the wnd proc the update will be atomic. The only problem I see is that your wnd proc might get called to process some other message, but you can solve this by having it chain to the previous wnd proc for all messages except the special one. -- Alexandre Julliard julliard(a)winehq.com

2 1

Relocatoion and ExceptionFilter problem?
by EriK W 30 Jul '01

30 Jul '01

Now I finally made a wine , :) But I can't get any program to excute so far, mostly It is like bash-2.03# wine --winver win95 sol.exe err:seh:UnhandledExceptionFilter Couldn't start debugger (debugger/winedbg 134639312 24) (2) Read the Wine Developers Guide on how to set up winedbg or another debugger or bash-2.03# wine --winver win98 icq2000b.exe err:win32:do_relocations Standard load address for a Win32 program not available - patched kernel ? err:win32:do_relocations FATAL: Need to relocate F:\export\home\ericw\system\icq2000b.exe, but no relocation records present (stripped during link). Try to run that file directly ! wine: can't exec 'icq2000b.exe': error=21 This wine seems taste not good, :) Francois Gouget wrote: > On Thu, 26 Jul 2001, EriK W wrote: > > > > What does not work? Do you have unicode/libwine_unicode.so or not? > > > Does the following command run or does it say it cannot find > > > libwine_unicode.so? > > > > > I does have the libwine_unicode.so > > but it just don't go to ~unicode directory to search for it, it always > > report " can't find it in /usr/local/lib" I don't know why, I am using bash, > > so I just simply copied libwine_unicode.so over to make it happy. > > I was wondering if it was the shell not exporting the environment > variable or something. Since you're using bash it should be all fine. > So you have to figure out why setting LD_LIBRARY_PATH does not work. > It's supposed to work. I'm 99.9% sure I did use it on Sparc Solaris so I > really don't see why it would not work on Solaris x86. Plus > LD_LIBRARY_PATH is such an important thing that it would be very > surprising if it really did not work and nothing else was broken in your > system. > > Did you try specifying an absolute path like: > LD_LIBRARY_PATH=/export/home/system/wine-20010629/unicode ./tools/winebuild/winebuild > > What does 'echo $LD_LIBRARY_PATH' normally say? Is it empty? > > [...] > > take it out? > > Can I do that by commenting " > > LIBPROGRAMS = \ > > debugger/winedbg" ? > > The following patch should do that nicely: > > --- cut here --- > Index: Makefile.in > =================================================================== > RCS file: /home/wine/wine/debugger/Makefile.in,v > retrieving revision 1.24 > diff -u -r1.24 Makefile.in > --- Makefile.in 2000/12/29 05:38:00 1.24 > +++ Makefile.in 2001/07/27 01:39:15 > @@ -3,7 +3,7 @@ > TOPOBJDIR = .. > SRCDIR = @srcdir@ > VPATH = @srcdir@ > -MODULE = winedbg > +MODULE = #winedbg > > C_SRCS = \ > break.c \ > --- Makefile.orig Thu Jul 26 19:03:36 2001 > +++ Makefile Thu Jul 26 19:00:53 2001 > @@ -3,7 +3,7 @@ > TOPSRCDIR = .. > TOPOBJDIR = .. > SRCDIR = . > -MODULE = winedbg > +MODULE = #winedbg > > C_SRCS = \ > break.c \ > --- cut here --- > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Broadcast message : fin du monde dans cinq minutes, repentez vous !

2 2

RE: Small OpenGL patch
by Patrik Stridvall 30 Jul '01

30 Jul '01

> It also puts the 'make_opengl' script in line with the latest > modification > to the spec file. It also changes the OPENGL32.@ to OPENGL.@ > as per Patrik's > modifications in 'make_opengl'. Arrgghhh! I just saw that I didn't do the same change in the script as in the .c files (I didn't run the script, since it worked badly last time I tried with my OpenGL files). Braino. :-( It should of course be OPENGL32.@ not OPENGL.@. The .c files was correct as they were. Sorry to cause you problems but can you fix the script and rerun on your OpenGL files and resubmit. > PS: god I hate Perl... I may well rewrite 'make_opengl' in > Python one of > these days :-) Whats wrong with Perl? I write applications sometimes in Perl and sometimes in Python, and I like them both and a dislike somethings about each language as well. Of course Perl is a little more difficult to learn but still. PS. You will se one of the advantages of Perl if you add use strict; at the top of the script. Of course after that you will have to declare all variable to it keeps the number of bugs down.

1 0

RE: winapi update
by Patrik Stridvall 30 Jul '01

30 Jul '01

> > In short, please apply it, they facillitates using the > > winapi tools alot and might make more people actually > > use them. They don't hurt anything. > > The problem is if we make it part of the default make install all Wine > distributions will include these non-functional (from the user POV) > scripts, and I don't think this is a good idea. That is true. > So I have applied it > but it doesn't run by default; developers who want it should run make > install in the tools/winapi directory. Ah, of course. Good idea. Thanks. This brings to mind the fact that three different kinds of "users": 1. Ordinary users 2. Wine/Winelib developers 3. Winelib application developers that need different kinds of tools installed. Not that I have any good solution to the problem. And not something that really is a problem either. Is was just something that occured to me. Oh well. Never mind.

1 0

Re: winapi update
by Alexandre Julliard 30 Jul '01

30 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > A full install is largely meaningless since the winapi tools are made > for work on a Wine source tree, so making them independant of such > a tree is largely meaningless. Agreed. > In short, please apply it, they facillitates using the > winapi tools alot and might make more people actually > use them. They don't hurt anything. The problem is if we make it part of the default make install all Wine distributions will include these non-functional (from the user POV) scripts, and I don't think this is a good idea. So I have applied it but it doesn't run by default; developers who want it should run make install in the tools/winapi directory. -- Alexandre Julliard julliard(a)winehq.com

1 0

broken misc/version.c (patch 1.43 -> 1.44) WIN95 value in version16
by Ladislav Sladecek 30 Jul '01

30 Jul '01

Two days ago a 16 bit application, which I use, started to complain about unknown windows version. After I rgressed to 1.43 of misc/version.c, everything was OK. I found the problem in the GetVersionInfo value that you changed at line 75 of the file. My windows 95 returns 0xC0000004 in WIN32 and 0x07005F03 in WIN16. You changed the 16bit value from 0x7005F03 to 0x7000304. Can you please check this? Do you have some docs? I think that we that we are both right; the value probably depends on longitude, altitude, and Windows language version. Mine iWindows 95 is Czech Edition, SR2. Regards Ladislav Sladecek

1 0

RE: winapi update
by Patrik Stridvall 30 Jul '01

30 Jul '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > I have resent winapi_install patch. > > > > While it probably that you didn't apply > > it because of lack of time I resend > > for your convinience. If not please > > explain. > > Correct me if I'm wrong, but it seems you are not actually installing > anything, only a script that needs the Wine source tree to work. That is a correct conclusion. > I don't really see the point. The point is that when you are in some sub directory of a wine tree, you can just write winapi_check or make_filter and whatever and it will call the correct version of the tool. Instead of having to type, if you are in dlls/winsock. ../../tools/winapi_check Sure you can currently do make winapi_check or make filter and adding winapi_{extract,fixup} is trivial but giving arguments through make is a little awkward. That why I wrote a few script to fix this and now when I have a tool (make_filter) that could possibly enjoy a wider use I decided to make a formalized "install" for them. > If you want to install something it should > be a complete installation that works without external files (not that > I suggest doing that for winapi_check, at least not by default). A full install is largely meaningless since the winapi tools are made for work on a Wine source tree, so making them independant of such a tree is largely meaningless. Well they actually are indendent of the specific tree they where install from. They do not reference to it at all. They use the current directory to find the real winapi tools in that tree. They will work equally well with any tree (of a later date than your hopefull application of the patch that is). They are as they are by design, not by mistake, and complete installation of them is almost completly meaningless. Sure there might be future winapi tools worthy of a complete install, a future tool for automatical generation of .spec files from any Winelib application, that we talked about some time ago, comes to mind, but I'm not there quite yet. I have begun to implement simple typedef parsing but it doesn't work 100% yet. In short, please apply it, they facillitates using the winapi tools alot and might make more people actually use them. They don't hurt anything.

1 0

Re: winapi update
by Alexandre Julliard 30 Jul '01

30 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > I have resent winapi_install patch. > > While it probably that you didn't apply > it because of lack of time I resend > for your convinience. If not please > explain. Correct me if I'm wrong, but it seems you are not actually installing anything, only a script that needs the Wine source tree to work. I don't really see the point. If you want to install something it should be a complete installation that works without external files (not that I suggest doing that for winapi_check, at least not by default). -- Alexandre Julliard julliard(a)winehq.com

1 0

Possible printer driver bug
by Jukka Heinonen 30 Jul '01

30 Jul '01

Wine compiled from CVS crashes since file "wine/dlls/gdi/driver.c" passes a NULL pointer to function CreateICA. The following patch stops crashing, but since I have no idea how Wine printer drivers work, this patch might be plain wrong. After this patch, Wine no longer crashes, but I haven't been able to test whether printing works or not. Index: wine/dlls/gdi/driver.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/driver.c,v retrieving revision 1.2 diff -u -r1.2 driver.c --- wine/dlls/gdi/driver.c 2001/07/28 00:18:02 1.2 +++ wine/dlls/gdi/driver.c 2001/07/29 14:10:18 @@ -376,7 +376,7 @@ if(!DRIVER_GetDriverName( lpszDevice, buf, sizeof(buf) )) return -1; - if (!(hdc = CreateICA( buf, NULL, lpszPort, NULL ))) return -1; + if (!(hdc = CreateICA( buf, lpszDevice, lpszPort, NULL ))) return -1; if ((dc = DC_GetDCPtr( hdc ))) { -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 1

Hi There
by Robert Laverick 30 Jul '01

30 Jul '01

Hi, I'm new to wine and while I've been messing about with it I've not acctualy done anything significant. I'm mostly into Java but picked up some C recently doing some parallel comutational stuff as part of my Final year project as part of my degree. Now I'm officaly Unemployed as apposed to a Student I can give of my time freely. I'd love to get into this, if someone could give me a point at something that needs a good looking at then I'll start there. My biggest motivation is to get to understand this whole thing better and (if I'm luck) get Diablo II running so I don't have to reboot out of linux each time my Girlfriend comes round and demmands to kick my ass. :-) Well thanks in advance and I hope I can prove usefull. Rob PS anyone who want's to be nice enough to offer me a job DO IT NOW PLEASE I'M SKINT!

1 0

Wine Unreal and a strange old problem
by FT Rathore 29 Jul '01

29 Jul '01

Hi I have been using wine to play Unreal for a long time, but it would always crash in the start when I play as root or when I have my /dos filsystem mounted rw. It would always blow my mind, but I would fail to catch it. (been happenning for years too). I copied the whole Unreal tree to my ext2 filesystem and tried with different file permissions. I came to reallize that wine will allways crash if the file Unreal.log in Unreal/System is writeable. If I make that file read only, wine works flawlessly and I can do everything including save/load games. I tried to debug it, but the clues were very strange. There is only one message I see before the crash: err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception. Besides that there is not much different between the good and the bad traces. I am attaching last 2000 lines of "-debugmsg +all" with this message. Someone might be able to get some sense from the trace. Anything else I sould do? FT

1 0

Re: wnd lock tracing
by Alexandre Julliard 29 Jul '01

29 Jul '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > Add a #define DBG_WNDLOCK in order to have reasonable wndlock debugging Please don't add #ifdefs. You should use a debug channel. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: -DSTRICT warning fixes
by Patrik Stridvall 29 Jul '01

29 Jul '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Sure Win64 should use 64-bit pointers as handles that is > > without questions, but forcing it on Win32 on 64-bit > > is totally unnessary > > This may be the root of your misunderstanding: there is no such thing > as Win32 on 64-bit platforms. Wine (and Winelib) implement Win32 on > 32-bit platforms, and Win64 on a 64-bit platform. Well, actually Win32 does exist (or rather existed, it has been discontinue by Microsoft) on Alpha. But, never mind, it doesn't matter. The point is somebody has souce code for a Windows application and wishes that it will run on Alpha. He or she doesn't care whether Win32 on 64-bit exists or not he wished to port his application with as little effort as possible. He or she doesn't care what magic Winelib does as long as it works and he has to change the source as little as possible. > If you want to > compile your apps as Win32, you need a 32-bit compiler. Sure thats an idea, but doing that is a little awkard, no 32-bit compiler currently exists for 64-bit platforms AFAIK. While this might work, at least in theory, if you only call the Win32 API, how do you suggest calls to 64-bit Unix libraries should be handled? > Then you use > the same compiler to build Wine as a Win32 library, and everything > works fine. If you use a 64-bit compiler, some types (including > handles) become 64-bit, and you have to deal with it. Since you refuse to make it easier for the porter, sure he or she will have to deal with it, that is pretty obvious isn't it? The question is what can we do to make it easier for the porters. We can almost always say "We don't care, its your problem", so that is not an argument by itself. Sure we can't do the impossible, and some things takes to much effort, but still. > The only possible exception would be running existing Win32 binaries > on ia64. And I'm not even convinced it needs an exception, it's > probably easier to simply build a version of Wine with the 32-bit gcc > than to try to come up with a translation layer. Well, that is a future problem. I don't know exactly how to handle it either, but as you pointed out earlier since we need to convert 32-bit pointers to 64-bit pointers we might as well convert 32-bit handlers to 64-bit handlers the same way. Of course that doesn't mean that being able to compile Winelib with handle as 32-bit integers won't help, but I really can't say whether or not right now.

1 0

Re: -DSTRICT warning fixes
by Alexandre Julliard 29 Jul '01

29 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > Sure Win64 should use 64-bit pointers as handles that is > without questions, but forcing it on Win32 on 64-bit > is totally unnessary This may be the root of your misunderstanding: there is no such thing as Win32 on 64-bit platforms. Wine (and Winelib) implement Win32 on 32-bit platforms, and Win64 on a 64-bit platform. If you want to compile your apps as Win32, you need a 32-bit compiler. Then you use the same compiler to build Wine as a Win32 library, and everything works fine. If you use a 64-bit compiler, some types (including handles) become 64-bit, and you have to deal with it. The only possible exception would be running existing Win32 binaries on ia64. And I'm not even convinced it needs an exception, it's probably easier to simply build a version of Wine with the 32-bit gcc than to try to come up with a translation layer. -- Alexandre Julliard julliard(a)winehq.com

1 0

toolbar fix
by nog 29 Jul '01

29 Jul '01

Hi all, Changelog: Nog <nog(a)sdf.lonestar.org> Don't enable the 'hot' state of a toolbar button when it's not enabled. --- dlls/comctl32/toolbar.c Sun Jul 29 09:08:56 2001 +++ dlls/comctl32/toolbar.c Sun Jul 29 11:41:50 2001 @@ -4123,13 +4123,13 @@ if (nHit >= 0) { btnPtr = &infoPtr->buttons[nHit]; - btnPtr->bHot = TRUE; infoPtr->nHotItem = nHit; /* only enabled buttons show hot effect */ if(infoPtr->buttons[nHit].fsState & TBSTATE_ENABLED) { + btnPtr->bHot = TRUE; InvalidateRect(hwnd, &btnPtr->rect, TOOLBAR_HasText(infoPtr, btnPtr)); }

1 0

RFC: Patch for making GrabPointer work
by Jukka Heinonen 29 Jul '01

29 Jul '01

After the following patch DXGrab works again. However, this patch has quite a few potential races, so I am not going to submit this to wine-patches. Storing old windows procedure in struct x11drv_win_data would remove the worst race, but unless window procedure update is atomic, it would not remove all races. I'm starting to think that QueueUserAPC used together with OpenThread (which does exist in Windows 2000/Me, but not yet in Wine) is the correct way to fix DXGrab. Index: wine/dlls/x11drv/x11ddraw.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/x11ddraw.c,v retrieving revision 1.9 diff -u -r1.9 x11ddraw.c --- wine/dlls/x11drv/x11ddraw.c 2001/06/04 21:55:17 1.9 +++ wine/dlls/x11drv/x11ddraw.c 2001/07/29 13:41:52 @@ -45,20 +45,64 @@ } } -static void GrabPointer(HWND hWnd) -{ +static LRESULT WINAPI GrabWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) +{ Display *display = thread_display(); - if (hWnd) { - /* find the X11 window that ddraw uses */ - Window win = X11DRV_get_whole_window(hWnd); - TRACE("WND: %x win: %ld\n", hWnd, win); - if (!win) { - TRACE("host off desktop\n"); - win = root_window; - } - TSXGrabPointer(display, win, True, 0, GrabModeAsync, GrabModeAsync, win, None, CurrentTime); + + if(message != 0x7777) { + ERR("Unrecognized message %d, expect trouble!\n", message); + return 0; } - else TSXUngrabPointer(display, CurrentTime); + + TRACE("hwnd=%d, grab=%d\n", hWnd, wParam); + + if (wParam) + { + /* find the X11 window that ddraw uses */ + Window win = X11DRV_get_whole_window(hWnd); + TRACE("X11 window: %ld\n", win); + if (!win) { + TRACE("host off desktop\n"); + win = root_window; + } + + TSXGrabPointer(display, win, True, 0, GrabModeAsync, GrabModeAsync, win, None, CurrentTime); + TSXSetInputFocus(display, win, RevertToParent, CurrentTime); + } + else + { + TSXUngrabPointer(display, CurrentTime); + } + + return 0; +} + +static void GrabPointer(HWND hWnd, BOOL grab) +{ + WND* pWnd; + WNDPROC pOldProcedure; + + pWnd = WIN_FindWndPtr(hWnd); + if(!pWnd) + return; + + pOldProcedure = pWnd->winproc; + pWnd->winproc = GrabWndProc; + + WIN_ReleaseWndPtr(pWnd); + + SendMessageA(hWnd, 0x7777, grab ? 1 : 0, 0); + + pWnd = WIN_FindWndPtr(hWnd); + if(!pWnd) + return; + + if(pWnd->winproc != GrabWndProc) + ERR("Window procedure has been changed!\n"); + else + pWnd->winproc = pOldProcedure; + + WIN_ReleaseWndPtr(pWnd); } static DWORD PASCAL X11DRV_DDHAL_DestroyDriver(LPDDHAL_DESTROYDRIVERDATA data) @@ -75,7 +119,7 @@ X11DRV_DD_PrimaryGbl = X11DRV_DD_Primary->lpGbl; SetPrimaryDIB(GET_LPDDRAWSURFACE_GBL_MORE(X11DRV_DD_PrimaryGbl)->hKernelSurface); X11DRV_DD_UserClass = GlobalFindAtomA("WINE_DDRAW"); - if (dxgrab) GrabPointer(X11DRV_DD_PrimaryWnd); + if (dxgrab) GrabPointer(X11DRV_DD_PrimaryWnd, TRUE); } data->ddRVal = DD_OK; return DDHAL_DRIVER_NOTHANDLED; @@ -108,12 +152,12 @@ static DWORD PASCAL X11DRV_DDHAL_DestroySurface(LPDDHAL_DESTROYSURFACEDATA data) { if (data->lpDDSurface == X11DRV_DD_Primary) { + if (dxgrab) GrabPointer(X11DRV_DD_PrimaryWnd, FALSE); X11DRV_DD_Primary = NULL; X11DRV_DD_PrimaryWnd = 0; X11DRV_DD_PrimaryGbl = NULL; SetPrimaryDIB(0); X11DRV_DD_UserClass = 0; - if (dxgrab) GrabPointer(0); } data->ddRVal = DD_OK; return DDHAL_DRIVER_HANDLED; -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

RE: -DSTRICT warning fixes
by Patrik Stridvall 29 Jul '01

29 Jul '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Does the Windows API really define exactly what a handle is? > > typedef void* HANDLE seems pretty clear to me. I was refering some documentation that said that application should always expect a handle to be a pointer. But never mind. Documentation and reality is often different things. > > However your suggestion that any Winelib application that > cares whether > > they are 32-bit or 64-bit are broken is a far too strict > IMHO and I see > > no reason to require porters to fix such things. > > An application that assumes that everything is 32-bit is broken, yes. > I don't see why handles are any different than other types; if > anything they should be less of a problem since they are supposed to > be opaque, so their size should not matter for the application. > > Of course most handles will fit in 32-bit, so we will still support > apps that do invalid casts and truncate the handles; but this doesn't > mean it is correct behavior, or that apps that do this should be able > to compile without warnings. OK, since you agree we should accept handles truncated to 32-bit, it still leaves the problem. Should API calls truncate the handles themselves ie take 32-bit integers as arguments or should they not ie take 64-bit pointers as arguments. There is no particular reason to not accept both and make the actual definition of handle be dependent on some define and leave the choice on whether they want warnings or not to the Winelib developers, not leave them without a choice. Actually we might also consider giving them the option to accept 64-bit integers. In short, the Winelib developers should decide what their application wants (warning wise), we shouldn't. > > So therefor I suggest that we should do the following > > TRACE("(%p)", (LPVOID) handle); > > You must be joking. No, I'm not. However reality forced me to change the solution somewhat. See below. > I said I didn't want any typecast, and here you > suggest to have one on every single debugging output. Well, we have (or should have) a debugstr_[aw]n? on every single string in the debugging output, because we have to. We might not like it, but we have it because we must. > Let me repeat it > once more just in case: *NO* *TYPECASTS*. I know that you said that and I have said that I support that whenever possible, which it fortunately is in the normal cases. > The whole point of STRICT and pointer handles is to be able to use > compiler type checks, and this is only possible without typecasts. Agreed, but there is no self value in having no exceptions on a rule. Remember no type cast is a means no a goal. Debugging output is hardly a critical piece of code so if we can gain something from it we should consider making an exception. But never mind, it turns out that we we needn't make a exception either. See below. > Not > to mention that your solution will probably still get a warning like > "converting integer to pointer of different size" on a 64-bit > platform. Ah, thats a good point. Practice often stand in the way of a good theory. :-( Unfurtunately I think you are right, it is more than probable that the compiler will generate such a warning, I if not now so sometime in the future. Casting to a 32-bit integer to 64-bit pointer is almost always bogus, so there is no reason for the compiler not give a warning epecially since you can do a double cast (32-bit integer to 64-bit integer to 64-bit pointer) if you really mean it. Fortunately the problem is solvable #ifdef __alpha__ #ifdef STRICT #define HANDLE2POINTER(handle) (handle) #else #define HANDLE2POINTER(handle) ((void *) (unsigned long) (handle)) #endif #ifdef STRICT #define HANDLE2POINTER(handle) (handle) #else #define HANDLE2POINTER(handle) ((void *) (handle)) #endif #endif TRACE("(%p)", HANDLE2POINTER(handle)); This solves your problem (at least for 32-bit developers) < The whole point of STRICT and pointer handles is to be able to use < compiler type checks, and this is only possible without typecasts. Francois problem < * Ignore gcc's warnings saying '%x format, pointer argument'. Fixing the format < at this stage would only introduce tons of warnings for the developpers not < participating in the switch (i.e. compiling with STRICT off). as well as my problem. Of course we might consider making it a debug output only construct instead Like s/HANDLE2POINTER/debugptr_handle/ and define it in debugtools.h. Non-debugging parts of Wine shouldn't need to use it either since as I said earlier just pass them long or must use an explict cast to a non-void pointer. Ah, wait a minute we will have "converting integer to pointer of different size" on 64-bit platforms for the actual cast to an object. Of course easily solved with a similar #ifdef __alpha__ #define HANDLE2OBJECT(type, handle) ((type *) (unsigned long) (handle)) #else #define HANDLE2OBJECT(type, handle) ((type *) (handle)) #endif but perhaps we should have the HANDLE2POINTER (debugptr_handle) in debugtools.h all the same, nobody else is intrested in a void pointer anyway. Of course, nothing forces us to define handles as the same both internally and externally. At least Alpha AFAIK will be binary compatible all the same, so we might not even need this. Oh well having to always using HANDLE2OBJECT is a small price to pay all the same and makes it possible for us to do adjustments on other 64-bit platforms if need be. And yes, I'm serious. My inital solutions wasn't so good, but thanks to your feedback I have managed to refine it to a much better solution, that I think actually works in reality. And yes, I still consider the 64-bit problem a real problem, you just tries to dismiss the problem by simply saying, that is the Winelib developers problem. Sure we could do that but, remember that Winelib is meant to help developers port application not make it more difficult by trying to enforce unnessary restriction on the code. Sure Win64 should use 64-bit pointers as handles that is without questions, but forcing it on Win32 on 64-bit is totally unnessary, especially since I now finally after your feedback managed to find a solution that solve all your stated problems (remember that no type casts is a means not a goal and actually there will be no type casts on 32-bit (-DSTRICT) either). But perhaps you can see any flaws in this refined solution as well?

1 0

Re: -DSTRICT warning fixes
by Alexandre Julliard 29 Jul '01

29 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > Does the Windows API really define exactly what a handle is? typedef void* HANDLE seems pretty clear to me. > However your suggestion that any Winelib application that cares whether > they are 32-bit or 64-bit are broken is a far too strict IMHO and I see > no reason to require porters to fix such things. An application that assumes that everything is 32-bit is broken, yes. I don't see why handles are any different than other types; if anything they should be less of a problem since they are supposed to be opaque, so their size should not matter for the application. Of course most handles will fit in 32-bit, so we will still support apps that do invalid casts and truncate the handles; but this doesn't mean it is correct behavior, or that apps that do this should be able to compile without warnings. > So therefor I suggest that we should do the following > TRACE("(%p)", (LPVOID) handle); You must be joking. I said I didn't want any typecast, and here you suggest to have one on every single debugging output. Let me repeat it once more just in case: *NO* *TYPECASTS*. The whole point of STRICT and pointer handles is to be able to use compiler type checks, and this is only possible without typecasts. Not to mention that your solution will probably still get a warning like "converting integer to pointer of different size" on a 64-bit platform. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: -DSTRICT warning fixes
by Patrik Stridvall 28 Jul '01

28 Jul '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > However for the debugging output I disagree. I orginally thought > > as Francois (and you it seems) that handles are pointers and should > > be treated as such. But then I realized that when we > implement Win32 on > > 64-bit platforms we can't have handles as pointers even > internally if > > we wan't to support x86 emulation and even exposing a 64-bit > > handle to Winelib application can only cause trouble since they > > might store it is a 32-bit memory location. Sure we will probably be > > able to handle 64-bit pointers truncated to 32-bit by storing all > > objects in the lower 32-bit part of memory, but fear it might > > cause trouble all the same. > > Handles are pointers in the Windows API, and they should be pointers > inside of Wine. On a 64-bit platforms pointers will be 64-bit, and so > will handles. Does the Windows API really define exactly what a handle is? It is just a identifier for an object that can be passed to various APIs but should not be used directly. > If you want to run 32-bit code on such a platform you > need a conversion for pointers anyway, > so you might as well use the > same conversion for handles. > Not to mention that some handles are > actually pointers (like HMODULE). That is an internal Wine/Winelib problem and shouldn't need to concern porters of Winelib applications. > So no, there is absolutely no reason > to force handles to be 32 bits. Handles are some sort of values as for as whether they are integers or pointers any Winelib application that cares are IMHO broken. I guess you agree on that point. However your suggestion that any Winelib application that cares whether they are 32-bit or 64-bit are broken is a far too strict IMHO and I see no reason to require porters to fix such things. Note that it might no be so easy to fix it either. Perhaps the application uses some external lib that provides storage of some user defined 32-bit data and use it to store the handles. Now it will suddenly not work anymore, and fixing it is not trival. Hint you are on a 64-bit platform that requires 64-bit pointers and you have 32-bit storage. The obvious solution an index of an array might not always work so well because of memory management requirements and beside the maintainer of the project might not accept a special patch for the 64-bit version. Anyway, never mind. See below instead. Sure pointer face in some meaning the same problems, but that sort of problems is more obvious and there is no reason to add more to the burden. > > The real reason that we should support compiling Wine with -DSTRICT > > is not because handles becomes pointers but because callbacks gets > > the correct prototype. > > No, it's because handles become pointers; you cannot do the -DSTRICT > typechecking with integers anyway. True, you can't do typechecking with integers but since Wine is primarily compiled 32-bit platform that will use 32-bit pointers, we will get the benefit of typechecking at the platform, which happends the only one Wine currently works on. Sure future developers on 64-bit will not find the errors then they compile, but everybody else compiling for a 32-bit platform will, so I don't see the problem. > Callbacks are a very minor issue; > the real point is to fix all incorrect handle manipulations, like > implicit 16-bit handle conversions or arithmetic on handle values. The ones of the above that can be found automatically will be fixed by the 32-bit developers. So the actual problem is what? Anyway, this discusion is getting a little carried away (mostly my fault). While I do not currenly agree that we really should use 64-bit handles on 64-bit platforms, your objections have made me think some more and made me come to the following conclusions. In order to not "close the door to the future" whether this is Win32 on 64-bit or Win64, the Wine code shouldn't internally not care (give errors or warnings or be semantically wrong) whether the header files: 1. Defines handles as integers or pointers 2. Defines handles as 32-bit or 64-bit (regardless of whether we have 32-bit or 64-bit pointers) This is not so a for the normal (non-debugging) code. OK, we might have to force memory allocation of objects for the lower 32-bit of memory if we have 64-bit pointers but that is probably not so large problem. After all the Winelib application itself can allocate memory on the full 64-bit memory range and Winelib itself are not likely to need more that 4Gb memory for objects. However, I see no really good solution for the debug output. Neither mine nor your previously suggested solution have the above properties. However the solution below have, I think TRACE("(%p)", (LPVOID) handle); eventhough it might display unnessary information on 64-bit platforms, but perhaps we should worry about that in the future, if it indeed is a problem at all. After all it is only a few more bytes in the debug output. So therefor I suggest that we should do the following TRACE("(%p)", (LPVOID) handle); It will fix the problem that Francois speaks of in bug report #90. < * Ignore gcc's warnings saying '%x format, pointer argument'. Fixing the format < at this stage would only introduce tons of warnings for the developpers not < participating in the switch (i.e. compiling with STRICT off). It will allow us to fix the debug output one by one (or at least seperately per type) since it will allow us compile without related warnings even without -DSTRICT as well as to prepare us for a possible future where handles might be 32-bit integers on 64-bit.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel July 2001