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.

It is easy to lose sight of the computer itself as an average programmer. Managed environments such as Java and .NET present programmers with an execution environment that makes their job easier. One of the most significant advantages of a managed platform over certain other languages (such as C++) is automatic memory management. Many programmers can slide by without knowing how the operating system manages memory, let alone how Java and .NET handle it. Programmer productivity is a great thing but in order to become a programmer that isn't just sliding by, getting the job done but not able to tackle certain classes of problems, one important area to study is how the underlying system works.

In the interest of peeking behind the curtain that is the computer, let's start with a short review of computer architecture.

The classic components of a computer are input, output, memory, and the processor (which is made of a control portion and a datapath portion).

The memory contains the programs that run on your computer and the data those programs need. We'll call this main memory since it is what is commonly known as "memory" in a computer. Physically, this is the memory chips that plug into your motherboard. You may have anywhere from 512 MB to several gigabytes of memory. However, the memory section of this big picture can apply to any form of memory storage.

The processor (aka the CPU, central processing unit) executes what are called instructions that are stored in memory. The control section of the CPU tells the datapath section what to do, such as add two numbers and store the result in a certain location in main memory. Processors also have a cache, which is memory closer to the processor, and thus is faster than main memory. We will get into the importance and opreation of a cache at a later date.

Programs are typically stored on a different type of memory, the hard disk. The CPU controls access to this device, transferring information from it to main memory. This is a function of the INPUT part of the computer.

The OUTPUT part of the computer is responsible for reading data from main memory.

Keep in mind that INPUT and OUTPUT are relative to the main memory, so input is data flowing to main memory, and output is data flowing from main memory. Any communication to and from the processor takes time. This is why cache is useful since communication is faster. Understanding how communication of data works in a computer gives you the information necessary to write algorithms that utilize memory better.

The processor executes instructions which might be familiar to you as assembly language or Java byte code or MSIL (Microsoft Intermediate Language) on .NET. These instructions are as close to the executing machine as possible while still being human readable. The processor sees these instructions as just a series of numbers, numbers that only have meaning to a specific processor and comprise its instruction set.

When you write a program in a high level language such as C++ (or C# or Java, among many others), what you write is translated into these intermediate instructions, part way between high human readability (C#) and low human readability (just numbers). Assembly language is known as a low level language because it is closer to the machine. A compiler is just a translator, taking code you can read and translating it to the numbers that comprise the instruction set of a processor. Output of .NET compilers on Windows is a DLL or an executable, same as C++ on Windows, all of which contain instructions for a machine, be it real or virtual.

I am over simplifying to some degree as there are many nuances to computer architecture and compilers, but this is a good big picture view. One of the most important concepts to understand is how memory is organized and how it works. Specifically, how it is used by both the operating system and a managed environment such as the CLR (common language runtime) on .NET. That will be addressed in a future entry.

Just because your assemblies are GAC'ed does not mean that they automatically appear in the .NET tab of "Add Reference" in Visual Studio 2003/2005. You can make your assemblies appear here by a registry tweak. First, decide which directory you want to store your assemblies. For example, say your projects copy the built assemblies to d:\build\output

Open the registry editor and navigate to the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders

Create a new key beneath AssemblyFolders. The name is arbitrary, so give it a name that applies to the assemblies in the directory, perhaps "INITECH UI 1.0" Next, single click this new key, and in the right pane you'll see (Default) with no value. Set the default value to your directory, d:\build\output

Here's a screenshot of what this looks like for the already-present "SQL Server Assemblies" on my machine.

Also note that this can be set on a per-user basis by performing the same action in the HKCU hive, specifically HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders

If you want multiple directories, create multiple keys.

[Add standard registry disclaimer here] Back up your registry before making changes if you're not used to editing the registry directly.

There are a wide variety of software tools that I use regularly in software development. I will semi-regularly introduce a tool that I actively use in a series called "Focus on Tools." Some tools are complex enough that I will go into deeper detail over time, showing various scenarios where certain aspects of a tool are best used. Obviously, to those already in-the-know, these tool introductions will be old news. But to those not in-the-know, learning about these tools can save you significant time. For example, the catch all solution to problems on a Windows system is "reboot Windows." I'll grant that sometimes this is necessary, but in many cases it isn't, and a reboot is costly time wise. I see this as burning down the house in order to kill a single rat. Effective? Yes. Overkill? You tell me.

Someone recommended rebooting recently when a piece of software wasn't working. In reality a registry setting by the application was incorrect. I've encountered other cases where resources are locked, such as a file or a DLL, and though rebooting would free this locked resource, it's much easier if you can find the source of the lock and then properly address it. Finding problems along these lines in the software we develop is vitally important. In the case of the registry setting that was wrong, I used a tool from http://www.sysinternals.com to monitor registry access. For general resource issues, I use Process Explorer from the same site. I'll introduce both these tools in their own entries soon.

There are many aspects of our job that tools help speed up, many cases where tools get us the information we need. Hopefully you'll find something you didn't know about here.

In my current life I'm a consultant contributing to design and development of software for a health care company. At the moment my work consists primarily of ASP.NET 2.0 and SQL Server 2005, though plenty of other technology is involved (Oracle; .NET 1.1; etc.). I'm also currently in charge of evaluating and demonstrating Visual Studio Team System internally. This gives you an idea of topics you'll see on this blog. I enjoy digging deep into technology so expect some material not covered often by others.

I started on .NET 1.0 when it was in pre-release, before it had any IDE support. I knew it would soon be big and I managed to get a couple articles published in Software Development magazine, but I foolishly did not keep up the publishing momentum, something I hope to rectify. Unfortunately the company I was at took a major financial hit and let roughly 80% of the company go. For my next job, I wound up in the Java world, taking the position to maintain a paycheck. After coming to grips with reality in a post-.COM era, this company downsized and although they kept me on, I soon decided to leave. I was a bit disillusioned with the software world and took some time off. I jumped back in eventually, again in a Java shop, working for a government contractor. Around this time I was given an opportunity to contribute to a Java book, Professional Java Programming with JDK 5, a book that is highly regarded based on feedback at amazon.com. We just finished the next edition of the book, Professional Java Programming with JDK 6, which should be in bookstores early 2007.

So I was a Java developer in my previous life, sandwiched between the Microsoft work of the past (VS 6, MFC, COM, a dash of .NET) and the Microsoft work of the present (mostly .NET, but I jump at a chance to do C++). I'm ecstatic to have the position I do now, getting to use Microsoft technology and truly utilize my skills. I'm passionate about software development - both getting down and dirty and spending late nights hacking, and also reeling in this inclination and focusing on the users of the software, the customer and what makes good business sense.

This is primarily a Microsoft blog, however if Java or other technologies make a guest appearance, don't be surprised. If you are a reader of either PJP book or in general have suggestions for topics or questions, please e-mail me at suggestions AT artofcoding DOT net. For all other correspondence please e-mail me at jeff AT artofcoding DOT net.

Thank you, and welcome!

P.S. The pun in the domain name is both intentional and serendipitous because the domain name was available.

P.P.S. I do ask that conversation in comments stay civil. No flame wars please. I have no desire to censor comments, but any comment I consider excessively harsh will be deleted without notice.