Qt X11 application built for Windows platform

3
votes

I know it is weird but I need to execute a Qt GUI application that supports X11 protocol on MS Windows platform.

It is obvious that if I build my Qt source code in Unix environment it automatically becomes an X11 application and this application can be run only on Unix Operating Systems, not MS Windows.

I tried to use MXE (MinGW cross environment) to compile my application in Unix for Windows, but it does not help for X11 issue. It creates an application for Windows but the application is not an XWindow application.

There is also a XPortMinGW project for minGW. But I do not know if it works for Qt applications.

Is there any way to build my Qt application with X11 support that can run in Windows OS?

1
qtmingwx11cross-compilingmxe
What do you mean by "supports X11 protocol"? – Kamil Klimek
How do you imagine X11 support in Windows, that don't support X11? If you have a Qt GUI Project just build it under Unix for Unix executable (with X11 support) and build under Windows for Windows executable (with Windows graphic system). – dmr
"It creates an application for Windows" -- Is there something wrong with it? Does it run? – n. 1.8e9-where's-my-share m.
There are some X server implementations for windows if that's what you mean... just google for it. And if by "supports X11 protocol" you mean that you have some X11 specific code jumbled up with qt widgets - just forget about it, it won't work unless you use some #ifdefs and windows equivalents. – j_kubik
"Supports X11 protocol" means; GUI aplication uses X11 libraries in windows operating system instead of native windows GUI libraries. – Anony

1 Answers

2
votes

I don't think that there's any need for cross-compilation. There are two problems:

  1. Getting Xlib compiled for Windows. I don't know offhand of any maintained Xlib implementations that are ported to Windows. You will definitely need to find one, or make one. Hopefully Xlib depends only on a handful of posix APIs and they may be easy to translate to win32. Forget about Cygwin.

    You may have luck porting Xlib yourself to Qt's network backend and making it cross-platform in the process, too. Xlib would simply use the core and network modules of Qt. No problem with that.

    The good news here are that Qt 5 comes with a bundled Xlib implementation. It would be presumably much easier to get that to compile on Windows than some other implementation.

  2. Configuring Qt to build using said Xlib on Windows. To do it right, you'll probably want to mess a bit with and rebuild the configure tool that comes with Qt, and add a makespec that will link with the Xlib.

    This should be much easier to do with Qt 5.

It's not an entirely trivial thing to do, but should be possible. Give yourself a month and expect to get very intimate with some details of Qt's configuration and Xlib.

Notes About Cygwin

  1. If your application is closed-source and distributed outside of your organization, you need to buy a commercial license in order to redistribute cygwin.dll. Otherwise, Cygwin is GPL and merely linking to cygwin.dll makes your application a derived work.

  2. Cygwin becomes problematic when you mix posix- and non-posix code in the same application, especially if the non-posix code is a large framework like Qt. You can of course use the Posix platform code in Qt and make it all run on Cygwin, but that way you lose performance and expose yourself to shortcoming of Cygwin's emulation of POSIX APIs.

  3. Using Cygwin for Xlib / windowing system but having Qt otherwise use Windows APIs may require a lot of tweaking for Qt code. So may using Qt with Xlib on Windows of course, but at least you don't have to debug/work around Cygwin's quirks.