6/2/2026 at 5:32:54 PM
Windows really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes. Or better yet, just switch everything to full POSIX.In powershell everything is much better than cmd, but it's just not enough.
WSL is generally great, but there are annoying downsides. I often get "catastrophic" crashes and the zone identifier files drive me nuts. Plus it takes so much longer to start VSCode when connecting with WSL, and now you've got two file systems. WSL1 was in many ways better than WSL2 for these reasons.
by jakegmaths
6/2/2026 at 6:10:04 PM
Windows is also a rare bird in UTF-16."UTF-16 is used by the Windows API, and by many programming environments such as Java and Qt. The variable-length character of UTF-16, combined with the fact that most characters are not variable-length (so variable length is rarely tested), has led to many bugs in software, including in Windows itself.
"UTF-16 is the only encoding (still) allowed on the web that is incompatible with 8-bit ASCII. It has never gained popularity on the web, where it is declared by under 0.004% of public web pages (and even then, the web pages are most likely also using UTF-8). UTF-8, by comparison, gained dominance years ago and accounted for 99% of all web pages by 2025."
by chasil
6/2/2026 at 6:56:44 PM
NT shipped with USC-2 as UTF-8 (and -16) did not yet exist. USC-2 naturally translated to UTF-16, hence the choice. NT/Win32 is also designed for fixed-with code units, something UTF-8 doesn't support.You can use UTF-8 on a per-application basis, within limits.
https://learn.microsoft.com/en-us/windows/apps/design/global...
Conversely, UEFI is UTF-16 only, thanks to Windows.
UTF-8 only would be an ABI breaking change, so that's not going to happen. We don't want the NT kernel to end up like Linux, after all :-)
by 0x1d7
6/2/2026 at 7:25:35 PM
> UTF-8 only would be an ABI breaking change, so that's not going to happen. We don't want the NT kernel to end up like Linux, after all :-)I think you're making a joke, but it still doesn't make sense. Linux does avoid breaking changes to its userspace ABI
by yjftsjthsd-h
6/2/2026 at 9:07:33 PM
Linux kernel's ABI/API surface is completely byte-based and is tiny compared to Win32 API. The stable ABI of Windows is strictly in the user space and it covers the entire useful operating system. Don't forget that glibc isn't that ABI stable nor anything that goes all the way up to systemd/X11/gettext/Wayland/cairo/GTK/Qt/glade/Pipewire/xdg. Nothing equivalent in Linux environment is stable, especially compared against Win32 system libraries.You encounter encoding requirements not in kernel system calls but in more user-facing sides of the OS. So your comparison should include all the userspace components of a Linux system (e.g. gettext), if you're considering the places where you encounter actual Unicode string-based operations where UTF-16 comes into play in Windows.
ALL OF THE equivalent Windows libraries (user32.dll, kernel32.dll, ws2_32.dll, shellex.dll ...) to the Linux ones I counted above and more are ABI and API stable.
by okanat
6/2/2026 at 9:26:46 PM
See, I was sympathetic to that view, except that they specifically posted> We don't want the NT kernel to end up like Linux, after all
(Emphasis mine)
And that's... The one part of the OS where Linux is ABI stable.
by yjftsjthsd-h
6/2/2026 at 11:01:12 PM
I think they didn't mean Linux as in the kernel sense but in the overall "Family of OSes and ecosystem with very unstable APIs" sense.by okanat
6/2/2026 at 6:20:09 PM
Additional Detail: it is specifically utf-16 little endian when a byte order mark is not used, which is the opposite of the recommended choice of big endian in the RFC.Worse are the byte order marks required to support both endians that end up in files.
by zahllos
6/2/2026 at 8:28:36 PM
The development of Windows NT based on UCS-2 precedes the RFC by roughly a decade, and little-endian was the natural choice for the Intel PC platform. Obviously the endianness had to remain the same when UCS-2 was extended to support UTF-16.by layer8
6/3/2026 at 10:56:37 AM
Also true. The BOMs though are annoying.by zahllos
6/2/2026 at 6:16:23 PM
UTF-16 is also used by C#, Java, and JavaScript. Since JavaScript is so widely adopted, I wouldn't call it a rare bird. Not necessarily used when reading or writing files, but it's what's used internally for the strings. As a result, your strings use UTF-16 surrogate pairs to represent characters outside of the basic multilingual plane (such as Emoji).by Dwedit
6/3/2026 at 12:41:43 AM
UTF-16 is the internal format of the ICU library (International Components for Unicode, the support library from the Unicode standards people) which is a common way to add "full fat" Unicode support to a programming language. This has knock-on effects everywhere. If you're using ICU, you either use UTF-16, too, or you constantly convert back and forth every time you interact with ICU. You're often best off using UTF-16 in memory and only converting to UTF-8 when you write files or transmit over the network.by electroly
6/2/2026 at 6:55:49 PM
> Windows is also a rare bird in UTF-16.Web browsers use UTF-16 internally. So Windows isn't even largest "platform" that uses UTF-16.
by wvenable
6/2/2026 at 8:45:03 PM
> Windows is also a rare bird in UTF-16.an interesting tidbit, some Windows kernel developer realized that most registry keys are ascii anyways so they could save up to 50% space simply by storing the name as ascii. The flag is called "compressed name" and they will pad with 0x00 when reading the name to make a proper utf-16 string.
by bvanheu
6/2/2026 at 5:58:38 PM
No worries, eventually Xenix will make a comeback.You cannot ditch CRLF, Microsoft isn't Apple.
Windows accepts backslashes and forward slashes, only old applications that manually search for one of them get it wrong.
by pjmlp
6/2/2026 at 5:48:00 PM
> Or better yet, just switch everything to full POSIX.Really not possible as most of POSIX semantics arise naturally from the kernel (or are enforced/executed at the kernel level). Windows technically provides some of them (or semantic equivalents) so you could make something work, but in order to do a full port you'd need to strip out too many concepts for it to be worthwhile. For instance the idea that "everything is a file" or the single root filesystem layout (which iirc is segmented deeply at the kernel level).
by rfgplk
6/3/2026 at 8:00:19 AM
> Really not possible as most of POSIX semantics arise naturally from the kernel (or are enforced/executed at the kernel level).The kernels undoubtedly take different approaches. But there's nothing in NT that strictly prohibits POSIX compatibility layers. As we see with the many compatibility layers that have existed for Windows over the years.
> For instance the idea that "everything is a file"
POSIX doesn't have a concept of "everything is a file". That's Plan 9. UNIX and POSIX actually made numerous concessions here and there are plenty of constructs that are not exposed as a file.
Windows does already abstract a few primitives as files too. In fact even DOS has the concept of device files, though in typical Microsoft fashion, it's implementation was a clusterfuck that took MS 40 years to fix.
> or the single root filesystem layout (which iirc is segmented deeply at the kernel level).
NT uses an object system for filesystem objects, but it still has a root. As you can see in the WinObj (eg screenshot below)
https://learn.microsoft.com/en-us/sysinternals/downloads/med...
The C:\ convention is really more there for compatibility with DOS-lineage software but the underlying filesystem APIs work fine with NT objects.
For example, C:\foo.txt might be equivalent to \Device\HarddiskVolume3\foo.txt
In this regard, it's similar to how POSIX has a database of inodes and the filesystem hierarchy is actually just an abstraction that sits on top of that
by hnlmorg
6/2/2026 at 5:52:10 PM
> ... Or better yet, just switch everything to full POSIX.Interix[0] did a pretty good job of this, but MSFT killed it. I was compiling GNU tools w/ GCC and running bash under Interix back in in 2000 under Windows 2000. It was grand.
by EvanAnderson
6/3/2026 at 6:32:42 AM
The experience with Windows Services for UNIX wasn't that great, so yet another good product killed via acquisitions?I only know it post acquisition.
by pjmlp
6/2/2026 at 6:50:16 PM
I ported a million-line, OpenGL/Motif application using Interix (before it was acquired). Indeed, it was grand.by dekhn
6/2/2026 at 6:06:24 PM
They might as well create a new OS with a different name, because none of the existing applications will work, and no enterprise customer will use it.by fg137
6/2/2026 at 6:17:26 PM
Most (everything?) on Windows actually works with forward slashes. However, much of the tooling will overwrite your version with a backslash wherever it can.by 0cf8612b2e1e
6/2/2026 at 7:01:46 PM
At which layer? dir /w, for example, is never going to list the contents of \w.by badc0ffee
6/3/2026 at 5:36:39 AM
All the layers, except applications where devs still look for the wrong slash manually.OSes and modern programming languages have APIs for file navigation for a reason.
On Windows this implies old applications from another era, good old command window, or people that don't know better.
by pjmlp
6/2/2026 at 9:24:01 PM
The kernel and ntfs does not care about slash direction. Specific programs like dir might though and honestly if you're on windows just use powershell and avoid legacy cmd stuff.by vips7L
6/3/2026 at 5:38:29 AM
Additionally on programming languages use the apis for path management, instead of explicit looking for the \ or / characters.by pjmlp
6/2/2026 at 8:00:29 PM
Use powershell.Get-ChildItem /w
by recursive
6/2/2026 at 11:24:40 PM
Too many keystrokes, people won't use it.by jimjimjim
6/3/2026 at 4:01:12 AM
https://learn.microsoft.com/en-us/powershell/module/microsof...by ranger_danger
6/3/2026 at 5:25:25 AM
Aliasesby pjmlp
6/2/2026 at 11:50:59 PM
gci /w than?by yyyk
6/2/2026 at 5:45:10 PM
Don't think this will ever happen, especially since this is Microsoft you are talking about [0]by cardboard9926
6/2/2026 at 5:48:45 PM
On Windows, I've mostly avoided CRLF by configuring text editors and git to use LF, and writing text files in binary mode.The only places that still forced CRLF were batch files and clipboard.
by Grom_PE
6/2/2026 at 5:56:12 PM
> I've mostly avoided CRLF by configuring text editors and git to use LF,That has been my experience as well. I can't remember the last time I had an issue related to CRLF.
by wnevets
6/3/2026 at 10:03:04 AM
The only times I can remember having line-ending issues is using GNU's tools on Linux. Every Windows tool I can remember using accepts both CRLF and LF.by Measter
6/2/2026 at 6:22:49 PM
Yesterday for me was the last time. Visual studio 2026 default to crlf I think maybe and I have autoctlf in git turned off. I should probably turn that back on.by pipes
6/3/2026 at 1:21:54 AM
I think you want a .gitattributes file where you set the EOL of the file types you care about. And you might want to try autocrlf=input.by dataflow
6/3/2026 at 8:11:07 AM
Thanks for this :)by pipes
6/3/2026 at 2:51:51 PM
does visual studio support editorconfig.org? I use end_of_line = lf for all my projectsby wnevets
6/2/2026 at 8:32:38 PM
A lot of tooling that generates or transform text-like files (e.g. XML) outputs native line endings, which in case of Windows is CRLF. Depending on what you do, it’s almost impossible to avoid that.by layer8
6/3/2026 at 12:54:33 AM
>> Windows really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes.{To the extent such stuff is pragmatic:} I think we should switch to Pascal-style strings everywhere, and then have no need for having special-purpose characters like path separators (a path now being a list of strings).
by alok-g
6/3/2026 at 6:14:37 AM
Windows has been doing for quite a while, that is how COM strings work.by pjmlp
6/2/2026 at 8:36:52 PM
"Windows really needs to ditch CRLF and just use LF, and switch from backslashes to forward slashes."Hahahahaha. That's hillarious.
Oh god, you're serious?
Do you have any idea how much of Windows, and user software would break? Any idea at all?
You really want MS, who has built backwards compatibility as a core feature of Windows, to break countless thousands of pieces of software that run on it?
I'm sure there's some idealized fantasy in which that change gets wrapped in a neat little abstraction that prevents anything from breaking. I promise you, there is no way of encapsulating or abstracting that change that works for everyone.
If I could wave a magic wand and make it so without breaking it, I would. But it's a fantasy.
by Night_Thastus
6/3/2026 at 8:10:44 AM
> break countless thousands of pieces of softwareI'd estimate millions
by hnlmorg
6/2/2026 at 5:36:59 PM
the two filesystems can be a super power... i seamlessly use the same driver between wsl2 and my dual booted opensuse.by aniceperson
6/2/2026 at 5:41:19 PM
Yeah I don't mind/like the two file systems. Looks like MS is taking it further too they also announced WSL Containers & API.by thewebguyd
6/2/2026 at 5:42:58 PM
honestly your point is a bit weird.powershell is good. its much better than unix's everything piped is Text idea. godawfull that. outputs being objects is a really solid take.
WSL is trash.
besides that, lf vs. crlf is silly as you mention but crlf is more logical considering what its implementing. that being said the notion of these control chars is already based on outdated and limited ideas.
if you want a consistent system to do things with dont pick a system which tries to be two systems.
Linux has wine. Windows has WSL.
I'd recommend BSD. any flavor will do.
might take some adjustments but you will have a more 'rational' system if that is what you desire.
(otherwise, embrace the madness!)
by saidnooneever
6/2/2026 at 6:04:51 PM
> outputs being objects is a really solid take.Glad I'm not alone here ha!
Being able to go someoutput | Format-Table | Select ColumnName,ColumnName,CloumnName is great. Beats memorizing the output format of any specific command and trying to wrangle it with awk.
by thewebguyd
6/2/2026 at 7:32:26 PM
I'm a big Linux advocate with limited experience on modern versions of Windows, but PowerShell objects are great. So is the Unix way of doing text. I think the strengths of each approach are in different use cases. Unix style is better for interactive usage because it's fast, I can type df -h | grep /home very quickly. Object output is better for scripts that can, thanks to objects, store and operate on sensible data while Bash scripts do a lot of ad-hoc data extraction/reformatting with string expansion, awk and whatever else to get data to the next step in the script.by ACS_Solver
6/3/2026 at 6:35:32 AM
Inspired by the ways of Xerox, Genera and ETHZ.It can be verbose, but the object approach, and having .NET, DLLs and COM as first class primitives is quite flexible.
Naturally you can have a similar experience on UNIX, e.g. fish, but very few do it.
by pjmlp
6/2/2026 at 6:49:27 PM
You can skip the `| Select` btw.Just do `someoutput | ft ColumnName,ColumnName,CloumnName`
by d3Xt3r
6/2/2026 at 6:15:04 PM
[dead]by throwaway613746
6/3/2026 at 12:24:13 AM
maybe windows should actually just become linuxby sometimelurker
6/2/2026 at 7:02:47 PM
I have absolutely zero sympathy for any tool that is incapable of handling \r\n and only works with \n. Literally absolutely no sympathy.All software accumulates warts over time. Linux is overflowing with horrible warts and tech debt. As is any software that has successfully served customers for decades.
But multiple line endings are quite possibly the easiest most trivial thing to support and there is absolutely no negative cost of any kind in doing so. Linux ecosystem chooses to be stubborn and provide a strictly worse user experience out of pure spite and for zero user benefit. It’s very irritating.
by forrestthewoods
6/2/2026 at 7:28:15 PM
> But line endings are quite possibly the easiest most trivial thing to support and there is absolutely no negative cost of any kind in doing so. Linux ecosystem chooses to be stubborn and provide a strictly worse user experience out of pure spite and for zero user benefit. It’s very irritating.The Linux ecosystem handles it fine (by using a single standard). Windows doesn't. That's its problem.
by yjftsjthsd-h
6/3/2026 at 10:12:37 AM
Complete and utter nonsense. Every Windows tool I remember using has handled LF-only endings perfectly fine, meanwhile Linux tools regularly fail to handle CRLF endings.by Measter
6/2/2026 at 7:50:28 PM
> The Windows ecosystem handles it fine (by using a single standard). Linux doesn't. That's its problem.It's always funny to see how the fanbois treat their way as the one and only 'True Way'.
by justsomehnguy
6/2/2026 at 8:23:48 PM
I didn't say it was the one and only True Way. My intended meaning - which I admit I may have poorly conveyed - is that tools from the unix ecosystem are intended to work on unix conventions, and do, and that works. Windows has different standards, which is also fine, but it follows that you shouldn't expect unix tools to follow Windows standards even if you make them run on Windows. This is like getting Windows software to run under WINE and then complaining that it doesn't use /n newlines and that it should change to accommodate Linux (or whatever). No, a Windows program will follow Windows standards even when made to run on a unix-like. And in the same way, unix-family software is going to follow unix standards even on Windows.by yjftsjthsd-h
6/3/2026 at 6:36:27 AM
UNIX and Windows aren't the only OSes on the planet, even though UNIX folks tend to assume that.Heck many mistake UNIX with GNU/Linux even, and then complain when given a UNIX that isn't a Linux distro.
by pjmlp
6/2/2026 at 10:32:49 PM
I think the point is that line endings are a really, really stupid hill for either Linux or Windows to die on. The day when any programs should have cared about line endings came and went decades ago.by CamperBob2
6/2/2026 at 9:33:17 PM
Your entire framing is wrong imho.Multi-platform is very easy and a solved problem if you try juuuust a tiny amount.
For example the Rust stdlib iterator for lines() handles both conventions. It just works. Very easy.
I live in a cross-platform world. Line endings in text files should not be a breaking problem because some CLI tool refuses to support both. That’s just plain bad software engineering.
I expect Unix tools that process text files to be capable of supporting text files that have different conventions. This is very easy. Refer to previous comments on stubbornness out of spite.
by forrestthewoods
6/2/2026 at 7:55:03 PM
Comments like this really make me wish HN allowed you to block users. Alas.by forrestthewoods
6/2/2026 at 8:29:32 PM
If you have something to say, say it. This is barely even an ad hominem.by yjftsjthsd-h
6/2/2026 at 9:05:21 PM
[dead]by cindyllm
6/2/2026 at 5:38:24 PM
>Windows really needs to ditch CRLF...Windows needs to ditch itself.
by weregiraffe
6/2/2026 at 5:52:14 PM
No, they need to ditch drive letters first. The NT kernel and NTFS don't even require them (I used to mount disks without drive letters back in the NT 4 era). They just don't care enough to get rid of this annoyance.by avidphantasm
6/2/2026 at 6:18:18 PM
Nobody wants to use \??\GLOBALROOT\Device\HarddiskVolume3\ in their paths.by Dwedit
6/2/2026 at 10:35:24 PM
Nonsense. You can mount filesystems to mount points in much the same way as is done in Unix. No one would ever need to do that.by avidphantasm
6/2/2026 at 11:14:55 PM
You can indeed use mount points like C:\mountdir, but that's still on the C drive, which is a drive letter. It's not "no drive letters".by Dwedit
6/3/2026 at 10:47:40 AM
And if \ was an alias for C:\ this would just be \mountdir.by avidphantasm
6/2/2026 at 6:01:39 PM
users , especially non-technical, find it highly useful in my experience. Is it a net positive to get rid of them, or will it largely only make developers happier ?by noselasd
6/2/2026 at 10:34:00 PM
It’s arcane and technical for no reason. /Users/ME/Documents, /Media/MyThumbDrive/…, etc. are much clearer and less confusing than C:\…by avidphantasm
6/3/2026 at 1:00:33 AM
At the very least, drive letters do make SMB shares a bit simpler for the non technical folks. T:\MyData is easier for them than \\0010-somehost-win.site1.mycorp.loca\Share01\MyData\I used to support a group of completely tech illiterate users in construction & manufacturing. Them figuring out T:\ was hard enough, ask them to type in a UNC path into the address bar in explorer and you get "Wtf is file explorer? Wtf is an address bar? Where is the backslash key??"
by thewebguyd
6/3/2026 at 10:45:39 AM
Or just use sane names like \\MyDivision\Share01\MyData and mount that to \Network\Share01 or some such.by avidphantasm
6/3/2026 at 2:02:13 AM
Then in this hypothetical world you could mount \\0010-somehost.win.site1.mycorp.local\Share01 to /Share01 rather than T:by piperswe