COM files are plain binary executable file format from the MS-DOS era (and before!) that provide a very simple execution model.
The execution environment is given one 64kb segment to fit its code, stack and data segments into. This memory model is sometimes referred to as the “tiny” model.
In today’s post, we’re going to write a really simple program; compile it, disassemble it and dissect it. Here’s our program that very helpfully prints “Hello, world!” to the console and then exits.
ORG 100h
section .text
start:
mov dx, msg
mov ah, 09h
int 21h
ret
section .data
msg DB 'Hello, world!', 13, 10, '$'
Nothing of great interest here. The only thing worth a mention is the ORG directive. This tells the assembler (and therefore the execution environment once executed) that our program starts at the offset 100h. There’s some more information regarding 16bit programs with nasm here.
nasm’s default output format is plain binary so, assembly is very simple:
$ nasm hello.asm -o hello.com
Running our program in dosbox and we’re given our prompt as promised. Taking a look at the binary on disk, it’s seriously small. 24 bytes small. We won’t have much to read when we dissassemble it!
Because this is a plain binary file, we need to give objdump a little help in how to present the information.
hello.com: file format binary
Disassembly of section .data:
00000000 <.data>:
0: ba 08 01 mov $0x108,%dx
3: b4 09 mov $0x9,%ah
5: cd 21 int $0x21
7: c3 ret
8: 48 dec %ax
9: 65 gs
a: 6c insb (%dx),%es:(%di)
b: 6c insb (%dx),%es:(%di)
c: 6f outsw %ds:(%si),(%dx)
d: 2c 20 sub $0x20,%al
f: 77 6f ja 0x80
11: 72 6c jb 0x7f
13: 64 21 0d and %cx,%fs:(%di)
16: 0a 24 or (%si),%ah
Instructions located from 0 through to 7 correspond directly to the assembly source code that we’ve written. After this point, the file is storing our string that we’re going to print which is why the assembly code looks a little chaotic.
Removing the jibberish assembly language, the bytes directly correspond to our string:
So, our string starts at address 8 but the first line of our assembly code; the line that’s loading dx with the address of our string msg has disassembled to this:
0: ba 08 01 mov $0x108,%dx
The address of $0x108 is going to overshoot the address of our string by 0x100! This is where the ORG directive comes in. Because we have specified this, all of our addresses are adjusted to suit. When DOS loads our COM file, it’ll be in at 0x100 and our addresses will line up perfectly.
sysstat is a collection of utilities for Linux that provide performance and activity usage monitoring. In today’s post, I’ll go through a brief explanation of these utilities.
iostat
iostat(1) reports CPU statistics and input/output statistics for devices, partitions and network filesystems.
mpstat goes a little deeper into how the cpu time is divided up among its responsibilities. By specifying -P ALL on the command line to it, you can get a report per cpu:
pidstat will give you the utilisation breakdown by process that’s running on your system.
sar
sar(1) collects, reports and saves system activity information (CPU, memory, disks, interrupts, network interfaces, TTY, kernel tables,etc.)
sar requires that data collection is on to be used. The settings defined in /etc/default/sysstat will control this collection process. As sar is the collection mechanism, other applications use this data:
sadc(8) is the system activity data collector, used as a backend for sar.
sa1(8) collects and stores binary data in the system activity daily data file. It is a front end to sadc designed to be run from cron.
sa2(8) writes a summarized daily activity report. It is a front end to sar designed to be run from cron.
sadf(1) displays data collected by sar in multiple formats (CSV, XML, etc.) This is useful to load performance data into a database, or import them in a spreadsheet to make graphs.
Docker is a platform that allows you to bundle up your applications and their dependencies into a distributable container easing the overhead in environment setup and deployment.
The Dockerfile reference in the docker documentation set goes through the important pieces of building an image.
In today’s post, I’m just going to run through some of the commands that I’ve found most useful.
Building a container
# build an image and assign it a tagsudo docker build -t username/imagename:tag .
Controlling containers
# run a single commandsudo docker run ubuntu /bin/echo 'Hello world'# run a container in a daemonized statesudo docker run -d ubuntu /bin/sh -c"while true; do echo hello world; sleep 1; done"# run a container interactivelysudo docker run -t-i ubuntu /bin/bash
# connect to a running containersudo docker attach container_id
# stop a running containersudo docker stop container_name
# remove a containersudo docker rm container_name
# remove an imagesudo docker rmi image_name
When running a container, -p will allow you to control port mappings and -v will allow you to control volume locations.
Getting information from docker
# list imagessudo docker images
# list running containerssudo docker ps
# list all containerssudo docker ps -a# inspecting the settings of a containersudo docker inspect container_name
# check existing port mappingssudo docker port container_name
# retrieve stdout from a running containersudo docker logs container_name
sudo docker logs -f container_name
A really handy feature that has been included in the Scala programming language is xml literals. The xml literals feature allows you to declare blocks of xml directly into your Scala code. As you’ll see below, you’re not limited to static xml blocks and you’re also given the full higher-order function architecture to navigate and process your xml data.
Definition and creation
You can create an xml literal very simply inside of your Scala code:
We test if the gender attribute contains an “M”, and if so we empty out the node. To apply this transform to the source data, we use the RuleTransformer class.
Pretty much the same. The only extra complexity is ensuring that we have an age attribute and getting it casted to an integer for us to perform arithmetic testing.
The RuleTransformer class accommodates if we want to use these two transforms in conjunction with each other.
Python provides a simple way to define anonymous functions through the use of the lambda keyword. Today’s post will be a brief introduction to using lambdas in python along with some of the supported higher-order functions.
Declaration
For today’s useless example, I’m going to create a “greeter” function. This function will take in a name and give you back a greeting. This would be defined using a python function like so:
defgreet(name):return"Hello, %s."%(name,)
Invoking this function gives you endless greetings:
We can transform this function into a lambda with a simple re-structure:
greeter=lambdaname:"Hello %s"%(name,)
Just to show you a more complex definition (i.e. one that uses more than one parameter), I’ve prepared a lambda that will execute the quadratic formula.
Now that we’re able to define some anonymous functions, they really come into their own when used in conjunction with higher-order functions. The primary functions here are filter, map and reduce.
We can filter a list of numbers to only include the even numbers.
filter(lambdax:x%2==0,range(1,10))
Of course it’s the lambda x: x%2 == 0 performing the even-number test for us.
We can reduce a list of numbers to produce the accumulation of all of those values:
reduce(lambdax,y:x+y,range(1,10))
Finally, we can transform a list or map a function over a list of numbers and turn them into their inverses: