Window programming in linux

How to run Windows software in Linux: Everything you need to know

Linux is more capable than ever. With over 1,000 Linux games available on Steam and a general shift towards more web-based desktop software, there’s less need for Windows than ever. After all, you can now watch Netflix on Linux without any hacks, and you can even use Microsoft Office on Linux—a web-based version of it, at least.

But, as most dedicated Linux desktop users will eventually discover, there comes a time when you just need to run a particular piece of Windows software on your Linux PC. There are quite a few ways to do so. Here’s what you need to know.

Wine is a way to run Windows software on Linux, but with no Windows required.

Wine is an open-source “Windows compatibility layer” that can run Windows programs directly on your Linux desktop. Essentially, this open-source project is attempting to re-implement enough of Windows from scratch that it can run all those Windows applications without actually needing Windows.

This is the only method here that won’t actually require a copy of Windows, but the downside is that it won’t run every application properly. You may encounter bugs or performance issues, especially if you’re using Wine to play video games. But if you’re running a popular game released a few years ago, you may find that it performs very well. Many people use Wine to play World of Warcraft on Linux, for example. You can get an idea of how an application will run and any tweaks it might require by visiting the Wine Application Database website and searching for that application.

PlayOnLinux’s version of Wine, running on Ubuntu.

First, download Wine from your Linux distribution’s software repositories. Once it’s installed, you can then download .exe files for Windows applications and double-click them to run them with Wine. You can also try PlayOnLinux, a fancy interface over Wine that will help you install popular Windows programs and games.

Codeweavers also offers a commercial version of Wine, known as CrossOver Linux. You have to pay to use it, but Codeweavers tries to go out of their way to officially support popular applications (like Microsoft Office, Adobe Photoshop, and some big PC games) and ensure they work properly. Codeweavers also contributes its changes back to the main Wine project.

Virtual machines

Virtual machines are a very convenient way to run Windows software on your Linux PC. As PCs have gotten faster, virtual machines have become comparatively more lightweight.

This process involves installing a copy of Windows in a “virtual machine” program like VirtualBox, VMware, or Linux’s built-in KVM (Kernel-based Virtual Machine) solution. That copy of Windows thinks it’s running on real hardware, but it’s really running in window on your desktop. Modern virtual-machine solutions can even break Windows programs running in the virtual machine out of that window, allowing them to act like normal windows on your Linux desktop.

VirtualBox in Ubuntu Linux.

This solution is more foolproof than Wine. As you’re running those Windows applications on an actual copy of Windows, you won’t encounter bugs.

Using a virtual machine does require a full copy of Windows, however, and there is more hardware overhead because that copy of Windows has to be running alongside your primary operating system. In particular, demanding PC games that need access to your computer’s graphics card won’t perform well at all—you’re better off with Wine for those. But for productivity applications like Microsoft Office or Adobe Photoshop, this is an excellent solution.

Dual-booting

Dual-booting isn’t technically a way to run Windows software on Linux itself, but it is how many Linux users run Windows software. Rather than using it directly under Linux, you just reboot your computer, choose Windows, and boot into Microsoft’s operating system. The Windows software can then run in its native environment. Thanks to modern solid-state drives, that reboot process should be faster than ever.

Installing Linux in a dual-boot configuration.

This is particularly ideal if you’re a PC gamer who just can’t give Windows up yet. Rather than forgoing all those Windows games, you can just reboot your computer when you want to play Windows-only games. As you’re using plain-old Windows running directly on the hardware, you won’t have to deal with any compatibility or performance headaches.

The best way to set up a dual-boot system is to install Windows first—if your computer came with Windows installed, that’s good enough. Next, install the Linux distribution of your choice and tell it to install alongside Windows. You’ll then be able to choose your preferred operating system each time you boot your computer. This Ubuntu guide to installing Linux beside Windows can help walk you through the process.

Want to stay up to date on Linux, BSD, Chrome OS, and the rest of the World Beyond Windows? Bookmark the World Beyond Windows column page or follow our RSS feed.

The best option really depends on what you’re trying to do. If you need to run a single application or game that works well in Wine, Wine may be ideal. If you need to run a variety of desktop applications—like the most modern versions of Office and Photoshop, which Wine might struggle with—a virtual machine will be best. If you’re a PC gamer who still wants to play the latest Windows games, dual-booting will give you the performance you want without the headaches of Wine.

Источник

Working across Windows and Linux file systems

There are a number of considerations to keep in mind when working between Windows and Linux file systems. We have outlined a few of them for you in this guide, including some examples of interoperability support for mixing Windows and Linux-based commands.

File storage and performance across file systems

We recommend against working across operating systems with your files, unless you have a specific reason for doing so. For the fastest performance speed, store your files in the WSL file system if you are working in a Linux command line (Ubuntu, OpenSUSE, etc). If you’re working in a Windows command line (PowerShell, Command Prompt), store your files in the Windows file system.

For example, when storing your WSL project files:

• Use the Linux file system root directory: \\wsl$\Ubuntu-18.04\home\ \Project
• Not the Windows file system root directory: /mnt/c/Users/ /Project$ or C:\Users\ \Project

When you see /mnt/ in the file path of a WSL command line, it means that you are working from a mounted drive. So the Windows file system C:/ drive ( C:\Users\ \Project ) will look like this when mounted in a WSL command line: /mnt/c/Users/ /Project$ . It is possible to store your project files on a mounted drive, but your performance speed will improve if you store them directly on the \\wsl$ drive.

View your current directory in Windows File Explorer

You can view the directory where your files are stored by opening the Windows File Explorer from the command line, using:

Alternatively, you can also use the command: powershell.exe /c start . Be sure to add the period at the end of the command to open the current directory.

To view all of your available Linux distributions and their root file systems in Windows File explorer, in the address bar enter: \\wsl$

Filename and directory case sensitivity

Case sensitivity determines whether uppercase (FOO.txt) and lowercase (foo.txt) letters are handled as distinct (case-sensitive) or equivalent (case-insensitive) in a file name or directory. Windows and Linux file systems handle case sensitivity in different ways — Windows is case-insenstive and Linux is case-sensitive. Learn more about how to adjust case sensitivity, particularly when mounting disks with WSL, in the Adjust case sensitivity how-to article.

Interoperability between Windows and Linux commands

Windows and Linux tools and commands can be used interchangeably with WSL.

• Run Windows tools (ie. notepad.exe) from a Linux command line (ie. Ubuntu).
• Run Linux tools (ie. grep) from a Windows command line (ie. PowerShell).
• Share environment variables between Linux and Windows. (Build 17063+)

Run Linux tools from a Windows command line

Run Linux binaries from the Windows Command Prompt (CMD) or PowerShell using wsl (or wsl.exe ).

Binaries invoked in this way:

• Use the same working directory as the current CMD or PowerShell prompt.
• Run as the WSL default user.
• Have the same Windows administrative rights as the calling process and terminal.

The Linux command following wsl (or wsl.exe ) is handled like any command run in WSL. Things such as sudo, piping, and file redirection work.

Example using sudo to update your default Linux distribution:

Your default Linux distribution user name will be listed after running this command and you will be asked for your password. After entering your password correctly, your distribution will download updates.

Mixing Linux and Windows commands

Here are a few examples of mixing Linux and Windows commands using PowerShell.

To use the Linux command ls -la to list files and the PowerShell command findstr to filter the results for words containing «git», combine the commands:

To use the PowerShell command dir to list files and the Linux command grep to filter the results for words containing «git», combine the commands:

To use the Linux command ls -la to list files and the PowerShell command > out.txt to print that list to a text file named «out.txt», combine the commands:

The commands passed into wsl.exe are forwarded to the WSL process without modification. File paths must be specified in the WSL format.

To use the Linux command ls -la to list files in the /proc/cpuinfo Linux file system path, using PowerShell:

To use the Linux command ls -la to list files in the C:\Program Files Windows file system path, using PowerShell:

Run Windows tools from Linux

WSL can run Windows tools directly from the WSL command line using [tool-name].exe . For example, notepad.exe .

Applications run this way have the following properties:

• Retain the working directory as the WSL command prompt (for the most part — exceptions are explained below).
• Have the same permission rights as the WSL process.
• Run as the active Windows user.
• Appear in the Windows Task Manager as if directly executed from the CMD prompt.

Windows executables run in WSL are handled similarly to native Linux executables — piping, redirects, and even backgrounding work as expected.

To run the Windows tool ipconfig.exe , use the Linux tool grep to filter the «IPv4» results, and use the Linux tool cut to remove the column fields, from a Linux distribution (for example, Ubuntu) enter:

Let’s try an example mixing Windows and Linux commands. Open your Linux distribution (ie. Ubuntu) and create a text file: touch foo.txt . Now use the Linux command ls -la to list the direct files and their creation details, plus the Windows PowerShell tool findstr.exe to filter the results so only your foo.txt file shows in the results:

Windows tools must include the file extension, match the file case, and be executable. Non-executables including batch scripts. CMD native commands like dir can be run with cmd.exe /C command.

For example, list the contents of your Windows files system C:\ directory, by entering:

Or use the ping command to send an echo request to the microsoft.com website:

Parameters are passed to the Windows binary unmodified. As an example, the following command will open C:\temp\foo.txt in notepad.exe :

This will also work:

Share environment variables between Windows and WSL with WSLENV

WSL and Windows share a special environment variable, WSLENV , created to bridge Windows and Linux distributions running on WSL.

Properties of WSLENV variable:

• It is shared; it exists in both Windows and WSL environments.
• It is a list of environment variables to share between Windows and WSL.
• It can format environment variables to work well in Windows and WSL.
• It can assist in the flow between WSL and Win32.

Prior to 17063, only Windows environment variable that WSL could access was PATH (so you could launch Win32 executables from under WSL). Starting in 17063, WSLENV begins being supported. WSLENV is case sensitive.

WSLENV flags

There are four flags available in WSLENV to influence how the environment variable is translated.

• /p — translates the path between WSL/Linux style paths and Win32 paths.
• /l — indicates the environment variable is a list of paths.
• /u — indicates that this environment variable should only be included when running WSL from Win32.
• /w — indicates that this environment variable should only be included when running Win32 from WSL.

Flags can be combined as needed.

Read more about WSLENV, including FAQs and examples of setting the value of WSLENV to a concatenation of other pre-defined environment vars, each suffixed with a slash followed by flags to specify how the value should be translated and passing variables with a script. This article also includes an example for setting up a dev environment with the Go programming language, configured to share a GOPATH between WSL and Win32.

Disable interoperability

Users may disable the ability to run Windows tools for a single WSL session by running the following command as root:

To re-enable Windows binaries, exit all WSL sessions and re-run bash.exe or run the following command as root:

Disabling interop will not persist between WSL sessions — interop will be enabled again when a new session is launched.

Источник

Window programming in linux

WinApps for Linux

Run Windows apps such as Microsoft Office/Adobe in Linux (Ubuntu/Fedora) and GNOME/KDE as if they were a part of the native OS, including Nautilus integration for right clicking on files of specific mime types to open them.

Proud to have made the top spot on r/linux on launch day.

WinApps was created as an easy, one command way to include apps running inside a VM (or on any RDP server) directly into GNOME as if they were native applications. WinApps works by:

• Running a Windows RDP server in a background VM container
• Checking the RDP server for installed applications such as Microsoft Office
• If those programs are installed, it creates shortcuts leveraging FreeRDP for both the CLI and the GNOME tray
• Files in your home directory are accessible via the \\tsclient\home mount inside the VM
• You can right click on any files in your home directory to open with an application, too

Currently supported applications

WinApps supports ANY installed application on your system.

It does this by:

1. Scanning your system for offically configured applications (below)
2. Scanning your system for any other EXE files with install records in the Windows Registry

Any officially configured applications will have support for high-resolution icons and mime types for automatically detecting what files can be opened by each application. Any other detected executable files will leverage the icons pulled from the EXE.

Note: The officially configured application list below is fueled by the community, and therefore some apps may be untested by the WinApps team.

	Adobe Acrobat Pro (X)		Adobe Acrobat Reader (DC)
	Adobe After Effects (CC)		Adobe Audition (CC)
	Adobe Bridge (CS6, CC)		Adobe Creative Cloud (CC)
	Adobe Illustrator (CC)		Adobe InDesign (CC)
	Adobe Lightroom (CC)		Adobe Photoshop (CS6, CC)
	Adobe Premiere Pro (CC)		Command Prompt (cmd.exe)
	Explorer (File Manager)		Internet Explorer (11)
	Microsoft Access (2016, 2019, o365)		Microsoft Excel (2016, 2019, o365)
	Microsoft Word (2016, 2019, o365)		Microsoft OneNote (2016, 2019, o365)
	Microsoft Outlook (2016, 2019, o365)		Microsoft PowerPoint (2016, 2019, o365)
	Microsoft Project (2016, 2019, o365)		Microsoft Publisher (2016, 2019, o365)
	Powershell (Standard, Core)		Visual Studio (2019 — Ent|Pro|Com)
	Windows (Full RDP session)

Step 1: Set up a Windows Virtual Machine

The best solution for running a VM as a subsystem for WinApps would be KVM. KVM is a CPU and memory-efficient virtualization engine bundled with most major Linux distributions. To set up the VM for WinApps, follow this guide:

If you already have a Virtual Machine or server you wish to use with WinApps, you will need to merge kvm/RDPApps.reg into the VM’s Windows Registry. If this VM is in KVM and you want to use auto-IP detection, you will need to name the machine RDPWindows . Directions for both of these can be found in the guide linked above.

Step 2: Download the repo and prerequisites

To get things going, use:

Step 3: Creating your WinApps configuration file

You will need to create a

/.config/winapps/winapps.conf configuration file with the following information in it:

The username and password should be a full user account and password, such as the one created when setting up Windows or a domain user. It cannot be a user/PIN combination as those are not valid for RDP access.

• When using a pre-existing non-KVM RDP server, you can use the RDP_IP to specify it’s location
• If you are running a VM in KVM with NAT enabled, leave RDP_IP commented out and WinApps will auto-detect the right local IP
• For domain users, you can uncomment and change RDP_DOMAIN
• On high-resolution (UHD) displays, you can set RDP_SCALE to the scale you would like [100|140|160|180]
• To add flags to the FreeRDP call, such as /audio-mode:1 to pass in a mic, use the RDP_FLAGS configuration option
• For multi-monitor setups, you can try enabling MULTIMON , however if you get a black screen (FreeRDP bug) you will need to revert back
• If you enable DEBUG , a log will be created on each application start in

Step 4: Run the WinApps installer

Lastly, check that FreeRDP can connect with:

You will see output from FreeRDP, as well as potentially have to accept the initial certificate. After that, a Windows Explorer window should pop up. You can close this window and press Ctrl-C to cancel out of FreeRDP.

If this step fails, try restarting the VM, or your problem could be related to:

• You need to accept the security cert the first time you connect (with ‘check’)
• Not enabling RDP in the Windows VM
• Not being able to connect to the IP of the VM
• Incorrect user credentials in

/.config/winapps/winapps.conf

Not merging install/RDPApps.reg into the VM

Then the final step is to run the installer which will prompt you for a system or user install:

This will take you through the following process:

Adding pre-defined applications

Adding applications with custom icons and mime types to the installer is easy. Simply copy one of the application configurations in the apps folder, and:

• Edit the variables for the application
• Replace the icon.svg with an SVG for the application (appropriately licensed)
• Re-run the installer
• Submit a Pull Request to add it to WinApps officially

When running the installer, it will check for if any configured apps are installed, and if they are it will create the appropriate shortcuts on the host OS.

Running applications manually

WinApps offers a manual mode for running applications that are not configured. This is completed with the manual flag. Executables that are in the path do not require full path definition.

Checking for new application support

The installer can be run multiple times, so simply run the below again and it will remove any current installations and update for the latest applications.

Optional installer command line arguments

The following optional commands can be used to manage your application configurations without prompts:

• Black window: This is a FreeRDP bug that sometimes comes up. Try restarting the application or rerunning the command. If that doesn’t work, ensure you have MULTIMON disabled.

• Some icons pulled from
  • Fluent UI React — Icons under MIT License
  • Fluent UI — Icons under MIT License with restricted use
  • PKief’s VSCode Material Icon Theme — Icons under MIT License
  • DiemenDesign’s LibreICONS — Icons under MIT License

About

Run Windows apps such as Microsoft Office/Adobe in Linux (Ubuntu/Fedora) and GNOME/KDE as if they were a part of the native OS, including Nautilus integration.

Источник