forked from madewokherd/wine-mono
-
Notifications
You must be signed in to change notification settings - Fork 1
/
README
80 lines (42 loc) · 3.99 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
Wine Mono is a package containing Mono and other projects, intended as a replacement for the .NET Framework (4.x and earlier) in Wine. It works in conjunction with Wine's builtin mscoree.dll, and it is not intended to be useful for any other purpose.
SOURCE CODE
To obtain the source code, clone it from github:
$ git clone --recursive git://github.com/madewokherd/wine-mono.git
To get to the source code for a specific release, check out the appropriate tag, and update the submodules:
$ git checkout wine-mono-6.0.0
$ git submodule update --recursive
Source tarballs and binary packages are available at http://dl.winehq.org/wine/wine-mono/
DEPENDENCIES
To build Wine Mono, you will need the following:
* All of the dependencies of Mono for your native (presumably Linux) system, such as autotools, CMake and a C++ compiler.
* Wine, for the winemsibuilder and cabarc commands. A 32-bit Wine is not necessary, despite the warnings when running 64-bit Wine.
* Python, to support the build system.
* libgdiplus, to support Mono's resource compiler.
* The dos2unix command.
* Optional: The zip or 7z command, for the tests-zip target only.
BUILD
To build Wine Mono, use the msi or bin target.
$ make msi
Optionally, a build VM can be automatically set up using the Vagrantfile included with the source distribution. To start the VM, run:
$ vagrant up
$ vagrant ssh
You can then cd to /vagrant and build from there.
Note that the source code will be rsynced into the VM when it is first created. If you edit the source code on the host, you can update the VM by running:
$ vagrant rsync
Or, to have vagrant watch for changes:
$ vagrant rsync-auto
INSTALL
To install Wine Mono, run the generated msi file with msiexec:
$ wine64 msiexec /i wine-mono-6.1.0.msi
Note that if a Wine Mono with a version number >= to this file is already installed, that command will do nothing, so you may have to remove the existing version (using 'wine64 uninstaller') first.
If you are building for development, you may find it more convenient to use the 'make dev' target, which builds a runtime in image/ and configures a wine prefix to use it. You can then rebuild individual dlls using their filename with no path. See 'make help' for details.
COMPOSITION
An installed Wine Mono contains the following:
* Registry keys and files in C:\windows\Microsoft.NET intended to make it look as if Microsoft .NET is installed, so that applications won't complain that it's missing, and the installers for Microsoft .NET won't install. This is part of an msi package named "Wine Mono Windows Support". (Wine Mono should always be removed before installing Microsoft .NET.)
* A modified version of the Mono runtime and class libraries, in the "Wine Mono Runtime" msi or a shared location outside the prefix.
BUGS
Bugs involving the use of this package to run Windows programs in Wine should be filed in the Wine bugzilla (http://bugs.winehq.org/) with product set to "Wine" and component set to "mscoree". Bugs in Wine Mono's build system or packaging can also be filed in Wine's bugzilla, or they can be filed as an issue on the wine-mono github.
PATCHES
Patches should be sent as a pull request to https://github.com/madewokherd/wine-mono or the appropriate submodule.
Before sending a patch for one of Wine Mono's forks, please consider whether it would be more appropriate to send to the upstream project. We'd like to keep the diff from upstream to a minimum, but we are willing to maintain diffs as long as we have a test for them in the test suite. This can be as simple as a .cs or .il program that returns 0 on success and non-zero on failure. If the bug cannot be reliably tested, we may accept changes without a test case.
The winforms and wpf projects are not being updated from upstream, and have diverged significantly. Since they are supporting .NET Core, which adds new features and is not binary-compatible with .NET Framework 4, their use case is very different from ours. In most cases, it doesn't make sense to send changes to these projects upstream.