Looks good functionality wise, you can even "compile" an app to a HTML file. This is exactly how something like this should work :-).
However, appearance-wise it looks very noisy/distorted with some crooked elements (especially window buttons) and missing visual parts (mainly bevel edges). I made a screenshot with comments for it[0].
I guess this was made with AI which isn't that great at making stuff pixel-level unless you explicitly told it to check reference images and be pixel level precise, so i'd recommend firing up a VM with WinXP in classic theme mode (or even better, 86Box running Windows 95 or Windows 98) and grabbing a bunch of screenshots.
Also i found some bugs:
1. You cannot click on non-visual controls (or disabled controls) to select them (e.g. timer). You can still use the rect selection to select them and drag them around by resizing via the handles but clicking on them selects the form.
2. Adding a control doesn't update the controls list in the editor unless you double click a control without a handler (i.e. the form, as long as you remove the Form_Load handler). Even after the controls are updated, if the event list has only one event, you cannot have the editor add by selecting it (i guess because it is already the selected item and you don't receive an event about selecting it).
I tried to make a simple pong game but it seems no key or mouse motion events are implemented yet so all i did was to make a bouncing OptionButton :-P.
I'm working on my own with AI (separate from this one - unrelated), its a slow burn, but I want to make a source-compatible compiler. So far I can open up forms, and source code (its all IDE specific) but until I build up the actual compiler / debugger, its all cute but nowhere near where it could be. Whenever I have something worthwhile I will put it up on GitHub more than likely.
I've been using screenshots, but I also did find an old laptop I still had a licensed copy on (in my college years I had access to DreamSpark and MSDN).
Its fun project and has many bugs still , its major work to make this fully work as one would expect, but keep checking I am putting many new features and fixes now. Thanks for feedback.
> runtimeterror.com has no https which is available for free, so I'm not entering it.
It is a direct image link, it wont ask your password.
Also, https is not available for free even if some solutions are available without asking money for it. In this case: the site is on a shared host so the only option is the paid one from the host (so it isn't free-as-in-money) while the alternative is having a VPS and installing something like let's encrypt (which is more expensive than the shared host and requires me to play sysadmin for it, so not only it isn't free-as-in-money but also free-as-in-time).
> It is a direct image link, it wont ask your password.
Have you lived under a stone? No wonder we have so many vulnerabilities if people have no idea about images being malicious, exploiting image decoding libraries.
> runtimeterror.com has no https which is available for free, so I'm not entering it
I think your threat model needs some work here. What exactly does https guard against when downloading a jpeg? A intermediary swapping it out for a different jpeg?
Downloading things from an unknown domain over https still carries the risk of the site itself vending you malware...
Perhaps a compromised device on the local network can MiTM a javascript payload that exploits three zero days on HackerThemAll's browser stack, pwning his computer and finally enabling his super advanced, persistent adversaries to get exfiltrate his super important data.
And all that for what, for a VB6 screenshot on a hn comment threat while procrastinating on top secret work ?
That looks interesting, built it (took seconds) and it is much smaller than Pi in terms of what it needs to work (when i installed Pi in a fresh Debian container it downloaded ~500MB of stuff, which isn't exactly what i had in mind when i read it is minimalistic :-P but it is a container so i didn't care much).
I'm just running it now in its own source with Qwen 3.8 27B and llama-server and asked it to analyze the code itself. I'm mainly curious to see how it handles context compaction during tasks (what Pi does is almost seamless and AFAICT it isn't anything particularly fancy so i'd expect Hax to do something similar) and i guess asking it to analyze a whole C codebase would help trigger that with a 131,072 context. Unfortunately it seems to be missing some "context usage" indicator while it does stuff (it shows context usage in the prompt but not while working), but i guess if it does manage to analyze the C code properly, i can ask it to add that :-P and see how it fares (from my use of Pi i'm positive Qwen 3.8 27B can do all that stuff, so it'd mainly be up to the harness).
EDIT: also i wonder if it works nicely if it is possible to convert Pi transcripts to Hax - i have a few "in progress" and i'd like to continue where i left from, though while both seem to use JSONL for the transcripts i'm not sure if they're compatible
EDIT2: hrm, it tried to use more than available tokens during a compaction and stopped there expecting me to increase the limit (i can, but what if i couldn't?) and restart the llama-server. Pi sometimes does hit it but it manages to recover by itself without requiring any input by me (or to increase llama-server's limit).
> also i wonder if it works nicely if it is possible to convert Pi transcripts to Hax - i have a few "in progress" and i'd like to continue where i left from, though while both seem to use JSONL for the transcripts i'm not sure if they're compatible
I’ll sometimes ask the new agent to look at the previous transcript file.
FWIW the compaction had failed again, so i used Pi with the same prompt, same model, same config to compare. The prompt was "check the current directory" followed by "analyze the code and give me a report in `CODE_REPORT.md` on how it works (also a brief report here). Make sure to update `CODE_REPORT.md` frequently (i.e. every time you analyze a file) to avoid context loss from context compaction".
Pi ended up hitting a compaction during a tool call and finished without issues, which is what i expected - in fact after giving the instruction i left to visit a relative since i expected it wouldn't need me to babysit it.
FWIW after it finished, i asked it the following:
---
Can you answer me the following questions about how Hax manages the context?
1. How does Hax handle running out of tokens? It does have some form of compaction, but if the compaction fails for some reason (e.g. the summary ends up needing more tokens) what does it do?
2. Can it handle cases where the context runs out of tokens during tool calls and if so, can it recover? How?
3. What happens with compaction if an LLM produces a few large responses or the LLM reads a few large files? Does the process ends up summarizing the entire (or all but one) conversation? Or is the entire conversation lost?
4. Are there any safeguards in place to avoid overwhelming the LLM? For example any file and tool output limits? If there is and any limits are reached, how does it handle them?
---
It went on and checked the code and, briefly the response (it was bigger but i don't want to repeat the entire thing):
1. It doesn't update the session on failure (last "good" session is kept), running out of context is treated like any other error without any automatic recovery and you're expected to fix it by hand (personally i'm not a fan of this).
2. Multiple tool calls are fine (there is a 85% threshold check to trigger compaction and a 50k tool result limit) but if a response and results jumps from below 85% to over 100% despite being under the 50k limit, it doesn't trigger any compaction and the next request is denied by the provider (i.e. llama-server). I have a feeling this is what i hit when i tried Hax with its own code.
3. There is no recovery from a user turn (prompt + response + tool result) that exceeds the window. FWIW this also seems to be the case with Pi.
4. It found a bunch of safeguards (tool output cap, caps in bytes and lines for the read tool, bash writes to a temp file and only a part of it is sent to the LLM, edit size cap, etc). AFAICT it is the same as Pi with one neat addition in that there is a default 2 minute timeout for bash calls (i've seen the LLM more than once run a command in Pi and end up stopping for 30+ minutes because the command wouldn't end).
For 3 i asked it a followup question: "About 3: AFAIK Pi (the harness you're on right now) does a "spit" summarization where the old messages are summarized up to a cutoff/split point and replaced with the summary while the newer messages after the cutoff/split point remain intact, which allow a mostly seamless transition between compactions. Does Hax do the same or something similar?"
The response was that, no, it doesn't, it summarizes the entire context. Which TBH is a bit of a dealbreaker for me since i often rely on this "seamless" continuity in my prompts and feels like the main reason why compactions feel like a non-issue with Pi.
Take the above with a grain of salt, i only checked the code for the compaction not using a split/cutoff point between older and recent messages, the rest are whatever Qwen 3.8 27B understood, but they do match my short empirical test. Also if my own understanding of the code is correct, it seems to be using the same system prompt for the summary as for regular/interactive use while AFAIK Pi uses a dedicated "you're an expert summarizer" (or something like that :-P) prompt. Not sure if it makes much or any difference, with LLMs being what they are, but TBH whatever Pi does works great IME.
On the other hand the idea of a self-contained native AI harness in C/C++ is enticing, especially one that doesn't have any network traffic outside of LLM-related stuff[0] and explicit user requests (Pi does try to autoupdate and has a separate opt-out telemetry beacon - both of which are disabled in different means, one via environment variable and another via a setting, which smells a bit like an dark pattern to me).
Anyway, this is the result of my findings about Hax. It is neat, but TBH the context handling is the main dealbreaker for me, especially since i'm often having the agent do something in the background (using a local LLM isn't exactly the speediest workflow) and do other stuff or leave the computer alone, so the last thing i want is to babysit the agent for errors. Pi's split summarization and context overflow handling seem to work much better.
For now i'll probably stick with Pi (i have autoupdates and telemetry disabled and i hope there isn't any other hidden snitch in place) and perhaps at some point i'll do the NIH thing and make yet another agent myself :-P
[0] well, it does attempt to autoconnect to a potentially running llama-server in localhost without being explicitly told to do so (Pi wants explicit configuration) but meh
I use it with a local Qwen3.8 27B on llama-server, but I don't know what it means for it exceed any window.
you can use /slots on the llama-server if you want to get more up-to-date details on session token use.
I always run models in their default context, which is 262144 for Qwen3.8 27B. I've run sessions in hax where it hit that cap multiple times and compressed the context down to 15% and continued with no problem.
Well, if you're fine with not being up to date in terms of C++ standards there is also the OpenWatcom C/C++ compiler[0]. Jiří Malák (the main v2 dev) is doing a herculean job maintaining and improving it.
According to some older comment by jmalak, it is compatible with C++98/C++03 with some C++11 features though, yes, it isn't C++11 compatible (there are some stubs for C++11 that i can see in the code but nothing implemented).
And that's a thing though, SFINAE hinted at it but more recent versions of C++ constexpr and consteval together with relaxed constexpr and "if constexpr" and "if consteval" together with compile-time dynamic typing forced the compiler to more or less include an interpreter in the frontend.
Adding some features of C++11 isn't close to building a C++ compiler capable of 11, 14, let alone 17, 20, 23 or 26.
If you can rip out a compliant parser, it might even be better to start over on a new compiler frontend if your current compiler frontend is targeting at pre-11 level.
I wonder if the source-to-source compilation could be used to transpile C++ code/libraries to other languages - e.g. could this be used (with appropriate modifications of course) to compile FLTK into Free Pascal code and used directly by Lazarus as a backend for LCL? Trying to use C++ libraries from non-C++ is always a PITA, especially if you want to avoid dynamic linking.
Also, since i mentioned Lazarus, if it can compile itself to Free Pascal, i wonder if it'd be useful for adding C++ support to Lazarus itself so that Free Pascal and C/C++ can be mixed in a project to make self-contained executables for desktop applications. It'd most likely need much more work than that just the compilation to make it a first class citizen like Free Pascal itself is for Lazarus/LCL (e.g. things like the object inspector and code tools being able to understand C++ well enough so that refactoring and stuff like doubleclicking on a button in a form automatically declaring and defining the handler and moving the editor cursor to the newly defined handler's code body), but maybe it could be used as a starting point.
Well, Borland had the benefit of being in control of both compilers :-). C++ Builder even had Object Pascal compatible extensions to link against VCL (which was written in Pascal).
You can already mix Free Pascal with C/C++ code if you use the same linker and libraries - i did manage to get FLTK statically linked with an initial backend for Lazarus in fact - this shot[0] shows a form and a few buttons from a self-contained binary on Linux (it links against FLTK statically and X11/etc dynamically).
But it is a PITA to get working for C++ libraries specifically (and you need a C intermediate for FPC to use). Also i couldn't get it to work for Win32, only Linux.
Borland made the virtual tables used by C++ and ObjPascal compatible, that's why it was possible to mix the two languages. If the design is different than it becomes a much more difficult problem.
glfw is smaller and more focused (SDL adds a TON of stuff, including even its own GPU abstraction API) so the choice was most likely made because of that focus.
Interesting that not even Raymond Chen knew about Shift+Click - i found it at some point years ago by trying random stuff on the Win32 controls and it was what i used to try whenever i wanted to tell if a program was using real Win32 controls or made its own since pretty much no toolkit had this behavior including Qt[0] :-P
[0] i think Qt might have added it at some point but it has been several years since i used Windows as a main OS and bothered to check it
A very significant difference is that AIs are programs, not people.
Perhaps it might be because i don't use any cloud LLMs, but the LLMs i use are all just data for a program running on my computer just like any other program and i don't really see them as any different than running -say- Bison to write a lexer or whatever (sure, Bison gives you the same output for the same input, but that is because LLM inference engines just add some randomness in the mix as that works better for the overall output - again, not any different than, say, rendering a 3D scene with a pathtracer that takes random samples: same input, different output -- or really any other thing that involves randomness).
That the combo of an LLM inference engine and weights kinda writes like a human and works with text in natural languages doesn't mean it is any different than any other piece of software.
I mean, i don't know about you but personally i'm not a fan of the idea of commissioning GCC to compile my code or Awk to process my text - even if i suspect there are business people out there who would love it :-P
I personally don't mind cloud LLMs as long as I'm aware of what's being sent to the internet.
I was thinking that it's a new thing for our field for such products only to be available behind a paid service. Before LLMs, there was always a local version of a product that worked just fine but with less capacity. Say, amazon vs local kubernetes, or CGI machines at Disney vs local Blender.
But on many other fields is normal for that to happen. Blacksmiths don't usually have a small steel furnace in their homes. Nurses don't buy a personal version of a CT Scanner to practice at home.
You really can’t see a difference between what Bison and GCC do and what an LLM does? You cannot tell GCC “I want a ZX Spectrum GUI” and get a working result.
The difference is that you'll get a different "ZX Spectrum GUI" each time with an LLM, but the same result with a compiler.
The actual work in both cases is not to write the source code, but to figure out and describe exactly what you want. In one case (traditional programming) this specificion happens directly in non-ambigious source code, in the other case (steering an LLM) you specify via an imprecise human language.
Quite often the human language specification is actually "good enough" to get what you wanted, but the more you need to go into specific details, the more the difference to traditional coding disappears.
Sure. If I ask my roommate to go make me a ham sandwich without mayo, I expect them to observe basic hygiene practices, too, but I am comfortable with them just handing me the sandwich and saying ‘there on you go - sandwich’ rather than “Here is an edible sandwich: No mayo, no lettuce – just bread and ham. And the load-bearing insight that makes it work: it doesn’t use the open ham from the fridge that was past its use-by date. That one decision changed everything.”
> I would hope someone didn't just fork it and Oracle owns the rights to it somehow?
Beh, i used to use Java all the time for a bunch of stuff (mainly desktop tools and the like) but after Oracle bought it my interest to it dropped like a rock and remained on the ground after the whole Oracle vs Google circus :-P.
Nowadays i still avoid any languages primarily backed by some large corporation.
reply