Thread in driver

Actually I would like to create a driver which I can pass a function
pointer in. And the driver is able to do the callback whenever there
is an interrupt. Here is my program...

File Driver_Main.c

void SomeISTThread()
{
while (TRUE)
{
/* Wait for the application event to be released */
WaitForSingleObject(Somevent, INFINITE);
Callback();
InterruptDone(SomeIntr);
}
}

BOOL WINAPI DllEntry(HANDLE hInstDll, DWORD dwReason, LPVOID
lpvReserved)
{
SomeThread = CreateThread(NULL, 0,
(LPTHREAD_START_ROUTINE)SomeISTThread,
NULL, 0, NULL);
return TRUE;
}

File Callback.c

PVOID callback_function = NULL;

void Callback()
{
if (callback_function != NULL)
callback_function();
}

void Add_Callback(PVOID callback)
{
callback_function = callback;
}

BOOL Is_CallbackExist()
{
return (callback_function != 0);
}

In debug mode I can see that my callback pointer is passed into the
driver. I can call the callback from the driver. However when an
interrupt is triggered. The function Callback reported that the
callback_function is NULL (which I saw the same result from debug
mode).

P.S. I already passed a function pointer in the variable
callback_function. And I am able to call the callback function from my
application program.

Thanks for the help

winstonhyypia
Fri Apr 11 00:12:06 PDT 2008

I found that there are 1 extra copy is built when the thread is
created. How can I do the data sharing between threads?

On Apr 11, 1:40=A0pm, winstonhyy...@gmail.com wrote:
> Actually I would like to create a driver which I can pass a function
> pointer in. And the driver is able to do the callback whenever there
> is an interrupt. Here is my program...
>
> File Driver_Main.c
>
> void SomeISTThread()
> {
> =A0 =A0 =A0 =A0 while (TRUE)
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Wait for the application event to be re=
leased */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 WaitForSingleObject(Somevent, INFINITE);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Callback();
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 InterruptDone(SomeIntr);
> =A0 =A0 =A0 =A0 }
>
> }
>
> BOOL WINAPI DllEntry(HANDLE hInstDll, DWORD dwReason, LPVOID
> lpvReserved)
> {
> =A0 =A0 =A0 =A0 SomeThread =3D CreateThread(NULL, 0,
> (LPTHREAD_START_ROUTINE)SomeISTThread,
> NULL, 0, NULL);
> =A0 =A0 =A0 =A0 return TRUE;
>
> }
>
> File Callback.c
>
> PVOID callback_function =3D NULL;
>
> void Callback()
> {
> =A0 =A0 =A0 =A0 if (callback_function !=3D NULL)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 callback_function();
>
> }
>
> void Add_Callback(PVOID callback)
> {
> =A0 =A0 =A0 =A0 callback_function =3D callback;
>
> }
>
> BOOL Is_CallbackExist()
> {
> =A0 =A0 =A0 =A0 return (callback_function !=3D 0);
>
> }
>
> In debug mode I can see that my callback pointer is passed into the
> driver. I can call the callback from the driver. However when an
> interrupt is triggered. The function Callback reported that the
> callback_function is NULL (which I saw the same result from debug
> mode).
>
> P.S. I already passed a function pointer in the variable
> callback_function. And I am able to call the callback function from my
> application program.
>
> Thanks for the help

Valter
Fri Apr 11 01:01:53 PDT 2008

winstonhyypia@gmail.com wrote in
news:12efb42e-b16b-4920-a82b-a87763e0298a@w1g2000prd.googlegroups.com
:

> Actually I would like to create a driver which I can pass a
> function pointer in. And the driver is able to do the callback
> whenever there is an interrupt. Here is my program...

This kind of solution will work only if your callback is inside
another driver (and in CE 6.0 both driver must be kernel mode drivers
or user mode driver of the same "group" and so running inside the same
process).
If you do that calling your driver from an application the callback
code will not be mapped inside the context of the caller (unless you
are in CE 5.0 and the code is inside a DLL that is shared by the
driver and the process) and, anyway, it will run in the context of the
caller process (device.exe in CE 5, the kernel or user-mode device
process in CE 6) and so it won't be able to access your process
memory.

If you need to implement such a mechanism, use a named event and set
it inside the IST. The app will spin a thread that will wait on the
same event and perform the operations that the callback was supposed
to perform when the event is set (you can call your current callback
inside the thread to reduce code changes).
If you need to way for the callback completition before you can accept
a new interrupt you can use another named event that the app will set
and the driver will wait on.
If you need to exchange data between the IST and your app you have a
wide choice of solutions: shared memory block, a IOCTL implemented by
the driver to return information stored inside the IST, a point-to-
point message queue (in this case you won't need the named event
because the queue can be use to synchronize the IST thread and the
application thread.



--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Winston
Sun Apr 13 20:11:25 PDT 2008

On Apr 11, 4:01=A0pm, Valter Minute
<v_a_l_t_e_r.m_i_n_u_t_e@g_m_a_i_l.com> wrote:
> winstonhyy...@gmail.com wrote innews:12efb42e-b16b-4920-a82b-a87763e0298a@=
w1g2000prd.googlegroups.com
> :
>
> > Actually I would like to create a driver which I can pass a
> > function pointer in. And the driver is able to do the callback
> > whenever there is an interrupt. Here is my program...
>
> This kind of solution will work only if your callback is inside
> another driver (and in CE 6.0 both driver must be kernel mode drivers
> or user mode driver of the same "group" and so running inside the same
> process).
> If you do that calling your driver from an application the callback
> code will not be mapped inside the context of the caller (unless you
> are in CE 5.0 and the code is inside a DLL that is shared by the
> driver and the process) and, anyway, it will run in the context of the
> caller process (device.exe in CE 5, the kernel or user-mode device
> process in CE 6) and so it won't be able to access your process
> memory.
>
> If you need to implement such a mechanism, use a named event and set
> it inside the IST. The app will spin a thread that will wait on the
> same event and perform the operations that the callback was supposed
> to perform when the event is set (you can call your current callback
> inside the thread to reduce code changes).
> If you need to way for the callback completition before you can accept
> a new interrupt you can use another named event that the app will set
> and the driver will wait on.
> If you need to exchange data between the IST and your app you have a
> wide choice of solutions: shared memory block, a IOCTL implemented by
> the driver to return information stored inside the IST, a point-to-
> point message queue (in this case you won't need the named event
> because the queue can be use to synchronize the IST thread and the
> application thread.
>
> --
> Valter Minutewww.fortechembeddedlabs.it
> Training, support and development for Windows CE
> (the reply address of this message is invalid)

Let me show you a different version

File Driver_Main.c

void SomeISTThread()
{
while (TRUE)
{
/* Wait for the IST event to be triggered */
WaitForSingleObject(Somevent, INFINITE);
Callback();
InterruptDone(SomeIntr);
}
}

BOOL WINAPI DllEntry(HANDLE hInstDll, DWORD dwReason, LPVOID
lpvReserved)
{
SomeThread =3D CreateThread(NULL, 0,
(LPTHREAD_START_ROUTINE)SomeISTThread, NULL, 0, NULL);
return TRUE;
}

File Callback.c

UInt callback_number =3D 1;

void Callback()
{
DEBUGMSG (TRUE,(_T("Callback callback_number 0x%X.\r\n"),
callback_number));
}

void Set_Callback(UInt input_number)
{
callback_number =3D input_number;
DEBUGMSG (TRUE,(_T("Set_Callback callback_number 0x%X.\r\n"),
callback_number));
}

I export the function Set_Callback to the external program. What I
observed is I got a break from Set_Callback which the number equals to
the input_number. When I trigger the interrupt I got a break from
Callback as well. However the callback_number shown in debugger is the
initialized number (1 in this case), no matter how I set the number on
the application.

Valter
Mon Apr 14 01:16:11 PDT 2008

Winston <winstonhyypia@gmail.com> wrote in
news:c43de1cf-d928-4376-bf54-1cd628d1b4f6@w5g2000prd.googlegroups.com
:

[...]
> I export the function Set_Callback to the external program. What I
> observed is I got a break from Set_Callback which the number
> equals to the input_number. When I trigger the interrupt I got a
> break from Callback as well. However the callback_number shown in
> debugger is the initialized number (1 in this case), no matter how
> I set the number on the application.

The callback is inside the driver DLL or a DLL loaded by the driver?
The driver and the application run in different processes and so each
instance has it's own global variables.
You can't use that callback mechanism unless you pass the callback
from another driver and even in this case you may have some
problematic cases (ex: when the drivers are loaded as user mode
drivers in different instances of udevice.exe).


--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Winston
Mon Apr 14 08:40:54 PDT 2008

On Apr 14, 4:16=A0pm, Valter Minute
<v_a_l_t_e_r.m_i_n_u_t_e@g_m_a_i_l.com> wrote:
> Winston <winstonhyy...@gmail.com> wrote innews:c43de1cf-d928-4376-bf54-1cd=
628d1b4f6@w5g2000prd.googlegroups.com
> :
>
> [...]
>
> > I export the function Set_Callback to the external program. What I
> > observed is I got a break from Set_Callback which the number
> > equals to the input_number. When I trigger the interrupt I got a
> > break from Callback as well. However the callback_number shown in
> > debugger is the initialized number (1 in this case), no matter how
> > I set the number on the application.
>
> The callback is inside the driver DLL or a DLL loaded by the driver?
> The driver and the application run in different processes and so each
> instance has it's own global variables.
> You can't use that callback mechanism unless you pass the callback
> from another driver and even in this case you may have some
> problematic cases (ex: when the drivers are loaded as user mode
> drivers in different instances of udevice.exe).
>
> --
> Valter Minutewww.fortechembeddedlabs.it
> Training, support and development for Windows CE
> (the reply address of this message is invalid)

Callback is inside the driver DLL.

Chris
Mon Apr 14 11:13:04 PDT 2008

I don't think you understand what's going on. Your driver DLL is running in
the context of device.exe, *not* your application where the void Callback()
definition and implementation resides. This means that the data segment
that contains the callback_number variable is *not* the same between driver
and the application and tehre's no way for you to make them the same. This
is a classic IPC issue and could be replicated without a driver. If you
need the two processes to share data, you need to use some form of IPC.
Maybe a memory mapped file, maybe a point to point queue, maybe SetVentData
or, just maybe, using IOCTLs - after all that's the whole point of having
DeviceIoControl.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com


"Winston" <winstonhyypia@gmail.com> wrote in message
news:2d013120-2e56-428b-9db1-87be10631c24@n14g2000pri.googlegroups.com...
On Apr 14, 4:16 pm, Valter Minute
<v_a_l_t_e_r.m_i_n_u_t_e@g_m_a_i_l.com> wrote:
> Winston <winstonhyy...@gmail.com> wrote
> innews:c43de1cf-d928-4376-bf54-1cd628d1b4f6@w5g2000prd.googlegroups.com
> :
>
> [...]
>
> > I export the function Set_Callback to the external program. What I
> > observed is I got a break from Set_Callback which the number
> > equals to the input_number. When I trigger the interrupt I got a
> > break from Callback as well. However the callback_number shown in
> > debugger is the initialized number (1 in this case), no matter how
> > I set the number on the application.
>
> The callback is inside the driver DLL or a DLL loaded by the driver?
> The driver and the application run in different processes and so each
> instance has it's own global variables.
> You can't use that callback mechanism unless you pass the callback
> from another driver and even in this case you may have some
> problematic cases (ex: when the drivers are loaded as user mode
> drivers in different instances of udevice.exe).
>
> --
> Valter Minutewww.fortechembeddedlabs.it
> Training, support and development for Windows CE
> (the reply address of this message is invalid)

Callback is inside the driver DLL.

Winston
Mon Apr 14 23:37:22 PDT 2008

On Apr 15, 2:13=A0am, "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com>
wrote:
> I don't think you understand what's going on. =A0Your driver DLL is runnin=
g in
> the context of device.exe, *not* your application where the void Callback(=
)
> definition and implementation resides. =A0This means that the data segment=

> that contains the callback_number variable is *not* the same between drive=
r
> and the application and tehre's no way for you to make them the same. =A0T=
his
> is a classic IPC issue and could be replicated without a driver. =A0If you=

> need the two processes to share data, you need to use some form of IPC.
> Maybe a memory mapped file, maybe a point to point queue, maybe SetVentDat=
a
> or, =A0just maybe, using IOCTLs - after all that's the whole point of havi=
ng
> DeviceIoControl.
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded communityhttp://community.OpenNETCF.com
>
> "Winston" <winstonhyy...@gmail.com> wrote in message
>
> news:2d013120-2e56-428b-9db1-87be10631c24@n14g2000pri.googlegroups.com...
> On Apr 14, 4:16 pm, Valter Minute
>
>
>
> <v_a_l_t_e_r.m_i_n_u_t_e@g_m_a_i_l.com> wrote:
> > Winston <winstonhyy...@gmail.com> wrote
> > innews:c43de1cf-d928-4376-bf54-1cd628d1b4f6@w5g2000prd.googlegroups.com
> > :
>
> > [...]
>
> > > I export the function Set_Callback to the external program. What I
> > > observed is I got a break from Set_Callback which the number
> > > equals to the input_number. When I trigger the interrupt I got a
> > > break from Callback as well. However the callback_number shown in
> > > debugger is the initialized number (1 in this case), no matter how
> > > I set the number on the application.
>
> > The callback is inside the driver DLL or a DLL loaded by the driver?
> > The driver and the application run in different processes and so each
> > instance has it's own global variables.
> > You can't use that callback mechanism unless you pass the callback
> > from another driver and even in this case you may have some
> > problematic cases (ex: when the drivers are loaded as user mode
> > drivers in different instances of udevice.exe).
>
> > --
> > Valter Minutewww.fortechembeddedlabs.it
> > Training, support and development for Windows CE
> > (the reply address of this message is invalid)
>
> Callback is inside the driver DLL.

Actually I want to send some data to the driver through a function
call (Set_Callback to set the number). And then the IST can pick up
the number once they got an interrupt. I saw the variable changed
during the Set_Callback function. However when my IST comes in and
calls the function Callback(). It shows that the number
callback_number is not the number I set before the IST comes in.
Thanks a lot

Valter
Tue Apr 15 01:49:53 PDT 2008

Winston <winstonhyypia@gmail.com> wrote in
news:344e4426-b7cd-404c-a267-e5dd370683d0@q1g2000prf.googlegroups.com
:

[...]
> Actually I want to send some data to the driver through a function
> call (Set_Callback to set the number). And then the IST can pick
> up the number once they got an interrupt. I saw the variable
> changed during the Set_Callback function. However when my IST
> comes in and calls the function Callback(). It shows that the
> number callback_number is not the number I set before the IST
> comes in. Thanks a lot

You linked the same DLL to your driver and to your application, I
suppose. Or you compiled the DLL as a driver and then linked it to
your app, this doesnt' change the picture.
You load the DLL inside _TWO_ different processes:
- You own application (let's call it APP.EXE)
- The driver manager (DEVICE.EXE in CE 5.0, NK.EXE in CE 6.0)

The code of the DLL will be loaded in memory once and shared between
the two processes (that's the main advantage of DLLs) but the DLL
private data (global variables) will be allocated twice. One instance
in each process.
So your variable (let's call it "MyVar") will be allocated at two
different memory addresses (let's call them 0x123 and 0x456) and so
when you change MyVar inside APP.EXE you will change memory at 0x123,
if you change it inside the driver you will change memory at 0x456 and
so you can't see the changes. To add some complication, you may see
both variables at 0x999 in both processesbecause they are mapped to
the same virtual address but point to different physical memory
locations!
If you need to share some data or do some cross-process operations you
should use one of the mechanisms that the OS provides to do that
(point-to-point message queues, memory mapped files, device io
controls etc.).



--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Winston
Tue Apr 15 02:33:58 PDT 2008

On Apr 15, 4:49=A0pm, Valter Minute
<v_a_l_t_e_r.m_i_n_u_t_e@g_m_a_i_l.com> wrote:
> Winston <winstonhyy...@gmail.com> wrote innews:344e4426-b7cd-404c-a267-e5d=
d370683d0@q1g2000prf.googlegroups.com
> :
>
> [...]
>
> > Actually I want to send some data to the driver through a function
> > call (Set_Callback to set the number). And then the IST can pick
> > up the number once they got an interrupt. I saw the variable
> > changed during the Set_Callback function. However when my IST
> > comes in and calls the function Callback(). It shows that the
> > number callback_number is not the number I set before the IST
> > comes in. Thanks a lot
>
> You linked the same DLL to your driver and to your application, I
> suppose. Or you compiled the DLL as a driver and then linked it to
> your app, this doesnt' change the picture.
> You load the DLL inside _TWO_ different processes:
> - You own application (let's call it APP.EXE)
> - The driver manager (DEVICE.EXE in CE 5.0, NK.EXE in CE 6.0)
>
> The code of the DLL will be loaded in memory once and shared between
> the two processes (that's the main advantage of DLLs) but the DLL
> private data (global variables) will be allocated twice. One instance
> in each process.
> So your variable (let's call it "MyVar") will be allocated at two
> different memory addresses (let's call them 0x123 and 0x456) and so
> when you change MyVar inside APP.EXE you will change memory at 0x123,
> if you change it inside the driver you will change memory at 0x456 and
> so you can't see the changes. To add some complication, you may see
> both variables at 0x999 in both processesbecause they are mapped to
> the same virtual address but point to different physical memory
> locations!
> If you need to share some data or do some cross-process operations you
> should use one of the mechanisms that the OS provides to do that
> (point-to-point message queues, memory mapped files, device io
> controls etc.).
>
> --
> Valter Minutewww.fortechembeddedlabs.it
> Training, support and development for Windows CE
> (the reply address of this message is invalid)

Yes I saw the same virtual memory address which I got confused. hmm...
where can I find the resource for cross-process operations?

Valter
Tue Apr 15 02:48:23 PDT 2008

Winston <winstonhyypia@gmail.com> wrote in
news:b3d737b7-f1b0-455c-ae53-bfe680e1f8c8@w1g2000prd.googlegroups.com
:

[...]
> Yes I saw the same virtual memory address which I got confused.
> hmm... where can I find the resource for cross-process operations?

I don't recall any resource (doc, article, blog entry) that compares
the different methods, but you can search on your favorite search
engine:
"point to point message queues Windows CE"
"memory mapped files Windows CE"
"DeviceIoControl Windows CE"

to get an overview of the three method that are commonly used to share
data between drivers and applications outside of the standard
streaming I/O interface.

If you open a new thread describing your problem in a more detailed
way (I mean: I need to do that, that and that) someone may suggest a
good architectural solution.

--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Winston
Tue Apr 15 03:01:55 PDT 2008

On Apr 15, 5:48=A0pm, Valter Minute
<v_a_l_t_e_r.m_i_n_u_t_e@g_m_a_i_l.com> wrote:
> Winston <winstonhyy...@gmail.com> wrote innews:b3d737b7-f1b0-455c-ae53-bfe=
680e1f8c8@w1g2000prd.googlegroups.com
> :
>
> [...]
>
> > Yes I saw the same virtual memory address which I got confused.
> > hmm... where can I find the resource for cross-process operations?
>
> I don't recall any resource (doc, article, blog entry) that compares
> the different methods, but you can search on your favorite search
> engine:
> "point to point message queues Windows CE"
> "memory mapped files Windows CE"
> "DeviceIoControl Windows CE"
>
> to get an overview of the three method that are commonly used to share
> data between drivers and applications outside of the standard
> streaming I/O interface.
>
> If you open a new thread describing your problem in a more detailed
> way (I mean: I need to do that, that and that) someone may suggest a
> good architectural solution.
>
> --
> Valter Minutewww.fortechembeddedlabs.it
> Training, support and development for Windows CE
> (the reply address of this message is invalid)

Hold on... I exported the Set_Callback function to the application
level. That would be the same way as the DeviceIOControl... right?

Valter
Tue Apr 15 03:57:59 PDT 2008

Winston <winstonhyypia@gmail.com> wrote in
news:5a3ba0d2-99c6-439f-95e7-649f42fedf6c@q10g2000prf.googlegroups.co
m:

[...]
> Hold on... I exported the Set_Callback function to the application
> level. That would be the same way as the DeviceIOControl... right?
>

Not at all.


--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Chris
Tue Apr 15 05:55:43 PDT 2008

No, no, no, no, no and NO. I think you need to do some reasearch on how
processes work. A callback runs in the context of the caller. Calling a
function does not. Totally different beasts with totally different results.
If you simply need to change a value for the IST from an application, call
DeviceIoControl. Quit trying to make it difficult and make yourself seem
clever by using a callback. It will not work.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com


"Winston" <winstonhyypia@gmail.com> wrote in message
news:5a3ba0d2-99c6-439f-95e7-649f42fedf6c@q10g2000prf.googlegroups.com...
On Apr 15, 5:48 pm, Valter Minute
<v_a_l_t_e_r.m_i_n_u_t_e@g_m_a_i_l.com> wrote:
> Winston <winstonhyy...@gmail.com> wrote
> innews:b3d737b7-f1b0-455c-ae53-bfe680e1f8c8@w1g2000prd.googlegroups.com
> :
>
> [...]
>
> > Yes I saw the same virtual memory address which I got confused.
> > hmm... where can I find the resource for cross-process operations?
>
> I don't recall any resource (doc, article, blog entry) that compares
> the different methods, but you can search on your favorite search
> engine:
> "point to point message queues Windows CE"
> "memory mapped files Windows CE"
> "DeviceIoControl Windows CE"
>
> to get an overview of the three method that are commonly used to share
> data between drivers and applications outside of the standard
> streaming I/O interface.
>
> If you open a new thread describing your problem in a more detailed
> way (I mean: I need to do that, that and that) someone may suggest a
> good architectural solution.
>
> --
> Valter Minutewww.fortechembeddedlabs.it
> Training, support and development for Windows CE
> (the reply address of this message is invalid)

Hold on... I exported the Set_Callback function to the application
level. That would be the same way as the DeviceIOControl... right?

Winston
Wed Apr 16 21:16:15 PDT 2008

On Apr 15, 8:55=A0pm, "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com>
wrote:
> No, no, no, no, no and NO. =A0I think you need to do some reasearch on how=

> processes work. =A0A callback runs in the context of the caller. =A0Callin=
g a
> function does not. =A0Totally different beasts with totally different resu=
lts.
> If you simply need to change a value for the IST from an application, call=

> DeviceIoControl. =A0Quit trying to make it difficult and make yourself see=
m
> clever by using a callback. =A0It will not work.
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded communityhttp://community.OpenNETCF.com
>
> "Winston" <winstonhyy...@gmail.com> wrote in message
>
> news:5a3ba0d2-99c6-439f-95e7-649f42fedf6c@q10g2000prf.googlegroups.com...
> On Apr 15, 5:48 pm, Valter Minute
>
>
>
> <v_a_l_t_e_r.m_i_n_u_t_e@g_m_a_i_l.com> wrote:
> >Winston<winstonhyy...@gmail.com> wrote
> > innews:b3d737b7-f1b0-455c-ae53-bfe680e1f8c8@w1g2000prd.googlegroups.com
> > :
>
> > [...]
>
> > > Yes I saw the same virtual memory address which I got confused.
> > > hmm... where can I find the resource for cross-process operations?
>
> > I don't recall any resource (doc, article, blog entry) that compares
> > the different methods, but you can search on your favorite search
> > engine:
> > "point to point message queues Windows CE"
> > "memory mapped files Windows CE"
> > "DeviceIoControl Windows CE"
>
> > to get an overview of the three method that are commonly used to share
> > data between drivers and applications outside of the standard
> > streaming I/O interface.
>
> > If you open a new thread describing your problem in a more detailed
> > way (I mean: I need to do that, that and that) someone may suggest a
> > good architectural solution.
>
> > --
> > Valter Minutewww.fortechembeddedlabs.it
> > Training, support and development for Windows CE
> > (the reply address of this message is invalid)
>
> Hold on... I exported the Set_Callback function to the application
> level. That would be the same way as the DeviceIOControl... right?

But I don't understand why DeviceIoControl but not the other function
I exported. Would you mind explaining? Since to me in both cases they
are different process as well. So why DeviceIoControl can send the my
data to the IST? Thanks a lot

Valter
Thu Apr 17 01:00:26 PDT 2008

Winston <winstonhyypia@gmail.com> wrote in
news:d993b6f0-bcea-49e5-b969-ea885bca9f4f@a1g2000hsb.googlegroups.com
:

[...]
> But I don't understand why DeviceIoControl but not the other
> function I exported. Would you mind explaining? Since to me in
> both cases they are different process as well. So why
> DeviceIoControl can send the my data to the IST? Thanks a lot
>

You don't export "DeviceIoControl", your driver export XXX_IoControl.
When an application calls DeviceIoControl (mind that I wrote an
application, not a driver) the OS "migrates" the calling thread into
the process context where the driver runs (kernel in 6.0, device.exe
in 5.0).
The code inside the driver can access its own process space (its
global variables). The kernel marshals the buffer passed by the
application (and so located inside its own process space) and allow
the driver to access them as long as it's running in the context of
the caller. The driver _may_ access other memory areas inside the
application address space (usually embedded pointers) but it will have
to marshal them on its own (and the operations required changed from
5.x to 6.0 and some kind of drivers, running in user mode, can't do
that operation).
You _may_ be able to call back a function inside the calling process
but this is _not_ granted at all and if it will work it will work only
during the tread migration time (XXX_* function call) and won't work
after that. The called function won't be able to access global
variables etc. so there's no point in implementing such an unreliable
and limited mechanism.
A side effect will be that the "callback" is allowed to access
device.exe or kernel memory space and this will be a huge security
issue too
If you need to share data use a memory mapped file. If you need to
pass some parameters to the driver or retrieve some information use
DeviceIoControl. If you need to asyncronously process data, use a
point-to-point message queue. In any case you may use named events to
synchronize your tasks.

--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)