xxxxx@45mercystreet.com wrote:
And I may have an answer; the _Interlocked*() instrinsics are, well,
intrinsics, e.g. the compiler knows about them. Which means the user-
mode docs for those instrinsics are all valid for the kernel, in which
case the user-mode abstraction I already have also works for the kernel.Will try it out in a bit.
And it works and we’re all fine and ported to the Windows kernel.
Thankyou all for listening =-)
“Toby Douglass” wrote in message
news:xxxxx@ntdev…
> xxxxx@45mercystreet.com wrote:
>> And I may have an answer; the _Interlocked*() instrinsics are, well,
>> intrinsics, e.g. the compiler knows about them. Which means the user-
>> mode docs for those instrinsics are all valid for the kernel, in which
>> case the user-mode abstraction I already have also works for the kernel.
>>
>> Will try it out in a bit.
>
> And it works and we’re all fine and ported to the Windows kernel.
>
> Thankyou all for listening =-)
>
Yep. AFAIK it isn’t documented anywhere, but the WDK compilers are
very close to the Visual C compilers, and share same intrinsics,
features and bugs, well covered in MSDN:
The compiler in WDK 600x is similar to VS 2005
The compiler in WDK 700x is similar to VS 2008 SP1.
Regards,
–pa
xxxxx@fastmail.fm wrote:
“Toby Douglass” wrote in message
> news:xxxxx@ntdev…
> > Thankyou all for listening =-)
> Yep. AFAIK it isn’t documented anywhere, but the WDK compilers are
> very close to the Visual C compilers, and share same intrinsics,
> features and bugs, well covered in MSDN:
>
> The compiler in WDK 600x is similar to VS 2005
> The compiler in WDK 700x is similar to VS 2008 SP1.
Indeed - I realised when I saw that the abstraction layer for user-mode
Windows was being picked up. It meant _MSC_VER was being asserted by
the compiler!
Is there a usual compiler set define which is used to know we’re
compiling for the kernel? I’ve used NTDDI_VERSION.
> WDK compilers are very close to the Visual C compilers,
Well, Visual C compiler can actually even generate a driver binary, although it will require an awful lot of modifications in project settings ( and in-depth expertize to do it right). Although I never did it myself I remember seeing a VC6 workspace where driver was a target output- its projects setting looked totally different from the one “regular” workspace where UM component is a target output…
Anton Bassov
> Well, Visual C compiler can actually even generate a driver binary, although it will require an awful lot
It is doable but unsupported. So, if one will have some hard-to-fix issue with the driver, no one of forums will help till he/she will move to BUILD.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Yeah, in your SOURCES file you add an explicit CDEFINES relevant to *your*
project that says you are compiling for the *your* NT kernel environment.
Maybe something like -DTOBYSLIB_NT_KERNEL
Why would you leave something like that to something outside your control?
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Toby Douglass
Sent: Sunday, October 04, 2009 4:43 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] atomic 64 bit add / atomic 128 bit CAS support?
(addendum 3)
xxxxx@fastmail.fm wrote:
“Toby Douglass” wrote in message
> news:xxxxx@ntdev…
> > Thankyou all for listening =-)
> Yep. AFAIK it isn’t documented anywhere, but the WDK compilers are
> very close to the Visual C compilers, and share same intrinsics,
> features and bugs, well covered in MSDN:
>
> The compiler in WDK 600x is similar to VS 2005
> The compiler in WDK 700x is similar to VS 2008 SP1.
Indeed - I realised when I saw that the abstraction layer for user-mode
Windows was being picked up. It meant _MSC_VER was being asserted by
the compiler!
Is there a usual compiler set define which is used to know we’re
compiling for the kernel? I’ve used NTDDI_VERSION.
—
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
xxxxx@msn.com wrote:
Yeah, in your SOURCES file you add an explicit CDEFINES relevant to
*your*
project that says you are compiling for the *your* NT kernel environment.Maybe something like -DTOBYSLIB_NT_KERNEL
Why would you leave something like that to something outside your control?
I think you can trust things like _WIN32 and _WIN64. If there is a
compiler asserted defined of similar status indicating a kernel build,
I’d be satisfied to use it.
Also, using something standard like that is easier for other people
reading the code. They know (or can/should know) about _WIN32. Having
your own define is another unique thing about your particular build the
reader has to learn.
xxxxx@msn.com wrote:
Yeah, in your SOURCES file you add an explicit CDEFINES relevant to
*your*
project that says you are compiling for the *your* NT kernel environment.Maybe something like -DTOBYSLIB_NT_KERNEL
Why would you leave something like that to something outside your control?
Turns out NTDDI_VERSION is set by windows.h when you include it, so it’s
not useful to me for differentiating between user-mode and kernel-mode
building - and I can’t find any other variable.
So I do have to define my own.
IMHO, the compiler should by assert defines make it clear to the code
what platform is in use. It minimizes complexity and puts it into the
compiler rather than requiring it to independently exist in everyone’s
code. Bah, humbug.
> I think you can trust things like _WIN32 and _WIN64.
…especially if you are able to give a definition of _WIN64, taking into account that x86_64 and IA64 are totally different target architectures that require separate builds…
Anton Bassov
No, that is not how things are architected.
The compiler neither knows nor cares that you are writing kernel mode code. (In fact, the same binary could even be loaded by both user mode and kernel mode callers – but this is typically rare and restricted to resource dlls only in practical use, as, of course, the operating environment in terms of available APIs is different.)
The same compiler is used if you build a user mode module with the WDK as is used to build a kernel driver.
The executable formats are, for NT, identical for user vs kernel mode.
This is a build environment thing, really.
-----Original Message-----
From: Toby Douglass
Sent: Sunday, October 04, 2009 11:24
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] atomic 64 bit add / atomic 128 bit CAS support? (addendum 3)
xxxxx@msn.com wrote:
> Yeah, in your SOURCES file you add an explicit CDEFINES relevant to
your
> project that says you are compiling for the your NT kernel environment.
>
> Maybe something like -DTOBYSLIB_NT_KERNEL
>
> Why would you leave something like that to something outside your control?
Turns out NTDDI_VERSION is set by windows.h when you include it, so it’s
not useful to me for differentiating between user-mode and kernel-mode
building - and I can’t find any other variable.
So I do have to define my own.
IMHO, the compiler should by assert defines make it clear to the code
what platform is in use. It minimizes complexity and puts it into the
compiler rather than requiring it to independently exist in everyone’s
code. Bah, humbug.
—
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
For the OP’s benefit, the compiler does define some predefined macros based on whether it’s targetted at amd64/ia64/i386.
MSDN has a nice page listing all of these IIRC.
-----Original Message-----
From: xxxxx@hotmail.com
Sent: Sunday, October 04, 2009 11:49
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Re: atomic 64 bit add / atomic 128 bit CAS support? (addendum 3)
> I think you can trust things like _WIN32 and _WIN64.
…especially if you are able to give a definition of _WIN64, taking into account that x86_64 and IA64 are totally different target architectures that require separate builds…
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
Well you see, the WDK build facility can build *many* target types including
kernel mode and user mode code. Only you know (especially when building a
static library) what target (or targets) make sense. It cannot, should not,
and does not make some blanket guess as to what you mean to be doing.
So ruminate all you want and espouse YHO - in the end, WDK BUILD works as
WDK BUILD does and you either can learn to use it or not.
There *IS NOT* a standard define to indicate kernel mode (or user mode) in
general for a static library so define your own if it matters.
Good Luck,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Toby Douglass
Sent: Sunday, October 04, 2009 2:24 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] atomic 64 bit add / atomic 128 bit CAS support?
(addendum 3)
xxxxx@msn.com wrote:
Yeah, in your SOURCES file you add an explicit CDEFINES relevant to
*your*
project that says you are compiling for the *your* NT kernel environment.Maybe something like -DTOBYSLIB_NT_KERNEL
Why would you leave something like that to something outside your control?
Turns out NTDDI_VERSION is set by windows.h when you include it, so it’s
not useful to me for differentiating between user-mode and kernel-mode
building - and I can’t find any other variable.
So I do have to define my own.
IMHO, the compiler should by assert defines make it clear to the code
what platform is in use. It minimizes complexity and puts it into the
compiler rather than requiring it to independently exist in everyone’s
code. Bah, humbug.
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
xxxxx@hotmail.com wrote:
> I think you can trust things like _WIN32 and _WIN64.
…especially if you are able to give a definition of _WIN64, taking into account that x86_64 and IA64 are totally different target architectures that require separate builds…
There are CPU-indicating defines asserted by the compiler.
I’ve found I can tell my platform, barring user-mode or kernel-mode,
from the compiler asserted defines.
xxxxx@valhallalegends.com wrote:
The compiler neither knows nor cares that you are writing kernel mode
code.
Similarly, though, the compiler neither knows nor cares I am writing for
_WIN32 or _WIN64. Nevertheless, the compiler asserts a define for me.
This is a build environment thing, really.
Yes.
xxxxx@valhallalegends.com wrote:
For the OP’s benefit, the compiler does define some predefined macros
based on whether it’s targetted at amd64/ia64/i386.
Thankyou for thinking to mention them - I know about them and I use
them.
xxxxx@msn.com wrote:
Well you see, the WDK build facility can build *many* target types
including
kernel mode and user mode code. Only you know (especially when building a
static library) what target (or targets) make sense. It cannot, should not,
and does not make some blanket guess as to what you mean to be doing.
It seems to me what I specify to TARGETTYPE unequivocably indicates what
I’m building.
Yes, it specifies it to MAKEFILE.NEW. It does not specify it to your code.
That is up to you.
Go read MAKEFILE.NEW. It is fascinatingly educational. The distinction
between LIBRARY and DRIVER_LIBRARY is what you are somehow expecting ‘help’
from. The distinction is really quite small. Indeed, 1/3 of the way
through the file, MAKEFILE.NEW just morfs TARGETTYPE of DRIVER_LIBRARY into
TARGETTYPE of LIBRARY. About the only thing that it did beforehand was to
add the DDK includes and set CBSTRING=-cbstring (for reasons I don’t care to
go figure out).
Nowhere along the way does it make the decision for you that the code is
targeted for UM or KM.
Taken to an even further extreme, the ‘little cousin’ OS Windows CE actually
runs drivers in UM. Here there are driver build environments like NDIS that
build just like KM code yet are actually UM.
You are tilting at windmills here (or, maybe I am by having the
converstation).
If you really hate typing, you can always use a SOURCES.INC (included to
your SOURCES file) that tests if you specified TARGETTYPE=DRIVER_LIBRARY or
TARGETTYPE=LIBRARY and adds a CDEFINES for you.
It’s not like it cannot be done (in fact, it is trivially easy). Your issue
seems to be that ‘somebody’ did not anticipate your expectation as being
higher priority and not do it your way. Oh well.
And as far as the size of the objects go - I suspect you will find that the
library has a rather full complement of FORCEINLINE functions embedded in
it. But then again, why would it matter as long as it links correctly.
Good Luck,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Toby Douglass
Sent: Sunday, October 04, 2009 4:31 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] atomic 64 bit add / atomic 128 bit CAS support?
(addendum 3)
xxxxx@msn.com wrote:
Well you see, the WDK build facility can build *many* target types
including
kernel mode and user mode code. Only you know (especially when building a
static library) what target (or targets) make sense. It cannot, should
not,
and does not make some blanket guess as to what you mean to be doing.
It seems to me what I specify to TARGETTYPE unequivocably indicates what
I’m building.
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
The compiler absolutely cares whether you are targetting 64-bit as this changes the pointer size, etc.
-----Original Message-----
From: Toby Douglass
Sent: Sunday, October 04, 2009 13:28
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] RE:atomic 64 bit add / atomic 128 bit CAS support? (addendum 3)
xxxxx@valhallalegends.com wrote:
> The compiler neither knows nor cares that you are writing kernel mode
> code.
Similarly, though, the compiler neither knows nor cares I am writing for
_WIN32 or _WIN64. Nevertheless, the compiler asserts a define for me.
> This is a build environment thing, really.
Yes.
—
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
xxxxx@valhallalegends.com wrote:
The compiler absolutely cares whether you are targetting 64-bit as
this changes the pointer size, etc.
Yes - the compiler does care about CPU type. But this is indicated by
the CPU type defines. However, thinking about what the docs say, really
_WIN64 is to be taken to mean “any 64-bit CPU”, so I was wrong in the
same way that _WIN64 is named, to claim the compiler doesn’t care about
it. TBH, I think it is misnamed, because it mixes up the fact it’s
Windows with the CPU word length.
xxxxx@msn.com wrote:
Yes, it specifies it to MAKEFILE.NEW. It does not specify it to your
code.
That is up to you.
Do you mean to imply that you can (and *reasonably* can, in terms of how
you would go about using the build system) specify you are building say
a kernel mode static library, and then go off and use that code in user-
mode?
Go read MAKEFILE.NEW. It is fascinatingly educational. The distinction
between LIBRARY and DRIVER_LIBRARY is what you are somehow expecting ‘help’
from.
Yes.
The distinction is really quite small. Indeed, 1/3 of the way
through the file, MAKEFILE.NEW just morfs TARGETTYPE of DRIVER_LIBRARY into
TARGETTYPE of LIBRARY. About the only thing that it did beforehand was to
add the DDK includes and set CBSTRING=-cbstring (for reasons I don’t care to
go figure out).
(Rhetorical question) So why does TARGETTYPE even *have* a difference
between the two?
I will look at MAKEFILE.NEW in the morning and see what I find.
Taken to an even further extreme, the ‘little cousin’ OS Windows CE
actually
runs drivers in UM. Here there are driver build environments like NDIS that
build just like KM code yet are actually UM.
What I am after is knowing which platform I am building on, for example
which set of header files I will be including. In that sense, the issue
isn’t an issue.
It’s not like it cannot be done (in fact, it is trivially easy). Your
issue
seems to be that ‘somebody’ did not anticipate your expectation as being
higher priority and not do it your way. Oh well.
No. You are projecting on to me.
I don’t have an issue, not in the way you think.
I think what is happening is wrong. I think this because it seems so to
me, by my standards of what I would expect a sane compiler to perform.
I may be wrong, but I get the impression you, ah, seem to picture me
here with a pout on my face having a little tantrum.
I have a USER_C_FLAGS and it works. Problem solved in an acceptable
manner. I still of course think what is happening is technically
incorrect.
And as far as the size of the objects go - I suspect you will find that the
library has a rather full complement of FORCEINLINE functions embedded in
it.
It has a few, yes. But why would these cause obesity in a kernel-mode
build and not in a user-mode build? the two builds are identical,
except that the abstraction function for aligned memory allocation in
the user-mode build is calling _aligned_malloc() and in the kernel-mode
build, ExAllocatePoolWithTag() (and similarly for the abstraction
function to free).
But then again, why would it matter as long as it links correctly.
It’s reasonable when noticing that kernel-mode object files are ten
times the size of user-mode, for identical code, to be concerned it
indicates a problem or mistake somewhere.
Right, eye-drops have dried, time for the second lot and back to bed 