Two types of mojibake are detected and fixed:
- UTF-8 parsed as cp1252
- Shift-JIS parsed as cp1252
For the latter case, utf16_to_cp1252() on Linux (and other systems that
use iconv) has been modified to handle five code points that iconv()
doesn't support: 0x81, 0x8D, 0x8F, 0x90, 0x9D.
TODO: Also do this for utf8_to_cp1252() and other cp1252 functions?
On Windows, WideCharToMultiByte() and MultiByteToWideChar() handle these
code points without any issues.
These three title updates now show a correct title:
TU_11LK1UV_0000004000000.0000000000081 (UTF-8 as cp1252)
Name: 'Dodonpachi Daifukkatsu Black Label Title Update #1'
Title: '怒首領蜂 大復活 Black Label'
TU_12501VG_0000004000000.0000000000101 (UTF-8 as cp1252)
Name: 'DREAM C CLUB Title Update #4'
Title: 'ドリームクラブ'
TU_15LG1UH_000000C000000.0000000000083 (Shift-JIS as cp1252)
Name: 'Circle of Students Title Update #1'
Title: '円卓の生徒'
Fixes#450: X360 - Non-Latin Titles appearing as mojibake
Reported by @Masamune3210.
Check the magic number before initializing libpng.
It seems there's something wrong with MSVC 2022 (17.6.5) that causes a
release build of libpng to crash when calling longjmp() on Windows 10.
If this is in fact a compiler bug, and upgrading the compiler fixes it,
then I'll need to switch away from my Windows 7 VM because MSVC 17.6 is
the last version to support Windows 7 as a build environment.
See #451: libpng errors crash due to libpng setjmp/longjmp (Windows 10, release builds only)
Reported by @Masamune3210.
When testing non-RomData files with `rp-stub -R`, I got random crashes.
gdb traced it back to an invalid g_bytes_unref() due to pngBytes not
being initialized properly.
This only affects the GTK4 version.
This fixes a regression from commit bc32b0c3a2.
([gtk] DragImage: Implement GTK4 drag & drop.)
Affects: v2.4 - v2.5
It seems this was broken since it was initially implemented in v2.0
in commit d732fbc010
([cmake] platform/gcc.cmake: Initial support for detecting DT_RELR.)
because TMP_HAVE_DT_RELR was unset too early.
Need to use be32_to_cpu() for 32-bit values, not be16_to_cpu().
This fixes a regression from commit 5cfce44312.
([libromdata] ISO: Always use host-endian except for CD-i, in which case, always use big-endian.)
Affects: v1.8 - v2.5
NOTE: v1.8 was the first version with CD-i support, so this was
effectively "always" broken.
Make it sort in ascending order by default instead.
NOTE: Using column -1 to suppress the sort indicator visibility.
Might want to guard this with QT_VERSION_CHECK(6, 0, 0), but it seems
to have no effect on KF5 on my system, but it might on some other
systems with weird shenanigans happening...
The SparseDiscReader changes in v2.3 broke this, so anything that uses
an ISO-9660 format showed 2048-byte sectors, even if this wasn't the case.
SparseDiscReader subclasses now have a set of CD-ROM specific fields to
set, e.g. CD-ROM sector size, mode, and subchannels. For multi-track
images, this should be set for the "main" data track.
Updated the following classes to set these fields:
- CdiReader (uses Track 02 for Dreamcast games)
- GdiReader (uses Track 03 for Dreamcast games)
- Cdrom2352Reader (always uses 2352-byte sectors, but gets mode from
the first sector)
- CisoPspReader (always uses MODE1/2048)
GameCube and Wii disc reading classes don't set these, since they aren't
CD-ROM formats with multiple sector sizes.
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 was previously handled by NintendoDS before banner parsing was
split out into a separate RomData subclass.
Without IMGPF_ICON_ANIMATED, rpcli won't indicate if an animated icon
is present, but it can still be extracted with `-a`.
This fixes a regression from commit f2565965b2.
([libromdata] NintendoDS_BNR: Split icon/title data parsing out of NintendoDS.)
Affects: v2.4 - v2.5
Unstaged images contain sets of components instead of a fully-installed
Windows system. These aren't as common as staged images.
The list of editions appears to be in the display description, though
I don't have an unstaged image to verify this. If the display description
contains "EDITIONS:", and the regular edition field and languages are
both empty, then it will be assumed to be unstaged. The list of editions
will be split and one image will be shown for each edition, using the
image number and a letter.
Should fix#445: [libromdata - WIM] Unstaged Windows OS installation images not properly supported
Requested by @pivotman319-owo.
NOTE: Needs to be verified!
Note that NEON's vtbl instructions doesn't support the bit 7 "zero it"
feature that x86's pshufb supports, so we have to use an AND mask in
addition to an OR mask.
Tested using luminance_alpha_reference_u.ktx2, which has a swizzle
value 'rrrg'. (Also used this for testing the previous commit, which
switched some mask stuff from 8-bit operations to 32-bit.)
Both lastmodtime_high and lastmodtime_low were being initialized to
strtoul(s_highPart, ...).
Testing Windows 10 (10.0.19041.5363) recovery image: (winre.wim)
- HIGHPART: 0x01D5ACCD
- LOWPART: 0x97A856C3
- Decimal: 132201763089962691
Timestamp conversions before and after: (using TZ=UTC)
- Before: 12/07/2019 07:07:37 AM
- After: 12/07/2019 07:11:48 AM
Manually converting it using a website:
- Saturday, December 7, 2019 7:11:48 AM
TODO: Split the XML code into a separate .cpp file and add DelayLoad checks.
It's only supported by glibc on Linux (and possibly some of the BSDs),
and it adds a lot of complexity. The regular C dispatch functions only
have a few instructions of overhead in most cases.
Adding ARM NEON would have complicated things:
- 32-bit ARMv7: Needs a check on Linux and Android; on Windows, it's
guaranteed to be present.
- 64-bit ARMv8: Always exists.
Both the GDI and CDI branches were attempting to create CdiReader objects.
That obviously won't work for GDI.
This fixes a regression from commit 209ea0d951.
([libromdata] MultiTrackSparseDiscReader.hpp: New interface for multi-track sparse disc reader classes.)
Affects: v2.4 - v2.4.1
qoi.h is used for upstream, instead of writing a custom decoder.
I may write a custom decoder later to decode the Qoi data directly
into an rp_image without having an intermediate step.
RomDataFactory::T_create(): Check if the filename is a drive letter.
IRpFile: Move IsDriveLetter*() and related from RpFile_win32.cpp to
IRpFile.hpp, #ifdef'd for Windows only.
CD-ROM drive volume roots can now be handled by rom-properties again.
This broke when support for Wii U Packages was added, since devices are
also considered root directories, so the directory check was done instead
of the device check.
Affects: v2.4 - v2.4.1
