Problem running delphi app on AMD64 chips

Hi, we have an app written in Delphi 5 that will not run (wont even start up) on some AMD64 chip machines running XP.
We have never had a problem with any other machine (Intel / AMD, or Operating system).
Some AMD machines that have displayed this problem have been fixed by applying a bios update, but other machines still have problems even after the bios update has been run.
I searched on Google and there are some issues with Windows XP Service Pack 2 and some new security feature re stack allocation etc, but found nothing pointing to any particular calls etc...I suspect this may be the cause, but I am not sure what calls need to be checked / changed to suit XP Sp2.

I am probably asking this question prematurely, as we are currently sourcing an AMD64 machine to try and work out why, but I was wondering if anybody else had experienced this?

Thanks
LVL 2
insomniac92Asked:
Who is Participating?
 
MadshiCommented:
Are you sure that DataRec.Data[Position] holds 4 bytes? There's definately no change in AMD64 chips about how they handle integer. If there would be such a change, no single program would run ok on AMD64, anymore. Also changeing sizeOf(Integer) to sizeOf(Double) is very bad, cause the Move would then write more bytes than iTemp can hold, which would overwrite parts of the stack.
0
 
BlackTigerXCommented:
does this happen only to Delphi applications?
0
 
insomniac92Author Commented:
It is only one particular Delphi app that we have this problem with. It is written in-house, and has been sold commercially for a couple of years with no problem. It is only the AMD64 chips (and only some of them) that seem to cause an issue.
0
Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

 
MadshiCommented:
My AMD64 is configured so that every application crashes which isn't properly written (boot.ini "/NoExecute=OptOut"). I've already noticed that BCB5 isn't properly written and needs to be listed in the OptOut settings. Delphi5 runs just fine, though. And also small D5 compiled exes run just fine on my PC.
0
 
insomniac92Author Commented:
Thanks, we now have an AMD64 machine. I've tried turning that switch to AlwaysOff, but the app still locks.
It is always after it has done a http call to one of our servers to retreive data, I am guessing it is about to write this data to the hdd, then the whole machine just freezes....no error, no keyboard, no mouse.. dead!
I could understand if this happened on all machines, but its only a few AMD 64's that have this same issue.
I guess (reluctantly) the next step is to install the dev environment on the test machine and debug it from there.

0
 
insomniac92Author Commented:
Ok, we have narrowed it down to this line of code.

Move(DataRec.Data[Position], iTemp, SizeOf(Integer));

If we change this to say sizeOf(Double) then it all works fine - we dont want to do this if possible as we would need to modify all of our existing data to store as double values rather than integers.
Running it on an Intel CPU works fine with SizeOf(Integer).
Something has changed in the way AMD64 chips handle integer data types.
We have checked the sizeof(integer) and it returns 4 bytes - on both the intel and AMD - as expected.
If we leave it as SizeOf(Integer) the AMD machine locks completely.

The declarations are below.

iTemp : integer;
Position : integer;

TPackedByteArray = packed array of byte;

TDataRecord = packed record
    NextRecord : integer;
    PreviousRecord : integer;
    dDateTime: TDateTime;
    Data : TPackedByteArray;
end;

Any ideas?
Thanks
0
 
insomniac92Author Commented:
okay problem fixed.
turns out to be a different line, but still moving memory with itemp and sizeof(integer).
we were initially populating itemp with trunc(some double value) to get just the whole integer value.
It turns out that trunc returns an int64, which is 8 bytes on a 64 bit machine, then we were trying to move this into a 4 byte integer.
We got rid of the trunc by using ceil instead.
Thanks for your help.



0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.