So that's why python screwed Windows 7

[PlainName]

"Microsoft currently employs Python creator Guido van Rossum"

and from https://www.python.org/psf/members/

"President: Guido van Rossum"

Call me a conspiracy theorist if you want, but this kind of thing is exactly what Microsoft gets up to. They have form for buying up software that runs perfectly well on Windows 7 then making it W8+ only and removing the previous versions from the web.

[ataradov]

Sometimes software needs to use new functionality in the OS to move forward. Especially for the OS that is no longer supported by the vendor.

If you need to be on the old OS, then stick with the old versions of the software too.

What downloads were removed? Here are all the downloads going back to 2001 -  https://www.python.org/downloads/windows/

[free_electron]

it's funny how they wave it away with things like "are people really using these old Os's".  Think about tons of test equipment and factory floor. Many people use python for data collection/processing. you don;t just go about upgrading machinery willy nilly. in many cases it is simply not possible cause the application does not run. That's why we are still dragging along things like windows XP for cash registers...

It's a programming language it should be able to run on windows 2000. (technically nt3.51 .. but that would be really far fetched )

[langwadt]

you want it to run on DOS too? win7 is 13 years old and end of life was 2.5 years ago

[ataradov]

Think about tons of test equipment and factory floor.

Use a version appropriate to the age of equipment. If you are actively updating the software on that equipment, why not update the OS?

you don;t just go about upgrading machinery willy nilly.

Yet you install software willy nilly?

in many cases it is simply not possible cause the application does not run.

Python is one of those applications.

That's why we are still dragging along things like windows XP for cash registers...

That's fine. You probably don't need the latest Python on a cash register either.

[free_electron]

you want it to run on DOS too? win7 is 13 years old and end of life was 2.5 years ago

no, i said windows 2000. same "new technology" base. But i'll take XP.
many other compilers for other languages work run fine and can compile to XP or later. and this isn't even a compiler. it's an interpreted language.

[free_electron]

Use a version appropriate to the age of equipment. If you are actively updating the software on that equipment, why not update the OS?

The machine application may not run on a newer OS. The python scripts you run in parallel may want to use a feature only available in the newer version of python.
Or even the machine hardware may not work on a newer OS and no replacement. Try getting something as silly as a printerport running these days. No modern hardware works at the standard addresses. it's all remapped and the control programs can't deal with it. Modern computers don't even have printerports anymore. PCIx doesn't work. Only a port on the LPC would work and possibly some very esoteric PCI cards. i've been trying at least 7 boards so far. nothing works. Run it on a motherboard with a true printerport and it works. (even on windows 7). anything else doesn't.

Python is one of those applications.

yeah i know. i have lived through the 2.xx to 3.xx nonsense. I had to take on a project made by some guy who made it as part of his university coursework and since he had to learn python for one of his classes he decided it was going to be written in python so he could do his university work during working hours. (he was pursuing a degree while working, so he spent his time learning python on our dime and time)  Once done it got tossed over the wall into my bucket. The thing wouldn't run on 3.xx This thing was using py-visa and some other stuff that hadn't been ported .. i tossed it straight back.

Anyway python is not my circus , not my clowns. But is still find it silly , especially since, as explained in many threads, it all pivots about a little thing. some guy fixed it with a fork and 3 lines of code.

[SiliconWizard]

it's funny how they wave it away with things like "are people really using these old Os's".  Think about tons of test equipment and factory floor. Many people use python for data collection/processing. you don;t just go about upgrading machinery willy nilly. in many cases it is simply not possible cause the application does not run. That's why we are still dragging along things like windows XP for cash registers...

You make a good point here. While for desktop use, they can always use the argument that you gotta upgrade anyway, blah blah... for machines running on Windows (or driven by a PC using Windows with a dedicated software), it's extremely common to have older versions that keep running for a long time. Heck, there are machines still driven by Windows XP or even older. Sometimes the equipment in question is extremely expensive, works completely fine and the company making it may not exist anymore (or may have stopped supporting the machine in question). This is a very common occurence in industrial equipement IME.

But this should be a wake-up call: Python is definitely NOT made for long-term compatibility, never was and likely never will be. Even the whole havoc between version 2 and version 3 should have already shaken the tree. Many companies having developed tools in Python 2 still haven't made the changes for Python 3. Just something to keep in mind.

Yes for now you can still have access to downloads for earlier versions. Who knows for how long. And also, as long as some software you use, relying on Python, doesn't actually *require* a newer version of it.

It's of course a complex management matter. Sure, one piece of software can't keep supporting older OSs, older versions of whatnot they would depend on, forever.
But if you want some chance of having more leeway, you should probably not use "trendy" tools. Just my 2 cents.

[Fredderic]

I would like to know what has actually been changed that requires the newer Win8.1+ libraries.

I read somewhere that it's only the Windows library and GUI support.  The entire core of the Python language — the same core that runs on Linux and MacOS just fine without those Windows-specific libraries — should continue to still work just fine, even if it needs to drop back to "Posix compliant" mode.

For most things I where I want to use the newer Python on my old Win7 laptop, Posix Asyncio is all it needs.  So a "Python Console Core" edition would work just fine.  Anyone know any specific reason that wouldn't have been possible?

Failing that, it really just feels like Microsoft forced the break to push their new Windows versions, counting on that the break would flow through to a LOT of other software that uses Python in one way or another.

[Karel]

Use a version appropriate to the age of equipment. If you are actively updating the software on that equipment, why not update the OS?

The machine application may not run on a newer OS.

Well, that's the fault of the manufacturer of  that machine. The machine vendor should make clear for how long
the hardware is supported. Also, the buyer of that machine should have a plan about what to do when the machine is EOL.

I have absolutely no pittty for companies and engineers that use certain software on their hardware without a plan about
what to do when the software supplier declares it EOL.

You want to stick with an OS from Redmond? Then stick with their forced updates and programmed EOL's and don't whine
if your precious hardware becomes useless. It's the price you pay for doing business.

[2N3055]

I would like to know what has actually been changed that requires the newer Win8.1+ libraries.

I read somewhere that it's only the Windows library and GUI support.  The entire core of the Python language — the same core that runs on Linux and MacOS just fine without those Windows-specific libraries — should continue to still work just fine, even if it needs to drop back to "Posix compliant" mode.

For most things I where I want to use the newer Python on my old Win7 laptop, Posix Asyncio is all it needs.  So a "Python Console Core" edition would work just fine.  Anyone know any specific reason that wouldn't have been possible?

Failing that, it really just feels like Microsoft forced the break to push their new Windows versions, counting on that the break would flow through to a LOT of other software that uses Python in one way or another.

Microsoft haters are just funny...

Old version of Python doesn't work on new OS... New version of Python doesn't work on old OS...
So new python is MADE not compatible with Windows and old python is NOT FIXED for a known problem and it is Windows fault...

Funny logic...

[bd139]

It’s probably because the compiler tool chain only targets CPUs with CMPXCHG16B now. This is required as of windows 8.1.

I doubt it’s some nefarious thing. I mean there’s plenty of nefarious shit that they are doing but this isn’t it.

[PlainName]

Sometimes software needs to use new functionality in the OS to move forward. Especially for the OS that is no longer supported by the vendor.

Yes. But W7 is not like XP and 3.x - the underlying stuff is still the same and much of the new stuff is in things like .net, which gets installed as necessary. Oh, yes, there is the stupid dark scheme and borderless stuff, but that's not something the application has to worry about.

If you need to be on the old OS, then stick with the old versions of the software too.

See that thread about BMW moving towards subscriptions? That would be your answer too I guess - if you don't want to spend your life in debt then don't get a new car. It is stupid to have your attitude when you're being potentially screwed over.

What downloads were removed? Here are all the downloads going back to 2001

Not Python, which they wouldn't be able to do since someone would just fork it and off they go again. But other applications which I have posted about previously. Here's a simple one:

https://www.microsoft.com/en-us/p/paper-defense/9wzdncrdncdl?activetab=pivot:overviewtab

On W7? Won't even let you download to try and run it. Used to be freely downloadable on all the usual suspects and ran on W7 just fine. Now try and find it. Doesn't use anything W10 specific (versions available for x86, x64, Arm).

[Karel]

Sometimes software needs to use new functionality in the OS to move forward. Especially for the OS that is no longer supported by the vendor.

Yes. But W7 is not like XP and 3.x - the underlying stuff is still the same and much of the new stuff is in things like .net, which gets installed as necessary. Oh, yes, there is the stupid dark scheme and borderless stuff, but that's not something the application has to worry about.

W7 is a relic from the past. Better to get over it sooner than later.
Complaining about it is not going to change anything anyway.

[PlainName]

W7 is a relic from the past.

That's irrelevant. Most stuff would still work perfectly well with it (and, indeed, does) if it weren't deliberately made not to work. That's the issue - stuff is being made to not work deliberately, not for any technical reason but purely as a marketing trick by Microsoft.

It is post-hoc obsolescence on the manufacturer's whim. Over in another thread TomTom get minus points (and lost sales) for lifetime updates that are some arbitrary device lifetime, and Garmin get plaudits for have actual real lifetime updates for ancient devices. Yet because y'all like to be contrary and you've succumbed to W10 anyway, somehow actively screwing up working kit is not so bad.

[Karel]

W7 is a relic from the past.

That's irrelevant. Most stuff would still work perfectly well with it (and, indeed, does) if it weren't deliberately made not to work. That's the issue - stuff is being made to not work deliberately, not for any technical reason but purely as a marketing trick by Microsoft.

It is post-hoc obsolescence on the manufacturer's whim. Over in another thread TomTom get minus points (and lost sales) for lifetime updates that are some arbitrary device lifetime, and Garmin get plaudits for have actual real lifetime updates for ancient devices. Yet because y'all like to be contrary and you've succumbed to W10 anyway, somehow actively screwing up working kit is not so bad.

You are barking at the wrong tree. Here, at work, I use Linux and once in a while windows in virtualbox.
My point was, if you need/want windows (for whatever reason), then you need to swallow Redmonds decisions.

Techgiants don't have any moral or ethics, except if it can make them look better AND (as a result) it generates more profit.
So, personally, I try to avoid them like the plague. However, I don't blame people for using (a recent version of) windows because many times it can be a justified business decision.
As long as they don't start whining that they got bitten...

[tszaboo]

Sometimes software needs to use new functionality in the OS to move forward. Especially for the OS that is no longer supported by the vendor.

Yes. But W7 is not like XP and 3.x - the underlying stuff is still the same and much of the new stuff is in things like .net, which gets installed as necessary. Oh, yes, there is the stupid dark scheme and borderless stuff, but that's not something the application has to worry about.

W7 is a relic from the past. Better to get over it sooner than later.
Complaining about it is not going to change anything anyway.

I still run W7 on my desktop at home. It works, and I cannot be bothered to update it.
Some stuff always breaks when I update an OS, some hardware is not supported anymore.
I have W10 on my work PC. It came with that, and everything works.

I used to like doing OS updates when I was 16 years old. Now the computer is just a tool.

[Karel]

Sometimes software needs to use new functionality in the OS to move forward. Especially for the OS that is no longer supported by the vendor.

Yes. But W7 is not like XP and 3.x - the underlying stuff is still the same and much of the new stuff is in things like .net, which gets installed as necessary. Oh, yes, there is the stupid dark scheme and borderless stuff, but that's not something the application has to worry about.

W7 is a relic from the past. Better to get over it sooner than later.
Complaining about it is not going to change anything anyway.

I still run W7 on my desktop at home. It works, and I cannot be bothered to update it.
Some stuff always breaks when I update an OS, some hardware is not supported anymore.
I have W10 on my work PC. It came with that, and everything works.

I liked doing OS updates when I was 16 years old. Now the computer is just a tool.

Good for you (and I really mean that).
The "problem" is that some people continue to use an unsupported OS and start to complain when their favorite
application doesn't support their beloved old OS anymore.

[free_electron]

Well, that's the fault of the manufacturer of  that machine. The machine vendor should make clear for how long
the hardware is supported. Also, the buyer of that machine should have a plan about what to do when the machine is EOL.

i don't agree.
Today you buy a logic analyser and spend 100K+. it runs windows 10. That machine serves you well.
The manufacturer supports the software for 20 years. win 10 will be long gone by then but the machine will go on running happily.
You deploy the viper programming language version 2 and script some things. no need for gui. it does its thing.
15 years from now a serious bug/security vulnerability is discovered in version 2 and version 3 comes along, but doesn't run on win10 anymore...

what do you do ?

I have absolutely no pittty for companies and engineers that use certain software on their hardware without a plan about
what to do when the software supplier declares it EOL.

So you suggest we all ditch python and ban it . We can also ban all other things. i think pencil and paper will probably be supported the longest. maybe a slide rule as well, but the manufacturers of those are slim pickins.

You want to stick with an OS from Redmond? Then stick with their forced updates and programmed EOL's and don't whine
if your precious hardware becomes useless. It's the price you pay for doing business.

you have no choice. machine X comes with Y. the OS/Software is part of the package.

look at the misery currently going on with part shortages. this kind of misery is coming with software.

on the other hand : you should treat these machines as black boxes and not install anything on them. air gap them from the internet. This has been stated many times by the likes of tektronix and HPAK. don't install virus scanners or office on the scope.
it is not a general purpose pc. it is a piece of machinery that happens to run an OS as part of its package.

but there are areas where the computer does not come as part of the package. the computer/os is user supplied. and those are the hard cases where you need to spend a lot of effort to keep em going

[artag]

Python is a pet hate of mine.

Any time I get some python utility off the web, it doesn't work. It's not that it's useless, it's that it always seems to be written for very specific version numbers. Not major ones like 2.7 but some intermediate 3.something that you then have to install.

Isn't there any sort of concept of writing good, portable code in pythonland that will run on some major release instead of a nightly build ?

The recommendation is usually to run it in a python virtual environment.

For development, that's maybe acceptable.

As a solution, it sucks.

As a philosophy of running python tools generally, it double sucks. If it'a an essential of running any python anywhere, then put it in the runtime so any arbitrary script pulls in the right interpreter and runs it in a VE transparently.

What I do not want is a version of the arduino IDE that will only work if I first fire up a virtual python environment to run it in, so the embedded scripts have the right environment. That sucks almost as bad as web programmers.

Every time this happens I get closer to ripping up the python utility and reimplementing in a proper, well-maintained language like C. Then pushing that code as a bug fix to the python repo.


Pythonistas used to like denigrating perl as a write-only language.  I've got news for you : Pythgon is much, much worse. It's write-only not because it's obscure, but because the only place it will run is on a development machine. That is not production-quality programming.

[Karel]

Well, that's the fault of the manufacturer of  that machine. The machine vendor should make clear for how long
the hardware is supported. Also, the buyer of that machine should have a plan about what to do when the machine is EOL.

i don't agree.
Today you buy a logic analyser and spend 100K+. it runs windows 10. That machine serves you well.
The manufacturer supports the software for 20 years. win 10 will be long gone by then but the machine will go on running happily.
You deploy the viper programming language version 2 and script some things. no need for gui. it does its thing.
15 years from now a serious bug/security vulnerability is discovered in version 2 and version 3 comes along, but doesn't run on win10 anymore...

what do you do ?

Blame the person who thought it was a good idea to make your business dependent on some piece of software that is not
backwards supported for the time you intend to use it.
Or accept the risk and buy a new analyzer if necessary and consider it the price you pay for doing business.

I have absolutely no pittty for companies and engineers that use certain software on their hardware without a plan about
what to do when the software supplier declares it EOL.

So you suggest we all ditch python and ban it . We can also ban all other things. i think pencil and paper will probably be supported the longest. maybe a slide rule as well, but the manufacturers of those are slim pickins.

Or you can accept the risk and buy a new analyzer if necessary and consider it the price you pay for doing business.

You want to stick with an OS from Redmond? Then stick with their forced updates and programmed EOL's and don't whine
if your precious hardware becomes useless. It's the price you pay for doing business.

you have no choice. machine X comes with Y. the OS/Software is part of the package.

I was referring to pc's where you do have a choice. If your applications needed for your business require the use of a certain OS,
then check how many years the whole setup is supported and be prepared to replace it when the time comes.

on the other hand : you should treat these machines as black boxes and not install anything on them. air gap them from the internet. This has been stated many times by the likes of tektronix and HPAK. don't install virus scanners or office on the scope.
it is not a general purpose pc. it is a piece of machinery that happens to run an OS as part of its package.

Here I agree.

but there are areas where the computer does not come as part of the package. the computer/os is user supplied. and those are the hard cases where you need to spend a lot of effort to keep em going

I don't agree. Check how many years the whole setup is supported and be prepared to replace it when the time comes.

In other words, think about the future, when and how to replace your machines, instruments, etc. before buying equipment.

[tszaboo]

Python is a pet hate of mine.

Any time I get some python utility off the web, it doesn't work. It's not that it's useless, it's that it always seems to be written for very specific version numbers. Not major ones like 2.7 but some intermediate 3.something that you then have to install.

Isn't there any sort of concept of writing good, portable code in pythonland that will run on some major release instead of a nightly build ?

The recommendation is usually to run it in a python virtual environment.

For development, that's maybe acceptable.

As a solution, it sucks.

As a philosophy of running python tools generally, it double sucks. If it'a an essential of running any python anywhere, then put it in the runtime so any arbitrary script pulls in the right interpreter and runs it in a VE transparently.

What I do not want is a version of the arduino IDE that will only work if I first fire up a virtual python environment to run it in, so the embedded scripts have the right environment. That sucks almost as bad as web programmers.

Every time this happens I get closer to ripping up the python utility and reimplementing in a proper, well-maintained language like C. Then pushing that code as a bug fix to the python repo.


Pythonistas used to like denigrating perl as a write-only language.  I've got news for you : Pythgon is much, much worse. It's write-only not because it's obscure, but because the only place it will run is on a development machine. That is not production-quality programming.

Code: [Select]

pip install pyinstaller

[free_electron]

The "problem" is that some people continue to use an unsupported OS and start to complain when their favorite
application doesn't support their beloved old OS anymore.

That scenario is ok with me. If the application is ported to a newer os ,  i have no problem upgrading the OS.
The reverse is the problem. The os gets updated but the application (or hardware) can no longer run.
The really hard problem is when you have two applications.

problem 1:

X runs on os9 but not on os10
Y runs on os10 but not on os9

problem 2: (happening simultaneously)

The base computer (processor/memory) can run both 9 and 10....
but I/O hardware A is only supported on os9
and I/O hardware B is only supported on OS10

I'm starting to understand why things like IBM Z systems are around and are still sold : long term support. They can run all the way back to ibm360 software. totally different hardware , os , but still fully compatible.

case in point : i'm staring again at my dataman programmer.
i take a modern computer. install windows XP or windows 7 , application runs fine . hardware access works fine on the built-in printer port
i take a slightly more modern machine . But this computer does not come with a printerport anymore. everything else works, but the program cannot find the programmer. Any pci/pcix card i tried so far works as a printer , but not for the programmer. Why ? Because these newer printerport no longer sits at 378 / 278 / 3bc. the PCI devices get remapped to other addresses. There is NO need to do that ! i can take the entire environment ( same OS/application) , drop it on slightly older hardware and it runs. The funny bit is that, if you take that hardware and drop DOS on it the port DOES end up at 378 and works. But run something else on it and the port magically reallocates.  It has something to do with switching between real and protected mode. port works in dos/win98/2000 but not in xp and later. Details are very fuzzy and i have not found a complete answer. The same problem exists on linux. Many people want to run linuxCNC and they hit the same problem. They need to find an older machine with a real printerport (one that sits on the ISA bus now masqueraded as LPC). try anything pci and it's off.

The only solution may be to treat the thing as another black box and make the computer/os part of the system. So i'll end up with one more computer on my shelf to keep around just for when i need the programmer. And no , a new programmer doesn't work. The newer machines do not support the very old devices ( unless you buy a 1000$+ one... but i paid already 1000$+ for the current one. This one replaced another very expensive one DataIO ChipLab, which suffered from the same problem. The control program was DOS only and would not run under windows. But back then windows was started from the DOS prompt so you could switch... they later came with a win98 version but the software was never ported to NT, so as of windows 2000 the programmer was a brick). fortunately somebody wrote a kernel driver to give applications access to the I/O so you could actually run the software on windows XP

[langwadt]

W7 is a relic from the past.

That's irrelevant. Most stuff would still work perfectly well with it (and, indeed, does) if it weren't deliberately made not to work. That's the issue - stuff is being made to not work deliberately, not for any technical reason but purely as a marketing trick by Microsoft.

It is post-hoc obsolescence on the manufacturer's whim. Over in another thread TomTom get minus points (and lost sales) for lifetime updates that are some arbitrary device lifetime, and Garmin get plaudits for have actual real lifetime updates for ancient devices. Yet because y'all like to be contrary and you've succumbed to W10 anyway, somehow actively screwing up working kit is not so bad.

how does it screw up working kit?  if you don't update it works just like it did when you bought it ...

[nctnico]

Think about tons of test equipment and factory floor.

Use a version appropriate to the age of equipment. If you are actively updating the software on that equipment, why not update the OS?

From which world are you? If you have hands on experience with updating an OS you would know that the driver model of Windows has changed a couple of times which makes it impossible to update the OS in many case because there simply isn't a driver for the hardware.

The same goes the other way around. There is quite a bit of software out there that won't run on newer WIndows versions without problems. Windows 10 has some major changes under the hood.

All in all, it is stupid not to support older versions of hardware and OS if you can. Python is actually pretty bad where it comes to any form of compatibility; Python is better to be avoided for any software that needs to be distributed. The KiCad developers have painted themselves into an ugly corner by choosing Python.

[free_electron]

Blame the person who thought it was a good idea to make your business dependent on some piece of software that is not
backwards supported for the time you intend to use it.

ah, is see , so we must all become sootseers, clearvoyants and future predictors. i'll go dust off the old dowsing rod.

Or accept the risk and buy a new analyzer if necessary and consider it the price you pay for doing business.

you can do that with a 5$ screwdriver. replace it every year. expensive machinery should run long time. 4 year old phone : sorry no more updates for you. toss it. but it cost me 1000$ ... so i paid 250$ a year for this thing... no wonder everyone is broke all the time.

Or you can accept the risk and buy a new analyzer if necessary and consider it the price you pay for doing business.

There is no need to buy a new machine. The machine works fine. so does the control program that came with it. The problem is elsewhere

I was referring to pc's where you do have a choice. If your applications needed for your business require the use of a certain OS,
then check how many years the whole setup is supported and be prepared to replace it when the time comes.

back to the dowsing rod then... or, since we are more technical here : a time machine. let's jump 10 years forward , buy the machine there and bring it back, then we know it will work guaranteed for at least 10 years.
Good luck getting an answer from device makers on longevity. Some things are outside of their control as well and they too rely on other systems.

In other words, think about the future, when and how to replace your machines, instruments, etc. before buying equipment.

i thought about it. the answer is simple : machines should keep working forever, as long as i need them, or until i retire, whatever comes first.

buy a screwdriver and 2 years from now they stop making the screws that needs that screwdriver. ok, I'll buy a new one then , no problem. but what i f i need to repair something with the old type screw ? so i'll have it laying around , cluttering up the place. and one day after i toss it i will need it...

Things move too fast. it's all spur of the moment. Release it early, hype it with influencers and social media , throw some crypto and arduino and iot in there for additional cred, and fix the bugs later (or hope it goes obsolete before so we don't have to spend time and money building more releases , we can focus on the next big thing : bilking people out of more money. Actually , let's not hope it goes obsolete. Let's just make it obsolete. If we really want to get rid of the support headache : let's shut down the company and start something new. That seems to be the china model : make it, sell it , dissolve company. We got our money and we don't need to support our customers if we don't exist.

Businesses can write off their large stuff. As a small consumer this becomes a problem. A time and money problem : you're constantly out of both
and as a hobbyist it just makes things less enjoyable , the number of hurdles just goes up and you are dealing with more and more noise to get to the signal.

[Karel]

<cut>

Yeah, I get it, the world is unfair. Get over it.

You decided to buy something that has limited support.
In addition, you install something that is not supported.
After years, that something breaks and suddenly it's somebodyelse's fault.

Back to the topic, what do we pay for Python that we can claim that they should do better?
It's easy to criticize, it's harder to come up with something better.

Personally, I find it astonishing that people grab some free software from the net and then start complaining.
If you don't like it, use something else or find your self another job or hobby...
And no, I'm not a Python fan.

[PlainName]

I think many of you are missing the thrust. I have no real problem with unsupported stuff just not working with new things that work differently. The screwdriver of free_electron might be a good example: it works fine but the screws are no longer made. That's a bummer and I'd be annoyed (and one reason I just purchased a Picoscope rather than a Chinese version-alike), but such is life.

The problem I am railing at is where the screwdriver is made deliberately obsolete. The screws are now made incompatible for no reason other than they won't work with the original screwdriver (but the latest screwdriver which also works with the old screws is fine). Think Dymo tape machines that Dave recently slammed.

But I know Microsoft does that. Since W10 came out they have done their best to kill off W7, and that wouldn't matter a toss if it was just them. If some new software genuinely needed a W10 feature then that's fair enough. But many don't. I have apps that are unsupported on W7 and that's cool - they will either work or not, but I'm not going to complain if they don't.

However, Microsoft are overstepping their brief and doing their best to ensure third-party apps are incompatible just to get people off W7, and it's that aspect that I am railing at. It's not an obsolete OS, it is just unsupported.

Again, think Dymo. How come they get shit thrown at them but with Windows it's the users that get covered in it?

[PlainName]

Back to the topic, what do we pay for Python that we can claim that they should do better?

We are their users (albeit unwittingly when it comes the Kicad). Don't the authors take pride in their work and try to match the needs of their users? Is it not professional-quality work? I am betting at least some of the authors see the ego boost of being involved as decent recompense.

So, why do they bother writing and making it available? Clearly, it is not some backwater hack to scratch a personal itch, so other than some money changing hands (and how much do you think would be needed to be able to say "that doesn't work for me" or "why doesn't it ..."), why do they do it?

If you don't like it, use something else

I do use something else and I don't use it because I can't. If they let me use it I might find it pretty good and switch to it. Do they not want more users or something?

[Karel]

So, why do they bother writing and making it available? Clearly, it is not some backwater hack to scratch a personal itch, so other than some money changing hands (and how much do you think would be needed to be able to say "that doesn't work for me" or "why doesn't it ..."), why do they do it?

Apparently they (KiCad) do it for the people that are willing to use the OS'es that they support.
It's already a lot of work to support three different OS'es.
Asking them to support also an OS that is not supported anymore by the manufacturer and also not
by a critical piece of software (Python) needed by KiCad, doesn't seem reasonable.

[free_electron]

You decided to buy something that has limited support.

well some things are slim picking ... supply, demand, budget ..

In addition, you install something that is not supported.
After years, that something breaks and suddenly it's somebodyelse's fault.

an UPDATE breaks something that works. There is such a thing as backward compatibility...

Back to the topic, what do we pay for Python that we can claim that they should do better?
It's easy to criticize, it's harder to come up with something better.

ahh .. the old open source problem. it has to be free , if you don't like it : you have the source , fork it and fix it.

Personally, I find it astonishing that people grab some free software from the net and then start complaining.

free as in free beer. ain't no such thing... somehow it needs to be paid for. Altruism only goes so far. at the end of the day there needs to be something on your plate to eat.

[james_s]

My solution was to simply stop updating Python. Updating from 2 to 3 was a huge mess but since then things have stabilized and I have not encountered anything that doesn't work with whatever version I have on Win7. More and more though I've been transitioning to Linux which is the only viable path forward that I see. Windows 8 was garbage and 10 and 11 are defective in new and interesting ways. I was forced to use 10 for a while at a former job and it was like a breath of fresh air when my new job issued me a Macbook but that hardware and ecosystem is too limited in selection for my taste when it comes to something I'm spending my own money on.

[PlainName]

Asking them to support also an OS that is not supported anymore by the manufacturer

You're just not getting it, are you? I am NOT asking them to support an OS that.. blah blah. I am merely asking them not to deliverately break it.

Do you not see the difference?

[janoc]

Guys, could we, please, stop spreading FUD and nonsense about Python?

And conflating incompetence of developers using with some sort of inherent misfeature of the language?

- First, distributing applications written in Python - if you are downloading Python scripts, you are doing it wrong. Or rather whoever has published the code (and it is meant to be an application) did. Python can be compiled and packaged into a self-contained executable, as any other Windows application without issues.

There is PyInstaller, there is fbs, there is freeze and probably a few other tools that can be used for that.

If the author of the program you are using didn't do this and is distributing a bunch of .py files with a dependency hell, blame them, not Python. That's like downloading C source code from Github and complaining about the C language conspiracy of Kernighan & co because you need to find and learn to use a compiler.


- Python versioning - again, if some software works only with certain versions of Python, that's hardly Python's fault. The major Python versions are very well backwards compatible, so pretty much anything that runs in 3.0 will work in the current 3.10.5. So just use the current up to date version (or at least something reasonably recent - like 3.8 when 3.10 is current) and you will be fine.

The major break was between Python 2 and 3 - but that's more than 14 years back and everyone had ample time to adjust and update their code. Python 2 has been EOL-ed since 2020.

One exception to this are binary extensions for Python which must be compiled for the matching Python versions (not every minor/patch, there is a defined ABI). However, properly written/setup Python package will handle that for you, including downloading pre-built packages so you don't even need a compiler setup on your own machine (it will compile only if the prebuilt binary isn't available for your version of Python, which is rare).

If this is not set up properly, complain to whoever wrote and published that piece of crap, not Python. Python has all the tooling and infrastructure to support this in place. That's no different than having a C library compiled with wrong options or for a wrong architecture and now one can't use it. Is that somehow fault of C or compiler developers?

However, most Python code does not use/need binary extensions apart from the commonly packaged, standard stuff (parts of Python's standard library, Numpy, Pandas, maybe Tensorflow if you are doing machine learning), etc. I probably didn't have to deal with compiling a Python extension (or even seen one compile as in most cases it is automatic) in at least two years - of daily Python development for work.


- Python's incompatibility with older Windows - that's simply because the toolchains for Windows stopped supporting the older Windows releases. Certainly, one could use old versions of Visual Studio - but that blocks the development of Python (and everything else) on an old version of C/C++, causes a ton of maintenance and support issues (different versions of code need to exist and be supported - a highly nontrivial stuff when you have huge packages like Numpy or Pandas depending on it!). Keep in mind that Python developers don't have unlimited resources.

If an old PC works with an old version of an OS for you - great. But don't expect that everyone else wants/can work like that and that people will support these old systems with current software releases (you can always use an old release, it will work fine) forever, no matter what problems it causes. At least not for free. If you do need such support for old machines for business reasons, you can always pay for it and you will get the stuff built for you.

ActiveState is one of such companies when it comes to Python, for example.


- Concerning Guido van Rossum - he has not been involved with day to day work on Python at least since 2018 when he left his position as the "benevolent dictator for life" and retired. In 2019 he left even the Python Steering Council. He joined Microsoft only later in 2019. Before Microsoft he worked at Google and Dropbox - both huge Python shops.

The first version of Python that is incompatible with Windows 7 is 3.9.0, released in 2020. Long past the time Guido had any decision power or influence on Python development. And the first version that broke XP compatibility was in 3.5.0 released in 2015 - while he was at Dropbox.

It also completely ignores the fact how the decision making in Python development is done - no, it isn't a single person deciding to "break Windows 7" even if they were outright hell-bent on it.

So stop the ridiculous BS conspiracies, please.

[nctnico]

Well, then explain to me why some Python software doesn't run because it depends HARD on particular OS libraries? Getting a Python application to work on Linux is a straight nightmare. And there isn't a good solution to package the libraries together with a Python application. It takes trial and error to figure out what is actually needed.

[janoc]

Well, then explain to me why some Python software doesn't run because it depends HARD on particular OS libraries? Getting a Python application to work on Linux is a straight nightmare. And there isn't a good solution to package the libraries together with a Python application. It takes trial and error to figure out what is actually needed.

Please provide specific examples of what software, which libraries, etc. Otherwise it is just trying to vent and that won't help anyone nor anything.

And I do happen to be Linux user myself - and never had any major issues with Python apps in Linux. The only exception of what could be a nightmare are the various machine learning tools like PyTorch or Tensorflow. But those are terribly designed because they grew out of what were essentially research projects, where the emphasis was on producing data and papers, not maintainable code, specifically in the case of Tensorflow it is a C/C++ library that is wrapped in Python front end. So the result is kinda like building Excel on top of a bunch of Matlab scripts ...

[nctnico]

Well, then explain to me why some Python software doesn't run because it depends HARD on particular OS libraries? Getting a Python application to work on Linux is a straight nightmare. And there isn't a good solution to package the libraries together with a Python application. It takes trial and error to figure out what is actually needed.

Please provide specific examples of what software, which libraries, etc. Otherwise it is just trying to vent and that won't help anyone nor anything.

Publicly available: the various NanoVNA applications written in Python.

But at some of my customers the problems to create distributable software using Python are even bigger. To the extend that software gets distributed as a VM image  .

[janoc]

Publicly available: the various NanoVNA applications written in Python.

Could you give me a specific pointer which one? I am not NanoVNA user so I don't know these.

The official stuff here is distributed as binaries which work fine for me (at least starts - I don't have a NanoVNA to test):
https://nanorfe.com/nanovna-v2-software.html

I have also tried NanoVNA Saver from here:
https://github.com/nanovna/nanovna-saver-v2-support


$ git clone https://github.com/nanovna/nanovna-saver-v2-support.git
$ cd nanovna-saver-v2-support/
$ python -m venv .venv
$ . .venv/bin/activate
$ pip install -r requirements.txt
Collecting scipy
  Using cached scipy-1.8.1-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (41.6 MB)
Collecting pyqt5
  Using cached PyQt5-5.15.7-cp37-abi3-manylinux1_x86_64.whl (8.4 MB)
Collecting pyserial
  Using cached pyserial-3.5-py2.py3-none-any.whl (90 kB)
Collecting numpy
  Using cached numpy-1.23.1-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (17.1 MB)
Collecting PyQt5-sip<13,>=12.11
  Using cached PyQt5_sip-12.11.0-cp38-cp38-manylinux1_x86_64.whl (361 kB)
Collecting PyQt5-Qt5>=5.15.0
  Using cached PyQt5_Qt5-5.15.2-py3-none-manylinux2014_x86_64.whl (59.9 MB)
Installing collected packages: PyQt5-sip, PyQt5-Qt5, numpy, scipy, pyserial, pyqt5
Successfully installed PyQt5-Qt5-5.15.2 PyQt5-sip-12.11.0 numpy-1.23.1 pyqt5-5.15.7 pyserial-3.5 scipy-1.8.1

$ python nanovna-saver.py
NanoVNASaver 0.2.2
Copyright (C) 2019 Rune B. Broberg
This program comes with ABSOLUTELY NO WARRANTY
This program is licensed under the GNU General Public License version 3


(and the program pops up)

And this is building/running the application from source, mind you, not a distributable executable. Moreover, it is an application that has Qt GUI and uses Numpy for number crunching, thus having binary dependencies. No issues at all.

What is important when doing something like this is that you create and perform the installation using a virtual environment (not a VM - Python virtual environment).

That's what these two lines do:

$ python -m venv .venv
$ . .venv/bin/activate


That will ensure that it will put its dependencies and binaries into the .venv folder in the current directory (in my case) and not use whatever libraries you may have installed system-wide (and which could conflict because of incompatible versions, etc.). In my case it is still using system Python 3.8.12 which is fairly old - and no problems at all.

But at some of my customers the problems to create distributable software using Python are even bigger. To the extend that software gets distributed as a VM image  .

Well, that's frankly a bit ridiculous. But I think that points more to the people not being familiar with the tools and ecosystem than any sort of failure or problem with the language.

OTOH, sometimes it is more practical to ship a VM image when you have a ton of things to ship and setup (regardless of whether it is Python or whatever). Start the VM and you are ready to go as opposed to an hour or two spent installing and configuring.

[nctnico]

The problem I typically run into that some of the Python modules need very specific versions of system libraries which may not even exist for Debian because the developer uses Python from Ubuntu.

[janoc]

The problem I typically run into that some of the Python modules need very specific versions of system libraries which may not even exist for Debian because the developer uses Python from Ubuntu.

That sounds a bit weird - that would matter only if the developer actually ships a binary of something - maybe a custom C library that they use from Python.

If you do like I did above - installing the requirements/dependencies into a virtual env using pip - then it should download whatever it needs, completely ignoring whatever you do or don't have on your system (well apart from Python itself). That should cover at least the common dependencies.

If whatever you are installing doesn't have a proper setup.py or requirements.txt or Pipfile to allow that then go and hit the author of that module with something heavy. That's squarely their fault.

[Karel]

Asking them to support also an OS that is not supported anymore by the manufacturer

You're just not getting it, are you? I am NOT asking them to support an OS that.. blah blah. I am merely asking them not to deliverately break it.

Do you not see the difference?

Yes, I see the difference and I feel your pain.
The reality is that you can ask as much as you want but microsoft apparently doesn't care.
What they (microsoft) want is that you switch to W10/W11.
Unfortunately for you, it's their product and they can do with it whatever they want.
Tech giants have no moral or ethics, there only goal is to please their shareholders.

Only drug dealers and software companies call their customers "users".

[SiliconWizard]

Only drug dealers and software companies call their customers "users".

Public services as well. Not that there isn't some occasional resemblance.

[free_electron]

software companies call their customers "users".

you have to watch out when IT/software people start  calling them "Local users" ... internally they write it as LUSER

[nctnico]

The problem I typically run into that some of the Python modules need very specific versions of system libraries which may not even exist for Debian because the developer uses Python from Ubuntu.

That sounds a bit weird - that would matter only if the developer actually ships a binary of something - maybe a custom C library that they use from Python.

If you do like I did above - installing the requirements/dependencies into a virtual env using pip - then it should download whatever it needs, completely ignoring whatever you do or don't have on your system (well apart from Python itself). That should cover at least the common dependencies.

If whatever you are installing doesn't have a proper setup.py or requirements.txt or Pipfile to allow that then go and hit the author of that module with something heavy. That's squarely their fault.

Probably but that doesn't solve my immediate problem. And -if I may move the goal posts a little bit-, that makes it a lot of work to share scripts that are meant to do simple tasks like automating processing measurement data into a graph. I have run into problems getting such relatively simple Python programs to work on different computers as well. Personally I have given up on Python as a software development language because it just is too much hassle to distribute the resulting programs. I do use Python but only for simple scripts to read some data from test equipment.

[janoc]

Probably but that doesn't solve my immediate problem. And -if I may move the goal posts a little bit-, that makes it a lot of work to share scripts that are meant to do simple tasks like automating processing measurement data into a graph. I have run into problems getting such relatively simple Python programs to work on different computers as well. Personally I have given up on Python as a software development language because it just is too much hassle to distribute the resulting programs. I do use Python but only for simple scripts to read some data from test equipment.

Well, if you want to distribute scripts that just display graphs, etc. you have two options:

- Look into Jupyter notebooks. Those are meant to allow distributing documents and simple (and not so simple) programs that are not quite full applications.

If you want your code to be portable and easy to distribute then you can either:

- Use only standard library functionality and make sure dependencies are easy to install - i.e. the install/setup scripts are in place so that it is easy for the user of your code to actually install any dependencies/requirements.

- Compile the whole thing into a binary. Then it is self contained, including dependencies and you don't have the problem. End user of it doesn't even need Python, it is basically a normal executable as anything else.

- Target only a single distribution of Python along with whatever they bundle as dependencies - e.g. Conda. I wouldn't recommend doing this but if you can standardize on it, it could simplify your life.

But without being specific of what exactly do you have problems with it is difficult to help you. 

because it just is too much hassle to distribute the resulting programs.

Well, that's like saying Matlab programs are a hassle to distribute because, gasp, they require Matlab and toolboxes and a license and what not. Sorry but that's just the nature of the beast. I haven't noticed that has stopped Matlab's adoption - and Matlab programs are probably order of magnitude worse written than an average piece of Python code.

You want "simple", so don't want to deal with software packaging and tooling to actually make your application easy to distribute - and at the same time you need external dependencies that are a mess to install because you didn't do your homework and the application isn't set up properly?

That doesn't work. Yes, distributing software is a complex problem. One can either accept it and deal with it (and learn the tools) - or blame the tools but you will hit the same problems with other tooling, because the problem really isn't about the language and tools 

[onsenwombat]

What... what am I missing here? So new versions won't be added under Win7 any more? Big deal, no?
The old stuff still works, and is there for everyone to install, even from their official site? What else is there to ask for? Yes, I know you have your legacy software running in production. It wasn't too long ago when I genuinely had my hands on a WinNT station desperately begging for retirement, but the company couldn't been arsed to port the stuff anywhere, so there it was - running hopefully until the EOL finally hits the floor.
Yes, MS wants to kill Win7 by whatever means they have on their disposal, and that's totally fine even though I absolutely loathe Win10 (and lord knows what kind of seizures I'll be getting from 11 eventually). And yes, such transitions will be hell for some poor developers, but here's the thing. If your system cannot be left alone running without a single update, like that poor WinNT bastard of mine, then you should know from the get-go that you will face platform, OS, and whatnot going obsolete, and need to get your hands dirty. If that puts you in the world of shit, then it was you who got yourself there all along.

[PlainName]

What... what am I missing here?

Half a cup of empathy with a splash of humility.

[eugene]

What... what am I missing here?

Half a cup of empathy with a splash of humility.

I don't know. Remember the old saying "if it's not broke, don't fix it"? The world has become crazy for updating software. But, I know of several machines in industrial settings that are happily running WinXP with whatever software the machine came with. Just don't change anything and it will continue to function (It's even possible to get replacement parts for the old hardware, so make sure the HD is backed up.) Yet people insist on updating software, drivers, even entire operating systems. Why? Just stop doing that.

It's true that some new software won't run on old systems. But if you have an old system with old software that runs well, then just leave it alone. If you need to run new software, then get a newer computer. This is the way it has been for as long as personal computers have existed.

[PlainName]

If you need to run new software, then get a newer computer. This is the way it has been for as long as personal computers have existed.

No, it hasn't. The opposite is the case: Microsoft got where it is, as has Apple, because of backwards compatibility. By contrast, those systems that required thousand-quid hardware investment every time software was updated are... well, can you name one?

There is nothing wrong with my hardware. Other than Microsoft preventing use of the onboard graphics if I don't run Windows 10, of course. The problem there is the hardware is too new!

[eugene]

If you need to run new software, then get a newer computer. This is the way it has been for as long as personal computers have existed.

No, it hasn't. The opposite is the case: Microsoft got where it is, as has Apple, because of backwards compatibility. By contrast, those systems that required thousand-quid hardware investment every time software was updated are... well, can you name one?

Not sure what you're asking. My entire point is to NOT update software beyond the capabilities of the hardware. If the hardware and software are running well together, but things break when you update something (software or hardware) then it's your fault. Don't make the upgrades.

There is nothing wrong with my hardware. Other than Microsoft preventing use of the onboard graphics if I don't run Windows 10, of course. The problem there is the hardware is too new!

Again, I'm not sure I understand. Since you say onboard graphics, I'll assume you bought a computer designed to run Win 10 and now you want to install Win 7. That's like complaining that your new 2022 Vauxhall won't accept parts from your 1999 model. If you want to drive a 1999 Vauxhall, then get one of those.

[PlainName]

Again, I'm not sure I understand. Since you say onboard graphics, I'll assume you bought a computer designed to run Win 10 and now you want to install Win 7.

No, I bought a computer to run Windows 7 which was fine. Then there was a hardware issue so I dropped in a replacement motherboard and CPU. The problem is it's a I7-7700. Windows 7 would be fine with that but Microsoft persuaded Intel not to release drivers that would work on Windows 7. There is nothing special about the graphics hardware or drivers, but since you can't get a working driver for new Intel processors later than I7-6xxx (or AMD, of similar vintage, I think), except for Windows 10, the only option is to use an external card.

So the software is fine. The hardware is fine. Microsoft just think that if I can run hardware this new then I should be using Windows 10, for no technical reason at all. And they go out of their way to enforce that.

Same with NVME SSDs. There are no official Windows 7 drivers. Unfortunately for Microsoft, they did release a driver a long time ago and people made a copy, which is available if you know where to look. Works fine but, again, if you're running hardware new enough to use NVME you must surely be forced to run Windows 10 if you want to use it.

[Karel]

Wasn't that the same when windows vista arrived? Many printers became suddenly obsolete because
HP refused to release printerdrivers for vista for their older printers. Those printers continued to work
fine with a modern Linux distro 

[PlainName]

Vista wasn't compatible with XP, so the drivers would be technically different. That's not the case with W7.

Besides which, no-one in their right minds used Vista 

[nimish]

If you didn't pay for extended support until 2023, that's on you. That's only for security upgrades.

Sucks but there's been replacements for over a decade.

Ask the python and kicad devs for a refund of the $ you spent on work to keep it compatible with 7.

[PlainName]

If you didn't pay for extended support until 2023...

I get the impression you haven't been following this thread properly. The issue is not that I would like support forever and a fortnight. It is merely that I don't want things deliberately broken when, without any action, they would otherwise work.

Which means your comment is probably meant for a different thread since it has no relevance to this one.

[nimish]

If you didn't pay for extended support until 2023...

I get the impression you haven't been following this thread properly. The issue is not that I would like support forever and a fortnight. It is merely that I don't want things deliberately broken when, without any action, they would otherwise work.

Which means your comment is probably meant for a different thread since it has no relevance to this one.

You're complaining that a major (i.e., breaking backwards compat is on the table) update version of software made a decision to remove Windows 7 support, but a) you chose to move to KiCad 6 (and not stick with 5.X like you are with Windows 7) b) you have latched on to the python 3 dependency as the culprit despite it being a core part of KiCad 6's pcbnew and necessary for many of the improved plugins and API, including the footprint wizards.

Next time, read the changelog more carefully and don't assume they dropped compatibility without reason. It's incoherent too, why did you upgrade beyond 5.X yet stick to win 7?

Have you gotten your money back yet?

cf. https://imgflip.com/s/meme/Bike-Fall.jpg

[Karel]

I also don't get it.
You have at least three options:

• stick with KiCad V5 and windows 7
• buy a windows 10 licence or buy a new pc
• use Linux

[johnh]

Dual boot if you need to use windoze software

I also don't get it.
You have at least three options:

• stick with KiCad V5 and windows 7
• buy a windows 10 licence or buy a new pc
• use Linux

[PlainName]

You're complaining that a major (i.e., breaking backwards compat is on the table) update version of software made a decision to remove Windows 7 support

No! Can you not read? I am complaining that they deliberately broke it so it couldn't work anyway. Without the ACTIVE breaking it may well have worked. If it didn't, them's the breaks and such is life, but that's not what happened.

[PlainName]

buy a windows 10 licence or buy a new pc

Not a chance. It is shit and worse than an unsupported W7. I already have it on a laptop and it is loathsome.

[PlainName]

Didn't want to keep bringing this up, but something was nagging at my mind and today I realised what it was.

My PC has a recent i7 with reasonably decent onboard graphics, but I have to use a graphics card with Windows because Microsoft decided they weren't going to support cheapskates who can afford a recent computer but not an upgrade to W10. Thus there are no drivers.

But... Linux works fine. Doesn't give a shit about arbitrary obsolescence. Indeed, there is support in there for all kinds of ancient and no longer available hardware, and it seems to be quite rare that hardware is just dumped on a whim. It seems to me that the sort of support there is attractive to those trying to ween off Windows, or just someone looking to something to get some old stuff working.

So the mindset of the Kicad/Python crew that "hey, it's old, get over it and buy something new" is counter to the perceived view of Linux and OS in general and more like that of Microsoft.

[Karel]

So the mindset of the Kicad/Python crew that "hey, it's old, get over it and buy something new" is counter to the perceived view of Linux and OS in general and more like that of Microsoft.

You are contradicting yourself. The (latest) Linux runs fine also on older hardware which means you can run the latest
KiCad also on older hardware (by using Linux).

[nctnico]

So the mindset of the Kicad/Python crew that "hey, it's old, get over it and buy something new" is counter to the perceived view of Linux and OS in general and more like that of Microsoft.

You are contradicting yourself. The (latest) Linux runs fine also on older hardware which means you can run the latest
KiCad also on older hardware (by using Linux).

You are missing the point here. Which is: why obsolete something 'just because'. And still you'd need to update a Linux box to a recent version which you may not want to do because older software might not be compatible with a newer Linux version. The best way is to always make software as compatible as possible with various OS versions to avoid causing problems for the user.

[PlainName]

So the mindset of the Kicad/Python crew that "hey, it's old, get over it and buy something new" is counter to the perceived view of Linux and OS in general and more like that of Microsoft.

You are contradicting yourself. The (latest) Linux runs fine also on older hardware which means you can run the latest
KiCad also on older hardware (by using Linux).

I am not. You are misunderstanding my point thrust. As Linux is to hardware, Kicad is to software.

[Karel]

The best way is to always make software as compatible as possible with various OS versions to avoid causing problems for the user.

Perfect is the enemy of good.

The best way to get what you want is to offer money. How much did you offer?

Feel free to fork KiCad and start your own variant. If you are right, it shouldn't be too hard to find enough volunteers
to help you. Probably many developers from the KiCad team will follow you. What do you think?

[nctnico]

The best way is to always make software as compatible as possible with various OS versions to avoid causing problems for the user.

Perfect is the enemy of good.

The best way to get what you want is to offer money. How much did you offer?

Feel free to fork KiCad and start your own variant. If you are right, it shouldn't be too hard to find enough volunteers
to help you. Probably many developers from the KiCad team will follow you. What do you think?

I think the Kicad developers are typical software engineers that do no care about common deployment problems for users. IOW: a bunch of amateurs that still need to learn A LOT about writing software to be used in a production environment. Just look at how much convincing and time it took for them to take implementing a parts database properly even serious. And now there is only one guy working on it.

[ataradov]

There is a solution - don't use products from amateurs, nobody is forcing you. Windows compatibility solved.

Maintaining outdated software has costs. You don't have to do a full fork. If you feel like this part could be improved - spend your own time. They have delivered a product that works on current OSes.

[nctnico]

There is a solution - don't use products from amateurs. Windows compatibility solved.

Indeed. That is why I bought Orcad (which works fine on Windows 7 and an older release of Linux) instead of dumping my money into Kicad.

[Karel]

There is a solution - don't use products from amateurs. Windows compatibility solved.

Indeed. That is why I bought Orcad (which works fine on Windows 7 and an older release of Linux) instead of dumping my money into Kicad.

Well then, I guess that's what dunkemhigh should do as well... Let's see what he thinks about that 

[PlainName]

There is a solution - don't use products from amateurs

Can't, though I'd quite like to try it out. Perhaps you missed that bit which is, after all, only the majority of this thread

[PlainName]

There is a solution - don't use products from amateurs. Windows compatibility solved.

Indeed. That is why I bought Orcad (which works fine on Windows 7 and an older release of Linux) instead of dumping my money into Kicad.

Well then, I guess that's what dunkemhigh should do as well... Let's see what he thinks about that 

As you should know, I use Altium. Which works on W7 perfectly happily, but then it's a serious commercial product so you'd expect that. I would quite like to try Kicad again to see what's changed, and if those things address my previous problems with it. Who knows, if I liked it enough I might switch, or at least add it to my repertoire. Doesn't look like I will have the opportunity to find out, though.

[Karel]

If you are used to use windows and don't feel like switching OS, and if you are satisfied with altium,
then why don't you stick with it as long as possible?
No need to try KiCad because you already paid for altium.
And the longer you wait, the more evolved and polished KiCad will be when you give it a try.

[PlainName]

Is there some reason why one shouldn't be inquisitive, look at different things, perhaps try to improve one's lot?

[Karel]

Is there some reason why one shouldn't be inquisitive, look at different things, perhaps try to improve one's lot?

A reason could be that a certain thing you would like to try, doesn't work on your pc / platform / configuration.
So hop on to something else worth trying, maybe something that actually works on your pc?

 

[PlainName]

I think Windows 7 users are typical users that do not care about the amount of time and effort it takes to develop software.

Actually, if you would be bothered to understand this thread instead of knee-jerking your outrage, you'd realise that we would quite like you NOT to make the effort to DELIBERATELY disable something you don't care about. If it were just left alone we would all be happy - you would ignore 'old stuff' and we could see how brill your product is. But someone, somewhere has made specific effort to prevent that. That's what this thread is about.

[PlainName]

Just having a public profile will get you that kind of hassle

[Karel]

They get very nasty and are filled with layers of disgusting entitlement.

Please try to ignore them. Many KiCad users appreciate what the devs are doing and understand that they
have limited resources.

[SiliconWizard]

I agree with dunkemhigh though about the fact there's a line between not being able to support a given platform for lack of resources (yes, additional platforms are additional work, if just for building and testing, and yes, KiCad's dev. means compared to the output are very limited IMO) and *deliberately* (which unfortunately was the idea conveyed by delfinom here, so we're not even making that up, that's clearly expressed, they even go as far as kind of "insulting" Win 7 users - not very cordial if you ask me.)

Now this is again only due to Python here, not directly KiCad, and the only issue is that devs decided (probably a long time ago already) to use Python as a scripting language. Now it's too late and there's nothing much they can do about it. They could disitribute KiCad with an older version of Python though - IIRC, 3.9 is the latest version that's supported on Win 7 - which would work just fine for KiCad's needs. But that would be limiting the future of KiCad and I understand not doing that.

One questionable point is that KiCad (at least the layout editor) just doesn't even work with basic functionalities without Python. I would personally not have based almost "core" functionalities on Python. I don't like this kind of dependency. I would have at most included it as a means for users to write plug-ins, but not for "internal" uses. Just my opinion.

As to KiCad on Win 7 - as I talked about quite a while ago now (a few months I think?), I *have* managed to build it for Win 7 and routinely use it on Win 7 as of late. I've used it enough now to know that it works fine and have not encountered any issue that was specific to this build. I have decided, so far, not to share it for a few reasons. One of them is that I was afraid of getting hostility from the KiCad team. And this thread kind of reinforces this concern. Those of you who'd be interested in discussing that, they can PM me.

And that said, this is not *against* KiCad devs in general, at all. KiCad is great and they are doing an awesome job, especially given the limited means they have. As to the above remark - uh no, Eagle is not better. It's atrocious compared to KiCad 6.

[PlainName]

I don't get paid on my off-hours to be cordial

Hope that was a joke but, in case it wasn't, perhaps you should treat off-hours as being actually off duty, if being cordial is too hard to do without being paid.

[nctnico]

@delfinom: May I add that Kicad's mission statement still says 'The goal of the KiCad project is to provide the best possible cross platform electronics design application for professional electronics designers'. Maybe change  'professional electronics designers' into 'hobbyists' to make sure professional CAD users don't ask for features and/or don't publicly rant at people that offer constructive critisism who might even be interested in a paid -for commercial use- Kicad version. Your rant certainly is not helping your case in any way.

However, my underlying point is not so much supporting Windows 7, but what is the next problem that occurs from switching to 'the latest and gratest'? Was the move to a newer Python (that no longer works on Windows 7) driven by new functionality in Python Kicad could absolutely not do without or just by wanting to use 'the latest and gratest'? In the past I have worked with several programmers that always wanted to use the latest version of whatever without really thinking about what the new version broke in it's wake or what the consequences where for the people using / maintaining systems to run their software. Developing software that is easy to deploy and keep running long term from a system administrator's perspective is also part of software engineering.

[SiliconWizard]

Was the move to a newer Python (that no longer works on Windows 7) driven by new functionality in Python Kicad could absolutely not do without or just by wanting to use 'the latest and gratest'?

As I said (from hands-on experience here), earlier versions of Python 3 work just fine. Actually, a number of Python scripts that are part of the latest source code version are rather old now and they have probably been written for old versions of Python 3.x without having been updated. So no problem with that. But again, I totally understand why they would update Python to a recent (if not last) version. Newer versions contain bug/security fixes. That's understandable.

You may rather either ask Python maintainers why they stopped supporting Windows 7, or - as I hinted - why KiCad maintainers chose to use Python, at your convenience - but again, now it's too late. They have to deal with it.

The latest Python (3.10) I'm using for my Win 7 build is from MSYS2. It works a treat on Win 7. But that's because MSYS2 provides packages for that (and they had to patch Python).
So one reason KiCad maintainers cannot provide Win 7-compatible binaries is that they stopped (officially) supporting builds on MSYS2 on Windows. Which is questionable, but their choice. That's what I use. Now unfortunately, MSYS2 maintainers announced earlier this year that they will stop supporting Win 7 too - they said by the end of this year. We'll see. At the moment, I can still build KiCad 6 with the latest versions of everything (Python, wxWidgets...) This will still be doable even after MSYS2 stops supporting Win 7 as long as KiCad doesn't absolutely *require* newer versions of libraries that may not be available then. But for now, I have built version 6.0.8 to day successfully and will switch to it after some testing.

As to purely the security argument ("we don't support Win 7 anymore because it's now unsecure, blah...") - didn't say that's what KiCad maintainers said, but that's an argument that's very often used by software maintainers - the sheer example of Firefox that still supports it, while web browsers are typically the kind of software for which security is the most problematic - should tell them one thing or two. Just saying.

[PlainName]

I note that Microsoft is pushing W11 now, and it's conceivable that W10 will go the way of W7. If that happens, will Python and Kicad turn off the ability to run on W10?

The comments to an article on The Register are interesting: hardly anyone wants to go to W11. It is very reminiscent of when W10 came out and people didn't want to move from W7, and since this time it requires a hardware upgrade (unless you hack it) the determination to stick may be a bit more robust, leaving more users 'out of support'. Will they still be ignored by Python/Kicad?

[edit: typos]

[Karel]

I don't care as long as they support Linux 

 

[PlainName]

Does it work on out-of-support Linux distros?

[nctnico]

Does it work on out-of-support Linux distros?

Given my experience with the 'portability' of Python my guess is not. Python in itself is such a moving target that using the latest version of any module likely means needing a Linux version that is very recent. When using Debian, which always lags behind due to rigorous testing, you might be out of luck even with the most recent version.

[PlainName]

Python is starting to sound like something to avoid if one isn't a an upgrade freak.

[Karel]

Up until a couple of weeks ago, I was still using Opensuse Leap 15.3 and KiCad was stuck at V5.
So, I moved on to Leap 15.4 and after that I was able to install KiCad V6.
But I had to do it anyway because Leap 15.3 will be soon without support (like your windows 7).

https://en.wikipedia.org/wiki/OpenSUSE#Version_timeline

Ofcourse there's always a period of overlap so that users can migrate without too much stress.

[PlainName]

It's a bit like Oracle, isn't it? They're telling you what you can run it on, not vice versa. Imagine if every vendor did that and you wound up with A needing one version and B refusing to run on that version. You'd end up with an entire machine just to run one particular application.

[JohnG]

You'd end up with an entire machine just to run one particular application.

Hmm, I've seen more than a few of those in my career, sometimes running Windows.

John

[PlainName]

Sure, but then you are really buying the application and it just happens to come on that machine. Kicad, and definitely Python, aren't in that class. Or shouldn't be!

[Karel]

It's a scandal!

[free_electron]

Python is starting to sound like something to avoid if one isn't a an upgrade freak.

remember the 2.7 to 3 problem ? that proved all...

[SiliconWizard]

Other than compatibility with some OSs (at least with official builds, because as I said, MSYS2 provides Python 3.10.7 for Win 7), another more general issue with embedding Python in some application, like KiCad does, are the installed modules.

If for your Python scripts within KiCad, you want to import some module that is not part of the embedded Python distribution, here begin the problems. Installing a particular module for a standalone Python usually involves using pip (as long as pip is installed on your system... and you manage to deal with paths so that you install modules for the right version of Python if you have several installed, which is pretty common). Installing a module in KiCad's embedded Python if it's not already in it is uh. Non-trivial to put it lightly.

Fun stuff.

[ataradov]

Installing a particular module for a standalone Python usually involves using pip

But if you are not using Python for scripting, then there is nothing to install anyway, so you might as well treat the supplied modules as all that is available.

I'm not a fan of Python for scripting, but pretty much all scripting languages suck one way of the other.

[Karel]

Eagle had a good scripting language and because it was C-style syntax it was also easy to learn.
Documentation was also good.

[ataradov]

Sure, creating your own domain specific language is a good option. But it is also a whole project of its own, and if resources are limited, it may not be a viable option.

[PlainName]

You only have to do it once (with a bit of maintenance). Or you could fork a language to keep control over it.

Slickedit, 'only' an editor, has scripting. Indeed, much of its functionality is through its scripting, so it's reasonably easy for the user to modify its behaviour or implement some missing feature (if they can think of one!). AFAIK, most scripts from a decade or more ago work fine - there will be some functions that have changed or become obsolete as the product evolves, of course. Runs on Linux 2.6+, Windows 7+, Mac something or other. Upgrades are complete non-thinkers - the possibility that something will break is very remote indeed. The worst experience I've had in upgrades is when it copies the previous version's config and forgets some setting.

This kind of thing can be done. The thought of Slickedit using jobbing Python horrifies me, to be honest.

[SiliconWizard]

Installing a particular module for a standalone Python usually involves using pip

But if you are not using Python for scripting, then there is nothing to install anyway, so you might as well treat the supplied modules as all that is available.

Not sure I quite got what you meant here. First, KiCad does require Python even if the user doesn't use it for custom scripting (but for this, you can indeed expect the embedded Python to have all requires modules). And otherwise, I guess you meant that the user should only use available modules, and nothing more? That sounds reasonable, but in practice, many Python users expect to have access to the whole Python ecosystem, and the whole benefit of Python is precisely the amount of existing third-party modules. It's problematic to offer Python, yet restrict the user to a set of modules that is not even documented. You can only try to import and see if it chokes or not. Pretty.

Another point is that Python uses kind of a mess of environment variables, so that some users could actually have KiCad's Python point to external Python's installs, which would further mess with compatibility. So in practice, for instance, some users may have access to Python modules on their particular machine that others do not, even with the exact same KiCad version. Yay.

I'm not a fan of Python for scripting, but pretty much all scripting languages suck one way of the other.

I won't deny that. Would have favored Lua though. Much cleaner, much easier to use, a lot fewer dependencies, very small footprint. Of course, it doesn't have the ecosystem that Python has, but see above for the ecosystem in question...

[ataradov]

Not sure I quite got what you meant here.

I mean if they used LUA or TCL or something more standard and stable, then there would not be pip for them. So, if you treat the embedded Python as a thing that also has no standard repositories, then it would be no different than LUA or TCL in that respect.

I think this is more or less standard for embedded Python. Blender is also using it to a huge degree and I think the situation is about the same - you just assume that all the modules that are provided is all you have.

[Karel]

Sunsetting support for Windows 7 / 8.1 in early 2023

https://support.google.com/chrome/thread/185534985/sunsetting-support-for-windows-7-8-1-in-early-2023

[james_s]

Sunsetting support for Windows 7 / 8.1 in early 2023

https://support.google.com/chrome/thread/185534985/sunsetting-support-for-windows-7-8-1-in-early-2023

When that happens I'll sunset my use of Chrome on my Windows machine. Actually I haven't used Chrome in some time, I like Brave much better, I wonder when they will follow.

[SiliconWizard]

I don't know what ending support will mean. Does that mean that they won't build and test Chrome for Win 7 - in which case, Chromium-based browsers, including Chromium itself, have chances to still be supported on Win 7, at least until they won't build compatible binaries anymore. But if Google make changes in the Chromium source code/rely on libraries that are themselves not supported anymore on Win 7, that will be another story.

I use Firefox anyway. And I have Chromium just in case, for the rare websites (unfortunately increasing in number) that are not compatible with Firefox.

[Karel]

I use Firefox anyway. And I have Chromium just in case, for the rare websites (unfortunately increasing in number) that are not compatible with Firefox.

I use Firefox as well and so far, the only website that doesn't play nice with Firefox is google maps.
Fortunately I use OpenStreetMap.

When a website doesn't work in Firefox, it's usually because my security & privacy settings are too strict or
there's some addon (related to privacy) that brakes the website.

[DavidAlfa]

Anyways, screw python, what kind of psychopath creates a language with significant spaces?
Last time I spent a whole afternoon for a f** tab!
Instantly added to my personal blacklist


Only COBOL and  INTERCAL are worse.
First 5 minutes are gold:

[SiliconWizard]

So, there we go!
I've used (occasionally) Chromium on Win 7 without a problem. Binaries available here: https://download-chromium.appspot.com/
Just downloaded the latest today. It can't run on 7 anymore. (Uses kernel32 functions from Win 8+.)

Which likely means it's also the end for Chrome itself (and a lot of the Chromium-based browsers) on Win 7. Cheers!

[PlainName]

Yep. I would sob if I happened to use Chrome, but this is just another reason not to

[Karel]

Looking forward to windows 13 

[Doctorandus_P]

Anyways, screw python, what kind of psychopath creates a language with significant spaces?
Last time I spent a whole afternoon for a f** tab!

I once encountered a bug in MeldMerge, and because I was interested in python back then I decided t have a look at it. It turned out that a few spaces were missing and a line that should have been part of a for loop was executed only once, but after the loop ended.
How do you even format a patch for that?

Another place where the whitespace significance bites me is by using the python shell as a calculator. If you type in " 5+3" (without quotes) you get: "IndentationError: unexpected indent" That's quite annoying when copying and pasting some forumula from elsewhere.

I also thoroughly dislike the ad-hoc -ness of python. The horrible "if something is __main__: " contraption to have an (unfrotuantely not so) decent start point for a program is another annoyance.

Mandatory declaration of variables would be another big improvement. I've spend too much time running a program and debugging only to find out I made a simple typo in some variable and that caused python to just create a new variable. There are also some areas in python where variable declarations are already mandatory. For use of global variables in functions for example. Also when you're appending to a list in for example a for loop, you often have to declare an empty list just to have something to add to.

But these day's there is unfortunately hardly a way around python. It's become the defacto scripting language in a lot of projects.
In C it's quite common to have "beautifiers" to change whitespace and adjust for "coding style". I guess it would not be too hard to write something similar for python which then also adds braces instead of whitespace and can have variable declarations and a syntax check on mistyped variable names. That program would then also be able to spit out "standard python" without those features.

Python as an interpreted language is also "obsoleted". These days the python "interpreter" (sort of) compiles everything before it executes it, and in doing that creates extra garbage files in your directory tree.

[SiliconWizard]

Yep. I would sob if I happened to use Chrome, but this is just another reason not to

Yep but as I said, I only use Chromium (not Chrome) occasionally for web sites that do not work properly on Firefox. And there certainly are more and more of them. Which comes from the fact Chrome has crushed the market and now 99% of web developers do not care about being compatible with Firefox anymore. They don't even test on it.

And as I also said earlier, this likely means that ALL browsers based on Chromium will also stop being supported on Win 7. And most alternative, and decent, browsers these days are Chromium-based (such as Brave), apart from Firefox. And who knows for how long Firefox will support Win 7.

The date is not random. This is coming right at the time when Win 7 extended support is ending. (I think early 2023.)

[PlainName]

A Mint migration has appeared on the horizon.

[JPortici]

Anyways, screw python, what kind of psychopath creates a language with significant spaces?
Last time I spent a whole afternoon for a f** tab!

I once encountered a bug in MeldMerge, and because I was interested in python back then I decided t have a look at it. It turned out that a few spaces were missing and a line that should have been part of a for loop was executed only once, but after the loop ended.
How do you even format a patch for that?

Another place where the whitespace significance bites me is by using the python shell as a calculator. If you type in " 5+3" (without quotes) you get: "IndentationError: unexpected indent" That's quite annoying when copying and pasting some forumula from elsewhere.

I also thoroughly dislike the ad-hoc -ness of python. The horrible "if something is __main__: " contraption to have an (unfrotuantely not so) decent start point for a program is another annoyance.

Mandatory declaration of variables would be another big improvement. I've spend too much time running a program and debugging only to find out I made a simple typo in some variable and that caused python to just create a new variable. There are also some areas in python where variable declarations are already mandatory. For use of global variables in functions for example. Also when you're appending to a list in for example a for loop, you often have to declare an empty list just to have something to add to.

But these day's there is unfortunately hardly a way around python. It's become the defacto scripting language in a lot of projects.
In C it's quite common to have "beautifiers" to change whitespace and adjust for "coding style". I guess it would not be too hard to write something similar for python which then also adds braces instead of whitespace and can have variable declarations and a syntax check on mistyped variable names. That program would then also be able to spit out "standard python" without those features.

Python as an interpreted language is also "obsoleted". These days the python "interpreter" (sort of) compiles everything before it executes it, and in doing that creates extra garbage files in your directory tree.

There is a reason why everybody with common sense writes "Option Explicit" at the beginning of every single visual basic module.
The same reason why if/end if or { } or any other way to define a code block are good and using whitespaces to do the same is completely and utterly retarded. Just the fact that every piece of code i will ever touch will immediately be converted to white spaces / two spaces per tab because "that is the only acceptable way to indent" (TM) should have highlighted the stupidity of the number of whitespaces having any significance in a language.

[SiliconWizard]

A Mint migration has appeared on the horizon.

Well I have Linux installed on a number of machines already. Just not my main workstation.
Reasons are relatively simple (and personal):
- I still find Win 7 more productive for the type of work I do than any Linux desktop environment (so, that's the desktop environment POV.)
- I use a number of Windows-only tools. Fewer and fewer though. And I know there is Wine, and if all hopes fail, I can use a virtual machine. But that's less convenient.
- I occasionally need to test stuff on a Windows environment. Admittedly, now being limited to Win 7 does limit my testing capabilities on Windows, but it's still often good enough for this.
- I use some Firewire hardware that only has limited support on Linux.

None of this is a huge showstopper though, and it's purely personal, although I'm pretty sure a few others are currently in the same boat.

[woofy]

Wine and VM's are not always a viable option. My last Windows software I need to run is Proteus PCB. It's not happy with Wine or in a VM (which needs a license upgrade from Labcenter). After my final win7 machine died I let it go and moved to win10. My current work station dual boots win10 and Mint - now my daily workhorse.

[voltsandjolts]

A Mint migration has appeared on the horizon.

My current work station dual boots win10 and Mint - now my daily workhorse.

Yup, Mint is nice and user-centric.
One day I will detach from Altium and make Mint my daily driver, until then Win10 mostly.
(IIUC Altium + Wine is a no-go so I haven't even tried)

[PlainName]

My current work station dual boots win10 and Mint - now my daily workhorse

How do you work that? I tried dual boot but found I only ever single booted. If there was something I needed the other OS for I just put it off because of the time taken to switch and the lack of whatever that I was using on the first OS. Workflow killer.

[woofy]

My current work station dual boots win10 and Mint - now my daily workhorse

How do you work that? I tried dual boot but found I only ever single booted. If there was something I needed the other OS for I just put it off because of the time taken to switch and the lack of whatever that I was using on the first OS. Workflow killer.

By dual boot, I don't mean both OS's at the same time, I mean selected at startup
I have 500GB ssd and 500 GB nvme drives. Started with a clean install and put Win10 on the ssd. With win10 up and running I installed Mint on the nvme drive. Mint detected the Win10 drive during installation and now presents me with the boot option at startup.
That said, I do have another Win10 in a VM for when I need a quick check on something.

[Ranayna]

My current work station dual boots win10 and Mint - now my daily workhorse

How do you work that? I tried dual boot but found I only ever single booted. If there was something I needed the other OS for I just put it off because of the time taken to switch and the lack of whatever that I was using on the first OS. Workflow killer.

Heh, i had just the same experience in the past. Sooner or later i settled back to Windows, because, let's face it, if you have decades of Windows experience, it is just easier to use.

So when the next attempt to try Linux came up, i went all out. I pulled an image of the running windows as a fallback, but then formatted the drive and only installed Manjaro. I had quite some hiccups early on that would have pushed me back to Windows. But the additional hurdle of needing to restore the image was enough to keep me on Linux. And i am not regretting that.

[PlainName]

My current work station dual boots win10 and Mint - now my daily workhorse

How do you work that? I tried dual boot but found I only ever single booted. If there was something I needed the other OS for I just put it off because of the time taken to switch and the lack of whatever that I was using on the first OS. Workflow killer.

By dual boot, I don't mean both OS's at the same time, I mean selected at startup
I have 500GB ssd and 500 GB nvme drives. Started with a clean install and put Win10 on the ssd. With win10 up and running I installed Mint on the nvme drive. Mint detected the Win10 drive during installation and now presents me with the boot option at startup.
That said, I do have another Win10 in a VM for when I need a quick check on something.

Yes, I realise that. It's just that it would seem to restrict one to either one set of apps or another, and your choice at boot defines what you can, and can't, do until another reboot (which isn't that quick). It would drive me bonkers booting one and then realising I need something on the other. That's a major reason why I installed VMWare many years ago...