on windows, is there any other option when programming network communication then using Winsock? There are many socket libraries for c++, are they all just winsock based?
You can consider using boost::asio. Boost is really great and well designed. Many parts of it have come already into C++0x. You will need to statically link to a lib or dll (it is not a header only template library)
Winsock are the sockets for Windows taken over from BSD (with actually exactly the same API excepting for closesocket vs close and the initialization/termination of the subsystem). Not the Win API itself has a more modern API the WSAxxx functions. C++ is socket unaware until now that means in order to do networking you MUST use the OS API, thus Winsock. There is no other low level API.
If you are trying to monitor traffic why don't you use WinPCAP?
There are other ways to program network communication, which don't use Winsock: for example, using the network file system (shared files), or using named pipes.
Software can also bypass Winsock (which is a Windows user-mode DLL) even for TCP/IP traffic, and instead interface directly with the kernel-mode drivers.
Related
EXE and DLL files usually come with lots of imports, some of them point to files located in System32 (Win APIs) and some of them point to files in the current directory. At some point an application likes to check for updates online, send feedback from customers and send crash reports to app developers so the application needs to initialize internet communications.
I have searched the WinAPI docs and found out that the InternetOpenA export in wininet.dll initializes communications through the internet, but....I did some testing and found out that it is not always true. Some applications can still connect to the internet without wininet.dll listed as an import.
How is that possible? Do those applications come with their own DLLs to connect to the internet, resulting in not being dependent on wininet.dll?
There are numerous HTTP(S) stacks in the Windows API and plenty of open-source and private stacks.
For the vast majority of these implementations of HTTP client libraries, they all need access to the TCP/IP stack in Windows, and the primary interface for that is the Winsock2 stack (ws2_32.dll).
HTTPS Stacks in Windows that build on top of Winsock include the following:
WinInet
WinHttp
URLMon
BITS
Some other 3rd party implementations built on top of Winsock include:
libCurl
Boost Beast
Likely many others.
Also, many programming frameworks including .NET, Java, Python, etc... have their own socket and http libraries as well.
There is no requirement that an application must use any of these stacks - they can roll their own on top of the Windows socket library or theoretically thunk down to a lower part of the network stack.
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.
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.
Anything higher-level, and more comprehensive than pipes/sockets?
For interprocess communication, D-Bus is the standard higher level mechanism. Both GTK and Qt have bindings for D-Bus, most desktop environments (or at least GNOME and KDE) expose various services via D-Bus, and many desktop applications can be controlled via a D-Bus interface. The system bus is also useful for finding out various low level information about the system using standard system services.
KDE4 (built upon Qt4) also includes a technology called KParts, which are often compared to Window's COM.
Yes, there are lots of things, but there isn't one as "Standard" as COM/DCOM. At least, in Windows, COM / DCOM are used by "Windowsish" stuff, and other RPC mechanisms are used by un-"Windowsish" stuff.
Linux doesn't have anything like that, instead things which need higher level RPC protocols typically use whatever their language provides, or a specific library which best suits an app's needs. Examples of that would be RMI in Java, Python's "pyro" module, etc, which will provide (some) functional parity with DCOM.
Corba is a bit heavyweight but some people apparently do use it.
A lot of applications roll their own RPC libraries. Don't do that unless you have to, it's nasty.
D-Bus
D-Bus uses a logical "Bus" over which connected applications may communicate
communication takes place via a simple object model that supports both RPC and publish-subscribe mechanisms
D-Bus includes a standard introspection mechanism for the run-time querying of object interfaces, applications connected to the bus may query for the availability of objects, call remote methods on them, and request notification for the signals they emit
before: GNOME Bonobo, KDE DCOP, CORBA, Sun RPC... nowadays people seem to prefer D-Bus
UNO
interface based component model, as are COM and CORBA
all UNO-interfaces must be derived from a interface that offers acquire, release, and a queryInterface method (comparable to COM)
the lifetime of UNO-objects is controlled by global reference counting.
components communicate only via their interfaces
o each component lives in a Uno Runtime Environment (URE), there is no performance overhead for components, that are instantiated within the same URE, e.g., in C++, a call from component A to B is just a virtual call
UNO-interfaces are specified in IDL
exceptions are used for error handling.
XPCOM
similar to Microsoft COM
Interfaces in XPCOM are defined in a dialect of IDL called XPIDL
disadvantage is that XPCOM adds a lot of code for marshalling objects between different usage contexts, which leads to code bloat in XPCOM based systems
...another alternative to consider might be Java RMI as well
It's also worth to see related questions:
Is there an equivalent to COM on *nix systems ? If not, what was the *nix approach to re-usability?
Analog of COM programming in Linux/UNIX
The Mono project jumps to mind. Mostly because the CLR/.NET is the new COM -- after all, COM was initially sold as language independent, binary compatible objects.
http://mono-project.com/
I guess DCOM (i.e. COM with a longer wire) would be .NET remoting? Or perhaps some web services with object serialization. I believe Mono supports both.
You can check out Corba, it works on Linux and Windows as well.
There is Mozilla's XPCOM technology, Cross Platform Component Object Model. Sort of similar to COM or DCOM conceptually.
Here is a list of the relatively few programs which do make use of the D-bus
DCOM is available on Linux. It isn't "the linux way of doing things", but hey, if you want "like DCOM, but Linux" then just use DCOM on Linux and have done...
https://web.archive.org/web/20071008135843/http://www.softworksltd.com/dcomlinuxfaq.html
I'm attempting to port a Linux application to Windows. The application isn't too complex, using all fairly standard code, with few external dependencies. The main dependencies are libelf (which compiles fine under mingw), pthreads (there appears to be a win32 version available), and sockets. The main problem is with sockets...Windows provides WinSock, but this is not 100% compatible with BSD (Berkeley) sockets as used by all *nixes. What I'm wondering is, has anybody written a wrapper on windows that exposes a BSD socket API, but calls Winsock on the backend, to ease porting?
I would recommend using cygwin.dll . It's built for bringing over *nixes to windows including sockets, file IO, etc.
For the most part, you'll just have to make sure that WSAStartup() and WSACleanup() are called at start and end, otherwise, basic BSD sockets will translate pretty well. You could create some static global variable that gets checked for each call to the socket calls, and call WSAStartup() and WSACleanup() accordingly. As for poll() ... well, it translates quite easily to select().