Most MS-DOS-likes aren't perfect replicas of MS-DOS, and you can usually use those quirks or extra functions to figure out what you're running on.^[1] And one would imagine DOSBox is the same! "Quirks" are more likely bugs waiting to be resolved, but commands like MOUNT and VER seem to have the ability to poke through to the outside world, so maybe there's an extra function somewhere?

Easy Mode: The Correct Way

Okay, I know you're screaming it at your screen: the simplest way is to just get the string at FE00:0061—which everybody knows is the common Award BIOS version string address^[2]—and check if it starts with DOSBox. But that's so brittle, y'know? I could just modify a non-DOSBox BIOS to have that version string, or modify DOSBox to have the model string be something else. There's even a comment in DOSBox-X (source) that alludes to this being a desirable change in the future:

    /* TODO: *DO* allow dynamic relocation however if the dosbox-x.conf indicates that the user
     *       is not interested in IBM BIOS compatibility. Also, it would be really cool if
     *       dosbox-x.conf could override these strings and the user could enter custom BIOS
     *       version and ID strings. Heh heh heh.. :) */

So of course I can't take this route! There are other easier ways, like checking the serial number of the Z: drive (or if it exists, for that matter). But these can all be faked pretty easily. No, we must find something that's an inherent part of the emulator. Something that proves this is DOSBox.

Inventing Instructions

Let's go back to how DOSBox can talk to the outside world with commands like MOUNT.COM. COM files are just machine code, meaning we can run it directly through a disassembler. So let's do that, with a copy of MOUNT.COM from DOSBox:

$ ndisasm MOUNT.COM
00000000  BC0004            mov sp,0x400
00000003  BB4000            mov bx,0x40
00000006  B44A              mov ah,0x4a
00000008  CD21              int byte 0x21
0000000A  FE                db 0xfe
0000000B  3805              cmp [di],al
0000000D  00B8004C          add [bx+si+0x4c00],bh
00000011  CD21              int byte 0x21
00000013  02                db 0x02

The first four lines make sense: INT 21h Function 4Ah shrinks the stack to 0x40 paragraphs (128 bytes). But the next couple lines are... basically garbage. db 0xfe just means "there's a byte here, 0xfe", and your typical x86 CPU would balk at this and throw an Invalid Instruction exception.

But when you're writing an x86 CPU, you can just invent your own instructions! Lo and behold, in the DOSBox sources:

/* Snippet from src/cpu/core_normal/prefix_none.h */
CASE_B(0xfe)               /* GRP4 Eb */
    {
	    GetRM;Bitu which=(rm>>3)&7;
	    switch (which) {
			case 0x00:     /* INC Eb */
			    RMEb(INCB);
			    break;
			case 0x01:     /* DEC Eb */
			    RMEb(DECB);
			    break;
			case 0x07:     /* CallBack */
			    {
			        Bitu cb=Fetchw();
			        FillFlags();SAVEIP;
			        return cb;
			    }
			default:
				E_Exit("Illegal GRP4 Call %d",(rm>>3) & 7);
				break;
	    }
	    break;
    }

This is the code for decoding the FE group of opcodes. 0x00 is INC and 0x01 is DEC, both real opcodes on x86.

But that last one, 0x07, that is a DOSBox exclusive. The word after the opcode is used to say which callback should be called...back, and breaks out. So, to fix up the disassembly from earlier, it might look like this:

00000000  BC0004            mov sp,0x400
00000003  BB4000            mov bx,0x40
00000006  B44A              mov ah,0x4a
00000008  CD21              int byte 0x21
0000000A  FE380500          CallBack 0x0005
0000000E  B8004C            mov ax,0x4c00
00000011  CD21              int byte 0x21

0000000A  FE380500          CallBack 0x0005
0000000E  B8004C            mov ax,0x4c00

FE 38 05 00    00 B8 00 4C

Byte:   00 111 000  (0x38)
Mod:    00          (0x00)
Opcode:    111      (0x07)
R/M:           000  (0x00)

Bitu cb=Fetchw();
FillFlags();SAVEIP;
return cb;

Anyway, here it is in the part of the code that generates virtual programs like MOUNT.COM:

/* Snippet from src/misc/programs.cpp */
static Bit8u exe_block[]={
    0xbc,0x00,0x04,                 //MOV SP,0x400 decrease stack size
    0xbb,0x40,0x00,                 //MOV BX,0x040 for memory resize
    0xb4,0x4a,                      //MOV AH,0x4A   Resize memory block
    0xcd,0x21,                      //INT 0x21
//pos 12 is callback number
    0xFE,0x38,0x00,0x00,            //CALLBack number
    0xb8,0x00,0x4c,                 //Mov ax,4c00
    0xcd,0x21,                      //INT 0x21
};

Conveniently, since callbacks are returned the same way as the general status, FE 38 00 00 is effectively a four-byte NOP! On DOSBox, anyway.

Other x86 CPUs won't have such fortune. Since the 80186, invalid instructions trigger a #UD (Undefined Opcode) exception, or Interrupt 06h. So we just need to write an exception handler. Something like this:

_catchUD:
	; Current IP is at the top of the stack, so +4 after we push ax/bx
	push bx
	push ax
	
	mov bx, sp
	mov bx, WORD [ss:bx+4]
	mov ax, bx
	
	mov bx, WORD [cs:bx] ; will copy little-endian (i.e. 0x38fe)
	and bh, 38h
	cmp bx, 38feh
	je .notDosbox
	
	; if we end up here, something went really wrong! clean up the IVT
	; and IRET so the actual #UD handler is called.
	; Since we don't modify the IP, it'll re-run the invalid opcode.
	push es
	xor ax, ax
	mov es, ax
	mov bx, [oldUDAddr] ; previous int 06h addr
	mov [es:18h], bx ; 06h*4
	mov bx, [oldUDSeg] ; previous int 06h segment
	mov [es:20h], bx ; (06h*4)+2
	pop es
	pop ax
	jmp .catchDone
	
	.notDosbox:
	; Not DOSBox -- increment the IP and zero AX
	; You can of course do whatever here, like setting a global
	add ax, 4
	mov bx, sp
	mov WORD [ss:bx+4], ax
	xor ax, ax
	add sp, 2 ; AX unneeded
	
	.catchDone:
	pop bx
	iret

which, once set up, could be tested like this:

	mov ax, 42
	db 0xfe, 0x38, 0x00, 0x00
	; was the exception handler here?
	cmp ax, 0
	jz .notDosbox ; Not DOSBox!
	; DOSBox-only code starts here!
	.notDosbox:
	; Non-DOSBox code starts here!

Add in some extra instructions to reset the interrupt 06h vector once done, and we should have a pretty good check for DOSBox!

DEBUGging x86

At this point in writing, I decided it'd be a good time to test this on hardware. But my Pentium II systems are currently a bit buried, and it'd be hard to get good screenshots of them anyway... so I figured I'd use 86Box.

This did not go according to plan:

Importantly, this is not DOSBox. But that's okay, because we can just step through it with the DEBUG program in MS-DOS and see what's going wrong. It's not the most, er, friendly program, but it's enough to get the job done in a case like this.

There's a command, t, which lets you step through the code one instruction at a time. (Well, mostly.) So we'll step through to the callback instruction, and we can see here DEBUG has no idea what's going on, even if it encodes it correctly enough... but then steps through it as though it's valid!?

At this point, I was entirely confused. Is this some secret undocumented instruction? Does 86Box ignore invalid instructions for some reason? Do invalid instruction exceptions not work how I thought they do? Could a DOS driver somehow mask the interrupt?

I'll save you the days of troubleshooting I spent on this: 86Box inherited a bug from PCem where any ModR/M opcode modifier other than 0 was treated as FE /1.^[3] So FE /2, FE /4, and FE /7 all acted as DEC calls. Thankfully the fix was pretty simple, and it's already been merged upstream.

As mentioned in the PR, special thanks to linear for testing this on actual hardware so we can be (at least somewhat) sure this isn't just an Intel documentation issue.

The Finished Product(?)

If you want to run the sample program I wrote for this, you can get it on my Git forge here. You'll need NASM to compile it. It'll run fine on DOSBox and DOSBox-X, at least.

While this was a fun project on its own, my intent wasn't just to detect DOSBox. It just happened to be the trickiest to figure out. NTVDM and the Win9x MS-DOS Prompt are easier to detect, basically just a single INT 2Fh call. There's another DOS emulator for linux, aptly named DOSEMU, which has... a surprising amount of callback APIs. They're all implemented as COM files (e.g. UNIX.COM lets you run arbitrary commands on the host system), so it's not like they're hidden features. Of course, none of these are quite as hard to spoof as a custom CPU instruction, but they're more liable to cause side effects than changing a BIOS string would.

You click "Unsubscribe," and you're unsubscribed. No pleading taco emoji, no line of check boxes, just a plainly-labeled button at the top of the email.

Apparently this is also supported in some webmail clients, but I'm not interested in accessing my email that way.^[1] Unfortunately, I haven't found an X11 or Wayland email client that supports this sort of functionality, so I decided to implement it myself. And anyway, I'm trying out Kontact for my mail at the moment, which supports plugins. So why not use this as an opportunity to build one?

What is Kontact?

Kontact is an all-in-one Personal Information Manager (PIM) developed for KDE. The actual "Kontact" program is more like a fancy frontend: Email is handled via KMail, KOrganizer provides to-do lists and calendars, and KAddressBook... well, these names aren't the most original. All of these programs can run independently, or be embedded into Kontact as KParts and using the KontactInterface::Plugin interface. These are called "Kontact plugins," and are not what we want to build.

However, there is another set of plugins. If you go to "Configure KMail...", you can see them:

These are split up into different categories: Akonadi Agents, Composer Plugins, Editor Plugins, and a category named "Message Viewer." Since we'd need to act on the message viewer, we'll want to write one of those. But there's no "install plugin" button. How do we start building one? If it's not a Kontact plugin, is it an Akonadi plugin? Or a secret third thing?

Akonadi and Messagelib

To quote KDE:

The Akonadi framework is responsible for providing applications with a centralized database to store, index and retrieve the user's personal information. This includes the user's emails, contacts, calendars, events, journals, alarms, notes, etc.

In essence, this is the backend of Kontact (Akregator excluded). So we won't be building a plugin for Akonadi, but we will be interacting with it shortly.

The plugins we see in the Configure window come from the PIM/kdepim-addons repository. We'll use the "Create Event" plugin as our reference, and we can find it in plugins/messageviewerplugins/createeventplugin. From there, we can find the interface being used:

namespace MessageViewer
{
class ViewerPluginCreateevent : public MessageViewer::ViewerPlugin
{
    Q_OBJECT
public:
    explicit ViewerPluginCreateevent(QObject *parent = nullptr, const QList<QVariant> & = QList<QVariant>());
    ViewerPluginInterface *createView(QWidget *parent, KActionCollection *ac) override;
    [[nodiscard]] QString viewerPluginName() const override;
};
}

MessageViewer isn't a direct part of KMail or Kontact. It's part of Messagelib, which contains various widgets used for displaying and composing emails. These widgets are then used by KMail.

Okay great, we finally have the interface and library we need to start building a plugin! Now to pull up the docs for MessageViewer::ViewerPlugin, and

oh

Working Backwards

Normally, I'd start by building code and set up the build system as I go. At least for smaller projects, it can be easier to hit the ground running. But since we have no idea what we're working with here, I'm going to set up the bare minimum to get a working plugin.

Due to the way KDE Frameworks are, we're going to want to use CMake for this. The good news is we don't have to think too hard about it, thanks to KCoreAddons and KDE's library of CMake Modules, known as, uh, Extra CMake Modules.

# I've been testing with KF6, but maybe this will work with KF5
set(KF_MIN_VERSION "6.0.0")

# Extra CMake Modules (ECM) setup
find_package(ECM ${KF_MIN_VERSION} CONFIG REQUIRED)
set(CMAKE_MODULE_PATH ${ECM_MODULE_DIR} ${ECM_KDE_MODULE_DIR})
include(ECMQtDeclareLoggingCategory)
include(KDEInstallDirs)
include(KDECMakeSettings)

set(kmail_unsubscribe_SRCS
	# C++ sources go here...
	unsubscribeplugin.cpp
	unsubscribeplugin.h
)

ecm_qt_declare_logging_category(
	kmail_unsubscribe_SRCS
	# What the header will be
	HEADER "unsubscribe_debug.h"
	# The object name
	IDENTIFIER "UnsubscribePlugin"
	# How to refer to it externally, e.g. by
	# QT_LOGGING_RULES
	CATEGORY_NAME "xyz.datagirl.kpim.unsubscribe"
	DESCRIPTION "Unsubscribe Plugin"
	DEFAULT_SEVERITY Info
	EXPORT
)

# Build a .so, not .a
set(BUILD_SHARED_LIBS ON)

# Let the KCoreAddons macro make our target
kcoreaddons_add_plugin(kmail_unsubscribe
	SOURCES ${kmail_unsubscribe_SRCS}
	# Used when installed
	INSTALL_NAMESPACE pim6/messageviewer/viewerplugin)
# Now we can link libraries, set properties, etc
target_link_libraries(kmail_unsubscribe
	KPim6::PimCommon
	#...
)

Now we have to define the metadata in a JSON file. In my case, it's kmail_unsubscribeplugin.json:

{
	"KPlugin": {
		"Description": "Adds an Unsubscribe button to messages",
		"EnabledByDefault": true,
		"Name": "Unsubscribe",
		"Version": "2.0"
	}
}

Then, integrate it with your plugin class. For example, I have in unsubscribeplugin.cpp:

// UnsubscribePlugin is defined in this header
#include "unsubscribeplugin.h"

#include <KPluginFactory>

using namespace MessageViewer;
K_PLUGIN_CLASS_WITH_JSON(UnsubscribePlugin, "kmail_unsubscribeplugin.json")

Finally, we're getting to code! First, we'll build out the scaffolding for UnsubscribePlugin in the header:

// Requires KPim6MessageViewer
#include <MessageViewer/ViewerPlugin>
#include <QVariant>

namespace MessageViewer {
	class UnsubscribePlugin
		: public MessageViewer::ViewerPlugin
	{
		Q_OBJECT
	public:
		explicit UnsubscribePlugin(QObject *parent = nullptr,
			const QList<QVariant> & = QList<QVariant>());

		[[nodiscard]] ViewerPluginInterface *createView(QWidget *parent,
			KActionCollection *ac) override;

		[[nodiscard]] QString viewerPluginName() const override
		{
			return QStringLiteral("oneclick-unsubscribe");
		};
	};
}

And in the source file:

// Pass up parent, ignore QList
UnsubscribePlugin::UnsubscribePlugin(
	QObject *parent,
	const QList<QVariant> &
) : MessageViewer::ViewerPlugin(parent)
{
}

// Create a new plugin interface when asked
ViewerPluginInterface *
UnsubscribePlugin::createView(
	QWidget *parent,
	KActionCollection &ac
)
{
	MessageViewer::ViewerPluginInterface *view =
		new UnsubscribePluginInterface(ac, parent);
	return view;
}

// Meta Object Code (MOC) with the plugin definition
#include "unsubscribeplugin.moc"
// MOC for the CPP file
#include "moc_unsubscribeplugin.cpp"

The Plugin Interface

Up until this point, we've been just getting the plugin structure setup. The real core of the plugin is the plugin interface class, defined in our case by ViewerPluginInterface. While its API documentation is lacking, it'll help us define our subclass:

#include <MessageViewer/ViewerPluginInterface>

namespace MessageViewer
{
	class UnsubscribePluginInterface
		: public MessageViewer::ViewerPluginInterface
	{
		Q_OBJECT
	public:
		explicit UnsubscribePluginInterface(
			QWidgetParent *parent = nullptr,
			KActionCollection *ac);
		~UnsubscribePluginInterface() override;

		// In our case, we'll be returning mActions (see below)
		[[nodiscard]] QList<QAction *> actions() const override;

		// We'll get to these four shortly
		void updateAction(const Akonadi::Item &item) override;
		void setMessageItem(const Akonadi::Item &item) override;
		void execute() override;
		void closePlugin() override;

		// This defines what your plugin supports. More on that
		// in a moment.
		[[nodiscard]] ViewerPluginInterface::SpecificFeatureTypes
			featureTypes() const override
		{
			return ViewerPluginInterface::NeedMessage;
		}
	private:
		// What we'll be returning in actions()
		QList<QAction *> mActions;
	};
}

For those who looked at the API docs, you might have noticed I'm skipping quite a few methods. The parent class, ViewerPluginInterface, defines all those methods as no-ops for us, so we don't need to implement what we don't care about.

The featureTypes() method defines the places it makes sense for your plugin to appear. While I haven't been able to figure out the specifics, the general idea seems to be:

• Define ViewerPluginInterface::NeedMessage when you're working with the whole message (ex., toolbar items on the message view)
• Define ViewerPluginInterface::NeedText when you'll be dealing with the currently-selected text in a message
• Define ViewerPluginInterface::NeedUrl when you'll be interfacing with a clicked URL

These can be combined with bitwise OR, if you need multiple. You can also just define ViewerPluginInterface::None if you have no need for any of those.

Okay, enough with the class definitions. Let's put together the constructor:

using namespace MessageViewer;

UnsubscribePluginInterface::UnsubscribePluginInterface(
	QWidget *parent,
	KActionCollection *ac
) : ViewerPluginInterface(parent)
{
	if (ac)
	{
		// Create an action...
		auto action = new QAction(this);
		action->setIcon(QIcon::fromTheme(QStringLiteral("news-unsubscribe")));
		action->setIconText(QStringLiteral("Unsubscribe"));
		action->setWhatsThis(QStringLiteral("Unsubscribe from the mailing list"));
		// ... and add it to the collection
		ac->addAction(QStringLiteral("oneclick_unsubscribe"), action);
		// Lastly, connect the triggered signal to a slot defined
		// upstream
		connect(
			action,
			&QAction::triggered,
			this,
			&UnsubscribePluginInterface::slotActivatePlugin
		);
		// Finally, add to our internal actions list
		mActions.append(action);
	}
}

This part is pretty straightforward: create a QAction, add it to the application's collection, and hook up the signal that occurs when the action is activated (e.g. when clicked, or a relevant keyboard shortcut is pressed).

That should be the last of our scaffolding. Finally, onto the interesting part!

The Interesting Part

Our plugin's journey truly starts when the user selects an email. When this happens, the Message Viewer calls our plugin interface's updateAction(Akonadi::Item &item) method.

While Akonadi::Items are general objects that can contain a number of things, we'll only receive ones with a shared pointer to a KMime::Message. Switching folders appears to cause an updateAction call with an Akonadi::Item that has a null payload, so you may want to guard against that:

if (item.hasPayload<KMime::Message::Ptr>())
{
	mMessage = item.payload<KMime::Message::Ptr>();
	if (mMessage == nullptr)
	{
		// Couldn't get the KMime message, bail
		return;	
	}

	// Now we can work with mMessage!
}

As might be evident by the method name, updateAction is to update our action for the email we're on. In the case of our unsubscribe plugin, we may want to disable the action if we determine the user can't automatically unsubscribe from this email.

Once our action is triggered, the following bit of code in Messagelib is run:

void ViewerPrivate::slotActivatePlugin(ViewerPluginInterface *interface)
{
    interface->setMessage(mMessage);
    interface->setMessageItem(mMessageItem);
    interface->setUrl(mClickedUrl);
    interface->setCurrentCollection(mMessageItem.parentCollection());
    const QString text = mViewer->selectedText();
    if (!text.isEmpty()) {
        interface->setText(text);
    }
    interface->execute();
}

We won't need to implement all of these methods for our plugin, but since we're here anyway, here's my understanding of the process:

1. setMessage(mMessage) provides us with the actual message pointer.
2. setMessageItem(mMessageItem) gives us the Akonadi::Item corresponding to the message.
3. If a URL is selected, setUrl(mClickedUrl) would give us the URL that was clicked.
4. setCurrentCollection(...) gives us the parent Akonadi::Collection for our given message. This would most often be the email's folder.
5. If there's selected text, setText(text) passes that to us.
6. Finally, execute() is our cue to start doing our thing!

There's one last important method: closePlugin(). This is called when the current email is closed, to tell plugins to flush the current state. This would of course include closing the window, but more importantly includes every time the user changes the active email. In such a case, updateAction is called almost immediately, and the cycle repeats.

connect(DKIMManager::self(),
	   &DKIMManager::result,
	   this,
	   &SomePluginInterface::slotDkimResult);
DKIMManager::self()->checkDKim(mMessageItem);

And all the Rest

And now you have at least a vague idea of how to build a plugin for a specific component of a specific part of Kontact!

"But what if I want to build a really cool plugin for (email composing/KAddressBook/Akonadi)?" I hear you ask. Well, dear reader, I have no idea. It looks like most other plugins are derived from PimCommon::GenericPluginInterface, which is independent of MessageViewer::ViewerPluginInterface.

My recommendation would be to look at existing plugins that do something remotely adjacent to what you want to do and look at the interfaces it implements. All of the built-in plugins come from PIM/kdepim-addons, so there's a good chance the repository is in there.

If the KDE API docs are failing you and web searches don't pull anything up, you'll want to reverse engineer those interfaces. Try to make a barebones plugin derived from your "sample," using ecm_qt_declare_logging_category to create a new logging category and a bunch of qCDebug(YourCategory) calls to trace the behavior of those methods. If all else fails, search the KDE PIM libraries' source code for where the interface would call your plugin!

yes this was the most efficient way to get the functionality i wanted, why do you ask :)

If you're interested in the project that kickstarted all of this, I have it available both on my Git server and on GitHub.

These days, file sharing is done via the Hypertext Transfer Protocol (HTTP)^[1], often using Transport Layer Security (TLS).^[2] Built into every version of Windows since Windows 95 is WinINet, which provides HTTP, FTP, and (in XP/2003 and earlier) Gopher. Obviously for older Windows versions, this library won't include support for recent technologies like TLS 1.3 or HTTP/2. cURL still supports Visual C++ 6, but that only provides the HTTP/FTP part. We'll need a TLS library to get connected to most modern systems.

Prerequisites

While I'm currently getting things running on Windows 2000 Professional SP4, I'd like to get this working on Windows 95 and 98 too. To that end, I'll be using Visual Studio.NET 2003, which was the last version to support Windows 95. I'm also building everything in Windows 2000, but that part's optional.

You'll also need a copy of the Platform SDK from the era. I'm using the February 2003 MSDN release, for no other reason than it sounded like a good fit for VS2003.

And some general advice if you want to develop for old Windows versions: the MSDN Library that comes with VS2003 is so much more useful than the version on the Internet. Today's MSDN docs are a minefield of incorrect version information, and while I'm sure modern-day search engines are far better than WinHelp, the built-in search function is surprisingly useful.

WolfSSL and Visual C++

Before we think about compiling cURL, we need a TLS library. In the past I've made hacks to OpenSSL to get it to build on pre-Vista Win32, but I'd really rather avoid that for something I share with others.

Inspired by the post on Dialup.net about building WolfSSL for Windows 3.11 for Workgroups, I decided that would be a better place to start.

At first glance, I noticed a file named wolfssl.vcproj, indicating a pre-Visual C++ 2010 project. Good start, except the project was made in Visual Studio 2008.^[3]

<?xml version="1.0" encoding="Windows-1252"?>
<VisualStudioProject
        ProjectType="Visual C++"
        Version="9.00"

To make matters worse, the project was woefully outdated. It was missing several files required to link, meaning I had to cherry-pick files as I got errors.

Unfortunately, there's not a great way to automate this. So began the process of painstakingly adding files to the project until it compiled, using the CMakeLists.txt and VC2010+ .vcxproj files as references.

Configuring WolfSSL

As is common with software written in C, configuration is handled via #define statements. WolfSSL helpfully allows you to override the usual configuration process by defining WOLFSSL_USER_SETTINGS. This allows us to use the configuration already used by the .vcproj: IDE/WIN/user_settings.h.

Figuring out the right defines took more troubleshooting than I care to describe, so here's a lightning round:

• First, force C89 by defining WOLF_C89 and NO_WOLF_C99. More on this in a bit.
• Disable WOLFSSL_SP_X86_64,since we won't be running this on an x86_64 CPU.
• We don't have strntok or strtok_s, so define USE_WOLF_STRTOK.

We also have to define a few functions, so add them:

#define XSTRTOK wc_strtok
#define XVSNPRINTF _vsnprintf

We also need to define strcpy_s. My workaround was to use StringCchCopy, which is close enough? Probably? You need to #include <Winerror.h> first though, so later #include <Windows.h> lines don't try to re-define the SUCCEEDED and FAILED macros. Win32 headers are annoying like that.

Out with the new

As mentioned previously, WolfSSL helps us avoid most of the C99 stuff with the WOLF_C89 and NO_WOLF_C99 defines. Unfortunately, this doesn't seem to account for variadic macros. They were first supported with VC2005, so we'll have to work around it. They're all used as a way to NOP functions, so we can either patch simpler functions like so:

// from ...
#define X509_check_purpose(...)     0
// ... to
#define X509_check_purpose(x)       0

Or for more complex functions where I don't feel like faking ten parameters, we can define an __inline variadic function:

// from...
#define SSL_CTX_add_server_custom_ext(...) 0
// ... to
__inline int SSL_CTX_add_server_custom_ext(SSL_CTX *ctx, ...) {
	(void)(ctx); // avoid compiler complaints about unused parameters
	return 0; // return 0
}

Lastly, although not a C99 feature, we need to stop wc_port.h from including <intrin.h>, since VC2003 doesn't include that. My understanding is VC2005 does, so we just change:

#elif defined(_MSC_VER)
     /* Use MSVC compiler intrinsics for atomic ops */
     #include <intrin.h>

to:

#elif _MSC_VER >= 1400
     /* Use MSVC compiler intrinsics for atomic ops */
     #include <intrin.h>

And now we're good. All done, ready to build.

Just kidding, I forgot about WinSock

There's one last function I couldn't just stub out: inet_pton. The prototype is pretty simple:

INT WSAAPI inet_pton(
  [in]  INT   Family,
  [in]  PCSTR pszAddrString,
  [out] PVOID pAddrBuf
);

In this case, Family can be either AF_INET or AF_INET6. You feed in a string representing the address (e.g., "198.18.0.1") and it writes either an IN_ADDR or IN6_ADDR struct, both more machine-readable than a C string. It's pretty convenient!

It's also not a thing on old Windows versions. Windows 2000 only supports IPv6 as part of a technology preview. And on older versions of Windows, you definitely aren't gonna see that turtle dance. From what I can find, inet_pton was first supported in Windows Vista. So we'll have to write our own.

That's pretty easy with inet_addr, which takes a C string and gives you an unsigned long. So, let's just build our own:

#ifndef InetPton

int __stdcall
InetPton(int Family,
         const char *pszAddrString,
         void *pAddrBuf)
{
        IN_ADDR *addr = pAddrBuf;
        unsigned long ulTmp;
        
        if (Family != AF_INET) {
		        // Oops! We don't support that addr family
                WSASetLastError(WSAEAFNOSUPPORT);
                return -1;
        }

        if (!pAddrBuf || !pszAddrString ||
	        pszAddrString[0] == '\0') {
                WSASetLastError(WSAEFAULT);
                return -1;
        }

		// Technically we could just put the return val directly
		// into addr->S_un.S_addr, but I don't like writing bad
		// data unless absolutely necessary. So store it in a temp
		// variable, first.
        ulTmp = inet_addr(pszAddrString);
        if (ulTmp == INADDR_NONE) {
		        // Not an IP address
                WSASetLastError(WSAEFAULT);
                return -1;
        }

		// S_un.S_addr is an unsigned long. Easy!
        addr->S_un.S_addr = ulTmp;
        return 0;
}

#endif /* !InetPton */

Now, this does throw a warning during compilation ("incompatible types - from 'PCWSTR' to 'const char *'"), but WolfSSL is already casting an ASCII string to PCWSTR. So I think it's fine.

Probably.

Deployment

Visual Studio doesn't provide a great way of deploying to a random prefix along the lines of your standard make DESTDIR=whatever install. So I tried to replicate that with a script called install.js. It performs the following steps:

1. Copies the include files in wolfssl to %DESTDIR%\include\wolfssl, excluding the files referenced by CMakeLists.txt;
2. Writes a hardcoded set of options to %DESTDIR%\include\wolfssl\options.h, similar to how it would be handled by CMake; and
3. Copies the wolfssl.lib file to %DESTDIR%\include\wolfssl\lib.

From the repository root, it should be as simple as running:

cscript install.js X:\whatever Release

to "install" the Release build.

Step 2: cURL

Now that we're done with the gauntlet of WolfSSL, installing cURL should be pretty straightforward! I mean, they provide a Makefile that they call out as compatible with Visual C++ 6.0. The README has no reference to WolfSSL—just MbedTLS or OpenSSL—but we'll come back to that later. For now, I want to see if this builds without TLS support.

According to the README, we'll need the following switches set in the command line:

• I'm setting mode=static to make a static library, just to arbitrarily pick something.
• VC=7 is more for our reference, since it sets the "full name" of the library. It doesn't affect anything else that we care about.^[6]
• ENABLE_IDN=no and ENABLE_IPV6=no, since our Windows versions don't support those.
• USE_SSPI=no, because some of the features used require higher than Windows 2000.

So with that, we run the build:

> nmake /f Makefile.vc mode=static VC=7 ENABLE_IDN=no ENABLE_IPV6=no USE_SSPI=no

Microsoft (R) Program Maintenance Utility Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.

configuration name: libcurl-vc7-x86-release-static
The input line is too long.
NMAKE : fatal error U1077: 'CALL' : return code '0xff'
Stop.

Ah.

A Quick Aside About Batch Files

no wait before you skip this, i promise it'll be quick

The Windows NT Command Prompt (cmd.exe) has a maximum amount of characters per command you can write. UNIX-y shells have this limitation too, and you can see it by running getconf ARG_MAX. Per some old Microsoft docs, the maximum in Windows 2000 (and NT 4.0) is 2047 characters. When you surpass this limit, you get The input line is too long. In modern technical terms, this is called an "annoyingly small limitation."

So, why are we hitting this limit? Makefile.vc is calling out to gen_resp_file.bat, which takes a bunch of files as input and dumps them out as an NMake .inc file to be imported later on. For example:

!INCLUDE "../lib/Makefile.inc"
LIBCURL_OBJS=$(CSOURCES:.c=.obj)

[...]
	@SET DIROBJ=$(LIBCURL_DIROBJ)
	@SET MACRO_NAME=LIBCURL_OBJS
	@SET OUTFILE=LIBCURL_OBJS.inc
	@CALL gen_resp_file.bat $(LIBCURL_OBJS)

I won't copy the contents of "../lib/Makefile.inc", but there's a lot of files in there. Enough that we run up against this limit, but not when the batch file is run. The culprit is this loop in the batch file:

for %%i in (%*) do echo         %DIROBJ%/%%i \>> %OUTFILE%

%* is a variable representing all the arguments passed to the batch file. Unlike shells like bash, for loops don't get special treatment—the variables get expanded before the command line is run, and we trip over the 2047 character limit before we can even get to looping.

So I'll make my own for loop, with SHIFT and GOTO:

:loop
IF [%1] == [] GOTO done
echo            %DIROBJ%/%1 \>> %OUTFILE%
SHIFT
GOTO loop
:done

In this case, we only need to expand one parameter at a time, avoiding the command line limitation altogether. It might be slower, but on my Pentium II @ 400MHz, I couldn't tell.

(Re)Configuring cURL

Of course, "compatible with Visual C++ 6.0" doesn't necessarily mean "compatible with wildly outdated operating systems." So there are a few extra changes to make. All of these changes can be made in lib\config-win32.h in the source tree.

Starting off: I cannot for the life of me figure out why __fseeki64 is defined in some versions of Visual C++ 6.0 and above, but not in others. It seems like it's probably not supported in Windows 9x anyway? So, sorry if you wanted to upload files larger than 2GiB, but I'm enforcing USE_WIN32_SMALL_FILES, which reverts to the old fseek function.

cURL wants a type named ADDRESS_FAMILY, but it never gets defined. I think this is also defined in later WinSock versions, but it also doesn't really matter since we can just #define ADDRESS_FAMILY USHORT.

Supporting WolfSSL

While we're already messing with build files, this seems like a good time to add WolfSSL support into the Makefile. You can already include MbedTLS with WITH_MBEDTLS=<dll/static>, so that seems like a good starting point. In MakefileBuild.vc:

!IFDEF MBEDTLS_PATH
MBEDTLS_INC_DIR  = $(MBEDTLS_PATH)\include
MBEDTLS_LIB_DIR  = $(MBEDTLS_PATH)\lib
MBEDTLS_LFLAGS   = $(MBEDTLS_LFLAGS) "/LIBPATH:$(MBEDTLS_LIB_DIR)"
!ELSE
MBEDTLS_INC_DIR  = $(DEVEL_INCLUDE)
MBEDTLS_LIB_DIR  = $(DEVEL_LIB)
!ENDIF

[...]

!IF "$(WITH_MBEDTLS)"=="dll" || "$(WITH_MBEDTLS)"=="static"
USE_MBEDTLS    = true
MBEDTLS        = $(WITH_MBEDTLS)
MBEDTLS_CFLAGS = /DUSE_MBEDTLS /I"$(MBEDTLS_INC_DIR)"
MBEDTLS_LIBS   = mbedtls.lib mbedcrypto.lib mbedx509.lib
!ENDIF

!IF "$(USE_MBEDTLS)"=="true"
CFLAGS = $(CFLAGS) $(MBEDTLS_CFLAGS)
LFLAGS = $(LFLAGS) $(MBEDTLS_LFLAGS) $(MBEDTLS_LIBS)
!ENDIF

For the most part, we can just copy and paste these lines, changing MBEDTLS to WOLFSSL. The only other line to worry about is updating the library files to be... well, wolfssl.lib:

WOLFSSL_LIBS    = wolfssl.lib

Also, now that we set USE_WOLFSSL, cURL will try to #include <stdint.h>. VC2003 doesn't provide that, so copy this public domain version that I patched into your deps/include folder. It's the same one that's been floating around the Internet for years, but I removed the WCHAR_MIN and WCHAR_MAX defines because they conflict with the ones in <Windows.h>.

Compiling cURL

> nmake /f mode=static VC=7 ENABLE_IDN=no ENABLE_IPV6=no WITH_WOLFSSL=static USE_SSPI=no

Assuming no errors occur, the completed curl.exe should be in builds\libcurl-vc7-x86-release-static\bin. But does it work?

> curl -kv https://bell.2ki.xyz
* Host bell.2ki.xyz:443 was resolved.
* IPv4: 209.251.245.54
*   Trying 209.251.245.54:443...
* Connected to bell.2ki.xyz (209.251.245.54) port 443
* SSL connection using TLSv1.3 / TLS13-AES128-GCM-SHA256
* using HTTP/1.x
> GET / HTTP/1.1
> Host: bell.2ki.xyz
> User-Agent: curl/8.6.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.24.0
< Date: Sat, 02 Mar 2024 00:52:43 GMT
< Content-Type: application/octet-stream
< Content-Length: 16
< Connection: keep-alive
<
It works! (TLS)
* Connection #0 to host bell.2ki.xyz left intact

At least on my system, it seems so!

What now?

There are a few projects other than the aforementioned screenshot project that I think could be useful. Providing a WinHTTP.dll shim library is my first thought, although I imagine most services using that library are already dead.

As you'll see in the build files for both projects, my next plan is to try for Windows 9x support. I don't currently have a 95/98 workstation readily available, but I'll update this post when I do. If you give it a try before then, please let me know!

Generating the site

Despite being the part I spent the largest chunk of time on, I don't have much to say on the scripts that assemble this site together. I was interested in learning Perl and found the idea of using an existing solution boring, so I made my own.

I would not advise you use this for your own site^[1], but if you want to check out the source, it's available here.

Professional...ness

For years I've been plagued by a need to be "professional" with the things I create online. This, in my mind, translates to an almost sterile expression—anything outside of absolute plain-text or some Twitter Bootstrap-y design is too far.

However, any site I make that ends up so barren will just cause me to lose any motivation to work with it. So, I'm trying something new! I'm hoping to hit an early-to-mid '00s style with this, with some extra handling for more modern devices. I don't feel it's really that far out of the norm anyway, but it's the little things that count, right?

Checking off "moral justification for putting all content into a single <table>"...

That said, making a more complex design means having to worry about how browser rendering engines work. That is, they work like a tower of bricks liable to topple if one of your hyperlinks sneezes the wrong way.

Browser engines

For better or worse, the browser landscape is pretty boring these days. Responsive design is more important with screens taking a myriad of forms, from touch-screen phones to 8K 50-inch televisions. Despite the variety, there are usually a few key assumptions you can make.

With over 65% market share as of time of writing^[2]—not even including the browsers using the same underlying renderer—Google Chrome and its Blink engine are going to be the most common you'll see. Of course there may be some small differences depending on the OS, but most if not all of the features are consistent. And especially if you stick to standards or keep an eye on sites like MDN and caniuse.com, supporting non-Blink browsers like Firefox and Safari won't be much of a problem.

But those aren't the only browsers still updated these days! Text-mode browsers like lynx, derivatives like Pale Moon and SeaMonkey, and built-from-scratch GUI browsers like NetSurf are all used by a multitude of people today. Not all these browsers are going to support modern JavaScript, features like custom fonts, or even graphical elements like images. This brings a lot of challenges, not all of which are neatly solved.

Just trying to support modern browsers, you might have to employ kludges to get things to look as you hope. For example, say someone converts an old bitmap font to a pixellated TTF format so you can further have that 2000s web design aesthetic for your site. You've taken a crowbar to the anti-aliasing algorithm of every browser as much as you can (much to the frustration of other web designers), and things are looking pretty crisp. Then you get a message or five from others saying the font looks broken. It's blurry, or it's stretched in weird ways.

You're able to deduce the issue as being a rendering issue if the text is aligned on a half-pixel^[3]. This weird quirk might be happening because of how you center your content in the browser. Maybe something like:

    width: 500px;
    position: absolute;
    left: -250px;
    margin-left: 50%;

So with a viewport size of 1920x960, (1920 * 0.5) - 250 = 710px and everybody's happy. But resize your window to 1919x960 and you get 709.5px, causing the font renderer to become evil.^{[citation needed]}

So you might end up with this garbage, just to get the centering to round to the nearest pixel:

function fixMargin() {
    document.getElementById("main").style.marginLeft =
        Math.floor(window.innerWidth / 2).toString() + "px";
}
window.addEventListener('resize', fixMargin, true);
window.addEventListener('DOMContentLoaded', fixMargin, true);

But it works! Most of the time. And also only if your browser supports JavaScript, but what browser wouldn't support JavaScript in 2022?

NetSurf

I have strong and complex opinions about JavaScript. They're nothing that hasn't been discussed to death, but I'd prefer to avoid JavaScript when possible and make sure that a curious user knows why I'm running code on their computer.

Even so, it'd be bad to assume my JavaScript will run at all.

NetSurf is a small, fast web browser that supports HTML5 and CSS 2.1 in varying capacities, and has some preliminary support for JavaScript. That said, support for JavaScript is disabled by default, and support for other technologies is a bit complicated.

I only started working on NetSurf support after a partner noted an older version of the site's design looked broken in the browser. The content was readable and most of the functionality worked fine, but it wasn't very pretty. And that just won't do.

First off was dealing with the CSS. Chrome, Safari, and Firefox support multiple background-images in succession, and show them right next to each other. Something like:

background-image: url(img/left.png), url(img/right.png);
background-position: top left, top left;
background-repeat: no-repeat, repeat-x;

NetSurf refuses to even process any images if it sees them in a list format like that. NetSurf also doesn't support z-index yet, so I had to be careful about how I designed elements that'd be in "layers," like the snowflake in the site background.

One hack I'm proud of is how I handle the "subtitle" seen on the index page. In browsers with JavaScript enabled, you only see one of the (currently) three subtitles, and can get another one by clicking on it:

If you're on a browser that doesn't support JS or has it disabled though, you should see the full list, like so:

This is accomplished by the use of a <noscript/> tag. If you have something like:

    <noscript>
      <p>
        Hello, world!
        <a href="http://example.com">Click here.</a>
      </p>
    </noscript>

A browser with JavaScript will hide the element, and a browser without JavaScript will show the element. Except it's not quite as simple as setting display: none; on the tag. The browser with JavaScript won't even attempt to process the HTML within the tag.

So the script that handles the rotation of the subtitles grabs the <noscript/> element, passes that to a DOMParser object, and uses that to grab the DOM elements it needs.

After a lot of tweaking and frustration, I had something that looked mostly similar between all the browsers I was testing. There are still some small differences (for example, NetSurf doesn't seem to support custom fonts yet), but it was enough for me to sleep peacefully at night.

And then I came up with an absolutely awful idea.

Anyway, Here's Netscape

I got together a Windows 98 SE virtual machine with QEMU, connected it to the Internet like your parents said you should never do, and installed Netscape 7.2. Surprisingly, the dev site was in pretty good shape. Probably the work put into NetSurf support paid off.

The most notable issue was that the subtitle wasn't appearing at all. Attempts to troubleshoot with Netscape's JavaScript console made me appreciate Firefox's modern console a bit more.

The majority of the errors were, as one might guess, features that just didn't exist when Netscape 7 was created. As shown above, no console object exists in Netscape for console.log() calls to log to the console. This also kills the script, which makes sense but is also annoying.

The JavaScript debugger bundled with Netscape, named Venkman, is surprisingly nice for the time. From my experiences as a kid messing around with Frontpage and Internet Explorer 6 or so, I was dreading it. To the contrary, it almost felt like a proper IDE. I can definitely feel where pieces of this ended up becoming the modern Firefox developer tools.

And without further ado, here's a full screenshot of the site in Netscape 7.2:

It's got some issues with colors, but I'm happy with it.

And in case you're curious, here's how it looks on Internet Explorer 5 on the same VM:

I will not be fixing this in the near future, mainly because debugging Internet Explorer is annoying and I don't even know where to begin with whatever's happening here. Maybe someday I'll revisit it.

Moving forward

This site is still far from complete, so things will change over time. Maybe I'll spontaneously find motivation to get the site presenting properly in Dillo! Probably not.

Honestly, the Netscape support was an "extra credit" exercise. I sought to support NetSurf because multiple loved ones use it, and I'm at least pretty confident that if my site can work in Netscape 7.x, it'll work in later Gecko forks like Pale Moon.

Also, I hate working with mobile browsers and will put off things I dread until the last second. But I'm sure that's got nothing to do with it.