Registering gives you access to our giveaways, forum features, increased search performance, access to our Download Library, create your own blog & gallery, and more!
Once you have registered, stop by in 'Hello World', and introduce yourself.
Minibroker COM API
Posted 27 April 2012 - 10:11 AM
Also, does anyone have any experience in calling the Minibroker COM from C++ in VS2010? I think I have it right, it compiles, but I can't test it because I can't get my SYS working properly.
Posted 27 April 2012 - 11:42 AM
An old hand at Premise, "John_in_VA", wrote several drivers for Premise using the MiniBroker and VB.NET. I developed a Text-To-Speech driver using C#, that runs as a service, but never released it. Its primary advantage is that it can run on another PC and communicate with a remote Premise server (i.e. a networked driver). However, I couldn't get it to work on Win 7 because of TTS restrictions. Eventually I wrote a Module-based TTS driver that does work on Win 7.
I've also attached the basic source (not the whole project) for an app called SYSTester which was the precursor of the MiniBroker TTS driver (runs as a Windows Form app instead of a Service to make it easier to debug). It is written in C# and demonstrates a few basics. It does not include the TTS driver's advanced features but can serve as a fair introduction to the basics. SYS.cs defines a class called SYSManager which is responsible for common "driver housekeeping chores" such as:
- Connecting to the Premise Server
- Establishing a heartbeat and watchdog.
- Automatically reconnecting after a connection interruption.
- Confirming the Premise Server has the desired driver schema.
- If missing, push the XML schema to the Premise Server (i.e. make the desired driver appear as a Device in Builder).
- Configure itself using user-defined values in app.config
- Manage property subscriptions.
I don't know of any MiniBroker examples in C++. I guess if one is proficient in C++, the HSDK might seem less daunting.
Edited by 123, 27 April 2012 - 11:44 AM.
Posted 27 April 2012 - 02:35 PM
The C# stuff helped... The classes, constructors, etc between C# and C++ are very similar (same even?). I also have not run the minibroker library through an analysis yet to see what calls are in it.
Posted 07 May 2012 - 10:00 AM
Here's the kicker... The minibroker DLL or COM is "funky" to say the least. It refuses to work with VS2010. Other COMs work no problem. And the minibroker COM works when called from IE/ActiveX and I can instantiate the object from other tools.
Very strange.. And continueing to dig.
It would be great if it was open source, and we could take a dive into to it. (Hint hint to anyone who might be reading.)
Posted 08 May 2012 - 01:45 PM
The issue was the calling appliction needs to have DEP compatibility turned off. If not, the exe opts in for DEP, this trickles down to the minibroker dll which really does not like DEP, and everything grinds to halt with absolutely no useful error codes. Setting the flag on the compiler to opt out of DEP, and everything works fine. There is *NOTHING* on the interweb about using COM objects and DEP being an issue.
That was fine and dandy until I compiled the code as a dll plugin for nodejs, and exact same issue re-appeared. But this time, setting the flag to opt out of DEP on the dll didn't work. The work around, and I hope I find another way around this, is to use an utility to remove the DEP flag from the original exe. In this case, the nodejs exe file. Doing that and everything works fine.
Next step... Flush out the wrapper a bit for connecting a pulling an object... And I'll post an example.
Edited by Timoh, 08 May 2012 - 01:46 PM.
Posted 08 May 2012 - 02:09 PM
Can you just turn off DEP at the Windows level? Maybe I'm honking of something else but ur seems like doing so would disable DEP for all apps.
Posted 08 May 2012 - 02:19 PM
Sorry I didn't spot your issue sooner. I came across the same problem a couple years ago and posted a solution.
Are you using minibroker on 64 bit windows? If so, have you had any success with property change subscription callbacks?
Posted 08 May 2012 - 03:03 PM
Umm, as per my post above, did you have a chance to look at post #3? Within that post it mentions the NXCOMPAT flag (and DEP) and links to the following article (dated 2007-12-13):
...There is *NOTHING* on the interweb about using COM objects and DEP being an issue. ..
The first paragraph states:
The C# compiler in Visual Studio 2008 and the .NET 3.5 Framework (csc.exe) is now generating PE files with the NXCOMPAT bit set. What is that bit and who cares, you ask? You may very well care if your application interops with native binaries or exposes a plugin model to 3rd parties. First, some background...
"Native binaries" like the MiniBroker COM object.
My attempt to create a MiniBroker-based Text-To-Speech driver caused me to bump into a problem with 64-bit Vista (driver development in 2009). I was using SSDP (Simple Server Discovery Protocol) to automatically connect, maintain, and reconnect (in the event of connection loss) to a Premise Server without having to use polling. It worked a treat on 32-bit XP and failed on 64-bit Vista. I assumed it was Vista's firewall because sometimes SSDP would work.
Anyway, that issue was wasting my time so I skipped it and continued with driver development. Ultimately, I discovered it was not possible to run TTS as a service in Vista (or Win 7). However, Property Subscriptions did work for my SYSTester application on 64-bit Vista (when SSDP was working). According to this post, John discovered Property Subscriptions fail on Win Server 2008 and, being in the same code family, Win 7 64-bit.
I'll try SYSTester again on Vista 64 and see what happens (still no Win 7 in my home).
Edited by 123, 08 May 2012 - 03:21 PM.
Posted 08 May 2012 - 03:57 PM
Anyways... Bygones as to why I didn't find it.
I'm not sure turning off DEP would work. I didn't dive into to it since I think DEP is good thing. But I did skim through a couple of folks mentioning the issue is with the NXCOMPAT flag and how windows interpets it versus DEP itself.
I'm sure I'll find a solution... Maybe by disabling dep on the node.js process, or if I can get more granular on the minibroker.dll or my node plugin dll. I'm not going to worry about it for now... I want to get back to focusing on is a Minibroker COM->C++->nodejs wrapper is feasable.
I haven't dived into 64 bit... yet. Of course the best solution for that would be to open source Premise and the community can make a 64 bit version available. (Hint hint to any one who may be reading )
Edited by Timoh, 08 May 2012 - 04:00 PM.
Posted 08 May 2012 - 06:12 PM
I look forward studying your example (and donating too)
Posted 08 May 2012 - 07:51 PM
If MiniBroker becomes a PITA under Windows 64, you might consider developing a native driver using the HSDK. You are comfortable with C++, and native drivers are developed exclusively in C++, so it looks like a good fit. All of the API calls you've seen in MiniBrowser COM are documented in the HSDK.
Native drivers run exclusively on the Premise Server. Minibroker-based apps can run on a remote PC with or without Premise Server.
Native drivers are tightly integrated with Premise Server. Minibroker apps depend on the MiniBroker COM object.
Native drivers are written in C++. Minibroker apps are written in whatever language that supports COM objects.
Native drivers can be loaded, started/stopped using Builder. MiniBroker apps are installed separately and have no UI component unless you include one.
A native driver, for your application, would talk an invented protocol of your design and connect to a remote (or local) node.js front-end via TCP-IP. Food for thought.
Posted 09 May 2012 - 03:58 PM
Posted 10 May 2012 - 08:36 AM
The other reason I backed away from native is because... Premise was written using MS ATL/Active Template Library. ATL is not included by default in VS2010 Express. The most recent version of ATL is unavailable unless you buy a copy VS2010. Older versions of ATL can be shoe-horned into VS2010, and this would probably be fine for Premise, but I didn't feel like mucking about trying to get ATL working just for a PoC and hobby project for a product I don't even run yet.
The upside is my solution will be scalable. And there are couple of options down the road we could consider. Do as 123 suggest and write a native driver to talk to a standalone UI/html/webserver renderer. This standalone could still be a v8/nodejs implementation. The cool thing about that is you could compile and run it on *nix, MacOS, + + +. Then Premise could talk via the native plugin to the html/UI layer. Or, along the same lines include v8 (and maybe nodejs) in a native plugin driver; don't worry about updates as previously mentioned. Then build the protocol using js+v8+nodejs features to talk to another server also running a standalone copy of nodejs.
That would make it so any js code someone might develop using the current approach, would also work with the native js/v8/nodejs driver if one is developped in the future.
Posted 10 May 2012 - 01:39 PM
So, 123 are you saying that property subscriptions work on Vista 64 with SSDP enabled?
Yes. I just re-confirmed using SYSTester BETA 3 (a MiniBroker-based TTS application). Here is how I tested it.
Athena. Win XP 32.
Gemini. Win Vista 64.
Test #1: SYSTester runs on Athena and connects to Gemini's Premise Server. Gemini can make Athena speak.
- This scenario "works for sure" because SYSTester is executed on Athena (Win XP 32) and it attempts to connect to Gemini's Premise Server.
- I turned off Gemini's Firewall. I had created rules to open UDP port 3976 but they failed to allow Athena to see Gemini's SSDP messages (i.e. Athena's Premise Server broadcasting its presence).
- Started DebugView to observe SYSTester's status messages.
- SYSTester is instructed to login to Gemini (via its config file)
- Click SYSTester's Start button.
- It uses MiniBroker's "SubscribeToDiscovery" method to (and I'm guessing here) broadcast a "who's out there" and looks for Gemini from among the replies.
- Gemini announces its presence (visible as a status message in DebugView along with the name of another Premise Server running in my home)
- SYSTester logs in and pushes a TTS Module into Gemini and creates a corresponding TTS Device called TTS_Athena. In other words, Gemini now sees Athena as a (remote) TTS device.
- Click the Speak property on Gemini's TTS_Athena device and Athena speaks the stock phrase "Premise speech is initialized".
- Click the ScanVoices property on Gemini's TTS_Athena device and its list of Voices (residing on Athena) is refreshed.
- Proof that SYSTester's Property Subscriptions, running on Athena Win XP 32, are working. The Speak and ScanVoices properties are two of four Property Subscriptions registered by SYSTester (Speak/Stop/ScanVoices/ScanOutputs).
- This scenario is the "will it work?" one because SYSTester is executed on Gemini (Win Vista 64) and it attempts to connect to Athena's Premise Server.
- Gemini's Firewall remains off.
- Stopped Gemini's DebugView because for a reason unclear to me it causes SYSTester to run glacially slow. DebugView does the same thing to Internet Explorer; I don't know why this happens but DebugView cannot be used.
- SYSTester is instructed to login to Athena (via its config file)
- Run SYSTester as Administrator. Click SYSTester's Start button.
- It uses MiniBroker's "SubscribeToDiscovery" method to (and I'm guessing here) broadcast a "who's out there" and looks for Athena from among the replies.
- Athena announces its presence (assumption because I can't use DebugView to see the connection progress).
- SYSTester logs in and pushes a TTS Module into Athena and creates a TTS Device called TTS_Gemini. In other words, Athena now sees Gemini as a (remote) TTS device.
- Click the Speak property on Athena's TTS_Gemini device and Gemini speaks the stock phrase "Premise speech is initialized".
- Click the ScanVoices property on Athena's TTS_Gemini device and its list of Voices (residing on Gemini) is refreshed.
- Proof that SYSTester's Property Subscriptions (Speak and ScanVoices), running on Gemini Win Vista 64, are working.
I think I sorted out the Firewall issue on Vista but I still can't run DebugView on Vista 64 without causing SYSTester, and IE, to stall.
Edited by 123, 10 May 2012 - 02:21 PM.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users