Title: Members Experiences

Visual Studio is a very expensive Windows development environment containing several programming languages, and Microsoft recently decided to give one copy to each of the second-year undergraduates at Cambridge. The idea is that we might like to use it in our final-year project and can thereafter keep it. The secret agenda could be to turn us all into Microsoft developers, Microsoft managers and so on, as opposed to the competition (e.g. open source). Needless to say there was quite an anti-Microsoft fuss in reaction to this, and suggestions of publicly burning the software, but that didn't happen and nearly all of the students did take their copies. (I know because I took mine just before the deadline so I could see how full the sign-up sheet was.) There is however no obligation and I doubt if many of them could be caught actually using it for their projects.

Well what is it like? My first impression is, how bloated! Just look at these disk space requirements: 116-135Mb for Basic, 302-403Mb for C++, 85-90Mb for FoxPro, 81-98Mb for InterDev, 86-104Mb for J++, 59-141Mb for SourceSafe, 43-59Mb for Internet Exploder 4, 57-493Mb for MSDN (required for the online documentation), 200Mb for the NT option pack, 80-95Mb for SQL server, 50-100+Mb for SNA server and may require additional space for other stuff. Fortunately you don't have to install all of it at once. While I'm far from convinced that every one of those megabytes are properly used, there does seem to be an awful lot "thrown in" - the CHtmlView class, for example, is essentially a web browser that you can bolt into your application.

The first thing I looked at was the included book, which describes an enterprise development model, often giving the impression of being vague and hand-waving, and points to the various diagramming tools and so on that are included (some of which assume you have several computers at your disposal), then gives some hype about the various development environments and "wizards" (which are all very well if you like their way of working, but not flexible enough to work with existing non-wizard code). Of course, it advocates all-Microsoft solutions (apart from some mainframe connectivity).

The book is in a sense amateurish, the diagrams looking like they were printed on an ancient dot matrix (the book is dated 1998) and there are some typographical errors like forgetting to embolden a subheading. And there are some significant technical errors. For example, after doing the Database section of my undergraduate course I picked up on the sentence at the bottom of page 69: "The process of refining tables, ... to create an efficient database is called normalisation". Actually, normal forms are not supposed to make the database more efficient. "One fact one place" is not always efficient, if processes have to queue up to get to that one place. Normal forms are intended to help with consistency and protect against some common design flaws. They must have known this because it's implied earlier on the same page. They seem to be using technical words like "efficient" in a marketing sense. I would rather not trust a book that does that.

If "automatic code completion eliminates the need to memorise language syntax", and "Visual C++ is the development tool used to build ... Word and Excel", can we infer that the developers of Word and Excel were not good enough to remember the syntax of the language? If you use any kind of tool that finishes your code for you, you'd better check that its guess really is right, which means STOP and THINK - if you haven't got time for that then you're in for Trouble.

Another thing I'm usually sceptical of is web-site design software, and going by the book's description, no wonder there are so many inaccessible sites out there.

Then I tried to install the software. It comes as a three-CD set with an extra two CDs for MSDN (including the documentation) and one for a service pack, and Visual J++ is on a separate CD. So, when the installation completely failed, I tried first installing J++. Have a good book handy when you install, and be prepared to restart your machine several times in the process. You will be told that Internet Explorer 4 is "essential" and if you wanted to keep another version for any reason, sorry but it's going. Your shortcuts, icons, file associations and so on will also be changed whether you like it or not, and generally bits get changed all over the system - in fact it can't completely clean up after itself, as is illustrated by the direction to "reformat the hard disk and re-install the operating system" if you have used a beta copy! I like to have at least some idea of what's going on on MY system, which I have taken a lot of time adjusting.

When it had finished installing, I launched J++ and tried creating a "Windows Application", whereupon it told me that I'd better enable Microsoft language extensions or it might not compile properly. I was told "While future versions of Microsoft Java's development tools may be prohibited by court order from incorporating keyword extensions and compiler directives not contained in Sun's Java language specification, any code written and compiled with this version of the product will be unaffected by such a ruling." Draw your own conclusions!

It took me into one of those IDEs that makes your desktop look like an aircraft control panel with not so much room for the code itself. It had created a file called Form1.java, but when I looked at it, instead of seeing code I saw a window template. I removed that file from the project and did File New, and it created a file called "Java File1.java". I'm not sure what sense there is in that, since a .java file should contain a class of the same name and you can't have spaces in a class name. It wasn't obvious how to change the filename, so I created one in advance and opened it.

As you type, keywords and comments are syntax highlighted, and it pops up a list of member methods where relevant, underlines suspect syntax, and does its own thing with indentation. As with Word, such "as you type" checking can be CPU-intensive and make the software less responsive, but everyone knows You Should Get A Faster Computer (TM). These features can be turned off; indeed there is a fair amount of configurability under Tools/Options (although not all of the fonts can be changed). I would prefer to be able to turn off the pop-up list but call it up with a hotkey should I need it (like Unix's tab completion), but not a chance - it's all or nothing. I added some AWT code I had and tried compiling, but got "Specified main class 'Form1' not found". However, opening and OK-ing the Project Properties dialogue, without changing anything, fixed this problem. It produced a Windows .exe that was surprisingly small (about 10k) because it used DLLs; other output formats include DLL files, self-extracting setups and applets. Also it is possible to build a console application, although the help text rather misleadingly calls this an "MS-DOS application"; you still need Windows to run it.

I very much doubt if I'll be using J++ in preference to Sun's command-line compiler, not being too keen on point-and-click GUI builders (let alone non-standard language extensions) and finding println quicker than integrated debuggers. I might use it if I need to compile a Java program into a .exe file, and for that it's a lot of hard disk space to pay.

After J++ was installed, the rest of the setup worked. I tried Visual C++, which has a similar IDE although it doesn't seem to do quite so much as you type. The compiler was nice to recognise 'using' as a keyword, but not so nice to give me warnings about main() returning a value, and when I typed 'main()' on its own, it said "assuming void". The "Hello world" program produced a 220Kb .exe file including debug code. By the way, the included "hello world" program looks like this:

#include "stdafx.h"
int main(int argc, char* argv[])
{
  printf("Hello World!\n");
  return 0;
}

Well if it were C I'd prefer puts, not to mention <stdio.h>, but it's supposed to be C++ so what's wrong with cout? Many C++ coders (myself included) sometimes use C-ish things because of "old habit", but doing it in the example code of a development package is slightly more serious.

Then I wanted to say a little more than "hello world", so I threw my access gateway at it; this is around 200k of source that works on GNU C++. It displayed a hierarchical list of classes and methods (in a font that couldn't be made any bigger), that could be clicked on to jump there in the source. When I built it, though, it said "Cannot execute program", "0 errors, 0 warnings" and there wasn't an executable. I then realised that it doesn't recognise GNU's preferred extension of .C++ for C++ files; they must be .cpp, even though it does allow you to add .C++ files to the project and then ignores them.

I then compiled it, and was surprised to find a few errors, given that it compiled under GNU C++ with all warnings turned on. Double clicking on these errors took you to the appropriate point in the source. A couple of times I had tried to delete[] a const char*, (but you are allowed to do that Francis) which GNU let me get away with but Microsoft didn't (my users needn't worry because it was the 'const' that was in error, not the 'delete'). When I wrote

class CgiInQuery : public CGIEnvironment::CgiInput

it complained that I couldn't access the protected class CgiInput (although GNU objects to 'class CgiEnvironment::CgiInQuery' and I didn't really want to put it all in the header file), and when I wrote

return(new TableEncoding[theNumberOfEncodings] (dataFile));

it said "cannot specify initialiser for arrays". Pity - GNU and I had always thought it was a neat way of loading all the data in one line. The other errors were due to Microsoft thinking that a variable declared in a 'for' initialiser extends beyond the scope of the 'for', which is wrong (although many compilers years ago did it) [when it was the correct thing to do Francis]

Now I have actually seen Visual C++ I still fail to see why some recruitment departments require experience in it, rather than C++ experience in general. If a company uses Visual C++, practically any C++ programmer should be able to walk in and start coding in it, give or take an idiosyncracy. As for the various "wizards", I thought the whole point of them was that you didn't need experience, and many of them don't do that much anyway. What remains are things like the Microsoft Foundation Classes (MFC), and it's quite possible to use Visual C++ without touching them, so requiring Visual C++ experience could very well be specifying the wrong thing.

I did not try the other components of Studio, such as Basic (just because someone's given me a Basic compiler doesn't mean I have to use the thing). I did try Internet Explorer and as I expected I'm not too keen on it, especially when it tries to take over my life. It is however integrated with the development environment - if you load a web page with a Javascript error in it, for example, you have the option of debugging, which takes you back to the aircraft control panel and lets you edit the code. Thanks, but I'd rather not end up with the overcomplicated IE-specific web-site I might get if I developed it in that.

Thanks, Silas. Actually you should not be quite so biased. The big problem with Visual Basic is that every release is incompatible with every other one. The good things about it is that it are that it isn't Basic and it has a reasonable Visual Programming environment (though that might not be an advantage to Silas).

The real problem with using Visual C++ is that it isn't C++. Once you have a body of source code that works with VC++ you are not going to like porting it to another, more conforming compiler. And, yes, MFC does not port to other compilers, the compilers have to be fixed to compile the source code. Exactly the wrong way round.

C was first used to write the Unix kernel and has always been closely associated with Unix, and its free variants that are gaining increasing acceptance. It can be argued that programmers should have at least some experience in these, and installing one on your own machine is one way to get such experience. Here I describe my adventures from the beginning.

To run Un*x on a PC you need at least a 386; there is such a thing as the "embedded Linux kernel subset" that will run on an XT but I have had no success with it (and anyway you need an existing Unix system to compile it). In autumn 1997 I got a machine with a high enough spec, so I dug out an old magazine cover CD that had Red Hat Linux on it (it was the CD that prompted the controversial Hewson article in The Times on 20th April 1997, but I didn't know that). I read the readme and installed it.

Installation is not necessarily easy (I have heard it said that installation can be the hardest part), especially if you don't know what you're doing. You'll probably find that your first attempt won't work. The old Red Hat greeted me by mangling my partition table - it helps if you know all about primary and secondary partitions and so forth. When I sorted that out, I ended up at a # prompt (root, i.e. superuser) and didn't know what to do (I didn't know a thing about Unix). So I deleted it and went through a year of the Computer Science course with my NT student license, during which I was introduced to the lab's Unix system, and because NT kept crashing (which eventually turned out to be due to a miss-configured motherboard) and I preferred the configurability of X Windows, I wanted to switch to something else at the first opportunity.

One of the philosophies of the Unix command line is to have lots of small tools that can be combined - passing the input of one to the output of another and so on (they really do run "in parallel", so if you're filtering the output of a command you see the output from the filter while the command is still running). And some of them are very flexible, for example bash and emacs.

Discouraged by Red Hat, I tried various versions of Linux that did not require separate partitions. Monkey Linux, for example, can be installed in a DOS partition. (Most of these things can be downloaded from the Web - it helps if you are well-connected. As I write this I am offline and don't know the URL, but a search for "monkey linux" will probably get there.) Unfortunately I found I couldn't get any of the packages (applications) to install properly (there were only five of them anyway), I couldn't connect to the network and I was only just able to run X Windows (and not very well). The documentation did say that Monkey is not recommended for serious use. When Adrian Wontroba made his BSD for free offer in the summer of 1998, I thought there's no better time than the summer vacation to install and get to know a new OS, except of course that I was offline and so could not use all the online sources of information to help. I used PartitionMagic to shrink my NTFS partition, put a few files on the shared FAT and left 200Mb for FreeBSD (www.freebsd.org/). I installed FreeBSD 2.2.6 from the CD-ROM and it worked fine, but there was hardly any of that 200Mb partition left. I trimmed it down by deleting stuff I thought I wouldn't need - bad mistake as things later didn't work and I couldn't work out why. But there's nothing like deleting the small fonts in order to force applications to use larger ones!

When back at university I used my FreeBSD installation as an X terminal to access software on other people's computers. This was easier than trying to cram anything else in that 200Mb but it has its disadvantages, not least of which is you are intimately aware of all network failures. I did everything as root because my random chmods "for extra security" had made it so that only root could do anything useful and I couldn't restore the old state. It is not a good idea to do everything as root because every program you run has full access to the system. It was still apparent though that FreeBSD was much better at managing resources than NT was - the hard drive, for example, didn't thrash nearly so much, and the system as a whole was much more responsive.

I set up the Cern HTTP daemon and Lynx so I could run the access gateway, along with PC Emulator to run a couple of DOS programs, Bash, and ytree to organise files (Explorer didn't work very well). I tried Wine (the Windows emulator) but it crashed on startup. I also tried Linux emulation and it worked on the couple of binaries I tried. Sendmail didn't work at all (I think I must have deleted something I shouldn't have). I had to run the generic kernel because I didn't have room to compile my own (also at this point the motherboard was still unstable and I couldn't run the computer for that long); the generic kernel can't do everything (notably it can't do audio). The PC Emulator was fine but slow (it's a good idea to run it at a low priority) and the timer routines aren't right. ytree is a nice XTree-like program that runs from the console.

Another problem was that the kernel kept running out of swap space, especially when running lots of windows of the latest Netscape (which seems to ask for a lot of X Windows memory). Sometimes it thrashes the disk for ages and sometimes X Windows will freeze on 100% CPU, meaning you have to log in from over the network to do anything. (There was no ssh daemon and I didn't want to telnet as root or su because of the danger of network snooping, so I wrote my own "let me in" program that uses a time-dependent secret function on a random number; I put the same algorithm in my Psion palmtop and used that for authentication.)

When I came to installing KLIC, I needed more space. I couldn't re-size the FreeBSD partition, but I could create another; I crammed everything else up and created another 300Mb partition, mounting it as /usr. (My old /usr became redundant space.) I also installed emacs to look at the info files and one or two other things, but primarily I was still using FreeBSD as an X terminal. Having to switch between operating systems all the time is a pain in the neck. (I used NT's boot loader together with a small freeware program BOOTPART that lets you add almost anything to its menu.)

Recently I had occasion to get a second hard drive, and a friend helped me install it and put Debian Linux on it (see www.debian.org/). Debian has the advantage that it is very easy to set up and maintain; it is supposed to be a "zero-admin" Un*x with all the defaults set sensibly and secure, and there is a package called apt that lets you use the command "apt-get install package-name" to take you through the complete process of downloading, configuring and starting a package. The packages can be uninstalled quite simply too, and kernel customisation can be done from a dialogue-driven interface.

I'm told that a lot of Cambridge people are Debian developers. There is a kind of "holy war" between Linux and FreeBSD, with FreeBSD advocates saying that it is more mature than Linux, and Linux advocates saying that Linux has overtaken FreeBSD and the FreeBSD people are stuck in the past. I would recommend that, if your organisation has a lot of people who are experts in one but not the other, then choose that one. There are a few subtle differences between Linux and FreeBSD that may trip up the experts of the other system. But Debian is rather nice.

I would further recommend that, as much as possible, you put all your personal configuration, customisation and data in your home directory (i.e. don't make the mistake I did with FreeBSD). That way you only have to back up the home directory and a list of the packages installed; anything else is replaceable. You do occasionally need to fine-tune files in /etc, but this is generally done automatically by the Debian administration tools.

Linux can also support more hardware and filing systems. It could read my FreeBSD partitions and the NT partition, as well as using DOS with long filenames. FreeBSD is supposed to be better as a server (quite important if you're providing services), seems to be preferred by a lot of Japanese people, and reading about the Halloween Document debate got me worried that one day I'd be punished by Microsoft if I ran Linux. Well I hope not.

One package that I have come to like very much is the K desktop environment (KDE). (Note that you need to install and configure X Windows first.) KDE does have its problems - one or two of the applications (like the mail client) don't fully support customised colours, for example - but generally there are few problems. (There are some bugs you might run into very occasionally and learn how to avoid, but they may well be fixed by the time you read this.) KDE is a fully-integrated window manager, application launcher, file manager with automatic MIME type detection, FTP and Web browser, help system, archive manager and bookmarks, with all the utilities you'd expect in a full-featured GUI-based operating system and more. If you want to use Unix but don't like the command line, get KDE; if you do like the command line, get KDE anyway because it makes your xterms look good :-) The KDE defaults seem to be intended so that Windows users will feel "at home", but more powerful features (such as automatic focus) can be enabled and the configuration is dialogue-based. The documentation is very good (especially given that most of the authors speak English as a second language), and although there are some sections saying "not written yet", this does not cause a problem.

Incidentally, you don't have to use the K window manager to use the KDE applications. They will work with any window manager. Quite a few people like icewm, but unfortunately it is not supposed to be very customisable.

I would recommend that you have some system to browse the "man" (manual) pages and "info" files. GNU Emacs can browse info files. KDE can browse both, although the version I have runs into bugs. FreeBSD comes with a program called "xman" to do it. The package "tkman" is nicer, but if you want to go through a Web browser, try installing the Apache web server and the packages info2www and man2html.

You won't need a C or C++ compiler because one comes bundled with the system, as do a number of other languages, and gdb, once you get used to it, is a debugger that can actually debug, as opposed to look pretty and crash whenever your program does. You will need an editor - in the old days all editing was done with vi, and there are some people out there who might put me on their hit list if I dare denounce it, but between you and me the only thing you have to know about vi is, if you should ever get into it by accident, typing :q! will get out. Setting the EDITOR environment variable to emacs (in your .bash_profile - you'll find out when you see the documentation) should prevent any nasty accidents. The package "nedit" is a nice editor for X Windows (not the console, so don't set EDITOR to it), with a fair range of features but lighter than emacs. My system really became a "development environment" when I created a .kdelink to nedit so I could click on source files to edit them.

While you're at editing your .bash_profile and .bashrc, I recommend adding something like the following:

alias ls="ls --color"
export PS1='\h:\w\$ '
export PATH=$PATH:.

(The syntax is all in the documentation.) I could go on for some time about the various other "dot file" tweaks I like, but you'd get bored. Reading the man page for X is a good idea.

nedit is not as stable or as powerful as emacs (the version I have, for example, crashes on save if you have syntax highlighting on, but this may have been fixed). Emacs is described as an "editor plus kitchen sink" or "a Lisp interpreter and a load of Lisp". Some people do everything in it - read mail, news, browse the Web, file management etc. It does have some nice editing modes but takes some getting used to. I would recommend XEmacs over emacs because it is "nicer" in X Windows but is otherwise similar. However, some packages insist on plain emacs; for this reason I have an installation of emacs 19 (the old version, without the internationalisation and other interesting stuff) and xemacs 20.

LyX is a very good WYSIWYG interface to LaTeX, which is better than the average wordprocessor because it takes care of all the style housekeeping for you. You don't have to know LaTeX to use LyX; using LyX easily compares with using the leading wordprocessors, except that you can concentrate on the content of your document more than the layout (which is handled automatically). It is also reputed to be very stable. Most universities use TeX or LaTeX for their typesetting. TeX is a typesetting package by Donald Knuth, LaTeX is a macro system for it, and LyX is a front-end. You'll need all these packages; gs, ghostview, gsfonts, gsfonts-other and magicfilter are also useful for easy printing. (Ignore the horror stories about Unix printing; it's File Print.) For viewing Postscript and PDF, you might prefer gv to ghostview but it doesn't use your own colours. (The Adobe Acrobat reader is rather redundant.) Distributing documents in PDF and Postscript format is not a good idea for electronic viewing anyway (although a lot of universities do it) - both packages are about the most awkward and least responsive text viewers I know, especially if you have large print, and it's much better to import the TeX into LyX. By the way, using a large magnification in xdvi risks locking the X server.

Yes

Other packages on my "get them" list are:

No

Packages on my "tried and don't really like" list (with no offence intended to the authors) include:

There are of course other packages, and it is worth spending time browsing the Debian (or FreeBSD or whatever) web pages that list them, especially if you have a specialist need.

I would recommend that anyone who is able to do so should try an open source system. You Windows people don't know what you're missing.

Are Silas and I the only software users?