July 2001 - Wine-Devel - list.winehq.org

Re: Documenting functions

by Andreas Mohr

On Tue, Jul 31, 2001 at 04:33:06PM +0000, Bill Medland wrote: > 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. IMNSHO full documentation should *not* be included in the Wine tree. Instead, we should rely on MSDN documented stuff wherever possible and only explain quirks/undocumented behaviour/whatever isn't documented. Having full docu inside the source tree simply bloats it too much IMHO. Not to mention that none, zero, zilch of the planned undertakings in that direction have actually taken off so far. Docu in general is fine, but duplicated function docu in source tree ? Avoid as much as possible, I think. > 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. If there's no additional "Wine" information about this function, then this is perfectly reasonable IMHO (see above). I'd like to see at most: function header with comment above with short description of i/o, additional statements about undocumented/special behaviour. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

July 31, 2001

Re: Patch to fix the Linux 2.2 joysitck interface

by Alexandre Julliard

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

July 31, 2001

Documenting functions

by Bill Medland

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

July 31, 2001

Re: RFC: Patch for making GrabPointer work

by Dmitry Timoshkov

"Alexandre Julliard" <julliard(a)winehq.com> wrote: > 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. And it would be much better to not hardcode 0x7777 as the special message value, but use RegisterWindowMessage instead. -- Dmitry.

July 31, 2001

Re: RFC: Patch for making GrabPointer work

by Alexandre Julliard

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

July 31, 2001

Re: (no subject)

by Alexandre Julliard

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

July 31, 2001

Re: Prevent excessive clipping in SysListView32

by Bill Medland

Ulrich Weigand <weigand(a)immd1.informatik.uni-erlangen.de> wrote in article <200107301823.UAA01150(a)faui11.informatik.uni-erlangen.de>... > > Bill Medland wrote: > > > Ulrich Weigand <weigand(a)immd1.informatik.uni-erlangen.de> wrote in article > > <200107262124.XAA25786(a)faui11.informatik.uni-erlangen.de>... > > > No, 'inline' must not change the semantics of the routine in any way, > > > including static variables. > > > > > > If the app behaves differently when 'perfect_graphics' is inlined, this > > > is a compiler bug. Which compiler version are you using? > > > > Excuse my ignorance. rpm says it is 2.96-81. How do I ask gcc what > > version IT thinks it is? > > (Running on RH7.1; how do I get the kernel version? rpm says 2.4.2-2) > > gcc 2.96 is the version RedHat is currently using; it is not an > 'official' version supported by the gcc folks ... > > However, RedHat has been fixing quite a bunch of bugs in their > compiler; it might be worthwhile to check whether this inlining > bug is fixed in the most recent RedHat update. (Check the RPM > sublevel to find out whether you have the most recent update, > that's the -81 in your case. AFAIK, bugfix updates can be > downloaded from the RedHat FTP site ...) > > Bye, > Ulrich Thanks; I'll try that when I have a moment. Bill

July 30, 2001

Re: Relocatoion and ExceptionFilter problem?

by EriK W

"Francois Gouget" <fgouget(a)free.fr> wrote in message news:Pine.LNX.4.21.0107301118510.11941-100000(a)amboise.dolphin... > On Mon, 30 Jul 2001, EriK W wrote: > > > 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 > > What we need are the lines that come before. See: > http://wine.codeweavers.com/docs/wine-user/bugs.shtml#BUG-REPORTING > > > > 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 > > Many windows executables must be loaded at a specific address. > Unfortunately it seems that on your system this address is already in > use so that we cannot load the executable there. In the past this > happened regularly because we were loading all programs in a single > address space. So after loading the first program we were unable to load > any other program at that same address. Hence the suggestion to "Try to > run that file directly !" in the error message. But this is all a thing > of the past as now each application is loaded in its own address space. > So there must be something else using the address that Wine wants. > It's strange because I don't remember people having this problem on > Solaris before. What you can do is run Wine in gdb and then type 'info > sharedlibrary' to get a map of the process memory and see what is using > the address Wine needs. So you will also need to fid out where Wine > is trying to load the exe. You can probably get this info by looking at > the loader source, activating the relevant debug channels, or running > dumpbin (comes with VC++) on the app. Could it be related to xpm? I have this info when I first time config wine Redhat : xpm xpm-devel Caldera OpenLinux : xpm xpm-devel xpm-devel-static SuSE : xpm Debian/Corel Linux: xpm4g xpm4g-dev Or get the sources from ftp.x.org and all its mirror sites from the directory /contrib/libraries. I got the source and compiled xpm3.4k(With couple warnings), after installation wine still can't find xpm.h, because it was installed to /usr/openwin/share/include/X11/X11/xpm.h, so I eventually copied it to /usr/openwin/share/include/X11/xpm.h to make it work for wine. I also tried to use something like ./configure --x-includes=/usr/openwin/share/include/X11:/usr/openwin/share/i nclude/X11/X11 but wine couldn't find the xpm.h in this way. > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Hiroshima '45 - Czernobyl '86 - Windows '95 > > > > >

July 30, 2001

RE: Small OpenGL patch

by Patrik Stridvall

> 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.(a). 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.

July 30, 2001

RE: winapi update

by Patrik Stridvall

> > 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.

July 30, 2001

Re: winapi update

by Alexandre Julliard

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

July 30, 2001

broken misc/version.c (patch 1.43 -> 1.44) WIN95 value in version16

by Ladislav Sladecek

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

July 30, 2001

RE: winapi update

by Patrik Stridvall

> 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.

July 30, 2001

Re: winapi update

by Alexandre Julliard

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

July 30, 2001

Re: Relocatoion and ExceptionFilter problem?

by Francois Gouget

On Mon, 30 Jul 2001, EriK W wrote: > 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 What we need are the lines that come before. See: http://wine.codeweavers.com/docs/wine-user/bugs.shtml#BUG-REPORTING > 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 Many windows executables must be loaded at a specific address. Unfortunately it seems that on your system this address is already in use so that we cannot load the executable there. In the past this happened regularly because we were loading all programs in a single address space. So after loading the first program we were unable to load any other program at that same address. Hence the suggestion to "Try to run that file directly !" in the error message. But this is all a thing of the past as now each application is loaded in its own address space. So there must be something else using the address that Wine wants. It's strange because I don't remember people having this problem on Solaris before. What you can do is run Wine in gdb and then type 'info sharedlibrary' to get a map of the process memory and see what is using the address Wine needs. So you will also need to fid out where Wine is trying to load the exe. You can probably get this info by looking at the loader source, activating the relevant debug channels, or running dumpbin (comes with VC++) on the app. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

July 30, 2001

Re: Prevent excessive clipping in SysListView32

by Ulrich Weigand

Bill Medland wrote: > Ulrich Weigand <weigand(a)immd1.informatik.uni-erlangen.de> wrote in article > <200107262124.XAA25786(a)faui11.informatik.uni-erlangen.de>... > > No, 'inline' must not change the semantics of the routine in any way, > > including static variables. > > > > If the app behaves differently when 'perfect_graphics' is inlined, this > > is a compiler bug. Which compiler version are you using? > > Excuse my ignorance. rpm says it is 2.96-81. How do I ask gcc what > version IT thinks it is? > (Running on RH7.1; how do I get the kernel version? rpm says 2.4.2-2) gcc 2.96 is the version RedHat is currently using; it is not an 'official' version supported by the gcc folks ... However, RedHat has been fixing quite a bunch of bugs in their compiler; it might be worthwhile to check whether this inlining bug is fixed in the most recent RedHat update. (Check the RPM sublevel to find out whether you have the most recent update, that's the -81 in your case. AFAIK, bugfix updates can be downloaded from the RedHat FTP site ...) Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

July 30, 2001

Relocatoion and ExceptionFilter problem?

by EriK W

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 !

July 30, 2001

Re: Possible printer driver bug

by Huw D M Davies

On Sun, Jul 29, 2001 at 05:31:05PM +0300, Jukka Heinonen wrote: > 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 ))) > { > Looks good. There's also another one in GDI_CallDeviceCapabilities16 (line 424) that needs the same fix. Could you fix them both and send the patch to wine-patches ? Huw.

July 30, 2001

Hi There

by Robert Laverick

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!

July 30, 2001

Wine Unreal and a strange old problem

by FT Rathore

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

July 29, 2001

Re: wnd lock tracing

by Alexandre Julliard

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

July 29, 2001

RE: -DSTRICT warning fixes

by Patrik Stridvall

> 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.

July 29, 2001

Re: -DSTRICT warning fixes

by Alexandre Julliard

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

July 29, 2001

toolbar fix

by nog

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)); }

July 29, 2001

Possible printer driver bug

by Jukka Heinonen

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/>

July 29, 2001