These are the possible types of computer you can use:
The quick summary is: all options are fine, except for Windows, in which case you've got a problem
Your simplest option is to use Codio, if possible
Your second option is to install Cygwin, but then there will be two problems later on (you can't use the advanced debugging options to find problems with pointers, and graphics is very slow and clunky)
Virtual machines, including WSL = Bash, typically have the same two problems
So at some stage you should consider installing Linux (dual boot)
The workstations in the lab 2.11 are Linux desktops
The differences from personal Linux computers are:
they share a filestore, so you can logout of one, login to another, and see the same files
they run Centos Linux rather then Ubuntu Linux, because that makes it easier to maintain a roomful of them remotely
Codio is not the official place to do assignments for this unit, just an alternative if it is available to you, so submit each piece of work on SAFE when it is done, by the SAFE deadline
Codio gives you a 'virtual' Linux computer, in the cloud (actually Amazon Web Services)
You login to Codio via Blackboard (a unit may have a customized version of the VM for convenience)
You need to be online all the time, and use Codio's in-browser editor - it can be a bit slow
You should be able to install other tools yourself
For example, sudo apt install clang if it hasn't been done for
you
There may be a single fake assignment called Courtsework for this unit, instead of one per week
Create a folder per assignment, if it hasn't been done for you
You should see a list of files on the left, some tabs on the right, and an editor menu bar along the top
The tabs are files and tools
Clicking on a file will create a tab for it
The Tools/Terminal menu entry will give you a terminal
Edit files, then compile and run in the terminal
To upload a file into Codio, use the File/Upload menu entry
To download a file, right-click its name in the file list and choose download
To submit a program for this unit, download it from Codio, then upload it into SAFE
A Makefile needs actual tab characters in it, not spaces
You can upload a Makefile, or copy/paste a Makefile
But typing tab in the Codio editor inserts spaces
So to edit a Makefile, change settings (Codio/Preferences/Project) and add
indent_with_tabs = true; but set it back to
false before editing programs
It is possible to run graphics on Codio, but the results are not brilliant (which is why there is a custom browser-based editor)
Use Tools/Install to install the "X Server" component
Graphics output appears in a Virtual Desktop tab
Linux has the best C programming environment
Linux is free, but computers with Linux already installed are rare and expensive, so the best option is usually to buy a Windows computer and install Linux yourself as 'dual boot'
Alternatively, a cheap Chromebook can be adapted to run full Linux - it is just about OK if you can manage the small screen
This means installing Linux alongside Windows, so that either can be booted up
Make or borrow a Linux memory stick, boot from it, try everything out to make sure it is working, then install from it (you should be able to get at the Windows filestore from Linux)
Problems: it can be a bit fiddly, it might not work if not all of your hardware is recognised, and there might be some difficult configuration to do such as setting up a non-English keyboard
It is possible to run a Linux virtual machine under Windows, or use the WSL (Windows Subsystem for Linux, also known as Bash)
But there are typically problems with those approaches: speed too slow, freezing up, difficulty in configuring for non-English keyboard, poor support for graphics, no support for advanced debugging options
Ubuntu Linux is recommended to install on your own computer (but it isn't the best choice for lab computers)
Linux was designed for programmers, and has everything already
installed, but you should install clang to use
instead of gcc (see compilers)
You should learn to program with an editor window and terminal window, edit and save in the editor, then use Unix commands in the terminal to compile and run
Use the apt package manager (or equivalent) to install things
A Mac is a good second best to Linux, but a bit expensive and a bit proprietary
Macs now are more-or-less Unix compatible, and you can use editor and terminal windows, as on Linux
The homebrew package manager is recommended for installing
things - to find out if you have it, type brew, otherwise install
it from its web site
Use brew doctor to check if everything is cleanly installed,
and fix everything it complains about
You should find that your Mac has clang installed
You should also find that the command gcc works as a synonym
for clang (type gcc -v to check)
The synonym was added when they changed to clang, to help
people who were used to typing gcc
You should find that all the tools you need are already available (they come with homebrew), otherwise you may want to install XCode, not to use it directly, but just to get the command line tools that come with it
XCode is an IDE rather than just an editor and, generally speaking, it is not recommended to use an IDE until you understand how everything fits together
But if you want to use XCode, see the next slide:
For each program, create a separate project, and give it a name. (Don't use the 'playground', and make sure you create a "C MacOS application" project.)
Rename main.c to hello.c or whatever you
want. Replace the comment at the top. Frequently use the "build and run" button
(right-arrow, top left)
Find out where the project folder lives, so you can get the program out for submission
Windows is the most difficult operating system by far for programming in the C language (because its focus is on C++ and on non-programmers)
Your best options are to use Codio or install Linux
But otherwise, don't use native Windows, Visual Studio, or MSVC, and check the other options carefully
One potentially major problem with all Windows approaches, which will be especially difficult when we reach pointers in the course, is that the advanced debugging options are not available
That means you may get 'segfault' or 'abort' crashes with no hint of where the problem is in your program
Or your program could have bugs which you don't see, but which we see when marking, so that you lose marks
The remaining notes explain the different approaches:
Don't use this in this unit, because your programs will not work on the computer we use for marking
A native environment means "use Windows-only tools (MSVC, Visual Studio) to develop Windows-only programs written in a Windows-only dialect of the C language, using Windows-only libraries"
This is so far away from standard C and standard libraries that there are lots of problems
Some of the known problems with native Windows are:
Programs start with WinMain, not main, and only
the embedded computer part of C90 is supported
The long type is 32 bits, not 64 and long long
is a Windows-only semi-standard type, for which you may need to use the
non-standard %I64d print format
Many 'standard' library functions don't work the way the standard says, and
non-standard libraries like windows.h, conio.h
don't exist on other computers
Line endings are \r\n not \n
You should probably not use MSYS2 in this unit, unless you are very confident, because your programs may not work on the computer we use for marking, and you can't use the advanced debugging options
But it produces lean native Windows versions of cross-platform programs, including decent graphics
The recommended approach is: first write your program in a cross-platform way, then look into the MSYS2 issues one by one, possibly using conditional compilation so that the program still works on other platforms
MSYS2 is based on mingw-w64 which provides the basic compiler and library tools for creating Windows programs using gcc, but it is not a good idea to use mingw-w64 on its own, because it doesn't provide a good development environment
MSYS2 also uses parts of Cygwin (itself built on mingw-w64) to provide a Linux-like programming environment
It allows you, if you know what you are doing, to produce native Windows programs with a proper C compiler
There are several problems to watch out for, including:
The default gcc isn't configured for native programs, long is
32 bits, many standard C library functions don't work properly because the
Windows libraries aren't standard, stdout is buffered by
default, and Windows commands can't be run by default
There is more info at:
A summary of fixes for the problems is:
mingw-w64-x86_64-gccint64_t instead of longint64_t with %I64dsetbuf(stdout,NULL) in main#define SDL_MAIN_HANDLED with SDLThese will be explained further one by one
Go to MSYS2 download
Click msys2-x86_64-... for 64-bit Windows
Follow the instructions on the download page, accepting all the defaults
Step 5 ends with a warning message - that's normal, step 6 is to shut down the MSYS2 window (with mouse, not keyboard) and start it up again
Note step 7 is just an example, in case you want git
You now have 3 commands installed in the start menu
"MSYS2 MSYS" (not set up for development, don't use)
"MSYS2 MinGW 32-bit" (use on Win32: it has environment variables set up for Win32, or for cross-compiling from Win64)
"MSYS2 MinGW 64-bit" (use on Win64: it has environment variables set up for Win64, or for cross-compiling from Win32)
You may find the text size in the MSYS2 window too small
Right-mouse-click on the title bar
Click Text, then Select, increase the size, then Save
From inside the MSYS2 window, you can get at the whole of your computer, for
example C:\Users\Me becomes /c/Users/Me
From outside the MSYS2 window, you can get at the folders inside, for
example /home/Me becomes C:\msys64\home\Me
To install gcc, don't use the default (pacman -S
gcc) because, like Cygwin, it is configured to create programs which
depend on a bloated translation library (msys-2.0.dll), so
instead:
pacman -S mingw-w64-x86_64-gcc
Option -S stands for Sync which means "find most recent version
and/or find dependencies and/or download and/or install and/or upgrade"
You'll need various other tools, for example:
pacman -S pkg-config pacman -S make pacman -S git
Try this:
pacman -Ss sdl2 pacman -S mingw64/mingw-w64-x86_64-SDL2
The first command shows all SDL2-related packages
Then use copy-and-paste to pick out the right one
The list also includes the common extensions, which you can also install similarly if you want
Using gcc or clang under MSYS2 solves the C11 language issues, with one exception
The long type is 32 bits on native Windows, instead of 64 bits
on every other platform (including Cygwin/Bash)
This is necessary for compatibility with the native Windows libraries
The C11 standard includes long long, but there is a suspicion
that this was only so that native Windows could claim to meet the standard
(which it doesn't anyway)
I don't recommend using long long in an attempt to make your
programs cross-platform
That's because there are lots of other issues to solve in programming on native Windows
So I recommend programming to the C11 standard to start with, and then switching to native Windows and gradually solve all the problems
The int64_t type is a better way to guarantee 64 bits
The standard output stream stdout is normally not buffered
This is essential, otherwise programs don't work properly and debugging becomes a nightmare because the time at which output appears on screen becomes unpredictable
The C system buffers stdout for efficiency if it thinks the
stream is going to a file or another program instead of being used
interactively...
MSYS2 needs to use the standard Windows terminal window so that various things work properly
But it also needs to send stdout through another program
before it reaches the windows terminal, to make other things work properly
But then the C system thinks stdout is not interactive, and
buffers it...
The best solution seems to be to include this as the first line of
main in every program
setbuf(stdout,NULL);
This explicitly switches off the unwanted buffering
What can you do about the fact that Windows expects programs to
start with WinMain?
The gcc setup provides a stub which fixes the problem
But SDL2 provides its own 'fix' for the native Windows compiler in
which your main is renamed
This doesn't work unless your main is defined
in precisely the correct way, so it is a long way from being
robust...
The best solution seems to be to include SDL with:
#define SDL_MAIN_HANDLED #include <SDL2/SDL.h>
The first line tells SDL that you already have a solution to the WinMain problem
By using the right mouse button on the MSYS2 MinGW 64-bit
shortcut, and choosing Properties, you can find out where it is,
probably C:\msys64\msys2_shell.cmd
Remove rem from the start of the line
set MSYS2_PATH_TYPE=inherit
Then, when you restart MSYS2, the Windows path will be added to the MSYS2 path, so you can use Windows commands, and programs that you have installed directly into Windows
Cygwin provides a Linux-like environment within Windows
It provides its own extensive library which meets both the C11 and (to a large extent) POSIX standards, and has far fewer problems than approaches which use the native Windows environment
It is suggested that you use it only for C programming, not for other languages or tools which you can use directly from Windows
Beware that most web sites about Cygwin are hopelessly out of date, but you can try:
Cygwin has one main problem, besides the lack of advanced debugging options
Running graphics programs is very awkward and unreliable, and this will be a problem when we reach graphics in the course
That's because they use Linux graphics calls, which get translated by the run time library into Windows calls
If you install the Haskell Platform onto Windows, it may globally change
where your computer thinks gcc is installed, so Cygwin may stop
working properly
So, it is suggested that you install Haskell before Cygwin, or delete and re-install Cygwin after Haskell
Go to cygwin.com and
download setup-x86_64.exe (assuming you have a 64-bit version of
Windows)
Put it somewhere handy (e.g. ...\Desktop\Cygwin) because it is
not just an installer, it is also your package manager, so you may be using it
a lot
The first time you run the program, choose all the defaults and don't install any packages
Accept default root C:\cygwin64, and anything you like,
e.g. ...\Desktop\Cygwin for the local package directory (for
temporary files)
Accept the top download site, or any other
When you get the big package selection window, ignore it for now and press next
Installation may or may not take a long time
After finishing the installation, click on the Cygwin64 Terminal icon
Now you have a Linux-like environment which you can explore, though with no packages yet
You can use Linux
commands: pwd, ls, cd, mkdir, rmdir, touch, rm, cp, mv, more, grep, find
You may find the text size of the terminal window rather small
Right click on the top title bar, choose options, choose text, press select, choose a larger font size, press save
The disk has two views now, one is the Windows view and one is the Linux view
For example /home/Me
becomes C:\cygwin64\home\Me
And C:\Users\Me becomes /cygdrive/c/Users/Me
That means you can use a Windows-installed editor to edit files inside the Linux subsystem
You can check correspondences by typing mount in the terminal
window
Run the setup program again, get to the big package selection window, and install whatever packages you want, one at a time or lots at once
The packages are organised into folders, but the organisation is not very logical
Typing the name or part of the name into the search box helps to get to the package faster
Suggested packages are coming up...
Some suggested packages are:
gcc-core in devel gcc-g++ in devel, for C++ clang in devel, alternative to gcc make in devel, not automake or cmake git in devel, version control xorg-server in X11, for graphics xinit in X11 xeyes in X11, test program for graphics libSDL2-devel in libs libSDL2_image-devel etc for extensions
More info about some of these is coming up...
Try out the gcc/clang compiler, e.g. on
#include <stdio.h>
int main() { printf("Hi!\n"); }
Use the -o option to name the created program, otherwise it
will be given the default name a.exe which you may not be able to
run because it may be blocked as a security measure
clang hi.c -o hi.exe ./hi
Git is a version tool - it is not needed for this unit, but you will need to use it sooner or later, so getting started with it now is a good idea
With things like git, you have a choice of whether to install them direct under Windows, or inside Cygwin (or both)
Graphics isn't essential for this unit, but it is desirable
Graphics is done via X11, a Linux graphics system which gets mapped into the Windows graphics system
xeyes is a silly little program showing some eyes which follow
the mouse round the screen, which is useful for testing whether graphics is
working
To get graphics working, try this in the Cygwin terminal window:
startxwin & export DISPLAY=:0.0 xeyes
The first two commands need to be done in every terminal session to start up the graphics system - they need to be exact, character for character, so copy and paste them
If you want the two commands:
startxwin & export DISPLAY=:0.0
to be executed automatically every time you start up the Cygwin terminal
window, edit the (hidden) file /home/Me/.bashrc also known
as C:\cygwin64\home\Me\.bashrc and add the two commands to it
SDL is a simple graphics library for C
It is not essential for this unit, but it is desirable later
When installing SDL:
Don't choose anything that isn't version 2
Don't choose anything with a mingw prefix
Bash (WSL) provides a Linux-like environment within Windows 10
It is better integrated with Windows than other virtual machines, because it is a joint Windows/Ubuntu project
It provides a good C programming environment, but you still can't use the advanced debugging options, and you may have trouble using a graphical editor or running SDL graphics programs
Bash hasn't been set up for graphics, so some types of graphics programs (using D-Bus?) don't work
You may find with Bash that it is practically impossible to edit programs
That's because your favourite editor won't work inside Bash because of graphics problems
And your favourite editor won't work outside of Bash because it changes files from a Windows point of view, without changing the extra information about files stored by Bash
If you have Windows 10, you can install Bash following these instructions
You will need to reboot, then run Bash
It is highly likely you will get an error: "Unsupported console
settings...", in which case you can follow
these instructions
You will find yourself in a root window ('administrator permissions') with a silly current directory
You are asked to choose a username and password - you will need the password
later for root (sudo) operations
After that, close the terminal window and restart ("Bash on Ubuntu on Windows") to get a normal terminal window
You may find the text size of the terminal window rather small
Right click on the top title bar, choose options, choose text, press select, choose a larger font size, press save
The earlier installation link has instructions for using the Ubuntu fonts
The disk has two views now, one is the Windows view and one is the Linux view
For example /home/me might
become C:\Users\Me\AppData\Local\lxss\home\me (lxss
is 'hidden')
And C:\Users\Me becomes /mnt/c/Users/Me
Beware: changing files from Windows using the path above causes trouble, because Bash stores its own directory info
Commands, programs and packages are installed in the same way as Ubuntu Linux, e.g.
sudo apt install gcc sudo apt install make sudo apt install dbus-x11 sudo apt install libsdl2-dev
A lot of online resources tell you to use apt-get, but that is
now included in apt, making things simpler
If you are happy with a non-graphical editor (vi, vim, pico, nano, emacs -nw), that's fine
If you can find a graphical editor that works despite Bash's graphics problems, that's fine
If you can find a way past Bash's graphics problems, that's fine
To get graphics working, first install
xming, directly into
Windows, not into Bash, and run it and type export DISPLAY=:0.0
before running graphics programs
It is likely you will get D-Bus problems which are nearly impossible to fix, though this or something like it may help
If you succeed, let me know