WinPR is a spin-off project of FreeRDP which aims at providing a portable implementation of important portions of the Windows API. Just like FreeRDP, WinPR is released under the Apache license. Unlike Wine, WinPR does not provide binary compatibility, and does not require applications to be built for Windows. Instead, WinPR provides API compatibility for applications targeting non-Windows environments. When on Windows, the original native API is being used instead of the equivalent WinPR implementation, without having to modify the code using it.
WinPR is the result of long and thoughtful process that came up after years of FreeRDP development. RDP, as you know, is a protocol designed by Microsoft and is primarily “Windows to Windows”. In many instances, protocol messages rely heavily on Windows-specific APIs which have no direct equivalent on other operating systems. For instance, core graphical messages are based on GDI, network level authentication makes use of the Microsoft SSPI authentication modules (CredSSP, NTLM), and terminal server gateway makes use of both SSPI and MSRPC. That’s not even mentioning all the effort that went into mapping keyboard systems and time zones. Developing FreeRDP is in many ways all about implementing Windows APIs outside of Windows.
Immense efforts have gone into the implementation of such features, to the point where they begin having value outside of FreeRDP itself. At this point, one of the most valuable part of WinPR is the set of SSPI modules. Various NTLM implementations exist, all with different interfaces, but the WinPR implementation is a direct replacement of the original. This is an advantage because the API is already well documented, with expected inputs and outputs. FreeRDP can also optionally build against the native SSPI modules when on Windows. Making this code easily reusable to any one means that application developers now have an easy way of porting their applications to make use of the Windows authentication architecture.
WinPR is also a response to a recurrent problem in FreeRDP development: the proliferation of custom helpers and utility functions. While those are useful, they often need to be modified and updated to meet new requirements, causing frequent API changes. Breaking the API regularly obviously makes a lot of developers unhappy. By choosing to implement an existing and mature API, we can effectively get rid of the core of the problem. If a certain API has been used for years and it fits the needs of most people, you are less likely to need to break it yourself.
Besides the argument of API stability, there is another huge advantage in using the Windows API over custom utility functions: the ability to easily share code with other projects that aim at implementing the same API. For instance, the SSPI modules currently developed in WinPR are of high interest to the ReactOS project. If the code was filled with custom utility functions, it would be much harder to use outside of FreeRDP, hindering such collaboration opportunities. For instance, instead of wrapping calls to MultiByteToWideChar() in a custom unicode conversion utility, we can use MultiByteToWideChar() as the utility function and provide an implementation on non-Windows systems.
As a general rule in WinPR, if a utility function can be replaced by a part of the Windows API, then the Windows API will have precedence. Otherwise, a utility method can be used, keeping in mind the downsides of it.
WinPR is also designed to be as modular as possible, using the MinWin architecture as a reference. MinWin is a refactoring effort of the Windows API which is more cleaner and comprehensive than the original. The API has been separated into logical sets, each with a DLL. Not a lot of documentation is available online about MinWin, but one can find its structure in the MSDN article “Windows API Sets”: http://msdn.microsoft.com/en-us/library/hh802935/
Just like MinWin, WinPR aims at being minimalistic and modular, such that one can have fine grained control over what is to be used. For projects making use of only a small amounts of WinPR, it should be possible to depend only on the minimum required.
At last, why not simply use Wine or code from other projects like ReactOS or Samba? In all of these cases, there are both licensing and architectural problems which make it fairly hard for us to use in FreeRDP. For instance, Wine provides binary compatibility, and it’s not easy for a native Linux application to make use of parts of it without being built for Windows. Samba has an interesting MSRPC implementation, but it’s a fairly big dependency, without counting the fact that we can forget about portability on mobile platforms like Android and iOS. Unfortunately, none of these provide a highly portable implementation of the Windows API in the way we would like and under a license which is suitable to us, justifying the existence of WinPR.
Through WinPR, investment done in FreeRDP development will take a new life and become even more valuable. We will open new doors to even higher levels of interoperability. We will foster collaboration with other projects following similar goals and reach new heights at an increasingly faster pace. Stay tuned, you will be amazed!