Hacker News Reader

Comment by Sakos | Hacker News Reader

This is the craziest shit I've read all month. How did this make it into production?

The entire UWP API was a fractal mess of poor decisions implemented sloppily, I can't say I'm surprised. There's so many footguns and glaring oversights that most people probably just gave up on it before they got this far.

Microsoft can do a lot of things right (asp.net core and sql server are awesome products). But they really suck at creating UI toolkits and platforms. The last sane UI toolkit was Winforms, but it didn’t really evolve for 20 over years now.

Yeah, WinForms has been deprecated since 2014. Microsoft spent the last 30 years inventing and deprecating and reinventing and deprecating more UI frameworks than the entire rest of the industry combined (excluding JS frameworks).

The same way it made it into production on POSIX?

O_TRUNC is not default: https://man7.org/linux/man-pages/man2/openat.2.html

I feel this is a bit different. At least O_TRUNC is an option that is shown in documentation right next to the open() function so the programmer has the opportunity to spot it. With the FileSavePicker, there is no such option available and they have to add a line to manually truncate the stream. Also, open() is a low-level call, whereas FileSavePicker is the supposedly easy-to-use high level feature. I would say it is closer to fopen(), which does truncate by default.

These are very minor points. The main one is the same across platforms : bad defaults are common

Notwithstanding the lowest-level function open() working that way (and it’s honestly a somewhat different situation due to what it is and what the flags all are), fopen(), the more user-friendly interface with its mode strings, has "w" equivalent to including O_TRUNC in open() flags: https://man7.org/linux/man-pages/man3/fopen.3.html

I only have a very basic understanding of it, but skimming it makes me think that, in addition to leaving non-truncated files full of garbage around, that kind of open, overwrite, close pattern could be problematic on BTRFS. I wonder if that's one of the scenarios where BTRFS can end up with a bunch of extents that are full of mostly un-referenced blocks, but can't reclaim space because some of the blocks in the extent are (or BTRFS thinks they are) still in use.

If you truncate, write new data, and close fd, nothing (in that file) refers to the old extents, and btrfs will garbage collect them just fine.

The thing that hurts all copy-on-write systems is something like SQLite/Postgres/etc that mutates the file here and there; explicitly not overwriting it. chattr +C is the standard convention to opt out of copy-on-write, for those.

It's a pretty clear sign of how unpopular and rarely used UWP is: they can ship horrible bugs and nobody notices. A similar bug in Win32 would surely have been caught instantly just based on how widely it is used, both inside and outside of Microsoft.

Over the past decade there has been a lot of half-baked Windows stuff that made it into production before needing a rethink.

/me glares at "per-monitor v2" API awareness. I hate spreading rumours, but the one I heard about this was that nobody within Microsoft itself had tried converting any of their first-party GUI apps to per-monitor DPI. Once they started to do so, they finally realized how bad their offering was and came up with v2.

Because our industry and modern society in general dare not slow down long enough to let good work be done, or trust a craftsperson when they say, "This isn't done yet"

"How did this make it into production" is what I've felt every time I've had to use metro apps since Windows 8 was released.

People say it's NOT unique to Windows Snipping Tool but other tools that use this workflow for pngs as well.

Only if they use UWP, which is still somewhat rare, due to Win32 having loads more features and less bugs.

Reply on news.ycombinator.com