D-Bus Remote Controlled Car Example - c++

I try to send integer value from one to another programme using for IPC QtDBUS(they are different executable files). My attempts to find simple example was unsuccessful. So, I am forced to build huge example D-Bus Remote Controlled Car Example like for one who has never used QtDBus. I repeated full tree structure(sources, headers). But one file controller.h includes #include “ui_controller.h”. There is no such file. So, I am not able to compile.
Maybe, is there something that I don’t understand?
http://s016.radikal.ru/i336/1112/ad/d4f681cbc2cd.png

Yes, ui_* files are generated in the build process. You can find the complete sources of all the dbus examples, including the one you're referring to here.

Related

How can I find the implement .cc file in Omnet++ INET's examples

I'm a fresh newer studying INET in Omnet now. I try to find out how the INET's examples like tutorial wireless networks work, but there are only ned and ini file in that directory without cc file. So I am very confused how this network works. Anyone can tell me how can i find it ?
There are no C++ files in INET examples because the whole behaviour of every module, protocol, channel, packet etc. used by INET has already been defined in C++ files in src directory. The compiled and ready to use code is present in file src\libINET.dll (or src/libINET.so for Linux). To get to know how a protocol was modelled look inside a module and look for simple modules. (In OMNeT++ the behaviour is defined only for simple modules.)
For example:
In the examples\wireless\lan80211 there is Lan80211.ned. Open it in source (text) format. This network uses (between other things) WirelessHost.
Go to declaration of WirelessHost (Hint: select this word and press F3 or click this word holding Ctrl). One can see that WirelessHost inherits from StandardHost and from NodeBase. Moreover: numRadios=1 and mgmtType = "Ieee80211MgmtSTASimplified".
In NodeBase.ned one can see that it uses Ieee80211Nic wlan module by default. The module Ieee80211Nic is defined in src\inet\linklayer\ieee80211\Ieee80211Nic.ned.
Looking inside Ieee80211Nic one can see that it uses Ieee80211Mac (between other things). This is a simple module defined in \src\inet\linklayer\ieee80211\mac\Ieee80211Mac.ned. And its behaviour is defined in \src\inet\linklayer\ieee80211\mac\Ieee80211Mac.cc.
This way one can discover a simple module and its C++ code of every compound module. However, take into account that to understand how the compound module works the connections between simple modules should be considered too.

How can I send OSC packets simply in windows/C++?

I have a VS2010 project which is a windows application that acquires data from a particular bluetooth device. All I want to do is alter my acquisition thread to send the data it acquires using OSC.
I spent a long time trying to use a library called LIBLO but it appears to function using POSIX style asynchronicity. I spent even more time trying to make pthreads-win32 work for me so that I could still use this library but still had no luck.
I switched to trying to use the OSCPACK library which I could not get to compile using the batch file included in the release. I was eventually able to get my VS2010 project to recognise the library but all I get now are linker errors (LNK2019 and LNK2001). The relevant directories are listed in "Additional Include Directories" in the project properties. I know this should be something easy to fix but after a day of frustration I am at my wits' end. I am used to working with xcode in osx so find it difficult to accomplish anything in VS2010. Do I need to give additional instructions to the linker?
can anyone either suggest a simple, prebuilt OSC library compatible with windows/VS or how I can fix my problem with unresolved externals?
OSC is a very simple protocol, especially if you only need to send outgoing OSC messages and don't care about receiving (and parsing) incoming OSC messages. One thing you can do is simply read the spec and look at some examples and write your own function that adds OSC data into a byte buffer in the prescribed format. That's only a few hours of work to do. Then it's just a matter of sending that char buffer out over a UDP socket, which is also quite straightforward to do. Depending on your needs, that might be easier that trying to integrate with a third-party OSC library (which I agree can be frustrating, especially under Windows).
Another possibility is to use OSCPACK, but instead of trying to build it separately and then link to the resulting DLL/LIB file, simply copy the necessary OSCPACK .c files directly into your own project's source tree and compile them in to your executable the same way you compile your own code. That will avoid any annoying build/link issues that can come with trying to get two different build systems to work together, and it also gives you full control over your (bastard) copy of the OSC code... e.g. if you want a particular function in OSCPACK to work differently, you can simply modify your copy of that function. (If you do that, be sure to make it obvious that the code is no longer 'stock', to avoid confusion... and of course try not to modify it in such a way as to break protocol compatibility with other OSC-using software)

how to get trusted time in an app, ntp maybe?

My app will need to periodically access a trusted time source, so can not rely on system time since this one can be modified easily by user or batery failure etc. My first idea is to statically link to libntp (from ntp.org) and use its functions, is this a good idea?
Libntp looks a bit complex framework, is there some simpler, client implementation (preferably ANSI C since the app needs to be for different platforms... though can be also Cpp if can be compiled with gcc / MS VS)?
Is there some other alternative to ntp?
Thanks!!
Edit: Just to add some more info... it is important that the trusted-time-server values can not be modified (lets say, attacker modifies the trusted-time-server response and app accepts fake time). I started looking at ntp and see that it takes care of that issue. The question is now should i use ntp sources from ntp.org as a starting point or there are some simple client-only implementatios? Ideally, some pointer to which module / source files from ntp.org sources should I use for client-only implementation and which header file shows the API I need to use, like for example a call getTrustedTime()... etc.
If you can rely on there being a network connection, your application could ask a remote server for the time, perhaps also over a signed or encrypted connection.
If you are using Boost you could use this

Versioning executable and modifying it in runtime

What I'm trying to do is to sign my compiled executable's first 32 bytes with a version signature, say "1.2.0" and I need to modify this signature in runtime, keeping in mind that:
this will be done by the executable itself
the executable resides on the client side, meaning no recompilation is possible
using an external file to track the version instead of encoding it in the binary itself is also not an option
the solution has to be platform-independent; I'm aware that Windows/VC allows you to version an executable using a .rc resource, but I'm unaware of an equivalent for Mac (maybe Info.plist?) and Linux
The solution in my head was to write the version signature in the first or last 32 bytes of the binary (which I didn't figure out how to do yet) and then I'll modify those bytes when I need to. Sadly it's not that simple as I'm trying to modify the same binary that I'm executing.
If you know of how I can do this, or of a cleaner/mainstream solution for this problem, I'd be very grateful. FWIW, the application is a patcher/launcher for a game; I chose to encode the version in the patcher itself instead of the game executable as I'd like it to be self-contained and target-independent.
Update: from your helpful answers and comments, I see that messing with the header/footer of the binary is not the way to go. But regarding the write permission for the running users, the game has to be patched one way or another and the game files need to be modified, there's no way to circumvent that: to update the game, you'll need admin privileges.
I would opt for using an external file to hold the signature, and modify that with every update, but I can't see how I can guard against the user spoofing with that file: if they mess up the version numbers, how can I detect which version I'm running?
Update2: Thanks for all your answers and comments, in truth there are 2 ways to do this: either use an external resource to track the version or embed it in the main application's binary itself. I could choose only 1 answer on SO so I did the one I'm going with, although it's not the only one. :-)
Modern Windows versions will not allow you to update an installed program file unless you're running with administrator privileges. I believe all versions of Windows block modifications to a running file altogether; this is why you're forced to reboot after an update. I think you're asking for the impossible.
This is going to be a bit of a challenge, for a number of reasons. First, writing to the first N bytes of the binary is likely to step on the binary file's header information, which is used by the program loader to determine where the code & data segments, etc. are located within the file. This will be different on different platforms (see the ELF format and executable format comparison)--there are a lot of different binary format standards.
Assuming you can overcome that one, you're likely to run afoul of security/antivirus systems if you start modifying a program's code at runtime. I don't believe most current operating systems will allow you to overwrite a currently-running executable. At the very least, they might allow you to do so with elevated permissions--not likely to be present while gaming.
If your application is meant to patch a game, why not embed the version in there while you're at it? You can use a string like #Juliano shows and modify that from the patcher while the game is not running - which should be the case if you're currently patching anyways. :P
Edit: If you're working with Visual Studio, it's really easy to embed such a string in the executable with a #pragma comment, according to this MSDN page:
#pragma comment(user, "Version: 1.4.1")
Since the second argument is a simple string literal, it can be concatenated, and I'd have the version in a simple #define:
// somehwere
#define MY_EXE_VERSION "1.4.1"
// somewhere else
#pragma comment(user, "Version: " MY_EXE_VERSION)
I'll give just some ideas on how to do this.
I think it's not possible to change some arbitrary bytes in the executable without side effects. To overcome this, I would create some string in your source code, like:
char *Version = "Version: AA.BB.CC";
I don't know if this is a rule, but you can look for this string in your binary code (open it in a text editor and you will see). So, you search and change this bytes for your version number in the binary file. Probably, their position will vary each time you compile the application, so this it is possible only if that location is not a problem for you.
Because the file is being used (it's running), you have to launch an external program that would do this. After modifying the file, this external program could relaunch the original application.
The version will be stored in your binary code in some part. Is that useful? How will you retrieve the version number?

program to monitor read/writes PATH of a program?

I was trying to make a program for a college project, but I got stuck at this:
How will you monitor a program as to what files it writes to or reads from?
I wish to have their path names.
To make the problem more clear, here is an example:
Consider the program we wish to monitor is a.exe, and a.exe first opens a file named "a1" residing in the same folder as a.exe, and then opens another file named "a2".
The program has to give the relative or absolute path of "a1" and "a2" files, irrespective of them being opened for read/write..
How do I implement this in C++?
EDIT : Is it possible to divert the calls for a1 and a2 files to another path??
EDIT2 : ok, let me put it this way: i have moved the firefox.exe from C:\program files to D:\, now when i run firefox.exe it wont work coz it works on many files that are there in C:\program files, firefox.exe would be using relative paths for accessing the files. What i intend to do is to capture the calls for the files firefox.exe works on and then direct the call to the program files folder. Plz let me know if i have made myself clear..
On linux you can you use 'strace' wich output the different system calls performed by your application. If you need to implement a program which perfoms the same kind of output as strace, a quick implementation could consists in a simple shell program which greps the output of strace. Otherwise looking into the strace code is a good start.
On Windows 'Process monitor' from Sysinternals suite may help you out.
If you want to modify the arguments to open(2), creat(2), truncate(2), and so forth, then you could use the Linux ptrace(2) facility to intercept the systemcalls and replace the filename strings before executing the call.
ptrace(2) is dark magic, so unless it's an advanced course, it might not be what your professor intended. (If the next lecture is on writing a debugger like gdb(1), then this is exactly what your professor intended.)
Another mechanism you can use, and probably much more portably, is library or function interpositioning -- you can write little wrappers around specific functions in a library, and by loading the library with the LD_PRELOAD environment variable (see the ld.so(8) manpage for details on the environment variables that influence library loading), your functions will be called instead of the standard functions.
Library interposition is grey magic; it's better documented than ptrace(2), but still pretty easy to screw up.