miniblink49: a one-file Chromium widget, and a C API that takes two calls

Two C calls and you have a browser window

The API is deliberately small, and the README leads with the shortest possible example, a borderless window:

// 无边框窗体 borderless window
wkeWebView window = wkeCreateWebWindow(WKE_WINDOW_TYPE_TRANSPARENT, NULL, 0, 0, 640, 480);
wkeLoadURLW(window, L"miniblink.net");

Two functions: create a web view of a given window type and size, then load a URL. The description says that through the exported pure C interface a browser widget can be created in a few lines of code, and the names in the example, `wkeWebView`, `wkeCreateWebWindow` and `wkeLoadURLW`, are the whole vocabulary you need to start.

For anything beyond that, the README points at two places. The compiled SDK on the releases page contains a `demo_src` directory described as a complete example, and a separate repository, `weolar/mb-demo`, holds demos as well. API documentation lives at miniblink.net/views/doc/index.html, with a longer introduction article on Zhihu.

The feature list also states that the widget can be called from C++, C# and Delphi, which is what a pure C interface buys you.

The tree is Chromium, five V8 versions, and a wke layer on top

The root directory listing is the clearest description of the project, because it is the Chromium source tree with a Miniblink layer on top.

There is `orig_chrome/` for the upstream source, `skia/` for graphics, `gin/`, `net/` and `media/` and `ui/` and `content/` for the Chromium subsystems, plus `cc/`, `base/`, `gpu/` and `vc6/`. On the Miniblink side there is `wke/`, which is the API layer the example above calls into, and `wkexe/`, which is the executable side.

Two directories explain features that would otherwise be mysterious. `quickjs/` is an embedded QuickJS engine alongside Chromium's own JavaScript, and `node/` with `electron/` is the embedded Node.js that lets the widget run Electron style applications.

The six V8 directories are the surprise worth noting: `v8_4_5/`, `v8_4_8/`, `v8_5_1/`, `v8_5_7/`, `v8_6_7/` and `v8_7_5/`. So the repository carries six pinned V8 versions rather than one. There is also an `mbvip/` directory whose purpose the README does not explain.

The documented way to get the code is a download, not a build

The build section is three sentences and the first is a refusal: it does not recommend building it yourself, and directs you to the compiled files on the releases page.

The reason given is worth quoting in spirit: because there are many updates every day, the author cannot guarantee that every update compiles. If you hit a compile error, the instruction is not to report it but to wait for the next commit.

That is an unusual position for an open source engine to take, and it follows from the shape of the project. The README says there are many updates every day, so the failure mode the author is protecting you from is a tree that is mid-update and does not build at all.

The practical consequence is that there is no reproducible source build for consumers. You take a dated SDK from the releases page, and the tags are dated: 20251212, 20250928 and 20250717. If you need a change to the kernel, you are waiting on the author rather than patching a branch.

This is the old kernel: 108 is on openEuler, 132 is on the way

The opening statement is the one to read before anything else, because the repository is not the current thing.

The miniblink 108 kernel version reached a strategic cooperation with Huawei and has been open sourced inside Huawei's openEuler system, at the Liteview project. This repository collects the older 49 kernel version, and if you need a newer one you should look at the 108 version instead.

The 132 kernel is described as also about to be open sourced, and the executable and header download address, which includes the latest 132 version, is the releases page of this same repository. So the same place serves the old kernel's source and the newest prebuilt binaries.

One release title makes the confusion concrete. The tag 20250717 is titled as the mb132 version, dated 250730, describing a large number of bug fixes and IPv6 support, and it sits in a repository named for kernel 49.

If you are evaluating this project, that mismatch between the directory name, the tags and the newer kernel is the first thing to get straight.

Support runs through a forum that needs QQ verification

The contact section is unusually detailed, and one line tells you the support model.

The developer forum is at bbs.miniblink.com, and the parenthetical note explains the catch: after registering you have to add the author's QQ so they can verify you. So access to the support forum is gated on a direct contact, which is a personal arrangement rather than an open one.

Alongside it there is a Telegram group, two QQ groups where one is listed as joinable and the other as full, an email address, and a note that WeChat has to be requested by email rather than published. The Zhihu column is also listed as a place to follow.

The opening statement also asks readers to respect open source and the labour of the author updating this full time for years.

So if you are evaluating this as a dependency, the technical support path is a person rather than a process, and that is worth pricing into your decision.

Headless mode, request interception and cross-origin are the embedded-app features

The feature list is short and each item answers a question an embedder asks.

Size is the first claim, extremely small, and the second is the language reach through the C interface. Then there is embedded Node.js so Electron can run, customisable features with the ability to simulate another browser environment, and support for Windows XP and NPAPI, which is legacy plugin support that a current Chromium has dropped.

HTML5 support and friendliness to front end frameworks come next. Then three items that only matter because the widget is embedded: cross-domain features become available once you turn off the cross-origin switch, network interception lets you replace any resource or any script of any site with a local file, and there is a headless mode described as saving a great deal of resources and suitable for a web crawler.

Those last three are the reason to embed a browser engine instead of writing a renderer: you can route traffic, pin scripts to local files, and run with no window at all.

Editorial conclusion

miniblink49 suits an application that needs to show HTML inside its own window and would rather have a small Chromium-based widget than a system browser, and that can live with a C interface and a prebuilt SDK. It does not suit a team that needs to compile the engine itself or to reproduce a build from source, because the author explicitly does not recommend it, and it does not suit you if you need the current kernel, since this repository holds the older 49 version while 108 is on openEuler. Verify three things before you commit: which kernel version your SDK actually contains, since the releases page carries 132 as well as 49, that the sample in `demo_src` runs on your platform, and what your exit path is, because technical support runs through a forum account that has to be approved by the author.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. weolar/miniblink49 on GitHub