2011 was the year of the games industry, as a whole, getting hacked.

Dear games industry; huge international publishers and development studios: are you seriously going to tell me you didn’t see this coming?

For the last several years, the games industry has been been infested by a plague of account systems. EVERY company wanted their customers to sign up for THEIR unique account, marketplace, community and download central, preferably with separate accounts for each. And then another account for support requests, of course. And the more of these accounts can be associated with credit card information, the better. And of course, in true games industry fashion, as much as possible should be developed in-house.

Every games company wants me to create a unique account just for them. Every games company wants my password. And apparently, nearly as many let their security be handled by Joe the Intern who does their website on weekends.

It’s absurd. And not just because you are getting hacked en masse, and your users have their sensitive information leaked to hackers courtesy of you and your incompetence and your stubborn insistence on acquiring sensitive information that you have no need of, no business storing, and are not qualified to handle and safeguard.

It is also absurd because, even when you are not being hacked, it is infuriating your users. I don’t want to have to invest in your imaginary currency (which can only be bought in bulk, in quantities conveniently designed to force you to spend more money up front than the price of the item you wanted to buy), in order to purchase DLC for my games. I don’t want to have to remember 47 different account usernames and passwords. I don’t want to have to remember which email address I signed up with two years ago on the company you bought 6 months ago and whose account database you have now integrated into yours.

I don’t want to have to guess whether I am supposed to log in with my Bioware account or my EA account when unlocking stuff for my Bioware game (published by EA). I don’t want to have to log in to both Steam and GfWL to play a game. I don’t want to have to log in to Rockstar Games Social Club. Sega, was it worth it to make me sign up for a Sega Pass? Did you get enough value out of yet another username in your database to justify my password now being in the hands of hackers?

All of you, do you really need me to sign up for anything at all? Or is this just your vanity and your 20-year-old habit of prompting users to “please fill in your registration card while you wait for the installer”, updated to the internet era for no reason whatsoever?

The rest of the world has, by and large, learned a couple of important lessons over the last years:

• online security is hard, and
• users have plenty of accounts everywhere already, and they don’t want to have to sign up for your exclusive site any more than they want to sign up for the 400 other sites they visited recently.

Thus, quite a lot of serious websites now “outsource” the account security business to those who are qualified to handle it. We have Facebook Connect, relying on the assumption that Facebook, a site with 400 million users, and a very tempting target for hackers, is able to deal securely with authentication, and we have OpenID, relying on the assumption that users themselves will use a provider that they trust among the countless different ones available.

What these have in common is that they allow you, the company hosting a website and an online service, to provide all the benefits of a personal user account to your users, but without you ever seeing a password, and without you being able to lose quite as much sensitive data when you get hacked. It also provides the convenience benefit of allowing the user (without forcing the user to do so) to reuse the same user ID across multiple sites, and it even offers the potential for exchanging (with the users’ consent, of course) information between different game companies.

And you know what? Steam is an OpenID provider. You could implement OpenID-based authentication, and people would be able to log in with their Steam ID (or their GMail account, or any of the dozens of other OpenID providers, of course), and you wouldn’t have to worry about protecting their passwords.

You could, practically in your lunch break, write a login system which allows GMail users, Steam users and Facebook users to log in using their credentials from those services, handled securely by those services, where you get all the benefit of juicy direct and “exclusive” access to the user, without the headaches of “how do we store the users’ username and password, and without hassling the user with “please come up with a username and password for yet another site.

So, dear games industry. I’m sure that pretty much anyone who has played a game over the last decade has already had his username, password, pet name, address and credit card info leaked by now, thanks to you.

But how about putting a stop to it from now on? How about leaving security to the companies that actually invest in it, and who make it their business? How about, along the way, getting rid of the current account hell where every user has to, for every game, every development studio and every publisher, remember a unique combination of URL (where your “service” is hosted this month, after the latest relaunch, the latest merger or the latest “let’s just start over because our previous system sucked”), and username, password and email address to log in to said URL?

How about making your jobs easier, while also treating your customers better and giving less information away to hackers?

How about growing up and catching up?

A common sentiment when these hacks really exploded this past summer was “these hackers need to be stopped”, but that’s missing the point. They’re only showing how absolutely trivial it is to hack a huge number of websites. Arresting them, torturing them for a few years at Gitmo or condemning them to the deepest pit of Hell doesn’t matter, because your websites are still vulnerable, and in a world of 7 billion people, someone is going to try to exploit it.

Yes, the hackers need to be held accountable, but so do you. You are the ones who chose to start hoarding user information, and you are the ones who didn’t even care enough about your users to do so securely. You are the ones who betrayed your users. You are the ones who failed to live up to the responsibility you wouldn’t even have had if you’d stuck to your actual business: making games, rather than collecting usernames and passwords.

Grow up. Start storing only the data you actually need, and make sure that what you do store is kept absolutely goddamn secure. If you ever even see my password, encrypted, hashed and salted or otherwise, you are doing it wrong.

I started on a new job back in August, which took up a lot of my attention for the first couple of months. On the home front, things have been kind of busy too, and I’ve had less time than usual for programming, and writing about programming.

But I’m not giving up on my blog. I just checked, and I have nearly as many draft posts lying around in various states of completion (47) as I’ve published (49). That is a lot of draft posts, and some of them are nearly finished.

So over the next weeks, I’ll see if I can’t wrap up a few of them, clearing out the backlog a bit and just making this place look a bit more “alive”.

So, here’s a quick followup, in order to fully exploit my 15 minutes of fame!

First, I highly recommend any newcomers read Doug Turnure’s comment on my previous post. It is an interesting read, and seems surprisingly frank about the problems with Connect as it is today. And where I would normally have expected some canned PR speech about how all the perceived problems aren’t actually problems, or can’t reasonably be fixed, it actually states that the problems are real, and that they will be fixed. Thanks, Doug!

Of course, words are cheap, and it remains to be seen whether any of this will actually result in tangible improvements to Connect. But knowing that someone within Microsoft is actually working on it is a lot better than nothing.

But being the cynical and demanding bastard that I am, I worry that this is only brushing the surface. Because the problem is not just that bugs get forgotten on Connect. Let’s try to separate the issues a bit:

Bugs are forgotten

As we saw, bugs are left to languish until they are mentioned on Twitter, implying that the way to get a bug fixed is not to bother with Connect, but instead to make a lot of noise about it on social media. Doug answered this quite clearly, saying that bugs currently “fall through the cracks”, which can, should and will be prevented in the future. That’s great, but it doesn’t solve the second part of the problem:

Even when bugs don’t fall off the radar, the way they’re handled is still broken

Bugs seem to be treated completely randomly once they’re entered into Connect. Even if they don’t “fall through the cracks”, they are still treated to a line of over-zealous moderators or whatever they are, who seem to be competing on who can close the most issues the fastest. Bugs are closed haphazardly, sometimes as a duplicate of a bug reported on an internal system that customers can’t see, sometimes as “won’t fix”, and sometimes as “won’t fix”, but with a comment saying that it may get fixed for a future release (which means it’s not quite “won’t fix” after all).

Sometimes the same scenario will result in a “deferred” status (which makes a lot more sense than “won’t fix”), and sometimes the bug will be closed as “by design”. Sometimes they’re Resolved as won’t fix, and other times they’re closed as won’t fix. What’s the difference? Are statuses assigned completely at random, or does it just look that way?

Why are issues closed when the team doesn’t have time to fix them in the upcoming release? They’re still bugs, and until a decision is made to never fix the bug, it is hard to see why they should not be considered as open, or unresolved, at least from the users’ point of view (what status it is given internally is of course up to Microsoft. But when customers see a bug closed as “won’t fix” merely because “we don’t have time to fix this in time for the next release”, they’re going to see red, and for good reason.)

Is any or all of this a consequence of the messy internal systems that Doug described, or is it that new bugs are processed and cataloged badly (whether due to the responsible staff receiving insufficient training, the policies they’re supposed to follow being unclear, or the tools they use being, well, broken)? I don’t know, but something is clearly wrong. And it is not just that bugs fall through the cracks and are forgotten.

So the real problems go deeper…

What needs to be done

Once the “superficial” problems with Connect are fixed, the next step is to make sure bugs reports are actually handled correctly: that bugs aren’t closed with “won’t fix”, unless that is actually what the responsible team intends; that duplicate bug reports are closed either with the same reason, or marked as duplicates, and that in general, reporting a bug gives the user the impression that “the bug report isn’t participating in some random lottery, where a random person will eventually close it with a random reason”.

But even then, we’re not quite home free. Because even when a bug is “fixed”, there’s a significant problem:

It hardly ever is!

When a bug is marked as “fixed“on Connect, it usually means “we have fixed this bug internally, in our trunk, and at some unspecified point in the future, we will release some unspecified product built from this source tree”.

In other words, the bug has not been fixed in the product where it was reported. The bug may have been reported in Visual Studio 2010, but it was “fixed” in Visual Studio 2012 (or whatever).

That’s not what “fixed” means, is it? A bug is fixed when it is no longer present in the product where it was reported. In other words, if a bug was reported against VS2010, then I’d consider it “fixed” when the following conditions are true:

• the bug has been fixed in the VS2010 source tree, and
• the fix is available to customers who own VS2010, or at the very least, has been scheduled for availability to users of VS2010.

Of course, some bugs are so insignificant that it’s not worth pushing an update out to users of the current product, and sometimes a fix would be so complex that it can’t be reasonably implemented in the product. Of course there are cases where it makes sense to implement the fix in the trunk of your source tree, and not in the product version where it was reported. But at least give it a different status than “fixed” then.

When a bug is “fixed” in Connect today, the message to the person who reported the bug basically boils down to this:

We have identified the problem, and if you buy a different product, priced at several thousand dollars¹, to be released in a year or two, you won’t experience it any more”.

Gee, really? So where does Connect enter into it? I’m pretty sure I can do that today without ever submitting the bug report to Connect. I could just buy a different OS or IDE. I hear a lot of people are pretty happy with XCode, for example.

Of course, exacerbating this problem, Visual Studio upgrades tend to be nontrivial for large code bases. The format of solution and project files is generally incompatible between versions (even when the only actual change to the format is an incremented version number), so not only does the user have to wait for a completely separate product to be released, and then buy it at the usual price, they also have to go through a potentially painful upgrade process… Just to see the fix to a bug they reported two years ago.

Even if all the other problems are fixed, this one still ensures that reporting bugs on Connect will feel like a waste of time. If we’re practically guaranteed that the product we reported the bug against won’t ever be fixed, why bother reporting the bug at all?

So it’s not just Connect

So this plays into another of my pet peeves about Visual Studio: I have no clue whose decision this is, and if it is actually an active decision made by someone who thinks it is a good idea, or if it is simply a fossilized holdover from the mid-80’s that no one have thought to change, but the policy of never ever improving on a released product has got to go. If I report a bug on VS2010 and you claim to have fixed it, I want the fix. If you don’t actually fix VS2010, then you haven’t fixed the bug that I reported. And if you’re not going to fix the bugs I report, where’s my incentive for reporting them?

Of course, once we accept that bugs should actually be fixed, when practically possible, it is worth asking why the same shouldn’t apply to new features and other improvements.

If you have a better compiler than the one I’m using, it really seems to be a win-win situation if you let me use it. I get to use a better compiler, I get more value out of the product I bought, and I am more inclined to buy VS vNext as well, if I know that it too will actually improve over time. Forcing me to use an, on average, 18 months old compiler doesn’t seem like good sales tactics.

Of course, not all VS users are affected equally by this. When I worked with .NET, this bothered me less, because the VS compiler set the pace: the language got updated when the compiler said so, and there were no alternative implementations to speak of. Who cares if your compiler is 2 years old? The language evolves in lockstep with the compiler anyway. Sure, I’d still have loved to see improvements to the IDE itself, but I knew there would be little point in updating the compiler out of band.

But now that I work with C++ every day, it drives me nuts. The VC++ team is (like any other C++ compiler team) perpetually playing catch-up to an international standard, and to a half-dozen competing compilers. When VC10 was released, it was on par with the competition for about 2 months. Sure, it lacked plenty of features that other compilers supported, but it also supported some that weren’t yet implemented in other compilers. Then, a couple of months later, a new GCC version was released which supported the few features that had previously been unique to MSVC. And after that, we’re witnessing a 2–3 year period of utter stagnation, where the VC++ compiler stands completely still, while all around it, the competition is making huge strides towards compliance with the new C++ standard, and making new features available by the dozen.

How is that a good idea? How does this make Visual Studio look good? Why would I pay thousands of dollars for a product that is obsolete 95% of its lifetime?

And the product doesn’t even need to be obsolete at all. The VC++ team is busy implementing countless improvements to the IDE and the compiler. But they’re being “hoarded”, waiting for the next major release, rather than being shipped out to your paying customers. It is as if someone at the top of Microsoft’s DevDiv considers software to be like fine wine; as if new features should be given a few years in a cold cellar to “mature” before being sold to customers.

Does anyone really think that this makes VS a more attractive product?

Connect is current broken, sure, but the problem goes deeper than a few “forgotten” bugs. Once that is fixed, there seems to be a lot of work to do in making Connect appear worthwhile to users (by giving better, more consistent, feedback on received bugs, and probably also through general site improvements, fixing the UX disaster that it is today), and even once those are solved, end-users are unlikely to notice much actual improvement, unless some changes are made to how the Visual Studio team in general deal with bugs, features and product updates.

At the end of the day, until we, the end-users actually get to benefit from the improvements made as a result of of our bug reports, the system will remain broken.

You can make Connect as responsive, user-friendly and all-round wonderful to use as you like — but if we, the end-users, don’t get to see fixes to the bugs we report, the system is still broken.

Of course, my ranting about this is unlikely to change much. I’m hardly in a position to tell Microsoft how to run their business. But on the other hand, there can be no harm in pointing out what I see as problems. So here we go. :)

1. create a new project of type Win32 Console Application, and under Application Settings in the project wizard, select Console Application and Empty Project.
2. create a single .cpp file
3. add the code int main() {} to it
4. hit build.

You’ll now get the warning (listed under “Errors”, for some reason): IntelliSense: PCH warning: header stop cannot be in a macro or #if block. An intellisense PCH file was not generated.

(I zipped up a solution reproducing the problem here. Note that everything is left at the default settings.

What the f…? How can something so simple break IntelliSense?

I am sometimes amazed at the apparent lack of testing that goes into a release of Visual C++. VC2010 beta 1 had a glaringly obvious bug, where the above program would fail with a linker error. Apparently, no one had thought to test a program which used the standard-compliant main instead of wmain with UNICODE enabled. Sure, it was beta, and you’d expect errors, but something simpler than a Hello World should still work, shouldn’t it?

Now we get spurious IntelliSense errors if we have the audacity to create the tiniest, simplest program imaginable, at the default settings.

Of course, it gets better. Because as we all know, Microsoft Connect is beyond useless, and obviously, some optimistic/foolish VC++ users had already reported the problem with this warning message. Google gave me the following three bug reports:

• this one, closed as By Design
• this, closed as Duplicate
• And of course, no discussion of Connect would be complete without something closed as Won’t Fix

It is one thing that errors that practically leap in the user’s face are allowed to exist in a shipping product at all, that literally the shortest, simplest program possible provokes the bug, but that Microsoft closes such bugs with three different close reasons only serves to underline how utterly useless, random and user–hostile Microsoft Connect is, and it is pretty hard to escape the conclusion that there is something fundamentally wrong with how Microsoft’s DevDiv operates.

I am generally reasonably positive towards Microsoft’s C++ compiler. It’s nothing special, certainly, and Microsoft’s policy of never ever improving an existing product means it is perpetually obsolete compared to the competition, but it generally works, and it has made great strides towards standards compliance. But the quality of the IDE, and of Intellisense, is really absurd, at times. VC2010 seems to have shifted the absurdity of IntelliSense from “it just plain doesn’t work”, to “It works reasonably ok, but imposes some baffling requirements on the code, has some kind of love affair with precompiled headers and seemingly doesn’t even bother with code that doesn’t have one, reports false positive ‘errors’, and lists them in the ‘Errors’ window, along with actual compile errors.”

And Connect is nothing short of an insult towards Microsoft’s customers. It is apparently staffed by monkeys, perhaps assisted by a script that randomly closes issues as “Won’t Fix”, and seems to serve the sole purpose of underlining to Microsoft’s customers, all the errors that will not get fixed.

Here’s another great example I saw in my Twitter feed just two days ago:

Bugs like this in WPF that date back to 2007 (I just hit it in .NET 4.0) makes me lose confidence in Microsoft Connect http://t.co/6IbRGQq

August 11, 2011 21:17 via Mobile WebReplyRetweetFavorite

@kellabyte

Kelly Sommers

Seriously 4 years on a bug that a user just has to drag something and everything busts is a pretty LONG time to not fix that… FOUR YEARS

August 11, 2011 21:21 via Mobile WebReplyRetweetFavorite

@kellabyte

Kelly Sommers

What’s worse is someone submitted a fix to the Connect bug using reflector and fixed the Microsoft code and STILL unfixed 4 yrs later

August 11, 2011 21:23 via Mobile WebReplyRetweetFavorite

@kellabyte

Kelly Sommers

@kellabyte Feedback passed over directly to very senior people in charge of WPF, expect some response

August 11, 2011 21:31 via TweetDeckReplyRetweetFavorite

@TheCATerminator

Valery M

May be a stupid question but why does a couple tweets get more traction than 4 years of people commenting on MSFT Connect? #SystemIsBroke

August 11, 2011 21:37 via Mobile WebReplyRetweetFavorite

@kellabyte

Kelly Sommers

#SystemIsBroke indeed. Why even have Connect, when bugs apparently only get resolved once someone with lots of followers on Twitter complain about it?

And of course, this gem of a response from Microsoft on the bug report itself is really remarkable:

I do understand your concern, but we are beyond our ZBB date, therefore only ship-blocker bugs make the bar at this point. Considering that we have shipped this bug before, it is hard to make a case that we need to fix it in this release since it did not block our previous release. Thank you.

Wait what? I guess this pretty much confirms what we all knew: that once a bug has been closed as “Won’t Fix”, the claims that “we will evaluate this for a future release” are just pretense. What actually happens is that the older a bug gets, the lower priority it’s given, according to some twisted “precedence” principle. “We’ve been able to ignore the bug for X years now, so surely, there’d be no harm in ignoring it one more year”.

Now sure, I’m not particularly concerned about WPF, but it shows that the problems with Connect are not limited to Visual C++ issues.

Dear Microsoft, Connect is broken. And everyone except you knows it.

Hurrah!

Apparently, it’ll take a few months for all the paperwork and such to catch up, and then the final standard will be published by ISO (I haven’t been able to find a clear answer to whether or not this might drag the final release all the way out to 2012, but hopefully, C++0x will be forever known as C++11).

Of course, whenever someone dares to admit this, they’re set upon by everyone and heckled and pestered until they give in and install some VCS. And then they spend a few afternoons moaning about how they “could have been coding instead”.

And it occurred to me that there doesn’t seem to be any short, simple, minimalist guide to setting up and using a VCS system. There are plenty of excellent tutorials and guides which explain everything about everything, and are an amazing resource to those willing to actually spend time to learn how to use their tool.

But newcomers to version control are generally someone who’s willing to give it 2–3 minutes, if it’ll shut everyone else up so they can get back to coding. They’re not interested in knowing what their code looked like 7 months ago, or what exact changes were committed on the 28th of June 2010 at 9:37 pm. And they don’t really see why they’d want to branch and merge their code.

Thus…

The 5-minute guide to Bazaar¹

You can use any VCS you like. But the distributed variants (DVCS) are newer, shinier, more powerful and easier to use. So use one of those. The three main ones are Git, Mercurial (Hg) and Bazaar (Bzr), in decreasing order of popularity (and, subjective alert, increasing order of user-friendliness). In any case, I like Bazaar, so that’s what this guide is going to use.

Install Bazaar

Pick yer poison. Bazaar is available for pretty much any OS. Pick the relevant one, download it and install it. (For Windows, you probably want the standalone installer, not the Python ones — unless you have Python installed, in which case you can pick the Python-based one if you like.

Fire up the command line

On Windows, that’s good old cmd.exe. On OS X or Linux, you’ve got terminals and a half-dozen different shells.²

Now, cd to wherever your code is:

c:\somewhere> cd \dev\myproject
c:\dev\myproject>

Initialize a repository. A repository is a small file-based database storing current and past versions of your code.³

c:\dev\myproject> bzr init
Created a standalone tree (format: 2a)

There we go. Bazaar now assumes that the current directory is what it’s supposed to track. It just created a subfolder with the name .bzr, into which it’s going to store all the versioning data associated with your project. If you ever want to just rip everything Bazaar out of your project, just delete that folder.

Now, it’s time to tell Bazaar which files to track:

Putting files under version control

We’ve probably already got some code, spread over one or more files. There’s almost certainly also some temporary files, intermediate files creating during a build, and your final executable, and whatever else, which we do not want to version control. Your VCS system should track the files needed to build your project. No more, no less.

So we need to divide our code up into these two groups. Files that should be version-controlled, and files that should be left out.

A good start is to ask Bazaar what it sees. If your project is a Visual C++ 2010 project, it might look something like this:

c:\dev\myproject> bzr status
unknown:
  Debug/
  myproject.sdf
  myproject.sln
  myproject.vcxproj
  myproject.vcxproj.filters
  myproject.vcxproj.user
  ipch/
  main.cpp

These are the files and directories which Bazaar found, and which, as it says, are unknown. We haven’t yet told Bazaar anything about them.

Well, running through the list, we can see:

• Debug, where the output of a debug build are stored. It contains a half-dozen different file types, from our myproject.exe to a bunch of build logs, and intermediate build files, manifests and other stuff. It’s all generated during build, so we don’t want any of it.
• The Intellisense database, myproject.sdf, and an associated ipch directory storing some other Intellisense cruft which is also generated automatically.
• The Solution file, which we do want Bazaar to keep track of
• The project file, including the project filters it uses, both of which should be version-controlled, and the .user file containing user-specific configuration. If you’re just one developer, you can let Bazaar track this as well, but with more than one developer, each will probably want his own .user file, so I’ll assume you want to keep it out.
• main.cpp — our actual source code. This should definitely be version-controlled.

Well, we could selectively add the files we wanted, but that would leave us with bzr status being all cluttered up showing files we don’t care about. Instead, we should tell Bazaar to ignore the files we don’t want. Then we can add everything else.

c:\dev\myproject> bzr ignore Debug/
c:\dev\myproject> bzr status
added:
  .bzrignore
unknown:
  myproject.sdf
  myproject.sln
  myproject.vcxproj
  myproject.vcxproj.filters
  myproject.vcxproj.user
  ipch/
  main.cpp

ok, so a very short detour first, We told Bazaar to ignore the Debug directory. (The trailing / tells Bazaar that it should only ignore directories with the name Debug. The command bzr ignore Debug would have ignored both files and directories named Debug.

Note that bzr status now shows us something a bit more interesting. Debug/ has vanished from the eyes of Bazaar. The directory still exists, but we told Bazaar to ignore it, so it does. It is no longer “unknown”. On the other hand, we now have a .bzrignore file, and it is not unknown, it’s “added”. This means that it is registered as something that should be added to Bazaars repository, but it hasn’t actually been done yet. As you might have guessed, this is where it stores the information that Debug/ should be ignored. Feel free to look inside the .bzrignore file, or edit it by hand. There’s no magic in it.

Now, let’s move on and ignore the remaining files:

c:\dev\myproject> bzr ignore Debug/
c:\dev\myproject> bzr ignore /*.sdf
c:\dev\myproject> bzr ignore *.user
c:\dev\myproject> bzr ignore ipch/
c:\dev\myproject> bzr status
added:
  .bzrignore
unknown:
  myproject.sln
  myproject.vcxproj
  myproject.vcxproj.filters
  main.cpp

Pretty straightforward, eh? Note that we can use * as wildcards, allowing us to ignore entire groups of files. We can also use a leading / to indicate that this rule only applies if the pattern matches starting from the root. In other words, we want to ignore .sdf files found in the root, but not in subdirectories, whereas with .user files, we just want a blanket ban. Wherever they’re found, Bazaar should ignore them.

Now our status is down to showing just the files we actually want to add. So let’s just add everything.

c:\dev\myproject> bzr add
adding myproject.sln
adding myproject.vcxproj
adding myproject.vcxproj.filters
adding main.cpp

Here, it’s time for another little word of caution:
We just told bazaar to add everything it can see. It will do so recursively. In my little example, that makes no big difference because I only had one subdirectory, and I already told Bazaar to ignore it. If you have subdirectories that are not ignored, then this command will make Bazaar add everything the files inside them as well, even if they weren’t listed on the bzr status output, which doesn’t look inside unknown directories. So it is possible that the add command just added a bunch of other intermediate files, which you didn’t actually want to put under version control. If so, you can use bzr rm <filename> to selectively remove files from version control again. Alternatively, you can just delete the intermediate files, and when Bazaar tries to add them in a minute, it’ll realize they don’t exist, and figure out that you probably didn’t want to add those after all. Or, of course, you could have played it safe and added only the directory itself (bzr add mydir), after which bzr status would have shown the contents of the directory as well, allowing you to easily see what should be ignored and what should be added.

At this point, either read over the output from bzr add above, or run a bzr status and check the added: section. Make sure that the files you want to add are on the list, and that none of your generated/temporary files are. If your ignore patterns hide too many files from Bazaar, go ahead and edit the .bzrignore file.

Committing changes

Assuming the list of added files now matches what we actually want to add, go ahead and tell Bazaar to commit these changes:

c:\dev\myproject> bzr commit

Or, as I prefer,

c:\dev\myproject> bzr commit -m "initial commit: added files"

When you commit, Bazaar expects a small text message describing the changes that were just committed. With -m you can specify this message directly. If you don’t, Bazaar will open a text editor so you can type the message there, save the file and close the editor.

In both cases, you’ll get this output:

Committing to: C:/dev/myproject/
added .bzrignore
added myproject.sln
added myproject.vcxproj
added myproject.vcxproj.filters
added main.cpp
Committed revision 1.

Now, Bazaar has stored a copy of all the files it knows about (files you just added, and files added previously) inside its .bzr subdirectory. If you ever want to go back and check what your code looked like in revision 1, you just have to ask Bazaar (but I won’t tell you how, because this is supposed to be a short minimalist guide).

Just for good measure, check the status again:

c:\dev\myproject> bzr status

Nothing. Bazaar sees nothing interesting. There are some ignored files, but we’re ignoring those. And there are some other files, which Bazaar already knows about, and they’re unchanged compared to the version Bazaar knows. So it has nothing to say, and is polite enough to say nothing.

This is what we like to see, because it means Bazaar is completely up to date on our code.

Now, go ahead and write some code. Change something in one of your files (in my case, that’ll be main.cpp since that’s the only actual code file I have), and run bzr status again:

c:\dev\myproject> bzr status
modified:
  main.cp

Aha! Bazaar has detected that our file has been modified, and these changes have not been recorded by Bazaar. Well, perhaps that’s because the code doesn’t compile, in which case that’s fine. We only want Bazaar to store the changes that are actually worth storing. The ones that mark an improvement to the code, or the ones we might want to be able to recover later on.

But perhaps these changes are actually something we’d like to keep, in which case we commit them:

c:\dev\myproject> bzr commit -m "Fixed a ton of bugs in main.cpp"
Committing to: C:/dev/myproject/
modified main.cpp
Committed revision 2.

And once again, bzr status is empty because everything is exactly as Bazaar expects it to be. Our code looks exactly like what Bazaar was given in our last commit.

And that is basically it. You’re now using version control. When you add new files to your project, just remember to bzr add them. When you’ve made some interesting changes, run bzr commit to tell Bazaar to store a snapshot of your code as it looks now. Regularly run bzr status in between to check that Bazaar’s view of the world correlates with your own. If it shows any unknown files, get them added or ignored. And if it shows other changes, it provides a list of what changes would be committed if you ran bzr commit now. (And also, a list of which changes would be lost if you accidentally overwrote the modified file).

If you want to look up how a command is used, simply type bzr help <command>.

Of course you can do all sorts of interesting things with your repository now⁴, but you wanted the quick version. As long as you add new files, and regularly commit your changes, other programmers will shut up and leave you alone. When you actually need the more interesting features of your version control system, you can always look them up.

But for now, you can go back to coding, and no longer have to hide when people ask “so do you use version control?”.

See? That wasn’t so bad, was it?

Games for Windows Live is being relaunched again.

Considering all the fun I had last time, I personally can’t wait for this. I am sure we’re all very excited to see if the Marketplace will actually allow us non-Americans to spend our money once this merger goes through.

That would be incredible. Then they’d just need to do something about their horrible client, the horrible restrictions it places on games, the horrible infrastructure it allows games to use, and all the other ways in which it currently tries so very hard to make games unbuyable, unpatchable, and unplayable. If they then also were to start taking potential security issues seriously, then we might finally have reached a point where it stops detracting value from the games it is inflicted upon.

Or, of course, this could be yet another attempt at “rebranding” the same miserable junk “service” they’ve had for years. It certainly wouldn’t be the first time they put out press release about how the service is going to improve.

So far, it hasn’t won many people over.

It’s still not quite where I want it to be, but I felt that at the very least, it deserved a proper status page. So here it is. A brand new page on my blog. As I’m still rather busy, I can’t promise that much will happen with the library over the summer, but when something significant happens, that page will be the first to know.

They obviously went to a lot of trouble to design a new touch-based interface. But because they need backwards compatibility as well, they have a “traditional” apps isolated into a kind of “Windows 7 ghetto”, something that looks just like Windows 7, and with no visible trace of being integrated into the whole Win8/touch thing… And this is for traditional PC’s. On my PC, I’m apparently going to have to choose which environment I’m using currently, because there’s limited interaction between them. And both worlds are going to suffer from that.

But why did they do this? A traditional PC doesn’t benefit from a touch interface. So on a PC, they went to the trouble of providing a new, shiny-looking UI, which doesn’t integrate well with what a PC needs to do, or with the apps that already exist on a PC.

And on tablets? Well, they’re most likely going to use the infamous ARM port of Windows, aren’t they? And that means they won’t be able to run existing applications anyway. But they still get to drag around the entire legacy desktop “ghetto” UI. Why? So that they can run the PC versions of Excel or Visual Studio (assuming an ARM port exists)? Yeah, that’ll be hilarious to use.

From what we’ve seen so far, Microsoft has managed to produce a good touch-based UI — something that might actually give them a fighting chance in the tablet space. And they’ve got a good keyboard/mouse-based UI already. (A good command-line based UI is still MIA, of course) — and at the same time, Windows Phone makes no attempt at compatibility, and lives in its own little world.

I suspect that one of the keys to Apple’s success is that they’ve exploited each platform’s differences. They didn’t try to make OSX run on the iPhone or iPad. They wrote iOS for that (admittedly with a lot of code reuse, but as separate beasts with separate APIs and UIs). The result is that every iPad app is written for iOS and for touch. Every OSX app is written for OSX and for the “PC” platform, for mouse and keyboard.

Trying to make every device do everything, as Microsoft is seemingly doing, sounds like it will merely give us the “traditional” Windows experience, the feeling that every app is written in another era, for a very different platform, with no attempt at fitting in. So our mouse-based apps on our tablets will get a fresh brush of paint, and then they’ll be let loose on the WinTablet. We’ll get touch-based apps designed for tablets, running on PC Windows, and trying to coexist with Excel, Visual Studio, Minesweeper, Notepad and Outlook. And no matter where the user turns, he’ll be faced with apps designed for a completely different UI paradigm. But for what purpose? Does Microsoft seriously think people will buy their tablet over the iPad because it runs MS Word? And are people going to buy a Windows 8 PC just so they can, using a mouse, play a port of Angry Birds or another touch-based game?

I don’t understand the attempt to make both coexist on every device. Neither PC’s nor tablets need both. Do they? Both seem to be weakened by the presence of the other. Can you honestly say that you’d like your iPad more, if it allowed you to run OSX apps out of the box, without requiring the apps to be rewritten and redesigned for touch? I doubt it.

I don’t get it.

Without getting into all the painful details, I’ve spent most of the last month or two trying to find a new apartment, and this past weekend was spent moving out of our old apartment, painting it and fixing it up. It’s been stressful, and it hasn’t left much time for anything else.

Until July 1st, when I get to move into the new apartment, I’ll be living on a friend’s couch, so things aren’t quite back to normal yet. But the worst part is over, and hopefully I’ll be able to spend a bit of time now on interesting things, such as blogging, coding and blogging about coding.