Hi,
Its a doubt.
Changing parts of the kernel means complete recompilation in Linux OS. So whenever we developed a new driver,we need to recompile kernel or we can add or remove at runtime(mudules).
I did not get any information what happend in windows os(xp)? How do we attach our kernel mode driver to windows kerenl? What actually happends while installing a driver in windows? We are not doing any recompilation in windows os.
A kernel driver in Windows is a dynamic link library (DLL). The kernel
when loading the driver resolves the external symbols the driver uses
the way any user space DLL or application does. The kernel then calls
DriverEntry as the known entry point of the driver just as a DLL is
called. Note: this is a simplified description and so you may get more
details, but the basics here are what you asked for. Most OS’es were
working on making drivers dynamically loaded before Linux was ever
started.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@nestgroup.net” wrote in message
news:xxxxx@ntdev:
> Hi,
> Its a doubt.
> Changing parts of the kernel means complete recompilation in Linux OS. So whenever we developed a new driver,we need to recompile kernel or we can add or remove at runtime(mudules).
> I did not get any information what happend in windows os(xp)? How do we attach our kernel mode driver to windows kerenl? What actually happends while installing a driver in windows? We are not doing any recompilation in windows os.
Linux has dynamically loadable drivers too. Windows drivers are essentially
kernel dlls and are loaded into the kernel as needed much as a user mode dll
can be loaded into an app as needed. DriverEntry is the standard
initialization routine for kernel drivers.
Mark Roddy
On Wed, Sep 15, 2010 at 3:03 AM, wrote:
> Hi,
> Its a doubt.
> Changing parts of the kernel means complete recompilation in Linux OS. So
> whenever we developed a new driver,we need to recompile kernel or we can add
> or remove at runtime(mudules).
> I did not get any information what happend in windows os(xp)? How do we
> attach our kernel mode driver to windows kerenl? What actually happends
> while installing a driver in windows? We are not doing any recompilation in
> windows os.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
On Wed, Sep 15, 2010 at 2:35 PM, Don Burn wrote:
> A kernel driver in Windows is a dynamic link library (DLL). The kernel when
> loading the driver resolves the external symbols the driver uses the way any
> user space DLL or application does. The kernel then calls DriverEntry as
> the known entry point of the driver just as a DLL is called
I must add that Linux (and every current mainstream OS for that
matter) handles this exactly the same way, therefore I don’t really
understand OPs `confusion’. In Linux you have the option to compile
the module statically in the kernel, in Windows you can’t because you
don’t have the kernel source, though surely it’s technically possible,
for example hal.dll contains multiple drivers.
–
Aram Hăvărneanu
Thanks for all…
Not to try to pick on a point of detail:
(a) No, it’s not… ALL drivers in Windows are dynamically loadable. It is NOT technically possible to build statically linked drivers in Windows.
(b) No, it doesn’t. HAL.DLL does not contain any drivers whatsoever.
There’s no mechanism in Windows that will build the necessary data structures to support drivers that are not loaded dynamically.
I ask folks to PLEASE be careful about making unsupported assertions, even if only for the archives. If you’re GUESSING, or making a supposition, please make that abundantly clear so as not to mislead somebody who’s desperately searching for an answer using Google late at night a year from now who happens to find your post.
Peter
OSR
Not necessarily. The drivers that are part of kernel initialization are linked in with Linux kernel ( This is a normal thing for most OS ). The rests ( a very large part ) are modules. You load them on the fly…
Here in Windows same story. There are a multiple ways to load a driver. Need to look more on DDK docs…
-pro
On Sep 15, 2010, at 12:03 AM, xxxxx@nestgroup.net wrote:
Hi,
Its a doubt.
Changing parts of the kernel means complete recompilation in Linux OS. So whenever we developed a new driver,we need to recompile kernel or we can add or remove at runtime(mudules).
I did not get any information what happend in windows os(xp)? How do we attach our kernel mode driver to windows kerenl? What actually happends while installing a driver in windows? We are not doing any recompilation in windows os.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
xxxxx@nestgroup.net wrote:
Changing parts of the kernel means complete recompilation in Linux OS. So whenever we developed a new driver,we need to recompile kernel or we can add or remove at runtime(mudules).
At the risk of starting another pointless debate, this is one of the
things that Windows has ALWAYS done better than Linux. Loading a kernel
module in Linux is more like an incremental static link than it is like
loading a DLL. Plus, IN MY EXPERIENCE, it is darned near impossible to
create a Linux kernel module binary that runs in more than one version
of the kernel. Part of that is philosophical, of course; you are
supposed to want to start from source – distributing binaries is evil.
However, I have Windows video capture drivers where the unmodified
binary will load and run all the way from Windows 98SE through Windows
7. That’s a heck of an accomplishment.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I would rather replace the term “accomplishment” with “liability” - in order to make it work this way MSFT has to maintain kernel interfaces dating back to the very first version of NT…
Anton Bassov
Yes… “Asset” or “liability”??
What you see is a function of where you sit. I’d say:
Customer: Asset. Potentially BIG asset.
Driver Dev: Asset AND Liability.
OS Vendor: Liability.
I can tell you from experience that the Windows core devs are *very* hesitant to do *anything* that might break existing code in the field unintentionally. They are *very* careful around legacy interfaces. It took more than 10 years to get some legacy #define’s removed from NTDDK.H that actually pre-dated the BETA release of NT V3.1.
That’s just part of the burden they bear. And that sort of compatibility is one of the major assets to the Windows platform for users.
Peter
OSR
> I can tell you from experience that the Windows core devs are *very* hesitant to do *anything*
that might break existing code in the field unintentionally. They are *very* careful around legacy interfaces.
It took more than 10 years to get some legacy #define’s removed from NTDDK.H that actually
pre-dated the BETA release of NT V3.1.
Actually, I was speaking about “liability” in terms of innovations/modifications/fixes, so that you just seem
to confirm my words. Indeed, MSFT kernel guys are just stuck with the system designed 20 years ago, with the features that make no sense whatsoever these days (although they did make sense at the time the OS got designed - pageable kernel code is the very first example that gets into my head), and with all architectural fallacies like lack of VFS and caching on per-file basis that they just cannot fix without breaking numerous drivers…
And that sort of compatibility is one of the major assets to the Windows platform for users.
Well, you seem to have a wonderful sense of humor, Peter…
What kind of “compatibility” can one speak about if the machine refuses to work with anything (MSFT-produced, of course), apart from OEM OS version, because MSFT had provided OEM with Windows source code and allowed them to modify it in a way that makes it incompatible with anything else, including RTM Windows versions??? What kind of “compatibility” can one speak about if you are unable to use a given piece of hardware on your 64-bit OS version, because, as a result of MSFT driver-signing policy, device vendor provides only 32-bit drivers for it at the moment??? If you search NTDEV archives you will see that the above problems are… ugh, "not-so-uncommon in Winuser’s world "…
Anton Bassov
Anton:
Do you really think that OEM build their own Windows bits? How do they sign them? They don’t even build drivers for the third party chips. IHVs do that.
Lack of 64 bit signed drivers is completely IHV fault. Time to dump ghetto vendors.
Looks like a good candidate to go to NTTALK !!!
But I don’t know for sure, how much of the Windows kernel can be made non-pageable using kernel configuration parameter, or even better it would adjust to the current real memory of the machine. But would be an interesting thing to know.
-pro
On Sep 15, 2010, at 5:37 PM, xxxxx@hotmail.com wrote:
> I can tell you from experience that the Windows core devs are *very* hesitant to do *anything*
> that might break existing code in the field unintentionally. They are *very* careful around legacy interfaces.
> It took more than 10 years to get some legacy #define’s removed from NTDDK.H that actually
> pre-dated the BETA release of NT V3.1.Actually, I was speaking about “liability” in terms of innovations/modifications/fixes, so that you just seem
to confirm my words. Indeed, MSFT kernel guys are just stuck with the system designed 20 years ago, with the features that make no sense whatsoever these days (although they did make sense at the time the OS got designed - pageable kernel code is the very first example that gets into my head), and with all architectural fallacies like lack of VFS and caching on per-file basis that they just cannot fix without breaking numerous drivers…> And that sort of compatibility is one of the major assets to the Windows platform for users.
Well, you seem to have a wonderful sense of humor, Peter…
What kind of “compatibility” can one speak about if the machine refuses to work with anything (MSFT-produced, of course), apart from OEM OS version, because MSFT had provided OEM with Windows source code and allowed them to modify it in a way that makes it incompatible with anything else, including RTM Windows versions??? What kind of “compatibility” can one speak about if you are unable to use a given piece of hardware on your 64-bit OS version, because, as a result of MSFT driver-signing policy, device vendor provides only 32-bit drivers for it at the moment??? If you search NTDEV archives you will see that the above problems are… ugh, "not-so-uncommon in Winuser’s world "…
Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> Do you really think that OEM build their own Windows bits?
Assuming they are given sources and a license to build them, why not…
Anyway, this is a good question. For example, if I am unable to partition a disk on OEM machine during
the original setup (let’s say I want to have multi-boot machine) just because no one asks me a SINGLE question throughout the whole process, should I be blaming OEM or MSFT for this???
Time to dump ghetto vendors.
…or, probably, " junk OS providers" - it seems even better option, at least to me…
Anton Bassov
Oems do not build their own copy of windows. A multi boot machine is a tiny, tiny, tiny segment of the market BTW.
d
dent from a phpne with no keynoard
-----Original Message-----
From: xxxxx@hotmail.com
Sent: September 15, 2010 8:02 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How driver attach to kernel in windows os?
> Do you really think that OEM build their own Windows bits?
Assuming they are given sources and a license to build them, why not…
Anyway, this is a good question. For example, if I am unable to partition a disk on OEM machine during
the original setup (let’s say I want to have multi-boot machine) just because no one asks me a SINGLE question throughout the whole process, should I be blaming OEM or MSFT for this???
> Time to dump ghetto vendors.
…or, probably, " junk OS providers" - it seems even better option, at least to me…
Anton Bassov
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> Looks like a good candidate to go to NTTALK !!!
In fact, I think this is where it belongs right from the original post anyway…
If someone wants to say something more on this topic PLEASE let’s move it to NTTALK, rather than polluting NTDEV with the off-topic issue - otherwise Peter will turn up with the long whip…
Anton Bassov
Doron,
Oems do not build their own copy of windows. A multi boot machine is a tiny, tiny, tiny segment
of the market BTW.
I replied on NTTALK to the above, so that we can discuss it there is you want…
Anton Bassov
I do am not a member of nttalk, sorry
d
dent from a phpne with no keynoard
-----Original Message-----
From: xxxxx@hotmail.com
Sent: September 15, 2010 8:32 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How driver attach to kernel in windows os?
Doron,
> Oems do not build their own copy of windows. A multi boot machine is a tiny, tiny, tiny segment
> of the market BTW.
I replied on NTTALK to the above, so that we can discuss it there is you want…
Anton Bassov
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
DisablePagingExecutive=1 will make the kernel and all drivers non-pageable.
On systems with more than 2 GB of RAM the kernel and the HAL are mapped with large pages, which effectively makes them non-pageable.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Wednesday, September 15, 2010 8:01 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How driver attach to kernel in windows os?
<…>
But I don’t know for sure, how much of the Windows kernel can be made non-pageable using kernel configuration parameter, or even better it would adjust to the current real memory of the machine. But would be an interesting thing to know.
Ha ha, I’ve to rub Anton’s nose 
-pro
On Sep 15, 2010, at 9:26 PM, Pavel Lebedynskiy wrote:
DisablePagingExecutive=1 will make the kernel and all drivers non-pageable.
On systems with more than 2 GB of RAM the kernel and the HAL are mapped with large pages, which effectively makes them non-pageable.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Wednesday, September 15, 2010 8:01 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How driver attach to kernel in windows os?<…>
But I don’t know for sure, how much of the Windows kernel can be made non-pageable using kernel configuration parameter, or even better it would adjust to the current real memory of the machine. But would be an interesting thing to know.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer