David's Blog

Windows/DOS has had a *bad* command shell for a long time…but that is about to change with the October 22nd release of Windows 7.

Windows 7 ships with PowerShell 2.0…and it is *really* good.

PowerShell 2.0 features:

• Unlimited output buffer (command prompt had 300 lines by default, and a max of 9999)
• Easy text selection (command prompt could only do “screen space” selection, which made selecting multi-line text virtually impossible…no more!)
• Aliases for standard Unix shell commands (pwd, cp, man, rm, rmdir, mv, ls, cat, grep, ps, kill, tee, clear)
• Aliases for standard cmd.exe commands (cd, cls, copy, help, del, rmdir, rename, dir, type, find, findstr, tlist)
• Support for paths with either forward or backward slashes
• Support for network resources *without* mapping a drive (i.e. can do this: cd \\share\mypics)
• All commands follow a consistent verb-noun naming convention (get-childitem, write-output, etc.) which makes the commands self descriptive and easy to learn
• Can use standard file system commands (cd, dir, rm, cp, etc.) on…
• The Registry
• Environment Variables
• Variables
• Aliases
• User supplied custom data
• Command and parameter tab completion
• Really good documentation, with examples via get-help (or help/man)
• Script debugger with support for breakpoints, stepping, call stack, and hover over variables to see values
• Commands are chained together via *objects* instead of text. Nice example of this powerful feature here.
• Can output your results in rich text format to out-gridview. I *love* this feature. Read about it here.
• Supported on Linux/Mac via Pash

Here is a nice table that compares all the different shells and their features. PowerShell comes out as the most advanced shell.

Windows 7 marks the first time Windows has had a better default shell than Linux or Mac.

Other Linux advantages that are no more with Windows 7:

• Windows 7 has support for symbolic links (actually added in Vista).
• Excellent free C++ compiler via Visual C++ Express

Posted on October 11, 2009 11:58 PM | Permalink| Comments (0)

PowerShell is a replacement for the Windows command prompt (a.k.a. CMD).

I ran into this feature today: accessing network shares.

With CMD, you map a drive letter to a network share in order to access it. Trying to access the share directly (via the UNC name) does not work.

For example, here's what happens if I try to list the contents of a share called \\ivory\users\public directly (fails) and then via a mapped drive S: using CMD...

PowerShell supports UNC! No more mapping drive letters!

Check out the same task via PowerShell...

Posted on July 2, 2009 12:15 AM | Permalink| Comments (0)

I am reading this document about the C# language.

Here are a list of features in C# that improve on how C++ works…

Technorati Tags: C#,C++,Programming

Posted on May 12, 2009 8:35 PM | Permalink| Comments (8)

I have been an OpenGL developer for more than 10 years. OpenGL was *the* 3D API for computer graphics since 1992…but not anymore. Direct3D has left OpenGL in the dust…and this is a big deal.

It has been clear for several years that OpenGL is struggling to keep up with Direct3D and every year the gap gets wider. This article does a great job detailing OpenGL’s problems.

If your OpenGL app competes with a Direct3D one…you need to be worried. It is not a fair fight. Direct3D is pushing the envelope for hardware features, which means a Direct3D app can run faster or look better than an OpenGL app on equivalent hardware.

Currently, managing shaders in OpenGL and Direct3D is painful. The next version of Direct3D (DirectX 11) dramatically improves how you combine small shaders into into larger, more complex shaders. This change alone will make OpenGL seem antiquated from a developer’s point of view.

OpenGL is the only cross-platform 3D API. As OpenGL falls further and further behind Direct3D, you’ll see less 3D apps on platforms that depend on OpenGL (like Linux and Apple Mac’s).

In the beginning, SGI was pushing OpenGL…until they got out of the graphics business. Then 3DLabs pushed OpenGL to create its shading language (GLSL)…until they got out of the graphics business.

Who is pushing OpenGL now? Nvidia? ATI? Both of those companies have more interest in Direct3D than they do OpenGL.

Without a major corporate sponsor, I don’t see how OpenGL will carry on. I’m actually surprised Apple hasn’t been a bigger supporter of OpenGL considering how important it is to them.

It was fun while it lasted…we’ll miss ya.

Technorati Tags: OpenGL, Direct3D, DirectX 11

Posted on December 16, 2008 11:33 PM | Permalink| Comments (6)

I recently finished reading “Designing Interfaces” by Jenifer Tidwell.

I think of this book as “Design Patterns” for user interfaces.

If this book was required reading for everybody that builds software, we’d have *much* better software and happier users. It has really changed how I approach creating user interfaces.

Before reading this book, I could point to an application and tell you if it looks professional and polished or not. Now I can tell you why.

This book deals with many subtleties and attention to detail that can have a huge impact on the user’s impression of your software.

Here is an example pattern, “Center Stage”…

A “preview” of the book is available online (with large chunks missing so you still need to buy it) here.

Highly recommended!

Technorati Tags: Designing Interfaces, Jenifer Tidwell, User Interface, Review, Software Development

Posted on December 14, 2008 11:58 AM | Permalink| Comments (5)

One common complaint about the winsxs folder is that it takes up too much space.

My winsxs takes up almost 9 GB!

Or does it?

According to this post by Microsoft, WinSxS has many duplicated files. The files are are *not* copies, but are instead “hard links” that point to the same data, and thus do not take up any extra space. Microsoft says a typical WinSxS folder contains around 400 MB of data.

The problem is that DIR and Explorer are not aware of the difference between an actual file and a hard link to a file. The disk usage reported by these two programs is as if each hard link *is* an actual file.

I did my own test to verify Microsoft’s claim. I created a small file called “original.txt” that uses 10 bytes. Then I created 10 hard links to the original file via the command line:

mklink /h hardlink<NUM>.txt original.txt

As expected, both DIR and explorer report that I’m using 110 bytes instead of just the 10 bytes of the original file:

Symbolic links, on the other hand, work as expected and are recognized by both DIR and explorer.

I created symbolic links using this command line:

mklink symboliclink<NUM>.txt original.txt

Here are the results of DIR:

Notice that only the original file reports any disk usage. The total directory size is only the original file, even though 11 files are detected. Also note that all the symbolic links are listed as “<SYMLINK>” and have a reference to the source of the symbolic link in []’s.

Here is what explorer looks like with symbolic links:

Explorer does the right thing and lists that the directory only contains 10 bytes. The symbolic links have “shortcut” indictors on top of the source icon. The file size for symbolic links are listed as 0 KB.

Technorati Tags: WinSxS, Windows, Symbolic Link, Hard Link, mklink

Posted on November 28, 2008 5:35 PM | Permalink| Comments (6)

Stackoverflow is an interesting new (still in beta) website for programmers.

You ask programmer-related questions and the community answers. No registration is required. Better answers get more votes and move to the top of the list. More about how it works here.

I tried it last night with this post...

Locking Executing Files: Windows does, Linux doesn’t. Why?

I got some decent answers from the Linux-side about how Linux works without locking a file. However, I *really* want to know why *Windows* locks files. Do you get better performance with locked files? It seems like there has to be a reason...but I still don't know it.

In any case, stackoverflow is a site I plan on using for casual reading about programming topics and to help out when I get stuck or want the opinion of the programming community. Recommended.

Posted on October 13, 2008 10:24 PM | Permalink| Comments (0)

My current hobby project (I always have some project that I'm working on that I never finish) is using Visual C# 2008 (free download) and Windows Presentation Foundation (WPF) to make an application with a slick, non-traditional User Interface (UI).

I'm using this project to learn about technology I think will have future importance.

So far I'm *very* impressed with C#. I've been doing C++ work since 1991 (Borland C++ 3.0). C# is a refreshing change, yet maintains enough similarities that it is easy for a C++ programmer to pick up with very little training.

WPF is the new UI API for Windows. It replaces the Win32 API, MFC, and Window Forms.

One of the features of WPF is that the fonts look perfect, no matter how much you magnify them. You can see this for yourself by using the magnifier tool (Start->Search->Magnifier).

To demonstrate, I created a sample WPF app in C# that displays some text...

Here is what my sample app looks like hovering near the task bar...

Here is what the same area looks like when I use 16x zoom with the magnifier (you'll have to click on the image to see it really zoomed in...it's too big to fit here):

Notice how sharp the WPF text is compared to the pixelated task bar. Very cool! This means apps can scale to any size monitor and still look perfect.

Using the magnifier, I've only found one application that uses WPF: Visual Studio 2008. And it only uses WPF in one place: the properties window for WPF elements. This is fairly new stuff...I expect it won't be long before you start seeing WPF-based apps.

Today I learned about another feature in WPF that I look forward to using: 2D on 3D. Basically, you can create standard 2D UI (buttons, scroll bars, sliders, etc.), but they can be mapped onto a 3D surface...and they still work!

It hard to explain, but this video really shows it off.

Daniel Lehenbauer and Kurt Berglund: Interactive 2D controls on WPF 3D Surfaces

I've downloaded the sample code from here. I plan on incorporating this into my project somehow.

This is fun stuff. When I have something worth showing, I'll post it.

Technorati Tags: WPF, C#, 3D

Posted on July 15, 2008 1:03 AM | Permalink| Comments (3)

The newest version of PowerShell came out a couple of weeks ago. You can get it here.

The command name tab completion now works (it didn't in CTP1) in the Graphical Windows PowerShell...which is the main reason I stayed away from CTP1.

There is a really cool new feature in CTP2's... Out-GridView.

Out-GridView takes console table data and displays it in a GUI that has these features:

• Search (lines that don't match are removed as you type)
• Sort by columns
• Group by columns
• Filtering

Here's what it looks like when I asked for a list of running services by typing "get-service | out-gridview"...

I like that *way* better than the traditional/non-interactive console output that looks like this...

Filtering is very helpful for getting to the data you want. Here it is in action:

I'm *really* excited about Graphical Windows PowerShell.

With this release, I'm going to start using it as my standard shell on my home PC and once the final version comes out, I'll probably start using it at work. This is software that will make you more efficient the better you know how to use it. Start learning it now!

Highly recommended!

Technorati Tags: PowerShell

Posted on May 18, 2008 10:55 PM | Permalink| Comments (1)

Tracking down how an include file (.h) got into your project can be painful.

It's obvious if the include file is #include'ed by one of your files. It's less obvious when the include file is brought in by nested includes. Also, some include files are enclosed in #ifdef XXXX/#endif which requires knowledge of macro XXXX in order to determine if this code path is actually used.

There's a better way!

Go to...

Microsoft Visual Studio->Project->Properties...->Configuration Properties->C/C++->Advanced->Show Includes

Set this option to "Yes."

When you compile your files, the Output window will show you:

• Every include file
• The order include files are parsed
• The parent include file via indentation

For example, in the above Output window, stdafx.h brings in targetver.h and windows.h. Windows.h brings in sdkddver.h and excpt.h.

Here's what stdafx.h looks like for reference...

You don't want this option on all the time because it will really pollute your output window and slow things down with massive amounts of information.

This setting can also be helpful in determining what include files should be part of your precompiled headers.

Technorati Tags: Visual Studio, Visual C++, Include Files, showIncludes

Posted on March 23, 2008 11:01 AM | Permalink| Comments (0)

XML (eXtensible Markup Language) is a standard way of storing data. It became a W3C recommendation in 1998.

If you aren't on the XML bandwagon yet, you should be. XML is a good thing and it makes software better.

XML is confusing at first, but it is worth the time spent understanding it.

I found a great resource that explains XML concisely, quickly and with many examples.

Here is the section I read to understand the XML format (.xml files).

After that, I read this section about how to "design" an XML file format using XML schema (.xsd files).

In less than a day, I have learned a lot about XML. I highly recommend the above two links to anybody doing software development.

The next issue is how to author XML.

Visual Studio 2005 comes with really good XML tools. Here's more info on what Visual Studio can do with XML.

I use Visual Studio 2005, but some of the people using the software I'm writing may not. I needed a free XML editor for these people.

I looked around and tried out several free XML editors. Many of them did not support .xsd files (which ensure the XML data is in the format you expect).

I found out that Microsoft's *free* version of Visual Studio *does* include the XML tools! These tools are great for creating XML schema, authoring XML, among other things. I'm going to recommend anybody that needs to edit/author XML use Visual Studio C# Express Edition or Visual Studio C++ Express Edition if they don't already have Visual Studio.

Technorati Tags: XML, XSD, XML Schema

Posted on March 1, 2008 3:41 PM | Permalink| Comments (2)

Optimizing DirectX Rendering on Multi-Core Hardware

I didn't get much out of this that I hadn't already heard before.

They presented some profiling for some games that showed 50% of CPU time was spent on graphics related tasks.

They gave a list of tools that are helpful for profiling:

• Intel's VTune Performance Analyzer
• Intel's Thread Profiler
• Microsoft's PIX for Windows
• AMD's CodeAnalyst

Some of the talk was about the benefit of multiple cores verses the overhead required to synchronize multiple cores.

Expo

Sandbox2 editor for CryENGINE by Crytek

• Best/slickest game editor I've ever seen
• An editor built on top of the game engine
• Everything is WYSIWYG
• Artists can get great results very quickly
• Realtime Shadows
• Realtime Ambient Occlusion

Check out these demo videos of Sandbox2 in action...

Intel VTune

• Only works on Intel processors (surprise!)

Mono

• Allows C# code to run on Linux, Mac
• Have a validator that examines C# code for compatibility with Mono called MoMA
• Mono supports most of .NET framework 2.0

IGF Pavilion

There were some "indy" games that caught my eye...

World Of Goo

The Misadventures of P.B. Winterbottom

FLIPSIDE

Crayon Physics Deluxe

Pleo

Pleo is a dinosaur-robot made by UGOBE. What are they doing at GDC? They wanted people to know that Pleo is a "platform"...you can program new behaviors and applications for Pleo (via an SD card) and they are reaching out for people to add to its abilities. Check it out in action here:

Technical Issues in Tools Development (Day 1)

This was my favorite talk of the day.

It was a round table hosted by John Walker from High Voltage Software. John was the moderator. He started by asking for a few topics people would like to cover. Then he would ask some questions concerning a topic and let people in the room answer. Some people used this as an opportunity to say, "Has anybody in the room tried to do X? How did it work for you?" It was very informative.

There is another one Thursday and Friday, so I may go to those as well since the conversation will be different because different people will be there.

Some of the things I picked up...

• An artist complained about data-driven tools being great for programmers, but terrible for artists. He wanted more custom GUI work.
• Someone mentioned using XGE (Xoreax Grid Engine) to speed up their tools.
• We have debug and release builds of code, why not data? The debug data could contain information about where the data came from so that a crash because of bad data could be quickly resolved.
• Artists and Programmers need better communications
  • For artists, programmers should do video captures with audio explaining how to use a tool
  • For programmers, artists should do video captures with audio showing how they *actually* use a tool
• Artists were pleading for tools to use standard formats as much as possible, it makes their lives much easier
• A company should standardize on a set of icons so their tools look and feel the same
• When planning the UI, consider what the artist already knows and is familiar with. Maya? Max?
• Involve Artists in UI design
• A new, untested concept: decoupling the UI from the code, like the WPF (Windows Presentation Foundation) model in Vista. This lets an artist build the UI independently of the code behind it. No one had done it yet, but there was much interest.

Stupid Spherical Harmonics Tricks

What I learned here...was that I need to learn a lot more about spherical harmonics (SH).

The DXSDK has several samples involving SH.

The presenter has a couple of papers on the subject (here and here).

Creating Havok with Destruction

Havok announced a new product, Havok Destruction.

• Coming out mid-2008
• Features fracturing and deformation
• Artists draw how and object can be destroyed (where cracks will be)
  • Deterministic
  • Art driven
• Use "connectivity" to determine how much of an object breaks
  • No connectivity - object breaks along every crack
  • With connectivity - object can break along crack in close proximity to collision
• Deformation
  • Throwing cannon balls at barrels that dent instead of crack
• Direct competitor to DMM

Technorati Tags: Game Developers Conference, GDC

Posted on February 20, 2008 11:40 PM | Permalink| Comments (0)

I'll be going to GDC next week. GDC is the convention for video game developers. It is here in San Francisco at the Moscone Center.

Not sure what I'm attending yet, but I'll probably be there Wednesday through Friday.

GDC is not as fun as SIGGRAPH, but you can learn a lot. The focus is on interactive 3D graphics and techniques you can use today to speed up or improve the look of your graphics.

Looking forward to it!

Technorati Tags: Game Developers Conference

Posted on February 16, 2008 6:52 PM | Permalink| Comments (1)

The C/C++ runtime library contains basic functions like memory allocation (malloc, new), output (printf), and string manipulation (strcpy, strlen).

When building a C/C++ application or library, you must pick a C/C++ runtime library. In Visual Studio 2005, you can select this option using Project->Properties...->Configuration Properties->C/C++->Code Generation->Runtime Library:

You have 4 versions:

1. Multi-threaded (/MT)
2. Multi-threaded Debug (/MTd)
3. Multi-threaded DLL (/MD)
4. Multi-threaded DLL Debug (/MDd)

The C++ runtime library is dependent on the C runtime library. The C runtime library version must match the C++ runtime library version.  Thus, these options apply to both the C and C++ runtime libraries.

In previous versions of Visual Studio, you had additional options that were single-threaded. These versions would execute faster on a single core than the multi-threaded versions. However, they were not safe to use in a multi-threaded application. I'm guessing these libraries were dropped since multiple cores are quickly becoming ubiquitous and multi-threaded applications are needed to take advantage of these extra cores.

These four choices are all the permutations from two variables:

• Debug vs. Release
• DLL vs. Static Library

The first variable is easy. Use Debug on internal software that is not shipped to customers. The debug runtime library *can't* be included with your application legally. Just to be clear, you *can* ship a debug version of your application to a customer, but it should use the *release* version of the runtime library.

The Debug runtime library gives you access to some helpful debugging aids for error reporting and tracking down memory leaks. See the additional debug functionality you get with this version of the runtime library (and macro _DEBUG defined) here.

The next variable is DLL or Static Library. In general, you should use DLL. You might consider the Static Library version if:

• You have a small application and you don't want to waste memory with runtime library calls you don't need
• You want a simple application that is not dependent on shipping with an additional runtime library DLL.

The above instructions work well if your application doesn't use any other libraries. That rarely happens. Microsoft has several vague warnings in their documentation about using more than one version of runtime in an application.

The goal is to use one runtime library throughout your entire application.

That is nearly impossible since you typically don't have control of which runtime library other libraries use. For example, OpenGL uses the runtime library. If your application or any other libraries you use don't use the same runtime library as OpenGL, then you are mixing runtime libraries.

How do you know what runtime library a .EXE, .DLL or shared library (.LIB), or .OBJ use? Use this command line:

dumpbin /all XXXX | find /i "msvcr"

...and replace XXXX with the .EXE, .DLL, .LIB (for static libraries...not the stub for .DLL's), or .OBJ in question. You should get something similar to this:

You can use the results from this command with this page to see which runtime library you should use.

If you don't get any output, then it likely means that a static runtime library is used.

Even with information about what runtime libraries are in use, you may find it impossible to make your application use a single runtime library. If you match the runtime libraries, it is possible that one library uses the Visual Studio 7.0 version of the runtime library (msvcr70.dll) but you only have access to Visual Studio 8.0 (msvcr80.dll).

So now what?

It turns out is is OK to mix runtime libraries *except* in certain cases. A well written library should avoid these cases and then it doesn't matter if the runtime libraries match. Libraries that cannot avoid these cases should ship with 4 versions of their libraries that match the 4 versions of the runtime libraries.

Here is a good article with examples of situations to avoid so that you don't have to worry about mixing runtime libraries.

Choosing a runtime library summary...

• Use the debug version only internally, release for anything that could be used by customers
• Use the DLL version except in special situations
• Use consistent settings throughout your project (the runtime library setting can be done per source file)
• Don't worry if your runtime library settings match other libraries you use (unless the library comes in multiple runtime library versions)

Technorati Tags: Runtime Library, C, C++, Mixing

Posted on January 12, 2008 2:50 PM | Permalink| Comments (15)

Linux/Unix (and Mac since OS X) have always had much better shells than Windows. But that is about to change.

Windows PowerShell 2.0 looks very impressive. It should make the Linux/Mac/Unix world scramble to come up with something that matches the features of PowerShell 2.0.

The feature I'm most excited about is called the "Graphical PowerShell." It is pictured above and replaces the pathetic "Command Prompt"...

You can see from the top picture that the Graphical PowerShell is broken into three parts.

1. The top part is used to store scripts. It has syntax highlighting and debugging (set breakpoints).
2. The middle section is output from the above scripts or from the interactive console.
3. The bottom section is what most shells look like. This is where you can interactively type in commands.

One of the things that drove me *nuts* about Windows' Command Prompt was that you could not select a multi-line command. Selection worked in screen space, which is terrible!

For example, below I wrote a command that I want to copy. Because selection is in screen space, the best I can select is 'more *.cpp | find' instead of the whole command 'more *.cpp | find "include"'.

Graphical PowerShell doesn't have this problem. You can select by line now (finally!)...

You can also resize the window which doesn't work very well with Command Prompt.

The PowerShell command language itself is well thought out and very consistent. All commands are made up of verb-noun pairs like Set-Location, Copy-Item, Write-Output, etc. (with aliases that work as shortcuts). It looks to be very competitive with all the other shells out there in terms of shell features.

Passing data between commands in Unix/Mac/Linux involves sending text from one to command to another (like "more junk.txt | grep lenihan"). PowerShell passes *objects* between commands.

This article shows a quick example of the power of passing objects instead of just text. A list of directories is passed to a move command. If this were done with text, the text would need to be formatted in such a way that the move command would recognized the text as file names (like removing the date information). PowerShell already knows what type an object is so you can skip any of this formatting! Very nice!

PowerShell 1.0 is out now. It still uses the old Command Prompt for input/output. The Graphical PowerShell (replacement for Command Prompt) is part of PowerShell 2.0, which is available in alpha right now.

I can't wait for PowerShell to replace the Command Prompt in Windows!

Technorati Tags: PowerShell, Command Prompt, Windows

Posted on January 8, 2008 11:15 PM | Permalink| Comments (1)

I love natural user interfaces like this...very cool.

Technorati Tags: User Interface, Crayon Physics, Tablet PC

Posted on November 20, 2007 9:47 PM | Permalink| Comments (2)

I love studying well done/efficient UI's. Here are some great articles on UI I recently read:

• Visualizing Fitts's Law
• Bruce Tognazzini's quiz on Fitts's Law
• Bruce Tognazzini's "First Principles of Interaction Design"

Technorati Tags: Fitts's Law, Bruce Tognazzini, Tog, UI, User Interface

Posted on October 19, 2007 1:29 AM | Permalink| Comments (1)

Just learned about this one today.

Windows Vista supports both hard links and symbolic links. The command line option to do this is called "mklink." It doesn't appear that the GUI (explorer) supports creating symbolic/hard links. Once they are created, the GUI can modify and delete the symbolic/hard links.

A symbolic/hard link is similar to a Windows shortcut, but more powerful. A symbolic/hard link acts just like the file/directory it points to. If you are writing an application that will open a file, you don't a have to do anything special to read a symbolic/hard link...just read the file normally. A shortcut is just a text file with information about the file/directory it points to. In Windows, shortcuts work effectively as symbolic links. From the command line, they don't.

For example, you have a text file named "happy.txt" with a shortcut called "happy.txt - Shortcut.lnk" If you double-click on the shortcut, Windows will open happy.txt as you would expect. From the command line, type "more happy.txt - Shortcut.lnk" and you will see the contents of the shortcut and not the contents of original file happy.txt. If you tried the same thing with a hard/symbolic link, you would get the contents of happy.txt in each case.

Probably not that interesting to Windows users, but *very* interesting to people bringing software over from the UNIX world where symbolic/hard links are commonly used. Now that it is a standard part of the console on Windows, I would expect more people (especially software developers) to start using it.

This article has a couple of nice pictures that describes the difference between hard links and symbolic links. Basically, a hard link points directly at the data and a symbolic link points at the filename that points at the data. It's a subtle difference. This website does a nice job of comparing the two types of links. A symbolic link can exist when the data has been removed, a hard link can't. You can use a symbolic link on your hard drive to point to a file on your USB flash drive. If you remove the USB flash drive, the symbolic link will point to nothing until you return the USB flash drive. You can't make a hard link from your hard drive to a USB flash drive.

Windows has actually had hard link support since Windows 2000, but it was only available through an API call (CreateHardLink), had no command line option, and it only worked on NTFS. Back in 2000, most systems used FAT, so hard links were of little value.

Technorati Tags: Windows, Vista, Hard Link, Symbolic Link, Shortcut, mklink

Posted on September 19, 2007 10:34 PM | Permalink| Comments (0)

I spend much of my time editing text in Visual Studio. I love their text editor...but Visual Studio is too big to load just to edit an occasional text file. For that, I use Notepad or Wordpad.

I ran into an issue where I needed to look at a specific line number in a text file. Visual Studio lets you jump to a line number, but Notepad/Wordpad don't.

I could load Visual Studio and then jump to the line number...but I decided to look for a Notepad replacement...and I found a great one!

It's called Notepad++. It is *exactly* what I was looking for...a free editor that gives you all the functionality of Visual Studio in a text editor that loads very quickly.

Things that I like about Notepad++:

• Line numbers/go to line number
• Free
• Quick to load
• Bookmarks
• Ctrl-F3 Search (searches for the word under the cursor without opening a dialog box)
• Uses the same keyboard shortcuts that Visual Studio uses
• Regular Expression Searches
• Tabbed Document Interface
• Syntax highlighting for C++, HTML, XML, Python, Lua, JavaScript, C# (and many others)
• Support for Windows, UNIX, and Mac line ending
• Macro recording/playback
• Plug-in Support
• Spell Check
• Alt-Left Mouse Button select (great for selecting a single column of text)

You can download Notepad++ (npp) here. I used npp.4.2.2.Installer.exe.

Highly recommended!

Technorati Tags: Notepad++, Wordpad, Notepad, Visual Studio, Review

Posted on September 9, 2007 12:05 PM | Permalink| Comments (6)

The Problem

At work, we recently upgraded to Visual C++ 2005 Service Pack 1 (SP1). At the same time, our application stopped working for some users.

Everybody that had SP1 was able to run the application. Some people *without* SP1 were also able to run the application.

My system (not SP1) could not run the application built by the newly upgraded SP1 build machines, so I tried to figure out why.  I used Dependency Walker to find out why my application would not load.

Dependency Walker showed that the C runtime library (msvcr80.dll) could not be found. I noticed the full path of where the application was trying to get msvcr80.dll was:

C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_
  8.0.50727.762_none_24c8a196583ff03b\msvcr80.dll

I searched my system and I *did* have msvcr80.dll in my \windows folder, but not in the path the application was using.

I had not seen a path like that before for a DLL. I had no idea why the application was looking there instead of in \Windows\system32 like it normally would.

I tried copying msvcr80.dll locally to the application folder and refreshed Dependency Walker. That had no effect...the application could not find msvcr80.dll.

That used be the failsafe way to make an application see a DLL...put it in the same directory as the application. Something was very different now.

The Cause

Something had changed. It was Microsoft's answer to DLL Hell that was introduced with Windows XP: side-by-side assemblies (winsxs).

Visual C++ 2005 is the first version of Visual C++ that uses side-by-side assemblies for the C/C++ runtime libraries.

The definition of an assembly is not straight forward. For the purposes of this discussion, I'm going to consider an assembly the collection of DLL's that make up the C runtime library.

Side-by-side assemblies changes where a DLL is stored for global access. Instead of using C:\Windows\System32, they are stored in the side-by-side directory, C:\Windows\winsxs.

The advantage of winsxs over system32 is that you can have more than one version of a particular DLL with the same name. With system32, you had to overwrite a DLL if you wanted to add a new version with the same name. Winsxs uses directories with version information to isolate DLL's from each other.

In the above picture I highlighted 4 directories. These 4 directories contain 4 versions of the C runtime DLL's. Each directory contains the same three C runtime DLL's:

• msvcr80.dll: C runtime library
• msvcm80.dll: C runtime library for managed code (i.e. .NET support)
• msvcp80.dll: C++ runtime library

All of these DLL's end in 80 because they are from Visual C++ 8.0 (a.k.a. Visual C++ 2005). The prefix is from MicroSoft Visual C (msvc).

The directory name is used when an application wants to load a particular version of the C runtime library. The directory name contains various pieces of information about the DLL's inside. Each piece of information is separated by an underscore. For example, consider this directory:

x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_
  8.0.50727.762_none_10b2f55f9bffb8f8

• x86 (processor architecture): Built for x86 (32-bit Intel Processor and compatibles)
• microsoft.vc80.crt (name): Microsoft Visual C 8.0 C RunTime
• 1fc8b3b9a1e18e3b (public key token): A unique ID for C Runtime
• 8.0.50727.762 (version): Version of the DLL's (right click on the DLL, select "Properties", and then the "Details" tab, and you should see this number)
• none (language): The language these DLL's are designed for
• 10b2f55f9bffb8f8: Not sure, but I assume this is a unique ID for this particular version of the DLL's

So how does an application know what version of a DLL it needs to load? That is where a "manifest" comes into play. A manifest is an XML file that contains information used to create the directory in C:\Windows\winsxs so that a particular DLL can be loaded. If you write an application that uses the C runtime library (99% of the time you will), then you are going to need a manifest.

Here is the manifest for an application designed to work with the above C runtime (auto-generated by Visual C++):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type="win32"
        name="Microsoft.VC80.CRT"
        version="8.0.50727.762"
        processorArchitecture="x86"
        publicKeyToken="1fc8b3b9a1e18e3b">
      </assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

The main line that is of interest is the "assemblyIdentity", which contains a "name", "version", "processorArchitecture," and a "publicKeyToken" like the above example winsxs directory.

There are two ways to store a manifest:

1. External .manifest file. The manifest file has the same name as the .DLL or .EXE, with ".manifest" added on to the end. For example, helloWorld.exe would have an external manifest called "helloWorld.exe.manifest." The manifest is located in the same directory as the .EXE or .DLL.
2. Embedded manifest. This is the default option for Visual C++ 2005. The XML file is store as a text resource in the .EXE or .DLL.

To chose an embedded assembly or external file, go to Visual C++ 2005 -> Project -> App Properties -> Configuration Properties -> Manifest Tool -> Input and Output -> Embed Manifest -> Yes or No.

Once an application is built, you may want to change which DLL's it is using. How do you change a manifest without rebuilding the application/DLL? For an external .manifest file, just edit the .manifest file and you are done.

Changing an embedded manifest is a bit more tricky. Here's what you do:

1. Create a text file that has the manifest in it that you want to use.
2. Select all the text and copy it to the clipboard (we'll use it later)
3. Visual C++ 2005 -> File -> Open -> File...
4. Select the .EXE or .DLL you want to modify and click "Open"
5. The manifest is stored in a resource called "RT_MANIFEST" with an ID of 1. Double-click the "1" to open it in an editor.
6. Ctrl-A to select all the text in the editor
7. Ctrl-V to overwrite the text with the text in the clipboard.
8. Ctrl-S to save the updated text in the .EXE/.DLL

The search order for DLL's has changed with winsxs. Now side-by-side directories (\windows\winsxs) are searched even before the local application directory. Here is an article about search order.

Since the winsxs directory is searched before the local application directory, it is impossible to override a .DLL in a winsxs directory, right? WRONG! This article shows how to do it. Basically, you just remove "public key token" from the application manifest and then create a manifest file for the DLL's you want to use (an assembly), like Microsoft.VC80.CRT.Manifest.

You may know the name of the DLL's you are interested in, but what is the assembly name for these DLL's? This page has a nice list of assemblies and the DLL's they point to.

I showed you earlier how to change a manifest without rebuilding an application. The next time you build the application, your manifest changes will be overwritten by Visual C++. To make your manifest changes permanent, you need to update the project settings so they are output every time you build your application.

To add information about an assembly to the application manifest...

1. Visual C++ 2005 -> Project -> App Properties -> Configuration Properties -> Linker -> Manifest File -> Additional Manifest Dependencies
2. In this text box, put the contents the <assemblyIdentity>, but leave out the <assemblyIdentity> open and close tags.
3. Replace all double quotes with single quotes
4. Enclose the entire line in double quotes

If I wanted to put the following into the auto-generated manifest file for an application...

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type="win32"
        name="Microsoft.VC80.CRT"
        version="8.0.50727.762"
        processorArchitecture="x86" >
      </assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

...then just put this line in "Additional Manifest Dependencies"...

"type='win32' name='Microsoft.VC80.CRT'
  version='8.0.50727.762' processorArchitecture='x86'" 

The Solution

So why were some people able to run the application even though they did not install SP1?

It appears that people that installed iTunes were able to run our application without SP1 installed. My theory is that version of iTunes was built against the SP1 C runtime and it installed the proper DLL in winsxs.

How did you get the application to work for people without SP1?

We decided to check to see what versions of the C runtime were available on a users system. If the version was older than the version our application was built against, we installed the SP1 C runtime libraries via the Microsoft Visual C++ 2005 Redistributable Package (x86).

• For Visual C++ 2005, use this
• For Visual C++ 2005 SP1, use this

Do you have to install the SP1 runtime in order to get an app built with SP1 to run?

That is certainly the preferred method, but you can also put the DLL's in the same directory as the app and bypass winsxs. One reason to not bypass winsxs is that if Microsoft pushes a fix for libraries that may have a security issue, you won't ever get the updates an your application will be left with the security holes.

We found another way that lets you work in the safety of winsxs on systems that may not have the same runtime libraries. Instead of using an explicit version of the C runtime (which requires that exact version present on your computer or else the application will crash on startup), there is a version that means "use the most recent compatible version of the C runtime". If we would have used this version in our application, it is likely that users would be able to run the application even if they don't have the SP1 C runtime library present. To get this "special" version, find the appropriate .manifest file in the C:\Windows\Winsxs\Manifests directory. Open this file and you will see a line with the XML tags "<bindingRedirect>". Basically, if you use a version in the range of "oldVersion", then the actual version that is loaded is given by "newVersion". I learned about this technique from this forum post.

In my case, versions 8.0.41204.256 through 8.0.50608.0 and 8.0.50727.42 through 8.0.50727.762 mapped to 8.0.50727.762. If you can find a version that always maps to a valid version via <bindingRedirect>, then use this version in your application's manifest and your app should work regardless of which versions of the DLL's are installed. You will need to check your user's machines to make sure they all redirect correctly in order for this method to work.

Conclusion

I knew *nothing* about winsxs (windows side-by-side) on Friday. It is a mess of complex topics that most people don't understand. There is a lot of information on the internet about winsxs, but it is spread all over the place and varies in degree of helpfulness. I'm certainly no expert, but I've learned a lot in the last couple of days.

Now that I understand the problem that winsxs is fixing, I can appreciate it, even if it is very messy and hard to understand.

The net result is applications will be more stable and reliable as more and more applications switch to winsxs. This is a good thing.

I wrote all this down mainly because I knew I'd forget about by the time I needed to address winsxs issues again. Hopefully this is helpful to others as well.

Technorati Tags: winsxs, Side-by-side assembly, Manifest, DLL Hell, C runtime, Visual C++ 2005, Dependency Walker, Embedded Manifest

Posted on July 24, 2007 1:45 AM | Permalink| Comments (43)

I ran across this today. It is subtle, but good to know.

An escape character (backslash '\') is handled in two ways in C++:

1. The C++ preprocessor ignores escape characters
2. The C++ compiler respects escape character

In Windows, the backslash has a dual use: it is used to separate files and directories and it is an escape character. This can lead to confusion.

So this line...

#include "c:\test\newfile.h"

...would treat the backslashes as file separators instead of the escape sequence "\t" and "\n" because it is parsed by the preprocessor.

This line...

system("type c:\\test\\newfile.h");

...requires two backslashes because it is handled by the C++ compiler. The "\\" is an escape sequence for a single backslash (a complete list of escape sequences is here). If you only used single backslashes, the "\t" would be treated as a tab and the "\n" would be treated as a newline.

Now, just to make it a bit more confusing, consider this...

#define COMMAND "type c:\\test\\newfile.h"

system( COMMAND );

...you have to use two slashes because the preprocessor will just replace 'system( COMMAND )' with 'system( "type c:\\test\\newfile.h" )', which will be processed by the C++ compiler and thus respects escape characters.

So...backslashes are always treated as escape characters EXCEPT when they are used by the preprocessor exclusively (i.e. the compiler never sees them) like the preprocessor directive '#include'.

The more you know!

Posted on June 6, 2007 1:03 AM | Permalink| Comments (3)

I saw this today and thought I'd pass it on. Microsoft is doing a special where they are giving away Visual Studio 2005 Standard Edition for free (normally $299). The catch? You have to watch a couple of Visual Basic videos. Click here to learn more about it.

My brother did a similar setup to get Microsoft Office 2007 for free, so I know this works and is not a trick.

Visual Studio 2005 Standard Edition comes with C++, C#, Visual Basic, and J#. Here is how the Standard Edition differs from other versions of Visual Studio.

I use Visual Studio 2005 at work and at home...highly recommended!

They are only giving away a limited number of the free Visual Studio 2005, so get it while you can.

Posted on May 17, 2007 9:26 PM | Permalink| Comments (1)

Gamedevmap.com helps answer this question. Just click a red dot on the map to get a list of game companies that call that area home. The site claims it stays current.

I love information like this. I just wish there was the same thing for every work discipline. Very helpful!

Posted on May 15, 2007 8:17 AM | Permalink| Comments (0)

XNA (which stands for "XNA is Not Acronymed") is a new moniker from Microsoft for tools to make video games for Windows and the Xbox 360. The tools are designed to make developing games easier and accessible to more people. This FAQ is helpful to understand what XNA is all about. The home page for XNA is here. 

About a week ago, Microsoft released a beta of the XNA Game Studio Express (GSE). I downloaded GSE this weekend to find out what it is about.

GSE appears to just be a plug-in to Visual C# Express (VCSE). Since GSE is a plug-in, it requires VCSE in order to install. After you install GSE and restart VCSE, everything looks the same. I had to do some digging to find out where exactly GSE "enhances" VCSE. I found 3 places:

1. Documentation. The help system has tutorials, a programming guide, and reference for XNA.
2. New XNA framework. This framework is built on top of the .NET framework. It adds the following libraries:
   • Application Model - game loop, how to pause/exit
   • Graphics - 2D, 3D
   • Math - vectors, matrices, collision detection
   • Input - read the mouse, keyboard, and Xbox 360 controller
   • Audio - associate sounds with events, like a gun shot when a player presses a button on the controller
   • Storage - generalizes where game data is read from and where game save data goes to so the same code will work on a 360 and a PC without modification
3. Templates. When you start a project in VCSE (File->New Project...), you are given some choices about what type of project you want to create (e.g. Windows Application, Console Application, Empty Project, etc.). GSE adds three more options: Windows Game, Windows Library, and Spacewar Starter Kit. The Spacewar Starter Kit is a rewrite of the classic Spacewar game using XNA. All the code is available so you can see how an actual game is using the XNA framework.

I followed a tutorial in the help called "Your First XNA Game." Basically you just create a project based on the "Windows Game" template, add some code to the update and draw functions, and you have quite possibly the worst video game of all time. To see for yourself, download this and extract it to a folder and run "shadowtest.exe." Granted, the point of the exercise is not to make a game, but to show you how to get started making a game, which it does well. It took me about 10 minutes to go through the tutorial.

Final thoughts...

• C# has a lot of buzz and is growing in importance in the game industry. I'm going to do my home programming projects in C# from now on.
• .NET/XNA can/will be used for video games. If you asked me about .NET use for video games 2 years ago, I would have said it is too slow. That appears to be changing.
• .NET/XNA development is more efficient than STL/OpenGL/OpenAL/etc. Instead of using many isolated libraries, .NET/XNA appears to be a single well organized library with a *ton* of functionality. STL has data types (like a list of strings) that OpenGL does not understand. In order for these libraries to inter-operate, the programmer is required to "massage" data to get it into the proper format. The incompatibilities in data types in .NET/XNA are largely removed since they are built on top of the same data types. Plus, all of the .NET/XNA library is documented in a consistent way, which lowers the learning curve.
• 360 controller is the only controller supported by XNA. This makes sense since the idea is you use XNA to make games that work on both Windows and Xbox 360. It sucks to make games for a PC and not know what controller to target. Now Microsoft is saying the 360 controller *is* the game controller for the PC. This may be bad news for choice and input device manufacturers, but it is great news for PC game development and ease-of-use. XNA-based PC games will "just work" with a 360 controller.
• XNA games will work on an Xbox (PowerPC-based) and a PC (x86-based) *without* recompiling. This is a side effect of using .NET. Just like a Java app can be "write once, run anywhere," same goes for .NET. 

There are several forums that discuss XNA. This one is about the XNA framework. This one is about the GSE. This is the parent page that lists forums for different game technologies. I've found a lot of good information browsing through these forums.

Another good place for XNA info is their blog.

XNA is a work in progress and they have a bunch of things coming. This is a technology that I'm going to be watching closely.

Posted on September 10, 2006 11:48 AM | Permalink| Comments (1)

I spent the last 3 years doing most of my development work on a Linux box. It is not my choice: our software only runs on Linux, so I have to play along. I am a Windows guy, and working with Linux has made me appreciate how great Windows is.

I *love* using Microsoft's Visual Studio for writing software. When I began developing software in Linux, I tried to find something close to Visual Studio. I started using KDevelop. While it doesn't compare to Visual Studio, I have found it is the closet thing on Linux. It is an Integrated Development Environment (IDE): editor, compiler, linker, and debugger all in one application.

KDevelop is a front end to other tools...GCC for compiling and linking and GDB for debugging.

When you are developing software, sometimes it doesn't work as intended. To track down the problem, there are two schools of thought:

1. Use a debugger
2. Insert messages in your software that help you get an idea of what is going on (aka "printf debugging")

Using KDevelop put me in the former category. I could click on a line and set a breakpoint, run my application, and have it stop at the breakpoint so I could analyze what was going on. This worked well for me until I spent several days trying to track down an issue. I set a breakpoint in my software where I thought the issue was, but that breakpoint was never hit. So I assumed that piece of software was never called, so I looked for the issue else where. After studying the software for several hours, I found that it was impossible for that breakpoint to not get hit. I dropped back to the old school printf debugging technique and guess what...the suspect code was executing, but the debugger was not honoring the breakpoint!

I did some research to find out how it is possible that my breakpoint would not stop my software from running. I thought it might be how the software was built, but nothing I did would make the debugger stop at that breakpoint.

I then found out that I'm not the only one that has run into this issue...it is a BUG in the DEBUGGER!!! How unsettling is that! The tool that is supposed to help you find bugs is actually hiding them from you! Here is the problem report, #1091. This bug was submitted in February of 2003 and it is still not fixed! I thought the open source community was supposed to fix things quicker than commercial software! This is a serious issue and I am shocked more people aren't outraged about it.

So just get another debugger, right? Wrong! GDB is used as the debugger for almost everything! It is used by KDevelop, Eclipse, and (here's the tie-in to Macs) Apple's Xcode. GDB is *not* the debugger for Visual Studio...thank goodness!

I found that all the Linux gurus in my group used printf debugging. Now I know why!

With bug #1091, GDB is terrible for software development. You must use GDB for Linux/Mac software development. Then by the transitive property, Linux/Mac are terrible for software development. If only Visual Studio would work on Linux/Mac!

Posted on June 25, 2006 4:50 PM | Permalink| Comments (4)