This allows user to know when there is not enough space on the target media,
when there is no permissions for the operation, or some other error.
CORE-9239
Fix (tr-TR) resource file compilation error RC2102 on VS2015 and 2017.
Based on the work done at CORE-7405, moves the string split location so
the first part of the message isn't too long anymore.
CORE-17910
- Use SendMessageTimeout instead of SendMessage.
- Use SwitchToThisWindow instead of BringWindowToTop.
- Use ShowWindowAsync instead of ShowWindow.
- Use SWP_ASYNCWINDOWPOS for SetWindowPos.
CORE-17894
- Add context structure and definitions, NEON128 structure,
runtime function entry, dispatcher context, scope table
All definitions are based on the latest SDK for arm64.
[SDK] Use _TARGET_PE64 in the pefixup
[GENINC] Add AA64 identifier for ARM64 PE binaries
CORE-17518
This reverts commit ecf3416f49.
This commit was meant to fix CORE-17688. While its effectively fixed
the problem, it introduced another regression CORE-17719.
In the mean time, commit c05a45e17e fixed
things properly.
CORE-17719
- Add IntIsWindowFullscreen function to judge whether the window is fullscreen.
- Add IntCheckFullscreen function to notify HSHELL_RUDEAPPACTIVATE if fullscreen.
- Add IntCheckFullscreen call in UpdateShellHook function.
- Add IntCheckFullscreen call in co_WinPosSetWindowPos function.
CORE-16130
- Extend PATH_WidenPath function as PATH_WidenPathEx with the path argument.
- Use PATH_WidenPathEx and PATH_FillPathEx functions to implement wide pen drawing in PATH_StrokePath function.
- Add the code to IntGdiLineTo, IntRectangle, IntGdiPolygon, and IntGdiPolyline in order to stroke the path when the effective wide pen.
FIXME: Boundary rectangle.
CORE-2527, CORE-8366
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.
It actually should look like '\\.\DISPLAY<n>' (since it comes from user mode),
which the function expects, and not '\\Device\\Video<n>', like done in the
kernel mode. Otherwise, passing wrong name causes a mismatch.
Fix the problem with video device access (failure with status 0xc0000022 when
trying to open it). Hence, it also fixes the following debug log spam:
'err: Could not open device \Device\Video0, 0xc0000022'.
Addendum to 77e891b8. CORE-17719 CORE-17786
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.
