putty-source/windows/utils/platform_get_x_display.c

/*
 * Implementation of platform_get_x_display for Windows, common to all
 * tools.
 */

#include "putty.h"
#include "ssh.h"

char *platform_get_x_display(void)
{
    /* We may as well check for DISPLAY in case it's useful. */
    return dupstr(getenv("DISPLAY"));
}
New library-style 'utils' subdirectories. Now that the new CMake build system is encouraging us to lay out the code like a set of libraries, it seems like a good idea to make them look more _like_ libraries, by putting things into separate modules as far as possible. This fixes several previous annoyances in which you had to link against some object in order to get a function you needed, but that object also contained other functions you didn't need which included link-time symbol references you didn't want to have to deal with. The usual offender was subsidiary supporting programs including misc.c for some innocuous function and then finding they had to deal with the requirements of buildinfo(). This big reorganisation introduces three new subdirectories called 'utils', one at the top level and one in each platform subdir. In each case, the directory contains basically the same files that were previously placed in the 'utils' build-time library, except that the ones that were extremely miscellaneous (misc.c, utils.c, uxmisc.c, winmisc.c, winmiscs.c, winutils.c) have been split up into much smaller pieces. 2021-04-17 15:22:20 +01:00			`/*`
			`* Implementation of platform_get_x_display for Windows, common to all`
			`* tools.`
			`*/`

			`#include "putty.h"`
Add some missing #includes. My experimental build with clang-cl at -Wall did show up a few things that are safe enough to fix right now. One was this list of missing includes, which was causing a lot of -Wmissing-prototype warnings, and is a real risk because it means the declarations in headers weren't being type-checked against the actual function definitions. Happily, no actual mismatches. 2022-09-03 11:43:46 +01:00			`#include "ssh.h"`
New library-style 'utils' subdirectories. Now that the new CMake build system is encouraging us to lay out the code like a set of libraries, it seems like a good idea to make them look more _like_ libraries, by putting things into separate modules as far as possible. This fixes several previous annoyances in which you had to link against some object in order to get a function you needed, but that object also contained other functions you didn't need which included link-time symbol references you didn't want to have to deal with. The usual offender was subsidiary supporting programs including misc.c for some innocuous function and then finding they had to deal with the requirements of buildinfo(). This big reorganisation introduces three new subdirectories called 'utils', one at the top level and one in each platform subdir. In each case, the directory contains basically the same files that were previously placed in the 'utils' build-time library, except that the ones that were extremely miscellaneous (misc.c, utils.c, uxmisc.c, winmisc.c, winmiscs.c, winutils.c) have been split up into much smaller pieces. 2021-04-17 15:22:20 +01:00
			`char *platform_get_x_display(void)`
			`{`
			`/* We may as well check for DISPLAY in case it's useful. */`
			`return dupstr(getenv("DISPLAY"));`
			`}`