Une question récurrente des clients qui analysent leurs exécutables est : «pourquoi mon EXE a-t-il grossi après l'ajout de sgcWebSockets ?». Une partie de cette augmentation provient d'un fichier de ressources que les paquets runtime sgcWebSockets embarquent par défaut : sgcResources.RES. Il contient le bundle client JavaScript qu'un serveur sgcWebSockets peut distribuer via HTTP à un navigateur distant — une fonctionnalité que la plupart des applications Delphi et C++Builder n'utilisent jamais.
À partir de sgcWebSockets 2026.6, vous pouvez vous en passer. Le Setup de l'édition source gagne une nouvelle case à cocher Include Resources sur la page Options ; la décocher annule la définition d'une nouvelle directive de compilation SGC_RESOURCES dans sgcVer.inc avant que les paquets runtime ne soient compilés. La ressource n'est tout simplement jamais liée — ni dans les BPL, ni dans les EXE de vos clients.
Ce qui est supprimé
La directive {$R} dans le code source de sgcWebSockets est désormais encapsulée dans {$IFDEF SGC_RESOURCES} :
// sgcWebSocket_Protocol_Base_Server.pas
{$IFDEF SGC_RESOURCES}
{$R sgcResources.RES} // sgcWebSockets JS client bundle
{$ENDIF}Quand SGC_RESOURCES n'est pas défini, le linker n'a rien à embarquer. La ressource disparaît purement et simplement de chaque exécutable lié au code source.
Quand vous n'avez pas besoin de cette ressource
Le bundle embarqué n'est nécessaire que lorsqu'un serveur sgcWebSockets distribue effectivement le client JS embarqué à un navigateur distant. Cela se produit avec les composants TsgcWSProtocol_JS_*, ou tout serveur qui répond à GET /sgcwebsockets.js en renvoyant le JavaScript embarqué.
Il n'est pas nécessaire pour :
- Les clients WebSocket Delphi / C++Builder — les données sont consommées en code natif, jamais dans un navigateur.
- Les serveurs natif-vers-natif — serveurs dont les clients sont eux aussi des applications Delphi / C++Builder.
- Les back-ends WebSocket servant un JS personnalisé — si vous livrez votre propre client JavaScript (votre propre bundler, votre propre CDN), celui qui est embarqué est du poids mort.
- Les serveurs MQTT, AMQP, STOMP, WAMP, MCP et serveurs protocole uniquement — aucun d'eux n'utilise le client JS embarqué.
Comment l'activer
La voie la plus propre est l'installeur. Lorsque vous lancez le setup de l'édition source de sgcWebSockets, appuyez sur le bouton Options et décochez la nouvelle entrée :
[ ] Include ResourcesL'installeur réécrira la ligne {$DEFINE SGC_RESOURCES} dans sgcVer.inc en {.$DEFINE SGC_RESOURCES} avant de compiler le moindre paquet, de sorte que les BPL design-time et runtime sont produits sans le bundle embarqué.
Si sgcWebSockets est déjà installé et que vous préférez effectuer la modification manuellement, ouvrez <sgc-install-folder>\Source\sgcVer.inc, trouvez la ligne :
{$DEFINE SGC_RESOURCES} { RESOURCES }et commentez l'accolade :
{.$DEFINE SGC_RESOURCES} { RESOURCES }Reconstruisez ensuite les paquets runtime / design-time ainsi que votre application. Allez dans Project > Build All Projects dans l'IDE, ou lancez votre script de build habituel.
Mesurer le gain
Si vous voulez confirmer le gain sur votre propre projet, générez un fichier map détaillé du linker avant et après le changement. Après la reconstruction, ouvrez le fichier *.map généré et faites défiler jusqu'à la section des ressources — sgcResources.RES devrait avoir disparu. La taille du module .text pour sgcWebSocket_Protocol_Base_Server diminue elle aussi légèrement, car le code utilitaire qui charge la ressource est éliminé en tant que code mort.
Le gain exact dépend de votre configuration de build et de l'édition de sgcWebSockets utilisée, mais sur un build client uniquement typique, l'EXE rétrécit sensiblement. Si vous combinez cette option avec les commutateurs existants au niveau de l'édition ({$UNDEF SGC_EDT_ENT} pour retirer WebAuthn / HTTP2 / OAuth-server, ou en remplaçant uses sgcWebSocket par uses sgcWebSocket_Client dans du code client uniquement), la réduction totale peut être substantielle.
Rétrocompatibilité
La valeur par défaut dans sgcVer.inc reste {$DEFINE SGC_RESOURCES}, donc les projets existants continuent à compiler et à fonctionner exactement comme avant. Le nouveau drapeau est strictement opt-out : rien ne change tant que vous ne désactivez pas explicitement la ressource, soit via la case à cocher de l'installeur, soit en éditant sgcVer.inc vous-même.
Si vous désactivez SGC_RESOURCES puis appelez une méthode serveur qui tente de servir le client JS embarqué (par exemple, un gestionnaire de réponse TsgcWSProtocol_JS_*), vous obtiendrez un EResNotFound propre — un signal évident que vous avez désactivé quelque chose dont vous aviez réellement besoin. Il suffit de réactiver le define et de reconstruire.
Disponibilité
La nouvelle option est livrée dans sgcWebSockets 2026.6, dans les installeurs de l'édition source uniquement (Standard, Professional et Enterprise). L'installeur Trial conserve la ressource embarquée afin que les démonstrations du client JS embarqué fonctionnent immédiatement.
Les clients disposant d'un abonnement actif peuvent récupérer le nouveau build depuis l'espace client. Des questions ou suggestions pour d'autres commutateurs de réduction de taille ? Contactez-nous — vous recevrez une réponse des personnes qui ont écrit le code.