Anders Melander

It sounds like you are reinventing WebDAV... Bad idea, IMO. Supposedly a client that has acquired read-access will expect some kind of file stability. It would make more sense to make write locks exclusive and have read locks block the acquisition of write locks.

I have just released version 3.1.2 with the following changes since 3.0.1: map2pdb can now consume JEDI jdbg-files. A rare overflow bug in the MSF writer has been fixed. The map parser can now handle the slightly different files produced by beta versions of Delphi. The big change here is the ability to create pdb-files from jdbg-files. You can thank Stefan for being so annoying that I finally caved in and implemented it to get him to shut up about it. This means that it is now possible to profile Delphi's run-time packages by converting the jdbg-files bundled with Delphi and binding the produced pdb-files to the bpl-files. It's as easy as map2pdb -bind:rtl290.bpl rtl290.jdbg Because of a bug in the JEDI tool Embarcadero uses to convert from map to jdbg, some symbol names produced from Embarcadero's jdbg-files may look a bit strange. It's a minor issue that has no impact on the functionality and there's nothing I can do about it since the original map files aren't available. Get it while it's hot: https://bitbucket.org/anders_melander/map2pdb/downloads/ Here's an example from Stefan showing an application using the rtl290.bpl run-time package being profiled with VTune:

I wish you would change your screen name; If you calculate the Scrabble value of it, using French Scrabble, you get... 26 which, as everyone knows, is twice as unlucky. If losing customers due to superstition really is that big of a problem they should just give up and go do something else.

That "joke" is getting a bit old, to say the least. Maybe it's time to evolve and not do that for once.

How do you justify the price difference between the English and the Russian version? English: USD 550-150= USD 400 Russian: 4*USD 65 = USD 260

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.