I have two separate c++ applications (running on Windows 10) that need to communicate with each other on multiple UDP ports. Both applications are running on one machine so I am just using the localhost IP on both ends. The first application is a robust control program that generates a lot of data that is sent out on these ports. The second application is a basic server that is designed to receive and process all this message traffic and occasionally send commands back to the first application.
When running in Visual Studio everything works as expected however running from the command line or a bash script my server app receives all the data as expected, but I cannot sending data to the control app.
I have tried tweaking the Windows Defender and symantic settings with no luck. Is it possible something else is blocking communication only in one direction? And why does it work in the Visual Studio debugger but not when running the executables from the command line?
Related
I am developing the test suit in C++ for the PDA-like device running Linux.
While working with development kit I have access to a serial console with system output. Eventually my software should be used on closed box with no console output and Ethernet connection available. I would like to be able to duplicate the entire console output (not only my code output, that would be easy). Any suggestions?
The SSH to the device is working, but apparently it only echoes the commands and responses I send from the remote console. I would like to sniff in on all system output from previously started applications and kernel.
Some Background -
I have written a C program on the TS-7800 (running Debian Linux) which I access through Putty. The program is essentially in charge of controlling DAC/ADC's in order to modify the state of a memory element.
My next task is to develop a GUI for that program. The GUI is built using Microsoft Visual Studio 2010 in C++. I've made most of the GUI and simply need a way to send the data which I collect to the Linux machine.
My first attempt was to invoke a connection with Putty through command line from the GUI, and then try to send various commands through that Putty connection. The drawback here is that once I invoke a connection with Putty using the command putty username#192.168.1.50, it is done in the foreground, rather then hidden in the background, and I don't know how to continue entering text/commands from the GUI into Putty once it has been launched.
My Question -
How should I go about connecting my GUI on Windows to the program on the Linux machine? Is my attempt with Putty a step in the right direction, or should I be taking a different approach - possibly Cygwin?
Thank you in advance for any help - this is my first post on stackoverflow so please forgive me if I've mistakenly overlooked some detail or if I did not abide by proper etiquette.
You have to follow some protocol to interact with the server. Then your GUI needs to follow that protocol to send commands to the server.
Probably, you are talking about SSH connection with server. There are a lots of SSH Client library available in windows. You can use one in your GUI to interact.
Try taking a look at Boost ASIO. It's a very solid asynchronous IO library included in boost. (You will need to build it however).
I have created a c++ command line application. This application sends a revives messages from other computers and logs the results to a file. A simple application. One of the first things the app does is write to the log file the start up time.
Now that I have gotten the application to a good place, I want to install it as a service that runs on my computer (win 7).
I am using the NSIS, Simple_Service_Plugin to install the application and register the service in windows. I can see the service in windows service manager.
When I attempt to start the service, I get the following error message. The log file does not get created.
Windows could not start __THE_APP__ service on Local Computer.
Error 1053: The service did not respond to the start or control request in a timely fashion.
When I start the app from explore it starts without any problems and the log file is updated correctly.
When I search this error message on-line I find lots of help for C# and .Net applications and nothing for c++ apps.
My question is:
How do I start a C++ application (not dot.net) as a service?
A service isn't a regular appliction. It's a program that uses specific system classes and implements certain features that enable the OS to communicate with it.
See here (and the surrounding pages) for more details.
There seems to be a set of commands to programatically modify Firewall rules on Windows Server 2008. I have an app that handles a set of sockets, and from time to time it gets a DDoS.
I want to block some IP addresses from receiving the SYN-ACK on the TCP handshake. How can I do that from C++ in MS Visual C++?
As Microsoft only published VB script samples,
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366415%28v=vs.85%29.aspx
You have to translate them to C++ manually if you don't want to call netsh command in your applications.
Generally speaking, there are a few COM objects you can use, such as HNetCfg.FwMgr. The VB script samples show how to use them properly.
Other references:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366449%28v=vs.85%29.aspx
I have an app that I have to debug. It is C++ on Windows Mobile 5.0, and it uses a network connection via WiFi. (Visual Studio 2008.)
Disconnected from USB and active sync the app connects to the network just fine, but as soon as I plug it into the cradle, (and consequently connect via ActiveSync) it automatically disables the WiFi network, and I can't seem to find anyway to turn it back on.
I need ActiveSync to control the program in the debugger, and I need WiFi to have the application run, but I seem to only be able to have one or the other.
Does anyone have any ideas? Please save me from having to resort to debugging via printf statements :-)
Don't use ActiveSync - debug directly through the WiFi connection.
I've recently been having reliable fortune debugging over WiFi. The magic seems to be configuring the device's transport IP address and using ActiveSync to jump-start the process.
(I'm using Visual Studio 2008 on a Windows 7 (x64) system; and a Windows Mobile 6.5 device, in case it matters.)
Start up copying the five files listed below unto the mobile device.
Make sure your WiFi is connected and your WM device had a valid IP.
Inside Visual Studio, select Tools .. Options .. Device Tools; then select Devices
Select the "Device" you want to debug; I used "Windows Mobile 6.5.3 Professional Device"
Properties
The Transport should be "TCP Connect Transport", click Configure.
Select "Use a specific IP address" and enter the address.
Exit the dialogs
Connect the WM device via ActiveSync; connect the project to the device within Visual Studio and run it (inside the VS debugger).
Exit the application, waiting to make sure the debugger completes normally.
Disconnect the device from the USB ActiveSync connection.
Run CMAccept (see below) on the mobile device
Run the debugger. (Don't wait to long, because there might a time-window.)
With any luck, the app will start just as if it were still connected to ActiveSync. You can even compile and deploy updated files without needing to reconnect ActiveSync.
First time this worked, I think my jaw hit the ground; I stumbled upon it by chance and simply couldn't believe it was working.
[Debugging on CE5.0 device without ActiveSync] discusses this for Visual Studio 2005 beta2; it seems to be relevant. (This link is also cited in another answer to this question).
The instructions include copying 5 files from host \Program Files\Common Files\Microsoft Shared\CoreCon\1.0\Target\wce400\<CPU> to \windows on the device.
I copied the 5 files from \Program Files (x86)\Common Files\Microsoft Shared\CoreCon\1.0\Target\wce400\armv4 to \VSDebugFiles on my device (expecting to experiment with them). What I did find was that, if Visual Studio refused to connect following the above steps, running CMAccept on the device would help.
In case the link is ever removed, the five files are:
clientshutdown.exe
CMAccept.exe
eDbgTL.dll
CommanClient2.exe
TcpConnectionA.dll
Ok, I admit that this is still very hit or miss, but it is hitting more often than not.
If you don't have a convenient way to check your device's IP, try VxUtil; it's my go-to network utility for validating Windows Mobile network connections.
Good luck, hope it works.