Dear All,
I am working on a Language monitor on windows NT/2000.
I want to display Printer Status in the spooler window using SetPrinter.
The problem is that when i use SetPrinter from a Win32 application, it works
fine but when i try to use it from the Language monitor it does not work.
I have given all the ACCESS rights in PRINTER_DEFAULTS.
If some one can help me in this regard, it would be of great help to me.
Thanks in advance.
Regards,
Shreyas.
-----Original Message-----
From: NT Developers Interest List digest [mailto:xxxxx@lists.osr.com]
Sent: Monday, May 13, 2002 9:30 AM
To: ntdev digest recipients
Subject: ntdev digest: May 12, 2002
NTDEV Digest for Sunday, May 12, 2002.
- Re: ISR latency too long?
- Re: reading registry
- Re: ISR latency too long?
- Another build question.
- Re: ISR latency too long?
Subject: Re: ISR latency too long?
From: Jan Bottorff
Date: Sun, 12 May 2002 00:36:40 -0700
X-Message-Number: 1
> I am working on a device driver for our hardware. I found the time
>period from the hardware assert the INTA pin to my driver’s ISR
>deasserting this pin is about 10us in the logical analyzer. But the NIC
>interrupt response only takes about 100ns. My ISR only deassert the INTA
>pin by write the hardware register, just one C statement. I use the
>Numega DriverWorks to develop the driver including the ISR, but I don’t
>think the overhead will be that large. How long should be normal? Do you
>have any idea on this? Thank you!
MANY things might cause this.
You are aware that on a PCI device YOUR driver may be down a chain of ISR’s
at the same level. You have no control over how long the ISR’s ahead of you
in the chain takes to see if the interrupt belongs to them. Many ACPI
systems will chain ALL the PCI devices on the same interrupt level. There
was a really interesting message thread about WHY this was so some months
ago on this list.
Offhand, 10 microsec to get your ISR to respond sounds not unusual for a
good case. In a not so good case, expect longer. The REALLY ugly case is
when you have a video card or some other device that does ugly things with
PCI retries, and can cause interrupt latency of like 10 milliseconds. I’ve
seen hardware devices where the ISR needed to respond within a few
microseconds, and basically told the client they had better redesign their
hardware if they wanted it to reliably work on Windows.
There was a big white paper on ISR latencies done by Intel a few years ago.
I believe the URL was posted in the list back then. You might also do some
searching on the Intel sight. The data may not have been updated for W2K
and WXP.
- Jan
----------------------------------------------------------------------
Subject: Re: reading registry
From: Jan Bottorff
Date: Sun, 12 May 2002 00:42:24 -0700
X-Message-Number: 2
> Why is it that most of the device driver books
>differ in the way RtlQueryRegistryValues in used from
>msdn.
I’ve been rather liking InitializeObjectAttributes, ZwOpenKey, and
ZwQueryValueKey recently to read registry values in drivers.
- Jan
----------------------------------------------------------------------
Subject: Re: ISR latency too long?
From: “Maxim S. Shatskih”
Date: Sun, 12 May 2002 17:32:48 +0400
X-Message-Number: 3
> good case. In a not so good case, expect longer. The REALLY ugly case is
> when you have a video card or some other device that does ugly things with
> PCI retries, and can cause interrupt latency of like 10 milliseconds. I’ve
> seen hardware devices where the ISR needed to respond within a few
> microseconds, and basically told the client they had better redesign their
> hardware if they wanted it to reliably work on Windows.
Why Windows? Windows does not do PCI retries.
This hardware will fail on any OS if the video card is one of those
misbehaving ones.
Max
----------------------------------------------------------------------
Subject: Another build question.
From: “Bill Potvin, II”
Date: Sun, 12 May 2002 14:53:30 -0400
X-Message-Number: 4
Here’s another small build question:
I have a rather large collection of um apps and static libs that I build
using build.
When the executables are linked, the syms are stripped to pdb files
written to the same location as the generated executable, and the
executable contains a fully qualified path to the pdb, rather than the
relative path I get when I do a rebase. In addition, the executable name
embedded in the executable file contains a relative path to the exe file.
For example, consider an app called foo located in D:\Work\foo. On a free
build, I get:
“objfre_w2k\i386\foo.exe”
“D:\Work\foo\objfre_w2k\i386\foo.pdb”
embedded in the foo.exe file.
What I want is:
“foo.exe”
“exe\foo.pdb”
If I build the app with a “normal” makefile, rebasing the syms out, then I
get what I want.
Using “normal” makefile builds is not an option; at this time there are
182 executables and 12 static libraries.
Looking at a few of the apps included with the base operating system,
(notepad, regedit, cmd), I see that they all have relative sym paths, i.e.
“exe\notepad.dbg” and, interestingly, none have the executable name
embedded in the executable. DLLs, on the other hand, do have their names
embedded and they are, or appear to be, relative names, i.e.
“lib\i386\acledit.dll”.
I presume that the NT source tree is constructed using build, so does
anyone have any idea how I might produce the same behavior?
regards,
bill.
PS: I posted this through the web interface, but I’d like to post via
email, which requires that my password be specified. I looked through the
lyris docs and the only thing I could find was in the admin guide and all
it said was that the password needs to appear somewhere in the body of the
post and that the listmanager software strips it before sending the post
through. There’s no indication that I could find of specifically how the
password is to be specified in the post.
Can someone point me to the appropriate docs, or tell me privately how to
specify my password in a post so that I can send via email? I’m guessing
that it’s something like pw=“mypassword”, but I’d like to be sure, rather
than just trying things.
----------------------------------------------------------------------
Subject: Re: ISR latency too long?
From: “Dave Harvey”
Date: Sun, 12 May 2002 23:18:25 -0400
X-Message-Number: 5
It certainly depends on the hardware platform (clock rate, bus type, PCI
bridges), and
also on whether you are getting cache hits.
On a 2Hz P4, 10 us is 20,000 CPU clocks! It would be pretty bad if this
was “typical”.
The main cost items are:
1) The hardware interrupt latency. Bridges do try to delay the interrupt
until any previously
queued data reaches memory. If your hardware DMAed a bunch of data into
memory
then generated an interrupt, a bridge might add a significant delay on the
interrupt.
2) PCI register reads. If you were sharing interrupts with another driver,
and that driver
read some PCI registers to determine if there was an interrupt, this could
take a while
(but getting to 10 us is hard just on a couple PCI reads), stalling the
CPU.
3) Cache Misses. If you are trying to have a clean sample, and are
measuring the first
interrupt from this device, you could probably get a substantial number of
cache misses.
These can be 100s of clocks each at high clock rates. See what happens if
you
generate a second interrupt almost immediately after the first is ACKed.
4) Incorrect use of uncached memory in the driver. I’ve seen drivers that
use uncached
memory to hold their own data structures, etc.
-DH
“William Zhang” wrote in message news:xxxxx@ntdev…
>
> Hi All,
>
> I am working on a device driver for our hardware. I found the time
> period from the hardware assert the INTA pin to my driver’s ISR
> deasserting this pin is about 10us in the logical analyzer. But the NIC
> interrupt response only takes about 100ns. My ISR only deassert the INTA
> pin by write the hardware register, just one C statement. I use the
> Numega DriverWorks to develop the driver including the ISR, but I don’t
> think the overhead will be that large. How long should be normal? Do you
> have any idea on this? Thank you!
>
> William
>
>
—
END OF DIGEST
—
You are currently subscribed to ntdev as: xxxxx@ggn.hcltech.com
To unsubscribe send a blank email to %%email.unsub%%