Problem sufficiently solved!
I figured out why the plugin GUI wasn't appearing. As those of you who have created your plugins probably already knew, there are two GUIDs that need to be added to the registry - not one. If I manually populate all required registry entries, the plugin works.
So, I was left with trying to figure out why regsvr32 is failing to actually register the dll, even though it reports success on completion. I learned something new today - how to examine a dll in debug mode while regsvr32 is executing. In function setKeyAndValue, I found that the result from RegCreateKeyEx was ERROR_ACCESS_DENIED. Also, function DllRegisterServer (which is called by regsvr32) returns S_OK no matter what happens - thus the outcome of regsvr32 always reporting success even when it fails.
Much online searching suggests that the crux of the registry issue has nothing to do with 64-bit, and everything to do with how Windows changed its registry editing access requirements starting with Windows Vista (I'm running Windows 7).
I have a working, but not so satisfying solution. First, I took Markleford's lead from his Ten Crazy deployments, and used a .bat to call regsvr32. It worked fine in all Windows XP 32-bit scenarios. Even under Windows 7, I get a success message, but as mentioned above, it's deceptive. Next, I tried right clicking the .bat and selecting Run As Administrator. Unfortunately, when you do this, the working directory changes from being whatever folder the .bat and .dll are in to being c:\windows\system32, and then it complains that it can't find the .dll. My solution for now is to reference the .dll with a static path inside the .bat. This is the unsatisfying part - it works, but the .bat needs to be edited if you want to put the .dll in a different directory, and you need to explicitly "run as administrator."
So, the sufficiently final solution to get everything working in the two sdk projects "MFCSample MFX" and "Sample MFX":
(these directions might be a bit specific to the sdk projects, but hopefully this will be helpful to anyone running into trouble with their own projects)
- Open the solution in Visual Studio 2010 Professional (I welcome someone else to try this with the Express Version)
- Agree to convert the project from Visual c++ 6.0 format to VS 2010 format.
- Agree to permanently remove version control bindings
- If you want to preserve your help system, you'll have to convert it to something more modern - good luck. Otherwise: from Solution Explorer delete:
- the .hpj file
- the entire Help Files directory
- Within the solution, select the project, and use the Configuration Manager to change the Active solution platform from win32 to x64.
- You'll now have to fix any broken deprecated items. For both projects, I only found errors in the Property Page code, but the errors were different in the two projects.
- MFCSample MFX: In files MFCSamplePropPage.h and MFCSamplePropPage.cpp, the return type of the callback function DialogProc needs to be changed from BOOL to INT_PTR.
- In Sample MFX: In file PropPage.cpp, function CPropPage::StaticDialogProc, change:
- SetWindowLong to SetWindowLongPtr
- GetWindowLong to GetWindowLongPtr
- The two instances of DWL_USER to DWLP_USER
- Rebuild and ignore the warnings if you dare. Almost all of the warnings have to do with string copy and concatenation functions. The deprecated versions have no bounds checking and allow buffer overflows, whereas the new versions perform bounds checks. However, when has a buffer overflow ever caused any trouble... :) points finger at the Morris Worm
- The sdk projects are configured to automatically register the dlls. However, the registration will fail due to the permissions issue.
- copy the .dll from the debug or release folder (as the case may be) and stick it in C:\Program Files\Cakewalk\Shared MIDI Plugins\
- Create a .bat file in the same directory, and put the following line inside of it (replacing MyPlugin.dll with the actual name of your own plugin):
- regsvr32.exe "C:\Program Files\Cakewalk\Shared MIDI Plugins\MyPlugin.dll"
- Right-click on the .bat file and select "Run as administrator"
- Rock and Roll
If anyone can identify an elegant way to elevate permissions and remove the need for a static path in the .bat, then I'm all ears.