KDE applications have several runtime library and tool dependencies. The library kdelibs for example currently has 17 external dependencies, which are zlib, pnglib, jpeglib, tiff, jasper, pcre carbon lib, acl, bzip2, libxml2, libxslt, openexr, openssl, gettext, perl, dbus and Qt.
Linux distributions have most of those libraries either on their installation CD's or in their repositories, which makes it easy to install them if a specific KDE package depends on it. This dependency tracking is provided by an install tool like RPM or DPKG and the libraries use a common package format, for example RPM or DEB.
On Windows the situation is completely different. Libraries required by KDE packages are not on any Windows distribution cd, they are scattered across the Internet and don't have a common format. Packages could consist of ZIP, BZ2, executables containing specific installers or MSI (Microsoft Software Installation) packages.
Additionally there is no common path layout for libary and tool packages. While many open source libraries and tools follow the bin/include/lib/doc/... directory layout, there are of course packages which use other schemes.
For building single installer packages there are several installer build systems available on Windows, like the open source tool NSIS (http://nsis.sourceforge.net) and Inno Setup (http://www.jrsoftware.org/isinfo.php), and commercial tools like InstallShield and the Windows Installer. Some installers are able to download additional packages from the Internet, like the Windows installer for the Qt opensource edition.
All mentioned installers have one important disadvantage: they build an executable, which is unable to be customized very well at runtime.
Modified URL's or paths of related packages requires an installer recompile and manual work to make a new release, announcements, etc. All users have to download the new version before they can use the new feature. This is all superfluous work.
There are other installer types available like the Cygwin installer, which is able to get its configuration online from the Internet. The KDE installer falls into this category because on every start it reads its basic configuration from a well-known website. This configuration could be quickly changed in case downloads are broken or additional sites providing KDE on Windows applications are available.
The KDE installer is designed like an installation wizard. Technically it uses a static Qt4 release, which makes it independent from any other installed library on the target system. The executable is compressed with UPX. The resulting executable is about 2.8 MB, which isn't very much for a Qt GUI-based installer.
People are working currently on different parts of KDE on Windows platform. Some people assist by compiling KDE on Windows from time to time just to see if it compiles. Others are listening to the kde-windows mailing list and doing support for people trying to enter KDE development, which is very important. And some are working on the D-Bus merge into the main D-Bus code, which requires currently additional developers, because there are still some challenges to be solved.
Some are trying to port kdelibs to Windows (not just compilation), which has seen some progress recently. I have seen that kdeinit, klauncher, kded and other basic KDE background applications are running already and they can use kio_file completely and kio_http partially. There are areas not yet ported, for example SSL support for kio_http. I have personally tested the applications KStars and KDevelop to gauge the current state of porting. KStars is usable, but display of downloaded images is broken and telescope control does not yet work and needs porting. KDevelop could be started and I was able to open a project and use the editor, class browser and the settings dialog, but there are many functions not listed in the IDE.
The best approach for developers interested in having KDE applications on Windows is to take a specific application and to port it or at least to try to get it running. During the porting they'll surely hit some bugs in the main KDE libraries which then can be fixed more easily than by just running kdelibs testcases (at least in my opinion).
If many developers would do so, the port would be completed in a short period of time. We need some publicity to get developers who are willing to work on kdelibs4/windows.
In the following screenshots, the Qt application "dbus-viewer" shows several kdebase applications running, like kded and klauncher. The klauncher D-Bus interface is open in the right window and shows some available methods.
As mentioned before, the "file" kioslave is mostly operational. This screenshot shows Kate opening via the KDE file dialog. This also shows that klauncher is able to start a kioslave:
This screenshot shows KWrite with a loaded document. See the syntax highlightning activated:
The following screenshot shows KFind searching for .cpp files in the kdebase source tree. This is also an example of a working "file" kio_slave:
The start page of Konqueror (currently with broken images):
It is very impressive to see how open source works and how talented people are contributing to this implementation. When I remember the beginnings (KDE 1 on Cygwin in 2001) there was a dream that it would be great to have KDE applications running on a Windows computer, and over time it evolved with KDE 2 and 3 on Cygwin and now KDE 4, natively running on Windows is on the horizon. Many thanks to all the people who have made this possible. Very impressive indeed.