The NTSF drive format makes significant changes in the "Attributes" and other information that can be recorded for a file, and Vista makes several additional bits of information available for viewing but provides no clear description of the "defining characteristics for them all. Some of these "expansions" were in OSs at least back to WinXP, but information available is uninformative.

There appear to be additional Attributes that are used by newer Windows versions, but there doesn't seem to be any information on how to use or edit them. I found one place where Microsoft states that NTFS "knows" 12 or so Attributes, but I haven't found anything on what they are. The ancient and venerable ATTRIB command in a Command Prompt window can display or change only 5 attributes. A whole bunch of other new file-specific information appears to be attached to each file, but with the same paucity of information in readily available sources.

If you go to Windows Explorer and Right-Click on the bar above the filenames column, you'll get a list of the "Categories" of information displayed, and if you click "More" at the bottom of the dropdown, there's a list of "Categories" that you can display. There appear to be about 279 column names you can use in Vista, and WinXP offered about 28, implying that each file knows whether the name applies, and if it does, what "value" to put up in the column.

(I'm calling the column names "categories" for discussion purposes, but I haven't found an "official" name for them.)

Among the things you can assign to Windows Explorer columns in Vista are 12 different kinds of "Dates." All of the dozen "look like" they would probably get the date/time value from the local clock any time a change was needed, but that's only a "reasonable assumption" and not a confirmed property.

I keep backup copies (not "backups" of a usual kind) of my data files using the Command Prompt XCOPY Command, and XCOPY, among other options, allows you to copy only files whose "date" is newer than a file of the same name already in the target folder, and ignore (don't copy) a file that "isn't newer." I've been casually poking about at trying to determine with some certainty which of the dozen dates XCOPY actually looks at to decide "what's new." It doesn't really matter a lot for my use, but satisfying a curiosity is a happy sort of thing to do if you can avoid being obsessive about it.

A very old gimmick, used quite a lot in prehistory, was to set the computer clock forward or back to achieve a desired result when moving or copying files. In former times, if you set the "date/time" on the source machine approximately the same as on the target machine you could copy files from one machine to another and have the copied file display the "date/time" on the local clock settings.

When it became apparent that some people were using this method to "redate" files in order to use "subscription" programs past their expiration dates, some unknown (to me) changes internal to the OS or in the files themselves made many files fail to copy correctly using the method, and lack of interest has precluded my investigation into what changed.

If, as Jon suggests, the program relies only on a date/time stamp to determine whether the program should install or run, by setting the clocks on both machines back to a time "when the program was legal" you might be able to copy the files from one machine to another in working order. If the reinstallation/activation of the program is blocked by almost any other method, copying this way probably will still produce a non-functioning copy.

An additional hurdle is that the activation code probably is stored in an encrypted file. Most encrypted files cannot be copied or moved without trashing the file. You generally need to "unencrypt" before copying and then re-encrypt the copy if needed. (BACKUP programs generally are "shredders" rather than backups for any files with a password attached - something that most backup programs (especially Microsoft's) don't clearly tell you.) Even if you have the code to re-enter it, the file it's supposed to be added to likely will be too corrupted to accept the new entry if it was copied whille encrypted.

Older programs, or programs that use older methods to apply an "expiration," sometimes could be run for an extended time if the computer's clock was set back before the expiration time arrived to a time after the file was downloaded, but if the deadline was missed, or the date set back too far, the program was - even in prehistoric times - trashed by some other method, so even attempting to do this with a "modern" trial version would be far too much hassle to be worth the attempt ....

And note that a wrong time on your "local clock" will be automatically "adjusted" each time you connect to the web, and sometimes with each "communication" made on the web, so resetting to a false time would be a nasty fight between you and the rest of the whole world to keep the setting wrong enough, even if such skulduggery had a remote chance of working.

Just not even worth trying ... of course.

John