Google’s Interactions API is a unified interface for interacting with Gemini models and agents.

We have reimagined Gemini Deep Research to be more powerful than ever, now accessible to developers via the new Interactions API.

Tracking down a far-flung team for a 40-year reunion isn’t easy. But the people who worked on Windows 1.0 got some help from their younger selves: a mischievous Easter egg they hid long ago in the software that would become the foundation of the world’s dominant PC platform.

Back in the mid-1980s, before the product launched, they secretly inserted credits in the code, listing their names, to be revealed through a specific combination of keystrokes. 

As the story goes, Bill Gates inadvertently found the list by slamming his fists on the keyboard in frustration over the system’s sluggishness, a discovery that only made things worse. The fix: make the sequence more obscure. It worked. The credits went unnoticed by the public until 2022, when a researcher who was reverse-engineering old Windows binaries found them.

So when members of the Windows 1.0 team decided to hold a 40th anniversary reunion this year, that roster became their starting point. It was a time capsule that doubled as a guest list.

A core group from that original Windows team reunited over dinner at Steve Ballmer’s offices in Bellevue on Tuesday evening — trading memories, correcting the historical record, and marveling at what they accomplished back then under nearly impossible circumstances.

“Today, developers have all these tools, drag and drop,” said Rao Remala, an early Windows developer, adding that he would challenge anyone today to build a functioning PC operating environment under the 64K segment limits and other technical constraints of the era.

“Have you tried it in ChatGPT?” Ballmer joked from across the room. 

This year has been filled with commemorative milestones for the tech giant, from Microsoft’s 50th to Excel’s 40th to the 30th anniversary of the company’s internet pivot. But this one is different. It’s a glimpse into one of Microsoft’s scrappiest projects, from a moment in its history when key resources — including budget and computing power — were far more scarce.

Microsoft’s landmark platform

Windows 1.0, which shipped on a set of 5.25-inch floppy disks, was technically considered an operating environment, not an operating system, because it ran on MS-DOS 2.0.

Microsoft announced that it was developing Windows in November 1983. The release was delayed as the team worked through leadership turnover, technical challenges, and user-interface debates (i.e., tiled vs. overlapping windows), giving rise to industry accusations of peddling “vaporware.” Windows 1.0 finally debuted on Nov. 20, 1985.

By the time Windows launched, Apple’s Macintosh had set the standard with its elegant interface (at least by 1980s standards), and other DOS-based alternatives were also on the market. Critics favored the Mac’s polish, but Microsoft bet on broad PC compatibility, and that approach ultimately paid off.

Microsoft would later get sidetracked temporarily by its ill-fated OS/2 partnership with IBM, before Windows 3.1 became a breakout hit and Windows 95 set the global standard.

But none of it would have been possible without Windows 1.0. The intense, multi-year project was the foundation for the platform that ultimately turned Microsoft into one of the world’s most valuable companies, launching careers that would reshape the tech industry.

For Ballmer, who was tapped to get Windows 1.0 across the finish line long before he became Microsoft’s CEO, the 40-year reunion stirred up old memories and emotions. 

“Of all the things I worked on at Microsoft, in a way, I have the most pride about this project,” he told the group, explaining that he truly felt part of the team.

Figuring things out on the fly

As the night went on, the stories came out, some of them for the first time.

Working out of Microsoft’s Bellevue offices, before the company moved to Redmond, the team was largely in their 20s and even their teens in some cases. Ballmer, in his late 20s at the time, was one of the older people in the office. That helps to explain the culture at the time. 

“Work and social life — there was no difference. It all sort of blended together,” said Scott Ludwig, who worked on the Windows 1.0 window manager, the core system that handled windows, input, events, menus, and dialog boxes.

In many cases back then, they were figuring things out on the fly. For example, when Lin Shaw started in August 1984, months before the original ship date, not a single printer driver existed. She built the banding architecture — a way of imaging one strip of a page at a time to work within memory constraints — that would last through Windows 95.

She routinely stayed up all night and considered it the best job in the world. “It was just like college,” she told the group during the reunion dinner, “except I got paid really well.”

Gates got involved, at times, down to the smallest details. Mark Taylor, who wrote the calculator and other early Windows apps, recalled Gates asking him to remove a timer delay in the Reversi game — not to make it faster, but to make Windows look faster. Years later, chips got so fast that the move flashed by too quickly to see, turning the fix into a bug.

Joe King, who worked on the Windows Control Panel, had an office across the hall from Ballmer with remarkably thin walls. He watched a parade of people come for their “SteveB meeting.” The pattern was always the same: quiet conversation at first, then Ballmer would start pacing, getting louder, gesturing emphatically, and reaching a crescendo before it was over.

“The door would open, a guy would sheepishly walk out, and Steve would greet the next person with full energy and enthusiasm,” King recalled. “I would see that all day long.”

Tandy Trower reminisced about joining the team in 1985 despite being warned that it was a dead end by another product manager, Rob Glaser, later of RealNetworks fame. 

“I came to Microsoft with this vision of bringing software to the people,” Trower said, explaining that Ballmer pitched the Windows project to him as a way of accomplishing that goal. 

He took the job, only to discover the head development manager was already gone. Ballmer offered reassurances that the product was “virtually done.” It wasn’t. 

When Trower suggested changes — overlapping windows, proportional fonts — he got the same response: “You want to ship this year?” The answer was yes. Trower ended up working on Windows through Windows 95, part of a Microsoft career that ultimately spanned 28 years.

Marlin Eller, a programmer and musician, was interested in building a music notation editor. At the end of his first year, Gates asked what he wanted to work on. Eller pitched his idea. Gates engaged enthusiastically, then asked: “How big is the market?” Eller realized it was very small.

Gates had another idea. For music notation, Eller would need to build a graphics package — lines, ovals, curves, etc. An operating system needed that foundational technology to support spreadsheets and charts. And that’s how Eller ended up working on Windows. 

“The thing the world does not know,” Eller joked before the dinner, “is that Windows was written so I could do music notation. All those other people were working for me.”

Pulling pranks and checking facts

And then there were the pranks. A month or two before Windows 1.0 shipped, for example, developer Mark Cliggett decided to have some fun. He wrote a program that gradually turned off bits on a computer screen, and installed it on Ballmer’s machine when he wasn’t there.

“Multiple bad decisions right there,” Cliggett acknowledged: putting malware on a colleague’s computer, giving it to the future CEO, and missing the irony given the security challenges that would consume the industry years later. Marlin Eller wasted an hour debugging the problem before realizing what had happened. Ballmer, to his credit, didn’t hold a grudge.

GeekWire was invited to cover the Windows 1.0 reunion and document all this history. To prepare, I pulled together a 16-page report using Google’s NotebookLM to mine for information about Windows 1.0 in a variety of historical documents, books, and articles.

After I mentioned this to Ballmer, he suggested I open the evening by reading some colorful anecdotes from the research. It turned into an impromptu fact-checking exercise. 

Did Ballmer really call a meeting at 9 a.m. on Easter Sunday 1985 and take down the names of anyone who didn’t show? Yes, he called the meeting. No, he didn’t take names. “I wouldn’t call it exactly a loyalty test,” Ballmer explained, saying it was more about setting a tone. 

Did the team really blow off steam by making bombs and rockets with sugar and saltpeter, drawing police to the building when a security guard smelled explosives? Actually, that happened when making a later Windows version, according to someone who was there. The security guard joined them to blow up traffic cones in the parking garage. The police came later, when they were hiding in the library. (The details are a little fuzzy, but you get the idea.)

And finally, turning to a canonical story about the Windows 1.0 project: was the pivotal 1983 Comdex demo really just a videotape flashing graphics on the screen — classic smoke and mirrors to freeze the market? No. “This was real code,” Remala insisted. 

“It was a little more smoky than not,” Ballmer added, “but it was all real code.”

Some notable former members of the Windows 1.0 team were missing from the reunion, including the famously hard-to-reach Gabe Newell, who went on to co-found Valve and build Steam into the dominant PC gaming platform.

Scott McGregor, the lead development manager recruited from Xerox PARC, left before Windows 1.0 shipped. McGregor later co-authored the X11 windowing system at DEC and served as CEO of Broadcom.

Other members of the Windows 1.0 team went on to remarkably varied careers. 

For example, user interface developer Neil Konzen worked at Ferrari in Italy and pioneered Formula One telemetry. Ed Mills, who worked on fonts, runs a movement therapy practice in Bellevue and is involved in a nonprofit that operates a roller-skating rink in Issaquah.

Cliggett became a long-distance running coach. Eller (who went on to co-author the book Barbarians Led by Bill Gates) teaches computer science. Trower founded a robotics company and continues to work in the field. Taylor is a Seattle public school teacher.

King still introduces himself in the Seattle tech scene by saying he goes back to Windows 1.0 — sometimes prompting the response: “There was a 1.0?” Yes, there sure was.

For Ballmer, the Windows 1.0 experience led to a management technique he still uses today. On his first day as development manager, he repeated to the team what he’d been told was the schedule for different aspects of the project. He heard laughter in response.

He now calls this the “snicker test” — repeat back what you’ve heard from a project’s leaders, and see how the room reacts. If they laugh, you know you’re not getting the true story.

But the real legacy of Windows is much bigger, he told the group this week. If it had shipped two or three years later, Windows wouldn’t have been a relevant product, he said. The key, he explained, was figuring out how to ship “enough of the right stuff at the right time.”

“You did, and it’s nothing short of amazing,” Ballmer said. “It did change the world.”

The order creates a Justice Department task force to challenge state AI laws and directs the Commerce Department to pull future broadband funding from states that pass “onerous” legislation.

GitHub Actions has grown massively since its release in 2018; in 2025 alone, developers used 11.5 billion GitHub Actions minutes in public and open source projects, up 35% year over year from 2024. At the same time, this has not been without its growing pains, and you’ve made clear to  us what improvements matter most: faster builds, improved security, better caching, more workflow flexibility, and rock-solid reliability. 

Meeting that level of demand first required a deliberate investment in re-architecting the core backend services powering every GitHub Actions job and runner. This was a substantial effort that laid the foundation for the long-term performance, scalability, and feature delivery you’ve been asking for. That new architecture is rolled out, powering 71 million jobs per day and giving us deeper visibility into developer experience across the platform. 

With that work behind us, we shift our attention back to your top requests for much needed, long-standing quality-of-life improvements. Below, we’ll walk through what we’ve shipped this year, how you can get started with these upgrades today, and what’s coming in 2026. 

Let’s jump in. 

Rebuilding the core of GitHub Actions

In early 2024, the GitHub Actions team faced a problem. The platform was running about 23 million jobs per day, but month-over-month growth made one thing clear: our existing architecture couldn’t reliably support our growth curve. In order to increase feature velocity, we first needed to improve reliability and modernize the legacy frameworks that supported GitHub Actions.

The solution? Re-architect the core backend services powering GitHub Actions jobs and runners. Our goals were to improve uptime and resilience against infrastructure issues, improve performance and reduce internal throttles, and leverage GitHub’s broader platform investments and developer experience improvements. We aimed to scale 10x over existing usage. This effort was a big bet and consumed a significant part of our team’s focus. And the work is paying off by helping us handle our current scale, even as we work through the last pieces of stabilizing our new platform.

Since August, all GitHub Actions jobs have run on our new architecture, which handles 71 million jobs per day (over 3x from where we started). Individual enterprises are able to start 7x more jobs per minute than our previous architecture could support. 

This was not without its share of pain; it slowed the pace of feature work and delayed progress on long-standing community requests. We knew this would be a tough call, but it was a critical decision to enable our future roadmap and sustainability as a product.

Shifting our focus back to community-requested improvements

We acknowledge we still have a ways to go, and this is just the beginning of this new chapter of the GitHub Actions story. As we shift our focus back to much-needed improvements, we want to call out some of the most recent ships on this front:

YAML anchors reduce duplication in complex workflows

First up, we shipped support for YAML anchors, one of the most requested features across both the runners and community repositories. YAML anchors reduce repetitive configuration in GitHub Actions workflows by letting you define settings once with an anchor (&) and reference them elsewhere with an alias (*). This allows you to maintain consistent environment variables, step configurations, or entire job setups across your workflows—all defined centrally rather than repeated across multiple jobs.

💡 Read our Docs to learn more about YAML anchors and aliases

Non-public workflow templates for consistent CI across teams

We released non-public workflow templates, a longstanding request from organizations that want consistent, private workflow scaffolding.  

Non-public workflow templates let organizations set up common templates for their teams directly in their .github repository, giving developers a reliable starting point when spinning up new workflows. Instead of manually copying CI patterns across repositories, teams can now work from a shared set of patterns.

💡 Read our Docs to learn more about workflow templates 

Deeper reusable workflows for modular, large-scale pipelines

We shipped increases to reusable workflow depth (another key request from the community).  Reusable workflows let you break your automation into modular, shareable pieces. With the updated limits now supporting 10 levels of nesting and 50 workflow calls per run, teams now have more flexibility to structure their CI/CD pipelines in a way that’s maintainable and scales with their architectural requirements.

💡 Read our Docs to learn more about reusable workflows

Larger caches for bigger projects and dependency-heavy builds

Repositories can now exceed the previous 10GB cache limit, removing a long-standing pain point for teams with large dependencies or multi-language monorepos.

For teams with larger codebases or complex build pipelines, the old 10GB GitHub Actions cache limit often meant build dependencies were evicted before they could speed up your next workflow run, leading to repeated downloads and slower builds. This release was only possible due to our architecture rework and fulfills a request from the community, particularly among some of our largest users.

💡 Read our Docs to learn more about managing cache storage

More workflow dispatch inputs for richer automation

In early December, we shipped an increase to the number of workflow dispatch inputs from 10 to 25, which also came up in our community discussions. Now developers have more flexibility to build sophisticated self-service workflows, whether teams are parameterizing deployments, configuring test runs, or building reusable automation with richer input options.

💡 Read our docs to learn more about manually running a workflow with workflow_dispatch

More performance and platform improvements shipped in 2025

We also made progress on the strong foundation laid earlier this year, including arm64-hosted runners for public repositories, macOS 15 and Windows 2025 images (now generally available), Actions Performance Metrics (also generally available), and Custom Image support in public preview.

These releases are designed to improve day-to-day workflow quality and remove long-standing friction.

What’s coming in early 2026

This is just the beginning as there is much we need to do to deliver an even better experience with GitHub Actions. Here’s what we’re planning for the first quarter of 2026, influenced by some of the top requests from our community:

1. Support for timezones in scheduled jobs and updates to schedule reliability.
2. Return the run ID from workflow dispatch.
3. Adding a case function for expressions so they have a conditional operator or function.
4. UX improvements, including faster page load times, better rendering for workflows with over 300 jobs, and a filter for the jobs list. 

Moreover, we’ll start work on parallel steps, one of the most requested features across GitHub Actions. Our goal is to ship it before mid-2026. Lastly, we are going to raise the bar and start to address some of the asks to lift quality in our open source repositories—we appreciate we need to drive up the quality of our experience here as well. 

Help us shape the 2026 roadmap for GitHub Actions

GitHub Actions is one of the most important primitives on GitHub. It powers the builds, tests, deployments, automations, and release processes that define how software ships today. 

Our promise to you: 2026 will bring more consistent releases, more transparency, and continued focus on the fundamentals that matter most. We are also increasing funding towards this area to enable us to meet your expectations faster than before.

And this is where we need your help to make sure we’re focusing on the quality-of-life improvements that matter the most. We need your feedback. To support our work:

1. Keep voting for your most important items in the community discussions.
2. Join us in our new community discussion post, where the GitHub Actions product and engineering leads will be actively discussing with you what comes next. 
3. Help us drive a plan for next year to make actions the best it can be.

We know GitHub Actions powers how developers build software, and the best version is the one we’ll build together. And as always, you can keep up to date with the GitHub Actions releases through the GitHub Changelog. 

The post Let’s talk about GitHub Actions appeared first on The GitHub Blog.

In the latest edition of our Cyberattack Series, we dive into a real-world case of fake employees. Cybercriminals are no longer just breaking into networks—they’re gaining access by posing as legitimate employees. This form of cyberattack involves operatives posing as legitimate remote hires, slipping past human resources checks and onboarding processes to gain trusted access. Once inside, they exploit corporate systems to steal sensitive data, deploy malicious tools, and funnel profits to state-sponsored programs. In this blog, we unpack how this cyberattack unfolded, the tactics employed, and how Microsoft Incident Response—the Detection and Response Team (DART)—swiftly stepped in with forensic insights and actionable guidance. Download the full report to learn more.

Insight
Recent Gartner research reveals surveyed employers report they are increasingly concerned about candidate fraud. Gartner predicts that by 2028, one in four candidate profiles worldwide will be fake, with possible security repercussions far beyond simply making “a bad hire.”¹

What happened?

What began as a routine onboarding turned into a covert operation. In this case, four compromised user accounts were discovered connecting PiKVM devices to employer-issued workstations—hardware that enables full remote control as if the threat actor were physically present. This allowed unknown third parties to bypass normal access controls and extract sensitive data directly from the network. With support from Microsoft Threat Intelligence, we quickly traced the activity to the North Korean remote IT workforce known as Jasper Sleet.

 
TACTIC
PiKVM devices—low-cost, hardware-based remote access tools—were utilized as egress channels. These devices allowed threat actors to maintain persistent, out-of-band access to systems, bypassing traditional endpoint detection and response (EDR) controls. In one case, an identity linked to Jasper Sleet authenticated into the environment through PiKVM, enabling covert data exfiltration.

DART quickly pivoted from proactive threat hunting to full-scale investigation, leveraging numerous specialized tools and techniques. These included, but were not limited to, Cosmic and Arctic for Azure and Active Directory analysis, Fennec for forensic evidence collection across multiple operating system platforms, and telemetry from Microsoft Entra ID protection and Microsoft Defender solutions for endpoint, identity, and cloud apps. Together, these tools and capabilities helped trace the intrusion, contain the threat, and restore operational integrity.

How did Microsoft respond?

Once the scope of the compromise was clear, DART acted immediately to contain and disrupt the cyberattack. The team disabled compromised accounts, restored affected devices to clean backups, and analyzed Unified Audit Logs—a feature of Microsoft 365 within the Microsoft Purview Compliance Manager portal—to trace the threat actor’s movements. Advanced detection tools, including Microsoft Defender for Identity and Microsoft Defender for Endpoint, were deployed to uncover lateral movement and credential misuse. To blunt the broader campaign, Microsoft also suspended thousands of accounts linked to North Korean IT operatives.

What can customers do to strengthen their defenses?

This cyberthreat is challenging, but it’s not insurmountable. By combining strong security operations center (SOC) practices with insider risk strategies, companies can close the gaps that threat actors exploit. Many organizations start by improving visibility through Microsoft 365 Defender and Unified Audit Log integration and protecting sensitive data with Microsoft Purview Data Loss Prevention policies. Additionally, Microsoft Purview Insider Risk Management can help organizations identify risky behaviors before they escalate, while strict pre-employment vetting and enforcing the principle of least privilege reduce exposure from the start. Finally, monitor for unapproved IT tools like PiKVM devices and stay informed through the Threat Analytics dashboard in Microsoft Defender. These cybersecurity practices and real-world strategies, paired with proactive alert management, can give your defenders the confidence to detect, disrupt, and prevent similar attacks.

What is the Cyberattack Series?

In our Cyberattack Series, customers discover how DART investigates unique and notable attacks. For each cyberattack story, we share:

• How the cyberattack happened.
• How the breach was discovered.
• Microsoft’s investigation and eviction of the threat actor.
• Strategies to avoid similar cyberattacks.

DART is made up of highly skilled investigators, researchers, engineers, and analysts who specialize in handling global security incidents. We’re here for customers with dedicated experts to work with you before, during, and after a cybersecurity incident.

Learn more

To learn more about DART capabilities, please visit our website, or reach out to your Microsoft account manager or Premier Support contact. To learn more about the cybersecurity incidents described above, including more insights and information on how to protect your own organization, download the full report.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

---

¹AI Fuels Mistrust Between Employers and Job Candidates; Recruiters Worry About Fraud, Candidates Fear Bias

The post Imposter for hire: How fake people can gain very real access appeared first on Microsoft Security Blog.