https://bugs.winehq.org/show_bug.cgi?id=38235
--- Comment #3 from Bernhard Übelacker bernhardu@mailbox.org --- I had another look at this issue and the access to HKLM\SYSTEM\MountedDevices maybe just a fallback for e.g. some old windows versions.
So when looking deeper Blindwrite7_setup.exe calls a sub installer: ------ "C:\Program Files\VSO\BlindWrite\7\EzPlay.exe" /install ------
And digging further that tries to install something but loggs just some FIXMEs: ------ trace:setupapi:SetupDiCreateDeviceInfoListExW {ff646f80-8def-11d2-9449-00105a075f6b} 0x2015c (null) (nil) trace:setupapi:SetupDiCreateDeviceInfoW 0x14d478 L"ezplay" {ff646f80-8def-11d2-9449-00105a075f6b} L"ezplay device ..." 0x2015c 1 0x33fa34 trace:setupapi:open_enum_key creating display keys trace:setupapi:SETUPDI_AddDeviceToSet 0x14d478, {ff646f80-8def-11d2-9449-00105a075f6b}, 0, L"ROOT\ezplay\0000", 1 trace:setupapi:SetupDiSetDeviceRegistryPropertyW 0x14d478 0x14d540 8 0x33f8a2 76 trace:setupapi:SetupDiSetDeviceRegistryPropertyW 0x14d478 0x14d540 0 0x33fb60 34 trace:setupapi:SetupDiSetDeviceRegistryPropertyW 0x14d478 0x33fa34 1 0x33fbe0 14 fixme:setupapi:SetupDiCallClassInstaller 25 0x14d478 0x33fa34 ------ (Related bug #33498)
If SetupDiCallClassInstaller is hacked to just return TRUE then another FIXME appears: ------ fixme:newdev:UpdateDriverForPlugAndPlayDevicesW Stub! L"*ezplay" L"C:\users\bernhard\Application Data\ezplay.inf" 0x00000000 ------
Hacking UpdateDriverForPlugAndPlayDevicesW to do SetupInstallFilesFromInfSectionA and SetupInstallServicesFromInfSectionA gives us at least the service that gives no error by a "net start ezplay".
Comparing the registry now to a native installation shows when searching for ezplay following: ------ 1 HKLM\SYSTEM\CurrentControlSet\Control\Class{FF646F80-8DEF-11D2-9449-00105A075F6B}\0000 2 HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses{f0d17319-8bb2-48b8-667b-d5ad0ae03dc0}##?#ROOT#EZPLAY#0000#{f0d17319-8bb2-48b8-667b-d5ad0ae03dc0} 3 HKLM\SYSTEM\CurrentControlSet\Enum\Root\EZPLAY\0000 4 HKLM\SYSTEM\CurrentControlSet\Services\ezplay ------ While 1 2 do not appear in wine at all. 3 has some entries less and a "Phantom" more.
After chaning HKLM\SYSTEM\CurrentControlSet\Enum\Root\EZPLAY\0000 to match the native one and some restarts ... I get in the logfile these traces: ---- 0008:0009:trace:file:CreateFileW L"\\.\ROOT#ezplay#0000#{F0D17319-8BB2-48B8-667B-D5AD0AE03DC0}" GENERIC_READ GENERIC_WRITE creation 3 attributes 0x0 0008:0009:trace:file:RtlDosPathNameToNtPathName_U (L"\\.\ROOT#ezplay#0000#{F0D17319-8BB2-48B8-667B-D5AD0AE03DC0}",0x32f144,(nil),(nil)) 0008:0009:trace:file:RtlGetFullPathName_U (L"\\.\ROOT#ezplay#0000#{F0D17319-8BB2-48B8-667B-D5AD0AE03DC0}" 520 0x32ee84 (nil)) 0008:0009:trace:ntdll:FILE_CreateFile handle=0x32f138 access=c0100000 name=L"\??\ROOT#ezplay#0000#{F0D17319-8BB2-48B8-667B-D5AD0AE03DC0}" objattr=00000040 root=(nil) sec=(nil) io=0x32f13c alloc_size=(nil) attr=00000000 sharing=00000000 disp=1 options=00000060 ea=(nil).0x00000000 0008:0009:warn:file:CreateFileW Unable to create file L"\\.\ROOT#ezplay#0000#{F0D17319-8BB2-48B8-667B-D5AD0AE03DC0}" (status c0000034) 0008:0009:trace:file:CreateFileW returning 0xffffffff ----
So might that be how Blindwrite accesses the devices on todays Windows?