Hi,
How can i assure that if i am loading my driver at boot time it should be first into driver stack. Reason when ever i am loading dynamically it is first at the driver stack location but in case of static loading it is not.
Regards
Raghwendra
This is one of the oldest mistakes in Windows, YOU CANNOT GUARANTEE YOUR
POSITION ON THE STACK, if your driver requires this it is broken!!! The
reason you cannot, is what happens if someone else needs to be first, who
wins? Forget this idea and write your code correctly.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntfsd…
> Hi,
> How can i assure that if i am loading my driver at boot time it should
> be first into driver stack. Reason when ever i am loading dynamically it
> is first at the driver stack location but in case of static loading it is
> not.
>
>
> Regards
> Raghwendra
>
xxxxx@techmahindra.com wrote:
Hi,
How can i assure that if i am loading my driver at boot time it should be first into driver stack. Reason when ever i am loading dynamically it is first at the driver stack location but in case of static loading it is not.
You can’t. There might be 20 drivers on the system that want to be ‘first’.
For legacy drivers you can control the order somewhat by setting
DependOnGroup (see KB115486). For a filter driver you set the altitude
(http://msdn2.microsoft.com/en-us/library/aa488218.aspx) - MS are
supposed to allocate these but I don’t think it works… the one we
applied for nearly a year ago never turned up (however I don’t think
there’s any hardship using a random number).
Tony
You cannot. Just imagine there is some other software which will also want
the same 
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntfsd…
> Hi,
> How can i assure that if i am loading my driver at boot time it should be
first into driver stack. Reason when ever i am loading dynamically it is first
at the driver stack location but in case of static loading it is not.
>
>
> Regards
> Raghwendra
>
> You cannot. Just imagine there is some other software which will also want the same
Unfortunately, some people don’t take no for an answer, and go lenth in order to meet this “requirement”. The tough part starts when two such “masterpieces” are present on the target machine at the same time, and try to “neutralize” one another…
Anton Bassov
Please don’t pick a random number out of the air. I have already seen
drivers in the wild that do this and one has already tried to use our
Microsoft allocated altitude.
I have not had any problems using the altitude allocation page you
mentioned.
Ben Curley
Head of Software Development
Data Encryption Systems Ltd.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
Sent: 27 June 2007 18:00
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Driver Position into Driver Stack
xxxxx@techmahindra.com wrote:
Hi,
How can i assure that if i am loading my driver at boot time it
should be first into driver stack. Reason when ever i am loading
dynamically it is first at the driver stack location but in case of
static loading it is not.
You can’t. There might be 20 drivers on the system that want to be
‘first’.
For legacy drivers you can control the order somewhat by setting
DependOnGroup (see KB115486). For a filter driver you set the altitude
(http://msdn2.microsoft.com/en-us/library/aa488218.aspx) - MS are
supposed to allocate these but I don’t think it works… the one we
applied for nearly a year ago never turned up (however I don’t think
there’s any hardship using a random number).
Tony
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com
So what is the problem, both drivers still get loaded won’t they ?
/Daniel
“Ben Curley” wrote in message news:xxxxx@ntfsd…
Please don’t pick a random number out of the air. I have already seen
drivers in the wild that do this and one has already tried to use our
Microsoft allocated altitude.
I have not had any problems using the altitude allocation page you
mentioned.
Ben Curley
Head of Software Development
Data Encryption Systems Ltd.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
Sent: 27 June 2007 18:00
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Driver Position into Driver Stack
xxxxx@techmahindra.com wrote:
> Hi,
> How can i assure that if i am loading my driver at boot time it
should be first into driver stack. Reason when ever i am loading
dynamically it is first at the driver stack location but in case of
static loading it is not.
You can’t. There might be 20 drivers on the system that want to be
‘first’.
For legacy drivers you can control the order somewhat by setting
DependOnGroup (see KB115486). For a filter driver you set the altitude
(http://msdn2.microsoft.com/en-us/library/aa488218.aspx) - MS are
supposed to allocate these but I don’t think it works… the one we
applied for nearly a year ago never turned up (however I don’t think
there’s any hardship using a random number).
Tony
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com
Ben Curley wrote:
Please don’t pick a random number out of the air. I have already seen
drivers in the wild that do this and one has already tried to use our
Microsoft allocated altitude.
Well if they don’t get allocated… there isn’t a lot to do. Drivers
have to be released sometime and holding it up because you applied for
an altitude months ago and it still hasn’t appeared isn’t an option.
It’s just an unnecessary layer of beaurocracy.
Load order doesn’t matter to us so the actual number is pretty
irrelevant anyway.
Tony
Sorry for this silly remark, I just learnt that the filter manager will
return STATUS_FLT_INSTANCE_ALTITUDE_COLLISION in case of altitude
collision. We cannot expect everyone to get a MS assigned altitude and a
clear disadvantage of the MS assigned altitudes when you look at the
altitudes they have provided is that most of them end with two or three
zeroes, thus statistically increasing the chances other vendors have grabbed
this altitude without registereing, so to blindly trust on your MS assigned
altitude is not very wise. I think you are much better off grabbing a not
so obvious number of your liking in the wide range which is valid for your
class of minifilter. Unfortunately FilterAttachAtAltitude is a ‘debugging
support function’ but it does allow you to solve the problem in a flexible
and dynamical way, that is trying to install at another altitude in case of
a collision.
/Daniel
“Daniel Terhell” wrote in message
news:xxxxx@ntfsd…
> So what is the problem, both drivers still get loaded won’t they ?
> /Daniel
>
>
> “Ben Curley” wrote in message news:xxxxx@ntfsd…
>
> Please don’t pick a random number out of the air. I have already seen
> drivers in the wild that do this and one has already tried to use our
> Microsoft allocated altitude.
>
> I have not had any problems using the altitude allocation page you
> mentioned.
> Ben Curley
> Head of Software Development
> Data Encryption Systems Ltd.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
> Sent: 27 June 2007 18:00
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] Driver Position into Driver Stack
>
> xxxxx@techmahindra.com wrote:
>> Hi,
>> How can i assure that if i am loading my driver at boot time it
> should be first into driver stack. Reason when ever i am loading
> dynamically it is first at the driver stack location but in case of
> static loading it is not.
>
> You can’t. There might be 20 drivers on the system that want to be
> ‘first’.
>
> For legacy drivers you can control the order somewhat by setting
> DependOnGroup (see KB115486). For a filter driver you set the altitude
> (http://msdn2.microsoft.com/en-us/library/aa488218.aspx) - MS are
> supposed to allocate these but I don’t think it works… the one we
> applied for nearly a year ago never turned up (however I don’t think
> there’s any hardship using a random number).
>
> Tony
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@des.co.uk
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
“Daniel Terhell” wrote in message
news:xxxxx@ntfsd…
> Sorry for this silly remark, I just learnt that the filter manager will
> return STATUS_FLT_INSTANCE_ALTITUDE_COLLISION in case of altitude
> collision. We cannot expect everyone to get a MS assigned altitude and a
> clear disadvantage of the MS assigned altitudes when you look at the
> altitudes they have provided is that most of them end with two or three
> zeroes, thus statistically increasing the chances other vendors have
> grabbed this altitude without registereing, so to blindly trust on your
> MS assigned altitude is not very wise. I think you are much better off
> grabbing a not so obvious number of your liking in the wide range which
> is valid for your class of minifilter. Unfortunately
> FilterAttachAtAltitude is a ‘debugging support function’ but it does
> allow you to solve the problem in a flexible and dynamical way, that is
> trying to install at another altitude in case of a collision.
>
Why can’t you expect people to get an MS assigned altitude? That is what
you are supposed to do.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"Sorry for this silly remark: I think you are much better off grabbing a not
so obvious number of your liking in the wide range which is valid for your
class of minifilter."
There, I fixed that for you.
Yer welcome.
- Dan.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Monday, July 09, 2007 4:00 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Driver Position into Driver Stack
Sorry for this silly remark, I just learnt that the filter manager will
return STATUS_FLT_INSTANCE_ALTITUDE_COLLISION in case of altitude
collision. We cannot expect everyone to get a MS assigned altitude and a
clear disadvantage of the MS assigned altitudes when you look at the
altitudes they have provided is that most of them end with two or three
zeroes, thus statistically increasing the chances other vendors have grabbed
this altitude without registereing, so to blindly trust on your MS assigned
altitude is not very wise. I think you are much better off grabbing a not
so obvious number of your liking in the wide range which is valid for your
class of minifilter. Unfortunately FilterAttachAtAltitude is a ‘debugging
support function’ but it does allow you to solve the problem in a flexible
and dynamical way, that is trying to install at another altitude in case of
a collision.
/Daniel
“Daniel Terhell” wrote in message
news:xxxxx@ntfsd…
> So what is the problem, both drivers still get loaded won’t they ?
> /Daniel
>
>
> “Ben Curley” wrote in message news:xxxxx@ntfsd…
>
> Please don’t pick a random number out of the air. I have already seen
> drivers in the wild that do this and one has already tried to use our
> Microsoft allocated altitude.
>
> I have not had any problems using the altitude allocation page you
> mentioned. Ben Curley
> Head of Software Development
> Data Encryption Systems Ltd.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
> Sent: 27 June 2007 18:00
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] Driver Position into Driver Stack
>
> xxxxx@techmahindra.com wrote:
>> Hi,
>> How can i assure that if i am loading my driver at boot time it
> should be first into driver stack. Reason when ever i am loading
> dynamically it is first at the driver stack location but in case of
> static loading it is not.
>
> You can’t. There might be 20 drivers on the system that want to be
> ‘first’.
>
> For legacy drivers you can control the order somewhat by setting
> DependOnGroup (see KB115486). For a filter driver you set the
> altitude
> (http://msdn2.microsoft.com/en-us/library/aa488218.aspx) - MS are
> supposed to allocate these but I don’t think it works… the one we
> applied for nearly a year ago never turned up (however I don’t think
> there’s any hardship using a random number).
>
> Tony
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@des.co.uk
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Somebody pointed out he tried and waited for months and didn’t get one. Then
it appears if you get an altitude now, you are still one of the first so the
chances that you are going to get an altitude with a rounded number which
collides with another existing filter driver (whose altitude is
self-assigned) is statistically much higher. So you have a clear
disadvantage with an MS assigned altitude while it remains unmandatory to
get one and little altitudes have been issued by MS. It looks like a good
idea if MS change this process a bit so they issue more random style numbers
within the valid range, for instance based on the name of the driver.
/Daniel
“Don Burn” wrote in message news:xxxxx@ntfsd…
> Why can’t you expect people to get an MS assigned altitude? That is what
> you are supposed to do.
>
Thanks, but did you follow the argumentation ?
/Daniel
“Dan Kyler” wrote in message news:xxxxx@ntfsd…
>
> “Sorry for this silly remark: I think you are much better off grabbing a
> not
>
> so obvious number of your liking in the wide range which is valid for your
> class of minifilter.”
>
> There, I fixed that for you.
>
> Yer welcome.
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
> Sent: Monday, July 09, 2007 4:00 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Driver Position into Driver Stack
>
>
> Sorry for this silly remark, I just learnt that the filter manager will
> return STATUS_FLT_INSTANCE_ALTITUDE_COLLISION in case of altitude
> collision. We cannot expect everyone to get a MS assigned altitude and a
> clear disadvantage of the MS assigned altitudes when you look at the
> altitudes they have provided is that most of them end with two or three
> zeroes, thus statistically increasing the chances other vendors have
> grabbed
>
> this altitude without registereing, so to blindly trust on your MS
> assigned
> altitude is not very wise. I think you are much better off grabbing a not
> so obvious number of your liking in the wide range which is valid for your
> class of minifilter. Unfortunately FilterAttachAtAltitude is a ‘debugging
> support function’ but it does allow you to solve the problem in a flexible
> and dynamical way, that is trying to install at another altitude in case
> of
> a collision.
>
> /Daniel
>
>
>
> “Daniel Terhell” wrote in message
> news:xxxxx@ntfsd…
>> So what is the problem, both drivers still get loaded won’t they ?
>> /Daniel
>>
>>
>> “Ben Curley” wrote in message news:xxxxx@ntfsd…
>>
>> Please don’t pick a random number out of the air. I have already seen
>> drivers in the wild that do this and one has already tried to use our
>> Microsoft allocated altitude.
>>
>> I have not had any problems using the altitude allocation page you
>> mentioned. Ben Curley
>> Head of Software Development
>> Data Encryption Systems Ltd.
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
>> Sent: 27 June 2007 18:00
>> To: Windows File Systems Devs Interest List
>> Subject: Re: [ntfsd] Driver Position into Driver Stack
>>
>> xxxxx@techmahindra.com wrote:
>>> Hi,
>>> How can i assure that if i am loading my driver at boot time it
>> should be first into driver stack. Reason when ever i am loading
>> dynamically it is first at the driver stack location but in case of
>> static loading it is not.
>>
>> You can’t. There might be 20 drivers on the system that want to be
>> ‘first’.
>>
>> For legacy drivers you can control the order somewhat by setting
>> DependOnGroup (see KB115486). For a filter driver you set the
>> altitude
>> (http://msdn2.microsoft.com/en-us/library/aa488218.aspx) - MS are
>> supposed to allocate these but I don’t think it works… the one we
>> applied for nearly a year ago never turned up (however I don’t think
>> there’s any hardship using a random number).
>>
>> Tony
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@des.co.uk
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
On the multiple occasions when I have requested an altitude, I have received
it within a few days. Others have reported the same. If it takes a long
time, something has obviously fallen through the cracks, and you should ping
someone.
If your randomly generated altitude happens to conflict with my MS assigned
altitude, our common customer is going to hear which of us can’t be bothered
to do things right.
Having a registry for altitudes is a good thing. We need the same for
device types and HRESULT facility codes.
- Dan.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
Sent: Monday, July 09, 2007 4:24 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Driver Position into Driver Stack
Thanks, but did you follow the argumentation ?
/Daniel
“Dan Kyler” wrote in message news:xxxxx@ntfsd…
>
> “Sorry for this silly remark: I think you are much better off grabbing
> a
> not
>
> so obvious number of your liking in the wide range which is valid for
> your class of minifilter.”
>
> There, I fixed that for you.
>
> Yer welcome.
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Daniel Terhell
> Sent: Monday, July 09, 2007 4:00 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Driver Position into Driver Stack
>
>
> Sorry for this silly remark, I just learnt that the filter manager
> will return STATUS_FLT_INSTANCE_ALTITUDE_COLLISION in case of
> altitude collision. We cannot expect everyone to get a MS assigned
> altitude and a clear disadvantage of the MS assigned altitudes when
> you look at the altitudes they have provided is that most of them end
> with two or three zeroes, thus statistically increasing the chances
> other vendors have grabbed
>
> this altitude without registereing, so to blindly trust on your MS
> assigned
> altitude is not very wise. I think you are much better off grabbing a not
> so obvious number of your liking in the wide range which is valid for your
> class of minifilter. Unfortunately FilterAttachAtAltitude is a ‘debugging
> support function’ but it does allow you to solve the problem in a flexible
> and dynamical way, that is trying to install at another altitude in case
> of
> a collision.
>
> /Daniel
>
>
>
> “Daniel Terhell” wrote in message
> news:xxxxx@ntfsd…
>> So what is the problem, both drivers still get loaded won’t they ?
>> /Daniel
>>
>>
>> “Ben Curley” wrote in message news:xxxxx@ntfsd…
>>
>> Please don’t pick a random number out of the air. I have already
>> seen drivers in the wild that do this and one has already tried to
>> use our Microsoft allocated altitude.
>>
>> I have not had any problems using the altitude allocation page you
>> mentioned. Ben Curley Head of Software Development
>> Data Encryption Systems Ltd.
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
>> Sent: 27 June 2007 18:00
>> To: Windows File Systems Devs Interest List
>> Subject: Re: [ntfsd] Driver Position into Driver Stack
>>
>> xxxxx@techmahindra.com wrote:
>>> Hi,
>>> How can i assure that if i am loading my driver at boot time it
>> should be first into driver stack. Reason when ever i am loading
>> dynamically it is first at the driver stack location but in case of
>> static loading it is not.
>>
>> You can’t. There might be 20 drivers on the system that want to be
>> ‘first’.
>>
>> For legacy drivers you can control the order somewhat by setting
>> DependOnGroup (see KB115486). For a filter driver you set the
>> altitude
>> (http://msdn2.microsoft.com/en-us/library/aa488218.aspx) - MS are
>> supposed to allocate these but I don’t think it works… the one we
>> applied for nearly a year ago never turned up (however I don’t think
>> there’s any hardship using a random number).
>>
>> Tony
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@des.co.uk
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
My customer who I did a mini-filter for reported it took a day. I really
cannot see how screwing the customers, and other firms by being lazy is
worth it for one day. Especially, since you can ask for it at the
beginning of development.
The claim of months sounds bogus, or that they did something wrong, I
wonder if they checked about it?
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Daniel Terhell” wrote in message
news:xxxxx@ntfsd…
> Somebody pointed out he tried and waited for months and didn’t get one.
> Then it appears if you get an altitude now, you are still one of the
> first so the chances that you are going to get an altitude with a rounded
> number which collides with another existing filter driver (whose altitude
> is self-assigned) is statistically much higher. So you have a clear
> disadvantage with an MS assigned altitude while it remains unmandatory to
> get one and little altitudes have been issued by MS. It looks like a good
> idea if MS change this process a bit so they issue more random style
> numbers within the valid range, for instance based on the name of the
> driver.
>
> /Daniel
>
>
>
> “Don Burn” wrote in message news:xxxxx@ntfsd…
>> Why can’t you expect people to get an MS assigned altitude? That is
>> what you are supposed to do.
>>
>
>
Don Burn wrote:
My customer who I did a mini-filter for reported it took a day. I really
cannot see how screwing the customers, and other firms by being lazy is
worth it for one day. Especially, since you can ask for it at the
beginning of development.The claim of months sounds bogus, or that they did something wrong, I
wonder if they checked about it?
Well the form is still so broken you can’t enter any more than the first
50 characters of the address… so I wonder how many people have
actually used it as they would have fixed it by now.
If I found a foolproof way to get one I’d script it and get a block of
100 or so (I can imagine large companies wanting blocks of 1000)… as it
is multiple requests including emails to support have gone unanswered.
Half the trouble is you get *no* acknowledgement that the request has
even gone though, other than the form blanks (presumably to allow you to
make another request… which would be fine but it blanks the static
information as well and backspace works a lot better).
If there’s truly a requirement that they’re unique it sounds more like a
bug in the filter manager being covered up as a ‘feature’. There’s no
logical reason for it… especially given the number of test drivers
that get written… I’d probably have needed more than 100 already by now!
If course if you just go the random route it solves itself. If you’re
worried about collissions have the installer scan the registry and pick
an unused one at install… problem solved. You’ll need to do that
anyway even if you go the official route because it’s impossible to know
what else is installed on the system.
Tony
The whole point I am making is that if I request an altitude now (currently
very few altitudes have been issued, you can view all of them in an excel
file of 62KB) I am likely to end up with a very rounded number like say
375000 for my activity monitor. In a theoretical situation where everybody
would request his altitude that would be fine but as this process is
voluntary, in real life this is surely a number which has already been
chosen (self-assigned) by someone, resulting in an altitude collision.
Praying to other developers not to use my altitude is not going to work. I
cannot just expect everybody to obtain an altitude the official way if it is
not mandatory. Only very few altitudes have been issued so far, and even in
this thread you can already read that somebody is complaining that another
vendor grabbed his altitude. To issue altitudes which are an exact multitude
of 1000 like is currently happening is just plain silly. It is not hard to
understand that with a MS assigned altitude (say 375000) my chances of
facing a collision with another filter are many times much higher then if I
would pick a unique number yourself (say 375831).
Potential solutions are dynamic altitude allocations or a system in which
multiple drivers with the same altitude are going to be tolerated on a don’t
care who goes first basis instead of receiving
STATUS_FLT_INSTANCE_ALTITUDE_COLLISION (also very silly). Another solution
would be that MS made this process mandatory.
What I am doing is actually waiting for others to go first so I am going to
receive a more unique ID which is not likely to be picked by someone very
quickly.
/Daniel
“Don Burn” wrote in message news:xxxxx@ntfsd…
> My customer who I did a mini-filter for reported it took a day. I really
> cannot see how screwing the customers, and other firms by being lazy is
> worth it for one day. Especially, since you can ask for it at the
> beginning of development.
>
> The claim of months sounds bogus, or that they did something wrong, I
> wonder if they checked about it?
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> “Daniel Terhell” wrote in message
> news:xxxxx@ntfsd…
>> Somebody pointed out he tried and waited for months and didn’t get one.
>> Then it appears if you get an altitude now, you are still one of the
>> first so the chances that you are going to get an altitude with a rounded
>> number which collides with another existing filter driver (whose altitude
>> is self-assigned) is statistically much higher. So you have a clear
>> disadvantage with an MS assigned altitude while it remains unmandatory to
>> get one and little altitudes have been issued by MS. It looks like a good
>> idea if MS change this process a bit so they issue more random style
>> numbers within the valid range, for instance based on the name of the
>> driver.
>>
>> /Daniel
>>
>>
>>
>> “Don Burn” wrote in message news:xxxxx@ntfsd…
>>> Why can’t you expect people to get an MS assigned altitude? That is
>>> what you are supposed to do.
>>>
>>
>>
>
>
>