miranda

[Geoff Thorpe]

Hi all,

I've been fishing round for something resembling a feature-full yet not
overly flakey I-M client (with support for the commonly-used protocols).
After finding many of the X11-native clients insufficient in many
respects, I'd been making do with trillian under wine. However that too
experiences many problems and the modern win32 obsession of creating
irritating GUI mutations is probably the reason. Eg. window creation
sometimes hangs wine, dragging window location sometimes hangs wine,
fonts seem to go haywire from time to time, preferences dialog seems to
have various breakages, etc. So I was interested in trying out "Miranda
I-M" which looked from the screenshots (in default mode anyhow) to be a
reasonably conventional-looking win32 GUI client and seems to be under
active development judging by sourceforge stats.

Unfortunately after installation, which went pretty well, the program
fails to start quite early on with this;

fixme:file:FindFirstChangeNotificationA this is not supported yet (non-trivial).

<sigh> Am I going to regret enquiring what this means? :-)

So my question is in two parts;

(1) is the above something that I can work on and/or help anyone else
work on?

(2) does anyone know of any other win32-based I-M client (supporting at
least ICQ, Yahoo, MSN, AIM) that is stable under wine?

Cheers,
Geoff

[Eric Pouech]

> fixme:file:FindFirstChangeNotificationA this is not supported yet (non-trivial).
>
> <sigh> Am I going to regret enquiring what this means? :-)
>
> So my question is in two parts;
>
> (1) is the above something that I can work on and/or help anyone else
> work on?

We sometimes doubt will be able to support correctly 
FindFirstChangeNotification under Wine without proper kernel support, 
which doesn't exist yet...
so it'd be a hard task

A+

FindFirstChangeNotification (Was: miranda)

[Hans Leidekker]

On Saturday 01 March 2003 20:53, Eric Pouech wrote:
> > fixme:file:FindFirstChangeNotificationA this is not supported yet
> > (non-trivial).
> >
> > <sigh> Am I going to regret enquiring what this means? :-)
> >
> > So my question is in two parts;
> >
> > (1) is the above something that I can work on and/or help anyone else
> > work on?
>
> We sometimes doubt will be able to support correctly
> FindFirstChangeNotification under Wine without proper kernel support,
> which doesn't exist yet...
> so it'd be a hard task

You know, a couple of weeks ago I looked at the possibilities
of a FAM based implementation, as suggested in bugrequest #588:

http://bugs.winehq.org/show_bug.cgi?id=588

There are other solutions (dnotify, fmon on FreeBSD), but FAM is
available now on RedHat and Mandrake distributions, which gives 
it an avantage. Furthermore, FAM will fall back to a polling
strategy when kernel level support is absent. I think it's
the best candidate.

The real question is: does FAM provide enough functionality to
implement all of FindFirstChangeNotification and friends? The short
answer is no. For example, Win32 change notifications can be obtained
for complete subtrees, e.g  you can ask to be notified of changes
to C:\ and everything beneath. As far as I can tell FAM only 
supports directory level notifications.

In addition, I found that there isn't a straight mapping from Win32
change events to FAM monitoring events: under Win32 you ask for
directories to be watched for certain events: file deletions,
added files, changes to file attributes and some more. With FAM,
you watch a directory OR a file for changes. This could mean that,
in order to mimic Win32 behaviour, one would have to watch both the
specified directory and ALL files in that directory to gather
all necessary information. And then FAM doesn't support file 
deletion events. We could of course regain those by doing some
extra bookkeeping, but it starts getting hairy.

All of this did not scare me enough however to actually implement
some of this API on top of FAM. And you know what, it already works!
It's really neat to see that Word file dialog automatically refresh
when you add a file to the directory you're looking at!

I will try to clean it up sometime and submit what I have. Don't
know if it's worth doing that though since it implements so little 
of the API. Another thing is that I wrote it against wine-20030115
and I saw that in CVS there are changes to the files (no pun!) I
touched.

Oh, and file monitoring eats a lot of CPU right now, since
my implementation amounts to polling FAMPending() from change_signaled() 
to see if there are any outstanding events. A better way to use FAM is
to use poll()/select() on an fd that FAM supplies. But of course
we can't block in a wineserver call. So I tried to have the wineserver
poll loop do that for me, but I was unsuccessful so far.

Bye,

-Hans

-----------------------------------------------
Hans Leidekker               Vrije Universiteit
                             Dienst IT
Systeembeheer Campusnetwerk  De Boelelaan 1105 
                             1081 HV  Amsterdam 
[phone]          The Netherlands 
-----------------------------------------------

FindFirstChangeNotification (Was: miranda)

[Mike McCormack]

Hi Hans,

Please don't write a FAM dependent implementation. This introduces an 
unnecessary dependency in Wine, and as you mentioned a polling solution 
to this problem is wasteful or CPU time.

I submitted a patch a couple of months ago that implements a kernel 
based solution (using F_NOTIFY) to the problem, which IMO is much nicer.

My patch is at:

http://www.winehq.org/hypermail/wine-patches/2002/11/0246.html

Mike

Hans Leidekker wrote:
> > We sometimes doubt will be able to support correctly
> > FindFirstChangeNotification under Wine without proper kernel support,
> > which doesn't exist yet...
> > so it'd be a hard task
>
> You know, a couple of weeks ago I looked at the possibilities
> of a FAM based implementation, as suggested in bugrequest #588:
>
> http://bugs.winehq.org/show_bug.cgi?id=588
>
> There are other solutions (dnotify, fmon on FreeBSD), but FAM is
> available now on RedHat and Mandrake distributions, which gives 
> it an avantage. Furthermore, FAM will fall back to a polling
> strategy when kernel level support is absent. I think it's
> the best candidate.

FindFirstChangeNotification (Was: miranda)

[Dimitrie O. Paun]

On Tue, 4 Mar 2003, Mike McCormack wrote:
> I submitted a patch a couple of months ago that implements a kernel 
> based solution (using F_NOTIFY) to the problem, which IMO is much nicer.

Any idea why it hasn't been merged in?

FindFirstChangeNotification (Was: miranda)

[Alexandre Julliard]

"Dimitrie O. Paun"  writes:
> > I submitted a patch a couple of months ago that implements a kernel 
> > based solution (using F_NOTIFY) to the problem, which IMO is much nicer.
>
> Any idea why it hasn't been merged in?

It needs some portability work, and I haven't found the time to do
that. And now of course it will need to be adapted to the new fd
management.

FindFirstChangeNotification (Was: miranda)

[Mike McCormack]

I've already adapted it to the new fd management stuff. The attached 
patch is against the Crossover Wine tree, but it seems to apply cleanly 
to WineHQ's tree. (You'll need to run tools/make_requests after applying).

Which portability fixes need to be made Alexandre?

Mike

Alexandre Julliard wrote:
> It needs some portability work, and I haven't found the time to do
> that. And now of course it will need to be adapted to the new fd
> management.

Index: server/change.c
===================================================================
RCS file: /cvstrees/crossover/office/wine/server/change.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 change.c
--- server/change.c	21 Feb 2003 01:33:09 -0000	1.1.1.4
+++ server/change.c	27 Feb 2003 01:22:18 -0000
@@ -18,6 +18,9 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */

+#include "config.h"
+#include "wine/port.h"
+
 #include <assert.h>
 #include <stdio.h>
 #include <stdlib.h>
@@ -28,15 +31,28 @@
 #include "thread.h"
 #include "request.h"

+#ifndef RT_SIGNAL_NOTIFY
+#define RT_SIGNAL_NOTIFY 34
+#endif
+
 struct change
 {
     struct object  obj;      /* object header */
+    int            fd;       /* the unix file descriptor */
     int            subtree;  /* watch all the subtree */
     int            filter;   /* notification filter */
+    char          *name;     /* name of file */
+    int            signaled; /* the file changed */
+    struct change *next;
+    struct change *prev;
 };

+static struct change *first_change, *last_change;
+
 static void change_dump( struct object *obj, int verbose );
 static int change_signaled( struct object *obj, struct thread *thread );
+static int change_satisfied( struct object *obj, struct thread *thread );
+static void change_destroy( struct object *obj );

static const struct object_ops change_ops =
 {
@@ -45,20 +61,108 @@
     add_queue,                /* add_queue */
     remove_queue,             /* remove_queue */
     change_signaled,          /* signaled */
-    no_satisfied,             /* satisfied */
+    change_satisfied,         /* satisfied */
     no_get_fd,                /* get_fd */
-    no_destroy                /* destroy */
+    change_destroy            /* destroy */
 };

+static void add_change_notification( struct change *change )
+{
+    change->prev = NULL;
+    change->next = first_change;
+    if ( first_change )
+        first_change->prev = change;
+    else
+        last_change = change;
+    first_change = change;
+}

-static struct change *create_change_notification( int subtree, int filter )
+static void remove_change_notification( struct change *change )
 {
+    if( change->next )
+        change->next->prev = change->prev;
+    else
+        last_change = change->prev;
+    if( change->prev )
+        change->prev->next = change->next;
+    else
+        first_change = change->next;
+    change->prev = change->next = NULL;
+}
+
+struct change *get_change_obj( struct process *process, obj_handle_t handle, unsigned int access )
+{
+    return (struct change *)get_handle_obj( process, handle, access, &change_ops );
+}
+
+static void change_destroy( struct object *obj )
+{
+    struct change *change = (struct change *)obj;
+
+    remove_change_notification( change );
+    free( change->name );
+}
+
+static void adjust_changes( int fd, unsigned int filter )
+{
+#ifdef F_NOTIFY
+    unsigned int val;
+    if ( 0 > fcntl( fd, F_SETSIG, RT_SIGNAL_NOTIFY) )
+        return;
+
+    val = DN_MULTISHOT;
+    if( filter & FILE_NOTIFY_CHANGE_FILE_NAME )
+        val |= DN_RENAME | DN_DELETE | DN_CREATE;
+    if( filter & FILE_NOTIFY_CHANGE_DIR_NAME )
+        val |= DN_RENAME | DN_DELETE | DN_CREATE;
+    if( filter & FILE_NOTIFY_CHANGE_ATTRIBUTES )
+        val |= DN_ATTRIB;
+    if( filter & FILE_NOTIFY_CHANGE_SIZE )
+        val |= DN_MODIFY;
+    if( filter & FILE_NOTIFY_CHANGE_LAST_WRITE )
+        val |= DN_MODIFY;
+    if( filter & FILE_NOTIFY_CHANGE_SECURITY )
+        val |= DN_ATTRIB;
+    /* fprintf(stderr,"setting F_NOTIFY to %08x for %d (%s)\n",
+               val,fd,change->name); */
+    fcntl( fd, F_NOTIFY, val);
+#endif
+}
+
+static struct change *create_change_notification( 
+        const char *name, int len, int subtree, int filter )
+ {
     struct change *change;
+    char *filename;
+    int fd;
+
+    /* fprintf(stderr, "Creating change notification\n"); */
+    filename = (char *) malloc (len + 1);
+    memcpy(filename, name, len);
+    filename[len]=0;
+ 
+    fd = open(filename, O_RDONLY);
+    if( fd < 0 )
+    {
+        free( filename );
+        return NULL;
+    }
+
+    adjust_changes( fd, filter );
+
     if ((change = alloc_object( &change_ops )))
     {
+        change->fd      = fd;
         change->subtree = subtree;
         change->filter  = filter;
+        change->signaled = 0;
+        change->name    = filename;
+
+        add_change_notification( change );
     }
+
+    /* fprintf(stderr,"done\n"); */
+
     return change;
 }

@@ -66,27 +170,82 @@
 {
     struct change *change = (struct change *)obj;
     assert( obj->ops == &change_ops );
-    fprintf( stderr, "Change notification sub=%d filter=%08x\n",
+    fprintf( stderr, "Change notification sub=%d filter=%08x file:\n",
              change->subtree, change->filter );
 }

static int change_signaled( struct object *obj, struct thread *thread )
 {
-/*    struct change *change = (struct change *)obj;*/
+    struct change *change = (struct change *)obj;
     assert( obj->ops == &change_ops );
-    return 0;  /* never signaled for now */
+    /* fprintf(stderr,"signalled\n"); */
+    return change->signaled;
+}
+
+static int change_satisfied( struct object *obj, struct thread *thread )
+{
+    assert( obj->ops == &change_ops );
+    /* fprintf(stderr,"satisfied\n"); */
+    return 0; /* not abandoned */
+}
+
+/* FIXME: this is O(n) ... probably can be improved */
+static struct change * change_from_fd ( int fd )
+{
+    struct change *x;
+
+    /* search for a matching fd */
+    for( x=first_change; x; x=x->next )
+        if( x->fd == fd )
+             break;
+
+    return x;
+}
+
+/* enter here from signal handler */
+void do_change_notify( int fd )
+{
+    struct change *change;
+
+    /* fprintf(stderr, "got signal!\n"); */
+
+    change = change_from_fd( fd );
+    if(!change)
+        return;
+
+    /* fprintf(stderr, "found notification %s (%d)\n", change->name, fd ); */
+
+    /* wake up threads waiting on this change notification */
+    change->signaled ++;
+    wake_up(&change->obj, 0);
 }

/* create a change notification */
 DECL_HANDLER(create_change_notification)
 {
     struct change *change;
+    const char *name = get_req_data();
+    int len = get_req_data_size();

reply->handle = 0;
-    if ((change = create_change_notification( req->subtree, req->filter )))
+    if ((change = create_change_notification( name, len, req->subtree, req->filter )))
     {
         reply->handle = alloc_handle( current->process, change,
                                       STANDARD_RIGHTS_REQUIRED|SYNCHRONIZE, 0 );
         release_object( change );
     }
 }
+
+DECL_HANDLER(next_change_notification)
+{
+    struct change *change;
+
+    change = get_change_obj( current->process, req->handle, 0 );
+    if (!change)
+        return;
+
+    if( change->signaled > 0 )
+        change->signaled --;
+    release_object( change );
+}
+
Index: server/fd.c
===================================================================
RCS file: /cvstrees/crossover/office/wine/server/fd.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 fd.c
--- server/fd.c	21 Feb 2003 01:33:09 -0000	1.1.1.1
+++ server/fd.c	27 Feb 2003 01:22:18 -0000
@@ -40,6 +40,12 @@
 #include "request.h"
 #include "console.h"

+extern void do_change_notify( int fd );
+
+#ifndef RT_SIGNAL_NOTIFY
+#define RT_SIGNAL_NOTIFY 34
+#endif
+
 struct fd
 {
     struct object        obj;        /* object header */
@@ -238,6 +244,13 @@
     exit(1);
 }

+void siginfo_handler( int signum, siginfo_t *si, void *x)
+{
+    /* fprintf(stderr,"signal!\n"); */
+    
+    do_change_notify( si->si_fd );
+}
+
 /* server main poll() loop */
 void main_loop(void)
 {
@@ -266,6 +279,11 @@
     action.sa_handler = sigterm_handler;
     sigaction( SIGQUIT, &action, NULL );
     sigaction( SIGTERM, &action, NULL );
+
+    action.sa_handler = NULL;
+    action.sa_sigaction = siginfo_handler;
+    action.sa_flags = SA_SIGINFO;
+    sigaction( RT_SIGNAL_NOTIFY, &action, NULL );

while (active_users)
     {
Index: server/object.h
===================================================================
RCS file: /cvstrees/crossover/office/wine/server/object.h,v
retrieving revision 1.1.1.8
diff -u -r1.1.1.8 object.h
--- server/object.h	21 Feb 2003 01:33:10 -0000	1.1.1.8
+++ server/object.h	27 Feb 2003 01:22:18 -0000
@@ -119,6 +119,10 @@

extern void abandon_mutexes( struct thread *thread );

+/* change functions */
+
+extern void do_change_notify( int fd );
+
 /* serial functions */

int get_serial_async_timeout(struct object *obj, int type, int count);
Index: server/protocol.def
===================================================================
RCS file: /cvstrees/crossover/office/wine/server/protocol.def,v
retrieving revision 1.14
diff -u -r1.14 protocol.def
--- server/protocol.def	21 Feb 2003 05:23:23 -0000	1.14
+++ server/protocol.def	27 Feb 2003 01:22:18 -0000
@@ -1061,6 +1061,9 @@
     obj_handle_t handle;        /* handle to the change notification */
 @END

+@REQ(next_change_notification)
+    obj_handle_t handle;        /* handle to the change notification */
+@END

/* Create a file mapping */
 @REQ(create_mapping)
Index: files/change.c
===================================================================
RCS file: /cvstrees/crossover/office/wine/files/change.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 change.c
--- files/change.c	29 Aug 2002 20:08:19 -0000	1.1.1.4
+++ files/change.c	27 Feb 2003 01:22:19 -0000
@@ -34,6 +34,9 @@
 #include <time.h>
 #include "winbase.h"
 #include "winerror.h"
+#include "msdos.h"
+#include "file.h"
+#include "heap.h"
 #include "wine/server.h"
 #include "wine/debug.h"

@@ -45,17 +48,18 @@
 HANDLE WINAPI FindFirstChangeNotificationA( LPCSTR lpPathName, BOOL bWatchSubtree,
                                             DWORD dwNotifyFilter )
 {
-    HANDLE ret = INVALID_HANDLE_VALUE;
-
-    FIXME("this is not supported yet (non-trivial).\n");
+    HANDLE ret;
+    LPWSTR path;
+    DWORD len;
+
+    TRACE("%s %d %08lx\n", debugstr_a(lpPathName), bWatchSubtree, dwNotifyFilter);
+
+    len = MultiByteToWideChar(CP_ACP, 0, lpPathName, -1, NULL, 0);
+    path = HeapAlloc(GetProcessHeap(), 0, len);
+    MultiByteToWideChar(CP_ACP, 0, lpPathName, -1, path, len);
+    ret = FindFirstChangeNotificationW( path, bWatchSubtree, dwNotifyFilter );
+    HeapFree(GetProcessHeap(), 0, path);

-    SERVER_START_REQ( create_change_notification )
-    {
-        req->subtree = bWatchSubtree;
-        req->filter  = dwNotifyFilter;
-        if (!wine_server_call_err( req )) ret = reply->handle;
-    }
-    SERVER_END_REQ;
     return ret;
 }

@@ -67,13 +71,23 @@
                                                 DWORD dwNotifyFilter)
 {
     HANDLE ret = INVALID_HANDLE_VALUE;
+    DOS_FULL_NAME full_name;

-    FIXME("this is not supported yet (non-trivial).\n");
+    TRACE("%s %d %08lx\n",debugstr_w(lpPathName), bWatchSubtree, dwNotifyFilter);
+
+    if (!DOSFS_GetFullName( lpPathName, TRUE, &full_name ))
+    {
+	WARN("Unable to get full filename from %s (GLE %ld)\n",
+	     debugstr_w(lpPathName), GetLastError());
+        return ret;
+    }

SERVER_START_REQ( create_change_notification )
     {
         req->subtree = bWatchSubtree;
         req->filter  = dwNotifyFilter;
+        wine_server_add_data( req, full_name.long_name, 
+                              strlen(full_name.long_name) );
         if (!wine_server_call_err( req )) ret = reply->handle;
     }
     SERVER_END_REQ;
@@ -85,8 +99,17 @@
  */
 BOOL WINAPI FindNextChangeNotification( HANDLE handle )
 {
-    /* FIXME: do something */
-    return TRUE;
+    BOOL r;
+
+    TRACE("%p\n",handle);
+
+    SERVER_START_REQ( next_change_notification )
+    {
+        req->handle = handle;
+        r = wine_server_call_err( req );
+    }
+    SERVER_END_REQ;
+    return !r;
 }

/****************************************************************************

FindFirstChangeNotification (Was: miranda)

[Alexandre Julliard]

Mike McCormack  writes:
> Which portability fixes need to be made Alexandre?

Mostly the RT signal stuff. You can't just #define RT_SIGNAL_NOTIFY
if it's missing...

[Mike Hearn]

> However that too
> experiences many problems and the modern win32 obsession of creating
> irritating GUI mutations is probably the reason. Eg. window creation
> sometimes hangs wine, dragging window location sometimes hangs wine,
> fonts seem to go haywire from time to time, preferences dialog seems to
> have various breakages, etc.

These are probably various unrelated bugs in Wine. I've also seen the
hang when dragging Trillian, I think the reason is that in order to do
non-opaque dragging wine locks the X server, and then if the mouse moves
too fast it "releases" the drag and doesn't release X. It looks like the
machine has locked, but killing wine releases everything.

It might be better to try and fix wine, but if you're not feeling like
some happy hacking...... :)
> So I was interested in trying out "Miranda
> I-M" which looked from the screenshots (in default mode anyhow) to be a
> reasonably conventional-looking win32 GUI client and seems to be under
> active development judging by sourceforge stats.
>
> Unfortunately after installation, which went pretty well, the program
> fails to start quite early on with this;
>
> fixme:file:FindFirstChangeNotificationA this is not supported yet (non-trivial).

This is almost certainly not the problem, unless this program has a
_very_ unusual installation procedure. What that function does is allow
the program to be notified by Windows when something changes on disk
afaik, the equivalent on Linux is FAM or dnotify.

Programs usually use it to give a more responsive GUI, ie if something
on disk changes while it's showing you a directory you don't have to
manually force a refresh.

I'd suggest doing a relay trace and seeing what's really going on,
installs can fail for a variety of reasons.
> (1) is the above something that I can work on and/or help anyone else
> work on?

For sure, it'd be nice to have but I don't know if it'd solve that
problem.
> (2) does anyone know of any other win32-based I-M client (supporting at
> least ICQ, Yahoo, MSN, AIM) that is stable under wine?

I'm working on getting RhymBox, a rather spiffy Jabber client, working
under Wine (rhymbox.org) - at the moment though it doesn't even start :)

You might simply be better off hacking on one of the linux IM clients to
bring it up to scratch. For other Win32 clients, check the apps db

thanks -mike

[Mike Hearn]

> > So I was interested in trying out "Miranda
> > I-M" which looked from the screenshots (in default mode anyhow) to be a
> > reasonably conventional-looking win32 GUI client and seems to be under
> > active development judging by sourceforge stats.
> >
> > Unfortunately after installation, which went pretty well, the program
> > fails to start quite early on with this;
> >
> > fixme:file:FindFirstChangeNotificationA this is not supported yet (non-trivial).

FWIW it runs fine here on Wine CVS, though being at work I didn't actually try to connect.
Prefs window is b0rked like Trillians is, you can't switch tab pages. I suspect
that's a bug in our treeview control. Some debugging would be required to make it work
really well.

[Geoff Thorpe]

Hi Mike,

Thanks for the feedback.

* Mike Hearn ([e-mail]) wrote:
> These are probably various unrelated bugs in Wine. I've also seen the
> hang when dragging Trillian, I think the reason is that in order to do
> non-opaque dragging wine locks the X server, and then if the mouse moves
> too fast it "releases" the drag and doesn't release X. It looks like the
> machine has locked, but killing wine releases everything.

Hm ... is there anyway to tweak the window dragging so this locking
isn't required? FWIW: I also occasionally saw window creation crash out,
eg. if trillian was lurking in the status bar (KDE integration is cool
for that, BTW :-) and a message came in, the chat window that gets
created would run a 50/50 chance at best.
> It might be better to try and fix wine, but if you're not feeling like
> some happy hacking...... :)

Well I'm not against doing so, but I don't know the wine internals at
all. As I wouldn't really recognise "normal" operation anyway, it seems
unlikely I'd have the faintest clue when I am observing "abnormal"
operation. If there's a wine hacker who wants to crunch some bugs and I
could provide some grunt-work, by all means please let me know. I hack
code reasonably well, it's just wine's architecture (and to some extent
win32 too) that throw up lots of question marks for me. For now, at
least ...
> > Unfortunately after installation, which went pretty well, the program
> > fails to start quite early on with this;
> >
> > fixme:file:FindFirstChangeNotificationA this is not supported yet (non-trivial).
>
> This is almost certainly not the problem, unless this program has a
> _very_ unusual installation procedure. What that function does is allow
> the program to be notified by Windows when something changes on disk
> afaik, the equivalent on Linux is FAM or dnotify.

Um, as mentioned - installation went fine, that fixme is what happened
when I tried to launch the program after installation. It is the only
output I saw, after which wine gave up immediately. There was no
discernable GUI activity having taken place.
> Programs usually use it to give a more responsive GUI, ie if something
> on disk changes while it's showing you a directory you don't have to
> manually force a refresh.

Yeah I'd guessed as much, partly from the name of the missing function,
but especially given the "non-trivial" trailer (I can imagine such a
thing being tricky with support on unix systems varying a lot as well as
the complexity of working this into wineserver's state-machine).
> I'd suggest doing a relay trace and seeing what's really going on,
> installs can fail for a variety of reasons.

As mentioned, installation seemed OK. If you want to contact me off-list
with any other suggetions/details however I'd be happy to help in
whatever way I can to diagnose this.
> > (1) is the above something that I can work on and/or help anyone else
> > work on?
>
> For sure, it'd be nice to have but I don't know if it'd solve that
> problem.
> > (2) does anyone know of any other win32-based I-M client (supporting at
> > least ICQ, Yahoo, MSN, AIM) that is stable under wine?
>
> I'm working on getting RhymBox, a rather spiffy Jabber client, working
> under Wine (rhymbox.org) - at the moment though it doesn't even start :)

Ah, so trillian it is then ...
> You might simply be better off hacking on one of the linux IM clients to
> bring it up to scratch. For other Win32 clients, check the apps db

The linux IM clients I've tried (gaim, everybuddy, etc) seem flakey at
best. The original per-protocol clients seem ok (eg. yahoo's client) but
I don't want closed-source advertisement-ware nor do I want to have a
different program for each protocol (hell, I don't especially like
I-Ming anyway, but situations demand it). I have this sinking feeling
I'm going to end up running bochs which is a far more heavyweight
solution than I'd prefer.

Someone mentioned mICQ(.org) which I could certainly cope just fine
with, however it appears to be ICQ-only which would still put me back to
square one w.r.t. yahoo, MSN, etc.

In a subsequent post you said;
> FWIW it runs fine here on Wine CVS, though being at work I didn't
> actually try to connect.  Prefs window is b0rked like Trillians is,
> you can't switch tab pages. I suspect that's a bug in our treeview
> control.  Some debugging would be required to make it work really
> well.

I would be most interested to know how you got it to run! :-) My wine
installation is pretty much a straight;

# cvs co wine
# cd wine
# ./tools/wineinstall
(enter yes for installation, enter root password, enter yes for creating
~/.config, enter yes for wine-only install (no native MS)).
# cp <install-file>.exe ~/c/
# wine C:\<install-file>.exe
...
# wine C:\Program\ Files\...

Thanks again for the feedback, I appreciate it. If you've got better
things to do than to continue with this then no sweat, just give me the
word - you'd know better than I whether this is a tree worth barking up.

Cheers,
Geoff

[Mike Hearn]

> Hm ... is there anyway to tweak the window dragging so this locking
> isn't required? FWIW: I also occasionally saw window creation crash out,
> eg. if trillian was lurking in the status bar (KDE integration is cool
> for that, BTW :-) and a message came in, the chat window that gets
> created would run a 50/50 chance at best.

AFAIK no, the X locks are needed to do the XOR of the border on to the
screen when you're not using opaque drags (I don't know why trillian
does non-opaque drags like that....., maybe it's a wine bug after all,
I've not really used it on Windows).
> Well I'm not against doing so, but I don't know the wine internals at
> all. As I wouldn't really recognise "normal" operation anyway, it seems
> unlikely I'd have the faintest clue when I am observing "abnormal"
> operation. If there's a wine hacker who wants to crunch some bugs and I
> could provide some grunt-work, by all means please let me know. I hack
> code reasonably well, it's just wine's architecture (and to some extent
> win32 too) that throw up lots of question marks for me. For now, at
> least ...

I was in the same boat a few months ago. I'm still a total newbie, Wine
is large, but I know enough to fix some bugs now. It's not really as
hard as it looks, believe me :)
> Um, as mentioned - installation went fine, that fixme is what happened
> when I tried to launch the program after installation. It is the only
> output I saw, after which wine gave up immediately. There was no
> discernable GUI activity having taken place.

Sorry, I must have not been thinking originally. As I said, try doing
some traces, to see where the problem occurs:

wine --debugmsg +relay foo.exe 2>relay.log
> Yeah I'd guessed as much, partly from the name of the missing function,
> but especially given the "non-trivial" trailer (I can imagine such a
> thing being tricky with support on unix systems varying a lot as well as
> the complexity of working this into wineserver's state-machine).

Well FAM is pretty standard, even if it is apparently pretty disgusting
code inside. KDE and GNOME use it for instance, and it's even portable
between forms of UNIX. It's more a case of nobody has written it yet,
there are other more important things to write.
> The linux IM clients I've tried (gaim, everybuddy, etc) seem flakey at
> best.

There's an article up at gnomedesktop.org about the new GAIM which
should be released soon. It's looking a lot better than its
predecessor... but, having said that, I'm the one trying to make a Win32
chat program work :)
> The original per-protocol clients seem ok (eg. yahoo's client) but
> I don't want closed-source advertisement-ware nor do I want to have a
> different program for each protocol (hell, I don't especially like
> I-Ming anyway, but situations demand it). I have this sinking feeling
> I'm going to end up running bochs which is a far more heavyweight
> solution than I'd prefer.

Yikes! You'd have to be really desperate to run an entire VM just for
one chat program....
> I would be most interested to know how you got it to run! :-) My wine
> installation is pretty much straight..

My setup is a bit different, I basically started with CrossOver, then
migrated it to Wine CVS, so all that's left is the original CrossOver
fake_windows directory and the config file, neither of which vary much
from the Wine defaults afaik.

The main difference is probably that I have IE6 installed, you may want
to try it first, as this installs some DLLs you are probably missing
otherwise. Doing some traces would tell you whether that's right or not.

thanks -mike