Hi everyone.  I am very excited about this forum.  I am new to programming.  I want to learn how to write non-proprietary code that can work on as many current machines as possible.  I'm interested in linux, bsd, unix, mach, and windows.  I intend to learn as much about these as possible.  But, my main objective is to learn assembly language.  I would like to get into new Kernel research studies starting from the ground up.  Basically I want to develop my own mini Kernel's.  I would also like to write my own High Level language based on assembly language. (I realize this will take years of research.) I want to learn to write a new kernel that will not require licensing of either proprietary or non-proprietary models that are already copyrighted.  Though I will study all of them to gain knowledge of the different approaches out there.  I currently like the concept behind MicroKernels such as Mach 3.0 and the new Mach 4.0.  Based on this information, what books would you read in order from beginning to end to become advanced in assembly language and development?  I should point out that I am just starting (as a Community College transfer student in General Studies) as a Jurnior in Computer Science/Computer Engineering (Double Major).  But I'm 32 years old so I want to learn as efficiently as possible.  I realize everyone will have a slightly different approach of study.  I'm hoping to find the most broad consensus of the best books to get me started.  Then I should be able to better choose books based on my needs.  Please share your perspective.  The thing that fascinates me is the several different Kernels currently being used.  So far here is what I've read that others have suggested:

1) First study C Programming
2) Then study C++
3) Then study Randall Hyde's Assembly Language Books
4) Also study W. Richard Stevens TCP/IP books.  (I've heard this is the TCP/IP Bible.)

Am I on track? 
Is this the correct order or would you study C and Assembly language together first, then C++? 

Or would you study C++ then C?  Why? 

Which programming C books are your favorite and why?
Which C++ books are your favorite and why?
Which Assembly Language books are your favorite and why?
Any other programming books and why?

I know that my goals are very ambitious.  This is why I am hoping that you can guide me though a step by step approach in the beginning so that I don't waste my time buying and studying the wrong books.  I want to approach this from the development side.  I'm sure I will eventually learn the most popular proprietary GUI type languages etc. 

Thanks for taking the time to read this post.

Posted on 2008-03-09 19:58:54 by der4
I must admit I really don't know what the "best" or "proper" way to learn is. I personally started out with Pascal, then 16-bit assembly, then 32-bit Assembly, then C/C++, et cetera. I'd probably recommend starting out with "C++ as C" or "Super-C" - basically doing .cpp files, writing procedural rather than OOP code, but using things like C++ std::vector instead of malloc/free, and std::string instead of raw char arrays.

Then, you can take on (32- and/or 64-bit, forget about 16-bit unless/until you really need it) assembly and "normal" C more or less at the same time, and add C++ (and spend quite some time ont it, if you want to do it right and not write crap bloated code :)). Then you have a pretty potent low-level base arsenal.

I'd also recommend looking at a couple of other languages, a scripted language like Python can be really useful to prototype ideas, or write "super batch files" (why limit yourself to .bat or bash shell scripts when you can do even better?). I'm recommending Python specifically because that's what the www.scons.org build system uses. If you want to play with kernel development, you need a powerful build system, and might as well skip the messy makefiles.

With regards to books, I don't really know - Randy's book focuses on 16-bit assembly, and for 32-bit his own HLA syntax. Haven't read them myself so I really don't know what to say about them, personally I learned assembly from Turbo Debugger, source code snippets, Turbo Pascal 6/7 inline BASM, and 386intel.txt... as for C/C++ I don't really know any good introductory text, there's of course Kernighan & Ritchie: The C Programming language and Bjarne Stroustrup: The C++ Programming Language but those are relatively dry references - not everybody deals with that presentation format very well :)

Once you have basics, I find that books from Addison-Wesley tend to be of pretty high quality. There's a lot of good books on C++ (which is what I've specialized in), and I wouldn't know which single book to recommend. but Scott Meyer's books are imho good intermediate books telling about some pitfalls to avoid, et cetera.

For a free C++ book, there's Bruce Eckel's Thinking in C++. I never completed it, but it seems pretty decent for a free book - and certainly dozens of times better than any of the "Teach yourself X in Y timeunits" :)

And yes, your goals are very ambitious - especially since you're interested in kernels. There's a lot of theory and practice you'll need to track down there, and you should definitely set some design goals: do you want to run on very low-end hardware, single- or multi-user, latest and greates x86-64 support or perhaps down to ARM scale, et cetera. The sad thing about kernel writing is that you'll have a hard time writing drivers because of missing specs, although things have brightened up a bit in the last months: Intel has released a lot of documentation about their integrated graphics, AMD has as well, and NVidia might be following troop - but there's still all the wireless LAN devices, storage controllers, ...

Good lucK! :)
Posted on 2008-03-09 20:21:13 by f0dder
...your goals are very ambitious

It looks like Bill Gates MK2 has arrived. ;)

My own recommendation would be to do the simplest language possible to start with.


Assuming you are hugely ambitious, these kind of languages are really easy to learn quickly, and you can quickly write decent outputs for yourself because debugging is so much easier and faster for a newbie.

Then you can quickly move onto slightly larger projects, which involve building an integrated program, and it's only at this point that you will start to understand what's really involved if you want to do coding for yourself.

This is also the point to decide what language you want to use.
You really can't decide what language you would prefer until you learn a bit of coding, and the faster you progress, the sooner you can decide for yourself.

So the simplest language possible is the best one to start with because that's the one which opens your eyes to the realities of coding sooner than later.

One you get your head around the brain crushing almost limitless possibilities of coding, and experience the triumph of your first final output product, then you'll be able to decide for yourself.

And only you will know where you want to go, and you won't know until you reach that point.

"what language should I use" is actually a chicken and egg question.
For myself, I spent 12 months doing DOS asm, and I could have reached the same personal conclusions doing BASIC for a couple of months, thereby saving myself 10 months of computer triggertime.
Posted on 2008-03-10 07:37:59 by eek
Never start with BASIC, though, it promotes brainrot.

And there's really no way around C/C++/Assembly if you want to do kernel programming - sure, it's possible to do kernel programming in C# (source) with only a very small amount of assembly, but you do need to understand C/C++/Asm in order to read documentation & existing kernel stuff, and get your own stuff done :)
Posted on 2008-03-10 08:29:05 by f0dder
I think many of us 'old timers' started with some kind of basic, before we learned that machinecode existed.

Starting with basic (of any kind) is not a sin, STICKING with it is.
Posted on 2008-03-11 08:17:04 by Homer
/*I've decide to start with Standard C.*/
#include <studio.h>
printf("Thank you all for posting.  As I've researched this more I have discovered that everyone has started somewhere in programming, whether it be a high level or lower level language.  Someone referred me to a book called "Absolute Beginner's Guide to C"  --Greg Perry.  I picked it up at a Barnes and Noble and I must say I actually understand the concepts.  I  learned Mandarin Chinese as a non native white guy.  Learning Chinese taught me how I personally learn other languages.  This C book works for me.  However, I realise not everyone learns the same way.  Another thing that has helped me grasp the basic concepts of this book (besides the author, who is a very good teacher) is the fact that I am reading about the architecture of the computer itself. It makes no sense to me that some programmers don't actually understand the machine they are trying to code.  I have also been reading it's history.  My next step is to get a solid work book that will give me basic code problems.  That way I can actually write this stuff.  It's one thing to have a reference of functions and get an idea of how they work.  It's a whole other thing to actually be able to pull them out of a hat, especially when it's crunch time.  I have decided that I need to not only be able to write C but I need to write it as accurately as possible./n");

printf("I have heard that debugging is a good way to improve one's skills.  Are there any books you would suggest that have debugging tutorials or should I use Open Source projects as my reference?  My only concern about Open Source is the accuracy of those writing the code.  Because I am so new I don't want to get bad habits.  I would prefer to have a solid foundation from the right source prior to doing group work.  Any suggestions on this would be very much appreciated.  At what point do I want to start studying Assembly Language?  I really do want to learn Assembly.  I realize some people would question why, because of the ASCII standards, but I figure the closer I get to the machine, with fluency, the better shot I have at being able to attempt studies on new Kernels etc.  Once I understand them I can implement the code in C to be Standard.  I really find the research end of computer science/engineering very fascinating.  The history on UC Berkeley in regards to the UNIX versus BSD, and Linux is very interesting./n");

printf("I hope it's okay if I ask questions from your community as I work on learning code?  I know I'm a complete beginner and my code will be very basic for you guys.");
return 0;

Posted on 2008-03-11 21:48:16 by der4
I'm no pro, but a book that i'm really enjoying is "Art of Assembly Language Programming" by Randy Hyde. You can pick up a copy free on the internet in either HTML or PDF form. It covers lots of low level details on how opcodes are handled etc. Here's what the author says
"I've geared this text and the accompanying software to University level students who've never previously learned assembly language programming...."
"A secondary audience who could benefit from this presentation is any motivated person that really wants to learn assembly language. Although I assume a certain level of mathematical maturity from the reader (i.e., high school algebra)...."
"... High school students and those who haven't seen a school in 40 years have effectively used this text (and its DOS counterpart) to learn assembly language programming."
Still I'd recommend learning a language like C++ first as it's higher level data structures are much more easily understood in that format versus the assembly counterpart. Plus after learning the higher level stuff I gained a better understanding of what things would be better done in c++ etc. and what needs to be assembly for optimization. It saves a lot of time. Have fun!
Posted on 2008-03-12 03:49:44 by elokide
To be honest, I'm really not one for book learning, I'm mostly self-taught .. I've learned by staring at code, reading whatever whitepapers I could muster, staring at more code, trying stupid ideas,  translating code from one language to another, and staring at yet more code.
If you stare at it long enough, it will hatch.
Posted on 2008-03-13 01:25:17 by Homer
That's the way I originally learned as well, Homer. I do feel that if you want to learn a complex beast like C++ properly, simply staring at code isn't enough - some insight in why a particular construct/pattern/whatever is used, some insight in techniques and their reasoning, etc. is hard to get from source code, and that's where book material does better.

Obviously there's no problem learning most languages by looking at source code snippets from the internet and such, but you don't necessarily end up writing good code that way - there's so much utterly crap C++ code floating around :)
Posted on 2008-03-13 07:55:45 by f0dder