Hacker News Reader

Comment by pjc50 | Hacker News Reader

The two canaries to watch for are a systematic switch in the default line ending character from CRLF to LF, which will be driven by Microsoft developers fed up of git hassles, and a switch in the default path character from "\" to "/". In most places those are already supported, but not default.

View on HN

As a developer who has had to integrate data between Windows and Linux systems, but lacks deeper insight into Windows, I'd say another really important milestone would be a complete switch from CP1252 to Unicode.

Countless times that codepage thing has haunted me when moving data from Windows workstations into automatic processing systems hosted on Linux.

Windows is UTF-16 internally while Linux is UTF-8.

If Windows goes to unicode by default, it will make things a lot worse because it won't be the same unicode.

Well, they say UTF-16, but they still allow unpaired surrogates in some places, so it is really more like UCS-2.

Linux also allows invalid utf-8.

It is, Windows NT's adoption of Unicode predates UTF-16 and it's impossible to really make it UTF-16 compliant without breaking obscure corners of compatibility.

Most programs assume it's all UTF-16, and it happens to work most of the time... at least until you encounter those sequences that are invalid.

WTF-16 makes the distinction that invalid sequences are allowed.

* http://simonsapin.github.io/wtf-8/

You can switch 1-byte encoding to UTF-8. But many applications probably won't work. And working applications probably are using unicode API anyway.

It was explicit for a long time that ANSI is a legacy feature, and new API functions are often added without ANSI version, like CreateFile2.

As of Windows 10 1903 you can set the codepage of the application to UTF-8 - in fact for UWP Microsoft recommends you do that (https://docs.microsoft.com/en-us/windows/uwp/design/globaliz...).

Unfortunately I don't see that being common enough for data ingestion tools for this to be relevant for a very, very long time.

For now, it's just another pain point because you can't assume Windows == UTF-16 lookalike anymore.

Is it now recommended rather than experimental? I expect some legacy apps that uses local OEM codepage would be broken.

Those are two of the smallest parts -- there is the entire Windows API, and kernel API. The line ending character used by notepad isn't what would stop a total re-write of Word.

Tens of thousands of methods which power the majority of paid-for software. Microsoft has spent decades, and huge amount of man-power keeping all that software working, why would they flush all that away?

The API is quite shim-able; WINE has done that in the reverse direction, and there is (or was) the "POSIX subsystem" and cygwin. People build cross-compilable C code that works on both. It's just a bit of a hassle because the semantics are different in key places.

Leaving aside things which touch the GUI (which is a lot! You need a window to receive messages to use certain APIs!), the next big differences are the process API (no fork, starting processes is a lot more time consuming) and the advanced filesystem API (completion ports).

There are frankly a few pieces of the API that I would like to see go in the other direction, like WaitForMultipleObjects().

Indeed. kevent() isn't quite there on FreeBSD yet, and the Linux kevent() library doesn't work the same as the BSD one.

* https://freebsd.org/cgi/man.cgi?kevent

* https://news.ycombinator.com/item?id=23549116

I don't think MS would ever switch the UI out for Linux... but it wouldn't completely surprise me to see MS helping with WINE, DXVK and Proton. More surprised if there haven't been MS contacts that have at least helped to clarify things on occasion.

Even notepad can handle LF now. There is no reason to use CRLF anymore on Windows.

I think a better canary would be if Microsoft start buying Linux-based companies that have already solved these problems.

  SWITCHAR='-'

Not sure what the point would be of switching the default path separator. They're both already supported. What's to be gained?

The problem is that not all of the software someone might want to run on Windows handles backslashes gracefully.

There are situations in which for example VS Code will run git commands "behind the scenes" (without ever showing the command to the user). The way it is now, VS Code sometimes obtains a file name to be used as an argument to a git command from a Microsoft function that return the name with backslashes, gives the name to git, which doesn't consider a backslash a path separator, so git causes an error, "no file named foo\bar\bash," or such, and since that git command line (command with arguments) was never manually submitted or entered by the user, the user can't get past the error just by replacing some backslashes with slashes, then resubmitting the command line.

Microsoft could submit patches to the git project to make git recognize the backslash as a path separator, but there is no guarantee that the maintainers of git would accept the patches. So, Microsoft could end up choosing to bend (on the backslash issue) to make Windows more compatible with git -- and other Unix-centric projects.

I don't think they'll ever become the default, because of 'compatability' reasons.

I could perhaps see them becoming configurable.

I can't at all see why either of those would indicate that Microsoft is gearing up to rebase Windows.

Reply on news.ycombinator.com