[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Qt-only KDE applications
From:       Thiago Macieira <thiagom () wanadoo ! fr>
Date:       2002-01-23 18:30:35
[Download RAW message or body]

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 provides 
Unix sockets provides the Internet sockets. Actually, the current code does 
not specify that the DCOP communications should be Unix-socket-only. It's 
just a matter of giving some socket names that resolve to TCP sockets and 
they'll be used even before Unix is tried.

I tried to write the sockets code as platform-independent as possible. I'm not 
sure, but I believe that any platform that complies to the RFCs should work. 
Problem is: Windows is not conformant, intentionally. Even the API for IPv6, 
which Microsoft is still implementing, they have already decided not to 
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 those 
who are used to ELF. To create a .dll, you need a list of symbols that are 
exported and several steps. And there's a problem of accessing variables.

That was actually a problem in the compiler/linker, that it generated 
function-access code (that is, a jump) instead of relocations to data inside 
the libraries. Other two problems:
- DLLs are not Position Independent. Each library has to have a "base address" 
known at link time
- DLLs must solve all relocations at compile/link-time. That is, there's no 
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 
dumping PE-COFF and use ELF even on Windows when I was faced with those 
problems.

-- 
  Thiago Macieira - UFOT Registry number: 1001
 thiagom@mail.com
   ICQ UIN: 1967141  PGP: 0x8F2978D5 and 0xEA9037A5 (PGP 2.x)
     Registered Linux user #65028

[prev in list] [next in list] [prev in thread] [next in thread]