I have an application which I need to port on Linux. I was thinking to use Free Pascal the problem is the application uses Windows API's to perform tasks such as serial port communication etc... Is there a msdn for linux users or a book covering how linux works internaly if there are apis.
I am very confused.
Well, it's sad to say but if your code in very Windows-dependend (not VCL depended!) then probably it'll be faster to write the application from the begining rather then porting it.
But if it's only serial port matter then give a try to multiplatform SynaSer library, find it here: http://synapse.ararat.cz.
hope this help :)
Robert Love has a book on Linux Systems Programming - that will cover this area and Love's books are generally good, so it is worth looking at.
It's not entirely clear from your question, but if your concern is that there are specific calls to hardware controlling functions in your Windows application that make it difficult to port I would suggest that is a misplaced fear. Both Windows and Linux operate on the principle that the application level programmer should be kept away from the hardware and that all that should be handled by the operating system kernel and only be accessible to applications via system calls. As the kernels of different operating systems face similar demands from users/applications, they tend to have system calls that do the same sorts of things. It is necessary to match the system calls to one another but I can see no reason why that should be impossible.
What may be more troublesome is that your Windows application may rely heavily on the Windows executive's windowing code/API. Again finding analogues for your code is not impossible but is likely to be a bit more complex e.g. in Linux this stuff is generally not handled in the kernel at all (unlike Windows).
But then again, your code may be written against a portable toolkit/library like Qt which would make things a lot easier.
Good luck in any case.
If the program contains GUI code you must use linux libraries like GTK/XLIB in order to create windows, forms, buttons, etc...
Windows specific functions (like EnterCriticalSection, WaitForSingleObject or _beginthreadex) must be replaced with equivalent linux api functions (a nice tutorial can be found here:
"www.ibm.com/developerworks/systems/library/es-MigratingWin32toLinux.html") or you can use libraries such as w2lpl or wine
A useful library for this kind of problems i've found at http://www.adontec.com/windows-to-linux-port-library.htm
I've had great experiences just using WINE. (https://www.winehq.org/)
You don't really port your app at all. You just make sure it doesnt violate some of the basc constraints of WINE and just run it as is. WINE (though is says it is not) is an emulator of the windows API's and will just do the translation for you. It's pretty complete in its coverage of the API's.
Related
I don't have any knowledge about Linux/Unix environment. So for some understanding I have put this question in front of all the developers and Unix/Linux technical people.
By applications I target IDE's used by developers, especially:
Visual Studio
IntelliJ Idea Community Version
PyCharm Community Version
Eclipse
And other peripheral apps used by developers, gamer and network engineers
To some experienced Linux users, my question might be baseless. But consider me a beginner with Linux. Thank You in advance.
The term "application" is a very vague, fuzzy one these days. It does not describe some artifact with a certain internal structure and way how to invoke it but merely the general fact that it is something that can be "used".
Different types of applications are in wide spread use on today's systems, that is why I asked for a clarification of your usage of the term "application" in the comments. The examples you then gave are diverse though they appear comparable at first sight.
A correct and general answer to your question would be:
One application can be used in different Linux based environments if that that environment provides the necessary preconditions to do so.
So the core of your question is kind of shifted towards whether different flavors of Linux based systems offer similar execution environments. Actually it makes sense to extend that question to operating systems in general, the difference between today's alternative is relatively small from an applications point of view.
A more detailed answer will have to differ between the different types of applications or better between their different preconditions. Those can be derived from the architectural platform the application is build on The following is a bit simplified, but should express what the situation actually is:
Take for example the IntelliJ IDEA and the Eclipse IDE. Both are java based IDEs. Java can be seen as a kind of abstraction layer that offers a very similar execution environment on different systems. Therefore both IDEs typically can be used on all systems offering such a "java runtime environment", though differences in behavior will exist where necessary. Those differences are either programmed into the IDEs or origin from the fact that certain components (for example file selection dialogs) are not actually part of the application, but the chosen platform. Naturally they may look and behave different on different platforms.
There is however another aspect that is important here especially when regarding Linux based environments: the diversity of what is today referred to as "Linux". Unlike with pure operating systems like MS-Windows or Apple's MaxOSX which both follow a centralized and restrictively controlled approach we find differences in various Linux flavors that far extend things like component versions and that availability. Freedom of choice allows for flexibility, but also holds a slightly more complex reality in the outcome. Here that means different Linux flavors do indeed offer different environments:
different hardware architecture, unlike MS-Windows and MacOSX the system can not only be used on intel x86 based hardware, but on a variety of maybe 120 completely different hardware architectures.
the graphical user interface (GUI or desktop environment, so windows, panels, buttons, ...) is not an integral part of the operating system in the Linux (Unix) world, but a separate add on. That means you can chose.
the amount of base components available in installations of different Linux flavors differs vastly. For example there are "full fledged, fat desktop flavors" like openSUSE, RedHat or Ubuntu, but there are also minimalistic variants like Raspbian, Damn Small Linux, Puppy, Scientific Linux, distributions specialized in certain tasks like firewalling or even variants tailored for embedded devices like washing machines or moon rockets. Obviously they offer a different environment for applications. They only share the same operating system core, the "kernel", which is what the name "Linux" actually only refers to.
...
However, given all that diversity with it's positive and negative aspects, the Linux community has always been extremely clever and active and crafted solutions to handle that specific situations. That is why all modern desktop targeting distributions come with a mighty software management system these days. That controls dependencies between software packages and makes sure that those dependencies are met or resolved when attempting to install some package, like for example an addition IDE as in your example. So the system would take care to install a working java environment if you attempt to install one of the two java based IDE's mentioned above. That mechanism only works however if the package to be installed is correctly prepared for the distribution. That is where the usage of Linux based systems differs dramatically from other operating systems: here comes the introduction of repositories, how to search, select and install available and usable software packages for a system and and and, all a bit to wide a field to be covered here. Basically: if the producer of a package does his homework (or someone else does for him) and correctly "packages" the product, then the dependencies are correctly resolved. If however the producer only dumps the raw bunch of files, maybe as a ZIP archive and insists on a "wild" installation as typically done for example on MS-Windows based systems, so writing files into the local file system by handing administrative rights to some bundled "installer" script that can do whatever it wants (including breaking and ruining or corrupting) the system is executed on, then the systems software management is bypassed and often the outcome is "broken".
However no sane Linux user or administrator would follow such a path and install such a software. That would show a complete lack of understanding how the own system actually works and the consequent abandonment of all the advantages and comfort offered.
To make a complex story simple:
An "application" usually can be used in different Linux based environments if that application is packaged in a suitable way and the requirements like runtime environment posed by the application are offered by that system.
I hope that shed some light on a non trivial situation ;-)
Have fun!
I am planning to implement Hiawatha web server on a non-linux platform which is uC/OS-II RTOS.
I need help to port the Linux dependent API's to RTOS platform.
Kindly let me if there are already build libraries that I can use to port Linux on RTOS.
Thanks in Advance
Any code that uses more than just the standard C library will require some porting effort - the extent to which non-standard and OS specific libraries and calls are made will determine the effort required or even the feasibility of such a port.
Most Linux code of any complexity will require a POSIX API and networking code will probably use BSD sockets. Multi-threaded code would likley use pthreads. uC/OS-II has neither of these; it deals with only scheduling, timing, synchronisation and inter-process communication; it is a scheduling kernel, not a full OS in the same sense as Linux - it does not even have a file system - a requirement of most Linux code. Of course adding additional libraries and extensions may provide some or all of what you may need.
Moreover uC/OS-II's simple one-thread-per-priority-level scheduler would make typical Linux multi-threaded code hard to schedule in the manner intended. Most RTOSes (including uC/OS-III) support round-robin/time-sliced scheduling of tasks at the same priority level, but uC/OS-II does not; possibly making it unsuitable for this task.
Something more sophisticated that uC/OS-II may be in order, or perhaps using code more suited to uC/OS-II perhaps. eCos for example is a far more complete RTOS for embedded systems; it is open-source and includes a POSIX API, file-system support and a socket API. It would be far easier to port Linux code to that. Equally there are many lightweight embedded webserver examples that are probably more suited to uC/OS-II and other simple RTOS or even no OS at all. LwIP for example is a TCP/IP stack for small embedded systems for which uC/OS-II ports exist and for which there are web server examples.
The point is that Linux are uC/OS-II are not comparable; one requires < 10Kb of code, the other has a minimal foot-print of about 4Mb! To get Linux code to run on such a system will require you to add a lot of additional code to provide the missing services, and it may not be feasible on your target platform.
[Edit: 08 July 2012]
Have you considered using Micrium's own TCP/IP stack and μC/HTTPs web-server add-on? It is likley to be better integrated to uC/OS-II and provide better performance than non-RTOS specific third-party code.
was wondering - if knowing The Linux way of life or the Linux architecture, would give a better frame of mind for programming on embedded devices especially when they have some kind of OS in them.
Just want to be sure that I did not miss a major thing :)
Note:
I come from a windows background, can program in C and C++.
Passionate and finally want to get started into Embedded programming. I would like to start by doing typical hobbyists project at home.
It would be nice if anyone would also comment on BeagleBoard as a starting point for me.
"Embedded" is a fuzzy word. There are two categories:
There are realtime embedded systems: microcontroller/microprocessor applications that are intimately communicating directly with the hardware on a low abstraction level. Typical applications are control systems/automation, industrial, automotive, medtech, household electronics, data/telecom communications etc.
And then there are fluffy embedded systems: various laptop:ish computers, embedded linux, embedded windows, phones and phoney operative systems, anything involving internet, human-machine intefaces etc.
People working in both categories will firmly state that they are working with embedded systems, while the latter kind are often just doing another flavour of desktop applications. Depending on which category you are aiming for, Linux may or may not be a merit. The telecom branch for example, overlaps both of these categories, and they are often using embedded Linux even for non-fluffy applications.
In either case, *nix may be used as the development platform, so knowing it won't hurt.
Yes and no. Mostly yes.
Lundin correctly described the "two worlds of embedded" (although the border between them is very fuzzy).
If you're writing for "higher embedded", like Android, or other devices that run Linux, then definitely expert knowledge of Linux will be of much help. You still need to know some "bare bones" and don't get scared when you see the likes of &=~ operator in C, but knowing Linux - the Linux of the old, where you configured stuff by editing files in /etc, where you compiled your own kernels for everyday use, where you would build software from tarballs, that's what helps. Knowing modern Linux - Gnome, gconf-editor, Synaptic and the likes will not be of much help.
Then next, if you're programming devices without OS, in the middle area - fast and strong enough to run C programs, but not the OS, you still need Linux. Because crosscompile. You don't need actual Linux. Cygwin is okay for that. MinGW may suffice. Still, you will probably need to be able to build your own crosscompiler (based on GCC), linker, debugger, make tools, and the rest of "backbone" of the IDE. Unless your chip supplier is awesome and provides a complete toolchain with IDE.
Only when you're into tiny processors, you don't need Linux. Stuff like car alarm remote, christmas lights blinker, car tire pressure sensor, battery level monitor - stuff that can have 16 bytes RAM, 1KB EEPROM, and the rest of CPU to match, you will need to use an IDE that works with this CPU, no OS, no C compiler, nothing remotely close to Linux - the IDE will most likely be Windows based.
I'd say you really do not need to know Linux for embedded programming. Many companies developing embedded software do it on windows and have no contact with other OS.
But sure, knowing more makes you more versatile, and general knowledge makes you a better engineer. This includes different OS as many other things.
When it comes to BeagleBoard, it depends on the kind of application you are interested in.
If you want to understand the low-level, I would start on a simpler processor and learn how to use peripherals, hardware interrupts, debouncing signals... There is an educational point in doing this yourself some time.
I suppose you can also skip that and start with an ARM-A8 and possibly an embedded OS, it's just not the path I followed.
What I am about to say may cause a flame war, but...
I have found that Linux is a much more productive development environment than Windows. At my previous job, we were developing firmware for managed switches and industrial automation equipment, which ran an embedded Linux operating system. All the developers had both Windows and Linux boxes, as the user interface software only ran on Windows. We all used Linux for developing, though, as it was simply easier.
At my current job, the only choice is to run Windows, but to make it more productive we are running Cygwin, which provides a Linux-like environment. It is very difficult to develop software on Windows that is not specifically for Windows.
As for developing for an embedded system without an OS... I have an Arduino that I play with occasionally. I have programmed it both from Windows and Linux, and have found the experiences fairly similar. Using Arduino's own tools, Windows seems to run a bit more smoothly, but if you want to hack on it and make something interesting, you're better off using Linux.
Personally (and this will likely provoke some nasty comments), I feel that Linux is best for doing productive work, and Windows is best for playing games.
So basically, this all boils down to this: Try using Linux for developing your project. You will probably find it to be a much smoother, more productive experience. If you don't like it, you don't have to keep using it. But the experience will probably be worth it.
Edit (due to question rewording): Knowing the "Linux way of life" is unlikely to help much when coding for an embedded project that is not running Linux itself. As I understand it, the Unix philosophy is about two main issues:
Each tool should do one thing and do it well (don't make something that tries to be everything).
Whenever possible, data should be plain text (allows for simple piping through processes and searching for content).
If you are working on a system without an operating system, you are writing code for a compiler and not likely working with a full shell at any point. You also are unlike to have any sort of file system. So both of these points are moot; you are not likely to gain anything concretely related to embedded programming by studying Linux, although it certainly couldn't hurt :-)
I really think if you want to learn a little about embedded sphere you should not start by using an OS directly. Prefer to have hands on a small low level project then add an OS if it's really needed for your final application.
I don't think setting up an OS into an embedded device will be easier than starting from scratch. It will bring you some functionalities (that I am not sure you really need to learn embedded) but it will bring you lot of hard debugging time in case of problems in the OS port.
I have been doing embedded programming for 10 years, currently for networking equipment and before that Apache helicopters. Both companies had POSIX-like operating systems on the target, but not embedded Linux directly. My current company uses mostly Windows for individual developer environments. However, we do have a few Linux boxes hanging around for special purposes. My previous company used a mix of Windows and Sun Solaris Unix. So wherever you go, you may not use Unix or Linux on your day to day computer, but you are likely to come across it at least occasionally.
On the other hand, I've known developers who have programmed on Linux for embedded Linux targets their entire careers. It really depends on the company, as smaller or newer companies have a tendency to use Linux more than corporations. However, using embedded forms of Windows on targets is very rare in my experience. I know devices are out there, but I've never personally met a developer who worked on one.
Anyway, Linux is free to use and has other benefits besides being good for a job. There's really no downside to giving it a try for a couple of months, other than giving up some of your time.
Linux is growing in embedded... see latest research:
Top 10 trends for the embedded software and tools market in 2011 - VDC research
Android Becomes Number One in U.S. Smartphone Market Share
Knowing the Linux way of life will definitely be a plus in embedded domain provided the kind of apps you are interested in are contained in the above mentioned links.
understanding Linux architecture will be over kill (although basic overview is good) before just starting in embedded field
e.g. to cut a tree you don't have to invent an axe - just start using one, then gradually you could learn to sharpen the axe
Its better to get started small - get hands-on, and focus on specific areas as is the need of the hour. grow with your work and work keeping your goals in mind
you will surely gain much faster and not get stuck in self loop - R&D to do R&D ;)
Only if you want to embed Linux! And as an embedded systems developer of some 22 years, I would suggest that Linux is unsuitable and unnecessary for a very large proportion of embedded systems projects.
Understanding the workings of an RTOS, and real-time priority based pre-emptive scheduling and IPC mechanisms would stand you in better stead. Take a look at this for example.
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.
How to migrate to *nix platform after spending more than 10 years on windows? Which flavor will be easy to handle to make me more comfortable and then maybe I can switch over to more stadard *nix flavors?
I have been postponing for a while now. Help me with the extra push.
Linux is the most accessible and has the most mature desktop functionality. BSD (in its various flavours) has less userspace baggage and would be easier to understand at a fundamental level. In this regard it is more like a traditional Unix than a modern Linux distribution. Some might view this as a good thing (and from certain perspectives it is) but will be more alien to someone familiar with Windows.
The main desktop distributions are Ubuntu and Fedora. These are both capable systems but differ somewhat in their userspace architecture The tooling for the desktop environment and default configuration for system security works a bit differently on Ubuntu than it does on most other Linux or Unix flavours but this is of little relevance to development. From a user perspective either of these would be a good start.
From a the perspective of a developer, all modern flavours of Unix and Linux are very similar and share essentially the same developer tool chain. If you want to learn about the system from a programmer's perspective there is relatively little to choose.
Most unix programming can be accomplished quite effectively with a programmer's editor such as vim or emacs, both of which come in text mode and windowing flavours. These editors are very powerful and have rather quirky user interfaces - the user interfaces are ususual but contribute significantly to the power of the tools. If you are not comfortable with these tools, this posting discusses several other editors that offer a user experience closer to common Windows tooling.
There are several IDEs such as Eclipse that might be of more interest to someone coming off Windows/Visual Studio.
Some postings on Stackoverflow that discuss linux/unix resources are:
What are good linux-unix books for an advancing user
What are some good resources for learning C beyond K&R
Resources for learning C program design
If you have the time and want to do a real tour of the nuts and bolts Linux From Scratch is a tutorial that goes through building a linux installation by hand. This is quite a good way to learn in depth.
For programming, get a feel for C/unix from K&R and some of the resources mentioned in the questions linked above. The equivalent of Petzold, Prosise and Richter in the Unix world are W Richard Stevens' Advanced Programming in the Unix Environment and Unix Network Programming vol. 1 and 2.
Learning one of the dynamic languages such as Perl or Python if you are not already familiar with these is also a useful thing to do. As a bonus you can get good Windows ports of both the above from Activestate which means that these skills are useful on both platforms.
If you're into C++ take a look at QT. This is arguably the best cross-platform GUI toolkit on the market and (again) has the benefit of a skill set and tool chain that is transferrable back into Windows. There are also several good books on the subject and (as a bonus) it also works well with Python.
Finally, Cygwin is a unix emulation layer that runs on Windows and gives substantially unix-like environment. Architecturally, Cygwin is a port of glibc and the crt (the GNU tool chain's base libraries) as an adaptor on top of Win32. This emulation layer makes it easy to port unix/linux apps onto Cygwin. The platform comes with a pretty complete set of software - essentially a full linux distribution hosted on a Windows kernel. It allows you to work in a unix-like way on Windows without having to maintain a separate operating system installations. If you don't want to run VMs, multiple boots or multiple PCs it may be a way of easing into unix.
Ubuntu is nicely balanced, with a user friendly desktop but the potential to set up a fully functional programming environment.
I would advise experimenting with virtual machines - there is no reason to ditch your current setup until you've tried a few of the major distributions. VMware and others have a wide variety of server and desktop builds available.
I guess it also depends on what programming languages your are comfortable with.
If you worked with C# in the past then you could look at using the knowledge by running Mono , or maybe look at using Java (which is syntactically very similar). Either way Linux would be good.
I personally would recommend you look at the Mac's OS X. Its a unix BSD based OS, but with a really slick user interface over the top. To me it feels like the best of both the Windows and Unix worlds.
I do all my unix development on it, deploying onto Ubuntu servers. If you do look at a Mac, definitely take a look at the MacPorts project, which packages a large amount of the open source unix/linux software up making installation of programming tools incredibly easy.
Ubuntu seems to be very user-friendly, and has a lot of specific information for it in forums etc. So support-wise you'll be covered.
I experienced the shift from windows to ubuntu as very much do-able, things you can do graphically in windows can be done exactly the same in ubuntu (maybe some exceptions) and a bit more. A computer savvy individual should not have any problems.
However, it helps greatly if you are familiar with the basic shell commands (you'll need them as a programmer!). Some are the same as on windows but especially ls (dir) sometimes has me wracking my brain for "what was that command again", and vice versa when I'm back on windows.
Take some time to try them out. (for example: pwd, ls, mv, rm, ps, kill)
Finally, when installing programs often a simple "sudo apt-get install X " does all the work for you, even more user friendly than the windows installer executables I find.
Edit: You might want to try a VMware player and try a few linux distributions to play around in before you install the dual boot.
Get a macbook pro. OSX is the smoothest flavour of unix and the laptop should give you the push you need.
Then when you're feeling more confident, you can decide whether or not you want to spend most of your time configuring your soundcard, running ./autoconfigure && make, and debugging package manager screwups.
Any modern version of Unix (or Linux) you can get running on your machine will be fine.
Here are the ones that I would consider:
Ubuntu. As others have noted, this is often considered to be the easiest to use. However some parts are not "standard" Unix. For example, the startup scripts do not use init. This is mostly a good thing, but if you're trying to learn Unix may not be what you need.
Fedora. Bleeding edge but with rough edges.
Slackware. Possibly the most Unix-like Linux distribution (some would say dated!).
One of the *BSDs: FreeBSD, OpenBSD, NetBSD. Different approach to some things than Linux.
Solaris. This is "proper" Unix. Seems bare-bones compared with Linux but worth playing with to see what's "standard."
In fact, I would consider running at least a couple of them, most run fine as a VM. One of the good and bad things about Unix is that what's standardised is more the philosophy than many of the details. There's no Visual Studio, there's no C# (by that I mean no canonical high level language; I know about Mono).
Excellent answers. A few comments:
Almost all distros support LiveCDs, to let you try before installing. folks mentioned VMWare and VirtualBox, also note that Ubuntu's WUBI installer lets you install Linux under Windows without repartitioning; very nice; I used it when I first switched to my 64-bit system, since I wasn't sure how good the driver support was. Ubuntu 9.04 works great in 64, though. Also, since Ubuntu is so popular, that are many versions, Kubuntu uses KDE instead of Gnome, Mint and Xubuntu are both lighter weight.
Expect to run side-by-side for a while when transitioning from Windows. Cygwin has some nice downloadable manuals for people getting used to bash, and basic information about how *nix works underneath, targeted at Windows users. There are tons of useful sites; the Ubuntu community forums have a tremendous amount of information, for both beginners and advanced.
For getting used to developing under Linux, check the Linux documentation project. In addition to KDevelop, there's Anjuta, Eclipse, and many more. Some are light, some are heavyweight.
One thing that can ease the transition is to use software that runs in both operating systems. Firefox, Thunderbird, OpenOffice, Subversion, and hundreds if not thousands of others run fine in both Linux and Windows. And with very little effort, you can use the same folders for application settings and data for many of these. Firefox and Thunderbird can easily use the same folders/files on an NTFS partition. Makes dual booting much easier. Instructions are on the Ubuntu community site and other locations.
Note that some Linux software isn't NTFS friendly; in Linux keep your Subversion working folders on a native partition.
One caveat for sharing application settings; some applications store absolute paths; as a workaround, you can create symlinks that look like Windows drive letters.
After you get comfortable with Linux, branch out and try non-Windowsy applications and tools. Sometimes different is better. Lots of people use Emacs and Vim for good reasons.
Try Kubuntu as a distro and Kdevelop and Qt to start programming with, it's all very civilised.
Kate's an ok notepad-esque text editor if you want to go that way but I don't see why you'd want to get in to Vi or Emacs apart from the geeky appeal of using something really arcane.