Meanwhile Allen Bauer shared with us the information that the team works in parallel at 64bit as well as cross-platform.

It isn’t as nice as a proper 64 bit memory addressing solution, but will certainly improve things.

“Cannot enable SE_LOCK_MEMORY privilege, please check the local policy.”

After some research I’ve found that under Vista Home Premium (which I’m using) you can’t enable this privilege, because you can’t change the local policy. Hard to believe but apparently true – at least I couldn’t find any way to do it. If that’s the case, then I don’t think AWE can be used on this OS version.

I’ll try it on a Vista Business machine if I get the chance.

…hehehe… ~ 200. Much less than on the other questions where we had till 1350. Ken was right: many of them even didn’t bother to vote – sign that this problem generally speaking isn’t so stringent to the community. So, even if Embarcadero will put such a poll in Delphi’s welcome page I don’t think that the results will be different. Many of them will just not vote (due of the nature of the question) and, perhaps, some of them will be annoyed.

I think Embarcadero should launch such a poll from the welcome page in delphi – so at least all users of delphi 2005 and ahead would be noticed about such a poll. So it should be more representative, I guess.

But please: do what all serious inquiry companies do: mention the absolute size of of the probe!

Regards, Fritz

If you have lots of strings and don’t need Unicode then either stay on Delphi 2007 or earlier or go through your code and change all your “string” and “char” declarations to “ANSIString” and “ANSIChar”.

In the All-Unicode-or-Nothing default behaviour of Delphi 2009+, every string in your application will occupy more than DOUBLE the amount of memory that it would occupy in Delphi 2007.

MORE than double because in 2009+ there are additional payload descriptor fields in addition to each character occupying 2 bytes rather than 1. That additional descriptor data also applies to ANSIStrings, so *every* string in Delphi 2009+ occupies more memory, but ANSI strings will incur *only* the additional descriptor but the string data itself is the same size as in 2007 and earlier.

But I would caution against asking for a “quick” solution to 64-bit.

The approach to Unicode was arguably determined by a desire to get it out quick and to make it quick for people to migrate.

Both were a mistake imho and have resulted in a compromised implementation that suits nobody, least of all anyone that wishes to *correctly* implement Unicode support in a Delphi application and even less for anyone for whom Unicode was/is simply irrelevant to their needs.

Our DB architecture already has a caching layer on top of the file system database, and I could definitely create an L2 cache to store DB information in a more raw form…

Memory pressures aside, that might (or might not) make a compelling case all on its own.

I can’t say I have seen anyone discuss the topic yet (not that I follow it that extensively)

TRecB = record
R1: integer;
R3: integer;
R5: integer;
R7: integer;
R2: byte;
R4: byte;
R6: byte;
R8: byte;
end;

1. Yessss!!! Now!!! …but this doesn’t mean that real 64bit is canceled
2. No, need real 64bit
3. Neutral, do as you wish
4. Perhaps is better to focus your resources on cross-platform first
5. If the next release will have this only and cross-platform it will be ok.
6. Moderately favorable.
7. Totally against.
8. Other

http://blogs.msdn.com/larryosterman/archive/2004/04/19/116084.aspx

Objects are implemented as a pointer to a record structure. If you need lots of instances and your record is really, really small (in which case packed won’t make much of a difference either), then the three additional pointers (one for the object, one for the VMT and one for the monitor) will probably be a deal breaker. But if the record is quite sizeable, these are probably the least of your problems.