Ok, here you go, the before and after of what the user sees when they install Nexus on Windows 11 dark mode. It's definitely not a night and day difference, but I believe (hope?) there is enough of an improvement...

It's my pleasure Jorge. You'll always know where you are with me - no sugar-coating, no fluff, just my honest thoughts.

Never seen that fish before, but then I banned that waste of space almost yonks ago. (Always hated the very idea - daftest thing ever created in Linux.) As for the moon phases, short of an actual sequence of high definition photographs they can't really be improved, they're as near perfect as can be. Pity I don't have the time at the moment, otherwise I'd make and send you alt calendar and digital clock icons matching in style - but basically, I'd suggest the plain background (or perhaps mildly graduated) with plain white font for both. Battery again doesn't really need changing I think, although personally I just use a plain bar graph type affair..

The UWP icons really look like something out of some kid's game or some such - ugly as hell. Of course, don't see any of that here as I got rid of all the UWP stuff years ago (plus Edge, and more recently also Copilot and Copilot+ Recall). I've seen Win 11 icons in screenshots, not really much better than the UWP ones. On the whole I must say I'm much happier with the icons in Ubuntu and Fedora than anything in the Windows world, although even those are far from perfect.

Indeed. I've almost always used a bar here for the RAM one.


Agreed, but then few icons look terribly good at large sizes unless very carefully designed, and then there's always a risk of them not working very well at smaller sizes. One more point in favour of the old NS icon as compared to the new ones - it better matches with the Winstep one

Rome certainly wasn't built in a day, but bear in mind the flip side - it was (more or less) destroyed in not a lot more than one!

Yes, I can appreciate that of course.

No clearing up needed here. Alas, I guessed you'd been seduced by the evils of ML/LLMs. That - pardon my French - shit will completely destroy any privacy yet if we're not very, very careful and vigilant.

N.B. - 500+ guests again!

Overall, I have to agree - should appeal to the punters.

Battery module has also been updated to the "flatter" Windows 11 style. I actually do not dislike this new version.




This is like revamping the look of the whole application a bit, but without actually getting rid of the old style icons/modules so users who prefer those are still pleased. What you cannot do is mix and match on an individual base, of course.

I have to agree, not bad at all compared to the old one!

Things have not been easy here in the past couple of days.

First I had to deal with a bot infestation on the forums (probably some kind of AI aggregator cloud) that bought the MySQL service and the server's Xeon processor to its knees (in practice a DOS attack on the forums, although I am pretty sure that was not the intention).

Unlike previous "attacks" there was no common point of origin or user agent string that could be used to distinguish the bots from real users or block them at the firewall or web.config level.

Ended up having to up the number of allowed SQL connections and to tight the limits on concurrent connections and server requests per second (went overboard and for a while there some users were missing some images on pages with lots of illustrations).

Not sure if it was this or if the bots simply finished what they came here to do, but suddenly all of them vanished into thin air. At one point there were over 10,000 bots scavenging the forums at the same time.

So, with so much still to do for the v25.7 release, I am forced to waste my time on this.

And then came the emails from a couple of Korean users, saying drag & drop wasn't working at all despite the system locale (codepage for non-Unicode applications) matching the Windows language). Decided to look into this and suddenly I understood how Alice felt when she went down the rabbit hole.

Winstep applications are ANSI applications, in that they do not support Unicode directly. So, to work properly with different languages, the system locale and the system language must match. The applications are developed in such a way that provided this is true they will work properly with Unicode strings.

But here is the catch: Korean characters, like those in many East Asian languages, may require two bytes instead of one for some characters (while others use only 1 byte). And this is where the problems truly start, the issue is not in the conversion of Unicode to ANSI, but on how the ANSI + DBCS is handled by the development environment internally.

Languages like Portuguese (Windows-1252) and Russian (Windows-1251) do not suffer from this problem because they use single byte encoding.

At first I did not understand how deep the rabbit hole went, so I ended up installing Korean in a Windows 10 VM I have here to try and understand what was actually happening - and I nearly fell off my chair at the amount of stuff that simply would not work right on systems with Double-byte character sets (DBCS). Couple that with trying to navigate a Korean Windows system when you don't understand a single word of Korean.

So, I think I might be able to solve the drag & drop issue in systems with languages like Korean - which is the major problem - but I don't think I will have time to fix all the issues.

Well, at least the drag & drop issue has been fixed for Korean systems (and systems like it).

Kudos Jorge - no mean feat that!

Tried to come here late afternoon - "The service is not available". Buggers got back in after all then. Real major PITA. And yeah, you can bet your last Euro that it's all "AI"-related. ML/LLMs are being trained to create all manor of programming already, alas with quite a lot of success. And of course for breaking cryptography. Just what governments - especially the one across the big pond that's striving to become 'Gilead'! - really would love to have at their disposal.

And looks like I fixed the rest of the issues too (resolving shortcuts with Korean characters, etc)...

In the mean time, the bots came back. Had to disable the board for a while.

Well done re: the issues resolving shortcuts with Korean characters etc.

Those bots look like they're going to keep on coming, the barstewards. There's got to be a way of locking them out permanently, but what?

Proton now have a ML/LLM chatbot - Lomo. There is a free version. It's completely private, no logging, no nothing. You might want to give it a go. You never know, it could even turn out to be useful re: the bots...

Yesterday I wasted even more time looking at this... The problem is not so much the bots as much as how old this board is, and how non-optimized it is. The bots aren't making enough requests to trigger the server's protection, it's just that there are so many of them and the structure of this board is so old that MySQL gets bogged down with table locks due to session delete requests.

Anyway, I don't have time to deal with this now, I will deal with it once v21.7 is out the door. In the mean time it looks like they will be coming back everyday at the same time.

And talking about getting bogged down, yesterday I got bogged down so much I nearly cried with despair lol

There was still one little thing that wasn't working properly in the Korean system, and it had to do with the creation and decoding of shortcut (.lnk) files. It worked fine for all shortcuts with Western names and even some with Korean characters, but there were still some shortcuts that could not be resolved. This was not a huge problem, but still bothered me...

So I went on a rabbit hunt and ended up falling down a rabbit hole. Winstep applications are ANSI, not Unicode (and I'm 20 years too late to change that lol) so to work properly with non-Western languages the system locale and the Windows UI language must match. As long as that is true the Winstep application is able to juggle text strings and filenames between the ANSI and Unicode worlds, and it works fine even with non-Western languages like Russian, etc...

The problem was not on the Unicode side, however, the problem was actually on the ANSI side and the fact that some non-Western languages like Korean have so many different characters that they do not all fit in the normal 1 byte (0-255) ANSI range, which is where double-byte character sets (DBCS) come in. Some ASCII codes are reserved as "lead" bytes, markers that the next character is actually composed of two bytes and not just one.

However, at the same time and to the programming language a single character is still a single character, no matter how many bytes it is represented by internally. The problem is that how this character is decoded will thus depend on the preceding byte - one wrong step and you get gibberish.

And it is because of this that the conversion to and from Unicode was sometimes failing on the Korean system, actually on the ANSI side of things when converting to Unicode using methods that worked fine if the language only used 1 byte per character (like Russian, for instance) but failed when using ANSI DBCS like Korean.

In this case it was better if instead of doing a ANSI to Unicode conversion I simply passed a pointer to the string/filename directly (despite the application itself being ANSI, the development environment actually uses Unicode behind the scenes, go figure! lol) but the TLB (Type Library that provides Windows API definitions) I was using for accessing certain OLE interfaces in the Windows API did not allow this.

And it was when replacing this TLB with another that did allow passing strings by pointer (which magically fixed the remaining problem in Korean Windows) that I fell down the rabbit hole, kicking and screaming.

Every TLB has a different way of passing arguments even to the same functions/interfaces, depending on a lot of factors including author style. They also may expose more (or less) details to different interfaces. So when I replaced one TLB with another, some of the API calls spread throughout the code that used the methods defined in the old TLB failed all at once.

To get things working again I had to painstakingly change how each of this function calls was written so it complied with the new TLB. Another nightmare was the types, one TLB used GUIDS and another UUIDs (which refer exactly to the very same thing, only the name is different - I know that and you now know that too, but the compiler did not, so I also had to change every GUID reference in the code to a UUID).

By this time I was making so many changes to the code that I was truly afraid I would break the whole thing and never be able to compile the project again.

The straw that broke the camels back was the fact that the old TLB also dealt with context menus (IContextMenu and IContextMenu2) and despite the new TLB also doing this, it did so in a different manner and exposed less methods and results than the old one did.

This caused so many problems in getting the contents of right click context menus to file system objects (would potentially create leaks too - or worse - because the new TLB did not expose the Release method) that in despair and despite being the first time I ever did something similar, with the help of ChatGPT I ended up writing my own TLB to the IContextMenu interfaces, exposing the required methods and properties. And it worked!

So suddenly I had a fully working - and compiling - application again (knock on wood) and now apparently 100% ready to tackle new markets like Korea, Japan, etc.. (which until now I did not know were having so much trouble with the application).

So, despite the many hours of darkness not seeing the light at the end of the tunnel (I worked non-stop and always 100% "in the zone" from something like 8AM to 6PM) in the end - and bar some newly introduced incompatibility I still haven't noticed - I think it was well worth it.

And my reward for all this? As soon as I finished, having the board invaded (AGAIN!) by AI intelligence gathering bots! Sigh.

Ah, forgot to mention one thing, also added a check for UI language and system locale compatibility at application startup.

If both match, the user will see nothing, but if there is a mismatch (or UTF-8 Beta is enabled) you will get a warning and a suggestion on how to fix the problem (here I am obviously forcing the application to show these dialogs, there is no issue if the code pages match and the UI language is English). If you agree the application will open the Windows Region dialog for you and tell you what to do to fix the problem (which requires a system restart or a user signout, so the application exits after this).

You can also click "Don't Ask Again" and you won't be bothered by the warning again.

Quick Beta of Winstep Xtreme v25.7 and Nexus Ultimate v25.7 is out now.

If you wish to try them out open Preferences, go to the Advanced tab, enable "Notify me of Beta (test) versions" and click the Check for Updates button.

Please post any issues you find ASAP.

Sorry, won't be able to get into Windows till Wednesday earliest. All tied up on the 'new' i5 laptop in Ubuntu, fighting to edit the Grub (Linux bootloader/boot manager) configuration which has gone awry thanks to a misbehaving Linux installation. (Got 5 Linux distros on that system, Ubuntu vanilla, 2 Ubuntu flavours, vanilla Fedora + 1 spin or flavour.)

That's quite some rabbit hole you fell into Jorge! What a PITA. But kudos for getting it sorted.

And speaking of PITA - the problem of the bots and the age of the board etc. Yep, that makes perfect sense. Plus of course a further factor is having a Windows server - with a Linux one it would have been highly unlikely the bots could get through to the board in the first place.

Doubt that. First you cannot distinguish the bots from normal users, unlike in the first wave of attack their IPs are from all over the world and their user agent strings randomized. So there is nothing to ban at the firewall level.

Second, I already rate limited the server and that didn't solve the problem, so you can't identify them by how fast they make requests either. The people behind these bots are not stupid.

But then again neither am I.

So what I did today when they came back was to actually limit the number of concurrent guests on the board to 100. If more than 100 guests are on the board, new guests are not allowed to create a new session (which is what was maxing out the MySQL server even when/if the board was disabled).

In case the guest is actually a real user, a message is also displayed that the board is currently not accepting guests due to security reasons and to please come back later.

Doing it this way has several advantages: first the CPU does not get pegged at 100% nor anywhere near due to MySQL getting bogged dow.

Second the board remains available and fully functional, if it slows down it is not even noticeable.

Third, new legit guest users cannot access that board until the bot cloud decides to leave, true, but logged in users (those who have the "Log me on automatically" setting enabled) should still be able to access the board (I still have to test this though, as I already had an active session when the bot cloud joined in today). Any guests that were already browsing the board BEFORE the bot cloud joined in, also continue to have access.

Finally, once the bots go away (and so far their pattern seems to be to attack the board at around 4-5 PM GMT and leave a few hours later) guest access is automatically restored without the need for manual intervention.

Doesn't fully solve the problem but it sure mitigates it.