-
Windows UI Library
Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
I find it hilarious that even in such a comprehensive post, the author missed some:
Some apps are now shipping with “Fluent but inconsistently round”, mostly the ones that use WinUI. Maps is a good example where this is noticeable. You can see some screenshots in link below.
https://github.com/microsoft/microsoft-ui-xaml/issues/3767
> Disclaimer: I work at Microsoft, but not on Windows (and I deal with a SaaS at MSFT). I am a FreeBSD committer and help maintain FreeBSD's GNOME packages and (very recently) the graphics drivers.
Completely unrelated and a shot in the dark, but if you’re both a Microsoftie and a FreeBSD user/committer, the FreeBSD .NET port is stumbling/regressing somewhat and could definitely use a little help:
https://github.com/dotnet/runtime/issues/14537
Anything you could do to help (if only pushing the right buttons/people internally), I’m sure would be greatly appreciated.
Not natively, but ntvdmx64[0][1] and otvdm[2]/winevdm[3] work fine, albeit a bit slowly.
[0]: http://www.columbia.edu/~em36/ntvdmx64.html
[1]: https://github.com/leecher1337/ntvdmx64
[2]: http://www.columbia.edu/~em36/otvdm.html
[3]: https://github.com/otya128/winevdm
---
For those interested, Wikipedia says there's no native/builtin 64bit NTVDM due to
> In an x86-64 CPU, virtual 8086 mode is available as a sub-mode only in its legacy mode (for running 16- and 32-bit operating systems), not in the native 64-bit long mode.
...
> The NTVDM is not supported on x86-64 editions of Windows,[31] including DOS programs,[32] because NTVDM uses VM86 CPU mode instead of the Local Descriptor Table in order to enable 16‑bits segment required for addressing[33] and AArch64 because Microsoft did not release a full emulator for this incompatible instruction set like it did on previous incompatible architecture.
https://en.wikipedia.org/wiki/Virtual_DOS_machine#Windows_NT...
---
Personally, since Microsoft still releases 32bit builds of Windows 10, I just dual boot 32bit (~48GB)/64bit (~900GB) partitions and run the 16bit programs natively on an old Thinkpad.
Not natively, but ntvdmx64[0][1] and otvdm[2]/winevdm[3] work fine, albeit a bit slowly.
[0]: http://www.columbia.edu/~em36/ntvdmx64.html
[1]: https://github.com/leecher1337/ntvdmx64
[2]: http://www.columbia.edu/~em36/otvdm.html
[3]: https://github.com/otya128/winevdm
---
For those interested, Wikipedia says there's no native/builtin 64bit NTVDM due to
> In an x86-64 CPU, virtual 8086 mode is available as a sub-mode only in its legacy mode (for running 16- and 32-bit operating systems), not in the native 64-bit long mode.
...
> The NTVDM is not supported on x86-64 editions of Windows,[31] including DOS programs,[32] because NTVDM uses VM86 CPU mode instead of the Local Descriptor Table in order to enable 16‑bits segment required for addressing[33] and AArch64 because Microsoft did not release a full emulator for this incompatible instruction set like it did on previous incompatible architecture.
https://en.wikipedia.org/wiki/Virtual_DOS_machine#Windows_NT...
---
Personally, since Microsoft still releases 32bit builds of Windows 10, I just dual boot 32bit (~48GB)/64bit (~900GB) partitions and run the 16bit programs natively on an old Thinkpad.
Perhaps, but the standard VFIO-style passthrough methods (if you can call anything about that "standard") is still a terrible solution; it requires more than one GPU to use both systems at once, requires navigating horrifically underdocumented driver systems that brick the system when experimented with (just like everything in Linux does, for that matter), and requires at the very least switching inputs between the host and the guest even if all of that works perfectly somehow.
Passing through an nVidia GPU the way that data centers do it, where you can run several hardware-accelerated VMs on the same GPU (as well as the host, on only one set of outputs), to my knowledge still requires this hack (https://github.com/DualCoder/vgpu_unlock); this is specifically what I'm referring to and is really the only workable solution as it's the closest to "press button get seamless performance from your gaming Windows VM" as we can get right now.