I've been looking to buy a laptop for awhile and decided it was worth the wait until Vista made its full debut. I tried some of the Vista betas but had difficulty with drivers for my custom built desktop machine. Nonetheless, I'm still quite excited about Vista.

I've heard and read many things about Vista, both positive and negative. The most significant negative I've come across is the sheer number of UAC prompts. No security mechanism is perfect, and we do trade security for convenience, but the purpose of UAC, as I understand it, is to prevent the granting of elevated privileges to rogue programs. I've heard someone say Microsoft went too far with UAC in building in security, but is there a way to reduce the number of UAC prompts and maintain the level of security it provides? (And for any nitpickers, I'm well aware UAC is by far not the only element of security added to Vista, but it does seem to be the most visible to end users)

I've heard people complain that Administrator is not the "true" administrator on Vista, that you still get plenty of UAC prompts. Again, looking closely at where we've come from, users are used to running as Administrator on XP. Like it or not, the Administrator account must also be locked down to some degree. UAC isn't a magic bullet, and it seems imperfect (but is any single security mechanism sufficient?) but it is also there to avoid granting privileges to programs that shouldn't have them.

On the positive side, I've read that once you get through the initial configuration of your machine, after running the various programs that need the elevated privileges to install, UAC quiets down. I'll soon see what my experiences with UAC are.

I just came across a post I really liked at Ryan Bemrose's blog (The Audio Fool). He discusses various classes of legacy applications that we will be running on Vista and how these affect UAC. You can read his post at Categories of Legacy Applications 

I don't have my Vista laptop yet, but once I do I plan on documenting my early experiences with it. I realize that I'm an experienced software engineer, significantly more technical than the average user, so I'm actually expecting far more UAC prompts than average. I'll be documenting which I believe are those that end users will deal with and those that myself, installing certain more technical pieces of software, will encounter. My challenge to myself is to avoid turning UAC off, though I might consider using the security policy edit I've come across to grant the Administrator account full administrator privileges in order to avoid UAC prompts.

At this point in time I'm highly optimistic about Vista, and while acknowledging my pro-Microsoft bias, I'll try to report as honestly as I can :) Sometimes Microsoft technology does frustrate me (I have stories for another time).

At work we currently use Serena Version Manager and Tracker products (PVCS) for our source control and issue tracking. As previously (albeit briefly) mentioned, we are in the process of converting to Team System. Ultimately we decided to start the source control repository clean instead of importing our source trees from Version Manager. I did some exploratory work on figuring out how to do an import, and although it's not fully fleshed out, I'd like to throw my findings out there in the hopes this will help someone.

Okay, now to my (rough) approach. The first goal was to retrieve all version history from VM. After many fruitless online searches I eventually found what I needed, a command line utility which provides an interface to VM. This utility is pcli.exe, which I found in C:\Program Files\PVCS\win32\bin, but obviously your installation will differ. I had trouble finding documentation online for this program, however if you type "pcli -h" you will see a list of commands. You can type "pcli command -h" to get assistance on options for a particular command.

I used this utility to retrieve a list of all files within a particular folder (and all its subfolders) including all revision information for each file. I ran the following command to retrieve this list: pcli.exe vlog -z -idUSERNAME:PASSWORD -fOUTPUT.TXT -pr"PROJECT NAME" PATH_IN_VM

The "vlog" command reports archive/revision information. If you type "pcli vlog -h" you can see a full list of options. Several things to note about the command line I used. The "-z" argument recursively processes the path. Username and password are separated by a single colon. The project name should be in the form \\NAME with no trailing backslash. The PATH_IN_VM, however, must use forward slashes, with a forward slash starting the path and no trailing slash. I believe I tried different combinations and settled on these - other combinations might work, but I know for a fact that these will.

If you execute this on a VM project you should have an OUTPUT.TXT that contains information such as what follows next. I'll first show example contents and then discuss how to parse it and use the information. Before discussing this file, I should again caution that I barely scratched the surface of parsing this file. My focus was narrow, simply only needing each revision number of a particular file and some extra information such as author, check in comments, etc. Okay, here's a sample OUTPUT.TXT

Archive:          \\SampleProject\archives\Dev\Web\PrototypeSite\Default.aspx-arc
Workfile:         Default.aspx
Archive created:  Oct 10 2006 13:37:44
Split mode:       Split \\SampleProject\archives\Dev\Web\PrototypeSite\Default.aspx-arc
Owner:            jeff
Last trunk rev:   1.2
Locks:           
Groups:          
Rev count:        3
Attributes:
   WRITEPROTECT
   CHECKLOCK
   NOEXCLUSIVELOCK
   EXPANDKEYWORDS
   NOTRANSLATE
   NOCOMPRESSDELTA
   NOCOMPRESSWORKIMAGE
   GENERATEDELTA
   COMMENTPREFIX = ""
   NEWLINE = "\r\n"
Version labels:
   "Baseline 1.0" = 1.2
   "SCR-1" = 1.2
Description:
Baseline 1.0

-----------------------------------
Rev 1.2
Checked in:     Oct 11 2006 11:53:04
Last modified:  Oct 11 2006 11:52:14
Author id: jeff     lines deleted/added/moved: 6/6/0
added custom httpmodule
Resolution for 1: baseline
-----------------------------------
Rev 1.1
Checked in:     Oct 10 2006 17:43:24
Last modified:  Oct 10 2006 17:40:46
Author id: jeff     lines deleted/added/moved: 0/7/0
added login screen
Resolution for 1: baseline
-----------------------------------
Rev 1.0
Checked in:     Oct 10 2006 13:37:44
Last modified:  Sep 27 2006 16:48:04
Author id: jeff     lines deleted/added/moved: 0/0/0
creation of web project
===================================

The first line of the file (and first line of text after any line containing only equal signs, ====) provides the full path to the file, however you need to strip the -arc at the end and also take out the archives\ directory. Since we want revision information, the next step is to skip ahead to the first line of dashes. After each dashed line we can read the revision number that appears after "Rev". In my parser I also parsed out check-in date, author ID, etc., but we only need revision numbers to retrieve a particular revision from VM. Also note that revisions are listed in reverse check-in order, so the latest revision comes first. When reading the revision information, either place this into a Stack (which you can then convert to an array via ToArray(), which will then be in the order you want) or process a List in reverse order. Again, each file is separated by a line of equal signs, so when you hit this line you know to stop processing the current file.

Now that we have all files in our repository and all revision information for each file, we have to construct a call to PCLI to retrieve a particular revision. This is the part that is ridiculously slow and sets off my internal alarms that scream THERE IS A BETTER WAY TO DO THIS! I just didn't dig in deep enough to find out the better way and I couldn't be bothered to do so now.

The command to retrieve a particular revision of a file is: pcli.exe run -y -ns get -id USERNAME:PASSWORD -o -a"c:\local\path\here" -wREV# -pr"PROJECTNAME" PATHNAME

"run" is the command, which we use to execute a specific PCLI command which, in this case, is "get"

The -y and -ns options stand alone, -y specifying that all prompts should be answered "yes" (I ran this from a C# program and did not want any user interaction) and -ns prevents extra stripping of quotes from command line.

The -id option is used again to specify credentials.

The -o option is used to override work file location so we can pull the file down to a directory of our choosing without needing to deal with work file locations.

The -a option is used to specify where the retrieved file should go.

The -w option specifies which revision number we want, such as -w1.0

The -pr option is used to specify the project and should be in the same format as our previous invocation of PCLI, for example, \\SampleProject

Now we have all the pieces to get a full list of files/revision history from VM and automatically retrieve a particular revision of a file. You can write a program to automatically invoke PCLI to create the revision history file, parse that file and pull down revisions one by one. I would suggest first processing all 1.0 revisions of all files within a particular root folder and then using Team Foundation Server's source control API to add these files. Then process all 1.1 revisions, checking these into Team Foundation server. And so on... Along with your check ins to TFS you can include original information such as author ID, check in comments, check in date, etc., so you can maintain a reasonable degree of information, hopefully alleviating the need to keep VM around for historical purposes. I'm leaving out details of the TFS source control API since it is documented well in many other places, but if you would like some suggestions or help, please leave a comment.

I'm almost ashamed to document such a clunky method of export/import, but without devoting significantly more time to exploring PCLI and various VM interfaces, this method was the best I found that I knew would work. There are (at least) two ways to improve on what I discussed, but I did not figure out how to do either. First, I believe there is a way to do batch operations with PCLI so you don't need to pull down a single revision at a time. Second, I came across a client API, but did not readily see how to do authentication so I was not sure how to properly connect to a repository and perform the calls needed.

I really hope this helps someone out there :)

I'm exploring some new technology by revisiting some old technology. I make no promise to the frequency of posts, but before delving into the specifics of what I'm attempting, some background information is necessary.

The old technology I'm looking at is something that was developed on DOS in the early 1990s. It used the standard 80x25 text mode in order to show various colored characters. The characters came from the 8-bit extended ASCII table. If my memory doesn't fail me, the standard ASCII table is 7-bits, which means it stores characters from index 0 to 127 (2⁷ - 1) for a total of 128 characters. The 8-bit extended ASCII table provides for 256 characters, from index 0 to 255 (2⁸ - 1). However, the first 32 characters are known as "non-printable." Although most have some graphical repesentation behind them, they are control characters meant to signal the printer or DOS to do something such as beep or insert a tab or go to the next line. These first 32 characters are listed below.

I'm listing these mostly for curiousity's sake (these are cribbed from http://www.asciitable.com). Characters 1 through 26 also correspond to Ctrl-A through Ctrl-Z (sometimes seen as ^A or ^G, the caret representing the Ctrl key). Even in modern programming we still encounter some of these characters, most significantly tab, carriage return and newline, which we know as \t, \r and \n in C# and other high level languages. The carriage return was used to make the cursor (and I'm fairly sure some printer heads, dating back to typewriters) go to the beginning of the current line, and then newline was used to advance the cursor to the next line. This is why seeing "\r\n" is common on Windows. The next character, 32, is the space, and this is where the printable area of the ASCII table starts. Interestingly, the control characters all have a symbol behind them (except for 0, which is empty but is treated as distinct from the space, character 32. The index into the ASCII table is what matters, not how it looks). Character 1, for example, is a hollow happy face, and character 2 is a filled in happy face. Each character in the ASCII table is made up of 8x16 pixels. Since the DOS text mode I'm looking at here is 80 characters across and 25 down, this gives us 80*8 x 25*16 pixels, or 640x400 for the video mode resolution. This character set, even the non-printable range, can be drawn to the screen on DOS. Each character can also have a foreground and background color.

DOS supports coloring of characters based on two hex values combined to form foreground and background. An alternate way to color on DOS is using ANSI escape sequences, but we aren't concerned with ANSI escape sequences here. If, right now, you open a command window (Win-R, type "cmd" and enter) and then type "color /?" at the prompt, you'll get a list of colors that correspond to each hex value. The colors Aqua/Cyan are the same, and Purple/Magenta are the same, incase you encounter these variant names somewhere. The "color" command uses "Aqua" and "Purple" but for what I'm working on, we will use its terminology, "Cyan" and "Purple." Also, different from the color command, there is no dark yellow (it's brown) or bright yellow (it's simply yellow). The full list of colors are listed next.

It isn't essential to know how these colors are used when printing a character, other than the fact that the color information can be stored in a single byte, where the upper nibble is the foreground color and the lower nibble is the background color. Thus E9 is yellow text on a bright blue background. The color command places the background color first, so if you want to try to change your command window colors, type "color 9E" for yellow on bright blue.

The next goal is to ensure we have the full set of ASCII characters (all 256) and the proper colors (we can use an eye dropper from a Paint tool to get exact RGB from a command window), all formatted for the presentation framework I intend to use. This is what will come next, and shortly after, an introduction of exactly what I'm attempting to create.