Mazen and Robin catch up on five months of React Native and Expo releases, covering the biggest updates in 0.82–0.84 and Expo SDK 55. They talk through the move to the new architecture, Hermes V1 becoming the default, faster builds, better developer tools, and AI updates that make upgrading a little less of a headache.
Infinite Red is an expert React Native consultancy located in the USA. With over a decade of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter, core React Native contributors, creators of Ignite and Reactotron, and much, much more), Infinite Red is the best choice for helping you build and deploy your next React Native app.
How much do you really know about the protocol that everything is built upon? This week, we go behind the scenes with Simone Carletti, a 13-year industry veteran and CTO at DNSimple, to explore the hidden complexities of DNS. We attempt to uncover why exactly DNS is often the last place developers check during an outage, drawing fascinating parallels between modern web framework abstractions and network-level opaqueness.
Simone shares why his team relies on bare-metal machines instead of cloud providers to run their Erlang-based authoritative name servers, highlighting the critical need to control BGP routing. We trade incredible war stories, from Facebook locking themselves out of their own data centers due to a BGP error, to a massive 2014 DDoS attack that left DNSimple unable to access their own log aggregation service. The conversation also tackles the reality of implementing new standards like SVCB and HTTPS records, and why widespread DNSSEC adoption might require an industry-wide mandate.
And of course we have the picks, but I'm not spoiling this weeks, just yet...
MS Access currently ships a standalone Database Compare tool (DATABASECOMPARE.EXE) that enables comparison of two Access databases. As of June 2026, this tool will no longer be distributed and installed with Office.
Access is retiring the Database Compare tool because it depends on components that are no longer available and fails to launch reliably on many Office installs. Because we can no longer provide updated components, it will no longer install with new Office setups.
This applies to:
Access 2019 volume licensed and Enterprise plans
Access 2021, Access 2024, and Microsoft 365 subscriptions
Access 2021 and Access 2024 as part of the Office 2021 and Office 2024 perpetual licenses (standalone versions)
DatabaseCompare.exe is installed typically under the DCF folder of your Office installation (for example, C:\Program Files\Microsoft Office\Office16\DCF\DATABASECOMPARE.EXE), and it often comes alongside Microsoft Spreadsheet Compare as part of Office Professional Plus or Microsoft 365. In addition, supporting DLLs and configuration files are located within the same DCF subfolder. These files handle database connections, reporting, and comparison functions. These files will be removed.
If you're running an older version of Office and have a working version of this tool, you can continue to use it until June 20, 2026. After that, it will be removed and will not be available for download. Therefore, we advise you to find a replacement for Database Compare.
You can find similar standalone tools that compare two Access databases from other vendors:
AccessDiff: This tool easily compares all objects in Access, including forms, code modules, queries, macros, and more. It is designed to help users retrieve lost software and compare all objects in Access databases.
AccdbMerge: This tool is an easy-to-use diff and merge tool for Microsoft Access database files. It compares table definitions, data, forms, modules, and more. A free version is available for the main database objects.
DataWeigher: This tool compares and synchronizes data between two MS Access databases. It provides a visual result with each type of record (added, deleted, changed) represented by a different color. The comparison results can be saved as a report or SQL script for data synchronization.
Total Access Detective: This tool allows you to find differences between any two objects in one Microsoft Access database, including fields, controls, properties, macro lines, module code, and data. It also supports comparing two blocks of text from text files on disk or the text you copy and paste.
We recognize this change may require planning, and we encourage customers to review these alternatives and plan a transition away from Database Compare ahead of its retirement in June 2026.
Our survey of stack limit checking wraps up with arm64, also known as AArch64.
The stack limit checking takes two forms, one simple version for pure arm64 processes, and a more complex version for Arm64EC. I’m going to look at the simple version. The complex version differs in that it has to check whether the code is running on the native arm64 stack or the emulation stack before calculating the stack limit. That part isn’t all that interesting.
; on entry, x15 is the number of paragraphs to allocate
; (bytes divided by 16)
; on exit, stack has been validated (but not adjusted)
; modifies x16, x17
chkstk:
subs x16, sp, x15, lsl #4
; x16 = sp - x15 * 16
; x16 = desired new stack pointer
csello x16, xzr, x16 ; clamp to 0 on underflow
mov x17, sp
and x17, x17, #-PAGE_SIZE ; round down to nearest page
and x16, x16, #-PAGE_SIZE ; round down to nearest page
cmp x16, x17 ; on the same page?
beq done ; Y: nothing to do
probe:
sub x17, x17, #PAGE_SIZE ; move to next page¹
ldr xzr, [x17] ; probe
cmp x17, x16 ; done?
bne probe ; N: keep going
done:
ret
The inbound value in x15 is the number of bytes desired divided by 16. Since the arm64 stack must be kept 16-byte aligned, we know that the division by 16 will not produce a remainder. Passing the amount in paragraphs expands the number of bytes expressible in a single constant load from 0xFFF0 to 0x0FFF0 (via the movz instruction), allowing convenient allocation of stack frames up to just shy of a megabyte in size. Since the default stack size is a megabyte, this is sufficient to cover all typical usages.
Here’s an example of how a function might use chkstk in its prologue:
mov x15, #17328/16 ; desired stack frame size divided by 16
bl chkstk ; ensure enough stack space available
sub sp, sp, x15, lsl #4 ; reserve the stack space
Okay, so let’s summarize all of the different stack limit checks into a table, because people like tables.
x86-32
MIPS
PowerPC
Alpha AXP
x86-64
AArch64
unit requested
Bytes
Bytes
Negative bytes
Bytes
Bytes
Paragraphs
adjusts stack pointer before returning
Yes
No
No
No
No
No
detects stack placement at runtime
No
Yes
Yes
Yes
Yes
Yes
short-circuits
No
Yes
Yes
Yes
Yes
No
probe operation
Read
Write
Read
Write
Either
Read
As we discussed earlier, if the probe operation is a write, then short-circuiting is mandatory.
¹ If you’re paying close attention, you may have noticed that PAGE_SIZE is too large to fit in a 12-bit immediate constant. No problem, because the assembler rewrites it as
Get design and reference implementation for secure deployment of AI agents on infrastructure.
Teleport's Agentic Identity Framework provides standards-based,
opinionated designs so teams can ship confidently.
Check it out.
Don't gamble with AI Agents.
Coder Workspace provides a secure, self-hosted environment, so you can leverage AI safely, collaborate effectively, and stay in control.
Learn more.
I built a real-time notification feature with SignalR, tested it locally, everything worked great.
Then I scaled to two instances behind a load balancer, and notifications started disappearing for some users.
The code was fine.
The problem was that SignalR connections are bound to the server process that accepted them.
Each instance only knows about its own connections.
So when an API request lands on Server 1 but the user is connected to Server 2, the notification just... doesn't get delivered.
This is the SignalR scale-out problem, and it bites almost everyone who goes from one instance to more.
The server holds the full map of who's connected, so sending a message to a user, a group, or all clients works because that map is complete.
But scale out to two or more instances, and that map fractures.
Server 1 has no idea Client 3 or Client 4 even exist.
So when an order status change happens on Server 1 and needs to reach Client 3, Server 1 checks its connection map, finds nothing, and the message is quietly dropped.
The fix is a backplane - a shared messaging layer that sits between all your server instances.
Every server publishes outgoing messages to a central channel, and every server subscribes to that same channel.
When a message comes in, each server checks if any of its local connections should receive it.
When Server 1 wants to notify Client 3:
Server 1 publishes the message to the backplane
All servers receive the message
Server 2 recognizes Client 3 as one of its connections and delivers the notification
From your code's perspective, it looks like every server can see every connection.
Redis works really well for this because its Pub/Sub delivers messages to all subscribers in near real-time.
And if you're already using Redis for distributed caching, you don't even need to spin up anything new.
Let me walk through how I set this up in an order notification system.
Clients connect to a SignalR hub, authenticate via JWT, and get real-time status updates when an order changes.
If you're running with .NET Aspire,
you will have the Redis connection string registered via environment variables, so you can just pull it from configuration.
Reference the same named connection:
If you have multiple SignalR apps sharing the same Redis instance, you'll want to add a channel prefix.
Otherwise, messages from one app will reach subscribers in every app on that Redis server.
The nice thing is that your IHubContext<> call site doesn't change at all.
Clients.User(...) works the same whether you have one instance or ten - the backplane handles routing behind the scenes.
When I tested this with two replicas in .NET Aspire, I tagged each notification with the sending instance's ID.
A client on Replica 1 received a notification stamped with Replica 2's ID, which confirmed the message was crossing instances through Redis.
This is something you should know before you set up the backplane: you still need sticky sessions.
The Redis backplane solves message routing, but it does not remove the need for sticky sessions.
SignalR's connection negotiation is a two-step process:
The client sends a POST to /hub/negotiate to obtain a connection token
The client uses that token to establish the WebSocket connection
Both requests must land on the same server.
If your load balancer routes the negotiation to Server 1 but the WebSocket upgrade to Server 2, the connection fails.
Make sure sticky sessions are enabled in your load balancer.
Most load balancers support this via IP hash or cookie affinity - check the docs for whichever you're using.
One thing worth knowing: SignalR does not buffer messages when Redis is unavailable.
If Redis stops responding, any messages sent during the outage are simply lost.
SignalR may throw exceptions, but your existing WebSocket connections stay open - clients don't get disconnected.
Once Redis comes back, SignalR reconnects automatically.
For most real-time scenarios like order updates or live dashboards, this is fine.
The next state change triggers a fresh notification anyway, or the user can just reload.
If you're dealing with something more critical (financial data, operational alerts), you'll want a reconciliation strategy on reconnect or a durable queue running alongside.
If you're on Azure, the managed Azure SignalR Service is worth considering.
It proxies all client connections through the service, so sticky sessions aren't required and your servers only hold a small number of constant connections to the service.
The Redis backplane is the better fit when you're self-hosted, latency-sensitive, or already running Redis.
For everything else, Azure SignalR Service is the cleaner option.
Honestly, the Redis backplane is almost too simple to set up.
One method call on AddSignalR() and your app goes from silently dropping messages to routing them across every instance.
You don't need to make changes to your hub code, client code, or application logic.
Just remember two things:
You still need sticky sessions
Messages aren't buffered if Redis goes down temporarily
Get those two right and SignalR scales out just as smoothly as the rest of your stack.
If you want to go deeper on building real-time features and APIs in .NET,
check out my Pragmatic REST APIs course.
In this article, we will explore how to implement a file-based document repository with version control in .NET using TX Text Control. This solution allows you to manage and track changes to your documents effectively.
Log in
