On February 10, 2005 07:38 pm, Thiago Macieira wrote:
> We use '/' as path separator in many places throughout KDE instead of
> using QDir::separator(). 

This is a bit of a misnomer. You can use C:/foo/bar just as well as C:\foo\bar 
as a path in Windows. Nothing will break. The tough part is more when you 
take into account the drive roots in win32. I know from experience that KURL 
does not play nice with Windows links because of this.

> We also expect /dev/null, /dev/zero, /dev/stdin 
> etc., to exist. I think Cygwin provides all that, but does a pure Visual
> C++ environment do that too?

This is one of the things I question... should we be accessing device files 
like that directly? Seems a bit presumptuous to me. It would be so easy to 
handle these things Does AtheOS have these devices? What if we want to go 
there someday? Even if it does, are they just some kind of 'emulation' 
mechanism (a-la Cygwin), whereby it would be more efficient to make direct 
system calls?

These kinds of problems are so easy to abstract out of kdelibs entriely, by 
using things like QDir::seperator() and other things ( for example, we could 
make a KDE wrapper class that provides QIODevices for null, random, 
stdin/out, etc, rather than accessing the files directly). I don't see why we 
need to be making these assumptions in the KDE core.

> As for sockets, the little I know about winsock is that it's a mess. And
> that it doesn't support AF_LOCAL (a.k.a., AF_UNIX) sockets, which we use
> from ICE to KIO.

No UNIX sockets is for sure a bad thing in WIn32.  But it is nothing you could 
not work around ( look at Java - there are many JDBC drivers, for instance, 
that will use a UNIX socket when in use in UNIX, and a TCP socket when in use 
in Windows (when you are making a local DB connection of course) ).

-- 
Jason Keirstead
http://www.keirstead.org
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<