| Date: | April 12, 2006 / year-entry #130 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060412-09/?p=31563 |
| Comments: | 40 |
| Summary: | (This is the first in a series of short posts on where Microsoft products got their names.) The original name for the malware protection service was "mpsvc" the "Microsoft Protection Service", but it was discovered later that that filename was already used by malware! As a result, the name of the service had to be... |
(This is the first in a series of short posts on where Microsoft products got their names.) The original name for the malware protection service was "mpsvc" the "Microsoft Protection Service", but it was discovered later that that filename was already used by malware! As a result, the name of the service had to be changed by sticking an "ms" in front, making it "msmpsvc.exe". Therefore, technically, its name is the "Microsoft Microsoft Protection Service". (This is, of course, not to be confused with "mpssvc.exe", which is, I guess, the "Microsoft Protection Service Service".) Fortunately, the Marketing folks can attempt to recover by deciding that "msmpsvc" stands for "Microsoft Malware Protection Service". But you and I will know what it really stands for. |
Comments (40)
Comments are closed. |
Microsoft Protection Services? Is that where you pay them insurance money so that you don’t have an unfortunate accident?
Any idea why they left the extra ‘m’ in there?
This might be a stupid suggestion, Raymond, but… Wouldn’t "Microsoft Protection Service.exe" be a much, much better name?
Love this series. Thanks
> Wouldn’t “Microsoft Protection Service.exe”
> be a much, much better name?
Personally, I hate file names with spaces in them, but generally having more descriptive long filenames would seem like a good idea. What is the fetish with 8.3 naming in 2006 all about? Aren’t we past that now?
For .NET binaries, the standard is to use a whole unique <Company>.<Component> namespace to name the thing: Microsoft.VisualBasic.Vsa.dll, Fabrikam.Security.dll. At least for shared assemblies. This is from the Framework Design Guidelines chapter 3 Naming Guidelines Setion 3.
I guess sqlwb.exe (SQL Server Managment Studio nee SQL Work Bench from SQL Server 2005 client tools) is an example of a .NET binary that uses 8.3 naming.
Sort of like how in the Alpha Longhorn days, we had the "Rover Service, not to be confused with the "RoverService" which also was in the builds but was something else entirely.
Restricting filenames to 8.3 means the CD can be plain-jane ISO9660, not Joliet, which simplifies building the CD and the installer.
I agree about filenames spaces. I’m ridiculously happy that Vista has changed "C:Documents and SettingsPaulMy Documents" to the much more sensible and type-able C:UsersPaulDocuments. I don’t know why they didn’t change "C:Program Files" to C:bin, but I’ll probably just do that myself.
When it comes to service filenames, though, I’m actually happy with a concise mnemonic. I spend a lot of time poking around in the task list, and I can skip over most of the common ones. Anything that’s the least bit off quickly catches my eye.
PMP
I agree that long filenames aren’t useful as a security feature, but neither are metadata and signed files. Joe User isn’t going to check any of that stuff, he’s just going to click on it.
Why do people hate spaces in file names? Unquoted values are just exploits waiting to happen, if you assume file names (and paths) will not have spaces in them and don’t quote it’s easy to give your code a value with a space to make it do things it isn’t supposed to do.
So, "Microsoft Malware Protection Service" protects malware? :)
Good series, looking forward to the next one.
Lisa: [reading Homer’s invitation] "Come to Homer’s BBBQ, the extra ‘B’ is for BYOBB."
Bart: What’s that extra B for?
Homer: Oh, that’s a typo.
Wasn’t the space in "Program Files" done with the explicit intent of forcing app writers to actually have thier apps work when handed paths/filenames with spaces? I remember there were a ton of buggy apps early on that didn’t handle them at all.
Long, English file names are no more or less a security risk than short, obfuscated file names. But there must be a fantastically good reason why they’ve stuck with 8.3 names all this time, because it’s an otherwise real pain for users.
Or is it because these names can’t be localized, so they’re obfuscated instead?
Long filenames are harder to type in, and putting spaces in the name adds 2 additonal characters to the effective length (the quotes).
Long filenames are hard to see on the screen because they get truncated. It’s a lot easier to tell what "msmpsvc.exe" is than "Microsoft P…" — of course you can expand the filename listing to show the whole thing, but then you waste a lot of space because most filenames aren’t that long, and you end up not being able to see as much on a screen.
Long filenames do not fit on an ISO 9660 CD filesystem, so either extensions have to be used or there has to be a way to know what the long name should be from looking at the ISO 9660 name.
"is it because these names can’t be localized, so they’re obfuscated instead?"
The computer manufacturer that bears a fruit name has solved this. The folder named Pictures will show up in all applications as Bilder on my system set to Swedish locale, but will still be Pictures when you are placed in a shell. Magic.
"Long filenames are harder to type in, and putting spaces in the name adds 2 additonal characters to the effective length (the quotes)."
When you want to start an application, which one of these methods do you use:
1) Click Start, select the application you want to launch, click it.
2) Press Win+R, type in the full path and name to the application you want to launch, press Enter.
If you chose method #2, you’re very much a minority.
"Long filenames do not fit on an ISO 9660 CD filesystem"
I don’t really buy the ISO 9660 file system theory. We have this new space-age technology available now: it’s called a zip file. It’s used as a container for several other files – it even remembers the full name of them!
Jens: Windows has had that same feature since Windows 2000.
To all those claiming some sort of "ISO 9660" explanation… Linux distributions have shipped with long filenames on CDs for 10+ years now. If you use the Joliet or Rock-Ridge extensions the long filenames gracefully fall back to 8.3 names.
It’s a bit rediculous that in this day and age Windows might be hampered by an old CP/M limit. I mean come on, my Apple II could do 20 character filenames (with spaces) no problem, and Apple DOS came out before MS DOS did.
If a mistake was made, it was by the people using a file name alone for identifying a file. The Microsoft file should have embedded vendor/product information saying it’s from Microsoft and will be cryptographically signed by Microsoft. Similarly-named malware won’t be signed by Microsoft, unless Verisign slipped up *again* and issued another bogus certificate.
Long descriptive names are just as much an opportunity to malware makers as they are to legit software developers. Gee, why would you want to stop a file named "Critical Security Update Service.exe" for example?
Wednesday, April 12, 2006 12:17 PM by Mike Dunn
> Restricting filenames to 8.3 means the CD
> can be plain-jane ISO9660, not Joliet, which
> simplifies building the CD and the installer.
My intuitive feeling is the same, but I’m pretty sure I saw some 9.3 filenames on the screen during the text-mode portion of a Windows setup.
Long file names for system components are becoming a lot more common. Vista includes a bunch, not to mention .NET assemblies.
"I don’t know why they didn’t change "C:Program Files" to C:bin, but I’ll probably just do that myself."
Maybe because 99% of Windows users wouldn’t have any clue what that means? At least by naming it "Program Files", they make it pretty obvious to novice users what is contained inside.
"Unquoted values are just exploits waiting to happen"
They are if your code has an exposed surface. It gets really unhappy when you need to mix tools that started life 20 years ago on Unix together with tools that started life 15 years ago on Windows. And if it’s for a 100% in-house tool, you just don’t care about exploits.
As someone that spends a lot of time in the command prompt, I don’t much mind long descriptive names since the shell offers auto-completion (though they make many commands wrap to 2-3 lines), but spaces are a pain.
Hard links offer an escape hatch, but a tool that I use that displays hard disk usage as a treemap isn’t aware of them so I get skewed results.
All in all, it would help if Vista removed spaces from standard directories and used Users and Programs instead. And I wouldn’t object if various programs installed themselves in, say, ProgramsMicrosoftOffice13 instead of "Program FilesMicrosoft OfficeOffice13".
Dejan
"I don’t know why they didn’t change "C:Program Files" to C:bin, but I’ll probably just do that myself."
That wouldn’t really be appropriate, since there’s program data, libraries and more often than not configuration settings in Program Files. The traditional use of bin folders is just for binaries.
I’ll chime in against 8.3 naming – I frequently find myself stumped at what processes I’ve got running. Norton AV has one or two that aren’t obvious at all, and often drivers have some daft application lurking about with an arcane name ("khalmnpr.exe" = some useless thing for Logitech mice).
I don’t buy the iso9660 argument, since the files on them are compressed anyway (Windows now being a bit bigger than 650MB) – so why not roll them up into .cab’s or whatever is the flavour of the minute?
Why not "bin"? Because a bin is something you put garbage in.
BTW, about the cab files… dosx/miniwindows (q stripped down windows 3.11) was used to install 9x, so it couldn’t ever use LFN, also you could start setup from MSDOS 6 iirc. So even though all of this would be no problem with winnt/2k/xp, many files have to stay 8.3 for BC all the way to 3.11 basically.
"You’re right. That said, c:programs could have been a better choice. Or at the very least, they could have kept "c:program files" on every language. And they could have found something less aberrant than "c:program files (x86)" :("
I assume %PROGRAMFILES% is constant – one of course shouldn’t worry about the actual path. If nothing else, you stand at least some chance of it being d:program files.
Is the (x86) from the amd64 version of XP? It’s moderately awful, yes, but they probably needed something. I’ve got /lib32 and /lib64 on here, so MS aren’t the only ones doing this sort of thing, even if it is a bit less elegant.
what’s wrong with using "c:progra~1"?
I am sure there’s something but it has done me for years…
It was already taken, but that’s okay.
Thursday, April 13, 2006 1:07 AM by Dejan Jelovic
> And I wouldn’t object if various programs
> installed themselves in, say,
> ProgramsMicrosoftOffice13 instead of
> "Program FilesMicrosoft OfficeOffice13".
You mean Progra~1Micros~1Office13? Have you looked in your registry to see how many shorticated paths programs are still recording for themselves?
Thursday, April 13, 2006 5:48 AM by 0xF00D
> Or at the very least, they could have
> kept "c:program files" on every language.
You mean they could have kept "D:実行可能ファイル" the same in every language. (Not a perfect example because in Japanese Windows they do still name this folder in English instead of Japanese. But still, think about it, that would deliver what you asked for.)
The last time I tried to make my program’s file association registration use long path names, it broke opening files from Explorer through DDE, so I gave up, and even ended up renaming my EXEs so they were 8.3 or less.
"And I wouldn’t object if various programs installed themselves in, say, ProgramsMicrosoftOffice13 instead of "Program FilesMicrosoft OfficeOffice13"."
I would. Whats wrong with "Program FilesOffice13" or at a pinch "Program FilesMicrosoft Office13"? Why should I ever care about what company wrote the program? Half the time I can barely remember what the program was called, let alone who made it, and it’s really annoying having to look through several folders of random companies.
ICR wrote: "Why should I ever care about what company wrote the program?"
In most cases one company writes few product which can interact, have something common etc. For such purpose I feel practical to have anything from Adobe installed in "Adobe" folder etc.
Also, including manufacturer name minimizes name conflict. Especially in "obvious" names you can’t be sure that there is not another program with similar name. So I’d rather have C:Program FilesMicrosoftOffice and C:Program FilesCorelOffice than "Office1" and "Office2".
Yes, there are other solutions, but this one – if well used – is simple and works.
"8.1 is enough for everyone"
ISO 9660 can handle 32 chars, which is enough for Microsoft Protection Service.exe
PingBack from http://blogs.msdn.com/oldnewthing/archive/2007/04/02/2008357.aspx