I spent a lifetime working at Microsoft. In the early 1990s, I began building and supporting Windows 3.x environments in a university, often cursing whatever MS was doing to make our lives more difficult (though a lot of the pain was self-inflicted by trying to integrate WFW3.11 with Novell Netware 4.0, but that’s a whole other story).

A later role in a consulting company saw me move into their own IT department at a time of great consolidation: the IT director had decided, in 1993, to bet everything on Windows NT and was rolling out NT3.1 as the company-wide standard. A brave move, perhaps some thought foolish at the time.

A couple of years later, I was replacing the global MSMail email system with this new thing called “Exchange” and that led me to jump ship and join Microsoft UK in mid-1997.

Having spent time in Redmond as part of the Exchange product group, I never worked directly on Windows (server or client) but thought myself a power user of Windows client while also keeping abreast of what Windows Server was doing, given Exchange’s dependence on it. This deepened considerably when Active Directory effectively grew out of the Exchange Directory and arrived with Windows 2000.

For years, Microsoft concentrated its efforts in growing end customer adoption of its technology in the “enterprise” – basically focussing on companies or public sector institutions who had a few hundred end users or more. They could persuade the finance team to sign up for a multi-year licensing arrangement which gave them access to the latest bits of Office, the servers that made the client apps tick (like Exchange, SharePoint, OCS/Skype/Lync) and of course the Windows Servers to run all the basic infrastructure. Logging people in, securing and updating their Windows client, providing file and print services and lots more – for many organizations, this was just the default.

Windows client and Office apps had once been the main revenue generators, though other servers and services grew to be just as significant, if not more so.

Along comes the cloud

In the early 2010s, Microsoft started getting really serious about Software-as-a-Service, especially the back-end services that would go on to become Office 365 (and now, “Microsoft 365”). CEO Steve Ballmer launched O365 in mid-2011 as the preferred way to provide email and collaboration services which would otherwise be delivered by on-premises servers.

Ballmer got some heat from Microsoft partners whose business was rolling out upgrades to Office apps and servers every few years, but the die was cast – the default should be to put this stuff in the cloud and fall-back to on-prem only if necessary. Even Microsoft salespeople were wary of pitching the subscription-based Office as an alternative to the traditionally licensed variant – but SteveB was very clear that he wanted them to lead with the cloud first.

A little later came the move to pushing Azure as a place to host other workloads whether in Virtual Machines, containers or natively written to be cloud services. Microsoft 365 grew further from Office, to encompass providing the same kind of infrastructure that would previously have required on-premises Windows Servers, to the point where many organizations would choose to have as little as possible in their own datacenters.

One customer even said at the Office 365 launch, that they were planning to put a jacuzzi in their datacenter in place of the servers they replaced…

Competition

Microsoft has always been somewhat paranoid about their competitors; Bill Gates realized early on that they had to protect their areas of strength and compete with other companies who might take away their customers.

Maybe that kind of belief is behind what got them into trouble with the US DoJ in the late 1990s, from forcing OEMs to bundle Internet Explorer and not Netscape or getting upset when Real Networks wanted to put their software on new PCs in competition with Windows Media Player.

There were lots of other areas which had cut-throat competition – MS Money vs Intuit, Word vs WordPerfect etc. They tried with Zune to compete against Apple’s iPod, and the whole Windows Mobile initiative was initially against Symbian and Blackberry before tearing it all up and launching Windows Phone to try and go after Android and iPhone. Many of these failed or became irrelevant, but the #1 mission behind most of what Microsoft was doing 30 years ago was to protect Windows.

This desire to keep Windows relevant and protected led Microsoft to build all kinds of product that wasn’t really core – like Money, Encarta, AutoRoute/Streets & Trips as well as games, loads of hardware and more.

There was always a threat that something would take over Windows’ crown; IBM and Microsoft had been developing OS/2 before their relationship broke down and Windows 3.x became the most successful system with a graphical user interface. IBM carried on trying to develop OS/2 just at the time when Apple had lost its way and needed Microsoft, of all companies, to bail it out and keep it viable. The Mac something of a threat to Windows, though it was used to try and show the DoJ that Windows was not a monopoly, given alternatives like Mac and Linux. At the time, it felt like the desktop OS was a battleground which, though Microsoft had been winning for a long time, could easily be ceded. Dilbert cartoons of the mid 1990s joked about the “OS Holy Wars”, and in hindsight, the biggest threat to Windows’ dominance was to come from mobile devices rather than other desktop OSes.

In the meantime, Windows Server was an upstart trying to compete against “proper” systems like VAX, Unix and even the likes of IBM’s AS/400. Linux would ultimately hoover up a lot of work that was done on many systems, and other competitors like Novell would sink beneath the waves.

The Desktop Years

When Windows XP came out in 2001 – only 6 years after Windows 95 – it really gave a single platform for consumers and business customers and went on to be wildly successful. Part way through XP’s life, there was a huge pivot to focus on security, meaning all code had to be thoroughly reviewed and patched, and new products had to be “secure by design”. This meant the eventual release of Windows XP Service Pack 2 was really like a whole new version (it was 2 years after SP1).

The ambitious “Longhorn” project that was supposed to bring a load of newer technology to both client and server ultimately ran aground (Ballmer admits that as one his biggest regrets from his time at Microsoft) and Vista arrived 5 years after XP, to a somewhat lukewarm reception from many.

Windows 7 was pitched internally in Microsoft as “bringing back the new car smell” for Windows. It was righting some of the wrongs of Vista (though faster hardware helped) and became the true successor to Windows XP.

Later, Windows 8/8.1 got distracted by worries that iPads were taking people away from PCs and obsessing over touch screens and store apps, when most users didn’t really need or want them. (Actually; having used a touch screen laptop since the old Windows XP Tablet Edition, I find it hard not to have it since pinching to zoom or just scrolling around a document or webpage feels so much nicer with touch than often using a mouse or trackpad).

Windows 10 was effectively the modern Win7 – right the mistakes of the predecessor, take advantage of faster machines just to make it look and feel better. Windows 11, which is approaching its fifth birthday, had a not dissimilar reaction to Vista – lots of users didn’t like some of the new design and wanted to stick with Win10 or make Win11 look and behave more like its predecessor. Maybe the old advice that you should skip alternate version of Windows, like Vista, 8.x and 11, is starting to fade.

It seems Microsoft had got distracted and stopped making Windows genuinely better. The revenue it brings is a shadow of what it used to be, at least in terms of relative importance within the company. Financial reporting is generally pretty obtuse, but in 1997 it’s probable that Windows Client revenue was about 40% of the total. Nowadays it’s reckoned to be less than 10%.

When it became clear that Linux and the Mac weren’t about to completely dethrone Windows, perhaps Microsoft put more effort into chasing subscribers to Office/Microsoft365 and Azure. The focus-on-nothing-but-AI of the last few years has also meant a lot of the updates to Windows and its venerable applications have been to jam Copilot or other AI capabilities where they might not be welcome.

Windows 11 and the new car smell again

It feels like Windows client has got a new focus – updates to the Start menu, reducing the insidious “sponsored content” and widgets chock full of stupid ads, while adding in features (like where the taskbar sits on the screen) that have been missing for half a decade despite continuous requests to restore them. And backing away from shoving Copilot/AI into every. single. app.

In a world where kids might go through all their schooldays and only ever use Chromebooks or iPads, there’s a risk that in another 20 or 30 years, nobody will remember what Windows was like, just as only old nerds can recall plugging a PCMCIA card into an inch-thick laptop just to connect it to a network.

Who knows if and when Windows 12 will ever appear, or if Windows 11 will just keep evolving in different directions depending on fashion and the whims of the people in charge.

What’s somewhat reassuring is that it seems Microsoft has decided to care about it again.

The post I spent 25+ years at Microsoft, and Windows is getting the care it deserves again appeared first on Windows Latest

If you’re still writing posts one at a time, your content pipeline is already obsolete. On the latest Zero to Agent in 30 Minutes, Craig Hewitt, founder of Castos, demonstrated how to turn a fresh Hermes installation into a social media agent that can study a person’s writing, draft posts, and plan recurring research, focusing on the context, workflows, and safeguards that help an agent produce useful work. Once set up, the always-on agent can run on a schedule, monitor external sources, and complete recurring tasks without human oversight. Check it out.

How to build a social media agent that researches and writes LinkedIn posts

1. Choose the right agent setup. Decide whether you need an interactive tool for active work or an always-on agent that runs on a schedule. Craig used the Hermes desktop app for the demonstration, which gives him the option to deploy it to a cloud server or dedicated computer later.
2. Create a structured workspace. Ask the agent to organize a new project with separate files for voice guidance, editorial standards, post templates, examples, and operating instructions. A clear file structure gives the agent reliable information to retrieve as it works.
3. Seed the agent with relevant context from your own work. Provide examples of your own posts, emails, and other writing that reflect the style you want. Craig also included examples of writing he likes from people he follows to give the agent a broader range to analyze.
4. Turn the examples into a voice system. Have the agent analyze the material and document its findings. The voice profile captures the audience, point of view, sentence style, recurring themes, editorial rules, and types of posts to create.
5. Test a narrow workflow with human review. Start with one task, such as drafting several LinkedIn posts from a supplied idea. Keep a person in the loop while you evaluate the output, correct mistakes, and refine the instructions.
6. Package repeatable work into skills. Create reusable instructions for recurring tasks such as researching topics, selecting a post format, retrieving relevant examples, and drafting in the approved voice. Craig compared these skills to standard operating procedures that make recurring tasks more consistent.
7. Connect the agent to fresh data. Add sources of new ideas, such as news feeds, websites, social platforms, or internal business systems. Craig recommended starting with a simple, semiautomated trend scan before investing in a more complex data pipeline.
8. Add triggers and safeguards. Decide what starts each workflow, whether that’s a schedule, a user request, a webhook, or a change in another system. Use separate accounts and limited permissions for autonomous agents so you can trace their actions and control their access.

Agents become useful when they have context, clear processes, the right tools, and enough oversight to validate each workflow. Once those pieces are in place, Craig noted, teams can gradually move from one-off prompting to systems that monitor information and complete recurring work.

Coming next week

In the next episode, Max Johnson, cofounder of briix.ai, will take a workflow that only lives in someone’s head at the moment (or maybe is captured in a messy Notion doc or a long email chain) and rebuild it as an autonomous agent, live and from scratch. You can follow along with every decision as you learn how to spot the steps that can be handed off, how to handle the ones that can’t, and how to structure the whole thing so it runs without you.

Ready to take your agent knowledge further? Learn to design and build production-ready agentic infrastructure by attending Harness Engineering for AI Agents on August 12. And if you want to go deeper with Hermes, join us for Build Your First Local Agent with Hermes on August 26.

Disclaimer: This article was created with the assistance of AI and reviewed by the JetBrains RustRover team. 

C and C++ to Rust migrations are no longer just an experimental idea. More teams are now looking at Rust as a practical way to improve memory safety, reduce long-term maintenance costs, and modernize performance-critical systems. But a successful migration is not about rewriting everything just because Rust is popular. The hard question is more practical:

‘’Why should teams consider Rust for existing C or C++ systems, which parts of those systems should move to Rust, and how do you do it without breaking what already works?’’

This was one of the main topics in our recent livestream with Luca Palmieri from Mainmatter, author of 100 Exercises To Learn Rust and the upcoming C to Rust Migration book, and Vitaly Bragilevsky from JetBrains. Mainmatter works with teams adopting Rust in real-world software projects, including through consulting, training, and migration support. In the livestream, Luca Palmieri shared what that practical experience shows: where C and C++ to Rust migration projects succeed, where they usually get stuck, and why incremental migration is often the safer path.

The full livestream is available here:

Tldr: For many production systems, the safest C++-to Rust migration strategy is not a full rewrite. It is an incremental migration: start with isolated modules, make Rust work inside the existing build and release process, and expand gradually as confidence grows.

Related resources: Mainmatter offers Rust consulting for teams planning or running migration projects.  For a deeper look at migration patterns, check out Mainmatter’s C to Rust Migration book. And if your team wants to strengthen its Rust foundations first,  Luca Palmieri’s 100 Exercises To Learn Rust is available as a JetBrains Academy course. 

Why teams are migrating from C and C++ to Rust

A few years ago, suggesting a C or C++ to Rust migration could feel risky. Nobody wants to be the canary in the coal mine, especially when the project is load-bearing, serving production traffic, or important to the business. If a team is investing years of engineering effort into a migration, they need to know they will not discover a roadblock halfway through.

That hesitation is weaker today. Companies like Google aren’t just migrating to Rust; they’re publishing data arguing that Rust adoption improves safety, especially by reducing memory-safety vulnerabilities, and reducing defect rates compared to their C++ predecessors. Beyond de-risking, there are several factors that have had an impact on today’s situation:

• Expertise is spreading. Engineers who learned Rust at one company bring that knowledge to their next role, creating a multiplier effect across the industry.
• Tooling has matured. The ecosystem gaps that made early adoption painful have largely been filled.
• Hiring concerns are fading. The argument that “we can’t find Rust developers” loses substance when more developers have production Rust experience.
• AI assistance reduces friction. Generative AI tools help flatten the learning curve, making the initial ramp-up less daunting.

The question has changed. Teams are now asking whether their C or C++ codebase has a problem that looks like a good fit for Rust. For a broader look at how the two languages compare, including memory safety, performance, and concurrency, see our Rust vs C++ comparison. Let’s see which projects should migrate and how. 

Which Projects Should Migrate?

Not every C or C++ project benefits from a Rust migration. For hobby projects, the calculus is simple: migrate if you want to learn Rust or if it feels right. For production systems, migration needs to make business sense. The strongest candidates are usually codebases where maintainability is already expensive:

• Performance-sensitive codebases where squeezing every ounce of efficiency pushes teams toward complex patterns that are hard to reason about. Rust’s safety guarantees don’t compromise performance, but they do make those complex patterns more manageable.
• Concurrent or multi-threaded systems where the borrow checker provides safety nets that are difficult to replicate in C++. Data races and memory safety issues that require constant vigilance in C++ become compile-time errors in Rust.
• Security-critical components where vulnerabilities carry high costs. If your code is an attractive attack target, preventing memory safety issues before they reach production has clear economic value.
• High-scale deployments where even modest efficiency improvements translate to meaningful infrastructure savings. If migrating to Rust lets you run on less powerful hardware, those savings compound quickly.

The common thread is maintainability. Successful migrations improve the ability to ship features faster, reduce defect rates, or both. The migration cost must be justified by reduced rework, fewer security incidents, improved developer productivity, or operational savings.

C++ to Rust migration: Full Rewrite vs. Incremental Migration

The choice between a complete rewrite and an incremental migration isn’t ideological. It depends on your deployment model, codebase characteristics, and available testing infrastructure.

A full rewrite can sound appealing. You start from scratch, set up the codebase the way you want, draw the boundaries where you like, and leave old decisions behind. But let’s see where a full rewrite makes sense? 

When Full Rewrites C/C++ to Rust Make Sense

• The codebase is relatively small, and the scope is tractable
• You have an exhaustive black-box test suite that validates behavior without assuming internal structure
• The API surface is well-defined and stable
• You control the deployment environment

Services deployed as backends can be good candidates. You can route shadow traffic to the new implementation, compare responses against the old system, and gradually shift load. If something breaks, you have multiple levers to pull: roll back instantly, route only a tiny percentage of traffic, or limit the migration to specific customer segments.

The key is confidence-building mechanisms. You need mechanisms that prove the new implementation behaves like the old one, including the small details that users may unknowingly depend on.

When Incremental Migration Is Better

For many teams, the safest C++ to Rust migration path is incremental, especially for large, active, or customer-deployed systems. Instead of replacing the whole codebase at once, you migrate one piece, ship it, learn from it, and continue.  Success looks like steady progress, ideally accelerating progress. One release may contain 95% C or C++ and 5% Rust. A later release may contain 90% C or C++ and 10% Rust.

Over time, the Rust part grows, the old code shrinks, and the team keeps watching the important signals such as defect rates, performance, user feedback, and developer velocity.

The value of this approach is that every migrated piece is integrated into the real product. Users get the new code. The team sees whether it performs better or worse. Bugs show up in the normal issue tracker. The migration builds confidence release by release.

Ideally, the more Rust you have, the easier it becomes to add more Rust. The lift-off phase is the hardest. Once the build system, testing setup, FFI conventions, and release process are in place, the next modules should be easier than the first.

Incremental migration also makes sense when institutional knowledge matters. If you migrate piece by piece, the developers who maintain the code stay involved throughout the process. A full rewrite risks knowledge loss: you might end up with better-structured code, but nobody remembers why certain decisions were made.

Where to start: eat the graph from the leaves

One practical approach is to look at the module graph and find isolated modules. Start from the leaves: modules that have no dependencies, or only a few dependencies on the rest of the system. This is usually the easiest starting point because the first Rust code does not need to call into C or C++ code. It only needs to be callable from the existing C or C++ codebase.

In other words, the Rust module exposes an extern API, but inside it can still be structured as normal Rust. This matters more than it seems. Before you write meaningful Rust code, you need to solve integration problems:

• How does Rust fit into the existing build system?
• How do C, C++, and Rust code link together?
• Can memory sanitizers still run across language boundaries?
• Does everything work on all supported platforms?
• How will the team test and release mixed-language code?

Starting with a simple, low-complexity module lets you solve these problems before tackling harder software challenges. You want to ship a line of Rust that does almost nothing but builds correctly, links properly, and works in all your CI flows.

Once that first module is done, you’ve freed other modules from dependencies. You tackle those next, gradually expanding your island of Rust code. Eventually, you have C on the outside and Rust on the inside, and you keep expanding until the C disappears.

The downside is that you might spend months working on modules far from the action, modules that haven’t been touched in years. It can feel like you’re not adding business value. But you’re building the foundation that lets you rewrite the complex, important parts without managing C dependencies underneath.

The alternative: vertical slices

The opposite approach is to drive a specific user flow or feature through Rust, cutting a vertical slice through the stack. This puts Rust code in the critical path immediately, demonstrating business value from day one.

The challenge is complexity. Your Rust code will constantly call into C and be called from C. You’ll have raw pointers everywhere. It will be Rust, but it will feel like C-style Rust. You won’t get safety benefits for a long time because most of the action happens outside the domain the borrow checker can verify.

This approach can leave teams wondering: “Is this Rust code actually better than the C++ it replaced? It looks and feels the same.” Both strategies have merit. Bottom-up from the leaves is generally cleaner and allows for better restructuring. Vertical slices show business value faster but require navigating more complexity upfront.

Rust FFI is where the migration gets tricky

The hardest part of incremental migration is crossing the language boundary. Inside pure Rust, the compiler helps enforce ownership, borrowing, and lifetimes. You can try a design, and the borrow checker tells you whether the memory-safety story works.

Once raw pointers cross between Rust and C or C++, that safety net becomes weaker. The programmer has to track assumptions manually:

• Is this pointer still alive?
• Does it have aliases?
• Who owns the value?
• Who is allowed to free it?

At that point, you become the borrow checker. This is where Rust FFI becomes central. The team needs clear rules for ownership, allocation, and cleanup.

A useful principle is: whoever allocates memory should free it. Avoid allocating in C and freeing in Rust, or the other way around, unless the boundary is designed very carefully. Unsafe code is expected in mixed C, C++, and Rust codebases. That does not make the migration wrong.

It means unsafe code needs to be treated as an important design surface, not as glue code nobody reviews. A lot of migration work is about making behavior that already exists in C or C++ visible and correct in the eyes of the Rust compiler. That can feel like hard work, but it is essential. The point of moving to Rust is to benefit from static analysis, and the code has to be structured in a way that lets those tools help.

What to do before you start migrating

A C++ to Rust migration is not just a rewrite. It is a long-term engineering project that affects the build system, release process, testing strategy, and the people who will maintain the code afterward. That’s why the safest migrations are usually the ones that build confidence step by step. Start small, solve the integration problems early, keep the Rust FFI boundary understandable, and make sure the team learns enough Rust to own the new code.

The practical takeaway is simple: C++ to Rust migration is not about replacing every line of code as quickly as possible. It is about moving the right parts of the system to Rust in a way that reduces risk, preserves knowledge, and keeps the product moving forward.

---

How do you make sure your favorite cereal is always on the shelves when a cyber disaster strikes? In this episode, hosts Tim Peacock and Alicja Cade sit down with Noah Korba, VP of Digital Core, Cybersecurity, and Enterprise Architecture at General Mills, to look under the hood of "Mills Collaborative Recovery"—their intensive, annual two-week drill that actually recovers 90% of their Google Cloud estate to test real-world cyber resilience.

• ⌨️ "Clicking and Clacking" vs. Talking: Why General Mills ditched traditional tabletop discussions to actually run hands-on, keyboard-driven recoveries of their entire cloud infrastructure.

• 🥣 Protecting the Cinnamon Toast Crunch: How the team mapped out their "Minimum Viable Business" to keep critical supply chain and manufacturing operations moving.

• 🔑 The IT vs. OT Reality: The unique challenge of recovering factory equipment, where software updates won't work without a physical key turned on the warehouse floor.

• 💼 To Board or Not to Board: Noah's take on whether involving the board of directors in active cyber exercises is a valuable use of their time.

Download audio: https://traffic.libsyn.com/secure/cloudsecuritypodcast/2026-06-15-GSP-Ep282-1.0_AUDIO.mp3?dest-id=2641814

A huge week for open models: Inkling (the first big US open-weight model since Gemma 4), Qwen 3.8, and Kimi 3 all dropped. Plus Vue 3.6 RC + Vapor Mode, the slow death of Stack Overflow, a decoy font that blinds AI, and the usual grab bag of fun links.

Show Notes

• 00:00 Intro
• 00:44 Welcome to Syntax
• 03:01 Vue.js 3.6 RC Released
  • Vue.js 3.6-RC.1
• 09:50 Brought to you by Sentry
• 10:35 Rift - new worktree alternative
  • Rift
  • Explaining Rift tweet
• 17:46 Every new browser feature
  • MDN Plus Browser features updates
  • CSS ’text-fit’ property
• 23:09 Kimi K3 Released
  • Kimi K3 release tweet
  • Kimi K3 blog post
  • Openrouter effective pricing
• 29:33 What are Open Weight Models
• 32:46 Kimi K3 Architecture
  • Kimi K3’s built up
  • Cutting off access to Kimi
• 33:59 Qwen 3.8 Released
  • Qwen 3.8 launch announcement
• 36:42 Inkling from Thinking Machines
  • Thinking Machines release Inkling
  • Inkling release post from Mira Murati
  • Thinking Machines news blog post
• 40:45 Mole Cleanup App
  • Mole
• 43:21 Moshi Terminal App
  • Moshi app
• 46:05 RIP Stack Overflow
  • Query for new questions on Stack Overflow
  • Stack Overflow for Agents
  • StackExchange
• 54:10 Scott’s Foot Pedal
• 54:59 Scott’s Feet
• 56:13 Decoy Font
• 59:16 Jurassic Park Computers
• 01:03:59 Ride the Tokyo Trains LIVE

Hit us up on Socials!

Syntax: X Instagram Tiktok LinkedIn Threads

Wes: X Instagram Tiktok LinkedIn Threads

Scott: X Instagram Tiktok LinkedIn Threads

Randy: X Instagram YouTube Threads

Download audio: https://traffic.megaphone.fm/FSI2079334345.mp3