Not sure how the debug GUI exe works but I found a solution for the service:

In ...WndControl.pas,

 TIcsWndControlVersion  = 110;
CopyRight : String = ' TIcsWndControl (c) 2002-2008 F. Piette V1.10 ';

 WH_MAX_MSG                   = 400; <== MODIFIED THIS from 100

so that it would create less windows per same number of messages. With this
change, My also ICS stress tester can open > 15k connections concurrently.
In a real life case, since there will not be a stress tester on the same
machine, I think it is ok. This must be a non-paged RAM drought issue...

Could you make WH_MAX_MSG a property so that each time users update ICS,
they would not need to change ICS source?

It is likely that Windows has different settings for a service application and a GUI application. Since a GUI application is likely to use a lot of windows (visible or not), probably Windows size his internal tables accordingly. A GUI application has a default 10.000 handles allowed. This is why I created TIcsWndControl in the first place. This allow to open more concurrent sockets since with TIcsWndControl a single window handle a lot of sockets (100 by default) and you don't run out of handle anymore.

This article could be a starting point for you:
And also this one:

The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)

To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to