Deciding on a programming language

[polarmystery]

Got a question for the community:

I am going to try and learn on a Linux platform (Ubuntu) to do some device driver creation/hardware manipulation but I don't know what is the best programming language to do it on. I have a genuine familiarity with C++ (from school) but I haven't used it in some time. I have all the basic understandings of object orientation, recursion, and most of the basic commands I still understand but most everything else I've pretty much forgotten.

I am re-learning, or rather deciding on doing this so I can change my current job to do something I would really like to do in the future. In my company they do exactly what I am going to learn to do (create device drivers in Linux via. C++ or C#) but I'm not sure which I should focus on.

I really have no background in C#. Any suggestions? It would be a lot easier to re-familiarize myself with C++ as I've used it a ton before and I'll pick it up a lot quicker but I don't know what is more popular nowadays. What do you guys think?

Just a side note: I have about three years industry experience and I am trying to move into a lateral position (not an upgraded position) but I know it will be a hard sell trying to interview by telling someone that I "sorta" remember how to do it. I'd like to know that I know what I'm talking about so I could convince someone to hire me for a new position. Any and all practice will be on my time. Any books/websites are also a welcomed suggestion! Thanks again

 

[MrChad]

If you're developing device drivers, you won't be using managed code (e.g. C#). I think C++ (or C, really) are your only options.

 

[polarmystery]

Originally posted by: MrChad
If you're developing device drivers, you won't be using managed code (e.g. C#). I think C++ (or C, really) are your only options.

all I needed to know. Thank you

 

[Cogman]

Originally posted by: MrChad
If you're developing device drivers, you won't be using managed code (e.g. C#). I think C++ (or C, really) are your only options.

Aye, for a C like language and low level coding, C++ is really the way to go. I believe that if you get C++ down, the transition to C# shouldn't be bad at all for you.

 

[slugg]

C++. C# is practically useless* on Linux/Unix.

* = some jackass is going to get on here and argue that _technically_ C# does work on Linux and that it's a good language, yadda yadda. I do think C# is a great language. My claim is that C# is _PRACTICALLY_ useless on a *nix environment. What I mean to say is that if you need to write some code to get something done, C# should NOT be your primary choice if you're on *nix. There are way more frameworks and libraries/packages for other languages (Python, Perl, C/C++, even Java) that can get you started much quicker. If you were on Windows, on the other hand, then C# is PRACTICALLY taking over, unless you need low level code.

 

[Nothinman]

I am going to try and learn on a Linux platform (Ubuntu) to do some device driver creation/hardware manipulation but I don't know what is the best programming language to do it on.

For Linux drivers your options are C or C. Some people have tried shoehorning modules done in C++ but it never works out because some C++ reserved words are used for variables, functions, etc so it won't even compile without a lot of reworking.

C++. C# is practically useless* on Linux/Unix.

I think the Mono and Gnome people would disagree.

 

[Modelworks]

If you intend to start doing device drivers and working low level with hardware you should also have at least a basic understanding of ASM. If you don't understand what instructions like EAX or MOV are doing then you may have a hard time making sense of the hardware.

http://www.emu8086.com/assembl...l_assembler_reference/

Is a good place to start. Lessons with emulator .

 

[Cogman]

EAX isn't an instruction, its a place

 

[Modelworks]

Originally posted by: Cogman
EAX isn't an instruction, its a place

Yeah but you have to register at the desk on arrival

 

[Markbnj]

Originally posted by: Cogman
EAX isn't an instruction, its a place

I thought it was some sound-related thing that caused blue screens.

 

[dinkumthinkum]

If you want to write Linux device drivers, you will be writing in C (gcc).

Linux Device Drivers, 3rd ed.
http://www.makelinux.net/ldd3/

It's a reasonably good book to get started with, and it's freely available online. Unfortunately, Linux internal APIs are a fast moving target, and there are out-dated details galore. The general principles will do you well, though. For the rest:

Linux Cross-reference
http://lxr.linux.no/

A hyper-linked version of the Linux source, for selected version. A good supplement to tags and other editor cross-reference tools. In many cases, there simply isn't documentation for the features you want to use. Diving in the source code is the most effective way to find out How Things Are Done.

Kernelnewbies
http://kernelnewbies.org/

A general website for those getting started.

System emulators:
http://www.qemu.org/
http://bochs.sourceforge.net/
http://www.vmware.com/ (vmplayer is 'free' proprietary software)

You do not want to learn to develop on your actual hardware. Trust me. You will crash. A lot. Learn to use the emulators, they're really easy these days.

 

[Woosta]

^ I concur, C. </thread> No C++.

 

[squatchman]

How useful is C# without the .NET framework? At that point it would be like Java without the bulk of the Sun APIs, right?

 

[sourceninja]

C# is a good choice for applications. It runs in mono on linux and works great. A lot of great gnome apps are written in C#. Python, ruby, C++, C#, java, etc are all great choices for application development on linux

For drivers however your only choice is C.

 

[Modelworks]

Nobody bothered to ask, me included, but drivers for what ?
USB drivers you can use C++ for, I have even seen USB drivers written in delphi.
Of course things like a mouse or keyboard are a lot easier to write drivers for than something like a motherboard chipset. I'm currently writing USB drivers for a infrared receiver using C though as my background in C is programming embedded micros.

 

[degibson]

Originally posted by: Modelworks
Nobody bothered to ask, me included, but drivers for what ?

Something else that nobody bothered to ask is: are we talking about a real, privileged driver, a user-level driver, or both? As others have said, C is the only thing available for anything loaded into privileged memory... but lots of things will work for the latter.

 

[postmortemIA]

Originally posted by: Woosta
^ I concur, C. </thread> No C++.

theoretically, you could use C++ for driver programming in some limited cases, but nobody sane would do. C++ will use just fine existing C libraries.

the problem I see is OP is more familiar with object oriented languages than he is with C, and this task does not need OO.

 

[dinkumthinkum]

You can write drivers in any language so long as you can eliminate the need for run-time support, or build that run-time support into the kernel, and interface with the existing kernel code written in C. As a practical matter, the kernel caters to C programmers and you will need to be able to understand the existing C code in order to have success. However, I am aware of some projects to allow other language environments to integrate with the Linux kernel.

For someone who is trying to learn to write a device driver primarily, and who is not interested in programming languages themselves, it is probably best to stick to my original advice.

 

[polarmystery]

Originally posted by: Modelworks
If you intend to start doing device drivers and working low level with hardware you should also have at least a basic understanding of ASM. If you don't understand what instructions like EAX or MOV are doing then you may have a hard time making sense of the hardware.

http://www.emu8086.com/assembl...l_assembler_reference/

Is a good place to start. Lessons with emulator .

I have used assemblers time and time again from school. I used NASM for some LCD I prog I made a while ago. The class I took for it in college was the reason why I wanted to start doing it!

 

[polarmystery]

And yes I am more familiar with Object-Oriented programming (ala C++) but I do know some about C. I am in essence re-learning C again with an old book I had in college. The company I currently work for has positions where they create linux device drivers for some of the embedded boards they create. I do not know how they use them or what they interface with (I don't have access to that information) but as long as I form a general idea, a job transition would be a lot easier than knowing nothing.

 

[Red Squirrel]

C# is easier and has way more built in functionality, but C++ is more robust imo and lets you get at a slightly lower level then C#. Even things like manipulating packets at the bit level become very hard to do in C# compared to C++. Also C++ is pretty much the Linux standard as far as I know. C++ is also not really owned by any one company, so there's no bias as to which OS it works better on. C# is a MS product and thus, made for Windows. Yes you can get C# to work in Linux but why bother, just go C++ route then your app should work in both windows and Linux (I like testing it on both as I'm coding so I can catch stuff fast, as not all function/headers work, obviously windows.h stuff wont work in Linux, for example).

For drivers, then C++ for sure. C++ can be frustrating at first as you have to reinvent the wheel a lot, but just make your own set of libraries then reuse them in all your apps. I've done this with networking and what not, as network code is long and not really something one could learn by heart, but by making a simple class for it it makes it easier to manage and cleaner. If there's a bug in your class and you wrote 5 programs then fix the bug and recompile those 5 programs and the bug is fixed in all 5.

 

[Nothinman]

Also C++ is pretty much the Linux standard as far as I know

If anything C is the Linux standard, C++ has gone through so many revisions that have changed the ABI that mostly everyone except for the KDE/QT crowd ignore it.

C# is a MS product and thus, made for Windows.

I can't remember the boundaries right now but most of .Net are published standards. Gnome wouldn't be investing in C# and Mono so heavily if the rug could be pulled out from under them next year.

just go C++ route then your app should work in both windows and Linux (I like testing it on both as I'm coding so I can catch stuff fast, as not all function/headers work, obviously windows.h stuff wont work in Linux, for example).

There's still a lot of platform specific stuff with C++ that you have to endure, even moreso if you're looking at GUI apps.

For drivers, then C++ for sure

Really? Ever looked at the Linux source code? Drivers done in C++ won't even compile because some C++ reserved words were used as functions, variables, etc. The whole "Why isn't the Linux kernel done in C++ is a FAQ at this point because it comes up every 6mo to a year on lkml.

 

[pdusen]

Originally posted by: Nothinman

Also C++ is pretty much the Linux standard as far as I know

If anything C is the Linux standard, C++ has gone through so many revisions that have changed the ABI that mostly everyone except for the KDE/QT crowd ignore it.

It is true that C is the Linux standard, but not for the reasons you say. Linux got started before C++ really took off (early 90s), so by then the Kernel and a lot of the GNU userland had already been done in C and other languages.

You have some strange ideas about C++. The language itself hasn't actually changed much (and where it has, it is almost entirely supplementary). The biggest changes have been changes (again, mostly supplementary) to the STL.

Even if you have a program from 10-15 years ago that doesn't compile on today's C++ (which is unlikely enough by itself), the changes to make it work are trivial at best.

There's still a lot of platform specific stuff with C++ that you have to endure, even moreso if you're looking at GUI apps.

I'm going to assume you meant something slightly different than what you said, because that doesn't even approach making sense. There is a single up-to-date C++ specification; there is nothing platform-specific about C++.

Compilers, on the other hand, are a different matter, and it's not unusual to have to work around little oddities on different compiler platforms. But that tends to be true of C as well, and even C# and Java in some instances, so it's hardly a unique problem for C++.

You mentioned GUI apps; that depends entirely on the toolkit you use, and is not unique or relevant to C++.

For drivers, then C++ for sure

Really? Ever looked at the Linux source code? Drivers done in C++ won't even compile because some C++ reserved words were used as functions, variables, etc. The whole "Why isn't the Linux kernel done in C++ is a FAQ at this point because it comes up every 6mo to a year on lkml.

True enough. At this point it's not really worthwhile to attempt any sort of core system development in C++; especially in the kernel.

It would be interesting to see an attempt at a kernel in C++, but that's pretty much an academic thing at this point. There are enough freely available, high-quality kernels that it's not really necessary to write any new ones from scratch.

 

[Nothinman]

It is true that C is the Linux standard, but not for the reasons you say. Linux got started before C++ really took off (early 90s), so by then the Kernel and a lot of the GNU userland had already been done in C and other languages.

The language that the kernel and the base userland are done in are irrelevant since there is sufficient infrastructure in C++.

Even if you have a program from 10-15 years ago that doesn't compile on today's C++ (which is unlikely enough by itself), the changes to make it work are trivial at best.

I said ABI, not API. Recompiling something is one thing, but when the ABI changes you need to recompile everything linking against those libraries which is a PITA.

 

[pdusen]

Originally posted by: Nothinman

It is true that C is the Linux standard, but not for the reasons you say. Linux got started before C++ really took off (early 90s), so by then the Kernel and a lot of the GNU userland had already been done in C and other languages.

The language that the kernel and the base userland are done in are irrelevant since there is sufficient infrastructure in C++.

I'm not really sure what that has to do with what we were talking about. Can you please clarify?

Even if you have a program from 10-15 years ago that doesn't compile on today's C++ (which is unlikely enough by itself), the changes to make it work are trivial at best.

I said ABI, not API. Recompiling something is one thing, but when the ABI changes you need to recompile everything linking against those libraries which is a PITA.

Perhaps, but that, too, is a question of the platform, not C++ itself. Besides, the only instance in which that happens would be a switch of platforms or an enormous version jump; for instance, would you honestly expect a program compiled with g++ on Linux to not have to be recompiled for VC2008 on Windows? I think not.

Correct me if I'm wrong, but it sounds to me like your problem is with the need to recompile a C++ program any time you switch elements of the environment. Sometimes it can be difficult, but it's something inescapable in system-level programming, so I recommend you get used to it.