- Wine-Devel - list.winehq.org

Detect wine filesystem inconsistency ?
by Sylvain Petreolle Feb. 24, 2003

Feb. 24, 2003

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 Feb. 24, 2003

Feb. 24, 2003

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 Feb. 24, 2003

Feb. 24, 2003

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 Feb. 24, 2003

Feb. 24, 2003

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

wxWindows 2.4.0 samples bugs
by Oleg Prokhorov Feb. 23, 2003

Feb. 23, 2003

Hello, I've found that wxWindows 2.4.0 samples shows a lot of visual bugs/glitches in wine. For example, Dialog sample opens without menu. menu shows on window size change Is anybody going to fix them or at least categorize all of them ? -- Best regards, Oleg mailto:xolegpro(a)rbcmail.ru

2 1

Unknown message
by Waldeck Schutzer Feb. 23, 2003

Feb. 23, 2003

When I fireup Xmpeg, I get lots of these errors: err:tooltips:TOOLTIPS_WindowProc unknown msg 0420 wp=00000001 lp=004894f0 Does anyone know that message code 0420 is? Best, Waldeck

2 1

Re: SMATCH: missing LeaveCriticalSection in error path
by Dmitry Timoshkov Feb. 23, 2003

Feb. 23, 2003

"Michael Stefaniuc" <mstefani(a)redhat.de> wrote: > Changelog: > Michael Stefaniuc <mstefani(a)redhat.com> > - add missing LeaveCriticalSection's in error path. Michael, I'm just curious, how hard it would be to adapt your SMATCH script for finding EnterCriticalSection/LeaveCriticalSection pair matching to do a similar work with wine_tsx11_lock/wine_tsx11_unlock, GDI_GetObjPtr/GDI_ReleaseObj, DC_GetDC[Ptr|Update]/GDI_ReleaseObj, USER_Lock/USER_Unlock, WIN_GetPtr/WIN_ReleasePtr, WIN_FindWndPtr/ WIN_ReleaseWndPtr and some other internal Wine locks? -- Dmitry.

2 1

CreateProcess + STARTF_USESTDHANDLES
by Oleg Prokhorov Feb. 23, 2003

Feb. 23, 2003

Hello , This bug occurs to chess.net client application and may be some others. I've debugged a problem with CreateProcess where parent process overrides child process' stdin, stderr, stdout handles. It can be done like this (portion of a code) // Override siStartInfo.dwFlags = STARTF_USESTDHANDLES; // Create the child process. if (!CreateProcess("child.exe", "child.exe", // command line NULL, // process security attributes NULL, // primary thread security attributes TRUE, // handles are inherited DETACHED_PROCESS, // creation flags NULL, // use parent's environment NULL, // use parent's current directory &siStartInfo, // STARTUPINFO pointer &piProcInfo)) // receives PROCESS_INFORMATION ErrorExit("Create process failed"); The bug in Wine is the following lines of scheduler/process.c else if (!(main_create_flags & (DETACHED_PROCESS|CREATE_NEW_CONSOLE))) { SetStdHandle( STD_INPUT_HANDLE, current_startupinfo.hStdInput ); SetStdHandle( STD_OUTPUT_HANDLE, current_startupinfo.hStdOutput ); SetStdHandle( STD_ERROR_HANDLE, current_startupinfo.hStdError ); } You see it does not allow any std handles overriding if main_create_flags' DETACHED_PROCESS or CREATE_NEW_CONSOLE bit is set on, which is partially wrong in Windows. Cause it doesn't take in account siStartInfo.dwFlags=STARTF_USESTDHANDLES, which requires overriding. The full proof of a bug is included, test it on Windows. It may be used as on of wine tests, if you need that. The bug seems to be easy to fix but to the wine server / client process creation insider. I'm not sure what will be better to you fix it yourself, or guide me how to do it in the most proper way. -- Best regards, Oleg mailto:xolegpro(a)rbcmail.ru

2 1

Wineconf 2003
by Jeremy White Feb. 23, 2003

Feb. 23, 2003

Okay, folks, I think we should have a Wineconf, and I think it should be in conjunction with LinuxTag in 2003. However, I am too swamped to arrange a conference in Germany. Further, Dan, who was kindly following this up, can't make it to Germany in July (congrats, btw, Dan <g>). So, while he started a conversation with the Linuxtag folks, and while they were willing to help out, we really need someone to pick up the ball and run with this. I think we really need someone in Europe. Could someone please volunteer to take responsibility for making this happen? Here's the threat: unless someone steps up and volunteers to drive this process, I will hold it in Minneapolis/St. Paul, and I'll try to pick the coldest and nastiest month to do it <grin>. Cheers, Jeremy

2 1

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes Feb. 23, 2003

Feb. 23, 2003

Here's a sample app and library that uses a couple of __thread variables in a manner similar to OpenGL. I'd appreciate it if someone could take a look and explain what I'm doing incorrectly, as I've declared the variables as LE and yet seem to be getting IE. Note that I'm away from home and don't have a system that I can actually run this app on, so it may very well be completely broken. Thanks! -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

2 1