There were encoding problems due to non-
Unicode functions.
JIRA issue: CORE-19653
- Adapt _ILGetDrive, _ILGetExtension,
_ILGetFileAttributes, _ILGetFileDate,
_ILGetFileSize, and _ILGetFileType
functions to Unicode.
- Adapt SHELL_IsShortcut and
SHGetFileInfoW functions to Unicode.
- Delete useless _ILSimpleGetText
function.
Windows has all its network drivers inf files in 8.3.
This is an addendum to 0.4.15-dev-52-g 019f21ee1d
which moved us further away from our target.
The commit on its own was a good idea actually to get the inf into the drivers directory
and therefore simplifies adding and excluding drivers more locally (e.g. excluding works by
adding a single hashtag within the specific drivers CMakeLists.txt now).
But that cool feature doesn't require us to move away from our target.
For the record:
The historic netrtpnt.inf and netisa.inf (both 8.3) have been merged to
netne2000.inf (not 8.3) by 0.4.15-dev-2763-g 6924b8ff39
Unification of that was cool too,
but again: 8.3 is superior. Therefore netne.inf for that.
Worst of all: Since the .inf files did contain their filename within a comment also, that means
the historic renaming by the mentioned commit invalidated that comment.
netamd.inf fixed by restoring the ancient filename before 0.4.15-dev-52-g 019f21ee1d
netrtl.inf fixed by restoring the ancient filename before 0.4.15-dev-52-g 019f21ee1d
netne.inf I fixed the comment manually.
CORE-16499
Addendum to commit 0a0e6a9f0 that introduced the problem.
Thanks to Hervé Poussineau for having caught it.
Fixes logic errors, and resulting compilation warnings/errors with GCC
in situations like the following one:
```c
if ((PartitionInfo.PartitionStyle == PARTITION_STYLE_MBR) &&
IsFTPartition(PartitionInfo.Mbr.PartitionType))
{ ... }
```
error: suggest parentheses around '&&' within '||' [-Werror=parentheses]
if ((PartitionInfo.PartitionStyle == PARTITION_STYLE_MBR) &&
cc1: all warnings being treated as errors
Retrial of #3818.
JIRA issue: CORE-16435
The font name is "Microsoft Sans Serif". This font is not Microsoft's font.
This font was not a solution of CORE-16435 but we add this font as a side
product of CORE-16435.
- Add media/fonts/micross.ttf as "Microsoft Sans Serif" font.
- The font height is 14%-shrinked from #3818.
- Add media/fonts/doc/MicrosoftSansSerif/LICENSE_OFL.txt.
- Modify CMakeLists.txt to add the font.
- Improve "J" and "Q".
Version: 3
License: SIL Open Font License 1.1
Reverts #6551
This caused the non-English programs menu
items to not be populated.
JIRA issue: CORE-12328 will have to be
reopened afterwards and approached
differently
JIRA issue: CORE-19652 will get resolved
This is the network driver which is used for MSVPC 2007.
I spotted it during a WIP-backport-experiment of the driver, when compiling with GCC4.7.2, which warned about it.
GCC8.4.0 unfortunately is blind to that on master head, for unknown reasons. Not good.
MSVC github buildbot is also blind to that on master head, for unknown reasons. Not good.
We later found that at least Clang did also warn about it on master head.
winioctl.h:
- Re-organize definitions according to the
NT DDK headers they have been taken from.
- Add missing include guards to some definitions.
- Add missing IsFTPartition() macro.
- Add missing volume definitions.
ntddvol.h:
- Guard definitions duplicated in winioctl.h.
- Add missing NTDDI_VERSION checks.
Note: IOCTL_VOLUME_POST_ONLINE is Win8+.
Our Tahoma font file had a workaround
to make bitmap glyphs working.
This workaround is no more necessary
because new FontForge doesn't have
this bug.
JIRA issue: CORE-9616
- Remove 「いうかひのん」 workaround
(See http://www.electronicdissonance.com/2010/01/raster-fonts-in-visual-studio-2010.html ).
- Remove Traditional Chinese codepage.
Version 0.020 khmz.
Fix IOCTL_MOUNTDEV_LINK_CREATED, IOCTL_MOUNTDEV_LINK_DELETED,
IOCTL_MOUNTDEV_UNIQUE_ID_CHANGE_NOTIFY, to Win2k3+ compatible definitions.
The previous versions of these IOCTLs (in Win2000 and XP) were defined without any access protection.
This was noticed here:
https://community.osr.com/t/ioctl-mountdev-link-created-definition-changed/29428
CORE-15575
In addition, fix a PartitionId assignment copy-paste error in PartitionCreateDevice().
The returned standard UniqueId has the following format:
- Basic volume on MBR disk: disk Mbr.Signature + partition StartingOffset (length: 0x0C)
- Basic volume on GPT disk: "DMIO:ID:" + Gpt.PartitionGuid (length: 0x18)
- Volume on Basic disk (NT <= 4): 8-byte FTDisk identifier (length: 0x08)
- Volume on Dynamic disk (NT 5+): "DMIO:ID:" + dmio VolumeGuid (length: 0x18)
- Super-floppy (single-partition with StartingOffset == 0),
or Removable media: DiskInterfaceName.
- As fallback, we use the VolumeInterfaceName.
References:
- https://winreg-kb.readthedocs.io/en/latest/sources/system-keys/Mounted-devices.html
- https://stackoverflow.com/a/72787681/21852502
- Manual testing on Windows.
CORE-15575
Detect whether the disk is a "super-floppy", which is the name given
to partitionless disk having no MBR, with the unique partition volume
starting at sector offset zero and spanning the whole disk.
The name comes from the fact that at the partitioning level, the disk
"looks like" a large-capacity floppy disk.
This is typically how external removable (USB, ...) drives are
partitioned by default by Windows.
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq?view=windows-11#superfloppy
The kernel-mode functions IoReadPartitionTable() / IoWritePartitionTable()
report the drive layout of a "super-floppy" disk as follows:
an MBR-style disk containing only one single partition starting at the
beginning of the disk (StartingOffset == 0) without hidden sectors, and
its type being FAT16 non-bootable.
The disk NTFT signature is set to 0x00000001.
----
Additional bug fixes to make the feature work reliably:
- Make PartMgrGetDriveLayout() also update the FDO DiskData's
PartitionStyle and Signature/GPT DiskId for consistency (code moved
from PartMgrRefreshDiskData()).
- In FdoIoctlDiskSetDriveLayout[Ex](), if the disk is "super-floppy",
but the user wants to create more than one partition, fail the call.
(In the Ex call, fail also if the partition style changes.)
warning C4267: 'function': conversion from 'size_t' to 'ULONG', possible loss of data'
The OutputBufferLength member that was temporarily stored in
outBufferLength is already a ULONG, and IssueSyncIoControlRequest()
takes the length as a ULONG. So there is no need to use 'size_t' here.
Move SRW and condition variable definitions out of kernel32_vista and into the NDK.
Essentially grabbed from PR #1190
Trying to reduce diff needed for Rtl/ntdll sync.
- Implement IOCTL_VOLUME_QUERY_VOLUME_NUMBER:
See usage example in:
7241cebfa2/mayfield/branches/spr/src/umapps/ndassvc/service/drivematch.cpp (L627)
- Stubplement IOCTL_VOLUME_IS_PARTITION:
The only type of volume we support right now is disk partition
so we just return success. A more robust algorithm would be
to check whether the volume has only one single extent, that
covers the whole partition on which it lies upon. If this is
not the case, return STATUS_UNSUCCESSFUL instead.
I have edited some traslation files for the italian language, as the text
looked robotic in the way senteces were written, or in some cases it used
not-really-fitting synonymous or incorrect spelling. The edited strings
are from varius areas of ReactOS. I hope this contribution makes italian
language less strange to native speakers.
- [ACCESS] Improve Italian (it-IT) translation
- [DESK] Improve Italian (it-IT) translation
- [JOY] Improve Italian (it-IT) translation
- [MAIN] Improve Italian (it-IT) translation
- [SYSDM] Improve Italian (it-IT) translation
- [TIMEDATE] Improve Italian (it-IT) translation
- [ACPPAGE] Improve Italian (it-IT) translation
- [DESKADP] Improve Italian (it-IT) translation
- [DEVCPUX] Add Italian (it-IT) translation
- [FONTEXT] Improve Italian (it-IT) translation
- [ZIPFLDR] Improve Italian (it-IT) translation
- [BROWSEUI] Improve Italian (it-IT) translation
- [USER32] Improve Italian (it-IT) translation
- [CONSRV] Improve Italian (it-IT) translation
- [USERSRV] Improve Italian (it-IT) translation
Reviewed-by: Joachim Henze <joachim.henze@reactos.org>
Reviewed-by: Simone Mario Lombardo <me@simonelombardo.com>
