13 new messages in 7 topics - digest

microsoft.public.development.device.drivers
http://groups.google.com/group/microsoft.public.development.device.drivers?hl=en

microsoft.public.development.device.drivers@googlegroups.com

Today's topics:

* NDISUIO - some basic questions - 1 messages, 1 author
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/8b1f429004ff8750?hl=en
* xenical canada par email xenical suisse sans ordonnance Achetez Le xenical
xenical suisse xenical bon marche - 1 messages, 1 author
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/71bf9b55852bc0c1?hl=en
* Windows PS printer driver - 1 messages, 1 author
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/7d5f6e0e1d16405c?hl=en
* Requirements or Restrictions using "Imaging Device" in Windows Driver
Manager - 2 messages, 1 author
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/4c0a784155b7d547?hl=en
* NDIS_PACKET_8021Q_INFO - 2 messages, 2 authors
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/267703a2be1df56e?hl=en
* NDIS marshalling pointers - 5 messages, 2 authors
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/c6853918b66d8360?hl=en
* Unknown Device,... - 1 messages, 1 author
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/c9be0a0124661aad?hl=en

==============================================================================
TOPIC: NDISUIO - some basic questions
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/8b1f429004ff8750?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Aug 8 2008 11:15 pm
From: Gammaraman

Hi,

I have some basic questions regarding NDISUIO and I am hoping someone here
can help me out. My platforms of interest are WM 6.1 and WM 7.0.

Basically I want to use NDISUIO to call some custom OIDs my WLAN miniport
driver provides from a user application. So all I want is the
IOCTL_NDISUIO_SET_OID_VALUE and IOCTL_NDISUIO_QUERY_OID_VALUE. I believe on
WM there is no issue with an application calling these IOCTLs even if WZC or
some other service has done a IOCTL_NDISUIO_OPEN_DEVICE since the
ptcDeviceName can be passed with the set/query IOCTLs.

Is there anything special that needs to be done from an application
perspective to use NDISUIO other than CreateFile and DeviceIoControl with
IOCTL_NDISUIO_SET_OID_VALUE/IOCTL_NDISUIO_QUERY_OID_VALUE with the
ptcDeviceName?

Does the application have to load the NDISUIO driver or is this loaded at
system start?

What happens if the NDISUIO driver is not loaded when application calls the
DeviceIoControl? What happens if there is no binding between the NDISUIO and
ptcDeviceName?

How can the application find out whether a given OID is supported by the
device? Is it application expected to query OID_GEN_SUPPORTED_LIST? Can NDIS
be relied upon to pass the custom OID supported information upto application?

Is there anything special that needs to be done from a WLAN miniport driver
perspective to work with NDISUIO? Is the miniport driver even aware of
NDISUIO? Does it even care?

How does the NDISUIO driver bind to the WLAN miniport driver? Is it the case
that when the WLAN miniport driver registers with NDIS by calling
NdisRegisterAdapter, NDIS will tell NDISUIO to create a binding to the
miniport? If not, how can I setup a binding between NDISUIO and my miniport
driver?

When the miniport driver gets a packet and it indicates it to NDIS, who will
NDIS send the packet to if multiple protocol drivers (say a IP protocol
driver and the NDISUIO driver) are bound to the same miniport? Is there a
chance that presence of the NDISUIO will impact the other protocol drivers
who care about the 802.3/802.11 frames?

Lastly, is marshalling handled by NDIS? So if an application passes a
pointer to a buffer in its address space with a query_oid, does the miniport
not have to worry about marshalling and it can just write to that pointer? Is
the differences in the memory architecture between WinCE 5.0 and WinCE6.0
handled by NDIS itself?

Thanks.

==============================================================================
TOPIC: xenical canada par email xenical suisse sans ordonnance Achetez Le
xenical xenical suisse xenical bon marche
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/71bf9b55852bc0c1?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 9 2008 6:02 am
From: sdgvfwe@yahoo.is.com

xenical canada par email xenical suisse sans ordonnance Achetez Le xenical xenical suisse xenical bon marche

+++ PERTE DE POIDS +++ PERTE DE POIDS +++ PERTE DE POIDS +++
+
ACHETER XENICAL BON MARCHE (ALL CARD ACCEPTED)
http://jhku.net/ACHETER-XENICAL-BON-MARCHE/
+
+
+
ACHETER ACOMPLIA BON MARCHE (ALL CARD ACCEPTED)
http://jhku.net/ACHETER-ACOMPLIA-BON-MARCHE/
+
+
+
ACHETER MERIDIA BON MARCHE (ALL CARD ACCEPTED)
http://jhku.net/ACHETER-MERIDIA-BON-MARCHE/
+
+
+
ACHETER PHENTERMINE BON MARCHE (Western Union, Diners, AMEX, VISA)
http://jhku.net/ACHETER-PHENTERMINEA-BON-MARCHE/

http://ibm-news.for-um.de/showthread.php?t=14927
http://ibm-news.for-um.de/showthread.php?t=14938
http://ibm-news.for-um.de/showthread.php?t=14924

xenical suisse sans ordonnance
generique pharmacie canada
un Achat de xenical avec livraison
xenical le plus bon marche
xenical canada Generique Inde
xenical belgique soft sans prescription
comprimes de xenical canada
acquerir xenical en France soft
xenical us usa a vendre
xenical canada commande en ligne
comprimes de xenical bon marche
commander xenical en France par mail
eurodrugs.org
xenical belgique en ligne
citrate de Orlistat canada
acheter xenical
xenical commande en ligne
eurodrugs.org
commander comprime de xenical us usa
Achat xenical france
commander xenical en France en ligne aucune prescription
xenical suisse Generique Inde
un Achat de xenical en France avec livraison
xenical par email
acheter xenical en ligne
acheter xenical concernées par cette
xenical belgique soft sans prescription
commander xenical en France en ligne aucune prescription
xenical canada par email
acheter xenical
xenical suisse le plus bon marche
xenical suisse soft generique
xenical suisse sans ordonnance
xenical canada le plus bon marche
xenical suisse
Achat xenical france

==============================================================================
TOPIC: Windows PS printer driver
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/7d5f6e0e1d16405c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 9 2008 7:16 am
From: CJacobs

This should be easy, but documentation on Windows printer driver functions is
hard to find. In the printer properties, General Tab, there is a group box
labeled "Paper available". I'm guessing this is to support Bi-directional
communication with the printer and is intended to show all paper currently
loaded in the printer trays. It always seems to have only one entry,
"Letter", which I'm also assuming is just the default value when the printer
/driver does not support Bi-di comm. Are my assumptions correct? Is there
a way to statically expand that list to include all the sizes a printer
supports even if the driver is not bi-directional?
Does anyone know of documentation which describes, completely, Windows
printer drivers?

==============================================================================
TOPIC: Requirements or Restrictions using "Imaging Device" in Windows Driver
Manager
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/4c0a784155b7d547?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Aug 9 2008 10:36 am
From: David.C.Reaves@fcimg.com

On Aug 8, 8:56 pm, Tim Roberts <t...@probo.com> wrote:
> David.C.Rea...@fcimg.com wrote:
>
> >We have created a digital camera for a specific customer who requires
> >that the camera display an icon in Windows Device Manager under
> >"Imaging Devices". We can accomplish this using the "Imaging Device"
> >GUID in the INF file ( GUID = {6bdd1fc6-810f-11d0-
> >bec7-08002be2092f} ).
>
> That's what I tend to use for web cameras, because you do inherit automatic
> WIA support.
>
> >However, the camera does not support WIA and is
> >not intended to be a "Still Image" camera.
>
> Doesn't matter; Windows will provide automatic WIA and TWAIN support, and
> will actually allow applications to grab snapshots from the stream.
>
> If you really don't want it to be exposed in Scanners and Cameras, you can
> choose to put it in Media class instead of Image class:
>   Class=Media
>   ClassGUID={4d36e96c-e325-11ce-bfc1-08002be10318}
>
> >If we submit the device to
> >USB-IF for compliance testing, will this cause a problem?
>
> USB-IF doesn't test the functionality of your device.  They won't use the
> driver at all.  They're going to test your electrical compliance, your
> descriptors, your response to power states and resets, etc.
>
> Did you really mean WHQL testing?
>
> >Are there any other restrictions/requirements for devices that use
> >this location in Driver Manager?
>
> Not really, no.
> --
> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.

Hi and thanks for the reply,

> If you really don't want it to be exposed in Scanners and Cameras, you can

choose to put it in Media class instead of Image class:...

Our customer specifically requires us to use the Image class.

> Doesn't matter; Windows will provide automatic WIA and TWAIN support, and
> will actually allow applications to grab snapshots from the stream.

Our driver package (a user mode DLL plus the Cypress kernel mode
driver) has a
proprietary API used only by the customer. There are is no TWAIN
support (nor
streams available to other applications).

Dave

== 2 of 2 ==
Date: Sat, Aug 9 2008 10:49 am
From: David.C.Reaves@fcimg.com

On Aug 8, 8:56 pm, Tim Roberts <t...@probo.com> wrote:
> David.C.Rea...@fcimg.com wrote:
>
> >We have created a digital camera for a specific customer who requires
> >that the camera display an icon in Windows Device Manager under
> >"Imaging Devices". We can accomplish this using the "Imaging Device"
> >GUID in the INF file ( GUID = {6bdd1fc6-810f-11d0-
> >bec7-08002be2092f} ).
>
> That's what I tend to use for web cameras, because you do inherit automatic
> WIA support.
>
> >However, the camera does not support WIA and is
> >not intended to be a "Still Image" camera.
>
> Doesn't matter; Windows will provide automatic WIA and TWAIN support, and
> will actually allow applications to grab snapshots from the stream.
>
> If you really don't want it to be exposed in Scanners and Cameras, you can
> choose to put it in Media class instead of Image class:
>   Class=Media
>   ClassGUID={4d36e96c-e325-11ce-bfc1-08002be10318}
>
> >If we submit the device to
> >USB-IF for compliance testing, will this cause a problem?
>
> USB-IF doesn't test the functionality of your device.  They won't use the
> driver at all.  They're going to test your electrical compliance, your
> descriptors, your response to power states and resets, etc.
>
> Did you really mean WHQL testing?
>
> >Are there any other restrictions/requirements for devices that use
> >this location in Driver Manager?
>
> Not really, no.
> --
> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.

Hi and thanks for the reply,

> If you really don't want it to be exposed in Scanners and Cameras, you can
> choose to put it in Media class instead of Image class:...

Our customer specifically requires us to use the Image class.

> Doesn't matter; Windows will provide automatic WIA and TWAIN support, and
> will actually allow applications to grab snapshots from the stream.

Our driver package (a user mode DLL and the generic Cypress kernel
mode driver CyUsb.sys) has a
proprietary API used only by the customer. There are is no TWAIN
support (nor streams available
to other applications).

> Did you really mean WHQL testing?

Well, our main goals are to be USB-IF certified and to get the driver
package signed so that we
can perform a "silent" installation without the annoying "not signed"
or "not Windows Logo..." dialog
boxes appearing. We DO NOT need to be Windows Logo compliant.

However, it seems that to get the packaged signed we need WHQL
certification as well as a certificate from
an entity like Verisign (which we have). Correct me if I am wrong,
but this may not be as onerous as it once was:
1. We can perform the WHQL testing in-house using the Driver Test
Manager (DTM).
2. We then email the results to Microsoft (for ~$250.00 !!!!).
3. If the tests pass, we will be emailed the proper certificates to
allow our package to be signed.

If this is incorrect, please let me know!

In addition, there is something called an "unclassified signature".
Will this allow us to use the Image class without
needing to support WIA/STI?

Thanks,

DCR

Dave

==============================================================================
TOPIC: NDIS_PACKET_8021Q_INFO
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/267703a2be1df56e?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Aug 9 2008 10:40 am
From: "Peter"

AFAIK, there is nothing in the OOB data to indicate whether the 0-value of
the Ieee8021QInfo data was or was not set by an application. I believe that
most WLAN miniports (at least the ones that I have worked on) rely on
DSCP-WMM mapping.

"Gammaraman" <Gammaraman@discussions.microsoft.com> wrote in message
news:6802E59F-A184-47D3-AD63-D50AF1C04172@microsoft.com...
> Thanks, Peter. As always, I appreciate your help.
>
> Sorry for not being more specific. Yes, this is on the send side.
>
> To provide some more context, I am trying to perform WMM classification in
> my WLAN miniport and I only need to take care of the classification on the
> uplink.
>
> I think for my specific case inspecting the UserPriority from the OOB is
> more efficient as I wouldn't need to exercise the logic to find the IP
> header
> (which could be at different offsets based on Ethernet-II framing/802.3
> framing with LLC+SNAP/802.3 framing with LLC+SNAP+802.1Q (when in-band),
> etc.)
>
> My doubt is how can miniport driver tell the difference between when an
> application specified UP=0 and when it did not specify any UP (but
> specified
> a DSCP)? If we could tell the difference, then in the first case we don't
> need to look at DSCP whereas in second case we would.
>
> If there is no way to tell the difference, then we could (as you mention)
> first check for UP from OOB always. If 0, then check the DSCP to decide
> what
> to do. If UP!=0, the just use the UP itself.
>
>
> "Peter" wrote:
>
>> It sounds like this is a question regarding the send path, but I'm a bit
>> confused by the question. In the snippet below, if UserPrority == 0, then
>> there is no OOB 802.1p setting and you can check the IP TOS field for the
>> DSCP value. If UserPriority == 0, then neither NDIS nor any IM driver
>> populated the OOB data.
>>
>> However, are you asking about precedence (i.e., if UserPriority != 0,
>> then
>> use that and don't use DSCP)? That's a tough one and I'm not sure there
>> is a
>> clear answer. IMHO, I would inspect DSCP first and use that if it is
>> non-zero before checking 802.1p, since DSCP is not limited to the local
>> LAN/subnet and should be carried across hops (as opposed to 802.1p tags).
>>
>> "Gammaraman" <Gammaraman@discussions.microsoft.com> wrote in message
>> news:341FB44D-4F86-4833-AA52-0F33A4441658@microsoft.com...
>> > Hi,
>> >
>> > Here is a snippet I found on MSDN on how to get the UserPriority and
>> > VlanID
>> > fields from the OOB of a NDIS packet.
>> >
>> > NDIS_PACKET_8021Q_INFO VlanPriInfo;
>> > UINT32 UserPriority;
>> > UINT32 VlanID;
>> > VlanPriInfo.Value =
>> > NDIS_PER_PACKET_INFO_FROM_PACKET(pPacketDesc, Ieee8021QInfo);
>> > UserPriority = VlanPriInfo.TagHeader.UserPriority;
>> > VlanID = VlanPriInfo.TagHeader.VlanId;
>> >
>> > My question is what is the behavior of this snippet if NDIS did not
>> > populate
>> > the Ieee8021Qinfo part of the OOB? Is there someway the miniport driver
>> > can
>> > check/know whether NDIS populated this part of the OOB so that if it is
>> > not
>> > populated, it can inspect the TOS field of the IPv4 header for packet
>> > classification instead?
>> >
>> > Thanks.
>>
>>
>>

== 2 of 2 ==
Date: Sat, Aug 9 2008 1:41 pm
From: Gammaraman

Thanks, Peter.

"Peter" wrote:

> AFAIK, there is nothing in the OOB data to indicate whether the 0-value of
> the Ieee8021QInfo data was or was not set by an application. I believe that
> most WLAN miniports (at least the ones that I have worked on) rely on
> DSCP-WMM mapping.
>
> "Gammaraman" <Gammaraman@discussions.microsoft.com> wrote in message
> news:6802E59F-A184-47D3-AD63-D50AF1C04172@microsoft.com...
> > Thanks, Peter. As always, I appreciate your help.
> >
> > Sorry for not being more specific. Yes, this is on the send side.
> >
> > To provide some more context, I am trying to perform WMM classification in
> > my WLAN miniport and I only need to take care of the classification on the
> > uplink.
> >
> > I think for my specific case inspecting the UserPriority from the OOB is
> > more efficient as I wouldn't need to exercise the logic to find the IP
> > header
> > (which could be at different offsets based on Ethernet-II framing/802.3
> > framing with LLC+SNAP/802.3 framing with LLC+SNAP+802.1Q (when in-band),
> > etc.)
> >
> > My doubt is how can miniport driver tell the difference between when an
> > application specified UP=0 and when it did not specify any UP (but
> > specified
> > a DSCP)? If we could tell the difference, then in the first case we don't
> > need to look at DSCP whereas in second case we would.
> >
> > If there is no way to tell the difference, then we could (as you mention)
> > first check for UP from OOB always. If 0, then check the DSCP to decide
> > what
> > to do. If UP!=0, the just use the UP itself.
> >
> >
> > "Peter" wrote:
> >
> >> It sounds like this is a question regarding the send path, but I'm a bit
> >> confused by the question. In the snippet below, if UserPrority == 0, then
> >> there is no OOB 802.1p setting and you can check the IP TOS field for the
> >> DSCP value. If UserPriority == 0, then neither NDIS nor any IM driver
> >> populated the OOB data.
> >>
> >> However, are you asking about precedence (i.e., if UserPriority != 0,
> >> then
> >> use that and don't use DSCP)? That's a tough one and I'm not sure there
> >> is a
> >> clear answer. IMHO, I would inspect DSCP first and use that if it is
> >> non-zero before checking 802.1p, since DSCP is not limited to the local
> >> LAN/subnet and should be carried across hops (as opposed to 802.1p tags).
> >>
> >> "Gammaraman" <Gammaraman@discussions.microsoft.com> wrote in message
> >> news:341FB44D-4F86-4833-AA52-0F33A4441658@microsoft.com...
> >> > Hi,
> >> >
> >> > Here is a snippet I found on MSDN on how to get the UserPriority and
> >> > VlanID
> >> > fields from the OOB of a NDIS packet.
> >> >
> >> > NDIS_PACKET_8021Q_INFO VlanPriInfo;
> >> > UINT32 UserPriority;
> >> > UINT32 VlanID;
> >> > VlanPriInfo.Value =
> >> > NDIS_PER_PACKET_INFO_FROM_PACKET(pPacketDesc, Ieee8021QInfo);
> >> > UserPriority = VlanPriInfo.TagHeader.UserPriority;
> >> > VlanID = VlanPriInfo.TagHeader.VlanId;
> >> >
> >> > My question is what is the behavior of this snippet if NDIS did not
> >> > populate
> >> > the Ieee8021Qinfo part of the OOB? Is there someway the miniport driver
> >> > can
> >> > check/know whether NDIS populated this part of the OOB so that if it is
> >> > not
> >> > populated, it can inspect the TOS field of the IPv4 header for packet
> >> > classification instead?
> >> >
> >> > Thanks.
> >>
> >>
> >>
>
>
>

==============================================================================
TOPIC: NDIS marshalling pointers
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/c6853918b66d8360?hl=en
==============================================================================

== 1 of 5 ==
Date: Sat, Aug 9 2008 11:53 am
From: "Pavel A."

"Gammaraman" <Gammaraman@discussions.microsoft.com> wrote in message
news:F211976D-E7FB-4E5D-BEFD-2FA76E560B45@microsoft.com...
> Hi,
>
> It appears to me that NDIS must be marshalling pointers being passed
> between
> the protocol drivers and the miniport drivers. For e.g. when a set or
> query
> OID is called by NDIS on behalf of a protocol driver, typically some
> pointer
> parameters are passed.
>
> I have not found any documentation saying that miniport drivers need to
> perform some type of marshalling before reading/writing to the pointer
> parameters. Yet without someone doing some marshalling, the miniport
> driver
> would not be able to read/write to the pointer params due to
> security/memory
> architecture, etc.
>
> Can someone please confirm this?

( note: my reply is in the context of NT based Windows. AFAIK it
does cover WinCE as well - but better ask in WinCE newsgroups )

Both ends of NDIS OID interface (miniports and protocols/IMs) are in the
kernel.

NDIS miniports are not supposed to communicate directly with something else
besides protocols or their hardware devices. All this occurs in kernel mode.
Making a miniport communicate with user mode stretches it's contract to the
limit that leads to many
unwanted issues. Like you've mentioned, this raises the need in
marshaling, access rights, and there are more issues with
graceful handling of PnP & power events.

NDIS gives you means to expose a miniport to user mode
(NdisMRegisterDevice or NdisRegisterDeviceEx)
but if you use this, you are beyond NDIS contracts and are
on your's own. So, no documentation.

Regards,
--PA

== 2 of 5 ==
Date: Sat, Aug 9 2008 12:12 pm
From: Gammaraman

Thanks, Pavel.

What about an application using NDISUIO to talk to the miniport? From the
miniport's perspective, it is talking to an NDIS protocol driver however one
of the end points of the OID interface is now in user-space. Someone has to
marshall the pointer parameters, right?

"Pavel A." wrote:

> "Gammaraman" <Gammaraman@discussions.microsoft.com> wrote in message
> news:F211976D-E7FB-4E5D-BEFD-2FA76E560B45@microsoft.com...
> > Hi,
> >
> > It appears to me that NDIS must be marshalling pointers being passed
> > between
> > the protocol drivers and the miniport drivers. For e.g. when a set or
> > query
> > OID is called by NDIS on behalf of a protocol driver, typically some
> > pointer
> > parameters are passed.
> >
> > I have not found any documentation saying that miniport drivers need to
> > perform some type of marshalling before reading/writing to the pointer
> > parameters. Yet without someone doing some marshalling, the miniport
> > driver
> > would not be able to read/write to the pointer params due to
> > security/memory
> > architecture, etc.
> >
> > Can someone please confirm this?
>
> ( note: my reply is in the context of NT based Windows. AFAIK it
> does cover WinCE as well - but better ask in WinCE newsgroups )
>
> Both ends of NDIS OID interface (miniports and protocols/IMs) are in the
> kernel.
>
> NDIS miniports are not supposed to communicate directly with something else
> besides protocols or their hardware devices. All this occurs in kernel mode.
> Making a miniport communicate with user mode stretches it's contract to the
> limit that leads to many
> unwanted issues. Like you've mentioned, this raises the need in
> marshaling, access rights, and there are more issues with
> graceful handling of PnP & power events.
>
> NDIS gives you means to expose a miniport to user mode
> (NdisMRegisterDevice or NdisRegisterDeviceEx)
> but if you use this, you are beyond NDIS contracts and are
> on your's own. So, no documentation.
>
> Regards,
> --PA
>
>
>

== 3 of 5 ==
Date: Sat, Aug 9 2008 12:27 pm
From: "Pavel A."

"Gammaraman" <Gammaraman@discussions.microsoft.com> wrote in message
news:29CBD99E-4822-4785-B6E8-390B1B0AB52A@microsoft.com...
> Thanks, Pavel.
>
> What about an application using NDISUIO to talk to the miniport?

Gammaraman,

As already answered, in WinXP NDISUIO does not provide documented interfaces
for
our applications. Since your app is for WinCE, please ask in WinCE
newsgroups.

> From the
> miniport's perspective, it is talking to an NDIS protocol driver however
> one
> of the end points of the OID interface is now in user-space. Someone has
> to
> marshall the pointer parameters, right?

Yes, NDISUIO does the marshaling - hence, it takes responsibility
for all possible problems you've mentioned.

Regards,
--PA

> "Pavel A." wrote:
>
>> "Gammaraman" <Gammaraman@discussions.microsoft.com> wrote in message
>> news:F211976D-E7FB-4E5D-BEFD-2FA76E560B45@microsoft.com...
>> > Hi,
>> >
>> > It appears to me that NDIS must be marshalling pointers being passed
>> > between
>> > the protocol drivers and the miniport drivers. For e.g. when a set or
>> > query
>> > OID is called by NDIS on behalf of a protocol driver, typically some
>> > pointer
>> > parameters are passed.
>> >
>> > I have not found any documentation saying that miniport drivers need to
>> > perform some type of marshalling before reading/writing to the pointer
>> > parameters. Yet without someone doing some marshalling, the miniport
>> > driver
>> > would not be able to read/write to the pointer params due to
>> > security/memory
>> > architecture, etc.
>> >
>> > Can someone please confirm this?
>>
>> ( note: my reply is in the context of NT based Windows. AFAIK it
>> does cover WinCE as well - but better ask in WinCE newsgroups )
>>
>> Both ends of NDIS OID interface (miniports and protocols/IMs) are in the
>> kernel.
>>
>> NDIS miniports are not supposed to communicate directly with something
>> else
>> besides protocols or their hardware devices. All this occurs in kernel
>> mode.
>> Making a miniport communicate with user mode stretches it's contract to
>> the
>> limit that leads to many
>> unwanted issues. Like you've mentioned, this raises the need in
>> marshaling, access rights, and there are more issues with
>> graceful handling of PnP & power events.
>>
>> NDIS gives you means to expose a miniport to user mode
>> (NdisMRegisterDevice or NdisRegisterDeviceEx)
>> but if you use this, you are beyond NDIS contracts and are
>> on your's own. So, no documentation.
>>
>> Regards,
>> --PA
>>
>>
>>

== 4 of 5 ==
Date: Sat, Aug 9 2008 1:42 pm
From: Gammaraman

Thanks, Pavel.

"Pavel A." wrote:

> "Gammaraman" <Gammaraman@discussions.microsoft.com> wrote in message
> news:29CBD99E-4822-4785-B6E8-390B1B0AB52A@microsoft.com...
> > Thanks, Pavel.
> >
> > What about an application using NDISUIO to talk to the miniport?
>
> Gammaraman,
>
> As already answered, in WinXP NDISUIO does not provide documented interfaces
> for
> our applications. Since your app is for WinCE, please ask in WinCE
> newsgroups.
>
> > From the
> > miniport's perspective, it is talking to an NDIS protocol driver however
> > one
> > of the end points of the OID interface is now in user-space. Someone has
> > to
> > marshall the pointer parameters, right?
>
> Yes, NDISUIO does the marshaling - hence, it takes responsibility
> for all possible problems you've mentioned.
>
> Regards,
> --PA
>
>
> > "Pavel A." wrote:
> >
> >> "Gammaraman" <Gammaraman@discussions.microsoft.com> wrote in message
> >> news:F211976D-E7FB-4E5D-BEFD-2FA76E560B45@microsoft.com...
> >> > Hi,
> >> >
> >> > It appears to me that NDIS must be marshalling pointers being passed
> >> > between
> >> > the protocol drivers and the miniport drivers. For e.g. when a set or
> >> > query
> >> > OID is called by NDIS on behalf of a protocol driver, typically some
> >> > pointer
> >> > parameters are passed.
> >> >
> >> > I have not found any documentation saying that miniport drivers need to
> >> > perform some type of marshalling before reading/writing to the pointer
> >> > parameters. Yet without someone doing some marshalling, the miniport
> >> > driver
> >> > would not be able to read/write to the pointer params due to
> >> > security/memory
> >> > architecture, etc.
> >> >
> >> > Can someone please confirm this?
> >>
> >> ( note: my reply is in the context of NT based Windows. AFAIK it
> >> does cover WinCE as well - but better ask in WinCE newsgroups )
> >>
> >> Both ends of NDIS OID interface (miniports and protocols/IMs) are in the
> >> kernel.
> >>
> >> NDIS miniports are not supposed to communicate directly with something
> >> else
> >> besides protocols or their hardware devices. All this occurs in kernel
> >> mode.
> >> Making a miniport communicate with user mode stretches it's contract to
> >> the
> >> limit that leads to many
> >> unwanted issues. Like you've mentioned, this raises the need in
> >> marshaling, access rights, and there are more issues with
> >> graceful handling of PnP & power events.
> >>
> >> NDIS gives you means to expose a miniport to user mode
> >> (NdisMRegisterDevice or NdisRegisterDeviceEx)
> >> but if you use this, you are beyond NDIS contracts and are
> >> on your's own. So, no documentation.
> >>
> >> Regards,
> >> --PA
> >>
> >>
> >>
>

== 5 of 5 ==
Date: Sat, Aug 9 2008 2:47 pm
From: "Pavel A."

you're welcome.
Try also microsoft.public.pocketpc.developer.networking
--PA

"Gammaraman" <Gammaraman@discussions.microsoft.com> wrote in message
news:BACD3F35-8CF1-408F-BCA2-67A312371EEE@microsoft.com...
> Thanks, Pavel.
>
> "Pavel A." wrote:
>
>> "Gammaraman" <Gammaraman@discussions.microsoft.com> wrote in message
>> news:29CBD99E-4822-4785-B6E8-390B1B0AB52A@microsoft.com...
>> > Thanks, Pavel.
>> >
>> > What about an application using NDISUIO to talk to the miniport?
>>
>> Gammaraman,
>>
>> As already answered, in WinXP NDISUIO does not provide documented
>> interfaces
>> for
>> our applications. Since your app is for WinCE, please ask in WinCE
>> newsgroups.
>>
>> > From the
>> > miniport's perspective, it is talking to an NDIS protocol driver
>> > however
>> > one
>> > of the end points of the OID interface is now in user-space. Someone
>> > has
>> > to
>> > marshall the pointer parameters, right?
>>
>> Yes, NDISUIO does the marshaling - hence, it takes responsibility
>> for all possible problems you've mentioned.
>>
>> Regards,
>> --PA
>>
>>
>> > "Pavel A." wrote:
>> >
>> >> "Gammaraman" <Gammaraman@discussions.microsoft.com> wrote in message
>> >> news:F211976D-E7FB-4E5D-BEFD-2FA76E560B45@microsoft.com...
>> >> > Hi,
>> >> >
>> >> > It appears to me that NDIS must be marshalling pointers being passed
>> >> > between
>> >> > the protocol drivers and the miniport drivers. For e.g. when a set
>> >> > or
>> >> > query
>> >> > OID is called by NDIS on behalf of a protocol driver, typically some
>> >> > pointer
>> >> > parameters are passed.
>> >> >
>> >> > I have not found any documentation saying that miniport drivers need
>> >> > to
>> >> > perform some type of marshalling before reading/writing to the
>> >> > pointer
>> >> > parameters. Yet without someone doing some marshalling, the miniport
>> >> > driver
>> >> > would not be able to read/write to the pointer params due to
>> >> > security/memory
>> >> > architecture, etc.
>> >> >
>> >> > Can someone please confirm this?
>> >>
>> >> ( note: my reply is in the context of NT based Windows. AFAIK it
>> >> does cover WinCE as well - but better ask in WinCE newsgroups )
>> >>
>> >> Both ends of NDIS OID interface (miniports and protocols/IMs) are in
>> >> the
>> >> kernel.
>> >>
>> >> NDIS miniports are not supposed to communicate directly with something
>> >> else
>> >> besides protocols or their hardware devices. All this occurs in kernel
>> >> mode.
>> >> Making a miniport communicate with user mode stretches it's contract
>> >> to
>> >> the
>> >> limit that leads to many
>> >> unwanted issues. Like you've mentioned, this raises the need in
>> >> marshaling, access rights, and there are more issues with
>> >> graceful handling of PnP & power events.
>> >>
>> >> NDIS gives you means to expose a miniport to user mode
>> >> (NdisMRegisterDevice or NdisRegisterDeviceEx)
>> >> but if you use this, you are beyond NDIS contracts and are
>> >> on your's own. So, no documentation.
>> >>
>> >> Regards,
>> >> --PA
>> >>
>> >>
>> >>
>>

==============================================================================
TOPIC: Unknown Device,...
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/c9be0a0124661aad?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Aug 9 2008 12:13 pm
From: "Pavel A."

Install VMware.
Connect some USB device installed on the host, to a virtual machine.
Then watch what VMware does to the actual device connected to the host.
You probably want to do the same.
This is not easy (requires a driver) but the direction will be clear to
you.
A simpler and supported way can be using WinUSB
( details and examples - in WDK )

Regards,
-- PA

"Kerem Gümrükcü" <kareem114@hotmail.com> wrote in message
news:#4Xnyid#IHA.5056@TK2MSFTNGP06.phx.gbl...
> Hi Tim,
>
>>In the future, don't ever say "please don't ask why". It just sounds
>>childish and conspiratorial. It's especially strange here, since you
>>immediately went on to TELL us why.
>
> sorry, it shouldnt sound like that. I thought this is a unusual
> question so,...anyway, you are right, it sound childish and
> conspiratorial,...we are grown ups,..and i am a little too tired,
> so i must honestly apologize here Tim,...sorry for that foolish
> words,..
>
> I have some webcams, but whatever i plug into my system
> will be recognized and bound into the device nodes, so thats
> why i look for something that my system (XPSP3) does not
> know. I was thinking about placing something "unknown"
> somewhere maybe in the registry and then trigger a hardware
> scan, forcing the system to search for the "unknown" devices
> driver, leading to a "Question-Mark" in the Device Manager,...
>
> So thats what i wanted to do,...is there any way,...?
>
>
> Regards
>
> Kerem
>
> --
> -----------------------
> Beste Grüsse / Best regards / Votre bien devoue
> Kerem Gümrükcü
> Latest Project: http://www.codeplex.com/restarts
> Latest Open-Source Projects: http://entwicklung.junetz.de
> -----------------------
> "This reply is provided as is, without warranty express or implied."
> "Tim Roberts" <timr@probo.com> schrieb im Newsbeitrag
> news:sh5q94p5kn7l7ookkjhdtb0gbs0n07eq0q@4ax.com...
>> "Kerem Gümrükcü" <kareem114@hotmail.com> wrote:
>>>
>>>this maybe sounds strange, but for testing purposes, i
>>>need to have a unknown device visible in the device
>>>manager. How can i place a unknown device, best
>>>would be two, three and four. But they must be removable
>>>again!
>>>
>>>Please dont ask why, i know this sounds strange but
>>>i am working on a application that looks for unknown
>>>devices and then works on them,...
>>
>> In the future, don't ever say "please don't ask why". It just sounds
>> childish and conspiratorial. It's especially strange here, since you
>> immediately went on to TELL us why.
>>
>> However, I would point out that there is no real way to "work on" an
>> unknown device, since by definition such a device does not have a driver.
>>
>>>Is there any safe way to place several dummy
>>>unknown device into the systems device nodes?
>>
>> What resources do you have at your disposal? If you have a couple of USB
>> devices that are not in the standard USB classes, they appear as unknown
>> devices. Have any unusual web cameras?
>> --
>> Tim Roberts, timr@probo.com
>> Providenza & Boekelheide, Inc.
>

==============================================================================

You received this message because you are subscribed to the Google Groups "microsoft.public.development.device.drivers"
group.

To post to this group, visit http://groups.google.com/group/microsoft.public.development.device.drivers?hl=en

To unsubscribe from this group, send email to microsoft.public.development.device.drivers+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/microsoft.public.development.device.drivers/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com?hl=en