search

CyberBoardPBEM / cbwindows

CyberBoard Play by EMail system for Windows
MIT License
6 stars 4 forks source link

_UNICODE compilation #108

Open wsu-cb opened 1 year ago

wsu-cb commented 1 year ago

For a variety of reasons, I think it is time to convert CB to compile with _UNICODE enabled.

As stated in https://github.com/CyberBoardPBEM/cbwindows/pull/71#discussion_r725491054, for portability/consistency to Linux/Mac, we probably want to use std::string, but assume utf-8 content in it. However, we will need to use utf-8/wchar_t conversion helpers to make calls to Windows Unicode functions. wxWidgets provides extensive helpers, but wxWidgets effectively requires _UNICODE, and I would prefer not to try to simultaneously add wxWidgets and enable _UNICODE, so I think we will need to provide our own (temporary?) helpers.

Note that CString + _UNICODE means wchar_t. Therefore, assuming we want utf-8, I think a prerequisite of _UNICODE is replacing CString with std::string.

Also note that I am not talking about true internationalization; just a single step down that path.

wsu-cb commented 1 year ago

Dale, do you agree with my comments above?

DLLarson commented 1 year ago

As stated in https://github.com/CyberBoardPBEM/cbwindows/pull/71#discussion_r725491054, for portability/consistency to Linux/Mac, we probably want to use std::string, but assume utf-8 content in it. However, we will need to use utf-8/wchar_t conversion helpers to make calls to Windows Unicode functions. wxWidgets provides extensive helpers, but wxWidgets effectively requires _UNICODE, and I would prefer not to try to simultaneously add wxWidgets and enable _UNICODE, so I think we will need to provide our own (temporary?) helpers.

As you can see from my comments in #71 above these sorts of changes can be difficult to implement especially when not much is gained as UTF-8 provides anything that UTF-16/32 bit characters do. I looked at the wxWidgets docs for their UNICODE change and was heartened so to see this:

This means that internally only Unicode strings are used and that, under Microsoft Windows, Unicode system API is used which means that wxWidgets programs require the Microsoft Layer for Unicode to run on Windows 95/98/ME.

However, unlike the Unicode build mode of the previous versions of wxWidgets, this support is mostly transparent: you can still continue to work with the narrow (i.e. current locale-encoded char) strings even if wide (i.e. UTF16-encoded wchar_t or UTF8-encoded char*) strings are also supported. Any wxWidgets function accepts arguments of either type as both kinds of strings are implicitly converted to wxString,

The overhead for these conversions are inconsequential as Windows has always done them way back to the start of Windows NT. wxWidgets is simply taking advantage of that fact and it allows developers to use either char* type strings or wide as they wish...at least that how I read it. I think it's great that wxWidgets takes on that burden as it makes it near seamless to support both for those who don't want abandon a bunch of code simply to upgrade their UI framework.

I'm one that's not generally convinced that 8bit characters will be displaced by wide characters--especially at the C/C++ level. On Linux/Unix OS's system and program configuration are and probably always will be simple 8-bit character files. UTF-8 seems to be the law of the land there.

All that being said, I'm again going to defer to you what level you wish to take this since I think your work is the future of CB--not mine. I'm getting long in the tooth and it's important that someone else move this program forward. I'm happy to provide opinions but I don't want my words to be law.

Anyway that's my 2 cents for what it's worth.

An aside... The work on the DPI awareness stuff has been stalled for a while with the holidays soaking up all my time. I'm about to get back at it. I've run into lots of quirks in coordinate systems between board scaling, DPI scaling and mouse management. Fun times!... but I'm gradually knocking them off.

-Dale