According to RFC 3927, the pseudo-random number generation algorithm MUST be chosen
so that different hosts do not generate the same sequence of numbers, and that the
pseudo-random number generator SHOULD be seeded using a value derived from the
IEEE 802 MAC address, so that a host will usually select the same IPv4 Link-Local
address each time it is booted.
The dialog box at the startup of On-Screen Keyboard is displayed alongside with main window. While the Microsoft's OSK in XP is written in MFC and OSK is actually a mere window whereas our OSK is a dialog, the main dialog procedure call is superseded until the user does something with the warning dialog box on startup.
Just create a thread for it and handle the dialog box on startup in its own thread.
Don't wait for their events to appear, just retrieve the list and
install drivers. This fixes the installation of manually reported device
nodes
CORE-17212 CORE-17398
Instead of PlugPlayControlResetDevice, PlugPlayControlStartDevice should
be used for a newly installed device.
For usetup, add a device status check before starting attempt, so we're
not touching devices which are already started.
CORE-17463 CORE-17490
We are not ready for enabling ATLASSERT. Enabling ATL assertions takes time to realize. CORE-17505
- Disable ATLASSERT by undefining _DEBUG.
- Revert currently non-fixable codes.
Two issues are addressed:
CORE-2189: missing undo feature
Works the same way as solitaire in windows xp:
- only 1 action can be undone;
- the player gets -2 points in standard score mode;
- the undo action resets when the player clicks on a row stack to turn the top card.
CORE-11148: invisible cards
This happens in 3-card mode, when only 1 card left in the deck. The fix for this is to modify the pile stack to contain all the face-up cards. It was actually already in the code somewhere else, so I turned it into a separate function.
- CACLS, FONTSUB, NOTEPAD, SOLITAIRE, VCDCONTROLTOOL, WORDPAD: Update Chinese Traditional translation.
- CALC, PING, SYSTEMINFO Add Chinese Traditional translation.
- PING, SYSTEMINFO: Update zh-TW.rc to make it less Windows like (maybe).
- WRITE, WINFILE: Translation sync to Wine.
+ Update media/doc/For_Chinese_Translation.txt
The AsciiChar of the ESCAPE key should be 0x1B instead of zero; however
this is not the case due to the hacked keyboard layout currently being
used. This will be fixed later ...
- Use NT values for uninitialized handle values.
- Cache the STD_INPUT_HANDLE.
- Free the console if GetConsoleScreenBufferInfo() fails in CONSOLE_Init().
- Use PnP storage class drivers
- Make partmgr an upper filter driver for Disk class
- Fill upper filters in txtsetup and usetup/devinst
- Add cdrom driver to the critical device database
CORE-6264
Add two hacks in UpdateDiskLayout() and WritePartitions() so that the
disk partition style is consistently set to a known value MBR, especially
when that disk was previously new and uninitialized (RAW).
A proper fix will be developed later when support for GPT is added.
so that they wrap the needed init steps for formatting/chkdsk'ing.
These helpers now accept a PPARTENTRY, together with the usual
formatting/chkdsk parameters. The helpers now determine the actual
NT path to use, and can perform the init steps on the partition
before performing the actual operation.
In particular, FormatPartition() is now made GPT-compliant. The
partition type retrieved by FileSystemToMBRPartitionType() is now
used as a hint for choosing FAT32 over FAT12/16, and only in the
case of a MBR partition that is *NOT* a recognized OEM partition,
it is used for updating the corresponding partition type. (OEM
partitions must retain their original type.)
The OEM partition types we (and NT) can recognize are specified
e.g. in the Microsoft Open-Specification [MS-DMRP] Appendix B
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dmrp/5f5043a3-9e6d-40cc-a05b-1a4a3617df32
Introduce an IsOEMPartition() macro to help checking for these types
(its name is based on the Is***Partition() macros from ntdddisk.h,
and from a dmdskmgr.dll export of similar name).
Instead of providing an MBR partition type to InferFileSystem(), make
it call IOCTL_DISK_GET_PARTITION_INFO(_EX) to determine whether the
partition pointed by the path/handle is MBR or GPT. Then, only if it's
MBR, we retrieve its partition type in order to "guess" an adequate file
system name, in case the latter was not recognized already via regular
ways (via GetFileSystemName() / NtQueryVolumeInformationFile()).
- Remove the GetFileSystemNameByHandle() and InferFileSystemByHandle()
functions. Instead, make the other GetFileSystemName*() and
InferFileSystem*() functions accept a HANDLE as an alternative to the
already-existing partition path string. These parameters are exclusive
to each other.
- Rename SetPartitionType() -> SetMBRPartitionType(),
and FileSystemToPartitionType() -> FileSystemToMBRPartitionType()
in order to really clarify what they do (since this code is meant
for MBR partitions only, not GPT ones).
[AUTOCHK] Add also support for scanning FATX volumes.
The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the
U*.DLL user-mode FS library dlls are different (and have different
prototypes) than the similarly-named functions exported by FMIFS.DLL .
In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()"
in our U*.DLL libraries actually correspond more, from their arguments,
to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their
*Ex() counterparts instead take most of the parameters through a
structure passed by pointer.
On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and
FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these
*Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx()
call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls
U*.DLL!FormatEx() (that we do not implement yet either) !!
To improve that, refactor the calls to these U*.DLL functions so as to
respect the more compatible prototypes: They contain the correct number
of parameters in a compatible order. However, some of the parameters do
not have the same types yet: the strings are kept here in PUNICODE_STRINGS,
while on Windows they are passed via an undocumented DSTRING struct, and
the FMIFS callback is instead a MESSAGE struct/class on Windows.
Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet
not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used
in the corresponding FMIFS.DLL functions.
One thing to notice is that the U*.DLL!Format() (and the Ex) functions
support a BOOLEAN (a flag resp.) for telling that a backwards-compatible
FS version should be used instead of the (default) latest FS version.
This is used e.g. by the FAT FS, where by default FAT32 is selected
(depending also on other constraints like, the disk and the partition
sizes), unless that bit is set in which case, FAT16 (or 12) is used.
- Added zh-TW translation for the following modules: credui, crypt32, getuname, mapi32, themeui, shlwapi.
- Modify zh-TW translation for other files.
- Moving Traditional Chinese translation back to Zh.rc for files came from Wine (comdlg32).
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
rapps.com will be launched when running 'rapps' from cmd or
from run, and since it is a console application, explorer/ cmd will
wait for it.
This rapps.com passes the commandline to rapps.exe,
and wait for rapps.exe to exit before closing.
CORE-17281
in favor of add_compile_options and the like with generator expressions
Also take this as an opportunity to remove the C++11 standard hack, GCC 8 now defaults to C++14
Instead of messing with global variables and the like, we introduce two target properties:
- WITH_CXX_EXCEPTIONS: if you want to use C++ exceptions
- WITH_CXX_RTTI: if you need RTTI in your module
You can use the newly introduced set_target_cpp_properties function, with WITH_EXCEPTIONS and WITH_RTTI arguments
We also introduce two libraries :
- cpprt: for C++ runtime routines
- cppstl: for the C++ standard template library
NB: On GCC, this requires to create imported libraries with the related built-in libraries:libsupc++, limingwex, libstdc++
Finally, we manage the relevant flags with the ad-hoc generator expressions
So, if you don't need exceptions, nor RTTI, nor use any runtime at all: you simply have nothing else to do than add your C++ file to your module
The formatter will select it anyway as soon as the partition size
permits it. We make it available internally however so as to "emulate"
FMIFS functionality.
Now rely on the partition filesystem for InstallVBRToPartition() instead
of the unreliable and deprecated partition type.
- Move the actual VBR bootcode installation helpers into fsutil.c
(they depend on the selected filesystem).
- Introduce InstallBootCodeToDisk() and InstallBootCodeToFile()
and bootcode.c helpers, in order to replace the several functions
that were duplicating the same code.
Fix filename completion that could cause a incorrect result when the path
contains "dots". (See also HBelusca@d12169b.)
See CORE-8623 and CORE-1901 (bug introduced in r25896 / 54cf74f).
For example:
- The current directory is `C:\Documents and Settings\Administrator\`, and you
input `".` and press TAB. The completion result would be `".Administrator"`,
which even does not exist.
- You input "some(file).ext", and you remove the final quote (or the quote
and "ext") and you attempt to complete the file name.
- Import two additional fixes from HBelusca@a826730: Fix the search ordering
in the comparisons between szSearch1, szSearch2 and szSearch3.
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
- Not all the wcscpy() / swprintf() calls have been converted to their
string-safe equivalents. Instead I used the string-safe functions only
for places where strings of unknown length were copied into fixed-size
internal buffers. On the contrary, for known-fixed-length strings being
copied or numbers being converted to string representations in large
enough buffers, I kept the original function calls.
- Verify the registry data that has been returned by NtQueryValueKey():
* When expecting (not multi) strings, check whether the data type is
either REG_SZ or REG_EXPAND_SZ.
* When expecting DWORD values, check whether the data type is
REG_DWORD and whether the data length is (greater or) equal to
sizeof(ULONG).
CORE-17050
Display the shutdown message popup dialog on the current input desktop,
and periodically monitor for any change of the input desktop. When the
latter changes, close the dialog and recreate it on the new input desktop.
In addition, retain the current dialog position and restore it when the
dialog is recreated on the new desktop.
CORE-17312
Hide everything under the same foreground & background colors, so that
the actual color and text blanking reset does not create a visual "blinking".
Then, blank the text and finally reset the actual foreground &
background colors.
We do this because we cannot do the screen scrolling trick that would
allow to change both the text and the colors at the same time (the
function is currently not available in our console "emulation" layer).
Dedicated to the hard work of Joachim Henze! xD
This reverts part of commit 043a98dd (see also commit b2aeafca).
Contrary to what I assumed in commit 043a98dd (and was also assumed in
the older commit b2aeafca), we cannot use the singled-linked lists to
queue and dequeue the PnP device-install events, because:
- the events must be treated from the oldest to the newest ones, for
consistency, otherwise this creates problems, as shown by e.g. CORE-16103;
- the system singled-linked lists only offer access to the top of the
list (like a stack) instead of to both the top and the bottom of the
list, as would be required for a queue. Using the SLISTs would mean
that only the newest-received events would be treated first, while the
oldest (which were the first received) events would be treated last,
and this is wrong.
Therefore one must use e.g. the standard doubly-linked list. Also, using
locked operations (insertion & removal) on the list of device-install
events is necessary, because these operations are done concurrently by
two different threads: PnpEventThread() and DeviceInstallThread().
Since the interlocked linked list functions are not available in user-mode,
we need to use instead locking access through e.g. a mutex.
- Move initialization of bc->raw_params also in BatchParams().
- The bc->raw_params, i.e. the unparsed batch/CALL parameters obtained
with %*, has any leading and trailing whitespace trimmed
(since Windows 2000+).
- Fail if no parameter is provided.
- The "CALL :label args..." syntax is available only when command extensions
are enabled. Fail if this syntax is used outside of a batch context.
- Reparse the CALL command parameter with the command parser, in order
to accurately parse and interpret it as a possible command (including
escape carets, etc...) and not duplicate the logic.
** CURRENT Windows' CMD-compatibility LIMITATION ** (may be lifted in
a "ROS-specific" running mode of CMD): only allow standard commands to
be specified as parameter of the CALL command.
This reparsing behaviour can be observed in Windows' CMD, by dumping
the interpreted commands after enabling the cmd!fDumpParse flag from
a debugger (using public symbols).
- When reparsing, we should tell the parser to NOT ignore lines that
start with a colon, because in this situation these are to be
considered as valid "commands" (for parsing "CALL :label").
* For Windows' CMD-compatibility, the remaining escape carets need to
be doubled again so that, after the new parser step, they are escaped
back to their original form. But then we also need to do it the "buggy"
way à la Windows, where carets in quotes are doubled either! However
when being re-parsed, since they are in quotes they remain doubled!!
(see "Phase 6" in https://stackoverflow.com/a/4095133/13530036 ).
* A MSCMD_CALL_QUIRKS define allows to disable this buggy behaviour,
and instead tell the parser to not not interpret the escape carets.
- When initializing a new batch context when the "CALL :label" syntax is
used, ensure that we reuse the same batch file position pointer as its
parent, so as to have correct call label ordering behaviour.
That is,
:label
ECHO hi
CALL :label
:label
ECHO bye
should display:
hi
bye
bye
i.e., the CALL calls the second label instead of the first one (and
thus entering into an infinite loop).
Finally, the "CALL :label" syntax strips the first ':' away, so, as a
side-effect, the command "CALL :EOF" fails (otherwise it would perform
a "GOTO :EOF" and succeeds), while "CALL ::EOF" succeeds.
Fixes some cmd_winetests.
All these modifications have been verified with Windows' CMD, either
by using written cmd_rostests and the existing cmd_winetests, or
manually by enabling the flags cmd!fDumpTokens and cmd!fDumpParse
(available in the public symbols) and analyzing how the tokens are
being parsed, as well as the generated command tree.
See also the following links for more details (but remember that these
observations have to be double-checked in Windows' CMD!):
* Parser rules: https://stackoverflow.com/a/4095133/13530036
* Discussion: https://www.dostips.com/forum/viewtopic.php?f=3&t=8355
* Numbers parsing: https://www.dostips.com/forum/viewtopic.php?t=3758
* Label names vs. GOTO and CALL: https://www.dostips.com/forum/viewtopic.php?f=3&t=3803
and: https://www.dostips.com/forum/viewtopic.php?f=3&t=3803&p=55405#p55405
- Fix REM command parsing. A C_COMMAND-like structure should still
be built, so that it can show up during batch command echo. However
some specific handling needs to be done, so use instead a new C_REM
command type.
Escape carets are parsed differently than usual: they are explicitly
kept in the command line and don't participate in line continuations.
Also, the Windows' CMD behaviour is to discards everything before the
last line continuation.
- Prefix operator '@' (the "silent" operator) is parsed as a separate
command. Thus, the command @@foo@bar is parsed as: '@', '@', 'foo@bar'.
- Improve the checks for numbered redirection.
For this purpose, we check whether this is a number, that is in first
position in the current parsing buffer or is preceded by a whitespace-
like separator, including standard command operators (excepting '@' !)
and double-quotes.
- Empty command blocks, i.e. "( )", standing by themselves, or present
in IF or FOR commands, are considered invalid. (The closing parenthesis
is considered "unexpected".)
- Ignore single closing parenthesis when being outside of command blocks,
thus interpreting it as a command, and ignore explicitly everything
following on the same line, including line continuations.
This very specific situation can happen e.g. while running in batch mode,
when jumping to a label present inside a command block.
See the code for a thorough explanation.
- Detect whether a parenthesized block is not terminated at the end
of a command stream (getting a NUL character instead of a newline),
and if so, bail out early instead of entering into an infinite loop.
- Perform a similar check for the parenthesized list in FOR commands.
- Initialize the static 'InsideBlock' value to a known value.
- The '&' operator (multi-commmand) is allowed to have an empty RHS.
When such situation occurs, turn the CurrentTokenType to TOK_END
so as to avoid a parse error later on.
- The main body of a IF statement, or its 'else' clause, as well as
the main body of a FOR statement, must not be empty, otherwise this
is considered a syntax error. If so, call ParseError() that sets
the 'bParseError' flag, and forcing all batch execution to stop.
- Detect whether a division by zero is done, and fail if so.
- Detect whether an invalid number is provided:
* If _tcstol() fails with errno == ERANGE, we've got an overflow or
underflow.
* If the next character where _tcstol() is not a whitespace but is a
character compatible with the first character of an identifier, the
number is invalid.
- Add + to the list of existing unary operators (!,~,-), and parse them
where many of these are present. Indeed, expressions like: +3, -+-+3,
!!-+3 (or with other unary ops, etc.) are valid.
- Operators constituted of more than one characters, can contain
whitespace separating their constituting characters.
Thus, "a + = 3" is equivalent to "a += 3" (and the same for -=, *=,
/=, %=, &=, |= and ^=), and "a < < 3" is equivalent to "a << 3" (and
the same for >>, <<= and >>=).
- After evaluating everything, if unparsed data remains, fail and bail out.
- Return Windows' CMD-compatible errorlevels.
See https://ss64.com/nt/set.html for more details.
Fixes some cmd_winetests.
Observation shows that this is done only when the top-level batch file
is being run (and then terminates); the echo flag is not restored to its
previous state when a child batch file terminates and gives main back to
its parent batch.
- Make sure that non-administrator users can list associations, and
display appropriate error messages when e.g. they don't have sufficient
privileges to perform an operation.
- Make the helper functions all return Win32 values, used as the
ERRORVALUE, except when a specific extension association fails to be
displayed, in which case the ERRORVALUE is normalized to 1.
- Since the 'param' is a modifiable string (that can be modified by the
command, independently of the way it's called), just use it to isolate
the extension by zeroing out the equls-sign separator.
Commands APPEND/DPATH and FTYPE are also concerned by this; however
we do not implement them in our CMD.EXE yet.
These commands set the ERRORLEVEL differently, whether or not they are
run manually from the command-line/from a .BAT file, or from a .CMD file:
- From command-line/.BAT file, these commands set the ERRORLEVEL only if
an error occurs. So, if two commands are run consecutively and the first
one fails, the ERRORLEVEL will remain set even if the second command
succeeds.
- However, when being run from a .CMD file, these command will always
set the ERRORLEVEL. In the example case described above, the second
command that succeeds will reset the ERRORLEVEL to 0.
This behaviour is determined from the top-level batch/script file being
run. This means that, if a .BAT file is first started, then starts a
.CMD file, the commands will still behave the .BAT way; on the opposite,
if a .CMD file is first started, then starts a .BAT file, these commands
will still behave the .CMD way.
To implement this we introduce one global BATCH_TYPE enum variable that
is initialized to the corresponding batch/script file type when the
top-level script is loaded. It is reset to "none" when that script
terminates.
See https://ss64.com/nt/errorlevel.html for more details,
section "Old style .bat Batch files vs .cmd Batch scripts",
and https://groups.google.com/forum/#!msg/microsoft.public.win2000.cmdprompt.admin/XHeUq8oe2wk/LIEViGNmkK0J
(comment by Mark Zbikowski).
This compatibility behaviour implements the buggy behaviour of FOR /F
token parsing that can be observed in Windows' CMD, and that is tested
by the cmd_winetests.
It can be disabled at compile time via the MSCMD_FOR_QUIRKS define.
It fixes additional cmd_winetests, in concert with commit cb2a9c31.
Explanation of the implemented buggy behaviour
==============================================
In principle, the "tokens=x,y,m-n[*]" option describes a list of token
numbers (must be between 1 and 31) that will be assigned into variables.
Theoretically this option does not cumulate: only the latest 'tokens='
specification should be taken into account.
However things are not that simple in practice. First, not all of the
"tokens=" option state is reset when more than one specification is
provided. Second, when specifying a token range, e.g. "1-5", Windows'
CMD just ignores without error ranges that are not specified in
increasing order. Thus for example, a range "5-1" is ignored without
error. Then, token numbers strictly greater than 31 are just ignored,
and if they appear in a range, the whole range is ignored.
Another bug is the following one: suppose that the 'tokens'
specification reads:
"tokens=1-5,1-30" , or: "tokens=1-5,3" ,
i.e. more than one range, that overlap partially. Then the actual total
number of variables will not be of the larger range size, but will be
the sum, instead.
Thus, in the first example, a total of 5 + 30 == 35 variables (> 31) is
allocated, while in the second example, a total of 5 + 1 == 6 variables
is allocated, even if they won't all store data !!
In the first example, only the first 30 FOR variables will be used, and
the 5 others will contain an empty string. In the second example, only
the first 5 FOR variables will be used, and the other one will be empty.
We also see that due to that, the "Variables" buffer of fixed size
cannot always be used (since it can contain at most 32 variables).
Last but not least, when more than one "tokens=" specification is
provided, for example:
"tokens=1-31 tokens=1-20"
a total number of 31 FOR variables (because 31 is the max of 31 and 20)
is allocated, **but** only 20 are actually used, and the 11 others
return an empty string.
And in the specification: "tokens=1-31,* tokens=1-20", a total of
31 + 1 + 20 = 52 variables is initialized, but only the first 20 will
be used, and no "remaining-line" token (the '*' one) is used.
Otherwise, use `RegDeleteKeyW` instead, on Windows versions whose don't have the Ex function (XP SP3 x32, Server 2003 SP0 and earlier).
It will fix regression with Rapps startup there, due to that missing function.
CORE-17264
* [RAPPS] Display custom applications icons for installed applications
- Implement `RetrieveIcon` helper function in `CInstalledApplicationInfo` class, which retrueves the current app's icon from registry, same as it done for `CAvailableApplicationInfo`.
- Use it for loading the icon in `CAppsListView::AddInstalledApplication` function, via `ExtractIconW`. Load default Rapps icon only when the app has no its custom icon.
- Retrieve `DisplayIcon` value from registry in `CInstalledApps::Enum` function, same as other registry values (like app name, description, etc).Store it in `szDisplayIcon` string, which is used in `CInstalledApplicationInfo::RetrieveIcon` for retrieving the data of that value.
- Increase `LISTVIEW_ICON_SIZE` macro from 24 to 32, so 32x32 icon size is now used instead of 24x24. This makes displayed icons more accurate, since most of apps contain 32x32 icon, so they look a bit distorted with 24x24 size.
Suppose the following FOR-loop command, to be run from the command-line
(if using a batch file, double each percent '%' sign):
FOR %l IN ("a,b,c,d,e" "f,g,h,i,j") DO (
FOR /F "delims=, tokens=1-3*" %a IN (%l) DO @echo %a-%b-%c-%d
)
The outermost FOR-loop enumerates the two strings "a,b,c,d,e" and
"f,g,h,i,j" (placed in %l), and parse each of these in turn, splitting
them at each specified delimiter (here only one character) ',' and storing
the results in consecutive tokens %a, %b, %c, %d, with the last token %d
containing all the remaining string (non-split).
The expected result is:
a-b-c-d,e
f-g-h-i,j
However, due to the way the delimiters string specified by the "delims="
option is stored (no stack/heap duplication of the FOR-option substring,
but reading from it directly), during the first run of the innermost
FOR-loop, the option string "delims=, tokens=1-3*" was truncated to just
after the ',' due to the erroneous "delims=" parsing, so that when this
FOR-loop ran for a second time (to deal with the second string), the option
string was already erroneously truncated, without the "tokens=..." part,
so that the parsing results were not stored in the tokens and resulting in:
a-b-c-d,e
f-%b-%c-%d
instead. The solution is to save where the "delims=" string needs to be
cut, but wait until running the actual FOR-loop to terminate it (and
saving the original character too), run the FOR-loop body, and then
restore the original character where termination took place. This allows
having the FOR-loop option string valid for the next execution of the
FOR-loop.
CORE-13682
- Split SubstituteVars() into its main loop and a helper SubstituteVar()
that just substitutes only one variable.
- Use this new helper as the basis of the proper implementation of the
delayed expansion of variables.
- Fix a bug introduced in commit 495c82cc, when GetBatchVar() fails.
CORE-11857 CORE-13736
It will be followed with a separate fix for the FOR-loop code.
Fixes some cmd_winetests.
A NULL pointer can be returned for a valid existing batch/FOR variable,
in which case the enhanced-variable getter should return an empty string.
This situation can happen e.g. when forcing a FOR-loop to tokenize a
text line with not enough tokens in it.
- Add Chinese Traditional language support for CHARMAP_NEW, DRWTSN32, UTILMAN, CHKDSK.
- Improve translation for CLIPBRD, MSCONFIG(_NEW), NOTEPAD, SHUTDOWN, SNDREC32, WINHLP32, DISKPART, FORMAT, REGSVR32, RUNDLL32, USERINIT, DESK.CPL and TIMEDATE.CPL.
They are currently specified for documentation purposes (i.e. what
Windows 8+ CMD.EXE can report) but not used yet, since ReactOS does not
support them.
* [RAPPS] move settings-related stuff to a separate file
* [RAPPS] refactor reg read/write
* [RAPPS] add params for Load/SaveSettings, no longer use global vars
* [RAPPS] now command-line option supports begin with both / and -
* [RAPPS] Add help command with /?
* [RAPPS] add /find command
* [RAPPS] add /info option
* [RAPPS] add copyright and contact e-mail
* [RAPPS] add function to set view-mode
* [RAPPS] move toolbar and searchbar into appview
* [RAPPS] remove settings and exit button from toolbar
* [RAPPS] add code to switch between list and tile mode
* [RAPPS] add auto-arrange for listview
* [RAPPS] adjust the minimum size of AppView
* [RAPPS] now image list of listview is stored inside the class
* [RAPPS] add list mode, and old list-mode are detail mode now
* [RAPPS] add check for unimplemented view mode
* [RAPPS] separate application-view from gui.cpp
* [RAPPS] make the code looks more clear
* [RAPPS] fix & improve tab-order handle
* [RAPPS] now double-click / right-click & install an item will install exactly this app
* [RAPPS] add handling for DWORD timestamp for InstallDate
* [RAPPS] make the code setting column style more clear
* [RAPPS] change the owner of popup-menu
* [RAPPS] now the popup menu (the one when right-click listview) now belongs to application-view
This makes it easier to maintain the listview, and better separates the application list and listview.
* [RAPPS] fix memory leak when cleanup. some renaming are also done
* [RAPPS] move the code adding apps info inside class CAppsListView
* [RAPPS] add table view, create listview and AppInfoDisplay inside it
* [RAPPS] rename INSTALLED_INFO as CInstalledApplicationInfo
now it corresponds with CAvailableApplicationInfo
* [RAPPS] add CInstalledApps
* [RAPPS] optimize the speed when refreshing listview
* [RAPPS] correctly handle Enum for InstalledApps
* [RAPPS] make check all working properly (this also fixes some bugs)
the old version has some bugs when check all items after switching tags in tree-view
* [RAPPS] add handling for wow64
* [RAPPS] use an inline function to replace INSERT_TEXT macro
* [RAPPS] fix the bug that StatusBar won't update when switching tags
* [RAPPS] now TableView always reset bIsAscending in SetDisplayMode
* [RAPPS] rename TableView to ApplicationView
* [RAPPS] now bIsAscending would be reset when switching column in listview
* [RAPPS] add snapshot url support
* [RAPPS] fix snapshot prev window won't update if size not changed
* [RAPPS] fix crash after cancel download
* [RAPPS] show broken-img if failed to create file / make network request
* [RAPPS] create a snapshots folder if it does not exist
* [RAPPS] add a helper function to perform callback
* [RAPPS] check bIsCancelled when handling ERROR_INVALID_HANDLE
* [RAPPS] remove W suffix for AsyncInetDownload
* [RAPPS] add assert for unknown event
* [RAPPS] Improve AsyncInetDownload error handling
* [RAPPS] move DisplayFailed to private, fix crash when cancelling
* [RAPPS] check for ERROR_INTERNET_OPERATION_CANCELLED
* [RAPPS] improve error logging
* [RAPPS] remove \r in error logging
* [RAPPS] rewrite AsyncInet
* add one more layer of window
* using Path* API to operate path
* always use rappmgr.cab as file name when downloading db. ignore the URL
* add snapshot preview window
* show a broken-image icon when failed to load image
* add a padding between image and content, and make sure always some space is reserved for richedit
* hide the padding if snapshot window does not have a width
* some work to avoid blinking when window resizing
* add WM_PRINTCLIENT handling
- Display the names of the files being TYPEd only if more than one file
has been specified on the command-line, or if a file specification
(with wildcards) is present (even just for one).
These names are displayed on STDERR while the files are TYPEd on
STDOUT, therefore allowing concatenating files by just redirecting
STDOUT to a destination, without corrupting it with the displayed file
names. Also, add a /N option to force not displaying these file names.
- When file specifications (with wildcards) are being processed, silently
ignore any directories matching them. If no corresponding files have
been found, display a file-not-found error.
- When explicitly directory names are specified, don't do any special
treatment; the CreateFile() call will fail and return the appropriate
error.
- Fix the returned errorlevel values.
See https://ss64.com/nt/type.html for more information.
Fixes some cmd_winetests.
- When reading from a file, retrieve its original size so that
we can stop reading it once we are beyond its original ending.
This allows avoiding an infinite read loop in case the output of
the file is redirected back to it.
Fixes CORE-17208
- Move the FileGetString() helper to the only file where it is
actually used.
- Restore any truncated space in the name prefix, before displaying
any error message.
- When trimming the name prefix from "special" characters (spaces, comma
and semicolon), so that e.g. "set ,; ,;FOO" displays all the variables
starting by "FOO", save also a pointer to the original name prefix, that
we will use for variables lookup as well.
This is done, because the SET command allows setting an environment variable
whose name actually contains these characters (e.g. "set ,; ,;FOO=42"),
however, by trimming the characters, doing "set ,; ,;FOO" would not allow
seeing such variables.
With the fix, it is now possible to show them.
That's an actual fact, done on original MS-DOS COMMAND.COM, FreeCOM,
Windows' CMD.EXE, etc., but is strangely undocumented on MSDN documentation.
See https://www.dostips.com/forum/viewtopic.php?t=4436
Fixes some cmd_winetests.
