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

RFC: Patch for making GrabPointer work

by Jukka Heinonen

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

July 29, 2001

RE: -DSTRICT warning fixes

by Patrik Stridvall

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

July 29, 2001

Re: -DSTRICT warning fixes

by Alexandre Julliard

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

July 29, 2001

RE: -DSTRICT warning fixes

by Patrik Stridvall

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

July 28, 2001

RE: -DSTRICT warning fixes

by Patrik Stridvall

> On Sat, 28 Jul 2001, Patrik Stridvall wrote: > [...] > > The real reason that we should support compiling Wine with -DSTRICT > > is not because handles becomes pointers but because callbacks gets > > the correct prototype. > > > > I case not you haven't realized the obvious, it doesn't matter if > > the handles are 32-bit integer or 32-bit pointers as long as > > all handles are the same. The code either > > No, I think you have missed something: when compiling with -DSTRICT > on all handles are not the same. Note I said same but meant compatible. Wrong choice of words. > For instance you cannot do > hDesk=hAccel. That's because with -DSTRICT on you have: > > typedef struct HDESK__ { int unused; } *HDESK; > typedef struct HACCEL__ { int unused; } *HACCEL; > > Thus HDESK and HACCEL are incompatible pointer types. This > brings us > more type safety which is the whole point of -DSTRICT. Oh sure, but the point is that if code, that are semanticly correct, cares whether you are strict or relax the type, the code it wrong. Perhaps I was I little unclear on that point. Being strict obviously makes it easier to find semantic errors, but that was not the point at all. > About 64bits Windows I don't know yet how we are going to do that. > But you have to check exactly what Windows 64bit does, not just > extrapolate from the way Unix 64bit does things. AFAIK the > approach used > by windows is quite different from that which Unices took. Yes, unfortunately, but I'm primarily worried about Win32 on 64-bit platforms.

July 28, 2001

RE: -DSTRICT warning fixes

by Francois Gouget

On Sat, 28 Jul 2001, Patrik Stridvall wrote: [...] > The real reason that we should support compiling Wine with -DSTRICT > is not because handles becomes pointers but because callbacks gets > the correct prototype. > > I case not you haven't realized the obvious, it doesn't matter if > the handles are 32-bit integer or 32-bit pointers as long as > all handles are the same. The code either No, I think you have missed something: when compiling with -DSTRICT on all handles are not the same. For instance you cannot do hDesk=hAccel. That's because with -DSTRICT on you have: typedef struct HDESK__ { int unused; } *HDESK; typedef struct HACCEL__ { int unused; } *HACCEL; Thus HDESK and HACCEL are incompatible pointer types. This brings us more type safety which is the whole point of -DSTRICT. About 64bits Windows I don't know yet how we are going to do that. But you have to check exactly what Windows 64bit does, not just extrapolate from the way Unix 64bit does things. AFAIK the approach used by windows is quite different from that which Unices took. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

July 28, 2001

Re: -DSTRICT warning fixes

by Alexandre Julliard

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. 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). So no, there is absolutely no reason to force handles to be 32 bits. > Beside doing TRACE("(%p)", handle) on 64-bit platforms will needlessly > display the always the same presumably zero upper 32-bit part > of the handle. That why I decided to should use > TRACE("(0x%08lx)", (DWORD) handle) instead to avoid such issues. Sorry but this is wrong. Handles are pointers and must be printed as pointers. Assuming that handles are always exactly 32-bit is very shortsighted. > 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. 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. -- Alexandre Julliard julliard(a)winehq.com

July 28, 2001

RE: -DSTRICT warning fixes

by Patrik Stridvall

> > If we do that can just do > > s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/ > > on the handle types on by one and fix the warnings. > > That's precisely the plan, and it is just the opposite of what you are > doing with your patch (you are turning DECLARE_HANDLE back into > DECLARE_OLD_HANDLE). The reason I did that was that they can't be fixed as long as HANDLE/HGLOBAL is the wrong types. When they become the right types the warnings will automatically disappear and we can do s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/. But there is no reason to have a lot of warnings that can't be fixed otherwise until then. > Yes you get a number of warnings if you turn > -DSTRICT on, most of them should disappear once the conversion is > complete; fixing them before that is a waste of time. Since we can't fix before that why show them at all? People that want to fix for example output messages can do, s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/ in their tree, fix them and submit the patches (without the s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/). > This is the > reason why -DSTRICT is not the default yet. Read bug report #90, > Francois explains everything there. OK. I have read bug report #90 now. > And don't forget the number one rule of the -DSTRICT conversion is: > *no* *typecasts*. If you have to add typecasts something is wrong. No typecasts where the handle is used in conjuction with other handles, certainly not, no argument there. The code some expect all handles to be the of same type. 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. Beside doing TRACE("(%p)", handle) on 64-bit platforms will needlessly display the always the same presumably zero upper 32-bit part of the handle. That why I decided to should use TRACE("(0x%08lx)", (DWORD) handle) instead to avoid such issues. In short, the code should IMHO support both 32-bit pointers as well and 32-bit integers as handles presuming of course that all handles use the same. The real reason that we should support compiling Wine with -DSTRICT is not because handles becomes pointers but because callbacks gets the correct prototype. I case not you haven't realized the obvious, it doesn't matter if the handles are 32-bit integer or 32-bit pointers as long as all handles are the same. The code either 1. Just pass them around as the same type of handles of other types of handles (HANDLE/HGLOBAL). 2. Tries to access the underlying object, in such case a void pointer will not do use any good, we must use a cast either after calls to functions like GlobalLock or alone.

July 28, 2001

Re: -DSTRICT warning fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > Concerning some parts of my warnings patch that was > partly rejected I disagree with the rejection. > The patch in question is in warnings_rejected.diff. > Note the field "u" is a union. But perhaps you know > and rejected it for other reasons? I know it is a union; I thought it was one of these cases that would get fixed by -DSTRICT, but now I see that it is a slightly different problem. I'll apply it. > If you accept all the strict_*.diff patches, perhaps we > should consider adding -DSTRICT as a permanent flag? > It removes the HOOKPROC/TIMERPROC warnings that is not > possible to fix otherwise. > > If we do that can just do > s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/ > on the handle types on by one and fix the warnings. That's precisely the plan, and it is just the opposite of what you are doing with your patch (you are turning DECLARE_HANDLE back into DECLARE_OLD_HANDLE). Yes you get a number of warnings if you turn -DSTRICT on, most of them should disappear once the conversion is complete; fixing them before that is a waste of time. This is the reason why -DSTRICT is not the default yet. Read bug report #90, Francois explains everything there. And don't forget the number one rule of the -DSTRICT conversion is: *no* *typecasts*. If you have to add typecasts something is wrong. -- Alexandre Julliard julliard(a)winehq.com

July 28, 2001

(no subject)

by Ladislav Sladecek

Alexandre Julliard: > I think GetClipBox is correct, the problem is > that the WM_ERASEBKGND > handler should not be using it, but > GetClientRect. You can try this: Hello Alexandre, thank you for your reccomendation. Unfortunately the DefWindowProc improvement does not help, because the default handler newer gets called in my app. The application (Progress _prowin.exe version 7) uses custom dialog boxes (forms) and also custom controls. The controls handle WM_ERASEBKGND themeselves. I have no access to the sources. What I know about GetClipRect, I know from the trace. I agree that your method (GetClientRect in the handler) is much better, but I cannot use it. I also agree that Windows should return the parent area in GetClipBox as Wine does. Unfortunalelly, the Windows do not do that while the _prowin.exe depends on it. I enclose a simple C example which I hacked to demonstrate this. The example displays two red children in a white parent. The value returned by GetClipBox is wsprintf-ed. 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. Regards Ladislav Sladecek

July 28, 2001

Re: -DSTRICT warning fixes

by Francois Gouget

- FIXME("(%x),stub!\n",hrasconn); + FIXME("(0x%08lx): stub\n", (DWORD) hrasconn); [...] I think I would rather use %p to print handles. After all they are pointers, not integers. The annoying aspect of it is that %08p is not very well supported IIRC. Maybe gcc has been fixed though. I forgot to mention it before. But I assume you saw bug #90. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

July 28, 2001

wine on clusters ??

by Francisco Perez

Hi everybody: Has anybody tried to run wine on a High Availabity cluster ?. Especifically we are interested on a Mosix environment where applications don't need be changed. The windows application to be clustered is a Remote IP network back-up system so no grafic intensive or plug modern like ActiveX and so. Any comments are highly apreciated thanks

July 28, 2001

Re: PATCH: wrong clipRect when CS_PARENTDC and WS_CLIPSIBLINGS styles are combined

by Alexandre Julliard

lsla(a)post.cz writes: > Where the Wine's GetClipRect returns the area of the parent, the > Windows version returns only the area of the child. Therefore in > Wine the WM_ERASEBKGND message erases the whole parent including the > other radio buttons. I think GetClipBox is correct, the problem is that the WM_ERASEBKGND handler should not be using it, but GetClientRect. You can try this: Index: windows/defwnd.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/defwnd.c,v retrieving revision 1.57 diff -u -r1.57 defwnd.c --- windows/defwnd.c 2001/06/20 23:16:34 1.57 +++ windows/defwnd.c 2001/07/27 23:47:26 @@ -457,20 +457,15 @@ case WM_ICONERASEBKGND: { RECT rect; + HDC hdc = (HDC)wParam; HBRUSH hbr = GetClassLongW( wndPtr->hwndSelf, GCL_HBRBACKGROUND ); if (!hbr) return 0; - /* Since WM_ERASEBKGND may receive either a window dc or a */ - /* client dc, the area to be erased has to be retrieved from */ - /* the device context. */ - GetClipBox( (HDC)wParam, &rect ); - - /* Always call the Win32 variant of FillRect even on Win16, - * since despite the fact that Win16, as well as Win32, - * supports special background brushes for a window class, - * the Win16 variant of FillRect does not. - */ - FillRect( (HDC) wParam, &rect, hbr ); + /* GetClientRect used to be GetClipBox, but it is not what + * Windows does, and it breaks badly with CS_PARENTDC */ + GetClientRect( wndPtr->hwndSelf, &rect ); + DPtoLP( hdc, (LPPOINT)&rect, 2 ); + FillRect( hdc, &rect, hbr ); return 1; } -- Alexandre Julliard julliard(a)winehq.com

July 28, 2001

Re: Dose wine people hate Solaris?

by Super-User

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 27, 2001

RE: winapi update

by Patrik Stridvall

> make_filter: : can't parse output: 'Make.rules.in is newer > than Make.rules, please rerun ./configure!' Fixed in my tree. > Would it be possible to have the messages pass through as-is when > they are not recognized (with the current directory for context)? [snip] > make_filter: gcc: can't parse output: 'd3ddevice/mesa.c:817: > warning: unused variable `xvis'' I have fixed that for gcc messages (unless --pedantic is specified), however I'm not sure it is good always doing that. I will think about it. > It looks like there's an incompatibility with colorgcc. [snip] > So it must be the controls characters added by colorgcc > that confuse > make_filter. No it wasn't, colorgcc checks whether STDOUT is a TTY or not.

July 27, 2001

RE: Even more misc fixes

by Patrik Stridvall

> > But OK I will try and compile with -DSTRICT and see what happends. > > IIRC somebody tried that but it didn't turn out so well. > > That would be me, probably. I started the conversion to -DSTRICT but > then other priorities came up and now it's on the back burner. I will > get back to it eventually but at the current rate it's hard > to know when > that will be :-( > Compiling with -DSTRICT is not that bad: with a relatively simple > patch it compiles (see attachement). Or at least, it used to. No patch is needed for the file in question. windows/property.c needs a simple patch though. > But there > are tons of warnings, which means tons of places that need > attention and > possibly fixing. That's where the work is. Yes. I've noticed that and I have fixed a few of them as well. However I'm not optimistic on fixing them all on the short term. The problem is not the number of them, the problem is that some of the warnings like the Global* can't be fixing in the .c files. It involves changing the .h files and that generated even more warnings. :-( I will investigate furher, but as I said, I'm not optimistic.

July 27, 2001

Re: Prevent excessive clipping in SysListView32

by lawson_whitney＠juno.com

On Fri, 27 Jul 2001, Igor wrote: > Bill Medland wrote: > > Excuse my ignorance. rpm says it is 2.96-81. How do I ask gcc what > version IT thinks it is? Script started on Fri Jul 27 11:44:32 2001 [whit(a)giftie whit]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/2.95.3/specs gcc version 2.95.3 20010315 (release) [whit(a)giftie whit]$ exit Script done on Fri Jul 27 11:44:39 2001 > (Running on RH7.1; how do I get the kernel version? rpm says 2.4.2-2) > > Bill > > > type at prompt > > uname -a > > > Igor > > > > ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

July 27, 2001

Re: Prevent excessive clipping in SysListView32

by Francois Gouget

On Fri, 27 Jul 2001, Bill Medland wrote: [...] > Excuse my ignorance. rpm says it is 2.96-81. How do I ask gcc what > version IT thinks it is? gcc -v gcc -dumpspecs > (Running on RH7.1; how do I get the kernel version? rpm says 2.4.2-2) cat /proc/version -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

July 27, 2001

Re:Re: native dll's

by Francois Gouget

On Fri, 27 Jul 2001, José Soriano Díaz wrote: [...] > > > So my question is quite siple How can I link a native dll in > > > a Unix project? > > > > I think you have used the right approach: LoadLibrary / > >GetProcAddress / FreeLibrary. If that works for you then it's the > >simplest approach. > > I'm afraid it doesn't work, when I executed what I compiled , I obtained > "Undefined Symbol" in any call to the native dll. Thanks anyway for the > advice. That's strange. It sounds like you are simply calling the functions but I thought you were using GetProcAddress to get a function pointer and then using that function pointer to call each function you imported from the dll. You should not have any undefined symbol when doing that. It's not C++? (C++ makes things more intractable because each virtual function table is a hidden import of a non function symbol.) Also you should be warned of any undefined symbol at link time. Didn't you get such warnings? What did they say? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

July 27, 2001

Re:Re: native dll's

by José Soriano Díaz

>From: Francois Gouget <fgouget(a)free.fr> >To: José Soriano Díaz <jose__sor(a)hotmail.com> >CC: wine-devel(a)winehq.com >Subject: Re: native dll's >Date: Thu, 26 Jul 2001 10:10:17 -0700 (PDT) > >On Wed, 25 Jul 2001, José Soriano Díaz wrote: > > > > > Hi there, I'm working in a telerobotics project and I need to >link a > > windows dll in order to use a Cybernet Joystick. > > First I tried to use the winAPI functions LoadLibrary, > > FreeLibrary and GetProccessAddress as I were working on Windows, and > > I recompiled my program with winelib: > > *. winemaker /my_path/ > > *. ./configure > > *. make all > > but it didn't create any executable, what I obtained was a > > lib*.so, because winemaker thought I was trying to compile a dll, > > not to use one. > > To force winemaker to generate an executable simply use it as >follows: > * type "winemaker --cuiexe /my_path" to indicate a console executable > * type "winemaker --guiexe /my_path" to indicate a graphical executable > > You can also use "winemaker -?" to get a list of options supported by >winemaker. > > > > So my question is quite siple How can I link a native dll in > > a Unix project? > > I think you have used the right approach: LoadLibrary / >GetProccessAddress / FreeLibrary. If that works for you then it's the >simplest approach. I'm afraid it doesn't work, when I executed what I compiled , I obtained "Undefined Symbol" in any call to the native dll. Thanks anyway for the advice. _________________________________________________________________ Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.es/intl.asp

July 27, 2001

[Fwd: Re: Any use for glyph bounding boxes in printer driver?]

by Ian Pilcher

Travis Michielsen wrote: > > What about GetCharABCWidth* what does this function use? (or could it use > this?) I see the function still shows a fixme (or atleast the last time I > checked). > The only one that works for printer fonts is GetCharABCWidthsFloat. I just tested it on Windows 2000 and verified that it always returns 0 for abcfA and abcfC (and returns the advance width in abcfB) when it is called on a printer font. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

July 27, 2001

Re: ChangeDisplaySettings

by Travis Michielsen

--- Lionel Ulmer <lionel.ulmer(a)free.fr> wrote: > > Hmm, I was going to try something like that, however, I had problems with > that > > method simply b/c of the load order between the dlls. > ChangeDisplaySettings is > > implemented in user32.dll which loads BEFORE x11drv. > > Yes, but if you look at file user32.spec, you have : > > init USER_Init > > This is a function called at DLL loading (AFAIK). It is in file user_main.c > > At DLL loading, this function calls 'process_attach' that calls > 'load_driver' (all functions are in the same file). > > 'load_driver' does the following : > > strcpy( buffer, "x11drv" ); /* default value */ > (...) > if (!(graphics_driver = LoadLibraryA( buffer ))) > { > MESSAGE( "Could not load graphics driver '%s'\n", buffer ); > return FALSE; > } > > This means that even if USER32.dll is loaded BEFORE x11drv.dll, the init > function of USER32 will load the current graphics driver, i.e. x11drv. > > Later in the same function, all function pointers are initialized using the > GET_USER_FUNC macro. Ahh, now I see. > BTW, you did NOT read the thread about my OpenGL fixes recently where > Alexandre plainly told that putting x11drv.dll in a spec file is bad :-) ? Hmm, will go find and reread it. Probably just skimmed through it the first time. > > Already using so of that code, although it could probably be cleaned up a > bit. > > I will get to that soon. > > Ah, did not look in details at your patch :-) Stopped at the 'Oh my god, X11 > calls in USER' :-) > > Anyway, let's hope I will not discourage you :-) > > Lionel Not to worry, I accept most of the constructive critizism that I recieve. Besides, I'm still new to and learning things about the project. - Travis Michielsen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

July 27, 2001

Re: Prevent excessive clipping in SysListView32

by Igor

Bill Medland wrote: 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) Bill type at prompt uname -a Igor

July 27, 2001

Re: Prevent excessive clipping in SysListView32

by Bill Medland

Ulrich Weigand <weigand(a)immd1.informatik.uni-erlangen.de> wrote in article <200107262124.XAA25786(a)faui11.informatik.uni-erlangen.de>... > > Uwe Bonnes wrote: > > >>>>> "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) > > 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) Bill

July 27, 2001

Re: How do I stop clipping?

by Travis Michielsen

--- Bill Medland <medbi01(a)accpac.com> wrote: > I don't like submitting incomplete code but I may have little choice unless > someone can point me in the correct direction here. As you may guess from > the following, my Windows experience is not that extensive but I think it's > enough to allow me to make sensible contributions. > > I am working on correcting the LISTVIEW_DrawLargeItem function, especially > when the item text is large. I have already got most of the way. However > the problem is this. > > When a user selects a large icon the text should be written completely (by > calling DrawText with DT_NOCLIP). It is doing so; I can prove it by > resizing the window and I will see the full text being displayed for a > selected item. However when drawing it at the moment of selecting it, the > text is being clipped to the usual two and a bit rows. Presumably this > means that there is a clipping rectangle in the DC or the window that I > need to inflate. Or Do I simply invalidate that rectangle (from within the > WM_PAINT handler!!!). > > Any help would be appreciated. > > Bill Looking at the DrawText code I see that DrawText just passes the NOCLIP flag to ExtTextOut, so the problem I likely not with DrawText but with ExtTextOut instead. I can take a look at the code for both functions (time providing) and find out what is happening. - Travis Michielsen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

July 27, 2001

Re: Any use for glyph bounding boxes in printer driver?

by Travis Michielsen

--- Ian Pilcher <ian.pilcher(a)home.com> wrote: > Currently, the Wine PostScript driver stores the bounding box (xMin, > yMin, xMax, yMax) for every glyph in every font. This information is > not currently used, and I'd like to get rid of it. (Note: this is > distinct from the advance width of each glyph, which is certainly > required.) > > From what I can tell, there is no API that a Win32 application or the > Windows GDI can use to get this information from a printer driver. > Since I'm not that familiar with either, however, I figure I should try > to confirm that this is indeed the case. > > So, does anyone know of any API that an application or the GDI can use > to get the dimensions of an individual glyph from a "real" Windows > printer driver? (I have verified that calling the GetTextExtentPoint > functions with a one-character string returns the height of the font, > not the height of the glyph. For example, it returns the same height > for 'A' and '_'.) > > Thanks! > -- > ======================================================================== > Ian Pilcher ian.pilcher(a)home.com > ======================================================================== > What about GetCharABCWidth* what does this function use? (or could it use this?) I see the function still shows a fixme (or atleast the last time I checked). - Travis Michielsen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

July 27, 2001

Re: Dose wine people hate Solaris?

by Francois Gouget

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 27, 2001

Re: Dose wine people hate Solaris?

by EriK W

> 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. > > [...] > > gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou > > ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o stabs.o > On my system r_debug is defined in '/usr/include/link.h'. According > to dpkg this is part of libc6-dev. So the problem is that the Solaris C > library does not define it. The link.h header says: > > Data structure for communication from the run-time dynamic linker for > loaded ELF shared objects. > > The easy way out is to say that winedbg is not essential to get > Wine working. So you could decide not to compile it at all. take it out? Can I do that by commenting " LIBPROGRAMS = \ debugger/winedbg" ? > A better approach would be to either provide this r_debug structure > somehow if it is relevant on Solaris, or remove all the related stuff on > Solaris. I'm not a winedbg expert so I've reached my limit here. Maybe > Eric Pouech could advise you better. OK, then I think I probably should be a quite beaver to sit and wait Eric Pouech to figure it out. :) Millions thanks, Francois!! > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

July 27, 2001

RE: winapi update

by Francois Gouget

On Fri, 27 Jul 2001, Patrik Stridvall wrote: [...] > PS. It filters the make messages and only display important messages. Ah, ok. I tried it. The first run gave me a number of errors: $ ./tools/winapi/make_filter make Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in pattern match (m//) at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in string eq at tools/winapi/make_parser.pm line 82, <IN> line 1. Use of uninitialized value in concatenation (.) or string at tools/winapi/make_parser.pm line 30, <IN> line 1. make_filter: : can't parse output: 'Make.rules.in is newer than Make.rules, please rerun ./configure!' Would it be possible to have the messages pass through as-is when they are not recognized (with the current directory for context)? So I ran ./configure and tried again and it was much better. What is a bit strange is that it did not leave a single message around. A third run on a file that I know generates a warning gave me the following: $ ./tools/winapi/make_filter make make_filter: gcc: can't parse output: 'd3ddevice/mesa.c:817: warning: unused variable `xvis'' It looks like there's an incompatibility with colorgcc. Colorgcc is a perl script that you can wrap around gcc and g++ and which colorizes the resulting output. So warnings appear in yellow, errors in red, some other items in cyan, ... It works pretty well as long as your xterm background is black like in the latest Debian. To use colorgcc you simply add symlinks to colorgcc in your path: $ ll /usr/local/bin/gcc /usr/local/bin/g++ lrwxrwxrwx 1 root staff 17 Apr 27 12:37 /usr/local/bin/g++ -> /usr/bin/colorgcc* lrwxrwxrwx 1 root staff 17 Apr 27 12:37 /usr/local/bin/gcc -> /usr/bin/colorgcc* So it must be the controls characters added by colorgcc that confuse make_filter. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

July 27, 2001

Re: Dose wine people hate Solaris?

by Francois Gouget

On Thu, 26 Jul 2001, EriK W wrote: > > The only message I see from you is the one you posted on wine-devel > > the 24th, two *days* ago. > > Actually, before this I posted it to comp.emulators-windows.wine couple > times without even a reply. :) Yes, I suspected as much. I sometimes read cemw but my ISPs news server is real bad. Not as bad as the news feed of Corel who's hosting wine-users. It's been over a month now that the link between wine-users and cemw has been severed :-( [...] > > winebuild is linked with 'libwine_unicode.so' which should have been > > compiled previously and should be in 'wine/unicode'. So the > > LD_LIBRARY_PATH setting seems correct and yet it seems winebuild cannot > > execute because that library cannot be found. > > So: > > * does unicode/libwine_unicode.so exist? > > * in the compilation process you should see Wine go into the unicode > > subdirectory and compile stuff there. Do you indeed see something like > > that? > > * try to start winebuild manually. When in Wine's root directory type > > "./tools/winebuild/winebuild'. Does it work? If not try to tweak > > LD_LIBRARY_PATH to get it to work. Maybe absolute paths work better than > > relative ones? > Doesn't work, I guess there is a problem in Makefile. 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? LD_LIBRARY_PATH="unicode:$LD_LIBRARY_PATH" ./tools/winebuild/winebuild Btw, what is your default shell? [...] > gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou > ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o stabs.o > stabs.c > stabs.c:1271: warning: `struct r_debug' declared inside parameter list > stabs.c:1271: warning: its scope is only this definition or declaration, > which is probably not what you want. On my system r_debug is defined in '/usr/include/link.h'. According to dpkg this is part of libc6-dev. So the problem is that the Solaris C library does not define it. The link.h header says: Data structure for communication from the run-time dynamic linker for loaded ELF shared objects. The easy way out is to say that winedbg is not essential to get Wine working. So you could decide not to compile it at all. A better approach would be to either provide this r_debug structure somehow if it is relevant on Solaris, or remove all the related stuff on Solaris. I'm not a winedbg expert so I've reached my limit here. Maybe Eric Pouech could advise you better. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

July 26, 2001

RE: Even more misc fixes

by Patrik Stridvall

> [...] > > > Most of these are because of the transition to making > HANDLE a void* > > > and compiling with STRICT. > > > > Yes, I notice this was the case with TIMERPROC casts. > > However it is no so with the HOOKPROC casts, > > and yes it is the same with the real Windows headers. > > ??? > AFAICS there are two versions of HOOKPROC: one for -DSTRICT and a > FARPROC one. Hmm. I looked again and it seems you are right. Must have missed it somehow. Strange. > [...] > > But OK I will try and compile with -DSTRICT and see what happends. > > IIRC somebody tried that but it didn't turn out so well. > > That would be me, probably. I started the conversion to -DSTRICT but > then other priorities came up and now it's on the back burner. I will > get back to it eventually but at the current rate it's hard > to know when > that will be :-( > Compiling with -DSTRICT is not that bad: with a relatively simple > patch it compiles (see attachement). Or at least, it used to. > But there > are tons of warnings, which means tons of places that need > attention and > possibly fixing. That's where the work is. OK. Will look at it later.

July 26, 2001

RE: winapi update

by Patrik Stridvall

> Btw, what does make filter do? > > Your post to wine-patches says it's nice an all but it does not say > what it does. Try and run it it is self describing. :-) Since Alexandre didn't apply the Makefile patch, running it is a little awkwark. Will fix that it later versions though. Try do: cd wine ./tools/winapi/make_filter make You can also give it parameters like ./tools/winapi/make_filter make clean Warning "make clean" doesn't look that good currently. PS. It filters the make messages and only display important messages. It might not always work 100% though, but I will fix problems as I find them. I wrote it many months ago and have run it from time to time since, so most issues have been fixed. The reason I wrote it was that I was irritated that important messages scrolled of screen. > If it's nice isn't it worth advertising to the Wine > developper community? I had intended to do that if but since I was unsure that Alexandre would apply my Makefile patch I decided to wait until it could present a better "user interface". But by all means test it.

July 26, 2001

RE: Even more misc fixes

by Francois Gouget

On Fri, 27 Jul 2001, Patrik Stridvall wrote: [...] > > The volatile stuff in dplay.h is part of the Windows header, you > > cannot remove it. > > No it isn't. I'm not sure why it was added in the first place. I don't have it in my VC6 headers either. But it may be in some more recent DirectX headers (7 or 8). [...] > > Most of these are because of the transition to making HANDLE a void* > > and compiling with STRICT. > > Yes, I notice this was the case with TIMERPROC casts. > However it is no so with the HOOKPROC casts, > and yes it is the same with the real Windows headers. ??? AFAICS there are two versions of HOOKPROC: one for -DSTRICT and a FARPROC one. [...] > But OK I will try and compile with -DSTRICT and see what happends. > IIRC somebody tried that but it didn't turn out so well. That would be me, probably. I started the conversion to -DSTRICT but then other priorities came up and now it's on the back burner. I will get back to it eventually but at the current rate it's hard to know when that will be :-( Compiling with -DSTRICT is not that bad: with a relatively simple patch it compiles (see attachement). Or at least, it used to. But there are tons of warnings, which means tons of places that need attention and possibly fixing. That's where the work is. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

July 26, 2001

RE: Even more misc fixes

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > No it isn't. I'm not sure why it was added in the first place. > > It is neither used by Wine, nor defined by Windows. > > It is in the Windows headers I have. It is not in my Microsoft Visual C++ 6.0 header, but perhaps you have a newer version? DPlay using volatile seems a little strange, so I thought is was wrong especially since it was not in my version, but then I have seen stranger things. :-) > > As you wish, but as I said HOOKPROC can't be fixed with STRICT. > > Why not? Because it would be incompatible (warning wise) with Winelib applications compile with -DSTRICT since Windows doesn't provide a special -DSTRICT version of HOOKPROC. The application might pass a FARPROC to it and expect it to work. Well, of course it works but it would generate a warning.

July 26, 2001

Re: winapi update

by Francois Gouget

On 26 Jul 2001, Alexandre Julliard wrote: > Patrik Stridvall <ps(a)leissner.se> writes: > > > The make_filter.diff patch is quite nice. > > > > Try it after applying it with by running: > > make filter > > I'm not sure about the portability of the wildcard rule. Why don't you > have make_filter call make instead of the other way around? This > would avoid the need for changing the makefiles at all. Btw, what does make filter do? Your post to wine-patches says it's nice an all but it does not say what it does. If it's nice isn't it worth advertising to the Wine developper community? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

July 26, 2001

RE: winapi update

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > The make_filter.diff patch is quite nice. > > > > Try it after applying it with by running: > > make filter > > I'm not sure about the portability of the wildcard rule. Why don't you > have make_filter call make instead of the other way around? This > would avoid the need for changing the makefiles at all. Well, make_filter actually calls make already. :-) Seriously, one reason that I added it to the Makefiles in the first place is that make_filter doesn't know what version of make to use. Sure it is called make on almost all systems and gmake (GNU Make) on most of rest, but since the user knows and calls "make", $(MAKE) contains the correct "make". Oh well, I guess just calling make will work on most platforms, it will on all platforms that I current use. The Wine Makefile is supposed to be portable so I guess it will have to do.

July 26, 2001

Re: Even more misc fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > No it isn't. I'm not sure why it was added in the first place. > It is neither used by Wine, nor defined by Windows. It is in the Windows headers I have. > As you wish, but as I said HOOKPROC can't be fixed with STRICT. Why not? > But OK I will try and compile with -DSTRICT and see what happends. > IIRC somebody tried that but it didn't turn out so well. No it needs a lot of fixes, which is what the warnings are here to remind us of. -- Alexandre Julliard julliard(a)winehq.com

July 26, 2001

RE: Even more misc fixes

by Patrik Stridvall

> The volatile stuff in dplay.h is part of the Windows header, you > cannot remove it. No it isn't. I'm not sure why it was added in the first place. It is neither used by Wine, nor defined by Windows. In fact only a few strange headers use volitile at all, and none of them is supported by Wine. > Most of these are because of the transition to making HANDLE a void* > and compiling with STRICT. Yes, I notice this was the case with TIMERPROC casts. However it is no so with the HOOKPROC casts, and yes it is the same with the real Windows headers. > Please don't add typecasts, consider the > warnings as an incentive to do the right fix... As you wish, but as I said HOOKPROC can't be fixed with STRICT. But OK I will try and compile with -DSTRICT and see what happends. IIRC somebody tried that but it didn't turn out so well. Oh well, lets see what happends.

July 26, 2001

Re: Dose wine people hate Solaris?

by EriK W

> The only message I see from you is the one you posted on wine-devel > the 24th, two *days* ago. Actually, before this I posted it to comp.emulators-windows.wine couple times without even a reply. :) And I think I am not the only one encountered this problem, I found exactly same report http://wine.codeweavers.com/cgi-bin/fom?_highlightWords=usr%20local%20lib%20 libwine%20unicode%20so%20open%20failed&file=424 with no any follow up yet, Though I don't know when he reported this problem. Anyway, thanks for your work and replies! > > > Do you guys hate solaris? :) > > I don't think so. But few Wine developpers use Solaris which makes it > harder for them to help you. I myself > > [...] > > Does anybody has even a suggestion for me? pls don't tell me nuke my > > solaris. :) > > No, certainly not. We need you if Wine is going to keep > supporting Solaris :-) > > > So from you previous email: > > [...] > > /usr/openwin/include/X11/Xutil.h:56: warning: ignoring pragma: "@(#)Xutil.h > > 1.2 00/07/05 SMI > > This one does not really matter. > > > > gcc -Wl,-G -Wl,-h,/usr/local/lib/libwine_tsx11.so locking.o ts_xf86dga.o > > ts_xf86dga2.o ts_xf86vmode.o ts_xshm.o ts_xlib.o ts_xresource.o > > ts_xvideo.o ts_xutil.o ts_shape.o ts_xpm.o -o libwine_tsx11.so.1.0 > > rm -f libwine_tsx11.so && ln -s libwine_tsx11.so.1.0 libwine_tsx11.so > > LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" > > ../../tools/winebuild/winebuild -fPIC -L../../dlls -o ntdll.spec.c -spec > > ./ntdll.spec > > ld.so.1: ../../tools/winebuild/winebuild: fatal: > > /usr/local/lib/libwine_unicode.so: open failed: No such file or directory > > winebuild is linked with 'libwine_unicode.so' which should have been > compiled previously and should be in 'wine/unicode'. So the > LD_LIBRARY_PATH setting seems correct and yet it seems winebuild cannot > execute because that library cannot be found. > So: > * does unicode/libwine_unicode.so exist? > * in the compilation process you should see Wine go into the unicode > subdirectory and compile stuff there. Do you indeed see something like > that? > * try to start winebuild manually. When in Wine's root directory type > "./tools/winebuild/winebuild'. Does it work? If not try to tweak > LD_LIBRARY_PATH to get it to work. Maybe absolute paths work better than > relative ones? Doesn't work, I guess there is a problem in Makefile. Eventually I copied the file to /usr/local/lib . But then I run into another problem. gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o msc.o msc.c gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o registers.o registers.c gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o source.o source.c gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o stabs.o stabs.c stabs.c:1271: warning: `struct r_debug' declared inside parameter list stabs.c:1271: warning: its scope is only this definition or declaration, which is probably not what you want. stabs.c: In function `DEBUG_WalkList': stabs.c:1274: storage size of `lm' isn't known stabs.c:1284: dereferencing pointer to incomplete type stabs.c:1274: warning: unused variable `lm' stabs.c:1273: warning: `lm_addr' might be used uninitialized in this function stabs.c: In function `DEBUG_RescanElf': stabs.c:1302: storage size of `dbg_hdr' isn't known stabs.c:1309: `RT_CONSISTENT' undeclared (first use in this function) stabs.c:1309: (Each undeclared identifier is reported only once stabs.c:1309: for each function it appears in.) stabs.c:1313: `RT_ADD' undeclared (first use in this function) stabs.c:1315: `RT_DELETE' undeclared (first use in this function) stabs.c:1310: warning: unreachable code at beginning of switch statement stabs.c:1302: warning: unused variable `dbg_hdr' stabs.c: In function `DEBUG_ReadExecutableDbgInfo': stabs.c:1324: `Elf32_Dyn' undeclared (first use in this function) stabs.c:1324: parse error before `dyn' stabs.c:1325: storage size of `dbg_hdr' isn't known stabs.c:1336: `dyn' undeclared (first use in this function) stabs.c:1339: `DT_DEBUG' undeclared (first use in this function) stabs.c:1339: `DT_NULL' undeclared (first use in this function) stabs.c:1325: warning: unused variable `dbg_hdr' make[1]: *** [stabs.o] Error 1 make[1]: Leaving directory `/export/home/system/wine-20010629/debugger' make: *** [debugger/winedbg] Error 2 Compilation failed, aborting install. Any idea? > > > > -- > > > >

July 26, 2001

Re: winapi update

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > The make_filter.diff patch is quite nice. > > Try it after applying it with by running: > make filter I'm not sure about the portability of the wildcard rule. Why don't you have make_filter call make instead of the other way around? This would avoid the need for changing the makefiles at all. -- Alexandre Julliard julliard(a)winehq.com

July 26, 2001

Re: Even more misc fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > * include/commctrl.h, > include/dplay.h: > Cleanup/removal of unnessary things that would have made > winapi_* parsing more complicated. The volatile stuff in dplay.h is part of the Windows header, you cannot remove it. > * dlls/comctl32/commctrl.c, > dlls/comctl32/tab.c, > dlls/dinput/dinput_main.c, > dlls/dsound/dsound_main.c, > dlls/ole32/clipboard.c, > dlls/ole32/ole2.c, > dlls/wineps/ps.c, > dlls/winmm/joystick.c, > dlls/winmm/wineoss/midi.c, > loader/dos/dosmod.c, > windows/caret.c: > Fixed some warnings. Most of these are because of the transition to making HANDLE a void* and compiling with STRICT. Please don't add typecasts, consider the warnings as an incentive to do the right fix... -- Alexandre Julliard julliard(a)winehq.com

July 26, 2001

Re: Prevent excessive clipping in SysListView32

by Ulrich Weigand

Uwe Bonnes wrote: > >>>>> "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) 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? Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

July 26, 2001

How do I stop clipping?

by Bill Medland

I don't like submitting incomplete code but I may have little choice unless someone can point me in the correct direction here. As you may guess from the following, my Windows experience is not that extensive but I think it's enough to allow me to make sensible contributions. I am working on correcting the LISTVIEW_DrawLargeItem function, especially when the item text is large. I have already got most of the way. However the problem is this. When a user selects a large icon the text should be written completely (by calling DrawText with DT_NOCLIP). It is doing so; I can prove it by resizing the window and I will see the full text being displayed for a selected item. However when drawing it at the moment of selecting it, the text is being clipped to the usual two and a bit rows. Presumably this means that there is a clipping rectangle in the DC or the window that I need to inflate. Or Do I simply invalidate that rectangle (from within the WM_PAINT handler!!!). Any help would be appreciated. Bill

July 26, 2001

Re: Handling X errors using exception handlers

by Alexandre Julliard

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > Do you plan to implement it or should I do it (be warned though that I can > work on it only if the weather is bad this week-end :-) ). I'll do it. I had a version working some time ago, I just need to adapt it to the new per-thread displays. -- Alexandre Julliard julliard(a)winehq.com

July 26, 2001

Re: Handling X errors using exception handlers

by Lionel Ulmer

> > - it cannot 'expect' more than one kind of error at the same time > > I was thinking you could use a special value as a "wildcard" for the > error codes, in which case it wouldn't be tested for a match. Hmmm, yes, nice and clean :-) > > - I am not sure that the parameters thing are really a good idea. Are we > > sure that the error code are the same on all X servers ? Are they > > standardized ? > > They are part of the X spec AFAICT, so yes it should be pretty much > standard. Yeah, now that I think of it, it should be part of the spec, except for the extension errors... But as we store the 'error base', it should work also for these cases. Do you plan to implement it or should I do it (be warned though that I can work on it only if the weather is bad this week-end :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 26, 2001

Re: Dose wine people hate Solaris?

by Francois Gouget

On Thu, 26 Jul 2001, EriK W wrote: > I have posted my question for compiling Wine in solaris x86 for 2 weeks, > seems no anybody even has a bit interest. The only message I see from you is the one you posted on wine-devel the 24th, two *days* ago. > Do you guys hate solaris? :) I don't think so. But few Wine developpers use Solaris which makes it harder for them to help you. I myself [...] > Does anybody has even a suggestion for me? pls don't tell me nuke my > solaris. :) No, certainly not. We need you if Wine is going to keep supporting Solaris :-) So from you previous email: [...] > /usr/openwin/include/X11/Xutil.h:56: warning: ignoring pragma: "@(#)Xutil.h > 1.2 00/07/05 SMI This one does not really matter. > gcc -Wl,-G -Wl,-h,/usr/local/lib/libwine_tsx11.so locking.o ts_xf86dga.o > ts_xf86dga2.o ts_xf86vmode.o ts_xshm.o ts_xlib.o ts_xresource.o > ts_xvideo.o ts_xutil.o ts_shape.o ts_xpm.o -o libwine_tsx11.so.1.0 > rm -f libwine_tsx11.so && ln -s libwine_tsx11.so.1.0 libwine_tsx11.so > LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" > ../../tools/winebuild/winebuild -fPIC -L../../dlls -o ntdll.spec.c -spec > ./ntdll.spec > ld.so.1: ../../tools/winebuild/winebuild: fatal: > /usr/local/lib/libwine_unicode.so: open failed: No such file or directory winebuild is linked with 'libwine_unicode.so' which should have been compiled previously and should be in 'wine/unicode'. So the LD_LIBRARY_PATH setting seems correct and yet it seems winebuild cannot execute because that library cannot be found. So: * does unicode/libwine_unicode.so exist? * in the compilation process you should see Wine go into the unicode subdirectory and compile stuff there. Do you indeed see something like that? * try to start winebuild manually. When in Wine's root directory type "./tools/winebuild/winebuild'. Does it work? If not try to tweak LD_LIBRARY_PATH to get it to work. Maybe absolute paths work better than relative ones? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

July 26, 2001

Re: Dose wine people hate Solaris?

by Marcus Meissner

On Thu, Jul 26, 2001 at 10:04:03AM -0700, EriK W wrote: > 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? :) No. We just do not have it, so we can't use it. > 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. :) Try WINE first, fix/report the errors? Ciao, Marcus

July 26, 2001

Re: ChangeDisplaySettings

by Lionel Ulmer

> Hmm, I was going to try something like that, however, I had problems with that > method simply b/c of the load order between the dlls. ChangeDisplaySettings is > implemented in user32.dll which loads BEFORE x11drv. Yes, but if you look at file user32.spec, you have : init USER_Init This is a function called at DLL loading (AFAIK). It is in file user_main.c At DLL loading, this function calls 'process_attach' that calls 'load_driver' (all functions are in the same file). 'load_driver' does the following : strcpy( buffer, "x11drv" ); /* default value */ (...) if (!(graphics_driver = LoadLibraryA( buffer ))) { MESSAGE( "Could not load graphics driver '%s'\n", buffer ); return FALSE; } This means that even if USER32.dll is loaded BEFORE x11drv.dll, the init function of USER32 will load the current graphics driver, i.e. x11drv. Later in the same function, all function pointers are initialized using the GET_USER_FUNC macro. BTW, you did NOT read the thread about my OpenGL fixes recently where Alexandre plainly told that putting x11drv.dll in a spec file is bad :-) ? > Already using so of that code, although it could probably be cleaned up a bit. > I will get to that soon. Ah, did not look in details at your patch :-) Stopped at the 'Oh my god, X11 calls in USER' :-) Anyway, let's hope I will not discourage you :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 26, 2001

Re: native dll's

by Francois Gouget

On Wed, 25 Jul 2001, José Soriano Díaz wrote: > > Hi there, I'm working in a telerobotics project and I need to link a > windows dll in order to use a Cybernet Joystick. > First I tried to use the winAPI functions LoadLibrary, > FreeLibrary and GetProccessAddress as I were working on Windows, and > I recompiled my program with winelib: > *. winemaker /my_path/ > *. ./configure > *. make all > but it didn't create any executable, what I obtained was a > lib*.so, because winemaker thought I was trying to compile a dll, > not to use one. To force winemaker to generate an executable simply use it as follows: * type "winemaker --cuiexe /my_path" to indicate a console executable * type "winemaker --guiexe /my_path" to indicate a graphical executable You can also use "winemaker -?" to get a list of options supported by winemaker. > So my question is quite siple How can I link a native dll in > a Unix project? I think you have used the right approach: LoadLibrary / GetProccessAddress / FreeLibrary. If that works for you then it's the simplest approach. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

July 26, 2001

Dose wine people hate Solaris?

by EriK W

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

July 26, 2001

Any use for glyph bounding boxes in printer driver?

by Ian Pilcher

Currently, the Wine PostScript driver stores the bounding box (xMin, yMin, xMax, yMax) for every glyph in every font. This information is not currently used, and I'd like to get rid of it. (Note: this is distinct from the advance width of each glyph, which is certainly required.) >From what I can tell, there is no API that a Win32 application or the Windows GDI can use to get this information from a printer driver. Since I'm not that familiar with either, however, I figure I should try to confirm that this is indeed the case. So, does anyone know of any API that an application or the GDI can use to get the dimensions of an individual glyph from a "real" Windows printer driver? (I have verified that calling the GetTextExtentPoint functions with a one-character string returns the height of the font, not the height of the glyph. For example, it returns the same height for 'A' and '_'.) Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

July 26, 2001

Re: DrawText

by Bill Medland

Travis Michielsen <tjmichielsen(a)yahoo.com> wrote in article <20010726134156.97724.qmail(a)web14204.mail.yahoo.com>... > > --- Bill Medland <medbi01(a)accpac.com> wrote: > > Travis Michielsen <tjmichielsen(a)yahoo.com> wrote in article > > <20010725154148.15682.qmail(a)web14205.mail.yahoo.com>... > > > > > Fully implement DrawText* functions. > > > > > > > > Thank you ; thank you; thank you > > > > > > > > Weird coincidence. I had just started thinking about problems with the > > > > display of large icon names in the ListView control and was about to > > start > > > > digging into who was supposed to be handling the word-wrapping etc. > > (Shows > > > > how little I know about Windows doesn't it). Now I don't have to think > > > > (but I'll look to see if the format is correct) > > > > > > > > Bill > > > > > > Glad I could help! :) Hopefully it works for you. Just hope its tested > > enough > > > that it works good in all situations. > > > > > > - Travis Michielsen > > > > Sorry, it doesn't. There are some problems down in the core to do with the > > handling of DT_WORD_ELLIPSIS in non-single-line controls etc. (The > > ellipsis handling needs to be in the TEXT_NextLineW). > > > > Are you well set up to handle all that stuff or shall I? (After all, I > > have the offending cases with which to test) > > > > Bill > > Sorry to hear that. I will be able to look into it but if anyone has any test > programs they would help ALOT. How about the Hello World sample program from Petzold 3rd edition chapter 2 with tiny modifications. Personally the difficult bit for me is designing the experiments themselves. If you like I can create some of the test cases if you want to do the coding. Do you want to take this off the newsgroup? By the way, how about using GetTextExtentExPoint to measure the string, that way you don't need to worry about the kerning etc; the only complication is the tabs. Bill

July 26, 2001

Re: Prevent excessive clipping in SysListView32

by Bill Medland

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote in article <15199.54377.7430.982534(a)hertz.ikp.physik.tu-darmstadt.de>... > >>>>> "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 ---------- > > > > It's not my function so I don't particularly care what happens; all that I know is that when the function was modified on 19 June it started causing problems with the listview control when the texts were too large to fit. Note that the static int perfect was inside the function before that date. However to be honest since the function grew so significantly and takes no argument I don't see why it is inline anyway. Bill

July 26, 2001

Re: DrawText

by Travis Michielsen

--- Bill Medland <medbi01(a)accpac.com> wrote: > Travis Michielsen <tjmichielsen(a)yahoo.com> wrote in article > <20010725154148.15682.qmail(a)web14205.mail.yahoo.com>... > > > > Fully implement DrawText* functions. > > > > > > Thank you ; thank you; thank you > > > > > > Weird coincidence. I had just started thinking about problems with the > > > display of large icon names in the ListView control and was about to > start > > > digging into who was supposed to be handling the word-wrapping etc. > (Shows > > > how little I know about Windows doesn't it). Now I don't have to think > > > (but I'll look to see if the format is correct) > > > > > > Bill > > > > Glad I could help! :) Hopefully it works for you. Just hope its tested > enough > > that it works good in all situations. > > > > - Travis Michielsen > > Sorry, it doesn't. There are some problems down in the core to do with the > handling of DT_WORD_ELLIPSIS in non-single-line controls etc. (The > ellipsis handling needs to be in the TEXT_NextLineW). > > Are you well set up to handle all that stuff or shall I? (After all, I > have the offending cases with which to test) > > Bill Sorry to hear that. I will be able to look into it but if anyone has any test programs they would help ALOT. - Travis Michielsen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

July 26, 2001

Re: ChangeDisplaySettings

by Travis Michielsen

--- Lionel Ulmer <lionel.ulmer(a)free.fr> wrote: > > This patch partially implements the ChangeDisplaySettings* functions. > > Well, I am 100 % sure that Alexandre will reject it :-) :-\ > If you want to do something like that, you need to implement the feature in > the X11 driver and then call it via the 'USER_Driver.pFunctionName' > protocol. Hmm, I was going to try something like that, however, I had problems with that method simply b/c of the load order between the dlls. ChangeDisplaySettings is implemented in user32.dll which loads BEFORE x11drv. This makes it impossible to initalize the function with the user32.dll. However, with DDraw, the x11drv.dll is loaded before the ddraw.dll! The only way I saw to exchange info was to initialize the function with a call from x11drv.dll. If you can suggest an alternative that takes load order into account I will likely use it. > Moreover, there are already some DDraw-related mode change functions (in > dlls/x11drv/xvidmode.c). This should be factorized between both code. Already using so of that code, although it could probably be cleaned up a bit. I will get to that soon. - Travis Michielsen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

July 26, 2001

Re: Prevent excessive clipping in SysListView32

by Uwe Bonnes

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

July 26, 2001

Re: DrawText

by Bill Medland

Travis Michielsen <tjmichielsen(a)yahoo.com> wrote in article <20010725154148.15682.qmail(a)web14205.mail.yahoo.com>... > > > Fully implement DrawText* functions. > > > > Thank you ; thank you; thank you > > > > Weird coincidence. I had just started thinking about problems with the > > display of large icon names in the ListView control and was about to start > > digging into who was supposed to be handling the word-wrapping etc. (Shows > > how little I know about Windows doesn't it). Now I don't have to think > > (but I'll look to see if the format is correct) > > > > Bill > > Glad I could help! :) Hopefully it works for you. Just hope its tested enough > that it works good in all situations. > > - Travis Michielsen Sorry, it doesn't. There are some problems down in the core to do with the handling of DT_WORD_ELLIPSIS in non-single-line controls etc. (The ellipsis handling needs to be in the TEXT_NextLineW). Are you well set up to handle all that stuff or shall I? (After all, I have the offending cases with which to test) Bill

July 25, 2001

Re: CallWindowProc syntax

by Alexandre Julliard

Marco Bizzarri <m.bizzarri(a)icube.it> writes: > While looking at the source code of wine, I looked into the synopsys of > the CallWindowProc function. According to winproc.c, the hWnd parameter > should be the handle to the window which has to receive the message. > > OTOH, if you look at MSDN, at > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/hh/w… > > it looks like the hWnd is the windows procedure which should receive the > message. hWnd is clearly a window handle, not a window procedure. As a rule, any resemblance between what MSDN says and what the code actually does is purely fortuitous. -- Alexandre Julliard julliard(a)winehq.com

July 25, 2001

Wine Winex Half-life/Nox and alsa

by FT Rathore

Hi I tried Jul 23 cvs of wine and winex and tried with Nox and Half Life. Both wine and winex work fine with the stock kernel sound drivers (es1371) but they do not work well with alsa with oss emulation. The sound gets played extremely fast in Half-Life like someone hit the fast-forward button. It is strange because the timing on the alsa oss-emulation (and commercial oss drivers) is better than the stock kernel drivers. Winex does a lot of improvement in Half-Life and it is fully playable (the splash, the menu and everything). Nox works near perfect with wine but it does not work at all with winex. FT

July 25, 2001

native dll's

by José Soriano Díaz

Hi there, I'm working in a telerobotics project and I need to link a windows dll in order to use a Cybernet Joystick. First I tried to use the winAPI functions LoadLibrary,FreeLibrary and GetProccessAddress as I were working on Windows, and I recompiled my program with winelib: *. winemaker /my_path/ *. ./configure *. make all but it didn't create any executable, what I obtained was a lib*.so, because winemaker thought I was trying to compile a dll, not to use one. After that I tried to compile my program without winemaker, and I obtained a HEAP_PTR error when executing what I copiled. And If I tried to link the lib*.so and load the main symbol I obtained the same error. So my question is quite siple How can I link a native dll in a Unix project? I've read somewhere that I have to use a parser, Is there anybody who can give me some code? Thanks for your precious time. _________________________________________________________________ Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.es/intl.asp

July 25, 2001

(no subject)

by José Soriano Díaz

Hi there, I'm working in a telerobotics project and I need to link a windows dll in order to use a Cybernet Joystick. First I tried to use the winAPI functions LoadLibrary,FreeLibrary and GetProccessAddress as I were working on Windows, and I recompiled my program with winelib: *. winemaker /my_path/ *. ./configure *. make all but it didn't create any executable, what I obtained was a lib*.so, because winemaker thought I was trying to compile a dll, not to use one. After that I tried to compile my program without winemaker, and I obtained a HEAP_PTR error when executing what I copiled. And If I tried to link the lib*.so and load the main symbol I obtained the same error. So my question is quite siple How can I link a native dll in a Unix project? I've read somewhere that I have to use a parser, Is there anybody who can give me some code? Thanks for your precious time. _________________________________________________________________ Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.es/intl.asp

July 25, 2001

Re: DrawText

by Travis Michielsen

> > Fully implement DrawText* functions. > > Thank you ; thank you; thank you > > Weird coincidence. I had just started thinking about problems with the > display of large icon names in the ListView control and was about to start > digging into who was supposed to be handling the word-wrapping etc. (Shows > how little I know about Windows doesn't it). Now I don't have to think > (but I'll look to see if the format is correct) > > Bill Glad I could help! :) Hopefully it works for you. Just hope its tested enough that it works good in all situations. - Travis Michielsen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

July 25, 2001

Re: DrawText

by Bill Medland

Travis Michielsen <tjmichielsen(a)yahoo.com> wrote in article <20010725140159.78216.qmail(a)web14203.mail.yahoo.com>... > Fully implement DrawText* functions. Thank you ; thank you; thank you Weird coincidence. I had just started thinking about problems with the display of large icon names in the ListView control and was about to start digging into who was supposed to be handling the word-wrapping etc. (Shows how little I know about Windows doesn't it). Now I don't have to think (but I'll look to see if the format is correct) Bill

July 25, 2001

CallWindowProc syntax

by Marco Bizzarri

Hi all. While looking at the source code of wine, I looked into the synopsys of the CallWindowProc function. According to winproc.c, the hWnd parameter should be the handle to the window which has to receive the message. OTOH, if you look at MSDN, at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/hh/w… it looks like the hWnd is the windows procedure which should receive the message. Can anyone help? Thanks Marco Bizzarri m.bizzarri(a)icube.it

July 25, 2001

DrawText

by Travis Michielsen

Fully implement DrawText* functions. - Travis Michielsen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

July 25, 2001

Re: Make built-in font data read-only

by Ian Pilcher

Alexandre Julliard wrote: > > Well, if it's not feasible so be it. But if it's at all possible I > think it's worth some reasonable amount of trouble. > AFAICT, just about every part of the driver that deals with fonts would have to be rewritten to deal with two different data models. In addition to the up-front work, just imagine the maintenance nightmare! I'll keep chewing on this. Suggestions are welcome! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

July 25, 2001

Re: Make built-in font data read-only

by Alexandre Julliard

Ian Pilcher <ian.pilcher(a)home.com> writes: > If all pointers have to be eliminated, I can't see any way to do it. > In order for the code to have any kind of sanity, built-in font metrics > and dynamically loaded font metrics have to use the same data model, and > I don't think it's even remotely practical to get rid of the pointers in > the case of the dynamically loaded metrics. Well, if it's not feasible so be it. But if it's at all possible I think it's worth some reasonable amount of trouble. > I'm open to suggestions, but I think that the effort involved in doing > this (assuming a sane way could be found) probably far outweighs the > benefit (less swap usage if the data is paged out; is there any other > benefit?). The main benefit is sharing between processes; so if you have 10 processes that want to print you only have one copy of the font data in memory. Plus it gets loaded on-demand so data that isn't used doesn't need to be loaded from disk at all. > Just in case I get inspired, though, what tool/command are you using to > determine read-only vs. read/write data sizes? Can I just go by what > objdump says about .data and .rodata? objdump is fine yes. size works too, though I seem to remember some versions not counting .rodata correctly. -- Alexandre Julliard julliard(a)winehq.com

July 25, 2001

Re: Make built-in font data read-only

by Ian Pilcher

Alexandre Julliard wrote: > Ian Pilcher <ian.pilcher(a)home.com> writes: > > > Unfortunately the data still isn't stored in read-only memory even > though it is declared const, because the structures contain pointers > that require relocation. Would it be possible to store offsets instead > of pointers? > > If all pointers have to be eliminated, I can't see any way to do it. In order for the code to have any kind of sanity, built-in font metrics and dynamically loaded font metrics have to use the same data model, and I don't think it's even remotely practical to get rid of the pointers in the case of the dynamically loaded metrics. I'm open to suggestions, but I think that the effort involved in doing this (assuming a sane way could be found) probably far outweighs the benefit (less swap usage if the data is paged out; is there any other benefit?). Better to focus to eliminating unused data, which is probably more than 50% of what's there right now. Just in case I get inspired, though, what tool/command are you using to determine read-only vs. read/write data sizes? Can I just go by what objdump says about .data and .rodata? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

July 25, 2001

Re: move 16bit COMM code to USER

by lawson_whitney＠juno.com

On Tue, 24 Jul 2001 11:11:05 +1000 Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a multi-part message in MIME format > > ------=_NextPart_000_83577347 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > > This patch completes the seperation of the 16bit COMM code from > KERNEL > and moves it to USER. Seems to work with Terminal from WFW 3.11. > > Mike If you get this, it seems to work for juno 1.49 too. Lawson ---oof--- > ChangeLog: > move 16-bit COMM code to USER dll > > ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

July 25, 2001

Re: Microsoft source code releases - a danger to Wine?

by kenon＠go2.pl

On Mon, Jul 23, 2001 at 02:39:02PM +0000, Bill Medland wrote: > > I must admit that as a newcomer to the Wine project I would appreciate a > little guidance on what are and are not valid methods for investigating > Windows sufficiently to work on the Wine project. This cuts two ways: > 1. What methods are accepted as legal for obtaining information and what > methods must not be used (in order to protect Wine) > 2. What methods are especially effective and what methods are a waste of > time (in order to improve the learning curve for contributors) > > Should there be a section in the Wine Development HQ > > (Or is it already there and I missed it). > > Bill > > I want to know too. Maciek

July 24, 2001

Re: Make built-in font data read-only

by Alexandre Julliard

Ian Pilcher <ian.pilcher(a)home.com> writes: > Log message: > Ian Pilcher <ian.pilcher(a)home.com> > WINEPS: make built-in font data read-only Unfortunately the data still isn't stored in read-only memory even though it is declared const, because the structures contain pointers that require relocation. Would it be possible to store offsets instead of pointers? -- Alexandre Julliard julliard(a)winehq.com

July 24, 2001

Re: oleaut32 patch

by Alexandre Julliard

Andreas Mohr <a.mohr(a)mailto.de> writes: > - changes OaBuildVersion() to always return a very high version value > (2.xx.0xffff), which can be overridden in the config file to deliver > an exact value instead Do we really need such an obscure parameter in the main config file? Are there actual cases where setting the version based on -winver is not enough? -- Alexandre Julliard julliard(a)winehq.com

July 24, 2001

Compile error, Please help!!!!!Thanks

by EriK W

Hi gurus, Please help me out with the fatal compiling problem. I am using soalris8 x86 with wine-20010629, Any suggestion would be highly appreciated! /usr/openwin/include/X11/Xutil.h:56: warning: ignoring pragma: "@(#)Xutil.h 1.2 00/07/05 SMI gcc -Wl,-G -Wl,-h,/usr/local/lib/libwine_tsx11.so locking.o ts_xf86dga.o ts_xf86dga2.o ts_xf86vmode.o ts_xshm.o ts_xlib.o ts_xresource.o ts_xvideo.o ts_xutil.o ts_shape.o ts_xpm.o -o libwine_tsx11.so.1.0 rm -f libwine_tsx11.so && ln -s libwine_tsx11.so.1.0 libwine_tsx11.so LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/winebuild/winebuild -fPIC -L../../dlls -o ntdll.spec.c -spec ./ntdll.spec ld.so.1: ../../tools/winebuild/winebuild: fatal: /usr/local/lib/libwine_unicode.so: open failed: No such file or directory *** Error code 137 make: Fatal error: Command failed for target `ntdll.spec.c' Current working directory /export/home/ericw/system/wine-20010629/dlls/ntdll *** Error code 1 make: Fatal error: Command failed for target `ntdll/libntdll.so' Current working directory /export/home/ericw/system/wine-20010629/dlls *** Error code 1 make: Fatal error: Command failed for target `dlls'

July 24, 2001

Re: Function declaration fixes

by Francois Gouget

On Mon, 23 Jul 2001, Patrik Stridvall wrote: [...] > *** declarations > > * dlls/msvcrt/cpp.c, > dlls/msvcrt/exit.c, > dlls/msvcrt/mbcs.c, > dlls/msvcrt/msvcrt.h, > dlls/ntdll/signal_i386.c, > dlls/shell32/shlmenu.c, > include/wine/undocshell.h: > - Made sure that the files that contains the declarations > of the implementated functions are included. > - Corrected mismatching prototypes. > - Cleaned up the include section. You should not add a prototype for MSVCRT_isleadbyte and MSVCRT_realloc in wine/dlls/msvcrt/msvcrt.h. These are declared in include/msvcrt/wctype.h and include/msvcrt/malloc.h respectively. The correct fix is to include these headers where needed. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

July 23, 2001

[PROBLEM REPORT] Edit control line scrolling

by Gerard Patel

With programs using a multiline edit control, such as Notepad (I'm using Win3.11 version) or Eudora Light 1.5 with mails from the 'In' mailbox (this is a 32 bits application), scrolling down the edit buffer line by line mostly does not work. In fact, it works only if the edit buffer size is an exact multiple of the line height. In all other cases, the format rectangle is smaller than the client size, and when the edit control tries to redraw the last line, the update rectangle is wrong : only the lower part of the line is drawn. I think that this problem can be traced to the replacement of code in ScrollWindowEx by the call to ScrollDC. What is happening is that the client rectangle is scrolled, but the client rectangle is bigger than the formatting rectangle by a few pixels; these pixels are missing in the update region. In Wine previous version, the client rectangle was first ANDed with the so-called 'visible region' (hvisRgn), so the result was not bigger than the format rectangle before being scrolled, then diff-ed with it. The following patch works around this problem. I don't have time to investigate further as I am taking one week of holidays :-) but if someone is interested in the edit control.... Gerard Index: dlls/x11drv/scroll.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/scroll.c,v retrieving revision 1.2 diff -u -r1.2 scroll.c --- dlls/x11drv/scroll.c 2001/06/20 00:18:48 1.2 +++ dlls/x11drv/scroll.c 2001/07/22 22:12:06 @@ -114,7 +114,7 @@ hrgn2 = CreateRectRgnIndirect( &rect ); if (hrgn) SetRectRgn( hrgn, rClip.left, rClip.top, rClip.right, rClip.bottom ); else hrgn = CreateRectRgn( rClip.left, rClip.top, rClip.right, rClip.bottom ); - CombineRgn( hrgn, hrgn, hrgn2, RGN_AND ); + CombineRgn( hrgn2, hrgn, hrgn2, RGN_AND ); OffsetRgn( hrgn2, dx, dy ); CombineRgn( hrgn, hrgn, hrgn2, RGN_DIFF );

July 23, 2001

Re: [PROBLEM REPORT] Edit control line scrolling

by Bill Medland

Gerard Patel <gerard.patel(a)nerim.net> wrote in article <1.5.4.32.20010723223108.4150002c(a)pop.nerim.net>... > With programs using a multiline edit control, such as Notepad (I'm using Win3.11 > version) or Eudora Light 1.5 with mails from the 'In' mailbox (this is a 32 bits > application), scrolling down the edit buffer line by line mostly does not work. > > In fact, it works only if the edit buffer size is an exact multiple of the > line height. > > In all other cases, the format rectangle is smaller than the client size, > and when > the edit control tries to redraw the last line, the update rectangle is > wrong : only the > lower part of the line is drawn. > > I think that this problem can be traced to the replacement of code in > ScrollWindowEx > by the call to ScrollDC. > > What is happening is that the client rectangle is scrolled, but the client > rectangle is > bigger than the formatting rectangle by a few pixels; these pixels are > missing in > the update region. > > In Wine previous version, the client rectangle was first ANDed with the > so-called > 'visible region' (hvisRgn), so the result was not bigger than the format > rectangle > before being scrolled, then diff-ed with it. > > The following patch works around this problem. > > I don't have time to investigate further as I am taking one week of > holidays :-) but if someone is interested in the edit control.... > > Gerard > > > Index: dlls/x11drv/scroll.c > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/scroll.c,v > retrieving revision 1.2 > diff -u -r1.2 scroll.c > --- dlls/x11drv/scroll.c 2001/06/20 00:18:48 1.2 > +++ dlls/x11drv/scroll.c 2001/07/22 22:12:06 > @@ -114,7 +114,7 @@ > hrgn2 = CreateRectRgnIndirect( &rect ); > if (hrgn) SetRectRgn( hrgn, rClip.left, rClip.top, rClip.right, > rClip.bottom ); > else hrgn = CreateRectRgn( rClip.left, rClip.top, rClip.right, > rClip.bottom ); > - CombineRgn( hrgn, hrgn, hrgn2, RGN_AND ); > + CombineRgn( hrgn2, hrgn, hrgn2, RGN_AND ); > OffsetRgn( hrgn2, dx, dy ); > CombineRgn( hrgn, hrgn, hrgn2, RGN_DIFF ); > > > > > If anyone does start looking at this, watch out for the following. I haven't looked closely and admit that I probably left the code very slightly incorrect for a degenerate case. I think that in the case of a single border (is WS_BORDER, no WS_CLIENTEDGE etc) then the edit control fiddles things so that it pretends it doesn't have a border (i.e. there is no non-client rectangle) and it draws the border itself. This is possibly unusual; I believe that most controls leave the border drawing to the NC_ code. Since I don't think WS_BORDER is specified alone in most cases I doubt if this is a problem in reality. Bill

July 23, 2001

Why is this wrong?

by Bill Medland

The code of "perfect_graphics" (attached) gives my system problems. The visible aspect of the problem is that the text in our application's listview doesn't get drawn properly. By experimentation I have narrowed it down to when perfect_graphics was edited. I observe that our application works correctly under the two following cases: 1. When the body of the function is removed and the value is hard-coded to true 2. When the "inline" is removed (which is the fix I am proposing and will submit in a moment) Since I do not like working without understanding I would like to know: Is there something wrong with the use of "inline" in this context? Or is there clearly something wrong with my build environment? Or is everyone else as confused by it as me? TIA Bill begin 600 e1 M+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ#0H@*B @(" @(" @(" @<&5R M9F5C=%]G<F%P:&EC<PT*("H-"B J($9A=F]R(&-O<G)E8W1N97-S(&]R('-P M965D/PT*("HO#0IS=&%T:6,@:6YL:6YE(&EN="!P97)F96-T7V=R87!H:6-S M*'9O:60I#0I[#0H@(" @<W1A=&EC(&EN="!P97)F96-T(#T(a)+3$[#0H@(" @ M:68@*'!E<F9E8W0@/3T(a)+3$I#0H@(" @>PT*"4A+15D@:&ME>3L-"@EC:&%R M(&)U9F9E<ELR,%T[#0H)+RH(a)9&5F875L="!V86QU92 J+PT*"7!E<F9E8W0@ M/2 P.PT*"6EF*"%296=/<&5N2V5Y02A(2T597TQ/0T%,7TU!0TA)3D4L(")3 M;V9T=V%R95Q<5VEN95Q<5VEN95Q<0V]N9FEG7%QX,3%D<G8B+" F:&ME>2DI M#0H)>PT*"2 @("!$5T]21"!T>7!E+"!C;W5N=" ]('-I>F5O9BAB=69F97(I M.PT*"2 @("!I9B(a)A4F5G475E<GE686QU945X02AH:V5Y+" B4&5R9F5C=$=R M87!H:6-S(BP@,"P@)G1Y<&4L(&)U9F9E<BP@)F-O=6YT*2D-"B @(" @(" @ M(" @('L-"B @(" @(" @(" @(" @("!C:&%R(&-H(#T(a)8G5F9F5R6S!=.PT* M(" @(" @(" @(" @(" @('!E<F9E8W0@/2 H8V@@/3T@)WDG('Q\(&-H(#T] M("=9)R!\?"!C:" ]/2 G="<@?'P(a)8V@@/3T@)U0G('Q\(&-H(#T]("<Q)RD[ M#0H@(" @(" @(" @("!]#0H)(" @(%)E9T-L;W-E2V5Y*&AK97DI.PT*"7T- @"B @("!]#0H@(" @<F5T=7)N('!E<F9E8W0[#0I]#0IY ` end

July 23, 2001

Re: Executable permissions on .exe/.com files

by Alexandre Julliard

Bernhard Rosenkraenzer <bero(a)redhat.de> writes: > Since some people will probably want to use BINFMT_MISC or similar > functionality to run wine transparently, I think we need the possibility > to set executable permissions on wine-generated (e.g. by "wine setup.exe") > .exe/.com files. > > This patch implements this (optionally - new configure switch). I have applied it, but without the configure switch. I think it should be OK to always set the permissions, and if it turns out to cause trouble we should add a run-time option, not a compile-time one. -- Alexandre Julliard julliard(a)winehq.com

July 23, 2001

Re: implement BuildCommDCB16 using BuildCommDCB

by lawson_whitney＠juno.com

On Mon, 23 Jul 2001 16:59:35 +1000 Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a multi-part message in MIME format > > ------=_NextPart_000_80675836 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > > This (untested) patch completes the COMM16 code seperation. The > COMM16 > code can now be moved into USER (i think). > > Mike Juno 1.49 finds no fault with this, but AFAICS from a comm trace, the app doesn't use the DCB functions, so this is not such a conclusive test. Anybody else have any 16 bit comms apps? Lawson ---oof--- > ChangeLog: > rewrite BuildCommDCB16 to depend on BuildCommDCB, not vice-versa > ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

July 23, 2001

Re: Still problems with snoop

by Uwe Bonnes

>>>>> "Francois" == Francois Gouget <fgouget(a)free.fr> writes: Francois> On Mon, 23 Jul 2001, Uwe Bonnes wrote: >> Hallo, >> >> some days ago I reported early crashes when running with the snoop >> debug option. E.g. vc98 msedv.exe is a good example. Running with >> "+snoop" crashes early. Running with "-snoop=devshl" lets the program >> succeed much further. Running without snoop gets even substancial >> further. >> >> So I think there must be something wrong with snoop. I tried to look >> hard at relay32/snoop.c, but didn't see anything fishy. So perhaps >> somebody else has some idea what's going wrong. Francois> Some time ago I found that we would crash in SNOOP_PrintArg Francois> when x==-1, eventhough it's all in a try/catch. I didn't get Francois> time to investigate in detail. You can try to see if this Francois> patch makes things better (the traces are there for debug in Francois> case you remove the -1 test): Francois, thanks for your help. However the crash happens miles away from an snoop entry or exit in an MFC42 function, so the patch doesn't help: 080672b0:CALL mfc42.5163: ?OnWndMsg(a)CWnd@@MAEHIIJPAJ(a)Z(00000081,00000000,405f5ad4,405f5728) ret=5f447664 ^^^^^^^^^^^^^^ 080672b0:CALL msvcrt.67: _EH_prolog(40f9007d,00000081,00000000,405f5ad4,405f5728,00000081,40a96dc0,40 400c48,00000000,405f5748,40f90064,00000081,00000000,405f5ad4,40a96dc0,40a96dc0, ...) ret=5f4476a4 080672b0:RET msvcrt.67: _EH_prolog() retval = 40f90096 ret=5f4476a4 080672b0:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006bc87 080672b0:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006bc87 ... 080672b0:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006bc87 080672b0:CALL msvcrt.203: _except_handler3(<unknown, check return>) ret=4006bc87 080672b0:CALL msvcrt.73: _XcptFilter(<unknown, check return>) ret=0040175d fixme:pthread_kill_other_threads_np WineDbg starting... on pid 8068990 No debug information in 32bit DLL '<Debugged process>' (0x00400000) Loaded debug information from ELF 'wine' (0x00000000) Breakpoint 1 at 0x4000da00 (_end+0x37fc1284) Loaded debug information from ELF '/spare/bon/wine/dlls/libntdll.so' (0x40026000) ... =>0 0x5f4475da (?AfxFindMessageEntry@@YGPBUAFX_MSGMAP_ENTRY@@PBU1(a)III@Z+0x10 in C:\NT4SP5G\SYSTEM32\MFC42.DLL) (ebp=405f567c) 1 0x5f44780a (?OnWndMsg(a)CWnd@@MAEHIIJPAJ(a)Z+0x170 in C:\NT4SP5G\SYSTEM32\MFC42.DLL) (ebp=405f5704) ^^^^^^^^^^^^^ 2 0x40f9007d (_end+0x2a1edd) (ebp=405f572c) 3 0x40f90064 (_end+0x2a1ec4) (ebp=405f5748) 4 0x50301f1f (DEVPRJ.PKG..text+0xf1f in C:\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=405f5764) For me it seems, that at some point we get different arguments back from a dll when run with snoop versus running without snoop. I don't expect subtile timing problems, as the crash happens deterministic. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 23, 2001

Re: Still problems with snoop

by Francois Gouget

On Mon, 23 Jul 2001, Uwe Bonnes wrote: > Hallo, > > some days ago I reported early crashes when running with the snoop debug > option. E.g. vc98 msedv.exe is a good example. Running with "+snoop" crashes > early. Running with "-snoop=devshl" lets the program succeed much > further. Running without snoop gets even substancial further. > > So I think there must be something wrong with snoop. I tried to look hard at > relay32/snoop.c, but didn't see anything fishy. So perhaps somebody else has > some idea what's going wrong. Some time ago I found that we would crash in SNOOP_PrintArg when x==-1, eventhough it's all in a try/catch. I didn't get time to investigate in detail. You can try to see if this patch makes things better (the traces are there for debug in case you remove the -1 test): --- cut here --- Index: relay32/snoop.c =================================================================== RCS file: /home/wine/wine/relay32/snoop.c,v retrieving revision 1.44 diff -u -r1.44 snoop.c --- relay32/snoop.c 2001/07/18 20:00:06 1.44 +++ relay32/snoop.c 2001/07/20 23:31:02 @@ -212,7 +214,7 @@ int i,nostring; char * volatile ret=0; - if ( !HIWORD(x) ) { /* trivial reject to avoid faults */ + if ( !HIWORD(x) || x==-1 ) { /* trivial reject to avoid faults */ sprintf(buf,"%08lx",x); return buf; } @@ -220,9 +222,13 @@ LPBYTE s=(LPBYTE)x; i=0;nostring=0; while (i<80) { + if (x==-1) TRACE("%d: i=%d\n",__LINE__,i); if (s[i]==0) break; + if (x==-1) TRACE("%d: i=%d\n",__LINE__,i); if (s[i]<0x20) {nostring=1;break;} + if (x==-1) TRACE("%d: i=%d\n",__LINE__,i); if (s[i]>=0x80) {nostring=1;break;} + if (x==-1) TRACE("%d: i=%d\n",__LINE__,i); i++; } if (!nostring) { --- cut here --- -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

July 23, 2001

Re: Microsoft source code releases - a danger to Wine?

by Bill Medland

Ian Pilcher <ian.pilcher(a)home.com> wrote in article <3B59F1DE.5010904(a)home.com>... > According to Slashdot, Microsoft has released the Windows CE source code > under one of their "shared source" licenses. Needless to say, it would > be an *extremely* bad idea for anyone associated with the Wine project > to look at it. I must admit that as a newcomer to the Wine project I would appreciate a little guidance on what are and are not valid methods for investigating Windows sufficiently to work on the Wine project. This cuts two ways: 1. What methods are accepted as legal for obtaining information and what methods must not be used (in order to protect Wine) 2. What methods are especially effective and what methods are a waste of time (in order to improve the learning curve for contributors) Should there be a section in the Wine Development HQ (Or is it already there and I missed it). Bill

July 23, 2001

Re: PATCH: msvcrt.ungetc

by Marcus Meissner

On Sun, Jul 22, 2001 at 03:40:24PM -0700, Alexandre Julliard wrote: > Marcus Meissner <marcus(a)jet.franken.de> writes: > > > --- include/msvcrt/stdio.h 2001/05/07 18:18:34 1.2 > > +++ include/msvcrt/stdio.h 2001/07/21 12:43:43 > > @@ -72,6 +72,7 @@ > > int _charbuf; > > int _bufsiz; > > char* _tmpfname; > > + int _ungetc; > > } MSVCRT(FILE); > > You cannot do that, the FILE structure has to remain binary > compatible. Hmm. Properly implementing would mean writing a complete stdio FILE* implementation, including buffer handling, which is currently too much work for me. Ciao, Marcus

July 23, 2001

Still problems with snoop

by Uwe Bonnes

Hallo, some days ago I reported early crashes when running with the snoop debug option. E.g. vc98 msedv.exe is a good example. Running with "+snoop" crashes early. Running with "-snoop=devshl" lets the program succeed much further. Running without snoop gets even substancial further. So I think there must be something wrong with snoop. I tried to look hard at relay32/snoop.c, but didn't see anything fishy. So perhaps somebody else has some idea what's going wrong. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 23, 2001

Re: PATCH: msvcrt.ungetc

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > --- include/msvcrt/stdio.h 2001/05/07 18:18:34 1.2 > +++ include/msvcrt/stdio.h 2001/07/21 12:43:43 > @@ -72,6 +72,7 @@ > int _charbuf; > int _bufsiz; > char* _tmpfname; > + int _ungetc; > } MSVCRT(FILE); You cannot do that, the FILE structure has to remain binary compatible. -- Alexandre Julliard julliard(a)winehq.com

July 22, 2001

Re: Microsoft source code releases - a danger to Wine?

by Ian Pilcher

Patrik Stridvall wrote: > >>Fair use? We don't need stinking fair use! After all, that might >>interfere with corporate earnings reports. (I'm too old to become a >>communist!) >> > > And favouring fair use have what to do with communism? > I was just joking about my growing disillusionment with the U.S. legal system. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

July 22, 2001

RE: Microsoft source code releases - a danger to Wine?

by Patrik Stridvall

> > Worse yet: If we coincidentally use similar code to theirs, > how can we > > prove we haven't looked at their code? If I were paranoid, > I'd say the > > single purpose of releasing the source was to get wine in trouble. > > It's not paranoia when they really are out to get you! Perhaps not, but do you really have proof that they are out to get you? :-) Seriously, I think you should calm down, getting to upset will do you no good. > IANAL, but distribution has been limited enough to this point > that they > would probably have to show some plausible manner in which > the exposure > could have occured. That's why I think wider distribution increases > the vigilance required. The burden of proof is still on Microsoft, not us.

July 22, 2001

RE: Microsoft source code releases - a danger to Wine?

by Patrik Stridvall

> There'a a legal doctrine whose name I can remember (I'm too young for > senior moments!) ... "inevitable contamination" or something It is call "inevitable disclosure" I think. > like that. > The basic idea is that someone who had been exposed to > Microsoft source > code and then worked on Wine within a given period of time would be > assumed to have used knowledge gained from that exposure. I believe > that the burden would be on that person or the Wine project to show > the opposite. For that person, perhaps. IIRC the doctrine of "inevitable disclosure" it on a little shaky ground as it is eventhough some Judges have use it so far, it is NOT 100% established doctrine. As far as the Wine project is concerned, you will have to stretch the doctrine pretty far since the Wine project can't possibly know what a patch submittor has done before unless he tells us himself. > This is what I'm really worried about. Some well-meaning hacker takes > "Advanced Operating System Theory" at a Microsoft-beholden university > and then makes a contribution to Wine. (The more I think about it, > I'm surprised Microsoft isn't trying harder to expose more people to > their code and license.) Sure, we probaly need to make others more aware of that, but that primarily concerns them, not us. > Fair use? We don't need stinking fair use! After all, that might > interfere with corporate earnings reports. (I'm too old to become a > communist!) And favouring fair use have what to do with communism? It is entirely possible to have a capitalistic society without Intellectuall Property (IP) at all or with very weak IP (strong fair use). > > That said, nothing I can see appears to restrict someone > who has accepted > > their license from answering explicit questions we might > have, so long as > > they are not doing so for hire (thus 'commercially'), and > so long as they > > don't distribute source code. A fair bit of useful > knowledge might be > > gained in that way, albeit slowly. > > > > > Now you're really scaring me! Why? Any violation is primarily their problem and extending derived work over a verbal description is stretching far to far. This has already been established by actual court case.

July 22, 2001

RE: Microsoft source code releases - a danger to Wine?

by Patrik Stridvall

> On Sat, 21 Jul 2001, Ian Pilcher wrote: > > > This leads me to wonder if anyone's ever thought of taking steps to > > protect Wine from "contamination" by Microsoft IP (legally, > not tech- > > nically :-). > > What can we do about that? Since none of the people involved > is going to > have a look at the actual M$ source, how are we supposed to know if a > patch posted on the list is taken from them? We can't and we don't have to. The burden of proof is on Microsoft. Of course it is a civil cases and the proof need only be on preponderence of evidence but it still their burden primarily. > Worse yet: If we coincidentally use similar code to theirs, how can we > prove we haven't looked at their code? If I were paranoid, I'd say the > single purpose of releasing the source was to get wine in trouble. First of all: We know who submitted a patch since that information is in the CVS log, so unless they can prove that Alexandre should have realized the person submitting the patch, submitted code not copyrighted by that person, the burden fall on that person and that person alone. If that person can't be identified through the e-mail adress to bad for Microsoft. If he can they will have to drag him to court, not the Wine project. Sure Microsoft probably can ask the Wine remove the offending code and sue us if we don't, but since we in fact also are a victim of the submitters misrepresentation I think any reasonable judge would: 1. Require that Microsoft prove that the code is theirs. This might be a little difficult without providing the actual code to the Wine project and requiring any developer of the Wine project to taint him self by signing a NDA with Microsoft would probably not required by the court. So the reasonable cause of action would for Microsoft to release the code without a license that could taint us or pay for an independent 3rd party to review and establish this. 2. Require that Microsoft provide a patch to remove the offending code from the current CVS. Note that we also are a victim so requiring more would probably be considered unreasonable. Why should we pay for (in money or effort) somebody elses crime or legal liabillity against Microsoft. All in all I think the Judge would be rather annoyed that Microsoft didn't try to solve this problem without him. In short, while IANAL, if Microsoft (or somebody) feels that some code in the CVS is copyrighted by them we should simple require that. 1. Prove it to us, without any risk of taint, or to some independent 3rd party at their expense. 2. Provide a patch against the current CVS that removes the offending code preferable made by the same 3rd party as above at their expense. 3. Require that the 3rd party sign a statement under perjury that the patch removes the offending code and only the offending code. Remember we are also a victim under such an event and requiring more would probably not be look on favourable by the courts.

July 22, 2001

Re: Microsoft source code releases - a danger to Wine?

by Ian Pilcher

Bernhard Rosenkraenzer wrote: > > What can we do about that? Since none of the people involved is going to > have a look at the actual M$ source, how are we supposed to know if a > patch posted on the list is taken from them? > Well, asking is a good start. I'm more concerned about a well meaning person doing something without realizing the consequences that I am about deliberate malfeasance. So making people think is the first step. > Worse yet: If we coincidentally use similar code to theirs, how can we > prove we haven't looked at their code? If I were paranoid, I'd say the > single purpose of releasing the source was to get wine in trouble. > It's not paranoia when they really are out to get you! IANAL, but distribution has been limited enough to this point that they would probably have to show some plausible manner in which the exposure could have occured. That's why I think wider distribution increases the vigilance required. > > That won't do much good, because e-mailed statements/forms aren't legally > binding. #include <fix-the-law.h> > Snail mail? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

July 22, 2001

Re: Microsoft source code releases - a danger to Wine?

by Ian Pilcher

Gavriel State wrote: > Well, first off, copyright law generally governs copying, not use. > Attempts to overreach the provisions of copyright law through additional > clauses in shrink-wrap/click-wrap and other contracts have been turned > aside in some court cases. In the US, federal copyright law trumps state > contract law, from what I've read. Thus, the license starts off on shaky > ground. > As you point out below, contract law is also involved. Add the DMCA, UCITA, and Bush 2.0 to the mix, and any lawyer who says he actually knows what's legal is lying. > > Again, the use issue rears its head. Another interesting question here is > the one of derivatives. It is possible that knowledge gained by study of > the source code, which is then applied to Wine, would not in and of itself > cause Wine to become a 'derived' work, assuming that no actual source code > was used. It is a somewhat grey area that I don't know very well, but > it may be worth investigating. > There'a a legal doctrine whose name I can remember (I'm too young for senior moments!) ... "inevitable contamination" or something like that. The basic idea is that someone who had been exposed to Microsoft source code and then worked on Wine within a given period of time would be assumed to have used knowledge gained from that exposure. I believe that the burden would be on that person or the Wine project to show the opposite. This is what I'm really worried about. Some well-meaning hacker takes "Advanced Operating System Theory" at a Microsoft-beholden university and then makes a contribution to Wine. (The more I think about it, I'm surprised Microsoft isn't trying harder to expose more people to their code and license.) > > Here again, we have the usage issue, as well as the platform-restrictive > clause for commercial users. The platform restrictions may constitute > anti-competitive 'copyright misuse', and thus be unenforceable. The > language used here is also interesting - they say 'reference', rather > than 'use'. I suspect that they are trying to explicitly restrict > efforts like Wine from even studying their code - an apparent violation > of 'fair use' provisions of copyright law. > Fair use? We don't need stinking fair use! After all, that might interfere with corporate earnings reports. (I'm too old to become a communist!) > > That said, nothing I can see appears to restrict someone who has accepted > their license from answering explicit questions we might have, so long as > they are not doing so for hire (thus 'commercially'), and so long as they > don't distribute source code. A fair bit of useful knowledge might be > gained in that way, albeit slowly. > Now you're really scaring me! > Anyhow, a useful link for anyone interested in more background on some > of the legal issues is: > http://www.richmond.edu/~jolt/v1i1/liberman.html > Good link, but dated. UCITA explicitly legitimizes most of the shrink- wrap and click-wrap license provisions that courts have previously found unenforceable. It'll be interesting to see if it dies a well deserved death, gains momentum, or (most likely) rears its hydra-like head in a different disguise a year or two down the road. IANAL, but I think that this is worth discussing. Thaks for the thoughtful response! (Anyone on this list know a good IP lawyer who's had an attack of conscience and wants to do some pro bono work?) -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

July 22, 2001

Re: Microsoft source code releases - a danger to Wine?

by Bernhard Rosenkraenzer

On Sat, 21 Jul 2001, Ian Pilcher wrote: > This leads me to wonder if anyone's ever thought of taking steps to > protect Wine from "contamination" by Microsoft IP (legally, not tech- > nically :-). What can we do about that? Since none of the people involved is going to have a look at the actual M$ source, how are we supposed to know if a patch posted on the list is taken from them? Worse yet: If we coincidentally use similar code to theirs, how can we prove we haven't looked at their code? If I were paranoid, I'd say the single purpose of releasing the source was to get wine in trouble. > I believe that the FSF uses some type of form/statement before they will > accept code, and it seems like the nature of this project would make it > particularly beneficial. That won't do much good, because e-mailed statements/forms aren't legally binding. #include <fix-the-law.h> LLAP bero

July 22, 2001

Re: Microsoft source code releases - a danger to Wine?

by Gavriel State

Ian Pilcher wrote: > > According to Slashdot, Microsoft has released the Windows CE source code > under one of their "shared source" licenses. Needless to say, it would > be an *extremely* bad idea for anyone associated with the Wine project > to look at it. While I agree that it is probably not a great idea to look at the CE code at this point, Microsoft's 'Shared Source' license is *very* interesting in a number of respects. First and foremost, the license is by far the most simple and straightforward software copyright license that I have ever seen. There is barely a hint of legalese about it. As such, it appears to me that there may be some interesting ways in which the license can be exploited to benefit Wine. 8-) Note that I'm not suggesting that anyone go out and do this without spending a fair bit of time (and money, unfortunately) with a lawyer. Certainly, no one at TransGaming is going to be downloading or looking at those sources. So - on to some analysis of the license. Everything below is based only on my own personal understanding of the legal issues involved, nothing more. This License governs use of the accompanying Software. Well, first off, copyright law generally governs copying, not use. Attempts to overreach the provisions of copyright law through additional clauses in shrink-wrap/click-wrap and other contracts have been turned aside in some court cases. In the US, federal copyright law trumps state contract law, from what I've read. Thus, the license starts off on shaky ground. You can use this Software for any non-commercial purpose, including distributing derivatives. Running your business operations would not be considered non-commercial. Again, the use issue rears its head. Another interesting question here is the one of derivatives. It is possible that knowledge gained by study of the source code, which is then applied to Wine, would not in and of itself cause Wine to become a 'derived' work, assuming that no actual source code was used. It is a somewhat grey area that I don't know very well, but it may be worth investigating. For commercial purposes, you can reference this software solely to assist in developing and testing your own software and hardware for the Windows CE platform. Here again, we have the usage issue, as well as the platform-restrictive clause for commercial users. The platform restrictions may constitute anti-competitive 'copyright misuse', and thus be unenforceable. The language used here is also interesting - they say 'reference', rather than 'use'. I suspect that they are trying to explicitly restrict efforts like Wine from even studying their code - an apparent violation of 'fair use' provisions of copyright law. The rest of the license is pretty straightforward with nothing that's too objectionable that I can see immediately. I won't bother going through it in detail. That said, nothing I can see appears to restrict someone who has accepted their license from answering explicit questions we might have, so long as they are not doing so for hire (thus 'commercially'), and so long as they don't distribute source code. A fair bit of useful knowledge might be gained in that way, albeit slowly. Anyhow, a useful link for anyone interested in more background on some of the legal issues is: http://www.richmond.edu/~jolt/v1i1/liberman.html Take care, -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

July 22, 2001

Proposed config file change

by Andreas Mohr

Hi all, I've been thinking for a rather long while now that the config file has a rather poor format. Several settings are pretty misplaced, and it tends to get chaotic. Let me just suggest something different: [COMM\\ParallelPorts] "Lpt1" = "..." "ppdev_378" = "..." [COMM\\SerialPorts] [COMM\\RASAPI] [COMM\\TAPI] [COMM\\WININET] [COMM\\WINSOCK] [DLLs\\Overrides] [File\\Drive x] [File\\General] "Windows" = "..." "System" = "..." "Temp" = "..." "Path" = "..." "ShowDirSymlinks" = "..." [File\\Registry] "LoadGlobalRegistryFiles" = "Y" "LoadHomeRegistryFiles" = "Y" "LoadWindowsRegistryFiles" = "Y" "WritetoHomeRegistryFiles" = "Y" "SaveOnlyUpdatedKeys" = "Y" "Profile" = "c:\\windows\\Profiles\\Administrator" [Graphics] "GraphicsDriver" = "x11drv" "WineLook" = "Win95" [Graphics\\DirectX] [Graphics\\Fonts] ;See a couple of examples for russian users below "Resolution" = "96" "Default" = "-adobe-helvetica-" "DefaultFixed" = "fixed" "DefaultSerif" = "-adobe-times-" "DefaultSansSerif" = "-adobe-helvetica-" [Graphics\\OpenGL] [Graphics\\Printing\\afmdirs] [Graphics\\Printing\\Spooler] "FILE:" = "tmp.ps" "LPT1:" = "|lpr" "LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -" "LPT3:" = "/dev/lp3" [Graphics\\Screen\\ttydrv] ;"Drivers" = "tty" ;"XtermProg" = "nxterm" ;"InitialRows" = "25" ;"InitialColumns" = "80" ;"TerminalType" = "nxterm" [Graphics\\Screen\\x11drv] ... [Sound\\DSOUND] "EmulatedDriver" = "..." [Sound\\WinMM] "Drivers" = "wineoss.drv" "WaveMapper" = "msacm.drv" "MidiMapper" = "midimap.drv" [wine] "ShellLinker" = "wineshelllink" [wine\\Clipboard] "ClearAllSelections" = "0" "PersistentSelection" = "1" [wine\\Ports] ;"read" = "0x779,0x379,0x280-0x2a0" ; "write" = "0x779,0x379,0x280-0x2a0" [wine\\Spy] "Exclude" = "WM_SIZE;WM_TIMER;" This has the advantage that it has a very basic structure (COMM, DLLs, File, Sound, Wine), and you always know where to start searching. I haven't spent much thought on whether it's really "right" and, most importantly, extensible, though. Comments ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

July 21, 2001

Re: glibc bug mmap/malloc

by Andreas Mohr

On Wed, Jul 18, 2001 at 02:00:36PM -0700, Alexandre Julliard wrote: > Andreas Mohr <a.mohr(a)mailto.de> writes: > > > I mean, come on: why did they bother to implement malloc() at all > > if the resulting architecture is THAT broken ? > > It's not broken, it just doesn't play well with programs like Wine > that muck around with the process address space. But it's a perfectly > reasonable (if not optimal) implementation for "normal" Unix apps. Hmm, ok. But even if we cease and desist, then we still have the problem of that hazardous malloc() in VIRTUAL_CreateView(), which makes loading of such big .exes fail. (and on *many* other places also) How to fix it ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

July 21, 2001

Microsoft source code releases - a danger to Wine?

by Ian Pilcher

According to Slashdot, Microsoft has released the Windows CE source code under one of their "shared source" licenses. Needless to say, it would be an *extremely* bad idea for anyone associated with the Wine project to look at it. This leads me to wonder if anyone's ever thought of taking steps to protect Wine from "contamination" by Microsoft IP (legally, not tech- nically :-). As the number of programmers who have been exposed to MS source code grows the chances of this happening will increase. I believe that the FSF uses some type of form/statement before they will accept code, and it seems like the nature of this project would make it particularly beneficial. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

July 21, 2001

Wine doesn't seem to like TrueType fonts.

by David Hagood

Has anybody else seen this behavior: I have a directory of TrueType fonts that I can point xfs to. When I have that directory in the fontlist, wine ALWAYS regenerates the font cache on every start (thus slowing Wine down immensely). Remove the TrueType directory from the font table, and all is well: Wine will regenerate the font cache once, and then use the font cache from there on.

July 21, 2001

Re: Marshaling

by richard.morgan9

Using the proxy/stub dlls that midl generates is one way for the implementors of custom interfaces to provide for marshalling. However, if the custom interface is OLE Automation compatible then the marshalling will be carried out by the OLE system itself, using the type library describing the interface (if the developer elects not to implement their own marshalling). I'm not sure how the existance of this "Type library marshalling" relates to the original question of out-of-process COM objects for an installer; it may be that it relies on this mechanism. Because type library marshalling doesn't require extra dlls or effort on the part of the developer, I think it is quite popular. ----- Original Message ----- From: "Daniel Walker" <diwalker(a)earthlink.net> To: <wine-devel(a)winehq.com> Sent: Saturday, July 21, 2001 3:01 AM Subject: Marshaling > > > From what I've read when someone creates a custom interface for COM, an > IDL file is generated, then the MIDL compiler uses the IDL file to > create proxy and stub code that works with the standard COM RPC > functionality.. So under some (most) circumstances wine's COM > implementation would only have to facilitate the sending and recieving > of the marshaled data .. > > Not to minimize the work involved .. The standard marshaling would have > to do all the generic COM interfaces like IUnknown, IStorage, IStream (I > think). Even though full implementations of those would be available . > But most components would have custom interfaces so they would also have > their own marshaling code .. > > If I'm 100% correct then , I guess, there wouldn't be a need for the > type information. Yet it exists .. Unless the type info is used for > something other than marshaling. > > Daniel Walker > >

July 21, 2001

Marshaling

by Daniel Walker

From what I've read when someone creates a custom interface for COM, an IDL file is generated, then the MIDL compiler uses the IDL file to create proxy and stub code that works with the standard COM RPC functionality.. So under some (most) circumstances wine's COM implementation would only have to facilitate the sending and recieving of the marshaled data .. Not to minimize the work involved .. The standard marshaling would have to do all the generic COM interfaces like IUnknown, IStorage, IStream (I think). Even though full implementations of those would be available . But most components would have custom interfaces so they would also have their own marshaling code .. If I'm 100% correct then , I guess, there wouldn't be a need for the type information. Yet it exists .. Unless the type info is used for something other than marshaling. Daniel Walker

July 21, 2001

Re: more misc fixes

by Francois Gouget

On Fri, 20 Jul 2001, Brandon Kilgore wrote: [...] > >Exactly; but note that in most cases the prototype is not even needed > >at all. I don't want all 16-bit C files to start with a bunch of > >prototypes either, this would just be unnecessary duplication; only > >the functions that are actually called from elsewhere in the file > >should be prototyped IMO. > > I don't understand....why would there be a function there that isn't called > from anywhere? It may never be called by Wine but still be called by Windows programs... especially for 16bit functions. And the .spec.c files have no use for prototypes anyway. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

July 20, 2001

Re: more misc fixes

by Brandon Kilgore

At 05:46 PM 7/19/01 -0700, Alexandre Julliard wrote: >Patrik Stridvall <ps(a)leissner.se> writes: > > > OK. So what you really what is exactly the opposite of what I tried to do? > >Yep ;-) > > > You want all 16-bit exported function prototypes moved from the .h > > files to the implementing .c file in all cases that is is possible (ie Wine > > compiles without errors or warnings)? > >Exactly; but note that in most cases the prototype is not even needed >at all. I don't want all 16-bit C files to start with a bunch of >prototypes either, this would just be unnecessary duplication; only >the functions that are actually called from elsewhere in the file >should be prototyped IMO. I don't understand....why would there be a function there that isn't called from anywhere? Shouldn't every function have a prototype either at the beginning of its C file, or in a header file? Otherwise, doesn't that mean it is not being used and can just be deleted? You only don't need a prototype if you're not calling it until after the actual function in the c file, right? i.e. void foo1() { ... } void foo2() { foo1(); } I must be missing something.... - Brandon

July 20, 2001

Re: UNC

by Travis Michielsen

--- Bill Medland <medbi01(a)accpac.com> wrote: > Is anyone doing anything on UNC filenames? (In particular I am interested > in GetFileAttributes) > Bill > If noone else is working on it (or wants to work on it) I can put it on my TODO list. - Travis Michielsen __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

July 20, 2001

Re: attempting to load mIRC32 5.91 using latest wine cvs

by mdew

On Thu, 19 Jul 2001 11:05:55 +0200 Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > >>>>> "mdew" == mdew <rpbrown(a)xtra.co.nz> writes: > > mdew> mdew(a)storm:~$ /usr/local/bin/wine fake_windows/mIRC/mirc32.exe > mdew> FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock > mdew> FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock > mdew> err:module:BUILTIN32_dlopen failed to load .so lib for builtin > mdew> x11drv.dll: /usr/lib/libwine_tsx11.so: undefined symbol: > mdew> XF86DGAGetViewPortSize Could not load graphics driver 'x11drv' > > Either get an newer X-Server with DGA capabilities, or configure and compile > on your system. i do...in fact, i downloaded an older version of wine (20010510) which works fine... Im running Debian Sid which comes with XFree86 4.0.3 and using the Nvidia openGL drivers.. dga works in all apps i use (mplayer, quake3, MAME) just not the latest cvs of wine.

July 20, 2001

Re: COMM16: use overlapped I/O not service thread

by lawson_whitney＠juno.com

On Fri, 20 Jul 2001, Mike McCormack wrote: > > Hi, > > i've tested this patch a little... with wfw3.1 terminal, i can type AT > and receive OK from my modem, but i'm not supremely confident about > it. If somebody :-) could test it and review it a bit i'd be > grateful... > > Mike > > ChangeLog: > Replace service thread with ReadFileEx/WriteFileEx for COMM16. > > So as not to damn it with faint praise, my 16 bit app sent a response, and received 0 messages successfully. I _think_ it is OK, there shouldn't have been any messages for it to receive. Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

July 20, 2001

Re: COMM16: use overlapped I/O not service thread

by lawson_whitney＠juno.com

On Fri, 20 Jul 2001 12:33:23 +1000 Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a multi-part message in MIME format > > ------=_NextPart_000_53222353 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > > Hi, > > i've tested this patch a little... with wfw3.1 terminal, i can type > AT > and receive OK from my modem, but i'm not supremely confident about > it. If somebody :-) could test it and review it a bit i'd be > grateful... > > Mike > > ChangeLog: > Replace service thread with ReadFileEx/WriteFileEx for COMM16. > > If you get this, my 16 bit comms app can at least send mail with your patch. It aint much, but it is a bit more than terminal.exe talking to a modem. Lawson --- Somebody, somebody has to, you see, So she picked out two somebodies, Sally and me. - T.S.G. ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

July 20, 2001

Re: more misc fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > OK. So what you really what is exactly the opposite of what I tried to do? Yep ;-) > You want all 16-bit exported function prototypes moved from the .h > files to the implementing .c file in all cases that is is possible (ie Wine > compiles without errors or warnings)? Exactly; but note that in most cases the prototype is not even needed at all. I don't want all 16-bit C files to start with a bunch of prototypes either, this would just be unnecessary duplication; only the functions that are actually called from elsewhere in the file should be prototyped IMO. > Do you also want the types and structures moved as well? > That will often not be possible, but do you want it > despite this in the cases where it is possible? Wherever possible it would be a good thing yes. -- Alexandre Julliard julliard(a)winehq.com

July 20, 2001

RE: more misc fixes

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Ah. You are right, I orginally meant to add it in a > > different file (wine/obj_base16.h perhaps) but I didn't > > think it would matter since other 16 bit interface like > > IStream16 and IStorage16 is in wine/obj_*.h already. > > Perhaps they should be move out as well? > > > > If so to where? wine/obj_*16.h or perhaps the DLLs > directories if possible? > > The DLL directories definitely; and if possible in the .c file where > they are needed, to make it clear they must not be used from the > outside. Ah, yes. The implementing .c file, thats an idea. Like in dlls/lzexpand/lzexpand_main.c, I guess you mean? > > In addition (as I hinted in 5.) requiring all non-static functions > > to have a .h file declaration is good policy for any application > > including Wine. Hint, if a function isn't static somebody else > > should use it otherwise some else is wrong, ie it really should > > be static after all. > > All 16-bit API functions must be treated as if they were static. Well we could actually make them truely static with a little trickery and a corrensponding change of winebuild. Idea: #define DECLARE_ENTRY_POINT16(module, function) \ void *module##_p##function = (void *) &function /* After the includes */ static void Foo(void *, int); DECLARE_ENTRY_POINT16(BAR, Foo); /* ... */ static void Foo(void *, int) { /* ... */ } It is probably not worth the trouble though. > They > cannot be because of the spec file reference, but ideally no code > should ever call a 16-bit API, it should use the corresponding 32-bit > API. Adding prototypes and a header file is only going to encourage > using these functions which is not what we want. OK. So what you really what is exactly the opposite of what I tried to do? You want all 16-bit exported function prototypes moved from the .h files to the implementing .c file in all cases that is is possible (ie Wine compiles without errors or warnings)? Do you also want the types and structures moved as well? That will often not be possible, but do you want it despite this in the cases where it is possible?

July 19, 2001

UNC

by Bill Medland

Is anyone doing anything on UNC filenames? (In particular I am interested in GetFileAttributes) Bill

July 19, 2001

RE: Lots of #defines OK?

by Brandon Kilgore

At 11:32 PM 7/19/01 +0200, Patrik Stridvall wrote: > > Patrik Stridvall wrote: > > > Not really, but as an alternative solution you could has a structure > > > instead of an array like: > > > > > > typedef struct { > > > GLYPHNAME A; > > > GLYPHNAME AE; > > > GLYPHNAME AEacute; > > > GLYPHNAME AEsmall; > > > /* ... */ > > > } GLYPHNAMES; > > > > > > Perhaps this is better since it doesn't use the preprocessor. > > > > I not thought of that -- neat idea. What is the downside of using the > > preprocessor, however? > >Well, the preprocessor "pollutes" the namespace in a way that is >sometimes bad and my solution gives IMHO a slightly nicer syntax. Yeah, this is true that preprocessor directives "pollute." In this case, though, I agree with both of you that it is an acceptable solution. It actually takes advantage of preprocessing in that it takes the work load off of run-time creation of a dynamic table and puts it on the compiler so it only has to be done once. They're often overused, but they can be helpful in some cases. - Brandon

July 19, 2001

RE: Lots of #defines OK?

by Patrik Stridvall

> Patrik Stridvall wrote: > > Not really, but as an alternative solution you could has a structure > > instead of an array like: > > > > typedef struct { > > GLYPHNAME A; > > GLYPHNAME AE; > > GLYPHNAME AEacute; > > GLYPHNAME AEsmall; > > /* ... */ > > } GLYPHNAMES; > > > > Perhaps this is better since it doesn't use the preprocessor. > > I not thought of that -- neat idea. What is the downside of using the > preprocessor, however? Well, the preprocessor "pollutes" the namespace in a way that is sometimes bad and my solution gives IMHO a slightly nicer syntax. Is this case in don't think it matters so much though, your orginal solution is fine, in fact is the standard solution in C to the problem you have AFAIK. My suggestion is really just brainstorming to give you hopefully a different perspective of the issue. Also note that your solution is not possible with languages that don't have pointer aritmetics that C, fortunately or unluckily depending on how you see it, have.

July 19, 2001

Re: more misc fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > Ah. You are right, I orginally meant to add it in a > different file (wine/obj_base16.h perhaps) but I didn't > think it would matter since other 16 bit interface like > IStream16 and IStorage16 is in wine/obj_*.h already. > Perhaps they should be move out as well? > > If so to where? wine/obj_*16.h or perhaps the DLLs directories if possible? The DLL directories definitely; and if possible in the .c file where they are needed, to make it clear they must not be used from the outside. > In addition (as I hinted in 5.) requiring all non-static functions > to have a .h file declaration is good policy for any application > including Wine. Hint, if a function isn't static somebody else > should use it otherwise some else is wrong, ie it really should > be static after all. All 16-bit API functions must be treated as if they were static. They cannot be because of the spec file reference, but ideally no code should ever call a 16-bit API, it should use the corresponding 32-bit API. Adding prototypes and a header file is only going to encourage using these functions which is not what we want. -- Alexandre Julliard julliard(a)winehq.com

July 19, 2001

RE: more misc fixes

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Index: wine/include/wine/obj_base.h > > =================================================================== > > RCS file: /home/wine/wine/include/wine/obj_base.h,v > > retrieving revision 1.40 > > diff -u -u -r1.40 obj_base.h > > --- wine/include/wine/obj_base.h 2001/05/07 18:15:40 1.40 > > +++ wine/include/wine/obj_base.h 2001/07/19 14:50:28 > > @@ -34,6 +34,8 @@ > > #include "wtypes.h" > > #include "guiddef.h" > > > > +#include "wine/windef16.h" > > This is wrong; Win32 header files must not include 16-bit ones. Ah. You are right, I orginally meant to add it in a different file (wine/obj_base16.h perhaps) but I didn't think it would matter since other 16 bit interface like IStream16 and IStorage16 is in wine/obj_*.h already. Perhaps they should be move out as well? If so to where? wine/obj_*16.h or perhaps the DLLs directories if possible? > Also please avoid adding more 16-bit headers in include/wine, there > are already too many of them. Well that was the idea at first but at least of the new ones are was needed in more that one directory some I ended up adding all of them there. But sure I can move the ones that are not use in more of one directory to that directory, I'm just a little worried that since the wine/*16.h header are 16-bit "mirrors" of the corresponding 32-bit files that functions from other DLLs happends to end up there as well. Microsoft seems have mixed headers and DLLs without much thought especially as far as OLE is concerned. Sure we can have several .h files with the same name in different DLL directories as far as functions are concerned since 16-bit functions shouldn't call across different DLLs anyway, but duplicating types and such are not a very good idea. But sure I can examine the files more carefully and see if it is possible and of course we can add it to a DLL directory first and then move it to include/wine if is because nessary in the future. > These headers (when they are really > necessary) belong in their respective dll directory. And BTW your new > lzexpand16.h is an example of a header file that is *not* necessary. Nessary for compiling Wine no, clearly not since it already compiles. However IMO all exported functions whether they are 16-bit or 32-bit and whether they are actually uses by other files or not should have declarations in some header file. For 32-bit it must obviously be so because of Winelib. The undocumented functions is of course not strictly nessary but I see not reason not to have them as a Wine extension that can be ported to Windows eventually in order to have the same source on both Unix and Windows. For 16-bit is seems that you disagree. Well, the advantages that I can think of for doing it for 16-bit as well is the following. 1. It makes it much easier for developer to add calls across files between 16-bit functions or move functions between files if the infrastructure is alreay in place. 2. It makes it possible to see related 16-bit functions together in a .h file instead of having to search the .c files. 3. It makes it possible go through each 16-bit .h file compare it with Windows and add the missing functions in the .h files and when somebody in the future runs winapi_check (or whatever) it is possible to present a list of what is not yet implemented. Sure the .spec contains that information as well in some meaning but it misses which functions that are actually listed in the 16-bit header files and thus likely to actually be used by real applications. 4. Since some of the 16-bit exported functions must be declared in some .h since it is used in some of file than it was declared, it is be much easier to require all 16-bit export function to be declared since it is difficult to tell which that are (or will be) really needed. 5. There is nothing unreasonable to require every non-static function let alone functions that are exported by either Win16 or Win32 to have a declaration in some .h files. Indeed tools like lint (at least on Solaris) have flags to check for this. In short trying to only add the 16-bit functions that are stricly nessary to .h files is more trouble than it is worth, especially compare to the advantages that having all of them .h files. In addition (as I hinted in 5.) requiring all non-static functions to have a .h file declaration is good policy for any application including Wine. Hint, if a function isn't static somebody else should use it otherwise some else is wrong, ie it really should be static after all. But OK. You think that there are too many 16-bit files in include/wine. No problem. I will try to avoid it if at all possible.

July 19, 2001

Re: CoGetClassObject

by Dan Kegel

"richard.morgan9" wrote: > > I think the book you guys are talking about is "Inside OLE", > > Microsoft Press, by Kraig Brockschmidt. Available for free in > > CD version of MSDN, not sure about online. Other books to check > > out are "Inside COM" from MS Press (not sure the author), > > and "Programming Applications for Windows" by Richter goes > > into some of the messy stuff involving thread, processes, etc.. > > The only description I've seen of how COM is actually > implemented by Microsoft apart from msj articles is in > Don Box's book "Essential COM" (possibly the self- > same articles reprinted in his book), which I found to > be the most informative book on the subject. Another interesting book is "COM IDL & Interface Design" by Al Major. It goes into great detail about how type libraries and marshalling work. http://www.amazon.com/exec/obidos/ASIN/1861002254 One of the amazon reviews calls it "god's gift to those who --pay attention, please-- want to achieve an in-depth understanding of the marshalling issues as applied to MS COM." - Dan

July 19, 2001

Re: CoGetClassObject

by richard.morgan9

The only description I've seen of how COM is actually implemented by Microsoft apart from msj articles is in Don Box's book "Essential COM" (possibly the self- same articles reprinted in his book), which I found to be the most informative book on the subject. Inside COM by Dale Rogerson is mistitled, IMO, as it is simply a description of how to write COM clients/ servers. ----- Original Message ----- From: "James Hatheway" <james(a)macadamian.com> To: <wine-devel(a)winehq.com> Sent: Thursday, July 19, 2001 7:45 PM Subject: Re: CoGetClassObject > > > Where is that, the Introduction to OLE? > > > > It was part of the MSDN Library or available as a book. Dunno where it got to. > > (Check msdn.microsoft.com) > > I think the book you guys are talking about is "Inside OLE", > Microsoft Press, by Kraig Brockschmidt. Available for free in > CD version of MSDN, not sure about online. Other books to check > out are "Inside COM" from MS Press (not sure the author), > and "Programming Applications for Windows" by Richter goes > into some of the messy stuff involving thread, processes, etc.. > > > -James > -- > James Hatheway > james(a)macadamian.com ~ http://www.macadamian.com > Software Designer - Macadamian Technologies, Inc. > "Software solutions for leading ISVs and e-Business" > > >

July 19, 2001

Re: CoGetClassObject

by Daniel Walker

Ove Kaaven wrote: > > On Thu, 19 Jul 2001, Daniel Walker wrote: > > > 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?) > > I'm working on it. In my tree, CoGetClassObject successfully launches > ikernel.exe and establishes an IPC connection to it, and queries it for > the CLSID that installshield wants. That works fine, but that's just the > easy part. Currently the service process (ikernel.exe) can't yet send a > reply, since interface marshalling is not quite implemented yet... > and I'm not entirely sure how typelibs work yet, and how to retrieve the > typelib info for a CLSID. I had to use a separate "ikernel.tlb" to get Wine to read the type information. It couldn't get it from the ikernel.exe because I think it's encoded somehow (unicode, MultiByte??). It doesn't have the magic MSFT as the first four bytes.. Wine seems to read all the type information correctly .. So then in CoGetClassObject you would create and return a dummy object that would act like the actual interface the program is looking for. Then the dummy object would accept parameters, do the marshaling, and make the IPC request to the Local Server? Daniel Walker

July 19, 2001

Re: CoGetClassObject

by James Hatheway

> > Where is that, the Introduction to OLE? > > It was part of the MSDN Library or available as a book. Dunno where it got to. > (Check msdn.microsoft.com) I think the book you guys are talking about is "Inside OLE", Microsoft Press, by Kraig Brockschmidt. Available for free in CD version of MSDN, not sure about online. Other books to check out are "Inside COM" from MS Press (not sure the author), and "Programming Applications for Windows" by Richter goes into some of the messy stuff involving thread, processes, etc.. -James -- James Hatheway james(a)macadamian.com ~ http://www.macadamian.com Software Designer - Macadamian Technologies, Inc. "Software solutions for leading ISVs and e-Business"

July 19, 2001

Re: more misc fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > Index: wine/include/wine/obj_base.h > =================================================================== > RCS file: /home/wine/wine/include/wine/obj_base.h,v > retrieving revision 1.40 > diff -u -u -r1.40 obj_base.h > --- wine/include/wine/obj_base.h 2001/05/07 18:15:40 1.40 > +++ wine/include/wine/obj_base.h 2001/07/19 14:50:28 > @@ -34,6 +34,8 @@ > #include "wtypes.h" > #include "guiddef.h" > > +#include "wine/windef16.h" This is wrong; Win32 header files must not include 16-bit ones. Also please avoid adding more 16-bit headers in include/wine, there are already too many of them. These headers (when they are really necessary) belong in their respective dll directory. And BTW your new lzexpand16.h is an example of a header file that is *not* necessary. -- Alexandre Julliard julliard(a)winehq.com

July 19, 2001

Re: CoGetClassObject

by Ove Kaaven

On Thu, 19 Jul 2001, Daniel Walker wrote: > 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?) I'm working on it. In my tree, CoGetClassObject successfully launches ikernel.exe and establishes an IPC connection to it, and queries it for the CLSID that installshield wants. That works fine, but that's just the easy part. Currently the service process (ikernel.exe) can't yet send a reply, since interface marshalling is not quite implemented yet... and I'm not entirely sure how typelibs work yet, and how to retrieve the typelib info for a CLSID. > 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?) .. Not necessarily. > 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? No. There's no reason to share memory either, we're supposed to do it like Windows does it and it doesn't share memory. It uses proxy objects, created by marshalling the interface across. > 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? I don't know how you're going to get that to work, CoRegisterClassObject needs pointers to application structures, which only ikernel.exe's startup code knows. And you probably *still* won't be able to load it into the same address space as the installer, for reasons known to everyone that eagerly awaited the big Address Space Separation.

July 19, 2001

Re: Lots of #defines OK?

by Ian Pilcher

Patrik Stridvall wrote: > > Not really, but as an alternative solution you could has a structure > instead of an array like: > > typedef struct { > GLYPHNAME A; > GLYPHNAME AE; > GLYPHNAME AEacute; > GLYPHNAME AEsmall; > /* ... */ > } GLYPHNAMES; > > Perhaps this is better since it doesn't use the preprocessor. I not thought of that -- neat idea. What is the downside of using the preprocessor, however? > > However I'm not sure if all C compilers supports 1258 structure members. > Another possible problem is alignment on some platforms if you must > be able for iterate over it and use it as and array. Of course > you can simply have a seperate array of pointers like: > I do need to iterate through it at one point. In fact I iterate through the array of names to create just such an array of pointers. The array may grow, however, so it has to be created dynamically. (I suppose I could start with a predefined array, copy it to the heap, and grow it there, but that seems inelegant and wasteful somehow.) Thanks for your feedback! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

July 19, 2001

RE: Lots of #defines OK?

by Patrik Stridvall

> I would like to get rid of the "hardcoded" offset into the glyph name > array and replace it with a macro ('GN_exclam', for example). > Each font > data file could then simply include a header that gets > regenerated when- > ever the glyphlist is changed -- eliminating the current > requirement to > regenerate all the font data. > > Anyone see any problems with this? (There are currently 1258 built-in > glyph names.) Not really, but as an alternative solution you could has a structure instead of an array like: typedef struct { GLYPHNAME A; GLYPHNAME AE; GLYPHNAME AEacute; GLYPHNAME AEsmall; /* ... */ } GLYPHNAMES; Perhaps this is better since it doesn't use the preprocessor. However I'm not sure if all C compilers supports 1258 structure members. Another possible problem is alignment on some platforms if you must be able for iterate over it and use it as and array. Of course you can simply have a seperate array of pointers like: GLYPHNAMES glyphnames = { /* ... */ }; GLYPHNAME *pGlyphnames[] = { &glyphnames.A; &glyphnames.AE; &glyphnames.AEacute; &glyphnames.AEsmall; /* ... */ };

July 19, 2001

Re: CoGetClassObject

by Marcus Meissner

On Thu, Jul 19, 2001 at 08:40:25AM -0700, Daniel Walker wrote: > Marcus Meissner wrote: > > > Please read the Introduction to OLE , especially the messy and very hard > > understandable parts on Proxies and Stubs and Marshalling. > > > > This is what is basically needed to implement :/ > > Where is that, the Introduction to OLE? It was part of the MSDN Library or available as a book. Dunno where it got to. (Check msdn.microsoft.com) > Maybe this is laughable , but it seems like we should be able to > eliminate the Marshaling since we're dealing with something that is > effectively a DLL .. Maybe I'm misguided in thinking that it's > "effectively a DLL" ? No, we need an extra process. The 'Dll only' approach is an 'in-process' server, these already work. Ciao, Marcus

July 19, 2001

Re: CoGetClassObject

by Daniel Walker

Marcus Meissner wrote: > Please read the Introduction to OLE , especially the messy and very hard > understandable parts on Proxies and Stubs and Marshalling. > > This is what is basically needed to implement :/ Where is that, the Introduction to OLE? Maybe this is laughable , but it seems like we should be able to eliminate the Marshaling since we're dealing with something that is effectively a DLL .. Maybe I'm misguided in thinking that it's "effectively a DLL" ? Daniel Walker

July 19, 2001

CoGetClassObject

by Daniel Walker

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

July 19, 2001

Lots of #defines OK?

by Ian Pilcher

I'm giving some thought to cleaning up the data structures used by the PostScript driver. Any significant change here will require that the glyph list and font data be regenerated. This is not particularly difficult, but it would be easier if I could remove the dependency of the font data on the glyph name array. Each glyph's metrics include a pointer to its name, and all of the built-in glyph names are in a single array named PSDRV_AGLGlyphNames (in dlls/wineps/data/agl.c). So the metrics for a glyph look like this: { 33, 0x0021, 600, PSDRV_AGLGlyphNames + 907, { 236, -15, 364, 572 }, NULL /* exclam */ } I would like to get rid of the "hardcoded" offset into the glyph name array and replace it with a macro ('GN_exclam', for example). Each font data file could then simply include a header that gets regenerated when- ever the glyphlist is changed -- eliminating the current requirement to regenerate all the font data. Anyone see any problems with this? (There are currently 1258 built-in glyph names.) Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

July 19, 2001

Re: CoGetClassObject

by Marcus Meissner

> 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.. Please read the Introduction to OLE , especially the messy and very hard understandable parts on Proxies and Stubs and Marshalling. This is what is basically needed to implement :/ Ciao, Marcus

July 19, 2001

Re: attempting to load mIRC32 5.91 using latest wine cvs

by Uwe Bonnes

>>>>> "mdew" == mdew <rpbrown(a)xtra.co.nz> writes: mdew> mdew(a)storm:~$ /usr/local/bin/wine fake_windows/mIRC/mirc32.exe mdew> FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock mdew> FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock mdew> err:module:BUILTIN32_dlopen failed to load .so lib for builtin mdew> x11drv.dll: /usr/lib/libwine_tsx11.so: undefined symbol: mdew> XF86DGAGetViewPortSize Could not load graphics driver 'x11drv' Either get an newer X-Server with DGA capabilities, or configure and compile on your system. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 19, 2001

attempting to load mIRC32 5.91 using latest wine cvs

by mdew

mdew(a)storm:~$ /usr/local/bin/wine fake_windows/mIRC/mirc32.exe FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/lib/libwine_tsx11.so: undefined symbol: XF86DGAGetViewPortSize Could not load graphics driver 'x11drv' err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found fixme:console:SetConsoleCtrlHandler (0x546e60,1) - no error checking or testing yet FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/lib/libwine_tsx11.so: undefined symbol: XF86DGAGetViewPortSize Could not load graphics driver 'x11drv' FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/lib/libwine_tsx11.so: undefined symbol: XF86DGAGetViewPortSize Could not load graphics driver 'x11drv' err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! spews this message out many times (then quits)..., using the same wine config ..as always.. Using Debian Sid x86 (gcc-2.95.4-XFree86-4.0.3)

July 19, 2001

Re: glibc bug mmap/malloc

by Gerard Patel

At 10:15 PM 18/07/2001 +0200, you wrote: <snip about glibc> >> > This is a BUG. While this glibc question is slightly offtopic here, I think that maybe a few people on this list could be interested in glibc, since the subject comes back on a regular basis... the following web page : http://sources.redhat.com/glibc is definitely the place to go. I feel that maybe this information could help someone, since I have wasted more than one hour searching www.gnu.org for the glibc mailing list archive :-) Also http://www.suse.de/~aj/Projects.html#glibc where it's said that Andrea Jaeger is responsible for glibc bug reports. Reading the archive gives me the impression that the whole glibc is written by no more than half a dozen programmers, btw. What's more, I have also the impression that these few are not even contributing full time to glibc :-/ Gerard

July 19, 2001

Re: Problem with 'GetPrivateProfileString'

by Brandon Kilgore

At 01:07 AM 7/19/01 +0200, Lionel Ulmer wrote >pAppName >[in] Pointer to a null-terminated string that specifies the name of the > section containing the key name. If this parameter is NULL, the > GetPrivateProfileString function copies all section names in the > file to the > supplied buffer. > >lpKeyName >[in] Pointer to the null-terminated string specifying the name of the key > whose associated string is to be retrieved. If this parameter is > NULL, all > key names in the section specified by the lpAppName parameter are > copied to > the buffer specified by the lpReturnedString parameter. so if lpAppName is NULL, it's supposed to copy all section names, and if lpKeyName is NULL, it copesi all key names in lpAppName section...maybe someone wasn't sure what to do if they were both NULL? It seems like as long as lpAppName is NULL, it doesn't really matter what lpKeyName is, right? If that is so, IMHO the code should reflect these rules by ordering the code so that you check AppName for NULL, and if it isn't, THEN you check KeyName for NULL. - Brandon

July 18, 2001

Problem with 'GetPrivateProfileString'

by Lionel Ulmer

Hi all, I have an installer crashing in 'GetPrivateProfileString' because of an NULL section pointer : 3 0x40076161 (GetPrivateProfileStringA+0x31(section=0x0, entry=0x40391efc, def_val=0x4039a394, buffer=0x403b0410, len=0x3e7, filename=0x4039a4e8) [profile.c:1232] in libntdll.so) (ebp=40586748) When looking at the code, there is the following comment (and code) : /* * undoc_feature means: * return section names string list if both section and entry are NULL. */ (...) if ((undoc_feature) && (section == NULL) && (entry == NULL)) /* undocumented; both section and entry are NULL */ But if I look at the entry for 'GetPrivateProfileString' in the MSDN, I get this : pAppName [in] Pointer to a null-terminated string that specifies the name of the section containing the key name. If this parameter is NULL, the GetPrivateProfileString function copies all section names in the file to the supplied buffer. lpKeyName [in] Pointer to the null-terminated string specifying the name of the key whose associated string is to be retrieved. If this parameter is NULL, all key names in the section specified by the lpAppName parameter are copied to the buffer specified by the lpReturnedString parameter. This is not in sync. with what Wine does.... It seems that only pAppName needs to be NULL to return a section name list. And there is another behaviour not done by Wine yet : copy all the keys of a section to the output buffer. So who is the author of this 'undocumented' feature in the Wine code ? Do you all agree that I should code it according to the (now) documented feature ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 18, 2001

Re: glibc bug mmap/malloc

by Alexandre Julliard

Andreas Mohr <a.mohr(a)mailto.de> writes: > I mean, come on: why did they bother to implement malloc() at all > if the resulting architecture is THAT broken ? It's not broken, it just doesn't play well with programs like Wine that muck around with the process address space. But it's a perfectly reasonable (if not optimal) implementation for "normal" Unix apps. -- Alexandre Julliard julliard(a)winehq.com

July 18, 2001

Re: glibc bug mmap/malloc

by Andreas Mohr

On Wed, Jul 18, 2001 at 11:40:37AM -0700, Alexandre Julliard wrote: > Andreas Mohr <a.mohr(a)mailto.de> writes: > > > You can clearly see that malloc() is able to squeeze up to 10232 bytes > > into the memory range just before the mmap()ed area, but when it gets > > slightly larger, it is NOT capable of switching to an entirely different > > memory area, throws its arms up in desperation and simply returns a shabby > > NULL. > > It only uses a new memory area in case the values get *much* larger, > > i.e. at least 131060 bytes. > > > > This is a BUG. > > (IMHO) > > What else should it be ? > > This is more a limitation of the malloc implementation than an actual > bug. malloc uses brk() to allocate memory, but brk() cannot grow past > an mmapped area, so malloc fails. With a standard Linux app shared > libraries are mapped high in memory (usually from 0x40000000) so the > malloc limit is about 1Gb; but if stuff is mapped lower, malloc > capacity is reduced. The reason it works for mallocs larger than 128Kb > is that glibc uses anonymous mmaps to reserve space for these instead > of brk(). Ah, this is exactly what I was silently afraid of. That it's not a bug, but simple braindamage. (ok, admittedly it's not as easy as that, but still...) After all we're talking about libc, which is used by bazillions of programs, so you could bet at least someone has noticed earlier and fixed bugs already, which is why it's very likely that more or less only "features" remain. > All in all, it's probably one more good reason for avoiding malloc in > Wine. Somehow I can't get rid of the feeling that there's missing a "very" or a "very much" at least *somewhere* in this sentence. I mean, come on: why did they bother to implement malloc() at all if the resulting architecture is THAT broken ? Nobody with their minds in right shape would ever use it then, right ? Get rid of it, period. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Microsoft Windows: Made for the Internet The Internet: Made for Unix

July 18, 2001

Re: Reaktivate

by Brandon Kilgore

At 12:34 PM 7/18/01 -0700, Daniel Walker wrote: >Brandon Kilgore wrote: > > Yeah, an OCX is an OLE Custom Control, or an AcitveX control. They're > > often used to allow Visual Basic programs to have access to controls > > written for C++, but they have many other uses. For instance, a Visual > > Basic program that wants to do standard Winsock programming can use the > > Microsoft Winsock ActiveX control to have an abstract interface into > > Winsock. It's kind of like a class, that gets packaged into a file (OCX) > > that gets used at run-time. I don't know why the didn't just use a DLL > > instead of an OCX... > > How is ActiveX related to COM/DCOM ? Would the reaktivate code be >useful in implementing all those COM related ole32 functions? > > Daniel The Only thing I know about the relationship is that ActiveX is one of the technologies built on top of COM. - Brandon

July 18, 2001

Re: Reaktivate

by Daniel Walker

Brandon Kilgore wrote: > Yeah, an OCX is an OLE Custom Control, or an AcitveX control. They're > often used to allow Visual Basic programs to have access to controls > written for C++, but they have many other uses. For instance, a Visual > Basic program that wants to do standard Winsock programming can use the > Microsoft Winsock ActiveX control to have an abstract interface into > Winsock. It's kind of like a class, that gets packaged into a file (OCX) > that gets used at run-time. I don't know why the didn't just use a DLL > instead of an OCX... How is ActiveX related to COM/DCOM ? Would the reaktivate code be useful in implementing all those COM related ole32 functions? Daniel

July 18, 2001

Re: Reaktivate

by Brandon Kilgore

At 12:18 PM 7/18/01 -0700, Daniel Walker wrote: >Marcus Meissner wrote: > > > > On Wed, Jul 18, 2001 at 11:35:43AM -0700, Daniel Walker wrote: > > > Are the reaktivate patches going to be put in the CVS eventually? > > > > Some of them are, the rest probably will be. > > Some parts can't be merged, notably the URLMON implementation, which is > > in C++ and uses KIO for http transfers. > > I just meant the patches specifically meant for wine. There's a >director in their CVS called "Patches-For-Wine" or something like that . >The rest of it looks useful too though. > > What's the OCX stuff? I remember the current windows help uses > and OCX >file? Is that some kind of ActiveX related control? > > Daniel Yeah, an OCX is an OLE Custom Control, or an AcitveX control. They're often used to allow Visual Basic programs to have access to controls written for C++, but they have many other uses. For instance, a Visual Basic program that wants to do standard Winsock programming can use the Microsoft Winsock ActiveX control to have an abstract interface into Winsock. It's kind of like a class, that gets packaged into a file (OCX) that gets used at run-time. I don't know why the didn't just use a DLL instead of an OCX... - Brandon

July 18, 2001

Re: Reaktivate

by Daniel Walker

Marcus Meissner wrote: > > On Wed, Jul 18, 2001 at 11:35:43AM -0700, Daniel Walker wrote: > > Are the reaktivate patches going to be put in the CVS eventually? > > Some of them are, the rest probably will be. > Some parts can't be merged, notably the URLMON implementation, which is > in C++ and uses KIO for http transfers. I just meant the patches specifically meant for wine. There's a director in their CVS called "Patches-For-Wine" or something like that . The rest of it looks useful too though. What's the OCX stuff? I remember the current windows help uses and OCX file? Is that some kind of ActiveX related control? Daniel

July 18, 2001

Re: glibc bug mmap/malloc

by Alexandre Julliard

Andreas Mohr <a.mohr(a)mailto.de> writes: > You can clearly see that malloc() is able to squeeze up to 10232 bytes > into the memory range just before the mmap()ed area, but when it gets > slightly larger, it is NOT capable of switching to an entirely different > memory area, throws its arms up in desperation and simply returns a shabby > NULL. > It only uses a new memory area in case the values get *much* larger, > i.e. at least 131060 bytes. > > This is a BUG. > (IMHO) > What else should it be ? This is more a limitation of the malloc implementation than an actual bug. malloc uses brk() to allocate memory, but brk() cannot grow past an mmapped area, so malloc fails. With a standard Linux app shared libraries are mapped high in memory (usually from 0x40000000) so the malloc limit is about 1Gb; but if stuff is mapped lower, malloc capacity is reduced. The reason it works for mallocs larger than 128Kb is that glibc uses anonymous mmaps to reserve space for these instead of brk(). All in all, it's probably one more good reason for avoiding malloc in Wine. -- Alexandre Julliard julliard(a)winehq.com

July 18, 2001

Reaktivate

by Daniel Walker

Are the reaktivate patches going to be put in the CVS eventually? Daniel Walker

July 18, 2001

Re: Reaktivate

by Marcus Meissner

On Wed, Jul 18, 2001 at 11:35:43AM -0700, Daniel Walker wrote: > Are the reaktivate patches going to be put in the CVS eventually? Some of them are, the rest probably will be. Some parts can't be merged, notably the URLMON implementation, which is in C++ and uses KIO for http transfers. Ciao, Marcus

July 18, 2001

Re: use GetCommState16 to save state in OpenComm16

by Marcus Meissner

On Wed, Jul 18, 2001 at 11:49:16AM -0400, lawson_whitney(a)juno.com wrote: > > > On Wed, 18 Jul 2001, Mike McCormack wrote: > > > > > with this patch, all use of unix fds has been eliminated from the > > 16bit comm code. Next step is to remove use of the service thread... > > > > ChangeLog: > > use GetCommState16 to save state in OpenComm16 > > merge comm16 globals into one structure > > gcc -shared -Wl,-soname,libkernel32.so kernel32.spec.o comm.spec.o kernel.spec.o stress.spec.o system.spec.o toolhelp.spec.o windebug.spec.o win87em.spec.o wprocs.spec.o comm.o debugger.o format_msg.o kernel_main.o stress.o string.o sync.o thunk.o time.o toolhelp.o utthunk.o win87em.o windebug.o wowthunk.o utthunk.glue.o -o libkernel32.so -L../../dlls -lntdll -L../../library -lwine -lm -lutil -ldl > /usr/i386-slackware-linux/bin/ld: warning: type and size of dynamic symbol `CALL32_Regs' are not defined > make[2]: Leaving directory `/oof/Wine-20010629/dlls/kernel' > > Is this right, or are my binutils getting long in the tooth? No, the error has been there for several months now. It does not seem to be harmful. Ciao, Marcus

July 18, 2001

Re: use GetCommState16 to save state in OpenComm16

by lawson_whitney＠juno.com

On Wed, 18 Jul 2001, Mike McCormack wrote: > > with this patch, all use of unix fds has been eliminated from the > 16bit comm code. Next step is to remove use of the service thread... > > ChangeLog: > use GetCommState16 to save state in OpenComm16 > merge comm16 globals into one structure gcc -shared -Wl,-soname,libkernel32.so kernel32.spec.o comm.spec.o kernel.spec.o stress.spec.o system.spec.o toolhelp.spec.o windebug.spec.o win87em.spec.o wprocs.spec.o comm.o debugger.o format_msg.o kernel_main.o stress.o string.o sync.o thunk.o time.o toolhelp.o utthunk.o win87em.o windebug.o wowthunk.o utthunk.glue.o -o libkernel32.so -L../../dlls -lntdll -L../../library -lwine -lm -lutil -ldl /usr/i386-slackware-linux/bin/ld: warning: type and size of dynamic symbol `CALL32_Regs' are not defined make[2]: Leaving directory `/oof/Wine-20010629/dlls/kernel' Is this right, or are my binutils getting long in the tooth? Seems to work OK though. Lawson ---cut here--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

July 18, 2001

Re: use GetCommState16 to save state in OpenComm16

by lawson_whitney＠juno.com

On Wed, 18 Jul 2001 12:08:51 +1000 Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a multi-part message in MIME format > > ------=_NextPart_000_33334807 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > > with this patch, all use of unix fds has been eliminated from the > 16bit comm code. Next step is to remove use of the service thread... > > ChangeLog: > use GetCommState16 to save state in OpenComm16 > merge comm16 globals into one structure Okay, if you get this, it does no harm to my 16 bit comms app. Does throw a little ld warning though. Well, let's see. Lawson ---cut here--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

July 18, 2001

Re: How to unsubscribe

by Antonio Augusto Todo Bom Neto

Begin forwarded message: Date: Wed, 18 Jul 2001 08:31:30 -0300 From: Antonio Augusto Todo Bom Neto <antonio(a)xultz.wox.org> To: wine-devel(a)winehq.com Subject: Re: How to unsubscribe On Wed, 18 Jul 2001 07:48:03 -0300 (ADT) tlegge(a)fundy.net wrote: > Hi > > How do I unsubscribe from this list? > > Regards > > Tim > > try it: http://www.winehq.com/mailman/options/wine-devel/tlegge%40fundy.net ;)

July 18, 2001

How to unsubscribe

by tlegge＠fundy.net

Hi How do I unsubscribe from this list? Regards Tim

July 18, 2001

Re: [Handhelds] Announcement : SynCE project

by Shane Nay

You might want to checkout Agenda Desktop, and VRSync. Agenda Desktop is a synchronization tool developed by the Agenda community of developers, and VRSync is a syncronization tool developed by internal Agenda people. Both are pretty good synchronization tools for the Agenda, and it would be nice if there was some interoperation between these two communities. Thanks, Shane Nay. On Tuesday 17 July 2001 14:11, Ludovic LANGE wrote: > Hello, > > First of all sorry for the intrusion, but I think this may be of > interest for some of you. > > > > SynCE project's ambitious goal is to provide a mean of synchronising > handhelds devices with a (desktop) computer. > > By handheld, we mean any portable / embedded / PDA.... device, that > needs to synchronize its data with a less mobile computer. > (An exemple would be any PDA/PocketPC running Windows CE, or any PDA > running Linux, etc...) > > > The first step of this project is to provide a full (client & server) > implementation of Microsoft's RAPI protocol, which is the low-level > protocol used in ActiveSync synchronisation. > This will allow, when completed : > - a Windows CE device to communicate with any (non-Microsoft) computer, > - A Linux device to communicate with a Microsoft computer and benefits > from the existing tools, > - etc, etc... > > The second step will be to provide a set of tools to synchronize data > with 'standard' open or closed source application : Mozilla, KMail, etc.... > > > Right now, the project is in its early, early stages ( we don't even > have an alpha release ! ), but yet there are some bits that allow an > implementation of the client part of the RAPI protocol, to query > informations (registry, filesystem, databases,...) from a WindowsCE device. > One tool (DBBackup) allows a full dump of the databases of the device. > > > I won't interfere more with the list, and I invite all people interested > to have a look on the project page ( > http://www.sourceforge.net/projetcs/synce & > http://synce.sourceforge.net ) and to subscribe to the mailing-list. > We currently are looking for developper, and for testers having mobile > devices still under Windows CE (PDA, PocketPC, etc...) and an unix-like > desktop environment. > > > Best regards, > > Ludovic LANGE > > _______________________________________________ > Handhelds mailing list > Handhelds(a)handhelds.org > http://handhelds.org/mailman/listinfo/handhelds > irc://irc.openprojects.net #handhelds

July 18, 2001

Re: how to add a new language wine?

by Dmitry Timoshkov

"jerry.zhang" <wenlongzhang(a)redflag-linux.com> wrote: > I want to add a new language to wine,but I found the document about this is out of date, > so,I want to know how to add a new language to the latest version of wine. First of all, you should make sure, that language you want to add has the code page <-> unicode translation table. Look at unicode subdirectory for a possible choice. Next you should check that wrc (tools/wrc) and wmc (tools/wmc) have support for that language/code page. If all the above is already in place, you can start adding resources to the kernel/user/comctl32/commdlg/etc. > In additional,I want to know how to define the value of many parameters in the file > "/dlls/kernel/nls/youlanguage.nls". Have a look at other .nls files. Choose the values that represent your local preferences. Good luck. -- Dmitry.

July 18, 2001

how to add a new language wine?

by jerry.zhang

hello,everyone: I want to add a new language to wine,but I found the document about this is out of date, so,I want to know how to add a new language to the latest version of wine. In additional,I want to know how to define the value of many parameters in the file "/dlls/kernel/nls/youlanguage.nls". Best regards Jerry Zhang Redflag Software Co. Ltd E-mail: wenlongzhang(a)redflag-linux.com

July 18, 2001

glibc bug mmap/malloc

by Andreas Mohr

[yeah, it's glibc bug time AGAIN] Hello all, I just wanted to let you all know that I found what I believe to be a glibc malloc bug. (yes, this happens even with 2.4.6 and latest Debian glibc 2.2.3-6). This is the only thing I did today, BTW. When Wine loads a very large (129 MB) exe file, it does an mmap() on it. After that it tries to do some malloc()s. That fails, which causes the entirely loading/execution of that file to abort. Thus I did malloc()/free() in a for loop after that 129 MB mmap() to test the problematic behaviour. Output: trace:module:map_image mapped PE file at 0x8051000-0xfc45000 err:virtual:VIRTUAL_CreateView now that the PE file has been mmap() /dev/zero:ed, we do some other malloc()s: malloc of 4 bytes: 0x804d878 malloc of 8 bytes: 0x804d878 malloc of 12 bytes: 0x804d878 malloc of 16 bytes: 0x804d878 malloc of 20 bytes: 0x804db20 <---- (chunk size optimization algorithm) malloc of 24 bytes: 0x804db20 <---- ("") malloc of 28 bytes: 0x804e7f8 <---- ("") malloc of 32 bytes: 0x804e7f8 malloc of 36 bytes: 0x804e7f8 . . . malloc of 10224 bytes: 0x804e7f8 malloc of 10228 bytes: 0x804e7f8 malloc of 10232 bytes: 0x804e7f8 up to 0x8050fef malloc of 10236 bytes: (nil) (0x8050ff3, which probably touches mmap() management headers) malloc of 10240 bytes: (nil) . . . malloc of 131052 bytes: (nil) malloc of 131056 (0x1fff0) bytes: (nil) ... malloc of 131060 bytes: 0x404c2008 malloc of 131064 bytes: 0x404c2008 . . . You can clearly see that malloc() is able to squeeze up to 10232 bytes into the memory range just before the mmap()ed area, but when it gets slightly larger, it is NOT capable of switching to an entirely different memory area, throws its arms up in desperation and simply returns a shabby NULL. It only uses a new memory area in case the values get *much* larger, i.e. at least 131060 bytes. This is a BUG. (IMHO) What else should it be ? I already contacted Ulrich Drepper about it, and I'll hopefully get a positive reply soon. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Microsoft Windows: Made for the Internet The Internet: Made for Unix

July 17, 2001

Re: Significant change to WINEPS - please test!

by Ian Pilcher

Gerard Patel wrote: > > Anything ? everything is a better word. > I'm glad I asked for feedback before submitting it! > I use a 'latin' language. No unicode for me. > Which code page/character set do you use? > I test with the software I use to send this mail. There is a 'preview' feature > and I can preview (and print) a mail. This is working fine with current > Cvs. > What software package is this? Can I download a trial version someplace? > If I use your patch, most characters in the mail body, are overlayed, > printed scattered in black heaps with small lines all around , strangely > evoking some insects. Pretty funny :-) It sounds like the characters are being printed, but in the wrong place. > > If my description is not clear, I can send you a screen capture. Wouldn't hurt. > > Strangely the page header and footer are still correct, though. > If you run it with '--debugmsg warn+psdrv', do you get any messages about missing glyphs? Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

July 17, 2001

Re: Significant change to WINEPS - please test!

by Gerard Patel

At 07:29 PM 15/07/2001 -0500, you wrote: >So please give me your feedback. I particularly want to know if it >breaks anything before I submit it. Anything ? everything is a better word. I use a 'latin' language. No unicode for me. I test with the software I use to send this mail. There is a 'preview' feature and I can preview (and print) a mail. This is working fine with current Cvs. If I use your patch, most characters in the mail body, are overlayed, printed scattered in black heaps with small lines all around , strangely evoking some insects. Pretty funny :-) If my description is not clear, I can send you a screen capture. Strangely the page header and footer are still correct, though. Gerard

July 17, 2001

Announcement : SynCE project

by Ludovic LANGE

Hello, First of all sorry for the intrusion, but I think this may be of interest for some of you. SynCE project's ambitious goal is to provide a mean of synchronising handhelds devices with a (desktop) computer. By handheld, we mean any portable / embedded / PDA.... device, that needs to synchronize its data with a less mobile computer. (An exemple would be any PDA/PocketPC running Windows CE, or any PDA running Linux, etc...) The first step of this project is to provide a full (client & server) implementation of Microsoft's RAPI protocol, which is the low-level protocol used in ActiveSync synchronisation. This will allow, when completed : - a Windows CE device to communicate with any (non-Microsoft) computer, - A Linux device to communicate with a Microsoft computer and benefits from the existing tools, - etc, etc... The second step will be to provide a set of tools to synchronize data with 'standard' open or closed source application : Mozilla, KMail, etc.... Right now, the project is in its early, early stages ( we don't even have an alpha release ! ), but yet there are some bits that allow an implementation of the client part of the RAPI protocol, to query informations (registry, filesystem, databases,...) from a WindowsCE device. One tool (DBBackup) allows a full dump of the databases of the device. I won't interfere more with the list, and I invite all people interested to have a look on the project page ( http://www.sourceforge.net/projetcs/synce & http://synce.sourceforge.net ) and to subscribe to the mailing-list. We currently are looking for developper, and for testers having mobile devices still under Windows CE (PDA, PocketPC, etc...) and an unix-like desktop environment. Best regards, Ludovic LANGE

July 17, 2001

Re: Small OpenGL fix

by Lionel Ulmer

> You can't really use either. The GDI one requires calling DC_GetDCPtr > which you cannot do from outside GDI, and the USER one requires a > reference to a global variable that isn't visible outside USER. Hmmm, I should have checked more :-) > A possible way is to use the Escape function and add a few > x11drv-specific escape codes. But first it would probably be a good > thing to check how opengl32 is implemented under Windows; I have no > idea how it works, but it probably needs some way to communicate with > the graphics driver, and we could use the same mechanism. Well, the only thing I know for sure about how OpenGL is done in Windows is that you load one DLL (opengl32.dll). This DLL support the standard software rendering mode but can also load an 'ICD' (by looking at the 'OpenGLdrivers' key in the system registry) that is the driver specific to the card. But after, how the software mode actually work or how this ICD (for my card, a DLL) interacts with the drivers, I have no idea... Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 17, 2001

Re: Small OpenGL fix

by Alexandre Julliard

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > In the current code, there seems to be two different mechanisms for driver > calling : > > - one that is 'GDI' specific with the 'dc->funcs->pFUNC_NAME' sort of calls > > - the other for 'USER' with 'USER_Driver.pFUNC_NAME' > > So which one of the two methods should I use the 'WGL' that is neither in > GDI nor in USER ? You can't really use either. The GDI one requires calling DC_GetDCPtr which you cannot do from outside GDI, and the USER one requires a reference to a global variable that isn't visible outside USER. A possible way is to use the Escape function and add a few x11drv-specific escape codes. But first it would probably be a good thing to check how opengl32 is implemented under Windows; I have no idea how it works, but it probably needs some way to communicate with the graphics driver, and we could use the same mechanism. -- Alexandre Julliard julliard(a)winehq.com

July 17, 2001

Re: Small OpenGL fix

by Lionel Ulmer

> The dependencies between x11drv and user should certainly be fixed, > but the real problem is that opengl32 and ddraw import x11drv at all. > x11drv is an internal driver and should never be imported by any > dll. Anybody feeling like fixing that? Well, I started looking at how one could re-code dlls/opengl32/wgl.c to not depend on X11DRV and I had some questions... In the current code, there seems to be two different mechanisms for driver calling : - one that is 'GDI' specific with the 'dc->funcs->pFUNC_NAME' sort of calls - the other for 'USER' with 'USER_Driver.pFUNC_NAME' So which one of the two methods should I use the 'WGL' that is neither in GDI nor in USER ? Should I use the GDI method for all calls that take an HDC as a parameter and the USER one for all the other ? Should I create a new mechanism (OPENDL_Driver ???) knowing that it would be part of X11DRV ? Thanks anyway for comitting my patch even if it's not the Right Thing (tm) :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 17, 2001

Re: using cvs diff

by Huw D M Davies

On Tue, Jul 17, 2001 at 02:25:49PM +0000, Bill Medland wrote: > I can't see it in TFM > > I thought I was keeping an eye on what patches had actually been applied to > the wine source (especially to see if mine had) by using "cvs diff wine". > It seemed to be working but I now realise it wasn't. I guess it was > diffing my local code against the corresponding revisions. > > How do I diff my current set of code against the current cvs? cvs diff will show you the differences between your files and the files in the repository as of your last cvs update. To perform a diff against a specific tag use cvs diff -r, so to diff against the current head you can do cvs diff -r HEAD Huw.

July 17, 2001

Re: using cvs diff

by Marcus Meissner

On Tue, Jul 17, 2001 at 02:25:49PM +0000, Bill Medland wrote: > I can't see it in TFM > > I thought I was keeping an eye on what patches had actually been applied to > the wine source (especially to see if mine had) by using "cvs diff wine". > It seemed to be working but I now realise it wasn't. I guess it was > diffing my local code against the corresponding revisions. > > How do I diff my current set of code against the current cvs? To diff your current tree, use 'cvs diff -u' in the wine toplevel directory. Or use 'cvs diff -u dir/file1 dir/file2' if you have only changed file1 and file2. Too see other applied changes, subscribe to the wine-cvs mailinglist, where those will be posted. Ciao, Marcus

July 17, 2001

Re: ChangeDisplaySettings

by Lionel Ulmer

> I have been browsing the source tree and was following the methods used by > DirectDraw and was considering a similar approach. While I was browsing the > source, I was eventually lead to dlls/x11drv/xvidmode.c which contains most of > the functions that I will probably need. But I still have a few concerns: > 1) Is the x11drv used for ddraw AND the gdi or just one? > 2) what is the best way to query if the video exists? without knowing syncs? > 3) and if i need to know syncs how do I find them? My first question was : why implement it ? I would personnaly find VERY annoying to have any Windows app. change the size of my desktop window when I prefer running my applications 'windowed'. Moreover, I would prefer you to handle first the 'Desktop' case :-) In that case, no need to use any X extension, you just have to resize the desktop window. > Another question I have is about pixel depth. From what I understand, it is > imposible to change the pixel format of the screen while X is running. > However, it is possible to start more than one X server with different configs > (and depth) which we could use if we have to but probably not a good idea. Of > course another posibility is to emulate the pixel depth, but that would > probably cause performance problems, especially when used by games. Anyone > have any suggestions or should we just leave changing depths as unimplemented? Depth changing is part of the new X extension called 'RandR' (Rotate and Resize). I do not know at all though when it will be available on 'normal' X servers (as it was mostly developped now for the iPAQ handheld to rotate the screen). Keith Packard (the Render author (BTW how is the support of this extension progressing :-) ? )) and Jim Gettys are the main developpers of this extension. So I would probably wait for this extension to be available before starting any code on ChangeDisplaySettings... And please consider having it optional :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 17, 2001

ChangeDisplaySettings

by Travis Michielsen

Hi, I was planning on implementing ChangeDisplaySettingsA soon but I'm not certain on how to do it. I have been browsing the source tree and was following the methods used by DirectDraw and was considering a similar approach. While I was browsing the source, I was eventually lead to dlls/x11drv/xvidmode.c which contains most of the functions that I will probably need. But I still have a few concerns: 1) Is the x11drv used for ddraw AND the gdi or just one? 2) what is the best way to query if the video exists? without knowing syncs? 3) and if i need to know syncs how do I find them? Another question I have is about pixel depth. From what I understand, it is imposible to change the pixel format of the screen while X is running. However, it is possible to start more than one X server with different configs (and depth) which we could use if we have to but probably not a good idea. Of course another posibility is to emulate the pixel depth, but that would probably cause performance problems, especially when used by games. Anyone have any suggestions or should we just leave changing depths as unimplemented? Thanks! - Travis Michielsen __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

July 17, 2001

DrawText

by Travis Michielsen

Hi all, I have put together a quick patch that SHOULD fully implement the DrawText functions. However, I have not had time to thoroughly tested most of the logic so I thought I would post it here rather than sending it directly to the patches list. I welcome any/all comments/suggestions. - Travis Michielsen Index: wine/dlls/user/text.c =================================================================== RCS file: /home/wine/wine/dlls/user/text.c,v retrieving revision 1.12 diff -u -r1.12 text.c --- wine/dlls/user/text.c 2001/07/17 00:51:00 1.12 +++ wine/dlls/user/text.c 2001/07/17 13:55:22 @@ -235,6 +235,7 @@ int prefix_x = 0; int prefix_end = 0; TEXTMETRICW tm; + int lmargin = 0, rmargin = 0; int x = rect->left, y = rect->top; int width = rect->right - rect->left; int max_width = 0; @@ -242,10 +243,8 @@ TRACE("%s, %d , [(%d,%d),(%d,%d)]\n", debugstr_wn (str, count), count, rect->left, rect->top, rect->right, rect->bottom); - if(dtp) { - FIXME("Ignores params:%d,%d,%d,%d\n", dtp->cbSize, - dtp->iTabLength, dtp->iLeftMargin, dtp->iRightMargin); - } + if (dtp) TRACE("Params: iTabLength=%d, iLeftMargin=%d, iRightMargin=%d\n", + dtp->iTabLength, dtp->iLeftMargin, dtp->iRightMargin); if (!str) return 0; if (count == -1) count = strlenW(str); @@ -258,8 +257,17 @@ else lh = tm.tmHeight; + if (dtp) + { + lmargin = dtp->iLeftMargin * tm.tmAveCharWidth; + rmargin = dtp->iRightMargin * tm.tmAveCharWidth; + if (!(flags & (DT_CENTER | DT_RIGHT))) + x += lmargin; + dtp->uiLengthDrawn = 0; //This param RECEIVES number of chars processed + } + if (flags & DT_TABSTOP) - tabstop = flags >> 8; + tabstop = dtp ? dtp->iTabLength : flags >> 8; if (flags & DT_EXPANDTABS) { @@ -292,7 +300,7 @@ if (flags & DT_SINGLELINE) { - if (flags & DT_VCENTER) y = rect->top + + if (flags & DT_VCENTER) y = rect->top + (rect->bottom - rect->top) / 2 - size.cy / 2; else if (flags & DT_BOTTOM) y = rect->bottom - size.cy; @@ -312,7 +320,7 @@ if (flags & DT_WORD_ELLIPSIS) flags |= DT_WORDBREAK; - if (flags & DT_PATH_ELLIPSIS) + if (flags & DT_PATH_ELLIPSIS) { WCHAR* lastBkSlash = NULL; WCHAR* lastFwdSlash = NULL; @@ -320,14 +328,11 @@ line[totalLen] = '\0'; lastBkSlash = strrchrW(line, BACK_SLASHW[0]); lastFwdSlash = strrchrW(line, FORWARD_SLASHW[0]); - fnameDelim = lastFwdSlash ? lastFwdSlash : lastBkSlash; - if (lastBkSlash && lastFwdSlash) /* which is last? */ - if (lastBkSlash > lastFwdSlash) - fnameDelim = lastBkSlash; + fnameDelim = lastBkSlash > lastFwdSlash ? lastBkSlash : lastFwdSlash; if (fnameDelim) fnameLen = &line[totalLen] - fnameDelim; - else + else fnameDelim = (WCHAR*)str; strcpyW(swapStr, ELLIPSISW); @@ -343,16 +348,16 @@ } len = MAX_STATIC_BUFFER; - TEXT_NextLineW(hdc, swapStr, &count, line, &len, width, flags); + TEXT_NextLineW(hdc, swapStr, &count, line, &len, width, flags); /* if only the ELLIPSIS will fit, just let it be clipped */ len = max(3, len); GetTextExtentPointW(hdc, line, len, &size); /* FIXME: - * NextLine uses GetTextExtentPoint for each character, + * NextLine uses GetTextExtentPoint for each character, * rather than GetCharABCWidth... So the whitespace between - * characters is ignored in the width measurement, and the + * characters is ignored in the width measurement, and the * reported len is too great. To compensate, we must get * the width of the entire line and adjust len accordingly. */ @@ -365,10 +370,10 @@ if (fnameLen < len-3) /* some of the path will fit */ { /* put the ELLIPSIS between the path and filename */ - strncpyW(swapStr, &line[fnameLen+3], len-3-fnameLen); + strncpyW(swapStr, &line[fnameLen+3], len-3-fnameLen); swapStr[len-3-fnameLen] = '\0'; - strcatW(swapStr, ELLIPSISW); - strncpyW(swapStr+strlenW(swapStr), &line[3], fnameLen); + strcatW(swapStr, ELLIPSISW); + strncpyW(swapStr+strlenW(swapStr), &line[3], fnameLen); } else { @@ -382,12 +387,15 @@ line[len] = '\0'; strPtr = NULL; } + if (flags & DT_MODIFYSTRING) + strcpyW(str, swapStr); } } if (!(flags & DT_CALCRECT)) { - if (!ExtTextOutW(hdc, x, y, (flags & DT_NOCLIP) ? 0 : ETO_CLIPPED, - rect, line, len, NULL )) return 0; + if (!ExtTextOutW( hdc, x, y, + ( (flags & DT_NOCLIP) ? 0 : ETO_CLIPPED ) | ( (flags & DT_RTLREADING) ? 0 : ETO_RTLREADING ), + rect, line, len, NULL )) return 0; if (prefix_offset != -1) { HPEN hpen = CreatePen( PS_SOLID, 1, GetTextColor(hdc) ); @@ -410,20 +418,35 @@ break; } } + if (dtp) + dtp->uiLengthDrawn += len; } while (strPtr); + if (flags & DT_CALCRECT) { rect->right = rect->left + max_width; rect->bottom = y; + if (dtp) + rect->right += lmargin + rmargin; } return y - rect->top; } /*********************************************************************** - * DrawTextA (USER32.@) + * DrawTextW (USER32.@) */ -INT WINAPI DrawTextA( HDC hdc, LPCSTR str, INT count, LPRECT rect, UINT flags ) +INT WINAPI DrawTextW( HDC hdc, LPCWSTR str, INT count, + LPRECT rect, UINT flags ) +{ + return DrawTextExW(hdc, str, count, rect, flags, NULL); +} + +/*********************************************************************** + * DrawTextExA (USER32.@) + */ +INT WINAPI DrawTextExA( HDC hdc, LPCSTR str, INT count, + LPRECT rect, UINT flags, LPDRAWTEXTPARAMS dtp ) { WCHAR *wstr; INT ret = 0; @@ -437,32 +460,19 @@ { MultiByteToWideChar( CP_ACP, 0, str, count, wstr, wcount ); ret = DrawTextExW( hdc, wstr, wcount, rect, flags, NULL ); + if (flags & DT_MODIFYSTRING) + WideCharToMultiByte( CP_ACP, 0, wstr, -1, str, count, NULL, NULL ); HeapFree(GetProcessHeap(), 0, wstr); } return ret; } /*********************************************************************** - * DrawTextW (USER32.@) - */ -INT WINAPI DrawTextW( HDC hdc, LPCWSTR str, INT count, - LPRECT rect, UINT flags ) -{ - return DrawTextExW(hdc, str, count, rect, flags, NULL); -} - -/*********************************************************************** - * DrawTextExA (USER32.@) + * DrawTextA (USER32.@) */ -INT WINAPI DrawTextExA( HDC hdc, LPCSTR str, INT count, - LPRECT rect, UINT flags, LPDRAWTEXTPARAMS dtp ) +INT WINAPI DrawTextA( HDC hdc, LPCSTR str, INT count, LPRECT rect, UINT flags ) { - TRACE("(%d,%s,%d,%p,0x%08x,%p)\n",hdc,debugstr_an(str,count),count,rect,flags,dtp); - if(dtp) { - FIXME("Ignores params:%d,%d,%d,%d\n",dtp->cbSize, - dtp->iTabLength,dtp->iLeftMargin,dtp->iRightMargin); - } - return DrawTextA(hdc,str,count,rect,flags); + return DrawTextExA( hdc, str, count, rect, flags, NULL ); } /*********************************************************************** __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

July 17, 2001

using cvs diff

by Bill Medland

I can't see it in TFM I thought I was keeping an eye on what patches had actually been applied to the wine source (especially to see if mine had) by using "cvs diff wine". It seemed to be working but I now realise it wasn't. I guess it was diffing my local code against the corresponding revisions. How do I diff my current set of code against the current cvs? Bill

July 17, 2001

Re: another debugstr patch

by Alexandre Julliard

Andreas Mohr <a.mohr(a)mailto.de> writes: > BTW, Alexandre, why didn't you apply my "debugstr patch" from Jun 04 ? It got lost somewhere; I've applied it now. BTW for everybody, when you submitted a patch and didn't see it applied and didn't hear anything about it, *please* resubmit or ask me what's going on. Patches can get dropped for multiple reasons, and it's your responsibility to follow what happens to your patch, until it is either applied or you know why it wasn't. -- Alexandre Julliard julliard(a)winehq.com

July 17, 2001

Re: Mouse trouble

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > I did consider that, but who's going to intercept and handle that message? > It's not an operation that is or should be known outside of the x11drv, so > sending the window a custom message will either conflict with some other > message, or get the message ignored (I doubt DefWindowProc passes custom > messages back to x11drv or anything). Or did you have any particular ideas > in this area? You can set a new window procedure to intercept the message, and pass all other messages straight through to the original window procedure. -- Alexandre Julliard julliard(a)winehq.com

July 17, 2001

Re: Mouse trouble

by Ove Kaaven

On 16 Jul 2001, Alexandre Julliard wrote: > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > Known bug in the current CVS. Turn dxgrab off. If it's on, mouse events > > are lost. I'm working on it, but have not yet thought of a way to fix it; > > I need to run a procedure (GrabPointer) in the context of the thread that > > owns the window that gets the grab. My latest idea was to queue an APC to > > the owner of the window, but QueueUserAPC requires a thread handle, while > > GetWindowThreadProcessId only returns a thread ID. > > I'd strongly suggest using some kind of SendMessage instead of > QueueUserAPC. I did consider that, but who's going to intercept and handle that message? It's not an operation that is or should be known outside of the x11drv, so sending the window a custom message will either conflict with some other message, or get the message ignored (I doubt DefWindowProc passes custom messages back to x11drv or anything). Or did you have any particular ideas in this area?

July 17, 2001

Re: Small OpenGL fix

by Alexandre Julliard

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > This is more a problem of inter-dependencies of X11DRV and USER32 (as the > former should NEVER be loaded before the latter)... But as I could not fix > this problem, I prefered going 'around' the problem :-) The dependencies between x11drv and user should certainly be fixed, but the real problem is that opengl32 and ddraw import x11drv at all. x11drv is an internal driver and should never be imported by any dll. Anybody feeling like fixing that? -- Alexandre Julliard julliard(a)winehq.com

July 17, 2001

fnt2bdf.c and font names

by Bill Medland

I've just been playing with fonts (sserife and vgasys) to get things working. In the process I notice that fnt2bdf seems to do some strange stuff about choosing a font name, pixel size etc. I don't want to submit a patch that merely demonstrates my stupidity/lack of understanding but am willing to put in my suggested fix. This will result in for example the MS Sans Serif 8 pt font getting a name of -windows-MS Sans Serif-medium-r-normal-sans-13-80-96-96-p-50-microsoft-cp1252 SIZE 8 96 96 as opposed to the current -windows-MS Sans Serif-medium-r-normal-sans-13-130-72-72-p-50-microsoft-cp1252 SIZE 13 96 96 (I don't understand why the 72 dpi is hard-coded) Do I submit it or am I misunderstanding something Bill

July 16, 2001

Re: Added sanity check to WINPROC_CallWndProc

by Jukka Heinonen

On Sun, Jul 15, 2001, Uwe Bonnes wrote: > >>>>> "Jukka" == Jukka Heinonen <jhei(a)iki.fi> writes: > Jukka> DeusEx causes Wine to crash (segmentation fault) because it calls > Jukka> CallWindowProc and passes null in HWND parameter. While I > Jukka> suspect that this is because some Wine function that should > Jukka> return a valid HWND is returning a null pointer, the crashing can > Jukka> be fixed simply by adding a sanity check to WINPROC_CallWndProc. > > How does Windows behave on those invalid arguments? On a Windows NT machine, CallWindowProc does not check any of its arguments. However, DefWindowProc and all WNDPROC handlers do check HWND argument. Many (if not all) Wine WNDPROC handlers do not have this check and null HWND handles therefore make Wine crash even though Windows doesn't. So, my patch was incorrect after all. Correct fix to Wine is simple: just go through all WNDPROC handlers and check after first WIN_FindWndPtr call that the returned pointer is non-null. Wine DefWindowProc is a good example of this. I might look at this next weekend unless someone else volunteers. It is likely that in every case where applications pass HWND handles to Wine, there should be a similar check. Confirming this would be pretty boring, though. > Jukka> After this patch, both DeusEx installer and DeusEx dialog for > Jukka> choosing rendering engine work. However, DeusEx still crashes > Jukka> later because DeusEx for some reason generates a division by zero > Jukka> FP exception. DeusEx handler for this exception calls > Jukka> __CxxFrameHandler which is not implemented by Wine and thus > Jukka> exception handling ends into infinite recursion. Luckily stack > Jukka> overflow makes Wine to crash :) > > Native msvcrt has __CxxFrameHandler, but I aggree that wine-msvcrt needs > exception facilities too. Actually, I looked at Windows development documents and tried some tests myself and found out that 1.0/0.0 (division by zero) should only raise an exception if a function call to _control87 or _controlfp is made to enable floating point exceptions. DeusEx does no such call. Therefore, Wine should not have raised this exception or at least it should have passed control right back to the application instead of invoking exception handlers. Likely Wine startup fails to properly initialize the floating point unit. Fixing this should not be too hard, but I have to see when I have enough time to look at it. I am not going to do anything regarding __CxxFrameHandler (is this C++ exception handling stuff?) since I have not found any documentation about it and I'm hoping that DeusEx doesn't really need it. -- Jukka Heinonen <http://www.iki.fi/jhei/>

July 16, 2001

Re: Mouse trouble

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Known bug in the current CVS. Turn dxgrab off. If it's on, mouse events > are lost. I'm working on it, but have not yet thought of a way to fix it; > I need to run a procedure (GrabPointer) in the context of the thread that > owns the window that gets the grab. My latest idea was to queue an APC to > the owner of the window, but QueueUserAPC requires a thread handle, while > GetWindowThreadProcessId only returns a thread ID. I'd strongly suggest using some kind of SendMessage instead of QueueUserAPC. -- Alexandre Julliard julliard(a)winehq.com

July 16, 2001

Re: Mouse trouble

by Brandon Kilgore

At 12:34 PM 7/16/01 +0200, Ove Kaaven wrote: >On Sun, 15 Jul 2001, Daniel Bingham wrote: > > > I just got the latest CVS and when I tried to run starcraft my mouse > > won't move. I have dxgrab turned on so as not to have my mouse going > > off the screen when I try to move. I am not very knowledgeable about > > wine or programming, so I thought I'd tell someone who was. > >Known bug in the current CVS. Turn dxgrab off. If it's on, mouse events >are lost. I'm working on it, but have not yet thought of a way to fix it; >I need to run a procedure (GrabPointer) in the context of the thread that >owns the window that gets the grab. My latest idea was to queue an APC to >the owner of the window, but QueueUserAPC requires a thread handle, while >GetWindowThreadProcessId only returns a thread ID. > >Does anyone else on wine-devel have any other ideas? Is there any way you could create a linked list of thread IDs and Handles as they are created so they can be queried at a later point? I don't know how feasible this is. There's no way defined in the Win32 libraries to go from a thread ID to a handle. Microsoft suggests asking the thread to DuplicateHandle(). Also, if you're running this procedure in the context of the thread that owns the window, shouldn't you have access to it's handle? This is the excerpt I found from Microsoft: --------------------------------------------------- The CreateThread() API is used to create threads. The API returns both a thread handle and a thread identifier (ID). The thread handle has full access rights to the thread object created. The thread ID uniquely identifies the thread on the system level while the thread is running. The ID can be recycled after the thread has been terminated. This relationship is similar to that of the process handle and the process ID (PID). There is no way to get the thread handle from the thread ID. While there is an OpenProcess() API that takes a PID and returns the handle to the process, there is no corresponding OpenThread() that takes a thread ID and returns a thread handle. The reason that the Win32 API does not make thread handles available this way is that it can cause damage to an application. The APIs that take a thread handle allow suspending/resuming threads, adjusting priority of a thread relative to its process, reading/writing registers, limiting a thread to a set of processors, terminating a thread, and so forth. Performing any one of these operations on a thread without the knowledge of the owning process is dangerous, and may cause the process to fail. If you will need a thread handle, then you need to request it from the thread creator or the thread itself. Both the creator or the thread will have a handle to the thread and can give it to you using DuplicateHandle(). This requirement allows both applications to coordinate their actions. ---------------------------------------------------

July 16, 2001

Re: Added sanity check to WINPROC_CallWndProc

by Jon Griffiths

Hi, >Native msvcrt has __CxxFrameHandler, but I aggree that wine-msvcrt needs >exception facilities too. While I'm still on holiday, i just bought a laptop to do some wine coding on. I had improved the exception handling in builtin msvcrt but my last run of patches to it werent accepted due to using asm instead of register funcs. Once I get my old sources mailed to me I will begin hacking on it again. I'm interested in getting the konqueror/ActiveX stuff working with builtin msvcrt, since the dot.kde.org press release singled it out as non-functional (much to my shame <g>). Meanwhile I'm strolling through shlwapi and should have some patches for that soon. Its great to see the progress made since february though, very impressive. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

July 16, 2001

Re: Mouse trouble

by Ove Kaaven

On Sun, 15 Jul 2001, Daniel Bingham wrote: > I just got the latest CVS and when I tried to run starcraft my mouse > won't move. I have dxgrab turned on so as not to have my mouse going > off the screen when I try to move. I am not very knowledgeable about > wine or programming, so I thought I'd tell someone who was. Known bug in the current CVS. Turn dxgrab off. If it's on, mouse events are lost. I'm working on it, but have not yet thought of a way to fix it; I need to run a procedure (GrabPointer) in the context of the thread that owns the window that gets the grab. My latest idea was to queue an APC to the owner of the window, but QueueUserAPC requires a thread handle, while GetWindowThreadProcessId only returns a thread ID. Does anyone else on wine-devel have any other ideas?

July 16, 2001

Mouse trouble

by Daniel Bingham

Hi, I just got the latest CVS and when I tried to run starcraft my mouse won't move. I have dxgrab turned on so as not to have my mouse going off the screen when I try to move. I am not very knowledgeable about wine or programming, so I thought I'd tell someone who was. If I have something set up wrong I can't find it and don't find any documentation to address it either. Any help would be much appreciated. Please email me directly because I get the digest and tend to ignore it. Thanks. Daniel Bingham db78(a)att.net

July 16, 2001

Significant change to WINEPS - please test!

by Ian Pilcher

The attached patch makes a fundamental change to the way the PostScript driver deals with character encodings -- it ignores them. Instead, the driver now operates directly on 16-bit Unicode characters. This should be a more robust strategy for handling non-Latin, and especially multi-byte, character sets. I really have no idea, however, how the rest of Wine handles non-Latin characters. As an English speaker, I'm not well equipped to test it. So please give me your feedback. I particularly want to know if it breaks anything before I submit it. Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ======================================================================== diff -urN ../wine-20010714cvs/dlls/wineps/font.c ./dlls/wineps/font.c --- ../wine-20010714cvs/dlls/wineps/font.c Sun Jul 15 16:07:36 2001 +++ ./dlls/wineps/font.c Sun Jul 15 16:27:27 2001 @@ -5,6 +5,7 @@ * */ #include <string.h> +#include <stdlib.h> /* for bsearch() */ #include "winspool.h" #include "psdrv.h" #include "debugtools.h" @@ -294,6 +295,7 @@ return TRUE; } +#if 0 /*********************************************************************** * PSDRV_UnicodeToANSI */ @@ -321,9 +323,52 @@ return 0xff; } } +#endif + +/****************************************************************************** + * PSDRV_UVMetrics + * + * Find the AFMMETRICS for a given UV. Returns first glyph in the font + * (space?) if the font does not have a glyph for the given UV. + */ +static int MetricsByUV(const void *a, const void *b) +{ + return (int)(((const AFMMETRICS *)a)->UV - ((const AFMMETRICS *)b)->UV); +} + +const AFMMETRICS *PSDRV_UVMetrics(LONG UV, const PSDRV_PDEVICE *physDev) +{ + AFMMETRICS key; + const AFMMETRICS *needle; + + /* + * Ugly work-around for symbol fonts. Wine is sending characters which + * belong in the Unicode private use range (U+F020 - U+F0FF) as ASCII + * characters (U+0020 - U+00FF). + */ + + if ((physDev->font.afm->Metrics->UV & 0xff00) == 0xf000 && UV < 0x100) + UV |= 0xf000; + + key.UV = UV; + + needle = bsearch(&key, physDev->font.afm->Metrics, + physDev->font.afm->NumofMetrics, sizeof(AFMMETRICS), + MetricsByUV); + + if (needle == NULL) + { + WARN("No glyph for U+%.4lX in %s\n", UV, physDev->font.afm->FontName); + needle = physDev->font.afm->Metrics; + } + + return needle; +} + /*********************************************************************** * PSDRV_GetTextExtentPoint */ +#if 0 BOOL PSDRV_GetTextExtentPoint( DC *dc, LPCWSTR str, INT count, LPSIZE size ) { @@ -346,11 +391,30 @@ return TRUE; } +#endif +BOOL PSDRV_GetTextExtentPoint(DC *dc, LPCWSTR str, INT count, LPSIZE size) +{ + PSDRV_PDEVICE *physDev = (PSDRV_PDEVICE *)dc->physDev; + int i; + float width = 0.0; + + for (i = 0; i < count && str[i] != '\0'; ++i) + width += PSDRV_UVMetrics(str[i], physDev)->WX; + + width *= physDev->font.scale; + + size->cx = GDI_ROUND((FLOAT)width * dc->xformVport2World.eM11); + size->cy = GDI_ROUND((FLOAT)physDev->font.tm.tmHeight * + dc->xformVport2World.eM22); + + return TRUE; +} /*********************************************************************** * PSDRV_GetCharWidth */ +#if 0 BOOL PSDRV_GetCharWidth( DC *dc, UINT firstChar, UINT lastChar, LPINT buffer ) { @@ -365,7 +429,24 @@ return TRUE; } +#endif +BOOL PSDRV_GetCharWidth(DC *dc, UINT firstChar, UINT lastChar, LPINT buffer) +{ + PSDRV_PDEVICE *physDev = (PSDRV_PDEVICE *)dc->physDev; + UINT i; + + if (lastChar > 0xffff || firstChar > lastChar) + { + SetLastError(ERROR_INVALID_PARAMETER); + return FALSE; + } + + for (i = firstChar; i < lastChar; ++i) + *buffer++ = PSDRV_UVMetrics(i, physDev)->WX * physDev->font.scale; + + return TRUE; +} /*********************************************************************** * PSDRV_SetFont diff -urN ../wine-20010714cvs/dlls/wineps/ps.c ./dlls/wineps/ps.c --- ../wine-20010714cvs/dlls/wineps/ps.c Sun Jul 15 16:07:36 2001 +++ ./dlls/wineps/ps.c Sun Jul 15 16:25:12 2001 @@ -115,6 +115,9 @@ static char psshow[] = /* string */ "(%s) show\n"; +static const char psglyphshow[] = /* glyph name */ +"/%s glyphshow\n"; + static char pssetfont[] = /* fontname, xscale, yscale, ascent, escapement */ "/%s findfont\n" "[%d 0 0 %d 0 0]\n" @@ -634,6 +637,7 @@ return TRUE; } +#if 0 BOOL PSDRV_WriteShow(DC *dc, LPCWSTR str, INT count) { char *buf, *buf1; @@ -671,6 +675,32 @@ return TRUE; } +#endif + +BOOL PSDRV_WriteShow(DC *dc, LPCWSTR str, INT count) +{ + char buf[128]; + int i; + + for (i = 0; i < count; ++i) + { + LPCSTR name; + int l; + + name = PSDRV_UVMetrics(str[i], (PSDRV_PDEVICE *)dc->physDev)->N->sz; + l = snprintf(buf, sizeof(buf), psglyphshow, name); + + if (l < sizeof(psglyphshow) - 2 || l > sizeof(buf) - 1) + { + WARN("Unusable glyph name '%s' - ignoring\n", name); + continue; + } + + PSDRV_WriteSpool(dc, buf, l); + } + + return TRUE; +} BOOL PSDRV_WriteFill(DC *dc) { diff -urN ../wine-20010714cvs/dlls/wineps/psdrv.h ./dlls/wineps/psdrv.h --- ../wine-20010714cvs/dlls/wineps/psdrv.h Tue May 29 17:06:11 2001 +++ ./dlls/wineps/psdrv.h Sun Jul 15 16:11:36 2001 @@ -421,6 +421,7 @@ GLYPHNAME *PSDRV_GlyphName(LPCSTR szName); VOID PSDRV_IndexGlyphList(); BOOL PSDRV_GetTrueTypeMetrics(); +const AFMMETRICS *PSDRV_UVMetrics(LONG UV, const PSDRV_PDEVICE *physDev); #endif

July 16, 2001

Re: Handling X errors using exception handlers

by Alexandre Julliard

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > The only problems I could see with this approach is that : > > - it cannot 'expect' more than one kind of error at the same time I was thinking you could use a special value as a "wildcard" for the error codes, in which case it wouldn't be tested for a match. > - I am not sure that the parameters thing are really a good idea. Are we > sure that the error code are the same on all X servers ? Are they > standardized ? They are part of the X spec AFAICT, so yes it should be pretty much standard. -- Alexandre Julliard julliard(a)winehq.com

July 15, 2001

Re: Added sanity check to WINPROC_CallWndProc

by Uwe Bonnes

>>>>> "Jukka" == Jukka Heinonen <jhei(a)iki.fi> writes: Jukka> DeusEx causes Wine to crash (segmentation fault) because it calls Jukka> CallWindowProc and passes null in HWND parameter. While I Jukka> suspect that this is because some Wine function that should Jukka> return a valid HWND is returning a null pointer, the crashing can Jukka> be fixed simply by adding a sanity check to WINPROC_CallWndProc. How does Windows behave on those invalid arguments? Jukka> After this patch, both DeusEx installer and DeusEx dialog for Jukka> choosing rendering engine work. However, DeusEx still crashes Jukka> later because DeusEx for some reason generates a division by zero Jukka> FP exception. DeusEx handler for this exception calls Jukka> __CxxFrameHandler which is not implemented by Wine and thus Jukka> exception handling ends into infinite recursion. Luckily stack Jukka> overflow makes Wine to crash :) Native msvcrt has __CxxFrameHandler, but I aggree that wine-msvcrt needs exception facilities too. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 15, 2001

RE: Documentation fixes

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > What kludge? Ugly OK, that is your subjective opinion, but kludge? > > Even if we only see it from a purely C language perspective, > > it solves the problem of making sure that the C library functions > > have the prototypes we expect them to have. There is no other > > way to solve that problem that I can think of so it is certainly > > not a kludge. > > Not only is it not a problem we need to solve, but it's more likely to > actually cause new problems. I wouldn't be surprised at all if your > patch broke compile on some platforms that have some slight > differences in prototypes (like char* vs. const char*). Well, believe it or not the thought actually occured to me before I submitted the patch, so I actually tested it on Solaris, FreeBSD and Linux, and the only thing I had to change was the include order or stdarg.h to make it work on all platforms. The thing is that if it actually breaks on some platform it is a red light that something might be (and probably is) wrong. We can always fix it with #ifdef:s and winapi_{check,extract,fixup} or whatever can use the #ifdef to generate a correct entry for that platform if need be. Of course the more likely scenario will be that it serves as a reminder that we really can't export the C library function directly because of platform incompabillities and simply don't do it. And no, I don't believe const/non-const is a problem. Beside even if it turn out I'm wrong we can just add a "#define const /* nothing */" at the top of each externs.c file. That, I admit, is a kludge but only a very small and harmless one. > > If you are not convinced now, you never will be. > > I think we agree on this one ;-) Probably. I don't have much hope of convincing you with the statement above either.

July 15, 2001