.exe file with a win8 app solution?

Question

hi experts, I have a following scenario:

    I want to develop a win8 store app which work together with a win 32/X64 process. When store app start, in run time it fork or create a new process to start this win32/x64 exe. And with these 2 process, I need them communicate with each other through either socket or other IPC methods.

SO

    - Is this possible that I include a win32 exe in my metro package?

    - Can I fork a new win32/x64 process in win8 store app? so far I know the laucher defined 2 ways to create process, but that is not I want, is that the only way? Can I create a process like the linux fork? So that I may avoid put a seperate .exe in package as well.

    - I noticed the saying that IPC using loopback for example (socket to 127.0.0.1) are not allowed in store app, is this true? And how about other IPC? for example: named pipe or shared file ?

Answer 1

hi experts, I have a following scenario:

    I want to develop a win8 store app which work together with a win 32/X64 process. When store app start, in run time it fork or create a new process to start this win32/x64 exe. And with these 2 process, I need them communicate with each other through either socket or other IPC methods.

SO

    - Is this possible that I include a win32 exe in my metro package?

    - Can I fork a new win32/x64 process in win8 store app? so far I know the laucher defined 2 ways to create process, but that is not I want, is that the only way? Can I create a process like the linux fork? So that I may avoid put a seperate .exe in package as well.

    - I noticed the saying that IPC using loopback for example (socket to 127.0.0.1) are not allowed in store app, is this true? And how about other IPC? for example: named pipe or shared file ?

Answer 2

Hi XXXing,

None of what you ask for is possible in a Windows Store app. Windows Store apps cannot directly launch other processes and cannot communicate directly (as opposed to via Windows' pre-defined Contracts) with other processes through any method.

--Rob

Answer 3

thanks, Rob.

But I really think this be a limitation for lots app planing to migrate to metro platform. multiple process and IPC are pervasive, and to build a firewall between metro and desktop app has nosense, because they are on the same windows platform, what's the reason for this boundary? security? performance?

I strongly urge that win8 get rid of this limitation.

Answer 4

Windows Store apps are run in a tight security context called AppContainer, which is intended to make it much more difficult for Windows Store apps to host malware.

http://blogs.msdn.com/b/ieinternals/archive/2012/03/23/understanding-ie10-enhanced-protected-mode-network-security-addons-cookies-metro-desktop.aspx

http://recxltd.blogspot.com/2012/03/windows-8-app-container-security-notes.html

Answer 5

hi Rob,

I want to reopen this discussion because I found a sample published by MSDN actually it create out-of process exe running with the main:

http://code.msdn.microsoft.com/windowsapps/Creating-a-Windows-Runtime-ed84af9d#content

Looks it contradict with what you said.

So I am really confused -- can any one from Microsoft give out a offical announce, what indeed the application model can be support?

Answer 6

Not a contradiction so much as a simplification.

You can include and instantiate registration-free COM objects in your app package. This does not allow launching arbitrary Win32 executables. The COM object run inside your AppContainer and have the same abilities and limitations of any other Windows Store app.

This didn't seem relevant to what you were asking for, and I didn't want to confuse the issue. From what I understand of what you are trying to do it is not supported in a Windows Store app. It is possible that I am misunderstanding your goal. If you can provide more details about your scenario we can let you know if there is another way to achieve it.

That said, there is no support for direct IPC between different apps, specifically including IPC between Windows Store apps and desktop apps.

--Rob

Answer 7

Thanks Rob,

From the sample and your comment, here is what I am thinking:

So if I can revise the exsiting executables wrapped by this COM object and include in the Win8 app solution, I can make it coexist with the main App, right?

The following question is revising executable to the COM is the only way to make it coexist? Can we have anyother way to make the executable stay in the same app container as the main win8 app? Actually COM is not popular to most of the developers currently.

Answer 8

Can you please explain the scenario you are trying to achieve?

A COM executable which meets the requirements for Windows Store apps can be included in an app's package and called from that app, but this won't allow calling desktop apps or API.

--Rob

Answer 9

hi Rob,

Here is my scenario:

Originally we've already have a standalone exe doing some network communication stuff for us, and we communicate with it through IPC. And now we are going to have a new Win8 app and need use this functionality, so we are trying to include this exe into our package. As you mentioned, COM executable meets the requirement can be inlcuded in win store app, so I would think it is possible that we can revise the executable code and wrap it in a COM model and change the communication between Win8 app and the exe to COM interface call to meet the reqirement. I think this is feasible, since we have the source code, right?

Answer 10

Yes, that is correct. Both the COM executable and the Store app must be in the same package in order to communicate. Also, the COM object must meet the Store certification policies.

---

Matt Small - Microsoft Escalation Engineer - Forum Moderator
If my reply answers your question, please mark this post as answered.

NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.