|
No, that's not true, at least not to any significant extent. In comparing new and used printers, I would consider such things as lifespan, likelihood of failure, maintenance cost, etc. But the difference in power consumption will be negligible.
|
|
|
|
|
I've been looking for a way to do this, but all I can find are ways to do this using the driver install wizard that pops up when you attach a PnP-device.
My problem is this: I have drivers for a USB device that I want to install silently. When the user attaches the device, it should just work. I am working with Windows Embedded Standard, which is an XP derivative.
Just right clicking the INF-file in an explorer window and selecting the "Install" verb just doesn't do it.
This shouldn't be hard to accomplish at all. I mean, USB mice and keyboards are installed on the fly, because Windows has been prepped with drivers for them. What's the silver bullet? 
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
I have solved it. I think. I'm working remotely into a virtual machine image at work. Unfortunately, as I'm not there, I can't really connect the USB-cable. 
Anyway, I found the solution in a book I have: Programming the Microsoft Windows Driver Model by Walter Oney (Microsoft Press). Distributed with it, there's a tool called FastInst, that installs the driver and the corresponding device node given a INF-file and all dependent files (drivers, CAT files, etc). I cannot publish the code here for legal reasons - I don't want to be sued for copyright infringements...
The chapter that references the topic of installing drivers, mentions that you can find the equivalent code in the DDK sample DEVCON. I can't publish that either, because the DDK isn't freely available anymore. I think there are old versions out there, that are freely available. YMMV.
Anyway, I verified that the FastInst utility installed the drivers in the correct place (C:\Windows\system32\drivers), the INF files in C:\Windows\INF (as oemXXX.inf as predicted by the book and several other web sites), corresponding registry entries (services, and configurations), as well as the signatures in C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.
I'll update this tomorrow morning if it worked out or not.
The Windows functions needed to perform the installation are (I think I can publish this without infringing on any copyrights):
* UpdateDriverForPlugAndPlayDevices()
* SetupDiCallClassInstaller()
* SetupDiCreateDeviceInfo()
* SetupDiSetDeviceRegistryProperty()
* SetupDiCreateDeviceInfoList()
* SetupDiDestroyDeviceInfoList()
* SetupOpenInfFile()
* SetupFindFirstLine()
* SetupFindNextLine()
* SetupGetFieldCount()
* SetupGetStringField()
* SetupDiGetINFClass()
* SetupDiClassGuidsFromName()
That ought to be food for google. This little utility by Walter Oney has probably been written many times by others.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
I mentioned earlier that I had found a tool (FastInst) that solves it all for me. That was true, in a sense. That tool is better used for updating existing drivers than it is installing new ones. If you run it for the first time, it will add a bogus device ID that will just sit in your device manager, never used. It kind of forced its way into the device tree, as if it missed something in the .inf-file, creating unusable devices. However, if I plugged in the real USB-device, a new node was created and matched to the driver. So it was a win, but it came with an ugly duckling.
What I really wanted was the installation of the driver, nothing more. It turns out that there's a magic function in the system called SetupCopyOEMInf(). I have seen it a couple of times, but it never caught my attention for some reason. It will copy the INF files, signatures, and whatever the INF-file wants, to your system and have the PnP-manager see it when the PnP-device is attached. It worked beautifully.
SetupCopyOEMInf(
"C:\Path\To\File.inf",
"C:\Path\To\DriverMedia",
SPOST_PATH,
0,
NULL,
0,
NULL,
NULL
);
The Path to the driver media is often the same directory as the INF-file itself.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
The technique I marked as "SOLVED" works only for XP Pro. In XP Pro, the CopyFile-sections of the INF file are executed. This means that the relevant driver files (*.sys) are copied to C:\Windows\system32\drivers. In Windows Embedded Standard, the CopyFile-sections are not executed - only INF and CAT files are installed. This means that the files have to be copied manually.
Why WES works this way, I am not sure. It could be that some crucial component has not been included in the image. I did not create the image, so I really have no idea.
So, for WES you have to either copy the files manually during a DUA update, or you can use Walter Oney's FASTINST if you have access to that.
For those of you who need to do this on Vista and later operating systems, there's a function called DiInstallDriver() that seems to solve pretty much everything for you. You just need the driver media (*.sys et al) and the INF/CAT files. I can't grasp why this function wasn't added eons ago...
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
You can do it programatically using CopyOEMInf().
Basically it just registers the inf file with the system and puts the relevant files in the right place.
Morality is indistinguishable from social proscription
|
|
|
|
|
It doesn't work. It's been a while, but if I recall correctly, it doesn't execute class installers, and update the appropriate PnP-IDs, etc.
Turns out that Vista has a really nice driver installation API, but XP doesn't. I found a working example in a book (I mention above).
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Ahmk you are tyalking about any upgrade,in that case use the setupdiupdatedriverforpnpdevice (or somehting like that). This worls for all windows oss
Morality is indistinguishable from social proscription
|
|
|
|
|
Hi, I have an old laptop dell latitude c600. It has a problem with its keyboard so I replace it witht he new one from dell company. The problem is the key C, and N could not type. After relate around 6 month, the new keyboard has a problem again. So I decide to purchase an external USB keyboard to use with this laptop because it is cheaper.
But using around 6 month again, the external keyboard also got a problem with the key C and N again (I could not type it). Why? Is it the problem with the keyboard or the laptop? I tough it was the problem with the laptop. So I try to used this external keyboard with the other computer but the problem is still the same. They key C and N is having a problem. I don't know why the problem just had with the laptop now its come to the external keyboard.
Does anyone know what is the cause of the problem and how to solve that problem?
Thank in advance!!!
|
|
|
|
|
Strange. Coincidence? Are you using the C and N keys aggressively?
|
|
|
|
|
Indivara wrote: Strange
Yes, it also strange to me too.
Indivara wrote: Are you using the C and N keys aggressively?
No, I use this keyboard very gentle. Actually, I also have another destkop computer to use. So it is very less chance for me to make someting wrong with the keyboard. I use it as normal and really love my computer.
Do you have any more idea about this problem?
|
|
|
|
|
Curioser and curioser...
Just listing the posssibilities -
* Virus messing with the hardware (has happened in the past) - but that would mean other keyboards on the second computer should be affected too
* Dirt in keyboard - but this couldn't possibly happen to the same keys on three keyboards
* Controller error on laptop - but the external keyboard shows the same symptoms on another computer
* Electrical fault on laptop burning out same keys on external keyboard - is this possible? No idea...
* Practical joke?
Trying another keyboard is the only thing I can think of now.
|
|
|
|
|
Does anybody have a clue as how to do this? I'm guessing the SetupDiXXX() functions in the DDK could help me, but I'm not sure. The API isn't all that intuitive.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
I expect WMI to hold all such information. Try the Win32_SerialPort class.
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
|
Hi Jörgen,
I would suggest that you have a look at the EnumSerialPorts class[^] by Microsoft MVP P.J. Naughter. His class includes WMI along with the Setup API functions and every other possible method of enumerating COM ports. You should easily be able to modify his class to identify the vendor.
Best Wishes,
-David Delaune
|
|
|
|
|
Oooh. I had already found a solution to my problem, but I think I'll go with PJ's class instead, as it's tested and more mature than my single function.
Thank you for the link!
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
|
I don't read Chinese.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Argh.  It was such a sweet idea, but I'm blown to hell by some of the device drivers I'm targetting. They don't seem to provide any information to WMI, so they're invisible to WMI queries, but visible with my SetupDIXXX()-implementation.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Yeah in my opinion WMI is not suitable for robust hardware enumeration. You are making the right choice by using the SetupDi class of API functions. I probably would have used the PnP Configuration Manager Functions[^] even though it seems Microsoft does not recommend calling them directly.
Best Wishes,
-David Delaune
|
|
|
|
|
WMI is not mandatory!
Actually I never imnplemented it.
Basically you will need to enumerate the serial (GUID) devices from your app. Get the friendly nmame for each device, and if it is the right port (this is the name displayed in device manager) then you go ahead and use it.
OK, I;ll be nice and bung you some code to help:
SetupDiGetClassDevs(); Thiks gives you a kind of handle to an array.
Call SetupDiEnumDeviceInterfaces(); for each device in sdaid 'array'.
With the info from this call SetupDiGetDeviceInterfaceDetail(), then call
SetupDiOpenDeviceInterface();
Then call SetupDiGetDeviceRegistryProperty() SPDRP_FRIENDLYNAME and SPDRP_DEVICEDESC for example.
If you agree that GW is a crock of chit I'll mail you some code. 
Morality is indistinguishable from social proscription
|
|
|
|
|
fat_boy wrote: If you agree that GW is a crock of chit I'll mail you some code. Poke tongue
I solved it using SetupDiEnumDeviceInterfaces() et al! So, no, I am not going to admit anything than greaaaaaaaat succeeess!
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Jörgen Sigvardsson wrote: I solved it using SetupDiEnumDeviceInterfaces() et al!
Yep, I'll bet it felt like giving birth to a water mellon!
Mind you, these funcs get easier to use the more you use them.
Morality is indistinguishable from social proscription
|
|
|
|
|
Well, I'm not going to venture into these territories again, if I don't really have to. My role is somewhere right above driver level all the way up to the UI.
The reason I had to do this was because of poor planning. We have devices running Windows Embedded that have already been deployed with a certain image/OS configuration. The new hardware requirement came after the deployment, so I had to find a way to install the driver in a device update script.
But I must say I've learned a lot about how Windows works. I've read a couple of device driver programming books as well as windows internals books (Russinovich et al). I've also had to figure stuff out on my own. Stuff that can be added to the CV, and mentioned i future job interviews.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Its a usefull (!!!) set of functions. You can disable a device for example to cause a power reset, but, as you say, they are a little bizare.
Of course as a kernel expert al this kind of stuff is bread and buter to me. For me to write an app now is just too dull. I guess I have spent so long messing around in the kernel that user mode is just too easy.
Its always uefull to know at least some of this stuff though.
Morality is indistinguishable from social proscription
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
