4 ms·
Nice. Now kill UWP[0] and bring some actual improvements to the base Win32 C API that any application written in any programming language and available from any
by badsectoracula 7y ago
Nice. Now kill UWP[0] and bring some actual improvements to the base Win32 C API that any application written in any programming language and available from any source (direct downloads form author pages, repositories like GitHub, eshops such as Steam, etc) can use.
[0] of course for backwards compatibility reasons this cannot be totally removed, though considering that 99.999% of the applications made for it were obtainable through the online Microsoft Store there is an assumption of internet availability so it can be installed on-demand like older versions of .NET framework.
- jfkebwjsbx 7y agoYes, please! Win32 ("WinAPI" nowadays) is the API everyone will keep using (plus .NET for higher level). Make a sandbox/container for Win32 apps and that's it.
- badsectoracula 7y agoI'm not sure if this is what you have in mind (because sandbox/container can mean several things, including things i wouldn't like to see like limiting what applications can do to each other) but one thing that i'd like to see is something like a "desktop chroot": being able to right click an EXE (or zip/installer/msi/whatever) and select "Run this in fresh Windows 10 VM" where the application runs in a VM (either inside its own window or seamlessly, could be an option) as if it was the only application installed in a fresh Windows 10 installation, optionally with a way to make this VM permanent as a desktop shortcut, until you decide to delete it and remove the entire thing as if it never existed. This would make it easy to experiment with applications you do not fully trust or simply trying out applications in an environment that wont affect your real working one. It is kinda/sorta possible to do that now using something like VirtualBox, but you need to create a full Windows 10 installation (which takes several GBs), it takes time to install (you can save some time by exporting a fresh installation to an appliance - at expense of more space - though you'd also need to disable networking otherwise after a while the moment it notices internet will start upgrading) and it can't use the computer resources properly (it runs much slower, you have no access to the GPU, etc). A properly integrated Windows 10 solution would be to map existing files to VM so that it reuses 99% of the stuff that would be the same and, if needed, do a copy-on-write in cases where these files are altered inside the VM (it could also help to see what exactly the programs inside the VM touch, sort of a system-wide diff... though that can also have false positives if the changes are by the OS itself).
- neilalexander 7y agoI think what you are looking for is a thing called Windows Sandbox, if it is throwaway containers you are after: https://techcommunity.microsoft.com/t5/windows-kernel-internals/windows-sandbox/ba-p/301849 https://techcommunity.microsoft.com/t5/windows-kernel-intern...
- badsectoracula 7y agoKinda. But it should be available to everyone, not just Pro, and it should be permanent until you decide to delete it instead of getting deleted after you close the application (as you may want to take your time using the application for a while before you decide if it is worth installing on your base system). This also implies that it should be possible to move files between the VM and the base system, preferably in a manner as simple as drag-and-dropping the files to/from the VM.
- iggldiggl 7y ago... and it shouldn't break hybrid sleep, either (by the way, is that still a fundamental limitation of using Hyper-V, or just a peculiarity of my specific system configuration?).
- noizejoy 7y agoWould sandboxing make my old 32bit midi apps stop talking to my new 64bit midi apps? If yes, that would be a shame, since the ability to still use ancient midi software and hardware is one of the things that’s nice about Windows 10.
- pcwalton 7y ago> Now kill UWP[0] and bring some actual improvements to the base Win32 C API that any application written in any programming language and available from any source (direct downloads form author pages, repositories like GitHub, eshops such as Steam, etc) can use. People said the same thing about Carbon on macOS—"why do I have to use this new Cocoa thing?"—but now nobody misses it. The Win32 API needs to go away (at least as the main way to develop apps) sooner or later. (It already is gone to a major extent: when was the last time a new Win32 app, written in Win32 with C++, made the news?)
- anthk 7y ago>(It already is gone to a major extent: when was the last time a new Win32 app, written in Win32 with C++, made the news?) Windows 10, for example. And the compiler stacks for Windows. I can go on forever.
- pjmlp 7y agoWindows 10 makes heavy use of UWP APIs, Win32 is stuck in XP vision of the world. All major new APIs since Vista are based on COM, with UWP being COM vNext. WinUI is becoming the basis of React Native for Windows, and is the only Windows UI toolkit with a roadmap beyond bug fixing.
- badsectoracula 7y agoI don't know what people said about Carbon, but i do know that many people do miss it - like the Lazarus developers that had to throw away years of work. > It already is gone to a major extent: when was the last time a new Win32 app, written in Win32 with C++, made the news? Every single PC game made since the mid90s? Also why the restriction to C++? A big benefit of Win32 is that being in C it can be used by many other languages since pretty much every language has some FFI that speaks the platform's C ABI.
- pjmlp 7y agoThat is what COM is for. C is on its way out as it should have been long time ago.