I ran into a wierd MameHooker bug, maybe you guys can help?

[Howard_Casto]

I've heard of some of the users running into a similar issue before, but I could never replicate it until now. 

Rather than posting the symptoms, let me first start with the cause.  Both mame and mamehooker must be launched with the same permissions for them to be able to communicate properly! It's that stupid win7 UAC again. 

If MH is launched in admin mode, and mame isn't... MH doesn't get any data at all, it's like mame hasn't even launched. 

Stranger still, is if mame is launched as admin, and MH isn't, MH will get the "Mame_Start" message, and "Mame_Stop" but nothing else.  Probably beause MH doesn't have the rights to send the "I'm here" message to mame.

So to any of you devs out there, is there a way to programatically fix this?

Sometimes users need to launch mame in admin mode because they will be shelling an app that needs admin rights.  I don't want to require mame to be launched in admin mode though, because if the users FE isn't also ran in admin mode, it will error out when launching mame.

Mind you somebody would have to be crazy to run UAC on a mame cab, but the issue doesn't make any sense to me, so I'd like to know what is going on.

[Gray_Area]

Mind you somebody would have to be crazy to run UAC on a mame cab, but the issue doesn't make any sense to me, so I'd like to know what is going on.

If it's a toggle-able feature/process, then why worry about it?  Regardless, I'm sure someone like Arby (let alone Aaron) would have an idea, hence this is not the place to ask.

[demeth]

It's both UAC and a part of it called UIPI that's the problem here, as what you want (bidirectional SendMessage using restricted message types between processes of different security levels) goes against the idea of the security policy in place.

Your options will boil down to:
1. [The one you noted] Just get the user to work around it by running both applications in the same security level, there shouldn't be much reason for any of them to run at different ones.

2. Switch IPC mechanism, the problem they tried to solve is that SendMessage can be used to mess any application up real good, and UIPI is pretty much a hack untop of it to get privilege separation without altering the API. Pipes, Shared Memory, Sockets, all have more developer definable access control.

3. [Fat chance] Write a manifest file for both programs that allows UI access between the two. This will either give you the nasty dialog (useless for a FE) or require your program to be signed with a certificate that matches one in the local chain and installed in a "secure location". Only high-end malware guys and Microsoft partners have those. Or you can get the user to install one of your own certificates .

4/5. Go Malware -- there's demo code circling around showing how to use broken COM objects in privileged processes to be able to inject your code into privileged processes (antivirus programs are a fun target).

6. Rethink WM_ types, not all are considered privileged by UAC/UIPI so there might be a combination that can be used to still do your handshake - I don't know them well enough to say which ones though.

[Howard_Casto]

Well I can't do 3-6.

3 is just out.
4/5 I refuse to write an app that shows up as malware, it's just the wrong way about doing things. 
6 is out as well.  The message types would have to be changed in mame, which is fine, but it would break not only mame hooker (which I can fix) but apps like led blinky, supermodel support, ect.  On top of that message types for outputs pretty much have to be custom ones due to the type of data sent back and forth, so there isn't much option in terms of changing it. 

2 is probably doable, but it isn't practical.  I talked with Aaron back in the day when he was implementing the system.  I went over a lot of suggestions with him, but the only one that seemed to fit in terms of being able to use it (easily) on multiple windows versions and from different programming languages was windows messaging.  Again, it would break everything out there, so it would be best to leave things as is.  I suggested a dll back then but officially mame's stance is that dlls are bad (umm k) since early in it's history mame had like 16 dlls and it was a mess to manage. 

Anyway, thanks for all the explaination, it helped.  I might try monkeying with the permissions and see if I can find a combo that'll keep both mame and mamehooker happy without much work on the user's end.  A simplier solution might be to change my shelling code to allow the launching of admin privelaged apps, the other oddball functions I have in there that somtimes need admin rights can be modified.

[headkaze]

I tried downloading MameHooker but got an error "Can't write to log file!"

Anyway my question is where do you install MameHooker or is it just a folder? I found that I had issues with several apps of mine on Windows 7 when it was installed in "Program Files" including CPWizard which uses MameInterop to communicate with MAME. Installing it into a folder in the root of C: seems to have solved those issues.

[Howard_Casto]

I tried downloading MameHooker but got an error "Can't write to log file!"

Anyway my question is where do you install MameHooker or is it just a folder? I found that I had issues with several apps of mine on Windows 7 when it was installed in "Program Files" including CPWizard which uses MameInterop to communicate with MAME. Installing it into a folder in the root of C: seems to have solved those issues.

I guess nobody is reading the words above my footer.... the ftp is broken... I don't have access to TDK and all file downloads are broken.  It's been like that for a month ever since the site move. (It was up for one night, thus the last blog entry.)  I guess woogie will fix it eventually.  Strangely enough, email server forwarding is still working, so I'm bombarded daily with "I can't download ____" emails. 

Nah I never install anything in program files for that reason.  Afaik this is a windows messaging issue, not something as simple as a folder problem. 

[headkaze]

Afaik this is a windows messaging issue, not something as simple as a folder problem.

CPWizard works in Windows 7 and uses Mame.dll like Mame Hooker does. So I don't think it's necessarily a windows messaging issue. The only difference between the dll's is the VB6 version has to handle strings slightly differently.

EDIT: I just looked at the VB6 version of Mame.dll again and I noticed there is no message pump loop. That seems very odd to me. I'm sure there was a reason for doing that but without one I can't see how messages are being dealt with.

Why not see if the VB6 and .NET demo's of Mame Interop work in Windows 7. If they do then it must be something else.

[Howard_Casto]

Yeah, I'll take a look at it later today, thanks.