I recently agreed to a change of role within the development team at my company. As a result, amongst other things, I have been learning to program in C. For the uninitiated, C is a powerful programming language that originated in the 1970s, and still persists to this day. It can be compiled and executed on most modern Operating Systems (including Windows, Mac OSX and Linux). It is generally used when high-speed performance and efficiency are essential.
The particular application that I will be contributing to is my company’s own customisation of Asterisk (an open-source PBX). Asterisk is written in C and, for our purposes at least, runs on CentOS (a flavour of Linux). I had primarily been a Windows/.NET developer, making GUI applications in a fully featured IDE such as Visual Studio 2013 so I was expecting a steep learning curve.
I only really knew enough about the Linux command line environment so that I could deploy a CentOS template in our VM system, connect to it via a PuTTY terminal and then install and monitor our customisation of Asterisk. I never spent more time than I needed to in this environment, opting to perform text file/configuration file editing in the basic editor provided by the excellent WinSCP — an FTP client.
So, to recap, in a relatively short period of time, I needed to learn C, Asterisk and to become comfortable operating in a Linux command line environment.
Programming in a Command Line Environment
We ordered in some classic books like The C Programming Language (2nd Edition) by Kernighan and Ritchie (also known as K&R, and appears to be affectionately known as The Bible, amongst programmers of a certain vintage) and Asterisk: The Definitive Guide amongst others. I deployed a CentOS VM (Virtual Machine) for playing with, installed the various GNU development utilities and I got going.
Here’s a screenshot of the obligatory “Hello World” example written in C, with Vim, in a PuTTY terminal.
I’m sure you’ll all agree that it is horrible. Syntax highlighting is a must, as far as I am concerned, which is why I initially opted from Vim over a more basic editor, but what’s with all the impossible to read dark blue? It is not much better in Nano, either, for that matter.
It wasn’t long before I began to get frustrated with this and look to customise the color scheme. I chanced upon the Zenburn colour scheme and followed the instructions in order to implement it. With a few extra tweaks (e.g. including line numbers) I arrived at a much better destination.
This was an improvement, but I still missed editing in a graphical editor on Windows as opposed to in a command line editor in a PuTTY terminal. I’m far more efficient in this environment. Especially when copying and pasting.
Returning to the comfort of Windows
I found both to be a pleasure to work in, although there’s one that I find I keep going back to first. Atom appears to have won this particular battle.
Despite deciding to code in a Windows environment, I still wanted my code to compile and run in a Linux one, so, alongside Atom, I needed to have a WinSCP window open at all times (for copying files across to the CentOS VM) and also a PuTTY terminal (for issuing the compile requests and for executing the resulting binaries).
I settled on this set-up, despite its clunkiness. This, until I heard that Microsoft and Canonical were teaming up to bring the Ubuntu Bash Shell to Windows 10. The potential advantage of this over the setup that I was running with at the time, was that this offers the opportunity to write and compile code for the target environment (Linux), in a non-target environment (Windows) because the Ubuntu layer shares the same file system as the Windows one.
Experimenting with Bash on Ubuntu on Windows
Obtaining a VM running a Windows 10 Preview build
Keen to experiment with this feature, I deployed a Windows 10 VM and got to work, retrieving and installing the latest Windows 10 Insider preview build.
NOTE: I’ll be using RDP to connect to the machine so I had to allow remote connections, which were disabled by default on my VM (press WinKey > type “allow remote” > select Allow remote access to your computer > select Remote Desktop group > check “Allow remote connections to this computer” > press OK).
Register your machine for preview builds
In order get the preview build, I simply went onto the Windows 10 Insider page, clicked on the Get Started link and filled out the necessary information. I promptly received an email from Microsoft which contained instructions on how to obtain the latest preview build.
I’ve documented them here:
On your Windows 10 PC, click Settings>Update & security>Windows Update>Advanced options>Get Insider builds>Get Started, then follow the instructions on the screen to get your PC ready for Insider Preview builds.
This was simple enough, although I should add that after initially providing my details, I had to click Get Started again in Settings>Update & security>Windows Update>Advanced options>Get Insider builds. This may be because I was actually signed into the Windows 10 session with different credentials to those that I signed up to the Insider program with.
Set the preview build frequency
Once your PC restarts, you can revisit Windows Update>Advanced options to choose how often you’ll get new Windows Insider Preview builds.
When the machine had rebooted, I logged back in, but this time with the Insider credentials from before. I chose the Fast Ring update scheme in Windows Update>Advanced options.
Install the latest preview build
Remember to keep your PC turned on and online to get the latest Preview builds.
I was getting frustrated that I wasn’t being offered the Preview build. I Googled around to no avail. I checked again after 10 minutes, then after half an hour, then an hour and again after two hours. Still nothing. The next morning, Preview build updates had been downloaded. I’m not sure of the cause; perhaps it just takes time for the machine to register itself for Preview updates. Whatever the reason, I installed the updates and rebooted the machine.
It took some time to configure the updates during the shutdown/reboot process, but once it was done, I had a Preview build watermark on my desktop.
Installing Bash on Ubuntu
I installed Bash as per the instructions on the affiliated following MSDN blog post. In short, I turned on Developer mode, enabled WSL (Windows Subsystems for Linux) and ran the bash command.
I now had a proper Bash environment installed on my Windows 10 VM.
Set up the Bash environment for Development
I needed certain development tools to be available before I could start programming in this environment. These were:
The fact that I was using “apt-get” above in order to retrieve these packages confirms that I am installing “real” Ubuntu binaries to my Bash environment.
Set up the Windows environment for Development
At this stage I was almost ready to get going. All I needed to do now was to retrieve the code I’d already written (from GitHub) and install Atom.
I’ve spent a lot of time playing with environments and tools whilst trying to learn to program in C and this looks like it has the potential to beat all of them. I should say that there is one alternative that I am yet to explore fully in Cygwin.
Cygwin is a much older approach and provides a similar bash environment for Windows with the caveat that native Linux binaries cannot be run. I can install e.g. Git, but it has to be recompiled for this environment, whereas in the Bash on Ubuntu on Windows environment, I can just grab the “real” Linux binaries from a package manager like apt-get.
I’ve also been looking at becoming more adept in the Vim text editor, having discovered the wonderful vimtutor application.
The only negative I’ve faced so far is in the performance of the VM once Atom and the rest of the development applications are running (it slows, badly). Our VM environment is not really optimised for development or high performance. It is mainly there for testing our software. We normally deploy a template, install the software under test, perform the tests and then destroy the machine.
One thing that I have enjoyed about it though, is unlike the text/graphics on the Windows 7 and Windows XP VMs on our system, the text/graphics on the Windows 10 VMs are rendered cleanly and fairly crisply. This means that working in a Windows 10 VM environment, visually, is far more pleasurable than on Windows 7 and Windows XP. It’s just a shame about the performance.
For the time being, I am going to try to persist with Vim in the Bash shell rather than Atom. I intend to report back in a few weeks, by which time, Bash on Ubuntu on Windows may have been released into the main update stream for Windows 10, at which point I’ll be more prepared to deploy it onto a bare metal machine.