Following on from my last question on implementing the Microsoft Active Script debugger interfaces on 64 bit windows. I have come across another intractable problem.
This time it's with IActiveScriptDebug which doesn't seem to work in its 64 bit incarnation.
The code in question is when attempting to set breakpoints using the code from MS example debugger code (converted to Delphi).
Href:=FEngine.QueryInterface(IID_IActiveScriptDebug,FdebugEngine);
Href:=FdebugEngine.EnumCodeContextsOfPosition(0,Line,LineLen,edcc);
if IEnumDebugCodeContexts(edcc).Next(1,dcc,numFetched) = S_OK then
Href:=dcc.SetBreakPoint(BREAKPOINT_ENABLED);
Where Fengine is the IactiveScript Language engine and FdebugEngine is the returned IActiveScriptDebug object and edcc is a IEnumDebugCodeContexts;
IID_IActiveScriptDebug is set to the IID_IActiveScriptDebug64 GUID for 64bit windows and IID_IActiveScriptDebug32 for 32 bit windows. In both cases a valid debug engine is returned.
Compiled for 32 windows, this code works fine. I can set breakpoints and the get the callbacks on breaks.
Compiled for 64 bit, FdebugEngine.EnumCodeContextsOfPosition returns a "Catastrophic failure" Hresult.
Any ideas why the 64 bit code produces this error ?
So after much chasing my tail and the lack of responses from this forum, I have come to the conclusion that the 64 bit version of the Active script debugger is broken and there is no prospect of it getting fixed as it seems to be deprecated.
So I leave this here as a warning to anybody wanting to implement this feature and let them know not to waste their time.
I have the new Dell XPS 15 Kaby Lake version with 3840x2160 resolution and text size set to 200%. Now, the Delphi XE2 looks terrible, some parts:
or I tried to set various settings via it's shortcut in Properties->Compatibility, I also tried to search the internet, but I only found that people care about the look of their applications, but our application looks well. Problem is only with the Delpi XE2 loooking so bad it's unusable on my laptop.
Any help how to easily fix it?
EDIT: I have Windows 10 installed.
Ok, I fixed it without help from internet by trying various settings of the shortcut:
It was needed to disable "Disable display scaling on high DPI settings" and also to enable "Combatibility mode" and set it to "Windows XP (Service Pack 3)", both settings were needed together, the program loads very slowly now, but good enough and the GUI is displayed perfectly.
I just added the '64 bits platform' to my project and my Delphi (XE7) keeps generating a huge RSM file (which increases the compilation time). According to the Help this should not happen if the 'Include remote debug symbols' option is disabled.
And in my case it is disabled.
There is something else to be disabled?
from http://embarcadero.newsgroups.archived.at/public.delphi.ide/201203/12030416462.html
Delphi XE2 generates RSM files that are several MB in size. As I
understand it, these files are for remote debugging. Is there a way
to turn off the generation of these files?
Yes. In the Project Options look on the page "Delphi Compiler\Linking"
for "Include remote debug symbols" and turn it off if you do Win32
debugging. Note it is necessary for Win64 debugging.
and continuing on http://www.devsuperpage.com/search/Articles.aspx?G=2&ArtID=20168
The IDE is 32-bit, because that's the only way it can work on both 32
and 64 bit versions of Windows. (Win64 can run 32 bit apps, but Win32
can't run 64 bit apps.) That's why the remote debugger is used for 64
bit and cross-platform apps.
Jeff Overcash from TeamB
Is the reason that Delphi XE2 is not itself really 64-bit?
Sure, then it can't be run on 32 bit OS's. All third party components
won't work at all until a 64 bit version of it exists (a 64 bit IDE
would not be able to load a 32 bit bpl), this would be a major reason
for people not to upgrade too. Supporting both a 32 bit and 64 bit
IDE doubles the testing time for little to no benefit.
Does FastMM makes your executables bigger? I notice my app grows about 300-500kb, which is rather big for me. I already turn off the delphi compiler option to exclude the debug info, but the size doesn't change.
I use the FastMM's FullDebugMode to on, is this affecting the size? But when I try to turn it off, it looks for libc, which I couldn't find.
Help please... I'm using D5
First of all, it doesn't really matter. Programs compiled with that option aren't meant for general distribution. They're meant to help you find the problem so you can fix it and then ship a correct version of your program without the debugging options enabled.
Second, half a megabyte is only big if you still distribute on floppy disks. Whether that's truly much space depends on how big your program was beforehand. Compress your program when you distribute it, and you'll probably hardly notice the difference.
Finally, to the crux of your question, yes, full debug mode makes your program bigger. It should be obvious that enabling that mode adds more code. It adds the code that does all the debug checking, such as checking for heap corruption, generating stack traces, catching the use of freed interfaces, logging errors to a file, and logging memory leaks. It also adds code to load and use the full-debug-mode DLL, and it changes any assembler functions to be written in plain Delphi instead.
The compiler option about debug information should have no effect. It controls whether debug information is included in the DCU files; that information is always excluded from the EXE files (unless you're talking about TD32 debug information, but you shouldn't enable that anyway since you're not using Turbo Debugger).
If your program is looking for the Libc unit, then you did more than turn of full debug mode. You somehow turned on Linux mode. You're not using Linux, so don't turn on that mode. If you're stuck, replace your copy of FastMM4Options.inc with the original version and start over.
The FullDebugMode use a pure pascal version of the FastMM4 heap manager.
This version marks blocks, so that any memory leak will be tracked and reported.
But in all cases, it won't NEVER add 300-500 KB to your executable.
It will be slower than "normal" FastMM4 mode, because of the pascal version of the coding (less optimized than asm) and because of the extra checks performed (e.g. the blocks marking).
But the 300-500 KB executable size increase is NOT related to FullDebugMode. It's only a matter of some dozen KB (in worst case), because most of the used code stays in the external FastMM_FullDebugMode.dll library.
You should have changed by hand some Project Options, like the TD32 info or the remote debugging info. But these info are not required with FastMM4 in full debug mode, as far as I understand.
FastMM should compile with D5 and it shouldn't look for libc, which is Linux library. There's problem with latest versions when compiling under D5 (like this), try the latest source code from source repository?
I release a single executable (.EXE) for a desktop program using Delphi 2009. I have no external DLLs or resources that I need for the program to run.
I use two components: LMD Innovative's ELPack and Sergey Tkachenko's TRichView that are compiled into my executable.
When I build my production version, using the "Release" build configuration, the executable file produced is 13,533 KB.
Prior to using Delphi 2009, I was using Delphi 4. The executable it produced was only 2,671 KB while incorporating the same two components and basically having the same code as my current version.
I do understand that Delphi 2009 is completely Unicode (which is the main reason why I upgraded), and being Unicode can cause up to a doubling of size. But this is about 5 times larger.
Is there a reason why my executable has to remain 5 times larger? Or are there some simple ways to cut down a significant chunk of the executable size?
Please note. Some people are answering with ways to compress the Delphi EXE. That is not what I am trying to do. I am trying to simply see why so much space is being used to remove what might not be necessary. If that is done, compression can still be done afterwards if so desired.
It really doesn't matter how big or small the executable is once it is installed. It is for downloading purposes and to minimize server load and download times that you want to compress it. I prefer to use Inno Setup and compress the program inside the install routine itself. Then when it is installed, it is expanded to full size. That both prevents possible detection as a virus and eliminates the extra startup time needed to uncompress the program in memory. Also I code sign both my executable and my install routine and some compression techniques are incompatible with that.
For more info about compressing, see the StackOverflow question: Delphi EXE compressor?
ldsandon asked me to provide exactly what options I'm using, so here they are:
(source: beholdgenealogy.com)
(source: beholdgenealogy.com)
When moving from Delphi 7 to Delphi 2010., our .exe's grew for example from 16 megs to 35 megs.
I asked a question similar to yours on the Embarcadero forum a few weeks ago. (link) In my OP, I listed a series of links on this subject that you might find helpful.
We tried using UPX to compress our .exe's. Letting it work for hours significantly reduced our .exe, but we probably won't use it in production for these reasons:
We have quite a few .exe's and don't want to wait 1/2-day on each build. (It's possible that we could find a non-brute force set of parameters to UPX that would reduce this...)
Although the size of the .exe is reduced, our shippable was not, because our installer (not surprisingly) is unable squeeze much more compression out of the already compressed file... whereas it was able to reduce the original 16 meg .exe down to 8 megs.
I've read some reports that at some time (rarely, but not never), UPX exe's triggered various anti-virus programs to report the application contained a virus. (I don't recall the date, site, or details of where I saw this, so it's a bit unfair of me to report it here.) But, we are so adverse to taking a risk of that even possibility happening, that UPX is off the table...
The link on the Embarcadero forum also includes a link to another SO thread on this topic.
I continue to be surprised and disappointed at the code bloat we found when moving to Delphi 2010. As Nick notes, 2X for Unicode is quite excessive.
However, the bloat is a relatively minor trade-off when moving to D2010, because, IMO, D2010 is such a terrific upgrade in so many other ways. But, it does mean that we'll probably have to move to shipping 2 CDs rather than one. I'm not looking forward to seeing the reaction to this from our organization...
Without seeing the actual settings that your "Release" build configuration uses explaining this increase in size requires a great deal of speculation.
Beyond some perhaps unlikely factors resulting in a vast increase in the amount of code being "dragged in" even though it isn't used, that magnitude of increase would most easily be explained by the inclusion of debug information.
I would check your compiler and linker settings for:
Debug Information (compiler setting)
TD32 info (linker)
Remote debug info (linker)
Compare these settings in your Delphi 2009 project with the equivalents in Delphi 4.
Factor out the expected 2X increase from Unicode and you end up with a 2.5X increase unaccounted for. This makes sense considering how many versions you've skipped. A lot's been added to the VCL and RTL since Delphi 4, and not all of it is stuff that can be easily smartlinked out, even if you never use it. Depending on how many units you're using, you could be hauling in quite a bit of extra baggage.
Allen Bauer and the compiler team added a new feature into D2010 to help reduce this, but apparently they're treading cautiously and didn't use it in as many places as they could have. Hopefully we'll see more cruft reduction in 2011 and subsequent releases.
I will add my few words.
Linker can remove unused procedures and functions only if it can follow the code hierarchy. The nightmare list for linker listed below:
Message-driven code, the sad news is that this code can't be removed whatsoever, that's why Delphi blank project size continues growing from version to version. Every new windows message (WM_TOUCH for example as long as I know introduced recently) creates procedure call hierarchy that can't be removed (even if you don't have plan to use Touch API at all). This is because every case WM_: fragment is something linker can't decide whether it will be used or not.
Code and data structures accessed from the begin end, initialization, finalization secions of the units. Here you have some control, remove unnecessary calls or object creation. Even if you create objects on demand and only free them in finalization section, make it carefully
Use "upx - compress or expand executable files" # http://upx.sourceforge.net
If you go to tools/configure tools, and set it up like this, you can compress the executable that you're working on easily via a menu item in the IDE.
Another way is to have a look to 'what unit increase the size ?'.
To do this, I use the JCL 'Project Analyser IDE', integrated in the IDE with the JCL/JVCL installation, it show you all the units with their respective size. You can export it in text file.
If you do it with the 2 environnements (D4 & D2009) you will have a lot of pertinent informations.
I've done some tests to see the difference between D2007 and D2010, because we are upgrading to D2010. I've tested a medium sized management GUI application, with about 60 forms (grids with detail forms, frames, etc). We're using TMS components + Remobjects.
D2007:
"normal" compilation: 18.8mb
with debug dcu's: 18.8mb (same size!)
D2010
normal: 23.9
debug dcu's: 48.8mb (!)
So using debug dcu's doubles our exe size...
Test with our business service (no big dfm's):
D2007: 12.3mb
D2010: 17.1mb
So yes, D2010 increases the exe (a bit), but this is not a problem for my customer.
Edit: some information about compiled size:
D2007:
D2010:
So an increase of code size, but a more than doubling of the data!
If you don't want to use an exe compressor then you should give StripReloc a try.
Check format of your dfm-s. They must be in binary format if you want to make your exe smaller.
1) You are generating a detailed map file, and because you've set "used debug dcus" it will also contains symbols for the RTL/VCL units. If it is used by an exception handling systems to generate call stacks and the like, it could be added to the executable. And if not compressed somehow, it could make your .exe size pretty large.
2) Using debug dcus will also make your .exe somewhat larger because usually they are compiled without optimization and debug options set, and they will make also your code slower. They shouldn't be used in a release version.
3) Debug information should add debig info only to the unit and not to the executable, although it is required IIRC to generate the map file.
Since D2010 adds extended RTTI, and RTTI is a notorious factor in increasing exe size, it would be interesting to see how big D2009 binaries are for that application.
If D2009 binaries are significantly smaller, it is not Unicode etc. For my own binaries, I only have a 30% increase or so going from D7 to D2009.
It has been stated earlier that using an executable compresser reduces the size of the exe but not of the install package. However, if you want a good compressor then try ASPack.
#Tom1952: ASPack is pretty fast, just a few seconds to compress a file
Also you can change the Icon. Icon in newest delphi IDE (ie XE3) is Vista/7 compatible and contains all sizes (up to 256x256 as far as I know). So you can reduce exe file size with changing the Icon.
The standard units in you newer delphi may contain more strings and constants such as error strings, that is included even if you disable debug information. Check your uses.
Don't have much of a somution besides not using a specific unit, or removing unneeded data from it.
(My experiences are with Delphi 5)
For Delphi 10.3 Rio with default setiings:
Step 1: Switch from Debug to Release in "Projects" window. This reduced my exe file from 22 MB to 5 MB !
Step 2: Use an exe compresor like ASPack. It further reduced my exe file to 1.3 MB. Unbelievable, isn't it ? :)
Uncheck debug information in project options.
If embarcadero can't provide any solution or explanation!!! I think the solution is simple: don't stuck only with Delphi there is a lot of programming languages, every one is limited only by programmer imagination.