|
I have been looking for a way in C++ to read the raw output levels sent to the DAC on a sound card for some time now. It would seem the only way to do this for Win2000 (and beyond) is to somehow access the kernel mixer and read the output. I know that I can't forcefully access the kernel space from a user-level application, but is there some entry point to query this information? I do not have too much experience in programming kernel processes, and I cannot find any clarification of KMixer.sys (other than people complaining about sound issues), but any explanation as to the functions that would do this in C++, the proper direction to take, or even suggestions for education on this topic or overall theory would be greatly appreciated!
modified on Saturday, February 9, 2008 9:38 PM
|
|
|
|
|
I found this over at OSR Online:
KMixer Driver Sample Rate Conversion and Mixing Policy[^]
The subject of Windows Audio Driver technology is amazingly complicated. If I were attempting to do what you suggested, I would be thinking along the lines of writing a kernel mode driver to intercept the data from the device driver stack. This is not simple or easy.
Even experienced driver writers find the subject challenging. And, as far as I know there are no books on the subject.
Probably OSR Online is your best starting point,...I have actually seen a couple of threads on the subject in the development forums. But, if you've never written a driver, I suggest that you plan carefully, driver development is difficult. Blue Screens of Death predominate.
I also found this blog by Larry Osterman[^] to be informative. He contrasts the audio stack on Windows XP and previous with Vista; there are significant design differences.
By the way, to answer your original question: there is an entry point for the kernel driver, but, it is not accessible from user mode. It is called by the Operating System kernel when the driver is first loaded.
modified on Monday, February 25, 2008 7:26 PM
|
|
|
|
|
Hii.. I am doing kernel level debugging through windbg. how can i attach windbg to DWM.EXE process in VISTA which is responsible for AERO feature.
thanx
prashant
|
|
|
|
|
prashantjain wrote: I am doing kernel level debugging through windbg. how can i attach windbg to DWM.EXE process in VISTA which is responsible for AERO feature.
thanx
How do you expect to debug user mode code when you are hooked up to the Kernel?
Run WinDbg ON the target and do File->Attch to Process.
Morality is indistinguishable from social proscription
|
|
|
|
|
I'm new for networking programing and i wanna know that how to write a java program for mesure to ping delay for particular site
Ex-: If we ping in command promt www.googe.com how to write a program for mesure ping delay??
CheeN
|
|
|
|
|
sacr83 wrote: how to write a java program for mesure to ping delay for particular site
Wrong website and forum 
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
Hi All,
I am trying to develop desktop sharing application like VNC .
In VNC there is use of hooks to capture changes. I want to know that is there any way to get screen updates other than hooks?
i thought of video hood driver but i am new to driver development.
can anyone tell me that from where i should start?
Ravi.
|
|
|
|
|
I have been reading a Book on Windows internals where it mentions being in Kernal mode vs User mode
My question is why would I want to be in Kernal Mode are thier certin Windows API's that can execute only Kernel mode or is thier certian areas of storage (system storage) they can be accessed modfied in Kernal Mode
Thankx
|
|
|
|
|
ForNow wrote: My question is why would I want to be in Kernal Mode
The only ones who want to be in Kernel mode are device drivers. "Kernel mode" refers to the priviledged mode that drivers and the guts of the OS operate in. "User mode" refers to applications and is a restricted mode of operation. User mode cannot directly manipulate the hardware of the system - all calls must go through the OS via the appropriate API call and the OS will route the request to the appropriate hardware driver to perform the requested action.
If you're familiar with Intel processors, it's the difference between ring 0 (kernel) and ring 3 (user).
Judy
|
|
|
|
|
Besides Hardware IS there a area of Storage or Certain Windows Api which Kernal Mode progs can Manipulate while user Mode cann't
|
|
|
|
|
ForNow wrote: Besides Hardware IS there a area of Storage or Certain Windows Api which Kernal Mode progs can Manipulate while user Mode cann't
I'm not sure I understand...
Storage is hardware, so directly manipulating the storage stack is prohibited from user mode. If by Windows API you mean the WIN32 API, that is user-mode only. There is a whole other API, described in the DDK (or whatever MS is calling it this month), that is used only by kernel-mode.
Judy
|
|
|
|
|
By Storage I meant certian storage Like OS control Blocks Maybe common storage outside of a applications Address Space
I am thinking maybe you have to be In Kernel Mode to manipulate those aress
I guess I am used to thinking like a Mainframer were in order to Manipulate Common Stoarge you have to do a modeset to get into supervisor state
Thankx
|
|
|
|
|
Ah, now I understand....
Yes, those things are only available from kernel-mode. Windows goes to great pains to prevent user-mode code from touching anything outside its own process space. Unlike your mainframe case, a user mode program cannot explicitly switch itself to kernel mode. The switches occur automagically within the OS when the user-mode program calls an API that needs to access a kernel-mode component.
Judy
|
|
|
|
|
thankx on the MainFrame the prog has to be in Apf Authorized Library to issue the Modeset to be supervisor state
So a User Mode prog cann't issue the SetKmode api maybe only a deviceDriver a exe with .sys extension
|
|
|
|
|
ForNow wrote: So a User Mode prog cann't issue the SetKmode api maybe only a deviceDriver a exe with .sys extension
Ah, that's where you're coming from. SetKMode is specific to Windows CE. CE has a totally different scheme of kernel versus user when compared to "normal" desktop Windows. The line between the two is much less firm. CE's concept of a driver is much less strict than desktop Windows. A driver on CE is basically a DLL that has some special entry points and that the CE OS loads and runs as a driver, in kernel mode. Unlike desktop Windows drivers, CE drivers can access what would normally be considered user-mode APIs. Something else that is unique to CE is that, depending on how the CE image is created, a user program may be able to switch to kernel mode using SetKMode. That "user commanded switch to kernel" capability is impossible on desktop Windows.
Any statement about how something works on CE and its derivatives usually does not apply to desktop Windows - the two OSes have completely different concepts of how firm the division is between user and kernel mode. The two OSes are targeted for very different uses.
Judy
|
|
|
|
|
JudyL_FL wrote: A driver on CE is basically a DLL that has some special entry points and that the CE OS loads and runs as a driver, in kernel mode.
Actually they run in user mode (on CE 5.0 and earlier). Drivers can use the VirtualCopy API to map physical addresses into their virtual address space. I'm not sure how I/O space is handled, but only x86 processors implement that - everything else uses memory-mapped I/O. CE 5.0 really has a faithful implementation of the microkernel model - scheduling and memory management are handled in the kernel, but everything else, including file systems (FILESYS.EXE) and drivers (DEVICE.EXE), not to mention GDI and windowing (GWES.EXE) happens in user mode. They came up with a very cheap inter-process call model which works with the memory model - your thread actually migrates into the called process (effectively) to perform the call.
CE 5.0 has really hit the buffers in terms of virtual address space per process, though. 32MB per process just isn't enough, particularly when the device has 64MB or 128MB of RAM, and a 32 process cap is also quite small (in practice fewer than 30 as the first few slots are used by filesys, device, gwes etc). Windows Mobile particularly sucks up all of slot 1 for eXecute-In-Place DLLs and overflows into slot 0, on one device leaving about 12MB of virtual address space per process. That isn't fun when the device driver thread stacks in device.exe occupy the rest of the virtual address space for the process and you can't load any more drivers because there's no VA space left.
CE 6.0 has a new macrokernel which moves some device, file system and GWES code into kernel mode, and reverts to the desktop-style overlapping 2GB virtual address space model. SetKMode has been removed from CE 6.0.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
I never really worried about kernel versus user when doing my drivers and services / GUIs for CE. It all always seemed to be the same  . I never found anything that didn't work in the "mode" I was, either from the driver or from the service or GUI that called the driver, so I stopped worrying about it. I last used CE 3, so I'm not up-to-date on the newer releases.
Judy
|
|
|
|
|
IS there any of getting in Kernal Mode in XP or a Device Driver with a .sys extension automatically gets control
in Kernal Mode (maybe like a PC rtn or a SVC on a MainFrame)
|
|
|
|
|
for XP:
A user mode program can't directly get into kernel mode - the OS prevents all attempts to execute code or access memory outside the program's assigned process space or touch hardware. A driver runs in kernel mode by the simple fact of being a driver, recognized as such and loaded by the OS. Note that there are software-only drivers - a driver that does not control hardware.
Judy
|
|
|
|
|
Thnankx
I understand ...
On the MainFrame a PC or SVC rtn can automatically be invoked in Supervisor state
Just trying to relate the concepts
Thankx
|
|
|
|
|
ForNow wrote: why would I want to be in Kernal Mode
If you were writing device drivers, or any code that needs to access hardware directly.
Morality is indistinguishable from social proscription
|
|
|
|
|
...and going forward not even all of that. I read that Vista had sound drivers yanked out of kernal mode so that Creative could no longer BSOD the OS with their badly written soundbastard drivers. I'm not sure if they pulled anything else out or not at the same time.
Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop.
-- Matthew Faithfull
|
|
|
|
|
Yep, Vista brings WDF, user mode drivers, but the transitions from uer to kernel are expensive. But it will be more stable.
However, for real drivers (like MINE : ), its the kernel!
dan neely wrote: They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop.
Have to say, Ubuntu is really quite nice. Good UI, good updating, stable, it realy does just work. And it ships with a WoPro and spread sheet.
Morality is indistinguishable from social proscription
|
|
|
|
|
It's instructive to compare modern Windows to DOS. In classic DOS, a program could write to any address in the system, potentially overwriting operating system data structures. It could also control any I/O device in the system. Very powerful, but also very dangerous as any program could crash the system or corrupt data. It also made sharing of I/O devices between programs pretty difficult.
This problem had been recognized previously in the mainframe and minicomputer worlds, and hardware had been added to add modes, typically called 'user mode' and 'supervisor mode', with certain instructions reserved for supervisor mode and the ability to protect regions of memory and I/O devices so that only code running in supervisor mode can read from or write to them. User mode - application code - can only then perform these tasks indirectly by requesting that the supervisor (or kernel) carry out the task for it. If it tries to perform such an operation, the CPU instead raises a fault (or exception) to the supervisor; the supervisor can then do whatever is required to fix the fault, or terminate the program.
The processor boots up in kernel mode, then when running a program it runs it in user mode. On x86 this is done by changing a couple of bits in one of the registers, but only supervisor mode code can change that. To get back into supervisor mode, you used to have to issue a software interrupt but in recent processors, the SYSENTER instruction was added. Hardware interrupts also put the processor into supervisor mode, with a return-from-interrupt instruction putting it back into user mode if the processor was running user-mode code when the interrupt occurred.
Generally operating systems try to keep as little code as possible in kernel mode, as the opportunity for this code to do damage is great. User-mode code should only be able to crash the process, not crash the whole system. Where the kernel only has responsibility for memory allocation and thread scheduling, with I/O performed by user-mode processes, this is typically called a microkernel. Windows Explorer and Internet Explorer are both user-mode processes.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Thankx My only then is can a User Mode program issue the SetKmode api....
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
