i'd like to make a function that can move a window in Linux in C++ by its PID. So I've tryed in under Windows. But I have trouble to compile it for Linux.
Is there any mean to do it with Qt ? Since I haven't found one, I've tryed to compile for Linux.
I'm using the MoveWindow function, which is part of the Windows API. Is there any Linux equivalent ?
You don't have to do that by hand if you don't really want to as there already are lots of tools out there, that can perform such tasks as moving, resizing, maximizing and whatever windows.
One tool you might want to take a closer look upon goes by the name of wmctrl even if you don't intend to use maybe you'll find some interesting tricks by taking a look into the sources.
The task of moving a window only known by the pid of the client that created the window might not be the easiest tasks of all for a couple of reasons.
First of all you really shouldn't try to do this as in the X Windows philosophy it is the job of the window manager to arrange the windows on the screen.
As well ICCCM (see: http://de.wikipedia.org/wiki/Inter-Client_Communication_Conventions_Manual) as the EWM spec (see: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html) strongly discourage any client from trying to move resize or whatever on its own. Most probably moving windows "owned" by another client might be considered even bigger evil.
The second problem you might face is, that the X 11 protocol doesn't have any notion of pid.
As it was designed to be used over a network you never can't be really sure the program runs on the same machine as the one you are currently sitting in front of. As such there isn't much sense in something like a pid as by chance there might be any number of clients with identical pids displaying windows on the same X Server if they ran on different machines.
Fortunately enough it is not all that bad, as the EWMH spec encourages any client to set the _NET_WM_PID property on its top level window the the pid of the client that created the window.
Again adhering to the EWMH spec isn't enforced by the X Server in any way so that while practically propably almost all clients will set it there's still no guarantee you'll find the window belonging to a specific pid.
Possibilities
While the whole points mentioned until here might seem rather limiting in fact most probably rather the opposite is true. Even because practically it is relatively easy to totally mess up any other client running in an X session the whole set of rules about how to be a good citizen in the X word were introduced.
As the X11 protocol itself is a network protocol (well not 100% true as locally running clients most probably will be communicating with the X Server via a UNIX domain socket) there isn't any specific library required to talk to the X Server.
Talking about C as mentioned in your question the Xlib has long been the one and only one implementation in wide use but there's also another binding called xcb. With a slightly changed API in comparison to the Xlib.
Xlib
Speaking Xlib I've never ever used any xcb until now, so I can't tell you too much about it might be the following methods that might be of use.
XOpenDisplay - open connection to the X server
XQueryTree - aquire the tree of windows currently alive on the server
XInternAtom - no fear it isn't dangerous. Just read about it in the manuals as you'll need it the get the "atom" mapping to _NET_WM_PID mentioned above
XListProperties - search for the _NET_WM_PID property with the value you are looking for
XConfigureWindow, XMoveWindow, XResizeWindow, ... - to finally perform whatever you wish to do.
All functions mentioned above should be documented in the manual pages. Just use man XOpenDisplay for example.
Oh, and be sure to learn about all the other tools at your disposal to further investigate about the X Window world. Run xlsatoms, check what xwininfo reports an take a list at the output of xprop for one single (!) window alone. Try to set some yourself to see what happens xprop will even do that for you if you ask politely.
Related
Is there a Windows standard way to do things such as "start fan", "decrease speed" or the like, from C/C++?
I have a suspicion it might be ACPI, but I am a frail mortal and cannot read that kind of documentation.
Edit: e.g. Windows 7 lets you select in your power plan options such as "passive cooling" (only when things get hot?) vs. "active cooling" (keep the CPU proactively cool?). It seems the OS does have a way to control the fan generically.
I am at the moment working on a project that, among other things, controls the computer fans. Basically, the fans are controlled by the superIO chip of your computer. We access the chip directly using port-mapped IO, and from there we can get to the logical fan device. Using port-mapped IO requires the code to run in kernel mode, but windows does not supply any drivers for generic port IO (with good reason, since it is a very powerful tool), so we wrote our own driver, and used that.
If you want to go down this route, you basically need knowledge in two areas: driver development and how to access and interpret superIO chip information. When we started the project, we didn't know anything in either of these areas, so it has been learning by browsing, reading and finally doing. To gain the knowledge, we have been especially helped by looking at these links:
The WDK, which is the Windows Driver Kit. You need this to compile any driver you write for windows, With it comes a whole lot of source code for example drivers, including a driver for general port-mapped IO, called portio.
WinIO has source code for a driver in C, a dll in C that programmatically installs and loads that driver, and some C# code for a GUI, that loads the dll and reads/writes to the ports. The driver is very similar to the one in portio.
lm-sensors is a linux project, that, among other things, detects your superIO chip. /prog/detect/sensors-detect is the perl program, that does the detecting, and we have spent some time going through the code to see how to interface with a superIO chip.
When we were going through the lm-sensors code, it was very nice to have tools like RapidDriver and RW-everything, since they allowed us to simulate a run of sensors-detect. The latter is the more powerful, and is very helpful in visualising the IO space, while the former provides easier access to some operations which map better to the ones in sensors-detect (read/write byte to port)
Finally, you need to find the datasheet of your superIO chip. From the examples, that I have seen, the environment controllers of each chip provide similar functionality (r/w fan speed, read temperature, read chip voltage), but vary in what registers you have to write to in order to get to this functionality. This place has had all the datasheets, we have needed so far.
If you want something real quick to just lower fans to a level where you know things won't overheat, there's the speedfan program to do so. Figuring out how to configure it in the early versions to automatically lower fans to 50% on computer startup was so painful that my first approach was to simply byte-patch it to start the only superio managed fan I had at lower speed. The newer versions are still bit tough but it's doable - there's a graphical slider system that looks like audio equalizer except that the x axis is temp and y is fan speed. You drag them down one by one. After you figure out how to get manual control for the fan you want, this is next step.
There's a project to monitor hardware (like fans) with C#:
http://code.google.com/p/open-hardware-monitor/
I haven't extensively looked at it, but the source code and use of WinRing0.sys atleast gives the impression that if you know what fan controller you have and have the datasheet, it should be modifiable to also set values instead of just getting them. I don't know what tool is suited (beside kernel debugger) to look at what Speedfan does, if you preferred to snoop around and imitate speedfan instead of looking at the datasheets and trying things out.
Yes, It would be ACPI, and to my knowledge windows doesn't give much/any control over that from user space. So you'd have to start mucking with drivers, which is nigh impossible on windows.
That said, google reveals there are a few open source windows libraries for this for specific hardware... so depending on your hardware you might be able to find something.
ACPI may or may not allow you to adjust the fan settings. Some BIOS implementations may not allow that control though -- they may force control depending on the BIOS/CMOS settings. One might be hard-pressed for a good use case where the BIOS control (even customized) is insufficient. I have come across situations where the BIOS control indeed was insufficient, but not for all possible motherboard platforms.
WIndows Management Instrumentation library (WMI) does provide a Win32_Fan Class and even a SetSpeed method. Alas, the docs say this is not implemented, so I guess it's not very helpful. But you may be able to control things by setting the power state.
So I need to simulate Isis2 in ns-3. (I am also to modify Isis2 slightly, wrapping it with some C/C++ code since I need at least a quasi real-time mission-critical behavior)
Since I am far from having any of that implemented it would interesting to know if this is a suitable way of conduct. I need to specifically monitor the performance of the consensus during sporadic wifi (ad hoc) behavior.
Would it make sense to virtualize a machine for each instance of Isis2 and then use the tap bridge( model and analyze the traffic in the ns-3 channel?
(I also am to log the events on each instance; composing the various data into a unified presentation)
You need to start by building an Isis2 application program, and this would have to be done using C/CLI or C++/CLI. C++/CLI will be easier because the match with the Isis2 type system is closer. But as I type these words, I'm trying to remember whether Mono actually supports C++/CLI. If there isn't a Mono compiler for C++/CLI, you might be forced to use C# or IronPython. Basically, you have to work with what the compiler will support.
You'll build this and the library on your mono platform and should test it out, which you can do on any Linux system. Once you have it working, that's the thing you'll experiment with on NS/3. Notice that if you work on Windows, you would be able to use C++/CLI (for sure) and then can just make a Windows VM for NS3. So this would mean working on Windows, but not needing to learn C#.
This is because Isis2 is a library for group communication, multicast, file replication and sharing, DHTs and so forth and to access any particular functionality you need an application program to "drive" it. I wouldn't expect performance issues if you follow the recommendations in the video tutorials and the user manual; even for real-time uses the system is probably both fast enough and steady enough in its behavior.
Then yes, I would take a virtual machine with the needed binaries for Mono (Mono is loaded from DLLs so they need to be available at the right virtual file system locations) and your Isis2 test program and run that within NS3. I haven't tried this but don't see any reason it wouldn't work.
Keep in mind that the default timer settings for timeout and retransmission are very slow and tuned for running on Amazon AWS, inside a data center. So once you have this working, but before simulating your wifi setup, you may want to experiment with tuning the system to be more responsive in that setting. I'm thinking that ISIS_DEFAULTTIMEOUT will probably be way too long for you, and the RTDELAY setting may also be too long for you. Amazon AWS is a peculiar environment and what makes Isis2 stable in AWS might not be ideal in a Wifi setting with very different goals... but all of those parameters can be tuned by just setting the desired values in the Environment, which can be done in bash on the line that launches your test program, or using the bash "Export" command.
I'm actually in charge of a FIP networking c++ application, working for the first time with Embarcadero C++ Builder XE5.
The app is nearly finished, but I can't find how to implement the last feature...
I wanted to open an external Windows HyperTerminal in order to see what happen on a given COM port, for this purpose I'm using ShellExecute() to launch it from my application but it's a bit ugly since there is 2 different windows.
I was wondering if it was possible to integrate this newly opened HyperTerminal into an existing form (Panel for instance). I couldn't find nothing related excepted this =>
Delphi style, but i don't understand a byte of #mghie answer since it's delphi.
If anyone have a clue I'm really interested, even the most basic clue!
For almost all of my projects where COM port interaction is needed I use AsyncPro. The project is very well documented with a ~1000 page reference manual.
Reference Manual
Developer's Guide
For this case, the package provides a VCL terminal that simply drops onto a form. It's quite flexible with a lot of options to configure its behaviour.
I wanted something similar in past but with no success.
1.The only thing I was able to do is the exact opposite.
dock my VCL window inside another (not VCL app) but that solved my problems
If you terminal is console window then I doubt even this can be done.
anyway find handle of desired window
find handle to a dockable subcomponent
set the parent of your subwindow to it / or use manual dock
2.maybe you can do some funny stuff
like hide terminal somewhere
and continuoslly copy its graphics to your window
newer done that hide thing
but copy the contents is doable (although on windows a little unstable sometimes)
done it once to feed my App with IR-camera feed from different App
while 'focus' stays on hidden terminal it should work
also you can try to post messages to it somehow if you need the focus ...
Sorry for a vague answer but at least you see some approaches of mine
maybe someone has a better way to do this
So I'm working on developing some code that uses the X11 library to work with X-Windows on Linux. I've found some simple tutorials, but they don't go into many details about best practices for more practical use-cases.
One thing I'm wondering is, should I be making one call to XOpenDisplay per application and passing around the pointer to the Display, or is it okay to call this function for each top-level window?
While you can use more than one connection to X server in your appilcation, there is a good reason not to do this: every connection is assigned range of resource IDs (even if your client does not create its own resources), and resource id is 32bit number, thus total number of connection is limited in X11 (and is usually as low as 256 to 512 on most systems)
You should only need XOpenDisplay once. One Display can have many windows.
I've been playing a big with the DC obtained with CreateDC(L"DISPLAY",NULL,NULL,NULL) and I've been wondering why does windows let you draw on the whole screen that easily, cause I think you could do some pretty evil stuff with that like putting a TIMER at 1ms and drawing a black rectangle on the whole screen every time the timer ticks.
The fact that you could do some pretty evil stuff doesn't mean windows shouldn't let you do it. Just think of all the other evil things you could do:
Run in an infinite loop and eat up all the cpu time.
Write random bits to a file until you fill up the whole hard disk.
Delete random files all over the place.
Allocate memory like crazy until the computer slows to a crawl.
Just because you CAN do those things doesn't mean windows should prevent you from writing to the hard drive or allocating memory or deleting files.
The purpose of Windows is to provide an environment in which programs can run. The more flexible they make that environment, the more interesting (and, unfortunately, devious) programs it makes possible for developers to create.
If they started putting in arbitrary restrictions on what you can do because you might abuse it... well, then it wouldn't be windows, it would be an iPhone :)
why does windows let you write to the hard drive so easily?
you could do some pretty evil stuff like overwrite every file on the hard drive.
The security of the desktop is given to the user running the desktop, you can't draw on it if you are not a privileged user.
Note that one doesn't usually CreateDC() on the desktop, but usually GetDC() for a particular window during the WM_PAINT message handler.
A program can also delete the file system, or destroy the registry (if suitably permissioned), the desktop is a user-permissioned resource like any other. If they run an application with their security credentials, they can do what they wish.
However in practice, one would create a window and paint within it.
Because it should be that easy.
It is that easy because to put rules and controls in place would mean that you would be cutting down the things you can do with the language and the windows framework. If this happened then there would be screams from the other side of the fence shouting at how you can't do this and that.
It is these abilities which make the language powerful, but with that power comes the danger. Just because you can do something, doesn't mean that you should. You can format you hard drive... doesn't mean that you should do this when you launch the clock application.
If you are not happy with this level of 'responsibility' then pick a different language or framework to write in.
Everything is a Window and Every Window has a HANDLE. So, if you have got DesktopHandle, then you can draw anything on it. What is the problem with it.
Offcourse, the application that is doing evil stuff(like you said) has been allowed to run on the machine by yourself, therefore, it can do more eviler stuff than this such as formatting your hard-drive etc.
If the method you're using (getting the screen DC) was disabled, it wouldn't stop people from doing the following.
You can create a window, you can paint in the window, you can set the size of the window to cover the whole screen, therefore you can paint on the whole screen.
And you can grab a bitmap of the whole screen, so you can paint the underlying screen content in the window and then make adjustments to it.
So it would be very easy to simulate the same effect using a combination of things that, on their own, are perfectly valid and extremely useful.
Because there may be a time when you need to do these things. I am sure at the moment you can't think of any but writing on the screen may be useful.
On OS X there are many applications who write directly on the screen. Useful information like CPU time or even a calender. That's cool!
But not everything that can be done must be done.
One of the primary reasons Windows is so afflicted with malware is the lack of security around such things as you describe. Others have cited examples such as filling the hard drive, erasing random files, or eating CPU time... all of these things are security concerns, and all of them are prevented by the other two major operating systems (Linux and OSX). This doesn't mean that you can't do similar things on those operating systems, but it means that a normal user can't do it. They'd have to be granted the right permissions, and usually also forced to use a very restrictive API to limit what they can do. So the answer to your question is "because it wasn't designed with security in mind". This allows programmers significantly more flexibility, and these powers can be used for good, but IMHO it more often breeds laziness (people use the brute force way instead of spending the time figuring out the "right" way to do something) and opens the door for security problems (malware).