I am porting a communications library from Linux to Windows. I know what my approach is for the most part. The library uses all raw ethernet level frames for all the communications.
The library I am porting from makes use of the PF_PACKET family and the struct sockaddr_ll. After browsing through the MSDN winsock site, I haven't found an equivalent family/struct. What should my approach be here?
I have a few ideas, but I am not sure if they are good ideas
I could use PF_UNSPEC, for unspecified.
I could just pass the number PF_PACKET represents (it's an unsigned short)
I could also just make my own sockadddr_ll struct in Windows.
None of those ideas seem good to me, they just seem like hacks that aren't really likely to work.
If anyone has any suggestions, I would appreciate it.
I assume you're referring to Raw Sockets (where you have to write the network layer, transport layer, and application layer information). New Windows versions (XP SP2 and up) have very limited support for raw sockets with many restrictions.
More info (scroll down to "Limitations on Raw Sockets")
The solution, I believe, is to use WinPcap, which allows you to send raw packets on those systems.
Related
There are a few programs like Proxifier that can force an exe to use a proxy. There are a few others, too. But the sites all look a bit shady. I don't even trust Proxifier tbh... So I'd like to know how these programs work. How do they do it? Is there a WinAPI function that can be used to do that? Or do you have to actually inject code into the processes?
I was only able to find functions to change the global proxy of windows. But some programs don't care what the global proxy says, they always try to connect directly, even if it's not possible...
Proxifier is based on LSP (layered service provider), but personally I never liked this technology because of often stability issues. However, besides LSP there are other possible approaches suitable to achieve the same functionality, you can find a short coverage of network filtering methods (including LSP) here: https://www.ntkernel.com/ndis-hooking-drivers-and-legacy-windows-systems/, however the document is a little bit out-of-date, I have written it in times of early Windows XP dawn and it does not cover WFP (Windows Filtering Platform), which replaced TDI, and NDIS Lightweight Filter, which replaced NDIS Intermediate and NDIS-hooking drivers. Both technologies were introduced by Windows Vista along with NDIS 6.0.
I think Wininet.dll is the canonical method for accessing HTTP from user mode programs on Windows. (The documentation for Windows Networking and Internet support is here. I didn't want to go through all of the doc, but I'm pretty sure Wininet.dll is the right one)
One method for doing a per process proxy, is to write a DLL that acts like Wininet.dll (and sits on top of the Windows' Wininet.dll). Your Wininet would have some sort of mechanism (registry, config file, etc.) to determine whether a particular process is to be proxied or not. If process isn't proxied then all calls go through to original Wininet, but if process is proxied then your Wininet does the redirection.
Another, somewhat similar, injection point is at the winsock layer (ws2_32.dll). (Back in the Windows 3.1, Win95 era, it was fairly common to replace winsock.dll (ws2_32 predecessor) by vendors of TCP/IP stacks.) Here's a case where the same concept is used to capture traffic at winsock layer. The article at the link has a nice diagram that illustrates the concept as well as implementation details of replacing ws2_32.dll.
The modern way to do this is to use Windows Filtering Platform.
https://en.wikipedia.org/wiki/Windows_Filtering_Platform
https://learn.microsoft.com/en-us/windows/win32/fwp/windows-filtering-platform-start-page
Windows Filtering Platform (WFP) is a set of API and system services
that provide a platform for creating network filtering applications.
The WFP API allows developers to write code that interacts with the
packet processing that takes place at several layers in the networking
stack of the operating system. Network data can be filtered and also
modified before it reaches its destination.
I'm trying to implement an AVRCP/A2DP connection between my Android phone and my car PC. The A2DP bit basically works out of the box so no issue there. I want the PC to be the AVRCP CT (controller) and the A2DP sink. The phone is the AVRCP TG (target) and the A2DP source.
Where I'm having trouble is getting any sort of AVRCP connection that I can use. Windows 7 comes with a toolbar application that at least provides the basic play/pause/skip/stop type functions. So it definitely works with the software I have without any extra drivers or otherwise. However my searching has produced little results on any way to do this or documentation on creating an L2CAP connection which I believe I need.
The 32feet.NET libraries don't support L2CAP connections unless you use a Broadcom/Widcomm stack. Buying a new BT USB device may be a viable solution but at the moment I'm trying to do this all in software :). i.e. like this although there a problems noted there that weren't solve (or reported as solved)
link: How can I establish an AVRCP connection from Windows 7 (controller) to phone (target) using L2CAP on Widcomm SDK?
I'd prefer to do it C# if possible but if I had some kind of library to interface with my code, that would be fine (like the 32feet.NET library which works quite well for the things it does work on.)
This is about the closest I've got but is all a bit Greek to me and not quite enough to get me started (I'm an embedded guy):
http://msdn.microsoft.com/en-us/library/windows/hardware/ff536674(v=vs.85).aspx
Is Bluetooth really such a mess on Windows that it seems to be from my searching? There are multiple different stacks that all seem to be significantly different in terms of the API etc.
Can anyone point me in the right direction? I've done a lot of searching/reading other posts here and elsewhere and not really made any progress.
Thanks
Christian
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 know this probably is not the easiest thing to do, but I am trying to connect Microcontroller and PC using USB. I dont want to use internal USART of Microcontroller or USB to RS232 converted, its project indended to help me understand various principles.
So, getting the communication done from the Microcontroller side is piece of cake - I mean, when I know he protocol, its relativelly easy to implement it on Micro, becouse I am in direct control of evrything, even precise timing.
But this is not the case of PC. I am not very familiar with concept of Windows handling the devices connected. In one of my previous question I ask about how Windows works with devices thru drivers. I understood that for internal use of Windows, drivers must have some default set of functions available to OS. I mean, when OS wants to access HDD, it calls HDD driver (which is probably internal in OS), with specific "questions" so that means that HDD driver has to be written to cooperate with Windows, to have write function in the proper place to be called by the OS. Something similiar is for GPU, Even DirectX, I mean DirectX must call specific functions from drivers, so drivers must be written to work with DX. I know, many functions from WinAPI works on their own, but even "simple" window must be in the end written into framebuffer, using MMIO to adress specified by drivers. Am I right?
So, I expected that Windows have internal functions, parts of WinAPI designed to work with certain comonly used things. To call manufacturer-designed drivers. But this seems to not be entirely true becouse Windows has no way to communicate thru Paralel port. I mean, there is no function in the WinAPI to work with serial port, but there are funcions to work with HDD,GPU and so.
But now there comes the part I am getting very lost at. So, I think Windows must have some built-in functions to communicate thru USB, becouse for example it handles USB flash memory. So, is there any WinAPI function designed to let user to operate USB thru that function, or when I want to use USB myself, do I have to call desired USB-driver function myself? Becouse all you need to send to USB controller is device adress and the infromation right? I mean, I don´t have to write any new drivers, am I right? Just to call WinAPI function if there is such, or directly call original USB driver. Does any of this make some sense?
To make your life easier, and avoid writing your own driver, try using the HID (Human Interface Device) API on top of USB. Although it says "Human Interface", it doesn't actually have to be for devices that a human controls. The advantage is that modern OSes already come with a HID driver and you can use sample code such as what you can find here to get started. Many microcontroller manufacturers provide suitable code for the embedded of the protocol.
Because OSes already understand HID, if you build a device using the HID interface you'll find that not only can you read from it from any OS, you may also find that many applications can already talk to your device if its communication is restricted to a small enough subset of HID. (For example, I built an input device for a music app, but amazingly I found I could literally plug it straight into a 3D animation app we use at work, running on a different OS, and have it work right away without writing a single additional line of code!)
This answer might aim you in the right direction.
The first answer here might also be helpful.
The answers to this have some actual code and links to yet other resources.
USB includes a set of stock functionality, much like supporting USB flash drives (USB Mass Storage class). The two most interesting for microcontroller interfacing are HID and CDC. CDC is easiest to use as it directly emulates an old fashioned serial port.
If you configure the microcontroller to act as a CDC device, Windows will enumerate it as a serial port, and all the old serial APIs will work on it.
I am working with a peripheral device that needs to be communicated through serial. I can send it commands using HyperTerminal, but now I need to write programs that will let me do it without HyperTerminal. Can somebody point me to a website and/or show me a sample hello world program to get me started? I have searched through many sites which give me uncompilable/ancient VC6 code.
In order to interface with the serial port, you open a file with one of the special filenames "COM1" through "COM9". For serial ports with higher numbers, the special filename begins with \\?\, which in C/C++ code must be escaped as "\\\\?\\COM10", etc.
http://msdn.microsoft.com/en-us/library/ms810467.aspx has a really good tutorial on using the serial port. Note that you should use the Windows file I/O functions such as CreateFile(), ReadFile(), and WriteFile(). I'm not sure if it will work to use standard I/O functions such as fopen(), fread(), and fwrite().
Microsoft provides an article with sample code describing how to do this under Win32.
Boost:asio may be able to help as a serial device was added recently.
Fair warning though; the serial port documentation is light, presumably since it's quite new (it was added in asio 1.1.1 which was included in boost 1.36).
But working your way through asio is, IMHO, a better solution than using the raw Win32 API. Why? It'll be easier to read and maintain (it's a higher level API) and it'll be cross platform (except where you need to specify the OS-specific device name).
The Boost - Users and asio.user mailing lists are quite active and friendly and ought to be able to help you out if you get stuck.
If using .NET 2.0 see System.IO.Ports and this article should be helpful. If direct Win32, then Adam's answer is best.
I believe you will find plenty of sample code for C# as well if you find VC6 too ancient. I think there are also a bunch of "free" serial/COM port wrappers but I just wrote my own when I wrote an RS232 device controller piece of software.
google C# and serial port or rs232
I got these:
http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.aspx
http://msmvps.com/blogs/coad/archive/2005/03/23/SerialPort-_2800_RS_2D00_232-Serial-COM-Port_2900_-in-C_2300_-.NET.aspx
You should have no problem finding suitable code with a google search.