Bill Gates-backed Breakthrough Energy, headquartered in Seattle, is reducing its operations even more. The organization has decided against pursuing additional capital for Catalyst, its initiative that funds ready-to-scale climate technology projects, Axios reported Friday.

• Catalyst raised an initial fund of $1.5 billion.
• Breakthrough Energy Ventures, a broader climate investment vehicle launched by Gates in 2015 with a who’s who of tech and business leaders, has raised three funds totaling approximately $3 billion.
• Breakthrough, which served as an umbrella organization, began significantly cutting staff and programming shortly after President Trump returned to office last year.
• Gates in October posted a memo on his personal blog making clear his philanthropic focus is on global health and downplaying climate threats.

Added

• Show IDE file selection indicator in the status bar when connected to an IDE
• Add repo-level settings to disable individual validation tools
• ACP server supports loading existing sessions
• Page Up/Page Down keyboard scrolling in alt-screen mode
• Add Ctrl+Z suspend/resume support on Unix platforms
• Support tilde (~) expansion in MCP server cwd configuration
• Support ctrl+n and ctrl+p as arrow key alternatives
• Exit CLI with ctrl+d on empty prompt

Improved

• Shell mode removed from Shift+Tab cycle, accessed only via !
• Improve /tasks dialog with consistent icons and typography
• Exit from alt-screen no longer replays full session history
• MCP server errors and loading issues surface in timeline
• Reduce input jitter with frame coalescing and smoother alt-screen animations
• Extend skill name validation to support underscores, dots, and spaces; make name and description optional in skill frontmatter with sensible fallbacks

Fixed

• Fix unknown option '--no-warnings' error
• Shift+Enter inserts newlines in terminals with kitty keyboard protocol
• MCP server list selection adjusts correctly after deletion

A new release of the Microsoft build of Go is now available for download. For more information about this release and the changes included, see the table below:

As of this release, Go 1.24 is no longer supported, per the Go release policy.

Changes in the Microsoft build of Go 1.26

The 1.26.0-1 release is a major version update, and it includes a few experimental features we are eager to get feedback on. Specifically, if you get a chance, please try to:

• Disable cgo and use the GOEXPERIMENT ms_nocgo_opensslcrypto.
• Use the Microsoft build of Go version rather than the upstream version in your programs. Our version is formatted in a way that we expect to be parsed correctly by existing tools, but let us know if this causes any problems. To do this:
  • Use -ldflags="-ms_upstreamversion=0" in your go build command. When you run go version <your-program>, you should see our toolset’s version.
  • Add ms_version=1 to the GODEBUG environment variable at runtime or configure this setting in your go.mod for compile time. This configures runtime.Version() to return the Microsoft build of Go version string.

As always, please let us know if you encounter a problem or have a question by filing an issue. If you have access to Microsoft internal sites, you can alternatively use one of the channels listed in our internal support documentation such as the Golang Friends group in Teams.

The following is a summary of the Microsoft build of Go 1.26 release notes, emphasizing important changes. To see the canonical release notes doc, visit the full go1.26 release notes Markdown file.

Toolchain

The GOCACHE environment variable now defaults to os.UserCacheDir()/ms-go-build instead of os.UserCacheDir()/go-build. This change removes the possibility of encountering cache conflicts between the Microsoft build of Go and other Go toolchains installed on the same machine.

The buildinfo embedded at build time now includes Microsoft-specific version information in a new microsoft_toolset_version setting. This allows all binaries built by the Microsoft build of Go to be easily identified, including the toolset’s binaries themselves. Along the same lines, we introduced a new GODEBUG runtime setting called ms_version and build-time linker flag -ms_upstreamversion that allow you to use the Microsoft-specific version string in your programs. For more information, see the Additional Features document.

Systemcrypto

Configuration

You can disable systemcrypto at build time by setting the environment variable MS_GO_NOSYSTEMCRYPTO to 1. It’s now the recommended method for disabling systemcrypto when necessary. This feature was backported to 1.25.2-1, so it’s now available in all supported versions of the Microsoft build of Go.

Backends

Windows

Setting the FIPS preference to enabled will no longer cause a panic when the Windows FIPS policy is disabled. The underlying crypto primitives on Windows are always FIPS compliant regardless of FIPS policy, so the panic is unnecessary and has been removed for compatibility with more scenarios.

OpenSSL

Linux binaries compliant with Microsoft internal cryptography policies can now be built without using cgo by setting GOEXPERIMENT=ms_nocgo_opensslcrypto. This much-anticipated feature removes a significant limitation the Microsoft internal cryptography policies have historically placed on compliant Go programs. For more information, see No-cgo OpenSSL Backend.

Improved support for the Fedora OpenSSL FIPS provider. See golang-fips/openssl#266.

Darwin

The macOS crypto backend is no longer in preview and is now fully supported. It is enabled by default for builds targeting macOS.

Unlike preview versions of macOS backend support, using this backend doesn’t require cgo.

Supported algorithms

The systemcrypto backends now support many new cryptographic algorithms, curves, key sizes, and TLS groups and suites. See the full go1.26 release notes Markdown file for the list.

TLS settings

The TLS curves X25519 and X25519MLKEM768 can be disabled using the GODEBUG setting ms_tlsx25519=0. This setting may help comply with certain cryptographic policies.

The TLS default settings are now aligned with Microsoft TLS internal policies. This behavior can be disabled using the GODEBUG setting ms_tlsprofile=off. The changes from standard Go TLS default settings are:

• TLS cipher suites using AES-256 are now preferred over those using AES-128.
• TLS cipher suites using CHACHA20_POLY1305 are no longer preferred over AES-GCM cipher suites when the client or server supports hardware acceleration for AES.
• TLS groups supported by the systemcrypto backends are now preferred over those that are not.

The post Go 1.26.0-1 Microsoft build now available appeared first on Microsoft for Go Developers.

While the Edge runtime has limited functionality, it’s a powerful solution in the right circumstances. Here’s when it can serve your JavaScript app well.

The Edge runtime is a fast alternative to Node.js for deploying your JavaScript application. Because it is so limited in functionality, you must know how to navigate it to get the features you want.

TL;DR

While Vercel Edge runtime may be dying in depreciation, Cloudflare, Deno and Bun will exist for a long time. If you connect to your database with HTTP, and you don’t need image processing, you shouldn’t have many problems deploying anywhere. Try and write your app so that you can connect to any server, in any environment, so you can prepare for any situation.

Server JavaScript Environments

Let’s look at a brief history of server-side JavaScript to understand where we are today.

V8

In 2008, Google released the V8 engine, making JavaScript load faster for browsers, specifically for the creation of Google Chrome using the open-source Chromium browser project.

Node.js

Node.js was released in 2009. It allowed developers to run JavaScript directly on the server, replacing the need for PHP, Python, C# or Java for backend server needs. Other languages like Perl, ColdFusion and Ruby were still active, but not as popular.

Overnight, frontend developers became full-tack developers. It was the only JavaScript server option for nearly 10 years.

Node.js is built on the V8 engine with I/O, networking and file system capabilities—things which are not allowed in the browser. These additions were written in C++.

Serverless

Amazon released serverless computing for the first time in 2014. AWS Lambdas allowed developers to run JavaScript on the server without provisioning or managing servers manually. Each function starts up, runs and gets destroyed. There are cold start times, but they can be minimal.

By 2017, ZEIT (now Vercel) introduced Now v1, which was a wrapper around AWS Lambas to allow easy deployment of the functions. After being rebranded to Vercel in 2020, the serverless functions have descended into something more powerful. The infrastructure built on top of the lambdas today are extremely powerful.

Recently added in 2025, the Fluid Compute engine gets rid of these cold start problems, adding incredible speed and facility.

Edge Runtimes

Edge runtimes allow isolated instances of JavaScript that can scale infinitely.

Cloudflare

Cloudflare Workers were introduced in 2017, using V8 Isolates. This means they created a sandboxed version of V8 for the server, and only added Web Platform APIs. There is no file system, TCP, nor child processes. You can use HTTP, just like the browser, for fetching data.

They are extremely fast, extremely limited and not meant for long processes or large applications. Today, there are some node compatibility options for certain common APIs.

Vercel Edge

Vercel copied the model of V8 Isolates in 2022. Some people have suspected it uses Cloudflare under the hood, but there is no public record of this. Either way, the limitations are the same.

Vercel has depreciated Edge Functions, however, Edge runtime can still be run inside the Serverless Functions. DO NOT confuse Edge Function depreciation with Edge runtime.

Vercel Bun

Vercel recently released a public beta of Vercel Functions using Bun. I suspect the goal is for Bun to replace the Edge runtime, as they actively recommend against using Vercel Edge, but have not depreciated the Edge runtime itself.

Bun is built on top of the JSC Engine (JavaScriptCore), which Safari browser uses, and uses Zig for the Bun Runtime. JSC is probably faster than V8 Isolates for Edge runtimes, but slower for large applications with intensive compute activities. Either way, the differences will be minimal and depend largely on configurations.

I believe Vercel is the only platform that hosts Bun for you at this time without configuration. You can self-host it anywhere.

Deno

Deno is widely used on platforms like Netlify Edge and Supabase Edge Functions.

Deno uses V8 Isolates with many more Node.js feature capabilities. It is written in Rust. However, I personally have struggled getting any Node.js-compatible APIs to work without hiccups. Deno does offer the most compatibility with Node.js, it just requires torturing yourself to get them to work correctly. I suspect this will get better over time.

Node.js vs. Edge Runtimes

Theo recently released benchmark tests basically showing Vercel Serverless is faster than Edge runtimes. Since Vercel is probably switching the Edge runtime for Bun (my guess) and doubled down on Serverless, they didn’t care so much. Since then, Cloudflare has updated some performance bottlenecks, and may have increased their speed.

The Real Winner

In reality, they are not arguing about which runtime is better; they are arguing about which service is better. Edge runtimes will probably always be faster for smaller applications, while Node.js will probably always be faster for application intensive applications.

Cloudflare vs. Vercel is a different story. I love seeing the companies solve some of the hosting issues, but I suspect benchmarks will go back and forth as things evolve. I hope the Bun Runtime gets real adoption, as I believe it has the best potential.

Remember to always put your functions as close to the database as possible.

It is still unclear if Cloudflare is faster than Vercel, as it really depends, but it is definitely cheaper.

Being Safe

I suggest you write your software with as little compatibility issues as possible. You do not want vendor lock-in, and having the ability to deploy your app anywhere gives you the best peace of mind.

Framework

It should also be noted that you can save more time using smaller JavaScript frameworks like Nuxt or SvelteKit, compared to Next.js, in any benchmark. If timing is the most important thing, the framework you choose matters the most.

Compatible JavaScript

Most standard JavaScript will work in Edge runtimes. However, certain features will not work out of the box, while others can’t work. There are always trade-offs, but there are usually work-arounds.

Image Processing

Manipulating an image requires a file system. Pure JavaScript is too slow for heavy pixel math, and those native bits can’t load in the Edge runtime. Fast image work normally relies on native libraries/codecs (libvips via sharp, mozjpeg, libwebp, etc.). The only alternative is Wasm.

WebAssembly

Edge runtime allows you to load Wasm files since you can’t use Node.js APIs. However, and a BIG however, currently loading Wasm with a Framework in Cloudflare or Vercel Edge does NOT work out of the box, and may not work at all. You can load Wasm in the browser, but it is very difficult on the server. Bundlers have a very hard time with Wasm files, particularly on the Edge.

Work-arounds

The best work-around is to create a separate function that is outside of your framework. This is NOT easy, but doable.

• Cloudflare Worker
• Vercel Edge Function
• Netlify Functions

If you’re using Vercel, the easiest route is to just create a separate Serverless Function using Node. Netlify functions may work as expected on Deno, but you’re locked in to a Deno deployment.

Cloudflare also wants you to pay for image resizing options. No thanks.

Vercel Open Graph Image

Vercel created a useful utility that allows you to generate Open Graph Images from HTML code on the fly. It first converts the image to SVG, then converts the SVG to a PNG. The @vercel/og is not open-source and is mainly imported with @next/og, but you can’t hide JS source code with NPM.

Satori

Satori converts HTML, including Tailwind, to an SVG image. It is beautiful and can run anywhere, but it doesn’t have all CSS features you would want. While it was written for JSX and React, you can use satori-html to convert any HTML string to a JSX object. This is useful for non-JSX environments.

Resvg

Converting the SVG to a PNG is the problem for Edge environments. resvg-wasm will handle this, it just currently can’t be bundled correctly when using a framework and edge deployment from any current examples I have ever seen, except the built-in NextJS library.

Sharp

Resvg only handles conversion to png, but you may need jpg conversion as well. Sharp does have a Wasm version, but I have never seen it used in action. I imagine you will get the same importing problems unless you don’t use a Framework to bundle it correctly.

Yoga

You may also need Facebook’s Yoga layout engine for calculating flexbox layouts. There is yoga-wasm for this as well.

Usage

The best way to use the og/image package, is to use it the way it was meant to be used, with Next.js or with Vercel Functions (not Edge). You will shoot yourself in the foot trying to configure it otherwise. I suggest creating a reusable function that can be called separately from any framework. This way you can have your cake and eat it to, with a workaround.

Database Connections

The main protocol people use to connect to database is TCP/IP. While managing connections is painful, you get a direct connection to your database. Edge runtimes do NOT support TCP/IP connections on their own.

Cloudflare

Cloudflare allows you to connect to TCP/IP through third-party options:

• Cloudflare Spectrum - Manage TCP for enterprise users
• Cloudflare Tunnel - Free, but local and not for scaling
• Use D1, Cloudflare’s SQLite compatible database

New in 2024

• Using connect() API, connect directly to a database via Sockets
• Use Node Compatibility and the node-postgres library for a postgres connection
• Use Hyperdrive if you need connection pooling

Connecting to a Database on Cloudflare shouldn’t be a problem with recent Node compatibility mode.

HTTP

You can always connect to your database if your database offers HTTP connections.

• Supabase – Under-the-hood via postgREST
• Firebase – JS SDK with Firestore Lite, but NOT Firebase Node admin; however, you CAN use Firebase REST API
• AppWrite – Can connect VIA HTTP
• SurrealDB – HTTP version
• Neon Postgres – Has built in HTTP Support
• PlanetScale – Serverless Driver
• Many other databases have GraphQL options. MongoDB depreciated its Altlas Rest API

Vercel Edge

Currently, there are no Node compatibility options without using HTTP or a custom proxy. Recommended database is Neon.

Netlify Edge

Deno supports npm packages now as well as a Deno TCP connector out of the box. There is a configuration hassle in Deno, but it can work.

In Short

Vercel Edge is not compatible with much, but it allows you to use Vercel Functions beside it. Cloudflare may can connect to your database, but will be painful to work with images. Netlify uses Deno with the most compatibility, but deploying them and getting them to work is difficult. It is too early to tell for Bun.

Compatibility is the Edge’s nightmare.

If you leave image processing to Serverless Functions, and connect to your database through HTTP, life is good.

There are always trade-offs.

Last time, we looked at how to distinguish the numeric keypad 0 and the top-row 0 in the WM_KEY­DOWN message. We may as well look at the analogous table for WM_CHAR.

I got the name VK_0 from this comment block in winuser.h.

/*
 * VK_0 - VK_9 are the same as ASCII '0' - '9' (0x30 - 0x39)
 * 0x3A - 0x40 : unassigned
 * VK_A - VK_Z are the same as ASCII 'A' - 'Z' (0x41 - 0x5A)
 */

Uh-oh. The extended bit doesn’t distinguish between the two. They both show up as VK_0, non-extended.

What changes is something not in the above table: The scan code.

So let’s convert the scan code back to a virtual key.

auto vk_from_scan = MapVirtualKey((lParam >> 16) & 0xFF, MAPVK_VSC_TO_VK);

So we can infer which zero was pressed by taking the scan code, mapping it to a virtual key, and seeing whether it’s the Ins key (from the numeric keypad) or the 0 key (from the top row).

But wait, we’re not done yet.

There are ways to type the character 0 without using the numeric keypad or the top row. For example, you can hold the Alt key and then type 4,8 on the numeric keypad, and that will type a 0. I tried it out, and the vk_from_scan was VK_MENU, which is the virtual key code for the Alt key. Another way of entering a 0 is by using an input method editor (IME). Or there might be a custom keyboard layout that generates a 0 through some wacky chord sequence.

Therefore, if the vk_from_scan is neither VK_INSERT nor VK_0, you have to conclude that the 0 was entered by some means other than the numeric keypad or the top row.

The post How can I distinguish between the numeric keypad 0 and the top-row 0 in the <CODE>WM_<WBR>CHAR</CODE> message? appeared first on The Old New Thing.

It was neat to stumble on this in the book, a piece by me, just a few years after Redgate acquired SQL Server Central. I’ll let the words speak for themselves.

I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.

The post The Book of Redgate: SQL Server Central appeared first on SQLServerCentral.