In recent years, we've reported on multiple efforts to reverse-engineer Nintendo 64 games into fully decompiled, human-readable C code that can then become the basis for full-fledged PC ports. While the results can be impressive, the decompilation process can take years of painstaking manual effort, meaning only the most popular N64 games are likely to get the requisite attention from reverse engineers.
Now, a newly released tool promises to vastly reduce the amount of human effort needed to get basic PC ports of most (if not all) N64 games. The N64 Recompiled project uses a process known as static recompilation to automate huge swaths of the labor-intensive process of drawing C code out of N64 binaries.
While human coding work is still needed to smooth out the edges, project lead Mr-Wiseguy told Ars that his recompilation tool is "the difference between weeks of work and years of work" when it comes to making a PC version of a classic N64 title. And parallel work on a powerful N64 graphic renderer means PC-enabled upgrades like smoother frame rates, resolution upscaling, and widescreen aspect ratios can be added with little effort.
When Marianne Smith was teaching computer science in 2016 at Flathead Valley Community College, in Kalispell, Mont., the adjunct professor noticed the female students in her class were severely outnumbered, she says.
Smith says she believed the disparity was because girls were not being introduced to science, technology, engineering, and mathematics in elementary and middle school.
Code Girls United
Founded
2018
Headquarters
Kalispell, Mont.
Employees
10
In 2017 she decided to do something to close the gap. The IEEE member started an after-school program to teach coding and computer science.
What began as a class of 28 students held in a local restaurant is now a statewide program run by Code Girls United, a nonprofit Smith founded in 2018. The organization has taught more than 1,000 elementary, middle, and high school students across 38 cities in Montana and three of the state’s Native American reservations. Smith has plans to expand the nonprofit to South Dakota, Wisconsin, and other states, as well as other reservations.
“Computer science is not a K–12 requirement in Montana,” Smith says. “Our program creates this rare hands-on experience that provides students with an experience that’s very empowering for girls in our community.”
The nonprofit was one of seven winners last year of MIT Solve’s Gender Equity in STEM Challenge. The initiative supports organizations that work to address gender barriers. Code Girls United received US $100,000 to use toward its program.
“The MIT Solve Gender Equity in STEM Challenge thoroughly vets all applicants—their theories, practices, organizational health, and impact,” Smith says. “For Code Girls United to be chosen as a winner of the contest is a validating honor.”
From a restaurant basement to statewide programs
When Smith had taught her sons how to program robots, she found that programming introduced a set of logic and communication skills similar to learning a new language, she says.
Those skills were what many girls were missing, she reasoned.
“It’s critical that girls be given the opportunity to speak and write in this coding language,” she says, “so they could also have the chance to communicate their ideas.”
An app to track police vehicles
Last year Code Girls United’s advanced class held in Kalispell received a special request from Jordan Venezio, the city’s police chief. He asked the class to create an app to help the Police Department manage its vehicle fleet.
The department was tracking the location of its police cars on paper, a process that made it challenging to get up-to-date information about which cars were on patrol, available for use, or being repaired, Venezio told the Flathead Beacon.
The objective was to streamline day-to-day vehicle operations. To learn how the department operates and see firsthand the difficulties administrators faced when managing the vehicles, two students shadowed officers for 10 weeks.
The department’s administrators now more easily can see each vehicle’s availability, whether it’s at the repair shop, or if it has been retired from duty.
“It’s a great privilege for the girls to be able to apply the skills they’ve learned in the Code Girls United program to do something like this for the community,” Smith says. “It really brings our vision full circle.”
At first she wasn’t sure what subjects to teach, she says, reasoning that Java and other programming languages were too advanced for elementary school students.
She came across MIT App Inventor, a block-based visual programming language for creating mobile apps for Android and iOS devices. Instead of learning a coding language by typing it, students drag and drop jigsaw puzzle–like pieces that contain code to issue instructions. She incorporated building an app with general computer science concepts such as conditionals, logic flow, and variables. With each concept learned, the students built a more difficult app.
“It was perfect,” she says, “because the girls could make an app and test it the same day. It’s also very visual.”
Once she had a curriculum, she wanted to find willing students, so she placed an advertisement in the local newspaper. Twenty-eight girls signed up for the weekly classes, which were held in a diner. Assisting Smith were Beth Schecher, a retired technical professional; and Liz Bernau, a newly graduated elementary school teacher who taught technology classes. Students had to supply their own laptop.
At the end of the first 18 weeks, the class was tasked with creating apps to enter in the annual Technovation Girls competition. The contest seeks out apps that address issues including animal abandonment, safely reporting domestic violence, and access to mental health services.
The first group of students created several apps to enter in the competition, including ones that connected users to water-filling stations, provided people with information about food banks, and allowed users to report potholes. The group made it to the competition’s semifinals.
The coding program soon outgrew the diner and moved to a computer lab in a nearby elementary school. From there classes were held at Flathead Valley Community College. The program continued to grow and soon expanded to schools in other Montana towns including Belgrade, Havre, Joliet, and Polson.
The COVID-19 pandemic prompted the program to become virtual—which was “oddly fortuitous,” Smith says. After she made the curriculum available for anyone to use via Google Classroom, it increased in popularity.
That’s when she decided to launch her nonprofit. With that came a new curriculum.
What began as a class of 28 students held in a restaurant in Kalispell, Mont., has grown into a statewide program run by Code Girls United. The nonprofit has taught coding and computer science to more than 1,000 elementary, middle, and high school students. Code Girls United
Program expands across the state
Beginner, intermediate, and advanced classes were introduced. Instructors of the weekly after-school program are volunteers and teachers trained by Smith or one of the organization’s 10 employees. The teachers are paid a stipend.
For the first half of the school year, students in the beginner class learn computer science while creating apps.
“By having them design and build a mobile app,” Smith says, “I and the other teachers teach them computer science concepts in a fun and interactive way.”
Once students master the course, they move on to the intermediate and advanced levels, where they are taught lessons in computer science and learn more complicated programming concepts such as Java and Python.
“It’s important to give girls who live on the reservations educational opportunities to close the gap. It’s the right thing to do for the next generation.”
During the second half of the year, the intermediate and advanced classes participate in Code Girls United’s App Challenge. The girls form teams and choose a problem in their community to tackle. Next they write a business plan that includes devising a marketing strategy, designing a logo, and preparing a presentation. A panel of volunteer judges evaluates their work, and the top six teams receive a scholarship of up to $5,000, which is split among the members.
The organization has given out more than 55 scholarships, Smith says.
“Some of the girls who participated in our first education program are now going to college,” she says. “Seventy-two percent of participants are pursuing a degree in a STEM field, and quite a few are pursuing computer science.”
Introducing coding to Native Americans
The program is taught to high school girls on Montana’s Native American reservations through workshops.
Many reservations lack access to technology resources, Smith says, so presenting the program there has been challenging. But the organization has had some success and is working with the Blackfeet reservation, the Salish and Kootenai tribes on the Flathead reservation, and the Nakota and Gros Ventre tribes at Fort Belknap.
The workshops tailor technology for Native American culture. In the newest course, students program a string of LEDs to respond to the drumbeat of tribal songs using the BBC’s Micro:bit programmable controller. The lights are attached to the bottom of a ribbon skirt, a traditional garment worn by young women. Colorful ribbons are sewn horizontally across the bottom, with each hue having a meaning.
The new course was introduced to students on the Flathead reservation this month.
“Montana’s reservations are some of the most remote and resource-limited communities,” Smith says, “especially in regards to technology and educational opportunities.
“It’s important to give girls who live on the reservations educational opportunities to close the gap. It’s the right thing to do for the next generation.”
This post is dedicated to the memory of Niklaus Wirth, a computing pioneer who passed away 1 January 2024. In 1995 he wrote an influential article called “A Plea for Lean Software,” published in Computer, the magazine for members of the IEEE Computer Society, which I read early in my career as an entrepreneur and software developer. In what follows, I try to make the same case nearly 30 years later, updated for today’s computing horrors. A version of this post was originally published on my personal blog, Berthub.eu.
The way we build and ship software these days is mostly ridiculous, leading to apps using millions of lines of code to open a garage door, and other simple programs importing 1,600 external code libraries—dependencies—of unknown provenance. Software security is dire, which is a function both of the quality of the code and the sheer amount of it. Many of us programmers know the current situation is untenable. Many programmers (and their management) sadly haven’t ever experienced anything else. And for the rest of us, we rarely get the time to do a better job.
It is not just you; we are not merely suffering from nostalgia: Software really is very weird today.
Let me briefly go over the terrible state of software security, and then spend some time on why it is so bad. I also mention some regulatory and legislative things going on that we might use to make software quality a priority again. Finally, I talk about an actual useful piece of software I wrote as a proof of concept that one can still make minimal and simple yet modern software.
I hope that this post provides some mental and moral support for suffering programmers and technologists who want to improve things. It is not just you; We are not merely suffering from nostalgia: Software really is very weird today.
Software is now (rightfully) considered so dangerous that we tell everyone not to run it themselves.
Software is now (rightfully) considered so dangerous that we tell everyone not to run it themselves. Instead, you are supposed to leave that to an “X as a service” provider, or perhaps just to “the cloud.” Compare this to a hypothetical situation where cars are so likely to catch fire that the advice is not to drive a car yourself, but to leave that to professionals who are always accompanied by professional firefighters.
The assumption is then that the cloud is somehow able to make insecure software trustworthy. Yet in the past year, we’ve learned that Microsoft’s email platform was thoroughly hacked, including classified government email. (Twice!) There are also well-founded worries about the security of the Azure cloud. Meanwhile, industry darling Okta, which provides cloud-based software that enables user log-in to various applications, got comprehensively owned. This was their second breach within two years. Also, there was a suspicious spate of Okta users subsequently getting hacked.
Clearly, we need better software.
The European Union has launched three pieces of legislation to this effect: NIS2 for important services; the Cyber Resilience Act for almost all commercial software and electronic devices; and a revamped Product Liability Directive that also extends to software. Legislation is always hard, and it remains to be seen if they got it right. But that software security is terrible enough these days to warrant legislation seems obvious.
Why software security is so bad
I want to touch on incentives. The situation today is clearly working well for commercial operators. Making more secure software takes time and is a lot of work, and the current security incidents don’t appear to be impacting the bottom line or stock prices. You can speed up time to market by cutting corners. So from an economic standpoint, what we see is entirely predictable. Legislation could be very important in changing this equation.
The security of software depends on two factors—the density of security issues in the source code and the sheer amount of code accessible by hackers. As the U.S. defense community loved to point out in the 1980s, quantity has a quality all of its own. The reverse applies to software—the more you have of it, the more risks you run.
As a case in point, Apple iPhone users got repeatedly hacked over many years because of the huge attack surface exposed by iMessage. It is possible to send an unsolicited iMessage to an Apple user. The phone will then immediately process that message so it can preview it. The problem is that Apple in its wisdom decided that such unsolicited messages needed to support a vast array of image formats, accidentally including PDFs with weird embedded compressed fonts using an ancient format that effectively included a programming language. So someone could send an unsolicited message to your iPhone that could probe for weaknesses in the rest of the phone.
In this way, attackers were able to benefit from security bugs in the phone’s millions of lines of code. You don’t need a high bug density to find an exploitable hole in millions of lines of code.
Wiping out all the bugs in your code won’t save you from the decision to implement a feature to automatically execute code embedded in documents.
Apple could have prevented this situation by restricting previews to a far smaller range of image formats, or even a single “known good” image format. Apple could have saved themselves an enormous amount of pain simply by exposing fewer lines of their code to attackers. Incidentally, the E.U.’s Cyber Resilience Act explicitly tells vendors to minimize the attack surface.
Apple is (by far) not the worst offender in this field. But it is a widely respected and well-resourced company that usually thinks through what they do. And even they got it wrong by needlessly shipping and exposing too much code.
Could we not write better code?
There are those who think the biggest problem is the quality of the code, expressed in terms of the density of bugs in it. There are many interesting things happening on this front, like the use of memory safe languages like Rust. Other languages are also upping their security game. Fuzzers—test tools that automatically modify inputs to computer programs to find weaknesses and bugs—are also getting ever more advanced.
But many security problems are in the logic underlying the code. For example, the Barracuda email exploit originated in a third-party library that would actually execute code in Excel spreadsheets when they were scanned for viruses. Wiping out all the bugs in your code won’t save you from the decision to implement a feature to automatically execute code embedded in documents.
The state of shipping software
Another problem is that we often don’t know what code we are actually shipping. Software has gotten huge. In 1995 Niklaus Wirth lamented that software had grown to megabytes in size. In his article “A Plea for Lean Software,” he went on to describe his Oberon operating system, which was only 200 kilobytes, including an editor and a compiler. There are now projects that have more than 200 KB for their configuration files alone.
A typical app today is built on Electron JS, a framework that incorporates both Chromium (“Chrome”) and Node.JS, which provides access to tens of thousands of software packages for JavaScript. I estimate just using Electron JS entails at least 50 million lines of code if you include dependencies. Perhaps more. The app meanwhile likely pulls in hundreds or thousands of helper packages. Many packages used will also, by default, snitch on your users to advertisers and other data brokers. Dependencies pull in further dependencies, and exactly what gets included in the build can change on a daily basis, and no one really knows.
If this app controls anything in your house, it will also connect to a software stack over at Amazon, probably also powered by Node.js, also pulling in many dependencies.
We are likely looking at over 50 million active lines of code to open a garage door….
But wait, there’s more. We used to ship software as the output of a compiler, or perhaps as a bunch of files to be interpreted. Such software then had to be installed and configured to work right. Getting your code packaged to ship like this is a lot of work. But it was good work since it forced people to think about what was in their “package.” This software package would then integrate with an operating system and with local services, based on the configuration.
Since the software ran on a different computer than the one it was developed on, people really had to know what they shipped and think it through. And sometimes it didn’t work, leading to the joke where a developer tells the operations people, “Well, it works on my system,” and the retort “Then back up your email, we’re taking your laptop into production!”
This used to be a joke, but these days we often ship software as containers, shipping not only the software itself but also including operating system files to make sure the software runs in a well-known environment. This frequently entails effectively shipping a complete computer disk image. This again vastly expands the amount of code being deployed. Note that you can do good things with containers like Docker (see below), but there are a lot of images over 350 MB on the Docker Hub.
Add it all up and we are likely looking at over 50 million active lines of code to open a garage door, running several operating-system images on multiple servers.
Now, even if all the included dependencies are golden, are we sure that their security updates are making it to your garage door opener app? I wonder how many Electron apps are still shipping with the image processing bug that had Google and Apple scramble to put out updates last year. We don’t even know.
But even worse, it is a known fact that all these dependencies are not golden. The Node.js ecosystem has a comical history of package repositories being taken over, hijacked, or resurrected under the same name by someone else, someone with nefarious plans for your security. PyPI (a Python counterpart of Node.js) has suffered from similar problems. Dependencies always need scrutiny, but no one can reasonably be expected to check thousands of them frequently. But we prefer not to think about this. (Note that you should also not overshoot and needlessly reimplement everything yourself to prevent dependencies. There are very good modules that likely are more secure than what you could type in on your own.)
The world is shipping far too much code where we don’t even know what we ship and we aren’t looking hard enough (or at all) at what we do know we ship.
You can write lean code today
Writing has been called the process by which you find out you don’t know what you are talking about. Actually doing stuff, meanwhile, is the process by which you find out you also did not know what you were writing about.
In a small reenactment of Wirth’s Oberon Project, I too wrote some code to prove a point, and to reassure myself I still know what I am talking and writing about. Can you still make useful and modern software the old way? I decided to try to create a minimalistic but full-featured image-sharing solution that I could trust.
Trifecta is the result. It is actual stand-alone software that lets you use a browser to drag and drop images for easy sharing. It has pained me for years that I had to use imgur for this purpose. Not only does imgur install lots of cookies and trackers in my browser, I also force these trackers onto the people who view the images that I share. If you want to self-host a Web service like this, you also don’t want to get hacked. Most image-sharing solutions I found that you could run yourself are based on huge frameworks that I don’t trust too much for the reasons outlined above.
So, also to make a point, I decided to create a minimalistic but also useful image-sharing solution that I could trust. And more important, that other people could trust as well, because you can check out all Trifecta’s code within a few hours. It consists of 1,600 lines of new source code, plus around five important dependencies.
You end up with a grand total of 3 megabytes of code.
To contrast, one other image-sharing solution ships as a 288-MB Docker image, although admittedly it looks better and has some more features. But not 285 MB worth of them. Another comparison is this Node-based picture-sharing solution, which clocks in at 1,600 dependencies, apparently totaling over 4 million lines of JavaScript.
The world ships too much code, most of it by third parties, sometimes unintended, most of it uninspected.
Note that Trifecta is not intended as a public site where random people can share images, as that does not tend to end well. It is however very suitable for company or personal use. You can read more about the project here, and there is also a page about the technology used to deliver such a tiny self-contained solution.
Response to Trifecta
This has been rather interesting. The most common response to Trifecta so far has been that I should use a whole bag of Amazon Web Services to deploy it. This is an exceedingly odd response to a project with the clearly stated goal of providing stand-alone software that does not rely on external services. I’m not sure what is going on here.
Another reaction has been that I treat Docker unfairly, and that you could definitely use containers for good. And I agree wholeheartedly. But I also look at what people are actually doing (also with other forms of containers or virtual machines), and it’s not so great.
“To some, complexity equals power. (…) Increasingly, people seem to misinterpret complexity as sophistication, which is baffling—the incomprehensible should cause suspicion rather than admiration.”
I’ve similarly observed that some people prefer complicated systems. As Tony Hoare noted long ago, “[T]here are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors.” If you can’t do the first variant, the second way starts looking awfully attractive perhaps.
Back to Wirth:
“Time pressure is probably the foremost reason behind the emergence of bulky software. The time pressure that designers endure discourages careful planning. It also discourages improving acceptable solutions; instead, it encourages quickly conceived software additions and corrections. Time pressure gradually corrupts an engineer’s standard of quality and perfection. It has a detrimental effect on people as well as products.”
Why spend weeks paring down your software when you can also ship a whole pre-installed operating-system image that just works?
“The plague of software explosion is not a ‘law of nature.’ It is avoidable, and it is the software engineer’s task to curtail it.”
If this is indeed on the shoulders of software people, we should perhaps demand more time for it.
The world ships too much code, most of it by third parties, sometimes unintended, most of it uninspected. Because of this, there is a huge attack surface full of mediocre code. Efforts are ongoing to improve the quality of code itself, but many exploits are due to logic fails, and less progress has been made scanning for those. Meanwhile, great strides could be made by paring down just how much code we expose to the world. This will increase time to market for products, but legislation is around the corner that should force vendors to take security more seriously.
Trifecta is, like Wirth’s Oberon Project mentioned above, meant as a proof that you can deliver a lot of functionality even with a limited amount of code and dependencies. With effort and legislation, maybe the future could again bring sub-50-million-line garage-door openers. Let’s try to make it happen.
Our new integrated learning experience allows young people to follow the project instructions and work in the Code Editor in a single window. By providing a simpler workspace, where learners do not need to switch between windows to read instructions and input code, we aim to reduce cognitive load and make it easier for young people to learn.
How the new integrated experience works
In the integrated project workspace, learners can access the project instructions, coding area, and output (where they can see what they have made) all in the same view. We have reorganised the project guides into short, easy-to-follow steps made up of simple instructions, including code snippets and modelled examples, for learners to work through to create their projects. The project guides feature fresh designs for different types of learning content, such as instruction steps, concept steps, code snippets, tips, and debugging help.
We have also optimised this learning experience for young people using mobiles and tablets. On mobile devices, a new ‘Steps’ tab appears alongside the ‘Code’ and ‘Output’ tabs, enabling learners to easily navigate to the project guide and follow the steps to make their projects.
Try out our new learning experience
We are testing our new integrated learning experience as a beta version in three projects:
Hello world (part of our ‘Introduction to Python’ project path)
Target practice (part of our ‘Introduction to Python’ project path)
Anime expressions (part of our ‘Introduction to web development’ project path)
In each of these projects, young people can choose to complete the original version of the project, with the project instructions and Code Editor in separate windows, or click the button on the project page to try out the new integrated learning experience.
We’d love to hear how your young learners get on with this new integrated experience. Try it out in the three projects above and share your feedback with us here.
Code Editor developments have been made possible with generous support from the Cisco Foundation.
In our series of community stories, we celebrate some of the wonderful things young people and educators around the world are achieving through the power of technology.
In our latest story, we’re heading to Vivek High School in Mohali, India, to meet Sahibjot, a 14-year-old coding enthusiast who has taken his hobby to the next level thanks to mentorship, Code Club, and the exciting opportunity to take part in the Coolest Projects 2023 global online showcase.
Introducing Sahibjot
When he was younger, Sahibjot loved playing video games. His interest in gaming led him to discover the world of game development, and he was inspired to find out more and try it out himself. He began to learn to code in his spare time, using tutorials to help him develop his skills.
Keen to share the joy he had experienced from gaming, Sahibjot set himself the challenge of creating a game for his cousin. This project cemented his enthusiasm for coding and developing games of his own.
“I always felt that I have played so many games in my life, why not make one and others will enjoy the same experience that I had as a child.
For my cousin, I made a personal game for him, and he played it and he liked it very much, so once he played it, I felt that, yes, this is what I want to do with my life.” – Sahibjot
Mentorship and collaboration
While continuing to hone his computing skills at home, Sahibjot heard that his school had started a Code Club. After initially feeling nervous about joining, his enthusiasm was bolstered by the club mentor, Rajan, talking about artificial intelligence and other interesting topics during the session, and he soon settled in.
At Code Club, with support and encouragement from Rajan, Sahibjot continued to develop and grow his coding skills. Alongside his technical skills, he also learned about teamwork and working collaboratively. He embraced the opportunity to help his peers, sharing his knowledge with others and becoming a mentor for younger club members.
“Last year, we joined this coding club together and we became friends. He’s a very friendly person. Whenever we need him, he just quickly helps us. He helps us to troubleshoot, find any bugs, or even fix our codes.” – Akshat, fellow Code Club member
A global opportunity
The next step for Sahibjot came when Rajan introduced him and his fellow Code Club members to Coolest Projects. Coolest Projects is a celebration of young digital creators and the amazing things they make with technology. It offers participants the opportunity to share their tech creations in a global, online showcase, and local in-person events celebrating young creators are also held in several countries.
Sahibjot was eager to take part and showcase what he had made. He submitted a Python project, a ping-pong game, to the online showcase, and was very excited to then see his creation receive a special shout-out during the Coolest Projects global livestream event. He was delighted to share this achievement with his friends and family, and he felt proud to be representing his school and his country on a global stage.
“I told everyone around me that there was going to be a livestream and I possibly might be featured in that, so that was really exciting. I learned a lot about just not representing my school and myself as an individual, I learned about representing my whole nation.” — Sahibjot
Sahibjot’s passion for computing has helped shape his aspirations and ambitions. Looking to the future, he hopes to use his technology skills to benefit others and make an impact.
“Using code and technology and all of the things like that, I aspire to make effort to do something with the world, like help out people with technology.” — Sahibjot
Inspire young creators like Sahibjot
To find out how you and young creators you know can get involved in Coolest Projects, visit coolestprojects.org. If the young people in your community are just starting out on their computing journey, visit our projects site for free, fun beginner coding projects.
For more information to help you set up a Code Club in your school, visit codeclub.org.
Join us in celebrating Sahibjot’s inspiring journey by sharing his story on X (formerly Twitter), LinkedIn, and Facebook.
Přihlásit se
What began as a class of 28 students held in a restaurant in Kalispell, Mont., has grown into a statewide program run by Code Girls United. The nonprofit has taught coding and computer science to more than 1,000 elementary, middle, and high school students. Code Girls United
