For those familiar with Linux, it is possible to create a module and register it as a block device. This allows the user to mount it as a regular disk (while all the block I/O is handled by the module, e.g. USB mass storage).
Is there a way to do this in Windows ? (Need to create a volume mountable by Windows. The raw data will come from propriety interface).
The easiest way (and it's not easy!) is to write a Storport Miniport driver, you can even do this with KMDF as well. The latest issue of OSR's "The NT Insider" has an article on how to do this, but it's not going to be any kind of easy.
You will learn a ton though, so if you're interested in kernel development, this is a good way to get started!
You can find some simple block device drivers at http://www.acc.umu.se/~bosse/ . Look at the FileDisk driver, which is a Windows equivalent of /dev/loop
Take a look at the Truecrypt project. They have a pretty good implementation of a virtual block device.
Related
I'm looking for a way to ensure that a USB device plugged into a Windows 7 machine will be mounted in a reliable, repeatable way.
I don't have that much Windows experience, but I wondered if there was a way to make the equivalent of a udev rule in Linux to match certain parameters to identify the device and then mount it on a specific COM port.
Any advice would be gratefully received.
Sarcastic answer:
I've looked for C:\Windows\etc\udev.d but there's no such directory
;)
Less sarcastic answer:
As far as I know, the only way to configure devices in windows is via the device management UI which can be started with mmc devmgmt.msc
This is obviously not even similar or even close to udev, there is no possibility to do this without the GUI.
While we want to create a device file in file system, which one should we choose right now? Make a node in udev, which will show up in /dev or use sysfs which will show up in /sys.
I just think I can accomplish most of functions for a device through these two different ways. So it confused me a lot.
Thanks.
Use udev (and or define and publish some major & minor device numbers, like for mknod). See makedev(3)
Application programs want to access physical devices in /dev/ (not in /sys/). Data to/from a device go usually thru /dev/ char or block devices. Metadata and configuration can go thru sysfs
Read more about udev and about sysfs. See also device file wikipage.
You won't get very useful answers if you don't explain more concretely your issues... What exact kind of device are you thinking about? Very probably there exist already similar devices....
Publish very early (even in alpha stage, when it is not fully working) your device driver and software source code as free software preferably as GPLv2 (the license used by Linux kernel). Ask also on kernelnewbies. Work hard (perhaps more than a year) to get your driver incorporated in the official Linux kernel.
You should be familiar with Advanced Linux Programming (in the application userspace world) before attempting to code a kernel driver. After that, read books and resources on Linux kernel driver programming and study the source code of existing drivers in the recent Linux kernels.
Is there any way Not to detect USB from windows PC?
The USB device should not mount on windows PC ,It should be handled by my application..
Suggestions please...
As far as I know there is no way of stopping the mount on the windows PC, however, you could set it up to autorun so that when it is plugged it in attempts to launch your application. This answer has some information on how to do this: https://stackoverflow.com/a/255067
There is also the option to hide a drive in windows by removing is drive letter (http://www.howtogeek.com/97203/how-to-hide-a-drive-in-windows-so-that-no-one-will-know-its-there/) however, this is almost certainly going to stop your application from reading it too.
If this is for a specific security reason then perhaps you could look at encrypting the drive and allowing only the application to decrypt the data. Thus, whilst mounted in windows it will be of little use.
Sorry I couldn't be of much more help.
Microsoft provides a utility called devcon for free download.
It's a "Command Line Uility Alternative to Device Manager".
It can actually do many things that I won't get into here, but removing a plug & play device is a simple operation once you know the unique name of the device you want to manipulate.
Refer this to check how to work with it.
It sounds like you don't want your device to show up as a drive in My Computer. In that case, why are you using the Mass Storage Device class at all? You could make a custom, vendor-specific device and talk to it using control/interrupt/bulk transfers with WinUSB. You would need to change the Device's USB descriptors to indicate it is a vendor-specific device and not a mass-storage device.
inHi, this question is fast, but from my point of view its pretty hard. I have been messing with implementing USB device built from MCU. So I found project called V-USB which is software-emulated USB interface for Atmel MCUs. But this is not so important.
The question is, on their site, they say that using custom USB class, you can simply write host software on Unix, but you need driver DLL for Windows. The problem is, they dont explain why.
So, please, why? I dont know Unix based systems, but I thought that the very basics of different OS are the same becouse thay rise from the same hardware, and even Unix cannot do HW IO operations from user mode.
I know about libraries for USB communication like LibUSB and so, but I want to know the very reason why thay say that its easy on Unix. Thanks.
EDIT:
Thanks for answer, but can I have further question? How this everything is a file works? I mean, my vision of driver on Windows is a program running in kernel mode, thus allowed to access CPU IO ports, which either provides functions to OS by some standarts, to allow Windows to use it (for example HDD driver must be accessible from filesystem driver by standardised set of functions, to allow any HDD work the same).
With this all you have to do is call drivers via WinAPI function or directly call its functions. But USB implements new feature which is different classes. So there is main USB root driver to handle USB and calling right secondary drivers for right devices. Than there is the same procedure, you just call your USB driver.
But if in Unix everything is a file, how are handled different classes? I just cannot imahine how this works in some analogy to Windows way. Does that file represents the way to communicate with USB root driver?
Everything in UNIX is a file, which supports simple operations. No matter if you are communicating via a terminal or a via a usb device, everything is a stream of bytes to a file.
* read
* write
* lseek
* close
How does one go about creating a virtual CD driver on Mac OS X programatically?
I can't find any relevant Cocoa APIs or any pure C BSD solutions.
Any help or information is appreciated.
You would need to use the I/O Kit framework to develop your own device driver that would emulate a virtual CD drive. Here are some links to the relevant APIs to get you started.
I/O Kit Fundamentals
I/O Kit Device Driver Guidelines
Kernel Extension Programming Topics
There are several different answers people have proposed here. The issue at hand is what are you trying to accomplish. If you really want to emulate a CD ROM (down to the commandset) you will need to write a device driver. If your goal is merely to emulate a block device with contents similiar to a CD you can create a disk image using disk utility and let the builtin disk image driver handle it for you.
MacFUSE is useful if you want to present some sort of custom filesystem functionality, but if what you are looking for is something that has the same semantics as an optical disc (whether that is and block or command set level) it is the wrong tool.
If you're simply looking to mount an ISO or something then it's done through the Disk Utility, simply drag it into the side-bar and then select it and choose mount.
If you want to do it from code you can issue the hdiutil command, as shown here. I'm not sure if there's an API call to do it, but getting that command to do the work is quite painless.
The simplest way to mount a custom volume is MacFUSE. It handles the IOKit details for you and lets you write the implementation in user space. However, I don’t think you can make a MacFUSE “look like” a CD; you’d have to modify FUSE to achieve that.
I had a nosey around DAEMON Tools for Mac's driver:
/Library/Extensions/DAEMONToolsVirtualSCSIBus.kext/Contents/MacOS/DAEMONToolsVirtualSCSIBus
I disassembled the binary using Hopper and discovered they are using
IOSCSIProtocolServices.