Windows 7 soon to be no longer functional for 6.0

[Piotr]

@fred4u

KiCad itself is worth upgrading the OS IMO. Even if need to purchase a new workstation machine, one can buy working Win10 machine

I suppose I will end with Windows 10 PC not connected to net for my work, and Windows 7 PC connected to net (for mails and datasheet collecting)

[marekr]

@Piotr

@fred4u

KiCad itself is worth upgrading the OS IMO. Even if need to purchase a new workstation machine, one can buy working Win10 machine

Windows 7 PC connected to net (for mails and datasheet collecting)

…
Please tell me you flipped that and you aren’t intending to put an operating system vulnerable to exploits on a network. There are even unpatched exploits in Outlook 2010 clients (that were common 7 installs) that will execute just by receiving email.

[Piotr]

@marekr

Please tell me you flipped that

No, I didn’t flipped 7 and 10 (if I understand you well).
Currently I am working on 3 PCs:
PC_1. Windows XP with Protel 3,
PC_2. Windows 7 with KiCad 5,
PC_3. Windows 7 for internet communication.
My PC_2 had seen internet only for few minutes 3 years ago just to register Borland Builder 2010.
I have just got info that when I will wont to switch to KiCad 6 I will have to change my PC_2. I see no special problem in it, as I also don’t see special problem in having PC_3 with Windows 7.

@marekr

There are even unpatched exploits in Outlook 2010 clients

Fortunately I don’t use Outlook.

[craftyjon]

The risks of continuing to use Windows 7 for general-purpose computing are well-known and confirmed by any computer security professional you ask.

That said, it’s not KiCad developers’ job to dictate what kind of security decisions people make for themselves. We simply do not have the resources or interest in maintaining support for obsolete systems on a volunteer basis. If running new versions of KiCad on obsolete operating systems is critical to someone’s business, they are welcome to explore one of several options for making that work – it will just have to be done without the support of the core KiCad development team.

[Piotr]

@craftyjon

We simply do not have the resources or interest in maintaining support for obsolete systems on a volunteer basis.

I suppose it is well understand by everyone.

[paulvdh]

@eelik

Each one of us has our own predictable responses.

My response was to switch to Linux, maybe some 5 to 7 years ago, and it has been running happily on 10+ year old hardware. An important part of switching was that I was completely fed up with windoze “upgrading” and obsoleting random parts just to be able to sell their next OS version.
“Python” is also not exactly known for keeping stuff up to date. It took 10 years to obsolete Python V2, and it’s now over a year ago that Python V2 has been officially obsoleted.

I find this discussion quite sad. Go complain to either windoze or to python for their lack of support, but not to KiCad for their efforts of moving forward. I applaud KiCad’s decision. Several of the Footprint wizards for V5.99 have been broken for months, because a patch for them for python V3 has been held back.

Footprint Wizards are throwing Exceptions: S-DIP, SOIC, BGA

At the moment 3 of the Footprint Wizards are throwing an exception on my system immediately after startup (Before changing any parameter). Just: Start Footprint Editor. “New Footprint Using Footprint Wizard” Select one of the wizards for S-DIP, SOIC or BGA. Before making a bug report (My Linux Mint is not officially supported) It would be nice to have some confirmation, preferably also from a different OS and python2. I can’t copy / paste the text, so a screenshot will have to do. The messa…

[Naib]

I guess people could install windows10 in a VM

[fred4u]

In order to do so, “RETAIL” Win10 license is needed. OEM cannot be run on VM.
M$ Licen$ing.

[Qbort]

or linux

[hermit]

If you are using a VM just for Kicad then why Windows 10?

But then again, I don’t see how this announcement generated so much feedback. The development decision is made. Technical issues that aren’t worth trying to get around. Move on.

[Naib]

Sarcasm really doesn’t work on the internet
Windows7 is EOL and python37 is EOL this december. Dropping support for both is sensible.

Those still using windows7 really should consider Linux

[hermit]

I had a fairly cushy networking contract job because some VP at a major corporation didn’t want to pay a vendor to port an application off of XP. They spent more on the mitigation than it would have cost for the port until an in house solution was ready. What may sound bizarre to some is ‘bread and butter’ to someone else. Hence, sarcasm is hard sometimes.

[davidsrsb]

@paulvdh

“Python” is also not exactly known for keeping stuff up to date. It took 10 years to obsolete Python V2, and it’s now over a year ago that Python V2 has been officially obsoleted.

Python team wanted to migrate to V3 many years ago, but large numbers of V2 developers could not be bothered to port over and the users pleaded for extension after extension.

[qu1ck]

@marekr could you update docs in https://dev-docs.kicad.org/build/windows-msvc/ to make sure they cover all dependencies?
I tried following them and cmake gets stuck on not being able to find a swig executable. There is no swig package in vcpkg so I just downloaded one from swig.org and put it on PATH for vcpkg environment in CmakeSettings.json
Then it couldn’t find python from vcpkg so I added ...\vcpkg\installed\x64-windows\tools\python3 to PATH.
Now it finds python but can’t detect wxpython because importing wx is broken. Even if I simply run python.exe from vcpkg and do import wx I get

Python 3.9.0 (default, Jan 22 2021, 08:15:16) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\devtools\vcpkg\installed\x64-windows\tools\python3\lib\site-packages\wx\__init__.py", line 17, in <module>
    from wx.core import *
  File "D:\devtools\vcpkg\installed\x64-windows\tools\python3\lib\site-packages\wx\core.py", line 12, in <module>
    from ._core import *
ImportError: DLL load failed while importing _core: The specified module could not be found.

Even though _core.pyd is right there in D:\devtools\vcpkg\installed\x64-windows\tools\python3\Lib\site-packages\wx next to core.py.

I got wxpython by doing vcpkg install wxpython and my vcpkg is from kicad fork, as per instructions. What am I doing wrong?

I did set VCPKG_DEFAULT_TRIPLET to x64-windows and verified that installed packages are all 64 bit.

UPDATE: I pulled in your vcpkg fix and now build is working. My other points about swig and path still valid.

UPDATE2: spoke too soon about working build. Cmake configuration passes but build fails with a bunch of linker errors unable to find wxString allocators and such.

 LINK: command "C:\PROGRA~2\MICROS~1\2019\COMMUN~1\VC\Tools\MSVC\1428~1.293\bin\Hostx64\x64\link.exe /nologo @CMakeFiles\eeschema_kiface.rsp /out:eeschema\_eeschema.kiface /implib:eeschema\eeschema.lib /pdb:eeschema\_eeschema.pdb /dll /version:0.0 /machine:x64 /DEBUG /MANIFEST:NO /debug /INCREMENTAL" failed (exit code 1120) with the following output:
     Creating library eeschema\eeschema.lib and object eeschema\eeschema.exp
D:\Microcontrollers\Kicad-src\common.lib(project_file.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) private: class std::allocator<class wxString> & __cdecl std::vector<class wxString,class std::allocator<class wxString> >::_Getal(void)" (__imp_?_Getal@?$vector@VwxString@@V?$allocator@VwxString@@@std@@@std@@AEAAAEAV?$allocator@VwxString@@@2@XZ)
...

UPDATE3: I got build to work by reinstalling wxwidgets package. I think I needed it to be recompiled with msvs2019 toolchain (I had vs2017 build tools before).

Now it builds but doesn’t start because it needs a bunch of dlls. I copied the usual suspects and everything I could find using dependency walker but .kiface libs still fail to load and I’m not sure why.

UPDATE4: (last one ) looks like dependency walker lied to me, when I just copied all .dll files from vcpkg/bin to kicad/bin everything started working. I now have a kicad build with python3 on windows

[nickoe]

@qu1ck

…

Now it builds but doesn’t start because it needs a bunch of dlls. I copied the usual suspects and everything I could find using dependency walker but .kiface libs still fail to load and I’m not sure why.

UPDATE4: (last one ) looks like dependency walker lied to me, when I just copied all .dll files from vcpkg/bin to kicad/bin everything started working. I now have a kicad build with python3 on windows

Yes, this is currently expected. For info there is a work-in-progres-almost-complete-more-or-less-complete powershell script in https://gitlab.com/kicad/packaging/kicad-win-builder/-/tree/powershell to help you along, it will package the installer as well.

[Sprig]

Does the newest Win nightly use Python3?
If not, there are at least a couple of bugs that might warrant attention…

[craftyjon]

We have not yet cut over to the MSVC/Python3 builds (this was a “heads up, change coming soon” kind of announcement)

[Sprig]

Well, then, there are least 3 significant bugs I have found in the first 15 minutes of tinkering.

[craftyjon]

Bugs with what? I’m confused about you asking about Python3 vs Python2, but if you have found bugs that relate to Python2, the answer is to just wait for a bit for us to release the Python3 version