https://bugs.winehq.org/show_bug.cgi?id=51815
Bug ID: 51815 Summary: DocumentProperties broken by last update Product: Wine Version: 6.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: spooler Assignee: wine-bugs@winehq.org Reporter: incubusrk@gmail.com Distribution: ---
Last update cause DocumentProperties return -1 for existing printer. GetLastError return 193
For wine 6.17 and lower it's work correct
https://bugs.winehq.org/show_bug.cgi?id=51815
--- Comment #1 from Konstantin incubusrk@gmail.com --- additional error info showed in console
01a4:err:winspool:DocumentPropertiesW Could not load config module for L"PRINTER_NAME"
https://bugs.winehq.org/show_bug.cgi?id=51815
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=51815
--- Comment #2 from Konstantin incubusrk@gmail.com --- Created attachment 70700 --> https://bugs.winehq.org/attachment.cgi?id=70700 Test win32 app
source
wchar_t wname[] = L"PDF"; int modeSize = DocumentPropertiesW(NULL, NULL, wname, NULL, NULL, 0); std::cout << "DocumentPropertiesW: " << modeSize << std::endl;
std::cout << "GetLastError: " << GetLastError() << std::endl;
https://bugs.winehq.org/show_bug.cgi?id=51815
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
--- Comment #3 from Jacek Caban jacek@codeweavers.com --- Please attach full +winspool debug output with an application that regressed. Your test case fails for me the same way on Windows and Wine because it depends on a printer named "PDF" be available. If I replace it with an actual printer name, it works.
https://bugs.winehq.org/show_bug.cgi?id=51815
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=51815
--- Comment #4 from Konstantin incubusrk@gmail.com --- Created attachment 70708 --> https://bugs.winehq.org/attachment.cgi?id=70708 logs with +winspool for wine-6.15 and wine-6.18
https://bugs.winehq.org/show_bug.cgi?id=51815
--- Comment #5 from Konstantin incubusrk@gmail.com --- Created attachment 70710 --> https://bugs.winehq.org/attachment.cgi?id=70710 fixed test case
change hardcoded printer name to GetDefaultPrinterW
https://bugs.winehq.org/show_bug.cgi?id=51815
--- Comment #6 from Esme Povirk madewokherd@gmail.com --- This came from the wine-mono report here: https://github.com/madewokherd/wine-mono/issues/120
I later found that the wine-mono tests also show this issue. x86_64.MonoTests.System.Drawing.Printing.PageSettingsTest:CloneTest fails, but x86.MonoTests.System.Drawing.Printing.PageSettingsTest:CloneTest succeeds. So it seems this is 64-bit specific somehow.
The printer name it tries to use is definitely correct.
A winspool log shows an error loading wineps.drv: 010c:warn:winspool:get_config_module Could not load L"C:\windows\system32\spool\drivers\w32x86\3\wineps.drv" 010c:err:winspool:DocumentPropertiesW Could not load config module for L"Canon_MF731C_733C"
So it seems the problem is that it tries to load 32-bit wineps.drv in a 64-bit process.
https://bugs.winehq.org/show_bug.cgi?id=51815
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source
--- Comment #7 from Esme Povirk madewokherd@gmail.com --- The bug can be even more easily reproduced by running "wine64 notepad". Pressing the "Properties" button on the Print dialog fails, and other information in print-related dialogs aren't filled in. All of this works fine when running the 32-bit version with "wine notepad".
https://bugs.winehq.org/show_bug.cgi?id=51815
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase
https://bugs.winehq.org/show_bug.cgi?id=51815
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |printing, win64
https://bugs.winehq.org/show_bug.cgi?id=51815
Konstantin incubusrk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|DocumentProperties broken |DocumentProperties broken |by last update |by last update (x64 only)
https://bugs.winehq.org/show_bug.cgi?id=51815
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #8 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 70734 --> https://bugs.winehq.org/attachment.cgi?id=70734 Return in a 64-bit process the x64 printer driver subdirectory.
It looks like the validate_envW function returns currently for 64-bit processes the 32-bit driver subdirectory.
This patch is an attempt to change this and seems to be at least for the "wine64 notepad" case an improvement.
https://bugs.winehq.org/show_bug.cgi?id=51815
--- Comment #9 from Jacek Caban jacek@codeweavers.com --- Yes, it looks like we will need something like that. We should probably make it match setupapi: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/setupapi/dirid.c#l48
https://bugs.winehq.org/show_bug.cgi?id=51815
--- Comment #10 from Esme Povirk madewokherd@gmail.com --- To match setupapi we're going to have to add a printenv_t for arm and arm64. Unsure if there are any other implications of this.
https://bugs.winehq.org/show_bug.cgi?id=51815
--- Comment #11 from Esme Povirk madewokherd@gmail.com --- More importantly we'll need to know what to put in for envname, which I guess requires looking at the registry of a Windows on ARM system under HKLM\System\CurrentControlSet\control\Print\Environments.
https://bugs.winehq.org/show_bug.cgi?id=51815
--- Comment #12 from Esme Povirk madewokherd@gmail.com --- Based on https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rprn/e81cbc0... it seems "Windows ARM" is an environment name but that doesn't tell us which one to use for aarch64.
https://bugs.winehq.org/show_bug.cgi?id=51815
--- Comment #13 from Esme Povirk madewokherd@gmail.com --- Well that's interesting. My (amd64) Windows box has a "Windows ARM64" environment in the registry, but not "Windows ARM". And it only has a version 4 driver for that, no version 3.
But, version 4 may actually have some differences in the API, so it's probably not a good idea to switch to that until some application needs it.
So even though it doesn't match real Windows, I think it makes sense to add a version 3 driver for both "Windows ARM" and "Windows ARM64" environments for now.
https://bugs.winehq.org/show_bug.cgi?id=51815
--- Comment #14 from Esme Povirk madewokherd@gmail.com --- I sent patches: https://www.winehq.org/pipermail/wine-devel/2021-October/198617.html https://www.winehq.org/pipermail/wine-devel/2021-October/198618.html
https://bugs.winehq.org/show_bug.cgi?id=51815
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |6e14766ad517cd8387c649d9958 | |f376fbcdc808c
--- Comment #15 from Esme Povirk madewokherd@gmail.com --- Should be fixed in 6.20.
https://bugs.winehq.org/show_bug.cgi?id=51815
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.21.