Live data from Hacker News

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

blogs.windows.com

21–30 of 158 posts

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

#21
post #6

Earlier quoted context omitted.

What if I'm using something more modern, like chocoaltey? MSI has never played well with CI servers and wix is way too complicated.

Nano server (variant of Server 2016) which has no UI component at all has adopted the appx for Windows Server apps (WSA) so I'd imagine the tooling will improve there. Though you can also build one with a text editor and command line: https://blogs.technet.microsoft.com/nanoserver/2015/11/19/ha...

> Though you can also build one with a text editor and command line

That's exactly the sort of thing I'm after, thanks. I hate it when configuration is hidden in favor of tooling.

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

#22

Earlier quoted context omitted.

You run the converter on your complied exe installer, not your applications code. That a fairly low barrier. Seems to make the Store very backwards compatible, it can even convert VB6 apps: http://www.hanselman.com/blog/PuttingMyVB6WindowsAppsInTheWi... Also if you want to go from exe rather than installer you can use makeappx directly https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...

VB6? That's... the awesome kind of crazy. How does the converter deal with the VB6 runtime that had to be distributed? Oh dude, this brings back some memories... but I have to admit, for long time there was nothing except VB6 if you wanted to put together GUI apps with very little code and a WYSIWYG GUI designer.

> How does the converter deal with the VB6 runtime that had to be distributed?

I've just checked on Windows 10, and yup, MSVBVM60.dll is still part of the OS install - the mind boggles. This is classic MS - providing support for as long as they can, where they can.

Of course I'm not sure how the UWP Bridge would work if your VB6 app referenced a bunch of old school .OCXs though, as typically even the self registering ones need to write to HKEY_LOCAL_MACHINE part of the Registry, which the Bridge docs say is a complete no-no.

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

#23

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…

> old-school desktop computers I'm very sad about how accurate this generalization is.

It wasn't meant in a negative way :) High-power gaming rigs will always require big and expensive cooling solutions.

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

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

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 will be attempted, and surely many will be addressed.

Personally I hope once the global filesystem concept will be gone, and apps will use isolated or shared storages where shared storage will get explicit access rights for each app/user it is shared with.

The old system had defaults originating from the single user non-multimedia usecases left over as a legacy, but currently we have so many things going on our computers, that privacy/security needs a rethinking of old concepts to cope with new challenges.

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

#25

Do I need to sign my code which means having to purchase a signing cert? The costs for code signing are prohibitive for some small devs.

Unless it's some sort of weekend hobby project, ~$100 a year is hardly "prohibitive".

[1] https://www.digicert.com/friends/sysdev/

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

#26

Earlier quoted context omitted.

You run the converter on your complied exe installer, not your applications code. That a fairly low barrier. Seems to make the Store very backwards compatible, it can even convert VB6 apps: http://www.hanselman.com/blog/PuttingMyVB6WindowsAppsInTheWi... Also if you want to go from exe rather than installer you can use makeappx directly https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...

VB6? That's... the awesome kind of crazy. How does the converter deal with the VB6 runtime that had to be distributed? Oh dude, this brings back some memories... but I have to admit, for long time there was nothing except VB6 if you wanted to put together GUI apps with very little code and a WYSIWYG GUI designer.

When I was about 12 my father gave me a copy of VB6.

I used form and image controls to made a pixel based tiled fighting game. Not an actual game engine. Just a horrible hack that actually worked and I was proud of it. It was one of those things that helped me get into programming.

(I still have a copy of it.)

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

#27
post #2

And all you have to do is convert it into a UWP app: >A few months ago, during Build 2016, we announced the Desktop Bridge, enabling developers to bring their existing desktop apps and games over to the Universal Windows Platform (UWP) by converting their app or game with the Desktop App Converter and then enhancing and extending it with UWP functionality. This then enables the path to gradually migrate the app or ga…

You run the converter on your complied exe installer, not your applications code. That a fairly low barrier. Seems to make the Store very backwards compatible, it can even convert VB6 apps: http://www.hanselman.com/blog/PuttingMyVB6WindowsAppsInTheWi... Also if you want to go from exe rather than installer you can use makeappx directly https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...

My WiX installer prepares the program folder location and installs exactly one downloader executable which pulls the rest of the desktop app from a location in the internet. Is this setup compatible with App Store via Desktop Bridge in principle or should I get problems with sandbox etc.? (No need to elaborate, if the answer is yes I'll work through the details on my own).

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

#28
post #21

Earlier quoted context omitted.

Nano server (variant of Server 2016) which has no UI component at all has adopted the appx for Windows Server apps (WSA) so I'd imagine the tooling will improve there. Though you can also build one with a text editor and command line: https://blogs.technet.microsoft.com/nanoserver/2015/11/19/ha...

> Though you can also build one with a text editor and command line That's exactly the sort of thing I'm after, thanks. I hate it when configuration is hidden in favor of tooling.

Also manual conversion steps without installer: https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...

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

#29

Earlier quoted context omitted.

You run the converter on your complied exe installer, not your applications code. That a fairly low barrier. Seems to make the Store very backwards compatible, it can even convert VB6 apps: http://www.hanselman.com/blog/PuttingMyVB6WindowsAppsInTheWi... Also if you want to go from exe rather than installer you can use makeappx directly https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...

My WiX installer prepares the program folder location and installs exactly one downloader executable which pulls the rest of the desktop app from a location in the internet. Is this setup compatible with App Store via Desktop Bridge in principle or should I get problems with sandbox etc.? (No need to elaborate, if the answer is yes I'll work through the details on my own).

Preparing your internet download desktop app as appx might be the way? Rather than converting the installer https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...

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

#30
post #19

Earlier quoted context omitted.

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.

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…

Personally I hope once the global filesystem concept will be gone, and apps will use isolated or shared storages where shared storage will get explicit access rights for each app/user it is shared with

I very much hope not, since default and easy global sharing is what makes desktop OSs so very useful, and a lot of this sharing is spontaneous, creative, and ad-hoc. Besides, we already have things like filesystem permissions. By all means have a sandbox for "the untrusteds", but I don't want the equivalent of being forced into the "everything which is not explicitly allowed is forbidden" bureaucracy.

Post reply on HN