Maybe they thought it was a security risk, but I'm having trouble imagining why it would be. Maybe you could convince a user to enter their password into the telnet window? I'm sure somebody thought this through and has a pretty good reason for it, although I'm not seeing it presently. :thinking:

Well the IE7 release notes say they disabled a number of obsolete scripting, addons, and protocols (like gopher and telnet). I guess the keyword *obsolete* is their reason why. Windows Vista still ships with the telnet program though.

There are easily over a hundred settings for IE in the registry, but only a few dozen are accessible from IE's options dialog. That's probably true of a lot of Windows apps. The registry is Window's /etc.

Hmm, I didn't realize that telnet was considered obsolete; a lot of network devices still use it. Now gopher I haven't seen in ages, but, well, … anyhow I'm not sure what harm it does to leave it enabled even if it's supposedly obsolete. (If you're going to code in the support anyhow…)

As for the registry: too bad it's not as easy to navigate as /etc … things go every which way and even though there is some sense to it in the end of the day it's just quite a bit messier. Oh well.

Not sure what you mean. Navigating it via the GUI is very much like using the tree in Windows Explorer or Gnome FileExplorer. And one can just as easily export, edit and import exactly what you want with command line tools:

C:\>regedit /a ie7.reg "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_DISABLE_TELNET_PROTOCOL"

C:\>more ie7.reg
REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_DISABLE_TELNET_PROTOCOL]
"iexplore.exe"=dword:00000001

C:\>edit ie7.reg

C:\>more ie7.reg
REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_DISABLE_TELNET_PROTOCOL]
"iexplore.exe"=dword:00000000

C:\>regedit ie7.reg

But the real benefit is that because it's a hierarchical database with an API, all applications can easily read and write configuration information to it the same way. On Unix the formats of config files in /etc is quite application dependent and must be specially parsed.

Well, I meant a few things. For starters, the registry is huge. There's a lot more stuff in there than you find in /etc. It mixes keys that make sense to the user, and system keys that make no sense whatsoever except to the very knowledgeable in that domain (e.g. the 'classes' section). It also has a fair bit of complexity based on local machine, user, etc. – obviously these have their undeniable uses, but the decentralization makes it hard to know when exactly you've gotten rid of everything. In /etc, a program's configuration will pretty much be in just one spot as far as the system is concerned, and just one spot as far as the user is concerned. (Windows suffers from the fact that the system/user distinction is very blurry, and many programs will put user config in the system section, for instance.)

Furthermore, some applications use the registry, some will use config files, some use a mixture of both… and inconsistency is never good. It makes it hard, again, to track down where all of a program's config entries are.

Additionally, the fact that you can write more or less anywhere means that there are apps that write more or less anywhere: the keys they write are not necessarily segregated into nice directories. (Of course, programs could misbehave in /etc, too. But note that /etc can only be touched by the super-user, which is a much stronger notion on Unixes than admin on Windows.)


Yes, that is a good thing. However, just because you have an API to walk the tree doesn't mean you have any idea what the data in the tree is saying. You still need to know how the application lays out its particular settings tree. So yes, you don't have to write a separate parser to read every application's config file, but you aren't gaining anything in terms of knowing what to do with the data you find there.

And arguably, in a considerable majority of cases, one application really has no business fiddling with the configuration of another application in the first place.

I know of many colleges, including mine, that have totally banned any telnet communications (including FTP) and have moved to only offering SSH and SFTP. There is a real security risk, but I am not sure I would call it obsolete yet. We should eventually be moving all services towards SSH and SFTP, though.

Fortunately, it's usually fairly easy to get around that by using SSH to tunnel to a remote host, and then doing whatever you need to do. It's how I got around the problem of my MUD's packets being shaped: I tunneled to the host where the MUD is run, and then locally connected. :smile:

(Of course, this only works if you have a shell account on some computer somewhere…)