Nathan's KB - devnotes

groundlift

Anonymous (anonymous@undisclosed.example.com) — 2023-05-13T07:58:28+00:00

GroundLift

The development notes are to be used for reference while developing GroundLift. Keep in mind that when this page was created the library and command line application were almost finished. More specifically we were in commit dda76fe. For reference, the last commit before the Windows port was commit 35c5c88.

Porting to Apple Systems

Multicast Entitlement

Apparently in order to send any sort of general broadcast or multicast packet outside of very strict mDNS (or Bonjour as Apple likes to call it) rules you are required to request an entitlement from Apple, namely com.apple.developer.networking.multicast. This will only be required when porting our library to more strict platforms like iOS or sandboxed macOS, but we need to perform some tests in order to ensure that Xcode won't block us by default even when not targeting the App Store for macOS deployments.

The worst part about all of this is that the entitlement is required even for development! This is the dumbest move ever, but let's ignore it for now. Maybe, since Apple apparently takes its sweet time processing requests, we could wrap the network discovery code behind a preprocessor flag and ensure that we have an alternative mechanism for doing “manual discovery” (i.e. something like asking your buddy to tell you their IP).

If we ever need more information on the subject, the great eskimo has blessed us with a summary of everything we may want to know about the entitlement.

All of this is part of Apple's Local Network Privacy initiative, which is just some bullshit to restrict things in the name of privacy.

If we still want to test the discovery code before or during the entitlement requisition process the only option we have available is to use a real iOS device running iOS <= 14.5.

Porting to Older Systems

getXbyY Functions

Take a look into these deprecated functions as maybe a portability path for functionality like getaddrinfo(3) on much older, pre-IPv6, systems. One quick example of such a function would be gethostbyname(3).

According to Microsoft:

Additional functions have been added over time to enhance Winsock for use by developers. For example, new name service functions (getaddrinfo and getnameinfo, for example) were added that support both IPv6 and IPv4 on Windows XP and later. Some of the older IPv4-only name service functions (the getXbyY class of functions, for example) have been deprecated.

Peer Discovery Service

Currently, we have implemented our peer discovery mechanism by sending a simple UDP broadcast message to the generic broadcast address (255.255.255.255). This means that the OS is choosing one interface to send this broadcast message through, we have no control over which network interface is chosen, and we desperately need to start working on changing this since we've already started bumping into the OS choosing the wrong interface to send the message through when porting the software to Windows.

Since our Windows machines usually have Hyper-V or some other type of virtualization software that creates virtual network interfaces installed, the OS was choosing the wrong interface to send the broadcast message through (either this or Windows has some issue with using the generic broadcast address). This was verified by hardcoding the local network's broadcast address in the peer discovery code, which immediately sprung back to life and started working.

We must implement a way of, on modern platforms, to iterate over the network interfaces available, figure out the broadcast address of each one, send the broadcasts on each network, and combine the replies into a single pool. We must also provide a fallback mechanism for older systems to still just broadcast to the generic address since some of the functions to support multiple network interfaces might not be available on such older or constrained systems.

Whenever we go down the path of iterating over multiple network interfaces we must take special consideration of the fact that we may end up in a weird situation where two network interfaces might be connected to the same physical network (i.e. Ethernet and Wi-Fi are both connected on the same home network) and we'll be duplicating the peers discovered. We still need to research how we can address this issue and check if both interfaces are connected to the same physical network.

Encoding Mechanisms

Instead of having to tell your friend that wants to share some data with you your entire IP address, which a lot of people will not do and is extremely cumbersome, we could encode this data in such a way that it is small enough for people to be comfortable speaking it out loud. Look into Base36 and Base64 as possible ways to encode the binary representation of the IP address.

Windows Porting

General topics of this section have been moved to devnotes:msvc-porting.

Since we already have a lot of experience developing Win32 applications, our first GUI application will be created for it. Here we'll catalog a bunch of resources required to finish the Windows version of our application.

Tray Icon

Our application will live most of its life as a simple tray icon (also known as the system tray or notification area), guaranteeing that the server is running and providing quick access to some of the application's functionality. Here are some resources to help us implement this feature:

macos

Anonymous (anonymous@undisclosed.example.com) — 2024-07-14T13:56:12+00:00

Mac OS X Development Notes

Recently I've finally started learning how to develop applications for Mac OS X, or macOS as Apple likes to call it these days. I want to get a good idea of how Cocoa applications actually work, so I'm learning Objective-C before diving into Swift. I'm basing my learning heavily on the book Cocoa Programming for Mac OS X.

Common Design Features

As the years passed, many common design patterns in OS X applications started emerging, this should provide resources on how to use them.

NSTableView with +/- buttons

Many applications in OS X have an NSTableView with +/- buttons in a toolbar at its bottom. This provides a sleek design solution to a problem: How to I provide users a way to add new items to a list? With this approach you just let the user click the + button and a new entry is created and ready to be edited.

The way to create this element is by utilizing the NSSegmentedControl component. A great tutorial on how to do this is available on StackOverflow: NSTableView with +/- buttons like in System Preferences using only Interface Builder.

References

Here is a collection of great resources on old Mac OS X programming:

Developing for Tiger and Leopard / PowerPC (a devlog)

msvc-porting

Anonymous (anonymous@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.

netaddr

Anonymous (anonymous@undisclosed.example.com) — 2023-06-05T09:46:35+00:00

Network Addressing Programatically

Network addresses have always been a massive pain in the ass for programmers since the dawn of time, but it doesn't necessarily have to be that way. Here you'll find some interesting tips and tricks to get you up to speed on how to deal with them like a pro!

Getting Network Interface Information

It's very common to have to get information on the network interfaces of a device in order to get more information about the network or just to be capable of talking to all devices on all the networks that you may have available. This can be a bit tricky and might involve a lot of platform-dependent code since most of the functions surrounding network interfaces are not portable and are deeply tied to the operating system.

According to this very comprehensive piece of code there are four ways of fetching the network interfaces of a device, two involve system functions and the other two involve ioctls:

Broadcast Address

The broadcast address of a network is essential when dealing with device discovery (unless you can use proper multicast), you can get away with using INADDR_BROADCAST, but that's very hacky and not recommended for devices that already have an IP address on the network. The correct way to broadcast a packet on a network is to get a list of all the network interfaces of the device and then get the broadcast address of each one of them.

Here are a couple of ways that you can get the broadcast address of interfaces on various platforms:

Using ioctls

This interesting bit of code shows how to use ioctls under most UNIX operating systems to get a list of the interfaces and their respective broadcast addresses:

getbroadaddr.c

#include <net/if.h>
#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <unistd.h>
 
static void show_interface_broadaddr(int fd, const char *name) {
	struct ifreq ifreq;
	char host[128];
	memset(&ifreq, 0, sizeof ifreq);
	strncpy(ifreq.ifr_name, name, IFNAMSIZ);
 
	if (ioctl(fd, SIOCGIFBRDADDR, &ifreq) != 0) {
		fprintf(stderr, "Could not find interface named %s\n", name);
		return; /* ignore */
	}
 
	getnameinfo(&ifreq.ifr_broadaddr, sizeof(ifreq.ifr_broadaddr), host, sizeof(host), 0, 0, NI_NUMERICHOST);
	printf("%-24s%s\n", name, host);
}
 
static void list_interfaces(int fd) {
	struct ifreq *ifreq;
	struct ifconf ifconf;
	char buf[16384];
	unsigned i;
	size_t len;
 
	ifconf.ifc_len = sizeof(buf);
	ifconf.ifc_buf = buf;
 
	if (ioctl(fd, SIOCGIFCONF, &ifconf) != 0) {
		perror("ioctl(SIOCGIFCONF)");
		exit(EXIT_FAILURE);
	}
 
	printf("Listing all interfaces:\n");
	ifreq = ifconf.ifc_req;
	i = 0;
	while (i < ifconf.ifc_len) {
#ifndef linux
		len = IFNAMSIZ + ifreq->ifr_addr.sa_len;
#else
		len = sizeof(struct ifreq);
#endif
 
		printf("%s\n", ifreq->ifr_name);
 
		ifreq = (struct ifreq *)((char *)ifreq + len);
		i += len;
	}
}
 
int main(int argc, char **argv) {
	int sock;
 
	sock = socket(AF_INET, SOCK_DGRAM, 0);
	if (sock < 0) {
		perror("socket()");
		exit(EXIT_FAILURE);
	}
 
	if (argc == 1) {
		list_interfaces(sock);
	} else if (argc == 2) {
		show_interface_broadaddr(sock, argv[1]);
	}
 
	close(sock);
 
	return EXIT_SUCCESS;
}

shortcircuit

Anonymous (anonymous@undisclosed.example.com) — 2024-07-14T14:03:14+00:00

Shortcircuit

The development notes are to be used for reference while developing Shortcircuit.

Concept and Idea

Create a simple small toolbar icon utility that’s simply a shortcut to the “Connect to Server…” option in macOS so that it's simple to automatically mount our network shares on macOS.

It's also very important, since it's a common feature on Windows and many organizations would love this, add the ability to automatically mount certain drives when the system boots.

Resources

Some resources gathered while researching what would be needed for the macOS application:

Mounting network shares programatically

Whenever you search online for ways to mount a network share programatically on macOS you'll inevitably find the NetFSMountURLSync and NetFSMountURLAsync functions that apparently are available if you include the NetFS.framework to your project. Apple really wants to hide this framework from the world, since its documentation isn't available anywhere online, and even when using the full offline docsets on Xcode 5.1 I only get changelogs and not the proper documentation.

From what I was able to gather the NetFS.framework was introduced in OS X 10.6, and according to the chapter “NetFS Changes” in the “OS X 10.8 API Diffs” collection, the NetFSMountURLSync and NetFSMountURLAsync functions were only introduced in OS X 10.8.

This presents a problem, since our application is supposed to work all the way down to the OS X 10.4 release on PowerPC (to at least target the Powerbook G4s), these APIs won't be available to us, so we can use them in builds for newer operating systems, but we need to ensure that we have an alternative for older platforms. It's important to have both approaches since using the newer APIs will most likely give us a bit more compatibility with ultra modern versions of the OS.

mount(2)

POSIX will always come to our rescue! We can use the low-level mount(2) function (and its umount(2) counterpart) to perform the same operation. In fact this will allow us an even greater level of flexibility since we can let the user specify custom mount options. According to this post the data argument is simply a string with the mount options as used in the -o parameter when using the command line interface to mount.

Given the flexibility afforded with this approach, we should reconsider the idea of using this only for older systems. I'm sure many users will find it useful to have access to these advanced options. We may even be able to create a nice UI for setting some of the more common options.

Help

I've been stuck trying to implement this for way too long. Apparently instead of implementing mount(2) in a sane way we are supposed to pass complex structures and the mount point should be part of that structure, not a parameter in the function call. I've asked about this on StackOverflow and on Apple's Developer Forums. Let's hope someone is able to help me out.

In the mean time I've been able to find these two questions about using mount(2) and its syntax, although they are both trying to mount an HFS file system:

I've also located an interesting structure in under /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/nfs/nfs.h:

/*
 * Old-style arguments to mount NFS
 */
#define NFS_ARGSVERSION 6               /* change when nfs_args changes */
struct nfs_args {
        int             version;        /* args structure version number */
        struct sockaddr *addr;          /* file server address */
        uint8_t         addrlen;        /* length of address */
        int             sotype;         /* Socket type */
        int             proto;          /* and Protocol */
        u_char          *fh;            /* File handle to be mounted */
        int             fhsize;         /* Size, in bytes, of fh */
        int             flags;          /* flags */
        int             wsize;          /* write size in bytes */
        int             rsize;          /* read size in bytes */
        int             readdirsize;    /* readdir size in bytes */
        int             timeo;          /* initial timeout in .1 secs */
        int             retrans;        /* times to retry send */
        int             maxgrouplist;   /* Max. size of group list */
        int             readahead;      /* # of blocks to readahead */
        int             leaseterm;      /* obsolete: Term (sec) of lease */
        int             deadthresh;     /* obsolete: Retrans threshold */
        char            *hostname;      /* server's name */
        /* NFS_ARGSVERSION 3 ends here */
        int             acregmin;       /* reg file min attr cache timeout */
        int             acregmax;       /* reg file max attr cache timeout */
        int             acdirmin;       /* dir min attr cache timeout */
        int             acdirmax;       /* dir max attr cache timeout */
        /* NFS_ARGSVERSION 4 ends here */
        uint32_t        auth;           /* security mechanism flavor */
        /* NFS_ARGSVERSION 5 ends here */
        uint32_t        deadtimeout;    /* secs until unresponsive mount considered dead */
};

Although I haven't been able to use this in a way that works.

Windows version

It would be interesting to also offer a Windows version to help everyone that wants to simply map a network share to a drive letter without messing with Windows' super complicated and buggy wizards. It will also make mounting NFS shares a breeze for the first time.

Simply create the same UI in a .NET application, since NFS is only supported on Windows 8+, that hides itself on the system tray and allows the same functionality as its macOS counterpart. If we are interested in pain we can always write the application using the Win32 API and target all the way down to Windows 95 and only support NFS mounts on supporting OSes.

Resources

Some research on what would be needed to pull this off on Windows:

unity

Anonymous (anonymous@undisclosed.example.com) — 2023-05-20T20:02:44+00:00

Unity Game Engine

Input System

https://gamedevbeginner.com/input-in-unity-made-easy-complete-guide-to-the-new-system/

VR

https://forum.unity.com/threads/oculus-quest-how-to-detect-a-b-x-y-button-presses.1108232/

https://developer.oculus.com/documentation/unity/unity-ovrinput/