|
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....
|
|
|
|
|
Aha! You didn't say you were working on Windows CE!
SetKMode isn't a good idea, was never officially documented for use by application developers, and was removed in CE 6.0. However, on platforms where it is implemented, it does indeed flip into kernel mode (through a software interrupt, I imagine) and continue running that thread.
I've been a CE developer for six years and never needed SetKMode.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Its Windows XP If so how do get into Kernal Mode is it my writting a device driver a app with a .sys extension
|
|
|
|
|
|
|
Hi
I have a belkin wireless modem / router. It has four wired ports which are all in use. Is it possible to add a 8 port hub to this? I know less than nothing about network hardware and googling is just throwing up new wireless modems.
I am running one of the wires from the hub into the loft and back down into the lads bedroom. I want to, ideally, plug that into another hub in the loft, so I can then run 8 more devices from it. (actually 7 more, as I still need to connect the lads machine up).
Is this as easy as just buying a hub?
The wireless access in the house is rubbish, as the study is at one end of the house, the house is old and all walls are either 9" or 4" solid.
Cheers
Malcolm
We violated nature and our children have to pay the penalty
Don't go near the water children... Johnny Cash - 1974
|
|
|
|
|
Using a hub in such a sense should work fine.
However using a switch would be better.
A hub sends alla data going through it to all other computers/devices while a switch sends the data to the corresponding computer/device.
Switches are therefore faster (under larger amounts of load) and more secure. I would never use a hub today.
You can connect multiple switches/hubs after each other (series) or besides each other (parallel) depending on where you want the new ports.
//Johannes
|
|
|
|
|
So, the router is in the study and three devices are attached to it? Plus one cable that now goes to another part of the house? And you want to add a hub in the middle? Should work ok, but might only offer limited network access. As someone already explained, a hub basically is a multi-port repeater. What goes in on one port comes out on all other ports. This also means that a hub will only run with the lowest common denominator of all devices in the network. If there is an IP-TV box, that MIGHT mean 10 Mbit / Half Duplex.
A switch, however, is a multiport bridge, meaning that it at least does basic OSI/ISO layer 2 routing and mixing. It will remember the port a device is attached to and send all packets addressed to a device to its specific port. A switch also has a backplane that offers seperate throughput for all ports, meaning that port 1 can talk to port 3 with gigabit connectivity, while ports 2 and 4 get data at 100 MBit/s delivered from a gigabit link on port 5... etc.
If you think that several of the devices attached on the breakout switch might be used at once, it might be no bad idea to set them to a bitrate one level slower that the uplink to your router (e.g. router<->switch: Gbit, switch<->devices: 100Mbit).
Oh, and you usually will only have six additional ports available. You will probably need one port to act as an uplink to your router.
Cheers,
Sebastian
--
"If it was two men, the non-driver would have challenged the driver to simply crash through the gates. The macho image thing, you know." - Marc Clifton
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
