Re: xwinclip
Colin, Hmm... yes, xwinclip is now supposed to try to reconnect to the X Server when the X Server resets or shuts down. However, there may be some problem causing xwinclip to keep running after it fails to connect to the X Server. I will have to look into it. Thanks, Harold Colin Harrison wrote: Hi I've just noticed that the new winclip does not terminate when XWin is closed..it used to? Minor error but my XP now has an end program prompt on shutdown. Colin
Re: xwinclip
Hi I've just noticed that the new winclip does not terminate when XWin is closed..it used to? Minor error but my XP now has an end program prompt on shutdown. Colin
Re: new runtime pseudo-reloc in cygwin 1.3.18
Alexander Gottwald wrote:
> No. That was wrong. I think I'll have to redefine _XtInherit to NULL. The
> compare will work but the fallback to produce the "Unresolved inheritance"
> error will then result in a segfault.
NULL did not work. But I've changed it to another constant and now it works.
What should work too is using a cygwin or libX11 function. That means a
function which is imported from a dll in both cases (libXt and libXaw) and
which terminates the program. Maybe exit?
---8<---8<-
diff -ur lib/Xt/Initialize.c lib/Xt/Initialize.c
--- lib/Xt/Initialize.c Sat Jul 6 15:03:01 2002
+++ lib/Xt/Initialize.c Tue Dec 31 15:47:20 2002
@@ -174,7 +174,9 @@
#endif
}
-
+#if defined(__CYGWIN__)
+#undef _XtInherit
+#endif
#ifdef SUNSHLIB
void _XtInherit()
{
diff -ur lib/Xt/IntrinsicP.h lib/Xt/IntrinsicP.h
--- lib/Xt/IntrinsicP.h Mon Dec 17 18:32:44 2001
+++ lib/Xt/IntrinsicP.h Tue Dec 31 18:53:32 2002
@@ -298,6 +298,9 @@
void
#endif
);
+#if defined(__CYGWIN__)
+#define _XtInherit 0xdeadbeef
+#endif
extern void XtCreateWindow(
#if NeedFunctionPrototypes
8<8<-
NP: Zeraphine - Flieh mit mir
--
[EMAIL PROTECTED]
http://www.gotti.org ICQ: 126018723
Re: new runtime pseudo-reloc in cygwin 1.3.18
Alexander Gottwald wrote: > I changed it so that libXt uses _XtInherit and all other libraries and code > uses _imp___XtInherit. Now it seems that the comparisation is passed, but > It's worse than that. No. That was wrong. I think I'll have to redefine _XtInherit to NULL. The compare will work but the fallback to produce the "Unresolved inheritance" error will then result in a segfault. Or is there any other way to access the location of _XtInherit from libXaw at linktime? > Can libXt.dll call a function from libXaw.dll? > If not, then we can skip the whole shared libXaw and libXt part. Some of > the widget classes from libXaw have callbacks defined which are called in > libXt functions. I now found some code that uses this. So it does work. NP: VNV Nation - Solitary -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: new runtime pseudo-reloc in cygwin 1.3.18
Charles Wilson wrote:
> I seem to remember that pointer comparisons across a DLL boundary is a
> Bad Thing; relocations and such. But I don't remember where I saw that
> -- MSDN or ld docs, and I can't find it now. :-(
I changed it so that libXt uses _XtInherit and all other libraries and code
uses _imp___XtInherit. Now it seems that the comparisation is passed, but
It's worse than that.
Can libXt.dll call a function from libXaw.dll? eg:
in Xt:
void XtCallFunction(void (*func)(void)) {
(*func)();
}
in Xaw:
void XawFoo(void) {
}
void XawBar(void) {
XtCallFunction(XawFoo)
}
If not, then we can skip the whole shared libXaw and libXt part. Some of
the widget classes from libXaw have callbacks defined which are called in
libXt functions.
NP: VNV Nation - Prologue
--
[EMAIL PROTECTED]
http://www.gotti.org ICQ: 126018723
Re: new runtime pseudo-reloc in cygwin 1.3.18
Alexander Gottwald wrote:
So I don't even know where _XtInherit is called and whats different with the
relocation.
gdb revealed:
Dll1 (libXt) defines void _XtInherit(). Dll2 (libXaw) uses _XtInherit and
passes it to a function in libXt which does
if (x == _XtInherit) { foo() };
Unfortunatly it is not the same if _XtInherit is used in libXt or libXaw.
the statement x = _XtInherit for example resulted in
x = 0xb38478 for libXt and
x = 0x641550 for libXaw. And thats why the if condition failed.
I seem to remember that pointer comparisons across a DLL boundary is a
Bad Thing; relocations and such. But I don't remember where I saw that
-- MSDN or ld docs, and I can't find it now. :-(
--Chuck
Re: XFree and File Systems
On Tue, 31 Dec 2002 10:28 am, Alexander Gottwald wrote: > MartÃn De Marchi wrote: > > Hi! > > > > I'm developing a linux application, but the majority > > of the pc's in my organization have installed windows > > system, so Im going to install cigwin's xfree in the > > machines and use the linux application remotely. > > I need that the user (windows system) use the > > remote linux application (via xfree) and see the > > local windows file system (not the linux file system) > > for load and save files, to use the local printer. > > Is there any way for configure X and make this? > > No. Using the remote application is like walking to the linux pc and > working there. You don't have access to the windows host. The only way > to exchange files is to use a network filesystem (SMB or AFS) and access > this from linux and windows. Same for the printer. The best and easiest way is to have a central server (eg NT, 2000, XP or for an open-source GPL solution, Mitel SME/E-Smith) with each user with a directory on the server \\centralserver\username. Then have something along the lines of: mkdir -p $HOME/windows smbmount //centralserver/$USER $HOME/windows called when they either log onto the linux box (via XDMCP) or run the program (via ssh for example). Exact implementation will depend on whether you are using XDMCP or ssh and various other factors. If you don't have a central windows (like) server, then I would recommend looking at the GPL version of Mitel SME (http://www.e-smith.org) - it is essentially a free NT server replacement without any user-license restrictions. If you *really* want the user to be looking at their local filesystem, and you are using ssh, then something along the lines of: WINDOWS_IP=`echo $SSH_CLIENT | cut -d' ' -f 1` mkdir -p $HOME/windows WINHOST=`nmblookup -A $WINDOWS_IP | head -n 2 | tail -n 1 | tr -s [:blank:] ' ' | cut -d ' ' -f 2` smbmount //$WINHOST/c$ $HOME/windows in either the logon script of your linux box, or in the start-up script of your program may do the trick. (The above assumes the same usernames on the Windows and Linux box.) If using XDMCP, then replace the first line with: WINDOWS_IP=`echo $DISPLAY | cut -d= -f 2 | cut -d: -f 1` In all the above, there are various issues with passwords and security that would need to be resolved before using in a production situation. See the manpages. You may also want to change //$WINHOST/c$ to //$WINHOST/mydocs or whatever. Cheers, Rasjid. -- Rasjid Wilcox Canberra, Australia (UTC +10 hrs) http://www.openminddev.net
Re: Buildpatch for cygdps.dll
Done.
On Mon, Dec 30, 2002 at 08:09:42 -0500, Harold L Hunt wrote:
> Alexander,
>
> Good catch!
>
> Alan - do you want to commit this directly?
>
> Harold
>
> Alexander Gottwald <[EMAIL PROTECTED]> said:
>
> > Hi,
> >
> > the patch fixes some dependency problems with crosscompiling libdps.
> > The Imakefile has a build dependency for ProgramTargetName(pswrap) which
> > is pswrap.exe for cygwin, but should be pswrap when crosscompiling. This
> > caused libdps to be recompiled whenever make or make install waas called
> > for libdps. The patch changes the ProgramTargetName to
> HostProgramTargetName.
> >
> > Index: Imakefile
> > ===
> > RCS file: /cvs/xc/lib/dps/Imakefile,v
> > retrieving revision 1.15
> > diff -u -r1.15 Imakefile
> > --- Imakefile 2002/06/06 01:40:21 1.15
> > +++ Imakefile 2002/12/30 23:16:57
> > @@ -201,7 +201,7 @@
> >
> > includes:: $(DPSOPSCFILES) $(PSOPSCFILES) $(HEADERS)
> >
> > -$(DPSOPSCFILES) $(PSOPSCFILES): ProgramTargetName($(PSWRAP))
> > +$(DPSOPSCFILES) $(PSOPSCFILES): HostProgramTargetName($(PSWRAP))
> >
> > SRCS = \
> > ${COMMONSOURCEFILES} \
> > @@ -224,13 +224,13 @@
> >
> > .SUFFIXES: .psw .h
> >
> > -.psw.c : ProgramTargetName($(PSWRAP))
> > +.psw.c : HostProgramTargetName($(PSWRAP))
> > RunProgram(PSWRAP,-a -o $*.c -h $*.h $<)
> >
> > -.psw.h : ProgramTargetName($(PSWRAP))
> > +.psw.h : HostProgramTargetName($(PSWRAP))
> > RunProgram(PSWRAP,-a -h $*.h $< > /dev/null)
> >
> > -ProgramTargetName($(PSWRAP)):
> > +HostProgramTargetName($(PSWRAP)):
> > @echo "checking $@ over in $(PSWRAPSRC) first..."; \
> > cd $(PSWRAPSRC) && $(MAKE); \
> > echo "okay, continuing in $(CURRENT_DIR)"
> >
> > NP: VNV Nation - Saviour
> > --
> > [EMAIL PROTECTED]
> > http://www.gotti.org ICQ: 126018723
> >
> >
>
>
Re: xwinclip
Harold, I can't test it till January 6. I tested xwinclip which looks at event.xselection.selection instead of PRIMARY, and it worked fine. But I don't know whether other change has succeeded. Kensuke Matsuzaki
RE: XFree and File Systems
actualy there is a working NFS server but its still in testing. (search the cygwin-apps mailing list for details) no NFS client i know of though. the URL was http://www.oneparticularharbor.net/cygwin/ only tried it for an afternoon though. > -Original Message- > From: Alexander Gottwald > [mailto:[EMAIL PROTECTED]] > Sent: 31 December 2002 01:23 > To: [EMAIL PROTECTED] > Subject: Re: XFree and File Systems > > > Sylvain Petreolle wrote: > > > Hasn't got cygwin any nfs port ? > > No. This does not make sense since the NFS driver must be > attached to the > windows VFS. It would be possible to write a fhandler for > cygwin which > does all the nfs stuff but then only cygwin programs could access the > nfs files. It's the same as the /proc filesystem for cygwin. > > NP: VNV Nation - Procession > -- > [EMAIL PROTECTED] > http://www.gotti.org ICQ: 126018723 >
