Over the years, Wine prefixes have gotten bigger and bigger, for a
number of reasons. Creating a new Wine prefix for each application is
still the current recommendation, as despite the best efforts of Wine
developers, some applications still require system-wide workarounds.
This leads to significant bloat for each application installed. With a
MinGW build of Wine without Mono or Gecko, new 32-bit prefixes are over
150 MB, and new 64-bit prefixes are over 300 MB. The vast majority of
these files are byte-for-byte identical to Wine's central DLL copies.
This patch set implements reflink support in Wine via the
copy_file_range syscall. The reasons for selecting copy_file_range over
FICLONE are outlined in patch 2. A previous unpublished version of this
patch set used FICLONERANGE, but it was less convenient to use from
setupapi and has inferior system support.
When reflink is supported by the underlying filesystem, new Wine prefix
sizes with Mono and Gecko disabled are reduced to less than 1 MB. The
resulting Wine prefix is byte-for-byte identical to one created without
reflink, but occupies less space on disk. If hard links or symlinks were
used, if an application such as winetricks writes to a system file, it
would overwrite the central copy. With reflink, the file blocks will be
transparently copied by the Linux kernel so that each Wine prefix can be
independent.
Some files cannot be deduplicated in the current Wine system, as they
are dynamically generated during the Wine prefix installation process.
These include 16-bit fake DLLs and manifest files. In theory, it should
be possible to pre-generate these files, but considering the Wine prefix
size is already reduced to less than 1 MB, the extra space savings are
likely not worth the effort.
v1->v2: Fix/improve errno handling.
v2->v3: Rebase.
Alex Xu (Hello71) (5):
ntdll: add support for IOCTL_COPYCHUNK.
kernelbase: use IOCTL_COPYCHUNK in CopyFile*
setupapi: Use IOCTL_COPYCHUNK, avoid buffering whole file
lmshare.h: define STYPE_TEMPORARY
kernel32/tests: add IOCTL_COPYCHUNK test
configure | 6 ++
configure.ac | 1 +
dlls/kernel32/tests/file.c | 137 +++++++++++++++++++++++++
dlls/kernelbase/file.c | 44 ++++-----
dlls/ntdll/unix/file.c | 121 +++++++++++++++++++++++
dlls/setupapi/fakedll.c | 198 ++++++++++++++++++++-----------------
include/config.h.in | 3 +
include/lmshare.h | 11 ++-
include/winioctl.h | 34 +++++++
9 files changed, 434 insertions(+), 121 deletions(-)
--
2.35.0
Hello all,
I have a Windows software which tries to access dos device name but it
is failing:
0009:Call KERNEL32.CreateFileA(0060f588
"\\\\.\\d6CDE-0",40000000,00000002,00000000,00000003,00000000,00000000)
ret=00b1117f
0009:Call ntdll.RtlInitAnsiString(0060f49c,0060f588 "\\\\.\\d6CDE-0")
ret=7b036296
0009:Ret ntdll.RtlInitAnsiString() retval=0060f49c ret=7b036296
0009:Call ntdll.RtlAnsiStringToUnicodeString(3fff8bf8,0060f49c,00000000)
ret=7b0362fb
0009:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000
ret=7b0362fb
0009:Call ntdll._wcsicmp(3fff8c00 L"\\\\.\\d6CDE-0",7b09d0c0 L"CONIN$")
ret=7b0355c9
0009:Ret ntdll._wcsicmp() retval=fffffff9 ret=7b0355c9
0009:Call ntdll._wcsicmp(3fff8c00 L"\\\\.\\d6CDE-0",7b09d0ce L"CONOUT$")
ret=7b035636
0009:Ret ntdll._wcsicmp() retval=fffffff9 ret=7b035636
0009:Call ntdll.wcsncmp(3fff8c00 L"\\\\.\\d6CDE-0",7b09d644
L"\\\\.\\",00000004) ret=7b035670
0009:Ret ntdll.wcsncmp() retval=00000000 ret=7b035670
0009:Call ntdll.iswalpha(00000064) ret=7b0356cd
0009:Ret ntdll.iswalpha() retval=00000102 ret=7b0356cd
0009:Call ntdll._wcsnicmp(3fff8c08 L"d6CDE-0",7b09d638
L"PIPE\\",00000005) ret=7b0356f5
0009:Ret ntdll._wcsnicmp() retval=fffffff4 ret=7b0356f5
0009:Call ntdll._wcsnicmp(3fff8c08 L"d6CDE-0",7b09d624
L"MAILSLOT\\",00000009) ret=7b03570e
0009:Ret ntdll._wcsnicmp() retval=fffffff7 ret=7b03570e
0009:Call ntdll.RtlIsDosDeviceName_U(3fff8c08 L"d6CDE-0") ret=7b035724
0009:Ret ntdll.RtlIsDosDeviceName_U() retval=00000000 ret=7b035724
0009:Call ntdll.RtlDosPathNameToNtPathName_U(3fff8c00
L"\\\\.\\d6CDE-0",0060f458,00000000,00000000) ret=7b035769
0009:Ret ntdll.RtlDosPathNameToNtPathName_U() retval=00000001
ret=7b035769
0009:Call
ntdll.NtCreateFile(0060f454,40100080,0060f474,0060f460,00000000,00000000,00000002,00000001,00000060,00000000,00000000)
ret=7b03581e
0009:Ret ntdll.NtCreateFile() retval=c0000034 ret=7b03581e
0009:Call ntdll.RtlNtStatusToDosError(c0000034) ret=7b035a11
0009:Ret ntdll.RtlNtStatusToDosError() retval=00000002 ret=7b035a11
0009:Call ntdll.RtlFreeUnicodeString(0060f458) ret=7b03592b
0009:Ret ntdll.RtlFreeUnicodeString() retval=0060f458 ret=7b03592b
0009:Ret KERNEL32.CreateFileA() retval=ffffffff ret=00b1117f
The problem is, that wine doesn't recognize "\\\\.\\d6CDE-0" as valid
DOS device name:
https://github.com/wine-mirror/wine/blob/e909986e6ea5ecd49b2b847f321ad89b2a…
Even when I created the device in HKEY_LOCAL_MACHINE\Software\Wine\Ports
it doesn't allow to open it.
When I patched the corresponding DLL to use COM81 and created the device
in Ports, it works okay (can open the device).
I want to write a patch for ntdll/path.c to recognize my string as DOS
device but I want it to be generic enough to be acceptable.
What approach do you suggest? Can I add a generic match, something like:
"\\\\.\\[^\\]+$" ?
To add some context here, the software is for controlling USB
osclloscope from Hantek:
http://hantek.com/uploadpic/hantek/files/20210731/Hantek-6000_Ver2.2.7_D202…
It installs a driver which creates mentioned "DOS device" and
communicates through it using ioctl.
I am reversing the driver and I'll create a Linux char device to handle
those ioctl calls and talk to the USB device using libusb.
Thanks.
--
S pozdravom / Best regards
Daniel Kucera.