Mixed-mode refers to the ability of code running on the Subsystem for UNIX Applications (SUA) to use native windows libraries. Anyone familiar with SFU or SUA would know that one can port POSIX compliant code over to SFU/SUA. Though this enables one to move his application over to windows, it still had a huge limitation; the old apps are still just the same. During the R2 release, we re-architectured the subsystem (aka SUA) so that any SUA application, in addition to the usual capabilities, can load a windows dll and make calls to it. This pushes the horizon for the POSIX apps to a greater extent. A POSIX app can load any dll built for the windows platform.
There are some significant advantages that this capability brings
Application Porting: A native SUA application would require all the libraries to be ported over to SUA. In some cases these libraries on which the custom application depends might be an ISV library and a version of the same library that is ported over SUA may not available. Mixed-mode removes this obstacle. Database applications are one example of such class of applications. Database applications usually link to a middle tier library, (OCI.dll in case or Oracle connectivity applications) and these libraries are not available on SUA. But since a windows version of OCI.dll is available and is supported by the vendor (Oracle), a mixed mode application can link to the windows version of the OCI.dll.
Extending functionality of SUA applications: One can take advantage of mixed-mode to extend the functionality of their applications. Applications can be extended to use other Windows libraries or ISV libraries (equivalent of which are not available over SUA).
Here are some of the scenarios that are possible with mixed mode...
1. A posix app can link to ODBC drivers to talk to any of the databases that supply a ODBC compliant client library. ODBC is just an example - infact a posix app can access any database if there is a windows version of the client library.
2. A posix app that uses x11 can be modified to display gui using any of the windows mechanisms (win32, .net etc).
3. Ported apps functionality can be increased by using technologies COM, active X, .net integration etc.
The common theme underlying all the above scenarios is that, bulk of the code remains the same – the complex business logic in the code etc remains untouched. You only change the part which you want to extend and you are able to give your legacy app more fire power. Think of your decade old console based app displaying swanky winforms UI; without rewriting the entire application.
So how does one build a mixed-mode app?
Simply compile the app with the –R flag e.g.:
gcc -R helloworld.c <windowslibrary> OR c89 - R helloworld.c <windowslibrary>
the –R flag tells the compile that the binary to be generated is a mixed-mode binary.
When a app is a marked as a mixed-mode app it becomes a hybrid app. It is very different from a normal SUA app and a normal windows App. A mixed-mode app interacts with both the Windows subsystem and the SUA subsystem. There are some limitations that this brings with. For example, the child process a mixed-mode app that called fork() will not be able to load and call windows dlls. A mixed-mode cannot be marked as a setuid binary. For a comprehensive list of all such limitations, refer to ‘releasenotes.doc” or releasenotes.htm in the docs folder (%windir%\sua\docs) of your SUA installation.
Stay tuned for more in this space. I will soon give some samples that would explain this better.