I really want to capture the packet on Windows 7
but i'm beginner of windows programming so I have no idea, how can I solve the
problem.
I know I can capture the packet by using DNIS but my computer is windows7 but
on the webpage there are only for windows 10 or windows 8.1
is there anyone let me know the information?
I know I can capture the packet by using DNIS
(Presumably "using NDIS".)
Yes, NDIS is the operating system mechanism that provides hooks for packet capture.
As you're asking on Stack Overflow, presumably you want to write a program to capture packets, rather than using an existing program.
You could write your own code to use NDIS (which works at least as far back as Windows NT 4.0, and probably earlier and, with different code, Windows 9x as well), but that's code that would run in the kernel, and that's a bit more difficult.
However, WinPcap and Npcap already have that kernel code, and a library that runs in user mode, providing the same API as libpcap on UN*X; the easiest way would probably be to install WinPcap or Npcap on your machine, along with the Software Development Kit for WinPcap or Npcap, and use that.
If you're programming in C or C++, you can use the API directly. In other languages, including .NET languages, there are wrappers for libpcap/WinPcap - see this list of wrappers, for example.
Related
I'm working on a USB device that will talk to a single application. It looks like we may want to have a Windows driver that presents a nicer software interface to the application. (As opposed to having the application itself send lower-level commands to the device via WinUSB.)
Is it possible to use WinUSB from within a DLL? Choosing a driver model for developing a USB client driver doesn't address that specifically.
Are there reasons in this situation that I should instead consider writing a UMDF-based or KMDF-based driver, or a hybrid driver that calls WDM routines?
Using WinUSB is probably the right way to go. You can definitely use WinUSB within a DLL. In general, you can write a DLL that calls functions in another DLL, and there is nothing special about winusb.dll that prevents you from doing that. Also, it is already done in other projects like libusb and libusbp, which compile to a DLL that uses winusb.dll.
I would also encourage you to make your code cross-platform: don't call WinUSB directly from your DLL, but instead use a USB abstraction library such as libusb or libusbp. Even if you only want to support Windows, these libraries are lot easier to use than SetupAPI and WinUSB, so they should save development time. They will also save a lot of time if you ever want your code to work on different operating systems.
I think the only reason to write your own UMDF or KMDF driver in a situation like this is if you need advanced features of the Windows USB stack that are not supported by WinUSB. For instance, if you needed to switch your device to a different USB configuration, or do tricky stuff with power management, or allow multiple applications to use the device at once. If you just want to send some data back and forth, WinUSB is a fine choice.
I've been on a little adventure learning about how Windows platforms deal with sounds. Now I know a couple of things from taking an Operating System class and reading this:
IO devices such as a sound card communicate with the OS through a device driver. Microsoft supplies a standard so that in kernel mode the OS can make certain system calls (in this case Win32 api calls) to make an I/O device do something. Bytes or characters are streamed to over buses to whatever port the I/O device resides in. These are interpreted by the device controller as instructions for the physical hardware.
There are OS calls to prepare audio devices and stream data to them. Actually for some reason their are 2 ways to do this: MMSystem and DirectSound. I think the reason there are 2 has something to do with gaming? Like DIrectSound was more geared toward that while MMsystem was more standard apps that need audio?
Beyond that their are also other audio APIs NOT written by microsoft for the Win32 platform. ASIO and GSIF.
How can these non Microsoft standards exist on the Windows platform? How can they possibly communicate with hardware or the OS? With something like openGL(something else I toy with), a version of Windows supports a version openGL standard and so does you GPU. BAM, easy-peasy no problems, everything checks out.
How I see it can be is:
MMsystem and/or DirectSound are not part of Win32, but there is some even lower level windows kernel driver everyone is keeping a secret because it's really ugly or
These other driver API's are built on top of the Microsoft supplied ones
Can someone please clarify? Where am I mistaken, I am missing something. I own my old OS textbook still(Modern Operating Systems 3rd Ed. by Tanenbaum) so if you want to point at something in there, go for it.
How would I go about creating a "gamepad" which appears to DirectInput applications as a normal game controller but the state of its controls is actually defined by software?
Write a device driver to pretend to be one.
Specifically, Windows device drivers handle what are called Interrupt Requests via the Interrupt Request Protocol - which boils down to a wrapped up structure and a set of buffers internally in the driver.
Now the next thing you need to know is that many drivers are actually layered, or stacked, or whichever name you want to use. So for example to write a disk driver, you might interface with the driver above it (as a disk class) but use a driver below it (scsi port, for example) to actually send commands to your devices.
That's how real devices work. Fake devices need to conform to the top level interface requirements, e.g. a disk, or a controller, or a mouse, or whatever it is. However, underneath they can do anything they like - return whatever values they like.
This opens up the possibility of controlling a driver via a user-mode application and pretending to "be" a device. To send a driver messages, you can DeviceIoControl to it; then to actually get those messages you can either:
Stuff them in the Irp that makes up that DeviceIoControl.
Have the driver read them out of your process' memory space.
Drivers can also access \\Registry\\Machine and various other, non-user-specific non-explorer registry areas, so it is possible to communicate that way.
Finally, there's no saying you can't filter existing IO, rather than make it all up via a new device. There are a great many options and ways you can go about doing this.
If you're going to do this, you'll need:
VirtualKD or an expensive debugger cable and two PCs.
You probably also want to start with the references on this blog post. You'll find that there are essentially a bazillion different names for driver code, so I'll interpret some of them:
WDM = Windows Driver Model, basically the NT driver model mixed with (some of) Windows 9x.
KMDF = Kernel mode driver framework - drivers of the above type use this, plus additionally WDF (Windows Driver Foundation) which is a set of libraries on top of WDM to make it quicker to use.
UMDF = User mode driver framework - write a driver without the danger of kernel mode. If you can, use this, as kernel mode drivers that go wrong will bluescreen (in driver parlance, bugcheck) your system.
Edit: I'm not massively knowledgeable on DirectInput - there may be a way to override the various API controls in use via DLL redirection and the like, which may be simpler than the way I've described.
There is vJoy opensource project: http://sourceforge.net/projects/vjoystick/ - can be worth looking at.
The easiest solution may be to emulate an XInput device (Xbox 360 and One). These are supported in most modern games and the set up is very simple. Here is a C++ project here that provides this without any installed drivers or external dependencies: https://github.com/shauleiz/vXboxInterface/
I know it is an old question but for anyone which is interested in this topic it is also worth looking at this project called ViGEm.
You can emulate some well known gamepads like Microsoft Xbox 360 Controller, Sony DualShock 4 Controller and Microsoft Xbox One Controller. The project offers also some API to interact with these virtual controllers. E.g. the C# API can be found here
The simplest solution I found was using vJoy and its C# wrapper.
You need to download the vJoy driver from here.
You can use the vJoy SDK for implementing a feeder program: https://github.com/njz3/vJoy/tree/master/SDK/c%23
Use the C# starter project for this, or simply add the two .dll-s to your existing project as references from the x86 or x64 folder.
You can find instructions on how to use the api in the readme.odt file.
I am into new project, which should use microcontroller. The easiest way to program it is using parallel port. But, there are few things I hope you can help me with. Oh, and the preferred language is C and platform Windows.
So, I studied LPT ports and Windows a bit, and from what I learned the most important is: Since Windows NT based systems, you cannot use instructions for direct port manipulation. This should be, because now programs are run in different privilege mode, which doesn't support the kind of instructions that are used by outport() function.
But at this point, I don´t understand a few things. First, I thought that Windows actually used privilege levels since first protected mode version, but that's the wrong assumption.
But more importantly, I thought that Windows has included functions for just about any hardware communication. I mean, anything you do in Windows these days, you just call windows functions which further call kernel services. I assumed that outport() doesn´t use any Windows function, and just makes the communication itself, which is prohibited now. But I am literally shocked that there is no system function to control parallel ports in modern Windows systems. At least that's what I read.
But even if I could get the control of parallel port, there comes my second problem.
For programming the controller, I need to follow special protocol, especially timing. But since Windows is multitasked, I worry about what if Scheduler switches to another app, and therefore when is the right time to switch signals on LPT, my program just will not be able to run.
Oh, by the way, I know I could use any 3rd-party apps, but I just like to be able to do it myself, or at least before I use some 3rd-party app, I want to know how it works. And yes, you can program some microcontrollers just by parallel port with some resistors, I know this for sure.
Thanks.
For windows you need to install a DLL which contains a driver to run at elevated privileges to get access to the HW ports.
You can find such a library at :
http://logix4u.net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_98/2000/NT/XP.html
There are also some links to sample code.
I do not know which uController you are using, but I programmed in the past a variety of them and never had issues with timings, well for programming at least. The programming protocols are usually robust enough to deal with the jitter caused by multitasking. Just keep your clock edges and signa edges well separated and it should go fine.
In a nutshell, I want to write my own device driver for windows, so that I can emulate a piece of hardware. I know very little about writing device drivers for windows, but I have a very firm understanding of the C and C++ languages, and I know enough x86(_64) assembly to get around.
I'm not really sure how one would go about even compiling a device driver, or what is required to create one. I'm certainly not against coding the entire thing in assembly if that needs to be done, but does it?
I'd like to do this using Windows tools obviously, I'm planning on trying to put it together using a windows GCC compiler, but I've got access to Visual Studio if that's needed. Can someone point me at resources that would be helpful, like reference manuals, tutorials, specs?
Oh: My target OS here is Windows 7, 64bit, which if I understand should be the same as Windows Vista 64bit, but correct my wrongness if it exists.
Thanks.
Everything you need to build your driver (including the compiler) comes from the WDK. Everything you need to know what to write comes from Walter Oney's books. Be prepared for a rough ride.