Download Code

We will be dealing with

• Introduction and some basics

• Creating a device file

• The driver code
  

• Compiling the driver

• Loading and unloading the driver

• Testing the driver

The post helps understand how to write a device driver, the significance of a device file and its role in the interaction between a user program and device driver.

Introduction

The devices in UNIX fall in two categories- Character devices and Block devices. Character devices can be compared to normal files in that we can read/write arbitrary bytes at a time (although for most part, seeking is not supported).They work with a stream of bytes. Block devices, on the other hand, operate on blocks of data, not arbitrary bytes. Usual block size is 512 bytes or larger powers of two. However, block devices can be accessed the same was as character devices, the driver does the block management. (Networking devices do not belong to these categories, the interface provided by these drivers in entirely different from that of char/block devices)

The beauty of UNIX is that devices are represented as files. Both character devices and block devices are represented by respective files in the /dev directory. This means that you can read and write into the device by manipulating those file using standard system calls like open, read, write, close etc.
For eg, you could directly write or read the hard disk by accessing /dev/sd* file – a dangerous act unless you know what you are doing (for those interested, try hexdump  –C  /dev/sda   –n  512 – what you see then is the boot sector of your hard disk !). As another example, you could directly see the contents of the RAM by reading /dev/mem.

Every device file represented in this manner is associated with the device driver of that device which is actually responsible for interacting with the device on behalf of the user request. So when you access a device file, the request is forwarded to the respective device driver which does the processing and returns the result.

For instance, you might be knowing about the files /dev/zero (an infinite source of zeroes), /dev/null (a data black hole), /dev/random ( a source of random numbers) etc. When you actually read these files, what happens is that a particular function in the device driver registered for the file is invoked which returns the respective data.

In our example, we will be developing a character device represented by the device file /dev/myDev.  The mechanisms for creating this file will be explained later.

Under the hood

Now how does Linux know which driver is associated with which file? For that, each device and its device file has associated with it, a unique Major number and a Minor number. No two devices have the same major number.  When a device file is opened, Linux examines its major number and forwards the call to the driver registered for that device.  Subsequent calls for read/write/close too are processed by the same driver. As far as kernel is concerned, only major number is important. Minor number is used to identify the specific device instance if the driver controls more than one device of a type.

To know the major, minor number of devices, use the ls – l command as shown below.

ls -l

The starting ‘c’  means its a character device, 1 is the major number and 8 is the minor number.

A Linux driver is a Linux module which can be loaded and linked to the kernel at runtime. The driver operates in kernel space and becomes part of the kernel once loaded, the kernel being monolithic. It can then access the symbols exported by the kernel.

When the device driver module is loaded, the driver first registers itself as a driver for a particular device specifying a particular Major number.

It uses the call register_chrdev function for registration. The call takes the Major number, Minor number, device name and an address of a structure of the type file_operations(discussed later) as argument. In our example, we will be using a major number of 89 . The choice of major number is arbitrary but it has to be unique on the system.

The syntax of register_chrdev is

int register_chrdev(unsigned int major,const char *name,struct file_operations *fops)

Driver is unregistered by calling the unregister_chrdev function.

Since device driver is a kernel module, it should implement init_module and cleanup_module functions. The register_chrdev call is done in the init_module function  and unregister_chrdev call is done in the cleanup_module function.

The register_chrdev call returns a non-negative number on success. If we specify the Major number as 0, the kernel returns a Major number unique at that instant which can be used to create a device file.
A device file can be created either before the driver is loaded if we know the major and minor number beforehand or it can be created later after letting the driver specify a major number for us.

Apart from those, the driver must also define certain callback functions that would be invoked when file operations are done on the device file. Ie. It must define functions that would be invoked by the kernel when a process uses open, read, write, close system calls on the file. Every driver must implement functions for processing these requests.
When register_chrdev call is done, the fourth argument is a structure that contains the addresses of these callback functions, callbacks for open, read, write, close system calls. The structure is of the type file_operations and has 4 main fields that should be set  – read,write,open and release. Each field must be assigned an address of a function that would be called when open, read,write , close system calls are called respectively.  For eg

file_operations structure initialisation

It is important to note that all these callback functions have a predefined prototype although the name can be any.

Creating a device file

A device file is a special file. It can’t just be created using cat or gedit or shell redirection for that matter. The shell command mknod is usually used to create device file. The syntax of mknod is

mknod path type major minor

path:-path where the file to be created. It’s not necessary that the device file needs to be created in the /dev directory. It’s a mere convention. A device file can be created just about anywhere.

type: -‘c’ or ‘b’ . Whether the device being represented is a character device or a block device. In our example, we will be simulating a character device and hence we choose ‘c’.

major, minor:- the major and minor number of the device.

Heres how

mknod command

chmod, though not necessary is done because, if not done, only processes will root permission can read or write to our device file.

The driver code

Given below is the code of the device driver

 Download Code

Device Driver Code

For debugging, I have included some printk messages in the code. To see those messages while the driver is in action, do dmesg|tail

Compiling the driver

A Linux module cannot just be compiled the way we compile normal C files.  cc filename.c won’t work. Compiling a Linux module is a separate process by its own. We use the help of kernel Makefile for compilation. The makefile we will be using is.

makefile for module compilation

Here, we are making use of the kbuild mechanism used for compiling the kernel.
The result of compilation is a ko file (kernel object) which can then be loaded dynamically when required.

Loading and Unloading the Driver

Once the compilation is complete, we can use either insmod or modprobe command ( insmod myDev.ko  or modprobe myDev.ko, of course assuming the current directory contains the compiled module). The difference between insmod and modprobe is that modprobe automatically reads our module to find any dependencies on other modules and loads them before loading our module (these modules must be present in the standard path though!). insmod lacks this feature.

To test if the driver has been loaded successfully, do cat /proc/modules and cat /proc/devices.  We should see our module name in the first case and device name in the second.

cat /proc/modules

cat /proc/modules

To unload the driver, use rmmod command. (rmmod myDev.ko)

Testing the driver

To test the driver, we try writing something to the device file and then reading it. For example,

Testing the driver

See the output. (The reason for the ‘ugly’ output is because echo automatically writes a newline character to the end of string. When the driver reverses the string, the newline is shifted to the front of the string and there is no newline at the end. Hence the result being ‘ugly’)

To see how this can be done from our program, I wrote a demo program given below

Interacting with the driver

Compile it normally(or run make test) and run ./test  some_string  and see the output.

Testing the driver

Note: You need to be root to compile the module, load the module and unload the module.

This driver interface presented here is an old one, there is a newer one but the old one is still supported.

Download Source

The post explains how to

• Write a bootloader

• Write a shell, a kernel placeholder
  

• Implement a basic filesystem

• Write the OS to disk

• Boot from the OS

The OS is written in the open source NASM assembler in Linux. To understand the working, you need to have some understanding about x86 booting process, bootloaders and real mode of processor operation.

Booting Process Basics

When the system is powered on, BIOS pops into action and performs what is known as Power On Self Test(POST) to verify the working of devices, initializing them etc. Immediately after that, POST loads BIOS executable code, present in the BIOS ROM into memory at address which is usually 0xF00000.  POST then places a jump instruction in the first byte of memory (CS:IP = 0). The jump instruction is nothing but a jump to the address 0xF00000 where the BIOS code is loaded.  Now the BIOS code takes control and performs certain operations like setting up the Interrupt Vector Table(IVT), finding a boot device, setting up certain information in RAM(BIOS Data Area), loading the bootloader  etc.

BIOS provides certain basic interrupts for the programmer for basic functions like loading and storing disk sectors, reading keyboard, printing to screen etc. These interrupts are similar to DOS interrupts but are not DOS interrupts.

Back to topic,  once these processes are over, the BIOS iterates through the list of boot devices and according the boot order preferences, the bios searches for a bootloader in each boot device. If a bootloader is found, its loaded into memory and is given control.

A point to note is that whenever system is powered on, whatever be the processor, Core 2 Duo or Core i7 or whatever operates in 16 bit real mode by default until it is explicitly asked to switch to 32  bit protected mode (by setting PE bit in CR0 register and doing a far jump to fix CS to point to a segment descriptor after setting up GDT).

Bootloader Basics

Bootloader is basically a 512 byte piece of machine code that is present in the first sector a boot device.  Bootloader is the first user defined program that’s loaded into memory and given control of. It is the duty of the bootloader to load the OS into memory and pass control to it.

A bootloader must be exactly 512 bytes in size. BIOS identifies  a valid bootloader by means of a signature. The 511th byte of the bootloader should contain the value 0×55 and 512^th byte should have the value 0xAA.

A Bootloader will always be loaded at address 0x7C00 in RAM. Usually, this corresponds to CS:IP pair of 00:0x7C00 but some BIOSes set CS:IP as 0x7C0:0 which is essentially points to the same address  but leads to issues in writing bootloader when we have to specify the offset where our code will be loaded.
This can be easily dealt by defining an offset 0 and then jumping to 0x7C0:start , where start is the label of the next instruction following  the far jump. This jump sets CS = 0x7C0

(Note: Physical address = CS x 16 + IP)

Our Bootloader

Our bootloader, present in the first sector of the pendrive  (the mechanism for writing the bootloader and the OS into the pendrive will be discussed later) will be loaded into memory and execution will immediately start.

Our bootloader serves 3 purposes, it displays a welcome message and then loads the OS and file table from the disk and jumps to OS entry point. The os is loaded at address 0×1000 and file table at address 0×2000

Heres our bootloader source

Download full Source

Our Bootloader

Bios provides interrupts for displaying characters as well as strings on screen. Here I have used character display interrupt to write a function to print a zero-terminated string like in C.

The interrupt for displaying character on screen is

INT 0×10, BX = character color, AL = character to display, AH = 0x0E

Our bootloader, OS and executables are stored on  disk . For execution, they need to be loaded to RAM. The bootloader will be loaded by BIOS and the rest we have to load when required through the sector loading interrupt.A block of 512 bytes (in this case, need not always be) is called a sector.
For loading sectors off the disk to RAM, bios provides an interrupt, INT 0×13 and the parameters to set are

AH = 2

DL = drive,  DL = 0×80 for hard disk and this applies to our pen drive

DH = head number

CH = track number

CL= sector number of the sector to be loaded

AL = number of sectors to load

ES = segment to load the sector

BX = offset from ES where the sector is to be loaded

Our  bootloader occupies the first sector, file table in the third sector and OS in the third sector.

The bootloader loads the os into address 0×1000:0 and filetable into address 0×2000

Implementing Filesystem

The shell provided by our os enables the user  to type an executable name and run it. For that , the os must know where exactly each executable is located on disk and this is where the concept of file system surfaces. A file system, in simple words is basically a specification that tells how to locate of a file on disk given its name.

For our purpose, I made a simple filesystem. Each file is mapped to a sector in disk to form a string with following structure

{file1-sector,file2-sector,…,filen-sector,}

This filetable is loaded to 0×2000:0 by the bootloader this address space is scanned to find the sector where the requested file is stored on disk and that sector is brought to RAM.

Our OS/Shell

So, the bootloader has loaded our OS at 0×1000:0 and filetable at 0×2000:0 and it makes a far jump to 0×1000:0, the OS entry point.  The working of the shell is simple, using BIOS interrupt to reach character, we read the executable name from the user. The filetable loaded at 0×2000:0 is scanned for a match, the associated sector number is read and that sector is loaded into memory at 0×9000:0 and the shell makes a far jump to this address. If the name entered by the user cannot be matched in the file table, an error message is shown.  After the executable completes execution, for it to return back to the OS, it must make a far jump to 0×1000:0, the OS entry point. This step is functionally similar to executing (AH= 4ch, INT 0×21 in DOS)

The interrupt for reading a character from a keyboard is INT 0×16 with AH=0, the read character will be available in AL.

Heres our OS source

Download full Source

Our Shell

Writing the OS to disk

Okay so everything is done, the final thing to do to boot from the pen drive, is to write our os into it. It can’t just be done by copying the files to the pen drive. It doesn’t work in our case for two reasons:

1.   We cannot write the bootloader to the first sector using this method. When we ask the OS to copy a file, it copies the file to some free sectors and add this information to the file table.

2. If were to copy the files to the pendrive, our filesystem has to be known to the host OS, like FAT  which means we have to write code to parse that file system during boot time which, well is an overkill for this os

So, to write the bootloader and custom file system, we need to have low level disk access, for which the obvious choice is Linux.  Linux treats devices like files which can be read and written to. This is a really powerful and useful concept. Commands like ‘dd’ use this concept. The file representing our harddisk would be something like sda, something  like sdc for pen drive, it varies. To know the file allocated, after the pen drive is attached, run dmesg|tail in the terminal.

Now whatever we write to the device file will be written as such into the device which is exactly what we want. To write the bootloader, write the compiled boodloader into the first 512 bytes of the file and this would be written to first 512 bytes of the disk and this can be done using C file operations. Pretty easy, isn’t it. Now to write the file table and OS  to the 2^nd and 3^rd sectors of the disk, just write these files to the next two 512 bytes of the device file . The same procedure applies to writing the executables to disk

The following C code does the job of writing everything to disk. It takes the path of device file, bootloader, os and list of executable as command line arguments.

Copy Program

Booting the OS

Plug in the  pen drive, find its corresponding device file (use dmesg|tail), open the makefile, substitute its path in dev variable. Then run ‘make’ , reboot the system, choose to boot from mass storage and you could see the sweet sight of our OS booting . At the prompt,  type ‘help’ and hit enter, you could see list of available executables, like reg to dump registers, echo that echoes back a string read from the user

Here are some pics of the OS in action(Click to enlarge).

OS in action

Our OS in action

There are around 338 system calls in linux kernel  2.6.35.7 by default. Presented here a howto on adding a new one into the kernel, a 339^th one so that it will be available globally for any program. As example, we will implement the strcpy function as a system call so that it can be used without including string.h.

Obviously, you need the kernel source tree since some kernel modification is involved. Get it from kernel.org (any kernel version higher than 2.6.35.7 would work fine )and untar it to get linux-2.6.35.7. The paths used below all will be relative to this path.
We need to edit 4 files and 2 files need to be created.

The Code

First, lets start off writing the code for strcpy. We need to include the file linux/linkage.h because it contains the macro asmlinkage which means that the system call expects the arguments on the stack and not in registers. Printk is the kernel alternative of printf, but with certain peculiar properties.

Code for the system call

“<1>” tells printk that we are giving that message the highest priority.

Create a folder named ‘test’ in the root of linux source directory and save this file as strcpy.c in that directory. Create a Makefile in that directory containing only the line.

obj-y:=strcpy.o

Thus, now the strcpy.c file and Makefile are present in

linux-2.6.35.7/test/strcpy.c
linux-2.6.35.7/test/Makefile

The Edits

The following files need to be edited.

1. linux-2.6.35.7/arch/x86/kernel/syscall_table_32.S

Append to the file the following line

.long sys_strcpy

linux-2.6.35/arch/x86/kernel/syscall_table_32.S

2. linux-2.6.35.7/arch/x86/include/asm/unistd_32.h

This file contains the unique number associated with each system call. We can see the names of all the system calls and the number associated with each. After the last system call-number pair (around line 345), add a line

#define __NR_strcpy  338

(if 337 was the number associated with the last system call).
Then replace NR_syscalls directive denoting the total number of system calls by the previous number incremented by 1 ie the new value is

#define NR_syscalls 339

Note down the number 338, we need it later.

linux-2.6.35/arch/x86/include/asm/unistd_32.h

3. linux-2.6.35.7/include/linux/syscalls.h

This file contains the prototype of all the system calls. Here we append to the file the prototype of our function.
ie. We add  the line

asmlinkage  long sys_strcpy(char *dest,char *src);

linux-2.6.35/include/linux/syscalls.h

4. Makefile

Open Makefile present in the root of source directory and find the area where core-y is defined and add the folder test to the end of that line as shown below

Makefile

Next compile the kernel. Assuming you are familiar with kernel compilation, execute
make bzImage  –j4
The last argument is optional and is intended to speed up compilation on dual core CPUS
Once compilation is complete, install the kernel by executing the following command with root permission
make install
Once the kernel image is installed to /boot, reboot the system.

Testing

Now we need to check the newly done system call. Run the code below and feel the satisfaction

System call test

The kernel has performed the strcpy for us. Cool ! isn’t it

Note:
Execute the command dmesg now, you can see done printed in the last. Printk by default doesnt  print to the terminal. It writes to the kernel ring buffer which is printed by the dmesg

Try putting an infinite loop inside a system call, the system just drops dead. As it goes, the linux kernel does not preempt itself.

In PWM, we generate square waves whose duty cycle can be varied. Duty cycle refers to the fraction of the time period of the wave for which the signal is in high state (or simply ON state).
For example, for a square wave of period 100ms, if the duty cycle=50%,
the signal will be in high state for precisely 50 ms and in low state for the next 50ms that make up the period.
If the duty cycle =20 %, the signal  will be high for 20ms and low for the remaining 80ms.

An interesting aspect of PWM is that we can actually perform DAC (Digital to Analogue Conversion), the output voltage is proportional to the duty cycle we set. i.e. for example, if the duty cycle is 50%, the average voltage available on the OCA1 pin will be 2.5V  and for duty cycle = 30 %, the output voltage= .3x 5 V = 1.5 V and so on.

PWM modes

There are several modes of PWM generation provided by AVR  which decides the shape of the square wave generated (the placement of the high section in each cycle). The modes are Fast PWM, Phase correct PWM and Phase and Frequency Correct PWM. Each of these is explained with figures below.

Fast PWM

In Fast PWM, the timer starts form zero, sets OC1A pin high and starts counting up. When the count equals the compare value (set in the OCR1A register), the OC1A pin is pulled low and the timer continues counting till TOP, resets to zero and repeats the whole cycle again. This is the normal non-inverted mode of operation. In inverted mode, OC1A is pulled low when counter resets and pulled high when compare match occurs.

Fast PWM mode

Phase Correct PWM

In this mode, when the timer count reaches TOP, it doesn’t reset to 0. Instead, it starts counting down towards zero. While counting up, when the count equals the compare value, the OC1A pin is pulled high and while downcounting, when the count again becomes equal to compare value, the OC1A pin is pulled low. The process repeats again when the count becomes zero.

Phase Correct PWM mode

Phase and frequency correct PWM

This is essentially the same as Phase Correct PWM but has the added feature that we can change the frequency of the square waves at any instant as opposed to the above modes where frequency is constant defined by the relation given in the section below.

Starting PWM generation

First, we need to configure the clock source for the timer. As discussed in the earlier post, a suitable prescaler may be chosen by setting the CS10,CS11,CS12 bits in the TCCR1B register.
The value of prescaler is a factor in the frequency of waves generated. The frequency of generated square wave (independent of the duty cycle) is given by

PWM formula

N is the value of prescaler and TOP is value to which the counter counts and then resets to zero.
In this discussion, we use the timer in mode 5 (refer datasheet), i.e. 8 bit Fast PWM with TOP = 255. This is a fairly simple mode and can be used to control the speed of motors on the go.
This mode can be selected by setting WGM10 bit in TCCR1A register and WGM12 bit in TCCR1B register. 9 bit and 10 bit PWM with TOP=511 and TOP=1023 can be selected by setting suitable WGM (Waveform Generation Mode) bits. Refer datasheet for the values.
Next we need to choose between normal or non-inverted PWM and inverted PWM (described above) . Inverted PWM is nothing but here duty cycle determines the off time of the waveform. Here we choose normal PWM by setting COM1A1 bit in TCCR1A register.

The duty cycle is given by setting a value between 0 and 255 in the OCR1A register (similarly, 0 to 1023 for 10 bit PWM and 0 to 511 for 9 bit PWM). Value of 255 corresponds to a duty cycle of 100 % and value of 0 in OCR1A corresponds to 0 % duty cycle.
ie OCR1A= 255 x duty cycle.
For example, for duty cycles 20 %, 37 %, 70 %, set OCR1A = 51, 94,  178 respectively
In our example given at the bottom, the frequency of waveform generated  = 46.875 KHz

An example

A simple straightforward way to demonstrate PWM is to hook up an LED to the OC1A pin. In PWM generation, since the average voltage is proportional to the duty cycle (DAC in effect), the brightness of the LED is proportional to the duty cycle with the LED being maximum bright at 100% duty cycle (OCR1A=255).
The following program increases the brightness of the LED connected to OC1A pin gradually from zero to maximum and then from maximum to zero and so on. Observe the power LED of your laptop while sleeping (laptop, not you ). We are reproducing the same.

PWM demo code

A timer (also called as counter) is simply a device that counts upon receiving clock pulses. The timer increments (or decrements in certain cases)its count with each clock tick it receives.  A timer is usually specified by the maximum value to which it can count (called MAX) beyond which it overflows and resets to zero(BOTTOM). Thus an 8-bit timer/counter can count from 0 through 255 and a 16-bit timer/counter can count from 0 through 65,535.
The speed of counting can be controlled by varying the speed of clock input to it. This is done by prescaling the clock of the microcontroller. By prescaling, we feed a fraction of the CPU clock to the timer.

Timer speed =F_CPU / prescaler

where F_CPU is the AVR CPU clock speed.Normal prescaler values are 1,8,64,256 and 1024. For example, for a 1MHZ clock, if prescaler is 64, then timer speed is  1000000/64=15625 i.e.  in one second,  the timer can count from 0 to 15625.
When the timer reaches the maximum value it can count, it is said to overflow and it automatically resets to 0 and starts counting again. We can set an interrupt to occur when the timer overflows.
When the timer 1 overflows, TOV1 bit will be set in the TIFR (Timer Interrupt Flag Register) register which will be cleared automatically when the corresponding ISR executes or it can be cleared by setting TOV1 bit to 1(odd, but that’s how ATMEL guys want us to clear it !).

Starting the timer

A counter starts counting as soon as it is set to use a clock source, by setting a suitable prescaler value bits CS10,CS11 and CS12 in the TCCR1B (Timer Counter Control Register 1 B )register . The instantaneous value of the timer is available anytime in the TCNT (Timer Count) register. Refer datasheet for more information on various bits in the register.

Timer in Compare Mode (CTC mode)

The timer used in above mode is of not much use as such. The AVR timer can be operated in a mode called CTC mode or Clear on Timer Capture mode in which we can set the timer to compare its count with a certain value set in OCR1A (Output Compare Register 1 A) register or OCR1B register and generate an interrupt or manipulate the OC1A or OC1B pin whenever a match occurs (i.e. when TCNT=OCR1A or TCNT=OCR1B).CTC mode can be used to generate accurate timings and square waves of desired frequency.
CTC mode can be enabled by setting WGM 12 bit=1 in TCCR1B register.
When TCNT=OCR1A, the timer resets and starts from 0 again. The value of OCR1A can be changed anytime and the change in the output will be reflected immediately.

toggling OC1A pin in CTC mode

When a match occurs we can either Set,Clear or toggle the OC1A/OC1B  pin.The action of OC1A pin can be set by setting suitable values for COM1A0 and COM1A1 bits in TCCR1A (Timer Counter Control Register 1 A) register (refer datasheet).

Whenever a compare match occurs, the OCF1A bit will be set in the TIFR(Timer Interrupt Flag Register) which will automatically be cleared when the associated ISR fires or else we have to manually clear it by setting it to 1.

The following example demonstrates CTC mode of Timer 1. An LED is connected to t0 PB1 pin(pin 15) of Atmega8 which flashes at 1 hz.

Atmega8 Timer 1 in CTC toggle mode

Generating Square Waves

With the OC1A pin set to toggle by setting COM1A0=1 in TCCR1A register, this mode can be used to generate a square wave of required frequency(50% duty cycle only though) by setting a suitable value in the OCR1A register.
As said above, the value of OCR1A can be changed anytime and the change in the output will be reflected immediately

The frequency of the square wave generated is given by

f = F_CPU / (2.prescaler.(1+OCR1A))

Generating Square waves in CTC mode

For eg, to generate a 50Hz square wave, set OCR1A=291

Timers and interrupts

AVR timers can generate 3 types of interrupts- Overflow, Compare match and Input Capture (Input capture is a mode in which we can have the value of the  TCNT register copied to the ICR register whenever  a rising/falling edge is found on the ICP1 pin of the ATMEGA) and we can execute a user specified ISR for these as demonstrated.
To enable interrupts, first we have to enable compare match interrupt for  timer 1 by setting OCIE1A (Output Compare A Match Interrupt Enable) bit in the TIMSK register and then we have to enable global interrupts with the sei() macro. For handling overflow interrupts, set TOIE1 bit in TIMSK register to 1.

The following example demonstrates the use of interrupts. The interrupt service routine(ISR) toggles the LED connected to pin 1 of port B.

Timer 1 Interrupt Handling

The regular expresion for this would be “<td>MICROPROCESOR BASED DESIGN</td>[a-zA-Z0-9=<>\s\n\t/]*<\td>“. Or better still,you could also try “BASED DESIGN</td>[a-zA-Z0-9=<>\s\n\t/]*<\td>“
The expression cannot start with “DESIGN” cuz it would match COMPUTER ORGANIZATION AND DESIGN,another subject !
Symbols <>,\n,\t,/ need to be be included because the section to be extracted contains html tags.

Heres the complete code. As obvious,regular expressions make things a lot easier as opposed to the usual approach.

Regular expression put to use

Anyway this post is about creating a anti-worm tool in VB – a behaviour based detection tool that  searches for and removes such malware .

First, you gotta give it a sample of the malware to search for. The directory structure of each drive is traversed and each directory is searched for the presence of an exe with the name same as the directory name, if such an exe is found, its size is compared with the size of the exe given as sample. If there is match,it is reported(MD5 signature based comparison would have been an anytime better alternative but i dunno if theres is an md5 implementation for vb yet). This second level of checking is needed cuz an exe with name same as the directory name need not always be a malware.

Download Source

Download Tool

Heres the tool in action

Ant-worm tool in action

Given below is the souce, download source

Anti-worm source in VB6

Create a list(or a tuple) containing 3-element tuples as the list members,the first member of the tuple being the string to be printed,the second being the function to be invoked and the third member being a list containing the arguments to be passed to the function.
Print the 0th element of the tuples present in the list in order,read a choice from the user and invoke the function as shown in the code.

Since python supports functional paradigm,functions are treated as first class members and hence they can inserted into lists,tuples etc
For dealing with function arguments,it would be good to have the function accept a list as its argument from which it can extract the needed arguments (which,well maynot be a good idea in cases we dont know the arguments to be passed to the function beforehand)
In case the functions that do accept any arguments,make the function accept a dummy lust as argument.

Heres an example based on the good ol’  Binary Search Tree

An alternative to If-Else and Switch

The code is straight forward.No rocket science. Just traverse the directories recursively and copy the exe to each directory renaming it to the name of the directory .

Download Source

I have assumed below that ‘malw.exe‘ is the malware you want to spread and its present in the same directory where the code will be running.

Malware Replication code :VB 6

The class exports  methods like connect(), selectdb(),query(),get_entry(),count_result() which are nothing but  a higher level abstractions over functions like mysql_connect(),mysql_query() while the other parameters like link identifier ,result resource etc remains hidden from the user.
The result of the query(SELECT query) becomes available in the array row with field name as the key.I think the rest is all self explanatory.
The script file containing the class can be included in the required page using include() PHP function.

Download Source

An abstraction for PHP MySQL transactions