We're porting our USB device dll's to use the generic WinUsb.
However, WinUsb doesn't support multiple concurrent application accss to the same device (Same VID & PID).
I wanted to know if there is a way to implement this concurrent access using WinUsb?
I read about filter drivers & services.
1. I don't want to use a filter driver because, as I understand, this will have to pass WHQL, and I rather not go this path.
2. Regarding a windows service: How exactly should I implement it? should the service get all of the calls to WinUsb, and if a different application tries to access the same device, it will close the connection to the first application, open a new connection, and back again?
Is the service the right correct solution in this case? Is there another way to implement the solution other that what I wrote?
Thanks.
A filter driver does not need to pass WHQL. You only need to sign the catalog file, needed by the driver package. This only needs a code signing certigficate from verising/... . This should be a good starting place to get to know this.
Nevertheless, a kernel driver can be hard to develop. So maybe a COM server would be a better approach. You implement this sharing from a service, by allowing COM-clients to create objects from your service and then implement some kind of sharing/mutual exclusion in your COM-server.
A COM-exe servers can be written relativly fast.
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 problem background - there are two different windows applications that are trying to access webcam on the computer at the same time. Currently, only one application is able to access to it. I want to be able to allow both applications to simultaneously access the webcam. A common example of my problem is, skype and yahoo messenger trying to access the webcam on the computer at the same time.
I found a few softwares (manycam.com, http://www.splitcamera.com/) that allow this on windows. But I am not sure how they implemented it. I want to write the code myself to achieve this since my code needs to be integrated with other APIs.
I appreciate if anyone can shed light on how to write a device wrapper to achieve this.
The kernel camera driver registers several OS-defined callbacks. One of the callbacks is used for the output stream. Dedicated Windows applications have an interface to this stream - you'll need to do some reading on this subject, it's not something that can be covered in scope of SO. You need a component that will be layered in between the client applications and the camera driver. This component should intercept your camera driver output and duplicate it for the registered clients. This can be achieved either in kernel (filter driver) or in user mode (preferable). http://msdn.microsoft.com/en-us/library/windows/hardware/ff557573%28v=vs.85%29.aspx is a good place to start.
Note: this functionality might be already supported by your camera software (though I think the chances are very slim) and in this case you should dig into the corresponding documentation.
I'm developing an app for filtering network connections from clients to my server (deny or allow to connect to my server).
I'm researching and found some resources like Windows Firewall API.
But I don't know if it's necessary for me or not.
What's the best API or solution to resolve it?
Thank so much.
regards,
Why don't you use an already-developed and proven app in the first place? If you really want to develop a filtering layer then what you need is a Filter driver and more specifically NDIS filter . A sample solution can be found here. But unless you are absolutely sure what you are doing and what you want to achieve I'd strongly suggest that you stick to an off-the-shelf solution - any firewall will be decent, or even a linux machine in front of your server with appropriate iptables rules.
Since you are working in a windows operating system. You would have to make use of Windows Filtering Platform as seen in the documentation on https://msdn.microsoft.com/en-us/library/aa366510.aspx
Drivers like TDS,LSP, and NDIS are all deprecated.
The programming language is C++. In my experience, it was a desktop application with the GUI in WxWidget and writing the filtering network connections hooks into the user mode.
There are two Filtering Layer Identifiers (Run-time Filtering Layer Identifiers and Management Filtering Layer Identifiers ), i made used of the earlier being that its more effective.
Should you need more assistance let me know.
I want to develop one driver so i have create one service and one .sys file for driver to be display now i do not know how to attach that two file or how to register my driver to windows.
so just tell me the step which i should follow.
Thanks and hoping for positive response.
You can load driver by using StartService API. And you can also use ZwLoadDriver. It's a native API. You can find more information about them in MSDN.
Depends on the driver you write. If it's a device driver it's automatically loaded once the system needs it for the previously defined device classes.
For drivers which don't need devices you need a special driver service. See this CodeProject example - section "Dynamically Loading and Unloading the Driver"
Basically the most straightforward is using the following apis (in that order). I think it should be pretty straight forward.
http://msdn.microsoft.com/en-us/library/ms684323%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms682450%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms686321%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms682028%28v=VS.85%29.aspx
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.