I am starting to design a DMO to run from inside a windows media player activeX control in Internet Explorer.
is there any reason why using windows named pipes from inside the DMO wouldn't work?
user permissions/privilages/ kernel mode stuff?
Thanks :)
Roey
I have not tried it but I can't think of any particular reason it could not work. However, keep in mind that starting with Vista Internet Explorer runs as a low integrity level processes so any pipe you connect to will need to have it's access control set accordingly.
I have done this from a FireBreath plugin (activex control on IE, npapi on others) and the only thing you need to keep in mind is that activex controls in IE are often running in low integrity mode, so you need to make sure you set the ACL mask on the pipe correctly. As long as you have it configured correctly, it works fine.
Related
I want to set up path redirection in both files and registry keys in the same manner UAC virtualization works for another process at launch time (either programmatically or using some existing interface).
For example, I want to run C:\my_path\app.exe and when it opens any file on disk (C:\other_path\file.txt) for writing, the actual open file should be C:\temp_for_my_app\C\other_path\file.txt.
I've seen some programs are able to set up such redirection (i.e. Sandboxie), but I'm unsure which mechanism they are using (not even sure if it is the same UAC virtualization uses).
Any insight into the way UAC virtualization implements it might be useful (your comment on this will be appreciated)
Try cmregistercallback() or API HOOKING to hook zwopenkey() and zwcreatekey()
I have a WEC7 powered machine and instead of the Explorer shell I have loaded the Taskman shell instead.
But the SIP (Software input panle) is behaving strange.
When I click a teck box, the SIP is shown for a few seconds and then it is hidden again.
On a WindowsCE 5.0 there are no problems.
Thomas
It may be that the SIP relies on Shell_NotifyIcon being supported and successfully called. This is the API used to include icons in the tray bar. Its implementation relies on a windows with a specific class and title so you may be able to copy the code needed from explorer and include it in your custom version of taskman.
But the best thing to do would be trying to debug the SIP using platform builder.
As far as I know the code for the virtual keyboards is available. I don't remember about the rest of the implementation but, in any case, trying to run it in debug mode may lead to some hints about the issue.
I want to make a windows application whose GUI will be streamed to another device (allowing remote control). The point is that I'm not willing to rely on creating Windows Sessions to isolate the GUI I/O's (1)
To achieve this, I started observing some existing solutions that are able to enable remote access using this premise to see if I could get a clue about where to start.
One of these solution is Winflector (BTW: it is free up to 2 connections).
I got interested in this solution because it seems (I'm guessing) it detects only the repainted regions. What I took from my observations are that:
While the streamed application is "invisibly" running locally in the same session I'm logged in (it shows the application process in my task manager), the application window seems not to be created anyhow - at least Inspect can't get any window information/handle of the application process - It looks like sort of a "GUI StdOut Redirection".
Apparently, no additional Desktop is created;
Also apparently, no Mirror Driver is installed;
Using Process Explorer, I found out Winflector adds some thread's to the original application process. I suspect it is about the GUI redirection (by the thread's names);
The application is started by the Winflector server - that is, it has control about the CreateProcess arguments.
What is the most likely technique to be used in this case?
Windows Hook?
Windows Messages interception?
Special Display Driver?
Sort of Memory Device Context?
Where should I start researching to get a similar approach? Any open source project regarding this subject would also be very welcomed.
PS: By my programming experience, this is sort of a whole "new world" - sorry if my questions are redundant/obvious/non-sense.
(1) That is, this application could be spawned, streamed and interact
with the remote client using the same session which a local user is
already logged in, without conflicting the IO (like a regular VNC
would do, for example). PS: At this moment, I'm focusing only at the
output.
I'm developing a filter driver which works on top of an input device. Notably I'm testing it on my development machine (and yes, I know this is a bad idea).
On Windows XP whenever I needed to reload the filter driver, I'd just execute a batch file that would disable-enable the relevant devices through devcon, thus cause my filter driver to unload and reload.
However, on Windows 7 there seems to be a specific measure built against disabling the input device which your session is using. The option simply becomes unavailable in the Device Manager and even devcon no longer works. It does work from a remote desktop session, along with the kernel debug print "Trying to disable physical device not enabled in this session." (which hints that something explicit is allowing me to do this).
Is there a way to disable this functionality of Windows 7? Or perhaps a workaround you can offer to run my disable-enable batch file from an unrelated session?
Using Sysinternals psexec to run dpinst.exe works around this limitation. (Not sure why, since the DpInst UI is still being displayed.)
It's possible, but is it appropriate to use SHFileOperation within a Windows service? All those SHxxx API functions in shell32.dll seem to have been written with user level programs in mind. Can I be certain SHFileOperation won't display GUI ever?
According to the SHFILEOPTSTRUCT documentation, you can use the following flags to prevent any UI from appearing:
FOF_SILENT | FOF_NOCONFIRMATION | FOF_NOERRORUI | FOF_NOCONFIRMMKDIR
or (if you're targeting Windows Vista), FOF_NO_UI, which is the same as the above.
Looking in the ShellAPI.h header file in the Windows SDK, the comment against FOF_NO_UI says "don't display any UI at all", so from this I assume it's OK to use SHFileOperation.
I would say, not it's not appropriate or advisable. Most of the shell32 APIs were written with a basic understanding that they would be used in interactive processes. I don't think there is any way you can guarantee that SHFileOperation will never display a UI component. In fact, if you look at IFileOperation (which is the new Vista interface that replaces SHFileOperation), it clearly states:
Exposes methods to copy, move, rename, create, and delete Shell items as well as methods to provide progress and error dialogs. This interface replaces the SHFileOperation function.
I have to agree: not appropriate or advisable.
The prinicpal reason to use SHFileOperation is to perform operations with a UI, and/or which are reversable. I.e. using SHFileOperation to delete files is going to place the files in a recycle bin rather than deleting them allowing the current interactive user to undelete, or undo the operation performed.
As the services run on a non interactive desktop, no one will ever be able to clear that recycle bin out.
I had this issue as well and working at implementing a secure and reliable network file copy between servers and network shares ( most of these shares are CIFS / NetApp filer based ) and SHFileOperation fails from time to time.
now started using ROBOCOPY (available by default in all Microsoft OS from Vista/Server 2008 upwards) and really looks interesting and reliable.
this has opened my eyes: https://stackoverflow.com/a/1030752/559144