As far as I can see - the only entrypoint to communicate with DeviceDriver - is using CreateFile.
Q1 - Is there any other way to communicate with device driver other than using CreateFile
Q2 - When using pseudo file access approach - what are common ways people use ReadFile and WriteFile? Only for passing data in-out or is there any other special purpose to use these?
Any link to appropriate article would be VERY appreciated.
These articles may be very useful for you
http://www.osronline.com/article.cfm?id=24
http://www.osronline.com/article.cfm?article=39
https://learn.microsoft.com/en-us/windows-hardware/drivers/wdf/working-with-usb-pipes
A1: Yes, there is few like Pipes but afair it uses CreateFileA
A2: This is not a pseudofile (kernel objects are not quite files, you can mainly read/write data from them), but read/writefile function are designed to pass data
If your driver is a minifilter driver (file system filter driver) working with filter manager you can use CommunicationPorts.
See FltCreateCommunicationPort.
Related
As we know, in Windows NT kernel, there are three ways to post a work item to execute in a system thread environment at PASSIVE_LEVEL.
i.e. ExQueueWorkItem, FltQueueGenericWorkItem, and FltQueueDeferredIoWorkItem.
However, I just wonder their differences and their respective application scenarios.
Any explanations?
From the documentation of each API:
ExQueueWorkItem : Can be used by drivers where there isn't any framework apis provided for such work. The documentation suggests to use IoQueueWorkItem instead.
FltQueueGenericWorkItem: For minifilter drivers, shall use this to do any non-IO related work. Like some periodic cleanup etc.
FltQueueDeferredIoWorkItem: For minifilter drivers for work related to IO operation. I.e. if you are filtering an IO, you can defer some work related to that IO using this function.
Is there any way to hook all disk writes going thru the system, and receive the file names of whatever's being modified, using the Win32 API? Or is this something that would require writing a driver?
You can't do this in user mode, it needs to be kernel mode and so that means a driver. You need a File System Filter Driver.
If you don't care about intercepting the actual data, and only want to know which files are being modified/created/deleted then you can use the ReadDirectoryChangesW API to get that info from userland. Note however that it's one of the hardest functions to use effectively and efficiently, and you should be familiar with IOCP to use it correctly.
In my computer, there are two network adapters, connecting to different subnet. As below:
adapter A: 10.20.30.201
adapter B: 10.20.31.201
I want to make all outgoing data of a special process (for example Process A) through adapter A. That is I want to make adapter A as the process's default route.
I know, I can modify route table for some special destination, But what I want to do here is very different. Process A may communicate with many different IP and I don't know in advance.
Winsock2 provides LSP as a way to lay a dll in TCP/IP stack. I'm not familiar with LSP and don't know whether LSP can do what I want to do.
Can anybody give me some suggestion, Thanks.
A quick background on LSP:
An application, which uses Winsock2 API, calls a combination of WSA-prefix functions, eg WSAConnect, WSASocket, WSASend, WSARecv, etc.
If an application still use old winsock functions, these functions are mapped to Winsock2 behind the scene anyway. For instances: send() is mapped to WSASend(), recv() to WSARecv(), etc
WSA-prefix functions will internally call their corresponding WSP-prefix functions provided by LSP. For instances WSASend() calls WSPSend(), WSASocket() call WSPSocket(), etc. In short, WSAWhateverFunction() will calls WSPWhateverFunction(). Their parameters/returns are also the same (Not quite, but kind of).
LSP is a dll with these WSP-prefix functions implemented, eg. modify outbound/inbound traffic, filtering, etc. However an LSP is still a userspace dll. It's as limited as other userspace programs, and has no higher privilege than its host application, eg internet browsers. It has access to same set of system functions that is available to other programs, eg. winsock etc.
Conclusion is if your program can direct out-coming traffic to specific NIC, LSP can do it too. If it can't, neither can LSP. LSP therefore is irrelevant to your problem.
I have a program that does some networking using Winsock, and one of our requirements right now is to port over our program to Linux. The only thing stopping us from doing this is Winsock.
My question is: How easy can I port this over to a Linux implementation?
Are there any pitfalls I should be aware of, and if I simply include the appropriate header files, what sort of things will I have to be sure to handle?
Thanks for any help!
I'd post code but I can't unfortunately due to legal reasons.
But, our code does use the following:
WSAStartup(..)
WSACleanup(..)
Socket(..)
sendto(..)
recvfrom(..)
ioctlsocket(..)
setsocketopt(..)
Based on that list of functions, things should more or less just work. Add #if _WIN32 around the calls to WSAStartup and WSACleanup (the linux equivalent is to not do anything, the sockets library is initialized automatically).
You also might need some OS-dependent code when setting socket options, some of them are the same, some aren't, and the types might be different.
It will depend if you use any windows specific networking functionality or if you're just using mostly the mostly BSD compatible API.
So, if you're using overlapped I/O and I/O completion ports and other advanced parts of the Winsock API then things will be very difficult to port and if you're just using the BSD compatible stuff then it should be easy to write a thin translation layer or even just have the winsock startup and shutdown stuff inside a windows specific ifdef...
This may help: http://tangentsoft.net/wskfaq/articles/bsd-compatibility.html
The only calls that make porting difficult are the WSA* calls.
WSAStartup() -> nop
WSACleanup() -> nop
Socket/setsockopt -> socket/setsockopt
Under *nix, sockets are blocking by default and it's not necessary or possible to use that weird setsockopt call to fiddle with it.
ioctlsocket -> ioctl
Under *nix we don't like asynchronous sockets much and prefer to use the select() system call.
---- Rest of this answer seems only to apply to Win95 compatible winsock ----
Unfortunately as the original socket() in Winsock was broken in some cases, you probably used WSASocket() and so have to convert those calls.
Without seeing code, it's tough to say how easy it is. But you should be able to replace winsock calls to analogs in sys/socket.h.
I'm developing a network-redirector like SMB.
I want to test various file I/O to compare NTFS or SMB implementation.
What I want to test are,
CreateFile
Read, WriteFile
DeleteFile
RenameFile
Set, GetFileInformationByHandle
etc.
And it' would be better if it can measure each I/Os duration.
Is there a program I can use?
If you are developing a file system driver or use some redirector driver (either our Callback File System or alternatives), you can use IFSTest tool to check your implementation for correctness.
XPerf will answer all of these questions, allowing you to see perf at both the file level and the block level. Check out the PDC09 video on the topic at http://www.microsoftpdc.com/2009/CL16
You can use the File Server Capacity Tool (FSCT) provided by Microsoft. It will let you simulate a typical user workload against a file server that supports SMB. The tool can simulate multiple users from a single client and aggregates the results into text files in the end.
You can get more information, including links to download and detailed presentations at http://blogs.technet.com/b/josebda/archive/2009/09/16/file-server-capacity-tool-fsct-1-0-available-for-download.aspx