|
Brady Kelly wrote: it won't get through all three sheets.
Changing to Draft mode won't change how hard the pins strike the paper, so give it a try. The current mode, however, may be double-striking, or using a font that's wider than normal to make a clear third copy. It's worth playing with it, though, and you can't hurt anything (so long as you remember what the original settings were and restore them later). You might also check the settings to see if bi-directional printing is enabled. That can make big speed difference.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Hi
I have a problem. I want to detect USB Disk, but when I use GetDriveType, fuction return 3 drives instead 1 (it also return floppy disk and remote hard drive). I what to know alternative of GetDriveType.
|
|
|
|
|
Hi,
you can use WMI classes to get more details, such as the interface ("USB").
However it is not that easy, and it keeps getting more and more complex to
figure out a general solution as more device types emerge: you have to discern
USB floppies, USB hard disks, USB memory sticks, USB DVD drives, etc.
However an ad hoc solution to a specific problem is most certainly doable,
given time and lots of googling.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
I think that using WMI it's a wright way and maybe connect to ("system evets") & ("USB") interface.
Thanks for help!!
|
|
|
|
|
I'm looking for some kind of toolkit used for building drivers.
I know of two:
Compuware has retired DriverStudio since 2006 and I cannot find any replacement for it from Compuware. So building a driver for e.g. 64-bit Vista would be out of the question with an old version of DriverStudio.
Is really Jungo the only alternative out there?
Of course it's possible to build a driver with only the DDK, but I figure that the benefits of using a toolkit outweighs the drawbacks.
Any tip is appreciated.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Fat_Boy develops drivers for a living, drop him an e-mail via CP and ask him what he uses.
modified 1-Aug-19 21:02pm.
|
|
|
|
|
Mmm, that's a thought, but I'm rather reluctant to sending personal mails.
I know I get somewhat upset when people are emailing me directly asking for help, it kind of invades the privacy...
Well, that's how I interpret the forum guidelines and since that's how I would like to be treated, I treat other members the same way.
But it's a good idea otherwise, thanks.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: Compuware has retired DriverStudio since 2006 and I cannot find any replacement for it from Compuware. So building a driver for e.g. 64-bit Vista would be out of the question with an old version of DriverStudio.
I only used DriverStudio in the past. To tell the truth, I don't really like it though: When there are more than one DDK version installed in the system, configuring VC6 for DriverStudio is sometimes a nightmare. And SoftICE debugger usually failed with most of newer graphic chips.
The driver team of my company uses simply WDK without any helper toolkit.
Even though DriverStudio is retired, there is DevPartner (LINK[^]) to replace with.
Maxwell Chen
|
|
|
|
|
Maxwell Chen wrote: Even though DriverStudio is retired, there is DevPartner (LINK[^]) to replace with.
Well, Maxwell....
Perhaps I'd better get my eyes checked, but I cannot find any information saying that DevPartner can be used for developing drivers the same way DriverStudio was used.
I've looked through the page you linked to prior to starting this thread, but to me DevPartner seems more like a tool for analysing the source code when it's already been written rather than using it for development with some class libraries.
DevPartner could probably be used for debugging a device driver, but I expect a toolkit to be bundled with that functionality as well as a class library or similar to be used for creating the driver.
Do you know of a page I haven't found that clearly stating that DevPartner ships with code and/or wizards to facilitate the development of a driver? 
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
You are right! DevPartner seems to focus on user mode analysis and debugging. There is no kernel mode device driver features. I am so sorry that I made a mistake.
Maxwell Chen
|
|
|
|
|
Maxwell Chen wrote: I am so sorry that I made a mistake.
No worries, Maxwell.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
There is the KMDF from Microsoft. I used that for my latest drivers and found it relatively easy to use, if a bit verbose in its function names  . It handles a lot of the tedious repetitive stuff like PnP and Power management for you. Now that KMDF is around, I haven't found a need to try to find another toolkit - the framework deals with all the stuff I previously wanted dealt with by a toolkit.
Judy
|
|
|
|
|
Nice Judy, thanks.
I'll look into it.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: but I figure that the benefits of using a toolkit outweighs the drawbacks.
not really. wrappers like jungo have their uses, perhaps (although I would never use it), but eventually, you are going to have to get your handsa dirty and dig around beneath the wrapper to either fix something in the wrapper or get some functionality it doesnt provide.
and then you are looking into the depths of hell itself. so you might as well start of like you mean to go on and take the big leap, dig into it, and just use the WDM api.
The ddk is limited, confusing, and nightmarish to useso, provided you only want to do WDM, then I suggest Walter ONeys book, Programming the Windows Driver Model.
Morality is indistinguishable from social proscription
|
|
|
|
|
Thanks for your reply fat_boy.
fat_boy wrote: but eventually, you are going to have to get your handsa dirty and dig around beneath the wrapper to either fix something in the wrapper or get some functionality it doesnt provide.
So I shall interpret this as something like "if you're writing a simple driver you won't need a toolkit and if you're writing a complex driver a toolkit provides more trouble than help"?
Or would that be pushing it too far?
My customer needs a driver for USB DFU (Device Firmware Upgrade), but they need to be able to modify the driver after I've left the building.
Even if I consider a driver for DFU as quite small and simple in comparison, my customer has very little or none experience of kernel mode development. That's why I'm interested in toolkits such as the one from Jungo as I assume that the need for kernel mode experience is limited (at least Jungo claims so).
Other ideas or Suggestions?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Writing kernel drivers for windows is a serious undertaking regardless of the size: every driver has the potential to trash the OS so I would not expect anyone short of a very good Windows programmer with 5 years of experience capable of even starting to begin to modify a driver and have it anywhere near stable. And even then they will have a massive learning curve.
I dont know Jungo though and it might well do what you want. Talk to them and see.
Morality is indistinguishable from social proscription
|
|
|
|
|
fat_boy wrote: every driver has the potential to trash the OS so I would not expect anyone short of a very good Windows programmer with 5 years of experience capable of even starting to begin to modify a driver and have it anywhere near stable. And even then they will have a massive learning curve.
Exactly my point.
That's why I wanted something to simplify things for my customer, if they need to modify the driver in the future.
Perhaps the chances of combining these two parameters are ridiculously close to zero and I end up writing it with the DDK anyway, or one of the frameworks Judy and Mike has suggested.
On the other hand it may create an opportunity to return to the scene of the crime if the driver needs to be modified.
Thanks for your time fat_boy.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: On the other hand it may create an opportunity to return to the scene of the crime if the driver needs to be modified.
That is a good idea. Sell them the product and maintenance.
If you ever do get a driver up and running, well, you will have acchievde a massive amount. You can capitolise on that work.
Morality is indistinguishable from social proscription
|
|
|
|
|
Since this is a USB device, perhaps the User-Mode Driver Framework[^] would be appropriate? See the FAQ[^].
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
It may be.
Judy suggested me to look into both UMDF and KMDF and I've done so a little. I haven't had the time to really get into things yet, but I will certainly have a serious go for it.
Judging from the FAQ it will do very well for this DFU driver.
I haven't really found all the info I need on how to get the framework and what it costs and that's essential input for my customer to make a decision whether to use it or not.
As I understood it, the framework is available through this MS "Connect"-thing... But what's the charge? Got to ask since I couldn't find a statement that it's free of charge.
Any chance you know it by heart?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hi,
Do you know locking/unlocking capability of your hard disk? If not, read following.
Every hard disk has inbuilt controller, called ATA controller. ATA stands for Advanced Technology Attachment or AT Attachement. ATA is the standard protocol to interact with the hard disk. ATA protocol has several commands using which hard disk can be locked or unlocked.
This lock is the hardware lock. Once hard disk is locked, you can't read/write from your hard disk, until unlocked. Once it is locked, all commands to hard disk will be aborted, except commands for unlocking and some special commands.
Almost all modern hard disk support security feature. By default security feature is disabled. It needs to be enabled and then only hard disk can be locked/unlocked. Some older hard disk might not support this feature.
I have created a utility, completely coded 'C' language, to lock/unlock hard disk.
For more details and downloading this utility, visit Lock-Unlock Hard Disk[^]
Thanks,
Sandeep B. Vaniya
|
|
|
|
|
This seems to be good material for an article.
|
|
|
|
|
I will publish article for the same on code project.
Thanks for your suggestion.
|
|
|
|
|
What about the last article you wrote here on that utility?
Make sure you include the source this time... 
|
|
|
|
|
I had published article after Andersson's suggestion. But you guys might not like that article so I have removed it.
I am already in my home with my bat and ball.
I am wondering that you are still searching for source code.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
