Hello World with SDL2

Ok, you’ve gone through the texture tutorial for Grafx2 and are eager to try out your skills with SDL2 programming. Look no further, we’re going to build a very basic “hello, world” application that should get you started writing great games.

Hello World

This tutorial is in plain C and not C++. This is in direct contradiction with most examples out there, and is helpful to showcase SDL usage, rather that game design of any particular author.

This tutorial is not meant to replace what is available on the Lazy Foo’ Productions web site, rather to complement it.

The code is explicitly WTFPL for maximum freedom. See the WTFPL website for further details.

Continue reading Hello World with SDL2

Running Pgbadger Automatically with Zsh

Here I present a simple script that queries the database for the log file locations and automatically chooses the one for yesterday. The trick here is to apply strftime to the log filename as configured in the database. This way, it doesn’t matter how complex the log file name is in the database, it’s alawys easy to guess. All this works as long as the system’s strftime and PostgreSQL’s log file escapes are equivalent; this should never be an issue.

There are some limits to the current script. It assumes log_directory is to be found within data_directory and is not an absolute path. It also assumes there are no strftime escape sequences in the directory names themselves. Fixing either or both of these is not hard if a more general script is needed. It is also hardcoded to choose the csv log file, but this is easy to change.

Finally it runs pgbadger on the log file from yesterday, and outputs html in the webserver’s directory. The assumption here is that PostgreSQL will write its log into a new file every day, possibly in a rotating sequence.

The script is mean to be called every day with cron.

#!/usr/local/bin/zsh

zmodload zsh/datetime

datadir=`/usr/local/bin/psql -A -t -q -w -c "show data_directory" ;`
logdir=`/usr/local/bin/psql -A -t -q -w -c "show log_directory" ;`
filename=`/usr/local/bin/psql -A -t -q -w -c "show log_filename" ;`

strftime -s log $datadir/$logdir/$filename $(( $epochtime[ 1 ] - 24 * 60 * 60 ))

/usr/local/bin/pgbadger -q -I -O /var/www/html/pgbadger/ -o index.html  ${log:r}.csv

Mitigating Linux TCP Vulnerabilities with UFW

On June 17, 2019, Netflix released a security bulletin about vulnerabilities in the Linux and FreeBSD kernels. Here we will only discuss the vulnerabilities affecting the Linux kernel and how to apply the mitigations with ufw.

The vulnerabilities discussed are: CVE-2019-11477, CVE-2019-11478 and CVE-2019-11479.

Netflix mentions patches and a choice of mitigations. Here we discuss only type of mitigation.

In the Netflix bulletin, we have mentions of sysctl and iptables. And fortunately, ufw does take care if this for us, albeit in a non-obvious way. The ufw config files are kept in /etc/ufw and that’s where we find before.rules and sysctl.conf.

So we edit sysctl.conf first, and make sure tcp_sack is set to zero.

## Setting this to zero to mitigate CVE-2019-11477, CVE-2019-11478.
net/ipv4/tcp_sack=0

Additionally, we can explicitly set the tcp_mtu_probing to zero, but that’s probably not necessary.

## Setting this to zero to mitigate CVE-2019-11479.
net/ipv4/tcp_mtu_probing=0

Then, we edit before.rules and add a firewall rule to drop small MSS packets, right after we accept everything on the loopback.

# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT

## Mitigate CVE-2019-11479.
-A ufw-before-input -p tcp -m tcpmss --mss 1:500 -j DROP

Finally, we reload the ufw to enable the new settings.

ufw reload

Disclaimer. I hope I got everything right, and these mitigations actually do work. In the event I misunderstood the Netflix recommendations and/or misapplied anything, I waive all responsibility. You are after all responsible for your own system.

OS/2 Sequence Driver

Introduction

Programmers often have a need for a unique identifier for various reasons. Sometimes people end up using databases for a simple reliable counter, when there’s no other need for a database.

This is overkill. There’s no need to depend on something like Postgres just because we need a simple counter. But implementing a reliable counter can be a daunting task. Particularly if there is more than one application using the same counter.

This is a service that could very well be implemented in the operating system. When uniqueness and perhaps order is all that’s required, it’s perfectly all right for application foo and bar to use the same counter. All it means, is that when foo requests a new value, the counter may have been incremented by bar.

We can call this a non-decreasing counter. For an individual application foo, the results could be 1, 2, and 5; when application bar has 3, 4 and 6.

Concept

Here we present a simple software driver that creates a device that can be opened and read like a regular file, but each read results in a new value from the counter. We shall call it dev$seq$ so that it will be unlikely to conflict with regular file names.

As a proof of concept this driver lacks certain features that are required in a real world application. First, it’s only 16 bits so it’ll wrap around at 65,535 and become zero. Second, there’s no way to save its value to the file system; it always starts at zero upon every reboot. Third, there’s no backup procedure that can be applied.

Continue reading OS/2 Sequence Driver

Building OpenSSL with OpenWatcom on ArcaOS: Second Porting Effort

I’ve written before about my OpenSSL port to OS/2. I’m doing this with OpenWatcom 1.9 on the ArcaOS flavour of OS/2.

Building with no Assembler

First, we copy OS2-OW.cmd to OS2-OW-NOASM.cmd and then make the new file run perl Configure OS2-OW no-asm and perl util\mk1mf.pl no-asm OS2-OW > OS2-OW.mak.

Then it’s just a matter of building the make file with OS2\OS2-OW-NOAM.cmd and building with wmake -u -c -f OS2-OW.mak.

This builds the libraries ssl.lib and crypto.lib plus a few applications. Some of them work.

apps/ca.c

This file fails to build with the error message .\apps\ca.c(86): Error! E1055: Unable to open 'sys/file.h' and we fix that by adding

&& !defined(OPENSSL_SYS_OS2)

on line 85 where it’s including sys/file.h and now this application builds also.

The Heisenbug

Now that we have crypto.lib and ssl.lib it’s time to try out OpenSSL with a simple example. Copying some code from the internet, and trying it out, we get a mysterious crash inside

SSL_CTX_new( method )

which causes the example program to terminate.

In order to debug this problem, we start by changing the optimization parameters and replace them with debugging symbols. In util/pl/OS2-OW.pl we make

$cflags="-DL_ENDIAN -d2 ";

in order for OpenSSL to be built with debugging symbols instead of optimizations.

Then we just delete everything in the out/ and tmp/ directories and build all over again with OS2-OW-NOASM.cmd and wmake -u -c -f OS2-OW.mak.

Lo and behold, there is no crash when we link with the new .lib files. This is definitely a Heisenbug.

Final Words

We now have a somewhat functioning OpenSSL port and can make simple applications such as hello, world work, albeit with a debug build, but more research is needed before the port can be considered finished. Particularly because there is a Heisenbug in the optimized version, which could be a code generation bug in OpenWatcom, or a symptom of something broken inside OpenSSL.

Do you need professional help with OS/2? Write to johann@myrkraverk.com.

CWEB: Hello, World!

To give literate programming a try, I wrote the quintessential hello, world program as an exercise. It includes how to build and run the resulting hello.c file with several compilers on different operating systems. The cweb source is not included though, so people cannot just tangle my source code. Writing out hello.c is left as an exercise for the reader.

Polymorphism in Plain C

Here we go through the steps required to implement polymorphic interfaces in plain C. We use function pointers for this task, hidden behind generic functions we define for the interface itself.

To demonstrate the technique, we implement a simple queue of string pointers. This entry is about the generic interface so some deficiencies and possibly bugs in the actual implementation may pass us by. Please write the author or comment on the post if you spot errors in the implementation.

First we define the interface we’re going to use. We start off by defining a struct with the function pointers we need.

struct queue {

  void *secret;

  void (* enqueue)( struct queue *, char * );
  char * (*dequeue)( struct queue * );
  bool (*empty)( struct queue * );
  struct queue * (* delete)( struct queue * );
};

The void *secret is what we use in the implementation to keep track of our secret data structure. The rest are the function pointers we need to define for each implementation.

Here we use direct function pointers for all of the functions. We could also put the pointers into a separate struct for easier sharing, or at least smaller concrete objects, but we leave that optimization as an exercise for the dedicated reader.
Continue reading Polymorphism in Plain C