Nick Sabalausky wrote:
"Don" <nos...@nospam.com> wrote in message
news:ikj7n9$1sg2$1...@digitalmars.com...
Steven Schveighoffer wrote:
On Tue, 01 Mar 2011 09:01:49 -0500, Nick Sabalausky <a@a.a> wrote:
People don't always realize it, but Windows really is the same way. It's
really only the user-level applications like Explorer that ever care
about
"extension", and even then the extension is always just "everything
after
the last dot in the filename". Anything beyond that is merely tradition
and
convention. The only real difference is that windows has no standard
mechanism for looking at the content of the file to help determine its
type.
No, it tries hard to make it look that way, but it's evolved from a system
where extensions were fundamental.
Even now, an 8.3 filename still exists for every file.
The existence of an 8.3 fallback doesn't really have any bearing on it. And
neither does pedigree. If there is still a fundamental distinction with
extension, it's nothing more than a detail of how the filesystem spec
defines its data storage and completely abstracted away by the filesystem
driver.
Name one case in windows where some sort of distinction between filename and
extension actually makes a real tangible difference versus unix, that
doesn't merely amount to convention (there's zero technical hurdle in the
way of a windows program considering ".bashrc" to be extensionless) or
manually re-implementing part of the filesystem spec (heck, unix has FAT32
and NTFS drivers, too).
??????
It ALWAYS makes a difference. For example, only .exe and .com files are
executable.
On unix, the filename is just a name. Nothing more. By contrast, the
Windows extension actually matters. They're completely different.
No, it's not "just a convention". It's completely enforced. You cannot
execute a file if it has the wrong extension.
On Windows, the extension is used to identify the file. Just as unix
uses the magic number at the start of the file.