DEV Community: Visnalize

Ranking Microsoft Windows versions - 2025 Edition

Khang — Sun, 20 Jul 2025 04:03:58 +0000

Everyone has their own preferences and opinions on which Windows version is the best, so in this fun little post, I'm going to rank the Windows versions from best to worst in my opinion.

As biased as this sounds, this list is actually backed by facts, statistics, and market share trends (source).

🏆 Windows 7 - the GOAT, no debate

Windows 7, without a doubt, is the best Windows version to this day. It was fast, stable, and had the best user interface. The perfect balance between performance and aesthetics. It took everything people hated about Vista and... didn't do it. Whether you were gaming, working, or just customizing the hell out of your desktop, Windows 7 made you feel like your PC got you. Even after Microsoft ended support, many users clung to it for years, including enterprises, businesses, and individuals.

If you disagree, you're against a civilization!

🥈 Windows XP - that startup sound chefs kiss

Blue skies, green hills, and a startup sound etched into memory. Windows XP was ridiculously lightweight, reliable, and compatible with almost everything. It was the first Windows version to really nail the user experience. It became the backbone of businesses, schools, and homes for years. Paint, Pinball, Clippy, Windows Media Player with custom skins. Enough said. It was the golden age of Windows.

🥉 Windows 10 - when Microsoft finally listened

Okay, this one is not on a nostalgia trip, but Windows 10 is a solid operating system. After the mess that was 8 and the "meh" 8.1, this was the comeback we needed. It brought back the Start Menu, improved performance, and finally had users agreeing on something. It was a step in the right direction, even if it had its fair share of bugs and issues.

4️⃣ Windows 98 - if you know, you know

Yet another classic. Windows 98 was the Windows for anyone growing up in the late 90s. It introduced several features which would become standard in future versions. The aesthetics it inherited from Windows 95 remained iconic. Remember Half-Life, Rollercoaster Tycoon, or Quake? Those games were the reason many of us fell in love with gaming and computers.

5️⃣ Windows 11 - trying hard to be cool

The latest version of Windows at this point in time. Windows 11 is a mixed bag. It has a sleek design, but it feels like Microsoft is trying too hard to be trendy. The new Start Menu and taskbar are... different. Some people love it, some hate it. It's fast (kinda, if you have the right hardware), but it feels like a glorified Windows 10 update. The new features are nice, but it doesn't feel like a major leap forward. It's like that friend who tries to be cool but ends up being cringy.

Honorable mentions and conclusion

🎀 Windows Vista: beautiful but slow and buggy, still a solid attempt that paved the way for Windows 7.

🎀 Windows 8.1: a decent attempt to fix the mess of Windows 8, but just not enough.

In conclusion, Microsoft has had its ups and downs with Windows versions. Some were revolutionary, while others were just... there.

But one thing is for sure: if you want to experience the best of Windows 7 and every other Windows version mentioned above, you can always check out Win7 Simu. It's the closest thing to reliving the glory days of Windows 7 without the hassle of installing it on your machine, or messing around with virtual machines and technical stuff. Just pure nostalgia and fun.

I built a Nokia Composer with AI's assistance

Khang — Mon, 10 Mar 2025 04:17:53 +0000

I have recently released a new update to Brick 1100 a few days ago, this update includes the new Composer feature allowing users to make their own ringtones in a monophonic style. It's a feature that I never thought I would be able to implement on my own, having no prior knowledge of music theory and even never having used the Nokia Composer before. However, with the help of AI, I was able to build it, in a considerably short amount of time. In this post, I would like to share the process of building the Nokia Composer and how AI has evolved remarkably to make it possible.

What is Nokia Composer?

Composer was a built-in feature on several classic Nokia phones, allowing users to create their own monophonic ringtones. It provided a simple interface where users could manually enter musical notes, defining their pitch and duration. This feature was a popular way for users to personalize their phones in the pre-polyphonic and MP3 ringtone era, enabling them to compose famous tunes, TV theme songs, or even their own musical creations.

How it works

The interface allow users to input notes using the phone's keypad. Each key corresponds to a different musical note, and additional options let users adjust the octave and duration of each note. Once a melody is created, it can be saved and set as the ringtone.

A typical composing process included:

Opening the Composer – Accessible through the phone's menu, a blank canvas would appear for users to start composing.
Composing the tune – Users could input notes using the phone's keypad:
- Numeric keys 1-7 are used to assign musical notes
- Keys 8 and 9 change the note's duration
- Key 0 adds a rest
- Key * shifts the note's octave
- Key # makes the note sharp
Editing the tune – The melody could be played back, and individual notes could be modified or deleted as needed.
Saving and setting as ringtone – Once satisfied, users could save their custom melody and assign it as the default ring

Deep dive

All possible combinations of a note's structure

Nokia Composer follows a structured approach to note input, using a simplified notation system. Below is a breakdown of the key components involved in composing a melody:

Musical notes: Each numeric key, 1-7, is assigned a specific note:
- 1 = C (Do)
- 2 = D (Re)
- 3 = E (Mi)
- 4 = F (Fa)
- 5 = G (Sol)
- 6 = A (La)
- 7 = B (Ti)
Duration: Keys 8 and 9 adjust the note's length. The default duration is a quarter note (1/4 length of a whole note), which is represented by number 4. Pressing 8 halves the duration, while 9 doubles it. The corresponding values are:
- 1 = whole note
- 2 = half note
- 4 = quarter note
- 8 = eighth note
- 16 = sixteenth note

Dotting a note increases its duration by half. For example, a dotted quarter note is 3/8 (1/4 + 1/8) of a whole note.

Octave: The * key is used to shift a note's octave, typically covering 3 octaves.
Rests: The 0 key is used to insert a rest (pause between notes). Duration keys can also apply to rests, adjusting their length accordingly.
Sharp notes: The # key is used to make a note sharp, raising its pitch by a semitone, not applicable to the E and B notes.
Tempo: The beats per minute (BPM) value to control the speed of the melody.

Example

Let's take 4c2 as an example, this represents a quarter note C in the second octave, which is also the default note for the Composer. By common convention, a quarter note equals to 1 beat, hence if we set the tempo to 120 BPM, the duration of this note would be 0.5 seconds (60 / 120 = 0.5s). In the same manner, we can interpret other note combinations:

8c2 = eighth note C in the second octave with a duration of 0.25s (half a beat)
2c2 = half note C in the second octave with a duration of 1s (2 beats)
4.c2 = dotted quarter note C in the second octave with a duration of 0.75s (1 and a half beats)
4#c2 = quarter note C# in the second octave with a duration of 0.5s
16.#d1 = sixteenth note D# in the first octave with a duration of 0.125s (1/4 beat)

How I built it

I hope the above explanation gives you a good understanding of how the Nokia Composer works, because that's something I didn't know prior to building it. I had never used the Composer feature on a Nokia phone either, so I wasn't sure if I would ever get to implement it in Brick 1100. However, the project wouldn't fulfill its purpose as a Nokia 1100 simulator without this iconic feature, and become a let down for users who were expecting it. I decided to give it a shot, and with the help of AI, anything now seems possible.

With AI's assistance

In summary, I used Cursor (an AI code editor) with the Claude 3.5 Sonnet model to build, the entire process took me 11 prompts, around 3 days to make the Composer fully functional and integrated with the project's codebase.

It's amazing to see how AI has evolved in such a short time, enabling developers like me to build complex features without prior knowledge or experience in a certain field. I remember just months ago, AI tools like ChatGPT or GitHub Copilot are just making dumb, made-up suggestions when it comes to coding, but now they can actually provide helpful assistance. This is even more impressive with Cursor + Claude's model, which could generate for me a fully functional Composer in the very first prompt. Though to be fair, quite a few iterations were needed to refine the code, especially in handling the core logic of the Composer and integrating it with the existing codebase, but the AI's suggested code was an excellent starting point. It's not an exaggeration to say that, as a software developer, I should be worried about my job security due to the rapid growth of AI, but as an indie maker, it makes me feel like I have a superpower to build anything I want.

Without much instruction, solely from my first simple prompt, the AI agent was able to gather the necessary information of how the Nokia Composer works by searching the web, it then scanned the existing codebase to understand the structure, inspected the relevant parts for the conventions, and reused for generating the code. The result was great, the Composer was functional, but it was nowhere near perfect. There were still flaws, bugs, and inefficiencies that needed to be taken care of. It couldn't understand the way the keypad input was handled (so it improvised, but completely off the mark), the composer interface didn't fit in the overall layout, and the notes' pitch and duration were not accurate. In general, if I were to give the generated code a score, it would get a 6/10, but the most crucial and hardest part was done, so I was pretty happy with it.

Iterations and refinements

From reviewing the generated code, I knew where the problems lied, but I had no idea how to fix them at that point. Luckily, I found this version of Composer built by Serge Zaitsev, which has a rather simple and clean implementation to follow. I used this as a reference source to feed the AI agent, asking it to explain the code to me and refactor it to be more readable and follow the project's coding style.

The generated code this time addressed most of the issues related the core logic of the Composer, once again, AI has been proven to be a wonderful tool for learning and adapting as it evolves. After some manual clean-up and adjustments, the Composer was finally in a good shape, the most crucial part of the Composer's logic was then encapsulated within the below function:

/**
 * @param {Note[]} sequence The sequence of notes to play
 * @param {MediaStreamAudioDestinationNode} [destination] The stream destination to record audio
 */
function playSequence(sequence, destination) {
  const oscillator = this.audioContext.createOscillator();
  const gainNode = this.audioContext.createGain();

  oscillator.connect(gainNode).connect(this.audioContext.destination);
  oscillator.type = "square";
  oscillator.start();
  if (destination) gainNode.connect(destination);

  let currentTime = this.audioContext.currentTime;

  const setAudioParam = (param, value) => param.setValueAtTime(value, currentTime);
  const clamp = (value, min, max) => Math.max(min, Math.min(max, value));

  sequence.forEach(({ note, duration, octave, isSharp, hasDot }) => {
    const noteChar = note.charCodeAt(); // ASCII value of note
    const noteStep = ((noteChar & 7) * 1.6 + 8) % 12; // map note to the 12-tone scale
    const octaveOffset = 12 * clamp(octave || 1, 1, 3);
    const noteIndex = Math.floor(noteStep + (isSharp ? 1 : 0) + octaveOffset);
    const isRest = noteChar & 8;
    const adjustedVolume = this.volume / 10; // adjust volume based on keypad volume

    setAudioParam(oscillator.frequency, 261.63 * 2 ** (noteIndex / 12)); // convert to frequency (Hz)
    setAudioParam(gainNode.gain, isRest ? 0 : adjustedVolume);

    const noteDuration = (24 / this.tempoValue / clamp(duration || 4, 1, 64)) * (hasDot ? 1.5 : 1);

    currentTime += noteDuration * 7;
    setAudioParam(gainNode.gain, 0); // add a small pause between notes
    currentTime += noteDuration * 3;
  });

  return wait((currentTime - this.audioContext.currentTime) * 1000);
}

In simple words, the function above takes a sequence of notes and plays them back in the correct pitch, duration, and tempo. It uses the Web Audio API to generate the sound, and the function is called whenever a note is inputted or a melody composition is played. It also takes the destination stream as an optional parameter, allowing the composition to be recorded for exporting as a ringtone, an enhancement that wasn't available in the original Nokia Composer.

From this point, I just had to make some more manual tweaks to make the Composer's UI fit in the project's layout, and used a few more prompts to fix some unknown issues as they popped up when testing the feature on Android and iOS. As mentioned earlier, the total time spent on building it was around 3 days with 11 prompts, and we had a production-ready Nokia Composer in Brick 1100.

Conclusion

Building the Nokia Composer was a challenging yet rewarding experience, and it wouldn't have been possible without the help of AI. I wouldn't know where to start to get a sufficient knowledge of music theory, let alone implement a feature like this in a short amount of time. Regardless how you perceive AI, it's undeniable that it has revolutionized the way we build software, and it's only going to get better from here. I'm excited to see what other features I can build with AI's assistance, and I hope you are too.

If you haven't tried out the Composer feature in Brick 1100 yet, I encourage you to give it a go, and let me know what you think (there's also a Discord server to hang out, leave feedback, or share your creations, join us if you're interested).

Turning my codepen into an actual app - Brick 1100

Khang — Sat, 07 Oct 2023 05:26:48 +0000

Some time ago, in one of my very first posts on DEV, I shared a silly codepen made from learning for pure fun:

Khang

Dec 18 '20

Nokia 1100 Simulation

#codepen #html #javascript #css

173

Comments 10

1 min read

Turned out people found it interesting somehow as the post and the codepen itself was seen receiving a few interactions. Years later, after gaining more skills, and more experience, I came back to this idea to actually complete it. From a mere silly codepen that was barely functional, it has become a full-fledged app (though still in beta) and made its way to Google Play. In this article, I'm happy to share the progress, how and what I used to build it, and let's explore some cool and unique features I have brought out with this app.

A silly idea that got realized

We, developers, tend to look for project ideas where we can challenge ourselves and put our knowledge and skills into practice. Just like everyone else, when I first got myself into web dev, I had plentiful ideas of what I could build to learn coding more easily, enrich my portfolio with more useless projects, and dazzle the recruiters to land a fulfilling job. However, a little bit out of the ordinary person I am, I actually wanted to build something cool, something original that not many people had thought of and done, so I came up with the idea of replicating the look of an old phone (whoa, how innovative...) and simulate some of its functionalities (so original...). As a result, we have the "Nokia 1100 simulation" codepen above.

At that time, I stopped where I thought was sufficient for a silly idea as it was, even if I wanted to go further, my skills at that point wouldn't allow it, because I was still a NOOB! (though I still am). I just left it there and forgot about it. Sometime later, after having gained some experience working for companies and leveling up myself a bit, I revisited some past projects to see if I could advance any of them with my new abilities. The Nokia simulation was at the top of that list, considering how much traction it gained at the time (maybe not much for you, but that was a lot for a NOOB!). And here we are, a pet project that actually got finished and made it to the public.

The making process

The idea initiated in codepen was made with pure HTML/CSS/JS as I had just started learning the fundamentals. However, this time, applying the wealth of front-end development knowledge I have earned over the years, I rebuilt the project from scratch, making good use of modern web technologies and frameworks to speed up the development, and ease the feature addition and maintenance process as it grows.

I started spending my free time outside of work hours and weekends to get into it. After about two weeks, I finally made it an MVP (minimum viable product) with most of the core features covered, sort of. So far, the most prominent stuff that I used to build it:

Vue 2.7 - the main framework that empowers its UI.
Pinia - the state management library to handle shared state across components.
Vue Router - the routing library to ease the navigation within the app.
Capacitor - the MVP that helps transition a traditional web app into a mobile app effortlessly.
And lastly, the most incredible database for managing user data - localStorage 😂

There are a few other packages and libraries that enhance the developer experience and contribute to the feature feasibility, e.g several Capacitor plugins wiring up certain native mobile features for the app, dayjs providing out-of-the-box utils to work with date and time, or voca for handy string utils without the needs of reinventing the wheel.

Breaking down the components

At a high level, the app is composed of the following major building blocks:

The container, which is just a freaking image, is layered below the other components. It also holds the responsibility of resizing the app to adapt to the device/browser window's size.
The screen plays a vital role in rendering what would be otherwise visible to the users.
The keypad/numpad is in charge of the interactivity of the whole app. The pattern here is that with the help of Pinia, the keypad/numpad would emit respective global events as the users interact with it and the other components then behave accordingly. It is easily the toughest part that I had to deal with as meticulously as possible, to capture the essence of a nostalgic feeling back when we all still used these pads to operate a phone.

Here's an outlook on how the above design is implemented for your reference:

<template>
  <phone-container>
    <phone-screen :state="state">
      <menu-screen title="Menu" :index="index">
        <menu-select
          class="main"
          :items="items"
          :current="index"
          @[Event.Back]="handleMenuBack"
          @[Event.Select]="handleMenuSelect"
          @[Event.Change]="handleMenuChange"
        />
      </menu-screen>
    </phone-screen>
    <phone-keypad />
    <phone-numpad />
  </phone-container>
</template>

A simplified snippet of the keypad/numpad implementation:

// PhoneKeypad.vue

export default {
  data() {
    return {
      startTime: null,
      timer: null,
      isHolding: false,
    };
  },
  computed: mapStores(useKeypadStore),
  methods: {
    clearTimer() {
      clearTimeout(this.timer);
      this.timer = null;
    },
    press(key) {
      if (this.timer) this.clearTimer();

      this.keypadStore.press(key);
      this.startTime = Date.now();
      this.timer = setTimeout(() => this.hold(key), HOLD_TOLERANCE);
    },
    release(key) {
      this.clearTimer();
      if (Date.now() - this.startTime < HOLD_TOLERANCE || this.isHolding) {
        this.keypadStore.release(key);
        this.isHolding = false;
      }
    },
    hold(key) {
      this.isHolding = true;
      this.keypadStore.hold(key);
    },
  },
};

// keypad.js

export const useKeypadStore = defineStore("keypad", {
  state: () => ({ key: null, event: "", _diff: 0 }),
  actions: {
    _set(event, key) {
      this.key = key;
      this.event = event;
      // workaround to observe the keypad interaction,
      // as the key before and after the interaction may be the same key.
      this._diff++;
    },
    press(value) {
      this._set(Gesture.Press, value);
    },
    release(value) {
      this._set(Gesture.Release, value);
    },
    hold(value) {
      this._set(Gesture.Hold, value);
    },
  },
});

Adding some twists

While the project originally aimed to replicate the phone experience faithfully, it also presented an opportunity to add unique twists that, to me, might turn out to be the selling points for the app to be more useful: a collection holder of mini-games/apps where newbie devs can also learn coding by submitting to this collection.

Due to the simplistic nature of the app and its design, I have a strong belief that it can be perceived as a code playground where people can get their ideas implemented in the rawest form, text-based apps, or apps with pixelated, monotonic graphics. Let's take a look at the simple model below:

Brick 1100 was built in a way that we could easily extend its functionalities with external games/apps. These external games/apps can communicate with Brick 1100 itself back and forth via an interface called Bridge 1100, you can read more about that in this Github repo.

It's nothing sort of any kind of innovation (as expected from a noob). Those external apps/games are just being gathered and pulled from this Github repo. By the time of this article, you can see from that repo, there are only 2 apps available:

Pwd Generator - a simple password generator from a length input.
Randomizer - a simple randomizer app that outputs a random result each time depending on the selected mode.

Both of them are super simple, plain text-based apps that can be completed in no time. However, they were developed using different web techs, with the first one using pure HTML/CSS/JS while the latter using the Mithril.js framework. This gives you the freedom of choice when it comes to the web tech that you want to learn by making and takes relatively little of your time and effort to complete an app idea.

How those apps show up in Brick 1100:

Final words

Despite how silly and ridiculously simple this project looks, I had a really great time building it and felt super proud to see a pet project that actually came to light and got installed on a few user devices. If it has somehow captured your interest and want to try it out, you can install it from Google Play. And feel free to join our Discord to have some little chit-chat, or if you want to build something on it but getting stuck somewhere, I'm happy to help out there.

And now, if you will excuse me I have an app to develop, and some users to satisfy. Thank you for reading ✌