gcc is able to optimize the if/else block into a jump table, but MSVC
gets confused and fails to optimize it. Converting to switch/case
allows both compilers to optimize it using a jump table.
The gcc version might be slightly bigger now due to explicitly stating
the 30-37 and 40-47 cases instead of checking ranges, but it might be
slightly faster due to not having to check ranges and instead simply
jumping to the correct case.
\033[m with no number should be interpreted as 0 (Reset).
Also, simply ignore invalid (unsupported) attribute numbers instead
of stopping \033[m processing entirely. Otherwise, the 'm' might
end up getting printed.
Add support for the following attributes:
- 4 (underline)
- 7 (reverse video)
- 27 (not-reverse video)
NOTE: These work on Windows 10, but not Windows 7. The Windows 10 support
is redundant, since on Windows 10, we're normally sending ANSI escape
sequences directly to the console, instead of using the custom handler.
Maybe these attributes work on Windows 8 and/or 8.1?
Move `uint16_t wAttributesOrig` before `HANDLE hConsole`. HANDLE is
64-bit aligned (on 64-bit), so it ends up leaving some space after
the bools that we can reuse for the uint16_t.
64-bit Windows:
Size before: 32 bytes
Size after: 24 bytes
Difference: -8 bytes
32-bit Windows:
Size before: 16 bytes
Size after: 16 bytes
Difference: 0 bytes
Effectively no difference on 32-bit, but reduces it by 8 bytes on 64-bit.
This prints a newline using WriteConsole() on Windows if possible.
Otherwise, it uses stdio.
Use ConsolePrintNewline() anywhere putchar('\n') or fputc('\n', stdxxx)
was used.
TODO: Optimize by not requiring a full utf8_to_utf16() here?
That might be a "super-micro-optimization", though...
This eliminates an strlen() when using a C++ string.
There are now two inline wrappers:
- one for C strings with implicit length
- one for C++ strings with explicit length
Both of these wrappers call the real ConsolePrint, which takes an
explicit length and doesn't take any optional arguments.
Also, the C++ wrapper was returning the return value from a void
function, which somehow "worked", but isn't correct.
Use fwrite() instead of fputs() when the size is known.
I used it while doing some testing with WriteConsole(), but that
function is now called in vt.cpp, and not by rpcli.cpp directly.
Also removed `using std::u16string;`.
romdata-6.dll also depends on libgnuintl-8.dll, so if libgnuintl-8.dll
is missing, romdata-6.dll won't be usable, either.
FIXME: libromdata doesn't appear to have a libgnuintl-8.dll check...
Support for ANSI escape sequences was added in Windows 10 1607, which
also handles UTF-8 console output correctly. Use WriteConsoleA() so
we don't have to convert from UTF-8 to UTF-16.
WriteConsole() is faster than printf/cout on Windows.
TODO: Maybe use WriteConsoleA() instead, so we can take advantage of
ANSI escape and UTF-8 support while also getting the performance benefit
of WriteConsole().
This resulted in an extra newline when showing usage in builds that
support decryption.
This fixes a regression from commit aa6f1aba07.
([rpcli] rpcli.cpp: New function ConsolePrint(), now used by ShowUsage().)
Somehow missed this in commit a2a61e614163f1c5968421803130bb2d88b369b0...
([rpcli] Rework the various Windows console functions to take ConsoleInfo_t*.)
ConsolePrint() works on both Windows and Linux.
On Linux, it merely calls stdio functions.
On Windows, it calls stdio functions if not using a real console.
Otherwise, it uses WriteConsole().
Add a ConsolePrint() overload that takes std::string.
NOTE: May be more efficient if the std::string overload calls
win32_write_to_console() with an actual length parameter, but
it takes more effort to maintain two versions of this function...
It was showing an error if the file specified was in fact a device file,
which prevents it from working.
This fixes a regression from commit 837315505e.
([rpcli] rpcli.cpp: Un-indent a few functions.)
Affects: v2.3 - v2.5
This will be useful when updating the stderr stuff in rpcli.cpp to use
WriteConsole() for both Unicode and performance reasons.
rpcli.cpp: Update for this change.
This is true if using a real Windows console, and false if using e.g.
MinTTY. MinTTY supports ANSI escape sequences, but not WriteConsole().
rpcli.cpp: Don't use WriteConsole() if we aren't using a real console.
This is faster than even using UTF-8 output on Windows 10 1607.
vt.cpp: win32_write_to_console(): Write in 4096-character chunks.
WriteConsole() seems to fail if the input buffer is > 64 KiB.
rpcli's JSON for rpcli.exe is 40,057 characters, which is > 64 KiB
with UTF-16 and failed to write. (The ANSI version "worked", though
without Unicode handling.)
WriteConsole() with Unicode (UTF-16) text seems to work around the
issue that was causing UTF-8 output to freeze on Windows 7. It's also
quite a bit faster than printf/cout on Windows.
WriteConsole() *does* work with ANSI escape sequences on Windows 10 1607,
so I'm going to do some reworking to make more use of it.
CMakeLists.txt: Remove the std::string_view check, since it's no longer
used in vt.cpp.
Compiled with:
- i386: gcc-14.2.1_p20241116, MinGW-w64 12.0.0
- amd64: gcc-14.2.1_p20241221, MinGW-w64 12.0.0
I tried updating it before, but every time I rebuilt gettext, it would
cause all of rom-properties to crash on startup. It turns out the
problem was -Wl,--pic-executable; removing this fixed it.
This *might* prevent ASLR .reloc sections from being generated in the
gettext executables. These are only used at compile time, so it's not
that big of an issue.
Removed most of the patches, since they are no longer necessary.
The remaining patches:
- 001-gettext-runtime-disable-iconv.patch
- 122-Use-LF-as-newline-in-envsubst.patch
Both patches have been updated for gettext-0.24.
TODO: Build for arm, arm64, and arm64ec.
Check that the first .so file was opened before opening the second one.
Code size difference: (64-bit Gentoo Linux, gcc-14.2.1_p20250301, release build, no LTO)
text data bss dec hex filename
1798 96 160 2054 806 tracker-mini.c.o [before]
1774 96 160 2030 7ee tracker-mini.c.o [after]
-24 0 0 -24 -18 Difference
Otherwise, I might forget to update it when building for various versions
of Ubuntu, which will result in Tracker being installed in the wrong
place for most newer versions.
Various pathnames were changed, but the API is essentially the same.
The API version will be handled as "3L".
dlopen-notes.h: Add ELF_NOTE_DLOPEN8().
[tracker] dlopen-notes.c: Add the API 3L library names.
NOTE: The Ubuntu 25.04 packages were all compiled with a hard-coded
-DTRACKER_INSTALL_API_VERSION=1. This should probably be removed from
debian/rules and we should just rely on auto-detection.
TODO: Release a v2.5.1 with this fix?
Delay of 0 means "end of sequence". This effectively is the same as a
static icon, but the previous method of just checking frame 0's delay
didn't work.
This resulted in the following ROM headers as being detected as having
an animated icon when they didn't:
- DMFEA4
- DSYESZ
- VSOE8P
TODO: Add one that does.
nds_structs.h: Mark some enum constants as unsigned.
This fixes a regression from commit f5d34d97cb.
([libromdata] NintendoDS_BNR::imgpf(): Check for animated icons.)
