Fix Windows build and runtime on Python 3.11.4

[AstralStorm]

Fixes:

• Runtime on Python 3.11
• Setuptools, tested with 3.11.4
• Missing pywin32 dependency
• Lock file mishandling on Windows

Not included yet:

• Executable creation, needs bigger rework of either pyinstaller or py2exe

[p5k369]

Hey @AstralStorm,
thank you for your pull request. Finally somebody addresses the windows os.
Please note that you did not mentioned that you included 312 in pycompat, which is not true atm. Also the supplied directory structure has to be altered or a different approach on building the C parts has to be implemented (getting rid of it would be the maintainers wish I think).
For now and for your pull request that change isn't necessary as far as I can tell.

[p5k369]

Forgot to submit...

[p5k369]

Thank you for your PR. Note that validation for 3.12 is only half the reason, mainly it is because the environment has to be prepared to build the C-extensions otherwise building them will fail. See #16 if you are interested.

[GreenReaper]

Thanks for your work on this, AstralStorm. I got the develop branch to at least run in development mode, but not completely. In the end I just went back to using the old 2.x install to actually calibrate this new system, but I thought I'd mention where I got to.

The readme is (understandably) a little focused towards Linux, but I figured out that I needed the MS Build Tools with Visual C++ compiler and the Windows SDK (when io.h was not found).

From a "trying to get this working without any python dev experience" perspective, it would've been useful to have pip install pywin32 as part of the instructions for running it, and perhaps also that it would be runnable after installing within the venv with python .venv\Scripts\displaycal - just typing 'displaycal' as suggested didn't seem to do it (I may have done it wrong,,,).

I also encountered 'no module named' errors for comtypes and wmi (so it actually seems to need pip install comtypes wmi - the latter relies on pywin32 - and the attempt to download ArgyllCMS 2.3.1 gave a 400 Bad Request error, on a new Win11 install.

After installing comtypes I still got a warning about the lack of comtypes.gen just after mention of the lock file and before "Starting up..." - perhaps comtypes.client.GetModule required?

Failure to make HTTP requests might also be why when trying to install the id3 colorimeter correction failed, unless I downloaded manually and selected it from a file - the DisplayCAL dl directory mentioned did not appear to exist and running oeminst as admin gave (True, None, None, None) rather than the successful (True, True, None, None).

Unfortunately spawning failed e.g. ambient reading with ArgyllCMS 3.1.0 x64 (x86 didn't seem better) with what looked like a Unicode/string conversion error.

\Desktop\Argyll_V3.1.0\bin\spotread.exe -v -a -x -c1         
Traceback (most recent call last):                                           
  File                                                                       
"\Desktop\displaycal-py3-develop\.venv\Lib\site-packages\DisplayCAL\worker.py", 
line 7077, in exec_cmd                                                       
    self.subprocess = wexpect.spawn(                                         │
                      ^^^^^^^^^^^^^^                                         
  File                                                                       
"\Desktop\displaycal-py3-develop\.venv\Lib\site-packages\DisplayCAL\wexpect.py", 
line 328, in spawn                                                           
    return spawn_windows(                                                    
           ^^^^^^^^^^^^^^                                                    
  File                                                                       
"\Desktop\displaycal-py3-develop\.venv\Lib\site-packages\DisplayCAL\wexpect.py", 
line 1775, in __init__                                                       
    self._spawn(command, args)                                               
  File                                                                       
"\Desktop\displaycal-py3-develop\.venv\Lib\site-packages\DisplayCAL\wexpect.py", 
line 1848, in _spawn                                                         
    self.child_fd = self.wtty.spawn(self.command, self.args, self.env)       
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^       
  File                                                                       
"\Desktop\displaycal-py3-develop\.venv\Lib\site-packages\DisplayCAL\wexpect.py", 
line 2073, in spawn                                                          
    self.startChild(args, env)                                               
  File                                                                       
"\Desktop\displaycal-py3-develop\.venv\Lib\site-packages\DisplayCAL\wexpect.py", 
line 2174, in startChild                                                     
    self.__oproc, _, self.conpid, self.__otid = CreateProcess(               
                                                ^^^^^^^^^^^^^^               
TypeError: Objects of type 'bytes' can not be converted to Unicode.

I tried to add , encoding='utf-8' to the self.subprocess = wexpect.spawn( line 7077 in worker.py, having seen it used, but it looks like the version of wexpect.py is too old (purportedly 2007), at which point I figured I was a little out of my depth.

It seems that dealing with wexpect is on the roadmap. https://pypi.org/project/winpexpect/ seems to have a old commit geertj/winpexpect@126ba45 which claims Python 3 support. However trying to incorporate the changes proposed did not seem to help much with this issue. I guess https://pypi.org/project/wexpect/ / https://github.com/raczben/wexpect is the refactored option?

[lbux]

I tried to add , encoding='utf-8' to the self.subprocess = wexpect.spawn( line 7077 in worker.py, having seen it used, but it looks like the version of wexpect.py is too old (purportedly 2007), at which point I figured I was a little out of my depth.
he refactored option?

I was able to get past this issue by ensuring everything passed into CreateProcess in StartChild was decoded to a string. However, I am now encountering this issue due to what I assume is the subprocess not being able to launch dispread. dispread.exe is never launched and the subprocess times out.

│ The process                                                                  │
│ C:\ProgramData\chocolatey\lib\argyll\tools\Argyll_V3.1.0\bin\dispread.exe    │
│ could not be started.

As a result, I encounter this screen but it shortly closes

Edit:

Idk if this is making things worse or better but instead of converting everything to string from binary, I only converted self.cwd. This time when I launch Calibrate & Profile, I get these errors/messages and the window shown in the screenshot instantly closes:

DisplayCAL: Starting interaction with subprocess
DisplayCAL: Reached EOF (OK)
DisplayCAL: Checking subprocess status
DisplayCAL: Subprocess no longer alive (OK)
dispread exitcode: 1
...aborted.

[lbux]

If anyone else experiences this issue, can you try passing in self.cwd.decode("utf-8") instead of self.cwd to the CreateProcess call in StartChild? and let me know if that lets you advance? I think my instrument is not supported by Argyll.

[515orestis]

I tried to add , encoding='utf-8' to the self.subprocess = wexpect.spawn( line 7077 in worker.py, having seen it used, but it looks like the version of wexpect.py is too old (purportedly 2007), at which point I figured I was a little out of my depth.
he refactored option?

I was able to get past this issue by ensuring everything passed into CreateProcess in StartChild was decoded to a string. However, I am now encountering this issue due to what I assume is the subprocess not being able to launch dispread. dispread.exe is never launched and the subprocess times out.

│ The process                                                                  │
│ C:\ProgramData\chocolatey\lib\argyll\tools\Argyll_V3.1.0\bin\dispread.exe    │
│ could not be started.

As a result, I encounter this screen but it shortly closes

Edit:

Idk if this is making things worse or better but instead of converting everything to string from binary, I only converted self.cwd. This time when I launch Calibrate & Profile, I get these errors/messages and the window shown in the screenshot instantly closes:

DisplayCAL: Starting interaction with subprocess
DisplayCAL: Reached EOF (OK)
DisplayCAL: Checking subprocess status
DisplayCAL: Subprocess no longer alive (OK)
dispread exitcode: 1
...aborted.

If anyone else experiences this issue, can you try passing in self.cwd.decode("utf-8") instead of self.cwd to the CreateProcess call in StartChild? and let me know if that lets you advance? I think my instrument is not supported by Argyll.

Hi,

I made you change and the dispread.exe is not closing

        self.wtty = Wtty(
            timeout=self.timeout,
            codepage=self.codepage,
            columns=self.columns,
            rows=self.rows,
            cwd=self.cwd.decode("utf-8"),
        )

self.cwd --> cwd=self.cwd.decode("utf-8") line 1840 at wexpect.py

but now i am stack at DisplayCal: checking subprocess status

the new windows is not frozen i can mute and un mute, but i am stack at this message the calibration windows goes from white to gray, but to process from there

[515orestis]

also i am also having the bellow warning/ error No module named 'comtypes.gen' . but i have install comtypes

Requirement already satisfied: comtypes in c:\python312\lib\site-packages (1.4.1)

`Connecting to 15411...

Connection to 127.0.0.1:15411 failed: [WinError 10061] No connection could be made because the target machine actively refused it
listening
writing to lock file: port: 56395

No module named 'comtypes.gen'

Starting up...

Audio module: wx 4.2.1

Enumerating display devices and communication ports...`