Re: [twsocket] Request for better Delphi version detection

2010-09-06 Thread Angus Robertson - Magenta Systems Ltd
If nothing else: If no VER defines are detected, then assume the latest. Which, in this particular case, would be VER210. Impossible, new Delphi releases are often breaking, it took months of effort to support Delphi 2009 and even Delphi XE needed changes in ICS. Using old components on

Re: [twsocket] Request for better Delphi version detection

2010-09-06 Thread Jon Robertson
On Mon, Sep 6, 2010 at 2:02 AM, Angus Robertson - Magenta Systems Ltd an...@magsys.co.uk wrote: Using old components on newer Delphi releases is always risky, and totally unnecessary with ICS since the XE version was available on the day of release of XE on both the ICS web site, CodeCentral

Re: [twsocket] Request for better Delphi version detection

2010-09-06 Thread Angus Robertson - Magenta Systems Ltd
My suggestion is largely based on a goal that I set for myself during the time that Delphi XE was being developed. The current overhead in maintaining the include file seems excessive, at best. It takes maybe 30 seconds to add a new version of Delphi to the include file, another minute to

Re: [twsocket] Request for better Delphi version detection

2010-09-06 Thread Jon Robertson
Please, please stop assuming that I'm trying to achieve some kind of magical hey, it works! trick out of a magician's hat. I already replied to DZ-Jay's concern about automatically supporting new versions. Just as there is a lowest version check, there can be a highest version check too. If

Re: [twsocket] Request for better Delphi version detection

2010-09-06 Thread Angus Robertson - Magenta Systems Ltd
But my suggestion has absolutely *nothing* to do with enabling ICS users to magically be able able to use ICS with future versions of Delphi. Wrong, that is exactly what you said in the root message, that version checks should be ignored for unknown new compilers. So, when compiling this

Re: [twsocket] Request for better Delphi version detection

2010-09-06 Thread Anton S.
As for me, I counted current compilers.inc code not-optimal too so I redesigned it. Haven't tested it with .Net or Linux (these targets use quite different approach) but Windows versions seem working OK. Here's my version: // Compiler defines not specific to a particlular platform. // BDS

Re: [twsocket] Request for better Delphi version detection

2010-09-06 Thread Anton S.
In addition to previous message: Jon's suggestion with {$IF CompilerVersion = ##} looks pretty, and if the only thing preventing from using it is a new compiler versions, it could be easily solved by this code: {$IF CompilerVersion LastKnownAndTestedCompilerVersion} Error ( Sorry, I don't

Re: [twsocket] Request for better Delphi version detection

2010-09-06 Thread Francois PIETTE
Hello all ! I've followed the discussion from the start. In my opinion, it is not worth getting upset with that matter. -- francois.pie...@overbyte.be http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto

Re: [twsocket] Request for better Delphi version detection

2010-09-06 Thread Jon Robertson
On Mon, Sep 6, 2010 at 4:53 AM, Angus Robertson - Magenta Systems Ltd an...@magsys.co.uk wrote: But my suggestion has absolutely *nothing* to do with enabling ICS users to magically be able able to use ICS with future versions of Delphi. Wrong, that is exactly what you said in the root

Re: [twsocket] New DLL hijacking vulnerability KB 2269637

2010-09-06 Thread Zvone
const GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL'; This is not required since writable typed constants is enabled. That's all fine but I don't see it published as property anywhere. How do I modify its value during runtime to set full path for SSLEAY32.DLL and LIBEAY32.DLL? -- To unsubscribe

Re: [twsocket] New DLL hijacking vulnerability KB 2269637

2010-09-06 Thread Francois PIETTE
const GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL'; This is not required since writable typed constants is enabled. That's all fine but I don't see it published as property anywhere. How do I modify its value during runtime to set full path for SSLEAY32.DLL and LIBEAY32.DLL? So simple: Just

Re: [twsocket] New DLL hijacking vulnerability KB 2269637

2010-09-06 Thread Arno Garrels
Zvone wrote: const GSSLEAY_DLL_Name : String = 'SSLEAY32.DLL'; This is not required since writable typed constants is enabled. That's all fine but I don't see it published as property anywhere. How do I modify its value during runtime to set full path for SSLEAY32.DLL and LIBEAY32.DLL?