Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
When we were designing NT 3.1, one of the issues that came up fairly early was the secure attention sequence - we needed to have a keystroke sequence that couldn't be intercepted by any application.
So the security architect for NT (Jim Kelly) went looking for a keystroke sequence he could use.
It turned out that the only keystroke combination that wasn't already being used by a shipping application was control-alt-del, because that was used to reboot the computer.
And thus was born the Control-Alt-Del to log in.
I've got to say that the first time that the logon dialog went into the system, I pressed it with a fair amount of trepidation - I'd been well trained that C-A-D rebooted the computer and....
Anonymous
January 24, 2005
The first time I saw NT 3.5, I thought someone had customised the logon screen as a joke, sort of like those people on IRC who tell you to press ALT-F4 to fix a problem.Anonymous
January 24, 2005
I thought the Alt-Crtl-Del was "invented" by an IBM-er?Anonymous
January 24, 2005
Out of interest, who was responsible for making the BSOD blue? Why is it still blue?Anonymous
January 24, 2005
The comment has been removedAnonymous
January 24, 2005
A Shipping Application? From MS? If it wasn't from MS, why did you guys care if it was used? Why not CTRL-ALT-SPACE? Who was using that? DEL is so far away from CTRL-ALT.Anonymous
January 24, 2005
Yeah, an IBM guy came up with CTRL-ALT-DEL as the reboot sequence. But we coopted it because no existing application was using it.
No existing DOS application would use CTRL-ALT-DEL in the application because of the rather obvious problems it would introduce (users expected that C-A-D would reboot the machine, and if it didn't reboot the machine, they would be upset).
Sushant,
You're new here, aren't you? You've never read my blog or Raymond Chen's (http://weblogs.asp.net/oldnewthing) blog and seen the herculean efforts that Microsoft expends to ensure that apps continue to work on our platforms. Here's a hint: With very, very few exceptions, Windows doesn't break apps across platform upgrades.
Some app used CTRL-ALT-SPACE for something - I don't know which app, but it was used. So were all the other CTRL-ALT combinations, and the CTRL-ALT-SHIFT, etc.
Mr. Blobby, actually, I believe it's because a lot of developers (myself included) find looking at white text on a blue background to be highly readable, so when it came time to pick a color scheme, that's what came out. I know others find black text on a white background to be cool, but...Anonymous
January 24, 2005
Hi Larry. Thanks for responding. While I do recognize the effort that MS goes to in order to allow backward compatibility, as a designer, does this come at a cost of an effective or efficient design? What makes a designer say, lets keep with the old because apps depend on it, versus, lets create a design that will most likely be used by millions of people maybe every day (I guess hindsight is always 20/20) :-) But I hope you see that I'm not trying to belittle your efforts, just trying to understand what an experienced developer would say.Anonymous
January 24, 2005
Hi Larry. Thanks for responding. While I do recognize the effort that MS goes to in order to allow backward compatibility, as a designer, does this come at a cost of an effective or efficient design? What makes a designer say, lets keep with the old because apps depend on it, versus, lets create a design that will most likely be used by millions of people maybe every day (I guess hindsight is always 20/20) :-) But I hope you see that I'm not trying to belittle your efforts, just trying to understand what an experienced developer would say.Anonymous
January 24, 2005
Sorry, I think I hit the button twice in a row. Didn't mean to.Anonymous
January 24, 2005
By the way, BSOD colors can be changed somewhere in the regitry... At least on Win 9x it was so.Anonymous
January 24, 2005
The comment has been removedAnonymous
January 24, 2005
Sushant,
The simple answer is that it's irrelevant whether it comes at a cost of an effective or efficient design.
The reality is that Windows is a platform for running applications. If the applications stop running (because we made the platform "more efficient"), then people will stop using the platform.
So compatibility is job 1. If a redesign can't be done without ensuring compatibility, then the new design needs to change. I personally think of it as an "opportunity to excel"Anonymous
January 24, 2005
"From where comes the inference that the then-absence of other uses makes it secure?"
No such inference was drawn. The security does not derive from its prior non-use.
What makes it secure is that the OS traps this key sequence in a way that makes it impossible for anything not in the Trusted Computing Base to handle it.
That part, the part that makes it secure, is orthogonal the choice of which particular key sequence they chose to trap in this way. They could have chosen anything. For example, they could have used, say, Ctrl-SysRq. Arguably that would have made sense of the fact that that key had had SysRq printed on it for no obvious reason all these years.
But if they had done that, this would have prevented applications that actually did something with that key sequence from working. If backwards compatibility is a goal (and it was) then Ctrl-SysRq is no better than choosing, say, the E key as the sequence...
They had to chose a key sequence that wasn't already in use if they were to avoid breaking existing applications. Since Ctrl-Alt-Del had been the reboot sequence since the dawn of time, arguably no sane development team would choose to use it to do anything important. Which of course is exactly what the NT team promptly did. ;-) (For the benefit of the irony-impaired, who seem to be particularly active in blog comments, I'd like to point out that that last sentence was in jest.)
Once they had chosen the key sequence, the thing that made that choice secure was the implementation of their decision to secure it.Anonymous
January 24, 2005
Larry, I think I understand the design philosophy a bit better now that you have elaborated. I think that Apple does give different weightings to compatibility vs effective or efficient design vs MS. From my little experience with apples products, backward compatibility isn't really a priority. Would you agree? Is that why their products weren't able to capture the market as well as MS in the early days?Anonymous
January 24, 2005
The comment has been removedAnonymous
January 24, 2005
The comment has been removedAnonymous
January 25, 2005
The comment has been removedAnonymous
January 25, 2005
Larry, isn't there a DirectX flag these days to inhibit C-A-D? I remember playing around with it and naturally locking everything up. I don't remember if it might have been in 9x, though.Anonymous
January 25, 2005
The comment has been removedAnonymous
January 25, 2005
It's no longer the case, apple changed, but in the past,
MS - Software compatability - all old programs run.
Apple - Hardware compatability - all new programs run on old hardware (even if it took 20 minutes to startup the app).Anonymous
January 25, 2005
This 'slavish compatibility' has failed somewhat for XP SP2 - you finally decided to make security come first. From various MSDN blogs I get the impression that the attitude was 'if we must break it, let's break everything once'.
However, Joel Spolsky seems to think that the problem is deeper - that the compatibility camp in MS has been outweighed by the new products camp.
What you are saying (I think) is that MS will try not to break compatibility, even in Longhorn. How far will this go? Will security concerns still trump compatibility, as with SP2?
I take it that you don't share the same concern, or feel the same sense of loss, about breaking compatibility with open-source software ;-)Anonymous
January 25, 2005
There will be one thing that will break a lot of compatibility: 64-bit Windows doesn't alow 16-bit Windows apps. Didn't Gates demonstrate DOS VisiCalc running on Longhorn? There's going to be a lot of 16-bit apps (e.g. old games) that won't work anymore once 64-bit becomes mainstream.
Microsoft could integrate Virtual PC into the OS in some fashion in order to allow 16-bit apps to run.Anonymous
January 25, 2005
Jonathan's right, 64 bit windows removes the DOS subsystem. And I'm not sure that it's the right decision - there are a number of x32 apps out there that still use 16bit setup technologies.
And the server platforms have removed support for Posix and OS/2.
It'll be interesting to see if the 16bit removal decision sticks.Anonymous
January 25, 2005
The comment has been removedAnonymous
January 25, 2005
Sorry for lack of research, but well:
Application-specific quirksmodes (as of Simcity fame) don't/won't exist any more?Anonymous
January 25, 2005
Mr Blobby,
Nope, appcompat will still work and they're still there. That's how we resolve the issue of broken apps - we change the system behavior for the single broken app instead of changing the entire system for the sake of an app.Anonymous
January 25, 2005
In which case, my previous comment about open-source apps still stands. However, that was just meant to be a joke... To make it less contentious, and more useful, how about this (broader) question:
Out of the set of all apps which don't work despite the work you put into the binary compatibility layer, how do you go about selecting/prioritizing the subset which will get the quirksmode treatment?Anonymous
January 25, 2005
The comment has been removedAnonymous
January 25, 2005
Mr. Blobby: I guess I understand, but.. If an open source product is successful, then it will become successful because it is available in a binary distribution.
Source distributions will NEVER be successful distribution mechanism (beyond the hobbiest or IT department level). User's just don't compile the code and run, they run pre-compiled binaries.
If you've got the source code and your app breaks on Windows, then you can fix it yourself - by downloading the source and recompiling it, you take on all responsibility for maintaining your code. That's the behavior of a hobbiest or IT person, not a consumer. As I said, consumers use binaries.
Norman, that's actually a really good point - a user that doesn't know the OS on the computer DOES have to reboot it to truly ensure that NT's running.Anonymous
January 25, 2005
The comment has been removedAnonymous
January 25, 2005
What about Windows XP and the Welcome screen - could that be spoofed? If your Windows XP machine is on a domain then you can't use the Welcome screen. I know that one reason for this (that Raymond Chen has mentioned) is because it's not feasible to enumerate network user accounts for display on that screen, but presumably another reason is that it doesn't use the SAS.Anonymous
January 25, 2005
The comment has been removedAnonymous
January 25, 2005
Mr Blobby: I don't know the answer to that one, I'm not on the appcompat team.
John: Actually the SAS is still there for the welcome screen - hit C-A-D twice and the old familiar logon dialog will come up.
KiwiBlue - if you believe that the bad guy's had enough access to replace your OS, then it doesn't matter, you might as well reformat.Anonymous
January 25, 2005
The comment has been removedAnonymous
January 25, 2005
Jerome, that's surprising - I'm not aware of any mechanism of spoofing C-A-D on NT - are you sure that was NT you were running?Anonymous
January 25, 2005
The comment has been removedAnonymous
January 25, 2005
Larry, I did know that actually but forgot (I found it out by accident once)!
Jerome, I know about the Task Manager shortcut and have seen it documented somewhere. Having said that, I couldn't find it in Windows XP Help.Anonymous
January 26, 2005
Larry, I don't agree that source distributions will never be successful. Most of the time users don't simply run binaries, they have to go through an installation process. And there's absolutely no reason why the installation could not include compiling the actual binaries. The users wouldn't know, much like they do not know today what the installer does. Users currently do not manually register type libraries but that haven't prevented applications that use COM from being used by BFUs.Anonymous
January 26, 2005
The comment has been removedAnonymous
January 26, 2005
The comment has been removedAnonymous
January 26, 2005
The comment has been removedAnonymous
January 26, 2005
A friend of mine who used to work at IBM and knew David Bradley (the creator of Ctrl-Alt-Del) told me that David often said:
"I'm the one who invented Ctrl-Alt-Del, but Bill [Gates] is the one who made it famous!
... For the NT logon screen, of course!"Anonymous
January 26, 2005
Larry Osterman
>Jerome, that's surprising - I'm not aware of any mechanism of spoofing C-A-D on NT - are you sure that was NT you were running?
Maybe I'm mistaken. It was a long time ago. Anyway, my problem was that I didn't lock my workstation and a coworker simply walked to the machine and installed all sorts of stuff. I've been mre careful since then.
John Topley:
>Jerome, I know about the Task Manager shortcut and have seen it documented somewhere. Having said that, I couldn't find it in Windows XP Help.
I'm glad it is documented somewhere. Anyway, since it is being used I guess it's here to stay anyhow.Anonymous
April 10, 2005
It seems to me that requiring ctrl+alt+del to log on is only secure if the user knows enough to stop if they don't get that prompt. In my experience, people will type their password into any dialog that looks like a logon prompt. Most won't stop and say, "Gee, I didn't have to press C+A+D; I'd better call the administrator."
Am I missing something?Anonymous
May 26, 2007
PingBack from http://www.altctrldelete.info/?p=5Anonymous
January 22, 2009
PingBack from http://www.hilpers.fr/643637-clavier-bloque-ecran-daccueil/5Anonymous
February 09, 2009
PingBack from http://batchgame.com/?p=1066Anonymous
May 31, 2009
PingBack from http://woodtvstand.info/story.php?id=1467