This will notably bring support for DOS mapping with LUID devices
(not yet supported in the kernel, though).
This also reduces complexity (and thus memory usage) with the "history"
thing. Multiple targets are stored in the link target as MULTI_SZ string.
This fixes regressions introduced with kernel32 fixes/rewrites.
This is also done on Windows for backwards compatibility with Windows 3.x/9x.
But, it's also used (i.e. "required") by some installers, like Doom 3 Demo installer and Battlefield 1942 Single Player Demo installer, for successful opening of their Readme file at the end of their installation!
- Add support for LUIDDeviceMapsEnabled;
- Broadcast proper message in case of device removal;
- Use less memory for strings management;
- Make code a bit cleaner.
by using TEB static unicode string (which is already
preallocated).
Also, properly handle RtlUnicodeStringToAnsiString failures.
Finally, make sure output buffer is properly 0 terminated.
CORE-13182 CORE-13196
- Use the correct character height & width.
- Additions: use StringCch*() when initializing the dialog title.
[CONSRV:CONCFG] Minor fixes.
- When retrieving font characteristics in ConCfgReadUserSettings(),
check for NULL/zero values that indicate that we should use default
ones instead.
- Rename 'dwNumSubKeys' into 'dwNumValues'.
This fixes back journal in ReactOS "at low costs". Indeed,
because write are improperly aligned right now, journaling
just fails.
With that patch, Cc will take care of aligning writes and
journal will be written again. Because flush operations
happen at each and every write to the journal, we expect
changes to land on disk quickly (not as quickly as if
they were directly written). But that's a good trade off
between over engineering and fixing a broken feature.
CORE-15973
This will avoid triggering a FAT repair on
unclean FAT volumes.
If dosfstools.fsck works fine in Linux, its
usage on ReactOS triggers worse corruption
than unclean shutdown.
Given I've no time for debugging this, I
kill it off.
CORE-14638
hid.dll and hidparse.sys must understand the same HID preparsed data,
so use the same code in hid.dll and in hidparse.sys
At the same time, this permis implementation of some HidP_* functions.
Interface between both is not anymore the HidParser_* functions, but
the HidP_* functions and the AllocFunction/FreeFunction/DebugFunctions/
ZeroFunction/CopyFunction.
