Access to parallel ports from Win32

NTDEV
21

But why does the DDK compiler generate a reference to a system
function that is not provided with the DDK, and that is left
dangling after a perfectly valid build ? My point is this:
either that call should not be generated, or that function
should be provided in some library and linked in properly. But
if they generate a call to some implementation of __chkstk()
which they don’t provide, maybe I’m justified in calling it a
bug.

I’m not worried about that function being injected in the
checked build, but I will not be happy if I see it inserted in
the free build. I have a deep philosophical and personal issue
with this thing: it’s my code and if I find out I need stack
checking, I’ll put in my own, thank you!

I don’t want to allocate buffers from the pool for several
reasons. First, this is a portable driver and I want to keep
that part of it OS-independent, which means, no Windows-unique
code here. Second, I’m indeed performance critical, and this is
not quite the right place to waste time invoking OS APIs and
library functions that I do not know how they behave and how
much overhead they put in. Third, this code is very much used by
multiple boards and multiple chips, so, I have all the interest
to make it as short and sweet as I can, and as free from
side-effects as possible, and that includes making sure that
there’s few, or better, no calls to anything I didn’t write
myself or that I don’t control its source code.

The on-stack solution looks simple enough: just declare it as a
local array, and use it! The code is written in C and not in
C++, I inherited the driver, so, it takes a small but real
amount of code to do that kind of allocation even though I’d
rather be overriding my “new” operator and forgetting about
memory allocation issues altogether.

Alberto.

----- Original Message -----
From: “Peter Wieland”
To: “Windows System Software Devs Interest List”

Sent: Friday, September 16, 2005 3:22 AM
Subject: RE: Re:[ntdev] Access to parallel ports from Win32

Why would the linker magically generate code to fill in a
function
that’s not defined in the runtime library? Would you be happy
about
such code or would you be calling that a bug too?

Are you worried about the performance lost by a single function
call
being injected? Or are you explaining why you don’t want to
allocate
the buffers from pool? I can’t actually tell (perhaps it’s just
too
late)

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alberto
Moreira
Sent: Thursday, September 15, 2005 7:01 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Access to parallel ports from Win32

You know, I don’t know if I like the idea of the compiler
inserting
calls into my object code and the linker not filling them up.
Because
this is a checked build, I’m not sure I care about what kind of
code
they generate for me, as long as it works! But I believe that
if the
compiler includes a call to chkstk, the linker should fill it
up; and
I’m using the DDK compiler, mind you. So, to me at least this
looks like
a bug.

Anyway, I’ll use the pragma, because I can do that without
messing up
with batch and make files: I hate to do that kind of thing. This
buffer
is a staging area for setting up a stream of graphics rendering
commands
to my chip, and that stream can be rather longish; the
alternative is to
put it in the nonpaged pool, but why waste time allocating and
deallocating memory if I can do it otherwise ? Another
consideration is,
this is portable code, it must run just the same under Windows,
Linux
and Solaris, so, I can’t be too particular about API issues or I
end up
multiplying by three the number of lines of code I have to
write.

The other thing is, this is a very high performance environment,
which
uses a huge amount of memory, so, it can be quite tricky to
allocate and
use resources without bringing the whole machine to its knees!
The
driver is very carefully tuned to extract the maximum throughput
from
the chip and from the bus, and that’s the major consideration
here.
Trading performance for safety may not be a feasible strategy in
my
case! So, even if the checked build doesn’t like it, if it works
in the
production free build I’m happy with it. But meanwhile I have a
daily
build to satisfy and a QA manager that will be on my back in no
time if
I systematically break that build!

Alberto.

----- Original Message -----
From: “David J. Craig”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”

Sent: Thursday, September 15, 2005 12:13 PM
Subject: Re:[ntdev] Access to parallel ports from Win32

>A couple of people provided advice to suppress this behavior,
>but I disagree. Any local stack usage should be carefully
>examined and anything large should be a pointer on the stack
>that is allocated from either the paged or nonpaged pool. Try
>driver prefast and it will flag all allocations larger than 1KB
>and the utility permits this to be varied so it will report
>even smaller stack usage by a single function. I think
>anything about 256 bytes in a single function is probably
>excessive and a potential danger.
>
> You can’t use the __chkstk() function in drivers since it is
> not aware of the rules. It could be replaced by your own
> function that uses the correct stack limits and usage calls,
> but I prefer to just not cause a problem. Of course, this
> becomes far more critical in file system filters.
>
> “Alberto Moreira” wrote in message
> news:xxxxx@ntdev…
>> Hi, Guys,
>>
>> I’m having an annoying problem that’s simple enough that I
>> feel I should know the answer, yet it’s buried within the
>> structure of the Microsoft DDK toolset that I’m reluctant to
>> dig into. So I wonder if someone has some wisdom to share
>> with me ?
>>
>> The problem is this, whenever I have a structure on the stack
>> that’s larger than a certain size, the C compiler generates a
>> call to__chkstk() in my checked builds. That reference, for
>> this or that reason, is not satisfied by the linker. I want
>> to either suppress the generation of that code or to find
>> which library that function is defined; I’d prefer that the
>> compiler doesn’t generate that call to begin with.
>>
>> Do any of you know how to do it ? Tks,
>>
>>
>> Alberto.
>>
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com

22

In the user space, I’ve noticed that free build does not have the stack
checking. Not sure if the free build of krnl-mode stuff would include
this. But I’m almost sure it does not include this in free build !

Probably there are many different ways to tackle this allocations - and if
some one can predict a general pattern of accesses - one can come up with
stunning custom implementations to squeez the performance out.

On the otherhand, when we try to solve a general class of the problem,
several implementations would only reflect which are better than others.
Some could be stack based, some other could be heap based etc. etc and
mixes thereof.

-pro

You know, I don’t know if I like the idea of the compiler
inserting calls into my object code and the linker not filling
them up. Because this is a checked build, I’m not sure I care
about what kind of code they generate for me, as long as it
works! But I believe that if the compiler includes a call to
chkstk, the linker should fill it up; and I’m using the DDK
compiler, mind you. So, to me at least this looks like a bug.

Anyway, I’ll use the pragma, because I can do that without
messing up with batch and make files: I hate to do that kind of
thing. This buffer is a staging area for setting up a stream of
graphics rendering commands to my chip, and that stream can be
rather longish; the alternative is to put it in the nonpaged
pool, but why waste time allocating and deallocating memory if I
can do it otherwise ? Another consideration is, this is portable
code, it must run just the same under Windows, Linux and
Solaris, so, I can’t be too particular about API issues or I end
up multiplying by three the number of lines of code I have to
write.

The other thing is, this is a very high performance environment,
which uses a huge amount of memory, so, it can be quite tricky
to allocate and use resources without bringing the whole machine
to its knees! The driver is very carefully tuned to extract the
maximum throughput from the chip and from the bus, and that’s
the major consideration here. Trading performance for safety may
not be a feasible strategy in my case! So, even if the checked
build doesn’t like it, if it works in the production free build
I’m happy with it. But meanwhile I have a daily build to satisfy
and a QA manager that will be on my back in no time if I
systematically break that build!

Alberto.

----- Original Message -----
From: “David J. Craig”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
>
> Sent: Thursday, September 15, 2005 12:13 PM
> Subject: Re:[ntdev] Access to parallel ports from Win32
>
>
>>A couple of people provided advice to suppress this behavior,
>>but I disagree. Any local stack usage should be carefully
>>examined and anything large should be a pointer on the stack
>>that is allocated from either the paged or nonpaged pool. Try
>>driver prefast and it will flag all allocations larger than 1KB
>>and the utility permits this to be varied so it will report
>>even smaller stack usage by a single function. I think
>>anything about 256 bytes in a single function is probably
>>excessive and a potential danger.
>>
>> You can’t use the __chkstk() function in drivers since it is
>> not aware of the rules. It could be replaced by your own
>> function that uses the correct stack limits and usage calls,
>> but I prefer to just not cause a problem. Of course, this
>> becomes far more critical in file system filters.
>>
>> “Alberto Moreira” wrote in message
>> news:xxxxx@ntdev…
>>> Hi, Guys,
>>>
>>> I’m having an annoying problem that’s simple enough that I
>>> feel I should know the answer, yet it’s buried within the
>>> structure of the Microsoft DDK toolset that I’m reluctant to
>>> dig into. So I wonder if someone has some wisdom to share
>>> with me ?
>>>
>>> The problem is this, whenever I have a structure on the stack
>>> that’s larger than a certain size, the C compiler generates a
>>> call to__chkstk() in my checked builds. That reference, for
>>> this or that reason, is not satisfied by the linker. I want
>>> to either suppress the generation of that code or to find
>>> which library that function is defined; I’d prefer that the
>>> compiler doesn’t generate that call to begin with.
>>>
>>> Do any of you know how to do it ? Tks,
>>>
>>>
>>> Alberto.
>>>
>>>
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

23

Alberto,

This is indeed an interesting discussion despite what the subject says:)

Are you using setenv.bat and build.exe? If YES, which version of DDK are you
using? IIRC, DDK used security cookie (/GS, note: cap S) instead of stackchk
(/Gs) a while back. At least, all DDK/WDK (the oldest one is 3790.1830) on
my hard disk does NOT do /Gs for chkbuild.

As for performance, you don’t have to (indeed I will not) trade safety.
Driver crash sucks.I worked on device that draws multi millions of polygons
per second, have multiple instances of application each rendering high
resolution 3D images at around 1000 frames per second. I know exactly what
performance really means. A well designed memory manager highly specific to
your client and command ring of your chip does the trick. This works great
for extremely high throughput slot like AGPx8 and PCI-E x16. At present, no
other PC device class gets even close to that kind of bus throughput.

Calvin Guan (Windows DDK MVP)
NetXtreme Longhorn Miniport Prime
Broadcom Corp. www.broadcom.com

----- Original Message -----
From: “Alberto Moreira”
To: “Windows System Software Devs Interest List”
Sent: Thursday, September 15, 2005 7:00 PM
Subject: Re: Re:[ntdev] Access to parallel ports from Win32

> You know, I don’t know if I like the idea of the compiler inserting calls
> into my object code and the linker not filling them up. Because this is a
> checked build, I’m not sure I care about what kind of code they generate
> for me, as long as it works! But I believe that if the compiler includes
> a call to chkstk, the linker should fill it up; and I’m using the DDK
> compiler, mind you. So, to me at least this looks like a bug.
>
> Anyway, I’ll use the pragma, because I can do that without messing up with
> batch and make files: I hate to do that kind of thing. This buffer is a
> staging area for setting up a stream of graphics rendering commands to my
> chip, and that stream can be rather longish; the alternative is to put it
> in the nonpaged pool, but why waste time allocating and deallocating
> memory if I can do it otherwise ? Another consideration is, this is
> portable code, it must run just the same under Windows, Linux and Solaris,
> so, I can’t be too particular about API issues or I end up multiplying by
> three the number of lines of code I have to write.
>
> The other thing is, this is a very high performance environment, which
> uses a huge amount of memory, so, it can be quite tricky to allocate and
> use resources without bringing the whole machine to its knees! The driver
> is very carefully tuned to extract the maximum throughput from the chip
> and from the bus, and that’s the major consideration here. Trading
> performance for safety may not be a feasible strategy in my case! So, even
> if the checked build doesn’t like it, if it works in the production free
> build I’m happy with it. But meanwhile I have a daily build to satisfy and
> a QA manager that will be on my back in no time if I systematically break
> that build!
>
> Alberto.
>
>
> ----- Original Message -----
> From: “David J. Craig”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, September 15, 2005 12:13 PM
> Subject: Re:[ntdev] Access to parallel ports from Win32
>
>
>>A couple of people provided advice to suppress this behavior, but I
>>disagree. Any local stack usage should be carefully examined and anything
>>large should be a pointer on the stack that is allocated from either the
>>paged or nonpaged pool. Try driver prefast and it will flag all
>>allocations larger than 1KB and the utility permits this to be varied so
>>it will report even smaller stack usage by a single function. I think
>>anything about 256 bytes in a single function is probably excessive and a
>>potential danger.
>>
>> You can’t use the __chkstk() function in drivers since it is not aware of
>> the rules. It could be replaced by your own function that uses the
>> correct stack limits and usage calls, but I prefer to just not cause a
>> problem. Of course, this becomes far more critical in file system
>> filters.
>>
>> “Alberto Moreira” wrote in message
>> news:xxxxx@ntdev…
>>> Hi, Guys,
>>>
>>> I’m having an annoying problem that’s simple enough that I feel I should
>>> know the answer, yet it’s buried within the structure of the Microsoft
>>> DDK toolset that I’m reluctant to dig into. So I wonder if someone has
>>> some wisdom to share with me ?
>>>
>>> The problem is this, whenever I have a structure on the stack that’s
>>> larger than a certain size, the C compiler generates a call to
>>>__chkstk() in my checked builds. That reference, for this or that
>>> reason, is not satisfied by the linker. I want to either suppress the
>>> generation of that code or to find which library that function is
>>> defined; I’d prefer that the compiler doesn’t generate that call to
>>> begin with.
>>>
>>> Do any of you know how to do it ? Tks,
>>>
>>>
>>> Alberto.
>>>
>>>
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hotpop.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

24

I’m using 3790.1830 and I get that problem. I am using both
setenv.bat and build.exe,and the DDK compiler, although I use
them through my MSVC.NET shell - but this is not relevant to the
problem. As I said, I don’t mind them inserting stack calls, at
least not in the checked build, but I don’t want them doing it
in the free build; that may be reason enough for me to use the
VC7 compiler instead, and you bet I can make it work just as
well as the DDK compiler for the application in hand. I’m also
seriously considering switching stacks on entry, because I need
stack space and what the OS gives me right now is too
mickeymouse for me to feel safe, warm and fuzzy.

Microsoft, are you listening ? Give me lots of stack. Like, a
separate and expandable, non-conforming, ring 0, stack segment:
every time I overflow it, you allocate a new buffer, switch
stack pointers, and give it back to me, all automatically and
behind my back. You know, the way a 21st century OS should
behave! Or even better, give me a way of switching to Ring 1 or
starting threads in Ring 1, where I can set up my TSS with my
own Ring1 stack. There’s no way I can feel my system is secure
if I have to share my stack with the OS and if I’m so limited
that I have to have Verifier and what not on my back to try to
catch my attention.

The machine has a lot of functionality. Use that power, dude…

Alberto.

----- Original Message -----
From: “Calvin Guan”
To: “Windows System Software Devs Interest List”

Sent: Saturday, September 17, 2005 5:19 PM
Subject: Re:[ntdev] Access to parallel ports from Win32

> Alberto,
>
> This is indeed an interesting discussion despite what the
> subject says:)
>
> Are you using setenv.bat and build.exe? If YES, which version
> of DDK are you using? IIRC, DDK used security cookie (/GS,
> note: cap S) instead of stackchk (/Gs) a while back. At least,
> all DDK/WDK (the oldest one is 3790.1830) on my hard disk does
> NOT do /Gs for chkbuild.
>
> As for performance, you don’t have to (indeed I will not)
> trade safety. Driver crash sucks.I worked on device that draws
> multi millions of polygons per second, have multiple instances
> of application each rendering high resolution 3D images at
> around 1000 frames per second. I know exactly what performance
> really means. A well designed memory manager highly specific
> to your client and command ring of your chip does the trick.
> This works great for extremely high throughput slot like AGPx8
> and PCI-E x16. At present, no other PC device class gets even
> close to that kind of bus throughput.
>
>
> Calvin Guan (Windows DDK MVP)
> NetXtreme Longhorn Miniport Prime
> Broadcom Corp. www.broadcom.com
>
> ----- Original Message -----
> From: “Alberto Moreira”
> To: “Windows System Software Devs Interest List”
>
> Sent: Thursday, September 15, 2005 7:00 PM
> Subject: Re: Re:[ntdev] Access to parallel ports from Win32
>
>
>> You know, I don’t know if I like the idea of the compiler
>> inserting calls into my object code and the linker not
>> filling them up. Because this is a checked build, I’m not
>> sure I care about what kind of code they generate for me, as
>> long as it works! But I believe that if the compiler
>> includes a call to chkstk, the linker should fill it up; and
>> I’m using the DDK compiler, mind you. So, to me at least this
>> looks like a bug.
>>
>> Anyway, I’ll use the pragma, because I can do that without
>> messing up with batch and make files: I hate to do that kind
>> of thing. This buffer is a staging area for setting up a
>> stream of graphics rendering commands to my chip, and that
>> stream can be rather longish; the alternative is to put it in
>> the nonpaged pool, but why waste time allocating and
>> deallocating memory if I can do it otherwise ? Another
>> consideration is, this is portable code, it must run just the
>> same under Windows, Linux and Solaris, so, I can’t be too
>> particular about API issues or I end up multiplying by three
>> the number of lines of code I have to write.
>>
>> The other thing is, this is a very high performance
>> environment, which uses a huge amount of memory, so, it can
>> be quite tricky to allocate and use resources without
>> bringing the whole machine to its knees! The driver is very
>> carefully tuned to extract the maximum throughput from the
>> chip and from the bus, and that’s the major consideration
>> here. Trading performance for safety may not be a feasible
>> strategy in my case! So, even if the checked build doesn’t
>> like it, if it works in the production free build I’m happy
>> with it. But meanwhile I have a daily build to satisfy and a
>> QA manager that will be on my back in no time if I
>> systematically break that build!
>>
>> Alberto.
>>
>>
>> ----- Original Message -----
>> From: “David J. Craig”
>> Newsgroups: ntdev
>> To: “Windows System Software Devs Interest List”
>>
>> Sent: Thursday, September 15, 2005 12:13 PM
>> Subject: Re:[ntdev] Access to parallel ports from Win32
>>
>>
>>>A couple of people provided advice to suppress this behavior,
>>>but I disagree. Any local stack usage should be carefully
>>>examined and anything large should be a pointer on the stack
>>>that is allocated from either the paged or nonpaged pool.
>>>Try driver prefast and it will flag all allocations larger
>>>than 1KB and the utility permits this to be varied so it will
>>>report even smaller stack usage by a single function. I
>>>think anything about 256 bytes in a single function is
>>>probably excessive and a potential danger.
>>>
>>> You can’t use the __chkstk() function in drivers since it is
>>> not aware of the rules. It could be replaced by your own
>>> function that uses the correct stack limits and usage calls,
>>> but I prefer to just not cause a problem. Of course, this
>>> becomes far more critical in file system filters.
>>>
>>> “Alberto Moreira” wrote in message
>>> news:xxxxx@ntdev…
>>>> Hi, Guys,
>>>>
>>>> I’m having an annoying problem that’s simple enough that I
>>>> feel I should know the answer, yet it’s buried within the
>>>> structure of the Microsoft DDK toolset that I’m reluctant
>>>> to dig into. So I wonder if someone has some wisdom to
>>>> share with me ?
>>>>
>>>> The problem is this, whenever I have a structure on the
>>>> stack that’s larger than a certain size, the C compiler
>>>> generates a call to__chkstk() in my checked builds. That
>>>> reference, for this or that reason, is not satisfied by the
>>>> linker. I want to either suppress the generation of that
>>>> code or to find which library that function is defined; I’d
>>>> prefer that the compiler doesn’t generate that call to
>>>> begin with.
>>>>
>>>> Do any of you know how to do it ? Tks,
>>>>
>>>>
>>>> Alberto.
>>>>
>>>>
>>>
>>>
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at
>>> http://www.osronline.com/article.cfm?id=256
>>>
>>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>>> To unsubscribe send a blank email to
>>> xxxxx@lists.osr.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as:
>> xxxxx@hotpop.com
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

25

Interesting idea, but how could it be done? You have an expanding stack for
a driver in the paging IO path and all of memory is committed. You also get
an interrupt for the paging IO device while its stack has overflowed. This
idea doesn’t pass the smell test. Maybe if the hardware and basic OS design
was different, but from what I know about the system, it is not possible. I
suppose with a new version more stack space could be allocated for kernel
mode stacks, but that is a real impact on available memory. The 64-bit OS
can better afford the impact and they already increased the stack to 16KB.

I see a problem scheduling if an ISR runs and queues a DPC. Then the DPC
doesn’t have a resident stack and how does the scheduler get it paged in?
The scheduler can’t run passive level threads when a DPC is ready to run.
If this was a real virtual system with complete hardware support, then the
only resident pieces would be in the “VM” OS and not the client OS. Maybe
in the future.

“Alberto Moreira” wrote in message news:xxxxx@ntdev…
> I’m using 3790.1830 and I get that problem. I am using both setenv.bat and
> build.exe,and the DDK compiler, although I use them through my MSVC.NET
> shell - but this is not relevant to the problem. As I said, I don’t mind
> them inserting stack calls, at least not in the checked build, but I don’t
> want them doing it in the free build; that may be reason enough for me to
> use the VC7 compiler instead, and you bet I can make it work just as well
> as the DDK compiler for the application in hand. I’m also seriously
> considering switching stacks on entry, because I need stack space and what
> the OS gives me right now is too mickeymouse for me to feel safe, warm and
> fuzzy.
>
> Microsoft, are you listening ? Give me lots of stack. Like, a separate and
> expandable, non-conforming, ring 0, stack segment: every time I overflow
> it, you allocate a new buffer, switch stack pointers, and give it back to
> me, all automatically and behind my back. You know, the way a 21st century
> OS should behave! Or even better, give me a way of switching to Ring 1 or
> starting threads in Ring 1, where I can set up my TSS with my own Ring1
> stack. There’s no way I can feel my system is secure if I have to share my
> stack with the OS and if I’m so limited that I have to have Verifier and
> what not on my back to try to catch my attention.
>
> The machine has a lot of functionality. Use that power, dude…
>
>
> Alberto.
>
>
> ----- Original Message -----
> From: “Calvin Guan”
> To: “Windows System Software Devs Interest List”
> Sent: Saturday, September 17, 2005 5:19 PM
> Subject: Re:[ntdev] Access to parallel ports from Win32
>
>
>> Alberto,
>>
>> This is indeed an interesting discussion despite what the subject says:)
>>
>> Are you using setenv.bat and build.exe? If YES, which version of DDK are
>> you using? IIRC, DDK used security cookie (/GS, note: cap S) instead of
>> stackchk (/Gs) a while back. At least, all DDK/WDK (the oldest one is
>> 3790.1830) on my hard disk does NOT do /Gs for chkbuild.
>>
>> As for performance, you don’t have to (indeed I will not) trade safety.
>> Driver crash sucks.I worked on device that draws multi millions of
>> polygons per second, have multiple instances of application each
>> rendering high resolution 3D images at around 1000 frames per second. I
>> know exactly what performance really means. A well designed memory
>> manager highly specific to your client and command ring of your chip does
>> the trick. This works great for extremely high throughput slot like AGPx8
>> and PCI-E x16. At present, no other PC device class gets even close to
>> that kind of bus throughput.
>>
>>
>> Calvin Guan (Windows DDK MVP)
>> NetXtreme Longhorn Miniport Prime
>> Broadcom Corp. www.broadcom.com
>>
>> ----- Original Message -----
>> From: “Alberto Moreira”
>> To: “Windows System Software Devs Interest List”
>> Sent: Thursday, September 15, 2005 7:00 PM
>> Subject: Re: Re:[ntdev] Access to parallel ports from Win32
>>
>>
>>> You know, I don’t know if I like the idea of the compiler inserting
>>> calls into my object code and the linker not filling them up. Because
>>> this is a checked build, I’m not sure I care about what kind of code
>>> they generate for me, as long as it works! But I believe that if the
>>> compiler includes a call to chkstk, the linker should fill it up; and
>>> I’m using the DDK compiler, mind you. So, to me at least this looks like
>>> a bug.
>>>
>>> Anyway, I’ll use the pragma, because I can do that without messing up
>>> with batch and make files: I hate to do that kind of thing. This buffer
>>> is a staging area for setting up a stream of graphics rendering commands
>>> to my chip, and that stream can be rather longish; the alternative is to
>>> put it in the nonpaged pool, but why waste time allocating and
>>> deallocating memory if I can do it otherwise ? Another consideration is,
>>> this is portable code, it must run just the same under Windows, Linux
>>> and Solaris, so, I can’t be too particular about API issues or I end up
>>> multiplying by three the number of lines of code I have to write.
>>>
>>> The other thing is, this is a very high performance environment, which
>>> uses a huge amount of memory, so, it can be quite tricky to allocate and
>>> use resources without bringing the whole machine to its knees! The
>>> driver is very carefully tuned to extract the maximum throughput from
>>> the chip and from the bus, and that’s the major consideration here.
>>> Trading performance for safety may not be a feasible strategy in my
>>> case! So, even if the checked build doesn’t like it, if it works in the
>>> production free build I’m happy with it. But meanwhile I have a daily
>>> build to satisfy and a QA manager that will be on my back in no time if
>>> I systematically break that build!
>>>
>>> Alberto.
>>>
>>>
>>> ----- Original Message -----
>>> From: “David J. Craig”
>>> Newsgroups: ntdev
>>> To: “Windows System Software Devs Interest List”
>>> Sent: Thursday, September 15, 2005 12:13 PM
>>> Subject: Re:[ntdev] Access to parallel ports from Win32
>>>
>>>
>>>>A couple of people provided advice to suppress this behavior, but I
>>>>disagree. Any local stack usage should be carefully examined and
>>>>anything large should be a pointer on the stack that is allocated from
>>>>either the paged or nonpaged pool. Try driver prefast and it will flag
>>>>all allocations larger than 1KB and the utility permits this to be
>>>>varied so it will report even smaller stack usage by a single function.
>>>>I think anything about 256 bytes in a single function is probably
>>>>excessive and a potential danger.
>>>>
>>>> You can’t use the __chkstk() function in drivers since it is not aware
>>>> of the rules. It could be replaced by your own function that uses the
>>>> correct stack limits and usage calls, but I prefer to just not cause a
>>>> problem. Of course, this becomes far more critical in file system
>>>> filters.
>>>>
>>>> “Alberto Moreira” wrote in message
>>>> news:xxxxx@ntdev…
>>>>> Hi, Guys,
>>>>>
>>>>> I’m having an annoying problem that’s simple enough that I feel I
>>>>> should know the answer, yet it’s buried within the structure of the
>>>>> Microsoft DDK toolset that I’m reluctant to dig into. So I wonder if
>>>>> someone has some wisdom to share with me ?
>>>>>
>>>>> The problem is this, whenever I have a structure on the stack that’s
>>>>> larger than a certain size, the C compiler generates a call to
>>>>>__chkstk() in my checked builds. That reference, for this or that
>>>>> reason, is not satisfied by the linker. I want to either suppress the
>>>>> generation of that code or to find which library that function is
>>>>> defined; I’d prefer that the compiler doesn’t generate that call to
>>>>> begin with.
>>>>>
>>>>> Do any of you know how to do it ? Tks,
>>>>>
>>>>>
>>>>> Alberto.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> —
>>>> Questions? First check the Kernel Driver FAQ at
>>>> http://www.osronline.com/article.cfm?id=256
>>>>
>>>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at
>>> http://www.osronline.com/article.cfm?id=256
>>>
>>> You are currently subscribed to ntdev as: xxxxx@hotpop.com
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>