KiCad 6 is coming! (has arrived!!)

[langwadt]

                   +++ RIP +++  Kicad 6,

I'm still under Win7 with NO MONEY for buying a new computer.
Thanks to all the developers for this brutal ending.

A happy new year to everybody who is still using Win7.

Why would you need a new computer? Just install Windows 10 on the one you have; it does not need more hardware resources. Last I tried, Win 7 license keys were still accepted by Win 10, hence the upgrade is totally free.

If someone feels the need to still use Windows 7 (which has not received security patches for nearly two years now, I believe) for whatever reason, I don't mind. But please don't whine about the fact that new software released today does not support Win 7.

and once you have install win10 you can run any linux stuff in WSL which works very well

[PlainName]

Windows 7 is completely insecure at this point

So what? That has nothing to do with the functionality of running programs. It is not the business of an ECAD suite to worry about system security.

[PlainName]

But when was the last time you saw a software product with good, extensive and complete documentation?

Before a week ago, I wouldn't be able to tell you. But as of last week:

https://www.easydatatransform.com/

Runs out of steam in some descriptions in the help (real help, not a link to a web page short list) but tells you why you might want to use an option and not just repeat what the button label says.

[PlainName]

don't whine about the fact that new software released today does not support Win 7

The problem not that it doesn't support Win7, it is that it actively breaks on Win7. It's the difference between "If it works it works, otherwise tough shit" and "might have worked but we're making sure you can't try and find out".

[LazyJack]

Well,  Windows 7 is out of support. So why should we expect any new software support or even run on it? If someone is has no problem running an OS four major releases behind the current, then surely they would not worry about running an EDA suite one major release behind.
Supporting older versions are always a pain in the butt and takes valuable resources away from the current versions. I'd rather have KiCAD developing faster than complain about it not supporting old OSes.

[Cerebus]

don't whine about the fact that new software released today does not support Win 7

The problem not that it doesn't support Win7, it is that it actively breaks on Win7. It's the difference between "If it works it works, otherwise tough shit" and "might have worked but we're making sure you can't try and find out".

My local tame, and very competent, Windows developer says that this kind of thing is actually Microsoft's fault. APIs have appeared, disappeared and changed in such ways that supporting older and current versions of Windows means maintaining more than one branch of your source code. You can't just say "I'll use the Windows 7 API, ignore newer APIs and rely on backwards compatibility to keep it going". There are new features that you must support to have your code run and to support those you must use the new APIs, you can't just call the new APIs for the new features and the old APIs for the old features. (Received wisdom, I'm not competent to debate whether this is the case or not.)

Talking about software development in general, and having done it myself in the past, it is insanity to run parallel branches of source code if you have any way you can avoid doing so. If doing so is necessary to support say less than 5% of users, then I can fully appreciate why a sane bunch of developers would say "Tough luck, if you've a very much older OS, you're stuck with a much older version of the product".

[gnuarm]

don't whine about the fact that new software released today does not support Win 7

The problem not that it doesn't support Win7, it is that it actively breaks on Win7. It's the difference between "If it works it works, otherwise tough shit" and "might have worked but we're making sure you can't try and find out".

I seem to recall one of the reasons for having an OS was to provide a consistent programming interface across different hardware and time.  If the OS itself breaks software over time, that seems to be counter productive.  I suppose it does seem to match the thinking of the day where everything is disposable and it is expected that you throw away the old and just buy the new all the time. 

It seems to me it should be imperative that a new OS not break the old software.  But I think you are talking about a new release of the software not working on the older OS.  That's a different matter. 

Someone referred to Windows 7 as being four versions back from the current.  So Win 10, Win 8, Win 7...  I only count two.  Vista was before 7, right?  Did I miss another named release after Win 7?  Was it Windows Ralph maybe?

[gnuarm]

I have a friend who develops code for browsers to interpret.  They have to support all sorts of old platforms including IE.  Different browsers, different versions, different bugs.  It's a bloody mess. 

I have issues with some company web sites working under Firefox.  Seems they've abandoned FF and tell me to use something else.  So not everyone tries very hard to maintain compatibility.  I thought HTML 5 would work on all browsers, but it seems the coders still like to use "special features", so the leave some browsers behind. 

[langwadt]

don't whine about the fact that new software released today does not support Win 7

The problem not that it doesn't support Win7, it is that it actively breaks on Win7. It's the difference between "If it works it works, otherwise tough shit" and "might have worked but we're making sure you can't try and find out".

I seem to recall one of the reasons for having an OS was to provide a consistent programming interface across different hardware and time.  If the OS itself breaks software over time, that seems to be counter productive.  I suppose it does seem to match the thinking of the day where everything is disposable and it is expected that you throw away the old and just buy the new all the time. 

It seems to me it should be imperative that a new OS not break the old software.  But I think you are talking about a new release of the software not working on the older OS.  That's a different matter. 

yes, if you insist on an old OS, you might be stuck with old software

Someone referred to Windows 7 as being four versions back from the current.  So Win 10, Win 8, Win 7...  I only count two.  Vista was before 7, right?  Did I miss another named release after Win 7?  Was it Windows Ralph maybe?

https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

7,8,8.1,10,11

[JohanH]

Windows 7 is completely insecure at this point

So what? That has nothing to do with the functionality of running programs. It is not the business of an ECAD suite to worry about system security.

It's your business as computer admin. Security wise, not so big deal with an ECAD suite, but possibly other software. If you develop PC or embedded software or remotely control other devices they can become infected. And of course other devices on the same network. I would not trust a business that run computers with Win 7. Win 7 is dead. Deal with it. It's gone. Good riddance.

[gnuarm]

don't whine about the fact that new software released today does not support Win 7

The problem not that it doesn't support Win7, it is that it actively breaks on Win7. It's the difference between "If it works it works, otherwise tough shit" and "might have worked but we're making sure you can't try and find out".

I seem to recall one of the reasons for having an OS was to provide a consistent programming interface across different hardware and time.  If the OS itself breaks software over time, that seems to be counter productive.  I suppose it does seem to match the thinking of the day where everything is disposable and it is expected that you throw away the old and just buy the new all the time. 

It seems to me it should be imperative that a new OS not break the old software.  But I think you are talking about a new release of the software not working on the older OS.  That's a different matter. 

yes, if you insist on an old OS, you might be stuck with old software

Someone referred to Windows 7 as being four versions back from the current.  So Win 10, Win 8, Win 7...  I only count two.  Vista was before 7, right?  Did I miss another named release after Win 7?  Was it Windows Ralph maybe?

https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

7,8,8.1,10,11

I didn't know 8.1 was a "version".  Is 11 a thing?  I thought we were still on 10!  I'm obsolete and didn't know it.  I guess my software will stop running now?  Oh, wait, my software is from 2000, Codewright and Eudora.  I'm safe! 

[JohanH]

  Is 11 a thing?  I thought we were still on 10! 

Most are still on Win 10 (unless they are running Linux or Mac). But I'm already testing software on Win 11 at $day-job.

[PlainName]

My local tame, and very competent, Windows developer says that this kind of thing is actually Microsoft's fault.

Yes, it is one of the tricks Microsoft use to push users to Windows 10. No technical reason for it, just a way of fucking up people that want proper windows with actual borders and discoverable features.

[PlainName]

Windows 7 is completely insecure at this point

So what? That has nothing to do with the functionality of running programs. It is not the business of an ECAD suite to worry about system security.

It's your business as computer admin.

My computer admin says relevant precautions are in place and it is fine.

[ataradov]

I don't get the complaints here. Win has excellent backwards compatibility. Stuff from 1995 still works today.  But they have to introduce new APIs in new versions of windows, and if software uses those APIs, then it will obviously not work on older versions. Sure, you can write software using only APIs from 1995, but why?

[PlainName]

I don't get the complaints here.

Indeed. Perhaps because:

if software uses those APIs, then it will obviously not work on older versions

That's fine. But if it doesn't use those APIs? The complaint is that we are not being allowed to find out, or to provide compatible APIs. Instead, it is being actively broken.

Consider the usual open source licenses which dictate that the user must be able to replace libraries and the like with other compatible ones. That's the entire reason for having the LGPL alongside the GPL, allowing proprietary source to coexist with the principles of open source.

[ataradov]

That's fine. But if it doesn't use those APIs? The complaint is that we are not being allowed to find out, or to provide compatible APIs. Instead, it is being actively broken.

Who is stopping you from providing it? Python could check the version of the OS and provide its own implementation of the missing API if it wants to work on W7. Or not use that API at all.

You will have to rebuild from source, of course, but adding the ability to provide binary code sounds like a non-trivial thing to do. Can you do this with any OS?

[bson]

But if it doesn't use those APIs?

Win7 used CodePage 65001 and had completely fragmented UTF-8 support.  Win10 uses UTF-8 natively and has only partial legacy support for CP65001 using special interfaces intended for things like file conversion and migration to UTF-8.  The two are not compatible, and having to support both is grossly impractical since character set encoding is used everywhere, and this particular MS legacy stuff is not easily encapsulated or abstracted out.  Basically, MS has abandoned CP65001 in favor of UTF-8.  Which is a good technical reason to throw Win7 in the trashbin of history where it belongs.

[JohanH]

My computer admin says relevant precautions are in place and it is fine.

Then you obviously are competent at taking care of those things. But it should not be the default, general advice to most people!

[Quarlo Klobrigney]

And the less knowledgeable folks that just check their mail and look at cat videos. Then comes the call where they say "The computer screen was all black and I couldn't do anything so I powered it off and back on. Now the thing won't do anything for hours now!" How many times have I had that call.

Quote from: dunkemhigh on Today at 02:12:55

Yes, it is one of the tricks Microsoft use to push users to Windows 10. No technical reason for it, just a way of fucking up people that want proper windows with actual borders and discoverable features.

[delfinom]

But if it doesn't use those APIs?

Win7 used CodePage 65001 and had completely fragmented UTF-8 support.  Win10 uses UTF-8 natively and has only partial legacy support for CP65001 using special interfaces intended for things like file conversion and migration to UTF-8.  The two are not compatible, and having to support both is grossly impractical since character set encoding is used everywhere, and this particular MS legacy stuff is not easily encapsulated or abstracted out.  Basically, MS has abandoned CP65001 in favor of UTF-8.  Which is a good technical reason to throw Win7 in the trashbin of history where it belongs.

I'm confused, CP65001 _is_ literally the designation for UTF-8 on Windows 10. It must still be enabled on a per-app basis but it's more capable now. We do in Kicad v6 now tell Windows to always give us CP65001. It converts pretty much all Win32 api over to utf-8 mode and even Windows UI framework functions (which has fixed a few render bugs)

Windows 10 and 11 otherwise still default to UCS16

[gnuarm]

I don't get the complaints here. Win has excellent backwards compatibility. Stuff from 1995 still works today.  But they have to introduce new APIs in new versions of windows, and if software uses those APIs, then it will obviously not work on older versions. Sure, you can write software using only APIs from 1995, but why?

Old software only works by chance, not by design or mandate.  I have some old software that works under Win 10, but just barely.  The File Open dialog is really messed up and many other features of the UI are crippled. 

Microsoft does not offer support for older program interfaces.  In fact, they intentionally end support for some things like help files.  I suppose there is a reason why, but I can't see where this doesn't hurt MS in the end.  I guess it's just a tiny paper cut.  I hope it doesn't get infected.   

[delfinom]

I don't get the complaints here. Win has excellent backwards compatibility. Stuff from 1995 still works today.  But they have to introduce new APIs in new versions of windows, and if software uses those APIs, then it will obviously not work on older versions. Sure, you can write software using only APIs from 1995, but why?

Old software only works by chance, not by design or mandate.  I have some old software that works under Win 10, but just barely.  The File Open dialog is really messed up and many other features of the UI are crippled. 

Microsoft does not offer support for older program interfaces.  In fact, they intentionally end support for some things like help files.  I suppose there is a reason why, but I can't see where this doesn't hurt MS in the end.  I guess it's just a tiny paper cut.  I hope it doesn't get infected.   

The help files system aka CHM had weekly CVEs filed and they threw them in the dumpster. It's bad design dating back to the IE era of development.

I have some old software that works under Win 10, but just barely.  The File Open dialog is really messed up and many other features of the UI are crippled. 

This is an interesting statement because Microsoft intentionally has kept the file open dialogs exactly the same across Windows versions depending on the API you use. So on Windows 10, programs using the Windows 98 era API will get the 98 era file dialog which is awful. Getting the Vista+ dialog requires using the Vista+ API.

[gnuarm]

I don't get the complaints here. Win has excellent backwards compatibility. Stuff from 1995 still works today.  But they have to introduce new APIs in new versions of windows, and if software uses those APIs, then it will obviously not work on older versions. Sure, you can write software using only APIs from 1995, but why?

Old software only works by chance, not by design or mandate.  I have some old software that works under Win 10, but just barely.  The File Open dialog is really messed up and many other features of the UI are crippled. 

Microsoft does not offer support for older program interfaces.  In fact, they intentionally end support for some things like help files.  I suppose there is a reason why, but I can't see where this doesn't hurt MS in the end.  I guess it's just a tiny paper cut.  I hope it doesn't get infected.   

The help files system aka CHM had weekly CVEs filed and they threw them in the dumpster. It's bad design dating back to the IE era of development.

Ok, so you agree that MS does not support older program interfaces and trashes some features intentionally. 

I have some old software that works under Win 10, but just barely.  The File Open dialog is really messed up and many other features of the UI are crippled. 

This is an interesting statement because Microsoft intentionally has kept the file open dialogs exactly the same across Windows versions depending on the API you use. So on Windows 10, programs using the Windows 98 era API will get the 98 era file dialog which is awful. Getting the Vista+ dialog requires using the Vista+ API.

I have no idea what you mean by "exactly the same across Windows versions".  The bottom line is the program has worked under every version of Windows from 95 up to at least Vista.  I think it started crapping out on Win 8, but I'm not certain (I don't have a copy of Win 7 running).  I know it works poorly under Win 10.  So where is the preservation???  When you talk about using an API, you are talking about the application using the API.  I don't think the program has changed anything.  The variable is the version of Windows. 

[delfinom]

I have some old software that works under Win 10, but just barely.  The File Open dialog is really messed up and many other features of the UI are crippled. 

This is an interesting statement because Microsoft intentionally has kept the file open dialogs exactly the same across Windows versions depending on the API you use. So on Windows 10, programs using the Windows 98 era API will get the 98 era file dialog which is awful. Getting the Vista+ dialog requires using the Vista+ API.

I have no idea what you mean by "exactly the same across Windows versions".  The bottom line is the program has worked under every version of Windows from 95 up to at least Vista.  I think it started crapping out on Win 8, but I'm not certain (I don't have a copy of Win 7 running).  I know it works poorly under Win 10.  So where is the preservation???  When you talk about using an API, you are talking about the application using the API.  I don't think the program has changed anything.  The variable is the version of Windows.

Yes, Microsoft has elected to "box in" the file dialogs to APIs. Depending on which API you use, that's the generation of file dialog you get even on Windows 10 which is using the Vista

This page roughly shows you the three generation if dialogs https://www.codeproject.com/Articles/16678/Vista-Goodies-in-C-Using-the-New-Vista-File-Dialog

Your old programs should be using the first, Windows 2000 dialog. It works the same as it always have.

Ok, so you agree that MS does not support older program interfaces and trashes some features intentionally.

Yes, some features that are better off dead. Nobody used those horrible CHM interfaces.