paperovyy.site

---

"Air Alert" for Windows 3.1 and 9x

Published: 15 Jan. 2025

This post uses the date before this site was created.

  If you don't know what an "Air Alert" app is, check out my

projects

page.

  In short, this is an unofficial air alert tracking software for Ukraine's territories made as a standalone app, specifically and design-wise for old versions of Windows, starting with 95 & 98, 2000, XP, up to Vista, 7, 8 and 8.1. There is also no reason for it to not to work on the modern 10 and 11 as well.

  Windows 3.1 was a starting point of this project and up to this day, a year later, it hasn't been finished. On the other hand, the MS-DOS version which came to my mind as a joke - turned out to be the real deal and my first C experience.

  The earliest issue I had faced while trying to make the Windows 3.x version of my app, and later the 9x version struggled for the same reason (quick note: 9x version is the one that can run on anything from Windows 95 to 11, while 3.x and MS-DOS are own separate things with own code) was the decal transparency. I could put the map as a bitmap, as shown on the picture above, but the "alert" dots would have had a very obvious white background, which is fine enough until you look slightly lower where the Active Alert label resides at.

  I could leave it as is, but I wanted to recreate the map in its full shape. One of my ideas was to get an image of the current map state from the Internet straight into the app, it would mean I would only have to render one image per 15 seconds instead of 20-ish objects with possibly different sizes. Some Telegram bots do the same thing basically, but obviously using SVG and the modern code.

  That idea didn't happen because I was still figuring out how to make the app communicate with outer world - Delphi 1 had no Web suite to make HTTP requests, like newer versions did. I have made few silly and naive attempts to a) render bitmaps with a special transparency color that would be deleted upon rendering and b) try writing own, I think, TCP/IP stack solely for this app. Both miserably failed, but in my defense I must say that's how some other software worked like. If I recall correctly, I was inspired by a YouTube video called

"ChatGPT App on Windows 3.1"

and the author pretty much wrote his own code, including the HTTP request part. I'll leave a link of it when I find it.

  Then I decided to drop it and move onto a more modern Delphi version - 6, which couldn't make 16-bit apps sadly, but it had built-in tools to do HTTP requests natively. If you check the code for it now - it's the worst imaginable, but I promise that one day I will release the rewritten version which I had started making in the autumn of 2025 - it has some inner design ideas to figure out.

  But back to the issue #0, I've figured it back in 3.x variant. The answer is simple: Windows Icon format. Literally every Windows version supports it, excluding MS-DOS obviously. However, yes, the color capabilities have increased since the early implementations, but the basic 8-color palette was damn enough to fullfill my ideas. Next step was to start drawing regions, from the biggest to smallest using the same resolution for all icons - that is important because I couldn't scale it in the Delphi environment, so that's the only way to keep the same aspect ratio for every object on the map that I had.

  Final touch was to make it work. It was another dilemma, just like the transparency, but I've cheated this time. I used an unofficial API that was made public seemingly for the same hacky-modders just like I am, and yes - there were many projects based on the alert map, mine wasn't the first in that field, but it was very likely the one in the retro-computing. Long story short: I couldn't figure out how to parse JSON on Delphi, so I decided to cheat even more and make if-else hell with MANY abstract strings that ended up working. The same story happened on MS-DOS version, although there was a community-made "cJSON" library, but I couldn't make it work as well, so... Hello C, this is if-else hell again! In my defense, again, I wrote the CLI version for Linux in the same autumn of 25' from the scratch and since it uses the same C version, I can likely make it work on MS-DOS if I try hard enough.

  Now, before I end this post I'd like to remember features that were cut during the development.

  One of the earliest, as seen from the first picture at the top, were the Settings tab and the Fullscreen capabilities. The first one is quite self-explanatory, there were not much to change in terms of the app functionality so the user had to use a whole menu for it, it only had like Debug Mode switch and it would basically un-hide another tab to the right which had as many switches as many regions were on the map to just test their position on the map by hiding and unhiding them. It code was later completely removed from the source, alongside with some other redundant stuff.

  Fullscreen, on the other hand, was never implemented and it's actually the reason why MS-DOS version had appeared - I jokingly thought that the only wise idea to implement that is only using text mode. It would look basically like the DOS variant ended like - 80x25 black & white screen with a map made with box-drawing characters, just without the additional text UI like time&date, app name, etc (because it was made later when I actually started writing the code for it).

  Same struggle on DOS version, but it got resolved pretty quickly and even managed to run in on MS-DOS 3.10 (the video above). After hours of earching the Internet, I came along a modern TCP/IP stack for DOS called "mTCP" and it turned out very handy, especially the HTGET application (basically WGET for DOS) which functionality was desperately needed in the Windows 3.1 version of my app since I wasn't parsing the JSON anyways. The biggest downfall of it is that the app requires the user to have the mTCP config set in autoexec.bat, and I must say it is quite an important thing since it contains few IP-related settings including the network card's packet integer which is crucial for doing literally anything with that hardware.

  While mTCP is quite easy to install it is still an odd decision to tie onto it and since all of its source code is open, including the HTGET, maybe I could modify it and include it as a bundle without requiring the mTCP config and by having own or common NIC config... Unless it is prohibited by their licensing of course, I'm not aware yet.

  And again, many things were planned and while I was very surprised and happy that it turned out working, it was quite hard to maintain since I would write all the code on MS-DOS itself using the Borland C suite. One big idea was to make an installer for the app, just like for the 9x version, but it would look like an OS installer that was used 'till Windows Vista. It would also fix the abovesaid issue of requiring mTCP config - it would try to generate one if none was present, it shouldn't affect anything if you had no mTCP anyways and their apps would pretty much use that same config anyways and write own stuff when needed (like DHCP.EXE).

  Sadly, I couldn't finish it because around that time I applied to my first job and it kind of sucked all the juice and will to do many of my past-time projects. Fun fact: one day I did try to code on my work place, but I got quickly caught early on, so I haven't really tried to do it again. Stuff like the basic VGA 16-colors support, slight customization (which I quite disapprove today) and the mTCP rework got frozen for an indefinite period.

  My favorite and the most successful in terms of my ideas was the Windows 9x release. It was built using Delphi 6 using the original 3.1 layout which got massively reworked, and well basically it got the functional code, unlike the previous did. As you can see from the picture above, I even added a whole help file with my custom decals, an installer and a tiny cute readme with brief updates explanations.

  I don't think it ever worked reliably for any new week and while the disclaimers which were located in some spots do say it, I still tried to fix all the issues. 80% of it were my code flaws, since the if-else hell was still there, but that 20% was something I couldn't fix on my end or atleast with the unofficial public API that I had.

  Around that time the officials, which that API tried to recreate, would introduce an alert system update that would allow controlling sub-regions statuses instead of more generalized approach with regions only. It might be quite hard to explain in English, but if you have ever looked at Ukraine's or any similarly structured country then you might understand what I mean. That update was highlighted in the local news articles many times, so I am not mentioning something confidential. The issue was actually the fact that the unofficial API for a very long time hadn't introduced such update and I can explain what did that cause on a simple example: if one (1) sub-region out of three (3) in some region would become active, the region would still be displayed as inactive on such API. And while their endpoint would still display only the regions in their web responses, I wasn't able to do much with it, my idea was to light up a region if atleast one of its sub-regions would appear active.

  No, I am not blaming anyone - it is their creation and they do with it anything they want, ESPECIALLY when it's public and free, just writing it as it were at the time. As of now, they still use regions in their API pools, but my app should still work, however I never guarantee it will (2038 is coming).

  Finally, the end of this incredibly long post will be about today's and future plans

  As I've said I did rewrite quite some things at the end of the 2025, but they are currently private. Instead of using the unofficial API, I switched to the official one, but my main concern was to hide the API key in some way from the user. Instantly realized that it would be overwhelming (imagine tons of requests using the same key) and it would likely be easier to crack to my app than some API server. I know- I know that some API key that could likely be very easily be canceled and renewed wouldn't be a concern to a normal developer, but I did my best to make the app truly standalone and at end I couldn't. I chose another route - a) I would host a server that would check up with the official API, parse it and spit out the data to the "Air Alert" app how I want b) or letting the user, who are smart enough to maintain such an old OS and make it connect to the Internet, simply run my server app on their modern machine and act something like a proxy (inspired by the "Browservice" GitHub project).

  I'm not sure what would be the best way, besides giving a choice to users themselves, but I would likely host the first variant since it would be way easier for an average person to just open my app and it simply works without the need to selfhost anything. Moreover, the variant B means the user would need their own API keys to the official endpoint, while in the A my server can just distribute the same amount of data using one key for all the incoming traffic.

  As of January 2026, I am not in the best conditions to maintain any project, moreover to self- or pretty much -host anything elsewhere that might attract big traffic. The 9x version was pretty much rewritten and was actually finished except that server-side part, DOS needs some big rework (it still has if-else hell), Linux graphical CLI version can be used as a base for it - it has essentially the same text UI, but its C code overall was just written way more effient, made from the scratch too and I think it was finished too. Windows 3.x version was rewritten too, but it had some graphical issues with the regions and the map and I had to scrap it for a while, but I did come back to it around the same time as the others, but I have not figured out the networking part for it.

  Thanks for reading that huge article! While there is still stuff to write about, I'll pause it here. A new version update will likely be published in its own post one day, so stay tuned.

---