7 ms·

Not yet. Their next strategy is to try and use ARM (again) to shove UWP down your throat. I love Windows but I seriously will not touch UWP until they loosen u

Not yet. Their next strategy is to try and use ARM (again) to shove UWP down your throat. I love Windows but I seriously will not touch UWP until they loosen up the sandbox restrictions so that I can do regular IPC with a win32 desktop app. You can't even send an HTTP request to a little node.js Web server running on your desktop right now. Fuck that. I'm not buying into it.

Kipters 10y ago
Care to elaborate on the HTTP part? You just need the "Internet (client)" capability in your manifest, it's even enabled by default when you create a new project Moreover, win32 desktop apps can use the AppService mechanism exposed by UWP apps (but cannot host an AppService themselves, just connect to UWP-hosted AppServices)
- WayneBro 10y ago
  Give it a try. You can't send requests to `localhost` or `127.0.0.1` at all. AppService is largely useless for IPC between UWP and Win32 since the UWP app can't initiate a request to the Win32 app. Another thing you can't do, which is really annoying: UWP won't let your code start an external process and use standard i/o pipes to communicate with it. The only possibility is to use files for IPC and you'd have to have your Win32 app listen for changes in the file or directory, then open it up and read the data. However UWP can't listen for changes in those same files, so it's a real PITA. All of the options are listed here - http://stackoverflow.com/questions/12341707/communication-between-windows-store-app-and-native-desktop-application http://stackoverflow.com/questions/12341707/communication-be... You can also use a loopback exemption, but it requires installing a fake root certificate (no thanks!) - http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureFiddlerForWin8 http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/Conf... or http://loopback.codeplex.com/ http://loopback.codeplex.com/
  - Someone1234 10y ago
    > However UWP can't listen for changes in those same files, so it's a real PITA. It can via the ContentChanged event see this example: http://stackoverflow.com/questions/39737147/how-can-i-watch-for-file-changes-in-a-uwp-project http://stackoverflow.com/questions/39737147/how-can-i-watch-... > Give it a try. You can't send requests to `localhost` or `127.0.0.1` at all. Luckily getting the local IP address is easy enough from UWP: http://stackoverflow.com/questions/33770429/how-do-i-find-the-local-ip-address-on-a-win-10-uwp-project http://stackoverflow.com/questions/33770429/how-do-i-find-th... That will work since it is treated like all other network traffic. localhost and 127.0.0.1 are considered privildged routes since you can bypass the firewall and exploit local processes to escalate.
    - WayneBro 10y ago
      OK, so ContentChanged is new since the last time I looked - thanks for that! However, IPC via files is still a PITA in general compared to something easy like sockets. Using an external IP address is a terrible solution for communicating with another process on the same machine. As soon as you disconnect from the network, it will stop working.
      - nitrogen 10y ago
        What does IPC between UWP and native buy you? Do you have some legacy code that has to run natively (been there with a Java app many years ago using TCP to talk to a tiny host process for some native code)?
        vmarsy 10y ago
        No the author, but I can see a use case where you have already existing "services"/"daemons" with your client Win32 app. If you want to rewrite the client from Win32 to UWP, it seems that you wouldn't be able to? Why do that? Indeed one could just call Windows 10 API from its existing client [1], but it seems that you would miss out on the easy install/update from the Store and other benefits a UWP app provides. [1] https://blogs.windows.com/buildingapps/2017/01/25/calling-windows-10-apis-desktop-application/ https://blogs.windows.com/buildingapps/2017/01/25/calling-wi...
  - Kipters 10y ago
    Wow, it's weird I never actually tried to send a request to localhost on UWP, usually only to other PCs on the network during development. I didn't know that. The Win32 app can connect to the UWP AppService, on PC you can also bundle a desktop app in your package and start it when the UWP app is launched. This desktop app can then act as a bridge between your UWP app and the "legacy" world, offloading the "dirty" stuff to the slave desktop app. It actually works, I used this for getting the taskbar to blink in my side-project for a messaging app.
  - rasz_pl 10y ago
    >http://loopback.codeplex.com/ http://loopback.codeplex.com/ is there anything like this, but working the other way around? I want to be able to forbid ordinary Win32 programs from accessing loopback/localhost.
PatentTroll 10y ago
I don't get the outrage over the rumored UWP only windows. There is no indication that MS would drop win32. This is a separate product, likely for a particular market. It's more of an iPad competitor than a Windows desktop replacement. So don't use it if it offends you, that's OK. I don't think this is all that forceful really.
- WayneBro 10y ago
  They already did UWP-only Windows. That was WindowsRT. Nobody bought into that either, but Microsoft still really, really wants that closed-market, walled-garden style business model to happen somehow and so they're going to keep trying. I believe that their next strategy is to release a full Windows OS (with Win32) that runs on ARM which lets Win32 apps run via an emulator. In this environment, Win32 apps will most likely run like crap and as a matter of course Microsoft is going to keep pushing everybody (developers and users) toward the model that they think will make them the most money. It's really no problem for my career because I stopped exclusively using Microsoft's tech years ago and I'm comfortable using Linux or a Mac if necessary (but really, I can't stand their UI and I think Apple is even worse than Microsoft in many, many ways). I just like the Windows UI the best and I'd like to be able to build stuff for it in the future....but not if they are working towards taking away my freedom to control my own computer.
  - pavlov 10y ago
    Microsoft famously keeps trying, and often the product initially looks like a failure until the third iteration is the one that clicks. (Windows 3.0, Surface 3, Windows NT's third version which was branded "NT 4.0"...) Windows RT was about as popular as Windows 1.0. I think Microsoft views the upcoming ARM-based "Cloud Windows" (whatever the branding is going to be) as the second iteration of this idea, and hopes to really gain traction a few years later.
  - NikolaeVarius 10y ago
    RT was literally the exact opposite of UWP. I would argue they killed the RT BECAUSE of the shift torward UWP. The RT was a stopgap measure to try and force windows onto a Architecture it wasn't ready for. Most of it didn't work at all which is why it failed.
Someone1234 10y ago
> I love Windows but I seriously will not touch UWP until they loosen up the sandbox restrictions so that I can do regular IPC with a win32 desktop app. The whole reason for the UWP sandboxing is to make it so that users can confidently install UWP applications with some assurances that it isn't spyware/malware/blackmailware that will take over their PC or steal their personal information. UWP is Microsoft's answer to years of criticism they received for the way process permissions work on Windows. They aren't going to just dump it all because you and a few others find the priviledge model inconvenient. > You can't even send an HTTP request to a little node.js Web server running on your desktop right now. If your node.js web server was network accessible you could. But, no, it won't allow unchecked IPC as that directly defeats the whole point of sandboxing to begin with. Personally I haven't used UWP much either, but that has nothing to do with sandboxing and everything to do with poor performance and UI issues (e.g. window controls, built in UI elements, etc). I still find the Windows 10 UWP Calculator horrible to use, it was a MASSIVE downgrade over the old one.
- WayneBro 10y ago
  > They aren't going to just dump it all because you and a few others find the priviledge model inconvenient. > But, no, it won't allow unchecked IPC... And I'm not asking for either. How about just giving the user a simple permission like they have for allowing UWP apps to access your Microphone, Camera, Bluetooth, etc? Seems a little silly that my UWP app can access everything on my network except for my own darn computer via localhost, doesn't it?
  - Someone1234 10y ago
    > Seems a little silly that my UWP app can access everything on my network except for my own darn computer via localhost, doesn't it? Unfortunately for historical reasons localhost (127.0.0.1) are treated almost like a named pipe. Meaning a LOT of Win32 (and UNIX-style) applications treat data over that path as "trusted." For one specific example, I've used a HP driver that installs a local webserver for no good reason, and if you can send a specially crafted request it will execute that request in the SYSTEM context. All you need is localhost access and knowledge to pull it off (this is not exploitable remotely). A lot of software has been designed with the assumption that localhost is trusted and they have therefore used it for IPC. This is exactly what you're attempting to do too. But let me ask you this, what happens if a third party UWP application tries to use your localhost backdoor? Does it allow UWP malware? How are you going to verify that only YOUR UWP application connects to your Node.js instance? File IPC allows you to limit it to just your UWP application because presumably the file will be within that UWP application's unique storage block. It might be a pain but at least the ultimate result is secure.
pjmlp 10y ago
I love sandboxes, on Windows, Mac OS X, Android, iOS ,Chrome OS X. One day my GNU/Linux installs will also only run sandboxed applications. I guess you don't use either an iOS or Android device, because you cannot do regular UNIX IPC on them.
- klibertp 10y ago
  > I guess you don't use I think he was talking about programming the apps, not just using them. From the looks of it (after reading the comments here and nothing more, so excuse me if I'm completely wrong) it may be a real inconvenience from the dev perspective: I can somehow understand the "no 127.0.0.1 communication" policy, but I expect to communicate with a spawned process via stdin/stdout pipes.
  - pjmlp 10y ago
    You have the same issue in other sandbox models. Old style IPC leads to information leaks and is another attack vector. You cannot do that on Android for example, Google explicitly removed UNIX V IPC from their Linux fork. You are expected to use TCP/IP or Android RPCs, assuming the app has android.permission.INTERNET permission. Also using fork/exec() on Android isn't a good idea, http://stackoverflow.com/questions/16179062/using-exec-with-ndk http://stackoverflow.com/questions/16179062/using-exec-with-... Which I doubt that would still work on Android 7 by the way. On iDevices, the same applies. https://developer.apple.com/library/content/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW24 https://developer.apple.com/library/content/documentation/Se... So people are complaining about Microsoft adopting what is already best practices on the other desktop/mobile sandbox models.
    - klibertp 10y ago
      > You have the same issue in other sandbox models. Would what PC-BSD does with jails qualify as an exception? > So people are complaining about Microsoft adopting what is already best practices on the other desktop/mobile sandbox models. Now I'm curious - weren't people complaining when the other sandbox systems were designed/created? It really looks a bit inconvenient (I'm referring to the SO explanation of what Android Chrome does), so I'd expect some reasonable opposition. It could be that with time people got used to the restrictions and don't complain that often anymore. To be honest, I like PC-BSD model, but that's probably not a good idea for platforms where the resources are constrained. It works ok on the desktop, though - I didn't work with PC-BSD itself for long, but I did the same with Docker on Linux (for web browsers) and the performance hit wasn't that bad IIRC.

Kipters 10y ago

Care to elaborate on the HTTP part? You just need the "Internet (client)" capability in your manifest, it's even enabled by default when you create a new project Moreover, win32 desktop apps can use the AppService mechanism exposed by UWP apps (but cannot host an AppService themselves, just connect to UWP-hosted AppServices)

WayneBro 10y ago
Give it a try. You can't send requests to `localhost` or `127.0.0.1` at all. AppService is largely useless for IPC between UWP and Win32 since the UWP app can't initiate a request to the Win32 app. Another thing you can't do, which is really annoying: UWP won't let your code start an external process and use standard i/o pipes to communicate with it. The only possibility is to use files for IPC and you'd have to have your Win32 app listen for changes in the file or directory, then open it up and read the data. However UWP can't listen for changes in those same files, so it's a real PITA. All of the options are listed here - http://stackoverflow.com/questions/12341707/communication-between-windows-store-app-and-native-desktop-application http://stackoverflow.com/questions/12341707/communication-be... You can also use a loopback exemption, but it requires installing a fake root certificate (no thanks!) - http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureFiddlerForWin8 http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/Conf... or http://loopback.codeplex.com/ http://loopback.codeplex.com/
- Someone1234 10y ago
  > However UWP can't listen for changes in those same files, so it's a real PITA. It can via the ContentChanged event see this example: http://stackoverflow.com/questions/39737147/how-can-i-watch-for-file-changes-in-a-uwp-project http://stackoverflow.com/questions/39737147/how-can-i-watch-... > Give it a try. You can't send requests to `localhost` or `127.0.0.1` at all. Luckily getting the local IP address is easy enough from UWP: http://stackoverflow.com/questions/33770429/how-do-i-find-the-local-ip-address-on-a-win-10-uwp-project http://stackoverflow.com/questions/33770429/how-do-i-find-th... That will work since it is treated like all other network traffic. localhost and 127.0.0.1 are considered privildged routes since you can bypass the firewall and exploit local processes to escalate.
  - WayneBro 10y ago
    OK, so ContentChanged is new since the last time I looked - thanks for that! However, IPC via files is still a PITA in general compared to something easy like sockets. Using an external IP address is a terrible solution for communicating with another process on the same machine. As soon as you disconnect from the network, it will stop working.
    - nitrogen 10y ago
      What does IPC between UWP and native buy you? Do you have some legacy code that has to run natively (been there with a Java app many years ago using TCP to talk to a tiny host process for some native code)?
      - vmarsy 10y ago
        No the author, but I can see a use case where you have already existing "services"/"daemons" with your client Win32 app. If you want to rewrite the client from Win32 to UWP, it seems that you wouldn't be able to? Why do that? Indeed one could just call Windows 10 API from its existing client [1], but it seems that you would miss out on the easy install/update from the Store and other benefits a UWP app provides. [1] https://blogs.windows.com/buildingapps/2017/01/25/calling-windows-10-apis-desktop-application/ https://blogs.windows.com/buildingapps/2017/01/25/calling-wi...
- Kipters 10y ago
  Wow, it's weird I never actually tried to send a request to localhost on UWP, usually only to other PCs on the network during development. I didn't know that. The Win32 app can connect to the UWP AppService, on PC you can also bundle a desktop app in your package and start it when the UWP app is launched. This desktop app can then act as a bridge between your UWP app and the "legacy" world, offloading the "dirty" stuff to the slave desktop app. It actually works, I used this for getting the taskbar to blink in my side-project for a messaging app.
- rasz_pl 10y ago
  >http://loopback.codeplex.com/ http://loopback.codeplex.com/ is there anything like this, but working the other way around? I want to be able to forbid ordinary Win32 programs from accessing loopback/localhost.

PatentTroll 10y ago

I don't get the outrage over the rumored UWP only windows. There is no indication that MS would drop win32. This is a separate product, likely for a particular market. It's more of an iPad competitor than a Windows desktop replacement. So don't use it if it offends you, that's OK. I don't think this is all that forceful really.

WayneBro 10y ago
They already did UWP-only Windows. That was WindowsRT. Nobody bought into that either, but Microsoft still really, really wants that closed-market, walled-garden style business model to happen somehow and so they're going to keep trying. I believe that their next strategy is to release a full Windows OS (with Win32) that runs on ARM which lets Win32 apps run via an emulator. In this environment, Win32 apps will most likely run like crap and as a matter of course Microsoft is going to keep pushing everybody (developers and users) toward the model that they think will make them the most money. It's really no problem for my career because I stopped exclusively using Microsoft's tech years ago and I'm comfortable using Linux or a Mac if necessary (but really, I can't stand their UI and I think Apple is even worse than Microsoft in many, many ways). I just like the Windows UI the best and I'd like to be able to build stuff for it in the future....but not if they are working towards taking away my freedom to control my own computer.
- pavlov 10y ago
  Microsoft famously keeps trying, and often the product initially looks like a failure until the third iteration is the one that clicks. (Windows 3.0, Surface 3, Windows NT's third version which was branded "NT 4.0"...) Windows RT was about as popular as Windows 1.0. I think Microsoft views the upcoming ARM-based "Cloud Windows" (whatever the branding is going to be) as the second iteration of this idea, and hopes to really gain traction a few years later.
- NikolaeVarius 10y ago
  RT was literally the exact opposite of UWP. I would argue they killed the RT BECAUSE of the shift torward UWP. The RT was a stopgap measure to try and force windows onto a Architecture it wasn't ready for. Most of it didn't work at all which is why it failed.

Someone1234 10y ago

> I love Windows but I seriously will not touch UWP until they loosen up the sandbox restrictions so that I can do regular IPC with a win32 desktop app. The whole reason for the UWP sandboxing is to make it so that users can confidently install UWP applications with some assurances that it isn't spyware/malware/blackmailware that will take over their PC or steal their personal information. UWP is Microsoft's answer to years of criticism they received for the way process permissions work on Windows. They aren't going to just dump it all because you and a few others find the priviledge model inconvenient. > You can't even send an HTTP request to a little node.js Web server running on your desktop right now. If your node.js web server was network accessible you could. But, no, it won't allow unchecked IPC as that directly defeats the whole point of sandboxing to begin with. Personally I haven't used UWP much either, but that has nothing to do with sandboxing and everything to do with poor performance and UI issues (e.g. window controls, built in UI elements, etc). I still find the Windows 10 UWP Calculator horrible to use, it was a MASSIVE downgrade over the old one.

WayneBro 10y ago
> They aren't going to just dump it all because you and a few others find the priviledge model inconvenient. > But, no, it won't allow unchecked IPC... And I'm not asking for either. How about just giving the user a simple permission like they have for allowing UWP apps to access your Microphone, Camera, Bluetooth, etc? Seems a little silly that my UWP app can access everything on my network except for my own darn computer via localhost, doesn't it?
- Someone1234 10y ago
  > Seems a little silly that my UWP app can access everything on my network except for my own darn computer via localhost, doesn't it? Unfortunately for historical reasons localhost (127.0.0.1) are treated almost like a named pipe. Meaning a LOT of Win32 (and UNIX-style) applications treat data over that path as "trusted." For one specific example, I've used a HP driver that installs a local webserver for no good reason, and if you can send a specially crafted request it will execute that request in the SYSTEM context. All you need is localhost access and knowledge to pull it off (this is not exploitable remotely). A lot of software has been designed with the assumption that localhost is trusted and they have therefore used it for IPC. This is exactly what you're attempting to do too. But let me ask you this, what happens if a third party UWP application tries to use your localhost backdoor? Does it allow UWP malware? How are you going to verify that only YOUR UWP application connects to your Node.js instance? File IPC allows you to limit it to just your UWP application because presumably the file will be within that UWP application's unique storage block. It might be a pain but at least the ultimate result is secure.

pjmlp 10y ago

I love sandboxes, on Windows, Mac OS X, Android, iOS ,Chrome OS X. One day my GNU/Linux installs will also only run sandboxed applications. I guess you don't use either an iOS or Android device, because you cannot do regular UNIX IPC on them.

klibertp 10y ago
> I guess you don't use I think he was talking about programming the apps, not just using them. From the looks of it (after reading the comments here and nothing more, so excuse me if I'm completely wrong) it may be a real inconvenience from the dev perspective: I can somehow understand the "no 127.0.0.1 communication" policy, but I expect to communicate with a spawned process via stdin/stdout pipes.
- pjmlp 10y ago
  You have the same issue in other sandbox models. Old style IPC leads to information leaks and is another attack vector. You cannot do that on Android for example, Google explicitly removed UNIX V IPC from their Linux fork. You are expected to use TCP/IP or Android RPCs, assuming the app has android.permission.INTERNET permission. Also using fork/exec() on Android isn't a good idea, http://stackoverflow.com/questions/16179062/using-exec-with-ndk http://stackoverflow.com/questions/16179062/using-exec-with-... Which I doubt that would still work on Android 7 by the way. On iDevices, the same applies. https://developer.apple.com/library/content/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW24 https://developer.apple.com/library/content/documentation/Se... So people are complaining about Microsoft adopting what is already best practices on the other desktop/mobile sandbox models.
  - klibertp 10y ago
    > You have the same issue in other sandbox models. Would what PC-BSD does with jails qualify as an exception? > So people are complaining about Microsoft adopting what is already best practices on the other desktop/mobile sandbox models. Now I'm curious - weren't people complaining when the other sandbox systems were designed/created? It really looks a bit inconvenient (I'm referring to the SO explanation of what Android Chrome does), so I'd expect some reasonable opposition. It could be that with time people got used to the restrictions and don't complain that often anymore. To be honest, I like PC-BSD model, but that's probably not a good idea for platforms where the resources are constrained. It works ok on the desktop, though - I didn't work with PC-BSD itself for long, but I did the same with Docker on Linux (for web browsers) and the performance hit wasn't that bad IIRC.