sanders wrote:
Thankyou for your responses, sadly my magic fairy queens are not yet educated in C or ASM... so I will have to force myself to conquer those languages myself.
The good news is, as Pype points out, large sections of the syntax of Perl and C are very similiar, if not the same. Learning Perl first was the right move; it is a much easier language to work in as a novice, despite it's complexity.
I'm teaching myself C and ASM, but I keep coming into code that makes me ask myself 'This is so much easier in Perl' [[...]]
That shouldn't be surprising. Perl was written to be a utility language - one which you could use to write powerful scripts quickly. It incorporates a large number of complex tools to make it easy to throw together a script for, say, filtering a mail spool for key words or phrases out a particular list, extracting the messages containing them, generating mail messages with the extracted message attached, and sending it to an anti-spam organization. Perl combines influences not only from C, but also from C shell and Bourne shell scripting, AWK, Emacs LISP, SNOBOL, and Icon, and possibly others (you'd have to ask Larry Wall), and can mix paradigms and metaphors with ease. Lastly, it takes advantage of the interpreted environment to allow such constructs as [tt]eval()[/tt], which allows you to run code stored in a string. For that matter, while it is rarely done, it is possible to run Perl interactively, in the debugger (try running '[tt]perl -de 0[/tt]' some time and see what I mean); there is talk of adding a true interactive mode, like those of Scheme or Python, but nothing has come of it AFAIK.
The price for this flexibility is that the language is complex, and implementing is even more so. It requires a huge amount of runtime support, so much so that it that it is more efficient to run it interpreted rather than compiled - a natively compiled Perl program would, in essence, have to link in the equivalent of the interpreter anyway (this is what compiled VB programs do, BTW - the runtime DLLs needed by them amount to the whole of the VB interpreter). Because of this overhead, writing a Perl compiler that could generate completely standalone code would be more difficult than writing a whole operating system - or rather, it would
be writing a whole operating system, just for the language interpreter! (This has been done before; see JavaOS, or the original Smalltalk systems, or the UCSD-p system, for examples of this approach).
C, by contrast, is a much simpler language, aimed at allowing programmers to build systems from the ground up with no more support than a text editor, a compiler, and a link-loader. But because of that, it requires more programming effort to do anything in C; even with the equivalent libraries available (which they won't be, in OS development, until you've written them yourself), it takes more work to write some kinds of programs, simply because Perl has a lot of built-in support for e.g., regexps, in the form of special syntax, whereas in C you must use function calls.
It is entirely possible to write the bulk of the OS in a very high level language like Perl, running on top of a small kernel and an interpreter, as mentioned before; but the low-level parts
must be written in assembly, or a combination of assembly with some low-level, low overhead language like C, Modula-2, or Forth (which, while interpreted, is quite well suited for this sort of programming; the interpreter is usually less than 32K of assembly code even on modern processors). I myself plan such an approach. Keep in mind, however, that to do that, you not only need to write the OS, but the language interpreter/compiler as well, a major undertaking in it's own right.
I am having difficulty finding a good book to teach ASM.
It sounds like it is a more advanced book than you need right now; for an assembly language novice, I'd recommend (as I always do) Jeff Duntemann's
Assembly Language Step by Step, if you can get a copy. It covers the basics in detail, with all examples in NASM; the first half of the book gives examples of DOS real-mode programming (which should run under WINE without a problem), while the rest discusses programming under Linux. You'll probably need to get through it, and into the more advanced book a bit, before you reach a point which is really applicable to OS programming, but for a beginner, it is great. Duntemann explains assembly programming with far more wit and clarity than most other writers can for high-level languages.
