sgcIndy Quick Start

At a glance

The fact that shapes everything else

There is no sgcId prefix. Not one unit, not one class. Your existing code compiles unchanged.

Unit names

Plain Indy names. IdTCPClient, IdHTTP, IdSSLOpenSSL, and around four hundred more. No unit in the library is named with an sgc prefix.

Class names

Plain Indy names too: TIdTCPClient, TIdHTTP, TIdSSLIOHandlerSocketOpenSSL, TIdSSHClient, TIdSFTPClient.

Palette pages

The same five: Indy Clients, Indy Servers, Indy Intercepts, Indy I/O Handlers and Indy Misc. Around 166 components across them, in the places you already look.

So what changes

The installer swaps which packages the IDE loads and rewrites the search path. Your project does not change. The visible difference is a new property, SSLOptions.APIVersion, and the fixes underneath.

Before you start

Requirements and editions

sgcIndy has no feature tiers. The licence tiers change what is in the box, not what the code can do.

What	Value
IDE	Delphi 7 through RAD Studio 13, and C++Builder 2007 through 13. Package groups ship for each.
Uses clause	Unchanged. Whatever your project already writes keeps working, because the unit names are identical to stock Indy.
Indy base version	The library reports itself as Indy 10.6.3.12. The sgc changes are marked with comments and conditional defines inside the original units, not by renaming them.
Editions	No feature tiers. The edition flag is injected at build time and has exactly two consumers, the About box and the IDE splash screen. Nothing in the library is gated by it. What the tiers actually change is packaging: the Community and Basic builds ship compiled binaries with the `.pas` and `.inc` files excluded, while the source build includes them.
FreePascal and Lazarus	Supported. A Lazarus package ships, along with the FreePascal package stubs and build files, and the compiler ladder covers FPC 2.2.2 up to 3.3.1. One caveat: Delphi mode is deliberately disabled for Lazarus, so a unit that assumes it will need adjusting.
Platforms	Windows, Linux, macOS, FreeBSD, iOS and Android all have their own conditional blocks. On iOS, OpenSSL has to be linked statically.

The single most useful thing to know before you start: because the unit names collide with the Indy that ships in RAD Studio, the installer manages the swap for you. It unregisters the built-in Indy design packages, registers its own, and rewrites the IDE search paths.

Step 1

Install and confirm the swap

The installer does the work. What matters is confirming that the IDE really is loading sgcIndy afterwards.

1. Run the installer

Run the downloaded setup and tick the RAD Studio versions and platforms you want. It copies the library and, for the Community and Basic packages, omits the source files.

2. Let it swap the packages

The installer unregisters the IDE's built-in Indy design packages and registers its own in their place. This is what makes the same unit names resolve to sgcIndy.

3. Let it fix the search path

It puts the sgcIndy folders at the front of the IDE search paths for each platform, and removes stale entries from a previous install.

4. Confirm at the splash screen

Restart the IDE. The splash screen names sgcIndy, and the Indy About box says so as well. That is the check that the swap took.

5. Rebuild your project

Open your existing Indy project and rebuild. Do not touch the uses clause. If it compiled against stock Indy it compiles against this.

QuickStart

Rebuild, then reach TLS 1.3

The first tab is what your existing project already looks like. The second is the one new line worth adding. The third proves you are on sgcIndy and not on stock Indy.

FHttpClient.pas

// This is a shipped sgcIndy demo's uses clause.
// Read it twice: there is not one sgc prefix in it.
uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, IdBaseComponent, IdComponent, IdTCPConnection, IdTCPClient,
  IdHTTP, IdIOHandler, IdIOHandlerSocket, IdIOHandlerStack, IdSSL,
  IdSSLOpenSSL, IdSSLOpenSSLHeaders, StdCtrls;

Your existing project already looks like this, which is the point. There is no sgcIdTCPClient and no TsgcIdSSLIOHandlerSocketOpenSSL, because no unit and no class in the library carries an sgc prefix. Install, rebuild, done.

FHttpClient.pas

procedure TFRMHttpClient.btnGoToClick(Sender: TObject);
var
  oStream: TStringStream;
begin
  // Two separate settings. APIVersion picks which generation of the
  // OpenSSL API to call, Method picks the TLS version. TLS 1.3 needs
  // the 3.0 API, so both lines change together.
  IdSSLIOHandlerSocketOpenSSL1.SSLOptions.APIVersion := sslvAPI_3_0;
  IdSSLIOHandlerSocketOpenSSL1.SSLOptions.Method := sslvTLSv1_3;

  oStream := TStringStream.Create('');
  try
    IdHTTP1.Get(txtURL.Text, oStream);
  finally
    FreeAndNil(oStream);
  end;
end;

TIdSSLAPIVersion has the members sslvAPIDefault, sslvAPI_1_0, sslvAPI_1_1 and sslvAPI_3_0. Neither the type nor the property exists in stock Indy, which makes this snippet a compile-time proof of which library you are building against.

fTcpClient.pas

procedure TfrmTCPClient.btnConnectClick(Sender: TObject);
begin
  IdSSLIOHandlerSocketOpenSSL1.SSLOptions.APIVersion := sslvAPI_3_0;
  IdSSLIOHandlerSocketOpenSSL1.SSLOptions.Method := sslvTLSv1_3;

  IdTCPClient1.Host := txtHost.Text;
  IdTCPClient1.Port := StrToInt(txtPort.Text);
  IdSSLIOHandlerSocketOpenSSL1.PassThrough := False;

  IdTCPClient1.Connect;
end;

procedure TfrmTCPClient.btnDisconnectClick(Sender: TObject);
begin
  IdTCPClient1.Disconnect;
end;

Same components, same properties, same palette page. PassThrough := False is what turns the plain socket into a TLS one, exactly as it does in stock Indy. Reading is IdTCPClient1.IOHandler.ReadLn, writing is IOHandler.Write, unchanged.

The first two tabs come from the shipped demo Demos\HttpClient\FHttpClient.pas, with the combo box replaced by a literal. Eighteen demos ship in total, including SSH and SFTP clients, an FTP client, mail clients, a TCP server and a UDP pair.

Step 2

Prove you are running sgcIndy

Because the unit names are identical, you cannot tell from your own source. Here are three checks that are unambiguous.

The splash screen

Restart the IDE after installing. The splash screen names sgcIndy. That is the check that the package swap took, and it is the fastest one.

The About box

The Indy About dialog reports eSeGeCe rather than the stock text, and says Community Edition on the free package.

A line that will not compile against stock Indy

SSLOptions.APIVersion := sslvAPI_3_0;. The TIdSSLAPIVersion type does not exist in stock Indy, so if that line builds, you are on sgcIndy.

Your own project

Rebuild it without touching the uses clause. It should compile exactly as it did before, because the unit and class names are identical.

Common problems

What usually goes wrong the first time

Six problems account for nearly every migration.

You went looking for sgcId units

There are none. Zero units and zero classes in the library carry an sgc prefix. If you rewrite your uses clause to sgcIdTCPClient the project will not compile, because no such unit exists.

The IDE still loads stock Indy

The installer handles the package swap, so this usually means the install did not complete or a manual search path entry is winning. Check the splash screen, which names sgcIndy when the swap took.

TLS 1.3 does not negotiate

Set both properties. SSLOptions.APIVersion selects which OpenSSL API generation to use, and SSLOptions.Method selects the protocol version. TLS 1.3 needs the 3.0 API, so both lines have to change together.

The OpenSSL DLLs are missing

Each demo folder ships the set it needs beside the executable. For the 3.0 API that is libcrypto-3.dll and libssl-3.dll. For the older APIs the names are different, and copying the wrong pair is a common cause of a handshake that fails before it starts.

A unit fails under Lazarus

Delphi mode is deliberately switched off for Lazarus builds in the compiler defines, with a comment saying it fails there. Code that relies on Delphi mode semantics needs adjusting.

The source files are not in the package

The Community and Basic installers ship compiled binaries and exclude the .pas and .inc files. If you need to step into the library, you need the package that includes source.

Go deeper

What sgcIndy adds on top of Indy

Four things worth knowing once the rebuild is done.

Modern OpenSSL, and TLS 1.3

Stock Indy 10.6.2 predates the OpenSSL 1.1 and 3.0 API changes. SSLOptions.APIVersion selects the generation, and sslvTLSv1_3 becomes reachable on the 3.0 API.

sgcIndy features

SSH and SFTP

TIdSSHClient and TIdSFTPClient are not in stock Indy at all. Demos ship for both.

SSH client and SFTP client

High-performance servers

The IOCP and epoll IO handlers replace the thread-per-connection model on Windows and Linux, which is what changes the shape of a server under real load.

How it compares

Modern authentication for mail

XOAUTH2 support means an SMTP or IMAP client can authenticate against providers that have retired basic authentication.

XOAUTH2 in sgcIndy

Resources

Reference, demos and documentation

Eighteen demo projects ship inside the download, from an echo client to SSH and SFTP.

	sgcIndy features What this build fixes and adds on top of Indy 10.6.3.	Open
	How it compares sgcIndy against stock Indy, feature by feature.	Open
	Download The Community package is free to use.	Open
	Order The packages that include full source.	Open
	Product overview What sgcIndy is, and who it is for.	Open
	All products Pricing for every eSeGeCe library in one table.	Open

Related reading: OpenSSL 3.0 with Indy, the IOCP server, the SSH client and the latest release notes. Every product has its own quick start, listed on the getting started page.

FAQ

sgcIndy quick start questions

No, and this is the single most important thing about sgcIndy. Every unit keeps its original Indy name, IdTCPClient, IdHTTP, IdSSLOpenSSL and the rest, and every class keeps its original name, TIdTCPClient, TIdHTTP, TIdSSLIOHandlerSocketOpenSSL. There is no unit and no class anywhere in the library carrying an sgc prefix. Install it, rebuild, and your project is on sgcIndy.

The installer swaps them. It unregisters the built-in Indy design packages from the IDE, registers sgcIndy's in their place, and puts the sgcIndy folders at the front of the search paths. Because the unit names are identical, that is what has to change rather than your code.

Three checks. The IDE splash screen names sgcIndy on startup. The Indy About box says so as well. And there is a compile-time proof: SSLOptions.APIVersion exists only in this build, so a line that assigns sslvAPI_3_0 to it compiles here and fails against stock Indy.

Two properties, set together. SSLOptions.APIVersion := sslvAPI_3_0 selects the OpenSSL 3.0 API generation, and SSLOptions.Method := sslvTLSv1_3 selects the protocol. The TIdSSLAPIVersion type has the members sslvAPIDefault, sslvAPI_1_0, sslvAPI_1_1 and sslvAPI_3_0, and TIdSSLVersion gained sslvTLSv1_3. Then ship libcrypto-3.dll and libssl-3.dll beside your executable, as the demos do.

The library reports itself as Indy 10.6.3.12. The sgc changes are made inside the original files, marked with comments and guarded by conditional defines, which is exactly why the unit names could stay the same.

None of them, because no feature is gated by edition. The edition flag is injected at build time and has only two consumers in the whole library, both cosmetic: the About box caption and the IDE splash screen text. What the tiers actually change is packaging, because the Community and Basic installers ship compiled binaries and exclude the .pas and .inc files, while the package with source includes them.

Yes. A Lazarus package ships, together with the FreePascal package stubs and build files, and the compiler ladder covers FPC 2.2.2 through 3.3.1. There is one caveat worth knowing before you start: Delphi mode is deliberately disabled for Lazarus in the compiler defines, with a comment saying it fails there, so a unit that depends on Delphi mode semantics will need adjusting.

Windows, Linux, macOS, FreeBSD, iOS and Android all have their own conditional blocks in the compiler defines. Unix targets use OpenSSL and the bundled zlib unit. iOS is the one with a real constraint: OpenSSL has to be linked statically there rather than loaded at runtime.

sgcIndy in five minutes