Fullscreen HTML5Med Res (??MB)HTML4

Practical Electronics Editorial offices Electron Publishing Tel +61 2 9939 3295 (Australia) Email pe<at>pemag.au Web www.electronpublishing.com Address mail to: Electron Publishing (Australia) PO Box 194, Matraville NSW 2036 Australia Advertising enquiries +61 2 9939 3295 pe<at>pemag.au Editor Nicholas Vinen Publisher Nicholas Vinen Digital subscriptions Stewart Kearn Tel 07918 614662 Online Editor Alan Winstanley Web Systems Kris Thain Production Bao Smith Technical staff Tim Blythman, John Clarke Print subscriptions Practical Electronics Subscriptions PO Box 6337 Bournemouth BH1 9EH Tel 01202 087631 United Kingdom Email pesubs<at>selectps.com Technical enquiries We regret that technical enquiries cannot be answered over the telephone. We are unable to offer any advice on the use, purchase, repair or modification of commercial equipment or the incorporation or modification of designs published in the magazine. Questions about articles or projects should be sent to the editor by email: pe<at>pemag.au Projects and circuits All reasonable precautions are taken to ensure that the advice and data given to readers is reliable. We cannot, however, guarantee it and we cannot accept legal responsibility for it. Some projects and circuits published in Practical Electronics employ voltages that can be lethal. Do not build, test, modify or fix any mains-powered equipment unless you fully understand the safety aspects involved and you use an RCD (GFCI) adaptor. Component supplies Silicon Chip Publications may offer kits or other parts for making our projects, but not in all cases. When kits are not available, readers will need to find and source parts themselves. We advise readers to check that all parts are still available before commencing any project in a back-dated issue. Advertisements Although the proprietors and staff of Practical Electronics take reasonable precautions to protect the interests of readers by ensuring as far as practicable that advertisements are bona fide, the magazine and its publishers cannot give any undertakings in respect of statements or claims made by advertisers, whether these advertisements are printed as part of the magazine, or in inserts. The Publishers regret that under no circumstances will the magazine accept liability for non-receipt of goods ordered, or for late delivery, or for faults in manufacture. Transmitters/bugs/telephone equipment We advise readers that certain items of radio transmitting and telephone equipment which may be advertised in our pages cannot be legally used in the UK. Readers should check the law before buying any transmitting or telephone equipment, as a fine, confiscation of equipment and/or imprisonment can result from illegal use or ownership. The laws vary from country to country; readers should check local laws. 2 Volume 54. No. 12 December 2025 ISSN 2632 573X Editorial The lost art of backward compatibility Part of the reason that Linux is still around after nearly 35 years (it’s gaining in popularity, too) is the very sensible philosophy of “don’t break user space”. This means that when people are adding features to the Linux kernel or making other changes, they shouldn’t prevent pre-existing software from running on the computer. This is also what made DOS and later Windows so popular; you could mostly keep using your software even when you upgraded to a newer version of DOS/Windows because they had very good backward compatibility. And yes, Apple does the same with its computers, even going so far as to use processor emulation to keep older code running on machines using totally different CPUs. However, embedded systems like Arduino do a relatively poor job of this. It’s quite common to upgrade a critical library like an LCD driver, real-time clock interface and so on, and find that your program no longer compiles. This is usually because they decided that their old API was bad in some way and they changed it without regard to breaking existing code. I think this is a real barrier to the adoption of Arduino and other similar systems. Nobody wants to write and test code, deploy it, then find later on that it suddenly no longer works. It’s especially annoying when we’re trying to teach people how to use these systems with example code, as often, they will complain that our examples don’t work. And they are quite right! What we wrote and published was valid at the time, but now the goalposts have been moved, and the compiler throws up its arms at this suddenly invalid code. I think there needs to be a real shift in attitude among software engineers with a recognition that this sort of thing is not acceptable. By all means, they should improve their software interfaces, but they need to find a way to do it that lets old code be. If you don’t like the interface the old function had, create a new one. The legacy function can be a ‘wrapper’ that simply calls the new function with the new syntax. It would be like if you bought a new car, and this year Toyota decided that you should steer with your feet and actuate the accelerator and brake with your hands. We sensibly keep car controls mostly the same from year-to-year, with new controls being added on in other places. Software should adhere to the same philosophy. Nicholas Vinen, Electron Publishing (Australia)* Publisher & Editor, Practical Electronics Magazine * a division of Silicon Chip Publications Pty Ltd. Practical Electronics | December | 2025