Question about the requirements for defining UNICODE and _UNICODE on Win32

[slabko]

I’m a bit confused that UNICODE is defined by Poco::Foundation publicly, with no way to turn it off.

As a result, every library that links against Poco::Foundation is effectively forced to have UNICODE and _UNICODE defined. While using UNICODE is generally recommended for Win32 projects, this isn’t always the case, there are situations where developers prefer to build applications in ANSI mode.

I also noticed that Poco builds fine even when UNICODE and _UNICODE are not enabled.

So my questions are:

1. Is it a strict requirement that Poco be built with UNICODE and _UNICODE on Win32?
2. Is it a strict requirement that client projects have these definitions?

For reference, this is the line where UNICODE is defined:
https://github.com/pocoproject/poco/blob/poco-1.14.2-release/Foundation/CMakeLists.txt#L140

[andrewauclair]

I don't know the answer. I think I would like to know as well. But, if you're looking for a workaround, this is what I do to remove UNICODE and _UNICODE from the Poco targets in my CMakeLists.txt:

function(remove_unicode)
	message(STATUS "remove UNICODE from " ${ARGV0})
	get_target_property(defs ${ARGV0} COMPILE_DEFINITIONS)
	list(FILTER defs EXCLUDE REGEX [[^UNICODE$]])
	list(FILTER defs EXCLUDE REGEX [[^_UNICODE$]])
	set_property(TARGET ${ARGV0} PROPERTY COMPILE_DEFINITIONS ${defs})
	
	get_target_property(defs ${ARGV0} INTERFACE_COMPILE_DEFINITIONS)
	list(FILTER defs EXCLUDE REGEX [[^UNICODE$]])
	list(FILTER defs EXCLUDE REGEX [[^_UNICODE$]])
	set_property(TARGET ${ARGV0} PROPERTY INTERFACE_COMPILE_DEFINITIONS ${defs})
	
	get_target_property(defs ${ARGV0} COMPILE_DEFINITIONS_DEBUG)
	list(FILTER defs EXCLUDE REGEX [[^UNICODE$]])
	list(FILTER defs EXCLUDE REGEX [[^_UNICODE$]])
	set_property(TARGET ${ARGV0} PROPERTY COMPILE_DEFINITIONS_DEBUG ${defs})
	
	get_target_property(defs ${ARGV0} COMPILE_DEFINITIONS_RELEASE)
	list(FILTER defs EXCLUDE REGEX [[^UNICODE$]])
	list(FILTER defs EXCLUDE REGEX [[^_UNICODE$]])
	set_property(TARGET ${ARGV0} PROPERTY COMPILE_DEFINITIONS_RELEASE ${defs})
endfunction()

if (MSVC)
	remove_unicode(Util)
	remove_unicode(Foundation)
	remove_unicode(Data)
	remove_unicode(DataSQLite)
	remove_unicode(XML)
	remove_unicode(JSON)
	remove_unicode(Net)
endif()

[matejk]

Analysis

Good questions! After analyzing the POCO codebase, here's what I found:

POCO's Internal Unicode Handling

POCO explicitly uses the wide-character (W) Windows APIs throughout its Windows implementations:

• CreateFileW(), FindFirstFileW(), GetFileAttributesW(), GetModuleFileNameW(), etc.
• Internally uses UnicodeConverter::toUTF16() to convert UTF-8 strings to UTF-16 for Windows API calls

POCO does not use:

• TCHAR or the TEXT() / _T() macros
• Generic function names like CreateFile (which resolve to CreateFileA or CreateFileW based on UNICODE)
• Any #ifdef UNICODE conditional compilation in the core Foundation code

Answers to Your Questions

1. Is it a strict requirement that POCO be built with UNICODE and _UNICODE?

No. Since POCO explicitly calls *W() functions rather than relying on TCHAR macros, the UNICODE definition doesn't affect POCO's own code. POCO will use wide-character APIs regardless.

2. Is it a strict requirement that client projects have these definitions?

No - for the same reason. POCO's public API uses std::string (UTF-8) and handles all Windows API calls internally with explicit *W() functions.

Why Is It Defined?

The UNICODE and _UNICODE definitions were added in commit 8a70ab8a1 (2018) as part of a CMake modernization. This was likely added as a "best practice" for Windows projects, but it's not technically required for POCO functionality.

Potential Change

The UNICODE and _UNICODE definitions could technically be changed from PUBLIC to PRIVATE (or removed entirely) without breaking POCO. However, this might affect:

1. Dependent code that inadvertently relies on these definitions being inherited from POCO
2. Windows resource scripts (.rc files) that might use TCHAR in string literals

If you'd like to see this changed, feel free to open a feature request. The workaround @andrewauclair provided is a reasonable solution in the meantime.