Leaderboard

And makes your app a target for anti virus products. And what what gain? You end up with the same executable loaded in memory. I've never understood the point of this tool.

It would make his project fit on 10 floppy disks instead of 35.

Also not true (anymore, it might have been decades ago) - or it might happen that a shifting pointer might be better because of register pressure or shortage under x86 because it only requires one register opposed to two when indexing into an array. But indexing into a memory address with an increasing or decreasing index register is always faster. Another situation might happen when your array is a field of your class and you index into that one because then the compiler is really stupid and re-reads the field every time and then indexes into it. But then the issue is re-reading the field and not the indexing into it. I solved this by putting the array into a local pointer variable and then index into that one - like here. And yet another situation happens on 64bit when using an Integer index variable because then it always does an extra register widening instruction which can be not zero cost (yes, I need to fix the code I just pointed to because it does exactly that having i declared as Integer and not NativeInt as it should be, shoot me). Oh, one particular bad thing about dcc64 is that it does not really optimize some instructions in loops well. From dcc32 we know about the counting down to 0 behavior of a for-to loop where it maintains two counters, the actual index variable (if you actually use that within the loop) and the counting down to 0 variable that it uses to control the loop. For that it usually uses the dec/jnz combination which works well, macro fuses and all that. On win64 it does sub reg, 1, test reg, reg, jnz where only test and jnz fuse which causes wasted cycles. That extra test is complete bonkers because the sub (which should actually be a dec) already sets the zero flag! See RSP-37745 Another missed opportunity of loop optimization that affects both win32 and win64 is letting the compiler create loop that counts from -count to -1 which is another optimization technique where you grab the position after the last element then index into it. This way if you don't need the index variable itself for something else than indexing you only need 2 registers, one points to right after the last element and the loop just needs the nicely fusing inc reg, jnz

All these marketing people trying to generate buzz around a name. How about fixing the bugs and making the product better? Then you can call it anything you like and it will sell.

Then please stop using it. Referring to a release by name instead of the version number which everybody recognizes, is just confusing, and everyone, Embarcadero in particular, should just stop doing it. It's pretty annoying having to Google it when someone refers to the name instead of the version number. I haven't bothered with the names since Ivory (see what I mean?). It's bad enough that the version number and build number haven't been in sync since marketing took over and made the numbers "hip" with D2xxx and later XE*

Just right mouse click over the button bars at the top of the IDE.

Changing the values makes no difference. Here is the solution:

re: the webinar I wouldn't mind a Youtube video link once it's over.

Like most new features and bug fixes, this introduces new bugs: https://quality.embarcadero.com/browse/RSP-43261 https://quality.embarcadero.com/browse/RSP-43263 Update I found a third even more serious issue related to the changes introduced for font scaling: https://quality.embarcadero.com/browse/RSP-43270

It's possible to care about more than one single thing. Personally, I care a lot about performance but I also care about code readability, ease of UI design, and TBH, the amount of fun I have writing the code. If I only cared about performance then I probably wouldn't use Delphi.

The lack of implementing that feature request was the driving force behind writing that article. As long as everybody steps away from designing in High DPI the collected bug reports will only cover the obvious cases but miss the deeper ones. Thus I decided to use the form designer in High DPI for at least one of my projects and see how it goes. Obviously I had to develop a strategy and some workarounds to make it usable in the first place. Publishing it is based on the hope that others also step on that ship and share their findings, too.

Why do you care about these tiny differences in these tiny executables? If you care use Delphi 5.

You realize that it's not "exact same code" if you compare 11 and 12, right? The code in the RTL and the VCL or FMX (depending on which one you use) - change between those versions. It only requires one use of a class somewhere that was not used before or an introduction of an additional list of something inside of some class and the binary size increases. Go diff the source directory of your C:\Program Files (x86)\Embarcadero\Studio\22.0 and C:\Program Files (x86)\Embarcadero\Studio\23.0 directories and check for yourself. Or build with a map file and then diff the map file to find these changes. Also - and this might be marginal but contribute to the overall increase: they changed the count and index of all collection types to NativeInt which means that some instructions regarding those might be a few bytes larger on 64bit (see some x86-64 instruction reference of your choice for details). Otherwise, when I think about it it might also save a few bytes because it does no do register widening anymore on 64bit. So take this last paragraph with a grain of salt and consider it just additional information. I would guess a few fixes and new features here and there can easily add up to 300K more binary size - especially with the general issue the Delphi compiler has with generics - see RSP-16520.

Yes, that ParentFont thing was what has kept me from making my application DPI aware. I do hope they got it right this time. I can imagine that the 3rd party suppliers, which have to support older versions too, won't enjoy having to adapt to the new way of scaling and maintain compatibility with the old way. Yes, from the list of compiler and RTL fixes and improvements alone, this looks to be one of the better releases. Not so much in terms of new gimmicks but I don't really need those (or the bugs that come with them) anyway. Now if I only had time to actually install it and try it out 😞

Marketing people don't fix bugs 😉

TBH IMO using years is kinda ok and a version number where the number after the dot means "update to that version". What was marketing bs was the XE numbering and then later making the 10 minor versions actually major versions - combining that with city names just made things more confusing (man, I still have to think if Tokyo or Rio was first...). Funny enough as far as I can see the IDEs in 11 and 12 don't reference the city name anywhere.

AFAIK it matches the commit from September, 11th 2023 (65ae6909208257e51450be7ec724fd54aedfeba4)

Going by the last couple of CE releases, not for at least several months, probably after at least update 2.