In Windows XP it was possible to substitute the logon interface for your own GINA implementation that could add additional features to the logon screen as well as implement some organisation-specific features.
I've looked at a number of MSDN articles and they all suggest that it is impossible to achieve that with the new logon system (Windows Vista and newer).
However, at the login screen or every time the SAS sequence is invoked, the LogonUI process starts up and provides a GINA-like interface for the user to interact with.
I was wondering, is it possible to roll your own implementation of LogonUI for the purpose of replacing the login/SAS UI? I couldn't find any articles on it, but I think it is a viable option.
Tad late, but here you go. You can create a custom credential provider with your own fields to accept logon credentials (whichever form they may take). If you want to go beyond that and build a bit of workflow, you will need to launch a modal window in the credential's SetSelected method. You can then pretty much use your GINA implementation (without the actual GINA functions). Use the CPUS type to know which mode you are running in (LOGON, LOCK_WORKSTATION, CHANGE_PASSWORD etc.) and customize your UI accordingly.
Obviously, this is not the "recommended" approach (quite hacky, actually), but it is the easiest. One caveat: you will have problems with C-A-D timeouts etc., so be prepared for some surprises.
The other, possibly more elegant way, is to build the custom credential provider with the logon/unlock screen (the right way). Then provide links to trigger other workflows (for instance, reset password). You can write custom screens that get launched when a particular link is clicked by implementing the credential's CommandLinkClicked method.
If you have time and you want to do this right, I would recommend the second approach. You will save yourself a lot of headaches down the road.
Related
At my company we have a really old program, maybe written in Delphi or something. We don't have the source code. The program works well, but we want to:
Hide some features from the user.
Prevent some actions, if the user doesn't have the right priviliges.
Automate a sequence of actions inside the program, with a press of the button.
How could it be possible to write a wrapper program around this exisitng Windows application with GUI. Which:
Hides the original underlaying programs GUI.
Allows the user to control the underlaying program, but with our given rules.
The new program could be really simple, but I dont't know what are the right tools for this.
Maybe consider AutoIt to pilot "automagically" the old program, since this language features native methods to programmatically interact with GUI, and probably can also hide / protect "dangerous" controls too.
You can even implement a new GUI (with AutoIt itself, BTW it uses an UI designer close to Delphi's one), just to wrap the one only controls you need, with preliminary consistency checks before sending them to the old GUI.
I successfully used AutoIt to automatically install programs that required user interaction during setup to properly install them (i.e. old MySql setups), so I don't see what would be impossible to do with it in your case.
Well the title seems pretty clear about what I want to do.
More precisely: I want to create a program (c++ or java is preferred) that manipulates the mouse in two ways, like: changing its position and doing clicks.
I was thinking about using allegro (it has mouse routines to manipulate the things cited above) or sdl(which I don't know if has that kind of routine). I tried with allegro nsuccessfully. My problem here was that I couldn`t virtually "do" clicks. I also couldn't redirect the stuff changed by my program to some other window.
Any tips?
There are a couple of ways to try automating other applications on Windows...
At the simplest level, one can use PostMessage to post keyboard and mouse messages to another application's windows. This has the advantage that it could work even if the other application is minimized. Unfortunately, this approach skips the majority of the input processing logic so applications that directly access key state using GetAsyncKeyState will not see (for example) the control key being 'down' no matter how many WM_KEYDOWN, vk=VK_CONTROL messages you send.
As Hans Passant commented, SendImput places input events in a lower level input event queue, and so can fully simulate modifier keys. These input events are not posted to windows however, so to get the input events delivered successfully the normal windows rules of activation and focus need to be followed. That said, this is the approach used by most testing-automation software (and is why most testing automation software requires the application being tested be the active application).
The last of the automation methods Ill mention - and sadly the least likley to work - is the Microsoft UI Automation framework. This framework is intended to allow applications to be used by disabled and/or special needs users. Sadly - very few software providers bother to implement this API in their products.
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.
I'm wondering if there is a way to intercept that a Windows session is about to be locked and essentially provide a pop-up just before. We've got an intranet punch in/out facility, and many people forget to punch in or out before leaving for lunch or for the day. Essentially I'm looking for a way to give the users the option to log out when they lock their machines.
I am also completely open to the possibility that this may not be possible due to security concerns, but I wanted to see what the community's take on it was anyway. Thanks!
Haven't tried it, but the Microsoft.Win32.SystemEvents class might have what you want.
Specifically, you may want to try the SessionSwitch event. According to this bytes.com post, it should work:
Handle the Windows Lock Desktop event/message?
You can use the Remote Desktop Services API WTSRegisterSessionNotification to get lock notifications, but there doesn't appear to be any way to override the lock.
I'm working hard on making my product work seamlessly on Windows 7. The problem is that there is a small set of global (not user-specific) application settings that all users should be able to change.
On previous versions I used HKLM\Software\__Company__\__Product__ for that purpose. This allowed Power Users and Administrators to modify the Registry Key and everything worked correctly. Now that Windows Vista and Windows 7 have this UAC feature, by default, even an Administrator cannot access the Key for writing without elevation.
A stupid solution would, of course, mean adding requireAdministrator option into the application manifest. But this is really unprofessional since the product itself is extremely far from administration-related tasks. So I need to stay with asInvoker.
Another solution could mean programmatic elevation during moments when write access to the Registry Key is required. Let alone the fact that I don't know how to implement that, it's pretty awkward also. It interferes with normal user experience so much that I would hardly consider it an option.
What I know should be relatively easy to accomplish is adding write access to the specified Registry Key during installation. I created a separate question for that. This also very similar to accessing a shared file for storing the settings.
My feeling is that there must be a way to accomplish what I need, in a way that is secure, straightforward and compatible with all OS'es. Any ideas?
Do you have to have it in the registry? If not, put it into a simple file, writable by everyone. Writing to HKLM requires additional privileges for a very good reason.
I'm new to here (otherwise i would've left a comment) and i'm not a windows guru, but...
imho the premise is wrong:
there's a reason if a non-elevated user cannot modify registry keys or directories read by all users (like Users\Public by default)
i think that allowing any users to modify a small set of global application settings may be disruptive for the experience of the other users that didn't expect their settings to be modified
on the other hand i don't know your use cases...
could you please specify why all users should be able to modify these settings?
and if indeed all users have to be able to do it... why can't you make these settings user-specific?