POSIX for Windows

[John E]

Not long ago I built an open source program (originally written for Linux) to run under Windows (or more correctly, to run under Cygwin). Although this was just a technical exercise I was quite surprised at how well it all worked - but of course, to run the app on somebody else's PC would require them to install Cygwin - which isn't exactly a trivial task..!

I just wondered if anyone here has ever used Microsoft's POSIX Services for Windows and if so, what kind of experiences did they have? In particular, were the apps easy enough to deploy? Also (for graphical apps) was it still necessary to use some variant of 'X'?

[JVene]

Your question sounds more like "how do most developers create portable applications?"....

The short answer; frameworks.

Qt or wxWidgets are two common choices. Qt is more modern, and with the recent move to LPGL, it's free even for commercial use.

wxWidgets has always been free, and it's workable. It's an older design, and it's portability to Mac is more limited than Qt, but it is generally reliable.

Qt is considered by many to be "the" framework. There are "adjustments" one must make pursuant to it's design and development philosophy, but it is robust and full featured.

Generally, the reaction a C++ developer has to most API oriented questions, especially regarding portability, but even from a viewpoint of leverage, is to encapsulate - even if that means finding an existing library. Any direct usage of the underlying OS API's from application code binds that application to the operating system, which isn't a good business or technical position.

Portability issues come up even when staying within a platform. By insisting that the application code interface to the OS through a set of objects, there are fewer place in the code where adaptation are required. With some care, complete independence from platform version changes and of switching platforms can be achieved.

In my view, the only code which should directly interface to the OS API is that of a framework, or at the least an abstraction in the relative position of a framework. There simply is no payoff for not doing this, and the benefits are obvious in the long run.

[John E]

Thanks JVene. If this was my own project, you'd have my vote every time. But I'm thinking more in terms of existing open-source projects which don't already use those technologies.

Up to now, my only exposure to open-source has been with projects that were originally written for Linux. The vast majority of them seem to depend on command-line tools such as make or scons etc. It's rare for these projects even to support an IDE build environment, let alone a modern graphical framework such as wxWidgets or Qt. This is a world in which POSIX is still regarded as a holy grail and where the (non object-oriented) GTK+ is still regarded as the pinnacle of GUI's.

So in essence I'm looking for a POSIX build environment for Windows. To be fair, Cygwin does an excellent job of making this stuff work on the Windows platform. However, Cygwin has problems of its own (for example, it's implementation of 'X' leaves a lot to be desired). Hence my interest in Microsoft's offering.

[JVene]

Unfortunately, the news isn't good toward your goal.

I understand the position your describing. I've been a developer since before C++ was developed, and I've written applications for Unix using the C style paradigms which are still in use today.

It was a long standing C paradigm to use libraries and API's directly from application code. There were few alternatives at the time, but of these two concepts, it was the library which proved portable, the API not.

The closest we get with such practices is Cygwin. You stand a better chance of portability to Mac than Windows.

Accepting the application code's practice, and seeking a POSIX solution on Windows, is going to meet with limited and disappointing results, like those you've observed already.

You could hope to find API substitutions, perhaps even supplying inline functions of slightly different names as a point of indirection (subsequently performing a text replace of all application code to route to the inlines), essentially providing emulation in Windows by creating a C library, but that is at least as tedious as bringing the application into more modern C++, advancing it toward the use of a framework (perhaps more so).

One must make the judgment call regarding the value of moving from Cygwin to native application performance. If the application is of sufficient value to warrant any such transformation, it deserves to have that done in a way which gives the most benefit given the amount of work required to pull it off. There is little doubt in my mind that any solution which leaves the application dependent upon a C API gives a diminished return on that investment compared to a transformation toward a good framework.

I realize that's not consistent with the goals of an existing open source project. If that obstacle is insurmountable, the only conclusion I come to is that it's not worth transporting the application out of POSIX dependency. Despite the attitudes demonstrated by the original design of the code, POSIX dependency is a liability if Windows is a target, just as dependency on GTK or X is a liability - and for that matter, dependency on win32API is a liability.

The logical conflict has no resolution which fits all interests. POSIX may have been a noble idea at the time, but it's a C concept which never actually proved portable to the extent required. This may be the fault of Microsoft in the case of Windows, but such blame is of no value to the application developer.

Either the applications dependent on these styles of development must be transformed toward portability, and brought forward into a C++ paradigm, or they must remain as they are. It may be the only good solution is to create a new open source application based on the design of the older one, abandoning the previous group members which insist on the older design, attracting newer ones which embrace more modern concepts. The end results will eventually become more valuable, and the resulting application will be more portable, probably more reliable and stands a better chance of long term feature enrichment, and public interest.

[John E]

Thanks JVene. If ever a reply deserved to be rated it must be that one! Unfortunately though, I rated your last reply and it won't let me repeat the exercise twice in succession.

I'm very grateful though for all your helpful suggestions.

[Yves M]

Not long ago I built an open source program (originally written for Linux) to run under Windows (or more correctly, to run under Cygwin). Although this was just a technical exercise I was quite surprised at how well it all worked - but of course, to run the app on somebody else's PC would require them to install Cygwin - which isn't exactly a trivial task..!

You basically just need cygwin1.dll on the target computer. That is the cygwin part. For the other dependencies, you need the appropriate dlls, just as with any Windows program. So it's not really that hard to distribute a cygwin exe. Quite a few shareware/freeware windows programs actually use cygwin versions of open source software to do the grunt work (e.g. deepburner).

I just wondered if anyone here has ever used Microsoft's POSIX Services for Windows and if so, what kind of experiences did they have? In particular, were the apps easy enough to deploy? Also (for graphical apps) was it still necessary to use some variant of 'X'?

For graphics it's probable that you do indeed need to start an X server on the windows host. That is probably also possible with the cygwin dll and the X dlls, but maybe an overkill.