I need to run the Microsoft Windows edition of Excel, but I'm using a Mac. I currently have Excel for my Mac, but it doesn't have all the functionality of Windows version. I need the advanced functionality only available in Windows edition. (Using Google Sheets isn't an option in this scenario). I have a license for Excel (both Windows and Mac editions).
I've heard Parallels (https://www.parallels.com/) is one way of doing it, but that would require me to have to purchase additional software.
I've thought about buying another computer, but I don't want to have to carry around 2 computers (one windows and one Mac).
Is there a way I could use Microsoft Azure, or some other cloud service to rent a windows PC, install Excel and access it from my mac?
I found this on pricing for a virtual machine, but it's not clear If it would allow to to accomplish this.
https://azure.microsoft.com/en-us/pricing/purchase-options/pay-as-you-go/
https://learn.microsoft.com/en-us/azure/virtual-desktop/
Any suggestions, or experience running the Windows edition of Excel from a Mac?
This might be a bit of a stretch, but have you looked into using Bootcamp? All you have to do is partition a part of your hard drive, then you can boot into Windows and run it natively. Bootcamp is great, as long as you understand the concept and how to use it.
Remote development on Linux from Windows is easily doable via SSH.
However, what about the other way? I need to build and debug my Visual C++ application on Windows, but I want to work on a Linux system.
Cross-compiling via MinGW doesn't work because of MSVC-specific libraries
Ubuntu on Windows is a good start, but I'd like to work on a real Linux system
RDP/VNC or something like that doesn't help either, because than I'd work on Windows again
So does a virtual machine
Maybe something like Powershell on Linux + SSH to the Windows Powershell?
I regularly develop Visual C# applications remotely from Linux, not MSVC for the most part, but, like you, I wanted to find a way to build and debug Windows-targeted applications and libraries on remote Windows machines without working directly in the box using RDP, Visual Studio, etc.
It's difficult to answer this question without more information about the development and debugging tools you prefer to use on Linux for the types of applications you develop. I'll try to provide a general overview and update the answer for details you add about your workflow.
Cygwin, similar to MinGW's MSYS, provides a Unix-like environment for Windows. Most importantly, Cygwin, unlike MinGW/MSYS, includes an implementation of the OpenSSH server that enables us to connect to the Windows box over SSH from Linux (or any other device with an SSH client, really). We can install the sshd package using Cygwin's setup utility. After connecting, Cygwin drops us into a Bash shell by default. With this capability, we can:
Execute remote commands and scripts over SSH.
Edit files using our favorite *nix command-line text editor (Vim, Emacs, etc.)
Mount remote filesystems locally using SSHFS (if Windows shares are unavailable).
Forward or tunnel ports if needed.
The availability of a general-purpose shell makes almost anything possible. We can execute batch files, PowerShell scripts, and native Windows executables from Cygwin's shell environment in addition to Linux scripts and Cygwin programs.
For example, we could run msbuild from the SSH session command line to build our VC++ application or we could configure our local GUI editor or IDE running in Linux to execute msbuild over SSH when we click the "build" button.
We could set up a similar environment in recent versions of Windows using the Windows Subsystem for Linux ("WSL", Bash on Windows). I personally prefer Cygwin for greater portability and ease of configuration. Cygwin's sshd can run as a Windows service, and, as an established project, Cygwin integrates very well with Windows systems (user accounts, filesystems, Windows APIs, etc.).
Working with Code
We can choose from several workflows depending on our tools and comfort-level with the command-line:
Completely text-based—all work performed through the SSH session
Use local tools on files mounted in a remote filesystem
Use local tools and synchronize files
I use the first approach. I'm a heavy Vim user, so I connect to Windows machines over SSH to do my work on the command-line using the tools and environment provided by Cygwin. The availability of tools typically found on Linux simplifies many tasks that are hard to do from the default Windows console. We can write shell scripts to automate tasks that Visual Studio might normally do for us. For example, I wrote a wrapper script around mstest that reads the XML test results and outputs them in a format that's easy to read in a terminal.
If we prefer to use a GUI editor or IDE, we can mount the remote code locally so tools can read and write files as if they were part of the Linux machine's local filesystem. We likely still need to use SSH to execute commands needed to build the projects, but many editors allow us to configure this command as the project's "build" action.
Sometimes a remote filesystem is too slow for effective editing. In these cases, we can synchronize files between the Linux development machine and the Windows host using a tool like rsync or the editor's "upload on save" feature (over SFTP, for example), if available.
Debugging
Everything works pretty well until we try to find a way to debug our applications. As of now, there is no reasonable substitute for Visual Studio's debugger when working with Visual C++ projects. We can debug managed C# applications running on the CLR using MDbg, but no comparable tool exists for C++ programs.
We can try to use gdb (from MinGW, Cygwin, etc.) for basic, low-level debugging of native binaries, like reading memory addresses, but the debugger does not yet support reading Microsoft's debugging symbols, so the debugging experience is very limited. Microsoft began documenting the PDB format a couple years ago, so we may see some compatibility in the future. Even so, it will take a long time to produce a satisfactory alternative to Visual Studio's excellent debugging tools.
For debugging, RDP is currently our best—and probably, only—option. For a more native-feeling experience, we can run Visual Studio using rdesktop (or other RDP client) and seamlessrdp to create a single-window RDP session of the Visual Studio IDE instead of a full desktop which integrates with whatever window manager we're using on Linux.
Sometimes we can get around launching a full Visual Studio debugging session for simple debugging scenarios by adding tracing to our application that outputs values to the console or to a log file. In many cases, this is faster than starting the debugger anyway.
We can also try to use Eclipse's CDT debugger configured for the Visual C++ toolchain. This may enable us to perform remote debugging using an Eclipse instance on the Linux machine. I have never tried this approach, and I expect there may be some issues when the application is linked against Microsoft's libraries.
I don't know all your requirements, but maybe you could use a gdbserver on Windows (from MinGW) and remote debug from VSCode on Linux - or any other environment you like. You can find more details in this post here. (Watch out, VSCode prevents you from running gdb unless it’s signed as mentioned in the first link.)
There is also a Native Debug VSCode extension that could be helpful.
Another solution I can think of is to use Visual Studio Online (free for small teams up to 5 persons) as build server.
As you have said, the other way around is pretty easy and nowadays even officially supported by Visual Studio 2017.
Most probably, the VS remote debugging tools for Windows wont be helpful for you.
I am running LabVIEW 2013 Dev Environment on a Chinese Windows 8 platform. LabVIEW is not a Unicode-base program, and consequently on Asian Windows there are display issues for our interfaces created with US-English character sets. I can fix this problem by setting the language settings for non-unicode programs to English. This works fine, except that all my other non-unicode-based programs are totally illegible.
A quick google search turned up Microsoft's utility for running application with a user-specified code page, AppLocale. The utility is only written to be compatible up to Windows XP. There are two suggested methods I ran accross for installing it: 1. run installer using compatibility settings 2. install using command prompt with admin privileges (apparently it doesn't play well with UAC. You can find one set of instructions here for installing AppLocale on Windows with UAC.
Unfortunately, nothing I have tried has been able to get LabVIEW to use the code page I would like it to. When I run LabVIEW through AppLocale and open the user-interface I am concerned about, the characters still do not display properly.
Any ideas what I might be doing wrong? Could there be a fundamental incompatibility with LabVIEW?
Does anyone know of an alternative to AppLocale that might work for me?
One alternative to Applocale on windows 8 is Locale Emulator created by xupefei. You will have to have visual studio to build the project.
Make sure that your region settings are set to an english speaking region such as the united states of america. You can check this under
control panel >> clock, language, and region >> region settings
Additionally ensure that you have the language packs installed for the character sets used by LabVIEW. You can check which language packs you have installed under control panel >> clock, language, and region >> language
You will want to have installed support for complex languages
If none of these things work I would try upgrading to windows 10 as it has much better language support
Zorin is a version of Linux which is very Windows-like. I am looking at their home page:
http://zorin-os.com/
and it says:
Zorin OS gives users more flexibility. It allows you to use Zorin OS
alongside your current operating system and run Microsoft Windows
programs in Zorin OS with the help of WINE and PlayOnLinux.
Does this mean I could use Visual Studio 2012 on Linux?!?!
Ok, so Wine is a compatibility layer which allows you to execute windows executables on your linux system. PoL is just a graphical frontend with some others functionalities.
You can use it on any linux system, it's not exclusive to Zorin.
However, executing windows applications through wine isn't always successful, especially with huge projects as Visual Studio which is using tons of native windows functionalities.
And indeed, when we check the reports, VS2012 doesn't work at all.
You can always try to install it, but when even the installer doesn't launch... You know there is no luck.
Information on IntelliJ's Blog says that drag&drop in Linux is supported as it uses the same JAVA API as Windows version. However, although I've enabled this feature in the app's properties, I cannon drag a file on Linux desktop (or from any Explorer window) and drop it in some /res folder. I cannon copy a file on desktop and paste it in any /res folder as well.
Anyone knows the way to enable this feature or make it work?
PS. The same version is installed on Windows 7 x64 and drag&drop (c/p as well) works flawlessly. I use Ubuntu 10.04 x64, but I think it's the same in all distros.
PPS. I've tested both IC and IU versions and neither supports drag&drop or c/p.
As stated in the blog, this feature is supported on Windows and on Mac, there is no word about Linux.
If you want it to work on Linux, vote for IDEA-42872.