Anders Melander

No, but making a Delphi 12 preview available most likely would have solved it. These closed betas are a ridiculously out-of-date way of doing things.

If only there was a way to solve that problem...

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

I'm pretty sure that depends on who "you" is. So far I haven't found one.

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.

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 😞

I'm guessing all the people who have already implemented workarounds to handle HighDPI font scaling will think there's a bit too much 🙂 Hmm. As a developer, the year tells me nothing; I can't trust that the value actually specifies the year the product was released (because: marketing) or how far there are between versions (because: D2008). Anyway, the damage is done. I just hope they now stick with the sequential numbering.

Not that I disagree with you, but what is the purpose of your post? You obviously registered here just to have a place to vent your frustration but unless you state what your concrete problem is (was?), you are just shouting into the void.

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*

Well, at least they are self-aware. Always an important step toward fixing problems 🙂

I can confirm that Uwe's solution works. I've been using it for a long time without any problems. The IDE automatically restarts the LSP if/when it dies (apparently they expected it to crash occasionally).

Different layers. I haven't used either but AFAIK RTC Portal is a layer on top of RTC SDK. Note though that it's a completely proprietary protocol. You need something that implements the RFB protocol (which is what VNC uses).

I think you mean this one: https://github.com/CloudDelphi/RTC-Portal-VCL But that is neither VNC nor RDP, which is what the OP asked for. For RDP there is an ActiveX but I don't know what it does. I've never used it. https://learn.microsoft.com/en-us/windows/win32/termserv/remote-desktop-activex-control

GR32 too. No problem AFAIK.

No; I think our scorn for this design choice will be limitless 🙂 https://en.wikipedia.org/wiki/Trie And store the data in a resource.

Here's a quick update on the two issues @Allen@Grijjy encountered: The problem with the overlapping segments has been worked around in code by ignoring conflicts caused by the .tls segment. Incidentally, Allen found an old QC report about a similar issue (RSP-12824). Unfortunately, that issue was closed by someone who apparently doesn't understand what the map file segment offset values signify. Regardless, an overlapping .tls segment now only produces a warning message. The filter problem turned out to be a copy/paste problem. Allen had copied his map2pdb parameter list from a post here, and somewhere along the way, two invisible zero-width no-break space characters (#$F0FF) got inserted into the string he pasted. So what looked like '-include:0001' was actually '-include:000'#$F0FF#$F0FF'1'. I've been bitten by that one myself a few times when I've copied code from a browser.

The syntax is correct. I fixed the Range Check Error yesterday. Pull the latest source. There's no point in having a PDB without line information and, given the parameters you use, you should get a usable PDB. You can mail the map file to anders🍥melander.dk Actually, apart from the .tls problem, they look fine to me. You have to take into account that the PE Tools segment offsets are relative to the image base (see the Optional Header dialog) while the map file offsets are absolute assuming an image base of $00400000.

Yes. This is the exact default setup that I use. I have an additional two setups; One that includes everything (without the -include filter) and one that excludes a bunch of units (-exclude:dx*;cx*;winapi.*;vcl.*;data.*;firedac.*;soap.*;web.*;datasnap.*;id*;vcltee.*) to keep the size of the pdb down. On a related note, I've been considering making a GUI for this so that the filters can be specified visually (I believe AQTime does this). Often you know exactly what part of the code you want to profile and having PDB info generated for the rest is just overhead. No, that's not necessary. By default, everything is included. It's only when you specify an inclusion filter that everything by default becomes excluded. Yes, of course it is. We really need more awareness among Delphi developers of the tools available to them. That was my initial way of dealing with overlaps but the problem with that is that you don't know if the segment you're skipping is the "correct" one. And you might need the segment later on if there are references to it elsewhere in the map file. So far I don't have enough test cases of map files with these overlapping segments to be able to make a decision on how best to handle them, so if I could get my hand on the one you have that would be great. Also, if you could examine the corresponding exe file (I recommend using PE Tools) to find out what the actual segment offsets and sizes are (because they're obviously not what the map file states) that would be a big help. The .tls segment does seem to be a common factor among the various segment-related problems. For example: Again, I could just ignore segments with Offset=0 but then I would get errors later on as there are symbols referencing it. Another solution would be to hardcode handling of the .tls segment but I would really like to avoid a fragile workaround like that and keep the handling generic. Right now I'm mostly leaning toward marking segments causing overlap, or with offset=0, as invalid and then simply ignore all later references to them. The best would of course be if Embarcadero fixed the map file but I'm not holding my breath for that, and I still need to be able to handle what's already out there.

They are not errors. The "debug" prefix tells you that they are diagnostic messages produced because you specified the -debug switch. I have no idea. I guess there's probably something on the VTune site or maybe some help installed with VTune. -include and -exclude are filters that are applied after the map file has been parsed. If neither is specified, everything is included. If -include is specified, everything that doesn't satisfy the include filter is ignored. If -exclude is specified, everything that does satisfies the exclude filter is ignored. -include:* does nothing since it just includes everything - which is the default. Well, overlapping segments should never occur so that would be a bug in Delphi if you have that in the map file. In the first version of your your other message, you stated that you encountered some exceptions but were able to work around them by modifying the source. I'll of course be interested to know exactly what the problem was and what you changed, so I can get it merged into the source if there really is a problem. I'll probably also need to see the map files to get to the bottom of this. You can either create a (public) issue at Bitbucket or PM them to me here.

Okay, but why? Oh, I think I see what you are doing. Is it correct that... ...gives you the smallest size of a kernel containing all values >= 1/255?

Okay, but why? As you know, my calculation is based on FWHM: and the value you use now is the same as Gimp's but I don't understand the rationale for that calculation. Of course, one can use any radius/sigma factor one chooses since it's kind of an abstract value (for some algorithms) but it makes it a bit difficult to compare blurs if they don't use the same scale. The Gaussian RMS test isn't that important, BTW. AFAIR, it does a blur of a single-pixel vertical line and then compares the horizontal pixel values to the ideal Gaussian curve. If your Sigma/Radius differs from the one I use for the test curve it will show in the RMS. For example, a single pass box filter will have a high RMS. Two passes will produce a lower RMS, and three passes even lower, etc., as the filter approximates closer and closer to the Gaussian. The more important test is the Gaussian signal loss. In that, I sum the blurred pixel values and compare that against the summed Gaussian values. I.e. I compare the integral of the filter and the integral of the ideal curve. In theory, they should both equal 255. In practice, rounding errors make this difficult to test precisely. For example, the sum of the ideal curve is 252 for a radius of 10. Your algorithm has a loss of zero against the theoretical ideal curve (i.e. you have a sum of 255). This test should not be affected by the Sigma/Radius value. FWIW: https://brainder.org/2011/08/20/gaussian-kernels-convert-fwhm-to-sigma/ https://mathworld.wolfram.com/FullWidthatHalfMaximum.html

Don't do that; I don't know your code but I would think that very few strings actually need to be AnsiString. And even if your code already supports Unicode there can still be places that assume that SizeOf(Char)=SizeOf(Byte) and SizeOf(PChar^)=SizeOf(PByte^). Also, WideString is not the same as UnicodeString. WideString should generally only be used with COM. https://docwiki.embarcadero.com/RADStudio/Sydney/en/String_Types_(Delphi)

And so will the users if he just ships it 🙂 But seriously; There's already lots of good advice here. If I should add anything it would be to make sure that you do all this under version control (re: Git). That relieves some of the pressure of changing something that works into something that might potentially be full of bugs. It also makes it easy to see what you've changed so far.

Yes, I know you don't need an extra license. My point was that I don't think you even need to run the installer.