Live data from Hacker News

Win32 and .NET desktop apps can now be published in the Windows Store

blogs.windows.com

131–140 of 158 posts

Re: Win32 and .NET desktop apps can now be published in the Windows Store

#131
post #19

Earlier quoted context omitted.

The introductory phrase of UWP explains why they pushed it: "A Universal Windows Platform (UWP) app can run on any Windows-based device, from your phone to your tablet or PC" . The point was getting more applications for their mobile platform by coaxing developers who might have otherwise built a desktop-only application. I'd say this new development is essentially an admission of defeat on mobile.

The problem is that it may take their desktop with it. The industry doesn't want to invest in a desktop windows app because there is no clear direction. WPF/Win32 etc seem to be getting deprecated, but UWP is too limited.

I agree with the sentiment but I think Win32 is with us forever (and because WinForms is just a wrapper on top of that that's probably safe too).

Re: Win32 and .NET desktop apps can now be published in the Windows Store

#132
post #97
post #76

Earlier quoted context omitted.

Silverlight may be the one glaring exception to that rule that I can think of. I don't think even IE or Edge support that anymore, which makes it dead. I had an ex-girlfriend whose employer made a big bet on Silverlight for their web app platform... in 2012. Having to rewrite it all in HTML5 and JS a year later almost put them under.

Couldn't they have ported to WPF with a lot less effort?

Silverlight was cross-platform.

Re: Win32 and .NET desktop apps can now be published in the Windows Store

#133
post #71

Earlier quoted context omitted.

> Filesystem permissions cannot be controlled on a per app level They can if you adopt a user per app model. I thought this is what android/UWP did under the hood. > I do not like the fact, that an installation of for example a game needs admin rights, and has every chance to access data it should not be able to do. I doesn't. The biggest cause of this is the default of requiring admin to access program files, even i…

Steam is a terrible security example because Steam just gives Everyone Read/Write/Execute access to its folder(s) on Windows. The Steam solution to permissions on Windows has always been to basically just give up and not bother.

Well, I mean, if I'm picking, I'd rather other applications can get to my games folder than the other way around.

Re: Win32 and .NET desktop apps can now be published in the Windows Store

#134
post #38

Earlier quoted context omitted.

UWP is limited as it is relatively new. The new (capabilities based) security model is clearly better than the old "if you are admin, you can do whatever you want" model. The old model was inadequate even at the start of the multimedia age, but it was not recognized until recently. The new sandboxed operation creates more portable and reproduceably operating apps. The limitations will show, as more and more usecases…

WinRT means: * No app closure callbacks. You don't know if it's suspending or exiting. * No "are you sure you want to exit? Save/Don't save" dialogs. If you close or crash pray your data was saved, and if it takes a long time to flush to disk...really pray. * No minimizing/backgrounding to tray icons allowed.

> No "are you sure you want to exit? Save/Don't save" dialogs. If you close or crash pray your data was saved, and if it takes a long time to flush to disk...really pray.

Of course not, because it's supposed to also work on mobile. Does your iPad let applications prevent you from going back to the home screen?

Re: Win32 and .NET desktop apps can now be published in the Windows Store

#135

Earlier quoted context omitted.

I don't know why this is buried, it is absolutely true. What windows users need are some sort of sandbox / container / jail where registry / file system / system calls are isolated. Then you could package up a program into one file and delete it to uninstall it like one file. This could have been done decades ago and now microsoft is banking off of the fact that they never did.

> I don't know why this is buried Because it is the typical anti-M$ conspiracy theory. It blames on "evil" what it can't understand. Win32 is not insecure because they wanted to sell security. It is what it is because that's what made sense at the time, before Internet and viruses appeared, memory was restrained and virtualization and sandboxing were obscure techniques and processing power and memory were severely co…

Well, yeah, a lot of the decisions that people question have to do with not breaking existing software.

Re: Win32 and .NET desktop apps can now be published in the Windows Store

#136

Earlier quoted context omitted.

There is a Suspending callback. Sounds like you have some misconceptions about the UWP/WinRT application lifecycle: https://msdn.microsoft.com/en-us/windows/uwp/launch-resume/a...

If I recall correctly, this callback has some undocumented deadline. Go over that and it's unceremoniously killed, great way to corrupt whatever you're desperately trying to write to disk.

No, it is a pretty well documented deadline at this point. The callback is not intended for I/O work, but to clean up resources or to spin up any background tasks you might need for I/O. There are lots of articles full of best practices for the app lifecycle. Yes, it's different than Win32. Yes, it's influenced by mobile and low resource environments. But it's better for it and worth learning.

Re: Win32 and .NET desktop apps can now be published in the Windows Store

#137

Too bad you still need a Microsoft account to use the store, besides sideloading. That's a deal breaker for me, at least on the desktop (I know you can login separately on each app). 1) How good is the sandbox? I followed the links but how battle-tested is it? What if you put an already sandboxed Chrome inside UWP, does it basically use almost the same calls or there are some extra benefits? Besides FS isolation. 2)…

It's not a proper sandbox. Converted apps run with full trust. There's file system and registry redirection but a malicious app can get around it. See this discussion: https://arstechnica.com/civis/viewtopic.php?f=15&t=1312055

Also full trust vs app container here: https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...

Re: Win32 and .NET desktop apps can now be published in the Windows Store

#138

Too bad you still need a Microsoft account to use the store, besides sideloading. That's a deal breaker for me, at least on the desktop (I know you can login separately on each app). 1) How good is the sandbox? I followed the links but how battle-tested is it? What if you put an already sandboxed Chrome inside UWP, does it basically use almost the same calls or there are some extra benefits? Besides FS isolation. 2)…

It's not a proper sandbox. Converted apps run with full trust. There's file system and registry redirection but a malicious app can get around it. See this discussion: https://arstechnica.com/civis/viewtopic.php?f=15&t=1312055 Also full trust vs app container here: https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...

That's worse than Win32 since it gives you a false sense of security and you have no way, AFAIK, to see what the app is doing (or to check if it's a true "native" UWP app). Some app uploading my personal stuff without my permission (no extra privileges required) is worse than a cryptolocker.

Re: Win32 and .NET desktop apps can now be published in the Windows Store

#139

So if I understand it right, this is basically running apps in a Win32-emulator/sandbox where all 'unsafe' Win32 file and registry accesses are redirected into sandboxed locations. I wonder why MS didn't go this way from the beginning instead of pushing that Frankensteinian half-desktop/half-mobile monstrosity called WinRT^H^H^H UWP on us. The UWP application model has been modelled after the (now 10 years old) iOS/A…

"Win32 is a pretty bad desktop API" What's a better desktop API, and why?

Re: Win32 and .NET desktop apps can now be published in the Windows Store

#140

So if I understand it right, this is basically running apps in a Win32-emulator/sandbox where all 'unsafe' Win32 file and registry accesses are redirected into sandboxed locations. I wonder why MS didn't go this way from the beginning instead of pushing that Frankensteinian half-desktop/half-mobile monstrosity called WinRT^H^H^H UWP on us. The UWP application model has been modelled after the (now 10 years old) iOS/A…

"Win32 is a pretty bad desktop API" What's a better desktop API, and why?

I'm not saying there's a better desktop API, just that Win32 is 'pretty bad' (IMHO). It's a collection of many small annoyances that have been stacked on top of each other over the decades. My favourite mis-feature is probably everything around UNICODE, such as hiding the xxxA() and xxxU() function names under global preprocessor defines, which in turn renames all your own functions which happen to have the same name. It's many little things like that. It's not that the OSX or Linux window system APIs are any better though.

IMHO a modern OS should only come with a low-level window-compositor which just composes canvases, and leaves rendering (including UI) to the user code through a thin 3D API. Other than that: file system, sockets, input, audio, and a very simple main-loop application model, all as C APIs which don't try to be object-oriented, leave all the different language bindings to the user-side.

Post reply on HN