Service Reference

Summary

Velox currently defines two Windows service executables in the Velox repository:

• VeloxService: the background execution service for scheduled flows, monitored folder flows, inbound transport monitoring, and outbound transport sending.
• VeloxAPIService: the background HTTP API service for REST/API flow endpoints.

Both services are Delphi TService applications. They share connection loading, setup loading, system logging, Windows Service Control Manager helper code, named IPC communication, module/action execution infrastructure, and shutdown waiting logic. The source code is the authority for this document; when behavior could not be proven from code, it is marked as unclear.

Related PKB Documents

• ARCHITECTURE.md
• DOMAIN_MODEL.md
• FEATURE_INVENTORY.md
• UI_INVENTORY.md
• MENU_REFERENCE.md
• DIALOG_REFERENCE.md
• MODULE_LIBRARY.md
• TECHNICAL_DEBT.md
• Configuration Reference

Source Code Locations

Area	Source
Velox service process bootstrap	VeloxService.dpr
Velox service worker	VeloxService/classMain.pas
API service process bootstrap	VeloxAPIService.dpr
API service worker	VeloxAPIService/classMain.pas
API WebBroker module	VeloxAPIService/vxWebModule.pas
Service manager facade used by Designer	Classes/GUI/vxManagerService.pas
IPC client and message constants	Classes/Tools/vxIPC.pas
Windows SCM helper functions	Classes/Tools/vxService.pas
Setup/configuration object	Classes/vxSetup.pas
Shared execution manager base	Classes/Service/vxManagerExecution.pas
Scheduled flow manager	Classes/Service/vxManagerScheduler.pas
Folder monitor manager	Classes/Service/vxManagerMonitor.pas
Inbound transport manager	Classes/Service/vxManagerTransportIn.pas
Outbound transport manager	Classes/Service/vxManagerTransportOut.pas
API endpoint manager	Classes/Service/vxManagerREST.pas
Runtime action threads	Classes/Service/vxActionThread.pas
Stop-wait thread	Classes/Tools/vxStopWaitThread.pas
Event logger	Classes/Tools/vxEventLogger.pas
System log classes/functions	Classes/vxModule.pas
General Setup service UI	Forms/frmSetupGeneral.pas
Service account dialog	Forms/frmServicePassword.pas
View Processes UI	Forms/frmViewProcesses.pas
Main service menu actions	Forms/frmMain.pas

Important Classes

Class	Purpose
TVeloxWorker	TService implementation for VeloxService. Owns schedule, monitor, inbound transport, outbound transport, IPC, and service lifecycle handling.
TVeloxAPIWorker	TService implementation for VeloxAPIService. Owns the REST manager, HTTP bridge, IPC, and service lifecycle handling.
TvxManagerService	Designer-side facade for service discovery, install/uninstall, start/stop/restart, and IPC calls.
TvxIPC	Cromis IPC wrapper used by Designer to send named requests to the running services.
TvxScheduleManager	Loads and manages scheduled flow execution items.
TvxMonitorManager	Loads monitored folder flows and queues detected files for execution.
TvxTransportManagerIn	Loads inbound transport monitor actions.
TvxTransportManagerOut	Polls and sends outbound transport queue work.
TvxRESTManager	Loads API endpoint actions and dispatches HTTP requests to REST execution items.
TActionThread and subclasses	Runtime flow execution threads for manual, scheduled, monitored, transport, and REST work.
TvxStopWaitThread	Waits for waiting/running execution threads during disable and shutdown paths.
TvxSetup	General Setup module containing service, API, transport, logging, and shutdown settings.

Important Forms

Form	Purpose
TSetupGeneral (Forms/frmSetupGeneral.pas)	General Setup editor. Provides service/API service install, uninstall, start, stop, service user authorization, API settings, shutdown wait, transport attempt interval, and debug memory dump controls.
TvxServicePassword (Forms/frmServicePassword.pas)	Collects and validates the Windows account/password used when installing services. It checks normal logon and attempts to grant/check "Log on as a service" rights.
TViewProcesses (Forms/frmViewProcesses.pas)	Displays flow runtime status by querying VeloxService over IPC; can refresh status and request task termination.
TMain (Forms/frmMain.pas)	Main Designer form containing service menu actions for enabling/disabling the runtime service and starting/stopping/restarting service executables.

Service Inventory

Windows service	Executable	Worker class	Service name pattern	Primary runtime responsibility
VeloxService	VeloxService.exe	TVeloxWorker	VeloxService$<service id>	Executes configured non-API background work: schedules, file monitors, inbound transport monitors, and outbound transport sends.
VeloxAPIService	VeloxAPIService.exe	TVeloxAPIWorker	VeloxAPIService$<service id>	Hosts configured REST/API flow endpoints through a WebBroker/Indy HTTP bridge.

VX_SERVICENAME, VX_APISERVICENAME, EXE_VELOXSERVICE, and EXE_VELOXAPISERVICE are defined in Classes/Tools/vxConstant.pas.

The service id is based on the active system connection. Designer installation code uses gSystemConnection.KeyService; the worker classes reconstruct the real service name from -c=<ConfigKey> plus the test-mode suffix when -test is present. Test mode adds :Test to the service name suffix and : TEST to the display name in worker helper methods.

Shared Service Architecture

Both services follow this shared pattern:

1. Process bootstrap configures FastMM/madExcept and marks the process as server/background.
2. The process loads the system connection using the -c parameter.
3. Test mode is enabled if -test is present.
4. A system log is created.
5. The service worker form is created and the TServiceApplication run loop starts.
6. ServiceCreate validates required command-line data and sets service names.
7. ServiceStart initializes COM, creates the IPC server, loads TvxSetup, and writes the initial system log.
8. ServiceExecute creates runtime managers, synchronizes enabled work, then blocks in ServiceThread.ProcessRequests(True) until the service is stopped.
9. Shutdown happens in ServiceExecute finally blocks, not in ServiceStopShutdown, so resources created in ServiceStart/ServiceExecute are released after the service request loop exits.

Installation and SCM Control

Designer installs services through TvxManagerService.InstallService and InstallAPIService in Classes/GUI/vxManagerService.pas. These methods call ServiceRegister in Classes/Tools/vxService.pas, which creates a SERVICE_WIN32_OWN_PROCESS service using:

• SERVICE_AUTO_START
• SERVICE_ERROR_NORMAL
• supplied binary path
• supplied service name
• supplied display name
• supplied service account and password

The install path prompts for account credentials through TvxServicePassword. That dialog validates the password with LogonUser, checks/attempts "Log on as a service" rights, and only returns success if those checks pass.

Designer also grants authorized service users SERVICE_START, SERVICE_STOP, and SERVICE_QUERY_STATUS access through GrantServiceUserRights. These authorized users are stored in TvxSetup.ServiceUsers.

The service worker classes also implement ServiceBeforeInstall/ServiceAfterInstall and ServiceBeforeUninstall/ServiceAfterUninstall, using -u and -p command-line parameters for account/password. The current Designer install code uses ServiceRegister directly; it is unclear from the inspected code whether the TService install event path is used by any current workflow.

Designer starts and stops services through:

• ServiceStart / ServiceStop in Classes/Tools/vxService.pas
• StartService, StopService, RestartService, StartAPIService, StopAPIService, RestartAPIService in TvxManagerService

ServiceStart and ServiceStop poll QueryServiceStatusEx until the service reports SERVICE_RUNNING or SERVICE_STOPPED, or until the default timeout of 30 seconds is exceeded.

The 30-second Designer/SCM helper timeout is separate from the service's internal shutdown wait. The service itself can continue reporting csStopPending while TvxStopWaitThread waits up to gSetup.MaxWaitBeforeTermination for waiting/running execution threads.

Command-Line Parameters

Parameter	Used by	Purpose
-c	Both services	Required configuration key used by gSystemConnection.Load and worker service-name construction. If missing, worker startup logs an error and ServiceCreate fails.
-n	Both services	Required unique display name used in the Windows service display name. If missing, the worker logs an error.
-test	Both services	Optional flag. Switches the system connection to test mode and changes service/display name suffixes.
-u	Worker install event path	Service account name used by ServiceBeforeInstall. Current Designer install path supplies the account directly to CreateServiceW.
-p	Worker install event path	Service account password used by ServiceBeforeInstall. Current Designer install path supplies the password directly to CreateServiceW.

VeloxService

Purpose

VeloxService is the primary background processing service for non-API Velox runtime work. It loads active configured flows and transports from the configuration database and keeps the runtime managers alive while the Windows service is running.

Startup

Startup details from code:

• VeloxService.dpr sets IsDesigner=False, IsServer=True, IsBackground=True.
• VeloxService.dpr sets MESettings.BugReportFile to AppDataLogPath + 'VeloxServiceBugReport.txt'.
• VeloxService.dpr sets the FastMM report file to AppDataLogPath + 'VeloxServiceFastMMReport.txt'.
• gSystemConnection.Load(GetParamVal('c', True)) must succeed before the worker is created.
• ServiceCreate sets AllowPause := False, requires a config key, builds RealServiceName, DisplayName, and StartupParams.
• ServiceStart calls CoInitializeEx(nil, COINIT_MULTITHREADED).
• ServiceStart creates a TIPCServer named IPC_SERVERNAME + ConfigKey + GetTestModeSuffix, where IPC_SERVERNAME is VeloxService.
• ServiceStart loads gSetup := TvxSetup.CreateAndLoad(nil).
• ServiceStart sets the SCM Started flag from gSetup.ModuleLoaded.
• ServiceExecute loads variable groups, creates runtime managers, synchronizes enabled work, saves the system log, and enters ServiceThread.ProcessRequests(True).

If gSetup.ServiceState = vssDisabled, ServiceExecute logs that the service is disabled and does not load actions.

Runtime Managers

Manager	Purpose	Startup behavior
TvxScheduleManager	Loads scheduled flows and starts timers for scheduled execution.	Synchronise is called during ServiceExecute; errors are logged as scheduled action load warnings.
TvxMonitorManager	Loads file monitor flows, creates directory watches, and queues files.	Synchronise is called during ServiceExecute; errors are logged as file monitor load warnings.
TvxTransportManagerIn	Loads inbound transport monitoring work.	Synchronise is called during ServiceExecute; errors are logged as transport in monitor load warnings.
TvxTransportManagerOut	Loads outbound transport send work and polls queue work.	Synchronise is called during ServiceExecute; errors are logged as outbound transport load warnings.

Scheduling

TvxScheduleManager creates TvxScheduleItem instances for configured scheduled actions. TvxCustomScheduleItem owns a start timer and repeat timer (TvxTimer) and calculates next run intervals. Timer callbacks run on timer threads and explicitly lock before mutating schedule state.

Each scheduled execution creates a TScheduleActionThread. A FThreadBlowSemaphore allows only a small number of pending schedule execution threads, protecting against very fast schedule events creating too many waiting threads.

File Monitoring

TvxMonitorManager creates TvxMonitorItem instances. Each monitor:

• resolves the target directory from its configured file connection,
• creates the directory if it is missing and can be created,
• starts a TvxMonitorFileQueue thread,
• processes existing files,
• creates a TDirectoryWatch using threaded notifications,
• watches only file-name changes for added files,
• queues detected files for TMonitorActionThread execution.

Pending files can be returned over IPC as a pipe-separated string in IPCRESPONSE_PENDINGFILES.

Transport Runtime

Inbound transport monitoring is handled by TvxTransportManagerIn and associated TTransportInActionThread execution.

Outbound transport sending is handled by TvxTransportManagerOut. It owns a repeat timer whose interval is gSetup.TransportAttemptInterval * 1000. The default setup value is 20 seconds. The repeat timer pauses while it checks outbound transports and resumes afterward.

TvxTransportItemOut uses queue/thread logic and semaphores around outbound execution. Comments in the code explicitly avoid some locks during disable paths to prevent deadlocks with execution semaphores.

IPC Communication

VeloxService handles these IPC actions in TVeloxWorker.OnIPCExecuteRequest:

IPC action	Behavior
ActionStatus	Returns schedule or monitor status, last run time, next run time, and monitor pending files. If ServiceState is disabled, status is forced to fstServiceDisabled.
ChangeAction	Resynchronizes a schedule/monitor flow or outbound transport. Monitor flow changes also resynchronize inbound transport actions.
EnableAction	Same resync behavior as change, with audit text indicating enable.
DisableAction	Disables a schedule/monitor flow or outbound transport. Monitor disable also disables inbound transport action.
EnableService	Sets the service runtime setup state to enabled and synchronizes all managers.
DisableService	Sets the service runtime setup state to disabled, disables all managers, waits for executing threads, and frees execution items.
RequestTaskCount	Returns schedule, file monitor, transport in, transport out, and REST counts. REST count is always 0 in VeloxService.
EndTask	Requests a schedule or monitor task to end. The manager implementations determine actual behavior.
DBConDetails	Returns SQL connection pool details.
SysConDetails	Returns system connection pool details.
MemoryDump	Returns a madExcept bug report string.

ChangeAction and EnableAction call CoInitializeEx/CoUninitialize around module loading because they may load action modules in the IPC request thread.

Shutdown

ServiceStop and ServiceShutdown call ServiceStopShutdown, which logs whether stop was user initiated or caused by computer shutdown. Code comments state that resource destruction should not occur there.

Actual cleanup happens in ServiceExecute after ServiceThread.ProcessRequests(True) returns:

1. Optionally write VeloxServiceShutdownMemoryDump.txt if gSetup.ShutdownMemDump is enabled.
2. Disable schedule, inbound transport, monitor, and outbound transport managers.
3. Terminate waiting monitor threads through gWaitingMonitor.TerminateThreads.
4. Create TvxStopWaitThread(gSetup.MaxWaitBeforeTermination) and keep reporting csStopPending while waiting.
5. Free transport, monitor, and schedule managers.
6. Save the system log before freeing connections.
7. Free action pool actions.
8. Free SQL connection pool connections.
9. Free the IPC server.
10. Free loaded modules.
11. Finalize and free the system log.
12. Free setup and system connection pool connections.
13. Call CoUninitialize.

The default MaxWaitBeforeTermination is 3600 seconds.

Pause and Continue

ServiceCreate sets AllowPause := False. ServicePause and ServiceContinue set their output flags to True, but there is no code in these handlers that pauses or resumes managers. Operational pause/resume behavior is therefore unclear from the code and should not be treated as a supported runtime control.

VeloxAPIService

Purpose

VeloxAPIService hosts configured REST/API flow endpoints. It loads API flow definitions into TvxRESTManager, starts an Indy TIdHTTPWebBrokerBridge, and dispatches each request through TRESTModule to the REST manager.

Startup

Startup details from code:

• VeloxAPIService.dpr sets IsDesigner=False, IsServer=True, IsBackground=True, and IsMultiThread=True.
• VeloxAPIService.dpr sets MESettings.BugReportFile to AppDataLogPath + 'VeloxAPIServiceBugReport.txt'.
• VeloxAPIService.dpr sets the FastMM report file to AppDataLogPath + 'VeloxAPIServiceFastMMReport.txt'.
• gSystemConnection.Load(GetParamVal('c', True)) must succeed before the worker is created.
• ServiceCreate sets AllowPause := False, requires a config key, builds RealServiceName, DisplayName, and StartupParams.
• ServiceStart initializes COM, starts an IPC server named IPC_WEBSERVERNAME + ConfigKey + GetTestModeSuffix, and loads TvxSetup.
• CheckPort currently returns True unconditionally; the source contains commented-out test-server code. Therefore startup does not currently prove that the HTTP port is available until the web bridge is activated.
• ServiceExecute calls RegisterWebModule, loads variable groups, creates gRESTManager, creates FWebServer, synchronizes API actions when enabled, sets FWebServer.DefaultPort, and activates the web server.

If gSetup.ServiceState = vssDisabled, API actions are not loaded.

Web Request Dispatch

VeloxAPIService/vxWebModule.pas registers TRESTModule as the WebBroker module class. RegisterWebModule sets:

• WebRequestHandler.WebModuleClass := RESTModuleClass
• WebRequestHandler.CacheConnections := True
• WebRequestHandler.MaxConnections := 0

TRESTModule.WebModuleBeforeDispatch handles every request before WebBroker action matching. It:

1. sets Handled := True,
2. calls CoInitializeEx(nil, COINIT_MULTITHREADED),
3. calls gRESTManager.ExecuteAPIForEndpoint(Request, Response),
4. calls CoUninitialize.

TvxRESTManager keeps a dictionary of endpoint strings to TvxRESTItem instances. TvxRESTItem.WebActionHandler supports GET and POST method types in the inspected code. GET and POST each create a TRESTActionThread, start it, and wait up to five minutes for completion. Timeout and exception paths set HTTP status and reason text.

API Service Configuration

Relevant TvxSetup settings:

Setting	Default	Observed use
VeloxAPIDomain	localhost	Used when building API URLs and by TvxRESTManager for endpoint URL construction.
VeloxAPIPort	8359	Used by TVeloxAPIWorker.GetVeloxAPIPort; 0 also falls back to 8359. Set as FWebServer.DefaultPort.
VeloxAPIEnableSSL	True	Used by TvxSetup.GetVeloxAPIUrl and General Setup UI. No service startup code was found that applies SSL settings to TIdHTTPWebBrokerBridge.
VeloxAPICertificate	empty string	Editable in General Setup. No service startup code was found that loads this certificate into the HTTP server.

It is unclear from the inspected code whether VeloxAPIService actually serves HTTPS. The source proves that HTTPS can be represented in generated URLs when VeloxAPIEnableSSL=True; it does not prove that server-side SSL binding is configured.

IPC Communication

VeloxAPIService handles a smaller IPC surface in TVeloxAPIWorker.OnIPCExecuteRequest:

IPC action	Behavior
RequestTaskCount	Returns REST count from gRESTManager.RESTItemCount; other counts are 0.
ChangeAction	Reads ModuleType and returns status True, but no visible REST manager resync is performed in the inspected handler.
EnableService	Empty handler body in inspected code.
DisableService	Empty handler body in inspected code.
EnableAction	Empty handler body in inspected code.
DisableAction	Empty handler body in inspected code.
Any other action	Returns status False.

This means the Designer-side generic IPC facade exposes methods for both services, but the API service currently implements only task count meaningfully in the inspected code. Runtime API endpoint refresh behavior after configuration changes is unclear; source evidence suggests restart may be required for changed API endpoints unless another path updates gRESTManager.

Shutdown

ServiceStop and ServiceShutdown log stop reason through ServiceStopShutdown. Actual cleanup happens in ServiceExecute after the service request loop returns:

1. Disable gRESTManager.
2. Stop the web server by setting FWebServer.Active := False and clearing bindings.
3. Free WebBroker modules with FreeWebModules.
4. Wait for executing threads with TvxStopWaitThread(gSetup.MaxWaitBeforeTermination), reporting csStopPending.
5. Free the web server.
6. Free the REST manager.
7. Save the system log before freeing connections.
8. Free action pool actions.
9. Free SQL connection pool connections.
10. Free the IPC server.
11. Free loaded modules.
12. Finalize and free the system log.
13. Free setup and system connection pool connections.
14. Call CoUninitialize.

Pause and Continue

As with VeloxService, AllowPause := False is set and the pause/continue handlers only set their output flags. No API manager or web server pause/resume behavior is implemented in those handlers.

Shared Configuration

Configuration	Source	Impact
Connection key	-c command-line parameter, loaded by gSystemConnection.Load	Selects the Velox system connection/configuration database for the service instance.
Test mode	-test command-line parameter	Switches connection mode and changes service/display name suffixes.
Service enabled/disabled	TvxSetup.ServiceState	Controls whether service managers/API actions load. Designer persists user changes. VeloxService also updates its in-memory setup copy when handling enable/disable IPC; the inspected API service enable/disable IPC handlers are empty.
Service users	TvxSetup.ServiceUsers plus Windows service ACL	Controls which non-elevated users can start/stop/query services from Designer.
Shutdown wait	TvxSetup.MaxWaitBeforeTermination, default 3600 seconds	Maximum wait used by TvxStopWaitThread during shutdown.
Shutdown memory dump	TvxSetup.ShutdownMemDump, default False	When enabled, VeloxService writes VeloxServiceShutdownMemoryDump.txt during shutdown. No equivalent API-service shutdown dump path was found.
Transport attempt interval	TvxSetup.TransportAttemptInterval, default 20 seconds	Sets outbound transport polling timer interval.
API domain/port/SSL/certificate	TvxSetup.VeloxAPIDomain, VeloxAPIPort, VeloxAPIEnableSSL, VeloxAPICertificate	Used by API URL generation; port is used by API service binding. SSL/certificate server binding is unclear from code.
App data folder	CUSTOMAPPDATASETTING, DEFAULTAPPDATAFOLDER, path helpers in vxConfigPath.pas	Determines log/report/config file locations such as AppDataLogPath.

Communication Between Components

IPC uses Cromis named IPC. The server names are:

• VeloxService + config key + optional test suffix
• VeloxAPIService + config key + optional test suffix

The IPC timeout is 3000 milliseconds.

Designer checks that a service is installed and started before most IPC calls. If a service is not started, many TvxManagerService methods return success for enable/disable/change operations because there is no running process to update.

Monitoring

Monitoring exists at several levels:

• Windows SCM status is queried through ServiceGetStatus, ServiceInStartState, ServiceStarted, ServiceStopped, and related functions in vxService.pas.
• Designer checks service counts through IPCACTION_REQUESTTASKCOUNT.
• TViewProcesses queries individual schedule/monitor action status through IPCACTION_ACTIONSTATUS.
• Monitor pending file names are returned through IPC and displayed as action details.
• The General Setup debug action can request a VeloxService memory dump through IPCACTION_MEMORYDUMP.
• System/database connection pool details can be requested through IPCACTION_DBCONDETAILS and IPCACTION_SYSCONDETAILS.

TViewProcesses currently queries VeloxService flow statuses. It does not call the API service for REST endpoint status in the inspected code.

Logging

Both services write to multiple logging channels:

• Windows Event Log through gEventLogger (Classes/Tools/vxEventLogger.pas).
• Velox system log through gSystemLog (Classes/vxModule.pas).
• madExcept bug report files:
  • VeloxServiceBugReport.txt
  • VeloxAPIServiceBugReport.txt
• FastMM report files:
  • VeloxServiceFastMMReport.txt
  • VeloxAPIServiceFastMMReport.txt
• Optional VeloxServiceShutdownMemoryDump.txt when gSetup.ShutdownMemDump=True.
• Optional VeloxServiceMemoryDump.txt when the General Setup debug action requests a dump from the running service.

TvxEventLogger.LogMessage also writes to gSystemLog when a system log is assigned, mapping event log error/warning/information to system-log message levels.

The code contains LogAPIServiceRequest support writing APIServiceRequests.txt, but most direct calls in the API service/REST manager are commented in the inspected files. It is unclear whether API request file logging is active in current builds.

Recovery

Internal Recovery and Cleanup

Both services have defensive shutdown paths:

• Manager disable/free operations are wrapped in exception handlers.
• Waiting and executing threads are given time to finish through TvxStopWaitThread.
• The service reports csStopPending while waiting.
• SQL/system connection pools are explicitly released.
• madExcept handles background exceptions.
• FastMM reports are configured per service executable.

TvxStopWaitThread waits first for gWaitingMonitor threads and then for gExecutionMonitor threads in two-second increments until all are finished or MaxWaitBeforeTermination is reached.

Windows Service Recovery Policy

No code was found in the inspected repository that calls ChangeServiceConfig2, sets SERVICE_CONFIG_FAILURE_ACTIONS, or configures Windows Service Recovery tab actions. ServiceRegister creates services with SERVICE_AUTO_START and SERVICE_ERROR_NORMAL, but does not configure automatic restart after failure.

Therefore, automatic Windows recovery behavior is unclear from the Velox code. If deployments rely on "restart service on failure" or similar SCM recovery settings, those settings must be applied outside the inspected service registration code or by an installer/script not found here.

Startup Failure Handling

VeloxService can fail startup if:

• -c is missing,
• gSystemConnection.Load fails,
• TvxSetup.CreateAndLoad does not load successfully,
• an unexpected exception occurs while connecting to the configuration database.

VeloxAPIService can fail startup for the same connection/setup cases and also if activating the web server throws an exception. The CheckPort method currently returns True, so it does not currently prevent startup on an occupied port before activation.

Runtime Reload Limitations

VeloxService has meaningful IPC handlers for changing/enabling/disabling scheduled, monitored, inbound transport, and outbound transport work.

VeloxAPIService does not visibly implement enable/disable/change action resynchronization in its IPC handler. API endpoint runtime reload behavior is therefore unclear from the code and should be treated as a potential restart-required area until proven otherwise.

Dependency Graph

High-Level Data Flow

For VeloxService, triggers are timer events, directory-watch notifications, inbound transport monitor work, and outbound transport polling. For VeloxAPIService, triggers are HTTP GET/POST requests routed by endpoint.

Open Questions

• Is the TService install event path with -u and -p still used anywhere, or is Designer's direct ServiceRegister path the only supported install path?
• Are Windows Service Recovery tab settings applied by an external installer or deployment script? No recovery-action configuration was found in the Velox service registration code.
• Is VeloxAPIService intended to serve HTTPS directly? Setup contains SSL/certificate fields and URL generation supports HTTPS, but the inspected service startup code does not bind SSL/certificate settings to the Indy HTTP bridge.
• Should VeloxAPIService support runtime IPC reload/enable/disable of API actions? The IPC constants and Designer facade exist, but the API service handler bodies are empty or no-op for most action-control commands.
• Should service pause/continue be disabled completely, or should these handlers implement manager pause/resume? The worker classes set AllowPause=False, and the handlers do not affect runtime managers.