Phoenicis PlayOnLinux 5.0 - Alpha 2 has been released

Hi everyone!

We wish a happy and successful year! For this first day of 2019, we are glad to release the second alpha version of Phoenicis PlayOnLinux 5.

A new wine builder

We have rewritten from scratch our winebuild platform. To make it short, it is more reliable, more transparent, easier to setup and cross-platform compatible. Any project that needs to use wine could now potentially use it and take advantage of the 1828 different builds. (We admit that some of them are outdated, though).

The winebuild project is open source, uses containers. You can install it on your machine in no time if you want to build wine by yourself.

Support of new wine distributions

Speaking about wine builds, we now support 4 wine distributions:

• Upstream wine builds are vanilla and unmodified wine ⁽¹⁾
• Staging wine builds are the wine builds patched by wine-staging
• Dos support wine builds contains wine and dosbox. (See the next feature)
• CX contains a wine version patched by codeweavers

We plan to support proton in the next weeks.
All these wine build can be compiled directly through https://github.com/PhoenicisOrg/phoenicis-winebuild/.

(1) Except the very old versions that have a specific suffix is their names, like 1.5.3-heap_allocation_v2-avoid_deadlock, but we are going to move them anyway.

DOS Support

Winebuild now provides dos_support distribution. The way these wine binaries works is very simple: Wine launch script has been modified to detect if the given .exe is Win32 or a DOS executable. If it is a DOS executable, it will set-up a dosbox configuration that will behave consistenly with wine:

• mount drive_c as C: on dosbox
• if a autoexec.bat file exists inside the prefix, it will run it
• support of custom DOS configuration per prefix
• ...

The script framework has also been modified so that you can tweak some dosbox settings directly from a script. Here is an exemple of "advanced" script

1 2 3 4 5 6 7 8 9

wine.run(wine.prefixDirectory() + "/drive_c/The Elder Scroll 1: Arena/Arena106.exe"); // Arena106.exe is a w32 fine, wine will run wine.dosbox()     .memSize(64)     .renderAspect(true)     .cpuCycles("max 95% limit 33000")     .renderFrameSkip(1); wine.run(wine.prefixDirectory() + "/drive_c/The Elder Scroll 1: Arena/ARENA.BAT"); // ARENA.BAT is obviously a MS-DOS file, dosbox will run

GoG support

We've added a way to add a web browser view directly inside script wizards. Thanks to this feature, scripts can now authenticate to any website.
Phoenicis can automatically download and install GoG games from your account, as POLv4 used to do during the past years.

A complete demonstration video of gog.com support: https://www.youtube.com/watch?v=Fopp-x9Fz3g&feature=youtu.be
Also, we have made a script pattern for all GoG games: it has drastically simplified them from POLv4. The script are so much easier that we believe that they will be a lot more maintained.

POLv5 script

POLv4 script

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 include(["engines", "wine", "quick_script", "gog_script"]); var installerImplementation = {     run: function () {         new GogScript()             .name("Teenagent")             .editor("")             .applicationHomepage("")             .author("Quentin PÂRIS")             .gogSetupFileName("teenagent/en1installer0")             .category("Games")             .wineVersion(LATEST_DOS_SUPPORT_VERSION)             .wineDistribution("dos_support")             .executable("TEENAGNT.EXE")             .go();     } };

We are planning to add tons of GoG games in the library so stay tuned!

Installation of verbs directly inside a container

You can now install verbs directly from a wine container.

Standalone packages

• We are now providing standalone packages that can work on any distribution without the need to install JDK runtime. These packages also remove all the feature that we don't need from the JDK. In the future, there will be probably two sorts of packages, but we want to make things easier for you for now.
• We now provide macOS packages
• We also support flatpak

I'd like to thank once again all the developers that helped us during the past weeks, plata, madoar, and also all those of you that contributed by reporting bugs, suggesting improvements, or tested phoenicis-winebuild.

Our next goals is to focus on prefix management (change of wine version inside a prefix, add debugging tools, etc...) and performance optimization.

If you have any suggestion or encounter any bug, we encourage you to come in our Github page: https://github.com/PhoenicisOrg/. This version is still at alpha-stage, so please be indulgent.
I also take the opportunity of this news to also announce you that PlayOnLinux and PlayOnMac 4.3.4 has been released. They have been updated to support the new winebuild system, and the different windows of the application have been made resizable. It should fix the HDPI issues some of you were encoutering. We continue to maintain these versions until you are 100% satisfied with POLv5

Full Article

Putty for Mac

$15.00

Wine development release 4.0-rc6 is now available for Linux FreeBSD and macOS

Wine development release 4.0-rc6 is now available for Linux FreeBSD and macOS

What's new in this release:

• Bug fixes only, we are in code freeze.

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 4.0-rc6 (total 18):

  29181  Combo box doesn't get a background in dialog editor
  40433  Fifa 11 EU demo fails to install when run from custom DVD
  40828  Switching resolution in desktop mode makes task bar redraw on top of full screen game
  43665  The Quantum Break crashes at certain place.
  45486  Byond 512.x dreamseeker will crash on loading into a ss13 station that uses shaders if run on wine 3.9 or later, but will run fine if you use 3.8
  46007  Binary Domain crashes with builtin d3dx9_43 or d3dcompiler_43
  46059  Final Fantasy XI Online: Mouse Movement Heavily Affects FPS
  46067  Crysis has lighting issues
  46200  issues printing with LTSPICE XVII X64
  46275  Some autocomplete tests fail on Win2k3 VM
  46346  ntoskrnl/tests/ntoskrnl.c shows uninitalized memory use
  46357  Cossacks 2 Battle for Europe show crashed graphics
  46359  Vietcong: shooting from weapon causes game crash
  46369  将棋所(Shogidokoro) doesn't start.
  46398  When starting Reflex Arena in Steam: "failed to init XAudio2, is DirectX 9.0c installed?"
  46403  Vietcong: crash caused by loading map/other events
  46430  Doom3 (CD version) fails to install
  46435  F1 2011 crashes with a messed up rendering in DX9 mode

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

How to SSH into a VirtualBox VM Using PuTTY for Mac

This article discusses setting up a virtual machine (VM) as a virtual private server (VPS) and accessing it using secure shell (SSH). This VM VPS can then be used to test configuration and software changes before deployment to a live VPS. A deployed VPS can usually be accessed using SSH, therefore using SSH into VPS running on a VM is good practice for a live situation. This test configuration should accurately reflect the live VPS, reducing mistakes when moving from test to production. This tutorial and guide shows how to set up a VirtualBox VM and access it via the SSH client PuTTY, replicating production world VPS access.

You should never test on live systems. Replicate the live system in a test environment. Use the test environment to try out new configurations and software. When happy with the changes deploy to the live system with confidence. Of course there is no guarantee that the changes to the live system will not cause problems. However, the chance of errors occurring is reduced. The test environment should be the same as the live systems so that changes have the same affect when deployed.

Using a VM is a good way to test a system without impacting a local machine. VirtualBox is a free application that can run VMs. This article uses VirtualBox to configure a VM as a test VPS.
A VPS running in the cloud can be replicated on a local machine using a VM. The first step is to create a local VM. Then on the local VM install the same OS as the one running on the live VPS.

Use Port Forwarding for the Test VPS Networking

By default port 22 is used for SSH, see a list of TCP and UDP port numbers in Wikipedia. VirtualBox can be configured to listen to a port on the host machine and forward any traffic for that port to a port on the VM. This is configured in the VM’s network settings.

To change the network settings the VM VPS must be powered off or suspended.  Or save the machine state with the VirtualBox VM window’s File then Close menu option.

With the VM highlighted in the VirtualBox Manager click the Settings icon or use the Machine menu and select Settings.

Under Network the Adapter 1 tab is selected, the default virtual network adapter enabled for the VM VPS. Click Advanced then click the Port Forwarding button On the Port Forwarding Rules dialog click the Adds new port forwarding rule icon. Give the new rule a name, e.g. ssh rule, the protocol will be TCP, Host IP address is blank. Choose a Host Port such as 2222, Guest IP is blank and Guest Port will be 22. Click OK to create the new rule.

Leaving the IP addresses blank means that if the host or guest IPs change then rule will still work. The host port should not be in use by another application or service (see the the Wikipedia list for common uses of ports). While 2222 is used by some products it is easy to remember as it is simply the default port 22 written twice. Use any valid port number in the range 1025 to 65535.

Install the PuTTY Terminal Emulator

The application PuTTY is a terminal emulation program, it implements Telnet, SSH and other network protocols. PuTTY can be used for remote connections to Windows or Unix type machines, such as a Linux based VPS.

Using PuTTY to SSH into VPS Running on a VM

Open PuTTY, start a new session, the Hostname is localhost (your machine), which is the same as entering 127.0.0.1. The port is 2222, or whichever port number was set up in the port forwarding rule. Click the Open button.

The first time PuTTY connects to the VPS a security alert is shown. Confirm that the VPS is the valid by selecting Yes (it is running on the VM on the localhost). By selecting Yes the alert will not appear next time. A terminal window will appear and if everything is configured correctly the login prompt will be available. Log in as root with the password set during install. Run a command such as ls to list the files in the directory.

Typing logout will end the session and close the PuTTY window.

We now use FastSpring as our preferred storefront, you can pay with Credit / Debit Cards, PayPal, Amazon payments, Wire Transfer etc. etc. This store is very secure, simple and fast.

Purchase Putty 9.1.0 now and have Telnet SSH FTP SCP on your Mac made easy!

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.