for_xyz

> I guess one challenge with this is that old school Win32 doesn't really support anything resembling automatic / responsive layout.

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).

> The latest UI framework (XAML/WinUI) sits on top of a better rendering architecture (compositor) that itself wraps DirectX tech.

WinUI/UWP still uses CreateWindowEx and good old WndProc for event loop message handling at the top level on Windows 10.

If you drop something, then you need some kind of replacement for that.

I don't see any alternative on where entire OS could be configured other than registry.

> 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.

Sorry, my bad. They already started rewriting core components in Rust.

Here you go:

https://dropbox.tech/infrastructure/rewriting-the-heart-of-o...

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).

[0] https://docs.microsoft.com/en-us/windows/msix/overview

[1] https://docs.microsoft.com/en-us/uwp/api/windows.management....

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.

In case of the Dropbox please read this:

_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.

[0] https://blog.dropbox.com/topics/company/thank-you--guido

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.

Old one yes. New one (since win vista) allows you to pick folders.

  pFileOpen->SetOptions(FOS_PICKFOLDERS | FOS_PATHMUSTEXIST | FOS_ALLOWMULTISELECT);
 

https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_...

Which VM software did you use under windows?

> So... it's both NTFS and the Windows "subsystems."

Ok, probably both on default windows installation due legacy and backward compatibility with dos names [1].

https://docs.microsoft.com/en-us/windows-server/administrati...

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.

> so what's the 'Windows way' then?

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.

Guess which one is used in practice.

It's possible to interact with native windows tooling from WSL.

Example: $ echo "test" > test.txt & notepad.exe test.txt

This is the correct answer. Myth that NTFS is slow should already go away.

You can already run windows on top of BTRFS if you want but it'll be painfully slow compared to linux [1].

https://twitter.com/NTDEV_/status/1327358814891470850 https://github.com/maharmstone/quibble

> 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]

[1] https://www.youtube.com/watch?v=qbKGw8MQ0i8

> This ad appeared only when our devices were set to use Google Chrome and Firefox as the default web browser.

I have new edge as default browser and I still got this screen.

This screen appears if you have other browsers installed even if they are not default.

It seems that code quality in Microsoft products keeps dropping rapidly every year.

It has already been 5 years and UWP is still unstable and buggy compared to Win32.

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.

> They can just ship a custom kernel only to their users and leave it at that.

Works really well for Google and Android where they offload handpicked versions of the Linux kernel to the phone vendors to maintain. In practice they don't bother with it so phones never get any updates after 1 year.

Maintaining custom Linux kernel fork is not possible if you want to keep it up with the upstream changes.

You're supposed to use APIs provided by mesa (OpenGL, OpenCL) or TensorFlow and similar ML Frameworks which then talk to D3D12 or DirectML as seen on linked diagrams.

It makes zero sense to consume D3D12 and DirectML under WSL directly from user applications since that prevents your app from being deployed on the real linux. There also won't be any SDK or headers released by Microsoft so you'll have to manually load functions from .so.

They also cannot be used from applications directly since they're just implementation detail inside mesa.

I'm pretty sure I ran vulkan apps via RDP and they worked fine. I think it was also on GTX 960.

Windows Update keeps drivers up to date except for ones installed manually.

Does write situation apply to linux as well?

Since 99% of the disk I/O is cached, write either success or fails completely. It's beyond scope of the userspace application to know what and when data arrives on the physical disk. Same applies to Windows as well.

Using direct I/O is different story where this is the correct behaviour.

I think I watched an interview with him where he talked about Subsurface project. In that interview he said that C++ is not all that bad but he still prefers C because he's so used to it and will continue write C code forever. I don't remember title of the video though.

Yes, you're correct. Linus still works on C backend of the application and sometimes has to connect his parts with C++ code.

His attitude towards C++ also changed when using it for his side project [1].

Initially he started with C and GTK+ and later migrated to C++ and QT Framework.

[1] https://subsurface-divelog.org/

Linux was heavily inspired by Unix but it's not Unix in any sense.

Rest of Unix certified implementations are however not widely deployed. I don't see many AIX, Solaris production machines anywhere since everyone often deploys Linux instead.

Same story applies to *BSD family.

The only thing that keeps the Unix identity on those system is the Posix interface which is also extremely outdated on modern systems and it's kept around as a legacy.