?
Solved

Problem running delphi app on AMD64 chips

Posted on 2005-04-15
7
Medium Priority
?
173 Views
Last Modified: 2010-04-05
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
0
Comment
Question by:insomniac92
  • 4
  • 2
7 Comments
 
LVL 13

Expert Comment

by:BlackTigerX
ID: 13798766
does this happen only to Delphi applications?
0
 
LVL 2

Author Comment

by:insomniac92
ID: 13799268
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
 
LVL 20

Expert Comment

by:Madshi
ID: 13800369
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
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 2

Author Comment

by:insomniac92
ID: 13811008
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
 
LVL 2

Author Comment

by:insomniac92
ID: 13874023
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
 
LVL 20

Accepted Solution

by:
Madshi earned 500 total points
ID: 13874125
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
 
LVL 2

Author Comment

by:insomniac92
ID: 13923620
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

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

A lot of questions regard threads in Delphi.   One of the more specific questions is how to show progress of the thread.   Updating a progressbar from inside a thread is a mistake. A solution to this would be to send a synchronized message to the…
Introduction The parallel port is a very commonly known port, it was widely used to connect a printer to the PC, if you look at the back of your computer, for those who don't have newer computers, there will be a port with 25 pins and a small print…
This Micro Tutorial will teach you how to add a cinematic look to any film or video out there. There are very few simple steps that you will follow to do so. This will be demonstrated using Adobe Premiere Pro CS6.
This video shows how to quickly and easily deploy an email signature for all users in Office 365 and prevent it from being added to replies and forwards. (the resulting signature is applied on the server level in Exchange Online) The email signat…
Suggested Courses

862 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question