wine-devel

wine-devel@winehq.org

84463 discussions

RE: uname(1) on UnixWare (Solaris)
by Patrik Stridvall 06 Jun '01

06 Jun '01

> 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 06 Jun '01

06 Jun '01

> 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 06 Jun '01

06 Jun '01

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 05 Jun '01

05 Jun '01

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 05 Jun '01

05 Jun '01

> 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 05 Jun '01

05 Jun '01

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 05 Jun '01

05 Jun '01

> 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 05 Jun '01

05 Jun '01

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

RE: Stanford Checker
by David.Goodenough＠dga.co.uk 05 Jun '01

05 Jun '01

Maybe we have to ask them to check our code, rather than the other way around? Patrik Stridvall <ps(a)leissner.se> on 05-06-2001 12:31:25 PM To: David Goodenough/DGA/GB cc: wine-devel(a)winehq.com Subject: RE: Stanford Checker [Forgot to include list. Trying again.] > 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? Yes, I have. However the problem is that it is not publicly available (yet) and I read somewhere (don't remember where) that it is no use trying to get copy even if you promise not to distribute it further. I will probably look into it when it is released. I have no idea when that will be though.

1 0

RE: Stanford Checker
by Patrik Stridvall 05 Jun '01

05 Jun '01

[Forgot to include list. Trying again.] > 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? Yes, I have. However the problem is that it is not publicly available (yet) and I read somewhere (don't remember where) that it is no use trying to get copy even if you promise not to distribute it further. I will probably look into it when it is released. I have no idea when that will be though.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel