! For the sake of simplifying things I will refer to Windows Store applications (also known as Metro or Modern UI) as "app" and to common desktop applications as "application" !
I believe this is still one of the most unclear yet important questions concerning app-development for developers who already have established applications on the market:
How to manage communication between apps and applications on a Windows 8 system? (please let's not start a debate on principles - there're so many use cases where this is really required!)
I basically read hundrets of articles in the last few days but still it remains unclear how to proceed doing it right from the first time. Mainly because I found several conflicting information.
With my question here I'd like to re-approach this problem from the viewpoint of the final Windows 8 possibilities.
Given situation:
App and application run on same system
1:1 communication
Application is native (written in Delphi)
Administrator or if required even system privileges are available for the application
In 90% of the use cases the app requests an action to be performed by the application and receives some textual result. The app shouldn't be left nor frozen for this!
In 10% the application performs an action (triggered by some event) and informs the app - the result might be: showing certain info on the tile or in the already running and active app or if possible running the app / bringing it to the foreground.
Now the "simple" question is, how to achieve this?
Is local webserver access actually allowed now? (I believe it wasn't for a long time but now is since the final release)
WCF? (-> apparently MS doesn't recommend that anymore)
HTTP requests on a local REST/SOAP server?
WinRT syndication API? (another form of webservice access with RSS/atom responses)
WebSockets (like MessageWebSocket)?
Some other form of TCP/IP communication?
Sharing a text file for in- and output (actually simply thinking of this hurts, but at least that's a possibility MS can't block...)
Named Pipes are not allowed, right?
There are some discussions on this topic here on SO, however most of them are not up-to-date anymore as MS changed a lot before releasing the final version of Windows 8. Instead of mixing up old and new information I'd like to find a definite and current answer to this problem for me and for all the other Windows application and app developers. Thank you!
If you are talking about an application going into the Store, communication with the local system via any mechanism is not allowed. Communication with the local system is supported in some debug scenarios to make app development easier.
You can launch desktop applications from Windows Store applications with file or protocol handlers, but there is no direct communication.
So, to reiterate the point... communication between WinRT and the desktop is not allowed for released Windows Store applications. Communication between the two environments is allowed in debug only.
The PG has posted in different places reasons for why communication is not allowed, ranging from security, to the WinRT lifecycle (i.e., you app gets suspended - how does that get handled re: resources, sockets, remote app, etc. -- lots of failure points) and the fact that Store apps cannot have a dependency on external programs (i.e., I need your local desktop app/service for the app to run, but how do I get your app/service installed? You cannot integrate into the Store app. You can provide another Store desktop app entry, but that is a bad user experience.) Those are high level summaries, of course.
Related
I am trying to port Wine 1.7.13 to modern Cocoa. I am considering running Windows binaries in an XPC service’s process, for security isolation and crash-proofing. However, there is one problem: To the best of my knowledge, XPC services are singletons. Only one XPC service process is allowed to be running at a time. This is a problem because, if I use threads to enable multiple Windows binaries to run at once, a segfault or other hard crash in one Windows binary would cause all the other binaries to crash with it.
As mentioned here, it is generally understood that the above assertion is true. If that is so, it would seem that I cannot implement this sort of isolation within a single XPC service process.
My other alternative is to use sandbox inheritance (having the GUI application fork and using more traditional IPC to have the Windows processes talk to each other) instead of an XPC service. What are the pros and cons of using that instead of an XPC service? I understand that processes that inherit their parent’s sandbox does not get to have its own entitlements. What other drawbacks are there?
I also understand that Apple discourages the use of sandbox inheritance in favor of XPC, but it is still an available design decision. They must have kept it around for a reason. Would a sandboxed Mac App Store app be able to use sandbox inheritance in this fashion?
I am going through the same decision. I had my heart set on XPC services, but upon discovering that there would be a single XPC Service with multiple connections, I cannot use them (my XPC Service will use plug-ins provided by third-parties so I want to keep them apart, and also the XPC Service will use libraries that might not clean-up properly, so I want to be able to dispose of them while keeping the UI stable - well I shouldn't have to justify this - I want one-process-per-job and that's that).
I am considering the normal sub-process model using posix_spawn() (I think this behaves better than fork() WRT to Sandboxing), CocoaAsyncSocket for the comms. I am going to see if I can replace the use of TCP/IP in CocoaAsynSocket with UNIX sockets to speed-up up comms (with the intent of contributing it back to the project if this works out). (UPDATE: this has already been done, some time ago by github user #jdiehl. See his socketUN branch and the discussion in issue #88 of the upstream repo).
For data marshalling I will use Google Protocol Buffers (UPDATE #2: Nope; not worth the hassle when NSKeyedArchiver and NSKeyedUnarchiver provide everything required out-of-the box. They may not provide data as packed as Google Protocol Buffers, but they 1) Don't require writing and maintaining, 2) Allow any class to participate by implementing the NSCoding protocol, and 3) Don't have to solve the issue of cross-platform data exchange.
The only possible disadvantage I can see is I don't know if file bookmarks can be passed to the subprocess and used (i.e. the UI opens a file or has a file dragged to it and wants to give access to the file to the worker process). I will update this answer with whatever I learn. (FINAL UPDATE: Passing the URL bookmark across the UNIX domain socket works fine, and the bookmark doesn't even need to be a security-scoped bookmark for this to work. There are no more impediments to this alternative to XPC).
Your assertion is incorrect about sub-processes not having their own entitlements; they do and are embedded into the executable and it must have "inherits sandbox" set for the sub-process to work correctly.
And the end-of-the-day the one-xpc-service-per-app is a show stopper so you have no choice but to find an alternative.
The question would be much clearer when use a concrete e.g,
Lets say I need to topup my mobile , I have two options
top up using sim services [UICC with OTA]
top up using a mobile-top-up-app (a hypothetical mobile app) [web-services https ]
my question is, what is the main advantage of option 1 over 2? what is so important about OTA?
OTA works out of the box as a 2G service (as such it benefits a huge coverage). It is supported by all devices regardless of brand, OS, country. The system also covers retrys to some extent. It will incur minimal cost to your customer, especially in roaming situations.
Using a data pipe works too, but you need to have an app deployed and running in the end-user's device.
I need to deploy an application onto some Windows machines for purposes of data collection from a group of people (i.e. the application will be used to gather responses to a series of survey questions). The process is interactive, alternating between displays of text and images with specific timing requirements. I have put together a prototype application using HTML and JavaScript that implements the survey. However, there are some unique constraints on the deployment environment that have me stuck:
While the machine is Internet-connected, the client requires that the survey application must run fully local to the PC that it runs on. Therefore, sending the survey results to a remote server is not permissible. Obviously, saving to a local file from a Web browser is typically not permitted for security reasons.
Installation of applications onto the machines that will run the survey is not permitted.
The configuration of the machines is not known specifically a priori, but I can assume some recent version of Windows with IE8+.
The "no remote access" requirement was a late comer, and has thrown a wrench into the plan of just writing a simple Web application that could post results to an HTTP server. I'm now looking for the easiest way forward. Two main approaches come to mind:
Use a GUI framework that provides a control that can display HTML/JavaScript; running a full-blown application on the PC would allow me to save the results to the filesystem. I've never done this, but it seems like in this day and age it shouldn't be too difficult. This would allow me to reuse much of my existing prototype implementation, but I would need some way of transferring the results (which would be stored in a JavaScript data structure) outside of the Web control to where the rest of the application could access it.
Reimplement the entire application using some GUI framework (I've used PyQt successfully before, although not on Windows). This approach is obviously less desirable than #1 due to the lack of reuse. However, it may be necessary if #1 isn't feasible.
Any recommendations for the best way to go? Ideally, I'm looking for a solution that can be run in a "portable" manner from a USB thumbdrive or similar.
Have you looked at HTML Applications (HTA)? They work in IE5+ and can use Windows Scripting Host to write to local drives and UNC shares...
Maybe you can use a portable web server with a scripting language on the server side. http://code.google.com/p/mongoose/ Mongoose, for example, you can run PHP, CGI, etc. .. scripts. Then, simply create a script to save a file to your hard drive. And let the rest of the application in the same manner.
Use a script to start the web server, and perhaps a portable web browser like K-Meleon to start the application http://kmeleon.sourceforge.net/ This is highly configurable. Or start the system explorer to your localhost URL.
The only problem may be that the user has to modify the firewall for the first time you run the server?
Why bother with multi-layer RIA if Internet now is fast enougth to do "traditional" fat client C/S?
What just use a plain C++ / Delphi / Oracle Forms / JAVA-Swing application talking directly to RDBMS thru Internet?
A very complex compiled exe program in Delphi is about 10MB, that amount of code downloads in a couple of minutes in a decent 1MB ADSL connection.
After all what is what we are doing with AJAX / BlazeDS / JSON / etc pushing thru http/https protocol but with a lot of layers and a lot of points of failure...
Comments please...
First a bit about terminology, what you refer as "traditional fat clients" are probably desktop software. Web applications are often written as thin clients, but they can also be written as fat clients. A fat client rich internet application are client centric, which means that a lot of the work is done in the client (browser). Fat client RIAs can be written with the help of technologies such as AJAX or Adobe Flash.
To compare the advantages of web based applications over desktop software:
Maintainability: One of the advantages of web based applications is the maintainability of them. You only have to make one installation of the application and then it is directly available for all users. Same goes for updating of the software, you only need to update the software on the server and then you can be sure that every single user is using the latest version of the software. This eliminates the need to update individual installments of the application on the users' computers.
Security: There are two positive security implication in using web based application. As said previously, you only need to update the software in one place. This means that the users always have the most up-to-date version of the software in use, thus eliminating the problem of people using outdated, vulnerable version of the application.
What is more important, is that fat client applications are insecure. They expose application logic and possibly sensitive data such as database credentials. Fat clients can be reverse engineered and attacks can be crafted based on the gained information. For an application to be truly secure, the application logic should stay on the server and the client should be thin and only server as a presentation layer for the information handled in the application. Do remember the exposure of application logic can also affect rich internet applications. It is easy to write RIA in a way that it exposes application logic. Hence it is important to remember that the application's state should always stay on the server, the browser is, as said, only means for presenting the data. In other words, both web based applications and desktop applications can be (in)secure, I'd just say that there is a greater risk of pushing application logic to the client when writing desktop software.
Platform independent: Web based applications are platform independent (with the exception in application that use platform specific functionality, such as activex). This means that your users can be using the application from a mac, a windows or a linux computer, it doesn't matter. Of course, it is unfortunately easy to create web applications that do not work/only works on specific browsers, such as Internet Explorer. Although, it is much easier to make a web application cross-browser compatible than to write a desktop software to be truly cross-platform compatible.
Accessability: If you are connected to the Internet/Intranet, you have access to the application. It doesn't matter if you have borrowed your friend's laptop or if you are sitting by your desktop computer, you still have access to the application since it doesn't require you to install anything on the computer. Just browse to the application URL.
In prior versions of Windows before Vista you could have a Windows Service interact with the current logged in desktop user to easy display information on the screen from the service. In Windows Vista Session 0 was added for security to isolate the services from the desktop. What is an easy way to communicate between a service and an application running outside of Session 0? So far I have gotten around this by using TCP/IP to communicate between the two but it seems to be kind of a sloppy way to do it.
You can use shared memory or named pipe to facilitate IPC as well. Conceptually this is similar to TCP/IP, but you don't have to worry about finding an unused port.
You have to make sure that the named objects you create are prefixed with "Global\" to allow them to be accessed by all sessions as described here.
AFAIK there is no way for a service to directly interact with the desktop any more.
Indeed, for security reasons it is no longer possible to communicate directly with the "desktop". What exactly is the "desktop" anyway, when you live in a machine with multiple active users + remote sessions?
The general way to solve the problem is to use service apps which communicate via some RPC mechanism (TCP/IP, IPC, .Net Remoting Channels over one of those, etc). Its kind of a pain, but I think the benefits are worth the change.
For the service to talk to the desktop, you're pretty much stuck with one of the RPC mechanisms. The .NET remoting mechanism (IpcServerChannel) isn't to hard to implement for this purpose.
Also with .NET a desktop application can send messages directly to the service with the ServiceController.ExecuteCommand. These commands are received by the service via ServiceBase.OnCustomCommand. This is even easier to do, and would be all you need if controlling the service is your only requirement.