February 2003 - Wine-devel - list.winehq.org

Re: Users Guide - added basic usage section
by Mike Hearn 24 Feb '03

24 Feb '03

> Again, I'm currently working on a MAJOR update of the Guides. > I'll incorporate these parts into my version. > And BTW: why is it that once you decide to do some major work, > EVERYBODY suddenly happens to come out of the eternally dark and dangerous > and forgotten woods?? ;-) Oops, sorry :) Well, just take it to mean that you chose a worthwhile thing to work on. I look forward to the new guides :) -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

Re: (resend) tests for GetPrivateProfileInt
by Dmitry Timoshkov 24 Feb '03

24 Feb '03

"Stefan Leichter" <Stefan.Leichter(a)camLine.com> wrote: > here are some tests for the function GetPrivateProfileInt. The expected > results are the one from NT4. Hopefully the will match for Win 9x also. > Before i convert GetPrivateProfileInt from ascii to unicode i like to > see some test result from Win9x/ME. > > ChangeLog > ------------- > Added test for GetPrivateProfileInt 1. The patch got wrapped by your mailer. 2. Unicode and Ansi versions of GetPrivateProfileInt (as all other APIs) should be tested separately. -- Dmitry.

2 2

Re: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 24 Feb '03

24 Feb '03

Roland McGrath wrote: > > In glibc, we actually allocate some excess space in the thread-local > storage area layout determined at startup time. This lets a dynamically > loaded module use static TLS if its PT_TLS segment fits in the available > surplus. (In sysdeps/generic/dl-tls.c, see TLS_STATIC_SURPLUS.) If there > is insufficient space preallocated, then loading the module will fail. In > fact, we put this feature there with GL in mind and can adjust the > preallocated surplus for what is most useful in practice. The last time we discussed this issue, I had the distinct impression that an OpenGL library would essentially be forced into using one of the dynamic access models (GD or LD) for __thread variables, hence requiring at least one function call to access a thread-local variable. I also had the distinct impression that the glibc maintainers were unwilling to modify their implementation so that we could use the LE access model, which would allow a 2 instruction thread-safe dispatcher among other things. It looks like I was wrong, and you've gone and addressed all the concerns I originally had with __thread variables. For that, I'm grateful. > In fact, we put this feature there with GL in mind... Did you inform the OpenGL vendors who were interested in this issue of this fact? Have you documented it anywhere, particularly in Ulrich Drepper's "ELF Handling For Thread-Local Storage" document? The current version of this document clearly states that the Local Exec TLS model "can only be used for code in the executable itself and to access variables in the executable itself". Perhaps you can see why I was still under the impression that it would not work for a dynamically loadable shared library. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

2 1

Building wine tests with nmake and cl in linux
by Dan Kegel 24 Feb '03

24 Feb '03

OK, so there's msvcmaker, but I don't use guis, so I threw together a way to build the wine tests using cl and nmake. I have the following files in ~/bin: nmake: wine -- wcmd /c F:\\bin\\nmake.bat "$@" nmake.bat: call f:/bin/vcvars32.bat echo on nmake %1 %2 %3 %4 %5 %6 vcvars32.bat: same as normal one, but without quotes nmakemaker: (attached) Then in any dll/tests directory, I can type nmakemaker > foo.mak nmake /f foo.mak and build all my tests with msvc. Each test is built as a separate executable, but that's the way I like it for testing anyway. Now I guess I'll submit patches to make everyone else's tests actually *compile* under msvc. It was real funny to see that article on slashdot appear as I was doing this. I seem to have gone a bit further than that guy, since I don't have to use that awful, horrible wcmd window. -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 #!/usr/bin/perl for $file (<*.c>) { push(@files, $file) if ($file !~ /generated.c/ && $file !~ /.spec.c/); } print "CC = cl\n"; print "CFLAGS = -I../../include\n"; print "all: "; foreach $a (@files) { chomp $a; $a =~ s/\.c$//; print "$a.exe " } print "\n"; foreach $a (@files) { chomp $a; $a =~ s/\.c$//; print "$a.exe: $a.c\n\t\$(CC) \$(CFLAGS) $a.c -o $a.exe\n" }

1 0

interestig link
by Igor 24 Feb '03

24 Feb '03

http://codingstyle.com/articles/using-ms-vcpp-with-gnu-wine.html

1 0

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 24 Feb '03

24 Feb '03

Ulrich Weigand wrote: > > From what I can see, you are actually getting LE model code > (omitting the ebp stuff which you can avoid using > -fomit-frame-pointer): > > movl %gs:0, %eax > movl __foo_dispatch(a)NTPOFF(%eax), %edx > movl (%edx), %ecx > jmp *%ecx > > Note that NTPOFF is used; for IE, you'd see INDNTPOFF > or GOTNTPOFF and an additional indirection. Right, thanks! Makes sense. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

1 0

Detect wine filesystem inconsistency ?
by Sylvain Petreolle 24 Feb '03

24 Feb '03

Digging into my C:\\windows\\system directory, I accidentally found two versions of shlwapi.dll. With chance, the 2 versions were identical. What if they werent ? I could have load an old version of the library or worse, of a document. Note this can happen with every file on the virtual disks if they re stored on a case sensitive filesystem. Could we detect and report a such "duplicated" file ? ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Wine Packagers Guide
by Dimitrie O. Paun 24 Feb '03

24 Feb '03

On February 16, 2003 12:53 am, Tony Lambregts wrote: > Change Log: Split up the Packagers Guide and move it to its own > directory. Include the the sample config file This is a bit of a problem: Tom is working on it, and splitting it now will screw him badly. Let's do the merge after he finishes integrating his changes. -- Dimi.

3 2

named pipe oddity
by Dan Kegel 24 Feb '03

24 Feb '03

A while ago, I noticed that our setup program didn't work with cvs wine. Somebody said "Oh, that's because named pipes are broken." Since then, the setup program works again with cvs wine, but I'm still curious about the state of named pipes. The simple sequence CreateNamedPipe CreateFile seems to work under Windows, but not under Wine. Does Wine for some reason require a ConnectNamedPipe between the two? A very simple test is attached. (BTW, I've been looking at the wineserver named pipe code a bit. Shame it's not better commented... at least it's small, so the lack of comments isn't too awful.) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 Index: dlls/kernel/tests/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/Makefile.in,v retrieving revision 1.6 diff -u -p -u -r1.6 Makefile.in --- dlls/kernel/tests/Makefile.in 4 Oct 2002 17:42:27 -0000 1.6 +++ dlls/kernel/tests/Makefile.in 13 Feb 2003 16:54:45 -0000 @@ -17,6 +17,7 @@ CTESTS = \ generated.c \ locale.c \ path.c \ + pipe.c \ process.c \ thread.c --- /dev/null 2002-08-30 16:31:37.000000000 -0700 +++ dlls/kernel/tests/pipe.c 2003-02-17 17:26:42.000000000 -0800 @@ -0,0 +1,80 @@ +/* + * Unit tests for named pipe functions in Wine + * + * Copyright (c) 2002 Dan Kegel + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include <stdlib.h> +#include <stdio.h> +#include <time.h> + +#ifndef STANDALONE +#include "wine/test.h" +#else +#include <assert.h> +#define START_TEST(name) main(int argc, char **argv) +#define ok(condition, msg) assert(condition) +#endif + +#include <windef.h> +#include <winbase.h> +#include <winerror.h> +#include <wtypes.h> + +#define PIPENAME "\\\\.\\PIPE\\tests_pipe" + +void test_CreateNamedPipeA(void) +{ + HANDLE hnp; + HANDLE hFile; + + /* Functional checks + * Just check things used internally by wine, in e.g. + * wine/dlls/ole32/compobj.c + * wine/programs/rpcss/np_server.c + * wine/dlls/rpcrt4/rpc_binding.c + */ + + hnp = CreateNamedPipeA(PIPENAME, + PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE|PIPE_WAIT, + PIPE_UNLIMITED_INSTANCES, + 4096, + 4096, + NMPWAIT_USE_DEFAULT_WAIT, + NULL); + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + /* in wine, the CreateFile is in a different thread, but that + * shouldn't matter. Also, the first thread does a ConnectNamedPipe, + * but that isn't required by the Win32 API, it's optional. + */ + hFile = CreateFileA(PIPENAME, GENERIC_READ|GENERIC_WRITE, 0, + NULL, OPEN_EXISTING, 0, 0); + ok(hFile != INVALID_HANDLE_VALUE, "CreateFile failed"); + + if (hFile != INVALID_HANDLE_VALUE) { + CloseHandle(hFile); + } + + CloseHandle(hnp); +} + +START_TEST(pipe) +{ + test_CreateNamedPipeA(); +} +

3 11

gtk look progress and pthreads.
by James Gregory 24 Feb '03

24 Feb '03

Hi all, I posted something similar to mono-devel, so sorry if any of you are seeing this twice. I've spent some time working on getting wine to have the option to look like a gtk app. At present I'm just trying to get wine to use the same colours as the current GTK theme. I made great progress on this last night: modified configure.ac et al to allow building against gtk, added an item to the enum for the various "looks", added the option so setting "WineLook" does the right thing for this new look. I added another array of colour settings to syscolor.c, and modified the condition that loads in that array to recognise the new colours (which are currently all set to red), and call a function to do a gtk_init() (for those who are wondering, I'm currently using a dummy argc and argv in the call. I'll do something about this later) and then start setting that array to the *actual* colours of the gtk theme (I chose red to make it easy to find bugs -- colours that weren't set would be obvious) Now, this was all going great up until the gtk_init() call. I'm now in the position where running I'm wine and seeing this sort of thing: $ LD_LIBRARY_PATH=/home/james/lib /home/james/bin/notepad Loading required GL library /usr/X11R6/lib/libGL.so.1.2 wine: Unhandled exception, starting debugger... FIXME:pthread_cond_init (repeated n times) Now, I'm assuming from the FIXME: that this is an unimplemented piece of wine. Is this saying that gtk can't run with the existing wine threading implementation due to this (and possibly) other functions being buggy/nonexistent? So, the point: what should I do? is this something which will be fixed by someone who knows threading better than I (which is to say almost anyone :))? Does someone know of a workaround that I can use? Is this doomed ==> should I throw in the towel? Thanks, James.

4 10