That way is … Links.

This concept did not originate with Windows. Not even close. It existed since the early days of operating systems and goes back to Unix. Historical Unix filesystems were designed around the idea that directory entries refer to filesystem objects rather than the filename somehow being inseparable from the data.

The classic Unix ‘ln’ command creates another link to an existing file. Hard links were part of Unix long before symbolic links appeared.

You can make a file appear in several folders without creating several copies. You can make one directory appear somewhere completely different on the disk. You can make software believe that a folder exists at ‘C:\Something’ while the actual data lives on ‘D:\Storage’. You can even construct entire duplicate-looking directory trees that consume almost no additional disk space.

The strange part is that Windows Explorer has never exposed that option to the user. The most the user can do is just copy or create a shortcut, and a shortcut is not a link to the file. A Windows shortcut is essentially a small file containing information about another file, folder, or application. For example, a ‘Photoshop.lnk’ on your desktop can point to ‘C:\Program Files\Adobe\Photoshop\Photoshop.exe’, but the shortcut itself is a real ‘.lnk’ file. Explorer understands it and opens the target when you double-click it. But the operating system does not generally pretend that the shortcut is the target. That distinction matters. If software expects ‘C:\MyProgram\Data’, you normally cannot create ‘C:\MyProgram\Data.lnk’ pointing elsewhere and expect the application to behave as though ‘Data’ were a real directory.

The application may not understand Windows shortcuts at all. Shortcuts are primarily a shell/user-interface feature. Filesystem links operate at a lower level.

That is exactly the problem Link Shell Extension, by Hermann Schinagl, solves.

Link Shell Extension adds hard links, junctions, symbolic links, volume mount points, link-aware cloning, and several more advanced operations directly to Windows Explorer’s context menu. Instead of opening a command prompt typing ‘mklink’, ‘fsutil’ or other commands, and remembering the full file paths, you can pick a file or folder, go somewhere else, and choose what kind of link you want to create.

Now, there are different kinds of links, and for a full overview, check out the Link Shell Extension page for more details, but the basics are:

Hard Links

A hard link is probably the most conceptually interesting type.

Suppose we have ‘D:\Photos\master.jpg’ and create a hard link to ‘D:\Website\images\hero.jpg’. There aren’t now two JPEG files. There is still one underlying file. It simply has two directory entries pointing to it. Microsoft describes an NTFS hard link as another directory entry referencing the same file. Programs can open any of those names and modify the file, and the file remains in the filesystem until its final hard link has been removed.

Hard links have an important limitation, which is that they must remain on the same filesystem volume, so no hard links between drives.

For ordinary Windows use, hard links are generally used for files, not directories.

Symbolic Links

Symbolic links, or usually shortened to symlinks, are the closest Windows equivalent to the Unix links most Linux users know, and are the closest to how actual shortcuts should work or how people think they work. A symbolic link is itself a filesystem object containing a reference to another path. Unlike a hard link, it does not refer directly to the same underlying file record. It refers to another path. That difference gives symlinks much greater flexibility.

Windows symbolic links can point to either files or directories, and Microsoft supports both absolute and relative symbolic-link targets. They can also target remote paths.

Symbolic links arrived natively in NTFS with Windows Vista. Microsoft explicitly describes them as having been implemented partly to improve migration and compatibility with Unix style systems.

Hard Link vs Symbolic Link

The distinction becomes much clearer if the target disappears. If there’s a hard link to a file A called B and you delete A, B is still pointing to the same data, but with a symbolic link, if you delete A, then B stops working as there is no longer a location A to which it was pointing. And B becomes a dangling link.

There are other types of links, but they are more specialized or just obsolete and superseded by symlinks.

So Why Doesn’t Windows Explorer Just Have a “Create Link” Button?

This is where things become more interesting. The underlying filesystem can do all of this. Windows itself uses these mechanisms. Microsoft provides APIs and command-line utilities for them. There is no single official Microsoft statement saying “we deliberately hid filesystem links from Explorer for reason X”, so the following is an interpretation based on the architecture and historical behavior of Windows.

There are several likely reasons.

Windows Was Built Around a Different User Model

Unix exposed filesystem concepts directly to technically oriented users very early. Commands such as ‘ln’, ‘mount’, ‘chmod’, and others were fundamental system-administration tools.

Windows evolved with a much stronger graphical abstraction. For ordinary users, a ‘file’ or a ‘folder ’ was a deliberately easier concept than filesystem object, directory entry, relative symbolic target, and so on. That abstraction was probably beneficial for most users. But power users lost convenient access to some very capable filesystem features.

Links Can Produce Very Surprising Behaviour

Hard links can cause confusion because Explorer may show multiple files with full file sizes even though those names reference the same underlying content. Microsoft specifically warns that hard links and reparse points can make disk-space calculations confusing.

Backup software also has to understand links correctly. If it blindly follows a junction, it may copy the same directory twice. If links form loops, naïve recursive software can get into serious trouble.

So this isn’t merely Microsoft hiding an obvious button. Links genuinely introduce semantics users and applications need to understand, but if you are just linking two folders, there should not be an issue.

Security

Symbolic links can also create security problems when applications are not written to handle them safely. One process may believe it is writing into a harmless directory while a link redirects the operation somewhere unexpected. Microsoft therefore historically treated symbolic-link creation as a privileged operation.

Modern Windows has become friendlier to developer symlink workflows, but the historical security model helps explain why symbolic links never behaved quite as casually as Unix users might expect.

---

Enter Link Shell Extension

Once installed, it adds link operations directly to Explorer. The basic workflow is wonderfully simple. Select something, right click and choose ‘Pick Link Source’. Then go to another directory, open the context menu, and choose something such as ‘Drop HardLink’ or Drop As...

• Junction

• Symbolic Link

• HardLink Clone

• Symbolic Link Clone

The extension also supports drag-and-drop creation. It is one of those utilities that makes a hidden filesystem capability suddenly feel like a normal Windows feature.

Moving Huge Application Data Off C:

Another excellent use case is moving storage without changing what an application sees. Suppose a program stores 500 GB in:

C:\Users\Ivan\AppData\Local\SomeApplication\Data

Move it to:

D:\ApplicationData\SomeApplication

and create a symlink at the original location.

The application continues requesting:

C:\Users\Ivan\AppData\Local\SomeApplication\Data

while NTFS transparently redirects those operations to D: \.

This technique can be useful for:

• game libraries

• model files

• caches

• development tools

• giant SDKs

• application databases

• media indexes

• software that refuses to let you change its data directory

Obviously, anything involving application databases or actively used data should be moved carefully and with the application stopped.

---

# Shared Assets Between Projects

Imagine five projects all need:

textures\

models\

samples\

reference\

Copying the assets creates five independent versions.

A junction or symlink can instead point every project toward:

D:\SharedAssets

For example:

Project-A\Assets ──┐

Project-B\Assets ──┼──> D:\SharedAssets

Project-C\Assets ──┘

Update the central assets, and every project sees the change.

Developers have been using filesystem links for exactly this type of architecture for decades.

# Mount Points

Link Shell Extension also exposes ‘volume mount points’. These are conceptually related but operate at the volume level. Instead of giving a disk its own drive letter like E:\, Windows can mount the volume inside a directory such as ‘C:\Storage\Archive’.

From the user’s perspective, ‘Archive’ looks like another folder. Behind it is an entirely separate filesystem volume. This is another idea Unix users will recognize immediately: filesystems do not fundamentally need drive letters. Drive letters are mostly a Windows convention. NTFS mount points allow Windows to behave much more like a unified filesystem tree.

And that’s it. Link Shell Extension solved my storage problem beautifully. It doesn’t replace NTFS. It doesn’t install some virtual filesystem. It simply exposes capabilities that were already sitting underneath Explorer.

For a developer, administrator, digital hoarder, photographer, game modder, AI enthusiast, or anyone constantly moving giant directories around, it can fundamentally change how you organize storage.

Once you understand filesystem links, copying a 100 GB directory simply because another program wants to see it somewhere else starts to feel almost barbaric.

Pixel Ortho is my take on that idea. The idea is that you already have clean orthographic drawings of an object; the app can use them as constraints to produce a simple 3D result. It lacks the polish and options of the original, but it’s a good starting point for them to be added in the future if needed. Pixzels is a paid version after all.

The pixel workflow starts with bitmap projections. These are flat images of the same object from orthographic directions: front, left, back, right, top, and bottom.

The minimum useful setup is usually front, left, and top. Front gives width and height. Left gives depth and height. Top gives width and depth. Once those three planes are aligned, every possible x, y, z position inside the grid can be tested.

I took ambulance projections to test out the app without asking; hope no one will get mad about that.

The test is simple. Front says this x/y position is occupied, left says this z/y position is occupied, top says this x/z position is occupied; if all active shape views agree, keep the voxel. That creates a voxel volume from the intersection of projections. The output is intentionally mechanical. If the input views line up well, the model reads well. If one view is shifted, scaled differently, or drawn from a slightly different angle, the intersection shows that immediately.

The voxel mode uses a shared square grid. 128 x 128 is usually the practical upper end for detailed sprites. Smaller grids are faster and cleaner for rough forms, icons, and early tests.

There is also an auto-size option. When “Auto-size grid from first imported image” is enabled, the first imported bitmap sets the grid size from its largest dimension, capped at 128. Later imports use that same grid. That matters because all views must share one coordinate system. If the front image fills the grid and the side image is tiny within it, the generated result is not wrong from the app’s perspective. It is doing exactly what the projections asked it to do.

Bitmap imports use transparency as the main signal. Transparent pixels do not create voxels. Opaque pixels do.

The preview and export do not create one separate cube mesh per voxel. The app builds one surface mesh by checking neighboring voxels and emitting only exposed quads. Internal faces are skipped, which keeps the result smaller than a naive cube-per-voxel model.

The exported GLB contains the generated geometry, vertex colors, and one material using those colors. It does not include the reference planes, source files, UI state, or project JSON.

Voxel mode also includes projection painting. Choose `Edit` on a source projection, then paint or erase pixels directly on that projection.

This is not a separate texture paint system. Editing the projection changes the source pixels, so the voxel shape and the sampled surface colors rebuild from that edited projection.

That is useful for quick fixes: closing a gap, erasing a stray background pixel, moving a silhouette toward the result you actually intended, or checking how a small projection change affects the 3D volume.

Currently, those edits are not saved to disk or edited on the original input, but that’s an option that will be added in the future.

I wanted to see if similar thinking can be made using vectors. Something like AmbigramGenerator.

The vector workflow is separate from the voxel workflow. It starts with filled SVG projections and builds a vector visual hull.

Instead of turning pixels into occupied grid cells, the app parses closed filled SVG shapes, flattens curves into polygon contours, extrudes each projection through 3D space, and intersects those extrusions.

Vector mode supports filled closed geometry. Unsupported content is ignored with a warning. That includes strokes, open paths, clipping, masks, filters, and text.

The important detail is that strokes do not constrain the model. If a line needs to affect the result, it has to be represented as filled geometry.

When you select “Edit” on a vector source, the camera locks to that source plane. The white points are anchors. The purple points are Bezier handles. Dragging an anchor also moves its attached handles. Dragging a handle changes the curve. The source path updates during the drag, and the final Boolean mesh rebuilds when the edit is committed. Vector sources also have offsets and visibility toggles. Visibility matters because only visible vector projections participate in the generated mesh.

It could be interesting to add more features to it, but for now I’m satisfied; my itch was satisfied. A working base is here.

We live in a strange world; I feel it has become like a mantra enabling us to feel safe in our ignorance while we watch the world pass us by. Or better yet, feel we can’t understand. And I feel, so many feels in this paragraph, for those people. I’ve spent my entire life trying to be in sync with the world's knowledge, as much as a single person can. I don’t need to understand every nuance and every detail of technology, process, biology, sociology, but to know general strokes. That enables me to focus on finding out more about a subject I'm interested in at any time. … Master of none, but still better than master of one.

And, I’ve finally fully embraced AI. I haven’t seen a line of code in my off time in weeks, months at this point. ( I code for fun too )

I remember talking to a college colleague of mine in 2006 at a nondiscript bar attached to a supermarket about artificial intelligence and how it could emerge spontaneously from the chaos of information we produce. At that time, I thought about my research about how much information the internet can contain at a certain time, which I completed a couple of years ago, way before the AI revolution of 2024.

I was close; it did not self arrange out of chaos at a global scale, so far we know, but did self arange, with guidance, in neural nets.

As I’m writing this, I’m cracking up. Decades of skill summed up in a couple of billion neuron connections. LoL. I know it’s not funny, but it kinda is. The sheer power is intoxicating. Ability to finish projects, experiment with different approaches. The ability to go from idea to working concept is just a prompt away. It truly is a drug.

I could not have predicted it; it was decades away, if ever. But now, here we are. On my modest setup at home, I'm running a 35 billion parameter mixture of experts model, Qwen 35B MoE via LM Studio, that can do tasks that would take me weeks, if not months, to complete, and it does it in minutes. It still breaks my mind thinking about it. Frontier models have over 700 billion parameters and some over 1.5 TRILLION, but, as it turns out, for tasks like coding, they don’t need that much. They need as few as a dozen billion.

I don’t think the future is some global supercomputer; I think that what I wrote in my post about Apple is still correct.

The future is local models. It may seem like it's unattainable, but when, not if, the bubble bursts and memory and compute become affordable, everyone will run their local AI models. Let’s just look at memory. High speed memory this, high speed memory that, but I’m fine if a task takes a couple of minutes longer; that’s just fine. I’m on an AM4 platform with DDR4 memory at 2400mhz, nowhere close to 6000mhz or more that a newer system can achieve, and that’s fine. System memory speed is important, as a large portion of the model I'm running is offloaded to system memory; if not, it would all be on fast GPU vram. And at the end of the day, data is mine, output is mine, control is mine; no one is mining me for data.

I remember a time when 60mb hard drives was a luxury. I remember 5.25 inh drives, not the 3.5’’ disk drives that everyone nowadays thinks of as a save icon. The actual 5.25inch disk that was flimsy as hell, and where the name floppy disk comes from, as you could use it as a freaking fan. And, what’s more to the point, it was not that long ago; I'm not some senile greybeard techno freak; it’s just that we have attention and retention deficits and think that everything that happened 30 years ago is ancient history.

Today, I have a 2 terabyte drive, one of many, in my system, with “modest” 32 gb or system memory. I remember trying to optimize my apps and fighting the bloat for every kilobyte so that the entire Windows app remains bellow 1mb, and feeling ecstatic about it. Now, a freaking Notepad with modern bells and whistles is above 100mb. Such absurdity.

The point is, a 700 billion parameters AI model that requires 1Tb of working high speed memory are not that unattainable. Yes, they are expensive now. Well, if you are well off and have 5k or so to spend, you can get NVIDIA Spark or an AMD equivalent 365 AI with 128 GB of unified memory. Get a couple of those or two Mac Studio Pros with 512 GB each, and you've got yourself a full-blown local equivalent to ChatGPT.

So, yes, it is expensive but not like it's unachievable or that the path towards domestication of that technology is not visible. It is already present.

I’m aware my hardware is not up to snuff to run more productive models, so until that time I’ll just pretend to be happy to spend over 14.000 monopoly bucks on ChatGpt, but that can not last. Such subsidy can not last.

We should all be aware of the ancient Chinese proverb or curse, depending on who you ask: may you live in interesting times. I thought that those times were behind me, but as it turns out, we are in the middle of them right now.

I took a couple of weeks off writing to test and finish a couple of projects I wanted to do, so stay tuned.

One day, while browsing the TikToks, the almighty algorithm served me this video, and I thought, " That is so cool, I also have access to modern AI coding tools, let’s give it a whirl”.

@made.by.antonWhen I was a kid, mobile phones were just starting to appear and the only pixel-based imagery I could create was a two-frame animation made of dots and dashes in a text message on my Nokia 5110. To be honest I only wanted that phone so I could design inappropriate animations to send to my mates during the most boring classes. Little did I know then that I’d grow up to be a pixel pusher. I never imagined this tech would evolve so far beyond recognition, becoming the universal building block for everything we see, even by reinventing the pixel itself. Fonts: Tobias by @xyz_displaay NaN Tragedy Display Mono & NaN Serf A Display by @nan_xyz Icons by @nounproject
Meat by Thuy Nguyen Owl by Pinky Cat and snake by Kim Sun Young Cheese by Visual Language #graphicdesign #typography #branding #ascii

Tiktok failed to load.

Enable 3rd party cookies or use another browser

At its most direct, the app can turn uploaded media into ASCII art. A photograph becomes a field of glyphs. A video becomes a moving grid of characters. Shadows, midtones, and highlights are mapped into different marks, and the app gives the user control over the whole translation process.

The grid resolution can be changed so it looks blocky or increased to resemble the original image or video more closely. The background color can be changed. Brightness can be inverted. The output can zoom, pan, rotate, scale, and shift over time.

The core of the app is the seven-state system. Instead of treating an image as a continuous blur of brightness, the ASCII Dither Filter divides it into seven tonal levels, from deep shadow to highlight. Each level can have its own color and its own uploaded SVG. The app can read colors from the uploaded image or video and apply them directly to the ASCII. It can also extract a seven-color palette from the source media, giving the shadow-to-highlight ladder a palette that belongs to the image itself. If the user wants a more synthetic look, colors can be randomized, cycled, or animated between keyframes.

Animation is where the tool becomes more than a still-image processor. Every major property can be keyframed: glyph sets, colors, zoom, zoom position, rotation, scale, inversion, source-color behavior, and other filter settings. The timeline sits below the main canvas so it can be edited with more horizontal space. Keyframe markers show where changes happen, and a dedicated keyframe list appears when an animation exists.

This makes it possible to build gradual transformations. An image can begin as a tight monochrome ASCII grid, then expand into colored SVG shapes. A video can start with small upright glyphs, then rotate and scale into a more abstract pattern. A palette can jump from source colors into random tones and then interpolate into another saved state.

Video handling follows the same logic. When a video is loaded, the animation timeline adapts to the length of the clip. Scrubbing the timeline also scrubs the video frame, so the filter settings and the source footage stay connected.

Animation can be saved and exported as a WebM video.

If you would like to experiment with video, you can get free videos at Pexels, but any image would do.

This was a fun project, and the code can be found, as always, on Barn Lab’s GitHub page.

alternative https://www.dailymotion.com/video/x89av60

alternative https://www.dailymotion.com/video/x8jxnie

https://www.dailymotion.com/video/x9bbwxe

https://www.dailymotion.com/video/x8gz92x

The idea is simple. Use the Wii sensor bar, which is just two IR LEDs spaced at a specific distance apart, and invert the tracking. Instead of the Wii sensor bar being static, he made the camera static and the sensor bar movable. As LEDs are placed at a known distance from one another, all kinds of data can be extrapolated, such as distance from the camera, rotation, angle, etc.

The concept was such a paradigm shift that he was invited to demonstrate his idea at the TED conference.

Now, that approach was not that new as TrackIR did a similar trick almost seven years earlier and is still in business. But it is expensive, while the Wii at that time was omnipresent, and such a “simple” hack was visibly impressive.

That was all good 18 years ago, but now we have AI models galore. In 2019, Google released MediaPipe. An AI model for human pose tracking with a total of 543 landmarks that can be tracked. Also, the model can be focused on certain parts of the body to increase tracking accuracy and speed.

And that’s what I did with my earlier tests, where I wanted to create a window to the past using Blender and its internal scripting.

Well, it worked, not well or fast, but it did, and since 2022, Google has improved the model to the point that a tiny, tincy model that is less than 4mb can detect hundreds of facial points really well now and do it fast.

From the original Blender script, it evolved into a standalone demo app with which I’m tinkering. It can be found as per usual on the BarnLab GitHub repo.

There are a whole lot of different customization options with which you can play around, but ones that I would suggest you alter first are to reduce the room depth and depth sensitivity, as defaults are currently a little too aggressive.

You can load custom targets as .GLB, which can be exported from Blender.

One additional note: don’t use “Use scene.glb” unless you provide such a file. Mine is too large for GitHub. It will replace the entire “room” with a custom scene for you to look around as if through a window.

This is an ongoing experiment and should have updates, so stay tuned. Until then, give it a twirl. Any suggestions or improvements are welcome.

The project first appeared on Yanko Design, and, like most posts there, Lumigrids was just a design practice without the end product.

I searched far and wide and found no mention of any product, just concept art and ideas for the last 8 years, with the last being from 2020, and it shows a weird deja vu effect (note from future me as i had this post in draft for a while, I don’t know why I wrote that it has a wierd dejavu, but I’m leaving it in for future contemplation, there has to be a reason I wrote this).

The concept is interesting, but I can also see why it was never realized as a commercial product. It projects a laser grid in front of the cyclists, and based on how warped the grid is, the cyclists could be warned about potholes or any unevenness on the road.

Why not just use a bike light? Well, that’s the question. A bright bike light should reveal any obstacle, with the added benefit of being an actual light that lights up your path much further than this, making this approach nothing more than a gimmick. But an interesting one which, as mentioned, got stuck in my mind, and now that I have some grown-up money, I could actually get unstuck.

To start off, I was thinking of using a line laser. I know I have a line laser in the barn lab somewhere that was used in early experiments with laser line 3D scanning. But, then again, could it not be possible to make a lens that projects a certain image? eBay to the rescue.

A little search later, and we have this

So I ordered some lasers, lenses, and casings to put them in.

Now we wait for some free time to get them all put together, so stay tuned.

But last week, a YouTube user named ancientjames posted his new experiment with a volumetric hologram that actually looks promising.

His channel got on my radar when he used a crystal cube engraving as a projection surface. That was brilliant. He called it a Solid State Volumetric Display. Where he sliced the resolution of a projection into layers, and each of the layers contained the resolution/n layers of pixels. So More layers, less resolution. Then, all layers are aligned they create a pixel grid equal to the resolution. Then you can project to different layers as you know which pixel is on which depth layer, and get a 3D image of low resolution. Remember, the projector resolution is divided by the number of layers. Here, the biggest issue is aligning everything correctly.

This time, he went a step further and, in my eyes, was even more impressive. When I saw it, I was instantly reminded of SeaQuest DSV Professor Martenson's hologram projection. Or Heliodisplay, now defunct, decades ahead of their time.

His approach uses the same principle but makes it way more advanced and impressive.

A projector image is split into 8 different views of an object, so again, the projector’s resolution is divided by 8. Those 8 views are then recombined with mirrors that converge at a central point where a bunch of water atomizers produce fine water vapor that’s used as a projection screen medium.

The result is just shy of amazing. With a better projector or more of them and some fine tuning of alignment, I can truly say that this is the first real contender for a free standing volumetric display that will not chop off your fingers if you try to touch it. Most current volumetric displays use fast moving screens or blades to create an image and are usually housed behind protective glass. Ancient even built his own version of that finger chopping monstrosity.

Also, one suggestion would be to add a top shroud that would pull the water vapor up and make it a closed loop, some water is reclaimed and does not contribute to the humidity of the room that much. But that’s nitpicking.

I'm genuinely interested in the future development of this approach, and if you are like me, go and subscribe to his channel.

Every now and again, I think about SWAG. It was mid early 1990’s, and I was scouring the BBS’s of that time (did not have internet, 14.4 modem, dial-up, and a huge phone bill), just a kid looking for a new packet of SWAG.

SWAG (SourceWare Archival Group) was StackOverflow of that dialup age.

SWAG ended up as a collection of around 4000 pieces of PASCAL and Delphi code when it was discontinued in 1997.

It contained samples, example code for almost any problem you could imagine, tutorials on how to draw plasma, how to repaint buttons, how to do encryption, and so much more.

I can’t stress how powerful or meaningful that archive was. I remember when I did a network chat for a computer science competition in high school over mailslot and had to basically recreate my own protocol, my first stop was SWAG, and how to calculate CRC16.

While that code is mostly obsolete for long-dead systems, many of the algorithms are universal. Windows today are so closed off from underlying hardware that it’s a miracle anything can be done on them without the blessings of Redmond. When I think about that, I guess that’s why the refurbished new Windows 95 era computers for industrial use are a thing. A $1.000 for an old new PC is just amazing business.

Windows back then could do amazing shit, they could interact with hardware directly, things like making your keyboard status lights (any keyboard), be it a VU meter or a status panel for your HDD read/writes, and so on. And it was so simple, a couple of Assembler code to write directly to the keyboard register, and that was it, it was magic.

DelphiDabbler Code Snippets Collection is a spiritual successor to that original project and is maintained by Peter Johnson. That collection contains some 700 example code snippets for Delphi. He also has a mirror of SWAG.

An online version you can browse right now is on the RetroArchive SWAG page.

For an even further stroll down memory lane, check out

and the original from The Presidents of the United States:

@cobratekku.gamesWe love the response we got to the demo for KIYO - Bunny Tyranny during #NextFest! Thank you to @beardedmuscletv for trying out our game and sharing it with your community!

Tiktok failed to load.

Enable 3rd party cookies or use another browser

And I was like, I know how that’s made, done a similar trick before. What you do is on start take a screenshot of the screen and then apply effects on that image. Not that hard to do, but yes, it’s effective.

- captures the current desktop image at launch

- opens a fullscreen borderless topmost window

- replays the captured desktop as a tile-based dissolve into black

- reveals a centered welcome message near the end of the effect

- exits when the user presses “esc”

Code for this effect can be found on BarnLabs GitHub.

Once the situation is resolved, he gently refuses offers to stay as a pet and continues his lonely journey to the next adventure.

Then there was Captain Power and the Soldiers of the Future. I remember spending hours upon hours with my friends discussing how those armours could become reality. We were just getting introduced to chemistry and thought electroplating was probably the best solution, but slow (dumb, I know, but we were kids)

In the year 2147, after the Metal Wars, evil machines rule the Earth. Led by the tyrannical Lord Dread, the robotic Bio-Dreads hunt down surviving humans and “digitize” them. Captain Jonathan Power and the Soldiers of the Future use high-tech Power Suits that transform them into armored super soldiers. They wage a guerrilla war against the machine empire from their hidden base, hoping to restore humanity’s freedom.

Automan was a weird show, but it had graphics that I never knew were possible at that time. It’s a basic procedural crime fighting show, but I was mesmerized. A police computer expert creates Automan, a powerful holographic superhero who can materialize in the real world at night.

Together with a small floating helper called Cursor, Automan fights crime in flashy, high-tech style. He can shape-shift, create objects out of thin air (including the iconic glowing supercar), and pull off impossible stunts while pretending to be a government agent.

And finally, a slow, true 80s teen scifi show about a girl from the future that gets sent back in time. What I remember to this day is that her ship had the ability to producee clean water and that the criminal in the show was pumping toilet water to his future society for profit as they had none.

A freaking notepad app takes almost 50mb in memory when equivalent NOTEPAD done in pure Win32 C takes 1.8mb of memory. It doesn’t look like 50mb is that much in today’s world, but that’s the point, mb by mb it all adds up. I recently got a brand new Intel Ultra 9 285 with 32 GB of RAM, and it’s freaking memory is 77% full when freaking Windows 11 starts up.

Programming with Win32 API is a lost art now, and I look longingly at how Windows apps were once programmed. It was messy, but it gave you complete control.

Most modern UI programming tries to hide the operating system from you. You are stuck with a rectangular box while there was a period in the Windows XP era when it was cool to have non standard application window, even Windows Media Player had it.

Not everything had to be a bland, rounded rectangle with a sidebar, a settings cog, and a web stack squatting underneath it. There was a period when Windows apps were allowed to look strange. Media players looked like hardware. Desktop mascots walked around your screen. Utility panels looked like dashboards, toys, radios, or little alien control consoles. A window did not have to be a rectangle just because the operating system started you with one.

The point was usually not usability. It was identity.

That is the part modern desktop UI mostly lost. Not because Windows cannot do it anymore, but because most people no longer program at the level where the window itself is something they control.

The GitHub repository of this post is a small reminder that Win32 still lets you do exactly that. One example makes a window elliptical. Another shapes it from a bitmap. The third turns the whole thing into an animated desktop mascot. None of it requires a giant framework. It just requires dealing with Windows directly.

The first thing that confuses people if they come from games, browsers, or modern UI frameworks is that Win32 does not revolve around an update loop you own. It revolves around messages. Your app sits there, and Windows keeps handing it events:

while (GetMessage(&msg, NULL, 0, 0) > 0) {

TranslateMessage(&msg);

DispatchMessage(&msg);

}

That loop is the contract. Windows says something happened, and your window procedure decides what that means. “WM_CREATE” means the window is being created. “WM_PAINT” means it needs to be redrawn. “WM_SIZE” means its client area changed. “WM_DESTROY” means it is done. That is the real shape of Win32 programming: you build behavior one message at a time.

And once you understand that, weird-shaped windows stop feeling mysterious.

A normal top-level window is rectangular, but Windows also has the idea of a region object, an “HRGN”. If you assign a region to a window with “SetWindowRgn”, only that part counts as the actual window. The rest disappears, both visually and interactively. That is the trick.

The simplest version is the one in “basic/main.c”. It creates a borderless window and then does this:

region = CreateEllipticRgn(0, 0, rc.right, rc.bottom);

SetWindowRgn(hwnd, region, TRUE);

That is enough to turn the window into an oval. Not a fake oval painted inside a rectangular frame, but an actual oval HWND. The sample also handles the practical bit people forget: once you remove the title bar, the system is no longer going to drag the window for you. So on “WM_LBUTTONDOWN”, it fakes a title-bar drag by sending “WM_NCLBUTTONDOWN” with “HTCAPTION”.

That little detail is the whole story of custom windows in miniature. Making the shape is easy. Replacing what the normal frame used to do for free is the real work.

The next sample is where it gets more interesting. Instead of defining the shape mathematically, “drivenbyimage/main.c” derives it from bitmap data. It loads “shape.bmp”, reads the pixels with “GetDIBits”, then scans the image row by row. Every horizontal run of non-transparent pixels becomes a tiny rectangle region, and those runs are combined into one final window region.

#define TRANSPARENT_COLOR RGB(255, 0, 255)

Magenta means empty space. Everything else becomes part of the window.

That means the bitmap is doing two jobs at once. First, it is the thing you paint in “WM_PAINT”. Second, it is the shape of the actual window. That is how a lot of old skinned apps worked. You were not limited to circles, rounded corners, or neat vector geometry. If the image looked like a dog, a spaceship, a stereo, or a cartoon face, the window could be that shape too.

This is the part that made old desktop software fun. The window frame stopped being a law of nature and became just another asset.

But bitmap-driven regions still have a hard edge. A pixel is either in or out. That is perfect for silhouettes and cutout UI, but if you want soft edges, translucent pixels, or animation, you need to move to layered windows.

That is what the “Animated/” example does. I found a nice sprite sheet of an animated 8bit dog on itch from the artist inmenus, who gave that art to Creative Commons. So thank you for that.

Instead of carving the window out of a region, the example creates a “WS_EX_LAYERED” popup and uploads a 32-bit alpha image into it with “UpdateLayeredWindow”. The sample uses a sprite sheet, advances frames on a timer, draws into a memory bitmap with GDI+, and then pushes the result to the desktop. At that point, you are not really saying “my window is an ellipse” or “my window matches this mask.” You are saying “my window is whatever these pixels are right now.”

An animated mascot works better as a layered window because you get per-pixel alpha, cleaner edges, proper transparency, and freedom to change the visible shape every frame.

But there is an issue with Win32 API programming. And the truth is that custom windows mean doing everything yourself, controlling every Windows message, and that is fragile.

The awkward part begins the moment you decide to throw away the normal frame. Then you own dragging, resizing, close behavior, hit testing, keyboard handling, repaint correctness, DPI handling, and every annoying little edge case the default window had already solved decades ago. That is why weird shaped windows are easy to prototype and expensive to polish.

Users do not usually reward that effort unless the result is genuinely exceptional.

Desktop UI culture shifted from “look at this crazy skin” to “work reliably and get out of my way.” Weird windows became associated with gimmicks, adware, toolbars, and bloated utilities more often than with serious software. Which is a shame.

Still, I like that this stuff exists. It reminds you that Windows was once a platform where software could have a physical presence, not just a page layout inside a disguised browser tab. Most of the time, a normal rectangular window is the right answer. But it is good to remember that it is a choice, not a law.

The nice thing about Win32 is that it does not try to talk you out of any of this. It just gives you the messages, the handles, the drawing APIs, and enough rope to build something interesting.

Code can be found in the GitHub repository of this post.

This is not the first time this has been made. Well, it is, but there was a similar approach to music in the early 80s called MOD. Born in the late 1980s on the Commodore Amiga, it was itself a hacker’s answer to limited hardware. You had a few sound channels, a set of samples stored in memory, and a vertical grid where time advanced in rows much like an Excel sheet of music. Each cell told the machine what to play, how to play it, and when to stop.
Something like:

C-3 01 20
--- -- --
E-3 02 A0

Notes, instrument numbers, and effects. Every column, every row was tightly packed data telling the sound chip what to do. It was deterministic, constrained, and brutally efficient. Every byte counted. Every row meant something. The composer was half musician, half assembler programmer. A MOD file wasn’t just a song; it was an instruction sheet for sound, and I loved it. To this day, I love 8bit music.

I remember hours spent listening to MOD music using FastTracker II. There’s a whole post about that legendary player.

Enough about MOD and old school music formats. Let’s look at Strudel.

Strudel, at its core, is the JavaScript reincarnation of TidalCycles. It runs entirely in your browser with no installation, no compilation, no setup headaches, unlike TidalCycles. You open a tab, write a few lines of code, and sound emerges. Its design feels lightweight but conceptually dense. You’re not writing imperative code that “plays” a note; you’re defining patterns, rules, and transformations that unfold over time. Time itself becomes a variable, a playground. Its syntax can be cryptic at first, like any new programming language, but as soon as you “get it,” it becomes second nature to use.

Now, there are issues. Browsers are imprecise timekeepers; JavaScript timers jitter, and latency can vary across devices. Also, you get synths built from oscillators, samples, filters, and the creative limits of JavaScript’s Web Audio API. It sounds good, but could be better.

Sonic Pi, on the other hand, descends from a different lineage. Originally conceived as an educational project for the Raspberry Pi, it grew into a fully fledged live performance environment.

Sonic Pi is a desktop app. It connects directly to SuperCollider, a veteran sound synthesis engine that powers serious digital instruments. That link gives Sonic Pi a richness Strudel can’t yet match: complex synthesizers, modulated effects, MIDI integration, network sync, and rock-solid scheduling. Its loops are threaded through a scheduler that guarantees temporal precision, even while you rewrite them on the fly. It’s less ephemeral than Strudel, more grounded, more mature.

Strudel treats time as a pattern to be reshaped, where everything is data, everything is transformable. Sonic Pi treats time as flow or something to be looped, synchronized, stretched, but always flowing forward.

They’re not rivals. They’re parallel evolutions in the same ecosystem. Strudel for immediacy, Sonic Pi for depth. Together, they remind us that code is not just logic. When we type, we don’t just command a machine, we compose, we improvise, we listen. Strudel and Sonic Pi are proof that sometimes, the most elegant code doesn’t just print “Hello, world.”

There is a collection of Strudel songs on GitHub for you to tryout and enjoy. And if you would like to save any music to your local drive, use warm.strudel.cc, which has an export function. But I found that it has a tendency to crash if you are exporting long songs. There is a Python script on BarnLab’s GitHub that can do that.