Vincent Parrett

Yup, have to a gree, and it doesn't help that the sites that sell certificates are just plain sh1te - I've never seem so much unhelpful content in one place. Working on a blog post about this, hoping to get it out tonight (it's almost 8pm here) or tomorrow. I'm trying to edit it down to a reasonable size and reduce the jargon where possible.

Good luck doing that when your build process runs from a windows service where you are not logged in.

I suspect this would be wasted money - my guess is OV certificates will eventually be discontinued.

I have been researching this for some time, since it will impact most of our customers. I really do wonder if they have considered the impact this will have on build automation. One thing I would point out is do not get a certificate that is issued on a Yubikey - there is absolutely zero way to automate signing - the yubikey uses the windows smart card api and absolutely prompts on every file you sign! So far in my research, it seems only SSL.com (also the cheapest) use Yubikeys - everyone else I have looked at so far uses SafeNet tokens, which do have a work around. If anyone has a token other than SafeNet or Yuibkey please let me know (brand and where it was issued). I did buy a Yubikey (without a cert) to experiment with but didn't get far with that yet. https://www.finalbuilder.com/forums/t/signtool-with-ev-certificate-fails/6535/22 I have yet to confirm if this work around works from a windows service (which is typically how CI servers run). More testing to be done in the next few days before my EV cert expires (we are still using our OV cert that expires next year in production).

Routing a support/install/licensing issue to sales (often 5 different people) to try and strong arm you into paying money doesn't make it a sales issue. I don't know of any other software company that sells perpetual licenses that does this. I've had issues installing old software before, but never once have I been strongarmed to buy again like embarcadero does. Hell, I sell software, and if you came to me an told me you had lost your v1 license key from 2001 I would help you get it installed at no charge (this happens multiple times a week). Of course I might suggest that you upgrade (and even offer a discount to get you on board), but I'm not going to route you to different people or employ used car sales tactics to get you to upgrade, I'll make the offer while helping you. Embarcadero need to do better if they want to retain customers and get old customers back on board, because right now their tactics are driving people away.

Licensing is not a sales problem, and yes the product is dying when you have to coerce former customers to keep paying for something they already paid for. Not a great way to build customer loyalty - so they don't have a currenty software assurance contract, now they probably never will.

This is imho an unconscionable business practice - either the licenses are perpetual or they expire when the subscription expires, embarcadero can't have it both ways. I can't imagine how many customers they have turned away with this practice - pretty much every delphi dev I have met has encountered this issue - several gave up and walked away from delphi because of this license insecurity. Some went back to D7 because they could always get their license to work. If a company is going to use node locked activation (which is what this is), then they have to provide a way to unregister/move/transfer licenses. It's not that hard.

Not so - they used helpers to avoid breaking dcu compatibility between the other 11.x releases - those helper methods will be merged into the classes in the next major release. Without the binary compatibility, third party vendors would find it next to impossible to support the varions .x releases.

If that were the case, then you wouln't need to change anything at all in SynEdit - but you do as it cannot see SetAdditionalPCREOptions. True, but with the regex they have created 2 helpers, and the TPerlRegex helper is the one causing the issue.

FWIW, the helpers embarcadero introduces in an update should disappear in the next major version, as those helpers were only used to avoid breaking dcu compatibility - so their methods will be rolled into the classes. At least that's the plan.

The one that embarcadero created will be used first, the synedit one will be ignored. Which helper is used is dependant on where they are decleared, since embarcadero declared theirs closest to the actual class declaration theirs will be seen first rather than the one on synedit.

Not sure you can.. the best option would be to change SetAdditionalPCREOptions to AddRawOptions - then it will compile in all supported versions.

Unfortunately they were implemented using a class helper, which now breaks Turbopack/SynEdit https://github.com/TurboPack/SynEdit/issues/229

I had the same issue, we closed our office and went full remote - the address with our DUNS number was still the old office/phone - so I wasn't able to verify via phone call - getting the DUNS details updated outside the US was a nightmare - we eventually got our new certficate a day or so before the old one expired. I won't leave it so late next time. The whole process is very unsatisfactory to say the least - they really need to find a (secure) way to streamline the process. Renewing should not be as hard as getting an entirely new certificate.

This is going to be a nightmare for us. Our CI servers are in a data center in another city (3hr drive) in a shared cage - so there is absolutely no way I can leave a dongle plugged into a server that other companies might have access to. Then there is the issue of sharing the dongle amongst multiple vm's - any of our CI agent vm's can do code signing at the moment - there is also the hassle involved in automating signing with the EV certificates We're currently investigating how this will impact us and our customers.

Does it stop working when you stop paying?

I'm too cheap, Fork is $50, gitraken is a subscription tool.

Yeah I know, pretty sure I was one of them. I've used a lot of version control systems over the years in my day job and git is certainly not my favourite - like it or not it has won the version control wars (for now). FWIW inhouse we use Mercurial (with tortoisehg) - which while similar to git, is simpler - with real error messages! I chose to learn enough git to get by, and with good tools like Fork I get by ok. The days of developers only needing to know one version control systems are long gone, just like the days of only needing to know one programming language.

99% of people working on open source are volunteers, none of us really have the time. I have a day job just like everyone else - I try to fit in my open source in evenings and weekends, in between spending time with family, football (I coach), home renovations etc. If something is going to take hours of research and more hours to develop, then it will likely have to wait until a gap in my schedule opens up. I'm sure I'm not alone in this. So yes projects might look abandonded, and maybe they are, but mostly the contributors are just busy. I don't know what the solutions are, but perhaps the jedi maintainers might enable issues on the github repositories, it makes much more sense to have the issues on the same site as the source code and pull requests (github links nicely between them all). That might spur on some contributions.

Why is this too complicated for people? Pull requests make a lot more sense for open source projects, as they make doing code reviews etc simple - where as with direct commit access there is always more risk that something get's broken, or that the committer takes the project in a different direction than what the project owner wants. I always tell people, before contributing to a project 1) create an issue and discuss with the other contributors/owners - then when everyone is on the same page 2) create a pull request 3) owner and other contributors review and approve/merge. Usually after step 1, if I do not have the time to implement it myself, I tag the issue as "PR Invited" meaning the issue is well understood and deemed worthy of implementation - and a PR that implements the feature/fix etc will have a good chance of being accepted. Sadly most of the time people ask/want but are not prepared to help/contribute. Github is not the barrier.

Yeah there are just too many issues/barriers with XE that made it too hard to support - for all my libraries now XE2 is the minimum I will support.

Before nuget and npm, there were not nearly as many libraries, and those that were out therre were hard to find. It was just like Delphi. Those tutorials you found would not have worked without the ability to restore the packages those projects referenced. If you mean having every third party library you use all installed at the same time - then no. The idea is you open a project in the IDE, DPM ensures that any libraries that project (or project group) uses will be installed. Not just any version of the libraries - the specific version that the project references (this is an important feature that Getit doesn't.. get). If the package has been installed before, it would available in your local package cache and the install takes ms - if not then it will download that package and it's dependencies (another feature Getit is missing) and install them. Sure, but Indy is just one of many open source delphi projects out there. Currrently they all have different instructions for installing.. go and look at the issues tab on github for most of them and there will be loads of people struggling to install them - expecially if they depend on other libraries. Delphi is absolutely being held back as legacy tool because of it's lack of a real package manager (well that and it's poor quality and lack of modern language features). GetIt is a toy, a tightly controlled black box with a curated list of packages (only ones embarcadero likes). Most of those are constantly out dated.. and if you install from there you always get the latest version that they decide on - what happens when that latest version breaks your project - how do you roll back. Being able to control the version of packages used by a project is an absolute must. Add automated builds/CI into the mix - do you really want a random version installed when you run a production build? Anyway, I'll shut up now.. I just get frustrated when I see or read about yet another way to install a single library 😞

Do you use GetIt? Or a package manager on other dev platforms - like nuget for .net, npm for javascript, Gem for ruby, Crate for rust etc. The idea is to provide a standard way to deliver and install libraries. GetIt doesn't meet the expectations of anyone who has used a real package manager. There is quite a lot done - but still plenty more to make it production ready. IDE integration looks like this - installing components into the pallete isn't working yet as it requires more work on the project group support (dealing with conflicts etc). I have also made some good progress on a package server (not a public repo yet). I have so far not managed to get the community interersted in helping out - so progress is painfully slow.

Or you could help working towards an automation tool for all libraries 😉 - I haven't had much time to work on it lately (too busy working on FinalBuilder) but I'm still keen to get it going.. I use it every day with my own packages.

With GDI Scaling - controls don't really do anything special - the OS is doing the scaling - it's not really the best option here. VST uses small bitmaps - which when scaled will look pretty poor - VST has no idea the OS is scaling things. I would go with Per Monitor V2 - which VST does support quite well (I use it and did some of the work on VST high dpi support) - it knows when scaling happens and it can redraw things like the arrow bitmaps rather than scale them.