MinGW code::blocks and Wine integration.

Feature: Code::Blocks MinGW/Wine Development

Summary

Make Code::Blocks able to create and run MinGW/Wine projects.

Current status

MinGW is in place, but PE binaries of its tools may be required. Also runtime .dll:s and development tools should be split with the creation of -devel packages.

Wine is in place, but will need som minor patching and perhaps some tool to map MinGW files to c:\mingw32

Code::Blocks is in place, but need a MinGW project type, with the ability to run and debug MinGW applications in Wine.

Detailed Description

Wine is a free software application that aims to allow computer programs written for Microsoft Windows to run on Unix-like operating systems.

MinGW (Minimalist GNU for Windows), formerly mingw32, is a native software port of the GNU Compiler Collection (GCC) and GNU Binutils for use in the development of native Microsoft Windows applications on Windows itself or as cross compiler.[2] It is deployed along with a set of freely distributable import libraries and header files for the Windows API. MinGW allows developers to create native Microsoft Windows applications.[3] Included in MinGW are extensions to the Microsoft Visual C++ runtime library to support C99 functionality.

MinGW is included in Fedora and has a lot of dynamic libraries (dll-files) in fedora packages. These dlls should be made available inside Wine:s virtual filesystem. One way to do this is to make a small program that copy them into wines file-system. Another and more clean way to do this is to modify Wines file-system to find these DLL:s.

Perhaps mapping /usr/i686-pc-mingw32/sys-root/mingw into c:\mingw32 will provide a clean and flexible way to access them. When we have support for 64 bit MinGW it could be mapped to c:\mingw64 in order to have both version installed side-by-side.

These mapped directories should be strictly read-only in Wine as they are system-wide. Even if root runs Wine (and rood should not run Wine) these should be read-only. As they are quite specific they are no need to make them available only in some Wine instances, they should be equally available everywhere.

Then there is the issue about using a IDE to develop WinAPI applications. The Windows version of code::blocks has support for MinGW and if we make all tools available in the wine virtual filesystem then the Windows version of code::blocks should be able to support building MinGW applications with little or no effort.

The Linux version of code::blocks should also be extended with the ability to create MinGW applications, and use Wine to run and debug them.

Benefit to Fedora

The availability of MinGW libraries and tools in Wine will benefit applications that are dependent on these libraries. We can have them updated using the standard RPM/YUM system.

Providing a development environment for WinAPI with IDE like code::blocks will make Fedora a good alternative for developing C/C++ Windows applications. MinGW on Linux is A LOT faster then any C/C++ compiler on Windows. And applications that run in Wine usually run on Window. So while many developers still cant be attracted away from Windows as a target platform, they can be attracted away from it as a development platform.

The advantage of having Windows developers using Fedora, MinGW and Wine as a development platform is that their final product will be very compatible with Wine, if not running flawlessly.

One of Fedora and Linux biggest problem is the gap between Wine and all Windows applications that does not run on Wine. With Fedora as a mayor development platform for Windows applications, this gap will be decreased.

Scope

Required steps are:

1. Make MinGW available in Wine
2. Create support for MinGW and Wine in code::blocks.

How To Test

1. Run Wine and test if /mingw32 appers
2. Run MinGW applications and see if they find dlls in /mingw32
3. Create, compile and run Wine/MinGW applications in code::blocks.

Contingency Plan

None of this task should break anything that currently works. Code::block patches should be in a new project type/target, and therefore not break anything else. If this patches does not provide the desired functionality we can still ship them, as long as they do not break currently working parts of Wine or code::blocks.