April 2003 - Wine-Devel - list.winehq.org

Re: REFIXED: [dx8-7] Fix compile problem introduced by dx8-2
by keisangi April 20, 2003

April 20, 2003

Ann and Jason Edmeades wrote: >Please use this fix rather than the last one - Just noticed the break >statement was the wrong side of the #endif > >Changelog > >DOT3 isnt there on earlier opengl versions > >Jason > > hi, i've subscribed this mailling list for testing purposes only, now i'd like to unsubscribe but i can't figure how to do. could someone can tell me?

3 2

Re: Remove db2html-winehq
by Alexandre Julliard April 20, 2003

April 20, 2003

"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes: > There is no reason to have our own db2html hack. It creates > problems, we never got it to work reliably on different distros, > etc. We should use the one provided with the system, it's a far > safer bet. Also, our build system uses the standard db2html, > it's only the make_winehq script that used it. And that script > is used only on WineHQ, where we should be able to control the > environment to have a half-decent db2html that supports the > -d option. Do we actually need that make_winehq script at all? It seems almost everything it does is already done in the normal makefiles, except the bit about the winehq stylesheet. And I'm not sure what this one is for, since the docs on WineHQ look identical to the one we get by doing 'make doc'. Does anyone know how this is all supposed to work? -- Alexandre Julliard julliard(a)winehq.com

3 6

cvs woes
by Ann and Jason Edmeades April 20, 2003

April 20, 2003

| device.c: In function `IDirect3DDevice8Impl_SetTextureStageState': | device.c:3456: `GL_MIRRORED_REPEAT_ARB' undeclared (first use in this function) | device.c:3456: (Each undeclared identifier is reported only once | device.c:3456: for each function it appears in.) Hmm - This is a more tricky one to fix - Lionel, got any ideas? I have #if'defed it for GL_VERSION_1_3, but it looks like some headers who define GL_VERSION_1_3 dont have the mirrored repeat ARB defines. As a workaround, add #define GL_MIRRORED_REPEAT_ARB 0x8370 at the top of the source part. Question - If you look in your glext.h, does it define GL_MIRRORED_REPEAT instead? Jason

3 3

compiling wine under cygwin - status ??
by Kai Kai April 20, 2003

April 20, 2003

Hi, all, I am a NEWBIE in this area. I am very interested in the wine and cygwin. Can wine work under cygwin now? Or can Wine DLL be build under cygwin? I just found the status from David on Nov28, 2002, is there news about it now? howto is better:-) Thanks Kai _________________________________________________________ Do You Yahoo!? 雅虎邀你参与CCTV-2对话节目调查：移动、联通、灵通，要说爱你不容易 http://rd.yahoo.com/mail_cn/tag/?http://cn.surveys.yahoo.com/cctv_wireless_…

1 0

CVS build failed
by Paul Millar April 20, 2003

April 20, 2003

Anyone else getting this? On a fairly standard RH7.3 machine: device.c: In function `IDirect3DDevice8Impl_SetTextureStageState': device.c:3413: `GL_DOT3_RGBA' undeclared (first use in this function) device.c:3413: (Each undeclared identifier is reported only once device.c:3413: for each function it appears in.) make[2]: *** [device.o] Error 1 Looks like http://cvs.winehq.com/patch.py?id=7915 is the cause. See http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php and http://www.astro.gla.ac.uk/users/paulm/WRT/buildinfo.php?id=394 for more details .. Cheers, Paul. ---- Paul Millar

3 2

Re: UPDATED: video mode changes
by Lionel Ulmer April 20, 2003

April 20, 2003

Just a small nitpick : > + XF86VidModeModeInfo *mode; > + DWORD dwBpp = GetSystemMetrics(SM_WINE_BPP); > + if (dwBpp == 24) dwBpp = 32; I would prefer this change to be done directly in the 'GetDeviceCaps' function of the X11DRV to always return 32 in case the scren depth is 24. I know for sure that this fixes at least one application and should not hurt others :-) A part from that, the patch looks nice... If it breaks apps on Desktop mode, we will fix it then by re-adding the 'dummy' modes :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

Re: [dx8-5] Windows never reports 24 bit screen depths
by Ann and Jason Edmeades April 19, 2003

April 19, 2003

(Apologies for the duplicate sent - Didnt put a subject on first time) >> Windows never reports 24 bit colours, and some games fail to work unless in >> specific modes. Report 16bit colour for 24bit modes >Out of curiosity, in that case, why report 24 bits at all ? Why not just >report 8, 16 and 32 ? I dont - I query it with GetDeviceCaps and this is what gets returned. hdc = CreateDCA("DISPLAY", NULL, NULL, NULL); bpp = GetDeviceCaps(hdc, BITSPIXEL); DeleteDC(hdc); Actually, all the screen handling in the dx8 code is awful (I can say that as I put it there...). I am hoping that if the recent changes to the window modes is implemented, I can use that code to query what modes this device supports, and to change the mode/resolution appropriately. The code that we have is a semi working stopgap really. Jason

2 3

(no subject)
by Ann and Jason Edmeades April 19, 2003

April 19, 2003

>> Windows never reports 24 bit colours, and some games fail to work unless in >> specific modes. Report 16bit colour for 24bit modes >Out of curiosity, in that case, why report 24 bits at all ? Why not just >report 8, 16 and 32 ? I dont - I query it with GetDeviceCaps and this is what gets returned. hdc = CreateDCA("DISPLAY", NULL, NULL, NULL); bpp = GetDeviceCaps(hdc, BITSPIXEL); DeleteDC(hdc); Actually, all the screen handling in the dx8 code is awful (I can say that as I put it there...). I am hoping that if the recent changes to the window modes is implemented, I can use that code to query what modes this device supports, and to change the mode/resolution appropriately. The code that we have is a semi working stopgap really. Jason

1 0

Re: [dx8-5] Windows never reports 24 bit screen depths
by Lionel Ulmer April 19, 2003

April 19, 2003

> Windows never reports 24 bit colours, and some games fail to work unless in > specific modes. Report 16bit colour for 24bit modes Out of curiosity, in that case, why report 24 bits at all ? Why not just report 8, 16 and 32 ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: [Resend] Implements languagegroups functions
by Alexandre Julliard April 19, 2003

April 19, 2003

Maxime Bellengé <maxime.bellenge(a)laposte.net> writes: > This patch implements the languagegroups functions. > As I have access to a French and English windows 2k+, I set > the resources accordingly for the kernel32 resources. However, as > I don't know the resources for other languages, I have put English > resources in the other nls files. People will have to change them to the > correct values. > As suggested by alexandre, I chose some unused resource ids because even > win2k and winxp don't store them the same way and both of them > conflicted with the actual kernel32 resources from wine. I applied the resource strings, but the rest will still need a bit of work: you can't use a global variable to store the callback function, this is not reentrant, you need to do everything on the stack. Also I think the locale->language group mapping should be stored in the resources too, not in the code. And I'd suggest pretending that all language groups are installed, since we can't install them dynamically anyway. -- Alexandre Julliard julliard(a)winehq.com

1 0

winedbg
by Michal Janusz Miroslaw April 19, 2003

April 19, 2003

Hello, Is anyone working on winedbg ? I have some ideas and would like to hear opinions/more ideas/flames: * enabling/disabling of displays [done] * displays shown in one function only [done] * implement define command to add symbols on the fly (didn't find it is sources except in help text ...) * save/restore breakpoints/displays/defined symbols * reverse backtrace list (so current frame is at the bottom and you dont have to scroll all the way up) * remove limit of 10 entries in DEBUG_GetSymbolValue [done] * remove duplicated code in DEBUG_FindNearestSymbol/DEBUG_CheckLinenoStatus I haven't looked everywhere, yet, but `grep FIXME *|wc -l` shows 106 now, so I should find something. :) -- Michal Miroslaw

3 4

Wine keyboard focus and bug 1385
by Roderick Colenbrander April 19, 2003

April 19, 2003

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 April 19, 2003

April 19, 2003

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 April 19, 2003

April 19, 2003

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 April 18, 2003

April 18, 2003

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 April 18, 2003

April 18, 2003

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 April 18, 2003

April 18, 2003

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 April 18, 2003

April 18, 2003

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 April 18, 2003

April 18, 2003

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 April 18, 2003

April 18, 2003

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 April 18, 2003

April 18, 2003

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 April 17, 2003

April 17, 2003

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 April 17, 2003

April 17, 2003

"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 April 17, 2003

April 17, 2003

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 April 17, 2003

April 17, 2003

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 April 17, 2003

April 17, 2003

>>>>> "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 April 17, 2003

April 17, 2003

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 April 17, 2003

April 17, 2003

> -----Original Message----- > From: Uwe Bonnes [mailto:bon(a)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 April 17, 2003

April 17, 2003

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 April 17, 2003

April 17, 2003

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 April 17, 2003

April 17, 2003

> 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 April 17, 2003

April 17, 2003

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(a)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 April 17, 2003

April 17, 2003

--- 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 April 17, 2003

April 17, 2003

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 April 17, 2003

April 17, 2003

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 April 17, 2003

April 17, 2003

> 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 April 17, 2003

April 17, 2003

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 April 17, 2003

April 17, 2003

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 April 16, 2003

April 16, 2003

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 April 16, 2003

April 16, 2003

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 April 16, 2003

April 16, 2003

> 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 April 16, 2003

April 16, 2003

"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 April 16, 2003

April 16, 2003

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 April 16, 2003

April 16, 2003

"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 April 16, 2003

April 16, 2003

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 April 16, 2003

April 16, 2003

> 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 April 16, 2003

April 16, 2003

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 April 16, 2003

April 16, 2003

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 April 15, 2003

April 15, 2003

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 April 15, 2003

April 15, 2003

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 April 15, 2003

April 15, 2003

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 April 15, 2003

April 15, 2003

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 April 15, 2003

April 15, 2003

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 April 15, 2003

April 15, 2003

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 April 14, 2003

April 14, 2003

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 April 14, 2003

April 14, 2003

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 April 14, 2003

April 14, 2003

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(a)snoop wine]$ ls -l z ls: z: No such file or directory [syl(a)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(a)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 April 14, 2003

April 14, 2003

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 April 14, 2003

April 14, 2003

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 April 14, 2003

April 14, 2003

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 April 14, 2003

April 14, 2003

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

Re: Implement proxies in wininet
by Steven Edwards April 14, 2003

April 14, 2003

--- 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 =) Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

1 0

Latest wine tarball not compiling with egcs and --disable-debug
by Gabriele April 14, 2003

April 14, 2003

Hi all, I'm trying to compile wine 20030408 with a pretty old compiler which is gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) If I run the configure scipt without passing --disable-debug and --disable-trace and then make depend && make everything builds just fine. If I disable debug and trace and then run make I get some errors. The first problem is with some defines in debug.c ../../include/wine/debug.h:84: warning: invalid character in macro parameter name ../../include/wine/debug.h:84: badly punctuated parameter list in `#define' I had to add a string before the '...' to bypass the error: #ifdef NO_DEBUG_MSGS #define WINE_WARN(arg...) do { } while(0) #define WINE_WARN_(ch) WINE_WARN #define WINE_FIXME(arg...) do { } while(0) #define WINE_FIXME_(ch) WINE_FIXME #endif The other error is the following : make[2]: Entering directory `/home/gabriele/wine-20030408/dlls/oleaut32' gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -gstabs+ -fPIC -D__WINESRC__ -D_OLEAUT32_ -DCOM_NO_WINDOWS_H -D_REENTRANT -o typelib.o typelib.c typelib.c: In function `ITypeLib2_fnGetTypeComp': typelib.c:3393: warning: unused variable `This' typelib.c: In function `ITypeLib2_fnReleaseTLibAttr': typelib.c:3584: warning: unused variable `This' typelib.c: In function `ITypeLib2_fnGetLibStatistics': typelib.c:3629: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnGetTypeComp': typelib.c:3870: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnAddressOfMember': typelib.c:4765: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnCreateInstance': typelib.c:4778: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnGetMops': typelib.c:4790: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseTypeAttr': typelib.c:4828: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseFuncDesc': typelib.c:4840: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseVarDesc': typelib.c:4851: warning: unused variable `This' gcc: Internal compiler error: program cc1 got fatal signal 11 make[2]: *** [typelib.o] Error 1 make[2]: Leaving directory `/home/gabriele/wine-20030408/dlls/oleaut32' make[1]: *** [oleaut32] Error 2 make[1]: Leaving directory `/home/gabriele/wine-20030408/dlls' make: *** [dlls] Error 2

1 0

keyboard mapping with XFree86 4.3.0
by Tim Ruehsen April 14, 2003

April 14, 2003

With XFree86 4.3.0 I experience the message fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (German keyboard layout without dead keys) 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. This is very annoying, I can't use the right alt key any more to reach characters like {,} or [. Very bad for C programming... (I use EditPlus together with wine). The Problem can be found with older versions (20020812) as with newer version (20030317). Here is my keyboard layout from XF86Config: Section "InputDevice" Driver "Keyboard" Identifier "Keyboard[0]" Option "MapName" "Standard Keyboard [ pc105 ]" Option "Protocol" "Standard" Option "XkbLayout" "de" Option "XkbModel" "pc105" Option "XkbRules" "xfree86" Option "XkbVariant" "nodeadkeys" EndSection wine -debugmsh +key,+keyboard application outputs: trace:key:X11DRV_InitKeyboard NumLockMask is 10 trace:keyboard:X11DRV_KEYBOARD_DetectLayout Attempting to match against "United States keyboard layout" trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff1b trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff1b trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 11, character 2 ... Any idea? Regards, Tim

4 11

Re: Fall Back to ttydrv when DISPLAY is not set
by Andreas Mohr April 14, 2003

April 14, 2003

On Sun, Apr 13, 2003 at 08:41:04PM +0200, Uwe Bonnes wrote: > > Changelog > wine/dlls/user/user_main.c: load_driver > wine/dlls/gdi/driver.c: load_display_driver > Fall back to the ttydrv when the DIPLAY variable is not set What about falling back to including a patch? ;-) BTW, do you print a SUFFICIENTLY LARGE warning message when doing so? Users should be aware that something "isn't ok" when this happens... (otherwise they'll keep running Wine with ttydrv and not be aware of the real reason for this behaviour, namely the missing DISPLAY variable) Anyway, since this is going towards error handling, you should make sure that people *know* what's going on instead of them confusedly deleting Wine again ;-) Andreas Mohr -- Help prevent Information Technology Fascism! - before it's too late... http://www.againsttcpa.com

4 3

Re: Fall back to ttydrv when DISPLA variable not set(with patch)
by Dimitrie O. Paun April 14, 2003

April 14, 2003

On April 13, 2003 04:35 pm, Uwe Bonnes wrote: > + { > + MESSAGE( "Falling back to ttydrv\n"); > + strcpy( buffer, "ttydrv" ); /* default value */ > + } I'm not sure this message is a good idea. What about if you don't run X, are we gonna spam people into running it? -- Dimi.

1 0

Re: UPDATED: video mode changes
by Dimitrie O. Paun April 14, 2003

April 14, 2003

On April 12, 2003 09:34 pm, Alex Pasadyn wrote: > +#define _X_FIELD(prefix, bits) if ((fields) & prefix##_##bits) TRACE(""#bits ","); +static void _dump_CDS_flags(DWORD fields) { > + _X_FIELD(CDS,UPDATEREGISTRY);_X_FIELD(CDS,TEST);_X_FIELD(CDS,FULLSCREEN); > + _X_FIELD(CDS,GLOBAL);_X_FIELD(CDS,SET_PRIMARY);_X_FIELD(CDS,RESET); > + _X_FIELD(CDS,SETRECT);_X_FIELD(CDS,NORESET); > +} > +static void _dump_DM_fields(DWORD fields) { > + _X_FIELD(DM,BITSPERPEL);_X_FIELD(DM,PELSWIDTH);_X_FIELD(DM,PELSHEIGHT); > + _X_FIELD(DM,DISPLAYFLAGS);_X_FIELD(DM,DISPLAYFREQUENCY);_X_FIELD(DM,POSITION); > +} > +#undef _X_FIELD I still think these should return a string as I described in my previous email... Also, there is no need for such tests: > + if (TRACE_ON(x11drv)) The TRACE will take care of things nicely. -- Dimi.

1 0

Re: ALTGR Problem
by Dmitry Timoshkov April 13, 2003

April 13, 2003

<duncan(a)semanticedge.de> wrote: > When ever I press the AltGr Key, I get the ^ sign and nothin happend > concerning the email "at" sign, the special brackets and so on. I have > a Toshiba notebook, 2430-101 with a qwertz keyboard, german layout. > Under RH everything works fine concerning the keyboard! > I'm not really familiar with keyboard settings, so editing the > keyboard.c will fail ;-) If I gonna try it with no idea what to do. Let's wait for a merge of keyboard patches from CX Office and see whether it works any better. -- Dmitry.

1 0

Re: Fall Back to ttydrv when DISPLAY is not set
by Vincent Béron April 13, 2003

April 13, 2003

Le dim 13/04/2003 à 14:41, Uwe Bonnes a écrit : > > Changelog > wine/dlls/user/user_main.c: load_driver > wine/dlls/gdi/driver.c: load_display_driver > Fall back to the ttydrv when the DIPLAY variable is not set You forgot the patch this time. Vincent

1 0

Re: OLE storage SetFilePointer fix
by Mike Hearn April 13, 2003

April 13, 2003

> 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... The main problem as far as I'm concerned isn't so much the lack of a patch "tracker", I'm usually capable of keeping track of whether my patches have been applied or not by watching wine-cvs (though i've found once or twice i've missed the commit), it's more an issue of if a patch is rejected, you have to ask why. That means I'm often left thinking, is my patch simply in the queue, or is something wrong with it? Or, like my last pkgconfig patch, is there another reason it didn't go in? The way gnome/mozilla do it is to have patches put in bugzilla, but for the sheer volume of patches Wine gets with only Alexandre committing (which is fine by me), that wouldn't work. I'd be perfectly happy with the current arrangement if when a patch was dropped, a reason would normally appear on wine-devel - but then I'm not the one doing the work, Alexandre is, so it's easy for me to ask for him to do more work :/ thanks -mike

2 2

Fwd: ALTGR Problem
by Sylvain Petreolle April 13, 2003

April 13, 2003

Welcome to the club ;-) ===== 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: dos games, vesa and wine
by Jukka Heinonen April 13, 2003

April 13, 2003

Enrico Horn wrote: > I tried my dos4gw games with dos32a and they "work"(except some warning dos32a > prints) but you have to run these games like this to get an result: > wine -- dos32a game.exe > thats is because the stub which loads the dos extender doesnt work and i have > no idea why. Neither dos4gw stub loader nor dos4gw itself work. Making these work would be nice, but since there are free, compatible DOS extenders available that work rather well with Wine, I'm not particularly interested to figure out what is wrong with them. I have toyed with an idea of trying to contact dos4gw authors (if I can find them) and ask them if they could help, but I'm just too lazy for this kind of stuff. > the games i use all make use of vesa > they want 640x480x256 > ddraw traces show a primary surface that is 8bit paletted. > is there any problem drawing this thing? > where is this done? > is there a routine that regularly updates the screen with content of this > surface? > i have looked in x11drv(can it be that x11drv is in need of a rewrite?) and > havent found anything but i am not expert at this and just poke around > randomly where i see an interest. That mode should work with DOS VESA emulation. It could be that those programs use VESA features that are not supported or that VESA emulation is faulty. It is also possible that those programs are waiting for timer interrupt which is not delivered in protected mode (I have a good idea how to do this, but we shall see when I have time to implement it). See dlls/winedos/int10.c and dlls/winedos/vga.c. It is unlikely that DOS display problems are due to x11drv bugs. -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

LdrGetDllHandle with FlashMX demo
by Darren Cook April 13, 2003

April 13, 2003

Hi, When trying to run the FlashMX Demo version I got about 120 lines of: fixme:module:LdrGetDllHandle Unknown behavior, please report It then dies with "Failed to initialize Vbox! (0010-0069-0090)". I wasn't sure whether to report it in bugzilla or here as I'm not sure if you consider this a bug. So I thought I'd try here first. I'm using this version of wine: wine-20030408-1rh8winehq.i686.rpm (plus stdole32.tlb, copied from winXP machine). FlashMX demo was copied over from a winXP installation (I couldn't get the installer to run under wine). I also have a full version of FlashMX which works (well, some rough edges :-), also by copying over from winXP. If you need more information, or want me to try in debug mode, etc. let me know (I'm not subscribed to the list). Darren

2 1

Re: OLE storage SetFilePointer fix
by Marcus Meissner April 13, 2003

April 13, 2003

On Sat, Apr 12, 2003 at 11:07:11PM +0200, Andreas Mohr wrote: > Hi all, > > the OLE storage code basically disabled itself, by doing a > READ_HEADER; > in STORAGE_get_pps_entry(). > This READ_HEADER uses -1 as block number for STORAGE_get_big_block() > (in order to retrieve the storage header block). > And if you look at the SetFilePointer() in STORAGE_get_big_block(), > you might notice that (n+1)*BIGSIZE for some strange reason evaluates > to 0, for n == -1. > Thus, SetFilePointer() seeks to position 0 to read the storage header. > > And now I'm terribly sorry to tell you that STORAGE_get_big_block() > did a > if (!SetFilePointer( hf, (n+1)*BIGSIZE, NULL, SEEK_SET )) > { > WARN(" seek failed (%ld)\n",GetLastError()); > return FALSE; > } > > Sounds like SetFilePointer() is *supposed* to return 0 if it seeks to > position 0, eh? > > In other words: > - fix blatantly wrong SetFilePointer() calls The 16bit storage code is probably not safe to work with, for instance saving is probably not working. It should call forward to the 32bit storage code, which I think is more correct. Ciao, Marcus

1 0

Re: OLE storage SetFilePointer fix
by Alexandre Julliard April 12, 2003

April 12, 2003

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > 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... You know, nobody prevents you from implementing a better patch tracking system, and if it makes my life easier I'll be more than happy to use it. Or if you don't want to write code, you could volunteer to manually keep track of all submitted patches and resubmit the lost ones. But of course that's a lot more work than simply complaining about it... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: video mode changes
by Lionel Ulmer April 12, 2003

April 12, 2003

Hi, I have some comments on this patch : > + if (devmode->dmFields & DM_BITSPERPEL) > + { > + if (devmode->dmBitsPerPel != GetSystemMetrics(SM_WINE_BPP)) > + continue; > + } This may cause problems... It's not per-se a problem in your patch, but from what I know Windows applications expect to have '32' on a 24/32 display and Wine stores here '24'. So you may 'refuse' some modes that should be valid. (again, if ever you have a graphic card still supporting 24/24 mode, please tell me so that I can torture your XFree libraries to find a valid way of checking the difference between 24/24 and 24/32) > + SYSMETRICS_Set( SM_CXSCREEN, devmode->dmPelsWidth ); > + SYSMETRICS_Set( SM_CYSCREEN, devmode->dmPelsHeight ); This are actually 'User' internal functions ? In that case, why not just do the resolution change in the X11 driver and let User itself handle the sysmetric change ? I.e. call these in the 'ChangeDisplaySettingsExW' function and not in the low-level graphic driver. Now my most important grief : did you think about all the people who 1) use Desktop mode and 2) disable XVidMode in their config file ? For those, applications may now abort saying 'Vidmode not supported' (whereas it was working just fine before because we accepted all modes that are smaller than the actual screen size). So I would say that if no VidMode is present or if the User driver function does not exist in the driver, the old 'stub' API should remain as it is. Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 3

Re: winedos / Improve tracing
by BiGgUn April 12, 2003

April 12, 2003

Why didn't you use TRACE instead of DPRINTF ? Stephan

1 0

Toolbar debug message
by BiGgUn April 12, 2003

April 12, 2003

Hi How can i see debug messages from toolbar.c ? Neither '--debug-msg trace+toolbar' nor '--debug-msg +toolbar' works. The '+loaddll' option claims that i use the _builtin_ version of comctl32. I do not have no more ideas :( Stephan

2 1

Wine 0.9 TODO v0.8
by Dimitrie O. Paun April 12, 2003

April 12, 2003

Hi folks, The next version of the 0.9 TODO is way past due (again!), and today is as good as any other day for a brand new release: http://www.dssd.ca/wine/Wine-0.9-TODO-0.8.html ChangeLog * Jer finished the WineHQ redesign (A1) * Brian completed the screenshot galery (A4) * Adam is our new Slackware maintainer (A6) * Andreas updated the User & Development Guide (B1,B3) * I took on the Packaging Guide and Winelib docu (B2,B4,B8) * New task: more modular doc building (B12) * I've updated and integrated Jaco's winecfg into the tree (C2) * John did more work on the DLL registration (C5) * Shachar got a working version of wineboot into the tree (C7) * I finished messing with wrc (D5) * I got winegcc to a working state (D6) * Marcus made the printing system detection dynamic (E3) * Eric improved WinHelp some more (E6) Please note that this version has been in the making for almost 4 month! Lot's of stuff changed, feedback is much appreciated. -- Dimi.

3 2

Re: PATCH: video mode changes
by Dimitrie O. Paun April 12, 2003

April 12, 2003

On April 12, 2003 12:16 am, Alex Pasadyn wrote: > + if (TRACE_ON(x11drv)) > + { > + MESSAGE("\tDM_fields=");_dump_DM_fields(devmode->dmFields);MESSAGE("\n"); > + MESSAGE(" bpp=%ld\n",devmode->dmBitsPerPel); > + MESSAGE(" width=%ld\n",devmode->dmPelsWidth); > + MESSAGE(" height=%ld\n",devmode->dmPelsHeight); > + MESSAGE(" freq=%ld\n",devmode->dmDisplayFrequency); > + } Please don't use MESSAGE. Use TRACE instead, it will do the right thing. This piece can be rewritten as: TRACE("\tDM_fields=");_dump_DM_fields(devmode->dmFields);TRACE("\n"); TRACE(" bpp=%ld\n",devmode->dmBitsPerPel); TRACE(" width=%ld\n",devmode->dmPelsWidth); TRACE(" height=%ld\n",devmode->dmPelsHeight); TRACE(" freq=%ld\n",devmode->dmDisplayFrequency); Also, it will be a lot nicer if you rewrite _dump_DM_dields to return a string, so you can write: TRACE("\tDM_fields=%s\n", debug_DM_fields(devmode->dmFields)); TRACE(" bpp=%ld\n",devmode->dmBitsPerPel); TRACE(" width=%ld\n",devmode->dmPelsWidth); TRACE(" height=%ld\n",devmode->dmPelsHeight); TRACE(" freq=%ld\n",devmode->dmDisplayFrequency); The debug_DM_fields() function would than look like so: static const char* debug_DM_fields(DWORD fields) { BOOL first = TRUE; char buf[128] = "", *p = buf; #define DEBUG_FIELD(x) if ((fields) & DM_##x) { p += sprintf(p, "%s%s", first ? "" : " ,", #x); first = FALSE; } DEBUG_FIELD(BITSPERPEL); DEBUG_FIELD(PELSWIDTH); DEBUG_FIELD(PELSHEIGHT); DEBUG_FIELD(DISPLAYFLAGS); DEBUG_FIELD(DISPLAYFREQUENCY); DEBUG_FIELD(POSITION); #undef DEBUG_FIELD return wine_dbg_sprintf("%s", buf); } -- Dimi.

2 1

Re: Wine Packaging Guide update
by Mike Hearn April 12, 2003

April 12, 2003

> NOTE: I am (was?) a strong believer in markup. I started this > work because I thought the document doesn't belong in the > Docu section, and needed updating, without being aware of > the potential problems with SGML. By the time I was done, > I was completely horrified by this SGML business. It has > it's advantages, but they come at a hefty price, so we > have to be very careful when we employ it. It works OK > for documents that don't require a lot of markup, like the > FAQ. In fact, in that case it _saves_ on formating markup. > It works nicely for documents that are essentially books > (such as the User Guide, etc.) where you can expect someone > to print out the nicely formatted .pdf/.ps. However, for > technical documents that need to be maintained often, and > are useful as a online resource that people are likely to > open in an editor, it blows chunks. Now I start to understand > Alexandre's preference for troff for man pages... Hehe, I'm glad I'm not the only one who thinks DocBook is overrated - I've been wrestling with it for the past few weeks as part of writing a shared packaging metadata spec, and an automatic documentation framework for bash libraries, and I have NEVER got it to work correctly. I've found that clean HTML with some small CSS can make a document that looks more professional (imo) and is far easier to read in a text editor, not least because emacs (and i assume vim) can apply the formatting in the tags to the text itself. I've never looked at troff, but free software seems to need a better documentation/markup system - DocBook SGML just seems far, far too complex for doing something that is essentially quite simple.

1 0

Re: PATCH: Winemaker's --wrap option
by Jeremy Newman April 12, 2003

April 12, 2003

Please stop resending this message to the list. I have gotten more than 20 copies of this message now. On Tue, 2003-04-08 at 14:59, Javier López wrote: > ----- Original Message ----- > From: "Juraj Hercek" <juraj(a)syncad.com> > To: <wine-patches(a)winehq.com> > Sent: Tuesday, April 08, 2003 4:35 AM > Subject: PATCH: Winemaker's --wrap option > > > > Changelog: > > > > Juraj Hercek <juraj(a)syncad.com> > > * tools/winemaker : > > Fixed generation of makefiles and wrapper files when "--wrap" option > > is used. > > > > <snip> -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

4 3

Re: wine/dlls make_dlls Makefile.in Makedll.rules.in
by Vincent Béron April 12, 2003

April 12, 2003

Alexandre Julliard a écrit: > ChangeSet ID: 7854 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/04/11 19:05:28 > > Modified files: > dlls : make_dlls Makefile.in Makedll.rules.in > > Log message: > Fixed rules for auto documentation (reported by Vincent Béron). > > Patch: http://cvs.winehq.com/patch.py?id=7854 > > Old revision New revision Changes Path > 1.23 1.24 +19 -0 wine/dlls/make_dlls > 1.172 1.173 +19 -0 wine/dlls/Makefile.in > 1.52 1.53 +4 -13 wine/dlls/Makedll.rules.in Not good. Won't work correctly for dlls containing subdirs with a Makefile (msacm, etc.). In those cases, only the first level directory will be processed, not the subdirs. Vincent

2 1

Provide USB support in wine ?
by Sylvain Petreolle April 11, 2003

April 11, 2003

"Accidentally", when updating my RH system, I discovered that libusb is a library that provides user access to the USB devices, regardless of the OS. It appears we could use it in wine, since : - its license compatible (LGPL) - it supports some OSes on which wine is built. Like : Linux FreeBSD NetBSD, OpenBSD (dont know if this works now, referring to http://www.winehq.com/?page=faq#Under_what_hardware_platforms_and_Wine) Darwin (never heard of it for Wine ??) MacOS X (recent Qemu work makes this possible) Could such a support be possible/doable ? ===== 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

5 4

ttydrv on a remote console
by Uwe Bonnes April 11, 2003

April 11, 2003

Hallo, I am trying to run a complex command line (XST from Xilinx) program with X disabled, like on a remote terminal. With "GraphicsDriver" = "ttydrv" and called like "~/tmp/wine/compile/wine/wine -- /tmp/webpack-5.2/bin/nt/xst -quiet -ifn __projnav/dacswitch.xst -ofn dacswitch.syr" it soon crashes. I tracked it down to a failing WM_NCCREATE mesage in TTYDRV_CreateWindow. Returning unconditional TRUE in TTYDRV_CreateWindow makes the program run. With x11drv, called on the command line like above, wndPtr->parent is not set and the clause { create_desktop( display, wndPtr, cs ); WIN_ReleasePtr( wndPtr ); return TRUE; } is taken. Any ideas? Running with wineconsole and wcmd resulted in a scrambled screen and a crash too. Thanks -- 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

Contrib page update
by Dimitrie O. Paun April 11, 2003

April 11, 2003

They'll be added to the Fun Projects on the next update to that page. ChangeLog Move some of the tasks to the Fun Projects where they belong. Index: templates/en/contributing.template =================================================================== RCS file: /home/wine/lostwages/templates/en/contributing.template,v retrieving revision 1.5 diff -u -r1.5 contributing.template --- templates/en/contributing.template 30 Mar 2003 15:59:45 -0000 1.5 +++ templates/en/contributing.template 11 Apr 2003 15:40:07 -0000 @@ -33,9 +33,7 @@ <ol> <li><a href="#devel_task">Some development task</a> </li><li><a href="#conf_tests">Conformance tests</a> - </li><li><a href="#cross">Cross referencing the windows executables and libraries</a> </li><li><a href="#doc_win_api">Documentation of the windows API functions</a> - </li><li><a href="#check_which">Check which APIs are missing for a given program</a> </li><li><a href="#port_app">Port your windows application to wine</a> </li><li><a href="#code_review">Perform a focused code review</a> @@ -284,24 +282,6 @@ </li></ul> - <a name="cross"></a> - <h3>Cross referencing the Windows executables and libraries</h3> - - <p>The idea is to write a Perl script that analyzes the Windows dlls and executables of a - regular Windows installation and cross references them. This would generate Web pages - telling you which API is used by which program/library and reciprocally. - Analyzing the import/export section of PE executables is quite simple: it's just a matter - of running dumpbin (part of Visual C++) or pedump (open source) on them and then parsing - the resulting text file. This already being done with the wpbtk toolkit. - To view winapi_check output see <a href="http://fgouget.free.fr/wine/winapi_stats-en.shtml">Quick API statistics</a>. - To help with this please contact <a href="mailto:fgouget(a)free.fr">Francois Gouget</a> - </p> - Required skills: - <ul> - <li>Perl - </li><li>General HTML - </li></ul> - <a name="doc_win_api"></a> <h3>Documentation of the Windows API functions</h3> @@ -320,28 +300,6 @@ <ul> <li>Knowledge of some documentation generation system for the person trying to enhance the documentation generation. </li><li>A bit of C to document the APIs themselves. - </li></ul> - - <a name="check_which"></a> - <h3>Check which APIs are missing for a given program</h3> - - <p>The scripts that scan a Windows environment could be modified to restrict the scan to the dependencies - of a given executable/set of executables. Then these results can be cross-referenced with the results - of the above script to tell you which APIs this program is missing, what percentage they represent, etc. - Reciprocally one can weight each API according to how often they are referenced in a given environment to - produce an approximation of the likely hood that such an API will actually be called. Note that this would - just be an approximation because we would miss all the dynamically loaded APIs and libraries - (since we only scan the statically linked dynamic libraries). This would be an even more approximate - measure of the likely hood that the program will work: even though a program references an API it may never call it, - work even though this API does not work, or really depend on this API or even some undocumented aspect of this API. - Still this may provide a better approximation of the completeness of Wine than just treating all APIs as equivalent. - </p> - Required skills: - <ul> - <li>Perl - - </li><li>General HTML to present the results - </li><li>Maybe querying a database will be necessary too </li></ul> <a name="port_app"></a> -- Dimi.

2 1

Re: Contributing: Check which APIs are missing for a given program
by Pouech Eric DMI AEI CAEN April 11, 2003

April 11, 2003

> Would it be helpful if pedump were supported so you don't need dumpbin from Visual C++ to be able to use the scripts? winedump (in the tools directory) has some of the features of pedump A+

2 1

WineHQ: updated Fun Projects
by Dimitrie O. Paun April 11, 2003

April 11, 2003

ChangeLog Remove the links from the title sections (visited links were invisible due to the color scheme). Small cleanups. Move the cross referencing tasks from the Contributing page. Index: templates/en/fun_projects.template =================================================================== RCS file: /home/wine/lostwages/templates/en/fun_projects.template,v retrieving revision 1.3 diff -u -r1.3 fun_projects.template --- templates/en/fun_projects.template 30 Mar 2003 16:23:41 -0000 1.3 +++ templates/en/fun_projects.template 11 Apr 2003 17:27:03 -0000 @@ -57,7 +57,6 @@ which would be <em>uber</em>cool. <h4 class=inprogress>Cygwin under Wine in Linux</h4> - This provides an a good test case for Wine. It is tough, but we do have the Cygwin source code, and we have a good chance to understand why it does not work. @@ -67,7 +66,6 @@ <li>status: runs <tt>bash -l -i</tt> and logs out <li>updated: Dec 4, 2002 </ul> - <h4 class=inprogress>Wine under Cygwin in Windows</h4> This will provide a good test case for Cygwin, but will help Wine's @@ -88,20 +86,18 @@ need to have a MinGW port on Windows (that is, they need to support building under MinGW). - <h4 class=todo><a name="jvm" href="http://java.sun.com">Java Virtual Machine</a></h4> + <a name="jvm"></a><h4 class=todo>Java Virtual Machine</h4> There are three noteworthy Java implementations: <dl> <dt><a href="http://java.sun.com/j2se/">Sun's JVM</a></dt> <dd>Unfortunately, the Windows port requires MSVC to build. How ironic.</dd> - <dt><a href="http://www.ibm.com/developerworks/java">IBM's JVM</a></dt> <dd>I can't seem to be able to find the sources for this one. Help!</dd> <dt><a href="http://www.kaffe.org">Kaffe</a></dt> <dd>This one seems to have ports to Cygwin and MinGW. Good candidate for a port.</dd> </dl> - <h4 class=todo><a name="perl" href="http://www.perl.com">Perl</a></h4> - + <a name="perl"></a><h4 class=todo>Perl</h4> Any Perl monger up for this? <ul> <li>worker: wanted @@ -112,10 +108,9 @@ <strong>Update:</strong> The ActivePerl branch support building under both Cygwin and MinGW. This is a very good test for <tt>winegcc</tt>. Unfortunately, the MinGW makefile uses backslashes as fileseparator, so it will take a bit of work to get working under Linux. - Why do people use backslash, when the forward slash works on both Windows and Linux? Eh... - - <h4 class=todo><a name="python" href="http://www.python.org">Python</a></h4> + Why do people use backslash, when the forward slash works on both Windows and Linux? + <a name="python"></a><h4 class=todo>Python</h4> Not very exciting, but still interesting port. It's a good test for the non graphic APIs, such as threading, files, etc. <ul> @@ -126,7 +121,6 @@ </ul> <strong>Update:</strong> Configure the packages like so: <pre> - CC=winegcc CXX=wineg++ configure --with-suffix --without-threads </pre> Unfortunately, configure gets confused about the executable extension, @@ -141,8 +135,7 @@ to create portable UI toolkits. Due to the large UI component of the Win32 API, these are a perfect test for Wine. - <h4 class=todo><a name="qt" href="http://www.trolltech.com/products/qt/windows.html">QT</a></h4> - + <a name="qt"></a><h4 class=todo>QT</h4> Imagine we compile QT under Wine, and then we get the entire <a href="http://www.kde.org">KDE</a> compiled and running under Wine! How cool would that be? <ul> @@ -150,7 +143,6 @@ <li>status: initial investigation <li>updated: Jan 6, 2003 <li>homepage: <a href="http://www.trolltech.com/products/qt/windows.html">www.trolltech.com/products/qt/windows.html</a> - </ul> <strong>Update:</strong> Unfortunately, QT/Windows is not free software. Moreover, it requires MSVC or the Borland toolchain to build. Before we can start thinking about @@ -159,7 +151,7 @@ <a href="http://www.troll.no">Troll's</a> part to support such an effort. If you think you can make a case for it, please let us now. - <h4 class=todo><a name="gtk" href="http://www.gtk.org">Gtk+</a></h4> + <a name="gtk"></a><h4 class=todo>Gtk+</h4> This is maybe a little less interesting than the others, as Gtk+ does not use the native widgets when ported to Windows. Instead, it uses it's very thin abstraction layer (gdk) to do the drawing, all else is build 'in house'. @@ -168,17 +160,15 @@ <li>status: todo <li>updated: Jan 6, 2003 <li>homepage: <a href="http://wingtk.sourceforge.net/">wingtk.sourceforge.net</a> - </ul> - <h4 class=done><a name="wxwindows" href="http://www.wxwindows.org">wxWindows</a></h4> + <a name="wxwindows"></a><h4 class=done>wxWindows</h4> A perfect test case for Wine's headers, and MinGW emulation! Wouldn't it be cool to have the Windows controls available on Linux too? <duck/> :-) <ul> <li>worker: <a href="mailto:dpaun(a)rogers.com">Dimitrie O. Paun</a> - <li>status: compiles, links, and runs! + <li class=modified>status: compiles, links, and runs! The <a href="http://www.winehq.com/hypermail/wine-devel/2003/01/0153.html">patch</a> - has been accepted in the official wxWindows tree! <li>updated: Jan 7, 2003 <li>homepage: <a href="http://www.wxwindows.org">www.wxwindows.org</a> @@ -215,7 +205,6 @@ free version available, but apparently you can buy one for around $100US. <ul> <li>worker: <a href="mailto:ps(a)leissner.se">Patrik Stridvall</a> - <li>status: most tests work, DLLs are pretty bad though <li>updated: Nov 29, 2002 </ul> @@ -228,7 +217,6 @@ <li>status: todo <li>updated: Jan 6, 2003 <li>homepage: <a href="http://www.borland.com/bcppbuilder/freecompiler/">www.borland.com/bcppbuilder/freecompiler</a> - </ul> <h3 class=todo>Watcom's cc</h3> @@ -252,12 +240,49 @@ <h2>Miscellaneous Projects</h2> This is a catch-all category for all sort of strange (and sometimes cute) ideas. + <a name="cross"></a><h3 class=inprogress>Cross referencing the Windows executables and libraries</h3> + <p>The idea is to write a Perl script that analyzes the Windows dlls and executables of a + regular Windows installation and cross references them. This would generate Web pages + telling you which API is used by which program/library and reciprocally. + Analyzing the import/export section of PE executables is quite simple: it's just a matter + of running dumpbin (part of Visual C++) or pedump (open source) on them and then parsing + the resulting text file. This already being done with the wpbtk toolkit. + <ul> + <li>worker: <a href="mailto:compsol(a)ptd.net">Dave Miller</a> + <li>status: Prototype ready + <li>updated: Apr 11, 2003 + </ul> + <strong>Update:</strong> + Currently the script can make HTML maps of the dll imports. I've been too + lazy to integrate the program that processed that into a table so + far. :) Right now it requires dumpbin (Visual C++) I plan to add pedump + or winedump support so more people are able to use it. It is also + analyzing the wine .spec files to determine if each API has an entry and + reports whether it's a stub, unimplemented (not in spec files), etc. + + + <a name="check_which"></a><h3 class=inprogress>Check which APIs are missing for a given program</h3> + <p>The scripts that scan a Windows environment could be modified to restrict the scan to the dependencies + of a given executable/set of executables. Then these results can be cross-referenced with the results + of the above script to tell you which APIs this program is missing, what percentage they represent, etc. + Reciprocally one can weight each API according to how often they are referenced in a given environment to + produce an approximation of the likely hood that such an API will actually be called. Note that this would + just be an approximation because we would miss all the dynamically loaded APIs and libraries + (since we only scan the statically linked dynamic libraries). This would be an even more approximate + measure of the likely hood that the program will work: even though a program references an API it may never call it, + work even though this API does not work, or really depend on this API or even some undocumented aspect of this API. + Still this may provide a better approximation of the completeness of Wine than just treating all APIs as equivalent. + <ul> + <li>worker: <a href="mailto:compsol(a)ptd.net">Dave Miller</a> + <li>status: Starting work <a href="http://www.winehq.com/hypermail/wine-devel/2003/04/0324.html">soon</a>. + <li>updated: Apr 11, 2003 + </ul> + <h3 class=inprogress>GDI Engine</h3> Integrate the GDI engine contributed by the <a href="http://www.transgaming.com">Transgaming</a> folks. <ul> <li>worker: <a href="mailto:johane(a)lysator.liu.se">Johan Gill</a> - <li>status: <i>It should be ready for submission in a few months from now.</i> <li>updated: Feb 22, 2003 </ul> @@ -270,7 +295,6 @@ <a href="http://bugs.winehq.com/show_bug.cgi?id=1304">Bug #1304</a>. <h3 class=todo>Wine Explorer</h3> - <p>A Windows Explorer replacement. People migrating from Windows would love it, and it would provide a great testbed for our <tt>shell32</tt> DLL, as well as some key controls such as the List-View Common Control. @@ -287,7 +311,6 @@ <li> A "Cancel" button (that changes to "Close" when tests are done) <li> A "Report..." button that brings up a "Save As..." dialog </ul> - Not hard to write, and quite cool to play with. Anyone familiar with the Win32 API can do it. -- Dimi.

1 0

winebuild incompatibility with binutils-2.13.90.0.20
by Piotr Pawłow April 11, 2003

April 11, 2003

Hi, There is a change in "nm -u" output format in the new binutils, now it outputs "U " before every symbol name. It looks like this: $ nm -u d3d8.dll.tmp.o U cos U CreateDCA U DeleteDC U ExtEscape U GetClientRect U GetDC U GetDesktopWindow U GetDeviceCaps U GetModuleHandleA U GetProcAddress U GetPropA (...) Winebuild parser is not prepared for that. It does not find proper symbol names, creates spec.c files with no imports, and the result is that linking fails on unresolved symbols, as reported in "--with-nptl and glibc-2.3.2" thread. A quick fix: Index: tools/winebuild/import.c =================================================================== RCS file: /home/wine/wine/tools/winebuild/import.c,v retrieving revision 1.48 diff -r1.48 import.c 664a665,667 > if (*p == 'U') { > if (p[1] == ' ') p+=2; > } Shouldn't winebuild, however, use libbfd where available, instead of relying on nm output? -- Piotr Pawłow mailto:pp(a)siedziba.pl

3 5

Re: CxxFrameHandler problem
by John K. Hohm April 11, 2003

April 11, 2003

Alexandre Julliard <julliard(a)winehq.com> wrote: > Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > > > Appended program uses CxxFrameHandler and crashes in wine with builtin > > msvcrt, but not with native. Compile as Release version and include the > MFC > > dll. Can somebody compile for Alexandre? Alexandre, is this a start or do > > you need something complete? > > That's a start, yes, thanks. I'll need a more complete example with > nested try blocks, destructors all over the place, typed exceptions, > etc. to make sure I understand all the compiler internal structures; > but I can at least try to make that simple case not crash... Although this may duplicate effort, I am familiar with several strange combinations of exception handling that I know work with Visual C++ 6.0; I will put them a test program for you. You can never have too many test programs, right?

1 1

Re: Re: wcmd, external commands, and options
by Pouech Eric DMI AEI CAEN April 11, 2003

April 11, 2003

> I don't think we need to change CreateProcess at all. In > my tests, Wine matched Win9x's CreateProcess behavior nicely. > All the changes we need are in wcmd, I think. > - Dan that's correct (I later checked also CreateProcess) wcmd is to blame. I may have a look afterwards at wcmd (I'm currently on a two week trip, without any Linux box at hand) A+

1 0

Wine's test process
by Eduardo Augusto Bezerra April 10, 2003

April 10, 2003

Hi I've been working on the definition of testing processes for open source projects and, so far, Open Office is one of the most organized projects I've found. The bug tracking system of Wine is quite good, but I haven't found much about the definition of Wine's test process. I was wondering whether somebody in this discussio list could send me some pointers or documents where I could learn more about Wine's test process. Basically, I've been looking for a place where I could find answers for questions such as: How has the test process been defined in the beginning of the Wine project? How was the test process performed at that time? How was the test process performed when there were no web versions for the bug reports? Are there test plans available? My research is not based only on Wine. I've been trying to find other open source projects that have an organized and documented test process, but it's quite hard. Many thanks for any help Eduardo. -- Eduardo Augusto Bezerra, PhD Space Science Centre, School of Engineering and IT The University of Sussex, Brighton, England, UK http://www.sussex.ac.uk/engg/research_groups/space/ Researcher, Software Testing Research Centre (CPTS) PUCRS/Hewlett-Packard Brazil, Porto Alegre, RS, Brazil Lecturer in Computer Science, Informatics Faculty Catholic University (PUCRS), Porto Alegre, RS, Brazil http://www.inf.pucrs.br/~gaph Phone/Fax UK: +44 (0)1273 877086 / +44 (0)1273 678399 Phone/Fax Brazil: +55 51 3320 3695 / +55 51 3320 3758 http://www.eduardo.bezerra.name PGP signature: Key ID B852E578 Public Key: http://www.keyserver.net/en/ or http://eduardo.bezerra.name

1 0

Problem actually with binutils, oops!
by Scott Carmichael April 10, 2003

April 10, 2003

Okay, so in any event, does anyone know when this will be fixed? Downgrading from 2.13.90.0.20 to 2.13.90.0.18 seems to fix the problem... But does anyone know why? And is this a wine problem? Or binutils? Thanks, Scott

2 1

Contributing: Check which APIs are missing for a given program
by Dave Miller April 10, 2003

April 10, 2003

I plan to be working on this soon. It should be able to share pieces of the script which cross references dlls and will create an API database (plain text file for now). Before I get started I have a couple of questions. Do we intend to gather all this information together and keep it? In a database, in the application database, in bug reports, etc. Or is it more for a developer trying to get a specific application working? What information should exist in the API database? Currently it outputs the spec file, API name, and whether it is a stub, forward, stdcall, etc. Does anyone think more information is needed? Would it be helpful if pedump were supported so you don't need dumpbin from Visual C++ to be able to use the scripts?

1 0

dos games, vesa and wine
by Enrico Horn April 10, 2003

April 10, 2003

Hi, Another day, another round of questions concerning this topic. I tried my dos4gw games with dos32a and they "work"(except some warning dos32a prints) but you have to run these games like this to get an result: wine -- dos32a game.exe thats is because the stub which loads the dos extender doesnt work and i have no idea why. the behaviour is the following(trace of +int21): allocate 1 block of memory resize block to 65536(this fails returnnig number of available blocks) resize block to whats available allocate 1 block of memory(this fails as all is already allocated) close all files, print error message and exit the games i use all make use of vesa they want 640x480x256 ddraw traces show a primary surface that is 8bit paletted. is there any problem drawing this thing? where is this done? is there a routine that regularly updates the screen with content of this surface? i have looked in x11drv(can it be that x11drv is in need of a rewrite?) and havent found anything but i am not expert at this and just poke around randomly where i see an interest. Thanks for putting up with me Enrico

1 0

About new RH glinc issue
by Sylvain Petreolle April 10, 2003

April 10, 2003

This is what I received today from Red Hat Network, maybe it could our issue. ===== 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

3 3

0408 w/ glibc 2.3.2 still broken
by Scott Carmichael April 10, 2003

April 10, 2003

> WHAT'S NEW with Wine-20030408: (see ChangeLog for details) > - Support for all variants of glibc 2.3. I'm still getting errors with glibc 2.3.2. The same ones I was getting with -20030318. Anyone know why this is? :) Unfortunately, the LD_ASSUME_KERNEL fix doesn't seem to work, as it seems to break everything else on my system needed to run the actual build. =\ Thanks, and the log of the fail follows... make[2]: Entering directory `/home/jobe/wine-20030408/dlls/d3d8' gcc -shared -Wl,-Bsymbolic,-z,defs d3d8.spec.o basetexture.o cubetexture.o d3d8_main.o device.o directx.o indexbuffer.o resource.o shader.o stateblock.o surface.o swapchain.o texture.o vertexbuffer.o volume.o volumetexture.o vshaderdeclaration.o d3d8.dll.dbg.o -o d3d8.dll.so -L../../dlls -L../../libs/wine -lwine -L../../libs/uuid -lwine_uuid -L/usr/X11R6/lib -lSM -lICE -lXxf86dga -lXxf86vm -lXv -lXext -lX11 -lGL -lGLU -L../../libs/port -lwine_port -lm -lc basetexture.o(.text+0x281): In function `IDirect3DBaseTexture8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' cubetexture.o(.text+0x2d2): In function `IDirect3DCubeTexture8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' d3d8_main.o(.text+0xf4): In function `Direct3DCreate8': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' d3d8_main.o(.text+0x1ba): In function `DllMain': /home/jobe/wine-20030408/dlls/d3d8/d3d8_main.c:64: undefined reference to `GetModuleHandleA' d3d8_main.o(.text+0x1d5):/home/jobe/wine-20030408/dlls/d3d8/d3d8_main.c:67: undefined reference to `GetProcAddress' d3d8_main.o(.text+0x1f2):/home/jobe/wine-20030408/dlls/d3d8/d3d8_main.c:68: undefined reference to `GetProcAddress' device.o(.text+0x35c1): In function `IDirect3DDevice8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x385c): In function `IDirect3DDevice8Impl_GetDisplayMode': /home/jobe/wine-20030408/dlls/d3d8/device.c:1081: undefined reference to `GetSystemMetrics' device.o(.text+0x3870):/home/jobe/wine-20030408/dlls/d3d8/device.c:1082: undefined reference to `GetSystemMetrics' device.o(.text+0x38a6):/home/jobe/wine-20030408/dlls/d3d8/device.c:1085: undefined reference to `CreateDCA' device.o(.text+0x38bb):/home/jobe/wine-20030408/dlls/d3d8/device.c:1086: undefined reference to `GetDeviceCaps' device.o(.text+0x38c8):/home/jobe/wine-20030408/dlls/d3d8/device.c:1087: undefined reference to `DeleteDC' device.o(.text+0x3f77): In function `IDirect3DDevice8Impl_CreateTexture': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x41d7): In function `IDirect3DDevice8Impl_CreateVolumeTexture': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x42ed):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x4385):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x453a): In function `IDirect3DDevice8Impl_CreateCubeTexture': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x47c4):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: more undefined references to `HeapAlloc' follow device.o(.text+0x110ac): In function `IDirect3DDevice8Impl_DeleteVertexShader': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x110cc):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x11117):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x11139):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x111a9):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x116e2): In function `IDirect3DDevice8Impl_CreatePixelShader': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x1195b): In function `IDirect3DDevice8Impl_DeletePixelShader': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' directx.o(.text+0x231): In function `IDirect3D8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' directx.o(.text+0x549): In function `IDirect3D8Impl_GetAdapterModeCount': /home/jobe/wine-20030408/dlls/d3d8/directx.c:150: undefined reference to `GetSystemMetrics' directx.o(.text+0x55b):/home/jobe/wine-20030408/dlls/d3d8/directx.c:151: undefined reference to `GetSystemMetrics' directx.o(.text+0x687): In function `IDirect3D8Impl_EnumAdapterModes': /home/jobe/wine-20030408/dlls/d3d8/directx.c:194: undefined reference to `CreateDCA' directx.o(.text+0x69c):/home/jobe/wine-20030408/dlls/d3d8/directx.c:195: undefined reference to `GetDeviceCaps' directx.o(.text+0x6a9):/home/jobe/wine-20030408/dlls/d3d8/directx.c:196: undefined reference to `DeleteDC' directx.o(.text+0x7bd):/home/jobe/wine-20030408/dlls/d3d8/directx.c:182: undefined reference to `GetSystemMetrics' directx.o(.text+0x7d1):/home/jobe/wine-20030408/dlls/d3d8/directx.c:183: undefined reference to `GetSystemMetrics' directx.o(.text+0x958): In function `IDirect3D8Impl_GetAdapterDisplayMode': /home/jobe/wine-20030408/dlls/d3d8/directx.c:228: undefined reference to `GetSystemMetrics' directx.o(.text+0x96c):/home/jobe/wine-20030408/dlls/d3d8/directx.c:229: undefined reference to `GetSystemMetrics' directx.o(.text+0x9a2):/home/jobe/wine-20030408/dlls/d3d8/directx.c:232: undefined reference to `CreateDCA' directx.o(.text+0x9b7):/home/jobe/wine-20030408/dlls/d3d8/directx.c:233: undefined reference to `GetDeviceCaps' directx.o(.text+0x9c4):/home/jobe/wine-20030408/dlls/d3d8/directx.c:234: undefined reference to `DeleteDC' directx.o(.text+0x109d): In function `IDirect3D8Impl_CreateDevice': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' directx.o(.text+0x11a7): In function `IDirect3D8Impl_CreateDevice': /home/jobe/wine-20030408/dlls/d3d8/directx.c:459: undefined reference to `GetPropA' directx.o(.text+0x11be):/home/jobe/wine-20030408/dlls/d3d8/directx.c:468: undefined reference to `GetDC' directx.o(.text+0x11ff):/home/jobe/wine-20030408/dlls/d3d8/directx.c:56: undefined reference to `ExtEscape' directx.o(.text+0x127f):/home/jobe/wine-20030408/dlls/d3d8/directx.c:480: undefined reference to `GetDesktopWindow' directx.o(.text+0x1291):/home/jobe/wine-20030408/dlls/d3d8/directx.c:480: undefined reference to `GetPropA' directx.o(.text+0x13a0):/home/jobe/wine-20030408/dlls/d3d8/directx.c:496: undefined reference to `ReleaseDC' directx.o(.text+0x143e):/home/jobe/wine-20030408/dlls/d3d8/directx.c:515: undefined reference to `GetClientRect' indexbuffer.o(.text+0x244): In function `IDirect3DIndexBuffer8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' indexbuffer.o(.text+0x264):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' resource.o(.text+0x231): In function `IDirect3DResource8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' shader.o(.text+0xc0a): In function `IDirect3DDeviceImpl_CreateVertexShader': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' shader.o(.text+0xc46):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' shader.o(.text+0x19f8): In function `IDirect3DVertexShaderImpl_ParseProgram': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1064): In function `IDirect3DDeviceImpl_CreateStateBlock': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1402): In function `IDirect3DDeviceImpl_DeleteStateBlock': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' stateblock.o(.text+0x14ed): In function `IDirect3DDeviceImpl_BeginStateBlock': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' surface.o(.text+0x234): In function `IDirect3DSurface8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' surface.o(.text+0x254):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' swapchain.o(.text+0x231): In function `IDirect3DSwapChain8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' texture.o(.text+0x2c3): In function `IDirect3DTexture8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' vertexbuffer.o(.text+0x237): In function `IDirect3DVertexBuffer8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' vertexbuffer.o(.text+0x269):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: more undefined references to `HeapFree' follow vshaderdeclaration.o(.text+0x6d): In function `IDirect3DDeviceImpl_CreateVertexShaderDeclaration8': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' vshaderdeclaration.o(.text+0x114):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' collect2: ld returned 1 exit status make[2]: *** [d3d8.dll.so] Error 1 make[2]: Leaving directory `/home/jobe/wine-20030408/dlls/d3d8' make[1]: *** [d3d8] Error 2 make[1]: Leaving directory `/home/jobe/wine-20030408/dlls' make: *** [dlls] Error 2 Compilation failed, aborting install.

1 0

Re: Opening AVI files in Wine
by Tom Hibbert April 10, 2003

April 10, 2003

On Wed, Apr 09, 2003 at 11:45:07AM -0500, wine-devel-request(a)winehq.com wrote: > From: Pouech Eric DMI AEI CAEN <pouech-eric(a)wanadoo.fr> > Reply-To: pouech-eric(a)wanadoo.fr > To: Tom Hibbert <cartel(a)cryptocracy.hn.org>, wine-devel(a)winehq.com > Subject: Re: Opening AVIs with wine > Date: Wed, 9 Apr 2003 18:31:03 +0200 (CEST) > > Please can someone tell me if it is possible for a wine application > > to open an avi file (or better yet use video for windows codecs). > in generic terms yes. > however, avi is an enveloppe to store video files, but the compression used can vary from file to file > so, you need the specific decompressor to handle a given type of file > normally, wine is ready (under the MCI and the msvfw32 interfaces at least) to play AVI files > however, to get further with your issue, we need to know : > 1/ which interface your program actually uses (MCI, msvfw, directx...) > 2/ which codecs are installed and configured under wine > 3/ the type of compressor used for your file > (btw, does changing the avi file to play changes also what is output - or not output in your case) Hi Pouche, thanks for your quick reply! Combustion uses the Video for Windows interface to open AVIs. The VFW interface is abstracted through a plugin in combustion's plugin system. When i use a native msvfw32.dll the overlays inside the app dissapear and some of the buttons fail to render which is a Bad Thing.. perhaps i need to use some other native supporting libraries in order to use native msvfw32, any suggestions? As for which codecs are installed and configured, I'm not sure how to tell. I've looked in the registry but cant find much. I have installed the DivX codec but thats about all I have done purposefully. The format of the files I want to open is Type 2 DVAVI. Selecting other types doesnt change my output. This is all getting confusing.. I am reading at http://www.microsoft.com/hwdev/tech/stream/vidcap/dvavi.asp that Microsoft provide interfaces for Type 2 DVAVI only, and only for direct show. This is consistent with Combustion's inability to read Type 1 files (under windows of course). Does DirectShow = vfw32? Sorry for the insanely confusing response, Tom

2 1

Re: [RFC] direct sound notify patch
by Alexandre Julliard April 10, 2003

April 10, 2003

Robert Reif <reif(a)earthlink.net> writes: > Adding a hardware notify introduces the use a new GUID from > dsdriver.h. I had to add initguid.h to get it to compile but is this > the proper thing to do? Should this file be added to libs/uuid? Yes it should be in libuuid, initguid.h should not be used. Also your patch doesn't compile because of references to the removed notifies fields, you probably forgot some files. -- Alexandre Julliard julliard(a)winehq.com

1 0

make htmlpages does not work - regression?
by thomas.mertes＠gmx.at April 10, 2003

April 10, 2003

Hello I noticed that "make htmlpages" does not work in Wine-20030408 but in Wine-20030318. The problem seems to be in some makefile or configure change since /dlls/Makedll.rules.in still contains the "Rules for auto documentation". but the actual Makefile does not. I have in the moment no time to fix it myself (or search the patch that made this change). Btw. the documentation system is great, but I think that only a few people know that it exists. To start it (according to Jon Griffiths): Run ./configure, make htmlpages, point your browser at documentation/html/index.html, then immediately start sending patches for documentation glitches :-) The interesting dlls (with many docomented functions) are shlwapi.dll and ntdll.dll. Greetings Thomas -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

2 1