View Single Post
  #140  
Old December 17th 17, 12:01 PM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Can a Macintosh person tell us how to change the name of a file?

Tim Streater wrote:
In article , Char Jackson
wrote:

On Sat, 16 Dec 2017 19:49:16 -0000 (UTC), Lewis
wrote:

In message Char Jackson
wrote:
On Fri, 15 Dec 2017 08:47:47 -0000 (UTC), Lewis
wrote:

In message Char Jackson
wrote:
On Thu, 14 Dec 2017 17:24:34 -0000 (UTC), Lewis
wrote:

In message Paul
wrote:
Wolf K wrote:
On 2017-12-14 00:24, Your Name wrote:
On 2017-12-14 03:16:11 +0000, Wolf K said:

On 2017-12-13 19:37, Your Name wrote:
[...]
... you can't rely on the OS to do that since a JPEG image
file

can
actually be opened in a text editor as the file's data, even if
it's rarely useful to do so.

That's what Open With is for.

Open With is near useless if you don't know what the file
actually
is. You'd have to Open With with every app you have until you
found one that could open it properly.

If we're talking about user convenience, I agree, showing a file's
type as part of the filename is very useful. (But IMO a
three-letter extension is too limited). There are many other
useful conventions,
eg, in icon design. These are converging on a common standard.

If we're talking about choosing a program to open a file,
extenions aren't needed. It would be easy to ensure that Open
With offers only programs that can open a given file without
reference to an extension. Just standardise metadata (eg, as a
series of slots, some which must
be filled, others for dev or user options). Easy peasy.

Have a good day,


Windows is not limited to 8.3.

Might not be in Windows 10 (though I think it is)

Nope. I can't remember what happened before XP, but at least with XP
through 10 you can create a filename with 200+ characters in the
extension, as long as you don't exceed the total number of characters
allowed.

Please reread what I said, that file will have an 8.3
representation in
the filesystem. This was true in XP and in Windows 7 and in Windows 8
(Hmm. now I'm not positive about Windows 8).

Let's try again. Windows filenames are not limited to 8.3.

Not in Win 10, not in 8.x, not in 7, not in Vista, not in XP. I'll stop
there because I don't personally remember when Long Filename (LFN)
support was introduced, but it was somewhere before that, possibly in
Win 95.

You are absolutely wrong.


OK, let's try a third time. It's clear that you're responding without
reading, or at least without understanding, so I'll keep it simple.

Windows filenames are not limited to 8.3.


So you're saying that ifI get a vanilla Windows system, one that no one
has dorked with, I can use long filenames with any and all software
that the system comes with. That sum it up?


Absolutists really crack me up.

There's 20 years of code in there, backward compatibility,
and an application can do anything it wants.

If I have an application from 1990, it may be hard-wired to 8.3
and fixed in its ways. And still be able to run on a modern OS.

To create this "exceptional" condition, install a 32-bit version
of Windows, then go searching through your old PC for
some 16-bit applications to test. Then, you should be
able to find some program that absolutely refuses
to use anything other than 8.3.

This is the problem with "bar bet" computer topics. It takes
a *lot* of analysis, to say what capabilities something
actually has.

Apple used to get caught on this too. As a Mac user, on a
number of occasions, they're release a Technical Note, where
it would be stated "System 7.5.3 supports 40 quadrillion byte
disk drives", even though such things didn't exist yet and
they couldn't physically have tested and verified it. Well,
the developer who wrote that gem, would look at one layer
in the code and say "yep, look how wide that data structure
is, 40 quadrillion will just fit". Yet, ignore some other
code path that "pinched" the limit. Three months later, they
would issue a retraction, with some lower limit stated. This
isn't stuff detected by testing large drives, it's anecdotes
circulating from people who know some other layers really well,
and can spot structures that are a limiting factor.

I ran into an example today. I had the Mac G4 fired up, and
it's running 10.2.x . I was saying to myself "I'm sure I've
had absolutely huge multi-gigabyte files on this thing". I
don't doubt the file system handles huge files. But, the
machine has a Classic VM as part of the package, and both
Compact Pro and Stuffit are Classic. When I needed to compress
some files, as part of cleanup on the G4, I noticed right away
in the Compact Pro menu, that a large file had a "negative"
file size listed. And based on experience, I said to myself
"uh, oh, a 2GB limit, signed 32 bit number, yikes". And I decided
to try compressing the file anyway, and I was greeted by an
appropriate error after about 10 minutes. So when dealing
with the Classic path through my OS, there are actually
other limitations.

If there was some way that "old" piece of code could have
interfaces to the "new" details of the file system, it
might indeed have been able to handle a 10GB file. And
sometimes, it's only by testing you discover the
"smallest piece of plumbing" in some software stack.

So to answer your question, for any reasonably modern
executable, which actually uses LFN APIs and uses data structures
big enough to handle modern path limits, "yes, it supports long
file names". If I install Win10 x32, which support 16-bit
executables, I'm sure I can find a crusty 16-bit executable
somewhere which has internal data structures only suited for
8.3.

Windows has *extensive* legacy support. This is why we can
have ClassicShell in Win8 and Win10, where the authors have
to write hardly any of their own menu code. The menus for
the older OSes are *still* in the modern OS. In Windows 10,
Microsoft released the OS without migrating all the dialogs,
so some of the dialogs *still* had a WinXP appearance to them.
How could they do this ? By not ripping out the old code.

When it comes to making absolutist statements then, due
consideration must be given to that huge pile of slime
trailing behind the OS.

If you installed a x64 version of the OS, *then* a lot of
pesky test cases will no longer run on the OS. Then
Char's statement is "correct", for that limited circumstance,
because a lot of legacy programs won't run in the x64 version.
The x64 OS only supports 64 bit and 32 bit executables.
And 32 bit executables with 16 bit installers, can't be
installed (because the installer bombs, not the program itself).

There are other nuances to file naming that haven't come up yet.
I can write programs with 8 bit character usage for file names,
or I can use the API for 16 bit (wide) characters. If I choose
to use the latter, I can have ç or è or é in a file name, and
not be limited to "English" c and e. For the little programs
I write, both options are available in the C library if I
want them. So if Tim asks the question, "can I use è in Windows 7",
then the answer would be "Yes you can, but not with that
poor program Paul wrote, where he used the wrong (8bit) API".
The OS allows a lot of stuff... that poor utility writing can
defeat the best of ideas.

Can I use é in 8.3 ? Probably not :-) They "hadn't invented
foreigners yet", when they did 8.3 :-)

Paul
Ads