any help to port winNT scsi miniport driver to win9x

Hi all,

We’ve written a scsi miniport driver for winNT to for
a virtual cdrom drive which is working fine. So, we
had to use some file operatiosn in the low level and
for that we used ‘ntddk.h’ . Now I’m facing problem in
porting it for Win9x because of those fileIO calls . I
want to replace those for Win9x. Can I get some tips
or tricks from anyone…

som


Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Ring0_FileXxx

Jamey
xxxxx@storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Raj Somsubhra
Sent: Saturday, August 25, 2001 6:51 AM
To: NT Developers Interest List
Subject: [ntdev] any help to port winNT scsi miniport driver to win9x

Hi all,

We’ve written a scsi miniport driver for winNT to for
a virtual cdrom drive which is working fine. So, we
had to use some file operatiosn in the low level and
for that we used ‘ntddk.h’ . Now I’m facing problem in
porting it for Win9x because of those fileIO calls . I
want to replace those for Win9x. Can I get some tips
or tricks from anyone…

som


Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

BTW: This will not work reliably under 9x and it will surly cause
problems in the future under NT/2000. These drivers, miniports, are not
designed for this type of stuff.

Jamey
xxxxx@storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Raj Somsubhra
Sent: Saturday, August 25, 2001 6:51 AM
To: NT Developers Interest List
Subject: [ntdev] any help to port winNT scsi miniport driver to win9x

Hi all,

We’ve written a scsi miniport driver for winNT to for
a virtual cdrom drive which is working fine. So, we
had to use some file operatiosn in the low level and
for that we used ‘ntddk.h’ . Now I’m facing problem in
porting it for Win9x because of those fileIO calls . I
want to replace those for Win9x. Can I get some tips
or tricks from anyone…

som


Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Hi Raj,

Some time ago (when our storage products were based on SCSI miniport
ideology) we just made our SCSI miniport link to own library that depending
of the OS was #define’ing file I/O stuff either as wrappers over ZwXxx
services (if Windows NT/2K was the target) or own VFAT, VCACHE & IFSMGR
replacer code (you’ll definitely hit famous IFSMgr_Block problem and VFAT
non-reentrancy when you’ll be porting your SCSI miniport to Windows 9X/ME,
as CDFS will be on the top of storage stack not VFAT it’s not so difficult
to resolve as you do not emulate hard disk but prepare for nighmare) if the
target was Windows 9X/ME.

Wish you luck!

Regards,
Anton Kolomyeytsev

CoolDev.Com - Toolkits for Network & Storage Kernel Software Developers
“KoolSockets” & “KoolStorage” - TDI Client, Kernel Sockets, iSCSI port
www.CoolDev.Com xxxxx@CoolDev.Com xxxxx@CoolDev.Com

On 08/25/01, “Raj Somsubhra ” wrote:
> Hi all,
>
> We’ve written a scsi miniport driver for winNT to for
> a virtual cdrom drive which is working fine. So, we
> had to use some file operatiosn in the low level and
> for that we used ‘ntddk.h’ . Now I’m facing problem in
> porting it for Win9x because of those fileIO calls . I
> want to replace those for Win9x. Can I get some tips
> or tricks from anyone…
>
> som
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
>
> —
> You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Hi Jamey & others,

SCSI miniports work just great under Windows 9X/ME. Only IDE driver under
Windows 9X/ME comes as full port driver (PDR). 99% of other storage
solutions are written and shipped to customers as SCSI miniports (MPDs).
Windows ME keeps the bugs (like broken file attributes when locking the
volume, attempts to alter the serial IDs of the removable media that’s
write-protected etc) for at least 5 years (from early beta version of
Windows 95). That’s why I do not think anybody in Microsoft will be brave
enough to change Windows ME storage driver model and drop SCSI miniport
support. And Windows ME will be with us (at least with some millions of us)
for next 2 years or so.

Why SCSI miniports will cause problems in future version of Windows? The
one I’ve written was designed for NT 4.0 and works recompiled under 2000
and XP w/o any source code modification. What should happen to them? Of
course there are other storage solutions under Windows 2000 and XP (like
full SCSI port drivers and STORPORT miniports) but SCSIPORT.SYS is still
there and I do not think MS will throw it away in post-XP Windowses. Of
somebody in MS told you they will?

I think SCSI miniport is the best choice when you need to design fast &
compareably low-cost (the ability to keep same source tree for Windows NT,
2K & XP and at least 90% of the source wil be the same for Windows 9X and
ME as well, rest 10% will go for very different file I/O and possibly
network stuff) virtual storage solution.

Surely fully deserialized storage drivers (like Windows 9X/ME port driver
that registers itself w/o DCB_dmd_serialize flag set and Windows 2K and XP
port drivers) can (theoretically!!! it depends of the task…) show much
better performance but their implementation will require a lot more time.
No good samples, no documentation, no support from MS, less people to ask
and so on. In the same time SCSI miniports are well documented and there
are tons of software written in this way - hundreds of people can answer
stupid questions like “Why should I set AutoRequestSense to TRUE to make my
driver work under Windows 2000?”

So the question is a usual “time or money?”. “Do you want get ready driver
in a month or do you want to wait for at least half a year before you’ll
see something working and not showing blue screens after every megabyte of
the data written to the disk?” In other words “Tiny low(but OK!)-performace
well debugged driver that costs 5K in one month VS huge high(do we really
need this???)-perfomance multi-K lines of code monster that driver verifier
refuses to verify for 30K and 6 monthes”. Most of the mangers beeing asked
with this question(s) will definitely select first solution. It’s good for
you (and me!) to discuss the things that require some time to implement in
software but most of the managers want the things to be done in “fast and
dirty” way. The model of the Universe you (and me!) belong to just does not
work for the most of the developers who have management above them and they
are not you (and me!) who are top management for themself. You (and me!)
are generals in their 10 men armies and most of the other developers are
privates in their 1000+ armies.
VERY different. You (and me!) pay with own money for own mistakes and own
job and most of the programmers get theis salaries from their companies and
pay for their mistakes with their company’s money. VERY different again…

Finally. There are no “Swiss-army knife” solutions. The performance and
“coolnest” of the solution can be affected with the time (at least!) this
solution can require to be implemented.

And SCSI miniports are not so bad -)

Regards,
Anton Kolomyeytsev

CoolDev.Com - Toolkits for Network & Storage Kernel Software Developers
“KoolSockets” & “KoolStorage” - TDI Client, Kernel Sockets, iSCSI port
www.CoolDev.Com xxxxx@CoolDev.Com xxxxx@CoolDev.Com

BTW: This will not work reliably under 9x and it will surly cause
problems in the future under NT/2000. These drivers, miniports, are not
designed for this type of stuff.


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

>SCSI miniports work just great under Windows 9X/ME. Only IDE driver
under

Windows 9X/ME comes as full port driver (PDR). 99% of other storage
solutions are written and shipped to customers as SCSI miniports
(MPDs).
Windows ME keeps the bugs (like broken file attributes when locking the

volume, attempts to alter the serial IDs of the removable media that’s
write-protected etc) for at least 5 years (from early beta version of
Windows 95). That’s why I do not think anybody in Microsoft will be
brave
enough to change Windows ME storage driver model and drop SCSI miniport

support. And Windows ME will be with us (at least with some millions of
us)
for next 2 years or so.

What ARE you talking about?

Surely fully deserialized storage drivers (like Windows 9X/ME port
driver
that registers itself w/o DCB_dmd_serialize flag set and Windows 2K and
XP
port drivers) can (theoretically!!! it depends of the task…) show
much
better performance but their implementation will require a lot more
time.
No good samples, no documentation, no support from MS, less people to
ask
and so on. In the same time SCSI miniports are well documented and
there
are tons of software written in this way - hundreds of people can
answer
stupid questions like “Why should I set AutoRequestSense to TRUE to
make my
driver work under Windows 2000?”

I am still lost… What are you talking about?

So the question is a usual “time or money?”. “Do you want get ready
driver
in a month or do you want to wait for at least half a year before
you’ll
see something working and not showing blue screens after every megabyte
of
the data written to the disk?” In other words “Tiny low(but
OK!)-performace
well debugged driver that costs 5K in one month VS huge high(do we
really
need this???)-perfomance multi-K lines of code monster that driver
verifier
refuses to verify for 30K and 6 monthes”. Most of the mangers beeing
asked
with this question(s) will definitely select first solution. It’s good
for
you (and me!) to discuss the things that require some time to implement
in
software but most of the managers want the things to be done in “fast
and
dirty” way. The model of the Universe you (and me!) belong to just does
not
work for the most of the developers who have management above them and
they
are not you (and me!) who are top management for themself. You (and
me!)
are generals in their 10 men armies and most of the other developers
are
privates in their 1000+ armies.
VERY different. You (and me!) pay with own money for own mistakes and
own
job and most of the programmers get theis salaries from their companies
and
pay for their mistakes with their company’s money. VERY different
again…

You sure have a lot to say to say nothing.

And SCSI miniports are not so bad -)

No one is saying that they are bad. They are great. I have probably
written 6 or more SCSI miniports for real hardware. I wrote one for
virtual hardware and realized that hacking the OS to make it work is a
horrible idea. Recursively calling back into SCSI port to complete a
request is a bad idea. You can run into stack problems, locking
problems and serialization problems. Your code will break someday. Lets
hope it does not break on an important client.


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Raj,

Try Ring0_FileIO

If you get stuck, send me some private email and I will help you fix the
blocking issue when it arises. It is quite simple, but I need to dig up
the code.

Jamey
xxxxx@storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Sunday, August 26, 2001 12:00 AM
To: NT Developers Interest List
Subject: [ntdev] Re: any help to port winNT scsi miniport driver to
win9x

Hi Raj,

Some time ago (when our storage products were based on SCSI miniport
ideology) we just made our SCSI miniport link to own library that
depending
of the OS was #define’ing file I/O stuff either as wrappers over ZwXxx
services (if Windows NT/2K was the target) or own VFAT, VCACHE & IFSMGR
replacer code (you’ll definitely hit famous IFSMgr_Block problem and
VFAT
non-reentrancy when you’ll be porting your SCSI miniport to Windows
9X/ME,
as CDFS will be on the top of storage stack not VFAT it’s not so
difficult
to resolve as you do not emulate hard disk but prepare for nighmare) if
the
target was Windows 9X/ME.

Wish you luck!

Regards,
Anton Kolomyeytsev

CoolDev.Com - Toolkits for Network & Storage Kernel Software Developers
“KoolSockets” & “KoolStorage” - TDI Client, Kernel Sockets, iSCSI port
www.CoolDev.Com xxxxx@CoolDev.Com xxxxx@CoolDev.Com

On 08/25/01, “Raj Somsubhra ” wrote:
> Hi all,
>
> We’ve written a scsi miniport driver for winNT to for
> a virtual cdrom drive which is working fine. So, we
> had to use some file operatiosn in the low level and
> for that we used ‘ntddk.h’ . Now I’m facing problem in porting it for
> Win9x because of those fileIO calls . I want to replace those for
> Win9x. Can I get some tips or tricks from anyone…
>
> som
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo!
> Messenger http://phonecard.yahoo.com/
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Raj,

IFSMgr_Ring0_FileIO together with file system hook that patches “container”
file attributes to make the file system driver (VFAT mostly) think it’s
memory-mapped and not cached file is the way Microsoft recommends to write
the drivers that manage virtual volumes. As I remember there is file on
Microsoft site called “IOSGuide.doc” that describes this technique and some
other recommendations you could pay some attention on as well. I think
that’s what Jamey will tell you to do (as this is really very simple way).
But this is not safe way and MS people does not use it themself if you
care. If you will not flush the cache on the drive that holds your
“container” file (Remember, you’re working with this file as it’s not
cached! Interesting, yeah?) the system will crash… There are other
situations that make the code like this behave very bad. I’m not gonna list
them as this is not the right place I think.

In the same time Microsoft itself writes this kind of drivers in totally
different way. It’s the way DriveSpace for example works. They get the
chain of the clusters (with the special API if you’re interested) that
belong to the “container” file in the very begining of the driver’s work
and process the actual sectors on the disk (w/o use of file system driver
surely). So you deal only with IOS and your code bypasses IFSMgr, VCache
and VFAT. This is secret MS does not want you to know.

So write me a private e-mail and I’ll show you how to do this. Sorry it’s
really not very easy way. But it’s correct way.

Regards,
Anton Kolomyeytsev

CoolDev.Com - Toolkits for Network & Storage Kernel Software Developers
“KoolSockets” & “KoolStorage” - TDI Client, Kernel Sockets, iSCSI port
www.CoolDev.Com xxxxx@CoolDev.Com xxxxx@CoolDev.Com

On 08/26/01, ““Jamey Kirby” ” wrote:
> Raj,
>
> Try Ring0_FileIO
>
> If you get stuck, send me some private email and I will help you fix the
> blocking issue when it arises. It is quite simple, but I need to dig up
> the code.
>
> Jamey
> xxxxx@storagecraft.com
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@hotmail.com
> Sent: Sunday, August 26, 2001 12:00 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: any help to port winNT scsi miniport driver to
> win9x
>
>
> Hi Raj,
>
> Some time ago (when our storage products were based on SCSI miniport
> ideology) we just made our SCSI miniport link to own library that
> depending
> of the OS was #define’ing file I/O stuff either as wrappers over ZwXxx
> services (if Windows NT/2K was the target) or own VFAT, VCACHE & IFSMGR
> replacer code (you’ll definitely hit famous IFSMgr_Block problem and
> VFAT
> non-reentrancy when you’ll be porting your SCSI miniport to Windows
> 9X/ME,
> as CDFS will be on the top of storage stack not VFAT it’s not so
> difficult
> to resolve as you do not emulate hard disk but prepare for nighmare) if
> the
> target was Windows 9X/ME.
>
> Wish you luck!
>
> Regards,
> Anton Kolomyeytsev
>
> CoolDev.Com - Toolkits for Network & Storage Kernel Software Developers
> “KoolSockets” & “KoolStorage” - TDI Client, Kernel Sockets, iSCSI port
> www.CoolDev.Com xxxxx@CoolDev.Com xxxxx@CoolDev.Com
>
>
> On 08/25/01, “Raj Somsubhra ” wrote:
> > Hi all,
> >
> > We’ve written a scsi miniport driver for winNT to for
> > a virtual cdrom drive which is working fine. So, we
> > had to use some file operatiosn in the low level and
> > for that we used ‘ntddk.h’ . Now I’m facing problem in porting it for
> > Win9x because of those fileIO calls . I want to replace those for
> > Win9x. Can I get some tips or tricks from anyone…
> >
> > som
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Make international calls for as low as $.04/minute with Yahoo!
> > Messenger http://phonecard.yahoo.com/
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Hi Jamey,

No one is saying that they are bad.

BTW: This will not work reliably under 9x and it will surly cause
problems in the future under NT/2000. These drivers, miniports, are not
designed for this type of stuff.

Jamey
xxxxx@storagecraft.com

Was this you or another Jamey? Why SCSI miniports will not work reliably
under Windows 9X/ME? So the one from www.daemon-tools.com is a ghost? And
why SCSI miniports will cause problems in future versions of Windows if
they work so great now? Can you tell me?

They are great. I have probably
written 6 or more SCSI miniports for real hardware.

Good for you. That’s why I respect you and call you a guru.

I wrote one for
virtual hardware and realized that hacking the OS to make it work is a
horrible idea.

Because you was hacking. There are ways to do this in civilized way. Why to
come into the house using windows if there is a door?

Recursively calling back into SCSI port to complete a
request is a bad idea. You can run into stack problems, locking
problems and serialization problems. Your code will break someday. Lets
hope it does not break on an important client.

  1. This is not uncontrolled and never ending recursion. There is single
    recursive call per single request. And there will not be more calls untill
    I’ll not return from this only recursive call and will not ask SCSIPORT to
    give me another SRB to process.

  2. My code cannot break in this place. I use deserialized SCSI Port. But in
    the same time I do not recommend writing it to anyone. Because it’s really
    a complex task and there can be (and are) other solutions.

With great respect,
Anton Kolomyeytsev


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> > Recursively calling back into SCSI port to complete a

> request is a bad idea. You can run into stack problems, locking
> problems and serialization problems. Your code will break someday. Lets
> hope it does not break on an important client.

  1. This is not uncontrolled and never ending recursion. There is single
    recursive call per single request. And there will not be more calls untill

It will hang on SMP machine trying to acquire the spinlock recursively.
Remember that HwScsiXxx are called with bunch of SCSIPORT’s spinlock held.
For instance, the interrupt spinlock is held.

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Why it does not hang when you call ZwXxx file I/O services that end finally
somewhere in the SCSIPORT?

It will hang on SMP machine trying to acquire the spinlock recursively.
Remember that HwScsiXxx are called with bunch of SCSIPORT’s spinlock held.
For instance, the interrupt spinlock is held.


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Because a) if you are calling Zw* from outside a scsiminiport context
there is no problem with a recursive spinlock call, while b) in general,
if you are calling Zw* from inside a scsiminiport context then indeed
you will deadlock or crash the system as you are holding the spinlock
that scsiport will attempt to acquire when it starts to process the
request. Note that the poster clearly state “on an SMP machine”, as
spinlocks are NOPs on the uniprocessor build of NT. You MUST test on
both version of the OS, even if your software is fully serialized, like
a scsiminiport driver.

Why it does not hang when you call ZwXxx file I/O services
that end finally
somewhere in the SCSIPORT?

> It will hang on SMP machine trying to acquire the spinlock
> recursively. Remember that HwScsiXxx are called with bunch of
> SCSIPORT’s spinlock held. For instance, the interrupt spinlock is
> held.


You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> Because a) if you are calling Zw* from outside a scsiminiport context

there is no problem with a recursive spinlock call, while b) in general,
if you are calling Zw* from inside a scsiminiport context then indeed

No, he does not call Zwxxx - he just sends IOCTL_SCSI_MINIPORT to the
miniport itself from this context.
Nevertheless, this is still a deadlock city on SMP.

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com