Can anybody give me a simple TDI driver which can block traffic from specified ip-port, or modify packet. I cant find good manual about this.
Thanks!
TDI drivers are extremely complicated. There are companies that sell them for $20,000 and they are worth that price. It would take years to develop and debug a TDI driver. The reason: Windows poorly implemented them, they are part of the network stack itself.
Try using WFP (Windows Filtering Platform) it's an easier interface but doesnt' support Windows XP. Good Luck.
Related
OK, so I recently purchased an Acer T232HL touch screen display to hook up to my Macbook Pro as a secondary monitor. To give you an idea, here's my setup.
OS X doesn't support this monitor in any way, so as you can see in the screenshot I'm actually running Windows 8 through VMware, which proxies the USB connection to Windows perfectly where the touch events are supported. But obviously this isn't ideal.
There's at least one 3rd party driver for OS X that looked sort of promising, but it doesn't seem to support multitouch from this device, it's expensive, and generally was a pain to get working to the small degree it was. There's also mt4j but best I could tell after running their examples, it doesn't support this device at all.
So here's my question: what exactly am I in for if I wanted to write a driver for this thing? I'm mostly a web developer with years of experience with Ruby, Objective-C (and a little C), Javascript, etc. I have never ventured into any kind of hardware programming, so from the surface this feels like an interesting while intimidating challenge.
I know at some level I need to read data from USB. I know this will probably mean trying to reverse engineer whatever protocol they're using for the touch events (is it possible this will be entirely custom?). However I haven't got a clue where to start - would this be a kernel extension? In C, I presume? Would love a high level overview of the moving parts involved here.
Ultimately I want to use the touch screen to drive a specialized web interface (running in Chrome), so ideally I could proxy the touch events straight to Chrome without the OS actually moving the mouse cursor to the touch location (so have the UI behave just as it would on an iPad), but regardless of whether this is technically possible, I'd love to start with just getting something working.
You're going to want to start with Apple's I/O Kit documentation. You can hope that the touchscreen isn't completely custom, though there must be some part that's not standard USB HID, or it would work already. If there are any linux (or other open source) drivers available, you'll have the advantage that somebody already did some of the reverse engineering for you. As an alternative to the I/O Kit, you might also want to look into libusb, which might make your brain hurt less when getting started. If you end up needing to write a kext, that might not help you anymore, though.
As to some of your specific questions:
would this be a kernel extension?
Maybe, maybe not. I'm not really up on the Mac OS X driver situation, but I did write some totally user-space USB code for OS X many years ago. Maybe you'll be as lucky.
In C, I presume?
Probably. I/O Kit itself is written in a subset of C++, so you can probably use that too, if you prefer.
is it possible this will be entirely custom?
Unfortunately, yes, it's possible.
Good luck!
I'm into something about writing a "Mock GPU driver" for Linux based systems. What I mean is that, simply I want to write a driver (Behind X-server obviously) to answer X's API calls with some debugging messages.
In other words I want to fool Linux about having an actual GPU. So I can make a test-bed for GUI-accelerated packages in console based systems.
Right now, if I execute a GUI-accelerated package in Linux console based systems; it'll simply dies due to lack of a real GPU (or a GPU driver better I'd say).
So I want to know:
Is it even possible? (Writing a GPU driver to fool Linux about having an actual GPU)
What resources do you recommend before getting my hands dirty in code?
Is there any similar projects around the net?
PS: I'm an experienced ANSI-C programmer but I don't have any clue in real Kernel/Driver development under *nix (read some tutorials about USB driver development though), so any resources about these areas will be really appreciated as well. Thanks in advance.
What you are looking for is actually part of Xorg server suite, and it is called Xvfb (virtual framebuffer).
If you're not afraid of a bit complex bash, you can take a look at Gentoo's virtualx.eclass for an use example (we use it to run tests which require X11).
A good place to start is the Mesa project - it implements OpenGL in software. It has a way to trick the OS into thinking that it is the OpenGL driver.
I need to make application which gathers basic data about system, like OS version, processor & memory type, data about installed programs...
Application will be written in c and will work on Win Server 2000 and 2003. So first thing on my mind was WinApi, but i can not find any tutorials for these things, every tutorial i found is about UserInterfaces and i do not need that.
So any help would be appreciated.
EDIT: Couple of things are answered below, and i will use WMI with WinApi, but still i dont know how to get detailed properties from any .exe program on windows??
WMI is likely what you need for some stuff. Not a fun API. The tool Hans refers to would be useful - even if you have to port the generated C# code back to C.
The following Win32 APIs are likely to help you:
OS Version: GetVersionEx and OSVERSIONINFOEX
CPU Info: cpuid (either write it in assembly, or call the compiler intrinsic)
Alternate CPU Info: Just look at the registry key in HKLM\Hardware\DESCRIPTION\System\CentralProcessor (1 subkey for each logical processor, each key is a cache of what cpuid returns + processor speed is listed as well).
Memory: GlobalMemoryStatusEx
This isn't covered by the Winapi, you need WMI (Windows Management Instrumentation). To get started on the kind of queries you can run, experiment with the WMI Code Creator tool. It can auto-generate the code you need. Not in C, you'll find that quite an awkward language for WMI.
You probably also want to know about the book Windows Internals, from the same folk who make a wide range of cool utilities for poking under the hood.
For Processor Information call
GetLogicalProcessorInformation.
Be Aware that this is not supported on all machines. So its better to call the DLL dynamically. Otherwise your program wont run on such machines. This example show how to do this
Why are there no good drivers for Windows for reading ext2/3/4 filesystems? Googling around indicates that there's 2 or 3 out there, but all of them have problems. Is there some technical inconsistency that makes it difficult to correctly code up something that would enable me to open up My Computer and work with an extN partition just like NTFS or FAT? I thought one of the benefits of open sources and standards was that problems like this should be solved fairly quickly.
Driver signing.
Microsoft's driver signing is by its own nature incompatible with the GPL and unsigned drivers don't work anymore.
I haven't used it myself, but a coworker of mine has used Ext2 IFS for Windows without any problems.
One of the benefits of open sources and standards is that problems like this can be solved fairly quickly. If no one is sufficiently motivated to work on a problem - whether that motivation comes from money, personal need, fame, whatever - then the problem is unlikely to get solved. (The closed source world is no different.) It probably doesn't help that relatively few open source developers have experience hacking on Windows kernel mode device drivers. Writing device drivers is a specialized skill. There are developers who understand the ext2/3/4 code very well and are very willing to work on it, but odds are that the the people experienced enough at hacking on the Linux kernel to work on the ext2/3/4 drivers are probably primarily Linux users (and so don't much care about writing drivers for Windows).
With regards to driver signing: It's my understanding that, starting with Windows Vista, Microsoft doesn't have to sign or certify your drivers for them to be installed without warnings, but you do need a code signing certificate. These are somewhere in the neighborhood of $400 - $500 a year (see Verisign's web site, for example), and most non-commercial developers aren't interested in paying out that kind of money. There are methods for disabling driver signing requirements, but none of them are something the average user is likely to try, which would hinder the acceptance of a non-signed driver.
I don't know how the Ext2 IFS for Windows handles it; either its author got a certificate somehow, or it requires that you disable the driver signing requirements.
So, to summarize, the best ext2/3/4 developers probably don't have much need for Windows, and driver signing discourages would-be open source driver developers for Windows, and the availability of NTFS for Linux means that you can use NTFS instead of ext2/3/4 to share data between Linux and Windows. These three factors work together to remove a lot of the interest in developing ext2/3/4 for Windows.
I'm trying to find a basic example, tutorial, or blog post on how to write a printer port monitor. I downloaded the Windows DDK and dug through localmon, but it appears that this sample is much more complex than just the nuts and bolts basics and from my understanding it is a bit different than an OEM port monitor because of how it handles the registry key and port enumeration. Does anyone know of a blog post, tutorial, or even book that walks the reader through the basic code to get one up and going? I've found a few links talking about the conceptual stuff, but nothing that is hands on code.
I can recomend http://www.codeproject.com/KB/printing/wpa.aspx, which describes how to write a printer driver and also has good hints about what's necessary to build a port monitor.
But my opinion is that a good tutorial in this area is not available on the Internet (I would be glad to find somebody who can show me that I'm wrong). So, when I had to deal with this task I was forced to do it the hard way: I've read carefully the MSDN explanations starting from this point: http://msdn.microsoft.com/en-us/library/ff561109.aspx. In parallel with reading MSDN I also checked the code in DDK you mentioned and try to understand it. I'm sure this solution could also work for you.
I wrote mine from the specs, there aren't really that many API's to implement.
The one thing that regularaly trips people up is EnumPorts, the spooler allocates enough memory for ALL the ports, not just yours. So you need to make sure you fill any strings from the end of the spoolers buffer, don't put them straight after your structures.
It doesn't say so in the specs but you can safely put the UI and Server functions in the same DLL.
It's also possible to create a single port monitor that supports NT and the later Windows 2000 type port monitors.
The code in RedMon is much easier to read than the localmon example, it's worth looking at before you start. It's quite nice because you can compile it in VS, you don't need to use the DDK to build it.
I have been over that exact same territory for a serial printer. About the best example I found was this article in Dr Dobbs Journal. The good part is that both a serial port driver and the user-space control program are covered and the project can also be used as an example of how to set up Visual Studio to compile a driver. This is also something a little difficult to find information about. The article discusses an old NT style driver, which worked well for me on XP.
There are quite a few good articles on CodeProject about writing drivers and programs to interact with them. They include source code and most deal with the newer WDM and WDF style drivers.
OSROnline is another good source, especially for discussion of specific issues and common mistakes. They also have some great utilities you will need.
Some of the most clearly written and understandable driver code I came across was Mark Russinovich's sample code. Although Microsoft withdrew all of the source when they purchased Sysinternals, some of the best examples can still be found cached here and there.
Drivers are pretty interesting. Whatever else you do though, do it in a virtual machine. Really.