- Wine-Devel - list.winehq.org

Re: uname(1) on UnixWare (Solaris)
by Alexandre Julliard June 6, 2001

June 6, 2001

Bang Jun-Young <bjy(a)mogua.org> writes: > I've nearly completed new DLL configuration code in configure.in. > Before making it available, I need to know what uname(1) command > prints out on UnixWare (and Solaris?). Why do you need that? Using uname(1) in a configure script is almost certainly the wrong thing to do. -- Alexandre Julliard julliard(a)winehq.com

4 9

Re: [PATCH] Flag unicode structure for user create window
by Uwe Bonnes June 6, 2001

June 6, 2001

>>>>> "Gerard" == Gerard Patel <gerard.patel(a)nerim.net> writes: Gerard> In the CreateWindow user driver function, it is not enough to Gerard> test the window procedure to know if the cs structure is unicode Gerard> or not : the window can be subclassed, in the cbt hook, for Gerard> example. Gerard> ChangeLog: Hallo, yesterday I tried to find why the findfile95 dialog only displayed the first character ( "o" versus "open"). Your patch fixed it :-) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

RE: uname(1) on UnixWare (Solaris)
by Patrik Stridvall June 6, 2001

June 6, 2001

> On Tue, Jun 05, 2001 at 12:18:00AM -0700, Francois Gouget wrote: > > On Tue, 5 Jun 2001, Bang Jun-Young wrote: > > > 1. Configure message is wrong: > > > checking whether we can build a Linux dll... yes > > > I see this even on FreeBSD and NetBSD. :( It's not a > Linux dll, > > > but an FreeBSD/NetBSD dll. > > > > Maybe this message should be changed, yes. But I don't think you > > should put a `uname` there. > > Could you explain me a bit further why we shouldn't do that? As far as the question above is concerned see Francois's reply. I fully agree with him. However regardless of this, uname shouldn't be used (at least not directly). Autoconf provides a standard way to do this (which BTW happends to use uname). It can be used as below. AC_CANONICAL_HOST case $host_os in *cygwin* ) CYGWIN=yes;; * ) CYGWIN=no;; esac It requires two files config.sub and config.guess be distribute along with Wine but that is not really a problem. Perhaps we need to do this anyway. Autoconf 2.50 has discontinued AC_CYGWIN so CYGWIN support seems to require it regardless. Actually the code above is how this is done with Autoconf 2.50. However making CYGWIN an exception is one thing, doing it in other cases is quite another thing. IMHO you will need to provide a _really_ convincing argument that we should make another exception assuming of course we make the first one for CYGWIN which we haven't done yet either.

2 1

RE: uname(1) on UnixWare (Solaris)
by Patrik Stridvall June 6, 2001

June 6, 2001

> On Tue, Jun 05, 2001 at 11:51:19PM -0700, Francois Gouget wrote: > > Maybe it was not your intention but I was afraid that we > would end up > > with something like: > > "checking whether we can build a `uname` dll..." > > and then a few lines down: > > "checking whether we can build a `uname` dll..." > > > > The problem is then you don't know exactly where the > message comes > > from. > > Sorry but I don't catch what you mean quite well. It's obvious which > message is printed on the screen, isn't it? Yes, but this means that the text no longer describes what it is trying to check. If somebody runs it on a OS called Foo it might trick the him/her into thinking that we know about and have added special handling for OS Foo, which we haven't. > What do you think about replacing "Linux dll" with "GNU style > ELF dll"? Acceptable, but it is not my decision.

1 0

Is this a bug?
by Ian Pilcher June 6, 2001

June 6, 2001

While poking around in gdi.h, I came upon the following: static inline INT WINE_UNUSED INTERNAL_XWSTODS(DC *dc, INT width) { FLOAT floatWidth; /* Perform operation with floating point */ floatWidth = (FLOAT)width; INTERNAL_XWSTODS_FLOAT(dc, &floatWidth); /* Round to integers */ return GDI_ROUND(floatWidth); } ... and a little later ... static inline INT WINE_UNUSED INTERNAL_YWSTODS(DC *dc, INT height) { FLOAT floatHeight; /* Perform operation with floating point */ floatHeight = (FLOAT)height; INTERNAL_XWSTODS_FLOAT(dc, &floatHeight); /* Round to integers */ return GDI_ROUND(floatHeight); } Shouldn't one of these (probably INTERNAL_YWSTODS) be calling INTERNAL_YWSTODS_FLOAT instead of INTERNAL_XWSTODS_FLOAT? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

2 1

Re: PATCH: set_thread_buffer fixed
by Gerard Patel June 5, 2001

June 5, 2001

At 10:43 AM 05/06/2001 +0200, you wrote: >> This calls fails because glibc detects that the value at (esp+28) >> is different of 0 - the real system call is never done, with your >> test app and Wine. > >Well, note that the second version is only pushing a 32bit offset, so >mmap64 accesses random stack space! Yes :-/ <snip> >Yes, check the sys/mman.h header, it should have __off64_t as argument >to the mmap ... asm("mmap64") not __off_t. Yes, it is __off_t and that is the problem; but how this header has come to be in this state is part of what I don't understand. It's marked as part of the glibc, but there is nothing like it in the glibc source that I used to compile. The mman.h in my glibc source is much shorter and the declaration of mmap64 seems correct. I guess that the file in my /usr/include/sys/mman.h is a generated file. I don't even want to count the number of 'mman.h' files on my system :-/ >So I think I can use this test program as check for mmap64 brokeness... Btw, the reference on large files http://www.suse.de/~aj/linux_lfs.html says that locking will never be supported on 64 bits files with glibc 2.1.3 so I don't see why it's necessary to support this case. Gerard

1 0

RE: Stanford Checker
by Patrik Stridvall June 5, 2001

June 5, 2001

> On Tue, 5 Jun 2001 David.Goodenough(a)dga.co.uk wrote: > > but has anyone thought of running these against Wine? > > I'm not sure if it'd do that much good. They're currently working on > checking the XFree86 tree (see the Xpert mailing list archives on > www.XFree86.org if you want), without a lot of big results > yet. From what > I gather, this tool has very limited and context-dependent > intelligence, Perhaps. But see below. > and is not conceptually very different from what a glorified > version of > Patrik's tools/winapi_check script might be, if given enough people > working on it. Not quite. winapi_check is 1. Specifically written for Wine 2. A syntax analyzer 3. Mostly ad hoc. The Stanford checker on the other hand is 1. Generalized for all C/C++ applications 2. A semantic analyzer 3. Formalized with a script language The way I choose when designing winapi_check was the one of the easiest ways and the way they choose is one of the hardest. So just calling it is glorified winapi_check gives the Stanford people too little credit. Anyway the way Stanford choose is really _very_ hard so what I fear is that they had to make some limiting decisions that makes their tool much less useful. That said regardless of how good the Stanford checker really will be I'm pretty there will be a lot of things that will be _much_ easier checked by writting a script for the Stanford checker than by extending winapi_check, because they have fundamentally different design philosofies. However don't underestimate winapi_check either. There is a lot of things that can quite easilt be checked by adding some clever perl pattern, if:s and a little state. Syntax level matching is not that bad just a little more crude. If somebody have something that he want to be automatically checked, please post it on the list and I will see what I can do.

1 0

Stanford Checker
by David.Goodenough＠dga.co.uk June 5, 2001

June 5, 2001

On the kernel list and in Alan Cox's patches for the kernel there are a lot of references to some logic checking tools being generated by Stanford. I do not know if these are generally available but has anyone thought of running these against Wine?

2 1

RE: Stanford Checker
by Patrik Stridvall June 5, 2001

June 5, 2001

> Maybe we have to ask them to check our code, rather than the other way > around? I think it far to much to ask. As Eric said, while it is AFAIK highly configurable with specific scripts, for each kind of check it is currently seems to be very much focused on the Linux kernel. I also believe, like Eric, that it is currently very buggy and that even if they have a powerful enough scripting language to be usable for Wine it will probably need some serious debugging to make the scripts we need to actually work in practise not only in theory. No, as I said, I think it is to much to ask. We will have to wait until they release it whenever that will be.

1 0

Re:Stanford Checker
by Eric Pouech June 5, 2001

June 5, 2001

last time I checked (a month ago), the tool wasn't freely available (nor finished), so nothing can be done for now when the tool is finished (<put here your date estimation>), one could be able to configure the tool for use in Wine (read: write the scripts for the things we want to check, like windows locks...) but, the tool is (as of today) configured for Linux, and check can only be done agains the Linux tree (AFAIU, they check for specific constructs like getting a spin lock, enabling / disabling IRQ... so highly dependent on Linux source...) however, I don't know (yet) the power of the script language they use for configuring, and whether it could be used for Wine... you'll have to wait until the tool is released... (I suspect, the tool is still buggy *AND* still requires lots of processing by hand - you get a 100 warnings from where only a few are real issues). A+ > On the kernel list and in Alan Cox's patches for the kernel there are a lot > of references to some logic checking tools being generated by Stanford. I > do not know if these are generally available but has anyone thought of > running these against Wine? --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

1 0