From kde-core-devel Wed Jan 23 18:30:35 2002 From: Thiago Macieira Date: Wed, 23 Jan 2002 18:30:35 +0000 To: kde-core-devel Subject: Re: Qt-only KDE applications X-MARC-Message: https://marc.info/?l=kde-core-devel&m=101181077930828 Rik Hemsley wrote >UNIX sockets are used for DCOP. Hopefully these work the same on MacOS >X, but for Windows we could either steal some cygwin code or use TCP >sockets. DCOP communicates libICE, which can use TCP sockets instead if >you ask it to. This raises more complex security issues than those >involved with UNIX sockets, but I'm sure they can be worked out. Sockets are already one step closer to that because the same API that pro= vides=20 Unix sockets provides the Internet sockets. Actually, the current code do= es=20 not specify that the DCOP communications should be Unix-socket-only. It's= =20 just a matter of giving some socket names that resolve to TCP sockets and= =20 they'll be used even before Unix is tried. I tried to write the sockets code as platform-independent as possible. I'= m not=20 sure, but I believe that any platform that complies to the RFCs should wo= rk.=20 Problem is: Windows is not conformant, intentionally. Even the API for IP= v6,=20 which Microsoft is still implementing, they have already decided not to=20 follow some aspects of the RFC they don't like. >MacOS X and Windows have shared libraries. I seem to remember hearing >something about ltdl working on MacOS X, which would help us a lot. As >for Windows, well, I'm no Windows expert. Perhaps someone else knows >whether it would be possible to do some dlopen-style stuff with the >native API. The problem here is deeper. The executable format (PE-COFF) is pain for t= hose=20 who are used to ELF. To create a .dll, you need a list of symbols that ar= e=20 exported and several steps. And there's a problem of accessing variables. That was actually a problem in the compiler/linker, that it generated=20 function-access code (that is, a jump) instead of relocations to data ins= ide=20 the libraries. Other two problems: - DLLs are not Position Independent. Each library has to have a "base add= ress"=20 known at link time - DLLs must solve all relocations at compile/link-time. That is, there's = no=20 way to access symbols defined in the main program. I don't know if solution was found to those issues. I've even though of=20 dumping PE-COFF and use ELF even on Windows when I was faced with those=20 problems. --=20 Thiago Macieira - UFOT Registry number: 1001 thiagom@mail.com ICQ UIN: 1967141 PGP: 0x8F2978D5 and 0xEA9037A5 (PGP 2.x) Registered Linux user #65028