yoy.be Why-O-Why

Delphi 64-bits: set your local variables!

Sat, 14 Feb 2026 09:43:29 GMT

I'm relatively new to programming for the 64-bits platform, and I ran into the same thing twice now, so I feel I need to write about this. This last time, it even first showed up as an exception that occurred with the release build only, not the debug build! But it showed up consistently, so it was something I could investigate. I found out the specific exception only occurred with the 'Optimization' compiler switch enabled. Apparently 'modern' Delphi has the 'Optimization' switch set to off in default 'Debug' configurations, and on in default 'Release" configurations.

'Modern' Delphi apparently also has 'Use debug DCUs' on for both 'Debug' and 'Release', which I very much regret. Most especially because when I introduce newlings to the Delphi debugger, we invariably drop into a core .pas-file, either causing confusion, or the need for an explanation of what that is and why you'd better never make changes there. Or also what's the relation to the program you're building on one side, and the resulting compiled binary code on the other side. Any way breaking away from working with the debugger for the remainder of the lesson.

What I want to warn about is that apparently the 64-bit compiler no longer provides the internal scaffolding to clear the memory of the local variables in procedures and functions. It also doesn't warn that you're using an unintialized value (1). In my case I've seen bugs appear just by switching from 32-bits to 64-bits, so be careful to always have an assignment to local variables before using them. Even if it's integers to zero and booleans to false. (Strings on the other hand, because of them being a pointer-type by nature, are zeroed for you.)

(1) The compiler does warn about you not using a value set to a local variable. And there's also a difference there between 32-bits and 64-bits compiling there. If you have a superfluous assignment to set a default value at the beginning, and the following code also sets a value in all branches of ifs and cases, I've found that the 32-bits compiler warns less about the unused assignment than the 64-bits compiler does. Perhaps because it's silently de-duplicating the assignments it's doing behind the scenes anyway? It's a minor inconvenience, but one I can live with, and one that reminds me to check if all local values get an initial value by my code.

AllSorts 1.2.0.700

Tue, 20 May 2025 21:06:25 GMT

→ AllSorts (github release...)

Shell extension "AllSorts" had been switched back from Lazarus to Delphi Community Edition some time ago, but this also allows me to add something that I was thinking of for a while, but hadn't taken the time to get it done: an option to 'paste into' a new file any text content currently on the clipboard and have explorer switch to editing this new file, just like you get with the 'new...' content menu options.
And lo and behold: it's just one API call away! (Well, two actually, I need the path converted to an item-id-list first...) But it looks like it works (and it looks like it'll be one of those things I'll need a few times a day, just like the "Copy UNC" option!)

Gek ideetje: ilasm.exe

Wed, 24 Nov 2021 19:38:24 GMT

Hier is een gek ideetje: zou ik met ilasm.exe sneller dingen voor dotnet kunnen op basis van mijn eigen taal, dan dat ik me in de dingen rond CodeDom en Roslyn zou moeten inwerken? Stel, ik doe kleine dingetjes in C#, kijk met ildasm.exe hoe die IL er uit ziet en die doe ik na. Alleen, veel optimizing moet ik niet verwachten waarschijnlijk. Behalve /optimize die blijkbaar wat instructies kan verkorten, en eventuele achter-de-feiten optimalisatie van de JIT. Maar misschien zou het genoeg zijn om de bootstrappen? En/of beter de rest te snappen eenmaal ik verder raak met het echte compilerwerk. (Of zou ik toch eerst nog eens LLVM proberen?) Ik was voorzichtig begonnen aan een 'Pascal code gen', maar daar komt meer bij kijken dan ik had kunnen denken. En dan doe ik dat al om uit de weg te blijven van register allocation...

Quick, write it down: just another CPU design idea

Wed, 5 May 2021 22:57:34 GMT

Ever since learning about the Mill architecture, and watching an excellent series of MIT 6.004 lectures by Chris Terman (I can't find them on Youtube any more! But there are newer versions of 6.004 online which probably are great as well.) and reading up on what's new about x64 and RISC-V and ARM, from time to time my mind wanders if you could go crazy and design yet another CPU design that does novel things with the umptillions of available transistors and not have the downsides of the currently popular CPU's.

So here's an idea I just need to write out of my system, and let you have a look so you can see if there's anything there at all. Modern CPU's use virtual registers to have hyperthreading and speculative execution, and push whatever ahead in the hope it was the right branch to make pipelining work better for the workload at hand. The Mill architecture would handle that a little different and fill the pipeline just with more concurrent threads and interleave those. (At least that's how I understood what would be going on.)

What if you design a CPU so that it also takes in a larger set of streams of instructions, also using a bank of virtual registers that get alotted to these streams, but also have hot memory just like the closest cache is, but use that for the stack. Ideally you could expect programs to keep the current stack-frame fit within one or a few kilobytes, and by having a larger number of streams you could avoid having to switch this stack along with all the rest on context changes (by the OS). Switching the stack and overflowing the stack to and from memory is something that will have to happen, so you'll have decent support for that, but if you're after speed you'll try to avoid it as much as possible.

Let's have some numbers just to get a clearer mental picture. Let's say a core has support for 256 streams of instructions. If the work for them is pipe-lines across the rest of the core, addressing them would take 8 bits, so you would see a band of 8 lines pipe-lined to everything everywhere. It's not even required to have 256 instruction decoders, and sub-groups of streams could share commen instruction decoders, but depending on the instruction set design itself, this could turn out to be the bottleneck, but let's find that out with further design and research.

Let's say each stream gets 4KiB of hot stack memory, in total is 1MiB which is not unrealistic to have in a modern code nowadays, if I understood that correctly. This special memory could have extra lines so it automatically flows over into system's memory if the local stack index rolls over, which perhaps could also help with loading and flushing stack data on context changes.

With instruction fetching, stack handling and these streams doing their thing with alotted virtual registers, there's a lot covered, but the ofcourse the sweet magic happens in ALU's and related things, so down the pipe-line, according to what instruction decoding prescribes, the streams queue up to get one of the available ALU's to handle an operation.

This would be a point at which you start on a real design in a simulator, but that's where my knowledge is stronger than my experience. I just decide to start writing things down (right here, right now), let it simmer a bit and maybe pickup starting a first attempt sometime later. If you see what a former attempt like plasm ("play assembler") looks, don't get your hopes up too much. For now it's good that I wrote the core idea down here. If I ever get down to it again and get something working, you'll read it here. Sometime later.

205B random strings and no 'Delphi'

Sun, 28 Feb 2021 17:48:19 GMT

→ Delphi-PRAXiS: Can Delphi randomize string 'Delphi'?

Ah, that takes me back. A while ago at work I got someone baffled by this statement: It is said that a thousand monkeys banging away on keyboards could at some moment in infinite time produce the complete work of Shakespeare (and that the combined internet forums are a living counter-proof). Now if you search online you can find an XML download of the combined works of Shakespeare, so it's not hard to find the relative occurance of each letter of the alphabet. One can guess this will have rougly the same values per letter as the total of the English language. So, then, if you take 'random' by its definition, and the monkey's produce text at 1/26 probability for each letter in the alphabet, therefore they'll never reach a point in time where they (re)produce the works Shakespeare.

Now, I'm not a real philosopher, or a statistician, so my thesis could be complete fiction and based on nothing, but sometimes you really got to take a lesson from practice. In theory, in infinite time, it's ofcourse possible that something really really inherently possible could emerge out of a random system, but there are characteristigs to anything random, and there are exponential things at play that soon but experimantal set-ups like with the link above, that they probably would produce the expected outcome in a time-span that exceeds the number of years we've got left before the sun sheds its outer layers and devours the earth, complete with a set of silicon-based machines churning away at putting a series of random characters in sequence and comparing them of some neat stories of a long gone English playwright.

Google is too big! Time to split it up in pieces.

Fri, 18 Dec 2020 22:42:12 GMT

I've tought and written before about splitting up Microsoft. With the recent lawsuits against Google, there's talk about splitting up Google. But how? My mind starts to wonder. If you would ask me, this is what I would say, based on what I know (which may not be the full picture, but I'm just trying to do the same to Google what I did to Microsoft before, let's see where it takes us.)

Department: Advertising

Products: online ads and banners
Revenue: price per exposure

Let's start with the cash cow. I know there's a bit if 'advertising' tied into 'selling' keywords with the search results, but I'm not considering that in this department. So specifically the online ads and banners shown on all kinds of websites, should separate into something independent. The sweet talk that proclaimed benefit from keeping it tied into the big mix is about being able to offer you more relevant ads, but we know what that means. Your e-mails and search queries go through a farm of computer centers, and you get advertisements for the stuff you just bought. (Or a brand of dental prosthetics you're orthodontist doesn't even work with...) So back to basics, one trustworthy entity you can call upon to fill a side-bar of your website to show a marketing message of some other company (that's not on your black-list). (Or perhaps that is on your white-list, but I guess you would have to agree to review newcomers soon enough or your percentage might suffer, or something...)

Department: Android

Products: anything Android
Revenue: licensing

Open source and big companies are a complicated subject. If we stick to the basics, and perhaps compare to something different but somewhat similar, I still think an independant corporate identity could be the steward of the Android project and sell licenses to get permission to use the Android name, and get a hand on a curated build by the central authority of the project. If you really want, you can fork the project and roll it all yourself, but if you pay a reasonable price, you could get feedback if you're doing it right, get certifiers from the central authority to guarantee you the binding with your hardware devices is just right and is future-proofed for at least a version or three.

Department: Chromium

Products: Chrome, ChromeOS, (Fuchsia?)
Revenue: not for profit foundation

Google once decided the best it could do to be sure people could get the best possible access to their web services, is provide the best possible browser. It took an available HTML rendering engine that was the easiest to adapt (WebKit), an advanced new JavaScript engine that was beating benchmarks by compiling the hottest bits of code of a page (V8), did all the new things the others did also (tabbing, accept more than URL's in the address box), added sandboxing for security and a brute but effective technique to protect against a minor problem browsers sufferd from back then (process crashes, with a process per tab, only a tab crashes). It was a success. It may have been the beginning of the end for Microsoft's Internet Explorer, but it did re-heat the browser competition. It's sad maybe that Mozilla is having difficulty keeping up of late, but the fact that they're a not-for-profit, is something I guess would be a good setting for everything Chrome when Google would split. Microsoft, Brave, Apple (Safari), could all benifit from a central authority to work with and decide over important things about the internals of the generic browser experience. It should keep close ties to Mozilla and web-standards-workgroups, and perhaps even merge. But this may be wishful thinking on my part. There's also a thing called ChromeOS and Fuchsia, and I'm not sure if a full fledged operating system (built around a browser) would fit into this, but it might. Look at Linux, that's doing great as a set of non-profits, but with corporate backing here and there, right?

Department: Search engine

Products: search engine
Revenue: keywords auctioning

There's this story online of an ex-employee of a search service provider, that knew the end was near when fellow employees were using Google themselves. Search for it online, you'll find it. Google cut out the middle man and the search service market evaporated. It started with a thing called PageRank, but what it did was offer better results to anyone's search queries. If you take all the text on the web, and search for bits of text, you're off to one side of the ideal result set. If you think you could catalog all of the web in an extensive category system, you end up on the other side of the ideal result set. (And put a lot of effort in for limited returns.) You could try and build something intelligent that organically aims at this center sweet spot, but remember Goodhart's law. If you succeed, your new system will get gamed. In other words, SEO was born.

So the search engine part of Google living on its own could and should still offer to show 'paid for' search results on the keywords stakeholders select and/or organic statistics indicate as good candidates. Since there's money envolved, the engine needs to be transparent (of the crystal clear kind). In tune with the new spirit, it should be based on anonymity and respect privacy to a high degree. Even so, it could and should still actively promote societal inclusivity and combat (internationally?) criminal behaviour like enciting violence or popular misleading.

Department: Productivity Software

Products: G-Suite apps
Revenue: subscriptions

It will need a new name though. I guess it started with GMail (which itself may be a response to Outlook Web Access) that hit a sweet spot for people in search of a low bar to clear to get started with e-mail, and also with established users that appreciate improved defaults in e-mail handling. (Yes, Outlook has a threaded conversation view, but not by default, I remember it was buried in the custom column sort group view something in Outlook 2000.) A logical extension was a calendar and the rest of the usual apps in an office suite typical attachments are made with (word-processor, spreadsheet, slide show). That it would all get delivered through the browser, now looks like an evolution that would have happened anyway. But it may be easy to take heavy-hitting modern browsers for granted these days. Anyway, their office suite has managed to catch up fast and is almost feature complete with most other office suites out there.

Department: Cloud Services

Products: anything cloud
Revenue: pay for what you use

It takes a lot of resources and effort to put up all this machinery in data centers to churn away and convert network traffic to and from storage. It takes a specific organisation to make it all work, and it's inceasingly done with a distance to what it is you're clients are actually up to. As a provider you've got a set of virtual machines running, and everything everywhere has the hell encrypted out of it. In the ideal case, you couldn't even get to know what you're clients are actually working on if you really wanted to, by design. (Though some find this too ideal.) What I noticed is that much of the cloud offerings out there like AWS and Microsoft Azure, are getting a lot of parity: for everything cloud, there's a roughly similar offering from each of the providers. In an ideal world, you can mix and match to your benifit, but since they're still tied to the data-centers they run in, we're still stuck in one of the silo's unless we pay extra to set up a dedicated link between them.

Department: Research

Products: ?
Revenue: ?

Being Google, the research that's been done ends up all over the place, or nowhere (Wave? Glass?). They start a thing called SPDY (pronounced "speedy"), and it ends up parts in HTTP 3 and part in a kind-of successor to TCP? They're building cars, and also a boat, or is it a barge?

To their credit, it's actually OK that Alphabet Inc. was created as a group with Google as a member. It opens up the endeavours thet get 'promoted' into members of Alphabet of their own for a possible future on their own, or under another corporate parent. One of these is "X", which apparently handles any undefined research going on. Anyway, things like that may be going on in any large young tech firm, so why not out of one of the newly formed ex-Google-chunks outline above.

And I'm sure I forgot some things that Google is also doing, but I think I've listed the most important things here.

What if they replaced Windows with Microsoft Linux...

Sun, 11 Oct 2020 19:26:39 GMT

→ What if they replaced Windows with Microsoft Linux

Hmm, in the very far future, sure, why not. But right now, it may be a little harder than these people make it look like. So, where are we now and what would it take? I'll do some projections here based on what I personally feel and think, so I may be far off, but I hope I can make some points some people may be overlooking in this matter...

We've got WSL which was a great first step in the right direction. The most important thing here, and I guess it follows from the work that was done to get Docker working on Windows, is that there's deep deep down in the mechanics of the kernal, made an opening into the very fiber of the very thing that makes Windows Windows, and a base into the task scheduler so it could work with both the heavy-handed old-style Windows processes, and the lighter, moderner Linux-like processes. (I believe it was chosen to call them pico-processes because I guess at that level you'll not really want to get tied to something specific like Linux there and then...) What I really think is the most important that this serves as a precedent, that the kernel team is listening and willing to budge in any direction at all. So yes perhaps into a hybrid model where Windows allows a little more *nix very close to it's internals, and move from there to a little more and more of this and a little less and less of the old until it's all fine and ready to move up into an emulation layer. At this point they should have seen this coming, Windows 95 had to be able to run 16-bit applications for DOS, and ran 'Windows on Windows' 16-bit application with a translation layer that would convert all the calls to the underlying system 32-bits system. So, if you're on Windows, check your machine now for C:\Windows\SysWOW64, yes there's another emulation layer your 32-bits applications use to get work done on the underlying 64-bits system. I guess they're very hard at work as we speak to have a "Windows x64 on Windows ARM" as we speak, I've noticed some news items about that here and there recently.

(Which I regret a little bit, to be honest. I guess things could get a lot smoother to first have a "Windows ARM on Windows x64" sub-system and start promoting the developer tools to get your current applications already running in (fake) ARM and have the plain user completely oblivious. Performance will probably be comparable, and the gain you'd get when you finally get a hand on Windows-ready ARM hardware would be even greater because they've already prepared for ARM... But this may be all wishful thinking on my part, and a hard sell to management that need to get to maximum success with minimal investment...)

WSL 2 is another step in this direction, it lets go of talking the speach a kernel would, and talks all like 'system' what a kernel itself understands. It's only a step though, and what I'm really looking forward to is having a full-on Linux application play nice with the Windows graphical environment. There's a lot of differences to overcome there to make it happen, but it would open the way for the next steps. If there's a way to have both side by side, the work can start on the mirror movement: having a revised Windows graphical sub-system that talks with a *nix-style graphical setup, and have that as primary agent handling the graphical environment. With that you'll have much more in place to build a solution that runs as a Linux process and emulates a system with the DLL's in place to make an EXE work.

I know too little about the Linux kernel to know if this would mean Linux needs to provide the neccessary to have pico-processes of its own (or better giga-processes to fully reverse the projection), so this emulation layer actually shows in process enumeration that there's an EXE image running together with the other ELF-based images. Then again, I don't even know if Wine has this now, or even needs it. It would be nice though, that in this progress Microsoft pays respect to what went into Wine and silently and respectfully makes it so that the end-result nicely overlaps with Wine, progressing into a single strong solution to run Windows programs on Linux.

Could you do a mill architecture with RISC-V?

Tue, 29 Sep 2020 21:26:48 GMT

I wondered today if it would be feasable to build a processing unit according to the mill architecture with the RISC-V instruction set. But as always, I also wonder if I'm out of my league and know far too little of these things to come even close to forming an accurate answer, or even if I'm anywhere close to a good idea. If I understood correctly, the mill architecture does what modern CPU's already do: use a bank of virtual registers with multiple heavily pipelined streams of translated instructions. CPU's that do hyperthreading have two streams of instructions, but that's about it. I'm really rooting for the first article I read about a real system that has more than two, but with just a little imagination, and if you know the 'price per transistor' keeps going down, you can image a huge bank of virtual registers, with a bank of ALU's close, that processes a 'large' number of instruction streams. Ideally even a totally variant number of instruction streams. This may be a caching nightmare, but instead of wasting a lot of in-system logic to do branch prediction and other bookkeepingof what an instruction stream is doing, what if you could just load another instruction stream, just up until you get all of the piplined stages fully occupied...

Alas, I'm so much out of that business that I guess I need to conclude I'm a wild dreamer. I may stumble on a good idea now and then, but know too little to be sure. So I'll note it down here. I hope I haven't bored you, and with just a little luck, you are able to judge about this idea. If so let me know...

HP Pavilion Keyboard 300

Thu, 2 Jul 2020 09:48:37 GMT

Dear HP,
More specifically: Dear HP-person that was responsible for the design of the HP Pavilion Keyboard 300,

Congratulations on the great design. I appreciate the effort that went into designing a keyboard that brings the evolution of the laptop design to the desktop user. (Though I have bought this keyboard because the keys on my laptop are coming loose. It's not an HP, don't worry.) The result is a sleek minimal design that fits well with most other accessories of contemporary office work.

"Modern" applications are using less and less of the function keys. So I understand that keys marked "f1" though to "f12" now have a primary function that controls multi-media, the screen, or open the search or configuration dialogs. If you need to press a function key, you can still unlock this function by combining the key press with the "fn" key. I'm willing to adapt. (Albeit grudgingly.) I'm also willing to forgive the dumb pricks from electronics that forgot to provide a 'fn-lock' feature, for example under a combination of "fn" and the padlock key, or "fn" and "esc".

A daring design decision must have been to drop the num-lock, caps-lock and scroll-lock indicators. They take up much space and are in a place that people don't notice anyway. Considering nobody ever has 'num' unlocked anymore — all keyboards have dedicated arrow keys, now — I was pleasantly surprised to find a "paste" key where "num lock" is on other keyboards! It must have been a such big departure from current standards, that you've decided to keep a "scr lk" button as a reminder of all the good times. I too think there must be enough people using it in their daily work that it still merits a key of its own.

You can hear I'm quite positive. The one big regret, though, is you stole my right "ctrl". I used that one a lot. Especially with one-hand combinations with the arrow keys. Now I get "<" and the cursor not in the place I wanted. That'll be a lot harder to adapt to. It'll take so much concentration that I'd want to temporarily halt my music, but that's easily done now with a single press of the "f5" key — excuse me the "⏯" key.

Congratulations and thank you. I'll be thinking about you a lot.

Update: I recently learned this may be limited to AZERTY-versions of this keyboard. Still, if you are responsible for the above, my angry gaze is aimed at you.

Carefull with Gogole Sheet CSV export

Fri, 26 Jun 2020 13:18:29 GMT

Ready for another story from the trenches? So image a Google Sheet made by someone else, with all kinds of dat in about 30 columns, of about a few thousand rows. Yes, it's a stretch to keep using Sheets for that, but this data will serve for the analysis for a decent application to manage this with... That probably won't be my team handling that project, but I had to do a quick cross reference of this data with the data in the database of one our current projects. The best way to do cross-checks is get the sheet into a table in the database to run queries. I guess you should be able to import a CSV pretty easily, right? I searched around and found this:

https://docs.google.com/spreadsheets/d/{key}/gviz/tq?tqx=out:csv&sheet={sheet_name}

Which I thought would provide the data in just the way ready for me to import. Wrong. The second column just happened to have codes for all of the items that are numeric for the first few hundreds of items, and then alphanumeric codes. At first I thought the CSV importer was fouling up, but I hadn't looked at the CSV data itself. Turns out this CSV exporter checks the first few lines (or perhaps even only the first one!), guesses the column is numeric, and then just exports an empty value for all non-numeric values in that column!

The code in that column was only in a number of cases needed to uniquely identify the items, so I first was looking for a reason why my cross-match was throwing duplicates in all of the wrong places. Ofcourse. Weep one tear for the time lost, then move on. Take solace in the wisdom gained.

I solved it by using the CSV from the Export menu. I only needed it once so I didn't get a URL for that.