Most BAT-to-EXE tools I found are either closed-source, outdated, or no longer actively maintained. I wanted to build a fully open implementation that anyone can inspect, modify, and build themselves.

The compiler itself is written in C++ using the Win32 API, while the runtime stub is written in C and built without the CRT using MinGW. The runtime stub is only about 14 KB, has no runtime dependencies, and supports both x86 and x64 Windows (Windows 7 and later).

Current features include:

• Resource embedding
• Custom icons and version information
• x86/x64 compiler/output
• An experimental in-memory execution mode (executing the embedded batch script through pipes)

The in-memory mode is still experimental and intentionally isn't the default. Some batch features that rely on a physical .bat file or interactive input are not fully compatible yet, so please read the documentation before using it.

The project is licensed under LGPL and I'm mainly looking for feedback, bug reports, feature suggestions, or general thoughts from people who are interested in Windows native development.

GitHub: https://github.com/LeapHeap/XBat

Thanks for taking a look!

Hi everyone,

For the past few months I've been working on a desktop application called CachePilot.

The goal is simple: make cleaning Windows cache easy, safe, and understandable. Most existing cleaners either look outdated, are filled with ads, or delete files without explaining what they actually are.

Current progress

The application is built with:

• Electron
• React
• TypeScript
• Vite

So far I've implemented:

• ✅ Real cache scanning (not fake progress bars)
• ✅ One-click cleanup
• ✅ Modern dark UI
• ✅ System tray support
• ✅ Scan history
• ✅ Automatic scanning
• ✅ Windows notifications
• ✅ Clear explanations for every cache category before deleting anything
• ✅ Local-first design (nothing is uploaded to a server)

What I'm still working on

• Better scan performance
• More cache locations
• Better analytics and cleanup reports
• Polish before the first public release

I'd love your feedback

I'm mainly trying to answer these questions:

• Would you actually use an app like this?
• What features are missing?
• What do you dislike about current tools like CCleaner or Windows Disk Cleanup?
• Would you pay for a lifetime license if it solved your problem?

If you'd like to try it:

📥 WebSite: https://mostafaarihani-debug.github.io/CachePilot/

📋 2-minute Survey: https://tally.so/r/Y5KPgv

I'm looking for completely honest feedback—even if it's negative. I'd rather improve the app now than launch something people don't actually want.

Thanks for taking the time to check it out!

I’ve started building WinDroid Runtime, an open-source Android compatibility and management project for Windows.

The application layer is being developed with:

• C# and .NET
• WinUI 3
• Windows App SDK
• modular ADB services separated from the UI

The first milestones are intentionally limited to the Windows tooling layer:

1. detect and configure ADB;
2. execute ADB commands safely and asynchronously;
3. discover connected devices and emulators;
4. display devices in a native Windows dashboard;
5. install APKs and expose useful command output.

The runtime itself is a longer-term research and engineering goal. The planned architecture would keep the Windows management application separate from runtime images and platform-specific backend components.

I’m particularly interested in feedback about:

• structuring reusable process and ADB services in .NET;
• keeping the WinUI project separated from backend logic;
• Windows virtualization technologies worth researching later;
• supporting both x64 and ARM64 Windows hosts;
• secure handling of APK installation and external processes.

Repository:
https://github.com/Nova-Systems-Lab/WinDroid-Runtime

The project is Apache-2.0 licensed and currently at an early stage. It is independent and not affiliated with Microsoft, Google, Amazon, or WSA.

Hey everyone,

I know what you're thinking: “Oh look, yet another Valkey-compatible service.” I don't want to play any marketing gimmicks here. There’s nothing magical going on. It’s just a simple drop-in Valkey Compatible Server written in Rust with a Tauri desktop interface.

I built it because running an entire Docker container or managing WSL2 loopback routing just to use a basic local cache on Windows is incredibly annoying. I love Memurai but it's Commercial and not open-source.

Radish doesn’t try to be an enterprise production store. It focuses entirely on local dev efficiency. Production Valkey relies on fork() for background snapshots, which Windows obviously doesn't have. Radish gets around this by default using an immutable Hash Array Mapped Trie (im::HashMap) for software-level Copy-On-Write. Taking a snapshot clone takes O(1) constant time. The main database loop keeps serving client traffic without heavy write locks, while a background thread dumps the cloned tree to disk. On an i3 loopback benchmark, it hits about 2.5M reads/sec and 720k writes/sec. Writes are too slow (around 1/4) to be compared with Valkey on Linux but if you compared to Docker or WSL it beats them.

(Fun side note: I actually experimented with a low-level, Windows-native Vectored Exception Handling (VEH) based COW implementation in a research branch called experimental-veh-cow. I prototyped a C++ blueprint using VirtualAlloc to mark memory pages read-only and intercepted access violations via a custom VEH handler to clone dirty pages on the fly. In bare-metal isolation, it cracked over 5.5 million writes/sec. Granted, doing 5.5M writes/sec isn't a fair comparison to a real Valkey server because the PoC was raw, minimal memory manipulation without the network stack and protocol parser overhead but it proved how fast hardware-backed page-faulting could be. Ultimately, I decided managing low-level memory exceptions was a bit too wild and prone to instability for a dev tool, so I stuck with the safer HAMT engine).

It currently supports a core subset of over 50+ developer commands cleanly routed through a custom matching router, spanning across:

• Strings: GET, SET (with all EX/PX/NX/XX variants), MGET, MSET, INCR, DECR, GETRANGE, etc.

• Hashes, Lists, & Sets: Full support for standard operations like HSET/HGETALL, LPUSH/RPOP, and SADD/SMEMBERS.

• Pub/Sub & Security: SUBSCRIBE, PUBLISH, AUTH, and basic ACL configuration handling.

• Generic System Ops: KEYS, SCAN, TTL/EXPIRE, database flushing, and real-time internal metrics generation (INFO).

It works with any standard client library, and while it plays nice with tools like Redis Insight, you won't really need it. Because it's a desktop app, it comes with a built-in GUI to visually inspect keyspaces, test Pub/Sub channels, and run an interactive terminal. It's simple, lightweight, and handles everything out of a single binary.

It's completely free and open-source (MIT). I'm looking to add Sorted Sets (ZSET) and Append-Only Files (AOF) next.

Check it out here if you're interested: https://github.com/satadeep3927/radish

I Would love to hear your thoughts on the HAMT snapshot approach, the VEH experiment, or any feedback on the implementation!

Mon bureau était un véritable cimetière de fichiers et de raccourcis. J'adorais le concept de Stardock Fences, mais je cherchais une solution plus légère, native et sans publicité ni suivi. J'ai donc créé Zones.

Zones ajoute des conteneurs transparents à votre bureau ; chaque zone affiche un véritable dossier (fichiers, raccourcis, applications) organisé par thème. L'application propose un dock de style macOS, un Launchpad, l'ancrage des actions, des thèmes clair et sombre, 19 langues, ainsi que les fonctions Annuler/Rétablir.

https://reddit.com/link/1up1hl6/video/4glrnhwftmbh1/player

Développée entièrement en C++ natif (très légère), Zones fonctionne hors ligne et ne nécessite aucun droit d'administrateur. Profitez d'un essai gratuit de 14 jours, puis d'un achat unique ou d'un abonnement à petit prix. Je suis le développeur solo — j'aimerais beaucoup avoir des retours honnêtes sur le concept et le site : fortis-apps-studio.com/zones

Je recherche principalement des retours honnêtes :

- Le concept est-il clair ?

- Voudriez-vous essayer cela au lieu de Stardock Fences ?

- Qu'est-ce qui rendrait le site web ou l'application plus convaincants ?

- Un essai gratuit de 14 jours + un achat unique est-il raisonnable ?

Problem

Windows Search has always felt too limited to me.

It can open apps and sometimes find files, but when I actually want to search my PC properly, it usually falls apart.

I want to search and use features like:

- Text inside files, code, and images

- Browser bookmarks and history

- Clipboard history

- Git commits

- Windows settings

- Local commands

- Local agents for Windows

Windows Search is not powerful enough for this workflow.

So I Built OmniSearch

OmniSearch is a fast, lightweight, local-first Windows launcher that opens with:

"Alt + Space"

You can also set your own custom hotkey.

It gives you one search box for your PC.

Instead of only searching apps or basic file names, OmniSearch can search across:

- Apps

- Files and folders

- Content inside files, supporting 50+ extensions

- Image OCR text

- Browser bookmarks and history

- Clipboard history

- Git commits

- Windows settings and Control Panel pages

It also features an AI agent powered by Hermes and includes a powerful clipboard manager that gives you features no other Windows clipboard manager provides.

The goal is simple: Find everything on your PC from one shortcut.

Why is OmniSearch better than Windows Search and other popular launchers?

- Free and open source

- Local-first

- Lightweight

- Designed to run easily on low-end Windows PCs

- Image OCR text search

- Blazing-fast search of content inside files, supporting 50+ extensions

- Blazing-fast search over centralized PC history, including browser history, Git commit history, clipboard history, and file history

- Hermes agents for local Windows tasks and long autonomous tasks

Links

Free and open source.

GitHub: https://github.com/PranshulSoni/omnisearch

Website: https://omnisearch-windows.vercel.app/

Feedback

I am currently maintaining OmniSearch, and honestly, I cannot find and fix every bug alone because building a launcher like this on Windows is genuinely hard.

I would love feedback from people who use Windows every day.

If OmniSearch solves a problem for you too, please consider leaving a star on GitHub.

If you have ideas, find bugs, or want to improve something, feel free to open an issue or contribute to the project.

Your feedback is always appreciated.

Wanted to share a little utility tool I worked on over the past days.

I've been working on Windows, for Windows for the past years and one thing that really annoyed me was the `pinentry` QT and GTK2 variants little dialogs from GNU bundled with Gpg4Win every time I wanted to gpg-sign something or even use pinentry to authorize reading private keys of the sort.

I (and claude) worked in `pinentry-win`, a fully Windows-native variant using purely Windows APIs.

In the era of AI, these dialogs are more important than ever in my workflow given interactive inputs are not really a thing in most of the harnesses.

https://github.com/flejz/pinentry-win

Give it a try if it you're also annoyed as I was. Fully DPI-aware.

Has anyone run into a tenant-level issue in Microsoft Partner Center where Store Listings can no longer be updated?

For about two weeks, every attempt to save a Store Listing (description, screenshots, etc.) fails with:

"Failed to save listing. Please reload the page or try again later."

Looking at the browser console, every save attempt results in a 403 Forbidden response from the clientsessioncontext API endpoint.

The weird part is that it doesn't seem related to listing content or validation. I can open an already-published listing, make no changes at all, click Save, and still get the same 403 error.

It's an account-wide issue, so it appears to be tenant-wide rather than app-specific.

I've already opened a support case with the Microsoft Store Certification Team. They requested a screen recording and HAR file, which I provided. On June 19 they told me the issue had been resolved, but after testing again (InPrivate mode and a different network), the exact same 403 error is still occurring.

At the moment the support cycle is taking several days between responses, so I'm trying to find out whether anyone else has seen something similar.

Has anyone experienced a tenant-level lock or synchronization issue like this in Partner Center?

If so, what ended up causing it, and how was it resolved?

I'm at a loss here while waiting for the next support reply.

Hello,

I'm developping a VST3 plugin for Digital Audio Workstations (DAWs). The plugin is a Windows DLL, which is loaded by the host DAW and extends its functionality. The plugin file has the extension .vst3 and uses the Steinberg VST3 API. My IDE is Visual Studio 2026.

My plugin provides a GUI containing regular Windows (common) controls. The GUI is supposed to use the theme of the Windows version the host DAW is running on. This works fine on most DAWs except one (Bitwig). When the plugin is loaded into Bitwig (which uses Windows themes itself), the GUI of my plugin has an oldfashioned W2k look rather than the modern Windows 11 look. In other DAWs such as Cubase, Ableton or Studio One the plugin looks fine.

I once found out how to solve this, but I forgot and I can't find the information any more. I only remember that I had to #define something in my code like "share aware".

Does anybody know how to solve this and can give me a hint? Thanks in advance.

Coreutils for Windows was announced during BUILD 2026 last week. Developers are finally getting Linux like commands in Windows without having to worry about workarounds or context switching. Plus, it is open source and built from the uutils open-source project. Microsoft has already started contributing upstream improvements to the project. I’d say this is a major win for developers! What do you all think?

Using ILSpy, you can decompile an entire .NET DLL or .NET Framework DLL to C# source code. It creates a Visual Studio csproj C# project.

Hot of the press, the new #winappsdk v2.2.0 was just released. New APIs and a bunch of fixes.

https://github.com/microsoft/WindowsAppSDK/releases/tag/v2.2.0

• Video Super Resolution AI API.
• New ApplicationData API for unpackaged apps. 
• New XamlBindingHelper APIs. 

+ several bug fixes

Try it out

• Download the 2.2.0 NuGet package to use WinAppSDK 2.0 in your app.
• Download and update the WinUI Gallery to see the WinUI 3 updates firsthand.

# Windows GPU‑Native Transitional Layer (WGTL)

## A Two‑Year Modernization Framework to Reduce Legacy Code and Enable a Unified Windows UI Future

## 1. Executive Summary

Many long‑standing Windows applications—some originally designed 20–30 years ago—now suffer from outdated windowing behavior, legacy menus, hybrid UI structures, inconsistent dialogs, DPI scaling issues, and frequent bugs. These problems are not caused by poor engineering, but by the absence of a modern, GPU‑native transitional toolset that helps developers gradually move away from legacy Windows technologies.

As a result, the same applications often look and perform significantly better on other operating systems, where unified rendering layers and modern UI frameworks exist.

This proposal introduces WGTL — Windows GPU‑Native Transitional Layer, an optional, C++‑native, GPU‑accelerated framework designed to help developers modernize their applications without rewriting everything from scratch. WGTL handles half of the modernization journey, while developers handle the remaining half—making the process realistic, affordable, and technically achievable.

Microsoft must share responsibility for modernization, because Windows has evolved dramatically while many legacy APIs remain unchanged. If an application runs on Windows, it must have access to the same level of tooling, agreements, and ecosystem support that other platforms already provide.

## 2. Problem Statement

### 2.1 Legacy UI, Menus, and Hybrid Interfaces

Many Windows applications still rely on:

- Win32 menus

- MFC‑era menu bars

- Legacy dialog boxes

- Old message boxes

- Hybrid UI structures (new window + old menu + old dialog)

- Outdated window chrome

These components are deeply tied to legacy code and cannot be modernized without breaking large parts of the application.

### 2.2 DPI Scaling Issues

Developers consistently struggle with:

- Incorrect scaling on multi‑monitor setups

- Blurry UI elements

- Misaligned controls

- Layout breakage at high DPI

- Per‑monitor DPI inconsistencies

These issues persist because no unified, modern rendering layer exists.

### 2.3 High Maintenance Cost

Developers spend enormous effort fixing:

- Window flickering

- Input latency

- Layout bugs

- Threading issues

- Legacy message loops

- Registry‑related problems

This slows down innovation and increases development cost.

### 2.4 Better Performance on Other Platforms

The same applications often run faster, smoother, and with better UI consistency on platforms that provide unified GPU‑native frameworks and modern windowing systems.

### 2.5 Registry Dependency

Windows applications still rely heavily on the Registry, which:

- Complicates deployment

- Increases corruption risk

- Slows modernization

- Makes cross‑platform parity harder

### 2.6 Lack of Motivation to Touch Legacy Code

Current Windows tools:

- Require too much manual work

- Do not provide GPU‑native UI

- Do not simplify legacy replacement

- Do not offer a clear modernization path

This makes developers avoid touching old code because it is risky, expensive, and slows development.

The result: user experience on Windows becomes worse compared to other systems.

## 3. Proposed Solution — WGTL

WGTL is a modern, optional, GPU‑native transitional layer that:

- Runs on top of DirectX 12 and WebGPU

- Is written in C++ for maximum performance

- Allows partial migration (e.g., 30–50% of the UI)

- Integrates with existing Win32/WPF/WinUI code

- Does not break any legacy application

- Supports all hardware that meets the published requirements

- Expands feature support over two years

WGTL is not a replacement for Win32. It is a bridge that helps developers modernize safely and incrementally.

## 4. Scope & Limitations

### WGTL does NOT:

- Replace Win32, WPF, or WinUI

- Force developers to migrate

- Break compatibility

- Rewrite extremely old code (e.g., Win95‑era MFC)

### WGTL DOES:

- Provide a modern GPU‑native UI path

- Reduce legacy code over time

- Improve performance and responsiveness

- Offer a realistic modernization strategy

- Help developers avoid full rewrites

- Provide a unified rendering model

## 5. Hardware Requirements

WGTL supports all hardware that meets the following requirements from Year 1:

### Minimum CPUs

- Intel 10th Gen+

- AMD Ryzen 3000+

- Qualcomm Snapdragon X‑series and newer

### Minimum GPUs

- NVIDIA GTX 1000+

- AMD RX 500+

- Intel Xe+

- Qualcomm Adreno (modern Windows‑on‑ARM GPUs)

### Minimum Driver

- WDDM 3.0+

### Minimum OS

- Windows 11 (with feature updates)

All eligible hardware is supported from the first year.

## 6. Two‑Year Modernization Roadmap

### Year 1 — WGTL 1.0

Focus: Core modernization tools

- Full support for all eligible hardware

- GPU‑accelerated rendering

- Vector graphics engine

- Text rendering engine

- DPI scaling engine

- Basic animation system

- Legacy integration layer (Win32/WPF interop)

- Tools for replacing old menus and dialogs

- Developer preview for major vendors (Adobe, Blender, Steinberg, Autodesk, etc.)

### Year 2 — WGTL 2.0

Focus: Legacy reduction + full integration

- Advanced layout engine

- Full animation system

- High‑performance compositor

- Complete hybrid UI support

- Tools for replacing legacy controls

- Tools for replacing legacy rendering paths

- Tools for replacing legacy text engines

- Tools for replacing old menu bars and dialogs

- Full integration with Win32/WPF/WinUI

- Vendor certification program

### After two years:

- All legacy‑related modernization tools are fully supported within WGTL.

- The only remaining work for developers is extremely old code paths (such as MFC or Win95‑era components), which cannot be automatically modernized.

- Microsoft provides the first 50% of the modernization journey through WGTL, and developers complete the remaining 50% at their own pace.

## 7. Microsoft’s Responsibility

Because Windows has changed dramatically over the years, Microsoft must:

- Provide modern tools

- Provide transitional layers

- Provide GPU‑native frameworks

- Provide agreements with hardware vendors

- Provide agreements with major software vendors (Adobe, Blender, Steinberg, Autodesk, etc.)

- Provide a clear modernization roadmap

Developers cannot carry the entire burden alone.

## 8. OEM & Vendor Agreements

To ensure WGTL succeeds, Microsoft must establish agreements with:

### Hardware Vendors

- Intel

- AMD

- NVIDIA

- Qualcomm

### OEMs

- Dell

- HP

- Lenovo

- ASUS

- MSI

### Major Software Vendors

- Adobe

- Blender Foundation

- Steinberg

- Autodesk

- Unity

- Unreal Engine

These agreements should cover:

- Driver optimization

- GPU scheduling improvements

- Hardware certification

- Joint testing

- Performance guarantees

- Early access to WGTL builds

## 9. Conclusion

WGTL is the missing piece in the Windows ecosystem.

It:

- Reduces legacy code

- Fixes DPI scaling issues

- Modernizes Windows UI

- Helps developers update 30–50% of their UI without rewriting everything

- Replaces old menus, dialogs, and hybrid UI structures

- Shares responsibility between Microsoft and developers

- Ensures Windows remains competitive

- Provides a realistic, gradual migration path

- Enables Windows to evolve without breaking the past

WGTL is not just a tool — it is the future of Windows modernization.

I got a very weird but interesting idea that I'd like to share with you all... you can find it here. it's about reviving the NT kernel agnostic environment subsystem system by making a custom environment subsystem that replaces win32 (CSRSS)
I'd like to hear your thoughts about it!

from a pure practical perspective, I don't really know any useful use case for it
but it's very exciting for me to work on just to understand windows internals + having fun with NT

[ Removed by Reddit on account of violating the content policy. ]