I'm moving from windows programming (By windows programming I mean using Windows API) to Linux Programming.
For programming Windows, the option we have is Win32API (MFC is just a C++ wrapper for the same).
I want to know if there is something like Linux API (equivalent to WINAPI) that is exposed directly to the programmer? Where can I find the reference?
With my little knowledge of POSIX library I see that it wraps around part of Linux API. But what about creating GUI applications? POSIX doesn't offer that. I know there are tons of 3rd party Widget toolkits like gtk, Qt etc. But I don't want to use the libraries that encapsulates Linux API. I want to learn using the "Core Linux API".
If there are somethings that I should know, please inform. Any programmer who is familiar with both Windows & Linux programming, please map the terminologies of Linux world so that I can quickly move on.
Any resources (books,tutorials,references) are highly appreciated.
I think you're looking for something that doesn't exactly exist. Unlike the Win32 API, there is no "Linux API" for doing GUI applications. The closest you can get is the X protocol itself, which is a pretty low level way of doing GUI (it's much more detailed and archaic than Win32 GDI, for example). This is why there exist wrappers such as GTK and Qt that hide the details of the X protocol.
The X protocol is available to C programs using XLib.
What you must understand is that Linux is very bare as to what is contained within it. The "Core" Linux API is POSIX and glibc. Linux is NOT graphical by default, so there is no core graphics library. Really, Windows could be stripped down to not have graphics also and thus not have parts of the win32 API like GDI. This you must understand. Linux is very lightweight compared to Windows.
For Linux there are two main graphical toolkits, GTK and Qt. I myself prefer GTK, but I'd research both. Also note that GTK and Qt exist for Windows to, because they are just wrappers. If you go take a look at the X protocol code for say xterm, you'll see why no one tries to actually creating graphical applications on top of it.
Oh, also SDL is pretty nice, it is pretty bare, but it is nice if your just needing a framebuffer for a window. It is portable between Linux and Windows and very easy to learn. But it will only stretch so far..
Linux and win aren't quite as different as it looks.
On both systems there exists a kernel that is not graphical.
It's just that Microsoft doesn't document this kernel and publishes an API that references various different components.
On Unix, it's more transparent. There really is a (non-GUI) kernel API and it is published. Then, there are services that run on top of this, optionally, and their interfaces are published without an attempt to merge them into an imaginary layer that doesn't really exist.
So, the lowest GUI level is a the X Window System and it has a lowest level library called Xlib. There are various libraries that run on top of this one, as you have noted.
I would highly recommended looking at the QT/C++ UI framework, it's arguably the most comprehensive UI toolkit for any platform.
We're using it at work developing cross platform apps that run on windows, osx and linux.
It also runs on Nokia's smart phone Operating System Maemo which has recently been merged with Intel's Moblin Linux OS, now called MeeGo.
This is going to sound insane since you're asking about "serious" stuff like C++ and C (and the "core linux API"), but you might want to consider building in something else. For instance:
Java Swing (many people love it! Others hate it and call it obsolete)
Mono GTK# (C# or VisualBasic or whatever you want, lots of people say it's pretty cool, but they're not not that many people)
Adobe AIR (ActionScript, you might hate it)
Titanium (totally new and unproven, but getting a lot of buzz in the iPhone world, at least)
And many other possibilities, some of which let you work on multiple platforms at once.
Sorry if this answer is not at all what you're looking for. The "real" answers on Linux are "pick a toolkit," which is also no answer at all :)
Have a look at Cairo. This something roughly similar to GDI+ and is under the hood of some of of the few usable GUI programs for Linux i.e. Firefox or Eclipse (SWT). It wraps most the natsy and ancient Linux stuff for you into a nice API that runs on most Linux installations without locking you into a entire subsystems like GTK or QT.
There is also the docs for the two different desktop platforms: Gnome and KDE that might help you down that road.
Related
I completely newbie in device drivers, so I hope my question is in place, but I need to develop a driver to control some equipment. I was thinking on using Linux as the host OS, but not sure if it is such good idea. I've heard some horror stories about the mess of developing device drivers under Linux. Is there a better alternative under the *Nix world? Or maybe should I check other OSes?
Linux documentation is basically non-existent (similar to other platforms). However, there are a few books which do cover enough information to get started, and the trickier kernel bits can borrowed from other drivers (yay for Open Source).
However, it is one of the easiest current platforms to develop drivers for. There are cleaner models, such as QNX, but that product is sadly near the end (and doesn't support 1/10th as much as hardware as Linux)
What type of device is the driver targetting? Many times you can avoid writing in-kernel drivers (for instance, using libusb in userspace, or the user space IO framework)
Hi I am keen on setting up a Linux box to play around with Rails, No-Sql, Mono C#... and opensource projects!
I am keen on learning Ruby on Rails and don't have a Mac so I think for now the cheapest option is to install a Linux distro on my computer. I am also keen on trying out MongoDB
I am a complete nube to Linux and am wondering if I should install openSuse, Ubuntu, Debian or ? I am also a C# developer so I can install Mono and MonoDevelop. They have packages for these http://monodevelop.com/Download
Anyone have some blog posts, screencasts, books, experience I would love to hear about it :)
Cheers
Jake
Note: you can still learn Ruby on windows, you can also use Ruby and .NET with IronRuby which is nearly 100% compatible with C Ruby. That's not to stop you from learning linux though as it gives you a different perspective on OS's and will expose you to the power of the command line.
Mono on linux is very complete. The best distribution to use with it would be Open Suse (as it's supported and recommended by Novell who develop Mono).
If you want to go the NoSql route than I would recommend looking at redis a very fast and advanced key-value data store with support for rich data structures, i.e. lists, sets and ordered sets. If you use C#/Mono you can this redis client which has native support for storing complex types and exposes Redis server-side lists and sets as IList<T> and ICollection<T>'s.
It probably doesn't matter much which Linux you install on a desktop. The user experience will be determined by Gnome or KDE, not the distro.
The two aspects of linux that have the biggest user-experience impact are the desktop and the package system. Linux has, sadly, two of each.1.
There are two desktops: Gnome and KDE. In general, you can choose Gnome or KDE with any distro and you can even install both. (You only run one at a time, though.) Please realize that except for some configuration details, for the most part the distros redistribute the same set of Unix-model software, so you aren't getting anything wildly different or even as different as XP vs Vista.
Either of the two main package systems can in some ways be used with any distro, but life will be much easier if you stay with the vanilla one for your distro. But since you aren't expecting either one I think it won't matter.
Now, if you went and installed, say, NetBSD, then you might notice some real differences, although you would still have your choice of Gnome or KDE.
1. Technically, there are 10 or 20 window managers that provide interesting lightweight GUI's that are something a bit less than a full-blown desktop GUI, but that's in the advanced class. Also in that class: Unix servers generally run no GUI at all.
I would go with Ubuntu or OpenSuse since most of the tutorials, community support and other stuff around Mono is targeted to these distributions.
I want to develop an application that can retrieve information such as, DLL version, DLL build mode(debug or release), info. regarding OS, memory, processer, processes/threads, program version etc. I am developing this mainly for Windows, but it'd be good if the application supports Linux too(wherever applicable).
I am basically a java programmer, and I know C, C++ to some extent.
Which programming language should I go for, that'd make my job easy? i.e. which language has APIs to fetch these kind of information?
Well... APIs are available regardless of the language... But the easiest way to get at what you are trying to do is going to be a C or C++ app. That doesn't mean it'll be easy (getting a DLL version is easy, getting memory and processor type is easy. The other stuff is certainly possible, but you may have to roll up your sleeves and learn the win32 API).
You might want to take a look at an application that already does exactly what you are asking about (Process Explorer) before you try to develop this yourself... It's going to be a big undertaking - and the folks at Sys Internals are really, really good at this stuff, and have already done it.
You commented on Kevin Day's answer that you would prefer to use Java for this.
Java is not very well suited for this, because the information you want to get is very platform-specific, and since Java is designed to be platform-independent, there are not a lot of ways to get at this kind of information from Java.
There are some methods in classes java.lang.System and java.lang.Runtime to get information about the platform that your Java program is running on. For example, class Runtime has a method availableProcessors() that tells you how many processors are available to the Java virtual machine. Note that this is not the same as the number of processors (or cores) that exist in the computer; the documentation even says that the number may change while the program is running.
Lookup the documentation for java.lang.System and java.lang.Runtime for more information.
Most likely you're not going to get exactly the information that you need by using pure Java - C or C++ will be better suited to get this kind of platform-specific information. If you would need this information from a Java program, you could write a small DLL or shared library and use JNI to call into it from your Java program.
Since DLLs are mentioned I presume we are talking about Windows.
I would recommend using WMI queries. They look very much like SQL and give you access to many very useful classes.
e.g. all info about the OS can be found here - in W32_OperatingSystem:
http://msdn.microsoft.com/en-us/library/aa394239(VS.85).aspx
You can use WMI classes from any language including C++.
As a side note - if you start a new application from scratch consider using PowerShell - new scripting language from Microsoft.
I've seen a lot frameworks to create a semantic web (or rather the model below it). What tools are there to create a small semantic web or repository on the desktop, for example for personal information management.
Please include information how easy these are to use for a casual user, (in contrast to someone who has worked in this area for years). So I'd like to hear which tools can create a repository without a lot of types and where you can type the nodes later, as you learn about your problem domain.
For personal semantic information management on the desktop there is NEPOMUK. There are two versions, one embedded in kde4, this lets you tag, rate and comment things such as files, folders, pictures, mp3s, etc. on the desktop across all applications.
Another version is written in Java and is OS independent, this is more of a research prototype. It has more features, but is overall less stable.
For KDE-Nepomuk see http://nepomuk.kde.org/
For Java-Nepomuk see http://dev.nepomuk.semanticdesktop.org/ and http://dev.nepomuk.semanticdesktop.org/download/ for downloads (the DFKI version is better)
Extensive list of semantic web tools
Also check out Protege
If you need to create a small model, then I suggest that you use topbraid. I have used for creating much larger models and I know people who have used to create humongous models. It comes packaged with a set of reasoners and provides ability to plug-in custom reasoner and in case if you decide to make your model larger, you can even integrate Topbraid with a triple store like Allegrograph.
And since its based on eclipse, to get started with it is relatively easier.
For developers who are spoiled working in more matured programming languages like Java (IDEA ? anyone), topbraid is the closest tool to an actual IDE.
Chandler is a "a notebook you can organize, back up and share!" It seems to be pretty simple to use.
OS: Windows, Mac, Linux
The same way DOS morphed into Windows?
We seem to have ended up supporting and developing for three platforms from Microsoft, and I'm not sure where the boundaries are supposed to lie.
Why can't the benefits of the CLR (such as type safety, memory protection, etc.) be built into Windows itself?
Or into the browser? Why an entirely other virtual machine? (How may levels of virtual machine indirection are we dealing with now? We just added Silverlight - and before that Flash - running inside the Browser running inside maybe a VM install...)
I can see raw Windows for servers, but why couldn't there be a CLR for workstations talking directly to the hardware (or at least not the whole Windows legacy ball and chain)?
(ooppp - I've got two questions here. Let's make this - why can't .net be built into Windows? I understand about backward compatibility - but the safety of what's in .NET could be at least optionally in Windows itself, couldn't it? It would just be yet another of many sets of APIs?)
Factoid - I recall that one of the competitor architectures selling against MS-DOS on the IBM PC was UCSD-pascal runtime - a VM.
And let's not forget that DOS didn't morph into Windows, at least not the Windows we know and love today. DOS was the operating system, Windows 3.1 a GUI shell resting atop said operating system.
When Windows 95 came out, it is true that there was no more boxed product labeled "Microsoft DOS," but Windows 95, architecturally, was DOS 7.0 with a GUI shell resting atop.
This continued through Win98 and WinME (aka Win9X).
The Windows we know today (XP, Vista, 2003, 2008) has its core from the Windows NT project, a totally separate beast. (Although NT was designed to be compatible with 3.1, and later, 9x binaries, and used a near-identical but expanded API.)
DOS no more morphed into the Windows we are familiar with than the original Linux core morphed into KDE.
The two APIs will need to continue to coexist as long as there are products built natively against Windows which are still in a support cycle. Considering that the Windows API still exists in Windows Server 2008 and Windows 7, that means at least 2017. Truthfully, it will probably be longer, because while managed code is a wonderful thing, it is not always the most appropriate/best answer.
Plus ... As a programmer, you ought to know better than anyone: It's never as easy to do something as it might appear from the outside!
Windows is multi-million lines of code, most of it in C. This represents an enormous decades-long investment. It is constantly being maintained (fixed) for today's users. It would be completely impossible to stop the world while they rewrite every line in C# for ten years, then debug and optimise for another ten, without totally wrecking their business.
Some of the existing code could in theory be compiled to run on the CLR, but it would gain no benefit from doing so. Compiling a large subset of C to the CLR is possible (using the C++/CLI compiler) but it does not automatically enable garbage collection, for example. You have to redesign from the ground up to get that.
Well, for one the CLR isn't an operating system. That's a pretty big reason why not ... I mean even the research OS, Singularity, is not just the CLR. I think you should read up on some books about the Windows kernel and general operating system stuff.
Microsoft are still a few Windows releases away from that.
But they would start with something like Singularity I think.
because it would break backwards compatibility? and mainstream chips architecture doesn't line up with VM architecture? They made hardware for a Java VM a while ago, but nobody cared.
The biggest issue I see is that the CLR runs on a VM, and the VM is useful as a layer of abstraction. Some .NET apps can be run on Linux (see the Mono project, I think they are up to .NET 2 compatibility now), so that would all be gone. In C/C++ or languages that directly talk to the hardware, you have to recompile your code into different binaries for every OS and hardware architecture. The point of having the VM there is to abstract that, so that you can write the code, build it, and use the exact same binary anywhere. If you look at it from a Java perspective, they have done a much better job of using their VM as a "write once run anywhere" model. The same java classes will run on Windows, Mac, and Linux without rebuild (by the programmer anyway, technically the VM is doing that work).
I think the #1 point here is that .NET/CLR is NOT Windows specific, and IMO Microsoft would only help the .NET suite of languages if it put a little more effort toward cross-OS compatibility.
Because Microsoft has got a huge legacy they cannot just simply drop. Companies has invested lots of money for the Windows and Win32 software they cannot dismiss.
CLR or some VM maybe used (VM's are being used) to run an OS on top of it . But then the question is, what should one use to build the VM? Probably C/C++ or some other similar language and (most) probably Assembly in some cases to speed up things.
That would mean the VM will still have the problems that Windows (or any OS) faces now. As pointed out by others, some part of the OS and related applications may be ported (or as you said morphed) to be over the VM, but getting the entire OS on top of a VM dosen't serve much purpose. The reason being, the VM will be the real OS then, implementing garbage collection and other protective measures for the Morphed OS.
Those are my two cents. :)
What language would the CLR itself use? What APIs would it call? Say it needed to open a file or allocate memory or create a process, you think the CLR is going to do that? The CLR is built on top of native code. A managed OS would create overhead.
CLR is for app development, it is there to make it easy to make apps, and easy to make less buggy software. It uses a garbage collector, and they can destroy performance. They can be great too, but you usually end up with some kind of performance problems during development, caused by garbage collection.
They must make it backward compatible so they must make it have some kind of native API.
If you're saying let's make a pure 100% managed OS and forget backward compatibility or have some giant compatability later, all you're really saying is let's force a garbage collector onto everything, right? Besides a garbage collector and the portability guarantees you get by being CLI compliant, what are you getting? The algorithms and everything are still being compiled into native code by the time they execute, so the only really significant difference is the memory management.
I actually did see trends that CLR will get planted deeper into the software stack. I remember saw the newest windows software stack, some CLR related library get planted into lower levels.
But CLR won't morph into windows, we know backward compatibility is very important for the software ecology.