45 replies to this topic 3 votes

[TRC]

hardbag, on 24 September 2011 - 09:14, said:

Not focusing on cores, I totally experience a faster file system, with 8.3 disabled and stripped. File operations like reading, writing, copying, moving, extracting, packing and even executing is faster.

Placebo effect.

[Aethec]

hardbag, on 24 September 2011 - 03:53, said:

No, MS left it just because they were lazy.

You just lost all your credibility.
Microsoft programmers are not lazy, stupid, bad, idiots, or whatever - someone who pretends to know an OS better than the guys who designed it should be ignored.

Unless you are willing to create an easily reproducible benchmarks which clearly shows the performance gain you are talking about..

[TRC]

To be fair there are certain situations where this is helpful and there are no drawbacks. Say you have thousands of media files on an external drive for example. Disabling short file names will probably improve performance in this situation, and there is certainly no need for your music, video files or photos to have 8.3 file names. They would also be disabled on servers obviously.

That said, I still don't recommend disabling it on your system drive. There's really going to be no noticeable improvement and its possibly going to break things; yes even on a modern x64 system. For example I just scanned my system drive with fsutil and it reported a large number of registry entries using short file names. It's not worth taking a chance on messing things up when you aren't going to see any real difference.

[neo158]

There's no need to "tweak" anything in Windows anymore. I keep saying this, Microsoft's programmers know what they're doing so if they left something in the OS then they left it in for a very good reason.

It's not safe to strip anything out of Windows, EVER. Remember the people who had issues with the Vista service packs, most of them used vLite to strip out what they thought was "bloat" and ended up crippling Windows. That's exactly what this "tweak" will do, you may not notice it now but I guarantee that at some point issues WILL come up.

The other thing to remember is that some 32-bit installers still call on 16-bit code and, possibly, 8dot3 filenames even on 64-bit systems.

Microsoft products run on a variety of systems and run a wide range of software, so unlike Apple they can't just strip out legacy code whenever they want.

@hardbag If you think you know better than the programmers that created Windows then go work for Microsoft, otherwise STFU.

[REM2000]

The whole question of stripping files can be easily solved by someone running a before and after HDD benchmark, i would but i don't want to run the command on my Win7 machine and i don't think a VM will be an accurate test.

[omnicoder]

hardbag, on 24 September 2011 - 06:00, said:

I think MS themselfes say that stripping improves performance. The fsutil 8dot3name strip was introduced in Server 2008 and in Win 7 and it is a clear indication that the backwards compatibility will be ditched. And about the installers, none of the 16-bit installers work in x64 no matter how 32-bit the program itself is. Vista completely changed the installers to x64/x86 and Vista also changed - forced - how applications were and are written.

You seem to be forgetting the part where Microsoft made custom Application Compatibility bootstrappers starting with Vista x64 to allow 16-bit installshield setup components to continue to operate... using 8.3 filenames obviously.

[neo158]

omnicoder, on 24 September 2011 - 14:32, said:

You seem to be forgetting the part where Microsoft made custom Application Compatibility bootstrappers starting with Vista x64 to allow 16-bit installshield setup components to continue to operate... using 8.3 filenames obviously.

Exactly, hardbag seems to forget that Windows isn't like MacOS where they can just strip out legacy stuff with a minimal impact on users.

[hardbag]

When I wrote that 8.3 was left because MS was lazy, I meant that. The poster who quoted should of quoted the whole post; 8.3 names are a cheap gum and glue; they could of recode x64 API but they left much of it like 32-bit API. Yes it is x64 but a lot of x86 code.

And as I and many said, stripping 8.3 will be good to go for many, but some users need them.

After stripping 7 installation there were 4 reg keys (pointing to 4 .tmp files) that could not be stripped because of exceeding 260, but that does not mean that the file system couldn't work with those files or delete them. With stripping, there is still compatibility.

The Vista compatibility was made because everybody was surprised how many installers were 16-bit. Now Vista completely changed how applications are written, no more 16-bit and no more crap code that could execute in XP. Unless you aren't using 6+ years old programs or devices (pc components do not count) it is safe to strip 8.3.

I have made quite a few 7 installations, stripped, installed service pack1, installed programs, installed games... No where anywhere no absolutely no problems. Of course I can't demonstrate the setups of thousands or millions of users, as said, for some, 8.3 could be needed.

But really why the 8.3 is still in the API is because the x64 API is a copy of 32-bit therefore it's just gum and glue, while they could of just recode 260 max path. That said, as earlier, despite stripping, 8.3 compatibility still exists - NTFS just does not automatically create 8.3 names and is able to srip 8.3 from files the OS does not see point of having.

[Udedenkz]

Going to test this.

My hard drive is ***** on my notebook.

Edited by Udedenkz, 24 September 2011 - 16:56.

[TRC]

hardbag, on 24 September 2011 - 16:43, said:

When I wrote that 8.3 was left because MS was lazy, I meant that. The poster who quoted should of quoted the whole post; 8.3 names are a cheap gum and glue; they could of recode x64 API but they left much of it like 32-bit API. Yes it is x64 but a lot of x86 code.

Well of course there is x86 code, we are still using x86 processors. As for the 32-bit parts they left them in for a good reason; compatibility. People have come to expect that all of their existing software will continue to work with new versions of Windows. Microsoft couldn't just get rid of 32-bit support. That would be insanity. I don't know if you've noticed but even today the majority of software is still 32-bit. Microsoft is not lazy; they know what parts of the OS are still necessary.

As for short file names, they have nothing to do with the 32-bit API. They're a part of NTFS and they're still needed.

[hardbag]

disable or not and strip or not, there still is compatibility. for example, on this location registry keys affected by 8.3 are 1000+, but those are all Office14 related and the apps work just fine and have worked just fine.

[Udedenkz]

hardbag, on 24 September 2011 - 17:00, said:

disable or not and strip or not, there still is compatibility. for example, on this location registry keys affected by 8.3 are 1000+, but those are all Office14 related and the apps work just fine and have worked just fine.

This resembles the XP vs 7 debate.

[HawkMan]

hardbag, on 24 September 2011 - 16:43, said:

Unless you aren't using 6+ years old programs or devices (pc components do not count) it is safe to strip 8.3.

Before you start giving people more ridiculous advice on tweaks that can break their OS while saving at most a couple of nanoseconds a day you should learn how to use, or rather not use double negatives. It's the second time this thread you've basically said the opposite of what you mea because you're trying to be clever and screw you the double negatives.

[soldier1st]

This tweak can, in certain but rare situations, be helpful but otherwise it is not worth messing with.
hardbag: Provide some actual proof before telling users to change it but if you can't do that then why waste your time?. My advice is to just leave it alone and move on.

[Wakers]

Definitely advise people not to bother with this.

There's a far greater chance that it screws something up than it making any noticeable difference.

Next he'll be telling you to turn superfetch and indexing off.