- wine-devel - winehq.org

Wine keyboard focus and bug 1385
by Roderick Colenbrander 19 Apr '03

19 Apr '03

Hi, When playing for example the game Jedi Outcast on Wine (quake3 based) in non-deskop a keyboard related problem appears. The game starts fine but doesn't receive any keyboard input. When I press for example the A key, the character appears in the console. I saw this problem before and it looks a lot like bug 1385: http://bugs.winehq.com/show_bug.cgi?id=1385 After looking a bit at the source code I found a way to fix my problem. I edited some code in the SetFocus function from x11drv/window.c. The original code looks like this: /* we must not use CurrentTime (ICCCM), so try to use last message time instead */ /* FIXME: this is not entirely correct */ XSetInputFocus( display, win, RevertToParent, /*CurrentTime*/ GetMessageTime() + X11DRV_server_startticks ); When I set the time to CurrentTime the problem was gone. According to the description and the FIXME neither solutions are correct. I don't know enough about the working of the x11 driver and X programming, so perhaps someone can help? Thanks, Roderick Colenbrander

1 0

Palettes - Any experts?
by Ann and Jason Edmeades 19 Apr '03

19 Apr '03

Hello, Having taken a break for a few months I thought I'd try playing with wine again... I have been trying to work out why one game I am investigating never even shows its splash screen, and have got most of the way until I have got stuck. Can anyone offer me some advice? The game launcher kicks off a process whose first thread creates a dummy 16x16 window which is placed in the center of the screen (who knows why!), and launches another thread. The main thread then proceeds to create another process, and wait for it to complete. This means the dummy window is not processing any messages and if sent any the whole thing hangs :-( The launched thread creates the splash screen and begins a WM_PAINT operation. During this processing it calls CreateCompatibleDC, SelectObject, SelectPalette and finally RealizePalette This RealizePalette call (UserRealizePalette, windows\painting.c) results in 256 colors being mapped in, and SendMessageA( HWND_BROADCAST, WM_PALETTECHANGED, (WPARAM)hWnd, 0L); to occur. This broadcast hangs attempting to send the message to the first thread as it is in a hung state waiting for another process to end. Under windows, the RealizePalette returns 0, and spy on Windows does not show this message being sent to the 'hung' thread. 'Interestingly', putting an xterm behind the splash panel, and trying to bring it to the front (to force a repaint) shows that UserRealizePalette is always returning 256, which I thing is the underlying bug. It appears to create a palette every WM_PAINT operation. Commenting out the broadcast makes the splashscreen appear perfectly, so I know I am along the right lines. Can anyone fill in some gaps and point me in the right direction? Debug logs willingly available! :-) Thanks Jason

3 6

FreeBSD and Total Annihilation (Bug 1392)
by Rod Taylor 19 Apr '03

19 Apr '03

With the sound fix, the demo version works great. The real version (which I just bought) doesn't work at all (blank screen) as shipped or with patches from the distributor. Attached is a trace of dplay and virtual, and below is the code snippit which I believe to be causing the problem. FreeBSD 4.8-RELEASE using 20030408 Wine sources ('official port') Any suggestions? Interesting lines from trace: trace:dplay:DPLAYX_ConstructData Through wait trace:dplay:DPLAYX_ConstructData File mapped 0x5c created trace:virtual:NtMapViewOfSection handle=0x5c addr=0x50000000 off=000000000 size=0 access=4 err:dplay:DPLAYX_ConstructData : unable to map static data into process memory space (487) trace:virtual:NtAllocateVirtualMemory 0x0 00110000 2000 00000040 The source of the error (487) seems to be line 466 in ntdll/virtual.c: static NTSTATUS anon_mmap_aligned( void **addr, unsigned int size, int prot, int flags ) { void *ptr, *base = *addr; unsigned int view_size = size + (base ? 0 : granularity_mask + 1); if ((ptr = wine_anon_mmap( base, view_size, prot, flags )) == (void *)-1) { if (errno == ENOMEM) return STATUS_NO_MEMORY; return STATUS_INVALID_PARAMETER; } if (!base) { /* Release the extra memory while keeping the range * starting on the granularity boundary. */ if ((unsigned int)ptr & granularity_mask) { unsigned int extra = granularity_mask + 1 - ((unsigned int)ptr & granularity_mask); munmap( ptr, extra ); ptr = (char *)ptr + extra; view_size -= extra; } if (view_size > size) munmap( (char *)ptr + size, view_size - size ); } else if (ptr != base) { /* We couldn't get the address we wanted */ munmap( ptr, view_size ); return STATUS_CONFLICTING_ADDRESSES; /* !! HERE !! */ } -- Rod Taylor <rbt(a)rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc

1 0

named pipe patch
by Dan Kegel 18 Apr '03

18 Apr '03

Here's a draft of a patch that tries to fix two problems: 1. can't open a pipe until server has called ConnectNamedPipe (on Win32, pipes can be opened immediately after CreateNamedPipe) 2. client loses any data in pipe if server calls FlushFileBuffers and then immediately calls DisconnectNamedPipe. I work around this by keeping a reference to the server side fd in the client pipe user. FlushFileBuffers still doesn't work, but we don't care; this is kind of a unixification of named pipe semantics. It shifts our win32 noncompliance from a very touchy spot to a less touchy spot, I hope. In both cases, I try to solve the problem by passing fd's inside wineserver. I have no idea if I'm doing this right, but it does pass most of my single-process regression tests. (Overlapped I/O is still broken, and I'm not sure if this fd passing magic will work if the pipe ends are in different processes.) Interestingly, it seems that the DisconnectNamedPipe()/ConnectNamedPipe() sequence as previously written would have failed if a unix file descriptor was created or deleted between pipe disconnection and reconnection. This is because a new fd is used for each pipe session, but the old fd number was never removed from the handle-to-unix-fd cache upon DisconnectNamedPipe. My workaround for the data loss problem exposed this issue. I "fixed" it by invalidating the cached fd for the handle passed to DisconnectNamedPipe. (If there are any other handles to this object, their fds won't be invalidated. Shouldn't matter in practice...) This patch also includes an improved test for named pipes. I'm posting it here rather than to wine-patches to get feedback on whether the fd passing I'm doing is sane. Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 Index: server/object.c =================================================================== RCS file: /home/wine/wine/server/object.c,v retrieving revision 1.27 diff -d -u -r1.27 object.c --- server/object.c 19 Feb 2003 00:33:33 -0000 1.27 +++ server/object.c 18 Apr 2003 17:41:17 -0000 @@ -193,6 +193,7 @@ struct object *grab_object( void *ptr ) { struct object *obj = (struct object *)ptr; + assert( obj ); assert( obj->refcount < INT_MAX ); obj->refcount++; return obj; Index: server/file.h =================================================================== RCS file: /home/wine/wine/server/file.h,v retrieving revision 1.7 diff -d -u -r1.7 file.h --- server/file.h 26 Mar 2003 23:41:43 -0000 1.7 +++ server/file.h 18 Apr 2003 17:41:17 -0000 @@ -49,6 +49,7 @@ extern struct fd *create_anonymous_fd( const struct fd_ops *fd_user_ops, int unix_fd, struct object *user ); extern void *get_fd_user( struct fd *fd ); +extern void set_fd_user( struct fd *fd, struct object *user ); extern int get_unix_fd( struct fd *fd ); extern void fd_poll_event( struct fd *fd, int event ); extern int check_fd_events( struct fd *fd, int events ); Index: server/fd.c =================================================================== RCS file: /home/wine/wine/server/fd.c,v retrieving revision 1.8 diff -d -u -r1.8 fd.c --- server/fd.c 26 Mar 2003 01:32:18 -0000 1.8 +++ server/fd.c 18 Apr 2003 17:41:18 -0000 @@ -884,6 +884,12 @@ return fd->user; } +/* change the object that is using an fd */ +void set_fd_user( struct fd *fd, struct object *user ) +{ + fd->user = user; +} + /* retrieve the unix fd for an object */ int get_unix_fd( struct fd *fd ) { @@ -993,15 +999,22 @@ return fd; } -/* flush a file buffers */ +/* flush a file's buffers */ DECL_HANDLER(flush_file) { - struct fd *fd = get_handle_fd_obj( current->process, req->handle, 0 ); - - if (fd) - { - fd->fd_ops->flush( fd ); - release_object( fd ); + struct object *obj = get_handle_obj(current->process, req->handle, 0, NULL); + if (!obj) { + set_error( STATUS_INVALID_HANDLE ); + } else { + struct fd *fd = get_obj_fd(obj); + /* It's ok for named pipes, and possibly other kinds of objects, + * to not have fds associated sometimes, so do nothing if no fd. + */ + if (fd) { + fd->fd_ops->flush( fd ); + release_object( fd ); + } + release_object( obj ); } } Index: server/handle.h =================================================================== RCS file: /home/wine/wine/server/handle.h,v retrieving revision 1.12 diff -d -u -r1.12 handle.h --- server/handle.h 14 Feb 2003 20:27:10 -0000 1.12 +++ server/handle.h 18 Apr 2003 17:41:18 -0000 @@ -39,6 +39,7 @@ extern struct object *get_handle_obj( struct process *process, obj_handle_t handle, unsigned int access, const struct object_ops *ops ); extern int get_handle_unix_fd( struct process *process, obj_handle_t handle, unsigned int access ); +extern void invalidate_handle_unix_fd( struct process *process, obj_handle_t handle ); extern int set_handle_info( struct process *process, obj_handle_t handle, int mask, int flags, int *fd ); extern obj_handle_t duplicate_handle( struct process *src, obj_handle_t src_handle, struct process *dst, unsigned int access, int inherit, int options ); Index: server/handle.c =================================================================== RCS file: /home/wine/wine/server/handle.c,v retrieving revision 1.26 diff -d -u -r1.26 handle.c --- server/handle.c 19 Feb 2003 00:33:33 -0000 1.26 +++ server/handle.c 18 Apr 2003 17:41:19 -0000 @@ -397,6 +397,17 @@ return entry->fd; } +/* invalidate the cached fd for a given handle */ +void invalidate_handle_unix_fd( struct process *process, obj_handle_t handle ) +{ + struct handle_entry *entry; + + entry = get_handle( process, handle ); + /*fprintf(stderr, "invalidate_handle_unix_fd: handle %d, clearing client unix process fd %d\n", (int)handle, entry->fd);*/ + if (entry) + entry->fd = -1; +} + /* find the first inherited handle of the given type */ /* this is needed for window stations and desktops (don't ask...) */ obj_handle_t find_inherited_handle( struct process *process, const struct object_ops *ops ) Index: server/named_pipe.c =================================================================== RCS file: /home/wine/wine/server/named_pipe.c,v retrieving revision 1.22 diff -d -u -r1.22 named_pipe.c --- server/named_pipe.c 4 Apr 2003 22:26:34 -0000 1.22 +++ server/named_pipe.c 18 Apr 2003 17:41:19 -0000 @@ -48,12 +48,13 @@ enum pipe_state { ps_none, - ps_idle_server, - ps_wait_open, - ps_wait_connect, + ps_fresh_server, /* server after create, before first connect */ + ps_idle_server, /* server after disconnect */ + ps_wait_open, /* server during ConnectNamedPipe() wait */ + ps_wait_connect, /* client during WaitNamedPipe() */ ps_connected_server, ps_connected_client, - ps_disconnected + ps_disconnected, /* client after disconnect */ }; struct named_pipe; @@ -62,6 +63,7 @@ { struct object obj; struct fd *fd; + struct fd *fd_for_peer; enum pipe_state state; struct pipe_user *other; struct named_pipe *pipe; @@ -103,6 +105,7 @@ static void pipe_user_destroy( struct object *obj); static int pipe_user_get_poll_events( struct fd *fd ); +static int pipe_user_flush( struct fd *fd ); static int pipe_user_get_info( struct fd *fd, struct get_file_info_reply *reply, int *flags ); static const struct object_ops pipe_user_ops = @@ -121,7 +124,7 @@ { pipe_user_get_poll_events, /* get_poll_events */ default_poll_event, /* poll_event */ - no_flush, /* flush */ + pipe_user_flush, /* flush */ pipe_user_get_info, /* get_file_info */ no_queue_async /* queue_async */ }; @@ -163,6 +166,8 @@ static struct fd *pipe_user_get_fd( struct object *obj ) { struct pipe_user *user = (struct pipe_user *)obj; + if (!user->fd) + return NULL; return (struct fd *)grab_object( user->fd ); } @@ -177,15 +182,20 @@ if(user->other) { - release_object( user->other->fd ); - user->other->fd = NULL; switch(user->other->state) { case ps_connected_server: user->other->state = ps_idle_server; + release_object( user->other->fd ); + user->other->fd = NULL; break; case ps_connected_client: user->other->state = ps_disconnected; + if (user->fd) { + user->other->fd_for_peer = user->fd; + set_fd_user(user->fd, &user->other->obj); + user->fd = NULL; + } break; default: fprintf(stderr,"connected pipe has strange state %d!\n", @@ -202,6 +212,7 @@ if (user->thread) release_object(user->thread); release_object(user->pipe); if (user->fd) release_object( user->fd ); + if (user->fd_for_peer) release_object(user->fd_for_peer); } static int pipe_user_get_poll_events( struct fd *fd ) @@ -209,6 +220,14 @@ return POLLIN | POLLOUT; /* FIXME */ } +static int pipe_user_flush( struct fd *fd ) +{ + /* Pretend we work. We don't, but the fact that we don't + * destroy contents on disconnect makes up for it in most cases. + */ + return 0; +} + static int pipe_user_get_info( struct fd *fd, struct get_file_info_reply *reply, int *flags ) { if (reply) @@ -273,6 +292,7 @@ return NULL; user->fd = NULL; + user->fd_for_peer = NULL; user->pipe = pipe; user->state = ps_none; user->other = NULL; @@ -290,13 +310,14 @@ return user; } -static struct pipe_user *find_partner(struct named_pipe *pipe, enum pipe_state state) +/* Find a pipe_user in any of the given states */ +static struct pipe_user *_find_partner(struct named_pipe *pipe, int states) { struct pipe_user *x; for(x = pipe->users; x; x=x->next) { - if(x->state==state) + if((1 << x->state) & states) break; } @@ -306,6 +327,12 @@ return (struct pipe_user *)grab_object( x ); } +/* Find a pipe_user in the given state */ +static inline struct pipe_user *find_partner(struct named_pipe *pipe, enum pipe_state s) +{ + return _find_partner(pipe, 1<<s); +} + DECL_HANDLER(create_named_pipe) { struct named_pipe *pipe; @@ -329,7 +356,14 @@ if(user) { - user->state = ps_idle_server; + int fds[2]; + user->state = ps_fresh_server; + if (!socketpair(PF_UNIX, SOCK_STREAM, 0, fds)) + { + user->fd = create_anonymous_fd( &pipe_user_fd_ops, fds[1], &user->obj ); + user->fd_for_peer = create_anonymous_fd( &pipe_user_fd_ops, fds[0], &user->obj ); + /* fprintf(stderr, "create_named_pipe: user %p, created fd %p, created fd_for_peer %p\n", user, user->fd, user->fd_for_peer); */ + } reply->handle = alloc_handle( current->process, user, GENERIC_READ|GENERIC_WRITE, 0 ); release_object( user ); } @@ -349,7 +383,7 @@ set_error( STATUS_NO_SUCH_FILE ); return; } - if (!(partner = find_partner(pipe, ps_wait_open))) + if (!(partner = _find_partner(pipe, (1<<ps_wait_open) | (1<<ps_fresh_server)))) { release_object(pipe); set_error( STATUS_PIPE_NOT_AVAILABLE ); @@ -359,22 +393,36 @@ { int fds[2]; - if(!socketpair(PF_UNIX, SOCK_STREAM, 0, fds)) - { - user->fd = create_anonymous_fd( &pipe_user_fd_ops, fds[1], &user->obj ); - partner->fd = create_anonymous_fd( &pipe_user_fd_ops, fds[0], &partner->obj ); - if (user->fd && partner->fd) - { - notify_waiter(partner,STATUS_SUCCESS); - partner->state = ps_connected_server; - partner->other = user; - user->state = ps_connected_client; - user->other = partner; - reply->handle = alloc_handle( current->process, user, req->access, 0 ); - } - } - else file_set_error(); + if (partner->fd_for_peer != NULL) { + /* Server side is fresh, so it already created the fds. + * Grab the fd it created for us, and set its user (since + * it couldn't know ahead of time). + */ + user->fd = partner->fd_for_peer; + partner->fd_for_peer = NULL; + set_fd_user(user->fd, &user->obj); + /* fprintf(stderr, "open_named_pipe: user %p grabbing fd %p from partner %p\n", user, user->fd, partner); */ + } else if (!socketpair(PF_UNIX, SOCK_STREAM, 0, fds)) { + /* Server side isn't fresh, so we have to create the fds for + * both sides. + */ + user->fd = create_anonymous_fd( &pipe_user_fd_ops, fds[1], &user->obj ); + partner->fd = create_anonymous_fd( &pipe_user_fd_ops, fds[0], &partner->obj ); + /* fprintf(stderr, "open_named_pipe: user %p, created fd %p, created fd %p for partner %p\n", user, user->fd, partner->fd, partner); */ + } else + file_set_error(); + if (user->fd && partner->fd) + { + enum pipe_state old_partner_state = partner->state; + partner->state = ps_connected_server; + partner->other = user; + user->state = ps_connected_client; + user->other = partner; + reply->handle = alloc_handle( current->process, user, req->access, 0 ); + if (old_partner_state == ps_wait_open) + notify_waiter(partner,STATUS_SUCCESS); + } release_object( user ); } release_object( partner ); @@ -389,7 +437,7 @@ if(!user) return; - if( user->state != ps_idle_server ) + if( (user->state & (ps_idle_server|ps_fresh_server)) == 0 ) { set_error(STATUS_PORT_ALREADY_SET); } @@ -455,16 +503,28 @@ if( (user->state == ps_connected_server) && (user->other->state == ps_connected_client) ) { - release_object( user->other->fd ); + /* This duplicates a fair bit of code from the destroy method */ + if (user->fd) { + /* fprintf(stderr, "disconnect_named_pipe: user %p passing fd %p to partner %p\n", user, user->fd, user->other); */ + user->other->fd_for_peer = user->fd; + set_fd_user(user->fd, &user->other->obj); + user->fd = NULL; + } user->other->fd = NULL; user->other->state = ps_disconnected; user->other->other = NULL; - - release_object( user->fd ); - user->fd = NULL; - user->state = ps_idle_server; user->other = NULL; + user->state = ps_idle_server; } + + /* IMPOSSIBLE PART: invalidate the cached unix fd for all + * handles that refer to user. + * We can only do it for the handle we were passed, + * so this will only work if that handle has no duplicate. + * FIXME: find out what happens to a handle in win32 when you + * disconnect a duplicate of it. + */ + invalidate_handle_unix_fd(current->process, req->handle); release_object(user); } Index: dlls/kernel/tests/pipe.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/pipe.c,v retrieving revision 1.2 diff -d -u -r1.2 pipe.c --- dlls/kernel/tests/pipe.c 25 Feb 2003 03:56:43 -0000 1.2 +++ dlls/kernel/tests/pipe.c 18 Apr 2003 17:41:20 -0000 @@ -21,23 +21,40 @@ #include <stdlib.h> #include <stdio.h> #include <time.h> +#include <assert.h> + +#include <wtypes.h> +#include <windef.h> +#include <winbase.h> +#include <winerror.h> #ifndef STANDALONE #include "wine/test.h" +#define trace2(a,b) trace((a),(b)) #else #include <assert.h> #define START_TEST(name) main(int argc, char **argv) #define ok(condition, msg) assert(condition) -#define todo_wine +#define todo_wine if (0) +static void trace2(const char *s, const char *t) +{ + DWORD cbWritten; + char buf[512]; + sprintf(buf, s, t); + WriteFile(GetStdHandle(STD_ERROR_HANDLE), buf, strlen(buf), &cbWritten, NULL); +} +static void trace(const char *s) +{ + DWORD cbWritten; + char buf[512]; + sprintf(buf, "%s", s); + WriteFile(GetStdHandle(STD_ERROR_HANDLE), buf, strlen(buf), &cbWritten, NULL); +} #endif -#include <wtypes.h> -#include <windef.h> -#include <winbase.h> -#include <winerror.h> - #define PIPENAME "\\\\.\\PiPe\\tests_" __FILE__ + void test_CreateNamedPipeA(void) { HANDLE hnp; @@ -45,8 +62,9 @@ const char obuf[] = "Bit Bucket"; char ibuf[32]; DWORD written; - DWORD gelesen; + DWORD nbytes_read; + trace("test_CreateNamedPipe starting\n"); /* Bad parameter checks */ hnp = CreateNamedPipeA("not a named pipe", PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE|PIPE_WAIT, @@ -86,10 +104,8 @@ /* lpSecurityAttrib */ NULL); ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); - hFile = CreateFileA(PIPENAME, GENERIC_READ|GENERIC_WRITE, 0, - NULL, OPEN_EXISTING, 0, 0); - todo_wine - { + hFile = CreateFileA(PIPENAME, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, 0); + todo_wine { ok(hFile != INVALID_HANDLE_VALUE, "CreateFile failed"); } @@ -101,15 +117,15 @@ 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(ReadFile(hFile, ibuf, sizeof(obuf), &nbytes_read, NULL), "ReadFile"); + ok(nbytes_read == 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(ReadFile(hnp, ibuf, sizeof(obuf), &nbytes_read, NULL), "ReadFile"); + ok(nbytes_read == sizeof(obuf), "read file len"); ok(memcmp(obuf, ibuf, written) == 0, "content check"); /* Picky conformance tests */ @@ -148,9 +164,460 @@ } ok(CloseHandle(hnp), "CloseHandle"); + + trace("test_CreateNamedPipe returning\n"); +} + +void test_CreateNamedPipe_instances_must_match(void) +{ + HANDLE hnp, hnp2; + + /* Check no mismatch */ + hnp = CreateNamedPipeA(PIPENAME, PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 2, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + hnp2 = CreateNamedPipeA(PIPENAME, PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 2, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp2 != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + ok(CloseHandle(hnp), "CloseHandle"); + ok(CloseHandle(hnp2), "CloseHandle"); + + /* Check nMaxInstances */ + 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"); + + todo_wine { + hnp2 = CreateNamedPipeA(PIPENAME, PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 1, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp2 == INVALID_HANDLE_VALUE + && GetLastError() == ERROR_PIPE_BUSY, "nMaxInstances not obeyed"); + } + + ok(CloseHandle(hnp), "CloseHandle"); + + /* Check PIPE_ACCESS_* */ + hnp = CreateNamedPipeA(PIPENAME, PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 2, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + todo_wine { + hnp2 = CreateNamedPipeA(PIPENAME, PIPE_ACCESS_INBOUND, PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 1, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp2 == INVALID_HANDLE_VALUE + && GetLastError() == ERROR_ACCESS_DENIED, "PIPE_ACCESS_* mismatch allowed"); + } + + /* etc, etc */ +} + +/** implementation of alarm() */ +static DWORD CALLBACK alarmThreadMain(LPVOID arg) +{ + DWORD timeout = (DWORD) arg; + trace("alarmThreadMain\n"); + Sleep(timeout); + ok(FALSE, "alarm"); + ExitProcess(1); + return 1; +} + +HANDLE hnp = INVALID_HANDLE_VALUE; + +/** Trivial byte echo server - disconnects after each session */ +static DWORD CALLBACK serverThreadMain1(LPVOID arg) +{ + int i; + + trace("serverThreadMain1 start\n"); + /* Set up a simple echo server */ + hnp = CreateNamedPipeA(PIPENAME "serverThreadMain1", 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"); + for (i = 0; ; i++) { + char buf[512]; + DWORD written; + DWORD nbytes_read; + DWORD success; + + /* Wait for client to connect */ + trace("Server calling ConnectNamedPipe...\n"); + ok(ConnectNamedPipe(hnp, NULL) + || GetLastError() == ERROR_PIPE_CONNECTED, "ConnectNamedPipe"); + trace("ConnectNamedPipe returned.\n"); + + /* Echo bytes once */ + memset(buf, 0, sizeof(buf)); + + trace("Server reading...\n"); + success = ReadFile(hnp, buf, sizeof(buf), &nbytes_read, NULL); + trace("Server done reading.\n"); + ok(success, "ReadFile"); + trace2("Server read '%s'\n", buf); + ok(memcmp(buf, "client->server", 14) == 0, "content check"); + + trace("Server writing...\n"); + sprintf(buf, "server->client i %d ", i); + ok(WriteFile(hnp, buf, nbytes_read, &written, NULL), "WriteFile"); + trace("Server done writing.\n"); + ok(written == nbytes_read, "write file len"); + + /* finish this connection, wait for next one */ + trace("Server flushing.\n"); + todo_wine { + ok(FlushFileBuffers(hnp), "FlushFileBuffers"); + } + trace("Server disconnecting.\n"); + ok(DisconnectNamedPipe(hnp), "DisconnectNamedPipe"); + } +} + +/** Trivial byte echo server - closes after each connection */ +static DWORD CALLBACK serverThreadMain2(LPVOID arg) +{ + int i; + HANDLE hnpNext = 0; + + trace("serverThreadMain2\n"); + /* Set up a simple echo server */ + hnp = CreateNamedPipeA(PIPENAME "serverThreadMain2", PIPE_ACCESS_DUPLEX, + PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 2, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + for (i = 0; ; i++) { + char buf[512]; + DWORD written; + DWORD nbytes_read; + DWORD success; + + /* Wait for client to connect */ + trace("Server calling ConnectNamedPipe...\n"); + ok(ConnectNamedPipe(hnp, NULL) + || GetLastError() == ERROR_PIPE_CONNECTED, "ConnectNamedPipe"); + trace("ConnectNamedPipe returned.\n"); + + /* Echo bytes once */ + memset(buf, 0, sizeof(buf)); + + trace("Server reading...\n"); + success = ReadFile(hnp, buf, sizeof(buf), &nbytes_read, NULL); + trace("Server done reading.\n"); + ok(success, "ReadFile"); + + trace("Server writing...\n"); + ok(WriteFile(hnp, buf, nbytes_read, &written, NULL), "WriteFile"); + trace("Server done writing.\n"); + ok(written == nbytes_read, "write file len"); + + /* finish this connection, wait for next one */ + trace("Server flushing.\n"); + todo_wine { ok( FlushFileBuffers(hnp), "FlushFileBuffers"); } + trace("Server disconnecting.\n"); + ok(DisconnectNamedPipe(hnp), "DisconnectNamedPipe"); + + /* Set up next echo server */ + hnpNext = + CreateNamedPipeA(PIPENAME "serverThreadMain2", PIPE_ACCESS_DUPLEX, + PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 2, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + + ok(hnpNext != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + ok(CloseHandle(hnp), "CloseHandle"); + hnp = hnpNext; + } +} + +/** Trivial byte echo server - uses overlapped named pipe calls */ +static DWORD CALLBACK serverThreadMain3(LPVOID arg) +{ + int i; + HANDLE hEvent; + + trace("serverThreadMain3\n"); + /* Set up a simple echo server */ + hnp = CreateNamedPipeA(PIPENAME "serverThreadMain3", PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, + 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"); + + hEvent = CreateEvent(NULL, // security attribute + TRUE, // manual reset event + FALSE, // initial state + NULL); // name + ok(hEvent != NULL, "CreateEvent"); + + for (i = 0; ; i++) { + char buf[512]; + DWORD written; + DWORD nbytes_read; + DWORD dummy; + DWORD success; + OVERLAPPED oOverlap; + int letWFSOEwait = (i & 2); + int letGORwait = (i & 1); + DWORD err; + + memset(&oOverlap, 0, sizeof(oOverlap)); + oOverlap.hEvent = hEvent; + + /* Wait for client to connect */ + trace("Server calling overlapped ConnectNamedPipe...\n"); + success = ConnectNamedPipe(hnp, &oOverlap); + err = GetLastError(); + ok(success || err == ERROR_IO_PENDING + || err == ERROR_PIPE_CONNECTED, "overlapped ConnectNamedPipe"); + trace("overlapped ConnectNamedPipe returned.\n"); + if (!success && (err == ERROR_IO_PENDING) && letWFSOEwait) + ok(WaitForSingleObjectEx(hEvent, INFINITE, TRUE) == 0, "wait ConnectNamedPipe"); + success = GetOverlappedResult(hnp, &oOverlap, &dummy, letGORwait); + if (!letGORwait && !letWFSOEwait && !success) { + ok(GetLastError() == ERROR_IO_INCOMPLETE, "GetOverlappedResult"); + success = GetOverlappedResult(hnp, &oOverlap, &dummy, TRUE); + } + ok(success, "GetOverlappedResult ConnectNamedPipe"); + trace("overlapped ConnectNamedPipe operation complete.\n"); + + /* Echo bytes once */ + memset(buf, 0, sizeof(buf)); + + trace("Server reading...\n"); + success = ReadFile(hnp, buf, sizeof(buf), NULL, &oOverlap); + trace("Server ReadFile returned...\n"); + err = GetLastError(); + ok(success || err == ERROR_IO_PENDING, "overlapped ReadFile"); + trace("overlapped ReadFile returned.\n"); + if (!success && (err == ERROR_IO_PENDING) && letWFSOEwait) + ok(WaitForSingleObjectEx(hEvent, INFINITE, TRUE) == 0, "wait ReadFile"); + success = GetOverlappedResult(hnp, &oOverlap, &nbytes_read, letGORwait); + if (!letGORwait && !letWFSOEwait && !success) { + ok(GetLastError() == ERROR_IO_INCOMPLETE, "GetOverlappedResult"); + success = GetOverlappedResult(hnp, &oOverlap, &nbytes_read, TRUE); + } + trace("Server done reading.\n"); + ok(success, "overlapped ReadFile"); + + trace("Server writing...\n"); + success = WriteFile(hnp, buf, nbytes_read, NULL, &oOverlap); + trace("Server WriteFile returned...\n"); + err = GetLastError(); + ok(success || err == ERROR_IO_PENDING, "overlapped WriteFile"); + trace("overlapped WriteFile returned.\n"); + if (!success && (err == ERROR_IO_PENDING) && letWFSOEwait) + ok(WaitForSingleObjectEx(hEvent, INFINITE, TRUE) == 0, "wait WriteFile"); + success = GetOverlappedResult(hnp, &oOverlap, &written, letGORwait); + if (!letGORwait && !letWFSOEwait && !success) { + ok(GetLastError() == ERROR_IO_INCOMPLETE, "GetOverlappedResult"); + success = GetOverlappedResult(hnp, &oOverlap, &written, TRUE); + } + trace("Server done writing.\n"); + ok(success, "overlapped WriteFile"); + ok(written == nbytes_read, "write file len"); + + /* finish this connection, wait for next one */ + trace("Server flushing.\n"); + todo_wine { ok( FlushFileBuffers(hnp), "FlushFileBuffers"); } + trace("Server disconnecting.\n"); + ok(DisconnectNamedPipe(hnp), "DisconnectNamedPipe"); + } +} + +static void exercizeServer(const char *pipename, HANDLE serverThread) +{ + int i; + DWORD success; + + trace("exercizeServer starting\n"); + for (i = 0; i < 8; i++) { + HANDLE hFile; + char obuf[32]; + char ibuf[32]; + DWORD written; + DWORD nbytes_read; + int loop; + + for (loop = 0; loop < 3; loop++) { + DWORD err; + trace("Client connecting...\n"); + /* Connect to the server */ + hFile = CreateFileA(pipename, GENERIC_READ | GENERIC_WRITE, 0, + NULL, OPEN_EXISTING, 0, 0); + if (hFile != INVALID_HANDLE_VALUE) + break; + err = GetLastError(); + if (loop == 0) + ok(err == ERROR_PIPE_BUSY || err == ERROR_FILE_NOT_FOUND, "connecting to pipe"); + else + ok(err == ERROR_PIPE_BUSY, "connecting to pipe"); + trace("connect failed, retrying\n"); + Sleep(200); + } + ok(hFile != INVALID_HANDLE_VALUE, "client opening named pipe"); + + /* Make sure it can echo */ + memset(ibuf, 0, sizeof(ibuf)); + sprintf(obuf, "client->server i %d ", i); + trace2("Client writing '%s'...\n", obuf); + ok(WriteFile(hFile, obuf, sizeof(obuf), &written, NULL), "WriteFile to client end of pipe"); + ok(written == sizeof(obuf), "write file len"); + trace("Client reading...\n"); + success = ReadFile(hFile, ibuf, sizeof(ibuf), &nbytes_read, NULL); + if (!success) + printf("ReadFile(%p, %p, %d,,0) failed, err %ld\n", hFile, ibuf, sizeof(ibuf), GetLastError()); + trace2("Client read '%s'\n", ibuf); + ok(success, "ReadFile from client end of pipe"); + ok(nbytes_read == sizeof(obuf), "read file len"); + /*ok(memcmp(obuf, ibuf, written) == 0, "content check");*/ + + trace("Client closing...\n"); + ok(CloseHandle(hFile), "CloseHandle"); + } + + ok(TerminateThread(serverThread, 0), "TerminateThread"); + CloseHandle(hnp); + trace("exercizeServer returning\n"); +} + +void test_NamedPipe_2(void) +{ + HANDLE serverThread; + DWORD serverThreadId; + HANDLE alarmThread; + DWORD alarmThreadId; + + trace("test_NamedPipe_2 starting\n"); + /* Set up a ten second timeout */ + alarmThread = CreateThread(NULL, 0, alarmThreadMain, (void *) 10000, 0, &alarmThreadId); + + /* The servers we're about to exercize do try to clean up carefully, + * but to reduce the change of a test failure due to a pipe handle + * leak in the test code, we'll use a different pipe name for each server. + */ + + trace("Try server #1\n"); + serverThread = CreateThread(NULL, 0, serverThreadMain1, 0, 0, &serverThreadId); + ok(serverThread != INVALID_HANDLE_VALUE, "CreateThread"); + exercizeServer(PIPENAME "serverThreadMain1", serverThread); + + trace("Try server #2\n"); + serverThread = CreateThread(NULL, 0, serverThreadMain2, 0, 0, &serverThreadId); + ok(serverThread != INVALID_HANDLE_VALUE, "CreateThread"); + exercizeServer(PIPENAME "serverThreadMain2", serverThread); + + todo_wine { + trace("Try server #3\n"); + serverThread = CreateThread(NULL, 0, serverThreadMain3, 0, 0, &serverThreadId); + ok(serverThread != INVALID_HANDLE_VALUE, "CreateThread"); + exercizeServer(PIPENAME "serverThreadMain3", serverThread); + + ok(TerminateThread(alarmThread, 0), "TerminateThread"); + trace("test_NamedPipe_2 returning\n"); + } +} + +void test_DisconnectNamedPipe(void) +{ + HANDLE hnp; + HANDLE hFile; + const char obuf[] = "Bit Bucket"; + char ibuf[32]; + DWORD written; + DWORD nbytes_read; + + 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"); + + ok(WriteFile(hnp, obuf, sizeof(obuf), &written, NULL) == 0 + && GetLastError() == ERROR_PIPE_LISTENING, "WriteFile to not-yet-connected pipe"); + ok(ReadFile(hnp, ibuf, sizeof(ibuf), &nbytes_read, NULL) == 0 + && GetLastError() == ERROR_PIPE_LISTENING, "ReadFile from not-yet-connected pipe"); + + hFile = CreateFileA(PIPENAME, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, 0); + todo_wine { + ok(hFile != INVALID_HANDLE_VALUE, "CreateFile failed"); + } + + /* don't try to do i/o if one side couldn't be opened, as it hangs */ + if (hFile != INVALID_HANDLE_VALUE) { + + /* see what happens if server calls DisconnectNamedPipe + * when there are bytes in the pipe + */ + + ok(WriteFile(hFile, obuf, sizeof(obuf), &written, NULL), "WriteFile"); + ok(written == sizeof(obuf), "write file len"); + ok(DisconnectNamedPipe(hnp), "DisconnectNamedPipe while messages waiting"); + ok(WriteFile(hFile, obuf, sizeof(obuf), &written, NULL) == 0 + && GetLastError() == ERROR_PIPE_NOT_CONNECTED, "WriteFile to disconnected pipe"); + ok(ReadFile(hnp, ibuf, sizeof(ibuf), &nbytes_read, NULL) == 0 + && GetLastError() == ERROR_PIPE_NOT_CONNECTED, + "ReadFile from disconnected pipe with bytes waiting"); + ok(CloseHandle(hFile), "CloseHandle"); + } + + ok(CloseHandle(hnp), "CloseHandle"); + } START_TEST(pipe) { + trace("test 1 of 4:\n"); test_CreateNamedPipeA(); + trace("test 2 of 4:\n"); + test_CreateNamedPipe_instances_must_match(); + trace("test 3 of 4:\n"); + test_NamedPipe_2(); + trace("test 4 of 4:\n"); + test_DisconnectNamedPipe(); + trace("all tests done\n"); }

1 0

winelib on sparc?
by Robert Reif 18 Apr '03

18 Apr '03

I would like to do some winelib programming on a sparc and I'm struggling with a few concepts. winelib and wine are the same sources? When you build and run the tests in wine, are the tests really winelib apps? Has anyone really done this? The docs just say "uncharted territory" and don't go any further. I added code for my architecture and compile the wine source but get assembler errors on the spec files. Any help would be welcomed. Thanks, Bob.

1 0

Bug Hunting - uninstaller.exe on Win2K with uninstall information.
by Steven Edwards 18 Apr '03

18 Apr '03

Hello Everyone, This bug is a year+ old and I have not done much work on it untill now as I never could debug the stupid thing. This has always bothered me because this program should work fine under Win2K if we are compatible with the registry APIs and such. Does anyone have a idea as to what is going on? Here is the info from bug 1395 in bugzilla When running uninstaller built from Mingw or MS-VC++ 6 under Win2K the application seems to work and run fine when there is no information in the uninstall branch of the registry. As soon as a program is registered and uninstaller is run the program crashes. This has been tested on 3 systems and with many differnt sources and versions of Mingw. When debugging under MSVC with uninstall information in the registry the debugger stops at this code. FetchUninstallInformation() Line 225/226: entries[numentries-1].key = HeapAlloc(GetProcessHeap(), 0, strlen(subKeyName)+1); Entries : Cxx0030: Expression could not be evaluated I will attach a Visual Stdio build with sources/debugging information this evening. Thanks Steven

1 0

Re: remove server silliniess
by Bill Medland 18 Apr '03

18 Apr '03

On April 16, 2003 01:51 pm, Gregory M. Turner wrote: > remove run-time checks of compile-time constants. Why is that a silliness? I dearly wish that there were a way of doing compile-time assertion, but there isn't, so it has to be done by a runtime assertion. So it adds a tiny amount to the runtime. If that really bugs you then create a function of compile-time assertions and ensure that it gets called once only. Personally considering the current status of wine and the way we have to work on code that we don't really understand I am surprised at how few assertions there are (and lets not get started on internal code documentation) Or are you saying that assertions are a waste of time :-) -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

5 5

Re: docu: remove uber document
by Francois Gouget 18 Apr '03

18 Apr '03

On Thu, 17 Apr 2003, Dimitrie O. Paun wrote: [...] > Index: documentation/architecture.sgml > =================================================================== > RCS file: /home/wine/wine/documentation/architecture.sgml,v > retrieving revision 1.6 > diff -u -r1.6 architecture.sgml > --- documentation/architecture.sgml 1 Apr 2003 03:26:13 -0000 1.6 > +++ documentation/architecture.sgml 17 Apr 2003 22:09:52 -0000 > @@ -1029,6 +1029,5 @@ >  IMHO, rather than removing these lines, it would be better to modify them to attach the file to the proper book: wine-user.sgml or winelib-user.sgml. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

2 2

Re: rpc server patch
by Gregory M. Turner 18 Apr '03

18 Apr '03

On Thursday 17 April 2003 09:36 pm, Ove Kaaven wrote: > diff -u -r1.12 rpc_server.c > --- dlls/rpcrt4/rpc_server.c 18 Apr 2003 02:04:17 -0000 1.12 > +++ dlls/rpcrt4/rpc_server.c 18 Apr 2003 02:16:51 -0000 > @@ -285,11 +286,18 @@ > > static void RPCRT4_new_client(RpcConnection* conn) > { > - conn->thread = CreateThread(NULL, 0, RPCRT4_io_thread, conn, 0, NULL); > - if (!conn->thread) { > + HANDLE thread = CreateThread(NULL, 0, RPCRT4_io_thread, conn, 0, NULL); > + if (!thread) { > DWORD err = GetLastError(); > ERR("failed to create thread, error=%08lx\n", err); > + RPCRT4_DestroyConnection(conn); > } > + /* we could set conn->thread, but then we'd have to make the io_thread wait > + * for that, otherwise the thread might finish, destroy the connection, and > + * free the memory we'd write to before we did, causing crashes and stuff - > + * so let's implement that later, when we really need conn->thread */ > + > + CloseHandle( thread ); > } > > static DWORD CALLBACK RPCRT4_server_thread(LPVOID the_arg) great, I don't understand this underlying pipe issue yet, but somehow, I'm betting this was just what the doctor ordered to get RPC back in on its feet ... thanks! btw, if you have kludgy patches that you would like to get back to wine, I reccomend you post them to wine-devel, which differentiates "not ready" from "ready" patches (that's just how I do it -- for all I know, this might contradict some official guideline). -- gmt "Democracy is the theory that holds that the common people know what they want, and deserve to get it good and hard." HL Mencken

1 0

Re: remove server silliniess
by John K. Hohm 18 Apr '03

18 Apr '03

Thus spake "Gregory M. Turner" <gmturner007(a)ameritech.net>: > ah, the hidden powers of the preprocessor -- how it drives us to obsfucation > with it's robotic stupidity... I wonder, is cpp a turing machine? Makes me > want to implement vim as a sed script ;) I don't think so. However, the C++ compile-time template mechanism *is* a turing machine (proof omitted). That is a persuasive argument, but I'm not sure if it's for or against C++.

1 0

winecfg kickoff
by Dimitrie O. Paun 17 Apr '03

17 Apr '03

Hi Alexandre, I have a little (and hopefully not too controversial :) suggesting on how to kickoff our little winecfg utility. Namely, we need to get the load/save from/to registry code going. To do so, we need the regisry key structure in place. Item C1 says "Merge configuration into the registry": http://www.dssd.ca/wine/Wine-0.9-TODO.html#conf So here's my proposal: 1. Do C1 now, but keep the current configuration in place 2. Label the conf file in CVS, to know when we merged it 3. Work on winecfg to load/save stuff properly 4. When done, compare the current version of the conf file with the labeled one, to see what's changed. 5. Adapt winecfg to the new changes 6. Drop the old config file Now, if this sounds like a plan, I was hopeing you could do (1) & (2) as it seems you have an idea where things should end up :) (and because only you can label stuff in CVS). Hopefully people will pick up on (3), if not I guess I can take a look, time permitting. -- Dimi.

2 1

Re: my dmusic and dpnhpast work, revised and resent
by Alexandre Julliard 17 Apr '03

17 Apr '03

"Rok Mandeljc" <rokmandeljc(a)hotmail.com> writes: > I just found out that my dpnhpast patch doesn't apply to current cvs tree > (msvcrtd implementation changed Makefile.in and configure). This also mean > that dmusic patch I've sent won't apply either. So I'm sending it again, > this time in one patch. It *should* apply to (today's) cvs cleanly. I have applied all the new dlls, but not the dmusic stubs. I think you should try to group related interfaces in the same source file (and possibly merge some of the existing files too), we can't have 40 different source files for a stub dll. A dozen files is the maximum IMO. -- Alexandre Julliard julliard(a)winehq.com

5 8

Re: Set TZ environment variable when not set
by Rein Klazes 17 Apr '03

17 Apr '03

On Wed, 16 Apr 2003 21:05:28 +0200, you wrote: > Changelog: > memory/environ.c: build_environment > Set the TZ value to GMT0, if TZ is not set > > Synplify.exe from the Quicklogic FPGA suite refused to work with the demo > license. Setting TZ to any value made it work. GMT0 should be a good > approach. > > Awaiting the "flame war" about noise level for that silent change :-) Uwe, Some programs, like Agent email/news client that I use, check the existence of TZ before attempting other timezone API call's. With your patch Agent displays all times in UTC, which is not making me happy. A correct patch should take care of the local timezone and daylight saving. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 4

Re: Initialise tid in WIN_CreateDesktopWindow
by Alexandre Julliard 17 Apr '03

17 Apr '03

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > windows/win.c: WIN_CreateDesktopWindow > Initialise pWndDesktop->tid > > This makes the Xilinx command line tools run with ttydrv This is wrong, the desktop should not be owned by the current thread. What's the problem with Xilinx? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine/ files/dos_fs.c dlls/kernel/tests/file.c
by Uwe Bonnes 17 Apr '03

17 Apr '03

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)wine.codeweavers.com> writes: Alexandre> ChangeSet ID: 7890 CVSROOT: /opt/cvs-commit Module name: wine Alexandre> Changes by: julliard(a)wine.codeweavers.com 2003/04/16 21:10:04 Alexandre> Modified files: files : dos_fs.c dlls/kernel/tests: file.c Alexandre> Log message: Uwe Bonnes Alexandre> <bon(a)elektron.ikp.physik.tu-darmstadt.de> FindFirstFile on Alexandre> root directory should fail. Alexandre> Patch: http://cvs.winehq.com/patch.py?id=7890 @@ -1937,7 +1937,6 @@ UINT codepage; data->dwReserved0 = data->dwReserved1 = 0x0; - if (!lpFileName) return 0; if (lpFileName[0] == '\\' && lpFileName[1] == '\\') { ERR("UNC path name\n"); This first patch thunk wasn't in the patch I sent. Is this intentional? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: wine/include/msvcrt malloc.h
by Dimitrie O. Paun 17 Apr '03

17 Apr '03

On Wed, 16 Apr 2003, Alexandre Julliard wrote: > Log message: > Fixed alloca handling the way mingw does it (reported by Vincent > Béron). > #ifndef USE_MSVCRT_PREFIX > -static inline void* alloca(MSVCRT(size_t) i) { return _alloca(i); } > +# ifdef __GNUC__ > +# define _alloca(x) __builtin_alloca((x)) > +# define alloca(x) __builtin_alloca((x)) > +# endif > #endif /* USE_MSVCRT_PREFIX */ If we know it's GNUC, isn't it better to use the alias feature, so we don't run into problems with the macros, like we use to? -- Dimi.

2 1

RE: What happend to the Stdole2 / Stdole32 (RESEND) patch fromRobert Shearman
by Robert Shearman 17 Apr '03

17 Apr '03

> -----Original Message----- > From: Uwe Bonnes [mailto:bon@elektron.ikp.physik.tu-darmstadt.de] > Sent: 02 April 2003 14:40 > To: Robert Shearman > Subject: Re: What happend to the Stdole2 / Stdole32 (RESEND) patch > fromRobert Shearman > > > >>>>> "Robert" == Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > > >> what happend to the stdole32.tlb patch that Robert sent > around 22.1? > Robert> It was rejected on the grounds that we shouldn't have binary > Robert> files in CVS and we can't generate the .tlb files at > the moment. > > Did you generate the files from some source you wrote? Yes. > What compiler was used? MkTypLib from MS Platform SDK > What constraints are put on distributing those generated files? None, as far as I could tell. > The present need for stdole*.tlb from a windows installation is > unsatisfactory. Agreed. > Bye > > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Hope this helps and sorry for not getting back to you sooner, Rob

1 0

Winelib MFC?
by Christopher Thielen 17 Apr '03

17 Apr '03

Hello, I've written an application in MFC which runs beautifully in wine. I'd like to distribute a Winelib version, so Unix users don't need wine. Can I recompile MFC applications with Winelib? Is this possible? -- chris (chris(a)luethy.net)

3 4

wild pointers in current named pipe implementation?
by Dan Kegel 17 Apr '03

17 Apr '03

I know Mike is planning to rewrite the named pipe implementation, but the current implementation could use a little love while we're waiting for the new one. So I'm looking into the recent user complaint about FlushFileBuffers and named pipes, in hopes I can find a very simple patch that will tide us over until the new named pipes code is ready (whenever that might be; Mike's busy on other things at the moment). So I added an early call to FlushFileBuffers in the named pipe regression test (see attached patch). While poking around in wineserver, I found a few places where pointers were not set to NULL after being invalidated, and after I added the missing statements to set them to NULL, wineserver started behaving badly on the regression test. A run of wineserver under valgrind showed a null pointer access, so I added a couple null pointer check asserts (see attached patch). And sure enough, they fire. So the question is -- did I screw up, or did I uncover a real issue? The answer will help me as I continue digging into the FlushFileBuffers named pipe bug report (and testing possible simple enhancements to the current named pipe implementation). Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 Index: server/object.c =================================================================== RCS file: /home/wine/wine/server/object.c,v retrieving revision 1.27 diff -d -u -r1.27 object.c --- server/object.c 19 Feb 2003 00:33:33 -0000 1.27 +++ server/object.c 14 Apr 2003 16:59:45 -0000 @@ -193,6 +193,7 @@ struct object *grab_object( void *ptr ) { struct object *obj = (struct object *)ptr; + assert( obj ); assert( obj->refcount < INT_MAX ); obj->refcount++; return obj; Index: server/named_pipe.c =================================================================== RCS file: /home/wine/wine/server/named_pipe.c,v retrieving revision 1.22 diff -d -u -r1.22 named_pipe.c --- server/named_pipe.c 4 Apr 2003 22:26:34 -0000 1.22 +++ server/named_pipe.c 14 Apr 2003 16:59:45 -0000 @@ -163,6 +163,7 @@ static struct fd *pipe_user_get_fd( struct object *obj ) { struct pipe_user *user = (struct pipe_user *)obj; + assert(user->fd); return (struct fd *)grab_object( user->fd ); } @@ -200,8 +201,11 @@ if (user->prev) user->prev->next = user->next; else user->pipe->users = user->next; if (user->thread) release_object(user->thread); + user->thread = NULL; release_object(user->pipe); + user->pipe = NULL; if (user->fd) release_object( user->fd ); + user->fd = NULL; } static int pipe_user_get_poll_events( struct fd *fd ) Index: dlls/kernel/tests/pipe.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/pipe.c,v retrieving revision 1.2 diff -d -u -r1.2 pipe.c --- dlls/kernel/tests/pipe.c 25 Feb 2003 03:56:43 -0000 1.2 +++ dlls/kernel/tests/pipe.c 14 Apr 2003 16:59:45 -0000 @@ -86,6 +86,10 @@ /* lpSecurityAttrib */ NULL); ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + if (!FlushFileBuffers(hnp)) { + /* we'll add a check here once we know how windows behaves */ + fprintf(stderr, "FlushFileBuffers on new pipe failed, err %d\n", GetLastError()); + } hFile = CreateFileA(PIPENAME, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, 0); todo_wine

5 14

Re: Duplicate messages
by Michal Janusz Miroslaw 17 Apr '03

17 Apr '03

> I receive duplicate messages with following headers. Could people please > look after their setup? It's my fault. Apologies for everyone. My fetchmail went crazy and I wasn't fast enough to stop it. :( -- Michal Miroslaw

1 0

Duplicate messages
by Uwe Bonnes 17 Apr '03

17 Apr '03

Hallo, I receive duplicate messages with following headers. Could people please look after their setup? Thanks Return-Path: <wine-devel-admin(a)winehq.com> Received: from mailserver2.hrz.tu-darmstadt.de (mailserver2.hrz.tu-darmstadt.de [130.83.22.129]) by elektron.ikp.physik.tu-darmstadt.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id h3HDs0j28561 for <bon(a)elektron.ikp.physik.tu-darmstadt.de>; Thu, 17 Apr 2003 15:54:00 +0200 Received: from ziemniak.ustronie.pw.edu.pl (czuby.resetnet.pl [62.233.189.254]) by mailserver2.hrz.tu-darmstadt.de (8.12.9/8.12.8) with ESMTP id h3HDqNdj008074 for <bon(a)elektron.ikp.physik.tu-darmstadt.de>; Thu, 17 Apr 2003 15:52:25 +0200 Received: (qmail 7122 invoked by uid 1000); 17 Apr 2003 13:56:56 -0000 Received: from mion.elka.pw.edu.pl [194.29.160.35] by localhost with IMAP (fetchmail-6.2.2) for mirq-forwarded@localhost (single-drop); Thu, 17 Apr 2003 15:56:55 +0200 (CEST) Received: from [198.144.4.3] ([198.144.4.3]:39372 "EHLO wine.codeweavers.com") by mion.elka.pw.edu.pl with ESMTP id <S318308AbTDQAbg>; Thu, 17 Apr 2003 02:31:36 +0200 Received: from localhost.localdomain (wine [127.0.0.1]) by wine.codeweavers.com (8.11.6/8.11.6) with ESMTP id h3H0BHG22385; Wed, 16 Apr 2003 19:11:17 -0500 Received: from mail.wine.dyndns.org (adsl-64-142-4-165.sonic.net [64.142.4.165]) by wine.codeweavers.com (8.11.6/8.11.6) with ESMTP id h3H0A5G22281 for <wine-devel(a)winehq.com>; Wed, 16 Apr 2003 19:10:05 -0500 -- 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: wineinstall: use pwd and drop ttydrv
by Steven Edwards 17 Apr '03

17 Apr '03

--- Vincent B�ron <vberon(a)mecano.gme.usherb.ca> wrote: > Testing as shown that either x11drv or ttydrv could be set, even without > X present, as long as the app doesn't use user or gdi. > Also, the second change allows to build from anywhere, not limited to > one of the pre-mapped drives. > > Changelog: > Don't change to ttydrv to install registry, regedit doesn't use X. > Make sure the current dir is mapped in DOS. regedit will use user32 and friends if the ReactOS changes are merged in. ATM our regedit is read only when you use the GUI but you can still use the command-line for writes. __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com

1 0

winsock.h portability patch causing portability problem
by Gerald Pfeifer 17 Apr '03

17 Apr '03

Alexandre, I am afraid the following patch revision 1.52 date: 2003/03/31 23:56:35; author: julliard; state: Exp; lines: +63 -60 Try to make winsock.h more portable (based on a patch by Francois Gouget). actually caused a portability problem for FreeBSD. /usr/bin/gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -fPIC -D_REENTRANT -o pipe.o pipe.c In file included from ../../../include/winsock2.h:47, from ../../../include/windows.h:62, from ../../../include/rpc.h:22, from ../../../include/wtypes.h:2, from pipe.c:34: ../../../include/winsock.h:925: conflicting types for `htonl' /usr/include/machine/endian.h:63: previous declaration of `htonl' ../../../include/winsock.h:926: conflicting types for `htons' /usr/include/machine/endian.h:64: previous declaration of `htons' ../../../include/winsock.h:927: conflicting types for `ntohl' /usr/include/machine/endian.h:65: previous declaration of `ntohl' ../../../include/winsock.h:928: conflicting types for `ntohs' /usr/include/machine/endian.h:66: previous declaration of `ntohs' gmake[3]: *** [pipe.o] Error 1 gmake[3]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/kernel/tests' gmake[2]: *** [tests] Error 2 gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/kernel' The FreeBSD declarations are unsigned long htonl __P((unsigned long)); unsigned short htons __P((unsigned short)); unsigned long ntohl __P((unsigned long)); unsigned short ntohs __P((unsigned short)); Sorry, Gerald

2 6

Re: Set TZ environment variable when not set
by Alexandre Julliard 17 Apr '03

17 Apr '03

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Changelog: > memory/environ.c: build_environment > Set the TZ value to GMT0, if TZ is not set > > Synplify.exe from the Quicklogic FPGA suite refused to work with the demo > license. Setting TZ to any value made it work. You should set it in your environment then, this doesn't belong in Wine. -- Alexandre Julliard julliard(a)winehq.com

4 4

RE: remove server silliniess
by Patrik Stridvall 17 Apr '03

17 Apr '03

> On Thursday 17 April 2003 02:13 am, Fabian Cenedese wrote: > > >> remove run-time checks of compile-time constants. > > > > > >I dearly wish that there were a way of doing compile-time > assertion, but > > > there isn't, so it has to be done by a runtime assertion. > > > > Well, there seem to be some reasonable tricks for that: > > http://www.jaggersoft.com/pubs/CVu11_3.html > > http://www.panelsoft.com/murphyslaw/apr01.htm > > > > This is for C++ but maybe also adaptable for C: > > http://www.boost.org/libs/static_assert/static_assert.htm > > > > bye Fabi > > ah, the hidden powers of the preprocessor -- how it drives us > to obsfucation > with it's robotic stupidity... I wonder, is cpp a turing > machine? I don't think so. > Makes me > want to implement vim as a sed script ;) :-) > nonetheless, considering one must sometimes make do with what > one has, that > array-of-zero trick is super-clever... perhaps I'll actually make a > constructive patch out of this debacle yet.. Note that Wine already have a macro for this that is not a Wine specific invention but is rather a feature of the Win32 API. >From include/winnt.h: /* Compile time assertion */ #if defined(_MSC_VER) # define C_ASSERT(e) typedef char __C_ASSERT__[(e)?1:-1] #elif defined(__GNUC__) # define C_ASSERT(e) extern char __C_ASSERT__[(e)?1:-1] #endif

1 0

winedbg regression?
by Mike Hearn 17 Apr '03

17 Apr '03

Hi, For the past week or so winedbg has refused to start, it just hangs whenever it tries to attach to a pid. Some traces indicate it's getting an access denied error when trying to attach? Not sure why i'd be getting that. I thought it was just my tree at first but Splinter on IRC says he has the same problem. Does anybody else see this?

6 9

Re: div in msvcrt
by Alexandre Julliard 17 Apr '03

17 Apr '03

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > This was in msvcrt/stdlib.h since version 1.1, probably straight from > mingw. It caused some problems because div_t is a structure, not a long > long (same thing for ldiv_t). > > Changelog: > Fixed the definition of div/ldiv. This won't work, the calling sequence on i386 is not compatible. I'm not sure there's a good solution for that one... -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Set TZ environment variable when not set
by Michael Stefaniuc 16 Apr '03

16 Apr '03

On Wed, Apr 16, 2003 at 09:05:28PM +0200, Uwe Bonnes wrote: > Changelog: > memory/environ.c: build_environment > Set the TZ value to GMT0, if TZ is not set > > Synplify.exe from the Quicklogic FPGA suite refused to work with the demo > license. Setting TZ to any value made it work. GMT0 should be a good > approach. > > Awaiting the "flame war" about noise level for that silent change :-) Well, can't help with that but we could start a new flame war about why UTC is better for this then GMT0. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

3 4

Re: Fallback to ttydrv (third attempt)
by Alexandre Julliard 16 Apr '03

16 Apr '03

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Index: wine/dlls/user/user_main.c > =================================================================== > RCS file: /home/wine/wine/dlls/user/user_main.c,v > retrieving revision 1.50 > diff -u -r1.50 user_main.c > --- wine/dlls/user/user_main.c 3 Dec 2002 23:34:54 -0000 1.50 > +++ wine/dlls/user/user_main.c 15 Apr 2003 11:05:08 -0000 > { > count = sizeof(buffer); > RegQueryValueExA( hkey, "GraphicsDriver", 0, &type, buffer, &count ); > + count = sizeof(buffer2); > + RegQueryValueExA( hkey, "TTYdrvFallback", 0, &type, buffer2, &count ); > RegCloseKey( hkey ); > } > + > + if (!strcasecmp("x11drv",buffer) && > + (GetEnvironmentVariableA("DISPLAY",buffer1,MAX_PATH-1) == 0) && > + !strcasecmp("y",buffer2)) USER has no business checking the DISPLAY variable, that's an X11 thing. The right way to do this would be to make x11drv fail its initialization in that case, and have USER check for that. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: winedbg improvement - display
by Pouech Eric DMI AEI CAEN 16 Apr '03

16 Apr '03

> Objet : winedbg improvement - display > I've just hacked winedbg 'display' handling. It now allows for temporary > disabling of displays and restricting them to one function. Look for > yourselves, comments welcome. :) since I'm away from home on a poor remote connection, I couldn't spend much time on this from a first look, enable/disable facility is fine but, here are, at least, two remarks : - first, I don't think we should have two ways of expressing the same thing (like disable display 1 and display disable 1). IMO, we should stick the former form (as we currently do) (I agree that current undisplay 1 and delete display 1 are may be a bit overkill too) - secondly, and most important, I don't like storing the frame context in the display information. I don't see how you're going to ensure that we got a correct context for evaluating an expression. Keeping the local frame name isn't even sufficient when calling the same function recursively. What I'm afraid of here is the user's perception of this specific context for evaluation. I know gdb has some of those tricks (i.e. that no one, except the one who wrote the code, is going to understand what context is going to be used for evaluating the expression). I really wonder what gdb does here. A+

2 1

Re: remove server silliniess
by Alexandre Julliard 16 Apr '03

16 Apr '03

"Gregory M. Turner" <gmturner007(a)ameritech.net> writes: > remove run-time checks of compile-time constants. What's wrong with that? and how do you propose to do the check then? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: WineHQ: whitespace
by Jeremy Newman 16 Apr '03

16 Apr '03

On Tue, 2003-04-15 at 14:55, Dimitrie O. Paun wrote: > Jer, > > When you apply my patches, please try to no change the whitespace, as it > creates conflicts on my side, and I can't tell if you've changed anything. > > I think you applied my patches from Windows, and the line endings changed, > or something like that. Please don't accuse me of using Windows. I would never do such a thing. ;) The problem comes from copy/paste the patch from my email prog (Evolution) to my text editor (Anjuta). I my web code, I prefer to use 4 spaces for indenting, no tab characters please. Don't give me the spaces take more time to transfer over http crap, our web server uses gzip encoding. <g> The patch was rejected by the patch command, so I had to manually line by line apply it (ish). In the future, attachments will be preferred for patches. I may just decide to not apply them otherwise.

3 4

Re: Keyboard Problem solved, one solution ...
by Dmitry Timoshkov 16 Apr '03

16 Apr '03

"Duncan Rubinger" <duncan(a)semanticedge.de> wrote: > I have a german keyboard layout and I'm using RH9 and KDE 3.1 > > After trying out some Keyboard layout settings I got the idea to > change one entry: > > From: > /*AltGrMask = event->state & 0x6000;*/ > > To: > AltGrMask = event->state; > > Now it works. Looks reasonable to me. Probably we have to be a bit picky what flags we want to save/restore. Does the attached patch work for you? -- Dmitry.

1 0

!IsWindowVisible && SetMenu
by Michal Janusz Miroslaw 16 Apr '03

16 Apr '03

When an app creates window without a menu, and later adds the menu without showing the window first, window's size doesn't update. Removing one if() in menu.c (as in patch attached) fixes it. (At least in DesignWorks 3.20. The app still hangs after showing it's windows, but at least menu is ok :). Is it a good fix, or the update should happen somewhere else when window is not visible ? -- Michal Miroslaw Index: controls/menu.c =================================================================== RCS file: /home/wine/wine/controls/menu.c,v retrieving revision 1.163 diff -u -r1.163 menu.c --- controls/menu.c 7 Mar 2003 23:03:27 -0000 1.163 +++ controls/menu.c 16 Apr 2003 09:43:49 -0000 @@ -3779,7 +3779,6 @@ } SetWindowLongA( hWnd, GWL_ID, (LONG_PTR)hMenu ); - if (IsWindowVisible(hWnd)) SetWindowPos( hWnd, 0, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE | SWP_NOZORDER | SWP_FRAMECHANGED ); return TRUE;

1 0

Re: winedbg regression?
by Mike Hearn 16 Apr '03

16 Apr '03

> I had this one: > [Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 996976720 > "Auto"="1" > "Debugger"="winedbg.exe --debugmsg -all %ld %ld" > > removing the '.exe' and adding --auto did not help. But i found the patch that > broke winedbg for me: > > http://www.winehq.com/hypermail/wine-cvs/2003/03/0371.html Hmm, more of Alexandres deep threading code. I don't really want to unapply that as I have no idea what it does or what its dependancies are. Alexandre, could you take a look at why this patch might have broken winedbg? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

winedbg improvement - display
by Michal Janusz Miroslaw 16 Apr '03

16 Apr '03

I've just hacked winedbg 'display' handling. It now allows for temporary disabling of displays and restricting them to one function. Look for yourselves, comments welcome. :) Patch follows, -- Michal Miroslaw index: programs/winedbg/Makefile.in =================================================================== RCS file: /home/wine/wine/programs/winedbg/Makefile.in,v retrieving revision 1.2 diff -u -r1.2 Makefile.in --- programs/winedbg/Makefile.in 15 Dec 2002 01:19:53 -0000 1.2 +++ programs/winedbg/Makefile.in 16 Apr 2003 03:04:56 -0000 @@ -31,6 +31,8 @@ @MAKE_PROG_RULES@ +DEFS += -DYYERROR_VERBOSE + y.tab.c y.tab.h: dbg.y $(YACC) -d -t $(SRCDIR)/dbg.y Index: programs/winedbg/dbg.y =================================================================== RCS file: /home/wine/wine/programs/winedbg/dbg.y,v retrieving revision 1.9 diff -u -r1.9 dbg.y --- programs/winedbg/dbg.y 1 Apr 2003 00:12:50 -0000 1.9 +++ programs/winedbg/dbg.y 16 Apr 2003 03:04:56 -0000 @@ -52,8 +52,6 @@ %token tCONT tPASS tSTEP tLIST tNEXT tQUIT tHELP tBACKTRACE tINFO tWALK tUP tDOWN %token tENABLE tDISABLE tBREAK tWATCH tDELETE tSET tMODE tPRINT tEXAM tABORT tVM86 -%token tCLASS tMAPS tMODULE tSTACK tSEGMENTS tSYMBOL tREGS tWND tLOCAL tEXCEPTION -%token tPROCESS tTHREAD tEOL tEOF %token tCLASS tMAPS tMODULE tSTACK tSEGMENTS tSYMBOL tREGS tWND tQUEUE tLOCAL tEXCEPTION %token tPROCESS tTHREAD tMODREF tEOL tEOF %token tFRAME tSHARE tCOND tDISPLAY tUNDISPLAY tDISASSEMBLE @@ -137,13 +135,6 @@ | tSHOW tDIR tEOL { DEBUG_ShowDir(); } | tDIR pathname tEOL { DEBUG_AddPath( $2 ); } | tDIR tEOL { DEBUG_NukePath(); } - | tDISPLAY tEOL { DEBUG_InfoDisplay(); } - | tDISPLAY expr tEOL { DEBUG_AddDisplay($2, 1, 0); } - | tDISPLAY tFORMAT expr tEOL{ DEBUG_AddDisplay($3, $2 >> 8, $2 & 0xff); } - | tDELETE tDISPLAY tNUM tEOL{ DEBUG_DelDisplay( $3 ); } - | tDELETE tDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } - | tUNDISPLAY tNUM tEOL { DEBUG_DelDisplay( $2 ); } - | tUNDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } | tCOND tNUM tEOL { DEBUG_AddBPCondition($2, NULL); } | tCOND tNUM expr tEOL { DEBUG_AddBPCondition($2, $3); } | tSOURCE pathname tEOL { DEBUG_Parser($2); } @@ -154,6 +145,7 @@ | tDETACH tEOL { return DEBUG_Detach(); /* FIXME: we shouldn't return, but since we cannot simply clean the symbol table, exit debugger for now */ } | list_command | disassemble_command + | display_command | set_command | x_command | print_command @@ -163,6 +155,22 @@ | walk_command | run_command | noprocess_state + ; + +display_command: + | tDISPLAY tEOL { DEBUG_InfoDisplay(); } + | tDISPLAY expr tEOL { DEBUG_AddDisplay($2, 1, 0, FALSE); } + | tDISPLAY tFORMAT expr tEOL{ DEBUG_AddDisplay($3, $2 >> 8, $2 & 0xff, FALSE); } + | tDISPLAY tLOCAL expr tEOL { DEBUG_AddDisplay($3, 1, 0, TRUE); } + | tDISPLAY tLOCAL tFORMAT expr tEOL { DEBUG_AddDisplay($4, $3 >> 8, $3 & 0xff, TRUE); } + | tDISPLAY tDELETE tNUM tEOL{ DEBUG_DelDisplay( $3 ); } + | tDISPLAY tDELETE tEOL { DEBUG_DelDisplay( -1 ); } + | tDISPLAY tENABLE tNUM tEOL{ DEBUG_EnableDisplay( $3, TRUE ); } + | tDISPLAY tDISABLE tNUM tEOL { DEBUG_EnableDisplay( $3, FALSE ); } + | tDELETE tDISPLAY tNUM tEOL{ DEBUG_DelDisplay( $3 ); } + | tDELETE tDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } + | tUNDISPLAY tNUM tEOL { DEBUG_DelDisplay( $2 ); } + | tUNDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } ; set_command: Index: programs/winedbg/debug.l =================================================================== RCS file: /home/wine/wine/programs/winedbg/debug.l,v retrieving revision 1.3 diff -u -r1.3 debug.l --- programs/winedbg/debug.l 30 Jan 2003 00:24:18 -0000 1.3 +++ programs/winedbg/debug.l 16 Apr 2003 03:04:56 -0000 @@ -58,6 +58,7 @@ %s WALK_CMD %s SHOW_CMD %s MODE_CMD +%s DISP_CMD %s NOCMD %x ASTRING_EXPECTED @@ -86,12 +87,12 @@ "0x"{HEXDIGIT}+ { sscanf(yytext, "%x", &yylval.integer); return tNUM; } {DIGIT}+ { sscanf(yytext, "%d", &yylval.integer); return tNUM; } -<FORMAT_EXPECTED>"/"{DIGIT}+{FORMAT} { char* last; +<DISP_CMD,FORMAT_EXPECTED>"/"{DIGIT}+{FORMAT} { char* last; yylval.integer = strtol( yytext+1, &last, 0 ) << 8; yylval.integer |= *last; return tFORMAT; } -<FORMAT_EXPECTED>"/"{FORMAT} { yylval.integer = (1 << 8) | yytext[1]; return tFORMAT; } +<DISP_CMD,FORMAT_EXPECTED>"/"{FORMAT} { yylval.integer = (1 << 8) | yytext[1]; return tFORMAT; } {STRING} { yylval.string = DEBUG_MakeSymbol(yytext); return tSTRING; } <ASTRING_EXPECTED>[^\n]+ { char* p = yytext; while (*p == ' ' || *p == '\t') p++; @@ -105,7 +106,7 @@ <INITIAL>enable|enabl|enab|ena { BEGIN(NOCMD); return tENABLE;} <INITIAL>disable|disabl|disab|disa|dis { BEGIN(NOCMD); return tDISABLE; } <INITIAL>disassemble|disassembl|disassemb|disassem|disasse|disass|disas { BEGIN(NOCMD); return tDISASSEMBLE; } -<INITIAL,INFO_CMD,DEL_CMD>display|displa|displ|disp { BEGIN(FORMAT_EXPECTED); return tDISPLAY; } +<INITIAL,INFO_CMD,DEL_CMD>display|displa|displ|disp { BEGIN(DISP_CMD); return tDISPLAY; } <INITIAL>undisplay|undispla|undispl|undisp|undis|undi|und { BEGIN(NOCMD); return tUNDISPLAY; } <INITIAL>delete|delet|dele|del { BEGIN(DEL_CMD); return tDELETE; } <INITIAL,NOPROCESS>quit|qui|qu|q { BEGIN(NOCMD); return tQUIT; } @@ -155,6 +156,11 @@ <INFO_CMD,WALK_CMD>window|windo|wind|win|wnd { return tWND; } <HELP_CMD>info|inf|in { return tINFO; } <MODE_CMD>vm86 { return tVM86; } +<DISP_CMD>local { BEGIN(FORMAT_EXPECTED); return tLOCAL; } +<DISP_CMD>delete|delet|dele|del { BEGIN(NOCMD); return tDELETE; } +<DISP_CMD>enable|enabl|enab|ena|en { BEGIN(NOCMD); return tENABLE; } +<DISP_CMD>disable|disabl|disab|disa|dis { BEGIN(NOCMD); return tDISABLE; } + <INITIAL,SHOW_CMD>directories|directorie|directori|director|directo|direct|direc|direc|dir { BEGIN(PATH_EXPECTED); return tDIR; } Index: programs/winedbg/debugger.h =================================================================== RCS file: /home/wine/wine/programs/winedbg/debugger.h,v retrieving revision 1.9 diff -u -r1.9 debugger.h --- programs/winedbg/debugger.h 1 Apr 2003 00:02:36 -0000 1.9 +++ programs/winedbg/debugger.h 16 Apr 2003 03:04:56 -0000 @@ -327,10 +327,11 @@ extern int DEBUG_ReadLine(const char* pfx, char* buffer, int size); /* debugger/display.c */ -extern int DEBUG_DoDisplay(void); -extern int DEBUG_AddDisplay(struct expr * exp, int count, char format); -extern int DEBUG_DelDisplay(int displaynum); -extern int DEBUG_InfoDisplay(void); +int DEBUG_DoDisplay(void); +int DEBUG_AddDisplay(struct expr * exp, int count, char format, int local_frame); +int DEBUG_DelDisplay(int displaynum); +int DEBUG_InfoDisplay(void); +int DEBUG_EnableDisplay(int displaynum, int enable); /* debugger/expr.c */ extern void DEBUG_FreeExprMem(void); @@ -386,6 +387,7 @@ struct datatype * type); extern BOOL DEBUG_Normalize(struct name_hash * nh ); void DEBUG_InfoSymbols(const char* str); +const char *DEBUG_GetSymbolName(const struct name_hash *); /* debugger/info.c */ extern void DEBUG_PrintBasic( const DBG_VALUE* value, int count, char format ); Index: programs/winedbg/display.c =================================================================== RCS file: /home/wine/wine/programs/winedbg/display.c,v retrieving revision 1.1 diff -u -r1.1 display.c --- programs/winedbg/display.c 13 Sep 2002 17:54:28 -0000 1.1 +++ programs/winedbg/display.c 16 Apr 2003 03:04:56 -0000 @@ -2,6 +2,7 @@ * File display.c - display handling for Wine internal debugger. * * Copyright (C) 1997, Eric Youngdale. + * Improved a bit by Michał Mirosław. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -27,130 +28,172 @@ #include <stdarg.h> -#define MAX_DISPLAY 25 +#define DISPTAB_DELTA 8 /* needs to be power of 2, search for MARK to see why :) */ -struct display -{ - struct expr * exp; - int count; - char format; +struct display { + struct expr *exp; + int count; + char format; + char enabled; + struct name_hash *frame_name; }; -static struct display displaypoints[MAX_DISPLAY]; +static struct display *displaypoints = NULL; +static unsigned int maxdisplays = 0, ndisplays = 0; -int -DEBUG_AddDisplay(struct expr * exp, int count, char format) +static struct name_hash *DEBUG_GetCurrentFrameName(void) { - int i; + struct name_hash *name; + unsigned int eip, ebp; - /* - * First find a slot where we can store this display. - */ - for(i=0; i < MAX_DISPLAY; i++ ) - { - if( displaypoints[i].exp == NULL ) - { - displaypoints[i].exp = DEBUG_CloneExpr(exp); - displaypoints[i].count = count; - displaypoints[i].format = format; - break; - } - } - - return TRUE; -} - -int -DEBUG_InfoDisplay(void) -{ - int i; - - /* - * First find a slot where we can store this display. - */ - for(i=0; i < MAX_DISPLAY; i++ ) - { - if( displaypoints[i].exp != NULL ) - { - DEBUG_Printf(DBG_CHN_MESG, "%d : ", i+1); - DEBUG_DisplayExpr(displaypoints[i].exp); - DEBUG_Printf(DBG_CHN_MESG, "\n"); - } - } - - return TRUE; -} - -int -DEBUG_DoDisplay(void) -{ - DBG_VALUE value; - int i; - - /* - * First find a slot where we can store this display. - */ - for(i=0; i < MAX_DISPLAY; i++ ) - { - if( displaypoints[i].exp != NULL ) - { - value = DEBUG_EvalExpr(displaypoints[i].exp); - if( value.type == NULL ) - { - DEBUG_Printf(DBG_CHN_MESG, "Unable to evaluate expression "); - DEBUG_DisplayExpr(displaypoints[i].exp); - DEBUG_Printf(DBG_CHN_MESG, "\nDisabling...\n"); - DEBUG_DelDisplay(i); - } - else - { - DEBUG_Printf(DBG_CHN_MESG, "%d : ", i + 1); - DEBUG_DisplayExpr(displaypoints[i].exp); - DEBUG_Printf(DBG_CHN_MESG, " = "); - if( displaypoints[i].format == 'i' ) - { - DEBUG_ExamineMemory( &value, - displaypoints[i].count, - displaypoints[i].format); - } - else - { - DEBUG_Print( &value, - displaypoints[i].count, - displaypoints[i].format, 0); + if (DEBUG_GetCurrentFrame(&name, &eip, &ebp)) + return name; + return NULL; +} + +int DEBUG_AddDisplay(struct expr *exp, int count, char format, int in_frame) +{ + int i; + + for (i = 0; i < ndisplays; i++) + if (displaypoints[i].exp == NULL) + break; + + if (i == maxdisplays) /* no space left - expand */ + displaypoints = DBG_realloc(displaypoints, + (maxdisplays += DISPTAB_DELTA) * sizeof(*displaypoints)); + + if (i == ndisplays) + ++ndisplays; + + displaypoints[i].exp = DEBUG_CloneExpr(exp); + displaypoints[i].count = count; + displaypoints[i].format = format; + displaypoints[i].enabled = TRUE; + displaypoints[i].frame_name = + (in_frame ? DEBUG_GetCurrentFrameName() : NULL); + + return TRUE; +} + +int DEBUG_InfoDisplay(void) +{ + int i; + + for (i = 0; i < ndisplays; i++) { + if (displaypoints[i].exp == NULL) + continue; + + if (displaypoints[i].frame_name) + DEBUG_Printf(DBG_CHN_MESG, "%d in %s%s : ", i + 1, + DEBUG_GetSymbolName(displaypoints[i].frame_name), + (displaypoints[i].enabled ? + (displaypoints[i].frame_name != DEBUG_GetCurrentFrameName() ? + " (out of scope)" : "") + : " (disabled)") + ); + else + DEBUG_Printf(DBG_CHN_MESG, "%d%s : ", i + 1, + (displaypoints[i].enabled ? "" : " (disabled)")); + DEBUG_DisplayExpr(displaypoints[i].exp); + DEBUG_Printf(DBG_CHN_MESG, "\n"); + } + + return TRUE; +} + +void DEBUG_PrintOneDisplay(int i) +{ + DBG_VALUE value; + + if (displaypoints[i].enabled) { + value = DEBUG_EvalExpr(displaypoints[i].exp); + if (value.type == NULL) { + DEBUG_Printf(DBG_CHN_MESG, "Unable to evaluate expression "); + DEBUG_DisplayExpr(displaypoints[i].exp); + DEBUG_Printf(DBG_CHN_MESG, "\nDisabling display %d ...\n", i + 1); + displaypoints[i].enabled = FALSE; + return; } - } } - } - return TRUE; + DEBUG_Printf(DBG_CHN_MESG, "%d : ", i + 1); + DEBUG_DisplayExpr(displaypoints[i].exp); + DEBUG_Printf(DBG_CHN_MESG, " = "); + if (!displaypoints[i].enabled) + DEBUG_Printf(DBG_CHN_MESG, "(disabled)\n"); + else + if (displaypoints[i].format == 'i') + DEBUG_ExamineMemory(&value, displaypoints[i].count, displaypoints[i].format); + else + DEBUG_Print(&value, displaypoints[i].count, displaypoints[i].format, 0); } -int -DEBUG_DelDisplay(int displaynum) -{ - int i; - - if( displaynum >= MAX_DISPLAY || displaynum == 0 || displaynum < -1 ) - { - DEBUG_Printf(DBG_CHN_MESG, "Invalid display number\n"); - return TRUE; - } - if( displaynum == -1 ) - { - for(i=0; i < MAX_DISPLAY; i++ ) - { - if( displaypoints[i].exp != NULL ) - { - DEBUG_FreeExpr(displaypoints[i].exp); - displaypoints[i].exp = NULL; - } - } - } - else if( displaypoints[displaynum - 1].exp != NULL ) - { - DEBUG_FreeExpr(displaypoints[displaynum - 1].exp); - displaypoints[displaynum - 1].exp = NULL; - } - return TRUE; +int DEBUG_DoDisplay(void) +{ + int i; + struct name_hash *cur_frame_name = DEBUG_GetCurrentFrameName(); + + for (i = 0; i < ndisplays; i++) { + if (displaypoints[i].exp == NULL || !displaypoints[i].enabled) + continue; + if (displaypoints[i].frame_name + && displaypoints[i].frame_name != cur_frame_name) + continue; + DEBUG_PrintOneDisplay(i); + } + + return TRUE; +} + +int DEBUG_DelDisplay(int displaynum) +{ + int i; + + if (displaynum > ndisplays || displaynum == 0 || displaynum < -1 + || displaypoints[displaynum - 1].exp == NULL) { + DEBUG_Printf(DBG_CHN_MESG, "Invalid display number\n"); + return TRUE; + } + + if (displaynum == -1) { + for (i = 0; i < ndisplays; i++) { + if (displaypoints[i].exp != NULL) { + DEBUG_FreeExpr(displaypoints[i].exp); + displaypoints[i].exp = NULL; + } + } + displaypoints = DBG_realloc(displaypoints, + (maxdisplays = DISPTAB_DELTA) * sizeof(*displaypoints)); + ndisplays = 0; + } else if (displaypoints[--displaynum].exp != NULL) { + DEBUG_FreeExpr(displaypoints[displaynum].exp); + displaypoints[displaynum].exp = NULL; + while (displaynum == ndisplays - 1 + && displaypoints[displaynum].exp == NULL) + --ndisplays, --displaynum; + if (maxdisplays - ndisplays >= 2 * DISPTAB_DELTA) { + maxdisplays = (ndisplays + DISPTAB_DELTA - 1) & ~(DISPTAB_DELTA - 1); /* MARK */ + displaypoints = DBG_realloc(displaypoints, + maxdisplays * sizeof(*displaypoints)); + } + } + return TRUE; } + +int DEBUG_EnableDisplay(int displaynum, int enable) +{ + --displaynum; + if (displaynum >= ndisplays || displaynum < 0 || displaypoints[displaynum].exp == NULL) { + DEBUG_Printf(DBG_CHN_MESG, "Invalid display number\n"); + return TRUE; + } + + displaypoints[displaynum].enabled = enable; + if (!displaypoints[displaynum].frame_name + || displaypoints[displaynum].frame_name == DEBUG_GetCurrentFrameName()) + DEBUG_PrintOneDisplay(displaynum); + + return TRUE; +} + Index: programs/winedbg/hash.c =================================================================== RCS file: /home/wine/wine/programs/winedbg/hash.c,v retrieving revision 1.7 diff -u -r1.7 hash.c --- programs/winedbg/hash.c 19 Feb 2003 03:41:48 -0000 1.7 +++ programs/winedbg/hash.c 16 Apr 2003 03:04:57 -0000 @@ -1314,6 +1314,11 @@ return TRUE; } +const char *DEBUG_GetSymbolName(const struct name_hash * sym) +{ + return sym->name; +} + #ifdef HAVE_REGEX_H static int cmp_sym_by_name(const void * p1, const void * p2) Index: programs/winedbg/info.c =================================================================== RCS file: /home/wine/wine/programs/winedbg/info.c,v retrieving revision 1.5 diff -u -r1.5 info.c --- programs/winedbg/info.c 14 Feb 2003 19:22:48 -0000 1.5 +++ programs/winedbg/info.c 16 Apr 2003 03:04:57 -0000 @@ -214,6 +214,8 @@ " stepi [N] nexti [N]", " x <addr> print <expr>", " display <expr> undisplay <disnum>", +" display local <expr> display delete <disnum>", +" display enable <disnum> display disable <disnum>", " delete display <disnum> pass", " bt frame <n>", " up down",

1 0

Fwd: Keyboard Problem solved, one solution ...
by Sylvain Petreolle 16 Apr '03

16 Apr '03

What do you think of this fix ? ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Winelib _alloca/alloca linking problem
by Vincent Béron 15 Apr '03

15 Apr '03

Ok, so this won't get into CVS (way too "hacked until it works for me and only me"), but I don't know where to look further. Can somebody explain me where _alloca is supposed to be implemented/forwarded/ends up being called? The provided small program should be able to compile with either _alloca or alloca being called. Under Winelib, with the current msvcrt headers, _alloca is not found at all and linking fails. With the included patch, the program runs. Should I add a forward in msvcrt.spec from _alloca to MSVCRT_alloca, which itself calls (glibc's) alloca? Or is there something obvious I missed? Vincent Index: wine/include/msvcrt/malloc.h =================================================================== RCS file: /home/wine/wine/include/msvcrt/malloc.h,v retrieving revision 1.5 diff -u -r1.5 malloc.h --- wine/include/msvcrt/malloc.h 22 Mar 2003 21:15:41 -0000 1.5 +++ wine/include/msvcrt/malloc.h 15 Apr 2003 23:34:34 -0000 @@ -79,9 +79,6 @@ } #endif - -#ifndef USE_MSVCRT_PREFIX -static inline void* alloca(MSVCRT(size_t) i) { return _alloca(i); } -#endif /* USE_MSVCRT_PREFIX */ +static inline void* _alloca(MSVCRT(size_t) i) { return alloca(i); } #endif /* __WINE_MALLOC_H */ #include <malloc.h> #include <stdio.h> #include <stdlib.h> char *mp() { char *p; p = _alloca(2); p[0] = 0x41; /* A */ p[1] = 0; return p; } int main(void) { char *p; p = mp(); printf("%02x %02x\n", p[0], p[1]); exit(0); return 0; }

1 0

Re: version patch
by Vincent Béron 15 Apr '03

15 Apr '03

Andreas Mohr a écrit: > @@ -162,16 +174,18 @@ > }, > /* NT2K */ > { > + "Windows 2000", > 0x05005F03, > 0x08930005, > { > sizeof(OSVERSIONINFOA), 5, 0, 0x893, > VER_PLATFORM_WIN32_NT, "Service Pack 2", > - 2, 0, 0, VER_NT_WORKSTATION, 30 /* FIXME: Great, a reserved field with a value! */ > + 2, 0, 0, VER_NT_WORKSTATION, 30 /* FIXME: Great, a reserved field with a value! Is this correct? */ I still have this value (30) on 2K SP3. What do others have for 2K and XP (see attached program)? Besides, shouldn't we report SP3 for NT2K? And SP1 for XP? Vincent #include <windows.h> #include <stdio.h> typedef struct _OSVERSIONINFOEXAB { DWORD dwOSVersionInfoSize; DWORD dwMajorVersion; DWORD dwMinorVersion; DWORD dwBuildNumber; DWORD dwPlatformId; CHAR szCSDVersion[ 128 ]; // Maintenance string for PSS usage WORD wServicePackMajor; WORD wServicePackMinor; WORD wSuiteMask; BYTE wProductType; BYTE wReserved; } OSVERSIONINFOEXAB, *POSVERSIONINFOEXAB, *LPOSVERSIONINFOEXAB; int main(void) { OSVERSIONINFOEXAB ver; ver.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEXAB); GetVersionExA((OSVERSIONINFOA *) &ver); printf("%d %d %d %d %d \"%s\" %d %d %d %d %d\n", ver.dwOSVersionInfoSize, ver.dwMajorVersion, ver.dwMinorVersion, ver.dwBuildNumber, ver.dwPlatformId, ver.szCSDVersion, ver.wServicePackMajor, ver.wServicePackMinor, ver.wSuiteMask, ver.wProductType, ver.wReserved); exit(0); return 0; }

2 1

manual patch tracking system for ntdll
by thomas.mertes＠gmx.at 15 Apr '03

15 Apr '03

Hello Since I am following the ntdll development, I noticed some not applied patches: - Ntdll atom stuff: http://www.winehq.com/hypermail/wine-patches/2003/04/0064.html - Ntdll atom tests. http://www.winehq.com/hypermail/wine-patches/2003/04/0065.html The tests where verified by Dmitry Timoshkov in this mail: http://www.winehq.com/hypermail/wine-devel/2003/04/0192.html - Resend: Implement some ACE functions http://www.winehq.com/hypermail/wine-patches/2003/04/0129.html IMHO, if a patch is correct (can be verified by tests) it should be applied, even if no application needs this functions (at the moment). If this functions are needed later, some implementation (with FIXMEs) is already there as base for further development. This is easier than looking for a (possibly outdated) patch in the archieves. I see the wine source also as a information repository, which is easier to access, than a patch archive. In the worst case it should be possible that a function is accepted but deactivated with #ifdef. Greetings Thomas Mertes -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

3 2

Re: Fall back to ttydrv
by Dimitrie O. Paun 15 Apr '03

15 Apr '03

On April 14, 2003 06:11 pm, Uwe Bonnes wrote: > + MESSAGE( "Falling back to ttydrv\n"); Again, I'd say this message is not appropriate, especially now that the user has to enable this configurations. For people using command line tools under Wine will be just pure spam. -- Dimi.

5 6

Cross compiling tests
by Hans Leidekker 15 Apr '03

15 Apr '03

Hi, I'm trying to cross compile the regression tests using MinGW as a cross compiler (i.e. I have installed the MinGW cross compiler on Linux and run 'make crosstest'). First problem I encountered was that my versions of the compiler and dlltool weren't detected at configure stage. Mine are called i386-mingw-gcc and i386-mingw-dlltool, whereas configure looks for i586-mingw32msvc-gcc and i586-mingw32msvc-dlltool. I've sent a patch to wine-patches that adds the former names to the configure check. Second major problem happens at the build stage. The Makefile for a test specifies -L$(DLLDIR) when linking the test executables, which is where the *Wine* libraries reside. I think this is wrong, we should link against the target platform libraries (MinGW in this case) when cross compiling. Removing -L$(DLLDIR) from the Makefile also solves a conflict that arises from the fact that both MinGW and Wine have an implementation of the C runtime: make crosstest i386-mingw32-gcc generated.cross.o testlist.cross.o -o urlmon_crosstest.exe -L../../../dlls -lurlmon -lm ../../../dlls/libmsvcrt.a(ds00443.o)(.text+0x0): multiple definition of `atexit' /usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x230):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:266: first defined here ../../../dlls/libmsvcrt.a(ds00319.o)(.text+0x0): multiple definition of `_onexit' /usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x250):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:274: first defined here Patch sent to wine-patches. Now most tests happily compile ;-). I have two tests left that have problems linking. It appears that they use symbols that are not available in any import library (not even Wine's): i386-mingw32-gcc dsound.cross.o testlist.cross.o -o dsound_crosstest.exe -ldsound -luser32 -lkernel32 -lm dsound.cross.o(.text+0x1656): In function `dsenum_callback': /usr/local/src/wine-cvs/wine/dlls/dsound/tests/dsound.c:403: undefined reference to `wine_dbgstr_guid' dsound.cross.o(.text+0x24dd): In function `dscenum_callback': /usr/local/src/wine-cvs/wine/dlls/dsound/tests/dsound.c:649: undefined reference to `wine_dbgstr_guid' make: *** [dsound_crosstest.exe] Error 1 The wine_ prefix suggests that this is a Wine internal function, so it will never be avaliable on Windows/MinGW. Can these be removed? Or is there an alternative that works on all platforms? This is the other one that fails: i386-mingw32-gcc safearray.cross.o vartest.cross.o testlist.cross.o -o oleaut32_crosstest.exe -loleaut32 -lm safearray.cross.o(.text+0x1496): In function `func_safearray': /usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:277: undefined reference to `IID_IUnknown' safearray.cross.o(.text+0x14d1):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:278: undefined reference to `IID_IUnknown' safearray.cross.o(.text+0x150e):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:281: undefined reference to `IID_IDispatch' safearray.cross.o(.text+0x1549):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:282: undefined reference to `IID_IDispatch' make: *** [oleaut32_crosstest.exe] Error 1 Same problem I guess. Any suggestion as to how this one might be fixed is welcome. -Hans

3 10

mouse_event()
by Brad Campbell 15 Apr '03

15 Apr '03

G'day all, I have been doing some testing of the mouse_event call in windows and wine. There is only one incompatibility that I can see. In windows 95, a call to mouse_event does not _move_ the mouse pointer, whereas in wine, the mouse pointer follows the mouse. In windows, I have to make a call to mouse_event then another call to setcursorpos() to make the pointer follow the mouse. When using a touchscreen for input, we use a setcursorpos() call to move the mouse pointer off the screen, and then just feed windows mouse_event calls with the position and button state. This works under wine, but of course the pointer follows the mouse_event. It looks like this would be difficult to fix as from what I can see the pointer movement seems to be pretty closely tied to the mouse position. Any ideas? -- Brad.... /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \

1 0

Re: Better fix for named pipe problem.
by Gregory M. Turner 14 Apr '03

14 Apr '03

FYI fixing the linewraps in the patch and applying does indeed stop the wineserver from crashing using the experimental pipe.c, and runs fine against CVS's pipe.c. However, also FWIW, using the experimental pipe.c from Bill, I still get a pipe.ok when I shouldn't doing make test... -- gmt "Democracy is the theory that holds that the common people know what they want, and deserve to get it good and hard." HL Mencken

1 0

re: Is it possible to call DLL functions from a Linux program?
by Dan Kegel 14 Apr '03

14 Apr '03

Eloy wrote: > Now, I want to run this program natively under Linux - I mean, I don't > want to run wcmd because that requires an X server. I suggest just running your little Windows program under Wine. Don't use wcmd, you don't need it. For instance, in my ~/bin, I have a shell script winword which just contains wine -- "c:\\Program Files\\Microsoft Office\\Office\\winword.exe" "$@" That more or less lets me run microsoft word from the commandline. You can configure wine to not require X. I've done it on some commandline Windows programs I wanted to use in shell scripts on Linux. It was and is a pain, I believe, because so few of the Wine developers use commandline Windows programs without X, but it is doable. (And maybe it's easier than it used to be; I don't know.) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

3 6

Bug: "Type" = "cdrom" allows writing !!
by Sylvain Petreolle 14 Apr '03

14 Apr '03

Trying to run "dir >test" in a drive set to "Type" = "Cdrom" will create a test file containing the directory listing. Test case: [Drive W] "Path" = "/home/wine" "Type" = "cdrom" "Label" = "WineSrc" "Filesystem" = "win95" [syl@snoop wine]$ ls -l z ls: z: No such file or directory [syl@snoop wine]$ wcmd fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (French keyboard layout) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. WCMD Version 0.17 W:\>dir >z W:\>exit [syl@snoop wine]$ ls -l z -rw-r--r-- 1 syl wine 2413 Apr 14 23:59 z ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: OLE storage SetFilePointer fix
by Dimitrie O. Paun 14 Apr '03

14 Apr '03

On Sat, 12 Apr 2003, Andreas Mohr wrote: > P.S.: Alexandre, I'd REALLY like you to finally put a patch status > tracking system in place. The number of people submitting patches > for the second, third, bazillionth time is astonishing (I speak > from my very own experience, too!). I really don't know how many very > valuable Wine patches got lost due to not getting applied without any > status reply whatsoever... > (particularly the ones from "foreigners") > Someone recently said (in WWN) that patch management was perfect or > something to that extent. I better don't comment on that statement, > you know my hot temper ;) > OK, it's definitely not awful, but I guess it could be better. First off, I don't think the current system is bad. Second, I was the one this in the WWN (so sue me :P). Any system that we would put in place would have to work with email just like the current one. Other suck big time, see the SF one. Once you notice that, you realize that the problem is not the system, but rather that Alexandre needs to reply to patches he rejects, wether through email/web based form/what have you. Don't get me wrong -- I've been multiple times at the rejecting end of this, and it's frustrating. But in retrospective, it's all for a better Wine, and I'd be hard pressed to produce a patch which got rejected by Alexandre, and which I still think should be applied. Also, your assesment that 'very many valuable Wine patches got lost' is a gross exageration. In fact, please produce 3 such patches that got lost in the last year (heck, in the last 3 years for that matter). I think you'll have a hard time finding a single such patch in the last X years (choose X as you may) that match your description. There is good reason for this: people put work into their patches, and if they don't get apply, they ask why. This is where I don't understand Alexandre: he will eventually have to reply to such questions, why not do it proactively, it's the same amount of work, me thinks. But I'm not the one putting in the time and effort to sort through the patches, so I may be missing many things. -- Dimi.

4 4

patch tracking system redux
by Dan Kegel 14 Apr '03

14 Apr '03

Steven Edwards (steven_ed4153(a)yahoo.com) wrote: > --- Dominik Strasser <Dominik.Strasser(a)t-online.de> wrote: >> The attached patch implements proxies in wininet to an extent that at >> least IE6 install works behind a firewall. >> >> ChangeLog: >> partially implement proxy support in wininet >> >> This is the third time I am sending this patch. Is anything wrong with it ? > > I think we are starting to see we need a patch tracking system =) I think Alexandre feels differently. Have you read http://www.winehq.com/hypermail/wine-devel/2003/04/0384.html ? I do know of one patch tracking system that works well (http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/). It's restricted to "trivial" patches, and wouldn't handle the wininet proxy change, but might still be useful for Wine. I dunno. Alexandre silently ignored several of my patches recently, but that's just fine with me. They needed more work, and it was pretty obvious to me which direction I needed to go in to make him happy. Since I care about them, I will keep plugging away until they meet his criteria. - Dan

1 0

Re: lostwages/templates/en todo_lists.template
by Vincent Béron 14 Apr '03

14 Apr '03

Jeremy Newman a écrit: > ChangeSet ID: 7866 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: jnewman(a)wine.codeweavers.com 2003/04/14 11:03:55 > > Modified files: > templates/en : todo_lists.template > > Log message: > Dimitrie O. Paun <dpaun(a)rogers.com> > Update TODO Lists to Wine 0.9 TODO v0.8 from: > Â http://www.dssd.ca/wine/Wine-0.9-TODO-0.8.html > > Patch: http://cvs.winehq.com/patch.py?id=7866 > > Old revision New revision Changes Path > 1.4 1.5 +281 -258 lostwages/templates/en/todo_lists.template It would be nice if my last name (and maybe other people's names) wouldn't be mangled. This is due to the <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> in the header of the page, but with the use of UTF-8 chars in the body. On Dimi's site it looks fine (same header, but use of iso-8859-1 chars in the body). It might be in the transfer that the characters get transformed (had to chase something akin to that yesterday with a text attachment in Evolution). Vincent

1 0

Is it possible to call DLL functions from a Linux program?
by Eloy A. Paris 14 Apr '03

14 Apr '03

Hi! Sorry if this has been covered before, but I could not find any answers in the archives or by Googling... Here's the situation: I have a Windows DLL and a small Windows program that calls functions from this DLL. The Windows program does not have a GUI (it's command-line based.) I have the C source code for this program, but don't have the source code for the DLL. I built the program with Visual C and was able to run it under WINE just fine with wcmd. Now, I want to run this program natively under Linux - I mean, I don't want to run wcmd because that requires an X server. The first question is: is this possible? (have a Unix program that calls functions from a native Windows DLL). I started experimenting with winelib, but am not sure if this is the correct way... If this is possible, how should I do it? I ran winemaker, configure, make, but am getting errors from winbebuild. Summarizing: I have the C source code. This C program calls function foo() that is in a Windows DLL. I want to run this program under Linux without the need for an X server. The program calls gets(), printf(), etc. I want these functions to be from my Linux's libc, not Windows'. Any help will be greatly appreciated. Thanks in advance! Eloy.- P.S. I read the winelib user guide, but couldn't find the answer there. If it is there, it's not clear to me :(

4 4

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