Despite the many problems typically seen with "mixing" applications and operating systems, there are occasions when it is a necessary evil -and even not so evil, with well-written applications and operating systems.
Literature on the Internet documenting particular applications and OS interactions abounds, particularly the issue of DOS applications on NT/2000/XP. My coverage here is a little different; I will focus on mixing and matching operating system components for the NT/2000/XP environment.
There are a few reasons that this is legitimate.
This is a list of several applications I have tested on various versions of the NT family, along with notes about known ramifications, limits, and repercussions.
Please verify the following; I assume NO responsibility for misinterpretation or mistakes. Also, if the response you get from channel distributors seems wrong (they have problems understanding Microsoft licensing too..) get in touch with a local Microsoft rep for clarification.
Microsoft actually has a down-level access rights policy about its line of operating systems acquired through standard distribution channels (NOT OEM). If you have a valid NT4 server license, for example, you can legally install NT4 Workstation instead, or Windows 95, or Windows 3.1... etc. This should implicitly give the right to run a down-level component on your current OS.
It does NOT work up level for obvious reasons. However, if you have a legitimate license to a current OS, run a down-level version of it instead, and then use a component from the up-level version, you should be clear. Again, check with your channel partners and/or Microsoft to make certain that you are applying the policy correctly.
This is an application that simply will not go away; generations of users seem to pass it down as a family heirloom. Other than the fact that it is a 16-bit application, though, it seems to have no real issues. IT works fine, doesn't hang anything, and generally does exactly waht it was always supposed to do.
I consider it "functionally compatible".
Another Win16 application, Macro recorder has functionality which was never built into Wi9x or the NT line. Certainly there are other ways to accomplish what you want - the Sendkeys method in WSH or Visual Basic both work for most of this - but it takes much more background knowledge and more time to write a script than to record it with Macro Recorder.
Macro Recorder runs OK on all of the NTish operating systems IF you confine yourself to keyboard activity. Attempting to use mouse recording (which had problems even on Win3.1) causes all sorts of havoc on the newer operating systems. At best, the macro will not work, the GUI will hang, and you will likely have to kill the explorer shell and all instances of ntvdm to recover; at worst, you can have a system freeze that requires a forced manual shutdown (cut the power).
For this reason, I consider it "partially functional - severe issues". It should NOT be used on any sort of production system, and most definitely not a server. IT does have some value for testing work or special automation on a system which can be arbitrarily crashed without causing problems for other users, but even then I wouldn't want it on one of my LANs.
This is the old MS-DOS tool for expanding *.??_ named files.
It will not correctly rename or even work with standard compressed NT files. So why bother?
Because old compressed files are NOT correctly renamed by the Windows NT "expand" command - but ARE by the Windows 3.1 expand command. You can readily identify this class of files by the fact that when NT extracts the files, it renames them by just chopping the final "_" in the name, leaving lots of files with extensions like .hl, .tx, .dl, .ex - and even worse, obscure files with no known correct expansion.
This tool is fully functional and even preferable for legacy compressed files.
This was removed from Windows 2000. Its special features have never been replaced. Although it has no context menu support and file operations have cumbersome paths involved, it has the following advantages:
It is fully compatible, although a bit cumbersome in the interface. For rapid, complex browsing, though, there is still nothing to compare to it.
The old GUI telnet. It works fine on 2000 and XP, albeit without NTLM authentication (something which should be disabled client side anyway so you don't broadcast passwords to every telnet URL in the universe).
Fully functional - telnet service on a Win2K system must have NTLM authentication not required to work with it, just as with any standard telnet client other than Microsoft's console telnet.
Works fine on the newer systems. Note that has much less functionality than the Win2000/XP CMD. The only remotely useful purpose is to test batch files in a simulated NT 4 environment, and even then it will only simulate the command extensions environment; the external commands will still be Win2000/XP unless you take the externals from NT4, place them in a special directory, and place that in the test environment path ahead of %windir%\system32 on the testing system - potentially dangerous. It is easier (and more reliable) to simply execute the scripts on an NT 4 system.
Functional but not worth it.
This can be installed on both Windows 2000 and XP to restore 1-second granularity to scheduling; it is specifically useful for that. I have a complete procedure and notes available.
Full functionality for standard AT-scheduling when 1-second granularity is desired over the 1-minute post-IE4 granularity. May break other things, so use with caution.
This was removed from Windows 2000 - yet another functional command line tools which has been replaced by a complex set of GUI steps which take work to automate.
Basic rdisk (other than the user data, of course) to floppy works fine. There are some conflicting reports about issues with some switches which I have never verified.
2000+ version gives errors but will work. The best bet if you want a console telnet on NT 4 is to either use one of the aftermarket ones (several are free) or get Windows Services for Unix.
Functional with errors.
Appears to work fine down-level. This may have use when working with special Win2000/XP designed scripts that need to be run on an NT 4 system occasionally. It DOES give the dynamic variables, but external commands (such as SET) will still depend on the old NT4 version unless you put the new versions in the path - potentially fraught with peril.
Appears to be fully functional, allowing use of dynamic variables. Use with caution if at all.
This was finally brought to the NT family with Windows XP; it works analogously to the Win9x msconfig.exe, and also shows a quick services summary.
It runs fine on Windows 2000, allowing quick access to automatically running applications - this can help in rapid troubleshooting of a system which may have suspicious startup items.
Functional for viewing; appears to also work for modification of service start and disabling GUI autostart apps, but not heavily tested by me.