|
You cannot include the ntddk.h in an application with the windows.h. so the only turn around is to copy the function definition from the ntddk.h and paste in one for your local file.
|
|
|
|
|
Hi Naveen,
Naveen wrote: so the only turn around is to copy the function definition from the ntddk.h and paste in one for your local file.
that's bad. where will he find the implementation of the function then ?
|
|
|
|
|
toxcct wrote: that's bad.
But thats the only way. You might be aware that that function are implemeted in the ntdll.dll. But Platform SDK or visual c++ dosent offer a ntdll.lib file so that he can staticaly link his application to ntdll.dll. So only chance is to load that dll dynamically and call those function.
|
|
|
|
|
Have you tried your luck with ntifs.h ?
-Sarath.
"Great hopes make everything great possible" - Benjamin Franklin
|
|
|
|
|
kcynic wrote: wdm.h or ntddk.h
You can't include those in normal user-mode programs. They are strictly for kernel-mode or native-mode programs.
Judy
|
|
|
|
|
Perhaps that is true.But I really what read some information from my USB device.My two task are these:
1.When I scan a USB device plugged,I want to get its driver letter like G,H,and so on.For example,i get a device instance like "USB\VID_0AC8&PID_301B\5&37FD04DB&0&2" using SetupDiGetInterfaceDeviceDetail,so I using that path to create a HANDLE(using ZwOpenFile),then I want to call ZwQueryInformationFile() to get some information,or call ObReferenceObjectByHandle().But these functions are decleared in wdm.h or ntddk.h.
2.The document of my USB device(or storage)says that,the special information should be retrieve by SCSI INQUIRY,I find it is IOCTL_SCSI_GET_INQUIRY_DATA command.But I do not know how to do.
I will be very appreciated if someone give me some advice.
Thanks.
GOOD LUCK
|
|
|
|
|
You can do this without using the functions from wdm and ntddk. After you get your device's name using the <code>SetupDi</code> functions, open a handle using <code>CreateFile</code>. Then use <code>DeviceIoControl</code> to send the IOCTL_SCSI_GET_INQUIRY_DATA to the device. Google on that IOCTL and you'll find some examples of calling it from user mode.
Judy
|
|
|
|
|
how to generate a random number within a range ( eg: between 5000 and 7500 ) ??
Thanks & Regards
|
|
|
|
|
|
Make it for 0 to 2500 and then add 5000 :P
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
|
Definitivelly, there is people that are blind and don't see the symbol of "joke" in the posts. I put a 5 to compensate the bad points.
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
Nelek wrote: Definitivelly, there is people that are blind and don't see the symbol of "joke" in the posts. I put a 5 to compensate the bad points.
Oh I don't care about bad votes of such people. Anyway, thank you very much I really appreciate you kindness.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
(rand() % (UPPER_BOUND - LOWER_BOUND)) + LOWER_BOUND
|
|
|
|
|
On statistical grounds (don't ask me why ) the best better approach is instead the one provided by the MSDN sample http://msdn2.microsoft.com/en-us/library/398ax69y(VS.80).aspx[^], i.e.
int u = (double)rand() / (RAND_MAX + 1) * (range_max - range_min)
+ range_min;
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Hi All,
I have functions A & B.
A will be the starter. A will call B.
Again B will call A.
This call will go recursively until a condition is satisfied.
But after around 200 executions, if the condition is not getting satisfied, Stack overflow happens.
fn A{
......
call fn B
}
fb B{
......
call fn A
}
Is there any way to call function B after the complete execution of A is getting finished. So that the scope of A will be completed before calling Function B.
What if call PostMessage in this case?
Any help would be appreciated...
Thanks in advance.........
|
|
|
|
|
krishnan.s wrote: This call will go recursively until a condition is satisfied.
But after around 200 executions, if the condition is not getting satisfied, Stack overflow happens.
IMHO it is a bit too early, but anyway....
krishnan.s wrote: Is there any way to call function B after the complete execution of A is getting finished. So that the scope of A will be completed before calling Function B.
What if call PostMessage in this case?
I think the question is: is the algo recursive?
If the answer is yes, then you can either try to increase stack size or transform the algo to do iteration instead of recursion.
If the answer is no, then you have to modify your buggy code.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
You may be able to prevent this problem by passing less data with each call, passing references instead, keeping your data in a heap allocated structure etc. These changes may be simpler than changing the algorithm. If you post a few more details, function signatures, some idea of the data structures involved as solution may present itself.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Hi Everyone,
I need some help regarding implementation of iLBC codec for compressing audio files.
Thanks in advance..
regards,
programmer81
|
|
|
|
|
This is a dialog based application. I want the application execute some code after the main window and all child windows displayed correctly. Where should I write the code ?
I think OnInitDialog is not a good place, because the window have not displayed yet.
Thank you all!
|
|
|
|
|
You can call PostMessage() inside OnInitDialog to post a user message, then in the message handler do needed stuff.
You can also use a one-shot timer for it.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Go for the PostMessage approach. Post it at the end of OnInitDialog.
Forget the timer approach. PostMessage is the correct way to do this.
|
|
|
|
|
pierre_ribery wrote: Forget the timer approach. PostMessage is the correct way to do this.
Why?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Because you are not guaranteed that the WM_TIMER message will be handled. THe dialog might be closed before the timer elapses (lets say 200-300ms). If you post a user defined message in OnInitDialog you are guaranteed that it will be handled before any messages sent after this! the timer might be invoked too late.
From MSDN: The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.
also, you have to remember to kill the timer as the first thing in the WM_TIMER handler.
Another point is that it uses significantly more system resources to simply post a message. Why create a timer which will post a message, when you can directly post the message? Timers are limited system resources.
Might be more reasons, but it boils down to what is the best approach. The timer approach is a possibility, but not the BEST.
|
|
|
|
|
pierre_ribery wrote: THe dialog might be closed before the timer elapses (lets say 200-300ms).
Provided you know such a feature it may be not a problem.
pierre_ribery wrote: also, you have to remember to kill the timer as the first thing in the WM_TIMER handler.
Of course. one-shot has to be one-shot, after all!
pierre_ribery wrote: The timer approach is a possibility, but not the BEST
pierre_ribery wrote: rom MSDN: The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.
To both points applies: Provided you've to immediatly execute code.
pierre_ribery wrote: Another point is that it uses significantly more system resources to simply post a message. Why create a timer which will post a message, when you can directly post the message? Timers are limited system resources.
Oh, there are two possibilities here:
(1) You already have such a timer (for different purposes) and you're just using its first call (in such a case, no performance loss).
(2) You haven't such a timer and hence make a one-shot timer that is a low resource waster.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
modified on Monday, December 17, 2007 5:11:51 AM
|
|
|
|