Anders Melander

That's nonsense; RAD Server is not a replacement for DataSnap and DataSnap is not being discontinued. Actually, IMO it is more likely that RAD Server will be discontinued before DataSnap is.

I miss it every single time I need to install/update. Apparently, there are no UXers left at Embarcadero. Left-aligning the button would likely solve the problem but ideally, it should not be placed on the EULA page where one habitually just clicks through.

Looks interesting but then I went to the SonarQube site to see what their commercial terms were like and... Of course, given that they don't even list prices and that I had to Google for them, I guessed that much. OpenSource only then, I guess.

Why do you say that? My guess is that you've been googling and once again have found some information that only applies to a specific product's implementation of WebDAV and once again haven't bothered to try to understand the context of the information. Maybe read the WebDAV specification instead.

It's a private repository... and why don't you migrate it to 64-bit yourself?

AFAIK the zlib library that TZipFile wraps does not support LZMA compression. If you google for "delphi lzma" there's plenty of other solutions.

It makes better sense when you've read the documentation... https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow And as is usually the case with things like this, Raymond Chen has words: https://devblogs.microsoft.com/oldnewthing/20090220-00/?p=19083

Sigh. Did you actually read the posts you highlighted? None of them are relevant to you. You do not need Indy to support it. You just need to be able to handle HTTP requests on the server and send requests from the client. Your server implementation will be completely custom to your application (like every other WebDAV server (which is also why you won't find a standard WebDAV "component" on any platform)) and since you will not be using a standard WebDAV client application, your client implementation might as well also be completely custom. If there's an Indu client component that can do what you want then sure, use that. WebDAV is a very simple protocol and would be easy to implement using standard HTTP components. There's nothing special about those requirements. I would think most WebDAV implementations have similar requirements. User authentication is handled in another layer (pretty standard http layering). The WebDAV layer gets user info from that layer and decides what the user is allowed to access and do. What would a user do with a list of "thousands of files and folders"? This sounds a bit like one of my current clients who as a requirement specified that "the grid must be able to display and scroll through a million rows without any lag"... I mean I could limit the grid to 10,000 rows and nobody would ever notice. Regardless, I don't see why sending a list of "thousands of files and folders" would become a performance problem. Regardless of what solution you go for, it's the same information that is going to be sent over the wire. Anyway, it sounds like you are rubber-ducking a bit here and it would probably be smarter to first figure out what it actually is you want to do before asking about how to do it.

I don't know why you quoted that specific document without specifying the source: https://support.netdocuments.com/s/article/360044231332 It's just some CMS service provider notifying its users that it no longer supports WebDAV. WebDAV isn't going anywhere; It's just a protocol standard.

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).