Re: [twsocket] Request for better Delphi version detection
> 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 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 and the companion DVD. A lot of effort is spent testing ICS on each new Delphi release, for very good reason. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Request for better Delphi version detection
On Mon, Sep 6, 2010 at 2:02 AM, Angus Robertson - Magenta Systems Ltd 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 and the > companion DVD. And a huge thanks to Francois and the rest of the ICS team for that. 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. > A lot of effort is spent testing ICS on each new Delphi release, for very > good reason. *sigh* When in the world did I ever suggest that there was no need to test against new releases of Delphi? I'm simply looking for an easier migration during the, uh, testing process. But alas, I've got my include file the way I want it. I'll just be sure to keep a copy so I don't lose it when I update my ICS source. Jon -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Request for better Delphi version detection
> 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 update SVN and the release is automatically zipped onto the web site, so not exactly excessive effort. It takes a lot longer to add new packages for new Delphi releases and test all the demos, project files cause us massive problems (and other vendors) since they keep changing as well and are not backward compatible to Delphi 2007 and with C++ Builder. Arno Garrels needs to thanked for all these changes. Many ICS users are using old releases, some ancient releases, and will lots of unexplained errors if they try to use them with Delphi 2009 and later. Delphi XE has turned out to be a straight forward update, but remember that Embarcadero road maps show OS-X, Linux and 64-bit support being added to Delphi and you will see a lot of preparatory work in the Delphi XE runtimes like the LINUX and MACOS conditions, and those changes all have major implications for ICS. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Request for better Delphi version detection
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 there are reasons that the VER defines are a better solution than
CompilerVersion, then please share them. I'd love to know what they
are.
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. My suggestion is only related to the amount of code added to
the include file to recognize a new version.
> It takes maybe 30 seconds to add a new version of Delphi to the include
> file,
and 53 lines. The approach I suggested only requires 16 lines. Is 53
lines of code more efficient than 16? Am I missing something here?
> Arno Garrels needs to thanked for all these changes.
Thank you Arno. Seriously, thanks to the whole team. I've been a
happy ICS user for 14 years. My intent was to provide a suggestion
that could save time maintaining the include file in the future. For
both the ICS team and for my own selfish needs. ;)
> Many ICS users are using old releases, some ancient releases, and will
> lots of unexplained errors if they try to use them with Delphi 2009 and
> later.
>
> Delphi XE has turned out to be a straight forward update, but remember
{snip}
You're preaching to the choir. You're arguing with a brick wall.
Please stop now.
Thanks.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] Request for better Delphi version detection
> 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 code for Delphi XE, the code assumes that the > compiler/VCL is compatible with Delphi 2010. In general, a fairly > safe assumption. Your suggestion to shorten the include file with CompilerVersion >= 22.0 has exactly the same problem. I believe you will also find that expressions were not allowed in conditionals for many early Delphi releases, so your code is not backward compatible. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Request for better Delphi version detection
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 2010 (BDS 7.0)
{$ifdef VER210}
{$define COMPILER_13}
{$define COMPILER_13_UP}
{$endif}
// BDS 2009 (BDS 6.0)
{$ifdef VER200}
{$define COMPILER_12}
{$define COMPILER_12_UP}
{$endif}
// BDS 2007 (BDS 5.0)
{$ifdef VER190}
{$define COMPILER_11}
{$define COMPILER_11_UP}
{$endif}
// BDS 2006 (BDS 4.0)
{$ifdef VER180}
{$define COMPILER_10}
{$define COMPILER_10_UP}
{$endif}
// DELPHI 9
{$ifdef VER170}
{$define COMPILER_9}
{$define COMPILER_9_UP}
{$endif}
// DELPHI 8
{$ifdef VER160}
{$define COMPILER_8}
{$define COMPILER_8_UP}
{$endif}
// DELPHI 7
{$ifdef VER150}
{$define COMPILER_7}
{$define COMPILER_7_UP}
{$endif}
// DELPHI/CPPB 6
{$ifdef VER140}
{$define COMPILER_6}
{$define COMPILER_6_UP}
{$endif}
// DELPHI/CPPB 5
{$ifdef VER130}
{$define COMPILER_5}
{$define COMPILER_5_UP}
{$endif}
// CPPB 4
{$ifdef VER125}
{$define COMPILER_4}
{$define COMPILER_4_UP}
{$endif}
// DELPHI 4
{$ifdef VER120}
{$define COMPILER_4}
{$define COMPILER_4_UP}
{$endif}
// CPPB 3
{$ifdef VER110}
{$define COMPILER_3}
{$define COMPILER_3_UP}
{$endif}
// DELPHI 3
{$ifdef VER100}
{$define COMPILER_3}
{$define COMPILER_3_UP}
{$endif}
// CPPB 1
{$ifdef VER93}
{$define COMPILER_2} // C++ Builder v1 compiler is really v2
{$define COMPILER_2_UP}
{$endif}
// DELPHI 2
{$ifdef VER90}
{$define COMPILER_2}
{$define COMPILER_2_UP}
{$endif}
// DELPHI 1
{$ifdef VER80}
{$define COMPILER_1}
{$define COMPILER_1_UP}
{$endif}
{$else (not Windows)}
// Linux is the target
{$define QT_CLX}
// KYLIX 1/2
{$ifdef VER140}
{$define COMPILER_6}
{$define COMPILER_6_UP}
{$endif}
// KYLIX 3
{$ifdef VER150}
{$define COMPILER_7}
{$define COMPILER_7_UP}
{$endif}
{$endif Win32}
//
{$ifdef COMPILER_13_UP}
{$define COMPILER_12_UP}
{$endif}
{$ifdef COMPILER_12_UP}
{$define COMPILER_11_UP}
{$endif}
{$ifdef COMPILER_11_UP}
{$define COMPILER_10_UP}
{$endif}
{$ifdef COMPILER_10_UP}
{$define COMPILER_9_UP}
{$endif}
{$ifdef COMPILER_9_UP}
{$define COMPILER_8_UP}
{$endif}
{$ifdef COMPILER_8_UP}
{$define COMPILER_7_UP}
{$endif}
{$ifdef COMPILER_7_UP}
{$define COMPILER_6_UP}
{$endif}
{$ifdef COMPILER_6_UP}
{$define COMPILER_5_UP}
{$endif}
{$ifdef COMPILER_5_UP}
{$define COMPILER_4_UP}
{$endif}
{$ifdef COMPILER_4_UP}
{$define COMPILER_3_UP}
{$endif}
{$ifdef COMPILER_3_UP}
{$define COMPILER_2_UP}
{$endif}
{$ifdef COMPILER_2_UP}
{$define COMPILER_1_UP}
{$endif}
So when a new compiler is released all we need to add is just 4+3=7 lines of
copy-pasted code. Maybe this way would be more optimal than current one?
--
Anton
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] Request for better Delphi version detection
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 know this compiler version )
{$ENDIF}
--
Anton
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] Request for better Delphi version detection
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 http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Request for better Delphi version detection
On Mon, Sep 6, 2010 at 4:53 AM, Angus Robertson - Magenta Systems Ltd
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 message, that version
> checks should be ignored for unknown new compilers.
I never said that version checks *should* be ignored for new
compilers. I was complaining about the incorrect version detection,
because compiling my D2010 copy of ICS in Delphi XE stopped on the
line:
Bomb('This component requires Delphi 7 or later');
Since Delphi XE *is* later than Delphi 7, this bugs me. If the code
wants to stop on a line that says my version of Delphi is not
supported by ICS, that would be an accurate message.
I went on to describe alternative techniques for version detection,
including the technique used in Raize Components. That technique does
assume an "unknown" version of Delphi was compatible with the last
version "known" by the component's code. That technique was shot down
pretty quickly, and I was even insulted in the process. However, my
next suggestion was to add a "highest version" check, like the current
"lowest version" check, that would still prevent the ICS code from
compiling on unsupported versions of Delphi while providing an
accurate error message to the user.
My apologies for implying that I felt _ICS_ should "just compile" in
future versions of Delphi. That was not my intent, but I can see now
how my initial discussion implied that it was. My pet peeve, and the
reason for the post (re: subject line), was that the Delphi version
detection is inaccurate (refer to the error above) and requires adding
an excessive number of new lines to the include file to add new Delphi
versions to the detection mechanism.
> Your suggestion to shorten the include file with CompilerVersion >= 22.0
> has exactly the same problem.
My suggestion to use CompilerVersion >= 22.0 was to suggest a better
"highest version detected" method than an error that says "requires
Delphi 7 or later". What "exactly the same problem" are you referring
to?
> I believe you will also find that expressions were not allowed in
> conditionals for many early Delphi releases, so your code is not backward
> compatible.
Conditional Expressions were added in Delphi 6. ICS v7 only supports
Delphi 7 and above. Why can't ICS use CompilerVersion?
I believe the checks below would provide better, more accurate version
detection.
{$IFNDEF CONDITIONALEXPRESSIONS}
Bomb('This component requires Delphi 7 or later');
{$ENDIF}
{$IF CompilerVersion < 15.0}
Bomb('This component requires Delphi 7 or later');
{$IFEND}
{$IF CompilerVersion >= 22.0}
{$Message Fatal 'Your version of Delphi is not yet supported by ICS.'}
{$IFEND}
In addition, COMPILER7_UP would always be defined for newer versions
of the compiler, without adding additional code to the include file.
The last version check above would stop the compile if the user's
version was not supported. But why do the COMPILER??_UP, DELPHI??_UP,
and BCB??_UP constants have to be $DEFINED so many times in the
include file? It really shouldn't take 53 lines of new code to detect
a new version of the compiler.
Jon
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
>>> 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 or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
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 assign GSSLEAY_DLL_Name the value you need, before it is first used. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] New DLL hijacking vulnerability KB 2269637
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? The DLL names are globally writable typed constants, set their values before the OpenSSL libraries are loaded. OSSL is dynamically loaded at runtime, that is when the first OpenSSL function is called. In order to enforce a load call TSslContext.InitContext or set TSslDynamicLock/TSslStaticLock.Enabled to TRUE. I prefer this anyway since the load errors don't raise somewhere but where I can handle them easily: try GSSLEAY_DLL_Name := ; GLIBEAY_DLL_Name := ; MySslContext.InitContext; except // Something went wrong with loading OSSL, handle it. end; -- Arno Garrels -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
