Monthly Archives: April 2018

Building OpenSSL with OpenWatcom on ArcaOS: First Porting Effort

I have previously written about my OpenSSL port to OS/2. Here I go over the first C code changes that make it compile with OpenWatcom 1.9.

As previously mentioned, I’m doing this on ArcaOS; so some Unix-ism will be present in the build system. This is apparently unavoidable, and fortunately, ArcaOS already comes with a lot of Unix ports; both out of the box and installed through yum (or the Arca Noae Package Manager).

The following changes leave us with a port that builds for the most part. Some parts will need more changes before they are strictly “correct” and we’ll return to those later.
Continue reading Building OpenSSL with OpenWatcom on ArcaOS: First Porting Effort

Building OpenSSL with OpenWatcom on ArcaOS: The Initial Hurdles

Building OpenSSL on a new system or compiler presents a lot of hurdles. The build system is a perl hack upon a perl hack; and no documentation about how it works, from what I can tell.

I am porting OpenSSL 1.0.2, which is what the software I want to work on expects. Hopefully my work can be applied to other versions as well.

Here I go through the initial steps to get a working build system on ArcaOS 5, also known as OS/2, using the OpenWatcom compiler; even though OpenSSL has already been ported to the EMX runtime, with GCC.

Because we’re using perl, the steps here are taken after installing perl with

yum install perl

and this gives us a working build system with the changes below, so the real work on porting OpenSSL can start.
Continue reading Building OpenSSL with OpenWatcom on ArcaOS: The Initial Hurdles

Using the OpenWatcom Assembler with Jam

I’ve previously covered the OS/2 port of Perforce Jam.

Here we’ll go over what it takes to make Jam know about the OpenWatcom assembler, Wasm.

First we can look at the Jambase file, in the source where we find the

actions As
$(AS) $(ASFLAGS) $(ASHDRS) -o $(<) $(>)

and we see that Jam has a few variables related to assembler files.

The Jamfile

First, we tell Jam that our assembler is Wasm.

AS = wasm ;

Then we redefine the As actions to be

actions As
$(AS) -q $(ASFLAGS) $(ASHDRS) -fo=$(<) $(>)

where -fo=$(<) is the output file, and $(>) the input file. We could also have used the newer syntax, $(1) and $(2). The -q tells Wasm to operate quetly; it means we won’t see the copyright information every time we run Jam; only the nice As file.asm output.

Now, we can make use of these changes with

Main hello.exe : hello.c sum.asm ;

The Sources

The source files we mentioned above are hello.c and sum.asm.

Here is hello.c

  #include <stdio.h>

  int sum( int a, int b );

  int main( int argc, char *argv[] ) {

    printf( "Hello, %d.\n", sum( 3, 5 ) );
    return 0;

And here is sum.asm

  .model flat
  PUBLIC sum_
  sum_ PROC
      add eax, edx
  sum_ ENDP

These two files demonstrate how we can declare a function in C, and then define it in an assembly file. We are using the register calling convention of OpenWatcom. The first argument is in eax, the second in edx and the return value is again in eax. That means we don’t have to worry about stack manipulation at all, in a simple function like sum(). OpenWatcom appends _ to function names with the register convention, so we have to append it also in the .asm file.

With the above Jamfile, we just run


and our demonstration program is built and linked properly for us.

Running the Demo

Now, when we run


on the command line, we see

Hello, 8.

Final Words

This has been written as Jamfile demonstration, but it can also be viewed as a demonstration of the register calling in OpenWatcom.

Do you need professional help with OS/2? Write to

Building Jam 2.6 on OS/2 with OpenWatcom

These instructions pertain to ArcaOS 5.0.1 and OpenWatcom 1.9. Any other OS/2 versions and compilers may behave slightly differently; your mileage may wary.

Here we will go through the process of porting Perforce Jam 2.6, released in 2014. At the time of writing, the source can be downloaded from the Perforce website.

There is also FT Jam, from the FreeType project, which is quite possibly more advanced, even though it’s based on Perforce Jam 2.5. and hasn’t been updated since about 2006, apparently.

Haiku Jam is also worth checking out.

JamPlus may also be a thing.

Copyright and disclaimers

Jam has the following copyright:

Copyright 1993-2002 Christopher Seiwald and Perforce Software, Inc.

License is hereby granted to use this software and distribute it freely, as long as this copyright notice is retained and modifications are clearly marked.


Furthermore, no work has been done to insure the OS/2 port is fit for any particular purpose, except to ensure it successfully builds itself.

The Makefile

The settings at the start should look like this.

  CC = wcl386
  EXENAME = jam0.exe

That is, the compiler is wcl386, with no special C flags, and the name is jam0.exe without the period and slash. The -fe= tells wcl386 what to name the executable file; possible mnemonic: file executable.

Optionally add wtouch all as the final command in the “all” rule, or build with -c; otherwise WMake will complain the “all” target has not been built.

That takes care of the Makefile.

The make1.c file

There are minor changes in the make1.c file, because it unconditionally calls unlink() and we “fix that” with these macros at the start.

  # ifdef OS_OS2                                         
  # include <os2.h>
  # define unlink DosDelete
  # endif

You will need to remove the READ ONLY flag from the file before it
can be saved.

attrib -r make1.c

The execunix.c file

In this file, there are some major changes; so to speak.

At the top we add

  # include <os2.h>
  # define unlink DosDelete

inside the OS/2 section, because it also calls unlink() unconditionally. And we also need to get access to process information, to get the PID.

The complete section shoudl look like this:

  # ifdef OS_OS2
  # define USE_EXECNT
  # include <process.h>
  # include <os2.h>
  # define unlink DosDelete
  # endif

After this change, on line 188, is a

  # ifdef USE_EXECNT

inside which is an NT call GetCurrentProcessId() which we port to use DosGetInfoBlocks() instead.

So at the start of the scope, we declare two new pointers, to the thread and process structure respectively.

            TIB *thread;
            PIB *process;

And before sprintf() that refers to the PID, we call

  DosGetInfoBlocks( &thread, &process );

while inside the sprint() call itself, where GetCurrentProcessId() used to
be, we have


instead. The complete function call now looks like

	    sprintf( cmdtab[ slot ].tempfile, "%s\\jam%lut%d.bat", 
				tempdir, process->pib_ulpid, slot );

where we have carefully updated the format specification to reflect unsigned long %lu, instead of integer %d. Even though integers and longs are the same size on 32bit OS/2, there’s no reason to be sloppy about format specifiers in the printf() family of functions.

You will also need to remove the read only bit before saving the file.

attrib -r execunix.c

The jamgram.c and parse.c files

These source files will have some warning about undeclared function names. This is ok, and is not worth fixing just to get Jam working on OS/2. Maybe later, and particularly if Perforce is willing to accept contributions, it may turn out to be a worthwhile effort to fix.

This takes care of the source files.

Building It

Now do

wmake -u -c

in a command prompt, and Jam will bootstrap itself. The Jam built object files and executable will be in a subdirectory called bin.os2x86 so don’t be surprised if you only see the jam0.exe file at first.

On modern hardware, the complete build takes only a few seconds.

The -u is for unix compatibility mode, and allows WMake to understand the backslash line continuation syntax; lines that end with \ are joined. Without this, there will be an error.

As mentioned previously, the -c is to stop WMake from complaining that “all” has not been built. Leave it out of you added wtouch all to the rule.


To install Jam, just copy the jam.exe file into c:\usr\local\bin, which you may have to create first, or wherever your %UNIXROOT% is.

mkdir c:\usr\local
mkdir c:\usr\local\bin
copy bin.os2x86\jam.exe c:\usr\local\bin\

It is normal that the mkdir commands fail when the directory exists already.

Alternatively, you can write the commands like this, in case your
UNIXROOT is not C:.

mkdir %UNIXROOT%\usr\local
mkdir %UNIXROOT%\usr\local\bin
copy bin.os2x86\jam.exe %UNIXROOT%\usr\local\bin

Final Words

Congratulations, now you have completed the build and installation of Perforce Jam 2.6.

Happy building.

Do you need professional assistance with OS/2? Write to

Setting up Perforce Helix Core Service on OS X High Sierra

Here is a guide about how to start Perforce Helix Core as a global daemon on OS X High Sierra, running under a separate user called perforce. By the nature of this guide, some of it applies directly to my own system; readers are expected to identify those instances and change appropriately.

First, we download the p4d and p4 executable files. Some people may prefer the visual client, but this guide is focused on the command line.

Then we install the binaries into /usr/local/sbin and /usr/local/bin, respectively.

Install the server binary.

  sudo mkdir -p /usr/local/sbin
  sudo cp p4d /usr/local/sbin
  sudo chown root:wheel /usr/local/sbin/p4d
  sudo chmod 555 /usr/local/sbin/p4d

And install the client binary.

  sudo mkdir -p /usrl/local/bin
  sudo cp p4 /usr/local/bin/
  sudo chown root:wheel /usr/local/bin/p4
  sudo chmod 555 /usr/local/bin/p4

We’ll create a group and user called perforce, and store the version control database in /usr/local/var/perforce with the log in /usr/local/var/log/p4d.log.

Here I’ve carefully chosen the unique id 268 for both the group and user because it’s free on my system. To see all group ids in use on a system, this one liner can be used,

  for f in `dscl . -list /Groups`; do dscl . -read /Groups/$f; \
      done | grep PrimaryGroupID | sort -k2 -n

and to see all the user ids, this one liner can be used.

  for f in `dscl . -list /Users`; do dscl . -read /Users/$f; \
      done | grep UniqueID | sort -k2 -n

We create the group with

  sudo dscl . -create /Groups/perforce
  sudo dscl . -create /Groups/perforce PrimaryGroupID 268
  sudo dscl . -create /Groups/perforce Password '*'

and then we create the user with

  sudo dscl . -create /Users/perforce      
  sudo dscl . -create /Users/perforce UniqueID 268
  sudo dscl . -create /Users/perforce UserShell /usr/bin/false
  sudo dscl . -create /Users/perforce RealName 'Perforce Server'
  sudo dscl . -create /Users/perforce NFSHomeDirectory /usr/local/var/perforce
  sudo dscl . -create /Users/perforce PrimaryGroupID 268
  sudo dscl . -create /Users/perforce Password '*'

Then we create the log file and database directory

  sudo mkdir -p /usr/local/var/log
  sudo touch    /usr/local/var/log/p4d.log
  sudo mkdir -p /usr/local/var/perforce

and set the ownership to the new user and group.

  sudo chown perforce:perforce /usr/local/var/perforce
  sudo chown perforce:perforce /usr/local/var/log/p4d.log 

Then we create the launch daemon description file.

  sudo nano /Library/LaunchDaemons/com.perforce.plist

and add the following.

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "">
  <plist version="1.0">
        <string>Myrkraverk's Perforce</string> 
      <string>Launches Perforce Server</string>

And finally, start the Helix Core service with

  sudo launchctl load /Library/LaunchDaemons/com.perforce.plist

we then issue

   p4 set P4PORT=localhost:1666

and we test it with

  p4 help

which outputs at the end

  Server 2018.1/1637071.

so we know it's all working.

The steps to properly set up Helix Core with p4 protect and so forth are left out of this guide; please see the administration guide from Perforce.

To use SSL for the connection, the P4PORT should start with ssl:.