Hacker News Reader

Comment by userbinator | Hacker News Reader

Only if you want to be trendchasing rather than letting backwards compatibility take care of itself...

I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 because it's fast and enough for what they do. Takes <250MB of disk space, and the self-contained binaries it generates will work on any version of Windows starting at Win95.

Long file paths: Azure, OpenSearch, and ~90 other open source projects have to document how to enable long file paths on Windows because the default is a ~255 character limit.

Personally, I think 260 is long enough and plenty to work with, while at the same time discouraging the ridiculous verboseness that seems to have crept into "modern" software. Then again, I stay away from .NET, VSCode, and the like. I am reminded of this post by Raymond Chen:

https://devblogs.microsoft.com/oldnewthing/20070301-00/?p=27...

View on HN

My issue with the 260 character limit is that it can easily be reached through normal usage, and can lead to some really strange behavior.

* File cannot be moved into a subfolder.

* Folder can be renamed, after which a file contained within it is inaccessible.

* File on a network drive may be accessible by some users, but not others. For example, one user may access the drive with the longer network name, while another has mapped the network drive as Z:\. A filename may exceed the 260 character limit for the first user, but not for the second.

* Cannot delete a folder, because it contains a file with a long name.

My experience may be biased due to using a program that recorded metadata in a filename, taking the majority of the 260 characters available in just the filename, but with the number of failure modes, I still don't think it is reasonable to have such a small limit.

Exactly. I believe NTFS has supported 65535-char paths since, forever? But last I checked, even simple apps like Win10 Notepad will fail to open them.

What is the point of the registry/gpedit setting to enable long paths system-wide -- when so much of Windows doesn't support it? File Explorer is really showing its age.

Has any of this improved in Win11?

Yikes, 260 character path names can be a real pain. Please support sensible path names or at least tell me why you can't read or write to a file. Often you just get a "can't write to that file" error message, or worse, "forbidden" so you spend an hour trying to debug the mess that is folder permissions on windows.

I'm not going to convince you to change your tool chain, userbinator, but for the sake of the discussion: Once you have multiple projects going on, with multiple components, and then those components have a small directory structure themselves, you can easily reach 260 characters. Add to that, if theres data coming from another org, a long file name can be very helpful to keep track of what it is (and don't forget 10-12 characters for a date!). And finally, the nail in the coffin: most users don't think about path names, I struggle to get people to not put periods in their filenames which messes with some tooling, how am I going to convince the guy in finance who gave me this data that he should use short file names? Should I modify the file name and make it untracable?

ETA: The "if you have to ask you've messed up", I don't ask, I expect and then get annoyed it broke. I had 10,000 files collected into a folder. Why can every other program tell me the list of files in an instant but windows explorer crashes (the whole desktop environment) because I opened that folder to see it. I'm not meant to do that? Then why can the kernel, the disk, the file system, and all other programs handle it with ease?

The 260 path limit is a pain for organizing media. It's not surprising most applications/games store their media in giant blobs instead of just individual files. This makes software updates a pain since it requires users to download the entire blob if you can't diff the blobs or if the diff corrupts the blob due to mismatched implementation versions.

giant blobs is a much faster solution than thousands of individual files. NTFS per-file overhead is significant.

Mostly blob based game assets is a system motivated by consoles, then reused on pc to keep build process consistent.

You'll see older pc centric game engines use loose files. With the advent of ssds on consoles we might see a return to bunch of files approach as it keeps patches smaller.

Steam and EGS updating handles binary diffing wonderfully. While consoles, not so much. Specifics are NDA of course but I bet any game dev reading will know who I am talking about when I say: "platform x has a horrible diffing algo yet requires approvals for updates over size Y". If I could ship a loose filesystem and get reasonable load times I would just for the update package advantage.

> Mostly blob based game assets is a system motivated by consoles, then reused on pc to keep build process consistent.

No, packing individual files into archives makes sense on PCs too due the native filesystem usually having a much bigger per-file storage overhead as well as non-negligible open() times - the second is especially true for Windows with "Anti Virus" software installed.

> You'll see older pc centric game engines use loose files.

Some maybe, but packing game assets into archives is as old as Doom and has been the norm all this time.

> Steam and EGS updating handles binary diffing wonderfully.

Steam handles binary diffin now, but it was not that long ago that it re-downloaded the whole changed file.

Not enough. Between path limits and "this file is in use by another program" nonsense I regularly ran into while developing on Windows, I switched away and never looked back.

That cuts both days, a Windows developer trying to port a project to Linux would be justified in concluding the filesystem locking semantics are horribly broken and non-existent.

I came from windows and found fewer problems when working on Linux. The problem with deleting files is something everybody will run into at some point. I don’t think what you describe is as common. I have never had it or heard it described as a problem when working in an organization which made software running on Linux and Windows.

The path separator, drive letter and text file line endings get me. But back when I switched to Linux for development it was the very slow file searches on Windows. I am fine with either macOS or Linux. Not windows.

> I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6

Doesn't that tie you to a really old C runtime, and aren't security holes often found in the C runtime?

It links dynamically to msvcrt.dll which is updated as part of the os. I believe it still gets updates as long as it doesn't break the ABI. Modern vc++ links with the universal CRT which is an independently updated msvcrt distribution.

msvcrt.lib includes things other than direct imports to msvcrt.dll; bugs in that code are going to be linked into your binary at compile time.

Note: https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=12...

Of course he has to toe the company line. But the truth is far simpler.

Similar problem to Java applications directly accessing internal JDK packages, and then breaking once access was restricted.

Both static and dynamic linking to a newer runtime (as they are versioned) will break backwards compatibility. For newer OS features you need, you can always GetProcAddress() the needed functions at runtime instead. The real downside to staying on VC6 is all the compilers' ancient optimizations, or lack thereof.

A quick Google check seems to yield only one CVE in msvcrt.dll in 2012, wouldn't call this "often" especially for a DLL which is likely among the top 5 most used in the world

It's incredibly fitting that all the links on that post are 403 Forbidden

That's Microsoft being (the new, not the old) Microsoft... they seriously fucked up the MSDN documentation when it was migrated to docs.microsoft.com, so I'm not surprised that a similar thing happened to the blogs:

https://news.ycombinator.com/item?id=20351358

they knew they would and they advertised that fact, and made blog and content owners migrate their stuff if they wanted it kept. many chose not to. those are the people you should be angry with.

that's quite a take.. expecting previous article writers to manually migrate their stuff is just as good as killing it.

the blog authors knew the content was their own responsibility going in.

"quite a take" f u

Or they could've just migrated it for them, and kept everything running.

I'm told that MSDN blog posts were owned by the authors, not Microsoft.

it wasn't Microsoft's content to move.

movement to docs.microsoft.com meant giving copyright to Microsoft, and not everyone chose to do that.

Many of the people were no longer at Microsoft when the migration happened, but their blogs were no less useful for that.

And some weren't even alive. Michael Kaplan and his amazing blog about internationalization and Unicode comes to mind - thankfully, other people have archived it: http://archives.miloush.net/michkap/archive/

Microsoft has never really "got" the idea of URLs. The only links to Microsoft stuff you should expect to still work properly in a year from learning them are in the form of an aka.ms alias which is publicly advertised.

Anything else, maybe it's a brief article explaining a technology you care about, next week somebody replaces that with a video blog of some people who don't really know much about it but are sure they'll become world experts over the next months and years - and you're invited on their journey, then the blog becomes a wiki, then it becomes an exciting new user-led forum, and then... it's a 404 because they were re-assigned to a different project and all knowledge was destroyed.

Raymond used to be just one of hundreds, maybe thousands of Microsoft bloggers. Then one day Microsoft decided blogging was not on brand and it just blowtorched all the blogs except a few very popular ones like The Old New Thing.

And I've found aka.ms links, referenced in a current Microsoft help page (KB article?), that were broken...

> Microsoft has never really "got" the idea of URLs

I immediately thought of Teams links.

At least make another URL shortener like teams.ms and pass the URL through it before giving it to me.

I wonder if I it's possible to create a file in Windows named after a MS teams link as it's so long.

Is it so difficult to generate a short UUID?

Zoom does it with numbers.

Google Meet does it better with hyphen separated 10 letters so you can even read it out or just remember for 5 seconds before typing it elsewhere.

And even there they deleted all the comments.

1) the URLs are simply missing a "b/" in the path to map to saved copies in the Web Archive, and 2) the comment system switched to requiring JS around 2011 so only comments from before then archived properly (>.>) but the threads are all from 2003-2006 so theoretically there are probably no new comments anyway.

nesting windows more than 50 levels deep: https://web.archive.org/web/20110623211503/http://blogs.msdn...

nesting menus more than 25 levels deep: https://web.archive.org/web/20110623211552/http://blogs.msdn...

creating a dialog box with more than 65535 controls: https://web.archive.org/web/20110623211515/http://blogs.msdn...

the maximum number of threads a process can create: https://web.archive.org/web/20110628235212/http://blogs.msdn...

the maximum length of a command line: https://web.archive.org/web/20110707074737/http://blogs.msdn...

the maximum size of an environment block: https://web.archive.org/web/20110623211524/http://blogs.msdn...

the maximum amount of data you can store in the registry: https://web.archive.org/web/20070302025026/http://support.mi... (the live link http://support.microsoft.com/kb/256986 still works perfectly, so here's the view as of ~the post date of the article)

if you have to ask, you can’t afford it: https://web.archive.org/web/20080607185547/http://listserv.l...

> Only if you want to be trendchasing

Cross-platform compiling is not a trend, it is one of the only two sane solutions to supporting customers.

The other is browser-based SaaS. But now you have two problems, to paraphrase Zawinski.

> Only if you want to be trendchasing rather than letting backwards compatibility take care of itself...

> I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 because it's fast and enough for what they do. Takes <250MB of disk space, and the self-contained binaries it generates will work on any version of Windows starting at Win95.

I share your view about the unmatched backwards compatibility of Win32 binaries, but I wouldn't let a 24-year old compiler like MSVC6 near any new project. We are talking about a compiler here that doesn't even support the C++98 standard, let alone all the basic features for writing safe software (stack cookies, _s APIs, smart pointers - just to name a few).

When I needed reliable self-contained binaries and backwards compatibility, I switched to VS2019's clang-cl compiler and ported their libc++. Together with winpthreads from the mingw-w64 project, this enabled me to write software using even C++20 features, but still maintain compatibility down to Windows NT 4 from 1996. If you're interested, it's all documented here: https://colinfinck.de/posts/targeting-25-years-of-windows-wi...

That's really cool, was wondering how hard it would be to make libc++ play nice with XP - currently I still use MSVC 2017 for those builds but that won't get newer language features and I am planning to move to Clang anyway. Do you know of any effort to go even further back and support pre-NT Windows with a modern C++ compiler?

It's depressing how fast and responsive MSVC6 runs on today's hardware compared with the current version of Visual Studio.

It started after they ported UI to WPF. Compare VS2008 and VS2010 if you have the time. I remember using both on a cheap laptop when VS2010 first came out, and was simply incomparable.

Yes, absolutely true. vs08 was their last fast ide.

Dang I don't want to even imagine the amount of bugs and how bad the codegen is compared to newer compilers.

> Only if you want to be trendchasing [...] > still using MSVC6

That's some strange logic - you expect someone wanting to compile things for windows to somehow discover a 24-year-old compiler using some older version of C/C++ and to conclude that, despite modern norms, it still works, is still legally available and still produces working binaries.

And if they don't somehow glean all of the above, you say they're trendchasing, rather than just not knowing and using something two-decades obscure and possibly illegal.

Reply on news.ycombinator.com