Shifting from Windows to *Nix Programming Platform

shifting from windows to *nix programming platform

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.

Any tips on Linux programming for Windows programmer (C/C++)?

As far as details on the *nix API goes, this is a good set of material:

http://www.hiraeth.com/alan/tutorials/courses/unixprog.html

And somebody has pulled together a nice list of links to many resources here

While it's good to learn the target platform, I strongly recommend using Boost libraries wherever possible as wrappers around the platform-dependent behaviors (for threading, networking, etc.)

How best for a Windows boy to start with *nix web development?

It sounds like you need to get a handle on the *nix basics first. Everything else builds on that. For example, trying to configure your run-of-the-mill Apache with PHP/Python/Whatever setup will be pretty tough without that knowledge - if you can ssh into your server in the first place :)

With that in mind: http://www.amazon.com/Unix-Programming-Environment-Prentice-Hall-Software/dp/013937681X/ref=sr_1_1?ie=UTF8&s=books&qid=1262712609&sr=8-1. Oldie but goldie, and should be easily accessible to any programmer coming from other environments. Perhaps someone can recommend an updated version of this?

Moving development from Windows to Linux

I moved from windows to linux 9 or so years ago after spending my initial career using Visual Studio.

The move was relatively easy as the build environment was first and foremost based on Makefiles. Up to this point I used scripts to create a visual studio project for the project each time there were changes.

At that time, the others in my team were using emacs. The learning curve is pretty steep when you come from something like VS, but IMHO it has been well worth the time I invested in it.

What sold me on emacs was the integration with gdb. Emacs has a mode specifically for gdb. Once this mode is started you can enable 'gdb-many-windows'. This gives you a view very similar to that of any debuger environment. Also, one of the first things that I did after moving was to setup the VS key shortcuts. So even after all this time, I have the following in my .emacs file:

(global-set-key [f7] 'compile)             ;; asks for a command to run eg: make
(global-set-key [f4] 'next-error)          ;; show the next error
(global-set-key [S-f4] 'previous-error)    ;; show the previous error

(global-set-key [f5] 'gdb)                   ;; start the debugger   
(add-hook 'gud-mode-hook                     ;; allows changes to debugger mode
          '(lambda ()
             (define-key (current-local-map)
               [f10]
               'gud-next)                    ;; F10 does step over
             (define-key (current-local-map)
               [f11]
               'gud-step)                    ;; F11 does step into
             (define-key (current-local-map)
               [\S-f11]
               'gud-finish)                  ;; Shift+F11 finish function
             (define-key (current-local-map)
               [f5]
               'gud-cont)                    ;; F5 does continue.
             (gdb-many-windows t)))          ;; Set's up a debugger type view

If you haven't used emacs before, then the first thing you need to know is that you type: Ctrl+X Ctrl+C to exit emacs.

If you do decide to give it a go, after loading it up use Ctrl-H then 't'. This starts the emacs tutorial which will give you the basics.

Of course, if you get stuck, then just review or ask a SO question tagged with emacs. This has become a really could source of information for emacs use. I only found out about gdb-many-windows this April from this question!

Switching to Linux for Windows development, bad idea?

That's a bad idea. I can see at least two reasons :

Develop on the same OS you write software for
Visual Studio rocks

C program cross platform differences on Windows and Unix OS

That kind of problems usually appear when you don't stick to the bare C standard, and make assumptions about the environment that may not be true. These may include reliance on:

nonstandard, platform specific includes (<conio.h>, <windows.h>, <unistd.h>, ...);
undefined behavior (fflush(stdin), as someone else reported, is not required to do anything by the standard - it's actually undefined behavior to invoke fflush on anything but output streams; in general, older compilers were more lenient about violation of some subtle rules such as strict aliasing, so be careful with "clever" pointer tricks);
data type size (the short=16 bit, int=long=32 bit assumption doesn't hold everywhere - 64 bit Linux, for example, has 64 bit long);
in particular, pointer size (void * isn't always 32 bit, and can't be always casted safely to an unsigned long); in general you should be careful with conversions and comparisons that involve pointers, and you should always use the provided types for that kind of tasks instead of "normal" ints (see in particular size_t, ptrdiff_t, uintptr_t)
data type "inner format" (the standard does not say that floats and doubles are in IEEE 754, although I've never seen platforms doing it differently);
nonstandard functions (__beginthread, MS safe strings functions; on the other side, POSIX/GNU extensions)
compiler extensions (__inline, __declspec, #pragmas, ...) and in general anything that begins with double underscore (or even with a single underscore, in old, nonstandard implementations);
console escape codes (this usually is a problem when you try to run Unix code on Windows);
carriage return format: in normal strings it's \n everywhere, but when written on file it's \n on *NIX, \r\n on Windows, \r on pre-OSX Macs; the conversion is handled automagically by the file streams, so be careful to open files in binary when you actually want to write binary data, and leave them in text mode when you want to write text.

Anyhow an example of program that do not compile on *NIX would be helpful, we could give you preciser suggestions.

The details on the program am yet to get. The students were from our previous batch. Have asked for it. turbo C is what is being used currently.

As said in the comment, please drop Turbo C and (if you use it) Turbo C++, nowadays they are both pieces of history and have many incompatibilities with the current C and C++ standards (and if I remember well they both generate 16-bit executables, that won't even run on 64 bit OSes on x86_64).

There are a lot of free, working and standard-compliant alternatives (VC++ Express, MinGW, Pelles C, CygWin on Windows, and gcc/g++ is the de-facto standard on Linux, rivaled by clang), you just have to pick one.

Why can't we create programs cross-platforms these days?

In fact, it's already done. To a certain extent at least.

One of the efforts is called Java, which is a cross-platform language. Java compiler compiles source to something called "bytecode", which is nothing more than a machine-independent "assembly language". That "executable" is later executed by the Java Virtual Machine (JVM), which is the part that differs from platform to platform (that is, Windows JVM is obviously different from MacOS JVM).

However, cross-platform apps are not that simple. It's relatively simple to write a basic VM that would execute some kind of abstract bytecode for every possible platform. But the language itself is practically nothing if it lacks a rich class library. So implementing the said class library is a very hard thing for various reasons.

Microsoft Visual Studio: Windows and Unix project source code compatibility

Step 1) set up your continuous integration system to build the code on Windows and Unix every time from day one. Preferably with multiple compilers on each platform.

Step 2) Use a cross-platform build system like scons or cmake.

Step 3) Don't use any platform specific code in your program at all - and when you have to, implement multiple versions under various ifdef guards. Prefer using cross-platform libraries instead.

Step 4) make sure you have plenty of unit tests (especially for the bits where you had to implement something multiple times using platform specific code) and make sure your CI system runs all the tests for every commit.

Step 5) Make sure all text is UTF-8 encoded from day one - conversion to other encodings can happen at the display layer, but keep everything UTF-8 clean internally.

Step 6) Do extensive manual testing on all supported platforms.

And make sure to tweak every compilers warning setting waaay up and make warnings errors (and fix all such errors). What's a warning with one compiler on one platform can often be silently miscompiled code with a different compiler on another platform.

Shifting from Windows to *Nix Programming Platform