Nathan's KB

openssl-self-ca - [Windows]

nathanpc (nathanpc@undisclosed.example.com) — 2026-05-02T08:19:58+00:00

Self-hosted Root CA using OpenSSL

Do you hate how modern web browsers complain about using HTTP as if it's actually insecure to read plain text? It's extremely dumb to think that self-hosted infrastructure is insecure and must be accessed via HTTPS, especially when it's only accessible locally or via a VPN, but here we are.

Modern browsers block these “insecure” websites from accessing your camera, microphone, and even the clipboard, and some of these features may be important for some homelab applications. Thus the need for you becoming your own Root CA arrises.

Building the Certificate Authority

This is how you can run your own CA infrastructure easily using only the default install of OpenBSD 7. Unless otherwise noted all steps taken here assume the root folder of the CA resides in the /ca directory at the root of your system drive.

Creating the Folder Structure

A Trusted Root Certificate Authority is a serious business, so you should be serious about the organization of your operation, for this I have created the following folder structure to ensure the CA infrastructure that is built is actually scalable and organized:

mkdir /ca        # The root of our CA infrastructure.
mkdir /ca/root   # Stores the Root Certificate.
mkdir /ca/certs  # Stores the self-signed domain certificates we issue.
mkdir /ca/utils  # Contains utility scripts to manage our operation.

If you're following this guide, this folder structure is expected to be in place.

Getting a Root Certificate

The root certificate will be responsible for creating the chain of trust of all your issued certificates. It's also the only one that will have to be installed in your clients to allow them to accept your self-signed certificates for all your locally-hosted websites. To create a root certificate you'll have to do the following:

cd /ca/root
openssl genrsa -des3 -out root.key 2048
openssl req -x509 -new -nodes -key root.key -sha256 -days 3650 -out root.pem

I won't pretend to understand exactly the implications of my decisions here in terms of parameters, but this should create a root certificate that will be good for 10 years.

Generating OpenSSL Configuration

The next step in achieving your status as a Trusted Certificate Authority is to create the OpenSSL configuration files used when generating new certificate requests. The OpenSSL certificate creation process must always go through a signing request procedure, even if you're doing so on the same machine.

This configuration file is the base of every certificate we generate and most of its contents are the same for every new request, so I have built this handy Perl script that takes care of the configuration file generation for you:

#!/usr/bin/env perl
 
# Save this script to /ca/utils/make-config.pl
 
=head1 DESCRIPTION
 
Builds the OpenSSL configuration file to request a certificate for a domain.
 
=cut
 
use warnings;
use strict;
use autodie;
 
use File::Basename;
 
# Main entry point.
sub main {
    if (scalar(@ARGV) != 1) {
        die "The domain name of the certificate must be provided.\n";
    }
 
    # Get the domain name.
    my $domain = $ARGV[0];
 
    # Remind the user that this tool always generates wild card certs.
    if (substr($domain, 0, 1) eq '*') {
        die "This tool generates wildcard certificates. Remove *.\n";
    }
 
    # Make the folder and write the configuration file.
    my ($cldomain, $folder) = make_folder($domain);
    open (my $fh, '>', "$folder/openssl.conf");
    print $fh build_config($domain);
    close $fh;
 
    print "$cldomain\n";
}
 
# Creates the folder for the certificate and config, and returns its path.
sub make_folder {
    my ($domain) = @_;
    my $cld = $domain;
 
    # Get the path to the certificate folder and make it.
    my $folder = dirname(dirname(__FILE__)) . "/certs/$cld";
    mkdir $folder;
 
    return ($cld, $folder);
}
 
# Builds the configuration for the certificate.
sub build_config {
    my ($domain) = @_;
 
    return <<"CONFIG";
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = XX
ST = Your State
L = Your Neighbourhood
O = Your Totally Legit Company
OU = CA
CN = *.$domain
[v3_req]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = \@alt_names
[alt_names]
DNS.1 = $domain
DNS.2 = *.$domain
 
CONFIG
}
 
main();
 
__END__
 
=head1 AUTHOR
 
Nathan Campos <nathan@innoveworkshop.com>
 
=head1 COPYRIGHT
 
Copyright (c) 2024- Nathan Campos.
 
=cut

You should edit the contents of the configuration template just below the [req_distinguished_name] line to suit your environment. Be sure to be clever when populating these values in.

This script should be placed in the /ca/utils directory with the name make-config.pl so that the certificate issuing script can make use of it.

Issuing Certificates

Issuing a certificate using OpenSSL is a painful process and extremely easy to get wrong or simply get bored of typing a bunch of commands for something that you just want to get over with. Just like I did with the configuration file, here's a shell script that should automate the whole process for you:

#!/usr/local/bin/bash
 
# Ensure we stop on error.
set -e
 
# Ensure we have the right amount of command-line arguments.
if [[ $# -ne 2 ]]; then
    echo "usage: $0 <domain> <desc>" >&2
    exit 2
fi
 
# Create certificate directory and configuration file.
echo "Creating the configuration for the certificate request..."
CLDOMAIN=$(./utils/make-config.pl $1)
CERTDESC=$2
pushd "certs/$CLDOMAIN"
 
# Create the certificate request.
echo "Building private key and certificate request for $1 as $CLDOMAIN"
openssl genrsa -out "$CLDOMAIN.key" 2048
#openssl genrsa -des3 -out "$CLDOMAIN.key" 2048
openssl req -new -out request.csr -key "$CLDOMAIN.key" -config openssl.conf
 
# Create signed certificate.
echo "Signing certificate for 5 years..."
openssl x509 -req -in request.csr -CA ../../root/root.pem -CAkey ../../root/root.key \
    -CAcreateserial -out "$CLDOMAIN.crt" -days 1827 -sha256 \
    -extensions v3_req -extfile openssl.conf
 
# Packaging the certificate.
echo "Packaging the certificate in PKCS#12 format..."
openssl pkcs12 -export -out "$CLDOMAIN.p12" -inkey "$CLDOMAIN.key" -in "$CLDOMAIN.crt" -certfile "$CLDOMAIN.crt" -name "$CERTDESC"
 
# Extracting keys in SSH format.
echo "Extracting keys in SSH format..."
cat "$CLDOMAIN.key" | openssl rsa > id_rsa
openssl rsa -in id_rsa -pubout | ssh-keygen -f /dev/stdin -i -m PKCS8 > id_rsa.pub
 
# Check our certificate.
echo "Checking the generated certificate..."
openssl verify -CAfile ../../root/root.pem "$CLDOMAIN.crt"
openssl x509 -text -noout -in "$CLDOMAIN.crt" | head -14
echo "..."
openssl x509 -text -noout -in "$CLDOMAIN.crt" | grep DNS
 
popd

This script should issue certificates that are valid for 5 years and exports the public and private keys to every format that you may need, so the generated certificate can be used for web servers, SSH, and basically anything under the sun.

As can be inferred from the usage line in the script, it takes a domain and a description. The description is a bit of text that's associated with the certificate and can be viewed by visitors of your website. The domain argument should not contain a wildcard since the make-config.pl script should take care of this automatically for you.

Adding SSL to Your Servers

The next logical step is to ensure that your servers can actually serve content with your self-signed certificates.

Nginx Proxy Manager

I like my home servers to be as easy to configure and maintain as possible, not to be the most secure or follow enterprise-grade best practices, so I use the humble Nginx Proxy Manager as the reverse proxy for all my self-hosted applications.

To add your self-signed certificates to your NPM instance you'll need to download the domain.crt and domain.key files from the CA server.

Inside NPM you'll navigate to the SSL Certificates tab and click Add SSL Certificate and select Custom. Now all you have to do is fill in the form with the following:

Name: Whatever you want
Certificate Key: domain.key
Certificate: domain.crt

The last step is to associate the newly added SSL certificate to the domain it belongs to in the Proxy Hosts page by selecting the proxy host you want to edit and going to the SSL tab.

Getting Clients to Trust You

Having your own CA is all well and good, but you need to ensure that your clients trust your self-signed certificates, for this you'll have to add the root.cer Root Certificate to the list of trusted sources in your clients, and this process is extremely different from system to system, and even may require you to add the certificate to individual applications such as web browsers.

Chromium and ChromeOS

On Chromium-based browsers and ChromeOS, you can add your Root Certificate by navigating to the Certificate Manager located at chrome://certificate-manager/localcerts and in the Custom section, click on the Installed by you card.

In the next window, you should import the root.cer certificate file to the Trusted Certificates section. You should now be able to access your self-hosted services using the needlessly complex HTTPS.

Windows

Adding the generated root certificate under Windows involves opening the certlm.msc MMC Plug-In and right-clicking the Trusted Root Certification Authorities folder. In the context menu, you should select All Tasks > Import… and follow the wizard, eventually browsing to the root.cer certificate file and importing it. While in the wizard, ensure that the “Local Machine” option is selected as the Store Location, since this will ensure that the Root Certificate Authority is trusted system-wide.

Linux

First make sure you rename the root.cer file to root.crt, since it's required to have the crt extension for it to be picked up by the certificate manager. Then run the following commands as root to move the file to its appropriate place and reload the certificate store:

mkdir -p /usr/local/share/ca-certificates/homelab
cp root.crt /usr/local/share/ca-certificates/homelab/
update-ca-certificates

8-inch-chinese-laptop - [Fixing the keyboard]

nathanpc (nathanpc@undisclosed.example.com) — 2026-05-02T07:26:01+00:00

8" Chinese Laptop

A tiny 8“ Intel-based laptop from China that comes in a box with no description and can be bought for very cheap on Amazon and AliExpress. It's the pinnacle of modern computing, the successor to the VAIO P-series, the closest thing that we can have to a modern HPC.

Fixing the keyboard

Upon closer inspection you will notice that, due to it's tiny size, the keyboard layout is absolutely insane. Not only that, but some decisions regarding the button placement are absolutely maddening. To fix these issues under X11, the following can be added to the ~/.xmodmap file:

clear lock
keycode 66 = Tab
keycode 23 = Caps_Lock
keycode 22 = Delete
keycode 119 = BackSpace

If you're on Wayland, use Input Remapper to easily remap the keys listed above.

Fixing rotated console

Upon first boot you will notice that the boot logs are rotated to the vertical position, since the firmware of this laptop is most likely based on a tablet form-factor. This makes no sense, so change the following in the /etc/defaults/grub to make the boot console landscape:

GRUB_CMDLINE_LINUX="fbcon=rotate:1"

Don't forget to run update-grub for the changes to actually take effect.

start - [Computers]

nathanpc (nathanpc@undisclosed.example.com) — 2026-05-02T06:37:40+00:00

Nathan's Knowledge Base

Welcome to the place where all of the information gathered by Nathan Campos in his adventures through the depths of programming, software, and hardware ends up. Keep in mind that this is supposed to be a living knowledge base that is updated while he's researching a specific topic or working on a specific project.

Since he rarely has time to organize the topics into nice category pages, we recommend that, to get a taste of what this wiki has to offer, you should check out its sitemap.

Programming

Development Notes

Some programming notes that are filled with quirks and information gathered from projects.

Projects

Platforms

Programming Languages

A collection of best practices and resources specific to certain programming languages.

C++
Python

Some snippets that are useful for a variety of occasions:

Win32 Programming Snippets

Computers

A random assortment of computery things and references for me to later never consult.

Hardware

Hardware that's so special that it might as well be documented in case I may need to ever set it up again.

8" Chinese Laptop

Windows

Unix

Projects

Some of the projects that we are either currently working on have worked on in the past.

Ideas

Some of the ideas that we have for future projects that have yet to materialize.

Solar-powered Windows Server

One of the weirdest things I've done in my life, but it sure is fun to have your own website hosted in a bizarre, sustainable, and mostly self-sufficient manner. Here are some of the things I've documented along the way:

Self-hosted Certificate Authority

I guess every homelab owner has had the urge to become a CA and start issuing certificates for internal domains to use HTTPS and quiet down modern browsers.

Homelab Root CA using OpenSSL

msvc-porting - [SO_RCVTIMEO Timeout Argument]

nathanpc (nathanpc@undisclosed.example.com) — 2026-02-01T16:49:55+00:00

Porting to Microsoft Visual C++

Microsoft's compiler is filled with weird quirks and was literally not C99-compliant until 2019, which means it is quite difficult to port software meant for a more standards-compliant compiler to it. This page means to compile everything that we may want or need to know in order to port our code to this awful compiler.

Installing on Modern Systems

Since Visual Studio 6.0 is extremely old it's expected that you may encounter some roadblocks when trying to install it on more modern systems. If you're on Windows XP or earlier you don't have to do anything, simply install as usual and everything should work out-of-the-box.

If you are on Windows Vista or 7, as per this blog post, you should deselect the Tools | OLE/COM Object Viewer when installing, otherwise the installation will fail with an “RegCreateKey failed for \Interface\OLEViewerIViewerCLSID. Access is denied” error. Now if you are on Windows 8, 10 or later you should follow these instructions and at the time can only install Visual Basic 6, no Visual C++ 6 yet.

Unicode

The most dreaded aspect of programming for Windows… Having to use UTF-16 for Unicode is just awful, but sadly it's what was available at the time that Microsoft needed strings that could represent characters from all over the world. This horrible decision in the past means that today where we live in a more civilized, UTF-8 society, we have to be constantly performing conversions between MBCS and WCHAR when programming for Windows, this can be easily done with a couple of helper functions since Microsoft's API for this is absolutely awful:

/**
 * Converts a UTF-8 multibyte string into an UTF-16 wide-character string.
 * @warning This function allocates memory that must be free'd by you!
 *
 * @param str UTF-8 string to be converted.
 *
 * @return UTF-16 wide-character converted string or NULL if an error occurred.
 */
wchar_t *utf16_mbstowcs(const char *str) {
	wchar_t *wstr;
 
#ifdef _WIN32
	int nLen;
 
	/* Get required buffer size and allocate some memory for it. */
	wstr = NULL;
	nLen = MultiByteToWideChar(GL_CODEPAGE, 0, str, -1, NULL, 0);
	if (nLen == 0)
		goto failure;
	wstr = (wchar_t *)malloc(nLen * sizeof(wchar_t));
	if (wstr == NULL)
		return NULL;
 
	/* Perform the conversion. */
	nLen = MultiByteToWideChar(GL_CODEPAGE, 0, str, -1, wstr, nLen);
	if (nLen == 0) {
failure:
		MessageBox(NULL, _T("Failed to convert UTF-8 string to UTF-16."),
			_T("String Conversion Failure"), MB_ICONERROR | MB_OK);
		if (wstr)
			free(wstr);
 
		return NULL;
	}
#else
	size_t len;
 
	/* Allocate some memory for our converted string. */
	len = mbstowcs(NULL, str, 0) + 1;
	wstr = (wchar_t *)malloc(len * sizeof(wchar_t));
	if (wstr == NULL)
		return NULL;
 
	/* Perform the string conversion. */
	len = mbstowcs(wstr, str, len);
	if (len == (size_t)-1) {
		free(wstr);
		return NULL;
	}
#endif /* _WIN32 */
 
	return wstr;
}
 
/**
 * Converts a UTF-16 wide-character string into a UTF-8 multibyte string.
 * @warning This function allocates memory that must be free'd by you!
 *
 * @param wstr UTF-16 string to be converted.
 *
 * @return UTF-8 multibyte converted string or NULL if an error occurred.
 */
char *utf16_wcstombs(const wchar_t *wstr) {
	char *str;
 
#ifdef _WIN32
	int nLen;
 
	/* Get required buffer size and allocate some memory for it. */
	nLen = WideCharToMultiByte(GL_CODEPAGE, 0, wstr, -1, NULL, 0, NULL, NULL);
	if (nLen == 0)
		goto failure;
	str = (char *)malloc(nLen * sizeof(char));
	if (str == NULL)
		return NULL;
 
	/* Perform the conversion. */
	nLen = WideCharToMultiByte(GL_CODEPAGE, 0, wstr, -1, str, nLen, NULL,
							   NULL);
	if (nLen == 0) {
failure:
		MessageBox(NULL, _T("Failed to convert UTF-16 string to UTF-8."),
			_T("String Conversion Failure"), MB_ICONERROR | MB_OK);
 
		return NULL;
	}
#else
	size_t len;
 
	/* Allocate some memory for our converted string. */
	len = wcstombs(NULL, wstr, 0) + 1;
	str = (char *)malloc(len * sizeof(char));
	if (str == NULL)
		return NULL;
 
	/* Perform the string conversion. */
	len = wcstombs(str, wstr, len);
	if (len == (size_t)-1) {
		free(str);
		return NULL;
	}
#endif /* _WIN32 */
 
	return str;
}

Setting up a Project

Also by default if you're using an old compiler like Visual C++ 6 you need to manually set up the project to use Unicode and be compatible with more modern versions of Windows. In order to do this you simply have to follow the following steps:

Define the UNICODE and _UNICODE preprocessor symbols:
1. Select Project→Settings.
2. Click the C/C++ tab.
3. Add the following symbols to the Preprocessor definitions text box: UNICODE,_UNICODE
Choose the entry point for Unicode:
1. While still in the Project Settings dialog box, click the Link tab.
2. From the Category drop-down list, select Output.
3. In the Entry-point symbol field, type the appropriate entry point for Unicode:
  1. For a GUI Unicode application, the entry point is wWinMainCRTStartup
  2. For a console application, the entry point is wmainCRTStartup
4. Click OK.
Set the debugger to display Unicode strings:
1. Select Tools→Options.
2. Click the Debug tab.
3. Make sure the Display unicode strings check box is checked.
4. Click OK.

Special Folders

Sometimes we want to have access to “special folders” like the Desktop, My Documents, AppData, just to name a few. Most of these have environment variables associated with them, but expanding environment variables in a program seems very bad, thankfully Microsoft provides a couple of interesting functions for us to use in order to fetch these paths.

If we are targeting Windows 95+ (with the Internet Explorer upgrade) we must use the SHGetSpecialFolderPath function. If we are targeting Windows 2000+, or can install a redistributable, the recommendation is to use SHGetFolderLocation since the previous function call has been deprecated in this version. If we are targeting Windows Vista+ then we can use the even fancier SHGetKnownFolderPath.

Here are some examples of how to use these functions:

Shims

A collection of functions that may require a bit of shimming if you come from the saner world of POSIX:

basename equivalent is PathFindFileName (requires linking against shlwapi.lib)
snprintf equivalent is _snprintf (can't count the number of bytes required for allocation)

Multithreading

As usual, when it comes to Windows, multithreading is not as simple or easy as under a POSIX system. Microsoft made sure to implement their multithreading API in multiple ways, one you can use the CRT, the other one you can't. In any case, just ignore everything and follow these instructions.

Mutexes

One of the most used capabilities when dealing with parallel operations are mutexes, they allow us to ensure that resources that are shared between multiple processes can be safely guarded against race conditions. Windows has the concept of mutexes, but they are extremely bad in terms of performance, although they have the “benefit” of working across processes. Usually what you want to use is the CRITICAL_SECTION and its associated functions, these resemble much of the pthreads API, although with that characteristic Win32 API flavor, and are very lightweight.

Windows CE

As with everything in Win32 land the Windows CE implementation of multithreading suffered a lot, especially when dealing with PocketPCs and non-Handheld PCs. We can understand that this was done due to the lack of resources of such devices, but still. Here are some online resources on the subject:

Additional Resources

Here are some resources that were used as references to write this section. These will most likely go into greater detail on the subject and give you a greater understanding of the API instead of just providing a reference.

MSDN: Multithreading with C and Win32
MSDN: Sample Multithread C Program
Why Pthreads are better than Win32 threads
Windows threading: _beginthread vs _beginthreadex vs CreateThread
Pthreads on Microsoft Windows (probably the best resource on the subject of multithreading under Windows)

Windows Server 2003 Platform SDK

If you want to have proper compatibility with every single 32-bit Intel-based Windows release ever made since Windows 95 you are required to use Microsoft's Visual C++ 6, which is a whole can of worms, but it is what you need to do in order to have full backward compatibility. Something that alleviates a bit of the pain of using this toolchain is the Windows Server 2003 Platform SDK, which can be downloaded using the following instructions.

You may need to install each SDK individually from the setup folder instead of running setup.exe, since this may cause issues if you're running a more modern version of Internet Explorer.

Sockets and Network Programming

Porting an application from the standard in UNIX land Berkley sockets to WinSock might be a bit of a nightmare, depending on the architecture of the project. If your application was developed with portability in mind, even going as far as wrapping every single socket function, you can more easily port your code to Winsock, but you may still run into problems.

Missing Functions and Types

As soon as we try to compile any piece of code that was made for a more standardized sockets implementation, one thing will become extremely apparent: You'll be missing a lot of stuff. In order to get a saner environment for socket programming under Windows, it's required to install the Windows Server 2003 Platform SDK.

Headers

According to Microsoft's documentation, you should not include windows.h when you are using Winsock2 since it tries to include the old Winsock 1.1 stuff, which generates loads of conflicts with the redefinitions in the Winsock2 headers. In order to get around this, since your application or libraries might be including windows.h you should define globally (in the project's settings) the WIN32_LEAN_AND_MEAN preprocessor definition.

A usual set of includes for Winsock2 should look like this:

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <winsock2.h>
#include <ws2tcpip.h>
#include <wspiapi.h>

setsockopt() Parameters

Another difference from other platforms is that the setsockopt() function takes its optval parameter as a const char * instead of the more common void *, requiring your parameters to be redefined just for Windows.

Error Handling

Whenever you must catch errors from resulting socket interactions, where under a POSIX system you simply check the contents of the errno variable after a function returns -1, under Winsock2 you must instead check if the function returned SOCKET_ERROR, and then call and store the return value of WSAGetLastError() and compare against Microsoft's WSA-prefixed error code definitions. This is all described in Microsoft's Return Values on Function Failure MSDN article. For more in-depth information on the subject of how to deal with Winsock2 errors, read MSDN articles Handling Winsock Errors and Error Codes - errno, h_errno and WSAGetLastError.

Another interesting quirk of Winsock error codes seems to be the fact that it doesn't have a EAGAIN definition, and that for situations where EAGAIN would've been used it's suggested to instead use WSAEWOULDBLOCK.

SO_RCVTIMEO Timeout Argument

Under all UNIX variants, the SO_RCVTIMEO option for setsockopt() receives a pointer to a struct timeval. This is not the case on Windows, and it does create a whole bunch of weird bugs, since the code technically compiles and may even run depending on the value pointed by the structure in question. Every single time I'm porting a socket application from POSIX to WinSock2, I want to pull my hair out whenever I encounter this bug.

Under WinSock2, the SO_RCVTIMEO option requires the timeout value to be passed as a ''DWORD'', with the number of milliseconds to timeout, casted to a const char *.

Miscellaneous

Beware that whenever you're dealing with in_addr_t, it isn't defined and you must instead define it as unsigned long.

Yet another interesting quirk was discovered by us, where if you have a large TCP packet that gets split at the source and must be reassembled at the client, a call to recv() will fail with a WSAEFAULT even though the buffer is large enough to hold the received information, requiring us to always set the MSG_WAITALL flag. This hasn't been thoroughly tested, and we were unable to pinpoint with great accuracy the real cause of the issue, but at least for now, we've attributed it to the partial packet thing. Keep in mind that older versions of the compiler don't have this flag available, so you'll need to implement this functionality manually by looping through the recv() call until all expected bytes have been received.

Linking

At the end of your journey, if all the compilation errors have gone away, be sure to link against the ws2_32.lib library to avoid the dreaded linker errors.

Initialization and Cleanup

Most importantly, after all this, make sure to add the following code to your main() application entry point:

int main(int argc, char **argv) {
#ifdef _WIN32
	WORD wVersionRequested;
	WSADATA wsaData;
	int ret;
#endif /* _WIN32 */
 
#ifdef _WIN32
	/* Initialize the Winsock stuff. */
	wVersionRequested = MAKEWORD(2, 2);
	if ((ret = WSAStartup(wVersionRequested, &wsaData)) != 0) {
		printf("WSAStartup failed with error %d\n", ret);
		return 1;
	}
#endif /* _WIN32 */
 
	/* Perform everything in your application. */
 
	/**
	 * If your application exits prematurely, make sure that WSACleanup() gets
	 * called beforehand.
	 */
 
#ifdef _WIN32
	/* Clean up the Winsock stuff. */
	WSACleanup();
#endif /* _WIN32 */
 
	return ret;
}

References

Here are the references that were most likely consulted in order to find all of these issues in real-world codebases and catalog them here:

Getting a Console

You'll quickly realize that if your target is a GUI Win32 application you won't have access to a console to print stuff out and quickly debug things. This is due to the way that Windows is architected and its subsystems work. In order to get a console you'll either need to allocate one and redirect every stream to that one or create an EDIT control anywhere on your application, create a pipe, redirect the streams to your pipe, then read from it and append the text to your EDIT field. Either way here are some resources to get you started:

Finding Memory Leaks

Finding memory leaks is always a though thing. Visual Studio has some tools which can be extremely useful when trying to find leaks, but you can also do it programmatically on every debug run of your application:

#ifdef DEBUG
#include <crtdbg.h>
#endif // DEBUG
 
int _tmain(int argc, TCHAR* argv[]) {
#ifdef DEBUG
	// Initialize memory leak detection.
	_CrtMemState snapBegin;
	_CrtMemState snapEnd;
	_CrtMemState snapDiff;
	_CrtMemCheckpoint(&snapBegin);
#endif // DEBUG
 
	// TODO: Do stuff here...
 
#ifdef DEBUG
	// Detect memory leaks.
	_CrtMemCheckpoint(&snapEnd);
	if (_CrtMemDifference(&snapDiff, &snapBegin, &snapEnd)) {
		OutputDebugString(_T("MEMORY LEAKS DETECTED\r\n"));
		OutputDebugString(L"----------- _CrtMemDumpStatistics ---------\r\n");
		_CrtMemDumpStatistics(&snapDiff);
		OutputDebugString(L"----------- _CrtMemDumpAllObjectsSince ---------\r\n");
		_CrtMemDumpAllObjectsSince(&snapBegin);
		OutputDebugString(L"----------- _CrtDumpMemoryLeaks ---------\r\n");
		_CrtDumpMemoryLeaks();
	} else {
		OutputDebugString(_T("No memory leaks detected. Congratulations!\r\n"));
	}
#endif // DEBUG
 
	return 0;
}

Guidelines

When developing applications for a given operating system it's always good to know about its standards, defaults, and most importantly its interface guidelines in order to make your application look “native”. In order to get a comprehensive look at Microsoft's recommendations of what Windows applications should look and feel you must check out their Layout Guidelines, most importantly since Visual Studio provides no help in this area, you should check out their Recommended sizing and spacing section which describes in detail how to size and space controls in Win32 applications.

It's not only important to follow Microsoft's guidelines for the UI aspects of the application, but also for the developer side of the application, using naming conventions that are accepted by other Windows developers. Here are a collection of articles related to this topic:

_MSC_VER

Since Visual Studio is quite an old application with lots of versions and many changes along the years, one of the most important aspects that you need to know in order to develop a project that can be compiled in multiple versions of this platform is the _MSC_VER constant that's defined for every version of the application suite. A comprehensive list of these definitions can be found here, but here are some of the most important ones for us:

Visual Studio 2012: 1700
Visual Studio 2005: 1400
Visual C++ 6.0: 1200

Issues with stdint.h (Error C2733)

If you're seeing things like error C2733: second C linkage of overloaded function 'wmemchr' not allowed when trying to compile an application under Visual C++ 6 using the official stdint.h shim it means that you haven't paid attention to the comments in the file itself:

// For Visual Studio 6 in C++ mode and for many Visual Studio versions when
// compiling for ARM we should wrap <wchar.h> include with 'extern "C++" {}'
// or compiler give many errors like this:
//   error C2733: second C linkage of overloaded function 'wmemchr' not allowed
#ifdef __cplusplus
extern "C" {
#endif
#  include <wchar.h>
#ifdef __cplusplus
}
#endif

Changing from extern “C” to extern “C++” should fix all your issues.

Registry Functions

It's extremely important to note that, only under eMbedded Visual C++ 3, all registry-related functions such as RegOpenKeyEx and RegQueryValueEx return ERROR_INVALID_PARAMETER instead of ERROR_INVALID_PARAMETER when a key hasn't yet been created. Also the lpdwDisposition parameter of RegCreateKeyEx is mandatory under the same compiler, not including it will result in an Access Violation error.

Image Lists

ImageLists are a crucial component from the CommonControls library. They allow us to add icons to our applications in a much easier manner and lets us associate indexes with them, but they do have some gotchas that are nice to know in order to take full advantage of them, specially when developing with multiple versions of Windows in mind.

System Metrics

Most of the time when building ImageLists we want to use them for standardized icons throughout our application, these usually use the small and large metrics defined by the operating system. In order to get these we can use the GetDeviceMetrics() function and ask for the SM_CXSMICON and SM_CYSMICON for small icons and SM_CXICON and SM_CYICON for large icons. The values returned by the function can be directly used to create an ImageList with ImageList_Create(). To learn more about these metrics consult the About icons page of the Microsoft documentation.

LoadIcon in Windows CE

When loading icons under Windows CE it's very important to note that the LoadIcon() function only loads icons of size SM_CXICON, if you use these in other size contexts the icon will simply be clipped. As the documentation states:

LoadIcon can only load an icon whose size conforms to the SM_CXICON and SM_CYICON system metric values. Use the LoadImage function to load icons of other sizes.

Given this explanation we can substitute our uses of LoadIcon() with the following to get a different resolution:

(HICON)LoadImage(m_hInst, MAKEINTRESOURCE(IDI_ICONRES), IMAGE_ICON, SM_CXSMICON, SM_CXSMICON, 0);

The issue now is that we need to keep the HICON handles in a list somewhere so that we can call DestroyIcon() on them when its time to dispose of them. This was done automatically when we used LoadIcon().

Bit Depth

Throughout the many versions of Windows, specially in the XP and pre-XP days, it was common for computers to not be capable of rendering in 24-bit or 32-bit colors, so whenever we are creating ImageLists we have to take this into consideration. One easy cop out from this situation is instead of passing a specific bit depth for the ImageList_Create() function we pass the ILC_COLORDDB flag. There was this interesting discussion on when to use this flag.

C++ STL for eMbedded Visual C++

If you think you could have a sane standard library for C++ under Microsoft's eMbedded Visual C++ you are completely wrong. For some reason they shipped it with one that was missing some bits and in some cases it was completely different from the published standard back in the day. You can get a much better and standards-compliant STL (based on SGI's work) from STL for eMbedded Visual C++. Also you should read the additional information on limitations and usage to learn more about it.

To install this we just have to decompress it either in the project's folder or somewhere else, go to Tools/Options…/Directories and add the folder where it was decompressed to the includes path for all targets.

change-uid - [Linux]

nathanpc (nathanpc@undisclosed.example.com) — 2025-10-11T13:48:27+00:00

Changing a User's UID

Having consistency of UID and GID on UNIX is extremely important if you have multiple servers and clients that you want to maintain a consistent identity on. Be it for NFS, Git, or any other administrative task. Having the same IDs for your users across different computers really helps.

Sadly, almost no OS install utilities allow you to specify the UID/GID of the default user that's created during setup, which means we have to do this afterward, thus this tutorial exists to give me and everyone a clear path to UID consistency.

Linux

I almost always run Debian on my Linux machines, thus I can't say this is the right way of doing it in other distros, I can't see why it wouldn't apply to others as well.

# Ensure no processes are running from the old user.
pkill -U $OLD_UID
 
# Change UID/GID using usermod.
usermod -u $NEW_UID -g $NEW_GID $USERNAME
 
# Fix file permissions to use the new UID.
find / -uid $OLD_UID -exec chown -h $NEW_UID {} +
find / -gid $OLD_UID -exec chgrp -h $NEW_GID {} +

If you're using a Raspberry Pi with its graphical desktop environment, you should use raspi-config to disable booting straight to X.

softether-securenat-prefs.png - created

nathanpc (nathanpc@undisclosed.example.com) — 2025-08-17T12:56:43+00:00

iis7-php5-handler-config.png - created

nathanpc (nathanpc@undisclosed.example.com) — 2025-07-24T10:45:40+00:00

nstableview-plus-minus-toolbar.png - created

nathanpc (nathanpc@undisclosed.example.com) — 2024-07-08T18:42:08+00:00