> I mean, it's an early leaked build. I predict that the file explorer specifically will be completely replaced, which is why it hasn't been updated at all.
I really hope that _replacement_ will be as feature complete and useful via keyboard as the current explorer. UWP UI components tend to be unnavigable via keyboard.
For example I really like old Win32 listview behaviour to just type in the item name to select it.
> Meanwhile, the big open-source desktop C++ libraries (Qt and WxWindows) still don't fully take advantage of the types and features in the standard library in 2021.
Of course not. C++ and libraries don't go along nicely. STL is not really useful for cross boundary interop due the fact that C++ ABI is not stable.
Shipping libraries that leak STL types all over the place will only give you headache.
If you start from scratch, I'd suggest to use MSIX [0] instead. It makes auto update trivial to implement with PackageManager.UpdatePackage(url_to_your_msix)[1] or plain execute via "ms-appinstaller:?source=url_to_your_msix". It'll do diffs properly and you also get package reflection for free via WinRT apis (such as where app is installed, appdata location, app version, etc).
To prevent half assed refactoring in the first place where only namespaces and classes get refactored while folders and filenames remain as they were. It would just further confuse new devs on the project.
_But as the company grew, new engineers who joined couldn’t understand the code. Clever code is usually short and cryptic, written by and for the individual who came up with it, but is hard for anyone else to understand—and nearly impossible to maintain. Guido called this “cowboy coding culture”. He recognized its value in our early stages of trying to implement things quickly, but knew it wouldn’t be sustainable over time, so he decided to speak up in his own quiet way._
And now they'll have to rewrite everything in programming languages where maintenance is not a burden.
No, he is in need of writing production quality software together with his medium to big sized dev team and he doesn't want to introduce maintenance burden into his project 10 years from now. Software will get improved during it's lifetime and not overwritten from scratch every 2 years.
Of course you can write anything in R but that doesn't mean it will be possible to maintain the codebase for the next 10 maybe 20 years including dev team changes.
In other words R is wrong tool to use for building the software just from maintainability standpoint.
I remember this issue when creating few million of files inside one folder and it was extremelly slow because of 8dot3 name creation. It has to go through each filename to generate short name O(n) when this legacy feature is enabled.
After disabling 8dot3 there were no performance issues anymore.
> I have no experience with BTRFS, but that doesn't prove anything without knowing more details (the overhead introduced to make it work)
I tried to point out following:
Ext4, Btrfs, Zfs, any other UNIX filesystem will be slow under Windows. NTFS or any Windows first filesystem will be slow on Linux. There is just too much of the differences in OS architecture between the NT and Linux.
Using either memory mapped files of overlapped io (IOCP).
It's tricky to use when you want to write the content since you must preallocate the file before you start with the writing. Appending to file just doesn't work under NT kernel since WriteFile blocks even if you use overlapped io.
Devs just need different mentality when it comes to Windows programming compared to Linux. Due the fact that everything under NT kernel is operated asynchronously you'll have to adapt your code to such concept. Meanwhile under Linux you had no other alternative for nearly 30 years (io_uring and friends) so if you wanted to be portable with minimum OS specific code then you had to implement things in synchronous way or write two separate code paths for each OS.
> the bottleneck is that NTFS is a crappy filesystem.
Care to explain why do you think NTFS is crap?
From my experience it's usually bad assumptions about files under windows and every application or library tries to stick to posix interface when dealing with files (open, read/write, close) which tends to block for longer periods on windows than on linux counterparts which results in significant perfomance loss .
Linux first software will always outperform windows implementation and Windows first software will outperform Linux implementations unless you provide separate code paths to properly handle underlying OS architecture and assumptions.
On Windows closing the file handle is extremely costly operation due AV checks and file content indexing [1]
Yes, I agree. What I meant was for mobile phone manufacturers who don't upstream their code portions and abandon it after a while due increased costs of maintaining the multiple versions. In other words... old hardware only works on older kernel release and new hardware only works on new kernel release.
It'd be much better if they upstreamed the changes instead of fragmenting the entire ecosystem with custom forks.
It gives you all the building blocks to implement it yourself.
Remember that Win32 is not UI framework but OS API which allow you to build yourself one (wxWidgets, QT, SWT).