Remy Lebeau

You can use ServiceThread->Terminate() instead. Yes, that will work, too. You can send it any control code that you can pass to ControlService(), such as SERVICE_CONTROL_STOP. If that is all the code your OnExecute handler has then you don't need to have the handler assigned at all. When OnExecute is not assigned a handler, the service handles SCM requests automatically by default. When you assign an event handler, you become responsible for handling requests yourself.

What is the goal here? GetTickCount64() is available in Vista (6.0) onward. The page you quoted says the 64bit tick counter existed in 5.1, but wasn't actually in use until 5.2. So 5.2->6.0 is a pretty small window if you are just looking to emulate GetTickCount64() on pre-Vista systems.

You are accessing a 64bit tick counter that is located at fixed address (0x7FFE0000+800), but according to this discussion: https://groups.google.com/g/comp.lang.asm.x86/c/zA0WcO6_5AU, in XP SP1 and earlier at least, the tick counter was a 32bit integer located at address (0x7FFE0000) instead. According to the history outlined here: https://www.geoffchappell.com/studies/windows/km/ntoskrnl/inc/api/ntexapi_x/kuser_shared_data/index.htm, Windows deprecated the 32bit counter and switched over to the 64bit counter in v5.2 (ie, XP Pro 64bit) onward.

They are called Unit Scope Names, not qualifiers. And don't confuse them with Namespaces, which uses a similar naming syntax but different semantics. Here is a useful site: List of Delphi Pascal Features and When Introduced

See the documentation: Properties (Delphi): Storage Specifiers

Sounds like the property isn't declared/coded properly. But without a specific example that demonstrates the problem, it is very hard for anyone here to diagnose it.

Sorry, but there is no native option for that. Only 3rd party solutions like GExpert. Can you be more specific?

https://github.com/IndySockets/Indy/wiki/Documentation/ https://github.com/IndySockets/Indy10Demos The link itself works just fine. Perhaps you are referring to the fact that the website has pages missing? https://www.indyproject.org/2021/02/10/links-to-old-indy-website-pages-are-currently-broken/

Why are you looking at Indy 9 snippets and not at Indy 10 snippets? Yes. All of the I/O methods that were present in the TIdTCPConnection class in Indy 9 were moved to the TIdIOHandler class in Indy 10, eg: IdTCPClient1.IOHandler.WriteLn('start'); ListBox1.Items.Add(IdTCPClient1.IOHandler.ReadLn); Also, many of the older writing methods in Indy 9 were renamed to Write() overloads in Indy 10.

Focus Mode hides everything except the code editor.

I was simply fixing the broken syntax in uligerhardt's reply.

const OTHER_FLOAT_CONSTANT = Double(0.005);

You should file a bug report about that. Embarcadero spend a lot of effort revamping the MDI system in 12.0.

It is true that variables can't be initialized when using the 'var' block at the top of the function. But inline variables can be initialized: begin var foo: Integer := 10; // OK

Does it have to be Win10 specifically? Or is Win8 enough? The ability to use the WS_EX_LAYERED style on child windows was added in Win8.

Or, simply run each build in a separate cmd.exe instance so they each have their own environment. Changes made to the environment variables are local to each instance, not saved globally or across instances.

They stopped publishing roadmaps publicly, there hasn't been a new roadmap shown for several years now.

Have you read the documentation yet? https://docwiki.embarcadero.com/RADStudio/en/MSBuild https://docwiki.embarcadero.com/RADStudio/en/Building_a_Project_Using_an_MSBuild_Command

Do you have the same problem if you use MSBuild instead of invoking the compilers directly? Building a Project Using an MSBuild Command

You have that backwards. It doesn't. Libs that are shipped with the IDE are separated, but user-provided libs are not. So either separate them yourself, or don't have them both installed at the same time.

That won't work. SetPairs() expects a list, not a Set or an array. You would need to use this instead: JsonObject.SetPairs(TList<TJSONPair>.Create); This is because SetPairs() takes ownership of the new list, freeing the old list. The list can't be nil or else you risk crashes on future operations on the TJsonObject.

The "crew" is me. Since Indy 11 has been pending for a very long time, I've been considering lately about updating Indy 10 just to bring it more inline with Embarcadero's releases (ie, adding LIBSUFFIX, etc) sooner rather than later. Dropping older compilers, etc will still wait for Indy 11 for now.

The OpenSSL code that is currently in the main library is being pulled out completely into its own separate package that uses the main library. This way, future updates to OpenSSL are more isolated and can be worked on and committed independently outside of the main library. Yes, that is the plan. I've already asked Embarcadero for details about the changes they make to their bundled release of Indy.

Just FYI, PR 299 (https://github.com/IndySockets/Indy/pull/299) has been abandoned by the author. Going forward, there is a new effort now to update Indy to the latest OpenSSL using a completely new and separate package as an add-on to indy: https://github.com/IndySockets/IndyTLS-OpenSSL The existing OpenSSL code in the main Indy library is being pulled out into this new package for a v1.0 release for existing users, and then it will be updated with the latest OpenSSL APIs in subsequent releases, independent of the main Indy library.

I started using C++Builder in the early 2000s with BCB v5, and then used v6 exclusively for ~15 years. But my day job doesn't use C++Builder anymore, so I haven't used it at all in recent years.