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

suspended threads acquiring synchronization objects
by Peter Hunnisett 13 Feb '03

13 Feb '03

Howdy, we've discovered that windows seems to not allow suspended threads to acquire synchronization objects, which make really really good sense, while wine does. I've attached a simple test case, the code for the test case and a ReWind licensed patch for the problem. Would people have a look at the patch and let me know if it's the best way to fix it, or if I've missed anything? Thanks, Peter peter(a)transgaming.com

3 2

Error in the server thread id fix
by Bill Medland 13 Feb '03

13 Feb '03

Is anyone else looking into a problem that appears to have been introduced by the server change on Feb 1st changing thread and process ids to small integers? As a result ACCPAC for Windows' main desktop process shuts down after about a minute, but leaves various other processes running. I'll have a look at it but I don't know how successful I'll be. -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

4 7

2GB visible partition size
by J. Grant 13 Feb '03

13 Feb '03

Hello, I noticed there is a 2GB visible partition size. This seems to be like FAT16, however I am running on ext3, is there a config option I can set to remove this limit? Regards JG

4 5

Looking for information on implemented API's in wine
by David Miller 13 Feb '03

13 Feb '03

I am ready to begin work on the actual database aspect of cross referencing the windows dlls. As part of the database I would like to include the status of a given API in wine so it will be possible to do things like query for all unimplemented APIs in a given dll. The first questions I have are whether or not I can depend on the spec files to give a complete list, and can someone either point me to documentation on the spec files or explain everything I need to know in order to determine the status of APIs defined there?

1 0

CreateNamedPipe questions
by Dan Kegel 13 Feb '03

13 Feb '03

Oddly enough, it looks like it's ok to pass NULL as the filename to CreateNamedPipe. Anyone know what programs do that, and why? Here's a patch that makes our CreateNamedPipe check for legal filenames (or NULL). It should probably allow forward slashes... The patch also adds a quickie regression test, but I still have to use late binding for CreateNamedPipe (or is it ok for the test to fail on win9x?). Would this test have caught the recent named pipe breakage? If not, what would I need to add? Comments welcome; I'll send it to wine-patches after addressing any feedback. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 Index: dlls/kernel/sync.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/sync.c,v retrieving revision 1.26 diff -u -p -u -r1.26 sync.c --- dlls/kernel/sync.c 25 Oct 2002 21:02:30 -0000 1.26 +++ dlls/kernel/sync.c 13 Feb 2003 07:47:27 -0000 @@ -508,6 +508,8 @@ HANDLE WINAPI CreateNamedPipeW( LPCWSTR { HANDLE ret; DWORD len = name ? strlenW(name) : 0; + static const WCHAR leadin[] = {'\\','\\','.','\\','P','I','P','E'}; + int i; TRACE("(%s, %#08lx, %#08lx, %ld, %ld, %ld, %ld, %p)\n", debugstr_w(name), dwOpenMode, dwPipeMode, nMaxInstances, @@ -516,7 +518,13 @@ HANDLE WINAPI CreateNamedPipeW( LPCWSTR if (len >= MAX_PATH) { SetLastError( ERROR_FILENAME_EXCED_RANGE ); - return 0; + return INVALID_HANDLE_VALUE; + } + /* FIXME: can name really be NULL?! */ + if (name && strncmpiW(name, leadin, sizeof(leadin)/sizeof(leadin[0]))) + { + SetLastError( ERROR_INVALID_NAME ); + return INVALID_HANDLE_VALUE; } SERVER_START_REQ( create_named_pipe ) { 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 07:47:27 -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-12 23:44:20.000000000 -0800 @@ -0,0 +1,109 @@ +/* + * 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_" __FILE__ + +void test_CreateNamedPipeA(void) +{ + HANDLE hnp; + HANDLE hFile; + const char obuf[] = "Bit Bucket"; + char ibuf[32]; + DWORD written; + DWORD gelesen; + + /* Bad parameter checks */ + hnp = CreateNamedPipeA("not a named pipe", + PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE|PIPE_WAIT, + /* nMaxInstances */ 1, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + + ok(hnp == INVALID_HANDLE_VALUE && GetLastError() == ERROR_INVALID_NAME, + "CreateNamedPipe should fail if name doesn't start with \\\\.\\pipe"); + +#if 0 /* Evidently it's ok in windows to pass NULL as the pipe name! */ + hnp = CreateNamedPipeA(NULL, + PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE|PIPE_WAIT, + 1, 1024, 1024, NMPWAIT_USE_DEFAULT_WAIT, NULL); + ok(hnp == INVALID_HANDLE_VALUE && GetLastError() == ERROR_INVALID_NAME, + "CreateNamedPipe should fail if name is NULL"); +#endif + + /* Functional checks */ + + hnp = CreateNamedPipeA(PIPENAME, + PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE|PIPE_WAIT, + /* nMaxInstances */ 1, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + 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) + return; + + /* Make sure we can read and write a few bytes in both directions*/ + memset(ibuf, 0, sizeof(ibuf)); + ok(WriteFile(hnp, obuf, sizeof(obuf), &written, NULL), "WriteFile"); + ok(written == sizeof(obuf), "write file len"); + ok(ReadFile(hFile, ibuf, sizeof(obuf), &gelesen, NULL), "ReadFile"); + ok(gelesen == sizeof(obuf), "read file len"); + ok(memcmp(obuf, ibuf, written) == 0, "content check"); + + memset(ibuf, 0, sizeof(ibuf)); + ok(WriteFile(hFile, obuf, sizeof(obuf), &written, NULL), "WriteFile"); + ok(written == sizeof(obuf), "write file len"); + ok(ReadFile(hnp, ibuf, sizeof(obuf), &gelesen, NULL), "ReadFile"); + ok(gelesen == sizeof(obuf), "read file len"); + ok(memcmp(obuf, ibuf, written) == 0, "content check"); + + CloseHandle(hFile); + CloseHandle(hnp); +} + +START_TEST(pipe) +{ + test_CreateNamedPipeA(); +} +

3 4

Fix for Treeview Regression in Putty, winamp, et al.
by Drew "DanteAliegri" Ogle 13 Feb '03

13 Feb '03

Putty and winamp use dialogs which contain treeviews. When the treeview code sets values to be passed to the callback function, it decides there if it is returning to A or W. When it is returning to a dialog, it returns a W, however, when the user code which the dialog calls is an A function, it excepts TVN_*A, when the treeview code is sending TVN_*W. The most logical place to test for this, was in DefDlgProcW, which then modifies the code when it finds a) the msg to be WM_NOTIFY b) the lParam to be non-null c) the code to be of W form d) the code to be of a TVN_ type. As this is my second real patch, any comments are welcome :) -Dante Index: windows/defdlg.c =================================================================== RCS file: /home/wine/wine/windows/defdlg.c,v retrieving revision 1.29 diff -u -r1.29 defdlg.c --- windows/defdlg.c 14 Jan 2003 19:29:15 -0000 1.29 +++ windows/defdlg.c 13 Feb 2003 05:39:00 -0000 @@ -395,12 +395,22 @@ LRESULT WINAPI DefDlgProcW( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam ) { BOOL result = FALSE; + BOOL forWide = FALSE; WNDPROC dlgproc; + /* make sure we only change TVN_ codes. */ + if( msg == WM_NOTIFY && lParam && ((LPNMHDR)lParam)->code & 0x30 ) + forWide = TRUE; SetWindowLongW( hwnd, DWL_MSGRESULT, 0 ); if ((dlgproc = DEFDLG_GetDlgProc( hwnd ))) { + /* if call was meant for a W funcition, but the callback + * is really an A function, change the code from a W code + * to a A code. + **/ + if( forWide && (WINPROC_GetProcType( dlgproc) == WIN_PROC_32A )) + ((LPNMHDR)lParam)->code += 0x31; /* Call dialog procedure */ result = CallWindowProcW( dlgproc, hwnd, msg, wParam, lParam ); /* 16 bit dlg procs only return BOOL16 */

2 2

Re: wine-devel digest, Vol 1 #1689 - 17 msgs
by ATMRD＠aol.com 12 Feb '03

12 Feb '03

Hey, > I am running Gnome on a variant of FreeBSD called Darwin. It shoudln't matter what window manager your running be it Apple's Aqua, or Gnome or KDE, as long as the X11, libraries are installed, because regardless Darwin is still the core of the OS. > Darwin runs > on PPC architecture opposed to x86 architecture. My question is can > Wine run on this variant of FreeBSD? Theoritically Wine should run on any version of FreeBSD, however due to Darwin's arhicteture, allthough it is FreeBSD based,which does not use the ELF format but isntead the Mach-O, wine does not work correctly or at all to my knowledge. > Can I download the source and > build Wine for my system? You can try, but I dont think it will work with out major modification to some of the core libs wich are X86 dependant. If for some reason it does I'd be dilighted to hear about it. There is a project called darwine, at http://darwine.sf.net, you can find more information about running wine on Darwin there. Hope this helps ~Sanjay Connare.

1 0

Re: [ros-kernel] Cool!
by Steven Edwards 12 Feb '03

12 Feb '03

Thought you guys might like to see this. We are making major progress on 3rd party drivers --- Ge van Geldorp <ge(a)gse.nl> wrote: > Attached is a screen capture of GDITEST.EXE. You might think "what's so > cool about that, gditest has been running for a while now". Well, look > again. Note the lines starting in the top-left and running to the bottom > and right side. They're in real RGB(64, 64, 128), not in the gray to > which they're mapped when you're running on a 16 color VGA display! > > The screen capture was taken from ReactOS running in a VMware virtual > machine, using the 3rd party VMware 16 bit per pixel video driver. > > It will take me some more time to finish this. Although GDITEST.EXE > works, WINHELLO.EXE doesn't yet. There is some cleanup still to be done > and I need to do some more testing to make sure I didn't break the > existing VGA video drivers (VGAMP.SYS/VGADDI.DLL). However, I think > support for at least some 3rd party video drivers is within reach now. > > G� van Geldorp. > > ATTACHMENT part 2 image/gif name=gditest.gif __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com

1 0

RegisterHotKey help needed
by Robert Reif 12 Feb '03

12 Feb '03

I have a program that uses RegisterHotKey and UnregisterHotKey. Is anyone working on implementing this or does anyone have any pointers on how to implement this myself? Thanks, Bob.

1 0

X11 Clipboard implementation
by Mike Hearn 12 Feb '03

12 Feb '03

Hi all, I've been poking around inside the wine clipboard system, in an attempt to make it properly compliant with the agreed upon specs over at http://www.freedesktop.org/standards/clipboards.txt At the moment, Wine mixes up CLIPBOARD and PRIMARY, which is not a good idea. Ideally, Wine would work like GTK, Qt, Mozilla and all the rest do, which is to keep CLIPBOARD for ctrl-c, ctrl-v type operations, and primary for selected text/middle click. When you select some text in say notepad, both CLIPBOARD and PRIMARY are grabbed, which is wrong, only primary should be grabbed. In a similar fashion, when you select Edit | Copy only CLIPBOARD should be grabbed. Currently, selecting text in Wine doesn't do anything (at least, not in notepad). So, the obvious way to fix that would be to introduce a new Wine-specific API, that lets the Wine controls call SetSelectedText or something, which then interfaces with X. So, I think x11drv/clipboard.c should be changed to basically eliminate references to PRIMARY, as without the ability to deal with middle clicks and grab-on-select, Wine has no business changing that selection. Therefore my questions are: 1) Should I try and hack up a patch to stop wine using PRIMARY? 2) What are the rules governing new wine specific APIs. I know the DLL Separation work is supposed to eliminate them, but there are no FAQs anywhere on it that I can see, could somebody explain this please? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

6 9