win32 to x11 where to start ?

Posted on 2004-04-22
Last Modified: 2010-04-21

Firstly (and don't hold this against me) I'm a win32 programmer who's looking to convert their app. to X11.  The application somewhat runs under wine but I'd really like to make it run under X11 (probably KDE).  Can you point me in the direction of where to start, tutorials, websites, boot etc....  Also what is the best development environment for this.

Thanks! :)
Question by:alsmorris
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions

Expert Comment

ID: 10892958
If you have the source for the application, I guess the easiest path is to use Winelib. See
LVL 23

Accepted Solution

brettmjohnson earned 150 total points
ID: 10893408
It is usually much easier to design code for portability before implementation.
The difficulties in moving an app from Win32 to Unix depend on how much
proprietary MS kits and constructs you used in the past.

You might be better off converting the code gradually.  Since it is often much
easier to convert Unix code to work on Windows, I would convert the app to
be more Unix-like in its concepts and architecture.  This will allow you to take
your existing Windows app and modify it in ways that still allow it to run on
Windows.  You can make most of the changes and debugging in your existing
Windows development environment, rather than starting on Unix with a code
base that doesn't even come close to compiling.  Hopefully, the transition will
allow you to use a common code base for both your Windows and Unix
implementation.  I would take the following steps.

1) Make sure your application has a design that sufficiently separates the
human interface from the core logic.  The Model/View/Controller (MVC) design
methodology stresses this.  If you adhered to this methodology (or a similar one)
the visual interface to your application should be pretty well separated from
the business logic.  I tend to isolate operating system interfaces into an OS
abstraction layer as well - at least for those interfaces that are non-ANSI C
and non-Posix.  Abstracting and isolating the interfaces to the user and the
OS should help you clarify the core functionality of your application.  One
indication of success would be minimal use of platform-specific conditional
compilation in your core logic (#ifdef WIN32).

2) Convert core logic and OS interfaces from Win32 interfaces to STL, Posix,
and ANSI-C library interfaces.  For instance, rather than CreatFile(), use
fopen(); rather than CreateThread() use pthread_create(); etc.  Microsoft
has provided nearly complete Posix interfaces (in order to sell to the US
military and government).  Any holes can usually be filled with (usually free)
third-party libraries.  After this conversion, your app should still run fine
on Windows.

3) Once you have isolated the core logic from the UI and OS, avoid using
MS-specific data types in your core logic.  Rather than using DWORD, use
either a native type (unsigned long, void *, etc) or a recognized typedef
(uint_t, uint32_t, uint64_t, size_t, etc).  The UI and OS abstraction layers
will then perform the appropriate cast when calling the appropriate Win32 or
Unix specific APIs.

4) Move your GUI code from Win32 to a platform-independent UI abstraction
like Qt.  Avoid falling into the trap of making the UI "identical" for all platforms.
It should be common, recognizable, navigatable.  But a Windows app should
look like a Windows app, a Mac OS X app should look like a Mac OS X app, a
Unix app should look like an X11 app (actually a Motif, Gnome, or KDE app).

5) Clean up your app to minimize the number of compiler warnings.  Turn on
the maximum warning level and clean up (or justify not cleaning up) each
warning.  You would be surprise how well this works when porting C code.
Try to get your code to compile under one of the Windows versions of gcc
such as djgpp or cygwin.

5) Once you have this all working on Windows, move the code over to a
32-bit x86 based Unix environment like Linux, FreeBSD, or Solaris x86 and
start ironing out the wrinkles.

6) Once you have things working on a 32-bit x86, move it to a 64-bit
BIG_ENDIAN architecture like TRU64 on Alpha, Solaris9 on ultraSPARC,
YellowDog Linux on a G5.  This will help you isolate byte-order and word-size

When you can snatch the pebble from my hand, walk upon the rice paper
without leaving a trail, and run your app on 64-bit Mac OS X, you will have
completed your journey, young Grasshopper.

Expert Comment

ID: 10895873
LVL 45

Expert Comment

ID: 10896583
KDE depends more on Qt .... check

Author Comment

ID: 10922123
Thank you all for your input. :)

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Have you ever been frustrated by having to click seven times in order to retrieve a small bit of information from the web, always the same seven clicks, scrolling down and down until you reach your target? When you know the benefits of the command l…
The purpose of this article is to demonstrate how we can upgrade Python from version 2.7.6 to Python 2.7.10 on the Linux Mint operating system. I am using an Oracle Virtual Box where I have installed Linux Mint operating system version 17.2. Once yo…
I've attached the XLSM Excel spreadsheet I used in the video and also text files containing the macros used below.…

696 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question