The NXSYS sources are ridden with C++ Preprocessor conditionalizations. Many are obsolete. I'm trying to extirpate the latter, but that is a tedious and unrewarding, hence low-priority task, as each such step requires lengthy (on Windows) rebuilding and careful testing.
Some flags are “pairs” of which one or the other must be true at all times. Currently, _WIN32 versus NXSYSMac is one such. If, of course, there ever arises a Linux or other third platform, a stricter regime would be required.
Many of these flags represent developments, incidents, or test stages of the application; three are mandatory until they are extirpated. The actual flags as specified to the compiler, in Visual Studio on Windows and Xcode on the Mac, are the authoritative source on what is necessary. The Mac windows.h spoof header defines the three “necessary“ ones on that platform.
This is required on Windows if you don’t want to drown in compiler “warnings” about how strlen, strcpy and other old K&R C troupers are “dangerous”. While (greater) NXSYS is becoming increasingly a “modern C++” app relying heavily on STL, std::string replacing the venerable char * and char buf[MAX_PATH] (let alone the new std::filesystem blessing), there are still numerous calls to these old chestnuts, and without this flag being specified, you will be scolded for each by the “modern” compiler.
Unfortunately, however, no Windows APIs accept STL strings, and many require "LPCSTR" (const char * in this non-UCS2 case) strings and a separate length, which is declared int in their headers. This causes use of the results STL strings’ size method, which is size_t, which is unsigned, to provoke more warnings, so each such use now has to be cast with (int).
| Flag | Meaning/remarks |
|---|---|
| NXSYSMac | Means "we are compiling on/for the Mac", for all applications and utilities. Supplied in Xcode build config. |
| _WIN32 | Defined and supplied by the Microsoft compiler. To this application means "We are compiling on/for Windows.", whether 32 or 64 bits. |
| WIN32 | This is being extirpated, but is still relied on, and must be specified to VS/VC on Windows. |
| _WIN64 | 64-bit Windows build, defined and supplied by the Microsoft compiler. Used in About dialog etc. to proclaim same. |
| DEBUG | NXSYS code looks at this to conditionalize debug code. Should be 1 for debug builds, both platforms. |
| _DEBUG | Microsoft language support depends on this. Visual Studio sets it, clang/Xcode do not. NXSYS code does not need it. |
| NDEBUG | For release builds, controls assert activation. NOT set by compiler! |
| TLEDIT | This is the track-layout editor, not the interlocking simulator. |
| REALLY_NXSYS | This is the interlocking simulator, not the track-layout editor (inferred from TLEDIT on Mac). |
| BLISP | This is the Lisp test build, not either GUI app. |
I haven't yet removed these artifacts. They enable interface code for obsolete features, not the inclusion of their actual code.
| Flag | Meaning |
|---|---|
| NXOGL | (Open Graphics library). Interface remains of the obsolete Version 1 Cab View system. |
| NXOLE | Supporting the Windows OLE server and client program. |
| NXCMPOBJ | (Supporting) compiled objects generated by the no-longer-supported (Windows) Relay Compiler. |
These should no longer appear in the source (3/21/2022). They do still appear in the Windows .vcxproj, but will be removed next time it is released.
| Flag | Meaning |
|---|---|
| WINDOWS | Meant same as _WIN32. There was 16-bit long [sic] ago. |
| XTG, NXV2 | (Extended track geometry). Both signify NXSYS Version 2 (or TLEdit, which is only version 2). Version 1 no longer exists. |
| RT | (“Rapid Transit”) Remains of a 1997 commercialization attempt. |
| APPDEMO | Ditto |
| NOTRAINS | Used during testing train system to factor it out. |
| PRODUCT_NAME (value) | This had to be ="NXSYS" or ="TLEdit". Currently established by include files. |
All other flags that may appear (that I haven't thought of) are obsolete and may be assumed undefined/false ... I think. There are some (e.g., _RELAYS) defined in the same module in which they are used (hence, not global).