Programming for Vista ?
in [MFC]
|
From: Tom Serface on 8 Dec 2006 19:30 So far it loks like things work about the same to me. The only differences are going to be applications that are more hardware/driver specific and, of course, if you want any of the special Vista controls or features. My guess is that most people will choose backwards compatibility to XP and Win 2K at least until WinFX is mainstream. Tom "Robert A." <invalid(a)invalid.org> wrote in message news:ePTSMpwGHHA.3268(a)TK2MSFTNGP04.phx.gbl... > Hi guys, > > Will programming for Vista be much different than WinXP ? Will MFC still > essentially be wrapper classes for the underlying Win32 SDK ? > > I'm still using VC6, I never switched to .NET, and I'm getting a little > worried. > > Thanks.
From: Daniel James on 9 Dec 2006 07:18 In article news:<uJgs6lxGHHA.5104(a)TK2MSFTNGP03.phx.gbl>, David Webber wrote: > It's not a question of MFC or whatever but of what you do with it. The > main problems (this is my guess) will occur with the User Account Control Yes, UAC breaks some stuff that it's not entirely obvious will be broken. I help maintain one application (which uses some MFC, but is mostly still a WinAPI app) that uses WH_JOURNALRECORD and WH_JOURNALPLAYBACK hooks to implement a keyboard macro recorder. Under Vista the SetWindowsHookEx functions that try to install these hooks fail. This is because UAC thinks the app might be a keylogger -- the solution (which we haven't tried yet) is to provide a manifest that says the app can use these hooks AND to get the app code-signed AND to install it in a trusted location (e.g. within "\Program Files"). Now, I can see a lot of sense in preventing keyloggers -- though it will provide a few more hoops for the writers of system-wide macro recorders/players to jump through. It makes no sense to prevent an application from logging *it's own* keystrokes, though. Why couldn't Vista allow the hook to be installed, just as in previous versions of Windows, but filter what the hook actually sees (based on the privilege of the running app) so that apps that only care about logging their own input could run as before? > Even that should not be too noticeable initially - though it may cause > some surprises - because of a "virtualisation mechanism" which makes it > look as if you have done what you are not supposed to. Nice idea ... but that approach is clearly NOT being used in the case of the journal hooks. The lesson here, I think, is that it's much harder to retro-fit basic levels of security to an insecure OS that's been in the field for years than it is to design them in in the first place. Microsoft is now struggling to effective and non-disruptive patches for the security holes resulting from its appallingly lackadaisical approach in the early days. To answer the OP's question, though, most things work just fine on Vista, and our app works on all Windows versions from Win95 up. Cheers, Daniel.
From: David Ching on 9 Dec 2006 10:27 "Daniel James" <wastebasket(a)nospam.aaisp.org> wrote in message news:VA.00000fc6.5348bb2d(a)nospam.aaisp.org... > I help maintain one application (which uses some MFC, but is mostly still > a > WinAPI app) that uses WH_JOURNALRECORD and WH_JOURNALPLAYBACK hooks to > implement a keyboard macro recorder. Under Vista the SetWindowsHookEx > functions that try to install these hooks fail. This is because UAC thinks > the > app might be a keylogger -- the solution (which we haven't tried yet) is > to > provide a manifest that says the app can use these hooks AND to get the > app > code-signed AND to install it in a trusted location (e.g. within "\Program > Files"). > Sounds like I need to read up more on Vista. I was told at PDC 2003 (way early, I know) that SetWindowsHookEx would continue to work as long as the app doing the hooking had at least as much priviledge as the app being hooked. It seems they also basically added the criteria that the hooking app needs to be properly signed and installed. Thanks, David
From: Daniel James on 10 Dec 2006 08:27 In article news:<eBAeh.242$yC5.98(a)newssvr27.news.prodigy.net>, David Ching wrote: > I was told at PDC 2003 (way early, I know) that SetWindowsHookEx would > continue to work as long as the app doing the hooking had at least as > much priviledge as the app being hooked. So it does for many hook types, AIUI, but the WH_JOURNALXXX hooks are essentially system-wide hooks -- they don't just hook the current app, they hook everything -- so unless they are running at as high a privilege as anything in the system they have to have a special privilege. My point was that there is a "Gotcha" here, because a lot of apps that use the journal hooks don't actually look at keystrokes to/from other apps -- they only want to log their own input. Maintainers of these apps may not expect their macro facility to be broken by UAC, and will be in for a nasty surprise. To implement an appropriate degree of security, here, UAC doesn't have to block the SetWindowsHook call, it could just filter the hook callbacks so that the app only saw its own keystrokes unless it had special permission to see them all. IOW: MS *could* have made UAC less intrusive, here, than they have. <irony> Thanks a bunch, guys. </irony> Cheers, Daniel.
From: Joseph M. Newcomer on 10 Dec 2006 15:47 I am reasonably convinced that Microsoft is totally clueless with respect to hooks and security. The pre-Vista security was a joke, and the key APIs needed, such as EnumerateHooks (I once wrote a specification and sent it to the hook group), to allow security audits, were omitted "by design". Why shouldn't I be able to discover which processes have set system-wide hooks, or for that matter, all hooks? joe On Sun, 10 Dec 2006 13:27:44 GMT, Daniel James <wastebasket(a)nospam.aaisp.org> wrote: >In article news:<eBAeh.242$yC5.98(a)newssvr27.news.prodigy.net>, David Ching >wrote: >> I was told at PDC 2003 (way early, I know) that SetWindowsHookEx would >> continue to work as long as the app doing the hooking had at least as >> much priviledge as the app being hooked. > >So it does for many hook types, AIUI, but the WH_JOURNALXXX hooks are >essentially system-wide hooks -- they don't just hook the current app, they >hook everything -- so unless they are running at as high a privilege as >anything in the system they have to have a special privilege. > >My point was that there is a "Gotcha" here, because a lot of apps that use >the journal hooks don't actually look at keystrokes to/from other apps -- >they only want to log their own input. Maintainers of these apps may not >expect their macro facility to be broken by UAC, and will be in for a nasty >surprise. > >To implement an appropriate degree of security, here, UAC doesn't have to >block the SetWindowsHook call, it could just filter the hook callbacks so >that the app only saw its own keystrokes unless it had special permission >to see them all. IOW: MS *could* have made UAC less intrusive, here, than >they have. > ><irony> >Thanks a bunch, guys. ></irony> > >Cheers, > Daniel. > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Help with CHTMLView and Session Next: leak using Clipboard in Unicode with richedit |