Wednesday, July 29, 2009

Amber Screens

Raise your hand if you remember when computer displays came in three colors: green, white, or amber text, always on a black background. Since the beginning, the Windows shortcut to a command prompt came configured to display text in either white or green, and always on a black background. The Colors tab allows you to choose foreground and background colors from a palette of a paltry 16 colors, which includes some decent colors, none of which is amber.

Among the three basic color schemes, I favored amber text on a black background from the first time I saw a an amber monitor. I liked it because the contrast was much better than green letters on a black background. Indeed, it might be surprising to some, but I think the contrast is at least as good as white on black, and, under certain circumstances, it is better.

Figure 1 - The Original Green Screen

Figure 1 - The Original Green Screen

Figure 2 - White Text on Black

Figure 2 - White Text on Black

In those days, there was considerable variation in the actual colors displayed; some of the green screens were brighter than the one shown in Figure 1, above, and some of the white phosphor screens were less bright than the one shown in Figure 2, above.

I promptly replaced my green screen with an amber one, which I used until I started buying VGA color screens to run Microsoft Windows 3.0, around 1990. The occupational health authorities in some European countries came to the same conclusion, and began requiring amber screens in work places, beginning in about 1983.

Beyond the 16 Color Palette

One day recently, having grown tired of yellow text on a blue background, I paid a visit to the Colors tab on the Command Prompt shortcut property sheet, and discovered something that I had scarcely noticed. In the upper right corner of the page, there is a group of three spinner controls, labeled Red, Green, and Blue (See Figure 3, below.). Their values change to reflect the selected color from the sixteen color tiles spread across the middle of the property sheet, and it didn't take long for me to realize that they are the RGB color codes that map to the selected color.

Figure 3 - Colors Dialog Box, showing settings for Amber text

Figure 3 - Colors Dialog Box, showing settings for Amber text

Using the preview controls just above the three push buttons, I began playing with the RGB color values. It didn't take long to see that I could replace any of the sixteen colors with the color of my choice, and assign it to any of the four color properties of a Command Prompt window. Hence, as is the case with the colors in the Display control panel applet, you have a choice of 16,581,375 colors!

Figure 4, below, illustrates my new amber on black Command Prompt window.

Figure 4 - My Amber on Black Command Prompt window

Figure 4 - My Amber on Black Command Prompt window

I Want to Start in My Documents

While I was at it, I decided to change the Startup directory, which is, by default, %HOMEDRIVE%%HOMEPATH%, and resolves to C:\Documents and Settings\David in my user profile. As shown in Figure 5, below, I replaced the default Start In string with %USERPROFILE%\My Documents. Since %USERPROFILE% resolves to C:\Documents and Settings\David, the whole string resolves to C:\Documents and Settings\David\My Documents. Since the path string may contain embedded spaces, it is enclosed in quotation marks.

Figure 5 - Startup Directory

Figure 5 - Generic Startup Directory, pointing to My Documents

Because all paths are specified as environment variable substitution tokens, and the remaining settings are at their default values, this shortcut works on any installation of Microsoft Windows.

http://www.wizardwrx.com/FREEBIES/AmberCommandPrompt.ZIP is a complete command prompt shortcut, ready for use. The Command Prompt shortcut, Command Prompt.lnk, in AmberCommandPrompt.ZIP reflects the settings shown in Figure 3, for colors, and Figure 5, for startup directory.

Long live the Amber Screen!

Friday, January 23, 2009

TrayProdder is for Programmers, too!

I just wrote about my latest software acquisition, TrayProdder, in aonther of my blogs, Wired Wisdom.  To ensure that the information reaches programmers who might follow this blog, but not that one, I decided to post a cross link here.

Wednesday, November 5, 2008

A Sparsely Documented Aspect of GetProceAddress

A couple of weeks ago, in the course of developing a new version of my MD5 digest library, I moved the Unicode versions of the functions into a separate library, which the main library would manage, and load only if the Windows platform on which it is running fully supports Unicode. Among other things, this meant that I needed to use the GetProcAddress Windows API function to call the functions in the Unicode satellite library. According to the documentation, on the platforms that support it, Windows exposes both ANSI and Unicode versions of this function.

Accordingly, I took the documented type of LPCSTR for the lpProcName argument to mean that the Unicode veersion of the function took a Unicode string. Silly me!

After hours of trial and failure, I repeated my Google search, and examined some of the other articles, starting with HowTo: LoadLibrary and GetProcAddress?, which gives hints of a few key elements not given sufficient emphasis in the formal documentation. The discussion on the Experts Exchange board indicated that I needed to create a typedef to match the function prototype. Less obvious is that the lpProcName argument to GetProcAddress should probably be documented as something more like char *. For this, I am indebted to the following text, taken from RE: GetProcAddress Usage.


... you will see that the lpProcName parameter is *only* configured
for const char*; there is no TCHAR derived type for the string used
here. So regarless of whether you are running with UNICODE turned
on or not, the name of a function passed to GetProcAddress is
never UNICODE formatted.


In the course of writing this article, with the knowledge learned from these and other articles, and the working code, which is part of the published source code of MD5Digest: Dynamic Link Library for Computing MD5 Digest Strings, I made a closer inspection of the included code sample.


// Call GetNativeSystemInfo if supported or GetSystemInfo otherwise.

pGNSI = (PGNSI) GetProcAddress(
GetModuleHandle(TEXT("kernel32.dll")),
"GetNativeSystemInfo");
if(NULL != pGNSI)
pGNSI(&si);
else GetSystemInfo(&si);


Although the library name in the GetModuleHandle call is wrapped in a TEXT macro, the function name string in the GetProcAddress call is not. Pretty subtle, eh?

Sunday, October 5, 2008

Could not Find Schema Information for the Element

Like Frederik Gheysels, and nearly any other developer worth his coding pad (er, editor), I like to resolve all exception reports, even warnings. Of course, there are very rare occasions when I leave a compiler warning. When I do, you can expect a comment, adjacent to the offending line, noting the warning number, and stating that the code works as designed, regardless of the warning.

In the course of sorting out one such message, "Could not Find Schema Information for the Element", which was reported when I built a new C# application, my first to incorporate application settings, I ran across two related blog articles that helped solve the problem.

The first,"Silly Config file Warnings," by Peter Richie, summarizes the cause of the problem, and provides a usable workaround, in the form of an amended DotNetConfig.xsd.

The second, ".NET 2.0: Could not find schema information for ... part 2," in Frederik Gheysels' DevLog Weblog on C# and Software Development, while it clarified and validated the first one, omitted one critical detail, which is that, after you install the new schema definition, you must restart Visual Studio for it to take effect.

Thanks to Peter and Frederik for their writings that supplied almost everything needed to solve this annoying problem.

This is hardly the first post that I've seen that was missing an essential detail. Expect to see more such gaps filled in this space.

What Is a Thought Snippet?

A thought snippet is the very essence of a Blog. It is to thoughts as a Code Snippet is to a complete C#, VB.NET, or ASP.NET program.

The intent of this collection of thought snippets is to provide permanent storage for such things as useful insights, notes about gaps in documentation that I've discovered and filled in the course of creating new software. We stand on the shoulders of others. Through this collection of notes, others will benefit from these discoveries.