Slashdot Mirror

← Back to Stories (view on slashdot.org)

KDE 2.2.1, On Win32/Cygwin

Posted by timothy on from the windows-with-a-small-w dept.

m_ilya writes: "It looks like KDE 2.2.1 has been ported on Cygwin. More than year ago I was forced to use WinNT at work, and I've been missing the Linux desktop a lot. I hope if I will be ever forced to use Windows again I would be able to have more Unix-friendly desktop :). Here's the announcement. Kudos to all the KDE hackers." Check out the posting on the Dot for some more links.

4 of 225 comments (clear)

  1. Re:Too bad nobody will use it... by fault0 · · Score: 4, Informative

    Sure you can. Qt/X11 is gpl'd without any other restrictions other than what the GPL has. So you can port it to whatever you want, including distribute binaries of said Qt port.

    Afaik, these guys are using Cygwin, which has a X11 server anyways, so not even that applies here.

  2. Re:KDE on windows by fault0 · · Score: 3, Informative

    > I wonder if it would not be more effective (or possible?) to port Kde as a litestep style shell replacement.

    I think they'd have to port Qt to windows natively. This, fortunatly, wouldn't be hard for an experienced programmer who knows the Windows API AND xlib. Most of the platform specific code of Qt is pretty well split off from the rest of the code. They are in the QXXX_x11.cpp files. There are only about 20 of these files, and KDE doesn't even use/require all of them (like QSound).

  3. Other resources by Col.+Panic · · Score: 4, Informative
    I also am forced to use NT at work, but it is much easier with a few tools. Here are a few other ports:

    pstools

    strings

    grep

  4. Re:Don't expect this to be a barn burner by man_ls · · Score: 3, Informative

    The problem is that a lot of the POSIX-style system calls don't map well to the Win32 system layer. One main example is fork():

    In Unix, it's fork and be done with it. The code's built in. Under Cygwin, fork() is emulated like in the first versions of Unix, involing some wierd scheme of memory address copying and process signaling, since Win32 has no need in itself for a function like fork.

    There was another in the similar line, I forget what exactly, but the cygwin FAQ or thereabouts said that those two system calls are what causes such a massive performance hit in emulation.

    Anything that has to do real-time conversions for an app is going to be slower than the native environment, even on a fast computer.