Working on Wine Part 6 Sending Your Work Upstream

Andrew Eikum a CodeWeavers employee and Wine developer is writing a series of post to introduce people to Wine usage and development.

About This Guide

This is a series of guides intended to introduce software developers to the Wine ecosystem. It will cover what Wine is, how to use Wine, how to debug Wine, how to fix Wine, and what to do with your fix once you've made it.

The guide will be published throughout January.

• Part 1 describes what Wine is and provides a short description of various popular forks of Wine.
• Part 2 describes Wine's build process.
• Part 3 describes how to use Wine as a developer.
• Part 4 describes how to debug Wine in general.
• Part 5 describes Wine's source tree layout and how to edit the source.
• Part 6 describes how you can send your work upstream.

If you recall from Part 1, there are many forks of Wine. Where your fix belongs can vary depending on what fork of Wine you use, the nature of the bug you fixed, and how you fixed it.

 

 

Choosing the right place to send your fix

The ideal place for your fix is in upstream Wine. This is the origin point of all Wine forks. If you fix it in upstream Wine, then all users of Wine will eventually benefit from your work as the various forks pull in changes from upstream.

Sending your fix upstream should be the default choice for your work. If none of the exceptions below apply, or if you're unsure where your fix belongs, work with upstream first.

 

When upstream is the wrong choice

Your patch may be built on top of an existing patch in wine-staging. In that case, it should be sent to the wine-staging maintainers. If you, or they, think that the patch is ready to be sent upstream, then go ahead and do that instead.

If your patch fixes the issue, but you failed to fix the tests you wrote, or your patch causes some other test failures, it may belong on the bug tracker, or possibly in wine-staging.
If your patch provides a useful feature that upstream Wine is not interested in, it may belong in wine-staging.

If your patch is builds on a feature exclusive to some fork of Wine, like Proton or CrossOver, it may belong in that fork and not upstream. Work with the fork maintainers to determine if it's appropriate for upstreaming.

 

Upstreaming your fix

Hopefully, your patch is going upstream. Wine's patch submission process is done via email. Your patch should be sent in plain text to wine-devel@winehq.org. You should subscribe to this mailing list to avoid being placed into the moderation queue.

It is recommended to use git send-email to send the email through your mail server. You can also use git format-patch and attach the resulting file in an email client. Be careful that your mail client doesn't wrap, or otherwise corrupt, the attachment as if it were a text document.

Patches that are sent upstream should have your Sign-off. This can be applied by Git automatically with the -s switch during git commit and/or git format-patch. You must use your real name in the Author field when submitting a patch.

If you are submitting a series of patches, try to limit yourself to about four patches per submission. Your patches should be self-contained anyway, so there is no harm in submitting them in several batches. Smaller patch series are easier to review, and keep from cluttering up the mailing list if you have to re-send the series with changes.

 

Receiving feedback

Wine has a patch status webpage which will track the status of your patch. Your patch will be tested by the Wine Test Bot to ensure any new tests pass on various Windows versions. If the area of Wine changed by your patch has a maintainer, it will be assigned to that person for review. If not, it will be reviewed by the general community, or by the Wine maintainer.

Be patient, it may take a few days for your patches to receive review. Wine reviewers try to reply to every patch within a week, but if you don't get feedback you may send an email to wine-devel asking for a review. Be sure you are subscribed to wine-devel, as some reviews may be sent to that mailing list instead of directly back to the author.

If you received some suggestions, take those suggestions into account and send a new version of the patch. Feedback from Wine reviewers should not be seen as criticism or an attack. Wine is a very complicated piece of software, and it has a high standard of code quality for contributions. Rejections aren't made lightly—everyone wants Wine to improve. Instead, understand that there are reasons for the rejection, apply the suggestions, and resend the patch. If you do not have the time or interest in making the requested changes, consider sending your patch to wine-staging so some other person may take up the patch in the future and try to get it upstream. Or, attach it to a Bugzilla bug so it is not lost.

If your patch is accepted, then congratulations! You have just made Wine better. It's time to move on to the next bug.

Full Article

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

 

Working on Wine Part 5 Fixing Wine

Andrew Eikum a CodeWeavers employee and Wine developer is writing a series of post to introduce people to Wine usage and development.

About This Guide

This is a series of guides intended to introduce software developers to the Wine ecosystem. It will cover what Wine is, how to use Wine, how to debug Wine, how to fix Wine, and what to do with your fix once you've made it.

The guide will be published throughout January.

• Part 1 describes what Wine is and provides a short description of various popular forks of Wine.
• Part 2 describes Wine's build process.
• Part 3 describes how to use Wine as a developer.
• Part 4 describes how to debug Wine in general.
• Part 5 describes Wine's source tree layout and how to edit the source.
• Part 6 describes how you can send your work upstream.

Once you've got some idea of what is causing the problem with your application, it's time to go understand how those APIs are implemented in Wine so you can fix it. You may also need to change Wine's code to debug the application in the first place.

 

Search for existing bugs

Before digging into the source, it's always useful to first search for existing bugs. You can search Wine's Bugzilla for your application, or for the symptoms you're seeing. As you begin to debug your issue, you may find other search terms to try. If you find a bug, you may find some useful analysis or work has already been done for the issue.

You may also want to look through the Wine Staging patches, especially once you have some idea of what the problem is. You may find someone has already written a patch to fix this problem, but it isn't ready to go upstream yet. You can pick up the torch and try to upstream the work.

 

Wine source layout

Wine implements the Windows operating system, which is composed of libraries, programs, and kernel functionality. You can find the code for Wine's implementation of each of those components in dlls, programs, and server, respectively. To give you some idea of how different components of Wine work together, some important, core components are listed here.

• dlls/ntdll – This is where many of the core OS APIs are implemented, like file handling, thread creation and synchronization, timing, and much more. Applications typically use kernel32 instead of ntdll directly.
• dlls/kernel32 – This is the application-facing interface for the core ntdll APIs mentioned above.
• dlls/user32 – This is where much of the Windows GUI handling lives, like window creation, message handling, terminal services, and so on.
• dlls/winex11.drv and dlls/winemac.drv – These libraries map the Windows GUI interfaces, and some other platform-specific functions, to the native platform. user32 calls into these platform drivers.
• dlls/d3d* and dlls/wined3d – These libraries implement the Direct3D graphics API on top of the platform's OpenGL implementation.
• programs/services – This program manages background services, both those created by Wine and those provided by installed applications.
• programs/wineboot – This program kicks off initial prefix creation and other tasks when a prefix is booted.
• programs/winecfg – This is Wine's configuration program.
• server – The Wine server implements all cross-process functionality, including message routing, multi-process synchronization primitives, registry handling, and much more. The Wine server is always running if an application is running.

While debug channels are often named after the component in which they are declared (e.g. the dsound channel is declared in dlls/dsound), this is not always the case. You can use git grep to find the relevant debug trace line if it isn't obvious.

 

Writing tests

In most cases, your work should be driven by tests. Study the documentation for the relevant APIs and write tests first to confirm that Windows's implementation behaves how you expect it to. Then, change Wine's source to pass the tests that you wrote.

Wine has an extensive suite of unit tests. The unit tests comprise well over one million lines of code as of this writing. Any patch you submit must pass all of these tests. Patches should contain more tests proving that the new behavior is correct.

In general, you should focus your work on what a real application actually does. That is, you don't need to implement a bunch of unrelated functionality if the application doesn't actually need it. You should write tests to show how an application is using an API, and how Wine fails to meet its expectations. Then fix Wine to also pass those tests without breaking any existing tests. Any change to Wine has the potential to break other applications. Simply passing tests that you wrote is insufficient reason to change Wine.

You can find the tests for a given component in the tests subdirectory. For example, the tests for dsound live in dlls/dsound/tests. You will find .c files in that directory. The tests start in the START_TEST function and exercise the component being tested. The ok function demonstrates correct behavior. Again, "correct" is defined to mean "like Windows." For example:

    hr = IDirectSound_CreateSoundBuffer(ds, &bufdesc, &primary, NULL);
    ok(hr == S_OK, "CreateSoundBuffer failed: %08x\n", hr);

Here you can see the return value from IDirectSound::CreateSoundBuffer is expected to be S_OK. If it is not S_OK, then the test will fail.

Your tests should demonstrate how your application behaves when interacting with that API. Since you are fixing a bug in Wine's implementation of the API, your tests should demonstrate that Wine will fail without your fix. It isn't necessary, or even recommended, to fully exercise all inputs to an API in the Wine tests. Instead, be thoughtful about how your application might use the API given different inputs from the user, and write tests that reflect those possibilities.

Your tests should be self-contained. They should initialize the necessary functions, test the APIs, and then clean up before continuing. If you need to create files on disk, create them in a temporary location and/or clean them up afterwards. If your test may leave changes to the system, expect to have to clean up after a previous run that crashed, before you run your tests.

After you have written some tests, you need to verify that they pass when run on Windows. To do this locally, run make crosstest, which will use your system's mingw-w64 compiler to build a Windows executable. Run this executable on Windows in the command prompt to verify Windows's behavior. If you do not have a Windows system or VM available, you can upload your patch or test binary to the Wine Test Bot.

Once your tests pass on Windows, run them in Wine with make test. If your tests meaningfully demonstrate a Wine bug, they should fail. Now it is time to fix Wine to pass those tests, as well as all existing tests.

 

Working with Wine's source

As you develop your fix, there are some rules you should know if you intend to send your work upstream.

For better or worse, Wine does not have a coding style standard and likely never will. The rule is to try to match the surrounding code as best as possible. Especially in older code, you will find a horrible mish-mash of tabs and spaces and brace styles. Do your best to make the code no worse than it was. However, extraneous changes are discouraged as they make review difficult and looking up the source history in Git more cumbersome. If you are changing a line, or even one line in a short code block, it can be re-formatted to be less ugly than it was. But don't reformat an entire function to fit some style, no matter how ugly it is.

Wine only accepts code that adheres to the C89 standard, because some compilers that Wine cares about don't support anything later. The three most common snags here are that your code must declare its variables at the top of the block, you cannot use //-style comments, and function declarations with no arguments must be declared with void arguments:

    int some_function(void);

Resist the urge to gut an entire function or module and re-write it. Small, discrete changes that can be easily understood are the right way to fix Wine. Wine is more than two decades old. There is a lot of hard-won knowledge in much of Wine's source, and throwing out all of that history because it's easier than working in the existing code is not likely to pass review.

Make your changes as obviously correct as possible. Unrelated changes must be placed into their own commits. You should not introduce unused code in an early patch, which begins to be used in a later patch.

Write your patches with the reviewer in mind. It may be unintuitive, but understand that it is more important for your patch to be easy to review than make Wine's code perfect. Reviewer time is one of Wine's most valuable assets. Patches that are easier to review are more likely to pass that review.
Be aware that some tests are "flaky." This is an unfortunate reality of a system as complex as Wine. Ideally all tests would pass on all Windows and Wine environments, but due to bugs, differing platform behavior (especially window managers) and timing differences, they don't. Most modules have well-written tests that should always pass. Some, like the user32 messaging tests, and some audio and graphics tests, fail with some frequency, even on Windows.

Full Article

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Working on Wine Part 4 Debugging Wine

Andrew Eikum a CodeWeavers employee and Wine developer is writing a series of post to introduce people to Wine usage and development.

About This Guide

This is a series of guides intended to introduce software developers to the Wine ecosystem. It will cover what Wine is, how to use Wine, how to debug Wine, how to fix Wine, and what to do with your fix once you've made it.

The guide will be published throughout January.

• Part 1 describes what Wine is and provides a short description of various popular forks of Wine.
• Part 2 describes Wine's build process.
• Part 3 describes how to use Wine as a developer.
• Part 4 describes how to debug Wine in general.
• Part 5 describes Wine's source tree layout and how to edit the source.
• Part 6 describes how you can send your work upstream.

If you've made it this far, then you should have a functioning Wine build and an application installed that has some problem that you want to fix.

Debugging Wine is unlike debugging an application or even most open source libraries and software. As a Wine developer, you typically don't have access to the source of the application. So you have to be able to guess at what the application is trying to do, and then figure out why Wine is failing to meet its requirements.

Applications are often debugged with debuggers, but this is of limited use with Wine. A lot of time is spent in application code, which isn't useful to us, or in OS library or kernel code, which is also often not useful to us. Wine is just the go-between from application code to library or OS code, so debuggers tend to spend a lot more time out of Wine code than in it. Problems in Wine are also often less about bugs than they are missing features. Debuggers don't help here.

 

WINEDEBUG

Instead, most Wine debugging is done with printf-debugging. Wine developers have introduced copious logging into the libraries. When you run an application with these debug traces enabled, it will spit out large quantities of information about how the application is using the library.

You enable these logs with the WINEDEBUG environment variable. This variable takes a comma-separated list of debug channels. While it has a more complicated syntax than this, usually you just enable channels entirely. For example, to debug a networking issue, you might start with:

    $ WINEDEBUG=+seh,+winhttp,+winsock,+wininet ~/src/wine.win64/wine Steam.exe

This will emit a ton of output on stderr. Usually you redirect to a file:

    $ rm -f out.txt && WINEDEBUG=+seh,+winhttp,+winsock,+wininet 

~/src/wine.win64/wine Steam.exe &>> out.txt

Notice that the redirect is in append mode, to allow for more readable multi-threaded logging. This requires that we delete any old log file first.

This is the basic Wine debugging loop. Run the application with logging enabled, demonstrate the failure, examine the log, add more logging if necessary, and repeat until you understand the problem.

 

Debugging channels

Wine trace logs have four "severities," called TRACE, WARN, FIXME, and ERR. TRACE is just general debugging, and is silenced by default. WARN indicates some suspicious, but non-fatal condition and is also silenced by default. FIXME indicates some missing feature of Wine and will be printed by default. ERR indicates a serious problem and will also be printed by default.

Wine lets developers output logs on specific channels. These are declared in the C source files with WINE_DECLARE_DEBUG_CHANNEL and WINE_DEFAULT_DEBUG_CHANNEL. Grepping the C files for DEBUG_CHANNEL works great.

It's not always easy to determine which log channels are useful to trace. If you know what general area your problem is in, you can add channels from the relevant Wine libraries. If you don't have any idea, then a log with just +seh is a decent starting place to dig for fixmes and errs.
There are some special debugging channels.

tid and pid will prepend each log line with the Thread ID and Process ID that outputted the log line. tid is enabled by default in recent Wine.

relay will output every API entry point that the application, or other parts of Wine, make a call to. This is extremely verbose, but can be very valuable, especially if you don't know where the problem lies.

timestamp will prepend every log line with a millisecond-resolution timer. This is great if you can estimate when in the log the problem occurred, or are working with timing-sensitive code like audio.

 

Working with log files

Most WINEDEBUG logs will grow to hundreds of kB and MB of plaintext. Logs of multiple GB are not uncommon, especially relay logs. Many GUI text editors will not handle files of these sizes very well. An editor like vim is recommended.

You should also get familiar with tools like grep, head, and tail to pare log files down to manageable chunks. In particular, grep -v can get rid of uselessly repetitive log lines.
When encountering a new log, a good first step is to grep for err:, warn:, and fixme:. These can indicate problems. You'll likely get a lot of fixmes and probably some warns. If you're getting messages from areas unrelated to the problem you're examining, you can usually ignore them. For example, fixmes from the d3d channel are probably unrelated to a problem with audio.

 

Log file techniques

One generally useful technique is to find the problem and then search backwards. For example, bad pointer dereferences are a common failure. These can be found in a +seh log by searching for c0000005. Once you've found the failure in the log, you can start going backwards and if you're lucky, find some fixme or err indicating a missing feature. Or in a relay log, you might find some API that is returning a failure, like a bad HRESULT instead of S_OK.

If you don't have an obvious crash point, you can also try to find where in the log things start to go bad. For example, most applications follow a pattern of loading libraries, initializing stuff, normal application processing, then uninitializing stuff and unloading libraries. If you have an application that is quitting unexpectedly, you can search for when shutdown-related code is happening and then start going backwards to try to find the culprit.

If you have an application that fails on some specific input condition (say, clicking on some UI element), you can actually write to the log at the same time that Wine is. While Wine is debugging, run:

    $ echo '@@@@@@@@' >> out.txt

Then perform your action and observe the failure. Then run it again:

    $ echo '########' >> out.txt

Now you know the failure occurred between the at-symbols and the hashes.

Full Article

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Working on Wine Part 3 Using Wine as a Developer

Andrew Eikum a CodeWeavers employee and Wine developer is writing a series of post to introduce people to Wine usage and development.

About This Guide

This is a series of guides intended to introduce software developers to the Wine ecosystem. It will cover what Wine is, how to use Wine, how to debug Wine, how to fix Wine, and what to do with your fix once you've made it.

The guide will be published throughout January.

• Part 1 describes what Wine is and provides a short description of various popular forks of Wine.
• Part 2 describes Wine's build process.
• Part 3 describes how to use Wine as a developer.
• Part 4 describes how to debug Wine in general.
• Part 5 describes Wine's source tree layout and how to edit the source.
• Part 6 describes how you can send your work upstream.

Now that you have Wine built, try running it:

    $ ./wine.win64/wine winecfg

This should pop up a winecfg dialog. If not, something has gone wrong.
The wine executable in the 64-bit build directory is your primary interface for running Wine. Use it to install whatever software you are trying to get functional:

    $ cd ~/software/MyFavoriteApp/
    $ ~/src/wine.win64/wine Setup.exe

 

Wine prefixes

On first run, Wine sets up a virtual Windows filesystems containing a C: drive and a bunch of other files to mimic a real Windows installation. The virtual Windows filesystem is called a "prefix." The default Wine prefix is located at $HOME/.wine/. You can override this location with the WINEPREFIX environment variable. This can be useful to set up experimental prefixes which you can destroy later without affecting other prefixes.

A typical Wine prefix looks like this:

    ./dosdevices/
                 c: -> ../drive_c
                 com1 -> /dev/ttyS0
                 com2 -> /dev/ttyS1
                 com3 -> /dev/ttyS2
                 com4 -> /dev/ttyS3
                 d:: -> /dev/sr0
                 z: -> /
    ./drive_c/
              Program Files/
              users/
              windows/
    ./system.reg
    ./userdef.reg
    ./user.reg

The dosdevices folder contains DOS drives in the form of symlinks to folders or special devices. When an application tries to open C:\some_file.txt, the c: symlink here will cause Wine to instead open $WINEPREFIX/dosdevices/../drive_c/some_file.txt.

The drive_c folder is where the contents of a typical Windows installation live, like the Windows folder and the Program Files folders.

The .reg files contain Wine's representation of the Windows registry. These are stored in a format similar to the Windows regedit .reg format. Rather than use regedit, you can actually edit these files with a text editor directly to modify the registry (though you shouldn't do that while Wine is running).
The application you installed is probably located in Program Files. You can change into that directory and go poke around its files, just like you could on Windows. You can also run Wine from that directory:

    $ cd '~/.wine/drive_c/Program Files (x86)/Steam/'
    $ ~/src/wine.win64/wine Steam.exe

If you are running applications directly like this, be mindful of your working directory. While many applications aren't sensitive to this, some assume that you launched it from the directory specified in the shortcut file that it created. This is not always the same directory in which the executable lives.

Running Wine from a build directory

If you run Wine from a build directory, like we have been here, then Wine will look up its library files from that build directory. This is as opposed to running from a system installation, where it will look up libraries in /usr/lib/wine, for example. This means that you can make changes to one Wine component, build just that one component, and then run Wine and observe the changes. No need for a top-level make or an install round trip.

Native vs built-in components

By now, you should understand that Wine is capable of running arbitrary software that was written for Windows. This includes software and libraries that Microsoft has written. Many of the components that Windows applications depend on are distributed with the application in the form of "redistributables," which contain Microsoft-written libraries. While these weren't intended for Wine, they are Windows applications like any other, so they do work in Wine.

Typically these redistributables drop DLLs into C:\windows\system32. When Wine is asked to load some DLL from system32, it will notice that these libraries are not Wine DLLs and will determine what to do on a per-library basis. The technical details of this are beyond the scope of this guide, but you can control whether Wine will prefer the Microsoft-owned DLLs (called "native") or the Wine-created DLLs (called "built-in") by using winecfg.

Since Wine tries to reimplement Microsoft code, these native libraries are by definition "correct." And unfortunately, Wine is not yet perfect. As a result, software running against native libraries will often work better than when running against Wine DLLs. This can be useful for end-users who just want to run their software.

However, you must be very careful when using native DLLs as a developer. Wine developers must never reverse-engineer actual Microsoft-owned code, and that includes using native libraries and using Wine's debugging features to determine what they are doing. There are no exceptions to this rule, so please understand the native vs built-in state of any libraries you are working on or debugging. Any developer found to be reverse-engineering in this manner may be banned from contributing to Wine. The correct way to determine the behavior of native components is to write software like any other application developer and test the behavior of those components as a black box. This will be discussed more later in these guides.

Fake DLLs and .dll.so files

On a Windows system, system libraries are installed into C:\windows\system32 (and C:\windows\syswow64 for 32-bit DLLs on a 64-bit system). Wine also installs DLLs into this directory. Some applications actually open these files directly and expect them to be valid Windows DLLs. However, Wine does not actually use the DLL file format for most of its own libraries. Instead these "fake DLLs" simply instruct Wine to load its real libraries, in whatever format is native to the underlying operating system (e.g. ELF).

As discussed above, Wine's libraries live in the build tree if you are running Wine from the build tree. They are named with the .dll.so extension. If Wine was installed someplace, then they will live in the lib/wine directory, for example in /usr/lib/wine and /usr/lib32/wine/. If you make changes to a Wine library and want to replace a single component in an existing Wine installation, you can just copy the .dll.so file into the appropriate location. Modifying the fake DLL in the Wine prefix will do nothing useful.

Tip: Virtual Desktop

Wine can be configured to run inside of a "virtual desktop." This is a single window, inside of which all of the Windows applications run. This can be extremely useful when testing fullscreen games, as this will prevent them changing the display resolution and you can still access other windows on your desktop. See the Graphics tab in winecfg.

Full Article

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Working on Wine Part 2 Wine Build Process

Andrew Eikum a CodeWeavers employee and Wine developer is writing a series of post to introduce people to Wine usage and development.

This is a series of guides intended to introduce software developers to the Wine ecosystem. It will cover what Wine is, how to use Wine, how to debug Wine, how to fix Wine, and what to do with your fix once you've made it.

The guide will be published throughout January.

• Part 1 describes what Wine is and provides a short description of various popular forks of Wine.
• Part 2 describes Wine's build process.
• Part 3 describes how to use Wine as a developer.
• Part 4 describes how to debug Wine in general.
• Part 5 describes Wine's source tree layout and how to edit the source.
• Part 6 describes how you can send your work upstream.

Wine is effectively an operating system, including all of the libraries that a Windows system provides, such as support for 3D graphics, networking, audio, and a graphical user interface, as well as dozens of support libraries that software can use like XML parsers, file format readers and writers, multimedia playback, and much more. As such, it is a very complex piece of software. Building Wine is not a trivial task.

Much of this process depends on your particular operating system, and operating system version. This guide will not get into particulars for every operating system, but instead describe the process in general. Specific guides are available at the WineHQ Wiki.

Acquiring Wine

While you can grab the Wine source from many places, the only useful place for Wine developers is to clone the Wine Git repository.

Wine uses the typical configure && make && make install process of other autoconf-based software projects.

Choosing 32-bit or 64-bit

Microsoft Windows started shipping support for 64-bit software in the mid-2000s. Wine also has support for running 64-bit Windows software. The way this works in Wine is you effectively build it twice: once for 64-bit software and again for 32-bit software. Wine will choose the correct library architecture for a given executable at runtime.

Unfortunately, building for both architectures can be complicated on Linux. Many Linux distros have poor support for installing software for multiple architectures. Since most of the software that distros support is open source, and since open source software can be built for any architecture, there is little reason to support alternate architectures. However, the Windows software that you want to run is likely to require 32-bit support. Distros that do provide multi-arch support often do it only for Wine. To be blunt, that's a fairly small usecase, and so these 32-bit libraries are often treated as second class citizens.

macOS is even worse. Apple is dropping 32-bit support entirely sometime in 2019. No one knows exactly what this will mean for users of unsupported, 32-bit-only software, including Wine users, but it doesn't look good.

In any case, 32-bit support is required to run most Windows software, so it is effectively required if you want to build Wine. It is also strongly recommended that you build 64-bit Wine as well, since more and more Windows software is being built for the 64-bit architecture. This guide will show you how to build both.

Building Wine

By default, configure will run in 32-bit-only mode. To support both 64- and 32-bit software (called "WoW64"), we want to first build 64-bit Wine and then make a build of 32-bit Wine which references the 64-bit Wine.

Wine's configure script will search your system for the libraries Wine needs to run Windows software. It takes a while to run. At the bottom of the output, it will warn you about any missing packages. Any missing packages that are critical will be marked with WARNING text. You are strongly suggested to install these missing packages before continuing, or your Wine may be missing critical features.

For example:

    $ cd src/
    $ mkdir wine.win64
    $ cd wine.win64
    $ ../wine/configure --enable-win64
    [ much truncated output ]
    configure: vkd3d 64-bit development files not found, Direct3D 12 

won't be supported.
    configure: WARNING: libjpeg 64-bit development files not found, JPEG 

won't be supported.

You can see my system is missing the 64-bit VKD3D package. This is OK, since I don't care about Direct3D 12 support for the applications that I want to run. On the other hand, if I did want to run some Direct3D 12 games, then I would need to fix this problem and re-run configure.
However, it is also missing the libjpeg package. This is bad news. Lots of applications will require JPEG support and may behave badly if it fails, so Wine gives me a big WARNING. I should install 64-bit libjpeg and re-run configure.

Continue installing packages and re-running configure until you are happy with the missing package state. Then build Wine with make. A typical Wine build for a single architecture can take between 20 and 60 minutes, depending on the speed of your CPU and hard drive. It is strongly recommended to run make with a -jN flag appropriate to your CPU count. ccache will also significantly speed up future Wine builds. You can build Wine with ccache using CC='ccache gcc' at configure-time.

Hopefully your build will complete without errors. At this point, you can run 64-bit Windows applications. However, most Windows software does require 32-bit support at some point, often for the installer or some background process and services. So let's get a 32-bit build started, using the same process:

    cd ../
    mkdir wine.win32
    cd wine.win32
    ../wine/configure --with-wine64=../wine.win64
    [ much truncated output ]
    configure: vkd3d 32-bit development files not found, 

Direct3D 12 won't be supported.
    configure: WARNING: libjpeg 32-bit development files not found, 

JPEG won't be supported.
    configure: WARNING: libpng 32-bit development files not found, 

PNG won't be supported.
    configure: WARNING: libxml2 32-bit development files not found 

(or too old), XML won't be supported.

Oh my, far more errors here. You need to install the 32-bit versions of all of the same packages. How to do this, and what packages are available in 32-bit, is going to vary widely between distros, and we won't cover this here. Refer to the Wine Wiki for your particular distro.
Again, when you are happy with the state of your packages, run make and go grab lunch. When it's done, you will now be able to run 64- and 32-bit Windows applications in Wine.

Building crosstests

The last stumbling block is cross-compiling the tests so that they can be run on Windows. This isn't technically required the Wine testbot will build a patch file and run it on Windows for you—but it will greatly speed up your development process if you can build the tests locally and run them in a Windows VM that you control.

To build the crosstests, you must have mingw-w64 installed at configure-time. Availability will vary by distro. Run make crosstest at the top-level of the Wine tree to build all of the crosstests.

Full Article

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Working on Wine Part 1 The Wine Ecosystem

Andrew Eikum a CodeWeavers employee and Wine developer is writing a series of post to introduce people to Wine usage and development.

About This Guide

This is a series of guides intended to introduce software developers to the Wine ecosystem. It will cover what Wine is, how to use Wine, how to debug Wine, how to fix Wine, and what to do with your fix once you've made it.

The guide will be published throughout January.

• Part 1 describes what Wine is and provides a short description of various popular forks of Wine.
• Part 2 describes Wine's build process.
• Part 3 describes how to use Wine as a developer.
• Part 4 describes how to debug Wine in general.
• Part 5 describes Wine's source tree layout and how to edit the source.
• Part 6 describes how you can send your work upstream.

 

What is Wine?

Wine is an open source reimplementation of Microsoft's Windows operating system on top of various Unix operating systems. It primarily targets Linux and macOS, but can also be run on other systems like FreeBSD, NetBSD, and Solaris. What this means for users is that they can run software that was made for Windows on other operating systems.

Wine does not contain any Microsoft-owned code, so there is no need for a Windows license to run Wine. Instead, the Wine developers have rewritten components of the Windows operating system such that software run in Wine will think it is running on Windows, even though it is actually running on Linux, for example.

As a simple example, consider the Windows CreateFile API. On Windows, an application could call:

    CreateFileA(
        "C:\\some_file.txt",   //lpFileName
        GENERIC_WRITE,         //dwDesiredAccess
        0,                     //dwShareMode
        NULL,                  //lpSecurityAttributes
        CREATE_ALWAYS,         //dwCreationDisposition
        FILE_ATTRIBUTE_NORMAL, //dwFlagsAndAttributes
        NULL                   //hTemplateFile
    );

Wine will take that CreateFileA call and turn it into a Unix open call:

    open(
        "/home/aeikum/.wine/drive_c/some_file.txt", //path
        O_WRONLY | O_CREAT,                         //oflag
        0644                                        //creation mode
    );

The file handle will be returned back to the application, which can then write to the file with a similar implementation mapping WriteFile to Unix's write. Of course the actual implementation of CreateFileA in Wine is far, far more complicated than this (consider the path conversion, for example), but this gives you the gist of what Wine does.

Wine Forks

Since Wine is an open source project, anyone is free to make copies of it and modify it to suit their needs or the needs of their users. There are hundreds of Wine forks, but a few of them have gained prominence and are described here.

"Upstream" Wine

Website: https://www.winehq.org/
This is the "official" version of Wine, from which all other forks are derived. When someone refers to "Upstream" Wine, they are talking about this project. Wine is primarily focused on correctness. Wine contains extensive unit tests which demonstrate the behavior of Windows, and requires that most patches provide tests. All patches must pass the existing tests to be accepted. There is also a strong focus on code quality. Wine is a very large project (it is literally an entire operating system, including a GUI), so technical debt is strongly avoided to keep the project maintainable going forward.

Wine Staging

Website: https://wiki.winehq.org/Wine-Staging
However, Wine's strict patch acceptance requirements means that lots of patches that are unproven, wrong, or dangerous, but useful for users today, would languish in private forks or on the bug tracker. The Wine Staging project (also spelled "wine-staging") is an attempt to gather and maintain these useful patches so users can easily take advantage of them. The Wine Staging community also works to upstream these patches into Wine, so their benefits become available for all Wine users and forks, while also lowering Wine Staging's own maintenance burden. It can also serve as a "testing grounds" for patches which are difficult to prove with unit tests before they are accepted upstream.

CrossOver

Website: http://www.codeweavers.com/
CrossOver is a commercial fork of Wine sold by the CodeWeavers company. It contains many patches that are application-specific hacks and not appropriate for upstreaming. CodeWeavers also maintains an application compatibility database which will pre-install some software components and otherwise modify the Wine environment so that certain applications work better. However, CodeWeavers strongly prefers to implement features correctly and send that work to upstream Wine. CodeWeavers employees perform a significant portion of the work done on Wine.

Proton

Website: https://github.com/ValveSoftware/Proton/
Proton is a fork of Wine created by the Valve software company, which is integrated with their Steam software, a major video game and software distribution platform. Proton is focused on providing a seamless experience for Steam users to run Windows titles on Linux. Like with CrossOver, most of the contributions to Proton are also sent to upstream Wine.

Other forks

There are many, many other forks of Wine. Some are packaged with commercial software and sold as macOS and Linux software. Others are one-off forks created by users for a specific application.

Developing for Wine

Wine isn't perfect, and it's likely you will run into an inadequacy or a bug in your day-to-day Wine usage. Perhaps you are interested in fixing Wine so it will run your application or game, or maybe your employer would like to use Wine and pay you to fix it. This guide will introduce you to how you can build, debug, and fix Wine, and how to send those fixes upstream.

Full Article

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

CodeWeavers has Released CrossOver 18.1.0 for Linux and MacOS

I am very pleased to announce that CodeWeavers has just released CrossOver 18.1.0 for both macOS and Linux.

CrossOver 18.1 now supports Visio 2016 on Linux.

For macOS users, CrossOver 18.1 contains a number of important bug fixes. We have resolved a bug which prevented game downloads and the Steam Store page from working on the latest Steam release. CrossOver 18.1 also addresses an issue some macOS users experienced running recent versions of Quicken on CrossOver 18. Those who experienced crashes or launch failures when using Quicken 2016-2018 should see full functionality on CrossOver 18.1.

Finally, CrossOver 18.1 restores controller support for Steam on both macOS and Linux.

macOS customers with active support entitlements will be upgraded to CrossOver 18.1 the next time they launch CrossOver.  Linux users can download the latest version from CodeWeavers .

Change Log For CrossOver Mac and Linux :

18.1.0 CrossOver - December 4, 2018

• macOS:
  • Fixed a bug that prevented Quicken from launching for some users.
  • Fixed a bug that caused the latest Quicken 2016 Mondo Patch to fail during installation.
  • Fixed a bug that prevented game downloads and the Steam Store page from working on the latest Steam release.
  • Restored controller support for Steam.
• Linux:
  • Support for Visio 2016.
  • Restored controller support for Steam.

Putty for Mac

$15.00

CodeWeavers has Released CrossOver 18.0.0 for Linux and MacOS

I am very pleased to announce that CodeWeavers has just released CrossOver 18.0.0 for both macOS and Linux.

CrossOver's core technology Wine has been updated to version 3.14, bringing thousands of improvements over our previous release to CrossOver 18.

CrossOver 18 significantly improves our support for DirectX 11 via wined3d. It is also the first version of CrossOver with DXVK compatibility, a Vulkan-based Direct3D 10 and Direct3D 11 implementation for Linux and Wine.  Users can now easily install DXVK into new and existing bottles with a simple crosstie.

CrossOver 18 now includes support for Direct3D 12 on Linux by way of VKD3D, a Direct3D 12 to Vulkan translation library.

On Linux, CrossOver 18 runs several popular Blizzard games such as World of Warcraft, Overwatch, and Diablo III.

CrossOver 18 provides full support for the latest version of macOS, 10.14 Mojave.

Mac customers with active support entitlements will be upgraded to CrossOver 18 the next time they launch CrossOver.  Linux users can download the latest version from CodeWeavers.

Change Log For CrossOver Mac and Linux :

18.0.0 CrossOver - October 16, 2018

• Core Technology Improvements:
  • CrossOver 18 is based on Wine 3.14, with thousands of improvements for Windows application compatibility.
• Linux:
  • Improved support for DirectX 11 via WineD3D.
  • DXVK Compatibility.
  • Support for DirectX 12 via vkd3d and Vulkan.
• Application Support:
  • Preliminary support for Outlook 2016 on Linux.
  • Support for Steam in Win 7 bottles.
• Bug Fixes:
  • Restored support for World of Warcraft, Overwatch, and Diablo III on Linux.
  • Fixed several bugs impacting the Battle.net client.
  • Fixed a bug which caused Office context menus to disappear.
  • Fixed a bug which caused a corrupt file error in Office 2016 when installed with Internet Explorer.

Putty for Mac

$15.00

CodeWeavers has Released CrossOver 17.5.1 for Linux and MacOS

I am delighted to announce that CodeWeavers has just released CrossOver 17.5.1 for both macOS and Linux. CrossOver 17.5.1 has many improvements to the core Windows compatibility layer and also specific enhancements for several popular applications.

CrossOver 17.5.1 supports the latest version of Microsoft Office 365 and includes a number of bug fixes to improve Office 2016. Users should see increased stability and encounter fewer crashes.

CrossOver 17.5.1 is the first step towards making CrossOver for macOS fully 64-bit compatible, in anticipation of Apple’s plan to end support for 32-bit applications. As part of our transition to 64-bit, we have removed the Legacy X Window System from CrossOver 17.5.1 The Legacy X Window System had been a fallback display technology since CrossOver 13, used in a limited set of circumstances. Users who require Legacy X Window System support should continue using an earlier version of CrossOver and contact our support team.

macOS customers with active support entitlements will be upgraded to CrossOver 17.5.1 the next time they launch CrossOver. Linux users can download the latest version from  CodeWeavers.

Change Log For CrossOver Mac and Linux :

17.5.1 CrossOver - July 25, 2018

• Application Support:
  • Fixed a bug that prevented installing and launching games in newly downloaded Steam bottles. Users can now install the latest Steam app and use without modification.
• macOS:
  • CrossOver 17.5.1 includes preliminary support for the beta version of macOS Mojave 10.14.

Putty for Mac

$15.00

Save up to $50 when you purchase CrossOver Mac or Linux Lifetime

Get a once in a lifetime discount (this is the FIRST time we have ever discounted the CrossOver Lifetime license) because we have limited the number of uses they have!

$50 Off First 5 People Only Enter yyzwkwwce to activate your discount Claim discount!

$25 Off First 25 People Only Enter jnndcnmc to activate your discount Claim discount!

$15 Off First 150 People Only Enter egcmghre to activate your discount Claim discount!

How do I know if the code has been used up?

Our site will tell you that the 'Coupon code' is not valid when the code has hit the maximum number of people allowed to use it.

What's Great in CrossOver 18.0

• Microsoft Office 2016 Support
• 64-bit Windows apps Support
• Battle.Net compatible running under Windows 7

Not only is CrossOver easy to set-up, our CrossTie technology makes installing your Windows software simple, with one click installation. Effortlessly switch between Mac and Windows programs and play Windows games at native speeds.

Unlike other cross-platform compatibility solutions, CrossOver doesn’t require that you purchase a Windows license ($99) in order to run Windows software on your Mac or Linux computer and with licenses starting as low as $39.95 USD, CrossOver is the most economical choice for running your Windows software on Mac or Linux.

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

CodeWeavers has Released CrossOver 17.5.0 for Linux and MacOS

I am delighted to announce that CodeWeavers has just released CrossOver 17.5.0 for both macOS and Linux. CrossOver 17.5.0 has many improvements to the core Windows compatibility layer and also specific enhancements for several popular applications.

CrossOver 17.5 supports the latest version of Microsoft Office 365 and includes a number of bug fixes to improve Office 2016. Users should see increased stability and encounter fewer crashes.

CrossOver 17.5 is the first step towards making CrossOver for macOS fully 64-bit compatible, in anticipation of Apple’s plan to end support for 32-bit applications. As part of our transition to 64-bit, we have removed the Legacy X Window System from CrossOver 17.5. The Legacy X Window System had been a fallback display technology since CrossOver 13, used in a limited set of circumstances. Users who require Legacy X Window System support should continue using an earlier version of CrossOver and contact our support team.

macOS customers with active support entitlements will be upgraded to CrossOver 17.5 the next time they launch CrossOver. Linux users can download the latest version from  CodeWeavers.

Change Log For CrossOver Mac and Linux :

17.5.0 CrossOver - May 8, 2018

• Application Support:
  • This update includes a variety of bug fixes to improve the behavior of Microsoft Office 2016. Users should see increased stability and encounter fewer crashes.
• macOS:
  • As the first step towards making CrossOver fully 64-bit compatible, we have removed the Legacy X Window System. The Legacy X Window System has been a fallback display technology since CrossOver 13, used in a limited set of circumstances.

Putty for Mac

$15.00

The WineHQ Wine development release 3.7 is now available for Linux and Mac

The WineHQ Wine development release 3.7 is now available for Linux and Mac

What's new in this release:

• MSI custom actions run in a separate process.
• Support for job files in the Task Scheduler.
• Improved viewport support in Direct 3D.
• Larger resolution version of the standard icons.
• Various bug fixes.

The source is available now. Binary packages are in the process of being built, and will appear soon at their respective download locations.

Bugs fixed in 3.7 (total 26):

  15350  wrong keyboard layout in Tomb Raider Anniversary / Legend
  15984  Black and White: crashes with page fault on temple completion
  18070  Multiple apps need separate msi custom action server process due to COM/MTA and/or isolation issues (Adobe CS3/CS4, Flash, Windows SDK 2008, Strawberry Perl, MS Office 2010)
  22210  HTML-Kit Tools trial installer produces an error message in Win7 mode (IShellLink object needs to provide IPropertyStore interface)
  22545  Multiple applications wrapped with Themida/WinLicense 2.0.x/2.1.x software protection need ntdll.dll.DbgUiRemoteBreakin stub (WinDVD 2010)
  31630  BlueStacks 2 crashes during install with Wine Mono
  37228  Cisco Jabber 11.x crashes on unimplemented function ntdsapi.dll.DsCrackNamesW
  37594  World of Warcraft in-game browser does not work (needs advapi32.BuildSecurityDescriptorW() implementation)
  37760  Several .Net applications fail under wine-mono with System.TimeZoneNotFoundException
  41295  Multiple games require stream output support for vertex shaders
  42106  Problem with user32.dll with Muv-Luv on steam: "Unimplemented function USER32.dll.GetAutoRotationState"
  42686  Poedit crashes on start on unimplemented function msvcp140.dll.?_IsNonBlockingThread@_Task_impl_base@details@Concurrency@@SA_NXZ
  43055  StarForce v3 kernel drivers crash on unimplemented function ntoskrnl.exe.FsRtlRegisterFileSystemFilterCallbacks (TrackMania Sunrise)
  43951  Fallout 4 not loading textures
  44343  Builtin WMP unable to play audio files from WPF's MediaPlayer class
  44368  Fallout 4 has graphical issues
  44871  Age of Empires II HD crashes often when restarting a scenario
  44922  Cisco Jabber 11.x crashes on unimplemented function IPHLPAPI.DLL.GetIpForwardTable2,
  44968  BASIC783Esetup.exe (Decimal BASIC) fails to install (needs SrClient.dll.SRSetRestorePoint)
  44971  HackShield for Banking Driver 'HSBDrvNt.sys' (part of Ahnlab Safe Transaction) crashes on unimplemented function ntoskrnl.exe.ExInterlockedPopEntrySList
  44984  Maya 2018 LT Installer requires unimplemented function api-ms-win-crt-time-l1-1-0.dll._timespec64_get
  44993  Magic The Gathering Arena fails to install
  44995  Metatrader4 installation needs sspicli.dll.AcquireCredentialsHandleW
  45026  Windows File Manager (WinFile) fails to build in winelib (LPDROPSTRUCT missing from winuser.h)
  45040  Morrowind Crashes shortly after boot when the user installs the Morrowind Code Patch.
  45044  Microsoft Visual C++ 2005, 2008 Redistributable installers fail with 'action L"SxsInstallCA" returned 1603'

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

 

The March Madness Mac software sale

The March Madness Mac software sale, massive savings on 65 essential macOS applications.

The Bundle Hunt New Year Mac Bundle expires on 12/25/18

Details about the bundle:

• Unlock The Bundle For $5: Unlock the bundle for $5 to access a top list of best-selling apps.
• Price/App start at $1 only
• Build Your Dream Bundle: Create your own bundle, select and add up to 30 apps per bundle.
• Multiple licenses per app: Add multiple license keys (max of 3 keys) for any app you like.

   Buy Now!

MacOS and Windows software bundles, save up to 90% off the normal retail price only at BundleHunt.

 

  Buy Now!

Putty for Mac

$15.00

Run Microsoft Office 2016 and Games on Linux with CodeWeavers CrossOver 17

Yup, that means the latest version of CodeWeaver‘s commercial Wine offering also supports the latest version of Microsoft’s hugely popular Office suite, including both Home and Business editions.
And that’s big news. LibreOffice and Google Docs are near-perfect replacements for most of us, but many students and business still require the use of Microsoft Office products or file formats. As great as interoperability is these days few alternatives are as fuss-free as opting to install Office on Linux using Wine.

Other Windows software and games that feature improved CrossOver 17 support:

• Microsoft Office 2016
• Microsoft Office 2013
• League of Legends
• Everquest
• Everquest II
• WebSite-Watcher
• Battle.Net

CrossOver 17 also features a large update to the Wine compatibility layer, a move that brings thousands of big fixes and usability improvements to users’ desktops and the (ever growing) array of software it supports.

Buy CrossOver 17

CrossOver 17 for Linux and macOS is available to purchase right now from the CodeWeavers website.

A free trial is also available if you want to test things out before you commit.

Wait: I thought Wine was free?

Wine is free, open-source software. It’s available to install on Ubuntu (and other Linux distributions) from the repos, for absolutely nothing.

CrossOver is (in effect) a commercial version of Wine. It’s not free; you have to pay for it. But many people are happy to do this — and no, they’re not crazy!

Full Article

 

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

CodeWeavers has Released CrossOver 17.0.0 for Linux and MacOS

I am delighted to announce that CodeWeavers has just released CrossOver 17.0.0 for both macOS and Linux. CrossOver 17.0.0 has many improvements to the core Windows compatibility layer and also specific enhancements for several popular applications.

Mac customers with active support entitlements will be upgraded to CrossOver 17.0 the next time they launch CrossOver.  Linux users can download the latest version from CodeWeavers.

Change Log For CrossOver Mac and Linux :

17.0.0 CrossOver - December 5, 2017

• Application Support:
  • CrossOver now supports Microsoft Office 2016.
  • CrossOver now supports Quicken 2017.
• Linux:
  • League of Legends now runs in CrossOver Linux.
• Core Technology Improvements:
  • CrossOver 17 includes an updated Wine with thousands of improvements for Windows application compatibility.
  • The default compatibility mode has been changed from Windows XP to Windows 7.
• Bug Fixes:
  • Fixed a bug which prevented Microsoft Office 2010 from registering.
  • Fixed bugs which prevented Everquest and Everquest 2 from running.
  • Many improvements to Microsoft Office 2013 applications, including better support for drawing shapes, support for gradient brushes, and more.
  • Many Windows applications will run better on high dpi screens.

Putty for Mac

$15.00

​How to run Windows apps on your Chromebook

Have you ever heard someone with a new Chromebook complaining because they couldn't run their favorite Windows application on it? I have. Now, there's a solution for them (or, for you, so you can run that one Windows application you can't live without). For years, CodeWeaver's CrossOver enabled you to run many popular Windows applications on Linux and macOS. Now, CodeWeavers is bringing those same Windows apps to your Chromebook.

Better still, the beta CrossOver on Chrome OS promises to be easier to use than ever before. Previously, you had to jump through hoops to get Windows apps running on a foreign platform. With CrossOver for ChromeOS, you type in the Windows app's name, pick it from a list when it shows up, make sure you have the installation media, and hit install. Nothing could be easier.

CrossOver won't run all Windows programs, but it runs many of them. For example, its supported Windows applications include Microsoft Office and Quicken. CrossOver also runs games. These include such popular massively multiplayer online role-playing games (MMORPGs) games as World of Warcraft and Guild Wars.

CrossOver on Chrome OS is still a beta. While I could run some of my favorite simple programs on it, like NotePad++, a source-code editor on it, I couldn't run others. For instance, while I could install Microsoft Office 2016 on my 2015 Chromebook Pixel, Office wouldn't run on it.

Games that lock the mouse, such as first-person shooters, won't work either. That's because the required application programming interface (API) isn't in Chrome OS' current version of Android. It's expected to be added shortly. Video-heavy programs that require OpenGL also aren't supported. This is because Android only supports OpenGL ES, which is an OpenSL subset.

So, I can't recommend switching to a Chromebook to run Windows applications yet. But, the beta download is free, and it's certainly worth trying. Well, it's worth giving a shot if you have a Chromebook that supports Android. You see, CrossOver on Chrome OS is really Chromebook on Android. That means you need a newer Chromebook.

Jeremey White, CodeWeavers' founder, explained the Android connection happened because: "We've been experimenting with Android support for the past four years ... There have been a lot of challenges - and a lot of challenges remain. For example, we poured a lot of energy into making Windows applications work on a variety of Android form factors, including phones and tablets. But the brutal truth is that if I give you, say, Microsoft Word, on your phone, you'll fairly quickly figure out that you don't really want the Windows version of Word on your phone. Your fingers can't operate the menus." But, then, he said, "With the announcement of support of Android in Chrome OS, suddenly things made a lot more sense. A Chromebook has a big enough screen. And a keyboard and a mouse. And often, an Intel processor. What's more, it's really handy to have Quicken or Wizard 101 or your favorite Windows application right there."

It doesn't have to be a powerful Chromebook to run Windows apps on a Chromebook, although it must have an Intel processor. That's because CrossOver uses Wine, a lightweight program that's been used for decades now to run Windows programs on macOS, Linux, and Unix. It does this by creating a Windows API compatibility layer. This enables you to install and run 32-bit Windows software without actually running Windows.

Full Article

CodeWeavers releases a open beta of CrossOver for Chrome OS

 From Jeremy White's blog

Today is a very exciting day - we have released an open Beta of CrossOver on Chrome OS, which runs on the Android subsystem of Chrome OS and makes it possible to easily and cleanly run Windows applications on an Intel based Chromebook.

This is a particularly satisfying for me, personally.  That is, I have always loved technology best when there is are a lot of vibrant options in the market.  With the launch of CrossOver, we believe that Chrome OS becomes an even more compelling choice.

And I love this version of CrossOver; I think it's our cleanest and most elegant version yet.  It's inspired by the simplicity and elegance of Android and Chrome OS; I think it's by far the best CrossOver we've ever made.

It's been a long journey - we've been experimenting with Android support for the past four years, and it's been ten years since we added a new major operating system (we launched CrossOver Mac in January of 2007)...

Full Blog post

The WineHQ Wine development release 2.14 is now available for Linux and Mac

The WineHQ Wine development release 2.14 is now available for Linux and Mac

What's new in this release:

• Mono engine updated with some bug fixes.
• C++ calling convention workarounds in the IDL compiler.
• Z-order support in the Android graphics driver.
• Scalable mouse cursors on macOS.
• Various bug fixes.

The source is available now. Binary packages are in the process of being built, and will appear soon at their respective download locations.

Bugs fixed in 2.14 (total 18):

  35423  Serif WebPlus x5/x6/x8 installer fails, reports 'Invalid command line.'
  38322  Call of Duty Modern Warfare 3 and Saints Row 3: Wine crashes when Steam is starting the game
  40919  Worms Armageddon Gameplay only shows top-left corner of screen
  41263  Dead by Daylight: Crash on starting the game
  41985  CHM viewer does not use default window
  42165  Root Double only shows black window in new game
  42416  iMesh 10 crashes at startup (IWMReader::QueryInterface doesn't support IWMReaderAccelerator, 'BDDC4D08-944D-4D52-A612-46C3FDA07DD4')
  42508  start.exe does not detect its title argument when it should  (breaking .e.g URL opening in League of Legends)
  42514  start.exe incorrectly treats multiple quoted arguments as the console title  (breaking .e.g URL opening in League of Legends)
  42526  DiRT Showdown hangs on start
  43135  The Witcher 3. The game does not start after upgrading to wine-staging 2.9. On wine-staging 2.8 game works.
  43144  Distorted graphics in the game Starcraft 2.
  43369  Nora, Princess and Stray cat (demo): fails to run (division by zero)
  43402  Star Wars - Knights of the Old Republic: hardware mouse pointer invisible
  43403  make error on Debian 4.9.30-2kali1 (2017-06-22) x86_64 GNU/Linux
  43413  Quicken Basic 2007 installer triggers __stack_chk_fail() on Wine builtin 'msiexec'
  43420  UnrealEd 3: Cannot fully build map since Wine 2.13
  43424  cursor icon has the wrong size

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

CodeWeavers has Released CrossOver 16.2.5 for Linux and MacOS

I am delighted to announce that CodeWeavers has just released CrossOver 16.2.5 for both macOS and Linux. CrossOver 16.2.5 has many improvements to the core Windows compatibility layer and also specific enhancements for several popular applications.

Mac customers with active support entitlements will be upgraded to CrossOver 16.2 the next time they launch CrossOver.  Linux users can download the latest version from https://www.codeweavers.com/

Change Log For CrossOver Mac and Linux :

16.2.5 CrossOver - July 12, 2017

• Application Support:
  • Fixed a bug which caused Steam to crash on startup.
  • Fixed a bug which caused Heroes of Might and Magic to freeze on startup.
  • Fixed a bug which caused certain Excel 2013 documents to load very slowly.

Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off  CodeWeavers CrossOver+ today.

Save 70% off CodeWeavers CrossOver Mac and CrossOver Linux

We are having a online sale at this time and the price of CrossOver Linux and CrossOver Mac is only $19.95 that's a savings of 70% off the normal retail price of CrossOver. We only have a limited number of 1 year licenses remaining, first come first serve.  :-)

Update 05/01/17

This sale has now been re-activated, CrossOver Mac and Linux is available in our FastSpring store.