It’s possible to use the Watcom compiler to mix your code with modules compiled (or in this article’s case, assembled) with other tools. In today’s post, I’ll take you through the simple process of creating a module using Borland’s Turbo Assembler and linking it with a simple C program.
Creating a test
First thing to do, is to create an assembly module that we can integrate with. For this module, we’re going to take two numbers; add them together and send out the result.
; adder.asm
;
; Assembly module to add two numbers
.386p
.MODEL FLAT
_TEXT SEGMENT DWORD PUBLIC 'CODE'
ASSUME CS:_TEXT
PUBLIC add_numbers
add_numbers PROC NEAR
push ebp
mov ebp, esp
ARG A:DWORD, B:DWORD
mov eax, [A]
mov ecx, [B]
add eax, ecx
mov esp, ebp
pop ebp
ret
add_numbers ENDP
_TEXT ENDS
END
This is a basic module, with most of the stack-balancing work being handled for us by the ARG directive. From the documentation:
ARG is used inside a PROC/ENDP pair to help you link to high level languages. Using ARG, you can access arguments pushed onto the stack.
Also from the documentation:
In the code that follows, you can now refer to PAR1 or PAR2, and the correct [BP + n] expression will be substituted automatically by the assembler.
Of course, we could have just as easily used the following without needing the ARG directive:
mov eax, [ebp + 12]
mov ecx, [ebp + 8]
In accordance with the 32bit ABI, we put the result in EAX at the end of execution. Producing an object file from this assembly source is relatively easy:
C:\SRC> tasm /mx /zi /os adder.asm adder.obj
Integrating with the module
Now that we’ve got an object file with our function in it, we’ll create a very small, simple C program that will use this function. In order to do so though, we need to declare the function as an extern; as it is implemented externally to our C code:
Because we’re using C, there’s no need to really decorate the function prototype of add_numbers. Had we been compiling a C++ module, this declaration would need to change slightly to attribute the calling convention:
extern"C"{intadd_numbers(inta,intb);}
This module is now ready to be compiled itself and linked to the assembly implementation. We can achieve this with wcc386 and wlink to tie it all together for us.
C:\SRC> wcc386 /d2 /3s test.c
C:\SRC> wlink system dos4g file test,adder name test
From there, we have a linked and read to run executable test.exe.
Docker provides a very convenient way of packaging your applications and their dependencies so that they can be moved around without too much effort. Another great side-effect of this type of system design is the isolation that you’re given between containers. In today’s post, I’ll walk through the setup of Google Chrome running in an isolated sandbox within Docker and so that it’s nicely integrated into Ubuntu.
Not starting from zero
I have to admit, most of the hard work had already been done for me in Jessie Frazelle’s post about hosting desktop applications in docker containers. The Chrome Dockerfile that I have hosted in my github repository is a pretty good rip, directly from Jessie’s post.
Getting started
Putting together a run script that you can repeatedly call from the operating system shouldn’t be too hard. It only needed to do three things:
Create a container when one didn’t exist
Start the container if it already existed
Open a new window if the container was already started
This is a relatively simple bash script to do this:
We want to check if the container is running, first up. I’ve standardised by calling the container chrome. Really creative. Upon successful return from the docker inspect command, the $CHROME_RUNNING variable should either be true or false. If the inspect call didn’t go to plan, it’s most likely because the container doesn’t exist and we need to use run to kick it into gear:
This gets the container up and running and the browser under our noses.
In cases where the container already exists, but isn’t running we’ll use run. When the container exists and it is running, the only reason why someone could be invoking this script is to get another browser window running; so we’ll use exec to get chrome to open up a new window for us:
By using the $@ variable in the exec script, we can take in any web address that’s passed into this script. This is what will allow us to integrate this container into our operating system.
Integration
We’ve done just about everything now with the run script. I’ve created myself a menu item with a chrome icon that just points to this run script:
The main key binding of Super + W, but the most important is changing the preferred browser so that it invokes the script. %s passes the desired web site through for a seamless finish.
Setting up passphrase-less login to your SSH servers is a convenient way of logging into your servers without being annoyed for a passphrase. In today’s post, I’ll take you through generating a key, distributing your identity and logging on.
Generating your key
If you haven’t done so already, you’ll need to generate some authentication keys for yourself. You can do this with ssh-keygen.
ssh-keygen -t rsa
The output of which will look like this:
root@64ed9b1beed9:~# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
b6:ff:5f:1b:88:12:7e:3d:5f:28:c9:66:fb:a7:21:6a root@64ed9b1beed9
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
| |
| S. |
| .....o... |
| .o oB+o.o|
| .E+ +oo=|
| .o.oo+= |
+-----------------+
Now that this process has completed, you’re given a public key and private secret key in your .ssh/ folder.
Distribute your identity
To deploy your public key to other servers so that you can authenticate using your private key, you can use ssh-copy-id.
$ ssh-copy-id remote-user@remote-host
You’ll want to swap out remote-user for the user that you’re associating your key to and remote-host with the machine that you want to connect to.
Another way that you can establish your key into the remote machine’s authorized set is as follows:
You’ll then be taken through the verification process, which is just supplying your remote password:
The authenticity of host '123.123.123.123 (123.123.123.123)' can't be established.
ECDSA key fingerprint is ae:2d:33:79:e9:d8:03:16:6c:17:d3:f2:7e:c4:05:60.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
example@123.123.123.123's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'example@123.123.123.123'"
and check to make sure that only the key(s) you wanted were added.
Conclusion
You’re free to login. Of course, if you don’t set a pass phrase for your keys you won’t be hassled all the time to unlock them. If you do set a pass phrase, your overall solution will be just a bit more secure.
In a previous post, I’d started talking about the Open Watcom compiler and its usage in the DOS environment. In today’s post, I’m going to walk through writing assembly code inside of your C/C++ that you’ll compile with the Watcom compiler.
Using the DOS api
When it comes to basic interrupt invocation or I/O port work, there’s no reason why the API provided by the dos.h header won’t suffice. It’s allows you to write C code, but directly invoke I/O ports and interrupts. Once you want to perform some custom logic, you’ll be reaching for planting assembly code directly into your code.
Here’s an example using the dos.h api. In this example, we’re going to request a key press from the user using keyboard service’s int 16h and print out the captured scan and ascii codes:
#include<stdio.h>
#include<dos.h>intmain(intargc,char*argv[]){unionREGSr;/* ah = 00h, int 16h "read key stroke" */r.x.eax=0x0000;int386(0x16,&r,&r);/* write the results to stdout */printf("scan code = %d\n",r.h.ah);printf("ascii = %d\n",r.h.al);return0;}
The call to int386 takes a register set as inputs and outputs, so that we can see the CPU state after the interrupt was executed.
Inlined
So, what does that look like inlined?
#include<stdio.h>intread_key_stroke();#pragma aux read_key_stroke = \
"int 0x16" \
value [eax];
intmain(intargc,char*argv[]){intkey=read_key_stroke();/* extract the ascii & scan code */intascii=key&0xff,scan=key>>8&0xff;/* write the results to stdout */printf("scan code = %d\n",scan);printf("ascii = %d\n",ascii);return0;}
Without needing to manage the registers anymore, we’ve cleaned up a little bit of the code. There is a little bit of alien syntax to deal with though.
#pragma aux
The basic structure of an inline assembly function using the #pragma aux syntax goes like this:
#pragma aux name_of_your_function =
. . . assembly code in here . . .
modify [ regs ]
value [ reg ]
parm [ regs ]
You start your function off optionally with a header definition. It’s been omitted in this example, but I’ve added one above for read_key_stroke.
The assembly code itself gets quoted and then terminates with three optional instructions.
modify allows you to tell the compiler which registers are going to get clobbered when the function runs. This is so it can do the appropriate save management of these registers to the stack.
modify [ eax ebx ecx ]
This line says that eax, ebx and ecx all get clobbered when this function runs.
value allows you to nominate which register has the return value in it.
value [ eax ]
This line says that the return value is in eax. As with read_key_stroke above, the value of eax is then fed into the int return value for the function.
parm allows you to nominate registers that will take the values of parameters passed in.
parm [ eax ] [ ebx ] [ ecx ]
If we were to implement a function that performs addition, we’d need two arguments to be passed in:
int add_ints(int a, int b);
#pragma aux add_ints = \
"add eax, ebx" \
parm [ eax ] [ ebx ] \
value [ eax ];
Passing parameters is fairly straight forward. You’re free to use EAX, EBX, ECX, EDX, EDI and ESI but you are not able to use EBP.
Being able to bundle blocks of your code (and data to some extent) into library files is quite a productive step forward when developing applications. Being able to port these pieces around means a higher level of code-reuse, and a less number of times you’ll spend re-writing the same stuff.
In today’s post, I’ll take you through creating a very minimal library. We’ll create a library module from this code and I’ll also show you how to consume it.
Howdy!
Our example library will expose one function, called greet. greet will take in a person’s name and will print a greeting to the console. Here’s the header:
Making a library is all about compiling your code to produce object files and then bundling your object files into a library file. So, the first step is to compile greeting.c into an object file:
C:\SRC> wcc386 greeter.c
After this, you’ll now have GREETER.OBJ in your project folder. You can turn this into a library with the following:
C:\SRC> wlib greeter +greeter
The command itself says invoke wlib to create (or modify) a library called greeter (the .lib extension is handled for us). Finally the +greeter says that we want to add greeter.obj into the library. We’ll now have a .LIB file that we can link against.
Consuming the library
Writing code that actually uses the library is as easy as including the header and calling functions. Here’s a test: