21 replies to this topic

[Timoh]

Does the MiniBroker COM API support the same classes, interfaces, etc as what's documented in the SDK API?

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.

Tim

[123]

There's plenty of overlap between MiniBroker and the HSDK. The attached file contains several examples of using MiniBroker with HTML/Javascript (faster and easier to tweak than a compiled language). The "TestSuite" folder contains Test.htm. Assuming Premise is loaded with the Apartment model, Test.htm has a combo-box loaded with MiniBroker's methods and allows you to test them. There are also C# and VB.NET examples from the old forums. I have other C# examples but they are all .NET circa 2003 so they have many deprecated functions.

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.
• etc

SYSTester.cs uses the classes defined in SYS.cs and goes about its business of creating a TTS driver.


I don't know of any MiniBroker examples in C++. I guess if one is proficient in C++, the HSDK might seem less daunting.

Attached Files

•  MiniBroker_Samples.zip   80.9K   8 downloads
•  SYSTester.zip   8.96K   9 downloads

Edited by 123, 27 April 2012 - 11:44 AM.

[Timoh]

Uggghh.... This is going to be "fun". I don't have choice for C++. I'm not writing a plugin for Premise to work with something else, I'm writing a plugin for something else to work with Premise. The "something else" is SDK'ed to C++, and there are advantages to doing it the way I'm doing it. Vague I know., I just don't want to generate hype on nothing.

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.

Tim

[Timoh]

Big Sigh.... My post buried the jquery thead about getting COM to work wasn't true. I was missing catching an error and thought it was succeeding.

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.)

Tim

[123]

FWIW, MiniBroker COM works with VS2005 and VS2008 (using C#). Ensure apps are compiled as 32 bit. The third post in this thread:
http://cocoontech.co...o-speech-driver
contains information you need to know when working with MiniBroker on 64 bit Windows.

[Timoh]

Found the issue... After banging my head against the wall for week+.

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.

Tim

Edited by Timoh, 08 May 2012 - 01:46 PM.

[roussell]

Hey Tim,
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.

Terry

[John in VA]

Hi Tim

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?

John

[123]

...There is *NOTHING* on the interweb about using COM objects and DEP being an issue. ..

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):
http://blogs.msdn.co...c-compiler.aspx

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.

PS
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.

[Timoh]

I really didn't do that much hunting on minibroker stuff... Everything was in C#, and since I was am in C++ land, I just silo-ed the two and it never crossed my mind to go deep on previous (C#) projects. I should have been more specific... There isn't much to lead you in the NXCOMPAT or DEP direction. The interface createinstance throws class not registered as an error and Access Violation on the stack. I was looking at permissions, threads, multi/apartmodels, bad C++ automatic smart pointers using #import... All sorts of things. DEP final came out at me by simply scrolling through the compiler options, and I had an a-hah moment.

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 )

Tim

Edited by Timoh, 08 May 2012 - 04:00 PM.

[etc6849]

Tim this is awesome news. It sounds like you very are close to enabling javascript to subscribe to property changes? It would be neat not having to worry about polling. Finally a 100% capable alternative to the built in automation browser!?! Your fresh approach along with w84no1's work is definitely welcome.

I look forward studying your example (and donating too)

[123]

Tim,

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.

Comparison:

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.

[John in VA]

So, 123 are you saying that property subscriptions work on Vista 64 with SSDP enabled?

[Timoh]

I did think about going native... But backed away when I was researching nodejs and Google v8. If I baked the v8 js engine and nodejs into a native Premise driver, I might have to release a new driver every time nodejs or v8 was updated. It's probably not a must, but if a nice new feature came out in v8/nodejs I would have to compile it in to the Premise driver and release. By contrast, using COM, and a seperate nodejs engine, if nodejs/v8 get updated, users can updated their install if they want, and I don't need to rerelease the nodejs Premise addon.

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.

Tim

[123]

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.

Test Bed
Two PCs:
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).

Scenario #2: SYSTester runs on Gemini and connects to Athena's Premise Server. Athena can make Gemini speak.

• 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.

PS
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.