Device removal mess

Device removal mess

Post by Guy Barwoo » Tue, 03 Sep 2002 17:13:06



I am trying to remove a device from the system (equivalent of just manually
deleting it from DM).

So far I have worked out I need to use the following (I think!)
    SetupDiRemoveDevice

But his need a handle to the device, so I have to use:
    SetupDiGetClassDevs
to get the device info set (in this case of the 1394 list)

Then use
    SetupDiEnumDeviceInterfaces
to get the required device handle of the individual device.

BUt also use SetupDiEnumDeviceInfo to get.., oh *I;m lost working out
what comes from where!

Iit seems like I'm jumping through too many hoops, I'm stuck on defining the
DeviceInterfaceData (PSP_DEVICE_INTERFACE_DATA).  I am reading I need to
"...set DeviceInterfaceData.cbSize to sizeof(SP_DEVICE_INTERFACE_DATA)
before calling this function. "

What the?  There is no indication as to how to go from here.  How do I even
know what the size should be?

Then there is the "IN PSP_DEVINFO_DATA  DeviceInfoData" paramater.

Any help out there???

 
 
 

Device removal mess

Post by Max Shoniche » Wed, 04 Sep 2002 01:43:59



> I am trying to remove a device from the system (equivalent of just manually
> deleting it from DM).

> So far I have worked out I need to use the following (I think!)
>     SetupDiRemoveDevice

> But his need a handle to the device, so I have to use:
>     SetupDiGetClassDevs
> to get the device info set (in this case of the 1394 list)

> Then use
>     SetupDiEnumDeviceInterfaces
> to get the required device handle of the individual device.

> BUt also use SetupDiEnumDeviceInfo to get.., oh *I;m lost working out
> what comes from where!

> Iit seems like I'm jumping through too many hoops, I'm stuck on defining the
> DeviceInterfaceData (PSP_DEVICE_INTERFACE_DATA).  I am reading I need to
> "...set DeviceInterfaceData.cbSize to sizeof(SP_DEVICE_INTERFACE_DATA)
> before calling this function. "

> What the?  There is no indication as to how to go from here.  How do I even
> know what the size should be?

> Then there is the "IN PSP_DEVINFO_DATA  DeviceInfoData" paramater.

> Any help out there???

you declare variable SP_DEVICE_INTERFACE_DATA:

        SP_DEVICE_INTERFACE_DATA data;

then initialize it with zeroes and set the size for Win could understand
what version your app is build for.
        data.cbSize = sizeof(data);    

that is exactly how it needs to understand message you were "reading"...

then you pass address of that structure to function required, for it
could change the values in the structure in response:

        SetupDiSomething(..., &data, ...);

Hope that helps fighting with this complicated API. Good luck, it only
looks frightful at first glance!  :)

 
 
 

Device removal mess

Post by Guy Barwoo » Wed, 04 Sep 2002 10:45:22


Thanks Max,

I also found an example of this at:
http://www.veryComputer.com/;EN-US;Q259695&

which has helped a lot,  its just ends up like this:
 SP_DEVINFO_DATA DeviceInfoData;
 DeviceInfoData.cbSize = sizeof(SP_DEVINFO_DATA);

Which is bizzare to me, and I sort of see how it is working but it seems
wierd to get the size of an object that has only been defined.

The page above has one issue (from these two lines):
    LPTSTR buffer = NULL;
    buffer = LocalAlloc(LPTR,buffersize);
this generates a compile error can not assign HLOCAL to LPTSTR, so I had to
change it to use
    buffer =(LPTSTR) HeapAlloc(GetProcessHeap(), NULL, buffersize);
instead.

Now I am stuck on another stupid little one.  I need to compare the contects
of a LPTSTR (as in the null terminated string it points to, not the pointer,
to a predefined string as in:

    if ("some text" == (&buffer) .......
I have tried lots of differnt options, but always get the likes of: "can not
convert from LPTSTR to Cstring/Char*" etc...

Any ideas. (PS I'm gona repost this little one a s a seperate thread.

Cheers

Guy



> > I am trying to remove a device from the system (equivalent of just
manually
> > deleting it from DM).

> > So far I have worked out I need to use the following (I think!)
> >     SetupDiRemoveDevice

> > But his need a handle to the device, so I have to use:
> >     SetupDiGetClassDevs
> > to get the device info set (in this case of the 1394 list)

> > Then use
> >     SetupDiEnumDeviceInterfaces
> > to get the required device handle of the individual device.

> > BUt also use SetupDiEnumDeviceInfo to get.., oh *I;m lost working
out
> > what comes from where!

> > Iit seems like I'm jumping through too many hoops, I'm stuck on defining
the
> > DeviceInterfaceData (PSP_DEVICE_INTERFACE_DATA).  I am reading I need to
> > "...set DeviceInterfaceData.cbSize to sizeof(SP_DEVICE_INTERFACE_DATA)
> > before calling this function. "

> > What the?  There is no indication as to how to go from here.  How do I
even
> > know what the size should be?

> > Then there is the "IN PSP_DEVINFO_DATA  DeviceInfoData" paramater.

> > Any help out there???

> you declare variable SP_DEVICE_INTERFACE_DATA:

> SP_DEVICE_INTERFACE_DATA data;

> then initialize it with zeroes and set the size for Win could understand
> what version your app is build for.
> data.cbSize = sizeof(data);

> that is exactly how it needs to understand message you were "reading"...

> then you pass address of that structure to function required, for it
> could change the values in the structure in response:

> SetupDiSomething(..., &data, ...);

> Hope that helps fighting with this complicated API. Good luck, it only
> looks frightful at first glance!  :)

 
 
 

Device removal mess

Post by Guy Barwoo » Wed, 04 Sep 2002 12:05:14


Don't worry, got it sorted, I think.
LPTSTR buffer = NULL;
LPTSTR buffertest = "ACPI Fixed Feature Button";
//buffer gets populated...

if (*buffertest == *buffer)

Who would think you could assign a string to a pointers contents directly
referencing the point.  Maybe I just don't understand the LPTSTR type
properly yet.


Quote:> Thanks Max,

> I also found an example of this at:
> http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q259695&

...>
> Now I am stuck on another stupid little one.  I need to compare the
contects
> of a LPTSTR (as in the null terminated string it points to, not the
pointer,
> to a predefined string as in:

>     if ("some text" == (&buffer) .......
> I have tried lots of differnt options, but always get the likes of: "can
not
> convert from LPTSTR to Cstring/Char*" etc...

...
 
 
 

Device removal mess

Post by Max Shoniche » Wed, 04 Sep 2002 14:16:26



> Don't worry, got it sorted, I think.
> LPTSTR buffer = NULL;
> LPTSTR buffertest = "ACPI Fixed Feature Button";
> //buffer gets populated...

> if (*buffertest == *buffer)

> Who would think you could assign a string to a pointers contents directly
> referencing the point.  Maybe I just don't understand the LPTSTR type
> properly yet.

Um... are you newbie to C++ ? :)

I guess you *should* read some good book about that language and
especially all chapters about pointers, arrays, references, and
structures or you will get those "another stupid little one" in million
of cases.

First, your solution for comparing strings is totally wrong. Don't
worry, it just wont work in some cases.  :)
The fact it managed to compile says nothing. :))
C++ likes those kind of ambiguosity, it just "thinks" that you must get
exactly what you've asked for. In that case - you compare NOT
the strings, but just ONE first character of each string!

LPTSTR is just another name to "char *", so it is very simple type and
"Who would think you could assign a string to a pointers contents
directly referencing the point." - is wrong. (Alas, this could be right
for some *really* complicated type, because most operations, even
dereference and comparation, could be overloaded in C++. You'll like
that language... :) )

The fact that
  LPTSTR buffertest = "ACPI...";
compiles, also says nothing.

It is just such special syntax to initialize pointers to char ("char
*"). It should be thinked of like this "allocate storage in data segment
for constant string during compilation time, copy  characters supplied
to that storage, remember address of the first character to given
variable". during execution time - NO string is allocated, your
buffertest just gets pointed to that pre-allocated single-use storage,
and NO copying of characters occures. If you change that string (meaning
the characters in string, NOT the pointers :) ) - all pointers to that
string would "show" changed value.

While dereferencing LPTSTR, which is "char *", you get "char", of
course... and the string is "char []", say "char [10]" or "char[256]",
you got it? string is the sequence of characters, i.e. array of chars.
Thus, if you want to compare whole strings, you must use something like:

_tcscmp(buffer, buffertest);

Second, the sample was written for "C", not the C++. C is much more
friendly, it does not allow classes, operator overloading, templates,
and thus all errors you could met with this. It also check types more
lazily, that's why LPTSTR type is equal to HANDLE type in the sample and
not in your project.

If you want allocate memory - in most cases you should forget about
Windows API like LocalAlloc, etc... use "new" operator, it comes with
C++ and support type conversion by default. Look here:

char *pStr = new char [200];

got it? the syntax is     'new "type"'. in that case type is char [200],
which means allocate 200 characters for storage. you could treat
"char[200]" like "char *", meaning that when you need to work with the
array you could just have pointer to the forst element of the array.

after you work with pStr (be sure NOT to change pStr, only use it as
"readonly", change values it points to, i.e. pStr[2]) you can free the
memory by calling

delete pStr;

that's the syntax: you get the pointer allocated with "new" and pass it
to delete. Understood the fact why pointer itself should not change?

Third, Windows lives for more over 10 years with lots of different
versions been introduced. The SetupDi API is from Win32, the LocalAlloc
is from Windows3.0, as far as I remember... ;-)

To support different versions, using "sizeof" member of structures is
just common practice (and not only in Windows). Guess what happens, if
you run "old" program which thinks sizeof(SP_DEVICE_DATA) is 100 with
new, revised version of the system which thinks sizeof(SP_DEVICE_DATA)
is 98? system would overwrite some piece of memory, and it will GPF.

Hope I helped you, follow the advise: study C++, it worth effors...

        Max Shonichev.

 
 
 

Device removal mess

Post by Guy Barwoo » Wed, 04 Sep 2002 17:12:17


Thanks Max,

I'm not new to C++, but very new to Visual C++.  LPTSTR is not a standard
c++ data type definition (at least from my experience and c++ Uni text
books), as are not functions like SetupDiGetDeviceRegistryProperty etc .
This is the problem I am having, learning the MS way/extensions.

I've spent a lot of time with pointers, arrays etc, and have great books on
the ANSI c++ language (my thesis was using four dimensional link lists and
maze path solving), just few on VC++.   Interesting the Visual C++ book I
have (in 21days series) makes no reference at all to LPTSTR or LPSTR
thoughtout the entire book.  I need a book entitled "So you know C++, now
learn how to do it the Microsoft/Windows way".

I've saved your response for much deeper reading and reference as I work on.
Thank you very much for your time

Cheers

Guy



> > Don't worry, got it sorted, I think.
> > LPTSTR buffer = NULL;
> > LPTSTR buffertest = "ACPI Fixed Feature Button";
> > //buffer gets populated...

> > if (*buffertest == *buffer)

> > Who would think you could assign a string to a pointers contents
directly
> > referencing the point.  Maybe I just don't understand the LPTSTR type
> > properly yet.

> Um... are you newbie to C++ ? :)

> I guess you *should* read some good book about that language and
> especially all chapters about pointers, arrays, references, and
> structures or you will get those "another stupid little one" in million
> of cases.

> First, your solution for comparing strings is totally wrong. Don't
> worry, it just wont work in some cases.  :)
> The fact it managed to compile says nothing. :))
> C++ likes those kind of ambiguosity, it just "thinks" that you must get
> exactly what you've asked for. In that case - you compare NOT
> the strings, but just ONE first character of each string!

> LPTSTR is just another name to "char *", so it is very simple type and
> "Who would think you could assign a string to a pointers contents
> directly referencing the point." - is wrong. (Alas, this could be right
> for some *really* complicated type, because most operations, even
> dereference and comparation, could be overloaded in C++. You'll like
> that language... :) )

> The fact that
>   LPTSTR buffertest = "ACPI...";
> compiles, also says nothing.

> It is just such special syntax to initialize pointers to char ("char
> *"). It should be thinked of like this "allocate storage in data segment
> for constant string during compilation time, copy  characters supplied
> to that storage, remember address of the first character to given
> variable". during execution time - NO string is allocated, your
> buffertest just gets pointed to that pre-allocated single-use storage,
> and NO copying of characters occures. If you change that string (meaning
> the characters in string, NOT the pointers :) ) - all pointers to that
> string would "show" changed value.

> While dereferencing LPTSTR, which is "char *", you get "char", of
> course... and the string is "char []", say "char [10]" or "char[256]",
> you got it? string is the sequence of characters, i.e. array of chars.
> Thus, if you want to compare whole strings, you must use something like:

> _tcscmp(buffer, buffertest);

> Second, the sample was written for "C", not the C++. C is much more
> friendly, it does not allow classes, operator overloading, templates,
> and thus all errors you could met with this. It also check types more
> lazily, that's why LPTSTR type is equal to HANDLE type in the sample and
> not in your project.

> If you want allocate memory - in most cases you should forget about
> Windows API like LocalAlloc, etc... use "new" operator, it comes with
> C++ and support type conversion by default. Look here:

> char *pStr = new char [200];

> got it? the syntax is     'new "type"'. in that case type is char [200],
> which means allocate 200 characters for storage. you could treat
> "char[200]" like "char *", meaning that when you need to work with the
> array you could just have pointer to the forst element of the array.

> after you work with pStr (be sure NOT to change pStr, only use it as
> "readonly", change values it points to, i.e. pStr[2]) you can free the
> memory by calling

> delete pStr;

> that's the syntax: you get the pointer allocated with "new" and pass it
> to delete. Understood the fact why pointer itself should not change?

> Third, Windows lives for more over 10 years with lots of different
> versions been introduced. The SetupDi API is from Win32, the LocalAlloc
> is from Windows3.0, as far as I remember... ;-)

> To support different versions, using "sizeof" member of structures is
> just common practice (and not only in Windows). Guess what happens, if
> you run "old" program which thinks sizeof(SP_DEVICE_DATA) is 100 with
> new, revised version of the system which thinks sizeof(SP_DEVICE_DATA)
> is 98? system would overwrite some piece of memory, and it will GPF.

> Hope I helped you, follow the advise: study C++, it worth effors...

> Max Shonichev.

 
 
 

1. Manually removal device from "Other devices" when install new device!

Dear ALL:
   When I install a new driver for a new device(This device has never been
install with any driver and is placed in "Other devices" ), I found this
system can not install my driver.
   If I remove this device from "other device" and refresh the device list
in Windows Device Manager, the the system can recogonize the newly discoverd
device and install the driver.
   I simply do not want to remvove the device from "other device" list
MANUALLY, how should I modify my inf file and driver code to automatically
install without any manual removal?
   Thanks & Best Regards!

  (Example Source code of the inf file is preferred)

2. <Wanted>Broken II,IIx,SE/30

3. Don't show "Unsafe Removal of Device" Dialog?

4. New HighSpeed Servo Library For Dios available

5. Surprise removal of USB device while writing data to isochronous pipe

6. VLM's and 32-BIT Disk Access

7. Surprise Removal of Multi-Function Device

8. Double navbar

9. Device insertion/removal Event Notification

10. Problem with Surprise Removal in a USB device

11. How can I receive a PnP event for USB device removal in usermode?

12. Avoiding the Win2k Unsafe Device Removal Dialog

13. NT Device Driver Installation and Removal