I need to retrieve process information in a C/C++ program. I need at least basic things like CPU% and memory usage, but additional details would be useful as well.
The problem is that I need to use this information in a portable program, that will run on multiple platforms: windows, linux, MAC and possibly Solaris too.
Is there a library that I can use or do I need to write my own HAL for the different platforms? I tried to look on google, but I couldn't see anything obvious.
I can't help you with a complete solution, but here's a link to my CPULoadMeter class, which you can use to poll CPU usage information over time. It works under MacOS/X, Windows, and Linux (and possibly other Unixy-OS's that have /proc/stat also, I don't know). Perhaps you can use it as a starting point.
https://public.msli.com/lcs/muscle/muscle/util/CPULoadMeter.h
https://public.msli.com/lcs/muscle/muscle/util/CPULoadMeter.cpp
This information must be retrieved from the OS.
By definition this is non portable, but there are a couple of OS abstraction layers out there. The one that springs to mind is ACE.
Related
When I develop a loadable kernel module (LKM) should I use C?
Is it possible to develop a loadable kernel module (LKM) on Linux with language other than C for example C++?
It may be possible to an extent, but be warned (from http://www.tux.org/lkml/#s15-3):
Is it a good idea to write a new driver in C++?
The short answer is
no, because there isn't any support for C++ drivers in the kernel.
Why not add a C++ interface layer to the kernel to support C++ drivers?
The short answer is why bother, since there aren't any C++ drivers for
Linux.
I think the best idea is to consult existing resources (there are a few kernel driver books, including a free one online) which are all in C, get the basics figured out, then you can try and see if you can get c++ to work there.
But I very much doubt that will be easy. You don't even have access to the full C standard library in the kernel. Something to think about: it does not link to shared libraries, and the total executable image is usually 2-3 MB.
I'm pretty sure I saw a kernel configuration option somewhere allowing C++ in kernel modules, a while back (but cannot find it again).
I can see how certain templates would be very interesting to use in driver modules. Just for anecdotics: the OS X Mach kernel is partly written in C++.
In the end it comes down to object code, which is generated by the Assembler and linked together afterwards.
So yes it is possible, you find a debate about that here.
It depends on what you want to do with the LKM, do you want to use it for yourself and some experiments or is it going to become productive anywhere?
There is an operating system which is rewriting Linux Kernel in C++ it's called Boss-Mool and you can write drivers using C++. Here's the link : https://www.bosslinux.in/boss-mool
Well, the original question was for Linux, not OS X or Windows or whatever.
There is absolutely no way to write a Linux kernel mode driver in C++ !
That's because you would need to link with libstdc++ which will not link with your module. libstdc++ is not available for kernel mode, as simple as that !
Im working on an app to collect and send various bits of system info (partition space/free, laptop battery info, etc). Im not having much success getting this information in the form of direct c++ api.. though its all available via files in /proc (or similar).
So - I'm wondering whether reading/parsing these files in my c++ app is the appropriate way to get this info or should I keep trying to discover APIs? ( NOTE: I am working with statvfs ).
So far it looks like it's easier to gather this sort of info in Win32. Seems strange.
It is best practice by far to stick with an API in the following order of precedence.
Your language API (not much help for you here, but say for strings, a C99 string function is better to use than a library string facility specified by a Posix or other OS standard.)
Posix operating software APIs
Documented kernel API's
Undocumented kernel APIs (at least these will break, say, ioctl users if they change, so they probably won't change)
/proc
/dev/kmem, /dev/mem
There is no reason to believe that /proc trolling will be portable or even the same from release to release. Not every system will even have a /proc mounted!
Having said all that, it is much easier to just scrape stuff off of /proc and if it's the only available interface then you should go ahead and use it.qa
Finally, the ordering of the last two isn't completely clear, because /proc isn't available for a post-mortem kernel crash dump analysis, but tools that can peek in the core dump will still work.
I though that /proc was the API (everything is a file...)
As you have noticed, a lot of Linux systems information is in /proc. And you're correct that there often isn't a C API for retrieving that information (though there is usually a shell command if you're inclined to stick with bash instead of C++). In the worst-case scenario, you might be stuck parsing through /proc, though you might be able to get some sample code in the form of open-source shell commands for the particular item you want.
I am working on tools that will be used on the multiple OSes and platforms. These tools will provide the details of the OS on which it is running, like 32-bit or 64-bit OS, exact version of Linux, Solaris, or other OS.
One way I am thinking is of using the "uname -a" command to extract the OS information on a Linux/Unix-based OS. Please suggest me that if it is efficient to call the command from the program.
Is there any API available or is there any workaround that I can implement?
Note that I also do need to check for OS information on the Windows.
Why don't you simply wrap the OS detection with #define and each time call the ideal function so as to return a meaningful string in every case?
Some examples of system function to get information about the current OS (such as the running version):
In Windows the function is:
GetVersionEx
FreeBSD (and unixes I guess): uname
The C++ Standard Library provides no way of doing this, so you are at the mercy of operating system specific features. And even then, there is no general method, as utilities like "uname" are not supported on Windows and will give differently formatted results on different UNIX flavours.
You can give a try to sysinfo() call (from sys/systeminfo.h on Unix).
Also regarding "uname -a" efficiency, it depends where are you going to use it. In normal circumstances (if your application is not time/CPU critical) performance of "uname -a" should be acceptable.
There is also a function, "uname()", present in the sys/systeminfo.h file, which may help you.
There is no standard way to do this. But you can apply fingerprinting techniques to find out the target OS.
These are generally used to guess remote machine OS. You can look at Nmap also. It does various types of fingerprintings.
I would think that uname -a would be a good way, but only for *nixes.
I am going to start a game in about 3 weeks and I would really like the game to run at least on another platform (linux, MacOS) but my team thinks that's a lot of work. I am up for it but wanted to know what are the things I should watch out for that won't port to linux (apart from Windows specific APIs like DirectXsound)?
I've been reading online and Windows "_s" functions like sprintf_s appear to exist only on Windows; is this correct or are they implemented on linux also?
No, the _s functions are NOT implemented in the standard gcc library.
(At least, grepping the include files for 'sprintf_s' turns up nothing at all.)
It might be worth looking at cross platform libraries like boost and apr to do some of the heavy lifting work.
A sample of specific things to look for:
Input/Output (DirectX / SDL / OpenGL)
Win32/windows.h functionality (CreateThread, etc)
Using windows controls on the UI
Synchronization primitives (critical sections, events)
Filepaths (directory separators, root names)
Wide char implementations (16 bit on windows, 32bit on linux)
No MFC support on linux (CString, etc)
If I were you I would use some of the available Frameworks out there, that handle Platform independence.
I wrote a 3D-Game as a hobby project with a friend of mine, the server being in Java and the clients running on Windows and Linux. We ended up using Ogre as 3D-Engine and OpenAL as Sound-Engine, both platform independent and available under LGPL.
The only things I really had to write separately were the whole Socket-handling, reading the config from file system and the initialization of the System. Compared to the rest of the Program, that was almost nothing.
The most time consuming will be to set up the entire project to compile under Windows and Linux (or Mac), especially if you're concentrating on one and only occasionally check the other for problems. If you have one in your team who checks regularly for these problems while they're being produced you won't have that much overhead from that as well.
All in all compared to the programming of the game itself, adapting it to different platforms is almost no effort, if all frameworks used are well written, platform independent systems.
Try to encapsulate any non-standard extentions like DirectX, OpenGL, SDL, etc. Then you only have to rewrite those parts based on platform.
I also would make it playable on one OS before even thinking of porting.
For the 'safe' functions: they are non-standard, and almost safe :)
Endianess is something look out for.
Endianess is the order of the bits in a byte. Some platforms are big endian while some are little endian.
This can affect how cross-platform your program is. But the biggest impact this would have would be in network communications. You have to convert from one endian to another before sending or receiving a network message.
If you focus on gameplay, design a game, and them implement that porting should not be especially onerous. If you implement it simultaneous on several platforms it should be straight forward.
But if you focus on effects, design something that you feel is going to "blow the others out of the water," and try to paste a game idea onto them, you are doomed.
So really it is up to you.
Don't know much about windows-apis, but I set up a daily (or on-commit) fully automatic build-system on all platforms you want to support. If you develop something on your windows-box that doesn't work on the others, your build-system should notify you of "failed build on platform x, see logfile/attachment/whatnot for details". It'll catch a lot of cross-paltform issues. Unittests will help as well.
Whether or not to target multiple platforms from the start is a good idea is another question.
Personally I'd start developing on another platform and then see about porting it to windows at a later time ;-)
Just remember that you are creating a model of game that does not depend on the details of any operating system. Your game depends on state management and algorithms which don't depend on the OS. The key is to write your game logic without dependencies to specific libraries which means a lot of encapsulation.
You shouldn't call sprintf_s directly you should write an routine, class, or MACRO that can be changed based on the platform, Don't use DWORD when you can use a class or typedef that can be tailored to different platforms.
For instance if you where making a football game, then algorithms for throwing the ball, running, tackling, positions of the players could be done completely in standard C++ without platform dependencies. If your encapsulation was good you could dump the state of you game to a file and display it separately with a rendering program.
If you truly want to do cross platform development easily I would suggest using one of the already built cross-platform engines like Unity or one of the Garage Games stuff like Torque Game Builder (2D).
I have virtually zero experience in either so can't tell you which is better but the Torque Game builder demo couldn't get through the first tutorial without having problems and they don't answer tech support questions in their forums like they claim to do so I can say avoid them if you are a novice in game design like myself. The big thing about Garage Games was supposed to be their great support, I saw zero support and in fact only saw a bunch of, "Hey, anybody here?" posts with no answers so I guess they are pretty much giving up on supporting their products.
http://unity3d.com/
http://www.garagegames.com/
I'm surprised nobody mentions libSDL and OpenGL because most cross platform games were written using those libraries.
If your game is 2D, you can use libSDL. A good example of game written using it is The Battle of Wesnoth. SDL uses DirectX on Windows, it's just a thin wrapper on it.
If your game is 3D, use OpenGL. For example, Quake 3 uses that library. You can find tons of examples and documentation on it. Of course, there are many libraries that wrap OpenGL, so you don't have to do low-level stuff. Look into OGRE, Crystal Space, etc.
As for the basic C/C++ libraries and functions compatibility, it's best you install some Linux and simply run man page for the function to see if it exists. Of you can look it up on the Internet.
I'm trying to get information like OS version, hard disk space, disk space available, and installed RAM on a Linux system in C++. I know I can use system() to run different Linux commands and capture their output (which is what I'm currently doing) but I was wondering if there's a better way? Is there something in the C++ standard library that I can use to get information from the operating system?
If you are using *nix commands via system.
Then do man scroll to the bottom of the man page and it will usually show you what relevant C system calls are related.
Example: man uname:
SEE ALSO
uname(2), getdomainname(2), gethostname(2)
Explanation of numbers:
(1): User UNIX Command
(2): Unix and C system calls
(3): C Library routines
(4): Special file names
(5): File formats
(6):
(7):
(8): System admin commands
So if you are using system("uname"). From the man page you can see that there is also a uname C system call (uname(2)). So you can now do a 'man 2 uname' to get information about how to use the C system call uname.
There is nothing in the C++ Standard library for these purposes. The library you could use is libhal, which abstracts the view of programs to the hardware, collecting various informations from /proc, /sys and others. HAL, scroll down, there seems to be an unofficial C++ binding available too (haven't tested it though, while libhal works also fine for C++ programs). Use the command lshal to display all device informations available to HAL.
If you don't want to use HAL as litb suggests, you can read things straight out of the /proc filesystem, provided it's there on your system. This isn't the most platform-independent way of doing things, and in many cases you'll need to do a little parsing to pick apart the files.
I think HAL abstracts a lot of these details for you, but just know that you can read it straight from /proc if using a library isn't an option.
System information is by definition not portable, so there is no standard solution. Your best bet is using a library that does most of the work for you. One such cross platform library (unlike hal, which is currently Linux specific) is SIGAR API, which is open source BTW. I've used it in a C++ project without much trouble (the installation is a bit non-standard but can be figured out easily)