Ensure that CMAKE_ASM16_COMPILER is 32-bit MASM.
It is used only for compiling 16-bit x86 ASM code on non-x86 builds.
Original patch by serrox. CORE-10452, CORE-17604
Co-authored-by: Sergey Chernov <serrox@ya.ru>
* [PIFMGR] Optimize png images
- Lossless optimization with `pngslim`. Saves ~50%.
- Restricted to RGBA color mode (‘c6’), for maximum compatibility at the cost of some compression.
* [ROSAPPS] Optimize png image
- Lossless optimization with `pngslim`. Saves ~10%.
* [MSTSC] Optimize png image
- Lossless optimization with `pngslim`. Saves ~56%.
- Restricted to RGBA color mode (‘c6’), for maximum compatibility at the cost of some compression.
* [Themes] Optimize png image
- Lossless optimization with `pngslim`. Saves ~20%.
- Restricted to RGB color mode (‘c2’), for maximum compatibility.
- Changed some wording according to the translation requirements.
- Fixed some mistakes.
- Changed my name.
Reviewed-by: He Yang <1160386205@qq.com>
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
Reviewed all Chinese Simplified translation files and updated those
inappropriate or outdated ones.
Co-authored-by: Liu Wenyuan <15816141883@163.com>
Reviewed-by: Chan Chilung <eason066@gmail.com>
Reviewed-by: He Yang <1160386205@qq.com>
Reviewed-by: Zheng Jianping <robsean@126.com>
Reviewed-by: Luo Yufan <njlyf2011@hotmail.com>
Reviewed-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
- Added zh-HK translation for following files:
- [BASE/SERVICES/W32TIME]
- [BASE/SYSTEM/...] (except CMD console only applications)
- [FDEBUG]
- [DLL/CPL/...] (except Wine related applications)
- [DLL/SHELLEXT/...]
- [DLL/WIN32/...] (not all applications are translated, and Wine related applications are excluded from this part)
- [MODULES/ROSAPPS/APPLICATIONS/...] (not all applications are translated)
- [SCREENSAVERS]
- [NTVDM]
- [USERSRV]
- Translation Improvement
- Fix header for zh-TW and zh-HK translation files
Reviewed-by: Luo Yufan <njlyf2011@hotmail.com>
Reviewed-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
- Added translation for:
- [W32TIME]
- [MODE]
- [TIMEOUT]
- [MODEMUI]
- [ARPING]
- [FRAGINATOR]
- and more
- Updated existing translation
- [WINNLS] Update cht (zh-TW) and zhh (zh-HK)
- [DOC] Update rules in Chinese translation notes.txt
- Wine translation sync
Some of the punctuation use in WIne has been converted to half-width,
so the punctuation will no longer synced.
This became a requirement, following a previous CMake update.
Otherwise the built EXEs would not export their intended functions.
Addendum to commit d8e92b5a (see PR #1335)
CORE-15406
[LOADCONFIG] The GCC rant had nothing to do with GCC, but everything with CMake...
[SPOOLSV] Add the missing exported stubs.
We get file matches when their attributes match and we can obtain
a valid 8.3 file name. This last condition is of upmost importance.
We cannot reliably use GetShortPathName() on the filename returned by
FindFirstFile()/FindNextFile() because the result is uncertain (one
either needs to build a full path before calling the function just to
get the final short path form, or change the current working directory
to the one where the search is being made, etc.)
The Find*file() functions return anyway the short file. name (in the
cAlternateFileName member) if the file does have such 8.3 filename and
its real name (in cFileName) is longer. Otherwise, cFileName could
already be *THE* short filename because it has the correct format for
it. Check this latter case with RtlIsNameLegalDOS8Dot3() and use it if
so. Otherwise this means the file has a long filename that cannot be
converted to short filename format (because e.g. it is in a volume where
short filenames are unavailable), and we skip such files: they wouldn't
be accessible from DOS anyways.
- Doxygen-document demFileFindFirst(), demFileFindNext() and associated
flags and structures. Update their annotations.
This fixes TurboC 2.x installation.
This fixes the age-long annoyance that wherever you ran a DOS program
with NTVDM, its cmos.ram file would be created in the same current
directory the DOS program was being started.
This created at least two problems:
- useless pollution of directories with cmos.ram files;
- for installers, e.g. of Turbo C 1.x that enumerate the install files
from their directories to be copied/extracted somewhere, the cmos.ram
file could then be enumerated along and cause the installation to
interrupt and/or fail.
Now the cmos.ram file is created in the same directory NTVDM resides
(usually in System32...).
Also, debug-print out only loading errors instead of successes as well.
There is no need to compile our DLLs as shared libraries since we are
managing symbols exports and imports through spec files.
On my system, this reduces the configure-time by a factor of two.
[CMDUTILS/AT] Fix missing translation strings in certain files.
[NOTEPAD] Fix SUBLANG code to brazillian.
[RAPPS] Fix missing translation strings in certain files.
[FDEBUG] Fix translation string ID.
[CPL/INPUT] Fix missing translation strings in certain files.
[ACPPAGE] Fix incorrect resource IDs.
[NETSHELL] Fix incorrect resource IDs.
[DEVMGR] Fix missing translation strings in certain files.
[LSASRV] Fix missing translation strings in certain files.
[RASDLG] Fix missing translation strings in certain files.
[SHELL32] Fix missing translation strings and incorrect resource IDs.
[TAPIUI] Fix missing translation strings in certain files.
[WINFILE] Fix incorrect resource IDs.
[NTVDM] Fix missing translation strings in certain files.
[USERSRV] Fix missing translation strings in certain files.
[BROWSEUI] One more missing string.
[FLTMC] Fix missing translation strings in certain files.
Detected using the TransDiffer tool (early alpha).
This doesn't include everything anymore, but I wanted to get the PR out of the way.
Some applications, run on a CDROM, may attempt to open
a file with write access. CDFS driver will deny such
request in ReactOS (but also in Windows NT). Then, to
restore that behavior from old Windows (9X), our ntvdm,
as Microsoft ntvdm will attempt to reopen the file only
with read access, if opening failed because of denied access
and if the file is on a CDROM.
CORE-15211
