Happened upon a pretty nifty map today.
Here’s a sample:
Basically, it’s a regular world map with all the DNS country codes imprinted on it.
Makes a decent wallpaper too, as long as you have a pretty big widescreen monitor.
Happened upon a pretty nifty map today.
Here’s a sample:
Basically, it’s a regular world map with all the DNS country codes imprinted on it.
Makes a decent wallpaper too, as long as you have a pretty big widescreen monitor.
We’re switching a major project over to SQL Express 2005 from MSDE 2000, and in the process of doing so, I came to several discoveries.
I did, however find this article about sqlexpr32 command line switches which should allow you to perform the Express install from within a normal MSI install by just running the exe with the proper switches. Not ideal, but it’s something.
I’ve played a bit now with the .NET configuration model and while I can certainly see some elements in there to like, it seems to me that it falls short in a number of different ways.
First off, it doesn’t really have any concept of “multi-level configuration.” In fact, it’s basically a single level XML file (granted, you could create a hierarchical organization within that single xml file, but there’s other issues with that). .NET does help a bit with the concept of a machine config file, but from what I can tell that’s about as far as it goes.
Second, the default behavior is to locate the application config file in the same path as the application itself. That’s great if your user is running as administrator, but not so great in more locked-down situations where users do not have full admin rights. In those cases, configuration that’s writable needs to be stored somewhere within the user’s profile directory structure. This is just going to get worse with Vista, too.
Ok, sounds good but what, you may be asking, is a multi-level configuration scheme, and why would I want one? Almost every app I’ve ever worked on, short of the trivial utilities I’ve built, has required this sort of configuration scheme (or at the very least greatly benefited from having it). It almost always follows along this line:
At each level, the system provides for an essentially unlimited number of name value pairs that can be cordoned off into groups (or sections as they used to be called in INI files). Some may argue that a section-name-value system like this is too limiting and you should always accomodate full hierarchical structures, but I’ve found the extra functionality rarely necessary.
Of course, the type of value (string, int, date, etc) for a particular setting is defined within the application, but value types might also be defined as OEM default settings. Should sysadmins really be able to change setting X from a string to a date? I’d imagine not usually.
The trick and the real beauty of the system is in the way that setting values are resolved. The resolution logic basically says that if the app can find a setting at a higher level in the hierarchy, it uses that value. Otherwise it searches down the hierarchy till it either finds a value, or till it drops to the OEM defaults. If no setting is specified at the OEM level, the system defaults to blanks, or 0’s depending on the data type.
So, for instance, the code might ask for the setting “AskOnExit” from the “Prompts” section. The config handler needs to look first at the “level of most significance” which, in the above list of levels, would be the Administrator specified user specific settings (ie those settings that are set on a per user basis, but that the user himself doesn’t have the authority to change.
If the setting isn’t found there, the code continues down the hierarchy, looking at each level in turn until eventually in run through them all and returns the default or a blank or 0.
And, of course, you also have to provide a means to retrieving and writing a setting at a specific level in the hierarchy, for those settings that are always application level or machine level or what not.
Obviously, such a scheme requires a little more work up front, but the configuration flexibility (especially when you’re talking about major, multi user systems with lots of configuration options, typically off-the-shelf, reseller-friendly applications like accounting systems or CRM packages), is a huge selling point to admins and users alike.
Why, then does configuration handling in .NET seem so archaically primitive?
Could you roll all these levels into that singular .config file? Sure, when where would you put it? In the Application path? No, users won’t typically have write rights there. Under the user’s Application Data folder in the Profile? No, can’t put app wide settings somewhere that only a single user can access it. How about that machine config file. Again, not writable by typical users.
It’s funny that Windows already has a rights system that is very stable, quite flexible and easy to work with, both manually and from within code and yet it often goes completely unused by larger apps. I’m talking, of course, of the file system.
These days, though, web apps are de rigueur and you can’t go assigning file system rights to web users. There’s no way that would fly with most web developers (you weren’t really thinking of something like that, right?). So, roll it up into a simple table, with a getSetting and a setSetting stored procedure to simplify the coding. With proper indexing, and a little intelligent caching, it’ll be every big as fast as using the .NET configuration functions, and whole lot more flexible.
Long story short. If your sideline utility needs to save a few settings, use the .NET configuration. It’s fast, relatively easy and convenient. But for just about everything else, take a little time and do it right.
Your users and their sysadmins will thank you.
I was looking for a particular reference book today and stumbled across a little book I hadn’t looked at in ages. It was a favorite way back and it’s still pretty funny now.
The book is the “Book of Minims” by Tom Weller. It’s appearently out of print now, but Mr. Weller has made the whole thing available online here.
In case you’re wondering, Minims are the opposite of Maxims, basically, sayings that sound like they have a deep meaning but in reality are so obvious or specific as to be useless.
One of my favorites: “Money is it’s own reward”.
Good stuff.
I’ve used several different media players over time, but since stumbling across J River’s Media Center, I haven’t seen the need to use anything else.
It has an fast and flexible database, and it can tag multiple tracks very efficiently. Plus it looks great!
I really only have two negatives about it.
Ok, scratch that last negative. I posted a question to the MC forums and got some very helpful responses, which led me to the Media Center Wiki with this post about the command line options. Just use:
MC12.EXE /COMMAND /NEXT
or
MC12.EXE /COMMAND /PREVIOUS
and Viola! Next and previous work just fine, no matter whether MC is minimized to the systray or not.
Now, maybe someone has an idea about getting it to work with Tivo again. Anyone?
If you’ve ever looking closely at Windows applications, you know that Windows Version Numbers are composed of 4 parts:
So a version of 4.8.3.9888 would typically mean Major version 4, Minor version 8, Revision 3, Build 9888.
If you’ve ever looked at VB’s Project properties box, though, you’ve probably noticed the disconnect.
Obviously, VB directly supports the Major and Minor, and appearently, the Revision number.
But, build a VB6 app with unique values in for each number and then view the app’s properties via Windows Explorer:
In this particular app’s case, Major and Minor are 0, and Revision was set to 49. However, according to the Windows Property panel, the Build number is 49. VB internally makes the Build number what you enter as the Revision number in the VB project property UI.
Now, whether this was just a typo on the part of the VB developers or an intentional “feature”, I can’t say. But it definitely can cause confusion and make it difficult to identify versions of your app out in the field. Then there’s the constant explaining of why your app’s revision always seems to be 0, but other applications have something there.
In a previous post on VB and resources, I mention the Microsoft Resource Compiler, a utility that can compile resource files into RES files, which can then be compiled into your application by VB.
This combination works wonders if all you want to do is embed icons, bitmaps, strings or arbitrary files into the resources of your app.
And, if you look at the RC documentation, you’d see info on VERSIONINFO statement that is used to define a Version Info Resource.
So, it would stand to reason that if you created a resource file, say like this:
VersionInfoTest.rc
1 VERSIONINFO FILEVERSION 1,2,3,4 PRODUCTVERSION 1,2,3,4 FILEOS 0x4 FILETYPE 0x1 //// 2 for dll, 1 for exe { BLOCK "StringFileInfo" { BLOCK "000004b0" { VALUE "CompanyName", "MyCompany" VALUE "ProductName", "MyProduct" VALUE "FileDescription", "MyFileDesc" VALUE "LegalCopyright", "MyLegalCopyright" VALUE "LegalTrademarks", "MyLegalTrademark" VALUE "OriginalFilename", "MyOriginalFilename" VALUE "ProductVersion", "1.2.3.4" VALUE "FileVersion", "1.2.3.4" VALUE "Comments", "MyComments" VALUE "InternalName", "MyInternalName" } } BLOCK "VarFileInfo" { VALUE "Translation", 0x0000 0x04B0 } }
Then, all you should have to do is compile the RC file with RC.EXE, load up VB, add the resulting RES file to your project and you’d be done.
Unfortunately, the path to enlightnment is never straightforward, and neither is the process of getting a proper version number into a VB6 executable.
The problem is that VB post-processes the compiled executable in order to put the version information from the Project properties screen into the VERSIONINFO resource. This means that the nice, correct VERSIONINFO resource that you just compiled into the executable get’s stomped on by whatever you happen to have in the Project Properties dialog, and that dialog will always reset the Windows Revision number to 0, and use the VB Revision number as the Windows Build number.
What you have to do is post-post-process your exe and put the correct VERSIONINFO resource back in after VB is completely finished with the file.
And the easiest way to do that is with a handy free utility called Resource Hacker. This utility allows you to easily open, view, and even extract all the resources in any EXE or DLL. If you want to just pull all the icons out of a file’s resources, there are definitely better ways. But if you really want to poke around the resources in a file, ResHacker is perfect. Plus, it’s got a very handy, if not a little arcane, command line interface that will allow you to automate much of the process via MAKE files or batch scripts.
Make sure the RESHACKER.EXE is on your path, then run:
reshacker -addoverwrite "yourexe.exe", "yourexe.exe", "yourexe-VersionInfo.res", versioninfo, 1 , 1033
I’m assuming your compiled application is called yourexe.exe, and that you’ve compiled an RC file with a VERSIONINFO resource in it to the file yourexe-VersionInfo.res.
Resource hacker will dutifully wipe out the VB created VERSIONINFO resource and replace it with the one compiled from your RC script.
One important note, though. ResHacker will not merge a single resource, and all of the version information is considered a single resource. That means that you need to specify all the pertinent version info properties in your RC file, because everything specified via the VB Project Properties dialog will get replaced.
“But”, you say, “the version numbers themselves appear to be replicated 4 times in the RC file! I’m a lazy programmer and the thought of updating 4 copies of the version number just seems, well, wrong.”
And you’d be right.
Fortunately, there is a way to convince RC.EXE to allow you to specify the version number for your app only once. However, doing so is, like the concept of using resources in a VB app, more complicated that you would at first imagine.
I’ll discuss that in my next post.
I haven’t played with Terragen much yet, but I’ve been thoroughly impressed by some of the work various people are doing with it. If you’ve never seen Terragen artwork, well, wow! It can generate some of the most photo-realistic scenes I’ve seen. And it’s free. Granted, there’s newer, more powerful programs out there now, but in good hands, Terragen can create some amazing stuff (and in the wrong hands, yikes!).
Anyway, check out any one of these sites. They’re some of the better ones I’ve stumbled across:
And, speaking of wrong hands, here’s my first shot at a Terragen scene. I call it Grand Pass.
The topic of hiring came up recently, and it reminding me of a novel approach an employer I once worked with used to find people.
They posted notices with all the major job search boards (that’s how I came across them in the first place), and in them, they gave no email address, just the URL of a zip file that contained the source of a broken project.
The task was to fix the project. Once you’d done so and were able to run the thing to completion, the end result was the email address where you needed to submit your resume.
The trick was that you couldn’t just find the email address in the source. The project really did have to be debugged and corrected first.
It wasn’t terribly tough. If I remember correctly, I fixed it up one morning before going in to my at that time current job, and submitted my resume more on a lark than anything else. The company was, after all, located in Chicago (I had no interest in moving to Chicago), and they made no mention of telecommuting.
In the end, I liked the guys involved, got the job and stayed for more than two years.
I was speaking with the CIO who concocted the test at one point. He said he got something like nine resumes submitted and every one of them looked like a great fit. That in contrast to the thousands of resumes that come in from a typical post to, say, Dice.
In the entire time I’ve used the various job sites out there, I’ve never seen this approach used by anyone else.
Feng Shui is all about the placement of things to better harmonize with their (and consequently your) surroundings.
With VB, there’s no better place to examine that than the file footprint of your application.
Ask yourself: You have two apps to evaluate. They perform identically, are configurable in all the same ways and behave exactly the same. One app consists of hundreds of files scattered across dozens of folders. The other’s footprint is exactly one file, the EXE itself. Which would you choose?
Granted, that’s an extreme case, but the point is, the smaller your app footprint, the better, in almost all circumstances.
And a really nice way to shrink an app footprint is with resources.
If you’ve never messed around with resource files in VB6, or maybe only tried to use the built in resource editor add-in, you really don’t know what you’re missing.
Resources can be an immensely handy way to embed everything from pictures to WAV files, to chunks of script, to icons, and just about anything else directly into your application, but in a way that makes them accessible to the outside world, for one-off customizations, translations, or to just keep the file footprint of your app as small as possible.
However, resource files can be notoriously difficult to work with because of the lack of tools available natively with VB6. VB.NET dramatically improves upon the situation, but there’s still a lot of VB6 code out there that might benefit from resources.
Generally speaking, you have two “types” of resource files where VB6 is concerned.
Why the distinction?
There’s one specific kind of resource that you very much should want to include in your compiled file, but which VB is notoriously lacking about. The Version Info Resource.
VB only allows you to specify the Major, Minor, and Build version numbers (although VB calls the Build number, the “revision” number, mysteriously).
Windows executables, on the other hand, support a Major, Minor, Revision, and Build.
Now, the truth is, VBs support is generally fine for utilities, hobbiest programs and the like. But real, commercial applications really should make use of all four numbers, and that’s something that is impossible using VB alone.
Ah, you say, VB does have that “Resource Editor” add-in, just use it! Not quite. You can’t create a version info resource in it, and even if you could, VB’s compiler replaces any version info element within that resource file with the information from the project properties window.
The solution is relatively simple and still preserves all the great things that resource files in VB can do for you.
For this resource file, you have 2 choices, use the VB Resource Editor Add-In, or create an RC resource script file, and compile it to a RES binary format file that VB expects. I prefer the later, simply because scripting the resource file makes it much easier to include things like big chunks of text (xml, scripts, icons, what-have-you), and you can leave all of those things external to the RES file without having to manually pull them in via the Editor add-in every time they change.
I usually create an RC file with the same name as the VBP file, but with an RC extension
test.RC
// Test Resource Compiler file // used to automatically compile the RC file into a RES file // BEFORE the project itself is compiled // This makes the Resource data available to code while in the IDE // //----------------------------------------------------------------------------------- // Arbitrary Text File Resources // //---------------------------------------------------------------------- TEXTRES1 TEXTRES_DEFS PRELOAD DISCARDABLE TextRes1.txt TEXTRES2 TEXTRES_DEFS PRELOAD DISCARDABLE TextRes2.txt //----------------------------------------------------------------------------------- // Bitmap Resources //----------------------------------------------------------------------------------- IMG_MAIN BITMAP PRELOAD DISCARDABLE ".\test.bmp"
Note that test.bmp is just some random bitmap file, and that TextRes1.txt and TextRes2.txt are arbitrary text files.
Then, you can access those resources via a little bit of VB code
To get the text file resources
Dim a() As Byte dim buf$ a() = LoadResData("TEXTRES1", "TEXTRES_DEFS") buf$ = StrConv(a, vbUnicode) 'need to convert the raw ansi text file content to UNICODE to make VB happy
Or to load the bitmap
Set form.Picture = LoadResPicture("IMG_MAIN", vbResBitmap)
Icons, and string tables are a little more difficult, esp. with respect to XP and VISTA format icons, so I’ll worry about them later.
You can compile the RC file using a command line similiar to the following:
rc.exe /r /fo "test.res" "test.rc"
Make sure the RC.EXE resource compiler is on your path for it to run right. The RC.EXE file itself should be somewhere in the VB6 installation folder under Program Files. For a muhc more thorough explanation of the Resource Compiler, check here. Microsoft has some very good RC information here also.
Alternatively, you can put this command in a BAT file, and execute it quietly:
cmd /Q /c rc.ex /r /fo "test.res" "test.rc"
One caveat. If you decide to use the RC file, be aware that VB loads the compiled RES file when you load the project. So if you make a change to one of the component resource files (say, an ICO or BMP file), you’ll need to exit VB, recompile the RC file to a RES file, and then RELOAD the project in VB. Since RES files don’t change all that much once initially created, this isn’t a huge problem.
Another note: You can only include one resource file in a single VBP project, so it has to contain all the resources the app will need (except, of course, for the Version Info Resource).
And a final note: You can easily add a resource file to a project by
1) compiling the RC file to a RES file
2) Opening your VBP project
3) dragging the RES file from Explorer to the VB Project Window.
For next time, handling the Version Info Resource….