Virtual Disk Driver

NTDEV
21

> From what I have seen on the various newsgroups and even in my

own experience when I was beginning to write drivers, I see a lot of drivers
written by taking a ‘sample’ and changing the minimum to get their objective done.

Well, if someone wants to argue with the above, the only thing he needs to do in order to understand that he is wrong is to search the archives - the number of “I modify XYZ sample…
my driver don’t work…”-style posts speaks for itself…

From my understanding of your argument, providing source code for
libraries would not be possible.

Well, library is just a specific form of a program - unlike executable, it does not have a life on its own. However, it is still a program that may be distributed in binary-only form. Therefore, when it comes to source availability, I don’t see any reason why we should think of libraries as of something special - in my opinion, the same rules should apply to all software that is distributed in binary-only form…

I prefer to have source for any libraries and as many others have
said the lack of source for NDIS, KMDF, UMDF, USB storage stack,
1934 storage stack, Io Manager, Cache Manager, and Memory
Manager make writing for Windows much more difficult.

I don’t really think it will ever happen in the Windows world, especially taking into account that
at least half of above mentioned things are parts of Windows kernel itself and are implemented by ntoskrnl.exe. I think that out of all things that you have mentioned above, the only one that theoretically may get disclosed at some point is KMDF source…

Anton Bassov

22

> 4. When Jamey Kirby gave a copy of the scsi port driver to someone there

was a license involved which restricts the use of the code to being included
in a binary form only. There were probably other restrictions too that
would apply beyond copyright. So therefore, placing the code in source form
and doing the ‘Robin Hood’ trick is not a good thing. I don’t believe that
package is available anymore, but Maxim can say for sure.

FileDisk was written by Jamey before I joined him.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

23

Yes, but since it was, I think, a part of the StorageCraft IP and you still
work for them, I thought you would know if the filedisk and SCSI port
package(s) are still being sold. I know that one sample in the SCSI port
package contains a driver that exposes ‘disk in a file’ capabilities. At
least it did three or four years ago.

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>> 4. When Jamey Kirby gave a copy of the scsi port driver to someone there
>> was a license involved which restricts the use of the code to being
>> included
>> in a binary form only. There were probably other restrictions too that
>> would apply beyond copyright. So therefore, placing the code in source
>> form
>> and doing the ‘Robin Hood’ trick is not a good thing. I don’t believe
>> that
>> package is available anymore, but Maxim can say for sure.
>
> FileDisk was written by Jamey before I joined him.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>

24

> Yes, but since it was, I think, a part of the StorageCraft IP and you still

work for them, I thought you would know if the filedisk and SCSI port
package(s) are still being sold.

No more.

I know that one sample in the SCSI port
package contains a driver that exposes ‘disk in a file’ capabilities.

Yes, but this has nothing to do with FILEDISK.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

25

Hi everyone, sorry I did not join this thread earlier but now that I have read it I think I would like to give you my point of view anyway.

I am the author of ImDisk Virtual Disk Driver available at http://www.ltr-data.se/opencode.html . The background to the project was that I had worked with FreeBSD before and now wanted an ‘md’-like driver under Windows. As I searched the Internet I found FileDisk and looked at the source code but when I read more about it at various forums I saw a post from Don Burn that this was stolen code so I made a quick decision to start something new instead, as much ‘md’-like as possible. Well, this was not the only reason, there were also certain things I just did not like in the FileDisk design.

A quick example, ImDisk has the ‘md’ concept of a separate control device and numbered virtual devices created as needed. In FreeBSD the control device is /dev/mdctl and devices are /dev/md0, /dev/md1 etc and for ImDisk the control device is \Device\ImDiskCtl and devices are \Device\ImDisk0, \Device\ImDisk1 etc. FileDisk has another concept of precreating devices when the driver is loaded. This is just an example. There are lots of design-related differences that should make it obvious that ImDisk is not based on, or inspired by, the FileDisk source.

However, there have been over the years and may still be similar-looking pieces of code in Brantén’s FileDisk and my ImDisk. The reason is that, for example some IOCTL handling code or modifications, have been added by various people to both projects (and in many cases many other projects too) at about the same time. Not much I can do about that. The important thing is that absolutely nothing of that are things taken from Jamey’s original FileDisk and that is also something I have always checked carefully before adding anything suggested to ImDisk.

But of course, if anyone find anything in the ImDisk source that looks like coming from stolen source, please tell me. I will take that very seriously. But you need to be a little more specific.

–
Olof Lagerkvist
LTR Data
http://www.ltr-data.se

26

Hi Olof,

it seems you reacted to one of my postings (can’t be sure as you didn’t quote to what you reply). I downloaded both ImDisk and FileDisk sources and used Beyond Compare to compare them. There are a lot of differences but there are lines which are completely equal which can’t be by accident (some_clearly_name_variable = another_variable + yet_another_variable). It could happen the way you describe: somebody else added the same code to both projects. I can’t compare with the original stolen code as I don’t have access to it and never had.

The logic I applied is simple. FileDisk is stolen. Check if there are similarities with ImDisk. Yes -> ImDisk is based on stolen code. It is apparently wrong logic but anybody else can use it now and in the future. That’s because it makes sense until one reads your explantion. For me it looks strange to add code to two different projects and make the same changes there. I’d personally select one and ignore the second.

As a side note, we have now discontinued product based on the same technique. We also have one control device and virtual devices created on demand. The interesting things happen when you want to multiple user sessions and fast user switching :slight_smile:

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@ltr-data.se[SMTP:xxxxx@ltr-data.se]
Reply To: Windows System Software Devs Interest List
Sent: Sunday, January 27, 2008 1:26 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Virtual Disk Driver

Hi everyone, sorry I did not join this thread earlier but now that I have read it I think I would like to give you my point of view anyway.

I am the author of ImDisk Virtual Disk Driver available at http://www.ltr-data.se/opencode.html . The background to the project was that I had worked with FreeBSD before and now wanted an ‘md’-like driver under Windows. As I searched the Internet I found FileDisk and looked at the source code but when I read more about it at various forums I saw a post from Don Burn that this was stolen code so I made a quick decision to start something new instead, as much ‘md’-like as possible. Well, this was not the only reason, there were also certain things I just did not like in the FileDisk design.

A quick example, ImDisk has the ‘md’ concept of a separate control device and numbered virtual devices created as needed. In FreeBSD the control device is /dev/mdctl and devices are /dev/md0, /dev/md1 etc and for ImDisk the control device is \Device\ImDiskCtl and devices are \Device\ImDisk0, \Device\ImDisk1 etc. FileDisk has another concept of precreating devices when the driver is loaded. This is just an example. There are lots of design-related differences that should make it obvious that ImDisk is not based on, or inspired by, the FileDisk source.

However, there have been over the years and may still be similar-looking pieces of code in Brant?n’s FileDisk and my ImDisk. The reason is that, for example some IOCTL handling code or modifications, have been added by various people to both projects (and in many cases many other projects too) at about the same time. Not much I can do about that. The important thing is that absolutely nothing of that are things taken from Jamey’s original FileDisk and that is also something I have always checked carefully before adding anything suggested to ImDisk.

But of course, if anyone find anything in the ImDisk source that looks like coming from stolen source, please tell me. I will take that very seriously. But you need to be a little more specific.

–
Olof Lagerkvist
LTR Data
http://www.ltr-data.se

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit: >
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

27

Michal Vodicka wrote:

Hi Olof,

it seems you reacted to one of my postings (can’t be sure as you
didn’t quote to what you reply).

Yes, that is correct, sorry I did not quote anything, I was posting
through the web interface and forgot about that.

I downloaded both ImDisk and FileDisk sources and used Beyond Compare
to compare them. There are a lot of differences but there are lines
which are completely equal which can’t be by accident
(some_clearly_name_variable = another_variable + yet_another_variable).
It could happen the way you describe: somebody else added the same
code to both projects. I can’t compare with the original stolen code
as I don’t have access to it and never had.

The logic I applied is simple. FileDisk is stolen. Check if there are
similarities with ImDisk. Yes -> ImDisk is based on stolen code. It
is apparently wrong logic but anybody else can use it now and in the
future. That’s because it makes sense until one reads your explantion.
For me it looks strange to add code to two different projects and make
the same changes there. I’d personally select one and ignore the second.

Well, of course I don’t know for sure if this is the reason for such
similarities, but it is my best guess. One reason is that I know some
people who have previously added things to FileDisk and stopped that
when they have heard about the stolen code issue and then taken their
own piece of code with them and continued with ImDisk instead. Another
variant of that could be that both ImDisk and FileDisk may have more
actively “borrowed” things from other but sometimes same open source
projects over a couple of years. Examples I could think of there right
now may have to do with CD/DVD multi-session and a few HDD partition
table emulation IOCTLs and a few other small solution details. Yet
another reason might be that there could exist variables with the same
name as some kind of DDK sample which has inspired both me and the
original FileDisk author (in the early days of ImDisk I read the
RAM-disk sample and the sources for disk.sys, cdrom.sys etc a lot). Or
of course combinations of these reasons. But again it surprised me a lot
that there were any similarities at all found and I am now just guessing
and this should not be taken as a final explanation, simply because I
don’t (and too bad cannot) know for sure.

Anyway, I am still absolutely sure that any kind of deeper look at the
source codes should make it obvious that ImDisk is not based on FileDisk.

The really frustrating thing for myself (and of course for many of the
commercial spin-offs from ImDisk) is that discussions like this was
exactly what I did not want and of course was the biggest reason why I
decided to write something from scratch instead (well, some not
disk-related stuff came from my other device driver projects, for
example the ugly named-pipe communication between kernel and user mode,
but anyway). But now, here we are anyway and all I can do is hope that
most people believe me, *sigh*…

As a side note, we have now discontinued product based on the same
technique. We also have one control device and virtual devices created
on demand. The interesting things happen when you want to multiple user
sessions and fast user switching :slight_smile:

That detail gave me a lot of headake until I found the current solution
I use. Not that my solution is particularily robust or good-looking but
at least it works in most cases. :slight_smile:

I assume you now have a virtual SCSI-port based product instead that
more or less automatically gives support for mount manager etc…

–
Olof Lagerkvist
ICQ: 724451
Web: http://here.is/olof

28

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Olof Lagerkvist[SMTP:xxxxx@ltr-data.se]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, January 29, 2008 8:11 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Virtual Disk Driver

But again it surprised me a lot
that there were any similarities at all found and I am now just guessing
and this should not be taken as a final explanation, simply because I
don’t (and too bad cannot) know for sure.

I’d recommend to do the same as I did. Use some good file compare tool and look at it. Beyond Compare has free 30-days trial version.

Anyway, I am still absolutely sure that any kind of deeper look at the
source codes should make it obvious that ImDisk is not based on FileDisk.

I’m sorry but my conclusion was different. It looks like somebody took FileDisk sources long time before, changed and added a lot but original root was the same. Look at DriverEntry and dispatch entry points. The same local variables, the same blocks of code. Compare IOCTL processing. One example: IOCTL_DISK_SET_PARTITION_INFO. Completely equal except KdPrint statements added in imdisk.c. And more and more. Identifier names don’t follow DDK samples convention. BTW, order of functions is also very similar which is the reason why compare tool can find so many similarities.

The really frustrating thing for myself (and of course for many of the
commercial spin-offs from ImDisk) is that discussions like this was
exactly what I did not want and of course was the biggest reason why I
decided to write something from scratch instead (well, some not
disk-related stuff came from my other device driver projects, for
example the ugly named-pipe communication between kernel and user mode,
but anyway). But now, here we are anyway and all I can do is hope that
most people believe me, *sigh*…

Only if they can read your explanation, sorry.

> As a side note, we have now discontinued product based on the same
> technique. We also have one control device and virtual devices created
> on demand. The interesting things happen when you want to multiple user
> sessions and fast user switching :slight_smile:

That detail gave me a lot of headake until I found the current solution
I use.

For me it seems as the only logical way :slight_smile:

Not that my solution is particularily robust or good-looking but
at least it works in most cases. :slight_smile:

I assume you now have a virtual SCSI-port based product instead that
more or less automatically gives support for mount manager etc…

No, we discontinued it completely because it has some drawbacks (fixed space hard to resize for example) and somebody at marketing believed there is a better solution. There are new drawbacks, of course, but that’s different story :slight_smile:

If I should solve this problem again, I would use the same solution instead of virtual SCSI miniport. I don’t see any real advantage of the second way. This one is simple, works well and has all necessary functionality from user’s point of view. As a user creating virtual driver on demand is exactly what I want and don’t care about Mount Manager at all.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

29

For what it is worth, I concur that there is both some very curious
similarities, as well as as lot of new code. Just to pour gas on the
fire, however, it appears that FileDisk has made it’s way in to
WinImage; Jamey Kirby is credited, as is our good friend Bo, and it
(seems to be) massively expanded ~ 4 times the size.

http://www.winimage.com/misc/filedisk64.htm

This may have happened a while ago; I don’t really know and didn’t look
at it very closely.

Cheers,

mm

Michal Vodicka wrote:

> ----------
> From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Olof Lagerkvist[SMTP:xxxxx@ltr-data.se]
> Reply To: Windows System Software Devs Interest List
> Sent: Tuesday, January 29, 2008 8:11 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Virtual Disk Driver
>
> But again it surprised me a lot
> that there were any similarities at all found and I am now just guessing
> and this should not be taken as a final explanation, simply because I
> don’t (and too bad cannot) know for sure.
>
I’d recommend to do the same as I did. Use some good file compare tool and look at it. Beyond Compare has free 30-days trial version.

> Anyway, I am still absolutely sure that any kind of deeper look at the
> source codes should make it obvious that ImDisk is not based on FileDisk.
>
I’m sorry but my conclusion was different. It looks like somebody took FileDisk sources long time before, changed and added a lot but original root was the same. Look at DriverEntry and dispatch entry points. The same local variables, the same blocks of code. Compare IOCTL processing. One example: IOCTL_DISK_SET_PARTITION_INFO. Completely equal except KdPrint statements added in imdisk.c. And more and more. Identifier names don’t follow DDK samples convention. BTW, order of functions is also very similar which is the reason why compare tool can find so many similarities.

> The really frustrating thing for myself (and of course for many of the
> commercial spin-offs from ImDisk) is that discussions like this was
> exactly what I did not want and of course was the biggest reason why I
> decided to write something from scratch instead (well, some not
> disk-related stuff came from my other device driver projects, for
> example the ugly named-pipe communication between kernel and user mode,
> but anyway). But now, here we are anyway and all I can do is hope that
> most people believe me, *sigh*…
>
Only if they can read your explanation, sorry.

>> As a side note, we have now discontinued product based on the same
>> technique. We also have one control device and virtual devices created
>> on demand. The interesting things happen when you want to multiple user
>> sessions and fast user switching :slight_smile:
> That detail gave me a lot of headake until I found the current solution
> I use.
>
For me it seems as the only logical way :slight_smile:

> Not that my solution is particularily robust or good-looking but
> at least it works in most cases. :slight_smile:
>
> I assume you now have a virtual SCSI-port based product instead that
> more or less automatically gives support for mount manager etc…
>
No, we discontinued it completely because it has some drawbacks (fixed space hard to resize for example) and somebody at marketing believed there is a better solution. There are new drawbacks, of course, but that’s different story :slight_smile:

If I should solve this problem again, I would use the same solution instead of virtual SCSI miniport. I don’t see any real advantage of the second way. This one is simple, works well and has all necessary functionality from user’s point of view. As a user creating virtual driver on demand is exactly what I want and don’t care about Mount Manager at all.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]