Related
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.
I'm trying to understand why adding traits to Dart would cause the shape of objects in memory to change, and am therefore curious how it loads in code right now.
Dart is a dynamically typed language that generates its own machine language equivalents straight from source code with no intermediate byte-code step. There is no generic bytecode (like the JVM or llvm) and instead it is directly compiled into machine code.
I would add that despite compiling straight to machine code, the language itself is not designed in a way that would allow a C/C++ style compiler to effectively generate fast efficient code. This is by design as Dart seems to be an attempt to fill the gap between JavaScript and Java rather than the gap between Java and C/C++. Dart addresses many issues that make JavaScript hard to optimize most importantly typing of numeric variables.
There are some efforts to port the Dart environment to various platforms beyond Windows/Mac/Linux but I have yet to see an actual straight to machine language compiler for Dart. That doesn't mean they don't exist, I just haven't seen anything other than ports of the Linux Dart environment onto Beagleboard and other small Linux distros.
From the Dart FAQ
Q. Why didn’t Google build a bytecode VM targetable by multiple
languages including Dart? Each approach has advantages and
disadvantages, but we feel that in the context of Dart it made sense
to build a language-specific VM for the following reasons:
Google already works on a multi-language bytecode: LLVM bitcode in
PNaCl.
Even if a bytecode VM is specialized for Dart, a language VM will be
simpler and faster because it can work under stronger assumptions—for
instance, a structured control flow. These assumptions make the
implementation cleaner and optimizations easier.
A general-purpose bytecode VM would be even larger and slower, as it
generalizes assumptions and adds functionality that for Dart is dead
code: for example, multithreading with a shared heap.
No bytecode VM is truly general-purpose; they all make assumptions
that privilege some class of languages. A language VM leaves more room
to improve the VM and make deep changes to optimization of the
language. Some Dart engineers wrote an article talking about the VM
question in more detail.
A pretty good presentation on Compiling Dart to Efficient
Machine Code
The current F# Compiler is written in F#, is open source and runs on .Net and Mono, allowing it to execute on many platforms including Windows, Mac and Linux. F#'s Code Quotations mechanism has been used to compile F# to JavaScript in projects like WebSharper, Pit and FunScript. There also appears to be some interest in running F# code on the JVM.
I believe a version of the OCaml compiler was used to originally Bootstrap the F# compiler.
If someone wanted to build an F# compiler that runs on the JVM would it be easier to:
Modify the existing F# compiler to emit Java bytecode and then compile the F# compiler with it?
Use a JVM based ML compiler like Yeti to Bootstrap a minimal F# compiler on the JVM?
Re-write the F# compiler from scratch in Java as the fjord project appears to be attempting?
Something else?
Another option that should probably be considered is to convert the .NET CLR byte code into JVM byte-code like http://www.ikvm.net does with JVM > CLR byte codes. Although this approach has been considered and dismissed by the fjord owner.
Getting buy-in from the top with option 1) and have the F# compiler team have pluggable backends that could emit Java bytecode sounds in theory like it would produce the most polished solution.
But if you look at other languages that have been ported to different platforms this is rarely the case. Most of the time it's been a rewrite from scratch. But this is also likely due to the original language team having no interest in supporting alternative platforms themselves and that the original host implementation might've not been able to support multiple backends and it's already too slow for this to be a feasible option to start with.
My hunch is a combination of re-writing from scratch and being able to do as much code sharing and automation as possible from the original implementation. E.g. if the test suites could be re-used for both implementations it would take a lot of the burden off the JVM port and go a long way in ensuring language parity.
If I really had to do this, I would probably start with the #1 approach - add JVM backend to the existing compiler. But I would also try to argue for a different target VM.
Quotations are not very relevant - as an author of WebSharper I can assure you that while quotations can give you a nice F#-like language to program with, they are restrictive, and not optimized. I imagine that for potential JVM F# users the bar would be a lot higher - full language compatibility and comparable performance. This is very hard.
Take tail calls, for example. In WebSharper we apply heuristics to optimize some local tail calls to loops in JavaScript, but that is not enough - you cannot in general rely on TCO, as you do in general F# libraries. This is ok for WebSharper as our users do not expect to have full F#, but will not be ok for a JVM F# port. I believe most JVM implementations do not do TCO, so it will have to be implemented with some indirection, introducing a performance hit.
An bytecode re-compilation approach mentioned by #mythz sounds very attractive as it allows more than just porting F# - ideally it allows porting more .NET software to the JVM. I worked quite a bit with .NET bytecode analysis on an internal WebSharper 3.0 project - we are looking at the option of compiling .NET bytecode instead of F# quotations to JavaScript. But there are huge challenges there:
A lot of code in BCL is opaque (native) - and you cannot decompile it
The generics model is fairly complicated. I have implemented a JavaScript runtime that models class and method generics, instantiation, type generation, and basic reflection with some precision and reasonable performance. This was difficult enough in dynamic JavaScript with closures and is seems quite difficult to do in a performant way on the JVM - but maybe I just do not see a simple solution.
Value types create significant complications in the bytecode. I am yet to figure this one out for WebSharper 3.0. They cannot be ignored either, as they are used extensively by many libraries you would want ported.
Similarly, basic reflection is used in many real-world .NET libraries - and it is a nightmare to cross-compile in terms of both lots of native code and proper support for generics and value types.
Also, the bytecode approach does not remove the question on how to implement tail calls. AFAIK, Scala does not implement tailcalls. They have certainly the talent and the funding to do that - the fact that they do not, tells me a lot about how practical it is to do TCO on the JVM. For our .NET->JavaScript port I will probably go a similar route - no TCO guarantees unless you specifically ask for trampolining which will work but cost you an order of magnitude (or two) in performance.
There is a project that compiles OCaml to the JVM, OCaml-Java: it's pretty complete and in particular can compile the OCaml's compiler (written in OCaml) sources. I'm not sure which aspects of the F# language you're interested in, but if you're mainly looking at getting a mature strict typed functional language to the JVM, that may be a good option.
I suspect any approach would be a lot of work, but I think your first suggestion is the only one that would avoid introducing lots of additional incompatibilities and bugs. The compiler's pretty complex and there are a lot of corner cases around overload resolution, etc. (and the spec probably has gaps too), so it seems very unlikely that a new implementation would have consistently compatible semantics.
Modify the existing F# compiler to emit Java bytecode and then compile the F# compiler with it?
Use a JVM based ML compiler like Yeti to Bootstrap a minimal F# compiler on the JVM?
Porting the compiler shouldn't be that hard if it is written in F#.
I'd probably go the first way, because this is the only way one could hope to keep the new compiler in sync with the .net F# compiler.
Re-write the F# compiler from scratch in Java as the fjord project appears to be attempting?
This is certainly the least elegant approach, IMHO.
Something else?
When the compiler is done, you'll have 90% of the work left to do.
For example, not knowing much F#, but I assume it is easy to use any .NET libraries out there.
That means, the basic problem is to port the .NET ecosystem, somehow.
I was looking for something in similar lines, though it was more like a F# to Akka translator/compiler. As far as F# -> JVM is concerned, I came across two not quite production ready options:
1. F# -> [Fjord][1] -> JVM.
2. F# -> [Funscript][2] -> [Vert.X][3] -> JVM
If Delphi is the primary language for my development, what is the ideal complement to Delphi.
which should be my next step?
C# for .net and web development
Java
C++ for Know Win32 in depth.
Ruby
Perl
What is your recommendation?
I would recommend HTML, CSS and JavaScript. This sounds like a bit of a strange suggestion when asking for programming languages, but the Web is taking over. Delphi has had the TWebBrowser component since ages, and there are a few alternatives that offer even more features and ways to have HTML rendered onto the forms of your Delphi applications. I have found, when applied in a number of complex situations, it has saved me a lot of work and code.
(To be completely honest, though. I'm suggesting this because I'm trying to blend web-building with Delphi with the xxm project)
My recommendation is C #, but before Getting started with Delphi Prism, the learning curve will be so much easier. Learning a .Net language is going to greatly expand your horizons and types of applications you develop. .Net has a lot of technologies where you can deepen WPF, SilverLigth, WCF.
Delphi Win32 - > Delphi Prism -> C#
Python. It'll take what you've learned in Delphi and allow you to generalize it further.
In addition to Delphi, Embarcadero also sells the RAD C++ development environment.
It uses the same IDE as Delphi so you won't have mix yourself up by learn a new IDE, just a new language.
And you will be able to mix and match Delphi and C++ as you want in the same projects.
In fact, by purchasing (or upgrading to) Embarcadero RAD Studio, you'll get Delphi, C++Builder and Delphi Prism (the .NET tool) all in one.
So C++ seems like the most natural fit and a very logical choice.
And if you want .NET development, don't use C#. Use Delphi Prism.
I will look not for a language, but will think what application technologies to learn and what to develop next. IOW, I will continue with Delphi. Why I have to change it ?
It depends what you want to achieve. I've recently been learning Ruby and Rails (framework) do develop a website and it's been a fabulous learning experience. The wide community of OSS gems and plug-ins means I get a lot more done a lot faster than with Delphi. (And I've also found areas where Delphi beats Ruby too).
Whatever language you choose it should be something with a different 'personality'. What I mean by that is that languages like Deplhi, C++, BASIC and C# all come essentially from the same roots with very similar philosophies. Choose a language like Lisp, Ruby or Haskell which will teach you to think about your coding in a different way.
It just depends on what kind of applications you need/wish to target beside Win32 native ones Delphi targets.
C#: good if you need to use Windows managed features or need asp.net. IMHO, forget Mono.
Java: good if you need to target "managed" non Windows development, especially in some enterprise environments heavily Java based.
C++: if you need to go beyond some Delphi capabilities, and/or target non-Windows platforms natively. Plain C should not be ruled out, can be useful for some advanced develpoment, i.e. kernel development or drivers.
Ruby, Perl, PHP, Python, etc: each have their pro and cons for scripted applications. Ruby and PHP are IMHO better to target web applications when multiplatform is a need, while Perl is a good language to perform heavy text processing in a lot of differnt situations, and Python being a good general purpose tool.
I went from using Delphi pretty much exclusively to using Ruby on Rails, and love it. RoR is to web development what Delphi was to Windows development. It provides a language (Ruby), a framework (Rails) and a whole bunch of code generators to do the heavy lifting for you.
I started a blog some time ago called Delphi to Rails which kind of went through my own experiences making the switch. As much as I enjoyed Delphi, I enjoy Ruby way, way more. It's a strange language at first, but once you've figured out the basics it's super cool, and really fun to program in.
If you had a differential of either venturing into Delphi land or Qt land which would you choose? I know they are not totally comparable. I for one have Windows development experience with Builder C++ (almost Delphi) and MFC (almost Qt), with a bit more time working with Builder C++. Please take out the cross platform ability of Qt in your analysis.
I'm hoping for replies of people who have worked with both and how he or she would compare the framework, environment, etc.?
Thank you in advance for your replies.
If you are talking UI frameworks, then you should be comparing Qt with the VCL, not the IDE (Delphi in this case). I know I'm being a stickler, but Delphi is the IDE, Object-Pascal is the language, and VCL is the graphical framework.
That being said, I don't think there is anything that even comes close to matching the power and simplicity of the VCL. Qt is great, but it is no VCL.
Edit: This answer was written in 2008. It probably is no longer so apt, though probably it is not entirely useless. Take with salt.
I have used both and have ended up going the Qt route. These are the reasons:
Trolltech offer quick and one-to-one support via email
Qt innovates, and introduces powerful new features regularly
The Qt documentation is amazing, and in the rare cases where it isn't, you can read the source code
Having the source code for Qt also allows you to debug inside your base libraries, which has been a life saver for me on many an occasion
The API is very consistent and well designed. We have put new people on the project and within a month they show deep knowledge of the toolkit and can learn new classes very quickly
It has bindings to other languages, eg. Ruby and Python.
C++ is somewhat of a downside, eg. compile times, packaging, and a less integrated IDE. However Qt does make C++ feel more like a higher level language. QStrings take all the pain out of string handling for example. Thus the additional issues with C++ that you would normally face, eg. more buggy code, are less prevalent in my experience when using Qt.
Also, there are more libraries for Delphi than for Qt, but this is mitigated due to the fact you can just use a c or c++ library in a Qt project, and also because Qt is so fully featured you often don't have to look any further.
It would be a strange situation where I would choose Delphi over Qt for a new project.
I would pick Delphi. Of course you ask any pascalholic and he is sure to answer just the same. ;)
Qt again is fine, but the VCL just feels more polished. But then that could be my years of working with it so it just feels right. My experience with Qt was limited to a short lived project that ended up being rewritten in Delphi after it was determined that cross platform was not really needed thanks to the power of GoGlobal which can make any win32 app a web application, and therefore run on any platform.
It really depends on your needs and experience. I have worked with both (though have to say that the last Delphi version I really worked with was Delphi 6, and I'm currently working with Qt 4.4).
The language
C++ pros:
C++ is more "standard", e.g. you will find more code, libraries, examples etc., and you may freely use the STL and boost, while Object Pascal is more of an exotic language
Qt compiles on different platforms and compilers (Kylix is based on Qt, BTW)
Object Pascal pros:
some dynamic properties are build right into the language, no ugly workarounds like the MOC are needed
the compiler is highly optimized for the language and indeed very fast
the language is less complex than C++ and therefore less error prone
The IDE
Qt pros:
Strictly spoken, there is no IDE for Qt besides the Designer, but it integrates nicely into your preferred IDE (at least Visual Studio and Eclipse)
the designer does a better job with layouts than Delphi forms (Note: this is based on
Delphi 6 experience and may not be true with current versions)
Delphi pros:
The IDE is really polished and easy to use now, and it beats Visual Studio clearly IMO (I have no experience with Eclipse)
there is no point 2... but if I had to assign the buzzword "integrated" I would assign it to the Delphi IDE
The framework
I will leave a comparison to others, as I don't know the newest VCL good enough. I have some remarks:
both frameworks cover most of the needed functionality
both have the source code available, which is a must IMO
both have a more or less consistent structure - I prefer Qt, but this depends on your preferences (remark: I would never say that Qt is almost MFC - I have used MFC for a long time, and both Qt and Delphi - and .NET, for that matter - are way better)
the VCL has more DB-oriented functionality, especially the connection with the visual components
Qt has more painting (2D / 3D / OpenGL) oriented functionality
Other reasons that speak for Qt IMO are the very good support and the licensing, but that depends on your needs. There are large communities for both frameworks,
A big difference between Delphi and Qt is the Qt signal/slots system, which makes it really easy to create N-to-N relationship between objects and avoid tight coupling.
I don't think such a thing exists in Delphi (at least there was no such thing when I used to use it).
I just started experimenting with Qt/C++/Qt Creator and I must admit I was surprised that this "little cute bastard" was just below my nose for some many years and I pay attention to it just now.
It (the framework) looks neat, feature-complete (even was stuff that .NET lacks such as inbuld XQuery support).
Seems that most of the Qt applications written are dealing with 2D/3D/Games.
I believe the downsides are only: having to know C++ and the lack of DevExpress goodies like QuantumGrid.
I am seriously considering porting one of my simple applications (a picture viewer like ThumbsView).
And it REALLY runs from same codebase. FOR REAL!
Forget about Kylix, Mono, Lazarus, Free Pascal. This Qt thing beats them all in 10 times.
Qt Creator is far from IDE. But I hope in the future they will add a more powerfull debugger, code insight and refactoring (at least the "Rename" one) and more meaningful compiler errors.
I would seriously recommend to someone without experience in Pascal/C++ to take the Qt learning curve.
I would pick Delphi, but that is probably because I have programmed it before. It seems there are still a number of companies which use it, and almost everyone who has 8+ years expierence has encountered it somewhere. It seems that most programmers can relate to using it or at least learning Pascal. Not to mention the fact that newer languages (C#) are based on it (at least partially).
Pick Delphi if your concern are native Win32 speed, a first class RAD environment and executable size. Pick QT if you need a truly cross-platform framework coupled with a now-flexible licensing policy and don't mind slightly bloated code.
I ported an old Delphi program under QT/C++, and I must say that QT is the framework that comes closest to VCL in terms of ease of use and power (IMHO)
I'd choose delphi. Only because I have more experience with it. I don't think that there is other reasonabl criterias.
Qt is cross-platform, Delphi not much if we count Kylix. Lazarus is cross-platform, but not quite feature-complete yet.