Page 1 of 2

Cannot compile madSecurity.pas in Delphi 2009

PostPosted: Wed Jul 29, 2009 9:38 am
by BenjyKid
Hi Mathias,

did you get my mails from Juli 12th, und July 19th (and July 29th)? I'm still waiting for an answer. I cannot compile madSecurity.pas in Delphi 2009. Could you please upload a madCollection with the correct madSecurity.pas that you use when compiling madCollection for D2009?

PostPosted: Thu Jul 30, 2009 10:28 am
by madshi
I don't seem to have received your emails. Strange. Try emailing to madshi (at) gmail (dot) com. madSecurity compiles fine in Delphi 2009 for me. The latest version is always available here:

What compilation error do you get?

PostPosted: Thu Jul 30, 2009 10:33 am
by BenjyKid
I'm getting [DCC Error] madSecurity.pas(3107): E2100 Data type too large: exceeds 2 GB

Code: Select all
type TAShareInfo50 = array [0..maxInt shr 6 - 1] of TShareInfo50;

I guess that is because TShareInfo50 is using char (instead of AnsiChar).

PostPosted: Fri Jul 31, 2009 7:09 am
by madshi
You're obviously using an old version of madSecurity.pas. The current version has TShareInfo50 defined with "AnsiChar". Please empty your browser cache and redownload madCollection.exe. I guess that your browser gave you an old version of that exe instead of downloading the correct one.

PostPosted: Fri Jul 31, 2009 7:52 am
by BenjyKid
Somehow I was afraid I was going to hear something like this. But, how do you explain that madTools.pas has osWin7 in included in TOsEnum? The digital signature of madCollection.exe is from Mittwoch, 22. Juli 2009 10:10:08. And as a precautios side-node: madSecurty.pas was created (not modified) on "Mittwoch, ‎29. ‎Juli ‎2009, ‏‎11:39:17" on my harddisk. So the file really must have come from the latest installer.

Are you sure that you're including the correct file in the setup? If it makes a difference, I bought the complete madCollection a while ago.

PostPosted: Mon Aug 03, 2009 6:46 am
by madshi
Thank you, you actually found a bug in my automated installer creation. The PAS file you got is outdated. But still, the DCU file should be correct. Why are you trying to recompile the PAS file? The madCollection installer sets up madCollection in such a way that the PAS files are never recompiled, instead the precompiled DCUs are used. So if you're using the default installation configuration of madCollection, Delphi should not try to recompile the PAS file for you. Have you changed the configuration?

PostPosted: Mon Aug 03, 2009 9:09 am
by BenjyKid
I needed to patch something in madtools.pas. So madsecurity needed to be recompiled. There is also another reason that I cannot post here.

PostPosted: Mon Aug 03, 2009 11:12 am
by madshi
The next build will contain the latest madSecurity source code.

PostPosted: Fri Sep 04, 2009 5:23 pm
by BenjyKid
Can I expect this version anytime soon? We need to compile this unit and our application with D2010 and the source code is not complete :-(

PostPosted: Fri Sep 04, 2009 5:39 pm
by madshi

There will soon be a new official version with 2010 support, though.

PostPosted: Fri Sep 04, 2009 5:59 pm
by BenjyKid
Thank you for the fast answer. But there is a new problem. This file has AnsiStrings almost everywhere. What happened? You could have upgraded it to Unicode with only minimal changes. Or was there a very mysterious reason that this file needed to be downgraded to ANSI?

PostPosted: Fri Sep 04, 2009 6:39 pm
by madshi
Converting everything to AnsiString was the quickest and safest way to make everything compile and work again without introducing all kinds of new bugs. madCollection uses loads of low level stuff and win32 APIs. Also win9x is still supported. Making sure that all this works fine with unicode strings would be a lot of work.

PostPosted: Sun Sep 06, 2009 7:41 pm
by iconic
No idea why Embarcadero didn't offer a codepage compiler directive switch to toggle between forcing unicode and ansi strings. Converting PChar to PAnsiChar, Char to AnsiChar and String to AnsiString is also what I had to do with my various projects when converting from Delphi 7. Since Delphi 2009 I am careful to suffix any Win32 API calls I make that have unicode counterparts with "A" when I need to use Ansi, otherwise the compiler interprets this as calling the unicode version. I really prefer Delphi 7 even to this day...


PostPosted: Tue Sep 15, 2009 5:31 pm
by madshi
iconic wrote:No idea why Embarcadero didn't offer a codepage compiler directive switch to toggle between forcing unicode and ansi strings.

Yeah, that would have made my life so much easier!

PostPosted: Tue Sep 15, 2009 6:38 pm
by BenjyKid
madshi wrote:Yeah, that would have made my life so much easier!

I might be reading this wrong, but wouldn't that have meant that lots of components would have worked only if this (global) switch was set to ANSI?

You do not need to support Win9x when UNICODE is defined, because Delphi 2009 applications won't run on Win9x.

For madsecurity.pas this means that all you would have needed to do is add a couple of {$IFNDEF UNICODE} windows 9x code {$ENDIF} and leave the rest of the file almost unchanged. And I'm almost sure that the WinNT Wide API functions work exactly like the ANSI functions. As a matter of fact, the exported ANSI functions are always wrappers around the Wide functions (there might be a few exceptions that confirm this rule). This might be different for undocumented stuff, but that seems to be relevant for Win9x only here.