Wednesday, May 04, 2005

The Force Is Strong With This One

If you've not yet guessed, my favourite programming languages are C,Python and D. I have no real order there, as it depends on what i'm doing, but with those three languages i have a whole spectrum of problem areas covered.

Recently, i've been thinking of adding one more layer to projects i do in C. A python layer.

The thougt process follows from trying to make a system as programmable and explorable as possible, and to reduce the amount of time needed for a hacker to get to actually hacking the system. What trips me silly about python everytime, is the live intepreter you get with it, so one can interogate libraries while learning about them. You don't have to use the usuall - READ_FIRST->Code->Compile->PRAY_MURPHY_IS_BUSY->Execute cycle. You can actualy grab a library, and fireup the intepreter, print the __doc__ string, and start figuring out how to go, if you get stuck, google, then come back and continue.

To a large extent you can do this in other languages, but Python with its live intepreter takes it to a new level... trust me :)

Anyway, this is a model of programming in c i'm trying to formulate:

[Applications (C-Programs,shellscripts, GUIs,etc)]

| | |

| [c-command-line-utility][Python Layer]

| | |

[ c-library-layer ]


[ problem scope ]

At the bottom-most of this layer, is the problem we're trying to solve. Say for instance, manipulating Netfilter on LInux in userspace.

The first layer, is made up of a well designed C-Library (in this case, libipq), that properly abstracts every kind of interaction with the linux Netfilter layer. Once the library is in place, theoritically, the problem is solved, but normal users can't use it yet. Applications have to be written.

On unix, there is a common practice, that these libraries normally are accompanied by command-line utilities, that are almost like proof-of-concepts for the libraries. Some of these tools are so advanced that every single thing doable in the library is doable by the commandline utility with just an option switch and the proper argument. (I should state here that sometimes, probably most times i guess, these libraries are never solo projects, but actually arise while on the path to craft the command-line tools)

Traditionally, after the command-line tool layer is available, it qualifies as an Application, well..., as a System software. At this stage, system administrators can use shell scripting, perl or even python to drive the command-line utility in ways the creators never thought was possible. Finally, GUIs can be tacked on as a Front-end to many of these utilities, and we have a complete appliation stack.

The problem is that once in a while, there exists a feature that can not by its very nature be exposed by the command-line-utility. Apart from that, it may not be desirable for any reason to write a much higher level application in C. I personally prefer to leave that layer for languages like Python and D... Actually Python ;)

This is where the other layer, the Python Layer comes in. I placed it at the same layer as the command line utility, because it interacts with the c-library-layer for you, but unlike the command-line-utility, it can have access to every single functionality of the c-library, hence allowing even more to be done at a higher level in the stack, without having to fall back to raw C.

I'm currently literally putting my money where my mouth is, by building a python layer for 'scode' i call, pyscode. Scode is a personal project of mine (hmm... i should put it up on my website next weekend.)

I’ve also concluded a python extention to another library I have (a much smaller one I use for managing packed inet addresses and dotted notation), called ‘addrtool’.

so far, i'm having fun learning how to extend Python with C. It trully a path to increasing the Force withing you :D

Ok... so much for my ramblings.


[x for x in range(0,200) if (lambda y: len([z for z in range(2,y-1) if y%z == 0]) == 0)(x)]


Post a Comment

<< Home