Re: Windows Media Player executes WMF content in .MP3 files.

• Previous message: Alun Jones: "Re: bait server"
• In reply to: Rahul Dhesi: "Re: Windows Media Player executes WMF content in .MP3 files."
• Next in thread: Alun Jones: "Re: Windows Media Player executes WMF content in .MP3 files."
• Reply: Daniel R. Tobias: "Re: Windows Media Player executes WMF content in .MP3 files."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: alun@texis.com (Alun Jones)
Date: Sat, 02 Mar 2002 21:34:44 GMT

In article <a5rdvi$d8e$1@samba.rahul.net>, c.c.eiftj@01.usenet.us.com (Rahul
Dhesi) wrote:
>alun@texis.com (Alun Jones) writes:
>
>>UNIX shells just check the mode bits and, if they allow
>>>execution, will ask the kernel to do the exec. The kernel looks at a
>>>predefined magic number and them decides how to execute the file. The
>>>filename is irrelevant.
>
>>Yes. This is my point....
>
>>Just the same way that Media Player ignored the file name, and used the file's
>>content to determine to play it as a WMV file.
>
>Alas, I think you are mixing up two issues, which is why we are arguing
>at cross-purposes.
>
>In the UNIX world, how a file is executed always depends on any magic
>number contained within it, and never on the filename. So the user is
>never surprised by the filename -- he knows it does not determine how a
>file will be excuted.

You have a much smarter user than I dealt with in my time with Unix users.
Granted, they were Project Managers, but they used Unix, and they expected
files with ".txt" in them to be text-only. We actually had demands from some
of the Unix administrators at engineering shops to give our shell-scripts
"extensions" of .sh, rather than leaving them extensionless. Obviously, this
education is not in everyone's DNA.

>In the Microsoft world, sometimes the filename counts, sometimes a magic
>number counts, sometimes both count in some combination, and the user is
>never sure about what is going to happen.

It's not that random - and this seems to be the point that you are missing.
In the Microsoft world, the file extension counts to decide what operations
the shell will offer on that file. The default among these operations,
usually "open", is what happens when you double-click on the file. The other
operations can be seen by right-clicking on the file. So, when you're talking
about double-clicking a file, the extension part of the file name _always_
counts, and _only_ chooses which application is launched.

Now, as far as most applications are concerned, there is no difference between
double-clicking a file, and providing it as an argument to the application's
executable in a command. Indeed, in many situations they can't tell the
difference, because there is none. So, the applications will generally ignore
the file name and its extension, and will go by the contents of the file.
[Or, if it's a one-format application, it'll assume that the file is in its
native format, and hurl in some manner when it finds any discrepancy]

>It's a workable solution to always use the filename and never a magic
>number within the file -- the user will not be surprised.

The user is not surprised, because Explorer always uses the filename (the
extension part, at least), and never a magic number, or any other part of the
content.

>It's a workable solution to always use the magic number and never the
>filename -- the user will not be surprised.

The user is not surprised, because the application will use the contents of
the file to determine what is in it.

>Unfortunately Microsoft doesn't do either one consistently, but mixes
>them in unpredictable ways. So if somebody sends you a file whose name
>ends in .doc, you cannot be sure whether your favorite Microsoft OS will
>treat it as a document or as some unpredictable executable program based
>on the contents of the file.

That's a ridiculous assertion. If somebody sends you a file whose name ends
in .doc, you can be sure that your favourite Microsoft OS will open it with
whatever application it opens any other .doc file with. And the application
will analyse the file to see if it can handle the format, and will open it in
whatever view is appropriate for that format. It will not open a .doc file as
an executable. You appear to have been confused (as have many users) by
viruses that distribute themselves as filename.doc.pif or filename.doc.shs, or
filename.doc.scr, into systems where the shell has been left at its default
setting of hiding those .pif, .shs or .scr extensions. Try it. Rename an
executable, or a batch file, as .doc, and double-click on it. You won't see
it run (unless you've defined the association for .doc to be an application
that runs executables).

>The situation is made worse because Microft software sometimes hides
>selected portions of the filename. This terribe behavior can be
>switched off, but is on by default. So if somebody sends you a file
>called x.txt.exe, Microsoft might show it to you as x.txt, leading
>you to believe it's a text file. So now the situation is even
>worse:

On this we agree. Hiding the extension, when that in itself is important
information as to how the system will react to you double-clicking the file,
is really unforgiveable.

> - is it x.txt.exe, an executable?
> - is it x.txt, a text file?
> - is it something else entirely, based on a magic number contained
> within it?

Of course, in an Explorer listing, the icon and the "file type" column will
give it away (though the icon is less reliable, since executables can contain
icons, and Explorer will display those).

>A user can never predict how a Microsoft environment will treat a
>given file.

Rubbish. They most certainly can.

>This is why there are so many security problems related to Microsoft's
>software, including the infamous Internet Explorer program and other
>programs that use the infamous Internet Explorer rendering engine.
>
>The situation is not helped by the fact that people like you, who ought
>to know better, try to make the situation sound better than it really
>is.

No, I am well aware of how bad the situation is. I find that my attempts to
get people to correct _real_ flaws are stymied by my reports being surrounded
by the cacophony of people crying "wolf" about imagined, or misheard, errors
that don't exist, and that they have not bothered to check about. That is why
I try and correct mis-statements, because I perceive that they get in the way
of my trying to persuade Microsoft to fix _real_ flaws.

Alun.
~~~~

[Note that answers to questions in newsgroups are not generally
invitations to contact me personally for help in the future.]

-- 
Texas Imperial Software   | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place   | http://www.wftpd.com or email alun@texis.com
Cedar Park TX 78613-1419  | VISA/MC accepted.  NT-based sites, be sure to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT.

• Next message: Rahul Dhesi: "Re: Windows Media Player executes WMF content in .MP3 files."
• Previous message: Alun Jones: "Re: bait server"
• In reply to: Rahul Dhesi: "Re: Windows Media Player executes WMF content in .MP3 files."
• Next in thread: Alun Jones: "Re: Windows Media Player executes WMF content in .MP3 files."
• Reply: Daniel R. Tobias: "Re: Windows Media Player executes WMF content in .MP3 files."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]