There are some quaint hoops to jump through to make USB drives work with OS/2. Here we go through the steps required to make a flash drive work.
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
bar to use the same counter. All it means, is that when
foo requests a new value, the counter may have been incremented by
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.
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.
Building with no Assembler
First, we copy
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
crypto.lib plus a few applications. Some of them work.
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
on line 85 where it’s including
sys/file.h and now this application builds also.
Now that we have
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
tmp/ directories and build all over again with
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.
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 firstname.lastname@example.org.
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
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
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.
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.
ALL WARRANTIES ARE HEREBY DISCLAIMED.
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 settings at the start should look like this.
CC = wcl386 CFLAGS = EXENAME = jam0.exe TARGET = -fe=$(EXENAME)
That is, the compiler is
wcl386, with no special C flags, and the name is
jam0.exe without the period and slash. The
wcl386 what to name the executable file; possible mnemonic: file executable.
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 # define INCL_DOSFILEMGR # 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
# define INCL_DOSPROCESS # define INCL_DOSFILEMGR # 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> # define INCL_DOSPROCESS # define INCL_DOSFILEMGR # include <os2.h> # define unlink DosDelete # endif
After this change, on line 188, is a
# ifdef USE_EXECNT
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.
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.
-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
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
copy bin.os2x86\jam.exe %UNIXROOT%\usr\local\bin
Congratulations, now you have completed the build and installation of Perforce Jam 2.6.
Do you need professional assistance with OS/2? Write to email@example.com.