frog
asked on
Delphi3 compiler options
I looked at part of my compiled application and found that it was not fully compiled.
Instead of an .exe consisting of only machine code there are bits of text of object parameters, procedure names, etc.
My guess is that instead of generating machine code for some objects it is just imbedding them as they are and jumping to them when required. It looks more like interpreted code instead of compiled code.
I've looked at 'all' the compiler options but I can't find anything that would produce this effect.
I suppose there's a 'fast compile' option that does this and then a 'full compile' option to produce the final code.
Can you please tell me which option(s) I need to set to produce fully compiled machine code.
Instead of an .exe consisting of only machine code there are bits of text of object parameters, procedure names, etc.
My guess is that instead of generating machine code for some objects it is just imbedding them as they are and jumping to them when required. It looks more like interpreted code instead of compiled code.
I've looked at 'all' the compiler options but I can't find anything that would produce this effect.
I suppose there's a 'fast compile' option that does this and then a 'full compile' option to produce the final code.
Can you please tell me which option(s) I need to set to produce fully compiled machine code.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
hi,
im wondering what you were expecting it to be ?
if you look at any exe with a hex editor you'll see strings ..dont worry it is very normal.
when you compile it doesnt turn abc into 110011 or xzy it just compiles to machine readable code.this is why you would never hardcode passwords/serial numbers etc into applications and pretty much why encryption is used as with encryption you can turn abc into zxy.
Regards Barry
im wondering what you were expecting it to be ?
if you look at any exe with a hex editor you'll see strings ..dont worry it is very normal.
when you compile it doesnt turn abc into 110011 or xzy it just compiles to machine readable code.this is why you would never hardcode passwords/serial numbers etc into applications and pretty much why encryption is used as with encryption you can turn abc into zxy.
Regards Barry
ASKER
Thanks for your comments.
Inthe, I was expecting to see the text for messageDlgs etc as text, but that was all.
I expected the rest to contain a contiguous stream of hex code that the processor would process. ( Stuff like 7E FE 61 DA that would cause the processor to load accumulator A from HL compare it with character 'a' etc, etc.)
I didn't expect to see anything that would give any visual clues as to what the code was doing. And I certainly did not expect to see text reference to say a button, but just the hex code to create the button, ie a heap of instructions to load accumulators, shift, compare etc, etc to finally draw the button.
I reckon Micke has answered my question by saying that Delphi uses resources embedded inside the 'compiled' .exe "to create the forms and data modules in run time."
Just why it would create them at run time and not at compile time only adds more questions. It must be awfully slow to create objects on the fly at run time, but I suppose it gives some flexibility.
This reminds me of a question that's been on my mind for a while - why don't the Delphi handbooks and help screens give the number of machine cycles for each instruction. I've only seen references like "inc(a) is faster than a := a+1" but there's no reference to how much faster, like "inc(a) = 4 machine cycles, a := a+1 = 27 cycles".
It sounds like it's all to do with Windows, is it that my exe isn't actually run directly by the processor, but that it tells Windows to draw a form and Windows then gets the processor to run code within Windows to draw it?
Inthe, I was expecting to see the text for messageDlgs etc as text, but that was all.
I expected the rest to contain a contiguous stream of hex code that the processor would process. ( Stuff like 7E FE 61 DA that would cause the processor to load accumulator A from HL compare it with character 'a' etc, etc.)
I didn't expect to see anything that would give any visual clues as to what the code was doing. And I certainly did not expect to see text reference to say a button, but just the hex code to create the button, ie a heap of instructions to load accumulators, shift, compare etc, etc to finally draw the button.
I reckon Micke has answered my question by saying that Delphi uses resources embedded inside the 'compiled' .exe "to create the forms and data modules in run time."
Just why it would create them at run time and not at compile time only adds more questions. It must be awfully slow to create objects on the fly at run time, but I suppose it gives some flexibility.
This reminds me of a question that's been on my mind for a while - why don't the Delphi handbooks and help screens give the number of machine cycles for each instruction. I've only seen references like "inc(a) is faster than a := a+1" but there's no reference to how much faster, like "inc(a) = 4 machine cycles, a := a+1 = 27 cycles".
It sounds like it's all to do with Windows, is it that my exe isn't actually run directly by the processor, but that it tells Windows to draw a form and Windows then gets the processor to run code within Windows to draw it?
ASKER
Thanks for your comments.
Inthe, I was expecting to see the text for messageDlgs etc as text, but that was all.
I expected the rest to contain a contiguous stream of hex code that the processor would process. ( Stuff like 7E FE 61 DA that would cause the processor to load accumulator A from HL compare it with character 'a' etc, etc.)
I didn't expect to see anything that would give any visual clues as to what the code was doing. And I certainly did not expect to see text reference to say a button, but just the hex code to create the button, ie a heap of instructions to load accumulators, shift, compare etc, etc to finally draw the button.
I reckon Micke has answered my question by saying that Delphi uses resources embedded inside the 'compiled' .exe "to create the forms and data modules in run time."
Just why it would create them at run time and not at compile time only adds more questions. It must be awfully slow to create objects on the fly at run time, but I suppose it gives some flexibility.
This reminds me of a question that's been on my mind for a while - why don't the Delphi handbooks and help screens give the number of machine cycles for each instruction. I've only seen references like "inc(a) is faster than a := a+1" but there's no reference to how much faster, like "inc(a) = 4 machine cycles, a := a+1 = 27 cycles".
It sounds like it's all to do with Windows, is it that my exe isn't actually run directly by the processor, but that it tells Windows to draw a form and Windows then gets the processor to run code within Windows to draw it?
Inthe, I was expecting to see the text for messageDlgs etc as text, but that was all.
I expected the rest to contain a contiguous stream of hex code that the processor would process. ( Stuff like 7E FE 61 DA that would cause the processor to load accumulator A from HL compare it with character 'a' etc, etc.)
I didn't expect to see anything that would give any visual clues as to what the code was doing. And I certainly did not expect to see text reference to say a button, but just the hex code to create the button, ie a heap of instructions to load accumulators, shift, compare etc, etc to finally draw the button.
I reckon Micke has answered my question by saying that Delphi uses resources embedded inside the 'compiled' .exe "to create the forms and data modules in run time."
Just why it would create them at run time and not at compile time only adds more questions. It must be awfully slow to create objects on the fly at run time, but I suppose it gives some flexibility.
This reminds me of a question that's been on my mind for a while - why don't the Delphi handbooks and help screens give the number of machine cycles for each instruction. I've only seen references like "inc(a) is faster than a := a+1" but there's no reference to how much faster, like "inc(a) = 4 machine cycles, a := a+1 = 27 cycles".
It sounds like it's all to do with Windows, is it that my exe isn't actually run directly by the processor, but that it tells Windows to draw a form and Windows then gets the processor to run code within Windows to draw it?
If you want your exe files to be inscrutable then get yourself one of the many free exe encryptors... they usually install a small asm program near the start of your exe and when your exe runs this decrypts the bytes of the exe before they are placed into memory.... you could compress the exe first and then encrypt it... that ought to make it look strange and plain-text free to snoopers with a hex editor :-)
> It must be awfully slow to create objects on the fly at run time
I don't think so but it can be tested very easily, by creating a form with some components at designtime and then another at runtime in code, and comparing the times they take to create.
If you're worried about using the .dfm resources, don't use them.
GExperts www.gexperts.org even have a wizard called 'Components to Code' which will allow you to design a form and then generate the corresponding code for selected components.
> why don't the Delphi handbooks and
help screens give the number of machine cycles for each instruction
Try View\Debug Windows\CPU menu during debugging ;-)
I don't think so but it can be tested very easily, by creating a form with some components at designtime and then another at runtime in code, and comparing the times they take to create.
If you're worried about using the .dfm resources, don't use them.
GExperts www.gexperts.org even have a wizard called 'Components to Code' which will allow you to design a form and then generate the corresponding code for selected components.
> why don't the Delphi handbooks and
help screens give the number of machine cycles for each instruction
Try View\Debug Windows\CPU menu during debugging ;-)
Oops, for Delphi 3 you need to add a registry entry to enable the CPU View:
http://delphi.about.com/compute/delphi/library/howto/htcpuview.htm
http://delphi.about.com/compute/delphi/library/howto/htcpuview.htm
ASKER
Thanks to everyone.
You have all been helpful, so I'll accept the first comment as the answer and then post points for the rest.
You have all been helpful, so I'll accept the first comment as the answer and then post points for the rest.
just to note
>>is it that my exe isn't actually run directly by the processor
exactly otherwise we could run our applications irrespective of operating stsyem..delphi is compileing our app to a win32 pe format exe which is i suppose you could say controlled by the windows os..
>>is it that my exe isn't actually run directly by the processor
exactly otherwise we could run our applications irrespective of operating stsyem..delphi is compileing our app to a win32 pe format exe which is i suppose you could say controlled by the windows os..
Compiler (the following are on, the rest are off):
Optimisation
Aligned Record Fields
I/O errors
Debug Info
Local Symbols
Reference info
Definitions Only
Assertions
Show Hints
Show Warnings
Strict var-strings
Extended Syntax
Open parameters
Huge strings
Assignable typed constants
Linker:
Map file - OFF
Linker Output - Generate DCU's
Hope that's what you needed
The Neil =:)