2 questions:
1) Is it possible to hook into the Share Broker in Windows 8 Metro, so that I am able to write a program that gets invoked each time an windows 8 app shares content with another windows 8 app? For example i would like to automatically make modifications to text content that is shared between apps. If so, i guess it would only be possible with Win32 API am I right?
2) Is the same thing possible for the Clipboard in Windows 8 Metro?
I guess WinRT is too sandboxed for writing such a global interception demon, but i could imagine that it is possible when using Win32...
thanks for you help!
Although you can monitor the clipboard using Win32 there is no way (at least that I'm aware of) to intercept a Share. Share itself is considered a contract and contracts are the only means for communication between two applications or even between one application and the shell. Allowing another application to intercept and potentially modify the data sent across a contract could present a security risk for impersonation, data stealing, etc.
Related
I have a situation which would be easily solved if we were using android as originally designed (and partially coded). Unfortunately, we're going the MS C++ on Windows Enterprise route because of some vital legacy applications. Basically we're coding a launcher that needs to start an application and when that application is closed, the user is brought back to the previous application (the one that launched the 2nd application). I hope that makes sense.
I know this can be done because I vaguely recall an application I used in college for taking exams did something like this, but when I do a search all I get are android solutions. Any help or links to libraries to look at will be wonderful.
there are may ways here are 2 most obvious:
most easy and safe way is that launched application send message to launcher that it is closing
but you need to add code to that application
you can use windows messaging or mailbox or semaphores or whatever else.
launcher periodically checks if there is active window handle of the right class/type/GUID.
if not then pop up the restore/maximize or visibility and set focus to it self.
you need to know what class is that app of yours
of course if there are more apps of the same class/id/type/GUID this way you cannot know which one is which
OK, it might be a problem with my system but I'm having a very difficult time getting Windows 7 to recognize my custom exe as the default handler of the mailto protocol.
First, I've seen this:
Register Windows program with the mailto protocol programmatically
Next, I've seen these:
How to Register an Internet Browser or Email Client With the Windows Start Menu
Registering an Application to a URL Protocol
I've added what seemed the appropriate registry entries but I still get Windows Live Mail coming up every time I click a mailto link (whether in a browser or via the Run window). I've set the registry entries for all users and for the current user, still it doesn't work.
When I go to the 'default programs' app and scroll down to the mailto protocol, I only see Outlook and Windows Live Mail listed. My custom app doesn't even appear.
I figure that it's either something special with Windows 7 or it's something with my computer.
My custom app is a WinForms .Net app but I don't think that matters.
Any ideas are greatly welcome.
The way described in the answer which you referenced in your question seems correct way for Windows 7 as for other operation systems.
I suppose that you use 64-bit version of Windows 7 and your program is 32-bit application. So if your application write in the HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\shell\open\command key it modifies only the key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\mailto\shell\open\command used for 32-bit applications. You can read more about registry virtualisation here and here.
If it's your case you can call directly native Win32 API RegOpenKeyEx with the KEY_WOW64_64KEY flag which will be ignored on 32-bit operation system.
Though a pretty late answer, what worked out for me is this: On regedit, this supersedes the registry keys mentioned in other answers:
HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\URLAssociations\MAILTO\Userchoice
Have a look at this page:
Default Mailto Registry
How can I add a custom url handler on Windows. Like iTunes itms:// Related but not.
This seems like a very high-nerd-level context to a fairly common problem. As a nerd, I'm swept up by the discourse on 64 vs x86 and the pseudo-universal binary aspects of .net. But the tech support troubleshooter in me can't help but think that the core problem needs to be made plain and addressed systematically...
So your real problem, regardless of the mail client (as you said yourself), and regardless of your CPU, is that you can't get your mail client to be the default protocol handler for mailto. Or to make it really simple, you can't get the program you like to be the default program.
I'm inclined to think that the 64/86 aspects of the problem are not relevant. They are interesting, and possibly having some effect, but if the program is running just fine (no issues with the code in that architecture, etc), and if it does email just fine (emails get send and received, all SMTP and IMAP all the way), then I doubt the OS is plotting to keep the client from taking over as the leader of the porch dogs.
If anything, I would say that the client had self-esteem issues and is afraid to be the mailto protocol handler. Most clients can't resist asking if the should be the primary and if you say yes, they pass the word along to the other apps and to the registry. They make sure everyone knows they are the new Mailbox king in the house.
So, what I would try first (basic troubleshooting): install another mail client and see if it has the same issue. If it does, your OS is a bully and you'll want to explore such routes.
But if this other client can get into the default programs club and be made the mailto handler, then the problem is with your app. It's a big wimp that doesn't know how to properly assert himself.
But like so many underdogs waiting for a cool kid to take them under their wing (and by wing, I mean Thunderbird. Don't bother with any other client), your app can stand on the shoulders of the working third-party client.
We have to assume that Thunderbird did at least one and possibly two things that your app didn't do. The first was getting it's name tied to the protocol in the registry. Go poke around and see if you can find his name and how it's associated to the mailto protocol. Chances are good that you can swap out his name for yours, or at the very least try to pin the protocol to you as well.
The second thing that T-Bird may have done was get himself in the "Default Programs" list (a feature of 7 that I didn't really like, because it had a cool concept behind it -- ie, let's group apps together up front rather than wait and see every time if one of them can do a similar job. But Windows screwed that good time (big surprise) by acting like the overprotective parent it always is, and showing up at the kids' party and saying "I think these two should be in this group, don't you?"
Well, my hope is that by getting access to the mailto by borrowing it from Thunderbird, that you'll be welcomed into the default programs club, but if you aren't and you are still the mailto handler, I'd write it off, at least gloat about it for a week or two, before trying to tackle that issue.
Now, if Thunderbird can't get mailto control, I'm very inclined to think that Windows 7 as actually put in to place some sort of strange caste system, where the application and it's installer (eg user) must some how prove their worthiness to be in the group by figuring out what the big secret is.
Oh, and if all else fails, try restarting in Safe Mode with no networking, install your client in that environment, and starting it up. See if you can't make it the default while the others are in suspended animation. Do a test run (with no network, obviously) by writing a basic HTML page with a mailto and see if clicking on it opens your client.
THen cross your fingers when you start back up in normal mode.
Let me know if any of the above proved the least bit helpful.
So I have been charged with the task of making all of the computers for a small company only able to access a single website, sort of like a web kiosk. After playing with a lot of the whitelist web filtering software out there and finding nothing that is in the company's budget that really does what they want. (blocking user access to all programs except IE, and IE can only access one domain) I'm not the greatest programmer in the world but I figured I could throw together a really simple C# web browser that only allowed access to a particular domain and make the users use that. Problem is that C# relies on other things existing in Windows to work properly. If it were possible to then setup a windows machine so that when a user logs on, all Windows functions are hidden, but still running in the background, and one specific program is running, then this C# web browser would start on the right domain and that would really be all that the user could do. Does anyone know of a way to make this happen?
Other solutions to my problem would be greatly appreciated. I would prefer a solution that is user specific on individual machines, not a network filter or something higher up. So that I can access the full web and computers when I do maintenance on them and because users could just access one of the many wifi networks available from neighboring offices if it was network level.
Oh yeah, and some machines are windows 7, and others are running XP.
I suggest you use the CreateDesktop/ SwitchDesktop WinAPI Calls from user32.
E.g. http://msdn.microsoft.com/en-us/library/ms686347(v=vs.85).aspx
Don't know how to call this from C#, but I think it is possible.
So your should integrate a desktop creation and switching inside your simple C# browser (at start of it) or in separate application, which does start your browser. Add this application (or browser) to the user's autorun.
Be very careful, when you does a desktop switch, is it very hard (I think impossible) to switch back.
We're starting a new custom project right now from a client and one of the requirements is the process cannot be terminated unless the system is shutting down, restarting, or logging-off.
This application monitors the USB interface. We will be using WMI to query the device periodically.
The client want's to run the application on Windows XP Operating System and doesn't like installing .NET. So we targeted Visual Basic 6 as our language.
My main concern is this application cannot be terminated. Our Project Adviser talks about Anti-virus and yes, some of the anti virus cannot be terminated. I was thinking how to do the same in Visual Basic 6. I know there will be API involved on the project but where should I go? so API is ok with me.
I saw some articles that converts the EXE to a SERVICE, create Windows Service in Visual Basic 6, etc.
So please .. share your thoughts.
If you want to be evil, you can call the (officially) undocumented RtlSetProcessIsCritical NTDLL function. This will immediately BSOD the machine if your process is terminated.
You cannot create a process that cannot be terminated without some sort of kernel-mode hooking, which involves writing a driver. You might want to look into Rootkits: subverting the Windows kernel if you're interested in that. However, even with kernel-mode hooking there are still numerous ways to terminate processes. The alternative is to use user-mode hooking, easily bypassed but enough for very simple projects.
The solution you want to use will depend on how far you want to go with the termination protection. And even if you do succeed in preventing process termination, there may be ways of preventing your application from working properly - e.g. killing the WMI service.
I think you want to look at writing an NT Service.
More info here: http://www.montgomerysoftware.com/CreatinganNTServiceinVisualBasic6/tabid/161/language/en-US/Default.aspxlink text
It's really frustrating coding in VB6 right now specially I dumped my head in C# for 2 years though I coded in VB6 for 5 years..
Moving back is a pain as if I am starting a new programming language.
To be honest, you are trying to do something in VB6 that it really isn't that great at.
When you say 'cannot be terminated' - what do you mean by that? There are several levels there:
a) App shows a window but the user cannot close it with the X button, or it does not show one
b) App shows no windows or maybe sits in task tray
c) App shows no windows and cannot be shut down from the Applications tab of task manager
d) App cannot be shut down from the process list of task manager
(a) and (b) are probably easiest to do in straight VB. (c) is still possible, but getting uglier. (d) gets you into hack territory and would almost certainly be frownd upon if you did manage it.
If you really need to stop users closing then you can probably hack it to a greater or lesser degree, but the real answer is as the others have said - a system service (this is exactly the srt of thing they were intended for). However that is one thing that VB6 isn't good at so the best solution to your problem is c#.
Is there anything similar on Windows what would achieve the same as the InputManager on OS X?
If you are looking to inject code into processes (which is what Input Managers are most commonly used for), the Windows equivalents are:
AppInit_DLLs to automatically load your DLL into new processes,
CreateRemoteThread to start a new thread in a particular existing process, and
SetWindowsHookEx to allow the capture of window events (keyboard, mouse, window creating, drawing, etc).
All of these methods require a DLL which will be injected into the remote process. C would be the best language to write such a DLL in as such a DLL needs to be quite light weight as to not bog the system down. RPC methods such as named pipes can be used to communicate to a master process should this be required.
Googling for these three APIs will turn up general sample code for these methods.
I'm pretty sure Windows has an API that developers can use to create new kinds of text input systems. I gather there are a wide variety of text input systems in use in non-Roman-derived markets, many of which are provided by third parties.
It's unclear if that's what you were really asking about, though, because you just assumed everyone knows what you would want to use an Input Manager for on Mac OS X.
If you want to create a new type of input method, ask how to do that.
If you want to get your own code running inside other applications, ask how to do that.
Don't just assume people can read your mind when asking questions, and don't assume that they have the same experience that you do and will recognize all the same platform-specific terminology.