SAPI in shared memory

I have SAPI now working within a DLL.  This DLL is a common element to 
multiple applications.  In this DLL, I use a shared memory segment for 
varables that are common to all applications.  I'm attempting to SAPI 
variables there:

In header file:
	extern CComPtr<ISpRecognizer> cpRecoEngine;
	extern CComPtr<ISpRecoContext> m_cpRecoCtxt;
	extern CComPtr<ISpRecoGrammar> m_cpDictationGrammar;


In cpp file:

#pragma data_seg("Shared")
               ....other stuff
	CComPtr<ISpRecognizer> cpRecoEngine = NULL;
	CComPtr<ISpRecoContext> m_cpRecoCtxt = NULL;
	CComPtr<ISpRecoGrammar> m_cpDictationGrammar = NULL;

#pragma data_seg()
#pragma comment(linker, "/Section:Shared,rws")

The first instance application to use the DLL works fine using the SAPI, but 
any additional applications get an access violation error implying the COM 
objects or their pointer are not in shared memory.

Any input?

Bruce K.

"Bruce K." <BruceK@discussions.microsoft.com> wrote in message 
news:A1B96507-3436-4598-945D-06C937D5D1D7@microsoft.com...
> The first instance application to use the DLL works fine using the SAPI, 
> but
> any additional applications get an access violation error implying the COM
> objects or their pointer are not in shared memory.

The COM objects that you are "sharing" encapsulate audio devices. You
can no 
more expect to share the handle to an audio device that you open in one 
application with another, any more than you can expect to share, say, a file 
handle between applications. That just doesn't work in 32 bit Windows.

Besides that, even if you could share the handles, it is not guaranteed (at 
least ion 2K/XP/2K+3/Vista that the shared memory resides at the same 
location. The pointers might well be invalid regardless of the state of the 
handles.

You can of course use the "shared" recognizer in as many applications
as you 
like so long as you create an instance an each application.

You may want to take a step back and explain what you need to do and not how 
you want to do it.

Regards,
Will

Thanks for input Will.

I wished I'd asked this question when I first posted the DLL question.  I 
had the same issue with a data acquisition resource I wanted to share with 
multiple applications. In this case, only one process can own the connection 
to the device.  My way around this was to create a thread in the DLL that was 
initiated by the first instance of the DLL. This thread would be the only 
connection to the device. All applications would then communicate with this 
single thread using DLL functions that incorporated event pipes to 
communicate with the thread.

I can either do the same as I did with the DAQ or simply make a small window 
application to perform speech I/O and communicate with the DLL.

The reason for all this is the computer system this software runs on is for 
an aircraft system simulation in incorporates many concurrent applications 
with a common DLL link. Some of these applications can only communicate using 
simple DLL calls.

Bruce K.
"William DePalo [MVP VC++]" wrote:

> "Bruce K." <BruceK@discussions.microsoft.com> wrote in
message 
> news:A1B96507-3436-4598-945D-06C937D5D1D7@microsoft.com...
> > The first instance application to use the DLL works fine using the
SAPI, 
> > but
> > any additional applications get an access violation error implying the
COM
> > objects or their pointer are not in shared memory.
> 
> The COM objects that you are "sharing" encapsulate audio devices.
You can no 
> more expect to share the handle to an audio device that you open in one 
> application with another, any more than you can expect to share, say, a
file 
> handle between applications. That just doesn't work in 32 bit Windows.
> 
> Besides that, even if you could share the handles, it is not guaranteed (at

> least ion 2K/XP/2K+3/Vista that the shared memory resides at the same 
> location. The pointers might well be invalid regardless of the state of the

> handles.
> 
> You can of course use the "shared" recognizer in as many
applications as you 
> like so long as you create an instance an each application.
> 
> You may want to take a step back and explain what you need to do and not
how 
> you want to do it.
> 
> Regards,
> Will
> 
> 

"Bruce K." <BruceK@discussions.microsoft.com> wrote in message 
news:38DBB426-061D-45BA-8416-CE3D42729C68@microsoft.com...
> Thanks for input Will.

You are welcome.

> I wished I'd asked this question when I first posted the DLL question.  I
> had the same issue with a data acquisition resource I wanted to share with
> multiple applications. In this case, only one process can own the 
> connection
> to the device.  My way around this was to create a thread in the DLL that 
> was
> initiated by the first instance of the DLL. This thread would be the only
> connection to the device. All applications would then communicate with 
> this
> single thread using DLL functions that incorporated event pipes to
> communicate with the thread.
>
> I can either do the same as I did with the DAQ or simply make a small 
> window
> application to perform speech I/O and communicate with the DLL.
>
> The reason for all this is the computer system this software runs on is 
> for
> an aircraft system simulation in incorporates many concurrent applications
> with a common DLL link. Some of these applications can only communicate 
> using
> simple DLL calls.

I'm with you as to the data acquisition scenario - it's essentially a client 
/ server design no matter whether the thread fielding the requests is the 
"main" thread of a server application or one spun up by a function in
a DLL.

But what I'm less clear on is why you can not use the shared recognizer in 
the standard way. It exists so that all applications can share a microphone 
and so that the active one does the recognition. You could use the same 
functions in a DLL linked against each of your applications. Of course, each 
of them would allocate their own objects.

Regards,
Will